Why does “filename.m” gets deleted when I use “dynare” command in Octave? - octave

I wrote a model to solve using dynare in octave. After writing the model, I save it with “.m” format. Then I type “dynare filename” in octave’s command window to run the model but instead the file gets deleted.
Oddly, it doesn’t happen if I use the command on a file with “.mod” format.
I’m using Octave 5.2.0 since the dynare only works with this version.
Please help me if you can. Tnx a lot.

I guess you used Dynare 4.5 instead of the recent stable release 4.6. As documented in the manual, the only supported file-types in Dynare are .mod and .dyn. You cannot name your file .m as Dynare will preprocess your .mod-file and create an m-file with the same name. Usually, you would get an explicit error message. However, in Octave, the following code is executed first:
% Workaround for a strange bug with Octave: if there is any call to exist(fname)
% before the call to the preprocessor, then Octave will use the old copy of
% the .m instead of the newly generated one. Deleting the .m beforehand
% fixes the problem.
if isoctave && length(dir([fname(1:(end-4)) '.m'])) > 0
delete([fname(1:(end-4)) '.m'])
end
Dynare 4.6 instead moved to Matlab-classes. There you will get an explicit error message.

Related

How can I get Octave GUI to load/read .m files correctly in editor and console?

I am taking a class on using Octave for machine learning algorithms, and as part of the assignments, they provide a series of .m files to build upon with our own code as well as to run for submission credit through the auto-grader. My problem is that the .m files load perfectly fine in a regular text editor program like Atom or Notepad, but in Octave, the files are best described as nonsense, and thus will not run in the console. If I open the files in a regular editor and copy/paste over the crazy into Octave, it seems to save it and reopen fine. But, I have close to 20 files for the first project alone, and this solution is untenable in the long run. I have a screenshot of how it's loading. Is there some setting I need to change? Uninstall/reinstall Octave? I'm new to Octave and the Octave GUI, and I'm striking out with Google for a solution. I am using version 6.2.0. Thank you for any help/advice!
screenshot of how octave is loading my .m files
Update: I responded to this in a comment below, but I tried loading it another way into Octave GUI and received the following error: ">> error: load: unable to determine file format of 'C:/Users/sophi/documents/octave/assignment_1/computeCost.m" This tracks for me because it makes sense why it would open the files in such a weird way. It's simply not sure what they are. However, I created my own simple functions from scratch to test, saved them as .m files, and was able to run them perfectly fine. I'm including one of the files below. Maybe there's a key in the formatting of the files offered by the class which is impacting Octave's ability to process it correctly?
function plotData(x, y)
%PLOTDATA Plots the data points x and y into a new figure
% PLOTDATA(x,y) plots the data points and gives the figure axes labels of
% population and profit.
figure; % open a new figure window
% ====================== YOUR CODE HERE ======================
% Instructions: .... goes on about assignment
% ============================================================
end
MOST RECENT UPDATE: The plot thickens. Yesterday, I was able to open the files I created and run them in the Octave environment, and I (wrongly) assumed they would still work today. They are doing the same stupid thing as the files included by the course. I checked inside preferences for the editor, and it says it is loading and saving them as IBM273 if that helps. Thank you for everyone has pitched in ideas. I really appreciate it!
It was 100% the encoding. I thought it was strange it was saving/loading in IBM273, so I switched it to UTF-8. Almost all the files are working now. The only ones that aren't are the ones I was trying to copy/paste yesterday to see what was going on with the load problems and the basic new problems I wrote. So I deleted everything, redownloaded, and set the default UTF-8 going forward and voila! Solved! Thanks again!
If you want to open a .m file in octave, Try this solution
It is necessary to declare a current directory before saving a file, loading a file, or running an M-file. By default, unless you edit the Octave shortcut, the current directory will be .../Octave/work. After you start Octave, change the current directory by either using the toolbar at the left-hand side of the screen, or entering the path in the bar at the top.
To open an .m file, you can use file -> open, or type
open filename

nsys says "please use the qdrep file instead" - huh?

I'm using NVIDIA Nsight Systems version 2019.5.2.16-b54ef97 with CUDA 10.2. I'm running:
nsys profile my_app --some --args=here
so, a plain-vanilla profiling with no funny business. And yet, I get, at the bottom of the output:
... etc. etc. ...
Saving report to file "/some/where/report1.qdrep"
Report file saved.
Please discard the qdstrm file and use the qdrep file instead.
Removed /some/where/report1.qdstrm as it was successfully imported.
Please use the qdrep file instead.
Why am I being told to discard files and use other files instead? Especially given how, eventually, only a single file is generated (a .qdrep file)?
I'm guessing some internal conversion utility is run, and the message is not really intended for me - or am I missing something?
It is just a logging, which is a little confusing though, and later it removes the *.qdstrm file for you automatically.

Cross compiling with mingw64 - wildcard expansion

