I try to use libserialport in DrRacket.
The libserialport is https://docs.racket-lang.org/libserialport/index.html .
I install the libserialport package source by the DrRacket "file->package manager".
After installation, when I use (require libserialport) in DrRacket, there's a error
ffi-lib: couldn't open "libserialport-0.dll"
How to fix it? thanks
The installation from DrRacket does not actually install the library itself, only the racket bindings to a library that needs to be installed prior to use. The error message you see is because it doesn't find the library since it's not yet installed.
In the documentation is clearly states:
It (the library) must be installed externally to this Racket module,
preferrably via the system package manager.
To install the library go to the Downloads section on libserialport's project page and download and install the one matching your operating system and architecture. When installed the racket module should work.
I got this done now.
For windows(32bit or 64bit),
Install libserialport in msys2-MinGW-32-bit environment. Then the file libserialport-0.dll is done.
Add the path of libserialport-0.dll file into the windows system PATH.
Install Racket(i386-win32) & the libserial binding. Then (require libserialport) will work.
Notice that the Racket(x86_64) can not load the libserialport-0.dll successfully.
Thanks to #Sylwester .
Related
I am trying to update an old racket package I had written ages ago to run on the new racket. I found the documentation extremely confusing and seemingly broke everything. Can you please suggest how things can be resolved?
While trying to run raco pkg install {path/to/package} I got an error saying my package was trying to find the old Racket 6.4 installation and since I have updated my operating system since then it didn't find it. I searched in that directory and could only find such references in the compiled/ folder. I skimmed the raco documentation and saw that raco setup --clean would remove that compiled folder. However, I thought it would be context specific: working on just the package who's directory I was in. That appears to not be the case. Now raco pkg doesn't even exist as a sub-command of raco!
How can I restore it and get back to trying to update my package so that it can be installed on the latest racket?
When you run raco, it works on the installation that it's a part of. So, for instance, if you have two copies of racket installed at /Users/clements/racket1/racket and /Users/clements/racket2/racket, then if I run the raco that's a part of the racket1 installation, I'll be updating the packages that are associated with the racket1 installation.
Sounds sensible, but I've messed this up myself, many times: depending on how your path is set up, the command raco may refer to either the racket1 or the racket2 installation. The problem here isn't really with racket, it's with the idea of paths, and how easy it is to mess things up when you have two installations containing the same binaries.
(And, of course, apologies if I'm misunderstanding your problem!)
I am trying out Manjaro Arm on my Raspberry Pi 3, but surprisingly find only Guile as the only viable Scheme interpreter/REPL.
I have tried the following:
Racket, and Mit-Scheme not found by pacman in the repositories.
Chicken Scheme seems to install, but will only run as the Chicken compiler, the csi REPL is MIA.
Chibi Scheme seems to compile and install fine (and make test ran fine before make install) but then crashes looking for a support file (libchibi-scheme.so.0).
Chez-Scheme is X86 centric, and no arm fork has been created yet. Historically older versions also ran on Sun SPARC. I did not try to compile or install it.
I would prefer a scheme REPL that is supported by Geiser, running within Emacs.
A couple of years later, and with a new install of Manjaro on a RPi4 (aarch64) I now have managed to install and get the following working:
Racket will compile from source. I had to use the "unix source" only, since "unix source + built packages" still crashed at the attempt at compiling. Compiling the full racket (including DrRacket) source took a few hours on the pi.
Chicken CSI is in the repositories under chicken-csi. A soft link in /usr/local/bin with the name csi fixes geiser's search for csi.
Exporting LD_LIBRARY_PATH as an env variable with the location of the chibi-scheme library ( /usr/local/lib/ by default ) makes chibi-scheme fully functional. Chibi-scheme compiled easily on the Rpi4.
Gambit Scheme seems to be in the repositories, although I have not played with it much.
Of course Guile 2.2 is in the repositories and works fine.
System Info:
MongooseIM version: 3.0.0
Installed from: pkg
Erlang/OTP version: 18
Ubuntu 16.04
I am having trouble creating a standard base for a custom module. I want to create a simple hello world program as outlined in the documentation for ejabberd.
However, I cannot get it to work for MongooseIM. Are there any instructions for how to do this? As a beginner I am just looking for building blocks to creating my own modules, and everything I look at is a little too complex for what I am trying to achieve at the moment.
Here is the code for my module: (taken from ejabberd) https://docs.ejabberd.im/developer/extending-ejabberd/modules/#mod-hello-world
And here is my log error:
I have added the following line in my config file with all other running modules:
{mod_hello_world, []}
I am assuming it has something to do with the compilation and there being no .beam file created for the modules as well as some syntax errors specific to MongooseIM. I am also unfamiliar with documentation for compiling modules when using a pre-built pkg as opposed to installing from source.
DISCLAIMER: I'm a MongooseIM developer working for Erlang Solutions.
The link you posted hints at the answer to the immediate question:
If you compiled ejabberd from source code, you can copy that source code file with all the other ejabberd source code files, so it will be compiled and installed with them. If you installed some compiled ejabberd package, you can create your own module dir, see Managing Your Own Modules.
MongooseIM (a.k.a. MIM) does not support the latter method of managing modules, i.e. it's not possible to drop source code into some predefined location when MIM is installed from a package and let it just compile and run the module. If we want to write a custom module, we have to build MongooseIM from source.
To be precise, we don't have to build the whole server from source and package it ourselves. We have to, however, clone the repository, place the new module source there (due to build time requirements like header files) and build it there. Once we get a .beam file of the new module we can just drop it into an installed MongooseIM's code path.
To be even more precise, let's say we have installed MIM from mongooseim_3.0.0-1~ubuntu~artful_amd64.deb available from the Downloads page at erlang-solutions.com, therefore we want to build a module compatible with 3.0.0:
Clone MIM: git clone https://github.com/esl/mongooseim
cd mongooseim
git checkout 3.0.0
Place mod_hello_world.erl under ./src/
rebar3 compile
Once rebar3 finishes get ./_build/default/lib/mongooseim/mod_hello_world.beam and copy to the target host where we installed MIM from a package.
Please note, though, that an example taken straight from ejabberd documentation might not work "as is" in MongooseIM. In this simple module, for example, we'll not be able to include logger.hrl as MongooseIM doesn't have such a header file - we would have to -include("mongoose_logger.hrl"). instead.
I'm trying to install ElScreen that allows multi-tab editing in Emacs.
One of its prerequisite is call APEL (A Portable Emacs Library). However, it seems that I cannot find a usable download link of APEL anywhere: wikipedia, Emacs-wiki, and ElScreen's README file all give broken links. Are there still anyone using this package and knows how to install? Thanks!
I followed the ubuntu link and was able to get it from there (thanks rvf0068), but figured it would be nice if there was an easier way to get at it than having to unpack a .deb.
So it's on github now too (and it works with emacs 24.2, I just did it).
https://github.com/jeffgran/APEL
If you use Ubuntu (and maybe also Debian) there's the possibility of installing apel from the repositories. See for example: http://packages.ubuntu.com/precise/apel
If you use emacs 24, a fork version of Elscreen having no dependency on APEL is available in github. You can install it easily through ELPA(Emacs Lisp Package Archive). I've been using it with no problems.
You can find the latest version at here. http://git.chise.org/elisp/apel/index.html.en
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.