@keszegh, yes, that's pretty much the issue I have too, detecting that the player was closed either by the user or by ZBS. I guess it should be possible to check if the process is still running with its pid
my issues with my project came from the fact that mobdebug was not in the root folder. if it is in some subfolder then how should i require it?
also, a print right after requiring mobdebug is not printed but if i put it later enough then it does. what does this depend on? can you make every print printed?
finally, after quitting the player, every print is repeated once again (with those prints appearing too which were not appearing (as being too close to require for example). can you make it that this does not happen?
also, a print right after requiring mobdebug is not printed but if i put it later enough then it does. what does this depend on? can you make every print printed?
finally, after quitting the player, every print is repeated once again (with those prints appearing too which were not appearing (as being too close to require for example). can you make it that this does not happen?
Not sure how ZBS fetches gideros logs. Did you try my improved gideros interpreter for ZBS (GiderosLink, https://forum.gideros.rocks/discussion/comment/68714 #Comment_68714) ? Meanwhile I improved quit/disconnect handling.
it still does not work. zbs does not crash anymore but also the app is not started in the player.
It works for me with latest ZBS, but you also need latest Gideros since it requires an updated bridge/daemon to work
i see, sounds good. for now i'm stuck with 2023.9.1 due to imgui rendering issues mentioned in the other thread. hopefully those will be sorted out and then i'm back to the latest version.
the gideroslink you said works nicely, it seems that now i don't need to kill the gdrdaemon task manually anymore. i have to stop debugging with shift-f5 manually though after i quit the player.
i've noticed that the performance when debugging (that is when i start the code with mobd=require('mobdebug').start("192.168.0.164")) is really bad, my app starts to lag quickly. even if i do nothing with debugging (no prints, no breakpoints). could this performance somehow improved? i do not seem to recall that in the lua days debugging slowed down the player this much. without debugging it is good.
also in gideros ide where it is theoretically debugging too, it runs fast. even with many prints. btw how can i add breakpoints in gideros ide? i seem to remember that it was possible but i can't find how.
I am afraid that enabling mobdebug automatically enable debugging hooks, which means that some extra code will be run after each lua instruction to check if line was changed or a breakpoint was hit. I can review the coded added for mobdebug compatibilty, to see if things can be improved.
When Gideros IDE is in charge of debugging, those hooks are enabled too but handled directly in C code, instead of relying on lua hooks. Maybe this is why mobdebug is slower currently.
To set a breakpoint in Gideros Studio, just click at the beginning of the line number column, to the left of the line number.
ah, i did click at the beginning of the line but not left enough. there should be some menu item too for adding/removing breakpoints though.
yes, probably lua is way slower than c in this sense, when i'm running for cycles on each frame on multiple arrays that have size>1000. i don't know what you can do but anything is appreciated. at least if i'm right and past zbs debugging was faster, then there must be some way to make the slowdown more reasonable. thanks a lot.
yes, probably lua is way slower than c in this sense, when i'm running for cycles on each frame on multiple arrays that have size>1000. i don't know what you can do but anything is appreciated. at least if i'm right and past zbs debugging was faster, then there must be some way to make the slowdown more reasonable. thanks a lot.
I had a second look at the code, and I don't think it can be made significantly faster. We could probably optimize a few calls, but I doubt this will make a big difference.
@hgy29 , thanks for looking. it is a bit bad as i need to turn on/off debugging depending on if i want to really debug something specifically, as otherwise it is too slow to test the app itself. but still way better than having no debugging at all, so thanks for your recent efforts in this direction.
Comments
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Meanwhile I improved quit/disconnect handling.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux, keszegh
without debugging it is good.
also in gideros ide where it is theoretically debugging too, it runs fast. even with many prints. btw how can i add breakpoints in gideros ide? i seem to remember that it was possible but i can't find how.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
When Gideros IDE is in charge of debugging, those hooks are enabled too but handled directly in C code, instead of relying on lua hooks. Maybe this is why mobdebug is slower currently.
To set a breakpoint in Gideros Studio, just click at the beginning of the line number column, to the left of the line number.
Likes: MoKaLux, keszegh
yes, probably lua is way slower than c in this sense, when i'm running for cycles on each frame on multiple arrays that have size>1000. i don't know what you can do but anything is appreciated. at least if i'm right and past zbs debugging was faster, then there must be some way to make the slowdown more reasonable. thanks a lot.
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game