I'm trying to cross compile GNU grep for Windows from Fedora, using their mingw64 cross compilers. The process is really easy, with one exception. By default, it appears that mingw64 doesn't expand wildcards on the command line, so that grep FOO * gives "Invalid argument: *" rather than searching all files in the current directory.
After a bit of research, I found that there is an external symbol, _dowildcard in the mingw64 CRT, that will trigger wildcard expansion if set to -1. But I've found no useful documentation on how to set this (maybe because it's considered obvious ;-)).
I could modify the source code to set the variable, but I'd much prefer to not have to modify the source if at all possible. (I want to set up an automated build, and applying code patches just adds complexity that I'd like to avoid). Is there any way to set _dowildcard from the configure or make command line? I seem to remember older versions of mingw having a setargv.obj file that could be linked into your project to enable wildcard expansion - is there anything similar for mingw64?
Answer from #ssbssa above:
There is a file CRT_glob.o file supplied with the mingw packages, in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/CRT_glob.o (or the corresponding location for 32-bit) that you can link with your executable to activate command line globbing.
You have to specify the file by full pathname for the linker to find it.

How do I get non-zero return from a syntax error while running an octave script?

lets say I have a test.m octave script
test.m
x = 1;
A % Syntax error, A isn't defined
so I run the script with
octave test.m
What I'm interested in is how do I get octave to return non-zero exit status if the script contains a syntax error? Note, I am not interested in encapulating the code with if-else statements and do exit(-1). I am interested in a solution that tells octave to return a non-zero value if the script contains syntax errors.
Edit: I was using Octave 4.2 that comes default with Ubuntu 18.04. Commenters have suggested Octave 5+ does not exhibit this behaviour.
Never mind I solved it. To give some context why I needed this behaviour, its because I'm trying to write the octave scripts that basically test octave functions I write.
Now more often than not I will have written scripts that contain syntax errors, and octave will raise errors while parsing the scripts. However, the return status is always 0 if you run your script in a straight forward manner like:
octave script.m
regardless if your octave script contains syntax errors or not. I however did not want to surround every script I write with if-else or try-catches, that is why I opened this question on SO.
A workaround I have found is just to source the script by using the --eval flag. i.e.
octave --eval "source('script.m');"
This way if your script does contain syntax errors the return value / status is a non-zero exit value. In this case I believe octave defaults to 1.
I cannot reproduce the behaviour in your question. In octave 5 at least, doing
octave myscript.m
results in a return value of 1 in case of error.
Same as doing
octave --eval "source('myscript.m')"

Loading tcl extension from tclsh

I have a C extension to Tcl where command mytest is defined. The extension is compiled correctly (I am on Linux, extension is *.so). For example, I can start tclsh and use it like this:
$ tclsh
% load /path/extension.so
% mytest abc
...
But, if I create a file myscript.tcl with the following content:
load /path/extension.so
mytest abc
then I get error:
$ tclsh myscript.tcl
invalid command name "mytest"
while executing
"mytest abc"
(file "myscript.tcl" line 2)
I am using bash on Ubuntu 14.04. Tcl 8.6.
EDIT 1: My question/problem is that I want to use tclsh with a script as an argument - this script should properly load extensions in such a way that mytest and other implemented functions are working without error.
EDIT 2: Uhh, If I use command "source myscript.tcl" inside tcl shell the result is the same. If I use absolute path for myscript.tcl the error is still the same --- "load" executes without warning but I am not sure about it because I get invalid command name "mytest". Maybe the problem is with scope, but it is working correctly when tclsh is used interactively.
If you are using the full path of the extension library in both cases, that part should work identically. It probably is doing though; if it couldn't load it, it would generate an error (which might or might not be helpful, as some of the ways that things fail give very little information; Tcl reports what it has got, but that's sometimes not enough, as it is dependent on the OS to tell it some things). Instead, the problem is probably elsewhere.
The main difference between interactive use and scripted use is that in interactive use, the unknown command will expand unknown command names to Tcl commands that the thing you typed is an unambiguous prefix of. This is convenient, but when converting to a script, you should always use the full command name. OK, not the full full command name — you mostly don't want or need the :: namespace on the front — but without abbreviation, so don't use lappe for lappend. (In interactive use, Tcl will also exec things as external programs without requiring you to type the exec explicitly; again, that's turned off in scripts as it is rather fragile.)
Could it be that this is what is going on? You can check by setting the global variable tcl_interactive to 0 before typing in your code (I recommend using cut-n-paste for that typing, so that you know exactly what is going in). If that fails, it's the interactive-mode helpfulness that is tripping you up. Check what commands you might have as an expansion for a prefix with info commands (after the load, of course):
info commands mytest*
If that just reports mytest, my theory is wrong. (Well, if it does that and the length of that string is 6; there could theoretically be extra invisible characters have been put on the command name, which would be legal Tcl but very nasty and DON'T DO THAT!)