Installation/(load "/home/inaimathi/quicklisp/setup.lisp") both fail. This still-open task from 2011 tells me it's probably not getting fixed.
Is there a workaround?
Clozure CL and SBCl both can run hunchentoot web server on ARM.
Related
While using SBCL normally I want to try CCL for some testing and installed it via homebrew on my computer. That worked fine but I fail to use quicklisp with CCL. If I try to load quicklisp's setup.lisp I get the following error message:
➜ ~ ccl64
Clozure Common Lisp Version 1.11.6 DarwinX8664
For more information about CCL, please see http://ccl.clozure.com.
CCL is free software. It is distributed under the terms of the Apache
Licence, Version 2.0.
? (require 'asdf)
ASDF
("uiop" "UIOP" "asdf" "ASDF")
? (load "~/quicklisp/setup.lisp")
> Error: There is no package named "ASDF/SYSTEM-REGISTRY" .
> While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Retry finding package with name "ASDF/SYSTEM-REGISTRY".
> Type :? for other options.
1 > :POP
I couldn't find a simple solution searching the web. CCL comes with ASDF as (require 'ASDF) is working. In quicklisp's documentation I couldn't find anything about extra efforts to use it with two lisp implementations in parallel.
If I check ASDF's version as suggested here I get "3.1.5" as installed version, which should be quite recent.
Is there anything obvious I am missing?
I think I found it: I had some old data in my ~/.cache directory from another attempt to install ccl. After deleting it, I can load quicklisp's setup.lisp without any error.
Please advice If I should delete my question or leave it here to prevent others from repeating my errors.
Please note that various Lisps have some startup files. Some of them are by default:
SBCL: ~/.sbclrc
CLISP: ~/.clisprc.lisp
Clozure: ~/.ccl-init.lisp
From the documentation of CCL:
By default, Clozure CL will look for a file named ccl-init.lisp in your home directory, and load it upon startup. On Unix systems, it will also look for .ccl-init.lisp.
CCL uses an ordinary lisp file called ccl-init.lisp which on unix systems is usually put on your home path. So you can add the following lines in that file (on my Ubuntu machine it's path is /home/me/.ccl-init.lisp) which instructs CCL to load quicklisp upon startup:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
This is enough for enabling your CCL to communicate with quicklisp.
I'm trying to deploy an ASP MVC project developed on Mono/OSX on my Linux server using mono 2.10.8.1 w/ fastcgi-mono-server4
The webapp always starts fine, but then I start getting random CS0006 compilation errors for various URIs, and once they break, they remain broken until I restart the server application.
An example error:
Server Error in '/' Application
Compilation Error
Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error.
Compiler Error Message: CS0006: Metadata file `/tmp/root-temp-aspnet-0/ed68754/App_global.asax_40e709ea.dll' could not be found
~/Views/Order/Download.aspx
There is a related thread from January, but both the question and the answer seem to be mod_mono specific and rather hand-wavy. Anyone have any advice on what to try to debug/solve/work around this issue? It's getting very frustrating. In particular, is there any "unsupported" workaround where I can copy something from my Windows Server machines to use an MS implementation instead of the buggy mono one?
(I've filed a bug report too.)
Since the errors appear to be issue with the Mono JIT attempting to compile temporary files that don't exist, I spent a few days trying different methods of working around this issue (vs solving it). One solution that worked was using aspnet_compiler on Windows to create a binary version that could be copied and run as-is on Linux/Mono (as the latest versions of Mono now support precompiled ASP.NET applications).
However, I was looking for a native Linux solution, and I don't want to have to compile and sync binaries (vs syncing a GIT repo of code) to the server, so I was looking for another solution when I came across Mono ahead of time compilation, which is pretty much the equivalent of ngen.exe on Windows.
While it doesn't precompile everything, it seems to have done the trick. For me, this deployment script does the job without any runtime build failures:
xbuild SystemDiscs.sln
mono --aot -O=all SystemDiscs/bin/SystemDiscs*.dll
killall -9 mono
nohup fastcgi-mono-server4 /socket=tcp:127.0.0.1:8000 /applications=/:/var/asp/S
ystemDiscs/SystemDiscs/ > /var/log/systemdiscs.log &
Where SystemDiscs*.dll is the output of the solution compiled with xbuild in the first step. I don't think this precompiles the ASP pages (and --aot=full isn't supported on x86, as far as I can tell), but somehow it did the job. I was waiting to see whether or not that was just a fluke, but it's been going fine with maybe a dozen commits/deploys since I asked this ten days ago, so I reckon its safe to say it works.
I had a similiar problem:
Compilation Error
Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error.
Compiler Error Message: CS0006: Metadata file `/tmp/<DOMAIN/>/<username/>-temp-aspnet-0/5ed74d00/App_global.asax_34cccb99.dll' could not be found
/Default.aspx
But it didn't have anything to do with precompiling but with a backslash in my username. I use likewise-open to login to a windows domain, so my username is <DOMAIN/>\<username/> while my home-directory is without a backslash: /home/likewise-open/<DOMAIN/>/<username/>. This difference or just the backslash itself caused mono not finding the compiled global.asax in the temp directory. If you look closely to the detailed output you see that the backslash \ in the out parameter is changed to a forward slash /:
dmcs /target:library /lib:"/home/likewise-open/<DOMAIN/>/<username/>/Documents/test9999/test9999/bin" /debug+ /optimize- /warn:4 /out:"/tmp/<DOMAIN/>\<username/>-temp-aspnet-0/5ed74d00/App_Web_17ca7bdd.dll" /r:"/usr/lib/mono/4.0/mscorlib.dll" /r:"/usr/lib/mono/gac/Microsoft.CSharp/4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll" /r:"/usr/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll" /r:"/usr/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll" /r:"/usr/lib/mono/gac/System.Web/4.0.0.0__b03f5f7f11d50a3a/System.Web.dll" /r:"/usr/lib/mono/gac/System.Data/4.0.0.0__b77a5c561934e089/System.Data.dll" /r:"/usr/lib/mono/gac/System.Web.Services/4.0.0.0__b03f5f7f11d50a3a/System.Web.Services.dll" /r:"/usr/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll" /r:"/usr/lib/mono/gac/System.Drawing/4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll" /r:"/usr/lib/mono/gac/System.EnterpriseServices/4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll" /r:"/usr/lib/mono/gac/System.IdentityModel/4.0.0.0__b77a5c561934e089/System.IdentityModel.dll" /r:"/usr/lib/mono/gac/System.Runtime.Serialization/4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll" /r:"/usr/lib/mono/gac/System.Xaml/4.0.0.0__b77a5c561934e089/System.Xaml.dll" /r:"/usr/lib/mono/gac/System.ServiceModel/4.0.0.0__b77a5c561934e089/System.ServiceModel.dll" /r:"/usr/lib/mono/gac/System.ServiceModel.Web/4.0.0.0__31bf3856ad364e35/System.ServiceModel.Web.dll" /r:"/usr/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll" /r:"/usr/lib/mono/gac/System.Web.Extensions/4.0.0.0__31bf3856ad364e35/System.Web.Extensions.dll" /r:"/usr/lib/mono/gac/System.Data.DataSetExtensions/4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll" /r:"/usr/lib/mono/gac/System.Xml.Linq/4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll" /r:"/usr/lib/mono/gac/System.ComponentModel.DataAnnotations/4.0.0.0__31bf3856ad364e35/System.ComponentModel.DataAnnotations.dll" /r:"/usr/lib/mono/gac/System.Web.DynamicData/4.0.0.0__31bf3856ad364e35/System.Web.DynamicData.dll" /r:"/usr/lib/mono/gac/System.Data.Linq/4.0.0.0__b77a5c561934e089/System.Data.Linq.dll" /r:"/usr/lib/mono/gac/System.Web.ApplicationServices/4.0.0.0__31bf3856ad364e35/System.Web.ApplicationServices.dll" /r:"/home/likewise-open/<DOMAIN/>/<username/>/Documents/test9999/test9999/bin/test9999.dll" /r:"/tmp/<domain/>/<username/>-temp-aspnet-0/5ed74d00/App_global.asax_34cccb99.dll" /nowarn:0169 /d:DEBUG -- "/tmp/<DOMAIN/>\<username/>-temp-aspnet-0/5ed74d00/App_Web_17ca7bdd_0.cs"
So:
/out:"/tmp/<DOMAIN/>\<username/>-temp-aspnet-0/5ed74d00/App_Web_17ca7bdd.dll
becomes
/tmp/<DOMAIN/>/<username/>-temp-aspnet-0/5ed74d00/App_global.asax_34cccb99.dll
If I copy the directory 5ed74d00 to /tmp/<DOMAIN/>/<username/>-temp-aspnet-0/ the application works as expected.
It took me almost 2 days to see this, so hopefully I can help others with this answer.
Do we have similar windows API of DebugBreak in Unix/ Linux. I want to debug a daemon process which should open NetBeans when DebugBreak statement is executed. Thanks in advance.
there is __builtin_trap() GCC intrinsic.
Whav! this is what I am looking for Embedded break points in C http://mainisusuallyafunction.blogspot.in/2012/01/embedding-gdb-breakpoints-in-c-source.html and to get sample program have a look in to https://github.com/kmcallister/embedded-breakpoints
I've been installing lispbuilder-sdl family with quicklisp and encountered error in sdl-gfx:
CL-USER> (ql:quickload "lispbuilder-sdl-gfx")
To load "lispbuilder-sdl-gfx":
Load 1 ASDF system:
lispbuilder-sdl-gfx
; Loading "lispbuilder-sdl-gfx"
...........;
; compilation unit aborted
; caught 1 fatal ERROR condition
Unable to load any of the alternatives:
("libSDL_gfx.dylib" (:FRAMEWORK "SDL_gfx"))
[Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]
I use slime+emacs+SBCL under macosx 10.6. I've installed SDL.framework from this link:
http://thirdcog.eu/apps/frameworks#glew
a file called sdl_with_friends.zip and put things under /Library/Frameworks. However it still complains about cannot find framework.
Any idea on this?
The easiest way to install lispbuilder-sdl on Mac OSX is to fire up SBCL and use Quicklisp:
(ql:quickload "lispbuilder-sdl")
It will probably fail, but you can then compile the OS-X specific helper library located in "~quicklisp/dists/quicklisp/software/lispbuilder-20110619-svn/lispbuilder-sdl/cocoahelper"; just cd to this directory and type "make"
To verify that worked, try this:
(ql:quickload "lispbuilder-sdl-examples")
(lispbuilder-sdl-examples:bezier)
Another common gotcha is when you are using Emacs / SLIME. The cocoa bits must run on the primary thread, so you have to invoke things like this:
#+darwin #+sb-thread
(let ((thread (first (last (sb-thread:list-all-threads)))))
(sb-thread:interrupt-thread thread #'(lambda () (ql:quickload "lispbuilder-sdl-examples")))
(sb-thread:interrupt-thread thread #'(lambda () (lispbuilder-sdl-examples:bezier))))
The error is complaining that it can't load the dynamic library for SDL. I'm sorry - I don't know much about the directory layout on macs (which appears to be where you're working), so I can't exactly tell you how to fix this. But somewhere you should have installed a file called libSDL_gfx.dylib (probably this extension) and the error message means that CFFI is failing to find it.
using homebrew you can brew install sdl_gfx
I'm having a weird issue with asdf-install.
* (require :asdf-install)
("ASDF-INSTALL")
* (asdf-install:install :split-sequence)
...
Installing /Users/zcai/.sbcl/SPLIT-SEQUENCE.asdf-install-tmp in /Users/zcai/.sbcl/site/,/Users/zcai/.sbcl/systems/
split-sequence/README.cCLan-install
split-sequence/split-sequence.asd
split-sequence/split-sequence.lisp
debugger invoked on a ASDF:MISSING-COMPONENT:
Component "split-sequence" not found
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY] Retry installation
1: [ABORT] Exit debugger, returning to top level.
((LAMBDA ()))
0]
The problem is that whatever package I'm trying to install, asdf-install will complain component with that package name is missing.
I'm not sure if this is a configuration problem or something else. I'm running 1.0.49 sbcl on OS X 10.6.
Any help would be appreciated.
Thank you.
UPDATE
I tried on a Ubuntu machine running sbcl 1.0.40. It does not have the same issue, maybe it's a bug of asdf that comes with sbcl 1.0.49?
UPDATE 2
I did a
(asdf-install:install :asdf-install)
Then it was able to install many packages without the earlier problem. But when I try to install :cffi, a dependency called "rf" case the same problem. Then I had to restart slime, and the installation will finish without a problem. Looks like it is something wrong with asdf-install then.
1- do NOT use ASDF-INSTALL. ASDF-INSTALL is obsolete and unmaintained.
2- Use Quicklisp.