Has anyone used COPASI via commandline? - bash

I am trying to run COPASI in commandline but there is very little documentation.
I have downloaded and unzipped binary, I am not sure how to proceed in order to do something as simple as import an SBML file?
Here is all the documentation I found:
http://copasi.org/Support/User_Manual/Model_Creation/Commandline_Version_and_Commandline_Options/
It doesn't say which command do I use to call COPASI?

The command line version of COPASI is CopasiSE, which you can install besides the GUI CopasiUI via any source here http://copasi.org/Download/.
For example, see https://github.com/ICB-DCM/solverstudy/blob/master/Bash_Scripts/install_copasi.sh, in which case the executable resides in a local folder.
Regarding usage, I am not sure whether extensive API documentation is available. It probably won't help much, but here's how we wrapped it in a study via Python to call an underlying CPS model file https://github.com/ICB-DCM/solverstudy/blob/master/Python_Scripts/simulation_wrapper_copasi.py#L77.

Related

Racket/Scheme compile to single binary, no dependencies? FFI and static linking

Say I'm building an app in Racket.
And say eventually I want to compile that app as a single binary file that could be distributed to users, without them having Racket or any other software libs installed. I believe this is possible, yes?
Say in that app I want to use the snappy package https://docs.racket-lang.org/snappy/ which is some FFI wrappers around a C++ lib.
I already ran into a minor problem. I did (require snappy) inside DrRacket and followed the prompts and got the package installed but I get the error:
../../Applications/Racket v7.7/collects/racket/private/kw.rkt:1349:57:
ffi-lib: couldn't open "libsnappy.1.dylib" (dlopen(libsnappy.1.dylib, 6): image not found)
I can assume from this that racket-snappy expects the files for libsnappy to be on the usual unix path, but I'm on macos and mine is installed via Homebrew somewhere else. I believe the answer to that problem is here https://stackoverflow.com/a/24287418/202168
My concern is: I do not want users of my app to have to install these libs via Homebrew and fiddle with paths etc.
I am a Racket noob and know basically nothing about the compiler toolchain or C/C++ for that matter either. But I believe what I need is when I compile my Racket project to be able to have raco exe(?) "statically link" the libsnappy that's on my system and roll everything into a single binary with no dependencies.
So my question is: is this possible? If so, is it straightforward (i.e. managed via raco tools)?
I'm imagining in the worst case I have to download all the dependencies and build them from source and build my Racket project also as a library and then have some kind of skeleton C project that pulls them all in into one thing. I hope not.
I will add also... if this is easier in other Schemes (Chicken? Chez? Gambit? Guile?) then I'd be interested to know too.
Update: I found this article with some year-old anecdata of someone attempting the same thing https://taoofmac.com/space/blog/2019/06/20/2310
Based on that, and Ryan's answer below, raco distribute looks promising and I really need to try this out for myself to confirm what works.
Update again: Here is another article again confirming raco distribute should put everything into a folder with no external deps https://defn.io/2020/06/28/racket-deployment/ and here is a pointer to the docs for how to build a .dmg image for MacOS: https://docs.racket-lang.org/raco/exe-dist.html#(part._.A.P.I_for_.Bundling_.Distributions)
There is a partial solution using a combination of raco distribute and define-runtime-path.
Suppose you have a program that uses libzmq, which you know is installed on your build system at /usr/lib/x86_64-linux-gnu/libzmq.so.5. You can use define-runtime-path to create a reference to that file and tell raco distribute to copy it to the distribution directory. For example, suppose that "my-app.rkt" is the following:
#lang racket/base
(require racket/runtime-path)
(define-runtime-path zmq "/usr/lib/x86_64-linux-gnu/libzmq.so.5")
(printf "zmq = ~e\n" zmq)
When you run the program using racket my-app.rkt, it prints
zmq = <path:/usr/lib/x86_64-linux-gnu/libzmq.so.5>
But when you run raco exe my-app.rkt and then raco distribute MyApp my-app, then the MyApp directory will contain a copy of libzmq.so.5:
$ find MyApp/ -type f
MyApp/lib/plt/my-app/exts/ert/r0/libzmq.so.5
MyApp/lib/plt/racket3m-7.7
MyApp/bin/my-app
and if you run ./MyApp/bin/my-app, it prints
zmq = #<path:/PATH/TO/HERE/./MyApp/bin/../lib/plt/my-app/exts/ert/r0/libzmq.so.5>
You can use (ffi-lib zmq) to load the shared library. Unfortunately, that directory is not in the search path that the application will use for loading shared libraries, so existing Racket libraries that just try to load (ffi-lib "libzmq" '("5")) won't find the application's copy.
There is another way of using define-runtime-path specifically for shared libraries, and I thought it would solve that problem, but it doesn't seem to. That seems like a bug to me, so I'll file a bug report.
Update: I have filed a bug report about the fact that define-runtime-path's shared library ('so) mode causes raco distribute to copy the shared library outside of the application's library search path.

