Hi all,
With support for CloserMOP now almost released (great job! Thanks Rudi, Pascal and everybody who helped out!), I'm looking forward to see how we can run more quicklisp packages.
If you look at http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.ht... and the load failures recently published for 1.2.0, you'll see that the root blockers now (apart from cl-glfw-opengl-corehttp://cl-test-grid.appspot.com/blob?key=1fgcximsyj which fails due to a missing dynamic library) portability libraries: uffi, iolib.base, kmrcl, acl-compat and metatilities.
Seems we're looking for people who want to submit portability code to these projects!
Bye,
Erik.
09.06.2013, 22:43, "Erik Huelsmann" ehuels@gmail.com:
Hi all,
With support for CloserMOP now almost released (great job! Thanks Rudi, Pascal and everybody who helped out!), I'm looking forward to see how we can run more quicklisp packages.
If you look at http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.ht... the load failures recently published for 1.2.0, you'll see that the root blockers now (apart from cl-glfw-opengl-core which fails due to a missing dynamic library) portability libraries: uffi, iolib.base, kmrcl, acl-compat and metatilities.
Seems we're looking for people who want to submit portability code to these projects!
Bye,
Erik.
Hint: to find out what systems are blocked by these failing libraries use quicklisp:who-depends-on:
(quicklisp:who-depends-on "iolib.base") => ("cl-inotify" "iolib" "iolib-tests" "iolib.examples" "iolib.multiplex" "iolib.os" "iolib.pathnames" "iolib.sockets" "iolib.streams" "iolib.syscalls" "iolib.trivial-sockets")
It returns ASDF systems directly depending on "iolib.base". If you want transitive dependencies, there is an utility in test-grid-reporting module:
(tg-reporting::dependents "iolib.base") => ("iolib.syscalls" "zeromq" "iolib.pathnames" "cl-v4l2" "iolib.multiplex" "iolib.streams" "iolib.sockets" "cl-popen" "iolib.os" "iolib.trivial-sockets" "iolib" "ucw.mod-lisp" "ucw.iolib" "clavatar" "cl-mw" "hinge" "inotify" "clws" "iolib-tests" "scriptl" "dbus" "clonsigna" "sw-http" "iolib.examples" "cl-mw.examples.higher-order" "cl-mw.examples.argument-processing" "cl-mw.examples.ping" "cl-mw.examples.hello-world" "cl-mw.examples.monte-carlo-pi" "cl-mw.examples.with-task-policy" "scriptl-examples" "cl-popen-test" "hemlock.base" "hu.dwim.util+iolib" "hu.dwim.logger" "hemlock.tty" "hemlock.clx" "hemlock.qt" "hu.dwim.util.temporary-files" "hu.dwim.walker.test" "hu.dwim.delico.test" "hu.dwim.util.soap" "hu.dwim.reiterate+hu.dwim.logger" "hu.dwim.util.error-handling" "hu.dwim.computed-class" "hu.dwim.util.zlib" "hu.dwim.logger.test" "hu.dwim.util.standard-process" "hu.dwim.logger+swank" "hu.dwim.partial-eval" "hu.dwim.rdbms" "hu.dwim.util.error-handling+swank" "hu.dwim.util.worker-group" "hu.dwim.rdbms.sqlite" "hu.dwim.rdbms.postgresql" "hu.dwim.rdbms.test" "hu.dwim.rdbms.oracle" "hu.dwim.rdbms.sqlite.test" "hu.dwim.rdbms.postgresql.test" "hu.dwim.rdbms.all" "hu.dwim.rdbms.oracle.test" "hu.dwim.rdbms.all.test" "hu.dwim.computed-class+hu.dwim.defclass-star" "hu.dwim.computed-class.test" "hu.dwim.computed-class+swank" "hu.dwim.perec" "hu.dwim.perec+iolib" "hu.dwim.perec.oracle" "hu.dwim.perec+swank" "hu.dwim.perec.sqlite" "hu.dwim.perec+hu.dwim.quasi-quote.xml" "hu.dwim.perec.postgresql" "hu.dwim.perec.all" "hu.dwim.partial-eval.test" "hu.dwim.util.authorization")
Those are ASDF system depending directly or indirectly on "iolib.base". If you want only prject names:
(tg-reporting::project-names (tg-reporting::dependents "iolib.base")) => ("cl-zmq" "cl-v4l2" "ucw" "clavatar" "hinge" "inotify" "clws" "dbus" "clonsigna" "sw-http" "iolib" "cl-mw" "scriptl" "cl-popen" "hemlock" "hu.dwim.walker" "hu.dwim.delico" "hu.dwim.reiterate" "hu.dwim.logger" "hu.dwim.rdbms" "hu.dwim.computed-class" "hu.dwim.perec" "hu.dwim.partial-eval" "hu.dwim.util")
(tg-reporting::project-names (tg-reporting::dependents "uffi")) => ("html-sugar" "cl-ncurses" "linedit" "clot" "cl-gd" "bknr-web" "cl-syntax" "cl-migrations" "clack" "clsql-fluid" "clsql-orm" "hyperobject" "umlisp-orf" "data-table" "clsql-helper" "cl-csv" "clsql" "umlisp" "cl-gene-searcher" "cl-twitter" "elephant" "weblocks")
(tg-reporting::project-names (tg-reporting::dependents "kmrcl")) => ("pubmed" "cluck" "cl-modlisp" "cl-rss" "rlc" "tbnl" "cl-base64" "kmrcl" "cl-photo" "umlisp-orf" "hyperobject" "clack" "umlisp" "cl-markdown" "lml2" "tinaa")
(tg-reporting::project-names (tg-reporting::dependents "acl-compat")) => ("mtlisp" "org-davep-dict" "postoffice" "org-davep-dictrepl" "pubmed" "cl-rss" "cl-geocode" "portableaserve" "bknr-web" "genworks-gdl" "wuwei" "cl-quakeinfo" "html-sugar")
(tg-reporting::project-names (tg-reporting::dependents "sclf")) => ("mime4cl" "html-sugar" "net4cl" "clot" "metafs" "binge" "ods4cl" "cobstor" "smtp4cl" "clpmr")
(tg-reporting::project-names (tg-reporting::dependents "mcclim")) => ("phemlock" "climacs" "beirc" "mcclim" "gsharp")
(tg-reporting::project-names (tg-reporting::dependents "static-vectors")) => ("cl-nxt" "antik" "fast-io" "gsll" "cl-libusb" "common-lisp-stat")
As a CL user I can suggest another perspective to increase adoption of a CL implementation: improving developer experience. Good slime integration, fast slime (fuzzy) competions, convenient sldb debugger, with local variables and so on.
Today ABCL is not bad from this perspective: slime competion work (speeding them up will be good though), slime functions argument hints work, slime-go-to-definition work. But of course there are always room for improvement. For me as a developer the dev enviroment convinience and development speed is more important even than execution speed of my code. So, after fixing the important libraries, you could probably consider development convenience as and area for attention.
Best regards, - Anton
Hi Anton,
Thanks for the explanation on how to grovel ASDF dependencies!
As a CL user I can suggest another perspective to increase adoption of a CL
implementation: improving developer experience. Good slime integration, fast slime (fuzzy) competions, convenient sldb debugger, with local variables and so on.
Today ABCL is not bad from this perspective: slime competion work (speeding them up will be good though), slime functions argument hints work, slime-go-to-definition work. But of course there are always room for improvement. For me as a developer the dev enviroment convinience and development speed is more important even than execution speed of my code. So, after fixing the important libraries, you could probably consider development convenience as and area for attention.
Right. Completely agreed. I have had ideas how to work on this for quite some time now. However, since the actual number of ABCL users has been fairly low (and the ones that did, seemed to get by with what's there), increasing library support seemed to be the best investment. Now that that's come such a long way, it does seem right to divert our attention to other problems indeed. So far, it's always been my intent to make it work on compiled code. However, maybe it's better to make it work on interpreted code first and only *then* move it to compiled code since that will mean quite a bit of impact on the compiler as well. (The compiler is structured around java stack frames, which don't take LET or M-V-B blocks into account.
Best regards,
- Anton
Bye,
Erik.
armedbear-devel@common-lisp.net
-
Anton Vodonosov -
Erik Huelsmann