- asdf-devel - mailman3.common-lisp.net

Is program-op supported on Lispworks ?
by Didier Verna 20 Mar '21

20 Mar '21

Hi, sorry for asking, I can't test it locally (I only have the personal edition here). -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

"How-to" request
by Marco Antoniotti 20 Mar '21

20 Mar '21

Hi I am trying to create a new ASDF:OPERATION, but I must be missing something and the manual (or Google) does not seem to help much. How do you create a new operation, which may be quite simple? Or better, how do you get PERFORM and/or OPERATE to actually do something for you. I know I should RTFM, but in this case it is more of a RTFC, which is far more difficult. I tried the following (defclass my-op (non-propagating-operation) ()) (defmethod perform ((o my-op) (s system)) (print 42)) (defmethod operate ((o my-op) (s system) &key &allow-other-keys) (print 666)) But then, doing cl-user 42> (operate 'my-op (find-system "somesys") :bar 1024) #<MY-OP > #<ASDF/PLAN:SEQUENTIAL-PLAN 2301B97B> is all I get. Any tutorial or advice? Thanks -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

4 12

System cleanup
by Didier Verna 19 Mar '21

19 Mar '21

Hi, I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around? The relevant parts are as follows: :defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel)) and :components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) Thank you! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

4 12

Re: System cleanup
by Didier Verna 18 Mar '21

18 Mar '21

François-René ÐVB Rideau écrivait: > What more, even Xach seems to have miraculously seen the light: one > months and one week ago, he updated the fallback ASDF in Quicklisp > from 2.26 to 3.2.1! That's also what made me think I could perhaps do some clean up! > That was the first update of ASDF in Quicklisp since 2012, to a > version then-current, to a version 4 years old. By linear > extrapolation, we should expect the next update to happen in 2030, to > a version from 2022. I admit that I was thinking his next move would > be to downgrade ASDF to 1.369 (the last version before I took over). :-) :-) -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!

1 0

Where is my executable?
by Didier Verna 17 Mar '21

17 Mar '21

Hi, what's the proper way to find out where a dumped executable (resulting from a program-op) has landed? I would like to it to literally :move-here #p"./", to speak in MAKE-BUILD terms... Note that *I* know where it is in the cache; what I want is programmatic access to its location. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

3 3

Fighting with the CI....
by Robert Goldman 16 Feb '21

16 Feb '21

There was an oddball thing in the Makefile, and changing it broke the CI. I'm just fixing it up now, but please don't pull from master until you get further notice. If you *have* pulled from master today, please backup to 3.3.4.8 until further notice. Sorry for any inconvenience.

1 1

Upgrading/Installation Instructions Clarification
by Wilfredo Velazquez 21 Jan '21

21 Jan '21

Hello all, Moving this question from https://gitlab.common-lisp.net/asdf/asdf/-/issues/52 To reiterate, I believe that the instructions in https://common-lisp.net/project/asdf/asdf/Upgrading-ASDF.html 'Upgrading ASDF' could use some clarification. I am attempting to run a newer version of ASDF than that provided by my impl. The text I'm having issue with is: > If your implementation already provides ASDF 3 or later (and it should), but you want a more recent ASDF version than your implementation provides, then you just need to ensure the more recent ASDF is installed in a configured path, like any other system. We recommend you download an official tarball or checkout a release from git into ~/common-lisp/asdf/. > Once the source code for ASDF is installed, you don’t need any extra step to load it beyond the usual (require "asdf"): ASDF 3 will automatically look whether an updated version of itself is available amongst the regularly configured systems, before it compiles anything else. First, it says I should download an official tarball. I looked to the best of my ability and could not find one. Even if I had found one, I don't know what I'd do with it. So I moved to the second option and cloned ASDF to `~/common-lisp/asdf/` and built it successfully. I verify that indeed I am running a newer ASDF. However, I noticed `~/comon-lisp/asdf/ext/` includes certain third-party libraries bundled in the repo. These are being prioritized over Quicklisp libraries, and it's causing conflicts. So my question is: May I get clarification on how I may build & install ASDF such that the implementation-bundled one will automatically find the newer version, while omitting the libraries ext/ directory from being picked up? Thanks all! -- Wilfredo Velázquez-Rodríguez

4 10

uiop:launch-program fails to run sudo without -S
by Pierre Neidhardt 21 Jan '21

21 Jan '21

