asdf-devel

asdf-devel@common-lisp.net

1376 discussions

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

Question about version in submitting patches
by Mark Evenson 27 Nov '20

27 Nov '20

I’m a little unsure of whether the “Committee for Ongoing and Perpetual ASDF maintenance” (hi Robert!) wishes us to include the results of “<file:bin/bump-version>” in submitted patches. I have a small ABCL-specific patch dealing with UIOP:PARSE-UNIX-NAMESTRING when loading system definitions from zip archives for which I have used bump-version to denote as version “3.3.4.0.1”. I’ve not quite finished my testing to ensure that previous versions of ABCL work well with it, but when I do, do you wish me to include the use of “bump-version” with the patch or is that something the Committee prefers to do on its own? yours, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

6 6

Unexpected error ..
by gwbennett 26 Nov '20

26 Nov '20

Good morning from Greg Bennett who is running sbcl 2.0.10 under linux mint 19.2 64-bit and using asdf 3.3.6 with mcclim from mcclim-20201016-git via quicklisp. I am working on a large project and wish to capture the results of a trial compile in a file so that I can check notes, warnings, errors, etc.. Such a compile essentially loops over a set of asdf load-systems. Not unnaturally for me, I make mistakes, and sometimes I get blocked by an unexpected error which I believe I have managed to isolate. I am quite unsure about the locus of the unexpected error .. asdf ? sbcl ? mcclim ? their interaction ? so I am starting with asdf-devel. I am uncertain how much to include by way of source files, so i have opted to summarise things here first. New sbcl 2.0.10 in emacs listener Load a set-up-file to ensure I am using asdf 3.3.6 [I gather this is significant for sbcl]. And some of my own logging tools. Two files attached. Load mcclim Running (in-package :cl-user) (a-l "mcclim" "doit" (doit) "Z" :base-name "/home/gwbennett/mcclim-code/") which has the effect of writing the results to a file, in this case /home/gwbennett/LOGS/MCCLIM/MCCLIM2020-lsbcl-to-Z-26-NOV-at-14:5:2.lsp" The process exits with: ; wrote /home/gwbennett/.cache/common-lisp/sbcl-2.0.10-linux-x64/home/gwbennett/mcclim-code/check-qmb/one/test-qmb-tmpJU0JWO19.fasl ; compilation finished in 0:00:00.051 ; No value Now suppose I do something which contains an error, such as CL-USER> (asdf-version) Since (asdf-version) is not in the cl-user package, this is an error. What I get back is a different error message: #<SB-SYS:FD-STREAM for "file /home/gwbennett/LOGS/MCCLIM/MCCLIM2020-lsbcl-to-Z-26-NOV-at-14:5:2.lsp" {1008BEC8A3}> is closed [Condition of type SB-INT:CLOSED-STREAM-ERROR] Which is my unexpected error. Sometimes after ABORT (twice), this error can block me from defining any new function or loading a new function .. all I receive is a repeat of this message. Thank you for your patience Cheers Greg Bennett

2 1

Looking for some ECL help...
by Robert Goldman 19 Nov '20

19 Nov '20

I have pulled in a patch independently derived by Luis Oliveira and Martin Simmons that fixes an issue with launch program. Unfortunately, the test I developed for it *reveals* an issue in ECL. Here's the report: https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/144 If anyone with ECL expertise has time to give a look into this, I would be grateful. Even if you just have time to tell me how to deal with ECL on this -- it's an issue of ECL not being able to read a pipe stream. Best, R

1 0

Jenkins expertise?
by Robert Goldman 17 Oct '20

17 Oct '20

Does anyone have expertise configuring Jenkins to run against a remote Gitlab install? If so, would you please reach out to me? I have *finally* restored some of my CI support for ASDF, but I don't know how to set up my Jenkins to run against merge requests on Gitlab (if that is even possible). I have a backlog of patches that I would like to get evaluated and merged, but could use some help with the automation. Thanks!

7 22

Don't follow symlinks in uiop:directory* on ECL
by Moritz Petersen 09 Oct '20

09 Oct '20

Hi, I recently noticed that directory* follows symlinks on ECL, whereas it would be desirable if it didn't. ECLs directory* function follows symlinks by default, but can be instructed not to. Please see below for the tweak and a suggested test case, which I based on test-symlink-loop.script. Thank you, Moritz Petersen

1 0

A CFFI -ASDF integration bug
by Ilya Perminov 28 Aug '20

28 Aug '20

Hi, I found a ASDF-related CFFI bug a couple of days ago. Can anyone think of a good way of fixing it? A method in grovel/asdf.lisp adds output files of process-op to output files of compile-op: ;;; Declare the .o and .so files as compilation outputs, ;;; so they get picked up by bundle operations. #.(when (version<= "3.1.6" (asdf-version)) '(defmethod output-files ((op compile-op) (c wrapper-file)) (destructuring-bind (generated-lisp lib-file c-file o-file) (output-files 'process-op c) (declare (ignore generated-lisp c-file)) (multiple-value-bind (files translatedp) (call-next-method) (values (append files (list lib-file o-file)) translatedp))))) As a result inputs and outputs of the ops look like this: process-op: input: wrapper-file output: bindings-file.lisp file.c FILE.O FILE.SO compile-op: input: bindings-file.lisp output: bindings-file.fasl FILE.O FILE.SO The problem is that process-op generates file.o and file.so before it generates bindings-file.lisp. Thus compile-op gets re-executed all the time, because its output files file.o and file.so are always older than its input file bindings-file.lisp. And an execution of the compile-op does not change anything, because it does not really generate .o and .so. One way to fix it would be to "touch" .o and .so to get the right order of file modification times, but there may be a better way. CFFI bug report: https://bugs.launchpad.net/cffi/+bug/1889491 Thanks, Ilya

4 11

← Newer
1
...
6
7
8
9
10
11
12
...
138
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel