Here is a version for public testing. There still some known issues, but the success rate seems strong enough for broadened application. Please come back with any information gathered during usage. This could still be a quite powerful tool as soon as we crack the problem cases.
@Alfkil I see you release a new version of spotless2 , and give it a go in hope it have some improvements: by sadly, GUI acts bad still :( Just some simple actions cause freezes of GUI, and i not mean anything even loaded in, just simple navigate over the RMB menu and buttons cause 100% dead of the debugger's window.
For example, and easy to reproduce:
-- run spotless -- press RMB and choose "configure"
There is glitch right in this time : some strange empty button on the left/top angle.
second one which is very easy to reproduce to:
-- run spotless -- hit "load" button, and hit "chancel" there.
Then buton "load" start to be ghosted (like we load anything), and button "stop" start to be un-ghosted. Since that time, does not matter what you choose and press, spotless GUI is frozen.
I think while first one it simple logical bugs in the GUI code, the second one is missing handler of situation when nothing is loaded and changed for any reassons.
I am having my Amiga system back in a few days, and I will fix these two things.
Just to be clear : Normal functioning should work. That is, if you choose a file to debug and DON'T click cancel, it should actually load (provided it has been built with -gstabs), and you should be able to do at least a few successful moves around the code using steps. If it doesn't, then there must be something with the system updates.
@Alfkil I wasn't go that far to load a test binary as find issues right at begining without even loading binary, so once you will have time/motivation/ability to work more of it, i will happy stress test it all again as before till death :)
In principle, you should be able to downgrade to Final Edition CD version and use Spotless on that. But yes, practically it is only supported for latest beta kernel and elf.library.
I will update the readme once I am ready with version 2.0.1.
Actually, the problem with choosing cancel in the load requester seems to be not that simple. Apparently, the call to CreateNewProcTags returns a positive value, when just the folder is selected, and there seems to be no method to detect, if the load has actually failed. Could you maybe take a look at this?? This is in the SimpleDebug/Process.cpp file.
Cool ! What about this "empty small button" arise in the left/top area when you hit "configure" in RMB menu and then hit chancel ? It feels like something wrong with GUI code exactly
ps. is that on github ? I just checked https://github.com/alfkil/Spotless , but seems this one didn't updated for half of year.. maybe you have another repo for now ?
I have not done much work on it recently. But I have a few changes, that are in my local repository. I will commit them a little later.
EDIT: Actually that was useful input. I did have a repository criss-cross, with multiple instances of the Spotless repo with different improvements to each. I have now deleted unnecessary copies and reduced to one. I am hoping, that all my well formed changes are intact.
Edited by alfkil on 2022/10/27 16:22:42 Edited by alfkil on 2022/10/27 16:23:14
@Alfkil Tested the latest version from os4depot: bug with load/chancel fixed for sure. And in general it seems works now, but find bunch of small (and new) issues:
1. a bit broken packaging of archive:
-- Directory inside of archive named "Spotless_drawer", dunno for what. -- It didn't have directory "sobjs" with libstdc++.so anymore, is it expected ?
2. bugs:
-- RMB didn't works. I.e. menu spawns, but nothing can be called from, not ABOUT, not Configure, not Switching to public screen, nothing. Once you choose anything, it simple closes and nothing happens.
-- all entries in RMB menu marked with letter "A" the same for everything, like, "A" key for any entry.
-- Issue which i report back ago still there and with which we circles around for too long :( To reproduce:
Quote:
-- download this test case: https://kas1e.mikendezign.com/aos4/debug/spotless/test.tar and unpack it to "work:debug/spotless/" as it. So you will have test case binary/source and .txt file in the "work:debug/spotless/spotless-test".
-- run Spotless -- hit "load" button -- choose in the "spotless-test" directory a file "test" -- when it loads up , you will see name "test.c" on the left side, click on it to show the source. -- in source file, click on the line 30 to set breakpoint on it. -- hit START.
At this point , you crash. Sometime you may have crash with GR, sometime you may have crash without GR (just on serial), but whole GUI will be deadlocked. Sometime you will have no crash at all, but then, click "start" button again. This time you will be definately have crash/deadlock.
That is reproducable on my x5000 all the time, always with 100% reproduce on the very latest beta-kernel.
-- And another issue: seems StepInto now works just the same as Step Over. I.e. i can't step-in into prinfs() for example anymore
-- After making a breackpoint and hittin "Start" and then click on "Memory Surfer": the Memory Surfer window is just empty.
IMHO it's time to structure all well, so to have one single version you works on, and commits to the repo, so there will be "100% fine" code after those bugs will be fixed, and then add on top of it new stuff, so just easy to rollback. Because as it now, it looks the more you spend time on, the more we have old and new issues arise always and we still didn't have just this minimal functionality to work as expected :(
-- Directory inside of archive named "Spotless_drawer", dunno for what. -- It didn't have directory "sobjs" with libstdc++.so anymore, is it expected ?
Fixed.
Quote:
2. bugs:
-- RMB didn't works. I.e. menu spawns, but nothing can be called from, not ABOUT, not Configure, not Switching to public screen, nothing. Once you choose anything, it simple closes and nothing happens.
-- all entries in RMB menu marked with letter "A" the same for everything, like, "A" key for any entry.
Fixed.
Quote:
-- Issue which i report back ago still there and with which we circles around for too long :( To reproduce:
This one is tricky. I am pretty certain, that what is happening is, that one of the variables or entries in the structs are uninitialized. There should be a safety on memory reads detecting, if an address is readable. But apparently it doesn't work. So the unreadable address is being read, which causes a crash. I am trying to consult the dev team for assistance.
Quote:
-- And another issue: seems StepInto now works just the same as Step Over. I.e. i can't step-in into prinfs() for example anymore
As mentioned before : There is no stepinto for assembly functions in the main window, since there would be no code to show in the code box. If you want to step into assembly functions, you will have to do it from the lowlevel assembly debugger window (aka The Memory Surfer).
Quote:
-- After making a breackpoint and hittin "Start" and then click on "Memory Surfer": the Memory Surfer window is just empty.
I am really hoping, that I have solved all of your present inquiries. If not, I will be happy to receive any new and relevant complaints :).
To answer your question : I have not done an AmigaGuide, because I think the user should be able to figure out the gui without guidance. If this proves to be a problem, I will consider doing a guide (just like in the old days) for an upcoming version.
-- no more "strange button" when do configure -- RMB works -- switch to public screen works. -- "about" works -- hit "load" and then "chancel" - works. Tried it on both wb and public screen. -- "quit" button works
Stressed it for a while pressing all kind of unnogical and non-stardart combos (just to not load binary) - all seems ok.
So at least this version we can be sure have GUI works.
Through i have one suggestion for : rename "configure" item to something like "add additional source directories" or something of that sort, so GUI will be self-explained.
Another suggestion for GUI, is to open "memory surfer" a bit bigger. Now it just as small as possible, but imho worth to open it by default so to be as big as it needs to fit whole horizontal information. Or do it like in some of our projects : gadge on bottom right together with iconify, where we can choose snapshot/unspanshot .. But maybe that will for now overcomplicate the things, and maybe just open it a little bit bigger will be fine for now.
Next, another thing which i can't call a bug, but more not-correctly functional :
-- when you switch public screen (so to have spotless on it's own screen), and load a some test in it, then it it runs on workbench screen, and not on the Spotless one. I.e. if we have in test case printf("aaaaa\n"); then when we on the spotless screen, this "aaaa" window opens on the workbench screen. While, imho, should be on spotless screen (as this is the default screen now, when we swith to it).
So, now , the most important part , the debugger itself. Dunno what you did, but i can say that my test case which always cause a crash (that one which i report previously) seems gone. I can load as many times i wish that test case, and set any breakpoints i want - it works and didn't crash seems so. At least, from first and second time i can't reproduce it anymore. Tried at least 10 times.
I do have through one time freez when exit from debugger, and one time something was with the showing source on wb/public screen switch, but this ones i need to test more carefull to be able to reproduce normaly.
Another issue which i see right now, is that once i set breakpoint, hit start, and switch to variables, then while it works, it give me some garbage of 4 bytes under each entry in myTT: and in dup_prot_seletor doo. I.e. parts with values or addressses (like missing null termination or so).
Next issue the same when i hit breakpoint and hit start : swith to stacktrace : none. But this functionality surely works (in the profiler tool author get it correctly for sure).
Registers/disassembler/console seems fine at least at brief check visually (at least surely not trashing, etc, all looks sane).
As for GUIDE, imho then later indeed. We can just take DB101 as base, and just change relevant bits where need it (at least explaining of stepin,stepout,stepover are worth to be in).
If you care about opinion, then IMHO, we better to not add for now anything else, but only fixing those issues of what we already have. Then another beta, once everything fine, we can mark it as "stable" tag as "v2.1.0" for example, and so be sure that we have at least one version which 100% works. Debugger such an importan piece of software and this one can so easyly fuckup everything, so we need to be carefull there :)
Another issue which i see right now, is that once i set breakpoint, hit start, and switch to variables, then while it works, it give me some garbage of 4 bytes under each entry in myTT: and in dup_prot_seletor doo. I.e. parts with values or addressses (like missing null termination or so).
I really need to tidy up the context writeout. I know about this, but I have been reluctant to take a closer look, because it is really complicated and quite confusing. As long as the application works without crashes, I am tending to think, that it matters less with the variables writeouts. But indeed, I need to take a look on this somewhere along the line.
Quote:
Next issue the same when i hit breakpoint and hit start : swith to stacktrace : none. But this functionality surely works (in the profiler tool author get it correctly for sure).
Forgot to check this. Sorry! It is the first item on my todo list.
In general : I am really happy, that you feel this is the optimal version. I was quite confident, when I uploaded it, and I think sticking to this for a while is definitely the way to go. I want more tests, and I want to confirm, that this version is actually usable. All the previous versions can basically be scrapped, as they all had strange problems and issues. This one should have strong performance and actually have a chance of helping developers.
Yeah, for sure we need not add any new functionality, but fixing bugs in this version to make it as it should be.
Quote:
I really need to tidy up the context writeout. I know about this, but I have been reluctant to take a closer look, because it is really complicated and quite confusing. As long as the application works without crashes, I am tending to think, that it matters less with the variables writeouts. But indeed, I need to take a look on this somewhere along the line.
At least will be good to have no garbage in variable, or maybe dunno, somehting like "unimplemented" words ?:) I just fear while there garbage, it mean trashing of memory.
There is another set of small issues :
First one:
-- run spotless -- hit rmb, choiise "Swith to public screen". -- hit iconify gadget. It will iconify to the WB screen -- swith by any way to workbenh screen (drag the spotless screen down, or hit gadget on spotless screen to back to the wb one) -- hit on spotless window => crash.
Crash in Widget.cpp:165
I think that crash i have once on exit was related to that public-screen functionality as well. Maybe that just one single issue.
Second one (an easy one imho):
-- when you iconify, the icon on the wb not of spotless, but default one. If i remember right it's about just additional option provide when do iconify.
Third one (more as cosmetical, but still):
-- when we tried to load Spotless binary inside of the Spotless, then progress bar going on fast (but while it happens, mouse is sluggish, 100% cpu loading). Then, everthing just stops/halts, and only after a few seconds (3-4) it refreshes and things show ups in Spotless. Imho if we can't speed things up for now there, will be worth to show progress bar finished only when evertyhing visibly on screen. Or, at least after progress bar finished, shoup a "busy mouse cursor" so we know it not freeze (but at this point, you can't move anything, it just like freeze, strange..).
Then after all loads, i hit the start and spotless didn't starts inside of spotles. Tried few times. When exit from main spotless, intuition seems to be messed up and trashed (so reboot need it).
At least will be good to have no garbage in variable, or maybe dunno, somehting like "unimplemented" words ?:) I just fear while there garbage, it mean trashing of memory.
I will take a look at it at some point.
Quote:
First one:
-- run spotless -- hit rmb, choiise "Swith to public screen". -- hit iconify gadget. It will iconify to the WB screen -- swith by any way to workbenh screen (drag the spotless screen down, or hit gadget on spotless screen to back to the wb one) -- hit on spotless window => crash.
Crash in Widget.cpp:165
I think that crash i have once on exit was related to that public-screen functionality as well. Maybe that just one single issue.
I think, I caught this one. Please test again, when I post the next release.
Quote:
-- when you iconify, the icon on the wb not of spotless, but default one. If i remember right it's about just additional option provide when do iconify.
I am only going to do this, when I have loots of time. I think, we will survive :).
Quote:
-- when we tried to load Spotless binary inside of the Spotless, then progress bar going on fast (but while it happens, mouse is sluggish, 100% cpu loading). Then, everthing just stops/halts, and only after a few seconds (3-4) it refreshes and things show ups in Spotless. Imho if we can't speed things up for now there, will be worth to show progress bar finished only when evertyhing visibly on screen. Or, at least after progress bar finished, shoup a "busy mouse cursor" so we know it not freeze (but at this point, you can't move anything, it just like freeze, strange..).
Then after all loads, i hit the start and spotless didn't starts inside of spotles. Tried few times. When exit from main spotless, intuition seems to be messed up and trashed (so reboot need it).
I can load and run Spotless inside itself just fine. I am not sure, if I changed anything, so if you could retest at the next release?
Quote:
Through i have one suggestion for : rename "configure" item to something like "add additional source directories" or something of that sort, so GUI will be self-explained.
This is a conscious choice. I want to keep the window with that name for enabling more configuration options. I don't want each option in their own window. For now, you can read the caption "Source roots:" in the bevel box title inside the window.
Quote:
Another suggestion for GUI, is to open "memory surfer" a bit bigger. Now it just as small as possible, but imho worth to open it by default so to be as big as it needs to fit whole horizontal information. Or do it like in some of our projects : gadge on bottom right together with iconify, where we can choose snapshot/unspanshot .. But maybe that will for now overcomplicate the things, and maybe just open it a little bit bigger will be fine for now.
This is actually difficult to do. Because I am keeping the ReAction classes as "slim" as possible, there are no real options to save positions and select placement/size. The question is, how much you yearn for this, because it is of course possible, but would add a lot of code with possible clutter and added maintenance.
Quote:
-- when you switch public screen (so to have spotless on it's own screen), and load a some test in it, then it it runs on workbench screen, and not on the Spotless one. I.e. if we have in test case printf("aaaaa\n"); then when we on the spotless screen, this "aaaa" window opens on the workbench screen. While, imho, should be on spotless screen (as this is the default screen now, when we swith to it).
This is also a "minimalist" issue. I simply don't code for anyting, and showing the console window on Workbench is default behavior. In fact I don't know at all how I could possibly move the default console to another public screen! Suggestions??
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
