BLADE - difference in debug "single step" and "step into"?
I'm trying to map my traditional debug keystrokes from the acad VLIDE to BLADE.
F8 was "do one function"
shift-F8 is do entire statement, from start ( to end )
those two are about all I care about besides F9 which is the same in VLIDE and BLADE already (set breakpoint).
What I cannot figure out is if in BLADE, "single statement" is different from "step into".
They seem to do the exact same thing, and one should get the F8.
The other, I will simply ignore.
The step out gets the shift-F8, that is clear.
Can anyone clarify before I bug Torsten on this?
thx
Comments
-
Dear James,
I'm trying to explain the difference between "single step" and "step into" :-)
"single step" is what it literally means - 1 atomic evaluation at one time ... there is never a "step into" operation triggered, it is always "eval the actual statement as one", regardless whether that is atomid "1+" or "(MyFuntion 1 2 3)" ..."Step Into" means, that it is attempted/tried to go "into" the function - if that is a user-defun; somewhat naturally, there is no way to "step into" into a native Lisp core function like "(1+ ...)" - but it will work for "(MyFunc 1 2 3)", under the condition, that "MyFunc" function was also loaded under debug context (if that function was loaded before debug session started, then it is handled like a native function - it is present for evaluator, but not for debugger (as loaded outside debugger).
In fact, harder to describe, than to try :-)
If you try "single step" and "step into" on your own "(MyFunc 1 2 3)", you will see the different behaviour ...
I know, that VLIDE (mis)interpetes "single step" vs. "step into", in a somewhat unlogical way ... I think, BLADE's logic is at least somewhat more consistent, and essentially what the name says : single step vs. step into.One excepton from that rule : if there is a breakpoint inside "(MyFunc ...)" function scope, the "single step" over "(MyFunc ...)" will in fact stop at the break point, as the break point has priority.
So you might assign different hotkeys to "single step" and "step into", and try with native "(1+ ...)" and with custom "(MyFunc ...)" functions;
means, BLADE will give you exactl ythe behaviour as intended (once the difference to VLIDE's strange logic is clear).I hope, I did not destroy the last clear things ? :-)
many greetings !0 -
Hi Torsten,
You have yet to butcher an explanation, I'm not sure you know how
That makes sense, as I must have tested on simple functions so it looked the same.
I think in the end, I want Step Into as F8 since that covers both needs.
On simple functions, it just does the function. On nested functions, it goes in one step at a time.
For the case where I want the entire (myfunc 1 2 3) run, I just use Step over.One interesting thing I just noticed that really confused me:
One the line where you set a breakpoint, like at beginning of:
(SETQ SCREENWIDTH (* (/ (CAR (GETVAR "SCREENSIZE"))(CADR (GETVAR "SCREENSIZE")))(GETVAR "VIEWSIZE")))
If you hit Step over, to evaluate the whole line, it actually steps into.
After that line, step over works fine, just line with breakpoint misbehaves.
You might look at that as I doubt its intended.Anyway, I am off and lisping!
0 -
Dear James,
I think I can (at least) explain :-)
The breakpoint is in fact assigned to the LINE NUMBER, not to the first statement at that line in code ... so that breakpoint is hit multiple times for each (sub-)statement in that line, as code execution continues ... kind of known issue :-(
But I promise to improve that, to only stop once, at first occurence, ignoring multiple subsequent hits at same file + same line, if the actual statement is at different position (column) ....
this details sometimes annoys me as well, so good chances to get this improved in reasonable time :-)thanks for feedback & many greetings !
0 -
Oh, so if I was in a loop, the "automatic" step into behavior would happen.
That's easy to work around.
I think the bigger thing on my list of practical issues now is I generally have two fas projects open in VLIDE.
I use the "load files for project" button a lot.
In BLADE, its only one project allowed, and you have to load all files to get them, including other, non project files you have open.
Sometimes I have three projects open in vlide, as I have one for autocad startup, one for my civil tools, and one for free version of my civil tools.
Something for the future maybe.
At the moment though, I wish there was a "load all files for just the project open" option.
thx0 -
Dear James,
At the moment though, I wish there was a "load all files for just the project open" option.
when you right-click on the "project root" item,, there is "Load all Lisp files in BricsCAD" ... when under Debug, all those are then automatically "debug-enabled" (except DES files, naturally);
I think that is what you are asking for ?Besides, BLADE debugger recognises if some Lisp code was not yet loaded (under Debug), and offers to load the appropriate Lisp file, if a function from that file shall be executed ... this allows to start with just 1 main Lisp file, and "dynamically" load-on-demand, whatever is needed;
at least, useful, if not 50...100 files are to be demand-loaded, but just a few ... :-)many greetings !
0 -
Hi Torsten,
I just realized that the "load all files" option on right click behaves different depending where you pick, very good!
So the thing I asked for is already there.
The weird thing is, I used to get a dialog when I did "load all lisp files..." but now I don't.
I just installed the latest build V20 last week so maybe the old build had one.At this point though there are two things really hampering my BLADE use:
1) autobreak on by default - I am happy to just uncheck it every time, but when you click the blue "start debug session" button, it seems to be loading the current file. Any "raw" statements not wrapped in a defun, will execute and it stops on them.
That jumps me to a line of code way away from where I started so is frustrating.
for instance, I have these kinds of lines:
(vl-arx-import 'acad_colordlg)
and starting a debug session stops on that line (as it should of autobreak is on), but that is not desired.
Really, starting a debug session should not load the current file, especially if I am in the middle of code tweaks where that file has errors.
I don't mind it loading that much, but the combination of it loading, and autobreak jumping me to outer space, is not great.
It also does not make sense as the sequence is always "start debug", then "load code to debug session". Curious of the logic there.2) Loading all 125 lisps in my project takes a long time, if doing so under debug. I thought if I was not in a debug session they loaded fast.
I can't get that to work now. It always loads slow. I could swear it loaded fast last week until I started debug. I am just starting fresh session and picking "load all lisps..." for the fas project.
Am I missing some way to load all lisps fast?
The way you have it, given the load speed, seems perfect - load all fast until one is needed, then the option to "debug" load. but its doing debug load always now...
thanks0 -
Dear James,
thanks for feedback, as always ...
Before latest V20, there was no automatism between starting a debug session and loading the actual file ... lot of developers stumbled here (as it is not obvious to load the Lisp file after starting the debugt session;
therefore, I now combined that - starting the debug session now loads the actual file (and any other required Lisp file can be loaded later).For the AutoBreak option :
there are 2 places to access that
a) the "Debug" toolbar
b) and now also in the "Debug" menu ... so you might dusable/uncheck that option via menuIn generally, that AutoBreak is a really important feature - not only for those "raw" statements outside a DEFUN block, but also as it allows to "jump" into Lisp code, when it is not clear where & when Lisp code starts (by user etc.) - then, stopping at first processed Lisp statement can e a powerful assistance.
Loading all 125 lisps in my project takes a long time, if doing so under debug
Yes, loading under "Debug" is significantly slower, by nature, as it needs to create "connections" between editor and Lisp core ...
but the idea of "demand-loading Lisp" under Debug is a smart approach ...I will try to explain :
assume, you have 10 Lisp files where you potentially want to debug into - but particular code flow is not known upfront
=> then, just load 1 Lisp file, where the entry point is ....
=> then start debugging ....Now, a call "(MyFunc1...)" is about to be processed, which was not-yet-loaded - Debugger will recognise this, and ask you to load the associated Lisp file (it will suggest an appropriate file, if known; but that can be rejected, and you can then select a different file, regardless whether in a project or editor) ...
such way, you will only load those Lisp files, effectively needed for a particular debug session / code flow ...
in other words, no need to load all your 125 Lisp files upfront, under Debug condition ...I hope this explains & helps a bit ?
many greetings !0 -
Thanks for fast reply
For the autobreak, I will just turn off from menu before starting debug session, no problem.
I guess it would be nice if BLADE remembered the state of that.
The users that get confused by the "must load after debug" must not have used the VLIDE, as it also requires you reload a lisp after setting a break point. Still, I do have to focus on the order of things in the BLADE, like setting the break point one line back from the spot I want to start so step over works on that line.The strategy you have for loading one file as debug, and letting it offer to load others needed as functions are called, is perfect.
The problem is much of the time I am not running under debug. I simply open BLADE, want to load say 10 files needed for my program, and do a test run. Then, if it errors, I might want to debug. To complicate things, my startup loads the compiled .des version of the program so I need the .lsp's loaded so functions do not get called from the .des which may be old.
There does not seem to be a way to load the lisps as "non-debug".
I guess in that case I will use another lisp to load the project files, which I do have for a few reasons, but I thought BLADE could load both ways.0 -
Dear James,
yes, I think I understand :-) In fact, we had long discussions with Martin Drese (beta testing), how to best get the loading vs. debugging topic solved ...
so far, no perfect solution, as too many different scenarios to be respected :-(There does not seem to be a way to load the lisps as "non-debug".
There is - you can load those files upfront, outside "debug session", by all available methods (Drag & Drop, from menus + context menus, assigned hotkeys) ...
And with latest V20, there is another (minor but important) improvement - in case, that some Lisp code uses (load "name") or (load "name.des") to normally load the existing .des file - then, when actively debugging, the Lisp (load) function will actively check whether the same-named .lsp file is in same place/folder ... and if so, that .lsp file loaded then instead, to allow debugging such .des code ...
but only, if an active debug session is present, otherwise no change.I think, this can help a bit ... just have both .lsp and .des in same folder (at least, if there is a 1:1 relation between lsp and des file).
many greetings !0 -
Thanks Torsten,
I know what you mean. My use of BLADE on one large projects and then multiple little ones at same time is way less common.
Also, you have those that live and die by acad's VLIDE, then those that have never opened an IDE (poor things...ha ha).
I plan to start a youtube channel on VLIDE and BLADE use, and that may show the different flows better so people have a reference of how someone like me uses them.
Its funny because people think its poor etiquette to mention a competing product in a forum like this, but really what Bricsys is fighting against to gain bacd use, is knowing autocad better. The customers that know acad, have a much easier time using bcad, since its the same thing for what they care about. Its the ones that are set up "by some previous guy" on autocad that can't switch to the more competitive product.0
