Quick Links: Gideros Home | Download Gideros | Developer Guide
zerobrane lua IDE with gideros support.. what do you think about this ide(a)?
  • keszegh +1 -1 (+1 / -0 )
    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.

    Likes: phongtt

  • yes, me too. zerobrane would be a nice addition.
  • This is really epic, remind me of flashdevelop for as3 coding, lightweight complete IDE. Looks like it could help gideros dev too. Hopefully @atilim will take a look at this
    have fun with our games~
    http://www.nightspade.com
  • paulclinger +1 -1 (+2 / -0 )
    Member Accepted Answer
    Thank you for your interest in ZeroBrane Studio. Yes, the IDE indeed supports moai/love2d debugging and auto-completion. I've been working on integrating support for Gideros too, but it's not quite complete yet.

    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

  • wow, that sounds good, you already work on it, that's much better than i could hope. thanks for your work paulclinger
  • @paulclinger great job! cant wait to try it out
    have fun with our games~
    http://www.nightspade.com
  • Just one quick note. If you use a packaged version (0.32), stay away from the Stack view as there are some issues that have already been fixed in the master branch.

    Paul.
  • @nascode, @keszegh, @lobo, @gorkem: I added Gideros integration, but it's only available from the github repo until the next release (shouldn't be long).

    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.
  • evsevs +1 -1
    Member
    Hello,

    On OSX it's at

    /Applications/Gideros\ Studio/Gideros\ Studio.app/Contents/Tools/gdrbridge


    cheers

    evs
  • Hi @paulclinger,

    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
  • @bowerandy, this is something I'd like to know too ;). I've tested this debugger on other mobile platforms (like Mosync with MobileLua) and I could use it to debug on iOS and Android devices.

    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.
  • @evs, thanks for the OSX location. I'll update the integration code to work on OSX too.
  • @paulclinger, could you post when you've got that OSX integration updated (I'm on Mac) and I will endeavour to give that debugging on the device a whirl.

    best regards
  • @bowerandy, the integration code needs to be update only for local debugging (the one you start from the IDE). You can still give the remote debugging a try as it should work with the current code.

    I'll post an update when I'm done with OSX integration.
  • @bowerandy, pushed the changes for ZeroBrane Studio to support integration on OSX. It will also check for gideros in default folders (/Applications on OSX, C:\Program Files\ and D:\Program Files\ on Windows), so if it's installed there, you don't need to configure anything.

    Give it a try.
  • I noticed one issue with the player on OSX. I see some output in the IDE like the following:

    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.
  • Hi @paulclinger. Hey, it works!

    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
  • @bowerandy: Thank you for giving it a try and for the detailed feedback! I'm very excited to hear it worked for you. I'll go over your comments item by item.

    > 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.
  • @paulclinger, thanks for those answers.

    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
  • @paulclinger, I'm a little confused as to how to create the config file.

    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
  • @bowerandy, thank you for the continuing feedback!

    > 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.
  • @paulclinger. Okay, I understand all that stuff about the player and the IP address now. I didn't quite get it before.

    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 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?

    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.
  • @bowerandy, I pushed several changes that may be of interest. I enabled the player output back on OSX, (I think) I fixed "Trying to solve a NULL hostname" warning (but it will still offer "localhost" if it can't find a hostname), and I added debug buttons to the toolbar. Also, you can now put user.lua in .zbstudio/ folder in your home directory.
  • Hi @paulclinger. I've taken the new version and built it (I do a "build/build-dmg" is that right?). I do get an error in the middle but the build continues and produces the DMG.
    This is the error:

    tar: bin/libjpeg.a: Cannot stat: No such file or directory
    tar: Error exit delayed from previous errors.

    Anyway, I seem to end up with a working ZBS except that I don't see the icons for the new debugging toolbar buttons. There seems to be space in the toolbar but no icons. Have you possibly left out some files?

    best regards
  • @bowerandy, icons haven't been packaged for the distribution yet, but you can run the IDE from the repository clone. Just run ./zbstudio.sh (or bash ./zbstudio.sh) from the root folder and it should all work.

    I'll update the MANIFEST files to fix the error and to add the icons.
  • atilimatilim +1 -1
    Maintainer
    @bowerandy @paulclinger I've disabled these debug messages.
  • Project | Lua interpreter | Love2d, Lua, Muai - Gideros is missing my.. how to fix it?
  • evsevs +1 -1 (+1 / -0 )
    Member
    Hello @duke2017

    You need the latest pre-release version from GitHub, until the official release!

    https://github.com/pkulchenko/ZeroBraneStudio


    cheers

    evs

    Likes: duke2017

  • @paulclinger, do you plan to add a window showing the list of functions? that would make it even more easy to navigate in a file.
    otherwise keep up the good for, zbs is my favorite ide.
  • > @paulclinger, do you plan to add a window showing the list of functions? that would make it even more easy to navigate in a file.

    @keszegh, the dropdown in the toolbar is not enough? ;) yes, I do have plans to add something more elaborate than a dropdown, but there are several options being considered, so nothing is settled yet.

    > otherwise keep up the good for, zbs is my favorite ide.

    Good to hear! I just recently released v0.70. Will do a separate post on it.
  • [good for->good work]
    @paulclinger,
    a dropdown needs one more click and also one cannot see an overview, so an outline would be much better so that i always see the structure of the file. like in flashdevelop the 'outline' window, although in lua probably it's harder or impossible to list the variables too (although it would be great to list for each file the classes in it, for each class the functions and for each function the local variables defined there. and also the 'self.something' type variables where self is the current class).
    in any case just always having a window with the content of the current function list dropdown would be already quite good.

    another thing which might be hard to do but would be useful is autocompletion for classes and functions that we defined. i think on the forum somebody make kind of a script that parses the lua files and generates an autocomplete file from it, so something like this done automatically in zbs would be great.

    so these are my suggestions, but as i said i'm already quite happy with zbs (and the new ctrl-i auto-indentation is a blessing for me as i always mess up my code).




  • > so an outline would be much better so that i always see the structure of the file.

    @keszegh, thank you for the suggestions. Yes, I've been trying various approaches to see what may work as a replacement for that dropdown. What you are recommending may work, but it has some disadvantages as well. I'm curious, why are you interested in local variables? One problem with displaying local variables is that they may be defined in sub-chunks of a function; how would you display it then?

    Actually, what *may* work as an outline is a way to collapse all lines in a file that don't start a new block and don't start with "local". This gives you immediate overview of the file that you can still navigate. I'll need to try that, but it may work quite well (although it will need to be turned on/off as it will be hiding some of the lines).

    > another thing which might be hard to do but would be useful is autocompletion for classes and functions that we defined. i think on the forum somebody make kind of a script that parses the lua files and generates an autocomplete file from it, so something like this done automatically in zbs would be great.

    Functions are a bit easier; classes are more problematic. I can assure you that I'm researching a ways to support this as it could support various related functions (like auto-complete, code navigation, re-formatting, refactoring and so on), so I'm interesting in finding a good, fast, and reliable way to do this. I've been looking at typedLua and metalua to support this, but it's still very much in the prototype stage.

    Paul.
  • @paulclinger,
    i also doubt that locals i would be interested in much. on the other hand 'globals of a class', i.e. the variables that i define inside functions as self.var1 self.var2 etc. would be useful to see all the time.

    about the class and function structure/list an all-time visible list (in a window) would suit me better than your idea of one-click all-collapse, as by collapsing i just loose my place in the code and then i have to readjust when opening back. so my preference is something that is visually just like the file-list window now, contentwise it can be exactly the same as the function dropdown [and then a list of classes and self.var-s would be a plus, but less crucial].

    but it's up to you, of course, perhaps you may ask other users what they think/prefer to see if i'm alone.
  • @keszegh, I tend to agree; I was thinking about possible options to use temporarily, but I agree that a different representation is needed. I think I'll probably show all the files that are currently opened in different tabs and will keep the current file always expanded. I don't plan to do local variables, but it may be useful to have global variables, called functions, and upvalues.
  • i noticed that there is a new version, with outline window, which is just perfect.

    also i tried again the live coding stuff in it and it is quite simple and useful, wish i've started to use it much earlier. bowerandy's tutorial is great but i think there could be an updated and much simpler, more to-the-point tutorial as in fact a few lines can make it work for e.g. testing menu element positions you just make a global temporary function containing the positioning and you add an eventlistener calling it at enterframe. when you are happy with the position, you just delete the whole stuff.
  • @keszegh if you have the knowledge to do it, I would be very interested in reading your "simpler and more to the point tutorial"
    twitter@TheWindApps Artful applications : The Wind Forest. #art #japan #apps
  • @Mells, here it is (really basic tutorial):

    say you want to position/fine-tune something in some function Fun in some class Cla
    then

    inside Cla:Fun()
    add
    stage:addEventListener(Event.ENTER_FRAME, function(s) pcall(liveupdate, s) end, self)

    and in the root of the file (e.g. Cla.lua) add the function with the functions you want to fine-tune, e.g.:

    function liveupdate(self)
    self:setPosition(183,505)
    self.subObject:setPosition(100,100)
    self.subObject2:setScale(2)
    end

    now start a livecoding session and you can fine-tune the properties by changing the values, you can add new lines during this session to the function etc.

    when you are done, you paste back the content of liveupdate to the right place in Cla:Fun (in place of line where you added the eventlistener) and remove the line that adds the eventlistener.

    then you can use the same liveupdate function in a similar way to fine-tune some other properties in some other class. etc. you can do lot of other things.

    there are some limitations in what you can liveupdate, e.g. if the function is a local inside Cla:Fun() then it does not live update for me, but e.g. it could be a function of Cla, e.g. Cla:liveupdate(self) and it would still work. in any case this is enough so that one can play around with livecoding. i'm far from understanding it's quirks.

    also in an arbitrary function of some class if i change something during the live session and then the function is called again later, it did not update for me, so one really needs an onenterframe event for this stuff. i don't know why this is needed, as theoretically i don't see why it would not work. but anyway, it's already a strong tool.

  • @paulclinger, is it possible that when i stop the program with the stop button in zbs, then the giderosplayer keeps running? the problem is that it takes a while until the player starts up and so now it slows down the debugging process to stop/restart the player all the time, while if the player keeps running then only my program would be stopped/rerun etc, which would be much faster.
    thanks
  • @keszegh, I'll need to check on that. Are you suggesting to call `gdrbridge stop` instead? It does complicate things comparing with the current mechanism, but I'll see if it's possible to add.
  • thanks, probably gdrbridge stop, although i don't know what is called now, maybe @ar2rsawseen could help you out with these details.
    and best would be to be able to check somehow if a player is running and in that case the program is loaded into that, otherwise a player is started and loaded into that.
    and of course when pressing stop the player should rather not close.
  • paulclinger +1 -1 (+1 / -0 )
    Member
    > best would be to be able to check somehow if a player is running and in that case the program is loaded into that, otherwise a player is started and loaded into that.

    I agree, it would be useful (or even necessary to restart the script), but I'm not sure it's possible to detect that in a general way... I'll check.

    Likes: keszegh

  • keszegh +1 -1
    Member
    @paulclinger, any news about avoiding gideros player stop/run all the time?

    also, with v1.1 of zbs the project is not starting in the player. when i push the play button then a gideros desktop player starts and there is some feedback in the console, so connection is there, but the project does not start, so approximately 'gdrbridge play *.proj' is not happening.
  • simwhisimwhi +1 -1
    Member
    @paulclinger @keszegh I have also experienced this issue. I couldn't work out why it didn't work. I replaced the old mobdebug.lua file with the latest version but this didn't make any difference.
  • @keszegh, do you have any error or other indication in the Output panel on what may be causing the issue? Just in case, what version of Gideros are you using? I'll try to test on the same version...
  • keszegh +1 -1
    Member
    i use the latest (05.09) version, when the gideros player starts there is some log in the console (no errors), which is normal when starting the gideros player:
    "Debugger server started at lt7:8172.
    Program starting as '"C:\Program Files (x86)\Gideros\GiderosPlayer.exe"'.
    Program 'GiderosPlayer.exe' started in '...' (pid: 7840).
    Starting the player and waiting for the bridge to connect at 'C:\Program Files (x86)\Gideros\Tools\gdrbridge.exe'.
    Starting project file '...\.tmp\'.
    GL_VERSION:3.3.11672 Compatibility Profile Context

    GLSL_VERSION:3.30

    Loaded shader:1

    Loaded shader:2

    VIndices: 0,2,1,3

    FIndices: 1,2,0,4

    GL Program log:Validation successful."

    (i changed the path to my project to ...)
    then nothing happens.
    btw if in the now open player i manually start a project (file/open project) then it is debugged in zbs, e.g. the print command is sent back to the zbs console.
    that's why i think that the only thing not working is sending the project to the running gideros player.

    also i note that i changed some timeout values in gideros.lua as otherwise zbs does not wait enough for the player to start.
  • keszegh +1 -1
    Member
    notice that it outputs:
    "Starting project file '...\.tmp\'."
    while the previous zbs outputs:
    "Starting project file '...\myproject.gproj'."
  • @keszegh, can you try with the latest master branch of ZBS? I think I fixed that issue earlier, but it could indeed be a problem with v1.10. The workaround is to replace `FileSysGetRecursive(self:fworkdir(wfilename), false, "*.gproj")` with `FileSysGetRecursive(self:fworkdir(wfilename), false, "*.gproj", {folder = false})` in interpreters/gideros.lua. I haven't been able to test it yet, but I expect it to work. Let me know if you get a chance to try it.
  • keszegh +1 -1
    Member
    @paulclinger, i tried the latest master, it works for me.
    i had to change some timeouts (i changed a 15 to 115 and a 30 to 130 in gideros.lua), it would be good to know more about which number to change to what in gideros.lua to achieve a sensible balance so that the values are not too big but it waits until the player starts, so far i just make random adjustments until it works.

    in any case if you manage to detect if a player is running then probably you can do somehow that the player runs constantly and one can run/stop projects in it without stopping the player. that would be optimal.

    thanks for all, zbs is great.
  • @paulclinger,
    since a while (i really don't remember since when, but not always, i think) in zbs many errors are not handled.
    if there is a typo then it warns me in the output window. however, e.g. when i call a function like somefn:start() and somefn does not exists (it is nil), then there is no error message (in gideros studio there would be) just my app does not start in the player without warnings. another example if i accidentally try to make a texture from a non-existing file (mistype the file name) then there is again no error message and the app does not start.
    because of these i have to regularly run gideros studio when such an error with no message happens to find out what's happening, which makes debugging much more complicated.
    thanks for trying to handle this.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID

In this Discussion

Top Posters