Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 317 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
zerobrane lua IDE with gideros support.. what do you think about this ide(a)?
keszegh
Member
Hi, i just noticed that the following lua IDE now/soon supports moai with debugging and code-completion:
http://studio.zerobrane.com/
perhaps it could support gideros as well if the gideros team contacts them. i would definitely be interested in it, probably others as well.
http://studio.zerobrane.com/
perhaps it could support gideros as well if the gideros team contacts them. i would definitely be interested in it, probably others as well.
Likes: phongtt
Longtitle Productions, creator of
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
+1 -1 (+1 / -0 )Share on Facebook
Comments
http://www.nightspade.com
You should still be able to debug Gideros applications with a bit of manual work. Here is what you can do:
1. Start the player using this batch file (the configuration is needed for it to find the debugging and socket libraries included with the IDE):
set ZBS=D:\ZeroBraneStudio\
set LUA_PATH=%ZBS%lualibs/?/?.lua;%ZBS%lualibs/?.lua
set LUA_CPATH=%ZBS%bin/?.dll;%ZBS%bin/clibs/?.dll
start "Player" "D:\Program Files\Gideros\GiderosPlayer.exe"
2. Add the following line to your main.lua file; this is where debugging will start:
require('mobdebug').start()
3. Start ZeroBrane Studio and select Project | Start Debugger Server (if it's enabled; if it's disabled, it means it's already started)
4. Run the bridge to start your application in the player:
"D:\Program Files\Gideros\Tools\gdrbridge.exe" play "Sleeping Bodies.gproj"
You may need to run it twice if the bridge was not connected.
You should see now in the IDE a green arrow pointing to the start() line you added and a message in the output window: "Debugging session started in 'D:\Program Files\Gideros\Examples\Physics\Sleeping Bodies\'."
I've tested on several samples that included with Gideros on Windows and stepping, breakpoints, watch view, stack view, and interactive console all seem to be work as expected. I plan on posting a detailed blog post in a day or two. I'm also working on running the player/bridge from the IDE directly to eliminate these manual steps, but I ran into some technical issues that I'm hoping to resolve soon.
Likes: gorkem, zaniar
Fragmenter - animated loop machine and IKONOMIKON - the memory game
http://www.nightspade.com
Paul.
This integration eliminates most of the manual steps I described earlier. These are the steps you need to do:
1. Specify path to your Gideros player: add something like "path.gideros = 'd:/Program Files/Gideros/GiderosPlayer.exe'" to cfg/user.lua (there is an example in cfg/user-sample.lua).
2. Set project directory to your project folder
3. Add the following line to your main.lua file; this is where debugging will start:
require('mobdebug').start()
Now you can use Debug (F5) to debug your application and the Player will launch automatically (in fact, you better not have a running copy as it will launch another copy and the two may be in conflict).
As I couldn't find a way to pass parameters to the player, Run and Debug commands behave in exactly the same way; the only difference is the require('mobdebug').start() line. If you have the line, your script will be debugged; if not, it will run from the IDE as it would normally run (in the player). If someone knows how to pass parameters to the player, please let me know.
Also, I checked the MacOS package, but couldn't find the Tools folder with the bridge files. Is it not available on Mac? I could make the same integration work on OSX too.
On OSX it's at
/Applications/Gideros\ Studio/Gideros\ Studio.app/Contents/Tools/gdrbridge
cheers
evs
With ZeroBrane (which, incidentally, looks really nice) will there be the possibility of debugging using the Gideros player running on a real device (in my case under iOS). Or are we limited to the desktop player for debugging?
best regards
Assuming luasocket is included on the actual device, you will need to do the following:
1. Include mobdebug.lua in your project (it's in lualibs/mobdebug/ folder).
2. Start the debugging server in the IDE: Project | Start Debugging Server and note the domain name it listens on; it wll show you something like "Debugger server started at DOMAIN-NAME:8171."
3. Change "require('mobdebug').start()" to "require('mobdebug').start('DOMAIN-NAME')"; use the same domain name the debugging server is using.
When you start the application on the device, it should connect to the IDE and start the debugging. You would need your main.lua file to be open in the IDE. This should work the same way on both OSX and Windows. Give it a try and see if it works for you.
best regards
I'll post an update when I'm done with OSX integration.
Give it a try.
Object:connect: ....
init_memory_pool: ...
Increasing refcount of happy-box.png. New refcount is 2.
Increasing refcount of happy-box.png. New refcount is 3.
...
fps: 59.2022
fps: ...
I don't see this on Windows and it looks like a leftover from some debug output (and it clutters the output as it's generated at least once a second). I disabled output in the IDE from the player on OSX, but will enable it back if needed.
Here's what I've done so others can follow along and you can check if I've done it correctly.
0) I installed the ZeroBrane from GitHub.
1) I launch ZBS and I see an error (Trying to solve a NULL hostname)
2) Set project folder to my Gideros project directory and open main.lua.
3) I carry on and run the debug server. It announces itself on localhost:8171. I don't think this will be sufficient to identify the host from the connected iPad so I go to System Prefs/Network and find out my local IP address. It is 192.168.1.101.
4) I add socket.lua and mobdebug.lua to the Gideros project file. I assume I have to do this inside Gideros IDE since the ZBS doesn't seem to know about the .gproj file. Is that right?
5) I choose Project/Lua Intepreter/Gideros in ZBE.
5) I edit main.lua and add 'require("mobdebug").start("192.168.1.101")'. I click next to a line in my main.lua that comes somewhere after the above in order to set a breakpoint.
6) I start the Gideros player on my iPad.
7) Now, I DO NOT choose Project/Start Debugging in ZBS. This would launch the desktop player which is not what I want. Instead I go to Gideros Studio, make sure that I reload my changed main.lua, and hit run.
8) The app stops at the breakpoint and I can see it in ZBS. I can continue / step etc. Look at variables in the stack window. Way cool!
Apart from WAY COOL. Here are my comments:
1) Obviously it would be nice not to have to have the Gideros Studio running in to launch the app in the player but to be able to do this from ZBS.
2) Choosing Project/Stop Debugging actually exists the player on the device. Really it should just return to the player start screen
3) Gideros has a notion of groups inside the .gproj project file. When the files are copied to the device a new folder structure is built to match these groups. This is usesul because it allows you to share code easily between projercts. ZBS only knows about the folder structure on the host computer which may not match the group structure. Hence it may not be possible to set breakpoints in these grouped files.
4) I think that debug output that you've disabled is quite important. Up to now we Giderans, having no debugger, have been used to littering our code with trace messages via print statements. Even with breakpoints these trace messages are still quite useful. @atilim did provide a means of turning the repetitive messages off but one has to call it explicitly inside a plugin. Maybe @atilim could disable the messages by default so they have to be explicitly enabled.
5) The stack view display is a little confusing. Why does it list the top level function as (e.g.) "anonymous function at line 263" rather than displaying the function name?
6) I'd quite like toolbar buttons to control the debugger step/continue/step into functions. The function keys on a Mac are a pain because they require that extra Fn modifier key.
7) Could the stack window be docked inside the main IDE?
8) Can I modify variable values in the stack window? Maybe by using the remote console and writing a bit of Lua to do it?
9) Ideally, I'd like to be able to change the ZBS font (or use the standard system font)
Anyway, Bravo! I shall keep playing around.
Best regards
> 1) I launch ZBS and I see an error (Trying to solve a NULL hostname)
can you please email me the screenshot to the address as the bottom of this page (http://studio.zerobrane.com/)?
> 3) I carry on and run the debug server. It announces itself on localhost:8171. I don't think this will be sufficient to identify the host from the connected iPad so I go to System Prefs/Network and find out my local IP address. It is 192.168.1.101.
I'll replace default "localhost" with an IP address if it's available.
> 4) I add socket.lua and mobdebug.lua to the Gideros project file. I assume I have to do this inside Gideros IDE since the ZBS doesn't seem to know about the .gproj file. Is that right?
Correct. It uses the .gproj file to launch the project, but doesn't know anything about its structure and doesn't modify it.
7) Now, I DO NOT choose Project/Start Debugging in ZBS. This would launch the desktop player which is not what I want. Instead I go to Gideros Studio, make sure that I reload my changed main.lua, and hit run.
Correct.
> Apart from WAY COOL. Here are my comments:
> 1) Obviously it would be nice not to have to have the Gideros Studio running in to launch the app in the player but to be able to do this from ZBS.
This would be my preference too, however, I can only work with the tools provided by Gideros. As far as I understand, the protocol between G Studio and G Player has not been published. I tried to reverse engineer it using wireshark, but it was too much work and I wasn't sure it wasn't going to change in the next version. So I went with the only documented way to launch the application.
> 2) Choosing Project/Stop Debugging actually exists the player on the device. Really it should just return to the player start screen
Agree, but for the same reason I don't have a way to cleanly abort the application. I simply use os.exit(), which exists the player (same thing happens locally). I'm sure there is some internal call that G Studio is using to abort the application, but I'd need to know the protocol. I'll look into using "gdrbridge stop" command, but it also requires the IP address to be configured.
> 3) Gideros has a notion of groups inside the .gproj project file. When the files are copied to the device a new folder structure is built to match these groups. This is usesul because it allows you to share code easily between projercts. ZBS only knows about the folder structure on the host computer which may not match the group structure. Hence it may not be possible to set breakpoints in these grouped files.
I'll need to try that. The IDE has some fuzzy logic in searching for appropriate files to activate. You'll need to have a file open and it will try to match the file with the one where breakpoint fired. You can also enable autoactivation, which will try to locate the file and open it for you, but it's even more difficult to do if the names on the device don't match those in the local file system (as you described).
> 4) I think that debug output that you've disabled is quite important. Up to now we Giderans, having no debugger, have been used to littering our code with trace messages via print statements. Even with breakpoints these trace messages are still quite useful. @atilim did provide a means of turning the repetitive messages off but one has to call it explicitly inside a plugin. Maybe @atilim could disable the messages by default so they have to be explicitly enabled.
I'll enable it back. You can also open interpreters/gideros.lua and find line with "not mac" and replace it with "true". There should only be one instance.
> 5) The stack view display is a little confusing. Why does it list the top level function as (e.g.) "anonymous function at line 263" rather than displaying the function name?
I just show whatever information I get from the Lua interpreter on this.
> 6) I'd quite like toolbar buttons to control the debugger step/continue/step into functions. The function keys on a Mac are a pain because they require that extra Fn modifier key.
I'll see if those can be added.
> 7) Could the stack window be docked inside the main IDE?
Not at the moment, but I'll look into that.
> 8) Can I modify variable values in the stack window? Maybe by using the remote console and writing a bit of Lua to do it?
Yes, you can switch to remote console and run any Lua code there. It will be executed in the context of your application, so whatever you do there will have immediate effect on your app (as long as it's stopped in the debugger). The stack view and the watch view will also reflect those changes.
> 9) Ideally, I'd like to be able to change the ZBS font (or use the standard system font)
You can add the following lines to cfg/user.lua:
editor.fontname = "Courier New" -- or any other font you want to use
editor.fontsize = 11
Look at src/defs.lua for a complete list and at cfg/user-sample.lua for examples.
@bowerandy, one question. In terms of doing everything from the IDE (assuming I can solve these technical issues in terms of interacting with the player on the device), I've been thinking that I could add a comment to start() line where you specify the IP of the device you want to connect to. Something like:
require('mobdebug').start('192.168.1.101') -- IP.of.your.device
I can then use this information to run the bridge to load the application to the player (not tested) and also use this information to stop the player gracefully. This would potentially minimize the switching between the IDEs. The deployment would still need to be done from G Studio though.
Paul.
I would have thought that adding that "callback" IP address would be fine. One has to do a similar thing in Gideros Studio anyway - once you start the player on the device you have to tell the IDE what IP it reports.
The only disadvantage I can see to this is that, if you wanted to debug your final app executable (i.e. not via the player) then you wouldn't necessarily get a chance to find out what the device IP address was (since it wouldn't be reported onscreen like it is with the player). However, in reality, you would probably have run the player just before and could get the IP address from that anyway. Does that make sense?
Looking at all of these issues, the only one that is making me hesitant to switch to ZBS right now is (3). I have a whole bunch of shared libraries (just Lua files in other directories). What would your suggested approach be to including these in a ZBS project with out copying them across into the project directory?
Oh, and one more request. I recently wrote a Gideros plugin called Hot Wax which gives access to all the iOS Cocoa libraries directly from Lua. As part of that package I wrote a bit of Lua script to dump out all the method names in a form that the Gideros Studio IDE uses for its autocomplete. Is there a similar way to tell ZBS about this autocompletion information?
best regards
I have created a file ~/.zbs/user.lua which contains:
editor.fontsize=40
And restarted ZBS. I don't see a change in the IDE font?
That error message, I reported on startup of ZBS can be seen here
best regards
> The only disadvantage I can see to this is that, if you wanted to debug your final app executable (i.e. not via the player) then you wouldn't necessarily get a chance to find out what the device IP address was (since it wouldn't be reported onscreen like it is with the player). However, in reality, you would probably have run the player just before and could get the IP address from that anyway. Does that make sense?
It does, but you wouldn't need to specify the device IP address. You'd only need to specify the IP address of the IDE (using the start() method), like you do now. This is the only thing that is requires to start the debugging (with or without the player); the rest of the steps exist just to make the process more convenient for the users.
Just to highlight the two ways to do this. You should be able to debug your application without the player (as long as you have luasocket and include mobdebug.lua like you did). To enable that you only need to include start() call with the domain name or IP address of the IDE.
When the player is used, its IP is only needed because I need to configure the bridge to communicate with the player to start the application you want to debug (note that the current integration only works locally). When the application is started (with or without the player), the debugging is again initiated with the start() method.
> Looking at all of these issues, the only one that is making me hesitant to switch to ZBS right now is (3). I have a whole bunch of shared libraries (just Lua files in other directories). What would your suggested approach be to including these in a ZBS project with out copying them across into the project directory?
You don't need to worry about projects in ZBS. They don't include files; they exist to provide convenient access to files you are most likely to access. You can still open, use, and debug files outside of the project structure. I do plan a couple of features related to projects (for example, closing/opening editor tabs for files related to a project and remembering the interpreter you used with that project), but the main idea is the same: you are not limited in any way to using files in your project. Does this resolve the issue for you?
> Oh, and one more request. I recently wrote a Gideros plugin called Hot Wax which gives access to all the iOS Cocoa libraries directly from Lua. As part of that package I wrote a bit of Lua script to dump out all the method names in a form that the Gideros Studio IDE uses for its autocomplete. Is there a similar way to tell ZBS about this autocompletion information?
This is most definitely possible. ZBS already includes auto-complete for love2d, moai, and other libraries, and it can be extended to cover more. You can see the files in api/lua/ folder. In fact, I'll probably convert your structure into the one that ZBS recognizes shortly. Do you have a similar one for Gideros API? Ideally with function descriptions.
> I have created a file ~/.zbs/user.lua which contains:
> editor.fontsize=40
> And restarted ZBS. I don't see a change in the IDE font?
Put user.lua into cfg/ folder under ZeroBraneStudio. .~/.zbs was not a good choice and will be changed to ~/.zbstudio shortly.
> That error message, I reported on startup of ZBS can be seen here
"Trying to solve a NULL hostname: giving up". Never seen this before, but I may know how to avoid this.
Paul.
I think what you are saying about the projects means that I should continue to use Gideros Studio to organize a project (if nothing else because one needs a .gproj file to be able to eventually export the app) but then just use ZBS for editing and debugging?
The Gideros autocompletion file is in Applications/Gideros Studio/Gideros Studio/Contents/Resources/gideros_annot.api. It is a text file and I just append my cocoa_api.txt file to it. I did ask @atilim what the various fields meant but he was a bit vague and I didn't push it since he was probably busy.
BTW, there is one bug that I've come across and it is rather irritating. It turns out that one can edit source files while debugging but, once debugging terminates, all of the changes are lost. I managed to lose about 10 minutes typing that way. I think you should disable the editor while debug is in progress.
I'm certainly enjoying being able to debug stuff, I can tell you :-)
best regards
I think so as I can't offer much help in terms of packaging the application and pushing it to the player. It will be possible to write plugins with ZBS, and this may be one of the tasks for a plugin. Just curious, what would you expect in terms of .gproj file management? You can always open it in ZBS and edit manually, but to push all the files to the device, I need to know the protocol and I haven't seen any details on it.
> The Gideros autocompletion file is in Applications/Gideros Studio/Gideros Studio/Contents/Resources/gideros_annot.api. It is a text file and I just append my cocoa_api.txt file to it.
Looks good. I should be able to add auto-complete for both of these to ZBS.
> BTW, there is one bug that I've come across and it is rather irritating. It turns out that one can edit source files while debugging but, once debugging terminates, all of the changes are lost. I managed to lose about 10 minutes typing that way. I think you should disable the editor while debug is in progress.
@bowerandy, can you provide bit more details on this? When you start debugging, all the editor tabs in the IDE switch to read-only and you shouldn't be able to change anything. If you open a new window while debugging, it's not set to readonly (which may be considered a bug), but whatever you type there won't be lost. When the debugging terminates, all your windows should be kept in exactly the same state (in other words, there is no special logic to restore anything that may remove your changes). I should be able to fix this if I can reproduce it.
> I'm certainly enjoying being able to debug stuff, I can tell you.
Very glad to hear that. The debug buttons are almost done, btw...
Paul.
This is the error:
best regards
I'll update the MANIFEST files to fix the error and to add the icons.
https://play.google.com/store/apps/details?id=com.uglygames.slug
You need the latest pre-release version from GitHub, until the official release!
https://github.com/pkulchenko/ZeroBraneStudio
cheers
evs
Likes: duke2017
otherwise keep up the good for, zbs is my favorite ide.
Fragmenter - animated loop machine and IKONOMIKON - the memory game