asdf-devel September 2016

asdf-devel@common-lisp.net

16 participants
35 discussions

Re: Windows problems: moratorium continues
by Robert Goldman 14 Sep '16

14 Sep '16

On 9/14/16 Sep 14 -6:14 AM, Faré wrote: > I don't know whether that would help on Windows, but I have a fix for > the require-system function that hopefully makes test-force stable, in > !16 on gitlab. Mostly I'm working my way back through history, then forward. 3.1.7.16 was broken because of the typo. 3.1.7.17 has the typo fixed, but fails test-clean-load on ecl_bytecodes. I believe that this is spurious, though. It's crashing on the code that hooks into REQUIRE, and it crashes only when run as make test-clean-load l=ecl_bytecodes and NOT when run as run-tests.sh -c ecl_bytecodes Here's the error: An error occurred during initialization: In form (PROGN (PUSHNEW '("fasb" . SI:LOAD-BINARY) *LOAD-HOOKS* :TEST 'EQUAL :KEY 'CAR) (UNLESS (ASSOC "asd" *LOAD-HOOKS* :TEST 'EQUAL) (APPENDF *LOAD-HOOKS* '(("asd" . SI:LOAD-SOURCE)))) (DEFVAR *WRAPPED-MODULE-PROVIDER* (MAKE-HASH-TABLE)) (SETF (GETHASH 'MODULE-PROVIDE-ASDF *WRAPPED-MODULE-PROVIDER*) 'MODULE-PROVIDE-ASDF) (DEFUN WRAP-MODULE-PROVIDER (PROVIDER NAME) (LET ((RESULTS (MULTIPLE-VALUE-LIST (FUNCALL PROVIDER NAME)))) (WHEN (FIRST RESULTS) (REGISTER-PRELOADED-SYSTEM (COERCE-NAME NAME))) (VALUES-LIST RESULTS))) (SETF *MODULE-PROVIDER-FUNCTIONS* (LOOP :FOR PROVIDER :IN *MODULE-PROVIDER-FUNCTIONS* :COLLECT (ENSURE-GETHASH PROVIDER *WRAPPED-MODULE-PROVIDER* #'(LAMBDA (MODULE-NAME) (WRAP-MODULE-PROVIDER PROVIDER MODULE-NAME)))))) Wrong number of arguments passed to function NIL.. I have checked what I thought was the obvious hypothesis: a NIL in *MODULE-PROVIDER-FUNCTIONS* -- but that is not the cause. And why the intercession of "make" should matter, I cannot say. I'm just not sure if there's any version that passes the tests on Windows since 16 August 2016. I'll have another look, but may have to give up the bisect strategy and just try to fix the head. This is obviously deeply undesirable. But bisect assumes that I can detect the interesting failures in a hill-climbing way, whereas here we have multiple points at which breakage has been introduced. Unfortunately, unlike on Mac and Linux, I have absolutely no clue how to automate Windows testing, which leads to these messes, which are precisely what continuous integration is supposed to avoid. best, r > > > On Tue, Sep 13, 2016, 23:05 Robert Goldman <rpgoldman(a)sift.net > <mailto:rpgoldman@sift.net>> wrote: > > Unfortunately, the last time I was able to run the Windows tests before > 2 days ago was in mid-August. Since then, there have been a flurry of > commits, many of which could have impacted the state of > test-force.script. > > Indeed, test-force.script *itself* has changed, so that, although we > call it a "regression test," we have no reason to believe that it *ever* > worked on Windows in its present form. > > Unfortunately, it may take me a while to get enough bisecting done to > figure out when we jumped the rails. I'll keep everyone posted, but in > the meantime, we should consider the repo locked against more changes. > Windows is badly broken, and we shouldn't be trying to move forward > again until we have restored function on this platform. > > thanks, > r > >

3 7

ASDF master head with attached patches passes all tests on MKCL master head!
by Jean-Claude Beaudoin 14 Sep '16

14 Sep '16

