I have a script, called TESTSCRIPT. It was running fine since I created it several hours ago, but now whenever I try to run it, either by pressing F5 or using the command prompt, I get the error message
Undefined function or variable 'TESTSCRIPT'
TESTSCRIPT is in fact a solution to another script file that had suffered the same consequence. I have read through many people's MatLab Forum posts, and I have tried many, if not all, the solutions given:
Checked, double checked, and triple checked the Matlab paths using path, which TESTSCRIPT, and pwd. All return the correct paths.
Changed file and function names so that they wouldn't match any function or file I don't know about within the MatLab paths.
Creating a new file, and copying the code. This provided a temporary solution, until now.
Commented out all but the declaration of two variables. Still get the same error message.
Changed computers. This didn't change anything.
The only thing that stood out when I did all these was when I typed which TESTSCRIPT and got <path>\MATLAB\TESTSCRIPT\TESTSCRIPT.m % Has no license available. I definitely do have a license, because I've been using it for the last 8-9 months without a problem.
I cannot put breakpoints within the code. When I try, a window pops up and says:
License Checkout failed.
License Manager Error -39
along with other stuff.
Scripts older than a week run fine when I hit F5. If I select a piece of code, within TESTSCRIPT, and run just that selection (by pressing F9), that runs without a problem.
My first thought was the file is corrupt, but then a new file would have worked, and this being the third time I've had to creat a new set of files, I'm confident it is not the case.
What is going on, and how do I solve this?
UPDATE
This seems to have resolved itself when I closed and opened MatLab. It does not explain why it has done this, but the problem seems to be solved.
Both dec2rad and pi are builtin functions, rename both variables to avoid the error.
Related
I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.
I wrote some script called drawCurves.m to draw some curves. Then I called this script via publish function:
publish('drawCurves.m', 'outputDir', destPath, 'showCode', false)
Unfortunately, no any breakpoints set inside drawCurves trigger. If I call script directly by name, breakpoints do trigger.
Is it possible to fix somehow?
The publish command calls a private function evalmxdom to actually run the code in your file. You can find evalmxdom at $matlabroot%\toolbox\matlab\codetools\private\evalmxdom.m, where $matlabroot$ is your MATLAB installation directory.
If you read through it, you'll find a section at around line 60 where it stores the current breakpoints, turns them all off, and then sets things up so that the original breakpoints are restored when publishing is finished.
You'll notice that the code calls a subfunction safeDbclear that clears the breakpoints. Try commenting out the contents of that subfunction, and publishing again.
NB:
I'm on R2017a: if you're on a different version and this file has changed between versions, the line numbers may be different.
Be careful: you will be modifying files that are part of your MATLAB installation here. Take a backup of the file before you make a change to it.
This may well mess up some aspects of publishing - it's turning off breakpoints for a reason.
My problem is as described. My script downloads files through an external call to cmd (using the system function and then .NET to make keypresses). The issue is that when it tries to fopen these files I downloaded (filenames from a text file I write as I download), it doesn't find them, causing an error. When I run the script again after seeing it fail, it works but only up to the point where it's trying to download/call new files again, where it runs into the same problem.
Are new files downloaded during when a script is running somehow not visible to the search path? Because the folder is most definitely in my search path (seeing as it works outside of during-script downloads). It's not that it isn't getting the files fast enough either, cause they appear in my folder almost instantly, and I've tried a delay to allow for it to recognize it, but that didn't work either.
I'm not sure if it's important to note that the script calls an external function which tries to read the files from the .txt list I create in the main script.
Any ideas?
The script to download the files looks like so:
NET.addAssembly('System.Windows.Forms');
sendkey = #(strkey) System.Windows.Forms.SendKeys.SendWait(strkey);
system('start cygwinbatch.bat')
pause(.1)
sendkey(callStr1)
sendkey('{ENTER}')
pause(.1)
sendkey(callStr2)
sendkey('{ENTER}')
pause(.1)
sendkey('exit')
pause(2)
sendkey('{ENTER}')
But that is not the main reason I am asking: I am confident that the downloads are occurring when the script calls them, because I see them appearing in my folder as it called. I am more confused as to why MATLAB doesn't seem to know they are there while the script is running, and I have to stop it and run it again for it to recognize the ones I've downloaded already.
Thank you,
Aaron
The answer here is probably to run the 'rehash' function. Matlab does not look for new files while executing an operation, and in some environments misses new files even during interactive activity.
Running the rehash function forces Matlab to search through its full path and determine if there are any new files.
I've never tried to run rehash in the middle of an operation though. ...
My guess is that the MATLAB interpreter is trying to look ahead and is throwing errors based on a snapshot of what the filesystem looked like before the files were downloaded. Do you get different behavior if you run it one line at a time using F9? If that's the case then you may be able to prevent the interpreter from looking ahead by using eval().
I am using matlab R2011b. I created a matlab gui that is a simple calculator just make addition. Then I created an .exe file. When I doudle click the .exe file which is in 'distrib' folder, nothing happens. Also, there is no error message.
I don't understand the reason. Is there anybody who has an idea about it?
I encountered 2 problems in the past when I tried to create an exe.
A. The program shut itself down as soon as it was 'finished'. To check whether the program actually runs, consider making a test program like this:
'abcd'
pause(5)
'efg'
If you can make a program like this, at least you know you can make a working exe.
B. You can choose from a few kinds of projects. Several of these make an exe, but you only want 1 of them. Not sure which one but it is not that hard to try all 3 or so options with a simple test program.
I have a script in perl that generates a .m file based on a series of parameters and then runs an octave algorithm through ticks like:
`octave my_script`;
And then I capture the results in a separate file. The problem is that even having installed the image package succesfuly mat2gray function is not working.
If I open manually octave like a separate console to be used manually, and call my script it does work perfectly. The issue appears only when calling the octave.exe from Perl. It shows:
error: `mat2gray' undefined near line 21 column 6
Which looks like the typical error you get when you don't have the image package (and I do have it installed and I'm able to usethe function on octave console directly). I already tried to iclude a line on my script at the very top to rebuild the package everytime my script runs, like so:
pkg rebuild -auto image;
But that didn't fix it. Anyone has seen this kind of odd behavior?
I'm using Octave 3.2.4, since I need that version due to some compatibility issues with other pieces of software that we need. And some plotting capabilities when called from perl don't work all that well. Just in case you were wondering.
For future reference, I replied to the question here.