@paulclinger, I wonder how difficult it would be to work with multiple Scratchpad files in ZBS. Only the currently selected file would be "live" and updating at any one time, but I'd like the ability to be able to switch between files during a single session. I have an idea for another demo which would need this, I think.
@bowerandy, it's not very difficult, but the trick is to know what editor events to track. You can search the code for scratchpad.editor to see what components refer to that functionality. There are 3 changes to the editor(s) when you turn scratchpad on:
1. Any changes to the text are being tracked 2. Mouse movements are being tracked to provide sliders 3. Number style is changed to provide underlining
The problem is not so much in enabling it; the problem is in usability. I had it enabled for all windows originally, but because you may have windows opened that have nothing to do with this particular script you're executing, any change in those windows will likely to cause errors in your application as it will be executing some arbitrary code.
You can still make changes in other windows, and execute selected block by doing "right click" | "evaluate in console"; not as convenient as background execution, but is limited to only those changes you do want to execute.
If you are still interested to give it a try, I can tell you what 2-3 changes to make if you want to test it; it won't be a permanent fix, but will be good enough to see if it works for you. Let me know.
@bowerandy, as an option, I can possibly add "Add to scratchpad" option to the "context/right click" menu to add the current editor tab to the scratchpad. This makes it more explicit and allows me to know exactly when to set those editor events and to what. It will also be useful for any new files you may open/create during that debugging session.
Hi @paulclinger. Well I certainly wouldn't want to enable it for all windows, just selected ones. And even then I'd only want the changes to the currently selected editor tab to be compiled and sent to the running app. Is that possible with your idea about the right click menu option?
@bowerandy, right, only the changes in the currently modified window will be sent to the application. The right click menu option will simply enable tracking of changes in a particular editor tab.
I'll give it a try as soon as I get this release out (there is only one bug and one feature left).
@bowerandy: FYI, I pushed couple of changes that improve error reporting during live coding. With these changes all compile errors are reported locally, which allows your application to continue working. All run-time errors are reported by the application as before.
I also shorten the code fragment reported in the error message to make it easier to see what the error message actually is.
I also added syntax aware indentation while I was at it...
@paulclinger, that's great about the shorter error message, I had been meaning to put in a request for that.
With your first change (above), about reporting compile errors locally, does this mean that while you are typing with a compile error in your code, the changes won't stop the application from running? If this is the case then I agree that it's a very good idea. I was messing around with ZBS yesterday, and it was something I noticed was breaking app the flow while I was typing. If your latest change is as I understand it then that's a great move.
I haven't tried the new version yet. I'll see if I get a bit of time later today.
@bowerandy, yes, it should work exactly as you describe and that was the intent: only run-time errors will now stop your application (and even those can be ignored to a degree with pcalls).
Please give it a try when you get a chance as I'm putting finishing touches before a release and want to make sure this part works not only for me.
I did see again one problem I came across before when making the demo video though. There is something a little screwy when using the auto complete. If one types in some text for which there are several autocomplete options, it doesn't seem possible to arrow down and choose anything other than the first offering. I assume that the down arrow key is the correct one to use?
Just try typing "app" into a file and you'll see that you are offered "Application" and "application". I don't seem to be able to choose the latter.
@bowerandy, I noticed the same thing; not sure what's causing it, but it is something I'm looking into. It seems to be a Mac-only problem, and only when using cursor keys for navigating the auto-complete list. The workaround is to use the mouse or to type enough to get your option to be first and then press Tab.
@paulclinger I enjoyed Zerobrane a lot however if you could find a way to get the print messages from Gidores to show up on your console it would be great. I am on MAC and without that it is tough to depend on Zerobrane completely.
i tried your IDE, and i like it with the debugging feature
but
i'm on windows and it seems there are no output printed in the IDE output window. im using gideros 2012.9 player. and the output already says "Debugging sessions started...",
also it seems i cant break in the middle of execution unless i hit the break execution process button multiple times.
and also after it hit breakpoint, i encountered an error from mobdebug saying that a variable is not declared although in gideros IDE it ran just fine. i dont know if this is the cause, but im using strict.lua
> i'm on windows and it seems there are no output printed in the IDE output window. im using gideros 2012.9 player. and the output already says "Debugging sessions started...",
> also it seems i cant break in the middle of execution unless i hit the break execution process button multiple times.
That's a feature of how the debugging works. It will only break when the execution is inside Lua code and in some cases it may be in C++ internal functions of Gideros/Lua; in this case you may need to "break" several times.
> and also after it hit breakpoint, i encountered an error from mobdebug saying that a variable is not declared although in gideros IDE it ran just fine. i dont know if this is the cause, but im using strict.lua
Can you post the full error message? I applied a fix on October 10th that should make the debugger strict.lua friendly. If you are using an earlier version, you may want to get the latest code from Github.
@bysreg, yes, this seems to be reported by strict.lua (and probably doesn't have anything to do with ZBS). You need to follow @atilim's advice and put log.dll he has attached to his post into Gideros/Plugins/ folder. This should fix this issue.
Just small suggestion, you may want to not stopping at require("mobdebug"), because i think i dont want to be bothered to clicked the play button two times to get the simulator running, and maybe ctrl+tab shortcut will be better if it acts like notepad++
@bysreg, there is an option for that, but it's not available from a config file yet.
You can still give it a try though. Open interpreters/gideros.lua and find "DebuggerAttachDefault()" call. Replace it with "DebuggerAttachDefault({runstart=true})".
Start the IDE and run the debugger. It shouldn't stop on the start() line now. You'd need to "break" the execution or set a breakpoint before starting the debugging.
"DebuggerAttachDefault({runstart=true})" works for me. Thanks.
Just something that is a bit of a nag.
When using the player with the original Gideros editor, you can change the Hardware settings in the player and they are remembered by Gideros editor even if you shut down both and restart.
However for the ZB Editor, the settings you make in the player are NOT remembered and when you start a session in ZB it keeps on using the settings you last saved using the Gideros editor.
If you were say testing a game in Gideros and set the hardware to 768x1024 with a zoom of 50% - ipad
Now if you open ZB and load an iPhone project and run it, and change the player settings to say
320x480 zoom 100%
it does change in the player. But if you stop the app to make changes and rerun, the Player restarts to 768x1024 with a zoom of 50% and you have to change it again to
320x480 zoom 100%
Even if I start the player manually and change the resolution and Zoom, when the app is run in ZB, it does not use this player session already open, but opens another and reverts to the original zoom/resolution. The only way I found to get ZB to open the player to my new resolution is to run Gideros and then open the player from it , make the Hardware settings changes, shut both down and restart ZB so it will now use the changed player settings.
This can be very annoying after a while.
Is this something that is in the way the player is started by ZB or what? Is it possible to get ZB to respect the player settings that have been changed a-la-Gideros editor without the torturous route of changing it in Gideros as above?
@bernard, there should be an easy solution. After you change the settings, instead of closing the debugging/running session from ZBS (which "kills" the player), simply close the player when you are done. ZBS will recognize this and close the debugging session and the player will remember its settings and will retain them next time it's started form ZBS.
@nascode, the new code should be interpreted as soon as it's entered. If there is a compilation or run-time error, it should be reported in the output window.
The effect may depend on the structure of your application; I remember @bowerandy was using "restart the app" button to toggle this mode on/off, but he is out of pocket for the rest of this week.
If you still have trouble to see the changes, maybe post your code and I should be able to look at it tomorrow.
@paulclinger what the ctrl+tab in notepad++ do is switch to the document you recently viewed, for example the first document i see is 1.lua and then i switch to 2.lua and then to 3.lua, when i hit ctrl+tab it'll swith to 2.lua and when i hit ctrl+tab again, it'll switch to 3.lua, but when i hit ctrl+tab+tab it'll swith to 1.lua.
@bysreg, there is a ticket opened with a similar request, but you can already move between the tabs using Ctrl-Tab and Ctrl-PgUp/Dn, although it's not in the most recently viewed order. I'm not sure I'm going to implement most-recently viewed order, although there is Recent Files menu and maybe I'll add navigation for those files.
Hi @paulclinger, i'm evaluating your IDE, but i'm stuck in certain point... everything works fine, but when i click the pause (break execution), the Gideros Player goes to Not Responding till i resume again (play button).
Do you have an idea of what could be wrong? I believe it's my fault somewhere
Comments
best regards
1. Any changes to the text are being tracked
2. Mouse movements are being tracked to provide sliders
3. Number style is changed to provide underlining
The problem is not so much in enabling it; the problem is in usability. I had it enabled for all windows originally, but because you may have windows opened that have nothing to do with this particular script you're executing, any change in those windows will likely to cause errors in your application as it will be executing some arbitrary code.
You can still make changes in other windows, and execute selected block by doing "right click" | "evaluate in console"; not as convenient as background execution, but is limited to only those changes you do want to execute.
If you are still interested to give it a try, I can tell you what 2-3 changes to make if you want to test it; it won't be a permanent fix, but will be good enough to see if it works for you. Let me know.
best regards
I'll give it a try as soon as I get this release out (there is only one bug and one feature left).
I also shorten the code fragment reported in the error message to make it easier to see what the error message actually is.
I also added syntax aware indentation while I was at it...
With your first change (above), about reporting compile errors locally, does this mean that while you are typing with a compile error in your code, the changes won't stop the application from running? If this is the case then I agree that it's a very good idea. I was messing around with ZBS yesterday, and it was something I noticed was breaking app the flow while I was typing. If your latest change is as I understand it then that's a great move.
I haven't tried the new version yet. I'll see if I get a bit of time later today.
best regards
Please give it a try when you get a chance as I'm putting finishing touches before a release and want to make sure this part works not only for me.
I did see again one problem I came across before when making the demo video though. There is something a little screwy when using the auto complete. If one types in some text for which there are several autocomplete options, it doesn't seem possible to arrow down and choose anything other than the first offering. I assume that the down arrow key is the correct one to use?
Just try typing "app" into a file and you'll see that you are offered "Application" and "application". I don't seem to be able to choose the latter.
best regards
i tried your IDE, and i like it with the debugging feature
but
i'm on windows and it seems there are no output printed in the IDE output window. im using gideros 2012.9 player. and the output already says "Debugging sessions started...",
also it seems i cant break in the middle of execution unless i hit the break execution process button multiple times.
and also after it hit breakpoint, i encountered an error from mobdebug saying that a variable is not declared although in gideros IDE it ran just fine. i dont know if this is the cause, but im using strict.lua
thank you
> i'm on windows and it seems there are no output printed in the IDE output window. im using gideros 2012.9 player. and the output already says "Debugging sessions started...",
What output do you expect to see? If you need to add log messages, you can follow @atilim's recommendation posted earlier in this thread (http://www.giderosmobile.com/forum/discussion/comment/13147#Comment_13147). You should then see these messages in the output window.
> also it seems i cant break in the middle of execution unless i hit the break execution process button multiple times.
That's a feature of how the debugging works. It will only break when the execution is inside Lua code and in some cases it may be in C++ internal functions of Gideros/Lua; in this case you may need to "break" several times.
> and also after it hit breakpoint, i encountered an error from mobdebug saying that a variable is not declared although in gideros IDE it ran just fine. i dont know if this is the cause, but im using strict.lua
Can you post the full error message? I applied a fix on October 10th that should make the debugger strict.lua friendly. If you are using an earlier version, you may want to get the latest code from Github.
Paul.
i tried that one by adding this two line :
require("mobdebug").start()
print = log
in main.lua
but i got "main.lua:3: variable 'log' is not declared" (maybe this one is connected to the strict.lua)
yesterday, i downloaded it from your git repo with zip
thanks
all right, now i can see the output. thank you!
Just small suggestion, you may want to not stopping at require("mobdebug"), because i think i dont want to be bothered to clicked the play button two times to get the simulator running, and maybe ctrl+tab shortcut will be better if it acts like notepad++
You can still give it a try though. Open interpreters/gideros.lua and find "DebuggerAttachDefault()" call. Replace it with "DebuggerAttachDefault({runstart=true})".
Start the IDE and run the debugger. It shouldn't stop on the start() line now. You'd need to "break" the execution or set a breakpoint before starting the debugging.
What does Ctrl-Tab do in notepad++?
"DebuggerAttachDefault({runstart=true})" works for me. Thanks.
Just something that is a bit of a nag.
When using the player with the original Gideros editor, you can change the Hardware settings in the player and they are remembered by Gideros editor even if you shut down both and restart.
However for the ZB Editor, the settings you make in the player are NOT remembered and when you start a session in ZB it keeps on using the settings you last saved using the Gideros editor.
If you were say testing a game in Gideros and set the hardware to 768x1024 with a zoom of 50% - ipad
Now if you open ZB and load an iPhone project and run it, and change the player settings to say
320x480 zoom 100%
it does change in the player. But if you stop the app to make changes and rerun, the Player restarts to 768x1024 with a zoom of 50% and you have to change it again to
320x480 zoom 100%
Even if I start the player manually and change the resolution and Zoom, when the app is run in ZB, it does not use this player session already open, but opens another and reverts to the original zoom/resolution. The only way I found to get ZB to open the player to my new resolution is to run Gideros and then open the player from it , make the Hardware settings changes, shut both down and restart ZB so it will now use the changed player settings.
This can be very annoying after a while.
Is this something that is in the way the player is started by ZB or what? Is it possible to get ZB to respect the player settings that have been changed a-la-Gideros editor without the torturous route of changing it in Gideros as above?
Ha. That works fine. Thanks.
awesome work!
I am trying the new version and then use Run as Scratchpad option on Mac Gideros Player, when will the new codes get interpreted?
http://www.nightspade.com
The effect may depend on the structure of your application; I remember @bowerandy was using "restart the app" button to toggle this mode on/off, but he is out of pocket for the rest of this week.
If you still have trouble to see the changes, maybe post your code and I should be able to look at it tomorrow.
what the ctrl+tab in notepad++ do is switch to the document you recently viewed, for example the first document i see is 1.lua and then i switch to 2.lua and then to 3.lua, when i hit ctrl+tab it'll swith to 2.lua and when i hit ctrl+tab again, it'll switch to 3.lua, but when i hit ctrl+tab+tab it'll swith to 1.lua.
Do you have an idea of what could be wrong? I believe it's my fault somewhere
Thanks!