I've got an application that I'm working on which currently takes a model, passes it to OpenModelica, compiles it, runs a simulation, and grabs the output. We'd like to switch over to use Dymola, but I can't figure out how to do this in a GUI-less fashion.
For instance, I've seen how I can use the javascript interface by running "dymola.exe -serverport 8082", but that actually still launches a GUI, and you can see everything running in the background when you use the javascript interface. Plus, closing the GUI kills the server.
Is there any way to use Dymola without a GUI? Note also that I can't simple use the .exe of a compile model, since compiling the model is one of the things I need to do.
Even easier is if there is a way for me to run my .mos file without the GUI launching.
you can use Dymola in command line mode and passing the right optional argument to not show its GUI.
You should use the following command :
C:/Program Files (x86)/Dymola 2016 FD01/bin64/Dymola.exe /nowindow myscript.mos
With the first part being the pass the the Dymola executable depending on where it was installed on your machine, the second one /nowindow being the optional argument stating that the GUI should not be displayed, and the third part path to your Modelica script which can contained the simulation setup.
Check the Dymola User Guide for additional details.
Best regards,
Gilles
From the command line, dymola.exe -nowindow.
Related
I have an existing GUI mac app and I'd like to add command line call to it. For example, the GUI app called "Gallifrey" looks up the actor playing Dr. Who and optionally the companion. The GUI has a text field for year and a checkbox for "And companion" and a button to look up. From the command line, I imagine it would be:
> gallifrey -y2014 -c
> Peter Capaldi, Jenna Coleman
I found this mention of a solution on apple-dev http://lists.apple.com/archives/cocoa-dev/2009/Oct/msg01480.html
Is that still the suggested solution? I considered moving the logic into an XPC service and bundling a separate command line target, but that seems needlessly complicated.
Edit: To be clear, I'm not asking how to parse the args, I've done that, just how to decide between launching the GUI vs just returning the answer.
Option 2
Edit your main() function and in it decide whether to return an answer instead of launching NSApplicationMain. This way you keep technically one app, one executable, that supports both ways of launching.
Option 1
Move all of your app's code into a framework (your own framework in your own app bundle).
Make separate GUI and CLI app targets, and have them both link to the framework with all the required functionality.
Linked framework makes everything available in the same process, so there's least amount of code change required, and no XPC to worry about.
The downside is that your CLI is not a standalone executable, but needs to live inside the app bundle.
Currently, I define the following function in the REPL at the start of a coding session:
(defn rt []
(let [tns 'my.namespace-test]
(use tns :reload-all)
(cojure.test/test-ns tns)))
And everytime I make a change I rerun the tests:
user=>(rt)
That been working moderately well for me. When I remove a test, I have to restart the REPL and redefine the method which is a little annoying. Also I've heard bad rumblings about using the use function like this. So my questions are:
Is using use this way going to cause me a problem down the line?
Is there a more idiomatic workflow than what I'm currently doing?
most people run
lein test
form a different terminal. Which guarantees that what is in the files is what is tested not what is in your memory. Using reload-all can lead to false passes if you have changed a function name and are still calling the old name somewhere.
calling use like that is not a problem in it's self, it just constrains you to not have any name conflicts if you use more namespaces in your tests. So long as you have one, it's ok.
using lein lets you specify unit and integration tests and easily run them in groups using the test-selectors feature.
I also run tests in my REPL. I like doing this because I have more control over the tests and it's faster due to the JVM already running. However, like you said, it's easy to get in trouble. In order to clean things up, I suggest taking a look at tools.namespace.
In particular, you can use clojure.tools.namespace.repl/refresh to reload files that have changed in your live REPL. There's alsorefresh-all to reload all the files on the classpath.
I add tools.namespace to my :dev profile in my ~/.lein/profiles.clj so that I have it there for every project. Then when you run lein repl, it will be included on the classpath, but it wont leak into your project's proper dependencies.
Another thing I'll do when I'm working on a test is to require it into my REPL and run it manually. A test is just a no-argument function, so you can invoke them as such.
I am so far impressed with lein-midje
$ lein midje :autotest
Starts a clojure process watching src and test files, reloads the associated namespaces and runs the tests relevant to the changed file (tracking dependencies). I use it with VimShell to open a split buffer in vim and have both the source and the test file open as well. I write a change to either one and the (relevant) tests are executed in the split pane.
I sometimes test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality. Of course, since my code is in development there are bugs, and frequent restarts of the interpreter are required. This isn't too painful when I've only executed a couple of interpreter lines before restarting: my key sequence when the interpreter restart looks like Up Up Enter Up Up Enter... but extrapolate it to 5 or more statements to be repeated and it gets seriously painful!
Of course I could put my test code into a script which I execute with python -i, but this is such a scratch activity that it doesn't seem quite "above threshold" for opening a text editor :) What I'm really pining for is the Ctrl-r behaviour from the bash shell: executing a sequence of 10 commands in sequence in bash involves finding the command in history (repeated Up or Ctrl-r for a search -- both work in the Python interpreter shell) and then just pressing Ctrl-o ten times. One of my favourite bash shell features.
The problem is that while lots of other readline binding functionality like Ctrl-a, Ctrl-e, Ctrl-r, and Ctrl-s work in the Python interpreter, Ctrl-o does not. I've not been able to find any references to this online, although perhaps the readline module can be used to add this functionality to the python prompt. Any suggestions?
Edit: Yes, I know that using the interactive interpreter is not a development methodology that scales beyond a few lines! But it is convenient for small tests, and IMO the interactiveness can help to work out whether a developing API is natural and convenient, or too heavy. So please confine the answers to the technical question of whether readline history-stepping can be made to work in python, rather than the side-opinion of whether one should or shouldn't choose to (sometimes) work this way!
Edit: Since posting I realised that I am already using the readline module to make some Python interpreter history functions work. But the Ctrl-o binding to the operate-and-get-next readline command doesn't seem to be supported, even if I put readline.parse_and_bind("Control-o: operate-and-get-next") in my PYTHONSTARTUP file.
I often test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality.
Stop using this pattern and start writing your test code in a file and your life will be much easier.
No matter what, running that file will be less trouble.
If you make the checks automatic rather than reading the results, it will be quicker and less error-prone to check your code.
You can save that file when you're done and run it whenever you change your code or environment.
You can perform metrics on the tests, like making sure you don't have parts of your code you didn't test.
Are you familiar with the unittest module?
Answering my own question, after some discussion on the python-ideas list: despite contradictory information in some readline documentation it seems that the operate-and-get-next function is in fact defined as a bash extension to readline, not by core readline.
So that's why Ctrl-o neither behaves as hoped by default when importing the readline module in a Python interpreter session, nor when attempting to manually force this binding: the function doesn't exist in the readline library to be bound.
A Google search reveals https://bugs.launchpad.net/ipython/+bug/382638, on which the GNU readline maintainer gives reasons for not adding this functionality to core readline and says that it should be implemented by the calling application. He also says "its implementation is not complicated", although it's not obvious to me how (or whether it's even possible) to do this as a pure Python extension to the readline module behaviour.
So no, this is not possible at the moment, unless the operate-and-get-next function from bash is explicitly implemented in the Python readline module or in the interpreter itself.
This isn't exactly an answer to your question, but if that is your development style you might want to look at DreamPie. It is a GUI wrapper for the Python terminal that provides various handy shortcuts. One of these is the ability to drag-select across the interpreter display and copy only the code (not the output). You can then paste this code in and run it again. I find this handy for the type of workflow you describe.
Your best bet will be to check that project : http://ipython.org
This is an example with a history search with Ctrl+R :
EDIT
If you are running debian or derivated :
sudo apt-get install ipython
I want to use F# for some very basic tasks for which I previously used batch files. I can associate fsx files with fsi.exe and run it just by double clicking them. That's great so far.
However, sometimes I might want to dive into the code deeper and debug things. When I open the fsx file within Visual Studio I can't run it and I also can't select the lines and use "Send to interactive", though.
It seems to me as if those commands only work if you set up a full F# project. That seems to be cumbersome (as an batch file replacement). I wonder which is the right approach? I want to have my cake and eat it! I want a simple file that I can change quickly but I also want the ability to use the analyze things with Visual Studio on demand.
UPDATE
I just figured out you can open the interactive console at "View\Other Windows\F# Interactive" and after that you do have the "Send to Interactive" command.
I'm still lacking the ability to run the code and set breakpoints, though..
As you already discovered, you don't need to create project to use the F# Interactive console.
I believe that features like debugging are a lot less important when you use F# for interactive development (or scripting), because you can quite easily evaluate code step-by-step to analyze its behaviour just by sending individual commands to FSI. So I don't feel the need for debugging in F# Interactive very often.
Although this isn't really a supported feature, you can debug code in a script file when using just F# Interactive. The trick is to attach the debugger to the fsi.exe process that's running behind the F# Interactive.
Just go to "Debug" -> "Attach to Process" and then select "fsi.exe". Then you should be able to place brakepoints in the fsx script file and the code running in F# Interactive will break. As I said, this is not really supported, but it generally works well for code in functions. I don't find this as useful often, but it may be useful now and then.
How can I get a callback within my application when an executable (such as pbs, cp, etc) launches and then exits? This would need to work only knowing the path to the executable.
You could move the original executable aside, and replace it with a wrapper that runs the original, reporting when it runs and exits.
You could look at the accton and lastcomm commands, which record the start and exit of every process on the system.
You could look into using dtrace, which can definitely do what you're asking but it's rather complicated to use. You'd probably have to do a fair amount of learning to do this. I don't know much about writing dtrace scripts, but I'd probably start with execsnoop as my model.