Mon 16 May 2016 05:46:50 AM UTC, comment #20:
I changed the already_existed variable name to delete_fcn since it seemed clearer. I checked in the changeset here http://hg.savannah.gnu.org/hgweb/octave/rev/4c080cbc4ef9.
The issue with having to type dbcont twice is because the isdir script is called when print_usage() is invoked. See the transcript below where I set a breakpoint in isdir ("dbstop isdir") before proceeding with another breakpoint and dbcont.
Closing report.
|
Tue 03 May 2016 01:14:35 PM UTC, comment #19:
What I saw is that upon typing "dbcont" the "instruction pointer" jumps back from the print_usage line in the if block to the preceding if condition itself.
As if isdir.m is called by print_usage() ... ?
|
Tue 03 May 2016 12:28:52 PM UTC, comment #18:
Thanks for checking, Philip.
I think everything between the keyboard and chair is in perfect working order. I've sometimes noticed that dbcont has to be issued twice in cases not involving "run" at all. It's probably worth looking into -- I've just ignored it until now.
|
Tue 03 May 2016 12:22:58 PM UTC, comment #17:
Finally tried the patch, sorry for the delay.
In the sequence of comment #6, "run isdir" is now interrupted properly.
What I do not understand is why I have to type "dbcont" twice to get to the end of the function, but that also happens with just "isdir". Maybe be between keyboard and chair I guess.
|
Thu 28 Apr 2016 08:47:36 PM UTC, comment #16:
Lachlan,
I forgot to cc myself (now done) so forgot all about this bug, sorry for that. Happens with more bugs I try, I should be more careful in that respect.
Somewhere in the next days I'll try the new patch.
|
Fri 15 Apr 2016 01:35:56 PM UTC, comment #15:
It's getting late. This time for sure...
(file #36939)
|
Fri 15 Apr 2016 01:34:22 PM UTC, comment #14:
Oops, this is the file I meant...
(file #36938)
|
Fri 15 Apr 2016 12:57:49 PM UTC, comment #13:
The attached patch should now work for functions as well as scripts. Instead of testing for "is_user_script", it checks for "is_user_code", which is true for either scripts or functions.
I've also updated the documentation for source().
When you get time, let me know how it goes.
(file #36937)
|
Fri 15 Apr 2016 11:37:55 AM UTC, comment #12:
Philip, the file foo.m defines a function "foo". It is not a script. When you source the file, it places the function "foo" in the symbol table, rather than executing it. That is why it doesn't print "Hello!", and why it is a command line function after running the file.
The bug in my code is that I call "find" to see if the symbol is already in the symbol table, but I didn't realise that "find" actually loads the symbol. Thus, after the find(), "foo" already points to the function and is not considered a "script".
I'll have to find a way to query the symbol table without loading a symbol.
|
Tue 12 Apr 2016 07:12:14 PM UTC, comment #11:
You mean what I saw in comment #2 of bug # 47585?
That still behaves the same.
Intriguing, and only noting now, is that I didn't see "Hello!" printed to the screen invoking "run foo", with or without breakpoint.
What I also see is that after "run foo" "dbclear foo" does nothing.
After closing foo.m editor tab and reopening foo.m in the editor, the breakpoint is cleared and there's no way to put it back.....
as if foo.m disappeared out of some memory slot.
Oh I accidentally hit a clue:
... so it morphed into a command line function instead of a .m function on disk, apparently after the command "run foo".
|
Thu 07 Apr 2016 07:35:55 AM UTC, comment #10:
I've just noticed that I forgot to upload the revised patch.
Philip, can you see if this fixes the problems you saw at bug #47585?
(file #36851)
|
Mon 08 Feb 2016 05:06:55 AM UTC, comment #9:
(Oops, I just noticed it was Philip who kindly tested the patch. Sorry for calling you Rik.)
I've reassigned this from Jordi to me.
|
Sun 31 Jan 2016 06:42:10 AM UTC, comment #8:
Rik, it turns out that the reason run isdir didn't return anything is that run does nothing if its argument is a function not a script.
I've extended the patch to throw an error if the argument to source (used by run) exists but is not a script. It still silently returns if the file doesn't exist, so that we don't get an error about ./.octaverc not existing.
The existing code also has a memory leak where the parse tree of the newly parsed file is not deleted if it is not a script. The patch fixes that too.
(My previous post was also too rushed; I thought that the error messages were for the run case, not for calling isdir directlly.)
|
Sat 30 Jan 2016 11:20:47 PM UTC, comment #7:
Thanks for the prompt reply, Rik.
You understand perfectly. I just checked that it stops, but didn't check that it continues :( One day I'll stop rushing...
I'll look into it and get back to you.
|
Sat 30 Jan 2016 10:34:28 PM UTC, comment #6:
Lachlan, after applying your patch to 4.1.0+:
I may not understand fully, but isn't the breakpoint supposed to be hit when doing "run isdir", similarly to just "isdir" ?
|
Sat 30 Jan 2016 11:38:17 AM UTC, comment #5:
The attached changeset fixes this bug.
The remaining idiosyncrasy is that if filename.m has a breakpoint, and we "run /other/path/ending/filename.m" then the breakpoint is cleared.
I look forward to this five year old bug being closed.
(file #36208)
|
Tue 25 Jun 2013 04:13:22 PM UTC, comment #4:
The problem is still open, so the bug should remain open. I won't be working on this, though.
|
Sat 22 Jun 2013 02:15:55 AM UTC, comment #3:
Jordi, do you want to continue with this bug report? Or can it be closed?
|
Mon 30 May 2011 07:17:06 AM UTC, comment #2:
Btw, asking around, I think Matlab behaves differently here. Doing "run" on a function file executes the function defined there, but apparently it's impossible to pass it parameters with this syntax. Since Octave allows defining functions in a script file unlike Matlab, perhaps this different behaviour should persist? In which case your suggestions would apply.
|
Fri 27 May 2011 05:21:47 AM UTC, comment #1:
Just to clarify, the run function doesn't run other functions. It can only run other scripts since it sources the named file. If you source a function file, you will just define the function, not execute it. So I assume that your file foo.m is a script file. Is that correct?
Also, if you plan to work on this, you might want to look at the functions load_out_of_date_fcn and out_of_date_check in symtab.cc. Those functions do something similar to what we probably want, except that they start with an octave_function object (which can be a script) and we only have the name of a script file.
What we may want to do is find out if there is already a script loaded in the symbol table from the same file that we are being asked to run, then check to see whether the already parsed script is out of date. If it is, we need to parse the file again. If not, then we should skip the parse step and execute the octave_user_script object that we found in the symbol table.
I suppose all of that could go inside the source function itself, then both run and source will be fixed. Unless you think that the source function should not bother with this optimization and should always parse the file. But if that is the case, then I don't see why the run function should behave any differently.
|
Thu 26 May 2011 08:41:53 PM UTC, original submission:
If you set a breakpoint with
but use the run command instead of just using the function's name
Then the breakpoint isn't hit. See this discussion: http://octave.1599824.n4.nabble.com/dbstop-doesn-t-break-with-run-script-td3551242.html
|