Hello ASDF-devs, After pulling all latest commits from ASDF master and thus having a ASDF 3.1.7.19 that git describes as "debian/2%3.1.5-1-514-g7b7b9f0", and patching it with the two attached patches, and using an mkcl from its latest github master head, I then get the following result: -#--------------------------------------- Using /home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/../../bin/mkcl Ran 61 tests: 61 passing and 0 failing all tests apparently successful -#--------------------------------------- ./test/run-tests.sh -c mkcl GOOD: Loading ASDF on mkcl produces no message ./test/run-tests.sh -l mkcl Loading all these systems: ;;; Loading "/home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/build/asdf.lisp" Done! Script succeeded

3 2

Test results
by Robert Goldman 13 Sep '16

13 Sep '16

I ran the tests again on all three platforms. Linux: Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block: ;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t) I do *not* see this on ECL non-bytecodes. The tests here fail as before. Windows: Allegro, ccl, ECL-bytecodes, and SBCL all fail test-force. ECL-bytecodes also fails test-run-program. These seem to be failing here: (DBG "Check that require-system of touched .asd will reload the asdf.") (DBG "(That's what it does now, but if it could be fixed that'd be nice.)") (unset-asdf-cache-entry '(locate-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf/force")) (touch-file "test-asdf.asd" :timestamp (+ 10000 (get-file-stamp file1))) (require-system 'test-asdf/force) (assert-equal (asymval :*times-loaded* :test-asdf-system) 2) Looks like *TIMES-LOADED* is evaluating to 1 instead of 2. Anyone know why this would have changed? Mac: Everything passes. Thx, r

3 12

[rfc][merge request]
by Daniel Kochmański 13 Sep '16

13 Sep '16

Dear all, me and Fare clearly can't reach a consensus about the changes I've recently proposed to ASDF: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/13 I acknowledge a possibility, that I'm totally wrong here (and if that's true, my deepest apologies to Fare for using vast amount of his time), but my conviction is that this is a step forward and a good proposition. I would appreciate 3rd party opinions, because I'm clearly not objective here since I've wrote the code in question. The code isn't in final shape yet, but it proves no regressions wrt tests shipped with ASDF right now (tested on ABCL, CCL, ECL, SBCL 1.2.0, SBCL and MKCL). I'm planning to write a proper regressions and feature tests and document the behaviour in question in the manual, but only if there is sense in it (i.e it will be merged after fixing the potential issues). Thanks, Daniel Kochmański -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

4 3

Moratorium on ASDF commits, please!
by Robert Goldman 12 Sep '16

12 Sep '16

I'm seeing a lot of failures on Windows. I'd like to take stock of this before anything more gets changed. thanks, r

1 0

ASDF compilation on MKCL now broken for version currently on gitlab master head.
by Jean-Claude Beaudoin 12 Sep '16

12 Sep '16

Hello ASDF-devs, I'd like to inform you that the recent commit Make module provider wrapping idempotent <https://gitlab.common-lisp.net/asdf/asdf/commit/016d6baec89099f369452446c18…> has introduced new issues in the ASDF code such that it does not compile anymore on MKCL. There seems to be at least 2 issues, both in footer.lisp. First, in the call to define-package, symbol *load-hooks* should not be looked at in package :mk-ext since it does not exist there but rather in package :si, as the following form seem to acknowledge. Second, the call to ensure-gethash crashes with what seems as an attempt to funcall/apply a function to the wrong number of arguments. This is pretty much a show stopper on running the test suite with MKCL on the recent ASDF modifications. Regards, JCB

2 1

[bundles][fixes]
by Daniel Kochmański 10 Sep '16

10 Sep '16

