Now that rvm seams to handle maglev with ease I wanted to start experimenting with an image different from the standard maglev image. I created a new image using
rake stone:create[experimental]
I could now run code in a VM connected to that stone using
maglev-ruby --stone experimental -e <code>
as expected and it reported the expected stone_name. However I could not get maglev-irb to run with a similar option, judging from the usage info they do not seem to be supported. Trying
maglev-irb --stone experimental
anyway results in an error like
ERROR 2730 , a NameError occurred (error 2730), , global $# is a read-only variable (NameError)
Maybe there is a less obvious way I am missing? It would really be convenient to play around with maglev features interactively without destroying the default VM in the process.
That seems to be an oversite on our part. As a workaround, try:
export MAGLEV_OPTS="--stone experimental"
maglev-irb
Related
I have a Windows 10 laptop where no TeX distribution was ever installed before (double-checked for config directories, files, and environment variables).
Wanting to install TeX Live 2021, I followed the full installation guide and also read the Windows-specific warnings. I've now tried several times, following different installation procedures - cleaning up everything (deleting base & user directories, environment variables, etc) before each time - but still don't manage to get a working installation. Before I report a bug at tex-live#tug, I wanted to ask for advice here, in case I'm doing something wrong. Here is what I did, step by step, and the problems I encountered in the process.
1. First I tried running the recommended online installer install-tl-windows.exe. It never got past the screen that tries to contact or load from a repository, even after a 30-min wait. Tried a dozen times, choosing different mirrors nearby and far away. No luck.
2. Then I downloaded and unpacked the install-tl.zip and run install-tl-windows.bat therein. This time the main installation window appeared. I left all default paths and environment variables (note that I do have write access to C:); in the selection scheme I unselected all languages except US & UK English, unselected XeTeX, LuaTeX, ConTeXt; also unselected TeXworks (I use Emacs), and clicked Install. After one to three hours (depending on the mirror I chose), the installation was complete.
I tried compiling a minimal latex document (see below), and got an error similar to the one in this old question:
I can't find the format file `pdflatex.fmt'
Following the advice in the answers to that question and similar questions elsewhere online such as this, I tried running texhash and fmtutil-sys --all. The latter gave the error
no appropriate script or programme found fmtutil.
for which there are also many posts online.
2a. Not understanding what the problem could be, I re-tried with all possible combinations of the following three options: (a) choosing different mirrors; (b) leaving the full selection of packages (ie without unselecting some languages, LuaTeX etc); (c) redoing the procedure by choosing "Run as Administrator". No luck.
3. At this point I tried downloading the ISO file with the full installation. Mounted the image and run install-tl-windows.bat (as normal user, as recommended; I repeat that I do have write access to C:). Everything proceeded as in step 2. above. At the end of the installation I tried running pdflatex on the minimal latex document. New error this time:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./minimal-template.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
! LaTeX Error: File `article.cls' not found.
Very strange. A file search revealed that article.cls is in the TeXLive file system; but kpathsea did not see it indeed.
4. At this point I opened the TeX Live Shell from the Start Menu; selected a CTAN mirror; updated the TL Manager which was not up to date; updated all packages; run Regenerate filename database; and run Regenerate formats. With the latter I got this error:
tex live shell:
mtutil [INFO]: total formats: 59
fmtutil [INFO]: exiting with status 53
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 53:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --all
Here is a snip from the full set of errors appearing in the "Other" tab (I'm replacing my user directory with asterisks for privacy; note that I do have write access to these directories):
start load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
finish load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
start load http://contrib.texlive.info/current
finish load http://contrib.texlive.info/current
running mktexlsr ...
done running mktexlsr.
running mtxrun --generate ...
done running mtxrun --generate.
running updmap-sys ...
done running updmap-sys.
regenerating fmtutil.cnf in C:/texlive/2021/texmf-dist
running fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
tlmgr.pl: fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX failed (status 255), output:
Unknown option: status-file
Try "fmtutil --help" for more information.
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 255:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX
running fmtutil-sys --byengine luajithbtex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
I tried to continue anyway with Regenerate fontmaps, and then tried again pdflatex on the minimal document. New error:
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
---! c:/texlive/2021/texmf-var/web2c/pdftex/pdflatex.fmt made by different executable version
(Fatal format file error; I'm stymied)
5. I tried again steps 3. and 4., but with "Run as Administrator". Same errors.
OK at this point I give up and really don't know what to do. Am I doing something wrong? For the moment I have to concur with this post: installation of TeX Live 2021 is an utter failure.
Here is the minimal latex file I used for testing (copy & paste):
\documentclass{article}
\begin{document}
test
\section{Section}
test
\end{document}
Found, that the download is not working because the system path to "cmd.exe" is not found. Therefore: open a cmd window and add the system path prior to starting the .bat file (set PATH=%PATH%;C:\Windows\system32)
How do I build a standalone executable in SBCL? I've tried
; SLIME 2.20
CL-USER> (defun hullo ()
(format t "hullo"))
HULLO
CL-USER> (sb-ext:save-lisp-and-die "hullo" :toplevel #'hullo :executable t)
but that just produces the following error.
Cannot save core with multiple threads running.
Interactive thread (of current session):
#<THREAD "main thread" RUNNING {10019563F3}>
Other threads:
#<THREAD "Swank Sentinel" RUNNING {100329E073}>,
#<THREAD "control-thread" RUNNING {1003423A13}>,
#<THREAD "reader-thread" RUNNING {1003428043}>,
#<THREAD "swank-indentation-cache-thread" RUNNING
{1003428153}>,
#<THREAD "auto-flush-thread" RUNNING {1004047DA3}>,
#<THREAD "repl-thread" RUNNING {1004047FA3}>
[Condition of type SB-IMPL::SAVE-WITH-MULTIPLE-THREADS-ERROR]
What am I doing wrong?
What you are doing wrong is trying to save an image while multiple threads are running. Unlike many errors in Lisp the error message explains exactly what the problem is.
If you look up the function in the sbcl manual here then you find that indeed one may not save an image with multiple threads running. The extra threads come from swank (the CL half of SLIME). The manual says that you may add functions to *save-hooks* which destroy excess threads and functions to *init-hooks* to restore threads.
One way around all this is to not save the image when it is running through slime but instead to start sbcl directly at a terminal (note: no readline support), load your program and save from there.
Working with slime is different. In theory there is a SWANK-BACKEND:SAVE-IMAGE function but I’m not sure if that works. Also as saving an image kills the process you may want to fork (SB-POSIX:FORK) first, unless you are on Windows. But forking causes problems due to not being well specified and file descriptor issues (i.e. if you try fork->close swank connection->save and die then you may find that the connection in the parent process is closed (or worse, corrupted by appearing open but being closed at some lower level)). One can read about such things online. Note that due to the way sbcl threads are implemented, forking clones only the thread that forks and the other threads are not cloned. Thus forking and then saving should work but may cause problems when running the executable due to partial slime state.
You may be interested in buildapp.
If you want to be able to use slime with your saved application you can load swank and start listening on a socket or port (maybe with some command line argument) and then in Emacs you may connect to that swank backend with slime.
You have to run save-lisp-and-die from a new sbcl, not from Slime. Dan Robertson explains more.
It is cumbersome the first time, but you can put it in a Makefile and re-use it. Don't forget to load your dependencies.
build:
sbcl --load cl-torrents.asd \
--eval '(ql:quickload :torrents)' \
--eval '(use-package :torrents)' \ # not mandatory
--eval "(sb-ext:save-lisp-and-die #p\"torrents\" :toplevel #'main :executable t)"
The quickload implies Quicklisp is already loaded, which may be the case if you installed Quicklisp on your machine, because then your ~/.sbclr contains quicklisp loading script ((load quicklisp-init)).
However sb-ext is not portable across implementations. asdf:make is the cross-platform equivalent. Add this in your .asd system definition:
:build-operation "program-op" ;; leave as is
:build-pathname "<binary-name>"
:entry-point "<my-package:main-function>"
and then call asdf:make to build the executable.
You can have a look at buildapp (mentioned above), a still popular app to do just that, for SBCL and CCL. It is in Debian. http://lisp-lang.org/wiki/article/buildapp An example usage looks like
buildapp --output myapp \
--asdf-path . \
--asdf-tree ~/quicklisp/dists \
--load-system my-app \
--entry my-app:main
But see also Roswell, a more general purpose tool, also supposed to build executables, but it is less documented. https://roswell.github.io/
If you want to build an executable on a CI system (like Gitlab CI), you may appreciate a lisp Docker image which has already SBCL, others lisps and Quicklisp installed, and if you want to parse command line arguments, see https://lispcookbook.github.io/cl-cookbook/testing.html#gitlab-ci and (my) tutorial: https://vindarel.github.io/cl-torrents/tutorial.html#org8567d07
My Intent
I have an image generated by BitBake on which I'm interested in changing the window manager to metacity or maybe something similar.
My Process
I've added require recipes-graphics/images/core-image-x11.bb into my core recipe, which provides a simple Matchbox terminal window but seemingly no other functionality. If I add matchbox-desktop and matchbox-session-sato, it adds a bit more usability but not what I'm looking for.
I've included the default package from the metacity_2.34.13.bb recipe from the meta-gnome layer from the OpenEmbedded Metadata Index in the IMAGE_INSTALL variable of my core image. This installs several components including a metacity command in /usr/bin. If I run that command, I get the following message:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
(metacity:1124): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' is not installed
Trace/breakpoint trap
I've navigated to /usr/share/glib-2.0/schemas and run glib-compile-schemas ., then run:
startx
metacity --replace
again. Now, the output is:
Window manager error: Unable to open X display
I haven't found a clear solution to this error which applies to my specific situation.
Update (2/29):
I may have now found a solution to this error, using these commands:
X&
export DISPLAY=:0
metacity&
At this point, I seem to be running something on one of my VTs. I can run demos like glxgears in that VT (glxgears is included in the mesa-demos recipe), but I don't know how to actually create a usable environment.
My question(s)
I'm not using much from meta-openembedded/meta-gnome (just metacity) or meta/recipes-gnome (adwaita-icon-theme, gnome-desktop3, gsettings-desktop-schemas and gtk+3), so am I missing some recipe which automates the addition of metacity?
(if not Question 1) How can I solve the error Window manager error: Unable to open X display?
The x11-common recipe adds a X session script that will run /usr/bin/x-session-manager: that is responsible for starting your desktop environment.
The way to implement a new session/DE in OE-Core is to use update-alternatives for "x-session-manager": see the matchbox-session recipe for the default implementation and mini-x-session recipe for an alternative.
mini-x-session might be modifiable for your needs so you don't need to write a new one: A /etc/mini_x/session file like this might do the trick:
# start any apps here, e.g. "my-desktop &"
exec metacity
Going from this (a running window manager) to "usable environment" might still be lots and lots of work, depending on your definition of usable.
I am trying to play a wav file in a very simple program that looks like this, currently attempting to use nim-csfml:
import csfml_audio
var alarmsong = newMusic("alarm.wav")
alarmsong.play()
but it appears to be relying on the existence of libcsfml.audio, and while my program compiles just fine, when I try to actually run it I get an error
| => ./alarm
could not load: libcsfml-audio.so
(I have a libcsfml-audio.dylib instead, being that I used the OSX shared libraries for csfml/sfml)
Is there some other way to play a .wav file in Nim?
Edit 1:
After the PR made by #def-, I now get a different, slightly more comforting error, which is probably due to some poor understanding of how nim deals with shared libraries:
| => ./alarm
could not load: libcsfml-audio.dylib
I added path = "/usr/local/lib" to my nim.cfg file, but it didn't seem to be affect anything. I also exported $LD_LIBRARY_PATH="/usr/local/lib" (/usr/local/bin is where libcsfml-audio.dylib is.), and tried compilation through
nim c alarm.nim --clib:/usr/local/lib/libcsfml-audio.dylib
Thanks for the help!
This program would just exit immediately; you need to keep it alive while the sound plays. Append this to the program:
import csfml_system
while alarmsong.status == SoundStatus.Playing:
sleep 100.milliseconds
For nim-csfml to work you'll need SFML 2.1 and CSFML 2.1. Also, it seems that nim-csfml is actually broken for Mac OS X, so I've made a pull request with a fix: https://github.com/BlaXpirit/nim-csfml/pull/4
Other modules that could play sound are sdl_mixer, sdl2/audio and allegro5.
As an OSX-only alternative without using any libraries, by calling the afplay binary:
import osproc
discard execProcess("afplay", ["file.wav"])
Edit1:
When Nim reports "could not load: libcsfml-audio.dynlib" that could also mean that one of the dependencies of that library are missing or in a wrong version. Especially SFML 2.2 doesn't work with CSFML 2.1. Make sure libsfml-audio.dynlib is in your LD_LIBRARY_PATH as well. If that doesn't work either, you could try to compile and run a regular C CSFML example like this one: https://gist.github.com/def-/fee8bb041719337c8812
Compile it with clang -o mainpage -lcsfml-graphics -lcsfml-audio -lGL -lGLEW mainpage.c to see the errors/warnings about missing libraries.
When building the latest grub2 (2.00) I get this error.
I have tried adding -Wno-unused-function to both HOST_CFLAGS, HOST_CPPFLAGS, TARGET_CPPFLAGS and TARGET_CFLAGS in the Makefile. I even tried deleting that function whilst make was running!
Unfortunately the error remains.
Have you seen this?
The latest flex makes the GRUB-2.00 build fail. I can work around the issues with --disable-werror, but grub-core/script/yylex.l causes two warnings that do not work with -Werror.
./grub-core/script/yylex.l: At top level:
grub_script.yy.c:2351:13: error: 'yy_fatal_error' defined but not used
This can be fixed by removing #define YY_FATAL_ERROR(msg) in yylex.l.
However, according to this post this seems to have been fixed.
Judging from the info on the net you either want to switch to grub 2.02 or try an older version of flex.