zerobrane lua IDE with gideros support.. what do you think about this ide(a)?

paulclinger

> @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.

keszegh

[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).

paulclinger

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

keszegh

@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.

paulclinger

@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.

keszegh

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.

Mells

@keszegh if you have the knowledge to do it, I would be very interested in reading your "simpler and more to the point tutorial"

keszegh

@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.

keszegh

@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

paulclinger

@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.

keszegh

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

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

keszegh

@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.

simwhi

@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.

paulclinger

@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

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

notice that it outputs:
"Starting project file '...\.tmp\'."
while the previous zbs outputs:
"Starting project file '...\myproject.gproj'."

paulclinger

@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

@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.

keszegh

@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.

SinisterSoft

imho the people who make that zerobrane ide need to look at the github source code or contact one of the maintainers so it can be sorted out.

totebo

@keszegh, maybe if you use strict.lua these thing would be flagged?

http://metalua.luaforge.net/src/lib/strict.lua.html

paulclinger

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

@keszegh, I would be interested to see how gideros studio does it as I can only show what's being sent by the process the IDE launches to the standard output/error stream (in this case it's "gdrbridge play" command).

keszegh

@paulclinger, i don't have knowledge about the workings of gideros inside, check
https://github.com/gideros/gideros
or more specifically this may be a place to look for (i guess only):
https://github.com/gideros/gideros/tree/master/ui

but maybe @ar2rsawseen or other core members can help out too.

keszegh

i tried using strict. lua, as @totebo suggested, but it did not help, the same thing, no error message, just the app does not start in player.
so it seems that the error messages (evoked by strict.lua in this case) are not received by zbs. if this is due to gdrbridge, then some core developer should help out @paulclinger how to receive error messages.

keszegh

somebody, please help @paulclinger, as gideros studio drives me to hell, i'm too used to the outline window of zbs. switching between the two editors is also annoying, as i need to close them so that the debug messages arrive where they should.

ar2rsawseen

I think nothing much will be possible till we separate communication with player into separate command line tool. Like we did with export recently, which is now completely controlled from command line.

Unfortunately I have couple of large features in to do list before that would be accomplished

BTW is Gideros support implemented in the core of zerobrane, or there is somekind of plugin mechanism? Cause if it would be plugin, it could be easier, cause that would allow to manage it on both sides, Paul's and Gideros community

keszegh

there is a gideros lua in the interpreters folder of zbs, i think basically that is doing the communication:
https://github.com/pkulchenko/ZeroBraneStudio/blob/master/interpreters/gideros.lua

as far as i remember in the past (say 1 year ago) error messages were handled by zbs correctly, so perhaps something can be done to make it work again even before complete separation of communication with player.

paulclinger

> as far as i remember in the past (say 1 year ago) error messages were handled by zbs correctly, so perhaps something can be done to make it work again even before complete separation of communication with player.

@keszegh, it's possible that it worked in the past because ZBS debugger is using debug.traceback assignment trick that only works with Lua 5.1. If/when gideros switched to LuaJIT, it stopped working.

> BTW is Gideros support implemented in the core of zerobrane, or there is somekind of plugin mechanism? Cause if it would be plugin, it could be easier, cause that would allow to manage it on both sides, Paul's and Gideros community

Yes, as @keszegh said, it's a separate interpreter module and I've been thinking about making it a standalone plugin, which would allow some additional functionality, like a filetree menu with project management functions. It would also be in the separate package repository and you (or anyone else) could submit changes to it.

> I think nothing much will be possible till we separate communication with player into separate command line tool. Like we did with export recently, which is now completely controlled from command line.

@ar2rsawseen, if this somehow works for Gideros Studio, maybe the same mechanism can be used in ZBS as well? How does run-time error get reported back to the IDE in your case?

ar2rsawseen

Interesting, as far as I know there is nothing changed much, that could affect that.

First step would be to determine what have changed.
Does new zerobrane work ok with old Gideros, or new Gideros with old zerobrane?
That way we would know on which end lies the problem