I am looking for some direction to run Matlab in org-mode on a Win10 machine.
Matlab is installed and fully pathed within windows so it loads without issues.
Matlab is added in the org-babel languages list which loads without error.
These two lines to identify explicitely where matlab is and define header arguments which load without error.
(setq matlab-shell-command "c:/Program Files/MATLAB/R2018b/bin/matlab.exe")
(setq org-babel-default-header-args:matlab '((:results . "output") (:session . "*MATLAB*")))
When I attempt to run a something simple such as
#+begin_src matlab :results output
a=4
b=5
c=a*b
ans=c
#+end_src
I receive an error "no such file or directory, matlab".
What is the correct way to identify the location and execution of matlab to process the org-mode block?
(Note: I have extensively googled it but have not found any usable instruction from Win10 users who seem to be few in number.)
Related
I've seen some applauses for org-babel in place of jupyter (https://news.ycombinator.com/item?id=16842786) and trying out what it is about.
I'd like to convert *.ipynb file to *.org file and the execute each source block in org mode as we would do in jupyter notebook.
(I tried ein couple of days, but it seems unstable)
I've succeeded converting file formats as illustrated in https://www.reddit.com/r/emacs/comments/7lcgkz/import_a_jupyter_notebook_to_an_orgmode_file/
However I'm having hard time executing code blocks because variables are not shared among code blocks.
Can I use PROPERTIES: or similar method to run them in the same context?
Can I use ipython?
I failed to google how to use org mode for ipynb file (as I try to do).
Would like to know if someone shares a work process of doing it
If variables are not shared between code blocks it might be due to the lack of :session argument otherwise each code block is run in standalone mode. For instance, the second block should print i
#+begin_src python :session my_session
i = 0
#+end_src
#+begin_src python :session my_session :results output
print(i)
#+end_src
whereas this one should raised a NameError: name 'i' is not defined error
#+begin_src python :results output
print(i)
#+end_src
I decided my birthday would be a good time to try and fix my Lisp problems.
I've received a Lisp program from someone to run an experiment. It works well on his OS X environment. However, I can't get it to run on either Windows 7 or Ubuntu. The program uses Act-R 6.2 to run a model. When I try to load the .lisp file I receive the following error:
:Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("*path*"/28 UTF-8)#xCFAD1AE, near position 1048, within "smile* (#initWithCo":
Undefined character #\/ in a #\# dispatch macro.
While executing: CCL:SIGNAL-READER-ERROR, in process listener(1)
The error is the exact same for Windows 7 and Ubuntu. Here is the console output if it is required:
http://i.stack.imgur.com/dFXVm.png
It seems load-turing-application.lisp loads multiple other files, one of which is turing-application-v1.lisp, in which the line (setf *smile* (#/initWithContentsOfFile: (#/alloc ns:ns-image)(ccl::%make-nsstring "smiley.jpg")))
seems to be the culprit. I suspect it has something to do with the #/-notation.
Any ideas would be appreciated.
This is answered in the comments, but #/ is a CCL syntax that only is available on OS X. This code is not expected to work on linux or windows.
I got a problem when executing batch file commands through matlab. This batch file includes commands to run simulations in Adams. When I execute the batch file directly from DOS window, it works well. But if I use matlab to execute it (using command dos()), it gives error saying 'cannot check out the license for Adams'.
This confuses me: if the license is incorrect, it should not work no matter I execute the batch file directly in DOS or ask MATLAB to execute it. I also tried to execute other DOS commands through matlab using dos() and it worked well.
Does anyone know what the problem may be?
Such issues are commonly caused by some environment variables being changed or cleared by MATLAB. I have very similar experience on Linux and Mac OS X, where this causes havoc when using system or unix.
In Unix-like systems, MATLAB is started from a shell script where all of this happens. So you can either incorporate missing variables there or in the .matlab7rc.sh in your home directory (the latter is preserved when you upgrade MATLAB and it is much easier to use). I won't go into all the Unix details here.
An alternative workaround is to explicitly set those variables when you issue a system command (e.g. system('export variable=value ; ...')). It is quite a bit of work, but you can then use that MATLAB code on different computers with ease.
On Windows, I'm not completely sure about the exact location of the corresponding files (and whether MATLAB starts in quite a similar way as on Unix). But if they exist, you can probably find it in the MATLAB documentation.
Anyhow, the alternative fix should work here as well.
First you need to diagnose which system variables you need (likely a PATH or anything that has a name related to Adams).
To do so in Windows, run set from the Windows command prompt (cmd.exe) and from within MATLAB. Whatever differs in the output is a possible suspect for your problem.
To inspect just a single variable, you can use the command echo %variablename%.
I will assume that you have found that the suspect environment variable is missing and should be set to value.
The workaround fix is then to run your command in MATLAB as system('set suspect=value & ...') where you replace ... with your original command.
I'm trying to get set up with SLIME on a Windows 7 box, but running M-x slime gives me the error
Spawning child process: invalid argument
I have inferior-lisp-program set to "C:\\Program Files\\ccl\\wx86cl.exe" (which is factually correct, and running (comint-run inferior-lisp-program) gives me a working CCL prompt), and the slime directory added to my 'load-path.
What am I doing wrong?
EDIT: Tried loading up the same environment through the Windows edition of lispbox, and it runs SLIME fine. I'd prefer not to use that one because it packages an older Emacs, CCL and SLIME than I want.
The message you received means that there's a high chance that there was a syntax problem with the command given to shell. This would be caused by having characters in the file name, which can be interpreted as doing something special. So, it looks like Emacs was trying to call C:\\Program "program" with an argument Files\\ccl\\wx86cl.exe.
There are several ways to address the error:
There has to be an escaping function, something like:
(shell-quote-argument "C:\\Program Files\\ccl\\wx86cl.exe")
But since you cannot affect how the file name is passed to the function which creates the process, this isn't going to work.
You can move the program you want to call to a directory with "safe" name.
You can move the executable to be on the system path (%PATH% variable in Windows) - through changing environment variables and appending the directory with the executable to it.
One more option is to add the directory with the executable to exec-path variable in Emacs. This variable holds a list of all directories looked up for programs to run, if you just call a program by name, rather then by full path. This also (at least for me) makes my .emacs file easier to port between different systems.
I'm trying to compile u-boot via Emacs' compilation mode, and it looks like Emacs doesn't know how to find bash environment variables. Even though I set them, and can compile via Emacs shell emulation, compilation mode still tries to compile as if they aren't there.
What do I need to do to make it more environment conscious?
You can try adding something like to your .emacs:
(let ((path (shell-command-to-string ". ~/.bashrc; echo -n $PATH")))
(setenv "PATH" path)
(setq exec-path
(append
(split-string-and-unquote path ":")
exec-path)))
Depending on whether you've set the env variables in .bash_profile or .bashrc you might need to slightly adjust this snippet. The example is for the PATH variable, which is a bit more special (since you have to set exec-path in Emacs as well), but can be extended to work for arbitrary variables - you could have a list of variables that have to be read from .bashrc and set into Emacs.
I'm not sure whether you're using OS X or GNU/Linux. Starting Emacs from the GUI's menu-bar in Linux will typically result in an Emacs that does not have the same PATH as one launched from the command line. This problem dates back to the first xdm Xsession scripts, and while they are fairly easy to fix (basically use an Xsessionwrapper script that does exec $SHELL -c Xsession so the shell gets run before running the user's Xsession), nobody has bother to do so in a very long time (and I doubt that anyone will). As far as I know the problem is present even into moder xdm descendants such as kdm and gdm.
On OS X the handling of the env variables is another problem entirely and to get your ENV variables you typically have to run Emacs from the command line like this /Applications/Emacs.app/Contents/MacOS/Emacs or play with ~/.MacOSX/environment.plist. The code snippet I've provided should cover you in both cases though.
Update
Recently this process was made easier by the exec-path-from-shell extension. It sets the emacs $PATH in more or less the same manner, but using an extension is generally preferable to hacking the solution yourself.
This is where the environment variables of the process that started emacs are:
— Command: getenv var
This function returns the value of the
environment variable var, as a string. var should be a string. If var
is undefined in the environment, getenv returns nil. It returns ‘""’
if var is set but null. Within Emacs, a list of environment variables
and their values is kept in the variable process-environment.
(getenv "USER")
⇒ "lewis"
— Variable: process-environment
This variable is a list of strings,
each describing one environment variable. The functions getenv and
setenv work by means of this variable.
process-environment
⇒ ("PATH=/usr/local/bin:/usr/bin:/bin"
"USER=lewis"
"TERM=xterm"
"SHELL=/bin/bash"
"HOME=/home/lewis"
...)
You seem to be assuming that emacs was started from a bash session. However, often processes under X are started from an sh session, which would not read the environment variables you had set in your ~/.bashrc script. One simple way to circumvent this is to change your ~/.xinitrc file to use bash instead of sh (it could be as simple as adding #!/bin/bash at the top of the file).
Source: gnu.org
It doesn't strictly answer your question, but you can always pass environment variables on the make command-line. For example : M-xcompileRETmake -k CXXFLAGS='-Wall'RET