How can I use a Common Lisp (Clozure CL) Library?

I'm learning Common Lisp (Clozure CL) on the Mac and would like to create a simple GUI. I have downloaded the "ltk" library from CLiki and put it into the project directory at the root level (I assumed I had to do this as I couldn't find instructions for a beginner).
Page 4 of the "LTK - a Lisp binding to the Tk toolkit" documentation says that the library should be compiled using (compile-file "ltk") before loading the library using (load "ltk"). However, I get this error message:
Error: File #P"/Users/myName/Desktop/lisp_experiments/GUI_EXAMPLE/ltk" not found
While executing: CCL::FCOMP-FIND-FILE, in process Listener(4).
Type cmd-. to abort, cmd-\ for a list of available restarts.
Type :? for other options.
I also used the full file pathname and got the same error.
What am I doing wrong?
Thanks for your help.
Marc
ps - there are almost no noob tutorials about this sort of thing online that takes the user through the process step by step.
I have downloaded the "ltk" library from CLiki and put it into the project directory at the root level.
Nowadays, this is a step that is seldom required, because libraries are easily accessible using Quicklisp (see also this gif).
Basically, you should be able to install Quicklisp and run the following:
(ql:quickload "ltk")
The above downloads, compiles and install Lisp libraries, but not necessarily the required C libraries, which you might need to install separately. If the above works without problem, then the following should work too:
(ltk:ltktest)
Quicklisp relies on Lisp systems being described with ASDF (Another System Definition Facility). The best practices document is also interesting to read.
In the case of LTK, you can see that ltk.asd only specifies one component, ltk.lisp. When you install the system named "LTK", quicklisp will do all the necessary work to install its dependencies, then compile and load ltk.lisp, as described in the manual.
What is unclear is why your explicit compile-file failed.
I found the ltk.lisp file on my machine; its pathname looks like:
#P"/home/user/quicklisp/dists/quicklisp/software/ltk-20150113-http/ltk.lisp"
Sure enough, calling compile-file with that pathname works and returns another pathname which ends in .fasl (the object format). Loading the returned pathname loads the library. Please provide more information about the error so that we can help you debug this problem.

CMake not finding SDL - Windows

I am trying to build a program that requires SDL. I have downloaded SDL for Windows so that I have a folder containing the include and lib suborders.
When I run CMake I get the following error:
Could NOT find SDL (missing: SDL_LIBRARY SDL_INCLUDE_DIR)
This is despite the fact that I have created two environment variables called SDL_LIBRARY and SDL_INCLUDE_DIR, pointing to the lib and include folders respectively.
I have no idea what to do.
In my experience, the best method when find scripts don't work as expected is to check their source code. Often you will identify the problem by just reading through the documentation at the top, but if that still doesn't work out, digging into the source is often the only thing that helps.
From the documentation alone you can see for instance, that CMake does only consider one environment variable SDLDIR for searching. SDL_INCLUDE_DIR and SDL_LIBRARY are the names of the CMake variables to hold the results of the find script. You can set them via the command line (or the cmake-gui), but I would advise against that, as it kind of undermines the purpose of using a find script in the first place.
Instead, verify that your directory structure corresponds to what the find script expects and simply set SDLDIR accordingly.
Please note that the script that currently ships with CMake does not work with the newer SDL2. If you are using SDL2, you will have to write your own script.

pygtk import gtk error

