[armedbear-devel] Next steps on our way to usability

[Anton Vodonosov]

09.06.2013, 22:43, "Erik Huelsmann" <ehuels at 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.html and 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