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: Uwe B. <ou...@ma...> - 2016-02-09 16:54:42
|
Hi all I am now trying to apply patches which have been posted to the mailing list. I have one which contains a line such as (defcustom matlab-change-current-directory nil Does anybody know who the author is? I applied the patch without problem, but would like to know who the author is before committing and pushing. Regards Uwe Brauer |
From: Eric L. <Eri...@ma...> - 2016-02-09 14:04:18
|
I added a git repository which shows up as "matalb-emacs" in the project toolbar via the web interface on source forge. If you send me your source forge user id I'll add you in as a developer so you can write the repository. Thanks Eric -----Original Message----- From: Uwe Brauer [mailto:ou...@ma...] Sent: Tuesday, February 09, 2016 6:06 AM To: matlab-emacs <mat...@li...> Subject: [Matlab-emacs-discuss] CVS git, sourceforge git state of art Hi There have not been more comments on the issue we discussed. That is why I propose the following: - @Eric: could you please open a git account on sourceforge and tell us what to do to get write access? I would then push the converted git repo. I would then also try to apply the patches I am aware of (2). Eric if there are more please let me know. - @github users: any volunteer to setup a github account and a *mirror* for sourceforge which could host matlab-emacs? I think the name for that account and its url are important. - in due time we can decide to move to github completely or just have a mirror. Regards Uwe Brauer ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Matlab-emacs-discuss mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Uwe B. <ou...@ma...> - 2016-02-09 11:06:26
|
Hi There have not been more comments on the issue we discussed. That is why I propose the following: - @Eric: could you please open a git account on sourceforge and tell us what to do to get write access? I would then push the converted git repo. I would then also try to apply the patches I am aware of (2). Eric if there are more please let me know. - @github users: any volunteer to setup a github account and a *mirror* for sourceforge which could host matlab-emacs? I think the name for that account and its url are important. - in due time we can decide to move to github completely or just have a mirror. Regards Uwe Brauer |
From: Uwe B. <ou...@ma...> - 2016-02-08 14:21:04
|
> On Mon, 8 Feb 2016, at 11:24 AM, Uwe Brauer wrote: > The feature github has is the large community that uses it and that it > has become the de facto standard hosting location. There are multiple > forks of matlab-mode on github because that is the easiest place for > many people to publish their changes. If we want to collect those > changes we have to make it as easy as possible for people to contribute > and for many people a github pull request is the easiest way to do that. > Working with SF is only slightly more effort, but we have to aim for the > minimum. > At the least we should have a github mirror that people can raise pull > requests against. But if we do that then the SF repo is just extra > effort. That sounds very reasonable to me, the question is how to set it up. I mean opening a github account is easy and cloning the repo as well, but how can we set up the mirror? Uwe |
From: Simon B. <li...@70...> - 2016-02-08 13:09:06
|
On Mon, 8 Feb 2016, at 11:24 AM, Uwe Brauer wrote: > So once we have decided for git, I don't see any difference > between sourceforge/github/bitbucket etc, save the graphical > interface. > Does everybody agree with that? A CVCS makes the question of the > server less important, no? > Or does github has some shiny wonderful feature I oversee? The feature github has is the large community that uses it and that it has become the de facto standard hosting location. There are multiple forks of matlab-mode on github because that is the easiest place for many people to publish their changes. If we want to collect those changes we have to make it as easy as possible for people to contribute and for many people a github pull request is the easiest way to do that. Working with SF is only slightly more effort, but we have to aim for the minimum. At the least we should have a github mirror that people can raise pull requests against. But if we do that then the SF repo is just extra effort. Simon |
From: Uwe B. <ou...@ma...> - 2016-02-08 11:24:46
|
>>> "dl" == dl <fri...@ho...> writes: > guys, i think we're not understanding each other, even after the Ok let us try to sort this out then. Recall the starting point was when Eric asked for help to apply some patches (I recall 2 but there might be more). I answered saying that I almost forgot what I ever knew about CVS and whether we could switch to a DVCS like git or hg. So we had a discussion and a vote and git won, so far so good. It is true that some people, among them, developers of other emacs-matlab versions expressed their interest to switch to github, however what I did not realise at that point, was that we did not discuss of how to export the mailing list (and maybe other stuff like issues etc, but I believe there is besides the mailing list nothing really interesting, if there is, please speak up). So I think it is best to discuss this issue now, and may be vote again. - I ask: if we use a DVCS, like git, then the very nature of it is as follows: people can clone the repo add their code, apply patches, merge etc and then push it back. This is a *decentralised* program, this is the beauty of it, no central server needed as in CVS or subversion. So once we have decided for git, I don't see any difference between sourceforge/github/bitbucket etc, save the graphical interface. Does everybody agree with that? A CVCS makes the question of the server less important, no? Or does github has some shiny wonderful feature I oversee? - how important is the mailing list and its archive to people on this list? I admit for me it is quite important and that is why I argue for staying in sourceforge but switching to git. What do other people think? Regards Uwe Brauer |
From: dl <fri...@ho...> - 2016-02-07 11:26:39
|
guys, i think we're not understanding each other, even after the democratic process, and the github developers views being presented (one was active and motivated to develop, the other said he can take pull requests --- do we have any active developer in sourceforge or do we have anyone taking pull requests here? if we convert to git and keep it in sourceforge, the only difference is that developers are gonna clone the git repo directly and push it to github. thus in practice nothing is solved as they are not going to do pull requests to sourceforge. and even if they did nobody would review or accept them (i might be wrong). (1) mailing list import there's no mailing list in github, so its not possible to import it. if we move to github, we either keep the mailing list here, or we just use the github facilities such as issues with tags/labels, as other projects use. for example on the spacemacs project, if u want to search for questions in the issues: https://github.com/syl20bnr/spacemacs/issues?utf8=%E2%9C%93&q=label%3Aquestion of course, we would not be able to consult the old mailing list this way, and i dont think it would be easy to convert it to this format. then we would have to reference the old mailing list. (2) issues regarding bugs, feature requests etc, i think i could do manually as they're only a bit more than 20 in total (all of them are several years old and probably not very usefull). (3) conclusions github was the chosen option by the developers and mailing list subscribers. i think the easiest way would be to keep the mailing list in sourceforge. put a link to the new github repo in the sourceforge. it should be very easy to keep sourceforge and github synchronized if needed. personally i will keep using some github version of matlab-mode, either official or not. if at some point it exceeds dramatically the sourceforge version, i would probably pull request melpa to use the github version to help other users. thats all from me, im leaving this threat. let me know if help is needed after a plan of action is ready. cheers d On Fri, Feb 5, 2016 at 12:04 PM, Uwe Brauer <ou...@ma...> wrote: > >>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I can add a git repo to the project, but we'd have to translate the > > content over ourselves. (As far as I know anyway) > > > Eric > > > I just got a reply from the SF team, and yes we do have to convert the > repo ourselves. > > As I said I did this using git --cvsimport successfully. > So that problem is solved. > > > Please github users: is it possible to import a SF account with the > mailing list and issues etc???? > > If not I propose we stay in SF and switch to git. > > I propose to wait till Monday before taking any actions. > > Comments? > > Uwe Brauer > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > > |
From: Cayetano S. <cay...@in...> - 2016-02-05 13:11:17
|
On 05-02-16 11:04:36, Uwe Brauer wrote: >>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I can add a git repo to the project, but we'd have to translate the > > content over ourselves. (As far as I know anyway) > > > Eric > > >I just got a reply from the SF team, and yes we do have to convert the >repo ourselves. > >As I said I did this using git --cvsimport successfully. >So that problem is solved. > > >Please github users: is it possible to import a SF account with the >mailing list and issues etc???? > >If not I propose we stay in SF and switch to git. > >I propose to wait till Monday before taking any actions. > >Comments? As far as I know, it's not. Now, once we decide to move to GitHub, is it really that necessary to keep the old mailing list ? I mean we can track in GitHub issues, announces, releases, etc, similar to the way other huge projects are doing. The old mailing list would be kept as a read-only reference on SF. -- Cayetano Santos >Uwe Brauer > >------------------------------------------------------------------------------ >Site24x7 APM Insight: Get Deep Visibility into Application Performance >APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >Monitor end-to-end web transactions and take corrective actions now >Troubleshoot faster and improve end-user experience. Signup Now! >http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >_______________________________________________ >Matlab-emacs-discuss mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Uwe B. <ou...@ma...> - 2016-02-05 11:04:46
|
>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > I can add a git repo to the project, but we'd have to translate the > content over ourselves. (As far as I know anyway) > Eric I just got a reply from the SF team, and yes we do have to convert the repo ourselves. As I said I did this using git --cvsimport successfully. So that problem is solved. Please github users: is it possible to import a SF account with the mailing list and issues etc???? If not I propose we stay in SF and switch to git. I propose to wait till Monday before taking any actions. Comments? Uwe Brauer |
From: Eric L. <Eri...@ma...> - 2016-02-04 19:58:17
|
I can add a git repo to the project, but we'd have to translate the content over ourselves. (As far as I know anyway) Eric -----Original Message----- From: Uwe Brauer [mailto:ou...@ma...] Sent: Thursday, February 04, 2016 10:29 AM To: matlab-emacs <mat...@li...> Subject: [Matlab-emacs-discuss] sourceforge github Hi I just wrote the sourceforge team to see whether it would be possible to convert the account from CVS to git. (And so save the mailing list archive) If somebody knows how to export/convert a sourceforge account to github, transferring the mailing list archive, please speak up. Regards Uwe Brauer ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Matlab-emacs-discuss mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Uwe B. <ou...@ma...> - 2016-02-04 15:28:44
|
Hi I just wrote the sourceforge team to see whether it would be possible to convert the account from CVS to git. (And so save the mailing list archive) If somebody knows how to export/convert a sourceforge account to github, transferring the mailing list archive, please speak up. Regards Uwe Brauer |
From: Uwe B. <ou...@ma...> - 2016-02-04 15:26:31
|
>>> "dl" == dl <fri...@ho...> writes: > uwe, have a look at this: > https://github.com/milkypostman/melpa/blob/ > b9faeb6d910d686cbcafe7d12e0bcf62a85689bd/recipes/matlab-mode > (matlab-mode > :fetcher cvs > :url ":pserver:ano...@ma...:/cvsroot/ > matlab-emacs" > :module "matlab-emacs" > :files ("*.el" "*.m" ("toolbox" "toolbox/*.m") ("templates" > "templates/*.srt"))) Thanks! I did not know about it and I even see that I was using 3.3.1 while the mpla version is 3.3.2, which contains new stuff, but not the patch I talked about and started this whole thread. Once we have decided and most likely moved to github, I will try to apply the patch which is a patch to 3.3.1, so some merging should be done. |
From: Dennis O. <do...@pu...> - 2016-02-04 13:49:26
|
I think moving to github would be a good idea. I'm excited to see that there still exists an active community around this package! On February 3, 2016 12:24:26 PM EST, Uwe Brauer <ou...@ma...> wrote: >>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I am not opposed to a move to some other DVCS. I just don't do much > > development anymore, and I don't really get time at work to work on > > this sort of thing anymore. > >> If those active on this list would like to do a move, I can >facilitate > > access, setup a new maintainer on SF, and will always be happy to > > research things from the MATLAB side to help out when I can. > >What do other people think? > >There are three options as far as I can see: > > 1 leave things as they are > > 2 stay in sourceforge but convert to git/HG > > 3 move to a different server (bitbucket (HG)[1]) or githug (git). > > >So please hands up: 1 or 2 or 3? > > >> In any move, a thing to watch out for is that in the past, many users > > don't have access to a CVS program, or any other VC software, so the > > special matlab download script was created to enable that. Changes > > have been small and few, so full releases were not worthwhile to do. > > >I am not sure I understand: github and bitbucket offer the possibility >to download the package as a zip without using git or hg. Are you >saying >that sourceforge does not offer that but requires a script which where >not provided by sourceforge? So in the case of a move that script I >think is provided by bitbucket or github. > >BTW, I mentioned the possibility to generate a MELPA packet for matlab >(it cannot be ELPA because of copyright issues). This would simplify >the >installation for the GNU emacs users, but leave xemacs out.[2] a MELPA >packet should dwell in github. > >Uwe > > > Eric > >Footnotes: >[1] bitbucket also supports git but I have the feeling that once the > decision is for git, github seems the preferred choice. > >[2] xemacs pkg system is right now in zombie state, all new packages > are in the pre-release state. > > >------------------------------------------------------------------------------ >Site24x7 APM Insight: Get Deep Visibility into Application Performance >APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >Monitor end-to-end web transactions and take corrective actions now >Troubleshoot faster and improve end-user experience. Signup Now! >http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >_______________________________________________ >Matlab-emacs-discuss mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: dl <fri...@ho...> - 2016-02-04 11:14:34
|
uwe, have a look at this: https://github.com/milkypostman/melpa/blob/b9faeb6d910d686cbcafe7d12e0bcf62a85689bd/recipes/matlab-mode (matlab-mode :fetcher cvs :url ":pserver:ano...@ma...: /cvsroot/matlab-emacs" :module "matlab-emacs" :files ("*.el" "*.m" ("toolbox" "toolbox/*.m") ("templates" "templates/*.srt"))) On Thu, Feb 4, 2016 at 11:30 AM, Uwe Brauer <ou...@ma...> wrote: > >>> "dl" == dl <fri...@ho...> writes: > > > i vote 3, github > > from usage, and never looking at code, Andrzej's matlab-mode works > > very well. and he took the cvs code in march 2015 > > > Uwe, there is already matlab-mode package in melpa, which points to > > the cvs repo. personally i use andrzej's version though > > > Oops did not see it. I will have to look again. > > > I am not sure what you mean by points to the CVS repo. It is a mirror? > > Uwe > > |
From: Uwe B. <ou...@ma...> - 2016-02-04 10:42:49
|
Hi I open a new thread for better readability. Till now if I did not miscount, the vote is Hg 1 Git 4 (3 for github) Very well then. It seems clear that people are inclined to git, and to github in particular, in addition Eric has told us that he is a bit familiar with git but not with hg. So git seems the way to go. I meanwhile was successful in converting the original CVS to git. (I had converted CVS to HG, and then with 2 converters (hg-git and hg-fast-export) converted them to git, but I'd prefer the direct import via git --cvsimport. Nevertheless I think we should wait a couple of days more. However there is one thing that worries me: the archive for the mailing list. There seems two possibilities - Export it to github, however I don't know how to do that, anybody has an idea? - if this is not possible and the mailing list is important to people we could stay in sourceforge, if we manage to convert CVS to git. Sourceforge requires now for *new* repos to chose some modern system such as git or hg. But again I did not find any documentation for converting an existing repo, if somebody has an idea.... Uwe Brauer |
From: Uwe B. <ou...@ma...> - 2016-02-04 10:30:15
|
>>> "dl" == dl <fri...@ho...> writes: > i vote 3, github > from usage, and never looking at code, Andrzej's matlab-mode works > very well. and he took the cvs code in march 2015 > Uwe, there is already matlab-mode package in melpa, which points to > the cvs repo. personally i use andrzej's version though Oops did not see it. I will have to look again. I am not sure what you mean by points to the CVS repo. It is a mirror? Uwe |
From: Torben K. <tk...@es...> - 2016-02-04 06:06:56
|
Dear all I have no idea what is best. I just appreciate that there are people out there that does a good job so I can enjoy matlab-mode. Thanks a lot. Associate Prof. Ph.D Torben Knudsen Mobile : (+45) 2787 9826 Section of Automation and Control, Department of Electronic Systems, Email : tk...@es... Aalborg University Web : es.aau.dk/staff/tk Fredrik Bajersvej 7 DK-9220 Aalborg Ø Denmark ________________________________ Fra: Qi Sun [qis...@gm...] Sendt: 4. februar 2016 00:58 Til: Uwe Brauer Cc: matlab-emacs; Eric Ludlam Emne: Re: [Matlab-emacs-discuss] execute matlab in a different directory. GNU vs Xemacs Thanks for the vote options and I strongly prefer github! On Wednesday, February 3, 2016, Uwe Brauer <ou...@ma...<mailto:ou...@ma...>> wrote: >>> "Eric" == Eric Ludlam <Eri...@ma...<UrlBlockedError.aspx>> writes: > I am not opposed to a move to some other DVCS. I just don't do much > development anymore, and I don't really get time at work to work on > this sort of thing anymore. > If those active on this list would like to do a move, I can facilitate > access, setup a new maintainer on SF, and will always be happy to > research things from the MATLAB side to help out when I can. What do other people think? There are three options as far as I can see: 1 leave things as they are 2 stay in sourceforge but convert to git/HG 3 move to a different server (bitbucket (HG)[1]) or githug (git). So please hands up: 1 or 2 or 3? > In any move, a thing to watch out for is that in the past, many users > don't have access to a CVS program, or any other VC software, so the > special matlab download script was created to enable that. Changes > have been small and few, so full releases were not worthwhile to do. I am not sure I understand: github and bitbucket offer the possibility to download the package as a zip without using git or hg. Are you saying that sourceforge does not offer that but requires a script which where not provided by sourceforge? So in the case of a move that script I think is provided by bitbucket or github. BTW, I mentioned the possibility to generate a MELPA packet for matlab (it cannot be ELPA because of copyright issues). This would simplify the installation for the GNU emacs users, but leave xemacs out.[2] a MELPA packet should dwell in github. Uwe > Eric Footnotes: [1] bitbucket also supports git but I have the feeling that once the decision is for git, github seems the preferred choice. [2] xemacs pkg system is right now in zombie state, all new packages are in the pre-release state. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Matlab-emacs-discuss mailing list Mat...@li...<UrlBlockedError.aspx> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Qi S. <qis...@gm...> - 2016-02-03 23:59:06
|
Thanks for the vote options and I strongly prefer github! On Wednesday, February 3, 2016, Uwe Brauer <ou...@ma...> wrote: > >>> "Eric" == Eric Ludlam <Eri...@ma... <javascript:;>> > writes: > > > I am not opposed to a move to some other DVCS. I just don't do much > > development anymore, and I don't really get time at work to work on > > this sort of thing anymore. > > > If those active on this list would like to do a move, I can facilitate > > access, setup a new maintainer on SF, and will always be happy to > > research things from the MATLAB side to help out when I can. > > What do other people think? > > There are three options as far as I can see: > > 1 leave things as they are > > 2 stay in sourceforge but convert to git/HG > > 3 move to a different server (bitbucket (HG)[1]) or githug (git). > > > So please hands up: 1 or 2 or 3? > > > > In any move, a thing to watch out for is that in the past, many users > > don't have access to a CVS program, or any other VC software, so the > > special matlab download script was created to enable that. Changes > > have been small and few, so full releases were not worthwhile to do. > > > I am not sure I understand: github and bitbucket offer the possibility > to download the package as a zip without using git or hg. Are you saying > that sourceforge does not offer that but requires a script which where > not provided by sourceforge? So in the case of a move that script I > think is provided by bitbucket or github. > > BTW, I mentioned the possibility to generate a MELPA packet for matlab > (it cannot be ELPA because of copyright issues). This would simplify the > installation for the GNU emacs users, but leave xemacs out.[2] a MELPA > packet should dwell in github. > > Uwe > > > Eric > > Footnotes: > [1] bitbucket also supports git but I have the feeling that once the > decision is for git, github seems the preferred choice. > > [2] xemacs pkg system is right now in zombie state, all new packages > are in the pre-release state. > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... <javascript:;> > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss > |
From: Cayetano S. <csa...@in...> - 2016-02-03 22:08:00
|
On 03-02-16 17:24:26, Uwe Brauer wrote: >>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I am not opposed to a move to some other DVCS. I just don't do much > > development anymore, and I don't really get time at work to work on > > this sort of thing anymore. > > > If those active on this list would like to do a move, I can facilitate > > access, setup a new maintainer on SF, and will always be happy to > > research things from the MATLAB side to help out when I can. > >What do other people think? > >There are three options as far as I can see: > > 1 leave things as they are > > 2 stay in sourceforge but convert to git/HG > > 3 move to a different server (bitbucket (HG)[1]) or githug (git). > > >So please hands up: 1 or 2 or 3? I vote 3, github, or any other git based > > In any move, a thing to watch out for is that in the past, many users > > don't have access to a CVS program, or any other VC software, so the > > special matlab download script was created to enable that. Changes > > have been small and few, so full releases were not worthwhile to do. > > >I am not sure I understand: github and bitbucket offer the possibility >to download the package as a zip without using git or hg. Are you saying >that sourceforge does not offer that but requires a script which where >not provided by sourceforge? So in the case of a move that script I >think is provided by bitbucket or github. > >BTW, I mentioned the possibility to generate a MELPA packet for matlab >(it cannot be ELPA because of copyright issues). This would simplify the >installation for the GNU emacs users, but leave xemacs out.[2] a MELPA >packet should dwell in github. > >Uwe > > > Eric > >Footnotes: >[1] bitbucket also supports git but I have the feeling that once the > decision is for git, github seems the preferred choice. > >[2] xemacs pkg system is right now in zombie state, all new packages > are in the pre-release state. > > >------------------------------------------------------------------------------ >Site24x7 APM Insight: Get Deep Visibility into Application Performance >APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >Monitor end-to-end web transactions and take corrective actions now >Troubleshoot faster and improve end-user experience. Signup Now! >http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >_______________________________________________ >Matlab-emacs-discuss mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |
From: Honglin Yu <yuh...@gm...> - 2016-02-03 22:06:38
|
Hi all, Thanks for letting me join the discussion The workflow of my piece of code is that: 1. First, emacs create a socket server 2. when it needs to do something (e.g. completion, lint), "lock" the output of terminal and run corresponding matlab code in toolbox folder. 3. the matlab code will send the information to emacs socket server, with a special ending code appended. 4. After detecting the ending code, emacs processed the collected data and do the job (e.g. completion, link) 5. "unlock" the output of terminal The "locking" of output of terminal is done in the filter function comint (just throw away anything). And before run any matlab code, it needs to check if the running program in terminal is ready (copied from original matlab-mode). Except making a "modern" matlab-mode, I think maybe we can make one step further: many language mode needs to communicate with the terminal. Can we make a general package with a robust protocol doing this? Based on the communication server, we can add flycheck, completions etc. And all the things a person needs to do for a new language is add "toolbox code" for each language? Cheers, Honglin 2016-02-04 4:24 GMT+11:00 Andrzej Pronobis <a.p...@gm...>: > Hi, > > Thanks for letting me know about this discussion. > > My original goal was to "modernize" the matlab-mode a bit by adding > compatibility with new popular packages and some fixes. Were the original > mode on github, I would have simply made a pull request afterwards. I've > made the following changes (as listed in the github readme): > - New company-matlab.el backend that works both inside the Matlab shell > and in Matlab files > - New flycheck-mlint back-end for flycheck which uses mlint to highlight > warnings in Matlab files. > - Fixed additional newlines and incorrect formatting of prompt after > completion > - Fixed version parsing for new Matlab versions > - Re-enabled HTML parsing > > In the current situation I suggest one of the following options: > - Creating a new repo on github and merging my changes there > - Using my repo as a starting point and moving forward from there, I'm not > going to do much development myself anymore, but can take pull requests. > > In general, since I don't know what the current situation of the original > matlab-mode is, I'll let you guys decide and say that I'm fine with > anything that moves matlab-mode to github (to facilitate future > development) and brings in the features I added. > > Best, > Andrzej > > > On Wed, Feb 3, 2016 at 8:43 AM dl <fri...@ho...> wrote: > >> i added the independent matlab-mode github contributers to this mail. >> maybe they read it. >> >> just to make myself clear. Im not saying we (or they) should merge their >> packages, although that would be good. what i meant is: >> >> if the official project was in github originally, these people would have >> just branched the original repo, and possibly suggested pull requests to >> the official project. if Eric can't work on it, its ok, other people might >> work on it. >> >> thus if it is to start anew, i would say better do it in github to >> facilitate these sporadic developers that we known are using github to >> contribute their work. >> >> ps to uwe: >> company-mode is an autocompletion framework. its very good when it works >> >> On Wed, Feb 3, 2016 at 3:35 PM, Uwe Brauer <ou...@ma...> wrote: >> >>> >>> "dl" == dl <fri...@ho...> writes: >>> >>> > since this conversation is now active, i would just like to comment >>> > that the following repo in github, https://github.com/pronobis/ >>> > matlab-mode (not sure the owner is in this list) provides a modified >>> > matlab-mode with very good company-mode support. As an emacs newbie >>> > (~ 2 years of use and no elisp skills) that was easier to setup with >>> > autocompletion than the original cvs matlab-mode. >>> >>> > besides there's at least one other modified version of matlab-mode >>> in >>> > github, https://github.com/yuhonglin/matlab-mode, which i havent >>> > tried, but its worked out company-mode and matlab documentation >>> > support according to the description. >>> >>> >>> I checked them both (they use the same name matlab-mode, which makes >>> cloning fun) >>> >>> The first one had his last entry Jul 24: >>> >>> ,---- >>> | >>> | commit dfd935346f6fd204b132f9b0b1d048308d77ef72 >>> | Author: Andrzej Pronobis <a.p...@gm...> >>> | Date: Fri Jul 24 13:52:46 2015 -0700 >>> | >>> | Fixed error when no matlab found. >>> `---- >>> >>> And a lot of entries Mar 19, most likely the day he made the >>> immigration. Just of these entries reads as: >>> ,---- >>> | commit 8618a2b530a23df54751d6e4a5ba3d7c8cbda824 >>> | Author: Andrzej Pronobis <a.p...@gm...> >>> | Date: Thu Mar 19 21:00:24 2015 -0700 >>> | >>> | Readme >>> `---- >>> >>> The other are similar, before that >>> ,---- >>> | commit f7594986a685882bbe856b99be1cb4ea1eab91a6 >>> | Author: Eric M. Ludlam <> >>> | Date: Sat Dec 27 12:44:52 2014 +0000 >>> `---- >>> >>> So it does not look like a very active development. >>> >>> Yuhonglin is more active: >>> Last commit: >>> >>> ,---- >>> | commit b9bf51f54539293fef843721852d4b5bb4210e74 >>> | Author: Honglin Yu <yuh...@gm...> >>> | Date: Tue Dec 1 15:32:53 2015 +1100 >>> | >>> | fix bug in jtd-matlab-process-received-data >>> | >>> | In determining whether rawreturn ends with '.m', should not >>> | just compare result of s-shared-end and empty string. Since >>> | if the rawreturn ends with 'm' but not '.m', it will not "". >>> `---- >>> but his mode seems quite a bit different. >>> >>> So I think it would be best to ask the authors, >>> >>> - what there fork is about (which are the new features) >>> >>> - whether they are willing to merge back (if that is possible) >>> >>> Uwe Brauer >>> >>> >> |
From: dl <fri...@ho...> - 2016-02-03 19:16:10
|
i vote 3, github from usage, and never looking at code, Andrzej's matlab-mode works very well. and he took the cvs code in march 2015 Uwe, there is already matlab-mode package in melpa, which points to the cvs repo. personally i use andrzej's version though d On Wed, Feb 3, 2016 at 6:24 PM, Uwe Brauer <ou...@ma...> wrote: > >>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I am not opposed to a move to some other DVCS. I just don't do much > > development anymore, and I don't really get time at work to work on > > this sort of thing anymore. > > > If those active on this list would like to do a move, I can facilitate > > access, setup a new maintainer on SF, and will always be happy to > > research things from the MATLAB side to help out when I can. > > What do other people think? > > There are three options as far as I can see: > > 1 leave things as they are > > 2 stay in sourceforge but convert to git/HG > > 3 move to a different server (bitbucket (HG)[1]) or githug (git). > > > So please hands up: 1 or 2 or 3? > > > > In any move, a thing to watch out for is that in the past, many users > > don't have access to a CVS program, or any other VC software, so the > > special matlab download script was created to enable that. Changes > > have been small and few, so full releases were not worthwhile to do. > > > I am not sure I understand: github and bitbucket offer the possibility > to download the package as a zip without using git or hg. Are you saying > that sourceforge does not offer that but requires a script which where > not provided by sourceforge? So in the case of a move that script I > think is provided by bitbucket or github. > > BTW, I mentioned the possibility to generate a MELPA packet for matlab > (it cannot be ELPA because of copyright issues). This would simplify the > installation for the GNU emacs users, but leave xemacs out.[2] a MELPA > packet should dwell in github. > > Uwe > > > Eric > > Footnotes: > [1] bitbucket also supports git but I have the feeling that once the > decision is for git, github seems the preferred choice. > > [2] xemacs pkg system is right now in zombie state, all new packages > are in the pre-release state. > > > |
From: L. L. S. <st...@um...> - 2016-02-03 19:07:00
|
Don't count my vote for much, I just use and lurk... But github is such a standard these days. But any approach is fine if advertised. Larrabee Uwe Brauer writes: >>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > > > I am not opposed to a move to some other DVCS. I just don't do much > > development anymore, and I don't really get time at work to work on > > this sort of thing anymore. > > > If those active on this list would like to do a move, I can facilitate > > access, setup a new maintainer on SF, and will always be happy to > > research things from the MATLAB side to help out when I can. > > What do other people think? > > There are three options as far as I can see: > > 1 leave things as they are > > 2 stay in sourceforge but convert to git/HG > > 3 move to a different server (bitbucket (HG)[1]) or githug (git). > > > So please hands up: 1 or 2 or 3? > > > > In any move, a thing to watch out for is that in the past, many users > > don't have access to a CVS program, or any other VC software, so the > > special matlab download script was created to enable that. Changes > > have been small and few, so full releases were not worthwhile to do. > > > I am not sure I understand: github and bitbucket offer the possibility > to download the package as a zip without using git or hg. Are you saying > that sourceforge does not offer that but requires a script which where > not provided by sourceforge? So in the case of a move that script I > think is provided by bitbucket or github. > > BTW, I mentioned the possibility to generate a MELPA packet for matlab > (it cannot be ELPA because of copyright issues). This would simplify the > installation for the GNU emacs users, but leave xemacs out.[2] a MELPA > packet should dwell in github. > > Uwe > > > Eric > > Footnotes: > [1] bitbucket also supports git but I have the feeling that once the > decision is for git, github seems the preferred choice. > > [2] xemacs pkg system is right now in zombie state, all new packages > are in the pre-release state. > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Matlab-emacs-discuss mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss -- L. Larrabee Strow UMBC Physics Department Email: st...@um... Cell: 724-288-6933 |
From: Andrzej P. <a.p...@gm...> - 2016-02-03 17:24:37
|
Hi, Thanks for letting me know about this discussion. My original goal was to "modernize" the matlab-mode a bit by adding compatibility with new popular packages and some fixes. Were the original mode on github, I would have simply made a pull request afterwards. I've made the following changes (as listed in the github readme): - New company-matlab.el backend that works both inside the Matlab shell and in Matlab files - New flycheck-mlint back-end for flycheck which uses mlint to highlight warnings in Matlab files. - Fixed additional newlines and incorrect formatting of prompt after completion - Fixed version parsing for new Matlab versions - Re-enabled HTML parsing In the current situation I suggest one of the following options: - Creating a new repo on github and merging my changes there - Using my repo as a starting point and moving forward from there, I'm not going to do much development myself anymore, but can take pull requests. In general, since I don't know what the current situation of the original matlab-mode is, I'll let you guys decide and say that I'm fine with anything that moves matlab-mode to github (to facilitate future development) and brings in the features I added. Best, Andrzej On Wed, Feb 3, 2016 at 8:43 AM dl <fri...@ho...> wrote: > i added the independent matlab-mode github contributers to this mail. > maybe they read it. > > just to make myself clear. Im not saying we (or they) should merge their > packages, although that would be good. what i meant is: > > if the official project was in github originally, these people would have > just branched the original repo, and possibly suggested pull requests to > the official project. if Eric can't work on it, its ok, other people might > work on it. > > thus if it is to start anew, i would say better do it in github to > facilitate these sporadic developers that we known are using github to > contribute their work. > > ps to uwe: > company-mode is an autocompletion framework. its very good when it works > > On Wed, Feb 3, 2016 at 3:35 PM, Uwe Brauer <ou...@ma...> wrote: > >> >>> "dl" == dl <fri...@ho...> writes: >> >> > since this conversation is now active, i would just like to comment >> > that the following repo in github, https://github.com/pronobis/ >> > matlab-mode (not sure the owner is in this list) provides a modified >> > matlab-mode with very good company-mode support. As an emacs newbie >> > (~ 2 years of use and no elisp skills) that was easier to setup with >> > autocompletion than the original cvs matlab-mode. >> >> > besides there's at least one other modified version of matlab-mode in >> > github, https://github.com/yuhonglin/matlab-mode, which i havent >> > tried, but its worked out company-mode and matlab documentation >> > support according to the description. >> >> >> I checked them both (they use the same name matlab-mode, which makes >> cloning fun) >> >> The first one had his last entry Jul 24: >> >> ,---- >> | >> | commit dfd935346f6fd204b132f9b0b1d048308d77ef72 >> | Author: Andrzej Pronobis <a.p...@gm...> >> | Date: Fri Jul 24 13:52:46 2015 -0700 >> | >> | Fixed error when no matlab found. >> `---- >> >> And a lot of entries Mar 19, most likely the day he made the >> immigration. Just of these entries reads as: >> ,---- >> | commit 8618a2b530a23df54751d6e4a5ba3d7c8cbda824 >> | Author: Andrzej Pronobis <a.p...@gm...> >> | Date: Thu Mar 19 21:00:24 2015 -0700 >> | >> | Readme >> `---- >> >> The other are similar, before that >> ,---- >> | commit f7594986a685882bbe856b99be1cb4ea1eab91a6 >> | Author: Eric M. Ludlam <> >> | Date: Sat Dec 27 12:44:52 2014 +0000 >> `---- >> >> So it does not look like a very active development. >> >> Yuhonglin is more active: >> Last commit: >> >> ,---- >> | commit b9bf51f54539293fef843721852d4b5bb4210e74 >> | Author: Honglin Yu <yuh...@gm...> >> | Date: Tue Dec 1 15:32:53 2015 +1100 >> | >> | fix bug in jtd-matlab-process-received-data >> | >> | In determining whether rawreturn ends with '.m', should not >> | just compare result of s-shared-end and empty string. Since >> | if the rawreturn ends with 'm' but not '.m', it will not "". >> `---- >> but his mode seems quite a bit different. >> >> So I think it would be best to ask the authors, >> >> - what there fork is about (which are the new features) >> >> - whether they are willing to merge back (if that is possible) >> >> Uwe Brauer >> >> > |
From: Uwe B. <ou...@ma...> - 2016-02-03 17:24:37
|
>>> "Eric" == Eric Ludlam <Eri...@ma...> writes: > I am not opposed to a move to some other DVCS. I just don't do much > development anymore, and I don't really get time at work to work on > this sort of thing anymore. > If those active on this list would like to do a move, I can facilitate > access, setup a new maintainer on SF, and will always be happy to > research things from the MATLAB side to help out when I can. What do other people think? There are three options as far as I can see: 1 leave things as they are 2 stay in sourceforge but convert to git/HG 3 move to a different server (bitbucket (HG)[1]) or githug (git). So please hands up: 1 or 2 or 3? > In any move, a thing to watch out for is that in the past, many users > don't have access to a CVS program, or any other VC software, so the > special matlab download script was created to enable that. Changes > have been small and few, so full releases were not worthwhile to do. I am not sure I understand: github and bitbucket offer the possibility to download the package as a zip without using git or hg. Are you saying that sourceforge does not offer that but requires a script which where not provided by sourceforge? So in the case of a move that script I think is provided by bitbucket or github. BTW, I mentioned the possibility to generate a MELPA packet for matlab (it cannot be ELPA because of copyright issues). This would simplify the installation for the GNU emacs users, but leave xemacs out.[2] a MELPA packet should dwell in github. Uwe > Eric Footnotes: [1] bitbucket also supports git but I have the feeling that once the decision is for git, github seems the preferred choice. [2] xemacs pkg system is right now in zombie state, all new packages are in the pre-release state. |
From: dl <fri...@ho...> - 2016-02-03 16:43:19
|
i added the independent matlab-mode github contributers to this mail. maybe they read it. just to make myself clear. Im not saying we (or they) should merge their packages, although that would be good. what i meant is: if the official project was in github originally, these people would have just branched the original repo, and possibly suggested pull requests to the official project. if Eric can't work on it, its ok, other people might work on it. thus if it is to start anew, i would say better do it in github to facilitate these sporadic developers that we known are using github to contribute their work. ps to uwe: company-mode is an autocompletion framework. its very good when it works On Wed, Feb 3, 2016 at 3:35 PM, Uwe Brauer <ou...@ma...> wrote: > >>> "dl" == dl <fri...@ho...> writes: > > > since this conversation is now active, i would just like to comment > > that the following repo in github, https://github.com/pronobis/ > > matlab-mode (not sure the owner is in this list) provides a modified > > matlab-mode with very good company-mode support. As an emacs newbie > > (~ 2 years of use and no elisp skills) that was easier to setup with > > autocompletion than the original cvs matlab-mode. > > > besides there's at least one other modified version of matlab-mode in > > github, https://github.com/yuhonglin/matlab-mode, which i havent > > tried, but its worked out company-mode and matlab documentation > > support according to the description. > > > I checked them both (they use the same name matlab-mode, which makes > cloning fun) > > The first one had his last entry Jul 24: > > ,---- > | > | commit dfd935346f6fd204b132f9b0b1d048308d77ef72 > | Author: Andrzej Pronobis <a.p...@gm...> > | Date: Fri Jul 24 13:52:46 2015 -0700 > | > | Fixed error when no matlab found. > `---- > > And a lot of entries Mar 19, most likely the day he made the > immigration. Just of these entries reads as: > ,---- > | commit 8618a2b530a23df54751d6e4a5ba3d7c8cbda824 > | Author: Andrzej Pronobis <a.p...@gm...> > | Date: Thu Mar 19 21:00:24 2015 -0700 > | > | Readme > `---- > > The other are similar, before that > ,---- > | commit f7594986a685882bbe856b99be1cb4ea1eab91a6 > | Author: Eric M. Ludlam <> > | Date: Sat Dec 27 12:44:52 2014 +0000 > `---- > > So it does not look like a very active development. > > Yuhonglin is more active: > Last commit: > > ,---- > | commit b9bf51f54539293fef843721852d4b5bb4210e74 > | Author: Honglin Yu <yuh...@gm...> > | Date: Tue Dec 1 15:32:53 2015 +1100 > | > | fix bug in jtd-matlab-process-received-data > | > | In determining whether rawreturn ends with '.m', should not > | just compare result of s-shared-end and empty string. Since > | if the rawreturn ends with 'm' but not '.m', it will not "". > `---- > but his mode seems quite a bit different. > > So I think it would be best to ask the authors, > > - what there fork is about (which are the new features) > > - whether they are willing to merge back (if that is possible) > > Uwe Brauer > > |