Trigger reloader from somewhere else.

[stuaxo]

I'd like a way of triggering the reloader from somewhere else, and when the code isn't necessarily in a file.

In Shoebot we execute code once per frame that may be in a .
New code can arrive from an external editor, which we crudely swap out.

It would be good if if we could use reloadr and call something to tell it that the new code has been updated and what it is.

We have a crude rollback system too - if the code raises and exception or has a syntax error, we roll back to the last known good code and state.
Not sure if that's in the scope of reloadr, but would be good, we use that so that the user can edit code as it's drawing animations etc.

[stuaxo]

(I'm not quite sure if this is a dupe of #6)

[stuaxo]

Here is out very crude approach to code loading
https://github.com/shoebot/shoebot/blob/master/shoebot/grammar/livecode.py#L44

I'm hoping to replace it with something modern.

[hoh]

Generating graphics is one of my motivations for creating reloadr.

Would you have a small video demonstrating how you use the shoebot editor so I can see how your code reloading works for a user ?

[stuaxo]

Here you go:

https://www.youtube.com/watch?v=foxzx0JFU5g

The editor used here is gedit with a plugin.
Shoebot gets new code every time the user presses a key.
Currently this is via stdout to shoebot as a subprocess - I can show you the code, but the code in shoebot classic is pretty old and crusty now, hence me building something new :)

[stuaxo]

Since code reloading may trigger weird side effects, the user can turn toggle turn it on or off ("live coding")

[hoh]

Interesting approach with the tenuous mode in shoebot's code.

Do I understand that shoebot will reload every function within the target ?

[stuaxo]

Do I understand that shoebot will reload every function within the target ?
Yes, with a bunch of caveats, because it's very dumb:

• It only updates the __code__ object in functions in the main file/code.
  This is usually OK as a lot of bots are in a single files, but updating other modules that were updated as well would be better.
  Variables come along for free, but doing these explicitly would probably be better.
• It doesn't know about renamed functions, so state is lost there.
• It doesn't play well with threads
  I made a basic audio API with a background thread and that isn't happy.

There are some things unavoidable in this approach ..

• Output to files / sockets in tenuous state is going to happen anyway if it happens before the error that causes things to be reverted.
• You need a drawing model that allows this (i.e. drawing to a buffer or a dummy output when tenuous).