Scilab can really be automated.
For instance you can use make to automatically start Scilab that will generate plots and save them to SVG with xs2svg, then start Inkscape to integrate it into a Latex document (with Latex code in legends!).
When using make it is convenient to run Scilab without the main interface by calling it with -nw. If you do not need graphics it can even run without java if called with -nogui.
It would be nice to be able to write scripts that can be either run by a user or by make. With that you could prevent code duplication while allowing easy debugging and report writing.
But that means:
closing the script when it's done
being able to skip some plots that should not be saved
etc
So how to detect options -nw or -nogui from within the script?
Using getargs
function y = nowindows()
y = (getenv("SCILAB_NW","undefined") ~= "undefined")
endfunction
then you can use this function:
if nowindows() then
mprintf("Running without a window.\n")
exit()
end
And if you set the environnement variable SCILAB_NW, nowindows() will return true.
SCILAB_NW="true" scilab -nw -f yourscript.sce
This solution adds redundancy to the command used to run Scilab but I found no other way. I also tried to use the sciargs function but I found it less convenient.
Related
im looking for a shell command-line tool to lint julia scripts (a static analyzer), eg.
local:~ $ linter(myjuliascript.jl)
which will produce its output to terminal => text with linter results = either
// messages inlined with text of myjuliascript.jl or
...
...
// messages indicating line numbers of myjuliascript.jl
...
...
i found this, https://github.com/tonyhffong/Lint.jl, but it does not look promising (does not compile).
question: do you know of any good-quality command-line tool with which to lint julia scripts?
id rather avoid plugins to IDE's, since im a little tired of IDEs; often they are too much kung-fu-fighting with too little benefit. eg. tried to get the VS code julia linter working, no luck; VS code, julia linter doesn't work (on mac)
The closest thing currently available appears to be https://github.com/julia-vscode/StaticLint.jl. While you could technically call this from the command line if so desired using, julia -e, the interface would not seem to be very conducive to that sort of usage.
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
Simple question. I'd like to know how to tell whether the current shell is running as a mc subshell or not. If it is, I'd like to enter a degraded mode without some features mc can't handle.
In particular, I'd like this to
Be as portable as possible
Not rely on anything outside the shell and basic universal external commands.
Though it's not documented in the man page, a quick experiment shows that mc sets two environment variables: $MC_TMPDIR and $MC_SID. (It also sets $HISTCONTROL, but that's not specific to mc; it affects the behavior of bash, and could have been set by something other than mc.)
If you don't want to depend on undocumented features, you can always set an environment variable yourself. For example, in bash:
mc() { MC_IS_RUNNING=1 command mc "$#" ; }
Entering a "degraded mode" is another matter; I'm not sure how you'd do that. I don't know of any way in bash to disable specified features. You could disable selected built-in commands by defining functions that override them. What features do you have in mind?
I have an elaborate script that spans multiple functions (and files). For debugging purposes I need to embed browser calls into all sorts of nooks and crannies. When I presumably fix something, I want to run the whole thing without debugging, ergo avoiding browser calls because commenting out all browser calls would mean a considerable effort from my part. #mdsumner on R chat suggested running the script in non-interactive mode (i.e. using Rscript.exe on Windows) but I would benefit from having that done in my console, to be able to access for instance traceback. I have gone through browser docs and I can find no option that would come close to what I'm trying to achieve. Any suggestions?
Here are three possibliities:
1) Overwrite browser command. Add this command to your global workspace to turn the browser commands off:
browser <- list
and to turn it back on
rm(browser)
This is probably the easiest but is a bit ugly due to the browser variable being left in the global environment.
The next two solutions are slightly longer but use options instead so that no new variables are introduced into the global environment. Also they are such that if no options are set then no debugging is done so you only have to set an option if you want debugging. The if solution may be faster than the expr solution although its likely not material.
2) Use expr= argument with option. Replace each browser command with:
browser(expr = isTRUE(getOption("Debug")))
and then define the "Debug" option to be TRUE to turn debugging on.
options(Debug = TRUE)
or set it to something else or remove it to turn debugging off:
options(Debug = NULL)
3) Use if with an option. Replace each browser command with:
if (isTRUE(getOption("Debug"))) browser()
and then set the Debug option or not as in the prior point.
Define global logical value
debug_mode <- TRUE
and then instead of browser() use
if (debug_mode) browser()
I think this just comes down to nuanced use of a debugging function. If you want to selectively control the use of browser(), put it inside an if that lets you enable or disable debugging for the function. When you want browser to be called, make that explicit like
myfun(x, debug = TRUE)
I often use Sweave to produce LaTeX documents where certain chunks are produced dynamically by executing R code. This works well - but is it also possible to have code chunks that are executed in different ways, e.g. by executing the code in the shell, or by running Perl, and so on? It would be helpful to be able to mix things up, so I could do things like run some shell commands to fetch some data, run some perl commands to pre-process it, and then run R commands to analyze it.
Of course I could use all R chunks and use system() as a poor-man's substitute, but that doesn't make for very pleasant reading in the document.
The new new thing (for multi-language, multi-format) docs may be dexy.it which for example these guys at opengamma.org use as the backend.
Ana, who is behind dexy, is also giving a lot of talks about it so also look at the dexy blog.
It's not directly related to Sweave, but org-babel, which is part of Emacs org-mode, allows to mix code chunks of different languages in one file, pass data from one chunk to another, execute them, and generate LaTeX or HTML export from the output.
You can find more informations about org-mode here :
http://www.orgmode.org/
And to see how org-babel works :
http://orgmode.org/worg/org-contrib/babel/
There is certainly no easy way to do this other than through either foreign language interfaces from R (maybe through inline if it's supported), or system(). For what it's worth, I would just use system(); that should be easy enough.
You can see this previous question about having a Sweave equivalent for Python, where one of the respondents actually creates a separate interface. This can give you a sense what what it would take to embed other languages which may not already be supported. At a minimum, you have to do major hacking on the Sweave driver.
Do you know emacs" org-mode and, more specifically, Babel? If you already know Emacs or are willing to switch to Emacs, then org-mode and Babel are the answer to your question(s).
For instance, I am currently working on a document which contains some shell-scripts, does computations with R and creates flow charts with dot (graphviz). Org-mode can export a variety of formats, e.g. LaTeX (that's what I use).
There is the StatWeave project which uses java rather than R to do the weaving, but will run multiple programs instead of just R. I don't know how hard it would be to get it to do Perl or other programs like that, but the homepage indicates that it already works with R, SAS, Stata, and others:
http://www.cs.uiowa.edu/~rlenth/StatWeave/