[Snek] [PATCH v3] snekserver: allow network connections to a snigle Snek instance

[Keith Packard]

"Misha Gusarov" <dottedmag at dottedmag.net> writes:

> Hey,
>
> On 19 Apr 2020, at 12:24, Misha Gusarov wrote:
>
>> OK. I'll send implementation of reset/eeprom soon too.
>
> I tried to, and found out I don't understand the lifetime of Snek 
> top-level, and got it wrong for ev3 port too.

I'm not sure there's a 'right' and 'wrong' way here; it really depends
on what environment you're running in. For most embedded Snek systems,
there isn't a file system, so all there is is a single stored program
and the REPL.

> Let me see how I see it should work, and please tell me where it should 
> be corrected.

I can provide opinions, but you're welcome to make things work best for
your environment.

> * ./snek-ev3, no stored program
>
>     -> REPL
>
> * ./snek-ev3, a stored program exists
>
>     -> Run the program. SIGINT should exit into REPL

Well, if the stored program terminates all on its own, then you should
end up in the REPL. I feel like this makes these two about the same,
with an empty stored program doing nothing so that the REPL starts right away.

> * ./snek-ev3 --file foo.py, no stored program
>
>     -> Evaluate foo.py, exit into REPL
>
> * ./snek-ev3 --file foo.py, a stored program exists
>
>     -> Evaluate foo.py, then run stored program. SIGINT should exit into 
> REPL

Hrm. Maybe my '--file' option was just a bad idea. I used it while
debugging to that I could load a pile of code and then explore how it
worked using the REPL. I just looked at how Python deals with this, and
that has the '-i' option, which means to go into the REPL after running
the script instead of terminating. Maybe that's a better interface? At
least it avoids the question of how to handle 'snek --file foo.py
bar.py'?

> * ./snek-ev3 foo.py, stored program irrelevant
>
>     -> Run foo.py, SIGINT should exit Snek.
>
> * ./snek-ev3 --file foo.py prog.py, stored program irrelevant
>
>     -> Evaluate foo.py, then run foo.py. SIGINT should exit Snek.

Yeah, I definitely like the idea that specifying a script on the command
line skips any stored program.

> Now, how should reset() interact with these 6 modes?

reset() is supposed to 'reboot' the snek interpreter, resetting all of
the input and output ports to default values and clearing the snek
heap.

It's done on the Duemilanove by resetting the whole processor. On chips
with a USB port, I couldn't do that as that would drop the USB
connection. Instead, I hack up the linker script to separate the 'snek'
globals out from the 'system' globals and re-initialize just the 'snek'
values as if the system were coming out of board level reset.

I suspect rebooting the whole EV3 would be a bit more heavy weight than
necessary, are you just restarting snek using exec() or are you trying
to actually reset within the same executable environment?

In any case, that doesn't really answer your question at all...

For the case where you don't have a script specified on the command
line, I'd suggest following the embedded model and have reset()
re-initialize the system and re-run any stored program before entering
the REPL.

When there is a command specified, I can think of several options:

 1) Leave 'reset' undefined (like it is in the desktop build).

 2) Have reset throw an error when running a command line script.

 3) Call exit()

 4) Call exec() passing the same command line options you were given

 5) Call exec() passing an empty command line (which would re-run any
    stored program and enter the REPL).

It seems like option 1) and 2) are pretty similar, and 2) is likely a
bit easier. I do like this option as it makes snek with a script on EV3
work like it does on other posix systems?

3) doesn't seem like a great choice; the user may have no idea why snek
exited?

I don't have strong opinions about 4) or 5), although if you are
implementing reset when there isn't a command line script using exec(),
it's probably simpler to just use whatever code you've already got?

> Are all these modes relevant, maybe some of them are completely useless?

All good questions; let's start with the easy ones and decide if we
should switch from the current '--file' parameter to the (Python
compatible) '-i' option. I think that will reduce the number of problems
a bit.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://keithp.com/pipermail/snek/attachments/20200517/f1abd703/attachment.sig>