I downloaded everything described as in pygtk for installation. Everything went fine until when I tried to type "import gtk", it threw an ImportError as follows:
from gtk import _gtk
ImportError: DLL load failed: ...(something unreadable)
Then I re-install the pygtk-2.22.0 again, the same problem existed. So what to do please? Thanks in advance!
The error you describe is usually caused by the python bindings (pygtk/pygobject/pycairo) being unable to load a dll it needs to function properly. Most of those errors are either caused by:
the GTK+ runtime not being on your PATH environment variable. This has long been
the advice on how to get pygtk working on Windows. Please don't change your user
or system PATH environment variable, it is no longer needed with the all-in-one
installer.
multiple GTK+ runtime versions are on your PATH environment variable and the first
(leftmost) one is not compatible with the pygtk/pygobject/pycairo versions you use.
This is why adding the GTK+ runtime to your PATH environment variable is a bad idea:
it is easy to mix up versions (sometimes GTK+ related installers add their bin
directory to PATH on installation which contains an older or incomplete runtime).
a rare case where some software package installed libintl.dll and iconv.dll into
%WINDIR%\system or %WINDIR%\sytem32
The most straightforward way to avoid the dll hell described above is to use the
PyGTK All-in-one installer (http://download.gnome.org/binaries/win32/pygtk/2.22/).
It contains both the Python bindings, the GTK+ runtime and even Glade and does
no longer require you to change the PATH environment variable.
Small warning: if you decide to use the all-in-one installer, you'll have to uninstall
the separate pygtk/pygobject/pycairo packages you've used before (or you'll be in
a world of trouble...)
read the source code, perhaps there is a need for a specific version of pygtk
edit the source code to work with your pygtk version
I had this issue as well. You didn't mention for sure in your answer, so I'll suggest the obvious (well...the obvious to people that have used it a while, perhaps). Did you use the following three lines of code to import? You have to use these, in order, to import PyGTK.
I'm assuming your version here is 2.24 like mine. If not, change it to the version you have.
import pygtk
pygtk.require('2.24')
import gtk
That should suffice in importing gtk.
Problem
As others have noted, don't put gtk in the path. I know, its tempting, and it works for XYZ, but it (to say the least) gets confusing. Dependency hell is bad enough on a platform like Linux which tries to make it easy for you.
For clarification, what the PyGTK All In One does for you is to install (what appears to be) a full gtk+ runtime directly in your python packages folder, so e.g. in C:\Python\Lib\site-packages\gtk-2.0\runtime
Solution
NOTE: %YOURPYTHONPATH% is an EXAMPLE variable which contains the path of your Python installation (e.g. C:\Python, or C:\Python27, or whatever it actually is). I suggest setting %PYTHON_DIR% or %PYTHON_PATH% if you want to use a variable to do this, as more programs are likely to use this.
To get your XYZ program requiring GTK to work, add %YOURPYTHONPATH%\Lib\site-packages\gtk-2.0\runtime\bin to the PATH when running your program; the correct versions of the DLLs it needs to link against are in that folder. All other GTK+ runtimes I had installed (GTK+/GTK2-Runetime) gave me errors.
Again; Do not attempt to set a user or system level variable (don't open up the dialog pictured below) as this will likely cause problems for you later unless you VERY sure you know what you are doing. If you are reading this, you most likely don't know as much as you think you do. Instead, alter the path in a cmd prompt, or use a batch/script file to set it up for you.
After you install the pygtk.org package, install each of these in the following order:
pycairo-1.8.6.win32-py2.6.exe
pygobject-2.20.0.win32-py2.6.exe
pygtk-2.16.0+glade.win32-py2.6.exe
gtk+-bundle_2.16.6-20100912_win32.zip
For more information:
http://freetstar.com/windows7-pygtk-gtk/
I got the secusses according the link on my PC.

Doxygen equivalent for Mathematica?

How do you put additional information into a Mathematica package file, like
parameter specification
doctests/example usage?
Up to now, I only found the ::usage string and some information on how to write documentation notebooks. I am looking for an option to generate these documentation notebooks from introspecting package files.
I don't know that there is any mechanism such as doxygen built into mathematica. If you want to embed a documentation notebook into your package I would proceed as follows
Write up the documentation notebook
Embed the notebook as a character string in your package
Write a help function that, when called, crates a file, writes out the notebook and uses front end manipulations to open it
You might be able to skip the creation of the external notebook by using Notebook[] instead of a character string for storing the documentation notebook inside your package file.
Integrating with Mathematica's own Help system is a bit more difficult (as the link you gave explains). Of course, you could still have the package write and move the appropriate files into place when the package loads.

Resources