Hey, Here are some fixes for a few problems with bundles (especially making a prebuilt system library a requirement – i.e sb-bsd-sockets or asdf) and cleaned up the code a bit. Moreover I've enabled load-bundle-op as a default load operation for ECL and its descendants and removed a deprecated function `bundle-system'. Also the "deprecation" comment is removed from `make-build' – IMO it's totally legit function for ASDF and is part of the ECL build system (thereof frequently used). Also I've found a problem with monolithic-dll-op (test-bundle.script) when running tests the second time, but it's not a regression (it was present before this patches). I'll probably investigate it soon. Patches attached below (inlined). Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

2 4

RUN-PROGRAM and error output
by Jason Miller 09 Sep '16

09 Sep '16

Hi, A lot of times the most useful information when an external program returns an error is the stderr output. However, I can't figure out any way to get this without setting :ignore-error-status to T. In particular I feel things would be strictly better if every invocation of the form: (run-program ... :error-output t) Acted more like: (let ((result (multiple-value-list (run-program :error-output t :ignore-error-status t)))) (when (not (zerop (caddr result))) (cerror ...)) (values-list result)) The former prints no output to *error-output* in the event of non-zero return, but the latter prints all the output. There may be a better way of doing this (including the error file or output in the condition object perhaps?), so I'm open to alternatives. Any thoughts? -Jason

2 2

Question about resolving "symlink/.."
by Jared C. Davis 08 Sep '16

08 Sep '16

Hi, I have set up the following directory hierarchy: lstest-dir | +---+------------------+ | | subdir1 subdir3 ---symlink---+ | | +-+---------+ | | | | xxxdir subdir2 <----------------------+ | | xxx.txt yyydir | yyy.txt On my linux system, shell commands like "ls" seem to resolve paths such as "lstest-dir/subdir3/.." to "lstest-dir/subdir1". For instance: $ ls lstest-dir/subdir3/../xxxdir xxx.txt In other words, when a path goes through "<symlink>/..", it seems to be resolved by first following the symlink, then finding the parent directory of the symlink's target. However, it appears that uiop:ensure-directory-pathname resolves ".." in a different way. For instance, on CCL on Linux, when I run: (uiop:ensure-directory-pathname (uiop:parse-native-namestring "lstest-dir/subdir3/..")) I get #P"lstest-dir/" instead of #P"lstest-dir/subdir1". Is there a way to configure ensure-directory-pathname to use a more shell-like behavior, or some other alternative that I might run to preprocess the path to resolve these obscure cases like the shell does? Thanks, Jared -- Jared C. Davis <jared.c.davis(a)gmail.com> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/

2 1

[haiku][patch]
by Daniel Kochmański 08 Sep '16

08 Sep '16

Hey, I've recently worked a bit to get ECL working on Haiku platform. To make ASDF work there, I had to patch the os-detection part of UIOP to recognize the platform. Patch is very minimal: -- CUT HERE -- >From ea6c95dc35fe3a71912fd6f43c4b704e70d35ac3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Kochma=C5=84ski?= <daniel(a)turtleware.eu> Date: Tue, 6 Sep 2016 21:33:10 +0200 Subject: [PATCH] detect-os: add haiku os --- uiop/os.lisp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/uiop/os.lisp b/uiop/os.lisp index 31e1583..85bd56a 100644 --- a/uiop/os.lisp +++ b/uiop/os.lisp @@ -55,13 +55,18 @@ keywords explicitly." "Is the underlying operating system an (emulated?) MacOS 9 or earlier?" (featurep :mcl)) + (defun os-haiku-p () + "Is the underlying operating system Haiku?" + (featurep :haiku)) + (defun detect-os () "Detects the current operating system. Only needs be run at compile-time, except on ABCL where it might change between FASL compilation and runtime." (loop* :with o :for (feature . detect) :in '((:os-unix . os-unix-p) (:os-macosx . os-macosx-p) (:os-windows . os-windows-p) - (:genera . os-genera-p) (:os-oldmac . os-oldmac-p)) + (:genera . os-genera-p) (:os-oldmac . os-oldmac-p) + (:haiku . os-haiku-p)) :when (and (or (not o) (eq feature :os-macosx)) (funcall detect)) :do (setf o feature) (pushnew feature *features*) :else :do (setf *features* (remove feature *features*)) -- 2.9.3 -- CUT HERE -- I did run ASDF tests - 6 failures (attached). ASDF performs well with Quicklisp and loads basic systems. Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel September 2016