Mon 18 Apr 2016 01:45:48 AM UTC, comment #17:
I tested the patch and it works for me as well. I pushed it here http://hg.savannah.gnu.org/hgweb/octave/rev/37a44d8af461. Closing report.
|
Sun 10 Apr 2016 01:06:37 AM UTC, comment #16:
Just to confirm that it works for me as expected after applying that patch.
|
Sun 10 Apr 2016 12:25:50 AM UTC, comment #15:
Thanks, Markus. That sounds like the behaviour we want, doesn't it?
I've attached a final patch (v3), without the diagnostic output, and with a commit message. It is now ready for a maintainer to review.
(file #36882)
|
Sat 09 Apr 2016 08:15:26 PM UTC, comment #14:
With your patch v2, I get the following result in Octave for Windows:
The forward slash is correctly converted to a backslash, the function file opens in the editor of the GUI and the stop point is set to the first line of the function. This works for both forward and backslash.
|
Fri 08 Apr 2016 11:16:13 PM UTC, comment #13:
Markus, I think your comment #11 was right. (I had forgotten to save the .cc file before exporting the patch...)
Did you actually try inverting the translation? If so, was it like v2 of the patch (attached)?
(file #36870)
|
Fri 08 Apr 2016 08:41:01 PM UTC, comment #12:
Please ignore the last comment. Nothing has to be inverted...
|
Fri 08 Apr 2016 07:51:09 PM UTC, comment #11:
I think the replacement of the filesep should be inverted in your patch. Building with this change at the moment.
|
Fri 08 Apr 2016 05:31:48 PM UTC, comment #10:
@Lachlan:
I have checked you patch on Win-7,
now both
are NOT working :-(
|
Fri 08 Apr 2016 05:53:04 AM UTC, comment #9:
Thanks Markus. Can you also try the attached patch?
It explicitly converts @.../... to @...\... on Windows for dbstop and related commands.
If it works, someone will have to decide whether that should be done explicitly for the dbstop family, or whether symbol_table::find_function () should do it automatically. I'm not sure what sort of performance hit there would be for that. It has to do a linear scan of the string, but I don't think that find_function is called on regular function calls -- just during parsing and when "referring" to a function, as dbstop does.
(file #36861)
|
Thu 07 Apr 2016 08:58:18 AM UTC, comment #8:
On an Octave mxe-build from mid march, I see the following:
|
Thu 07 Apr 2016 08:30:24 AM UTC, comment #7:
I checked with Octave 4.0.1 on Windows 7:
"which" does not seem to have a problem with "/" on Windows.
|
Thu 07 Apr 2016 07:17:51 AM UTC, comment #6:
What does Windows do for
Also, note that you are using an out-of-date build. The warning is now "add_breakpoint: unable to find function '<name>'".
|
Thu 31 Mar 2016 04:07:16 PM UTC, comment #5:
Just tested this with Matlab on Windows: it accepts both forward slash '/' and back slash '\' in arguments for dbstop.
|
Thu 31 Mar 2016 03:18:33 PM UTC, comment #4:
I think we need to know what the Matlab behavior is in this regard in order to fix it. It may be that Matlab accepts either '/' or '\' in which case the fix should be in the C++ code. Or it may be that Matlab really wants a file path which means '@class\method.m' for Windows and '@aclass/method.m' for Linux. If this is the case then we just need to alter the BIST test to have an ispc() clause to decide which filesep to use.
|
Thu 31 Mar 2016 10:26:09 AM UTC, comment #3:
@Rik (comment #1)
This test was added in http://hg.savannah.gnu.org/hgweb/octave/rev/b248c28d9a7b.
I did not check it, but brobably failed always in Windows.
|
Wed 30 Mar 2016 08:55:45 PM UTC, comment #2:
Second question: Does Matlab allow the '/' as a separator for "@class/method.m". Or does it too want "@class\method.m" on Windows?
|
Wed 30 Mar 2016 08:51:08 PM UTC, comment #1:
Sure looks like a path separator problem. Did this use to work, i.e., this is a regression, or has it always failed?
|
Wed 30 Mar 2016 06:44:04 PM UTC, original submission:
Checking in MXE-Octave under Win-7
This error causes failure in test libinterp\corefcn\debug.cc-tst
note:
works fine
|