[Matlab-emacs-discuss] Fwd: Missing execution line pointer after upgrading Matlab

[Odd A. <odd...@gm...>]

In case anybody is interested, here is the "patch" I wrote that enables the
debugger to update the instruction line pointer with newer versions of
Matlab.
The m-file should go in the toolbox directory, the other file describes the
changes I made to matlab.el.

Odd A.

On Fri, Jan 29, 2016 at 11:29 PM, Eric Ludlam <Eri...@ma...>
wrote:

> Hi,
>
>
>
> That looks like a great idea for a simple fix.   You might be able to
> shadow “dbstep” in the Matlab-emacs toolbox directory, and have it call
>
>
>
> builtin(‘dbstep’,...)
>
>
>
> to dispatch, then fprintf items out.
>
>
>
> I’m not sure why it wouldn’t remove the hotlink text.   That will need
> some time in the Emacs debugger around matlab-shell-render-anchor to know.
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Friday, January 29, 2016 12:10 PM
> *To:* mat...@li...
> *Subject:* Re: [Matlab-emacs-discuss] Missing execution line pointer
> after upgrading Matlab
>
>
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
> [image: Image removed by sender.]
>
>
>
> On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...>
> wrote:
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
>
>
> On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...>
> wrote:
>
> Hi,
>
>
>
> I have looked into this, and in Earlier MATLABs I used to take advantage
> of a “bug”, which I thought was a feature, that allowed MATLAB to send me
> html like anchors which I could interpret.  MATLAB is now correctly
> identifying that it is not pointing at a device that supports anchors
> (since it is a plain pty), so I don’t have the data.
>
>
>
> I asked a couple folks about this and I don’t believe there is a trick I
> can pull to get this data to be output to Emacs with the newer MATLABs,
> which leaves things kind of broken.
>
>
>
> Before the links, I used to interpret the plaintext, but this was buggy,
> and simple output tweaks from MATLAB, or locale changes would mess it up,
> so it doesn’t seem too good either, but could be resurrected.  I don’t
> really have the bandwidth for that kind of refactoring project though. L
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Wednesday, January 27, 2016 8:21 AM
> *To:* mat...@li...
> *Subject:* [Matlab-emacs-discuss] Missing execution line pointer after
> upgrading Matlab
>
>
>
>
>
> Hi,
>
> After I upgraded my Matlab version from R2014a to R2015b, I can no longer
> see the little arrow that indicates the current execution line while
> debugging matlab code using matlab-emacs.  Moreover, debugging seems to
> work poorly in other ways: it apparently no longer brings up the relevant
> code buffer while debugging (possibly tied to the problem above), and when
> arriving at a multi-line function call (i.e. where each line of text is
> continued with '...'), it no longer treats this as one line but insists on
> stepping over each text line separately.
>
> I saw someone else (Tunc Aydin) mentioned the missing execution line
> pointer on this mailing list last fall, and was answered by Eric Ludlam
> that apparently the "output Emacs was interpreting for the debugger has
> changed" and that this .  (
> http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
>
> Has anyone looked into this since then?  matlab-emacs has worked wonders
> for me in the past, and it's very sad if it stops providing a practical
> debugging tool  as people upgrade to newer versions of Matlab.
>
> Best,
>
> Odd Andersen
>
>
>
>
>