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.
Related
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.
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
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.
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.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.