I would like to edit matlab scripts in two cases
(1) In matlab Command window running in a linux terminal, how to create and edit a script file? use
edit(filename)
will invoke the interactive editor, which is not desired while operating on a linux server.
(2) In emacs, is there any way to edit matlab script conveniently? Which is better, using MATLAB-Emacs or EmacsLink?
when I am trying to cvs checkout MATLAB-Emacs from http://sourceforge.net/scm/?type=cvs&group_id=154105, which modulename should I specify?
Thanks!
EDIT:
When installing MATLAB-emacs, there is some problem. I thought my CEDET is installed here:
/usr/share/emacs22/site-lisp/cedet-common
/usr/share/emacs22/site-lisp/cedet-contrib
My CEDET is of version 1:1.0pre4-3 （intrepid) on Ubuntu. So I type the command:
$ make "LOADPATH=/usr/share/doc/cedet-common /usr/share/doc/cedet-contrib"
for loadpath in . /usr/share/doc/cedet-common /usr/share/doc/cedet-contrib; do \
echo "(add-to-list 'load-path \"$loadpath\")" >> autoloads-compile-script; \
done;
"emacs" -batch --no-site-file -l autoloads-compile-script -f cedet-batch-update-autoloads matlab-load.el .
Generatim autoloads for cedet-matlab.el...
Generatim autoloads for cedet-matlab.el...done
Generatim autoloads for matlab.el...
Generatim autoloads for matlab.el...done
Generatim autoloads for mlint.el...
Generatim autoloads for mlint.el...done
Generatim autoloads for semantic-matlab.el...
Generatim autoloads for semantic-matlab.el...done
Generatim autoloads for tlc.el...
Generatim autoloads for tlc.el...done
Generatim autoloads for semanticdb-matlab.el...
Generatim autoloads for semanticdb-matlab.el...done
Updatim header...
Updatim header...done
Wrote /home/tim/.emacs.d/matlab-emacs/matlab-load.el
make: *** No rule to make target `matlab-publish.el', needed by `lisp'. Stop.
What's wrong? Thanks!
You should be aware that starting with version R2009a EmacsLink has been removed from Matlab, so I would say that at this point Matlab-Emacs is a better alternative. The main strength of EmacsLink was tighter and integration with Matlab, especially when using the debugger, but current version of Matlab-Emacs is quite capable and will probably satisfy most people's needs just as well as EmacsLink.
In order to invoke Emacs from Matlab, the cleanest solution is to run the Emacs server (M-x server-start). The edit() command can then be set up to open the script in Emacs. The detailed instructions on how to do this, as well as on running matlab-shell as inferior process are provided here:
http://blogs.mathworks.com/desktop/2009/09/14/matlab-emacs-integration-is-back/
Regarding CVS checkout: modulename is "matlab-emacs". You used to be able to download an archive and simply unpack into your elisp directory.
EDIT: I decided to reinstall matlab-emacs; here is a step-by-step of what I did. (The steps are pretty obvious, but this might still be useful seeing how it's easy to run into a compilation error or to misinterpret some instructions). Note that matlab-emacs didn't compile until I reinstalled CEDET.
Download CEDET from http://cedet.sourceforge.net/ (1.0pre7 in my case)
Uncompress the archive into ~/.emacs.d/elisp/ (now have ~/.emacs.d/elisp/cedet-1.0pre7/ directory)
Compile CEDET via make EMACS=/usr/bin/emacs
While in ~/.emacs.d/elisp, do the cvs checkout:
cvs -z3 -d:pserver:anonymous#matlab-emacs.cvs.sourceforge.net:/cvsroot/matlab-emacs co -P matlab-emacs
Compile matlab-emacs via
make "LOADPATH=../cedet-1.0pre7/common ../cedet-1.0pre7/eieio ../cedet-1.0pre7/semantic/bovine/ ../cedet-1.0pre7/semantic/"
Ideally, everything should compile; now it's time to edit startup files: in the .emacs add
(setq load-path (cons "~/.emacs.d/elisp/matlab-emacs/" load-path))
(load-library "matlab-load")
and in matlab's startup.m add
addpath('~/.emacs.d/elisp/matlab-emacs/toolbox','-begin');
rehash;
emacsinit;
That should do it! Launch emacs, and do M-x matlab-shell. If edit foo.m doesn't open foo.m in emacs, make sure that the server has been launched (M-x server-start).
To be most productive, you might wish to figure out what works for you in terms of sending commands from the edit buffer to matlab process (experiment with the shortcuts in the mode help). Finally, if you need to debug stuff, do dbstop in foo, and when you run foo you can either use use dbstop family commands (look them up) or turn on toolbar (M-x tool-bar-mode) and use the buttons there to control breakpoints, stepping, continuing, etc. When finished, type dbquit.
Unfortunately, if you are on Windows, matlab-shell is not an option (which is a little surprising, seeing how I can run pretty much everything else under the sun from the command line -- Mathematica, R, numpy...) -- so your options for tight emacs/matlab integration are somewhat limited (unless you don't mind running an old matlab version that supports emacslink).
The matlab-emacs project at http://matlab-emacs.sourceforge.net/ is a slightly more up-to-date version of the Emacs scripts available in the EmacsLink directory that comes with MATLAB. It is OK to use the matlab-emacs project files with the EmacsLink files that comes with MATLAB.
The "modulename" is "matlab-emacs".
I made a blog post about how to use Emacs with MATLAB in more recent versions of MATLAB where the EmacsLink support was dropped. You can read it here:
http://blogs.mathworks.com/desktop/2009/09/14/matlab-emacs-integration-is-back/
The scripts here show how to tweak MATLAB to to use "emacsclient" so that files are pulled up in an already running Emacs.
EDIT:
The build system is a bit imperfect with a partial download. The fact that matlab-publish didn't compile is not critical.
The matlab-emacs code from CVS includes a toolbox directory with some M code in it. When you run that code, it should setup MATLAB to use emacsclient as the editor. I wrote emacsinit.m against the most recent MATLAB, so you may need to edit it with older MATLABs that don't support all features.
To run emacsclient from matlab-shell, the path should be setup automatically, and it should run emacsclient automatically. If you don't use matlab-shell, you will need to add that directory to your MATLAB path, then call emacsinit.
If it doesn't work for calls to edit, then I'd guess an older MATLAB doesn't have the same configuration features. You can start MATLAB once with the desktop enabled, and use the Preferences dialog to specify your external editor as emacsclient -n.
The reason that matlab-publish.el does not compile is because in fact it is not downloaded (thus missing) by the MATLAB script dl_emacs_support.m. I also find that the download script also did not download company-matlab-shell.el, which exists in the tarball from CVS. Consequently, when make is called, error occurs when the required files are not found.
Even worse, the dl_emacs_support.m script is replaced with the file from CVS when the source files are downloaded by executing the script in MATLAB. Patches or modifications to dl_emacs_support.m is thus lost after the files are downloaded.
To be safe, I recommend to download matlab-emacs from the tarball on the CVS server, or checkout the source. The compilation should go well then.
Remark about CEDET: I checked out CEDET source code and compile it with no sweat. If you are using Ubuntu, I believe the following packages in the repository should be installed before compiling matlab-emacs: cedet-common, ede, eieio, semantic, speedbar. These packages are installed to /usr/share/emacs/site-lisp, so the LOADPATH should be "/usr/share/emacs/site-lisp/cedet-common /usr/share/emacs/site-lisp/ede /usr/share/emacs/site-lisp/eieio /usr/share/emacs/site-lisp/semantic /usr/share/emacs/site-lisp/semantic/bovine".
Related
I'm trying to use Steel Bank Common Lisp with GVim.
I installed Steel Bank Common Lisp (AMD64) into 'C:\Program Files\Steel Bank Common Lisp'.
I unzipped SLIMV into 'C:\vimfiles'
I installed Python3 and put it in Windows PATH.
I installed Python 2.7 and put it in Windows PATH.
I installed 64-bit GVim and finally got Python recognized.
I ran ':helptags C:/vimfiles/doc' in Vim to generate help tags for SLIMV
I have a 'Slimv' menu at the top of the Vim window but no Repl menu.
g:slimv_lisp = sbcl
g:slimv_impl = sbcl
g:slimv_preferred not set
g:slimv_lisp not set
g:slimv_swank_cmd not set
Per webpages and manual, I put this in my vimrc file
let g:slimv_swank_cmd = '!start "c:\Program Files\Steel Bank Common Lisp\sbcl.exe" -l "c:\Users\epic\vimfiles\slime\start-swank.lisp"'
I don't know if that's supposed to be 'set' instead of 'let'.
(start_swank) doesn't do anything inside SBCL.
I assume '!start' is a Vim command, the first thing passed is the location of SBCL on my computer, don't know what the '-l' does, and the third parameter is where SLIMV put 'start-swank.lisp'.
At this point, the Vim command ',c' will open a command window running SBCL and wait. Typing '(exit)' in SBCL will take me back to Vim with a red error message saying 'SWANK server is not running, Press ENTER to continue."
Any other documentation I can find is for SLIME, not SLIMV.
How can I get SLIMV running so I can use Vim for SBCL?
EDIT:
Thank you for the help as to what I'm telling to do what, romaini. Thanks for the slimv help, Tamas.
I have removed the g:slimv_swank_cmd entry in .vimrc, as I believe it does the same thing by itself that it would if I had the command right.
Now, I think I'm back to the problem I was trying to fix with that command, and that might be that SBCL is not working for me (?). Without the g:slimv_swank_cmd setting in .vimrc, Vim starts SBCL which then fails because COMPILE-FILE returns NIL when evaluating line 16 of start-swank.lisp. Vim will then report "SWANK server not running" while SBCL is at a debug screen asking whether to RETRY, CONTINUE, ABORT,,,, or EXIT.
Could it be that slimv is working well but SBCL is not working? I'm still trying in Vim to either compile a program (* 3.0 4.0), evaluate the line, or just connect-server ',C'.
EDIT2:
Trying to install a newer version of slimv from GitHub, I'm afraid we've hit the end of my capabilities. The Readme says to install the zip, reading the whole thing says see internal docs for more, and the internal docs say unzip the zip file in the vimfiles directory. There are lots of files on Github but I don't see a zip.
EDIT3:
With slimv-master.zip from github extracted to .vimfiles, I get the same error that "COMPILE-FILE returned NIL" while evaluating line 16 of ./slime/start-swank.lisp.
EDIT4:
Apparently, the SBCL download went from v2.2.0 to V2.2.1 since 01-26-22. I'm on a 64-bit Windows 10 machine and my SBCL download is automatic from SourceForge after clicking Windows-AMD64 here. I have the same issue, ./slime/swank/sbcl.lisp returns NIL from line 16 where COMPILE-FILE returns NIL. It is starting SBCL v2.2.1 now.
EDIT5:
Both my versions of slimv were extracted to ./vimfiles/. My ./vimfiles/slime/slime.el is Version 2.19. Did the newer slimv version not overwrite files when extracting to ./vimfiles/? Is there an uninstall when we're just extracting zips to ./vimfiles/?
EDIT6:
I don't have a check mark next to comments to mark the last of Tamas Kovacs' responses as the answer (as was the rest of his help through the comments). I now have a REPL window in Vim and Tamas solved my issue.
I summarize the results of our investigation (see comments above):
No need to set slimv option g:slimv_swank_cmd, because slimv should autodetect sbcl and build the correct start command for the swank server.
If autodetection fails or you want to make your own start command for any other reason, then you should use the --load switch (instead of -l) for loading a script into sbcl (the switch depends on the lisp implementation). On Windows machines I also suggest adding /MIN to the !start command, that would start the swank server minimized. This is an example start command for starting sbcl on Windows:
'!start /MIN "c:\Program Files\Steel Bank Common Lisp\sbcl.exe" --load "c:\Users\epic\vimfiles\slime\start-swank.lisp"'
Unfortunately vim.org has an outdated version of slimv, and recent changes in sbcl broke compatibility with the swank server contained in that slimv version. Therefore I strongly recommend that you download or checkout slimv directly from the github repository: https://github.com/kovisoft/slimv
When downloading the slimv-master.zip file from github and manually installing it, make sure that you extract the files from the zip to the proper subdirectories of the vimfiles folder of vim. This means that the contents of slimv-master\ftplugin should go into vimfiles\ftplugin, slimv-master\slime should go into vimfiles\slime, etc. In other words the slimv-master directory in the zip represents the vimfiles directory on your system. Of course this also holds when you install slimv by checking it out from github.
(Note: this is similar to this question, but the answer there does not apply.)
Running under FreeBSD, I have ncurses installed via the usual pkg method for FreeBSD, but because I've seen some odd behaviour with a previously working curses program, I decided to download an ncurses source tarball from the official site and compile it under my home directory.
The compile went fine, but attempting to run any of the included test programs results in:
Error opening terminal: xterm.
The documentation does say:
NOTE: You must have installed the terminfo database, or set the
environment variable $TERMINFO to point to a SVr4-compatible terminfo
database before running the test programs. Not all vendors' terminfo
databases are SVr4-compatible, but most seem to be.
So it looks like the answer is to set TERMINFO, but to what? I don't see any terminfo database under the build directory itself, but I do have a file /usr/local/share/misc/terminfo.db installed as a result of the regular FreeBSD installation.
Nevertheless, setting (csh syntax) setenv TERMINFO /usr/local/share/misc/terminfo.db (or the same omitting the .db extension) doesn't make any difference.
(Note: this shouldn't matter because I haven't so far attempted to install the local build, but when I ran "configure", I used: ./configure --prefix=$HOME so that it would install under my home directory.
By default, ncurses uses (reads/writes) a directory-tree of terminal descriptions. Optionally (and seen in the makefile for the ncurses port), it reads/writes a hashed database file, as well as reads the directory-tree.
The INSTALL file in the ncurses sources goes into some detail about the --with-hashed-db configure option, which you apparently overlooked. The term(5) manual page gives a better overview.
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
I am extremely new to haskell and I have been searching all over the web but I haven't been able to solve my problem. I downloaded the Quipper package but I have not been able to get haskell to recognize where all of the modules and files are and how to properly link everything.
I have downloaded all of the files and programs and installed them properly, I just dont know how to get haskell to recognize the quipper libraries and templates. Evey time I try:
:load And_gate.hs or some other file.
I get:
Could not find module "Quipper" or its respective modules it requires.
I don't think it is an error or anything, I think it is just my lack of knowledge on how haskell works.
I'm using windows 7.
So I emailed Peter Selinger, one of the professors who created Quipper.
The only thing I need to do extra was inside MSYS:
ghci -iC:/quipper -iC:/quipper/quipper
This complies everything correctly and the files run properly.
Here is his email to me:
Dear -----,
thanks for writing. Let me see if I can help.
Are you following the instructions in the README file? Under "Building
the various algorithms and programs", the instruction is to run
"make". This would build all of the tests in the "tests" directory
automatically.
Next, to compile a Quipper program, you should use the "quipper"
script that is located in quipper/scripts. It works just like "ghc",
except that it automatically includes the correct directories for
Quipper's files in the search path. On Windows, you would be using
"quipper.bat".
Quipper is not really meant to be run interactively, i.e., from ghci.
However, if you do need to run Quipper interactively, I recommend
using the "quipperi" script, also in quipper/scripts. This too would
set the load paths correctly. In Windows, use "quipperi.bat".
Finally, if you need to include Quipper stuff from ghci, but for some
reason can't or don't want to use the quipperi script, you need to
specify those directories with the "-i" option, for example
ghci -iC:/quipper -iC:/quipper/quipper
It could be that in Windows, you need to use "\" instead of "/", but I
am not sure if this is necessary.
I hope this helps, -- Peter
When compiling and exe with ghc just make sure you include the commands:
-iC:/quipper -iC:/quipper/quipper.
If you use the quipper script as suggested by Professor Selinger, inside of MSYS do the following:
Navigate to the folder in which all of the Quipper files are held, this was my case:
cd C:/quipper/quipper/scripts
Then type quipper and your file's location in MSYS to compile an exe like so:
quipper C:/quipper/tests/And_gate.hs
The file will compile and should print updates like so:
[1 of 22] Compiling Libraries.Typeable (......
[2 of 22] Compiling Libraries.Tuple (......
and so on.
The exe (in this case And_gate.exe) will be inside the folder it was compiled from (C:/quipper/tests). You'll need to move it to a folder that contains the acroread.bat which comes in quipper/scripts for it to work properly.
For some reason, this code isn't packaged as a standard Haskell package. It if were, installing it would be fairly simple. As it is, the instructions in the README file look awful (especially under Windows, where it looks like you need MSYS to run the makefile).
Your problem might be as simple as telling GHCi which folder to look in to find the files; you can do that using the :cd command. Since you're on Windows, I'd suggest trying WinGHCi, which should allow you to browse to the right folder using the GUI.
If it isn't that simple... really, as a Haskell beginner, you're probably going to struggle to get this working. The documentation looks pretty minimal.
If you red both README and INSTALLING.windows and did everything as well, then you should add a path to Quipper's script folder to environment variable. Here is the path:
quipper-*/quipper/scripts/
where quipper-* is a <distribution name>-<version>.
There are two important scripts in that folder. The first one is quipper.bat which runs a ghc compiler to run Quipper's modules. The second one is quipperi.bat which is a ghci analogue for Quipper.
Now, when you added a path to variable, you can run And_gate.hs in Quipper's interpreter as follows:
quipperi And_gate.hs
I have a project with Fortran and I use gvim as my editor. When I use gfortran as my compiler in my makefile, I encounter no problems. I also have a version of the makefile that uses intel fortran and that makefile also works fine when called from the terminal.
My problem is within gvim. Gfortran version of my makefile works great when called within vim with :make and it shows me the errors and jumps to them etc. However, when I use the ifort version, :make command in vim gives me an error saying he could not find ifort.
ifort works fine from the terminal. I have both ~/.bashrc and /etc/bash.bashrc edited so that it sources intel compilers. I use Crunchbang Waldorf (read: Debian Testing) and I remember having the same problem in LMDE.
Any help is greatly appreciated
Move PATH modifications from .bashrc//etc/bash/bashrc to .profile//etc/profile. This way you won’t need interactive shell like #ib. suggests (and, by the way, you need to do modifications to only one file, not both).
If your distribution uses /etc/env.d it may make sense to do
echo 'PATH=/path/to/ifc/binaries' >> /etc/env.d/99ifort
env-update
. But this should be distribution-specific.