You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(3) |
2010 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(13) |
May
(2) |
Jun
(4) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
(4) |
2011 |
Jan
(11) |
Feb
|
Mar
(18) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(10) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
(10) |
2012 |
Jan
(4) |
Feb
(26) |
Mar
|
Apr
(1) |
May
|
Jun
(8) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(1) |
Dec
(2) |
2013 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(7) |
2014 |
Jan
(14) |
Feb
|
Mar
(6) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(7) |
Oct
(9) |
Nov
(9) |
Dec
(5) |
2015 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
(4) |
Sep
(8) |
Oct
(1) |
Nov
(3) |
Dec
(3) |
2016 |
Jan
(12) |
Feb
(59) |
Mar
(23) |
Apr
(11) |
May
(4) |
Jun
(15) |
Jul
|
Aug
|
Sep
(9) |
Oct
(19) |
Nov
(12) |
Dec
(5) |
2017 |
Jan
(1) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(12) |
Nov
(15) |
Dec
|
2018 |
Jan
(7) |
Feb
(6) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
2019 |
Jan
(2) |
Feb
(9) |
Mar
(4) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(5) |
2020 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(28) |
Dec
(5) |
2021 |
Jan
(11) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(15) |
Jun
(9) |
Jul
(11) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
(9) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(4) |
Jun
|
Jul
(22) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(14) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
(35) |
Jun
(1) |
Jul
(18) |
Aug
(31) |
Sep
(5) |
Oct
(18) |
Nov
(20) |
Dec
(9) |
2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Cumhur E. <cum...@gm...> - 2017-10-25 03:40:18
|
Hi, Assuming that matlab-mode and matlab-shell are working, org-babel natively supports matlab code execution. Your org-babel-execute:matlab overrides the org-babel defaults in ob-octave.el, which can be inspected there. I enable the babel support in .emacs as (org-babel-do-load-languages 'org-babel-load-languages '( (latex . t) (plantuml . t) (java . t) (matlab . t) (C . t) (csharp . t) (table . t) ) ) after this, C-c C-c will execute the code, but the next snippet in .emacs makes the sessions continuous, and simplifies the arguments given each time (setq org-babel-default-header-args:matlab '((:session . "*MATLAB*") (:results . "silent") ) ) More an org answer than matlab.el, but I hope these help. Cumhur Erkut > On Oct 24, 2017, at 22:53, Uwe Brauer <ou...@ma...> wrote: > > Hi > > I am using more and more org mode, a long with auctex and matlab.el. > Orgmode comes in handy if I write a document which contains (matlab) > code which I want to execute, but the rest of the file maybe text, which > I can then export to latex. > > So a typical file looks like > > Given > \droppoints > \begin{displaymath} > \begin{cases} > \frac{du}{dt}&= -t u^2,\\ > u(0)&=1, > \end{cases} > \end{displaymath} > > Solve using ... > > > #+BEGIN_solution > #+begin_src matlab :results output latex :exports results :eval never-export > f=@(t,y)[-t*y^2]; > [t,y]=mieuler(f,[0 1],1,2); > disp('\begin{align*}') > fprintf('t = [%g \\qquad %g \\quad %g] \\\\\n', t) > fprintf('y = [%g \\qquad %g \\qquad %g] \n', y) > disp('\end{align*}') > #+end_src > > Now I can execute the matlab code in that org file using > > C-c C-c ( org-ctrl-c-ctrl-c, the *one-ring-to-rule-them-all* function in > orgmode. > > Thanks thanks to a function provided to me by John Kitchin it executes > matlab. > > It is as follows: > > (defun org-babel-execute:matlab (body params) > (interactive "P") > (let* ((current-file (buffer-file-name)) > (code (org-element-property :value (org-element-context))) > (result-params (cdr (assoc :result-params params))) > m-file > md5-hash) > (with-temp-buffer > (insert code) > (setq md5-hash (md5 (buffer-string)) > mbuffer (format "*m-%s*" md5-hash) > m-file (format "m-%s.m" md5-hash))) > ;; create the file to run > (with-temp-file m-file > (insert code)) > (let ((results (shell-command-to-string > (concat > "/usr/local/bin/matlab " > "-nodesktop -nojvm -nosplash -nodisplay <" > m-file)))) > (delete-file m-file) > (when results > ;; strip out >> > (setq results (replace-regexp-in-string ">> " "" results)) > ;; remove first 10 lines that are the header. > ;; matlab license seem to expire soon, so 5 warning lines are added > ;; change first 10 to first 15 lines > (setq results (mapconcat 'identity > (nthcdr 10 (split-string results "\n")) > "\n"))) > (org-babel-result-cond result-params > results)))) > > The problem of that code is that it starts matlab every time I execute > C-c C-c . There seems to be a python based kernel around which avoids > this, but I thought that maybe with a bit of hacking one could use the > elisp based matlab-shell and the corresponding functions. > > Anybody has an idea, Eric? > Needless to say that I played a bit around but did get it to work.... > > Regards > > Uwe Brauer > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Uwe B. <ou...@ma...> - 2017-10-24 21:20:12
|
Hi I am using more and more org mode, a long with auctex and matlab.el. Orgmode comes in handy if I write a document which contains (matlab) code which I want to execute, but the rest of the file maybe text, which I can then export to latex. So a typical file looks like Given \droppoints \begin{displaymath} \begin{cases} \frac{du}{dt}&= -t u^2,\\ u(0)&=1, \end{cases} \end{displaymath} Solve using ... #+BEGIN_solution #+begin_src matlab :results output latex :exports results :eval never-export f=@(t,y)[-t*y^2]; [t,y]=mieuler(f,[0 1],1,2); disp('\begin{align*}') fprintf('t = [%g \\qquad %g \\quad %g] \\\\\n', t) fprintf('y = [%g \\qquad %g \\qquad %g] \n', y) disp('\end{align*}') #+end_src Now I can execute the matlab code in that org file using C-c C-c ( org-ctrl-c-ctrl-c, the *one-ring-to-rule-them-all* function in orgmode. Thanks thanks to a function provided to me by John Kitchin it executes matlab. It is as follows: (defun org-babel-execute:matlab (body params) (interactive "P") (let* ((current-file (buffer-file-name)) (code (org-element-property :value (org-element-context))) (result-params (cdr (assoc :result-params params))) m-file md5-hash) (with-temp-buffer (insert code) (setq md5-hash (md5 (buffer-string)) mbuffer (format "*m-%s*" md5-hash) m-file (format "m-%s.m" md5-hash))) ;; create the file to run (with-temp-file m-file (insert code)) (let ((results (shell-command-to-string (concat "/usr/local/bin/matlab " "-nodesktop -nojvm -nosplash -nodisplay <" m-file)))) (delete-file m-file) (when results ;; strip out >> (setq results (replace-regexp-in-string ">> " "" results)) ;; remove first 10 lines that are the header. ;; matlab license seem to expire soon, so 5 warning lines are added ;; change first 10 to first 15 lines (setq results (mapconcat 'identity (nthcdr 10 (split-string results "\n")) "\n"))) (org-babel-result-cond result-params results)))) The problem of that code is that it starts matlab every time I execute C-c C-c . There seems to be a python based kernel around which avoids this, but I thought that maybe with a bit of hacking one could use the elisp based matlab-shell and the corresponding functions. Anybody has an idea, Eric? Needless to say that I played a bit around but did get it to work.... Regards Uwe Brauer |
From: nchodosh <nch...@an...> - 2017-10-17 15:44:27
|
Hi, Sorry about the delay, I had a busy few weeks. Here's the diff for matlab.el, I also included one for company-matlab-shell.el which enables predictions while editing the middle of a line. Best, Nate On Tue, Oct 3, 2017 at 3:24 PM Eric Ludlam <Eri...@ma...> wrote: > Ah, this is a good reminder I need to poke the source forge site to point > at the new github location that Uwe is using. > > > > Start with the mailing list. I’m not sure what process would work best > for Uwe. > > > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > > *Sent:* Tuesday, October 03, 2017 1:18 PM > > > *To:* Eric Ludlam <Eri...@ma...>; > mat...@li... > *Subject:* Re: [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > Great. I've never contributed to a sourceforge project, should I post the > diff under patches? > > > > On Tue, Oct 3, 2017 at 12:59 PM Eric Ludlam <Eri...@ma...> > wrote: > > Sounds reasonable to me. > > > > When you are happy with your changes, post a diff and hopefully Uwe can > install it. > > > > Thanks > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > > *Sent:* Tuesday, October 03, 2017 12:26 PM > *To:* Eric Ludlam <Eri...@ma...>; > mat...@li... > *Subject:* Re: [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > That's what I thought the purpose of the newline is, but the documentation > for comint-simple-send states that it automatically appends a newline to > the command, so it's not needed. > > As an aside I think that in the current version of emacs the while loop in > the same function needs to be wrapped in a with-local-quit to avoid raising > an error (or at least the accept-process-output call does). > > Best, > > Nate > > > > On Mon, Oct 2, 2017 at 4:14 PM Eric Ludlam <Eri...@ma...> > wrote: > > I wrote that a long time ago, but my vague recollection is that the > newline was needed to make the subprocess execute the command. Is it > adding a 2nd newline to the end of ‘command’ resulting in the spare line? > > > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > *Sent:* Monday, October 02, 2017 1:27 PM > *To:* mat...@li... > *Subject:* [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > Hello, > > I've noticed that calling 'matlab-shell-collect-command-output' can result > in extra new lines being sent to the *MATLAB* buffer which aren't deleted. > When using company-mode to complete text this behavior is pretty annoying > since as I'm typing lines are being inserted above the prompt. I believe > that the cause of this is the line: > (comint-simple-send (get-buffer-process (current-buffer)) > > (concat command "\n")) > > The newline added to the end of the command causes an extra line to be > printed since it's interpreted as execute 'command' and then send a > newline. Removing the newline fixes the problem. > > This seems like a suspiciously simple fix so I'm wondering why the newline > was being appended to the command. > > Thanks, > > Nate > > P.S I am new to using mailing lists so if I've committed any faux pas in > this email please let me know > > |
From: Eric L. <Eri...@ma...> - 2017-10-03 19:24:26
|
Ah, this is a good reminder I need to poke the source forge site to point at the new github location that Uwe is using. Start with the mailing list. I’m not sure what process would work best for Uwe. Eric From: Nathaniel Chodosh [mailto:nch...@an...] Sent: Tuesday, October 03, 2017 1:18 PM To: Eric Ludlam <Eri...@ma...>; mat...@li... Subject: Re: [Matlab-emacs-discuss] Removing extra lines from collect-command-output Great. I've never contributed to a sourceforge project, should I post the diff under patches? On Tue, Oct 3, 2017 at 12:59 PM Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>> wrote: Sounds reasonable to me. When you are happy with your changes, post a diff and hopefully Uwe can install it. Thanks Eric From: Nathaniel Chodosh [mailto:nch...@an...<mailto:nch...@an...>] Sent: Tuesday, October 03, 2017 12:26 PM To: Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>>; mat...@li...<mailto:mat...@li...> Subject: Re: [Matlab-emacs-discuss] Removing extra lines from collect-command-output That's what I thought the purpose of the newline is, but the documentation for comint-simple-send states that it automatically appends a newline to the command, so it's not needed. As an aside I think that in the current version of emacs the while loop in the same function needs to be wrapped in a with-local-quit to avoid raising an error (or at least the accept-process-output call does). Best, Nate On Mon, Oct 2, 2017 at 4:14 PM Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>> wrote: I wrote that a long time ago, but my vague recollection is that the newline was needed to make the subprocess execute the command. Is it adding a 2nd newline to the end of ‘command’ resulting in the spare line? Eric From: Nathaniel Chodosh [mailto:nch...@an...<mailto:nch...@an...>] Sent: Monday, October 02, 2017 1:27 PM To: mat...@li...<mailto:mat...@li...> Subject: [Matlab-emacs-discuss] Removing extra lines from collect-command-output Hello, I've noticed that calling 'matlab-shell-collect-command-output' can result in extra new lines being sent to the *MATLAB* buffer which aren't deleted. When using company-mode to complete text this behavior is pretty annoying since as I'm typing lines are being inserted above the prompt. I believe that the cause of this is the line: (comint-simple-send (get-buffer-process (current-buffer)) (concat command "\n")) The newline added to the end of the command causes an extra line to be printed since it's interpreted as execute 'command' and then send a newline. Removing the newline fixes the problem. This seems like a suspiciously simple fix so I'm wondering why the newline was being appended to the command. Thanks, Nate P.S I am new to using mailing lists so if I've committed any faux pas in this email please let me know |
From: Nathaniel C. <nch...@an...> - 2017-10-03 17:18:01
|
Great. I've never contributed to a sourceforge project, should I post the diff under patches? On Tue, Oct 3, 2017 at 12:59 PM Eric Ludlam <Eri...@ma...> wrote: > Sounds reasonable to me. > > > > When you are happy with your changes, post a diff and hopefully Uwe can > install it. > > > > Thanks > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > > *Sent:* Tuesday, October 03, 2017 12:26 PM > *To:* Eric Ludlam <Eri...@ma...>; > mat...@li... > *Subject:* Re: [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > That's what I thought the purpose of the newline is, but the documentation > for comint-simple-send states that it automatically appends a newline to > the command, so it's not needed. > > As an aside I think that in the current version of emacs the while loop in > the same function needs to be wrapped in a with-local-quit to avoid raising > an error (or at least the accept-process-output call does). > > Best, > > Nate > > > > On Mon, Oct 2, 2017 at 4:14 PM Eric Ludlam <Eri...@ma...> > wrote: > > I wrote that a long time ago, but my vague recollection is that the > newline was needed to make the subprocess execute the command. Is it > adding a 2nd newline to the end of ‘command’ resulting in the spare line? > > > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > *Sent:* Monday, October 02, 2017 1:27 PM > *To:* mat...@li... > *Subject:* [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > Hello, > > I've noticed that calling 'matlab-shell-collect-command-output' can result > in extra new lines being sent to the *MATLAB* buffer which aren't deleted. > When using company-mode to complete text this behavior is pretty annoying > since as I'm typing lines are being inserted above the prompt. I believe > that the cause of this is the line: > (comint-simple-send (get-buffer-process (current-buffer)) > > (concat command "\n")) > > The newline added to the end of the command causes an extra line to be > printed since it's interpreted as execute 'command' and then send a > newline. Removing the newline fixes the problem. > > This seems like a suspiciously simple fix so I'm wondering why the newline > was being appended to the command. > > Thanks, > > Nate > > P.S I am new to using mailing lists so if I've committed any faux pas in > this email please let me know > > |
From: Eric L. <Eri...@ma...> - 2017-10-03 16:59:51
|
Sounds reasonable to me. When you are happy with your changes, post a diff and hopefully Uwe can install it. Thanks Eric From: Nathaniel Chodosh [mailto:nch...@an...] Sent: Tuesday, October 03, 2017 12:26 PM To: Eric Ludlam <Eri...@ma...>; mat...@li... Subject: Re: [Matlab-emacs-discuss] Removing extra lines from collect-command-output That's what I thought the purpose of the newline is, but the documentation for comint-simple-send states that it automatically appends a newline to the command, so it's not needed. As an aside I think that in the current version of emacs the while loop in the same function needs to be wrapped in a with-local-quit to avoid raising an error (or at least the accept-process-output call does). Best, Nate On Mon, Oct 2, 2017 at 4:14 PM Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>> wrote: I wrote that a long time ago, but my vague recollection is that the newline was needed to make the subprocess execute the command. Is it adding a 2nd newline to the end of ‘command’ resulting in the spare line? Eric From: Nathaniel Chodosh [mailto:nch...@an...<mailto:nch...@an...>] Sent: Monday, October 02, 2017 1:27 PM To: mat...@li...<mailto:mat...@li...> Subject: [Matlab-emacs-discuss] Removing extra lines from collect-command-output Hello, I've noticed that calling 'matlab-shell-collect-command-output' can result in extra new lines being sent to the *MATLAB* buffer which aren't deleted. When using company-mode to complete text this behavior is pretty annoying since as I'm typing lines are being inserted above the prompt. I believe that the cause of this is the line: (comint-simple-send (get-buffer-process (current-buffer)) (concat command "\n")) The newline added to the end of the command causes an extra line to be printed since it's interpreted as execute 'command' and then send a newline. Removing the newline fixes the problem. This seems like a suspiciously simple fix so I'm wondering why the newline was being appended to the command. Thanks, Nate P.S I am new to using mailing lists so if I've committed any faux pas in this email please let me know |
From: Nathaniel C. <nch...@an...> - 2017-10-03 16:25:55
|
That's what I thought the purpose of the newline is, but the documentation for comint-simple-send states that it automatically appends a newline to the command, so it's not needed. As an aside I think that in the current version of emacs the while loop in the same function needs to be wrapped in a with-local-quit to avoid raising an error (or at least the accept-process-output call does). Best, Nate On Mon, Oct 2, 2017 at 4:14 PM Eric Ludlam <Eri...@ma...> wrote: > I wrote that a long time ago, but my vague recollection is that the > newline was needed to make the subprocess execute the command. Is it > adding a 2nd newline to the end of ‘command’ resulting in the spare line? > > > > Eric > > > > *From:* Nathaniel Chodosh [mailto:nch...@an...] > *Sent:* Monday, October 02, 2017 1:27 PM > *To:* mat...@li... > *Subject:* [Matlab-emacs-discuss] Removing extra lines from > collect-command-output > > > > Hello, > > I've noticed that calling 'matlab-shell-collect-command-output' can result > in extra new lines being sent to the *MATLAB* buffer which aren't deleted. > When using company-mode to complete text this behavior is pretty annoying > since as I'm typing lines are being inserted above the prompt. I believe > that the cause of this is the line: > (comint-simple-send (get-buffer-process (current-buffer)) > > (concat command "\n")) > > The newline added to the end of the command causes an extra line to be > printed since it's interpreted as execute 'command' and then send a > newline. Removing the newline fixes the problem. > > This seems like a suspiciously simple fix so I'm wondering why the newline > was being appended to the command. > > Thanks, > > Nate > > P.S I am new to using mailing lists so if I've committed any faux pas in > this email please let me know > |
From: Eric L. <Eri...@ma...> - 2017-10-02 22:48:23
|
I wrote that a long time ago, but my vague recollection is that the newline was needed to make the subprocess execute the command. Is it adding a 2nd newline to the end of ‘command’ resulting in the spare line? Eric From: Nathaniel Chodosh [mailto:nch...@an...] Sent: Monday, October 02, 2017 1:27 PM To: mat...@li... Subject: [Matlab-emacs-discuss] Removing extra lines from collect-command-output Hello, I've noticed that calling 'matlab-shell-collect-command-output' can result in extra new lines being sent to the *MATLAB* buffer which aren't deleted. When using company-mode to complete text this behavior is pretty annoying since as I'm typing lines are being inserted above the prompt. I believe that the cause of this is the line: (comint-simple-send (get-buffer-process (current-buffer)) (concat command "\n")) The newline added to the end of the command causes an extra line to be printed since it's interpreted as execute 'command' and then send a newline. Removing the newline fixes the problem. This seems like a suspiciously simple fix so I'm wondering why the newline was being appended to the command. Thanks, Nate P.S I am new to using mailing lists so if I've committed any faux pas in this email please let me know |
From: Nathaniel C. <nch...@an...> - 2017-10-02 17:54:56
|
Hello, I've noticed that calling 'matlab-shell-collect-command-output' can result in extra new lines being sent to the *MATLAB* buffer which aren't deleted. When using company-mode to complete text this behavior is pretty annoying since as I'm typing lines are being inserted above the prompt. I believe that the cause of this is the line: (comint-simple-send (get-buffer-process (current-buffer)) (concat command "\n")) The newline added to the end of the command causes an extra line to be printed since it's interpreted as execute 'command' and then send a newline. Removing the newline fixes the problem. This seems like a suspiciously simple fix so I'm wondering why the newline was being appended to the command. Thanks, Nate P.S I am new to using mailing lists so if I've committed any faux pas in this email please let me know |
From: Eric L. <Eri...@ma...> - 2017-09-12 15:11:53
|
Hi Dave, That is ‘auto-fill-mode’ which is part of Emacs. matlab-mode extends auto-fill-mode, so you can use all of auto-fill’s behaviors, such as using C-x f to set the fill column to 100 or whatever you like. Eric From: Dave Coleman [mailto:dav...@gm...] Sent: Monday, September 11, 2017 5:09 PM To: mat...@li... Subject: [Matlab-emacs-discuss] Prevent Breaking New Line Hi Matlab-Emacs users, I find it very difficult to edit .m files in emacs with the Matlab plugin because there is some hidden auto-line break functionality that splits the line when it is 66 characters or longer. This makes no sense to me. I have searched all over the emacs and matlab-emacs documentation and lisp code but cannot figure out how to disable this. I would like 100 characters or some variable amount. Thanks! - dave |
From: Justin G. <jus...@gm...> - 2017-09-12 13:17:32
|
Hey Dave, you can the following to your .emacs before loading the library. (setq default-fill-column 110) Justin On Tue, Sep 12, 2017 at 2:11 PM, < mat...@li...> wrote: > Send Matlab-emacs-discuss mailing list submissions to > mat...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > or, via email, send a message with subject or body 'help' to > mat...@li... > > You can reach the person managing the list at > mat...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Matlab-emacs-discuss digest..." > > > Today's Topics: > > 1. Prevent Breaking New Line (Dave Coleman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 11 Sep 2017 15:08:50 -0600 > From: Dave Coleman <dav...@gm...> > To: mat...@li... > Subject: [Matlab-emacs-discuss] Prevent Breaking New Line > Message-ID: > <CAFJzPMtH2z0xahCjUc2jFJbUPjOJeDziJh5HffBSyzNy43Pt_A@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Matlab-Emacs users, > > I find it very difficult to edit .m files in emacs with the Matlab plugin > because there is some hidden auto-line break functionality that splits the > line when it is 66 characters or longer. This makes no sense to me. I have > searched all over the emacs and matlab-emacs documentation and lisp code > but cannot figure out how to disable this. I would like 100 characters or > some variable amount. > > Thanks! > > - dave > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > > > ------------------------------ > > End of Matlab-emacs-discuss Digest, Vol 65, Issue 1 > *************************************************** > |
From: Dave C. <dav...@gm...> - 2017-09-11 21:09:18
|
Hi Matlab-Emacs users, I find it very difficult to edit .m files in emacs with the Matlab plugin because there is some hidden auto-line break functionality that splits the line when it is 66 characters or longer. This makes no sense to me. I have searched all over the emacs and matlab-emacs documentation and lisp code but cannot figure out how to disable this. I would like 100 characters or some variable amount. Thanks! - dave |
From: Dong T. <ti...@me...> - 2017-07-31 14:51:55
|
Hi Dennis, Your input is very useful to me, thanks! The method to attach a running MATLAB process fits my need better. After some tests on your scripts, I just realized that a secondary emacs instance is preferred, given that a first emacs instance is running matlab-shell. A bit of summary of what I do: Put Dennis' first piece of code in matalb-attach.py Launch the first emacs, using emacsclient, to run matlab-shell. Launch the second emacs, using emacsclient, to run gdb. M-x: gdb gdb -i=mi -x matalb-attach.py (gdb) break mexFunction In the first emacs, (matlab-shell) K>> *some commands to call mexFunction* In the second emacs, (gdb) window will grab the control on MATLAB and show the source code of mexFunction. Make sure using -g when compiling the mex function. Thank you, Dong On Mon, Jul 24, 2017 at 02:12:34PM -0400, Dennis Ogbe wrote: > You can use Python as a scripting language in gdb to find the PID of a > currently running MATLAB process and attach to it. I remember doing this > a while back. The code was something around the lines of: > > <code> > > # debugging MEX files in emacs on linux > > import sys > pythondir = '/usr/share/gcc-6.2.1/python' > sys.path.append(pythondir) > > from libstdcxx.v6 import register_libstdcxx_printers > from subprocess import check_output > > try: > register_libstdcxx_printers(None) > except Exception as e: > pass > > # find the PID of the MATLAB process > def get_pid(name): > return list(map(int, check_output(["pidof", name]).split())) > > # set a new breakpoint, deleting any breakpoints referring to the same location > def new_bp(loc): > bps = gdb.breakpoints() > if bps: > for bp in bps: > if bp.location == loc: > gdb.execute("d " + str(bp.number)) > # set the dummy breakpoint > return gdb.Breakpoint(loc) > > # attach to the MATLAB process. if gdb attach fails, do > # sudo sh -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope" > pids = get_pid("MATLAB") > gdb.execute("attach {:d}".format(pids[0])) > > <end code> > > an alternative approach is to launch matlab from gdb: > > <code> > > run_matlab = True > > if run_matlab: > # spawn a new MATLAB process > matlab_dir = "/path/to/MATLAB/R2016b/bin/glnxa64/MATLAB" > gdb.execute("file " + matlab_dir) > > # set the MATLAB_DEBUG env > gdb_loc = "/usr/bin/gdb" > gdb.execute("set environment MATLAB_DEBUG = " + gdb_loc) > > # need to execute this according to > # https://www.mathworks.com/help/matlab/matlab_external/debugging-on-linux-platforms.html > gdb.execute("handle SIGSEGV SIGBUS nostop noprint") > > # set the breakpoint at the mexFunction > mex_Bp = new_bp("mexFunction") > > # run matlab > gdb.execute("run -nojvm -r debug_encoder -singleCompThread") > > <end code> > > Dennis > > Dong Tian <ti...@me...> writes: > > > Hi Eric, all, > > > > Thanks for replying. > > > > It is non-trivial to attach the matlab process to gdb. > > > > Matlab provides a command line option -Dgdb to associate the Matlab process > > for gdb debugging. Would it be easier to launch "matlab-shell" with -Dgdb > > as option? Maybe your or someone else could put lights on this approach? > > > > Thanks, > > Dong > > > > On Wed, Jul 19, 2017 at 09:01:56PM +0000, Eric Ludlam wrote: > >> Hi Dong, > >> > >> You can fire up GDB from within Emacs and "attach" to a process. > >> Using this to attach to a process running MATLAB inside Emacs' > >> matlab-shell will let you debug through MATLAB code and into your C++ > >> code. > >> > >> I haven't done this in a few years, and not with Mex (I was debugging > >> MATLAB directly) but I'm guessing the principle is the same. > >> > >> Eric > >> > >> -----Original Message----- > >> From: Dong Tian [mailto:ti...@me...] > >> Sent: Wednesday, July 19, 2017 1:56 PM > >> To: mat...@li... > >> Subject: [Matlab-emacs-discuss] How to debug MEX files (C code) from Emacs? > >> > >> Hello, > >> > >> Could anyone provide a pointer on how to debug MEX files from Emacs? > >> E.g. using gdb? > >> > >> I am familiar with the procedure of debugging pure c/c++ code or .m > >> code from Emacs using gdb, but I don't know a good way to debug MEX > >> file coded in C from Emacs. > >> > >> Thanks in advance, > >> Dong > >> > >> ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://secure-web.cisco.com/1ujKNEvoZ9nB-3MswM8yQpeWgC6aSas93lzT8a00GA11SdB5SpQ6CVRIOx-heKXnqKECDVK85FoUunZq98vpNfzj9z-dAEXYdTSCYMo17rGews2sXFe04QVklpkIgysqCMwIaoJQltBgN0vzTKcyy6uH42EmnOZN9d_7d6GI8HTluD2CTM_kIvO0I4ApdEW1uyzzeVHPDe01AEhL8z1lCXCd9Ls5JK37FPBnlqU-vHsqgajNbrh54-xMsjRMjU-khdIzpnhQOzvN53aQbsoH_mYU759kv1n9L6l97WEaazGtUV61gkLrwcRmPqtZUkz2IU_aA6HkROB1JRv1L63MCOuGFFTjdNrbynGp78WL3jRQ/http%3A%2F%2Fsdm.link%2Fslashdot _______________________________________________ > >> Matlab-emacs-discuss mailing list > >> Mat...@li... > >> https://secure-web.cisco.com/10eOO6rYM1RqFCHmlXsWS1TYTfQt0mblS7KZvYNUIxTp-ZGg9Gb7geEfnffV5gC9W3jjN5jlZyDrKFrGw14cD9PgfSBzm5qQ_6jbAPG5AQ61KZoTDufZTTsMhvlc7k-8mkewh3PKUPkO-9wtKK_ayCNqBB37kEYCLOH673oZPhzvewWVdd2KYIRf8sWleZLty8CyehfWXIWwMAX6yxqj9reri0LJu_hSOjSDE7bqwujPw_GaFGbRLesA4iu9JVaGg--IWyW7nW0t2ki22_ESPWiRYdGq7hqiMg7EYsAtkPymllsorUJDO3-uBqjP-SI1ky0GgTCRGnzpyoe5id6tfPy19K959g_PDiyGSEevC8Us/https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmatlab-emacs-discuss > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://secure-web.cisco.com/1ujKNEvoZ9nB-3MswM8yQpeWgC6aSas93lzT8a00GA11SdB5SpQ6CVRIOx-heKXnqKECDVK85FoUunZq98vpNfzj9z-dAEXYdTSCYMo17rGews2sXFe04QVklpkIgysqCMwIaoJQltBgN0vzTKcyy6uH42EmnOZN9d_7d6GI8HTluD2CTM_kIvO0I4ApdEW1uyzzeVHPDe01AEhL8z1lCXCd9Ls5JK37FPBnlqU-vHsqgajNbrh54-xMsjRMjU-khdIzpnhQOzvN53aQbsoH_mYU759kv1n9L6l97WEaazGtUV61gkLrwcRmPqtZUkz2IU_aA6HkROB1JRv1L63MCOuGFFTjdNrbynGp78WL3jRQ/http%3A%2F%2Fsdm.link%2Fslashdot > > _______________________________________________ > > Matlab-emacs-discuss mailing list > > Mat...@li... > > https://secure-web.cisco.com/10eOO6rYM1RqFCHmlXsWS1TYTfQt0mblS7KZvYNUIxTp-ZGg9Gb7geEfnffV5gC9W3jjN5jlZyDrKFrGw14cD9PgfSBzm5qQ_6jbAPG5AQ61KZoTDufZTTsMhvlc7k-8mkewh3PKUPkO-9wtKK_ayCNqBB37kEYCLOH673oZPhzvewWVdd2KYIRf8sWleZLty8CyehfWXIWwMAX6yxqj9reri0LJu_hSOjSDE7bqwujPw_GaFGbRLesA4iu9JVaGg--IWyW7nW0t2ki22_ESPWiRYdGq7hqiMg7EYsAtkPymllsorUJDO3-uBqjP-SI1ky0GgTCRGnzpyoe5id6tfPy19K959g_PDiyGSEevC8Us/https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmatlab-emacs-discuss |
From: Dennis O. <do...@pu...> - 2017-07-24 18:25:09
|
You can use Python as a scripting language in gdb to find the PID of a currently running MATLAB process and attach to it. I remember doing this a while back. The code was something around the lines of: <code> # debugging MEX files in emacs on linux import sys pythondir = '/usr/share/gcc-6.2.1/python' sys.path.append(pythondir) from libstdcxx.v6 import register_libstdcxx_printers from subprocess import check_output try: register_libstdcxx_printers(None) except Exception as e: pass # find the PID of the MATLAB process def get_pid(name): return list(map(int, check_output(["pidof", name]).split())) # set a new breakpoint, deleting any breakpoints referring to the same location def new_bp(loc): bps = gdb.breakpoints() if bps: for bp in bps: if bp.location == loc: gdb.execute("d " + str(bp.number)) # set the dummy breakpoint return gdb.Breakpoint(loc) # attach to the MATLAB process. if gdb attach fails, do # sudo sh -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope" pids = get_pid("MATLAB") gdb.execute("attach {:d}".format(pids[0])) <end code> an alternative approach is to launch matlab from gdb: <code> run_matlab = True if run_matlab: # spawn a new MATLAB process matlab_dir = "/path/to/MATLAB/R2016b/bin/glnxa64/MATLAB" gdb.execute("file " + matlab_dir) # set the MATLAB_DEBUG env gdb_loc = "/usr/bin/gdb" gdb.execute("set environment MATLAB_DEBUG = " + gdb_loc) # need to execute this according to # https://www.mathworks.com/help/matlab/matlab_external/debugging-on-linux-platforms.html gdb.execute("handle SIGSEGV SIGBUS nostop noprint") # set the breakpoint at the mexFunction mex_Bp = new_bp("mexFunction") # run matlab gdb.execute("run -nojvm -r debug_encoder -singleCompThread") <end code> Dennis Dong Tian <ti...@me...> writes: > Hi Eric, all, > > Thanks for replying. > > It is non-trivial to attach the matlab process to gdb. > > Matlab provides a command line option -Dgdb to associate the Matlab process > for gdb debugging. Would it be easier to launch "matlab-shell" with -Dgdb > as option? Maybe your or someone else could put lights on this approach? > > Thanks, > Dong > > On Wed, Jul 19, 2017 at 09:01:56PM +0000, Eric Ludlam wrote: >> Hi Dong, >> >> You can fire up GDB from within Emacs and "attach" to a process. Using this to attach to a process running MATLAB inside Emacs' matlab-shell will let you debug through MATLAB code and into your C++ code. >> >> I haven't done this in a few years, and not with Mex (I was debugging MATLAB directly) but I'm guessing the principle is the same. >> >> Eric >> >> -----Original Message----- >> From: Dong Tian [mailto:ti...@me...] >> Sent: Wednesday, July 19, 2017 1:56 PM >> To: mat...@li... >> Subject: [Matlab-emacs-discuss] How to debug MEX files (C code) from Emacs? >> >> Hello, >> >> Could anyone provide a pointer on how to debug MEX files from Emacs? >> E.g. using gdb? >> >> I am familiar with the procedure of debugging pure c/c++ code or .m code from Emacs using gdb, but I don't know a good way to debug MEX file coded in C from Emacs. >> >> Thanks in advance, >> Dong >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://secure-web.cisco.com/1ujKNEvoZ9nB-3MswM8yQpeWgC6aSas93lzT8a00GA11SdB5SpQ6CVRIOx-heKXnqKECDVK85FoUunZq98vpNfzj9z-dAEXYdTSCYMo17rGews2sXFe04QVklpkIgysqCMwIaoJQltBgN0vzTKcyy6uH42EmnOZN9d_7d6GI8HTluD2CTM_kIvO0I4ApdEW1uyzzeVHPDe01AEhL8z1lCXCd9Ls5JK37FPBnlqU-vHsqgajNbrh54-xMsjRMjU-khdIzpnhQOzvN53aQbsoH_mYU759kv1n9L6l97WEaazGtUV61gkLrwcRmPqtZUkz2IU_aA6HkROB1JRv1L63MCOuGFFTjdNrbynGp78WL3jRQ/http%3A%2F%2Fsdm.link%2Fslashdot _______________________________________________ >> Matlab-emacs-discuss mailing list >> Mat...@li... >> https://secure-web.cisco.com/10eOO6rYM1RqFCHmlXsWS1TYTfQt0mblS7KZvYNUIxTp-ZGg9Gb7geEfnffV5gC9W3jjN5jlZyDrKFrGw14cD9PgfSBzm5qQ_6jbAPG5AQ61KZoTDufZTTsMhvlc7k-8mkewh3PKUPkO-9wtKK_ayCNqBB37kEYCLOH673oZPhzvewWVdd2KYIRf8sWleZLty8CyehfWXIWwMAX6yxqj9reri0LJu_hSOjSDE7bqwujPw_GaFGbRLesA4iu9JVaGg--IWyW7nW0t2ki22_ESPWiRYdGq7hqiMg7EYsAtkPymllsorUJDO3-uBqjP-SI1ky0GgTCRGnzpyoe5id6tfPy19K959g_PDiyGSEevC8Us/https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmatlab-emacs-discuss > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://secure-web.cisco.com/1ujKNEvoZ9nB-3MswM8yQpeWgC6aSas93lzT8a00GA11SdB5SpQ6CVRIOx-heKXnqKECDVK85FoUunZq98vpNfzj9z-dAEXYdTSCYMo17rGews2sXFe04QVklpkIgysqCMwIaoJQltBgN0vzTKcyy6uH42EmnOZN9d_7d6GI8HTluD2CTM_kIvO0I4ApdEW1uyzzeVHPDe01AEhL8z1lCXCd9Ls5JK37FPBnlqU-vHsqgajNbrh54-xMsjRMjU-khdIzpnhQOzvN53aQbsoH_mYU759kv1n9L6l97WEaazGtUV61gkLrwcRmPqtZUkz2IU_aA6HkROB1JRv1L63MCOuGFFTjdNrbynGp78WL3jRQ/http%3A%2F%2Fsdm.link%2Fslashdot > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://secure-web.cisco.com/10eOO6rYM1RqFCHmlXsWS1TYTfQt0mblS7KZvYNUIxTp-ZGg9Gb7geEfnffV5gC9W3jjN5jlZyDrKFrGw14cD9PgfSBzm5qQ_6jbAPG5AQ61KZoTDufZTTsMhvlc7k-8mkewh3PKUPkO-9wtKK_ayCNqBB37kEYCLOH673oZPhzvewWVdd2KYIRf8sWleZLty8CyehfWXIWwMAX6yxqj9reri0LJu_hSOjSDE7bqwujPw_GaFGbRLesA4iu9JVaGg--IWyW7nW0t2ki22_ESPWiRYdGq7hqiMg7EYsAtkPymllsorUJDO3-uBqjP-SI1ky0GgTCRGnzpyoe5id6tfPy19K959g_PDiyGSEevC8Us/https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmatlab-emacs-discuss |
From: Dong T. <ti...@me...> - 2017-07-24 15:23:31
|
Hi Eric, all, Thanks for replying. It is non-trivial to attach the matlab process to gdb. Matlab provides a command line option -Dgdb to associate the Matlab process for gdb debugging. Would it be easier to launch "matlab-shell" with -Dgdb as option? Maybe your or someone else could put lights on this approach? Thanks, Dong On Wed, Jul 19, 2017 at 09:01:56PM +0000, Eric Ludlam wrote: > Hi Dong, > > You can fire up GDB from within Emacs and "attach" to a process. Using this to attach to a process running MATLAB inside Emacs' matlab-shell will let you debug through MATLAB code and into your C++ code. > > I haven't done this in a few years, and not with Mex (I was debugging MATLAB directly) but I'm guessing the principle is the same. > > Eric > > -----Original Message----- > From: Dong Tian [mailto:ti...@me...] > Sent: Wednesday, July 19, 2017 1:56 PM > To: mat...@li... > Subject: [Matlab-emacs-discuss] How to debug MEX files (C code) from Emacs? > > Hello, > > Could anyone provide a pointer on how to debug MEX files from Emacs? > E.g. using gdb? > > I am familiar with the procedure of debugging pure c/c++ code or .m code from Emacs using gdb, but I don't know a good way to debug MEX file coded in C from Emacs. > > Thanks in advance, > Dong > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Eric L. <Eri...@ma...> - 2017-07-19 21:16:55
|
Hi Dong, You can fire up GDB from within Emacs and "attach" to a process. Using this to attach to a process running MATLAB inside Emacs' matlab-shell will let you debug through MATLAB code and into your C++ code. I haven't done this in a few years, and not with Mex (I was debugging MATLAB directly) but I'm guessing the principle is the same. Eric -----Original Message----- From: Dong Tian [mailto:ti...@me...] Sent: Wednesday, July 19, 2017 1:56 PM To: mat...@li... Subject: [Matlab-emacs-discuss] How to debug MEX files (C code) from Emacs? Hello, Could anyone provide a pointer on how to debug MEX files from Emacs? E.g. using gdb? I am familiar with the procedure of debugging pure c/c++ code or .m code from Emacs using gdb, but I don't know a good way to debug MEX file coded in C from Emacs. Thanks in advance, Dong ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Matlab-emacs-discuss mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Dong T. <ti...@me...> - 2017-07-19 18:13:47
|
Hello, Could anyone provide a pointer on how to debug MEX files from Emacs? E.g. using gdb? I am familiar with the procedure of debugging pure c/c++ code or .m code from Emacs using gdb, but I don't know a good way to debug MEX file coded in C from Emacs. Thanks in advance, Dong |
From: Eric L. <Eri...@ma...> - 2017-05-30 15:51:00
|
Hi Chris, When using MATLAB from within Emacs, there is an extra toolbox directory added to the path, and an init file. The purpose of this toolbox is to shadow ‘opentoline’ to get it to integrate better with Emacs. If you run Emacs separately, you won’t get that toolbox. I haven’t tried it, but I’ll guess you could add that Emacs toolbox to your MATLAB path, and run the ‘emacsinit’ command therein. If you find there are more things to shadow to improve the experience, be sure you are using the newer matlab emacs git repository so your ideas can be integrated back. Thanks Eric From: Christian Peel [mailto:cp...@ta...] Sent: Monday, May 22, 2017 9:17 PM To: mat...@li... Subject: [Matlab-emacs-discuss] matlab-emacs on Windows 10 with a cygwin emacs Hi folks, I'm using Matlab 2015a on Windows 10 with GNU Emacs 25.2.1 (x86_64-unknown-cygwin) via cygwin. My goal is to use emacs with matlab in generally the same way as in the EEI-enabled past, or as described by Eric Ludlum in a 2009 Matworks post: https://goo.gl/E7AO51 Do others do this? Or at least thing it's possible? I think I've done this in the past, yet I've always had some sort of *NIX available to work on and did not rely on Windows. I can use a batch file to open emacsclient from matlab (say via 'open myfun'), which flashes a batch window on the screen. Is there any way to start emacsclient without this DOS command window temporarily showing up on the screen? This is relatively minor and just provides context for the question below. After configuring emacsclient as editor, and having it work as above, why does clicking on line number in the command window open the *Matlab Editor*? The same thing happens if I set the editor preference to 'Automatically open files when Matlab reaches a breakpoint'. I'm happy to give more details as needed. Chris -- |
From: Christian P. <cp...@ta...> - 2017-05-23 01:41:55
|
Hi folks, I'm using Matlab 2015a on Windows 10 with GNU Emacs 25.2.1 (x86_64-unknown-cygwin) via cygwin. My goal is to use emacs with matlab in generally the same way as in the EEI-enabled past, or as described by Eric Ludlum in a 2009 Matworks post: https://goo.gl/E7AO51 Do others do this? Or at least thing it's possible? I think I've done this in the past, yet I've always had some sort of *NIX available to work on and did not rely on Windows. I can use a batch file to open emacsclient from matlab (say via 'open myfun'), which flashes a batch window on the screen. Is there any way to start emacsclient without this DOS command window temporarily showing up on the screen? This is relatively minor and just provides context for the question below. After configuring emacsclient as editor, and having it work as above, why does clicking on line number in the command window open the *Matlab Editor*? The same thing happens if I set the editor preference to 'Automatically open files when Matlab reaches a breakpoint'. I'm happy to give more details as needed. Chris -- |
From: Deepak C. <dpa...@gm...> - 2017-03-22 19:53:12
|
On my machine, it was because the default-fill-column is not defined as a variable. Adding this statement (defvar default-fill-column 100) before loading matlab-mode fixes it. On 03/01/2017 07:17 AM, Eric Ludlam wrote: > Font lock runs in a series of hooks to make it feel like it’s running in > the background. If something throws an error in font lock, it gets > shut off. > > > > In a fresh emacs, load up an offending M file, and check your > **Messages** buffer to see if there is anything there. > > > > If not, you may need to lower the font lock level to find out which > level causes the error. To do that: > > > > M-x customize-variable RET font-lock-maximum-decoration RET > > > > I think there are 3 levels so you can pick 1, 2, or 3, or leave at > ‘maximum’. I haven’t used this option in a very long time, but suspect > you may need to kill your MATLAB buffer and open it again to have the > option take effect. > > > > Eric > > > > *From:*Tyler Morgan [mailto:a.t...@gm...] > *Sent:* Monday, February 27, 2017 2:34 PM > *To:* mat...@li... > *Subject:* [Matlab-emacs-discuss] Syntax highlighting not working > > > > I recently installed matlab-emacs on emacs 26.0.50 on Ubuntu. Everything > seems to be working properly, but I am not getting syntax highlighting > when opening *.m files using global-font-lock-mode. I do however get > highlighting in the matlab-shell. > > > > I'm not sure exactly what other information might be relevant for > teasing out this issue, but it makes matlab-mode difficult to use. > > > > Thanks, > > Tyler > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > |
From: Peter M. <pet...@gm...> - 2017-03-15 18:29:48
|
For those of you still using 2016b (or 2016a), here is a relatively painless solution. I usually have /usr/local/bin/matlab symlinked to the /Applications... file. Following a suggestion from Eric Ludlam, I changed that file to the following script which solves my crashing issues. #!/bin/bash ulimit -s 8512 /Applications/MATLAB_R2016b.app/bin/matlab $* note that 8512 is the MAXIMUM value that ulimit -s can be set to. Higher values cause failure. I don't know why. Peter |
From: Cumhur E. <cum...@gm...> - 2017-03-10 14:28:58
|
Hi, I can happily announce that this issue seems to be solved in MATLAB R2017a. Tried with emacs 25.1 and spacemacs on Mac, and get the long awaited message without crashes < M A T L A B (R) > Copyright 1984-2017 The MathWorks, Inc. R2017a (9.2.0.538062) 64-bit (maci64) February 23, 2017 To get started, type one of these: helpwin, helpdesk, or demo. For product information, visit www.mathworks.com. >>> Thanks all for looking into this, best wishes Cumhur > On 20 Dec 2016, at 17.32, Cumhur Erkut <Cum...@gm...> wrote: > > Dear Eric, Rhys, and list > > Thanks so much for looking into this. As Eric predicted, I could not get anything by setting max-lisp-eval-depth to a higher or lower value, matlab still crashes. > > Today I have downloaded the R2017a Prerelease, the behavior is the same but the crash-report is more varied. > > I have created the following support request at mathworks, I’ll post if I hear something. > > Season’s greetings, Cumhur > > —— > Since 2016a, MATLAB crashes in Emacs, in matlab-shell or even without using it from any eshell. The developers of matlab-shell have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size. It looks like MATLAB has more demands on stack size since 2016a, and Emacs cannot cope with it. We are trying to find a way to increase the stack-size in Emacs, but if not absolutely needed, could you please also decrease the MATLAB needs? This behavior remains in R2017a Prerelease, would be great to find a solution to keep using Emacs as the main editor of MATLAB code. I attach the crash log below. > ---- > > > < M A T L A B (R) > > Copyright 1984-2016 The MathWorks, Inc. > R2017a Prerelease (9.2.0.494151) 64-bit (maci64) > December 1, 2016 > > > To get started, type one of these: helpwin, helpdesk, or demo. > For product information, visit www.mathworks.com. > > Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/mathworks/cfbutils/StatEntryReceiver > at com.mathworks.mwswing.MacAppearanceUtils.getMacAlternateSelectedControlColor(MacAppearanceUtils.java:254) > at com.mathworks.mwswing.MacAppearanceUtils.setMacAppearanceColors(MacAppearanceUtils.java:229) > at com.mathworks.mwswing.MacAppearanceUtils.initialize(MacAppearanceUtils.java:41) > at com.mathworks.mwswing.plaf.PlafUtils.correctMacintoshLookAndFeel(PlafUtils.java:203) > at com.mathworks.mwswing.plaf.PlafUtils.correctPlatformLookAndFeel(PlafUtils.java:118) > at com.mathworks.mwswing.plaf.PlafUtils.setLookAndFeel(PlafUtils.java:298) > at com.mathworks.fatalexit.FatalExitFrame.doMatlabLikeSetup(FatalExitFrame.java:731) > at com.mathworks.fatalexit.FatalExitFrame.access$1400(FatalExitFrame.java:93) > at com.mathworks.fatalexit.FatalExitFrame$13.run(FatalExitFrame.java:882) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:738) > at java.awt.EventQueue.access$300(EventQueue.java:103) > at java.awt.EventQueue$3.run(EventQueue.java:699) > at java.awt.EventQueue$3.run(EventQueue.java:697) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:708) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > Caused by: java.lang.ClassNotFoundException: com.mathworks.cfbutils.StatEntryReceiver > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:425) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > ... 23 more > > ------------------------------------------------------------------------ > Bus error detected at Tue Dec 20 17:15:38 2016 > ------------------------------------------------------------------------ > > Configuration: > Crash Decoding : Disabled - No sandbox or build area path > Crash Mode : continue (default) > Current Graphics Driver: Unknown hardware > Current Visual : Quartz > Default Encoding : ISO-8859-1 > Deployed : false > Host Name : h304.aau1x-3.klient.sydhavn2.site.aau.dk > MATLAB Architecture : maci64 > MATLAB Entitlement ID: 3623390 > MATLAB Root : /Applications/MATLAB_R2017a.app > MATLAB Version : 9.2.0.494151 (R2017a) Prerelease > OpenGL : hardware > Operating System : Darwin 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 > Processor ID : x86 Family 6 Model 70 Stepping 1, GenuineIntel > Virtual Machine : Java 1.7.0_75-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode > Window System : Quartz > > Fault Count: 1 > > > Abnormal termination: > Bus error > > Register State (from fault): > RAX = 000070000b884338 RBX = 0000000000000003 > RCX = 0000000000000000 RDX = 000000011f167ac0 > RSP = 00000001167e6dd8 RBP = 000070000b8840f0 > RSI = 0000000107c7be7a RDI = 000070000b8840c0 > > R8 = 00000001167e6e08 R9 = 00007fb229087a00 > R10 = 000070000b8840e0 R11 = 000000010e33ab4a > R12 = 0000000000000000 R13 = 0000000000000000 > R14 = 00007fb22b4df080 R15 = 000070000b884180 > > RIP = 0000000000000000 RFL = 000000010c7a0ea7 > > CS = 000070000b884100 FS = 0000000107bb1bdf GS = 0000000000000000 > > Stack Trace (from fault): > [ 0] 0x00000001079e3714 bin/maci64/libmwfl.dylib+00034580 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052 > [ 1] 0x00000001079e70ca bin/maci64/libmwfl.dylib+00049354 _ZN2fl4test17terminate_handledEv+00000810 > [ 2] 0x00000001079e6b39 bin/maci64/libmwfl.dylib+00047929 _ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000185 > [ 3] 0x000000010ac2d6c1 bin/maci64/libmwmcr.dylib+00435905 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00002081 > [ 4] 0x000000010ac2d010 bin/maci64/libmwmcr.dylib+00434192 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00000368 > [ 5] 0x000000010ac2ba0a bin/maci64/libmwmcr.dylib+00428554 mnFatalSignalHandler+00000154 > [ 6] 0x00007fffb4037bba /usr/lib/system/libsystem_platform.dylib+00011194 _sigtramp+00000026 > [ 7] 0x0000000000000020 <unknown-module>+00000000 > [ 8] 0x0000000107bb1bdf bin/maci64/libmx.dylib+00043999 _ZN6matrix6detail10noninlined12mx_array_api31try_nonrecursive_mxDestroyArrayEP11mxArray_tag+00000015 > [ 9] 0x000000010e33af8d bin/maci64/libmwlxetypes.dylib+00098189 _ZN9MathWorks3lxe6xvalueC1ENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000077 > [ 10] 0x000070000b884230 <unknown-module>+00000000 > [ 11] 0x000070000b884198 <unknown-module>+00000000 > > > If this problem is reproducible, please submit a Service Request via: > http://www.mathworks.com/support/contact_us/ > > A technical support engineer might contact you with further information. > > Thank you for your help.** This crash report has been saved to disk as /Users/cerkut/matlab_crash_dump.52230-1 ** > > MATLAB is exiting because of fatal error > > M-Shell killed: 9 > —— > > >> On 19 Dec 2016, at 15.02, Eric Ludlam <Eri...@ma...> wrote: >> >> Hi Rhys, >> >> I am referring to the C stack size (the amount of memory allocated for both the stack and variables of a running C program. In this case MATLAB as a subprocess is being limited in how big it’s stack can be because its parent (Emacs) has setup limits for that subprocess. >> >> This can be a useful thing to do if you don’t always trust a subprocess, since it will prevent the subprocess from accidentally (or perhaps purposefully) locking up your computer by using up all available memory. >> >> Eric >> >> From: Rhys Thomas [mailto:e.r...@gm...] >> Sent: Sunday, December 18, 2016 4:20 AM >> To: mat...@li... >> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1 >> >> Hello, >> >> Is max-lisp-eval-depth what you are looking for? >> >> max-lisp-eval-depth is a variable defined in ‘C source code’. >> Its value is 800 >> >> This variable may be risky if used as a file-local variable. >> >> Documentation: >> Limit on depth in ‘eval’, ‘apply’ and ‘funcall’ before error. >> >> This limit serves to catch infinite recursions for you before they cause >> actual stack overflow in C, which would be fatal for Emacs. >> You can safely make it considerably larger than its default value, >> if that proves inconveniently small. However, if you increase it too far, >> Emacs could overflow the real C stack, and crash. >> >> >> Regards, >> >> Rhys >> >> On 14/12/16 16:46, Eric Ludlam wrote: >> Hello again, >> >> I’ve been watching progress in development around this Mac/Emacs/MATLAB issue. They have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size. A way to reproduce outside of Emacs is as follows: >> >> ulimit -s 8515 >> matlab >> >> Stacks limited to sizes of 8512 or more works fine for them. >> >> I looked into stack size within emacs, and saw several references to increasing the stack size to 8519 in Emacs to work around a bug I’m not familiar with, but not to a way to increase the stack size of sub-processes. >> >> Any Emacs hackers on this list familiar with updating stack size for sub-processes in Emacs as a way to work around this problem? >> Thanks >> Eric >> >> From: Peter Mao [mailto:pet...@gm...] >> Sent: Monday, November 14, 2016 11:18 AM >> To: mat...@li... >> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1 >> >> Further evidence (I hope this helps someone solve the problem): >> >> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell. >> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal >> 3. 2016a works fine in emacs >> 4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b! >> $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java >> >> This might not be a Java issue. >> >> On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...> wrote: >> Yes, I'm seeing this problem, too. Mathworks won't touch it, as it does seem to be a real third party issue with Emacs. >> >> I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?). >> >> I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color. >> >> In all cases, the actual shell is /bin/bash. I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly. May be time to cross post to emacs developers. >> >> Peter >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> Matlab-emacs-discuss mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ >> Matlab-emacs-discuss mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > |
From: Eric L. <Eri...@ma...> - 2017-03-01 22:19:58
|
Hmm. I'm not certain what the difference is. As I mentioned, matlab-shell has no directory parsing itself, it just turns on this service. When I looked at how it works, it's just a long conditional trying out different regexp trying to divine what is being CD'd to. I'm assuming you needed the 'quotes' around the path in case of spaces in the path. Looking through shell-dirtrack-mode, it looks like there isn't much in the way of options regarding syntax around the string. It was probably an error when I tried it in a dos shell due to how the syntax table was set up. Perhaps the desired path can be examined for spaces, and then have no special syntax around it if there are no spaces. That will allow it to work in most cases. Or maybe instead of depending on the cd command, just change the default-directory next to the code that inserts the CD command. That would be pretty robust. Eric -----Original Message----- From: Uwe Brauer [mailto:ou...@ma...] Sent: Friday, February 24, 2017 1:26 PM To: Eric Ludlam <Eri...@ma...> Cc: Uwe Brauer <ou...@ma...>; matlab-emacs-discuss <mat...@li...> Subject: Re: [Matlab-emacs-discuss] annoying path behavior of the *MATLAB* shell buffer who is the culprit >>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > Hiya, > Matlab-shell uses dirtrack, or shell-directory-tracker. It just > watches the input stream and changes default-directory when it sees: > cd /some/path/to/directory > I'll guess MATLAB syntax around (['/path']) is confusing it. > You could probably replace all the parens etc with just: > cd '/path' > which should work fine. I tried this with a DOS shell in Emacs and > Emacs followed the path even though the actual shell threw and error. Hi Eric Thanks for your answer, however at least for this does not work I know obtain, with the same logic as before >> cd '/home/oub/ALLES/Dir-Matlab/dir1/' >> test y = 64 >> addpath('/home/oub/.emacs.d/elpa/matlab-mode-20160902.459/toolbox','-begin'); rehash; emacsinit('emacsclient -n'); >> >> pwd ans = /home/oub/ALLES/Dir-Matlab/dir1 >> cd '/home/oub/ALLES/Dir-Matlab/dir2/' >> test2 y = 49 However find-file still thinks it is in dir1 not 2. Uwe |
From: Eric L. <Eri...@ma...> - 2017-03-01 14:17:31
|
Font lock runs in a series of hooks to make it feel like it’s running in the background. If something throws an error in font lock, it gets shut off. In a fresh emacs, load up an offending M file, and check your *Messages* buffer to see if there is anything there. If not, you may need to lower the font lock level to find out which level causes the error. To do that: M-x customize-variable RET font-lock-maximum-decoration RET I think there are 3 levels so you can pick 1, 2, or 3, or leave at ‘maximum’. I haven’t used this option in a very long time, but suspect you may need to kill your MATLAB buffer and open it again to have the option take effect. Eric From: Tyler Morgan [mailto:a.t...@gm...] Sent: Monday, February 27, 2017 2:34 PM To: mat...@li... Subject: [Matlab-emacs-discuss] Syntax highlighting not working I recently installed matlab-emacs on emacs 26.0.50 on Ubuntu. Everything seems to be working properly, but I am not getting syntax highlighting when opening *.m files using global-font-lock-mode. I do however get highlighting in the matlab-shell. I'm not sure exactly what other information might be relevant for teasing out this issue, but it makes matlab-mode difficult to use. Thanks, Tyler |
From: Tyler M. <a.t...@gm...> - 2017-02-27 19:34:04
|
I recently installed matlab-emacs on emacs 26.0.50 on Ubuntu. Everything seems to be working properly, but I am not getting syntax highlighting when opening *.m files using global-font-lock-mode. I do however get highlighting in the matlab-shell. I'm not sure exactly what other information might be relevant for teasing out this issue, but it makes matlab-mode difficult to use. Thanks, Tyler |