Hi! I'd like to run a "sudo" command from Common Lisp. The following works: --8<---------------cut here---------------start------------->8--- (uiop:launch-program '("sudo" "-S" "ls" "/root") :input :stream :output *standard-output*) (format (uiop:process-info-input #v1) "MY-PASSWORD~%") (finish-output (uiop:process-info-input #v1)) --8<---------------cut here---------------end--------------->8--- Note that I'm using the "-S" parameter of sudo. From the man page: > Write the prompt to the standard error and read the password > from the standard input instead of using the terminal device. Without it, "sudo" terminate immediately. Somehow, Emacs _does_ support calling the sudo process without the "-S" flag. Try this: --8<---------------cut here---------------start------------->8--- (make-process :name "dummy" :command '("sudo" "ls" "/root")) --8<---------------cut here---------------end--------------->8--- and the "sudo" process is kindly waiting for input in the background. Any idea why that is? Is it be possible to do the same in Common Lisp? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/

3 6

dump-image should not make CLISP images executable
by Pierre Neidhardt 07 Dec '20

07 Dec '20

Hi! I noticed a possible mistake in the dump-image code for CLISP: --8<---------------cut here---------------start------------->8--- (apply #'ext:saveinitmem filename :quiet t :start-package *package* :keep-global-handlers nil :executable (if executable 0 t) ;--- requires clisp 2.48 or later, still catches --clisp-x (when executable (list ;; :parse-options nil ;--- requires a non-standard patch to clisp. :norc t :script nil :init-function #'restore-image))) --8<---------------cut here---------------end--------------->8--- According to the documentation (https://clisp.sourceforge.io/impnotes/image.html) > When non-NIL, the saved file will be a standalone executable. In this > case, the #P".mem" extension is not added. On Win32 and Cygwin the > extension #P".exe" is added instead. Additionally, if this argument > is 0, the standard CLISP command line options will not be processed by > the executable but will be placed into EXT:*ARGS* instead. Here since we are setting `:executable` to 0 or t, the result is always executable. I don't think this is right because then the result cannot be loaded with `clisp -M path/ro/result`. I believe the fix would be ```diff - :executable (if executable 0 t) + :executable (if executable 0 nil) ``` Cheers! -- Pierre Neidhardt https://ambrevar.xyz/

4 8

Helper function to dump REPL-optimized core
by Pierre Neidhardt 30 Nov '20

30 Nov '20

Hi! Generating a core with pre-loaded packages (namely sb-bsd-sockets, sb-posix, sb-introspect, sb-cltl2, asdf) is a common optimization technique for faster REPL startups. The technique is detailed in the SLIME and SLY manuals. Some may argue that modern machines are fast enough. But from personal experience even on very fast hardware, I find that it makes for a much smoother experience, especially for people using SLIME / SLY as their shell :) I've implemented my own Emacs helper (https://github.com/joaotavora/sly/pull/366) but in https://bugs.launchpad.net/sbcl/+bug/1904042 it was suggested to bring the issue to ASDF which might be the most appropriate place where to share a helper for everyone, independently of the Lisp implementation or editor. So what about adding a function the would dump an optimized core a bit like I did in the SLY pull request: --8<---------------cut here---------------start------------->8--- (defvar *default-core-extra-modules* '(asdf)) (defun asdf:dump-core (&key (path *asdf-default-core-location*) (extra-modules *default-core-extra-modules*)) ... ;; Complete the extra-modules with implementation specific modules, as documented in the SLIME / SLY manuals. (cond ((sbcl-p) (append '(sb-bsd-sockets sb-posix sb-introspect sb-cltl2) extra-modules)) ((ccl-p) ... --8<---------------cut here---------------end--------------->8--- Then all the user would have to do is: --8<---------------cut here---------------start------------->8--- CL-USER> (asdf:dump-core) --8<---------------cut here---------------end--------------->8--- And restart their REPL, assuming they've configured their REPL to use this new core. It can also be useful to only replace an existing core if the modules or the Lisp version are different. This would allow the user to systematically run `asdf:dump-core` before starting their REPL, thus automatically ensuring they run an optimized core. --8<---------------cut here---------------start------------->8--- ;; In Emacs: (setq sly-lisp-implementations '((sbcl (lambda () (call-process "sbcl" nil t nil "--no-userinit" "--eval" "(require :asdf)" "--eval" "(asdf:core-dump)" "--quit") `(("sbcl" "--core" path-to-core)))))) --8<---------------cut here---------------end--------------->8--- Thoughts? -- Pierre Neidhardt https://ambrevar.xyz/

2 5