[ZeroBrane Studio] Re: Live coding details

  • From: Paul K <paul@xxxxxxxxxxxxx>
  • To: "zerobrane@xxxxxxxxxxxxx" <zerobrane@xxxxxxxxxxxxx>
  • Date: Thu, 25 Aug 2016 11:41:35 -0700

Hi Rob,

Is there a way to either find out when a file has been reloaded by the 
debugger for live coding? Either a variable to check (when the file is being 
loaded) or a function we can call?

Yes, but sort of. There is mobdebug.onscratch event (added recently in
0.64) that is called after a new content has been evaluated, but it
doesn't know anything about "files" as it only deals with code
snippets. It gets the result of the evaluation as its parameter, so
you can probably signal this way which of the chunks has been
evaluated.

Paul.

On Thu, Aug 25, 2016 at 11:34 AM, Rob Probin <rob.probin@xxxxxxxxx> wrote:
A quick question:

Is there a way to either find out when a file has been reloaded by the
debugger for live coding? Either a variable to check (when the file is being
loaded) or a function we can call?

I guess I could set a file local or global variable after initial loading
(of the whole app, or the specific file), then check that when loading the
file.

Any other ideas?

The basic thought it to copy the state from the old (with partial
re-initialization) and/or replace old instances with the new version (if I'm
using an oriented approach).

Regards,
Rob



On 24/08/2016 20:14, Paul K wrote:

Hi Rob,

So I understand how the restart entire application works, but how does
the reload current tab work? Does it send mobdebug an effective "dofile(f)"
command?

Your understanding is correct. There is a small difference between
"scratchextloop" true/false values is that when the value is set to
"true", the application is suspended, the code in the current tab is
executed and the application then continues. When the value is
"false", the application is not only suspended, but is actually
stopped, so when the code in the current tab is executed, the
application starts from scratch. The "true" value works well for
applications that have some event loop where updating its "draw"
method would change the result. The "false" value works for simple
applications that may need to be completely restarted.

Also keep in mind that you can add more tabs to live coding by using
local menu in the editor and selecting "Add to Scratchpad". It will
add more tabs to live coding monitoring, but still only the current
tab will be reloaded.

Paul.

On Wed, Aug 24, 2016 at 11:20 AM, Rob Probin <rob.probin@xxxxxxxxx> wrote:

Hi,

So, as far as I understand:

"There is an interpreter parameter that controls live coding:
"scratchextloop" (you may check the existing interpreters for its use):

It's set to "nil" by default, which means that the interpreter doesn't
support scratchpad and all related functionality will be disabled in the
IDE.
You can set it to "true" and this will make scratchpad to work by
reloading
the current editor tab without
restarting the entire application (this is what you'd expect with most of
gaming frameworks, which have some "draw" function, like love2d, corona,
gideros, and others),
You can set it to "false" and this will make scratchpad to restart the
entire application (this is how it's done for the default Lua
interpreter)."


So I understand how the restart entire application works, but how does
the
reload current tab work? Does it send mobdebug an effective "dofile(f)"
command?

I'm considering whether I can get the state in such a manner that, for
instance, on a game a single entity would carry on with changes ... much
like Notch does with Minecraft here with the skeleton:
https://www.youtube.com/watch?v=BES9EKK4Aw4 ;(from 0:25 onwards).
Reloading
the skeleton in the world with default parameters would be reasonable as
well. (I think this applies for a lot more than just games).

Regards,
Rob


P.S. I also know:

"Mobdebug can only reload the application when it can "suspend" the
script
from debug hook, which can only be done from Lua code."

"To avoid checking if there is a new "suspend" request too frequently
(which
negatively affects performance) it's only done every 200th hook call,
which
may be too large for your example (if the check is only done once a
second).
You may adjust this by setting
"require('ZeroBraneStudio.mobdebug').checkcount = 1" before starting
debugging."






Other related posts: