asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

ECL on Windows
by Robert Goldman 19 Nov '16

19 Nov '16

I apologize, but I think I am going to have to proclaim ECL on Windows as officially unsupported by ASDF. There are underlying bugs in ECL on Windows that preclude ASDF functioning correctly. To the best of my knowledge, there isn't anyone able to maintain ECL on Windows, and given that, attempting to keep ASDF working on that platform just piles up failing tests. With apologies, as of now I am removing "ecl_bytecodes" from my Windows test suite (I was already unable to test vanilla ECL because of not having a C compiler on Windows). If there are patches available and a means of verifying them, I would like to see Windows ECL support come back, but at the moment the community seems entirely unable to support this platform. Note that ECL is still supported on Mac OS X and Linux.

1 0

Work-around built-in ~/common-lisp/ in search path?
by Robert Goldman 18 Nov '16

18 Nov '16

Here's my issue: 1. I have a bunch of lisp libraries that I use on everyday things installed in ~/common-lisp/. One of the systems in there is an older, modified version of fiveam that my company uses in many projects. 2. I have a project where we use libraries from quicklisp to make it easier to handle dependencies. For this project, I run a function that resets the ASDF source-registry, and uses a special copy of quicklisp (a copy that writes its systems in a different location). 3. I cannot build my system because the version of fiveam in ~/common-lisp/ shadows the version of fiveam from quicklisp, which I need. 4. I don't see any OBVIOUS way to tell ASDF to ignore my ~/common-lisp/ directory. I can do the following: (setf asdf:*default-source-registries* (remove 'asdf/source-registry::default-user-source-registry asdf:*default-source-registries*)) but that seems really hard-core. Would it be reasonable to make the defaults a little easier to override? Maybe something that's equivalent to --no-userinit and --no-sysinit when starting lisp -- something that will remove the user-specific entries or system-specific entries, respectively? I don't believe I can simply wipe the defaults, because then I might miss some SBCL libraries that come with the system default settings. Cheers, r

5 5

Misnamed secondary systems
by Faré 18 Nov '16

18 Nov '16

Starting with ASDF 3 (2013), ASDF officially supports "secondary systems", i.e. additional systems named in an asd, beside the main one. For the additional systems to be findable by ASDF, though, their name must be of the form "foo/bar" where "foo.asd" is the name of the file, and "foo" is called the primary system name. ASDF1 and ASDF2 would let you define those systems, as well as other systems of arbitrary names, but would be incapable of finding them. By badly copying each other, Lispers have developed a lot of misnamed secondary system the name of which doesn't match the pattern. I'd like to forbid such misnamed systems. Now a quick grepping through Quicklisp (see latest update to my ql-test) finds 233 .asd files with such misnamed secondary systems. Obviously it will take time to clean up the mess, so for after the next release, I'd like to signal a full WARNING when the condition is detected, and at some point, make that a CERROR, then later an ERROR. Cleaning up this mess will also prevent a subtle class of errors, such as when two .asd files define each other's systems (see test case test-mutual-redefinition.script in asdf/test). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Demand the establishment of the government in its rightful home at Disneyland.

4 6

test-run-program.script
by Robert Goldman 17 Nov '16

17 Nov '16

I see this in test-run-program: #+(and sbcl os-windows) (leave-test "SBCL won't let us pass unquoted arguments to cmd.exe" 0) #-(and sbcl os-windows) (progn (DBG "Testing echo ok 1 via run-program as a string") (assert-equal "ok 1" (dewindowize (run-program "echo ok 1" :output '(:string :stripped t))))) If we know that SBCL on Windows won't let us pass unquoted arguments to cmd.exe, should we raise a NOT-IMPLEMENTED-ERROR on that combination, and check for it in the test? Thanks, r

3 3

3.1.7.35 test status
by Robert Goldman 17 Nov '16

17 Nov '16

I show 3.1.7.35 passing all tests on Mac and Linux, failing test-require and test-run-program on ECL bytecodes on Windows. test-require is a long-standing ECL bug on Windows that Jason Miller has confirmed. There's a bug report in to ECL, so we don't have to worry about this. test-run-program shows a failure on run-program with a string argument versus with a list argument. Attaching a snippet of the transcript. I'd like to get this either fixed or dismissed as an ECL problem before we release. Cheers, R

2 2

Version 3.1.7.35 has been pushed
by Robert Goldman 17 Nov '16

17 Nov '16

This version contains many fixes to RUN-PROGRAM by Elias Pipping with support from Faré. Please try it out. Working towards a release of ASDF soon, so anything you could do to help iron out bugs would be very much appreciated!

5 7

Can we give up :INTERACTIVE I/O for RUN-PROGRAM?
by Robert Goldman 09 Nov '16

09 Nov '16

Interactive I/O is not reliable across implementations, and is also difficult to test. Do we really need to support this? If you, as a programmer, really want interactive I/O, you should probably write your own wrapper to manage I/O to the program. Some enterprising soul could even write a clone of "expect" for CL. I'd rather lose the :interactive option, than have it and have it work unreliably. So I'm soliciting comments -- particularly from those who think we should keep it. It seems like some people also have a means to search Quicklisp to screen suggestions like this. I'd also welcome feedback based on libraries in QL. thanks, r

2 1

Running tests with test coverage enabled
by Alexey Veretennikov 19 Oct '16

19 Oct '16

Hi all, Right now I'm running unit tests using Fukamachi's prove library: (asdf/operate:test-system 'my-system). I want to run my tests generating the tests coverage of my system. For this I would like to have similar operation, but which will: 1) turn on the code coverage in LispWorks (just call to some global function) 2) rebuild system which I want to test (in this case my-system), but only (!) this system (not dependencies) 3) run tests 4) call coverage results processing function. 5) on normal run (asdf/operate:test-system 'my-system) rebuild the system without coverage. How could I proceed with this task? -- Br, /Alexey

2 6

Recent disappearance of asdf:bundle-system.
by Jean-Claude Beaudoin 18 Oct '16

18 Oct '16

Hello ASDF devs, I noticed recently that asdf/bundle:bundle-system has disappeared from ASDF. MKCL is/was a user of that function as a convenient entry point to the ASDF bundle facility. My impression was that, along the lines of asdf:load-system and asdf:compile-system, asdf:bundle-system was playing a (small but) useful role as a convenience function. I will most probably simply have to fold that function inside the build code of MKCL if it is to be removed from ASDF for good. Yet, to see a publicly exported function disappear between version 3.1.7.10 and 3.1.7.12 to most likely result in a 3.1.8 release gives pause. Are we really seeing here a public API code breaking modification being done between two patch level releases? BTW, there seems to have been a few other MKCL related breakage issues introduced by the recent wave of changes. I will have to examine each one in turn... Cheers, JCB

6 12

poiu 1.31
by Faré 10 Oct '16

10 Oct '16

I was considering merging POIU into ASDF, or at least part of it: https://gitlab.common-lisp.net/qitab/poiu The part that I am really interested in merging is the plan that completely and correctly models the action graph based on an explicit graph (duh). This would be a prelude to allowing more meaningful queries on the build plan, but also hopefully to allowing better support for operate-in-operate as necessary for defsystem-depends-on and such. I just split poiu into multiple files, and added some docstrings, to get an idea of which part takes how much. These implement the aforementioned action graph (wc output), where queue would go to uiop (it could be stripped down a bit), and action-graph in asdf (with some more commenting needed): 123 591 4609 queue.lisp 186 764 8360 action-graph.lisp The parallelizing implementation (currently only for allegro, clisp, clozure, sbcl and only on unix) is this big (the first two files would go to uiop; the last part is the asdf-specific code and needs more commenting): 219 977 8972 fork.lisp 180 714 8362 background-process.lisp 145 533 6714 poiu.lisp This would have been a lot in the times of ASDF1 when ASDF was < 1000 loc (and then, the original POIU was even larger, for it needed to patch ASDF that was lacking suitable interfaces). But it's not that much now that ASDF is >12.5kloc. We've grown a lot, yet much slower than Moore's Law. So, should I import the first part of POIU? All of it? Is there anything bad about compiling in a fork, when available? Actually, I'm thinking the forking part should probably be left in an extension, since it won't be used in SLIME anyway, because SLIME uses threads, which invalidates the forking ability of POIU. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced misquotation is indistinguishable from an original statement. — John McCarthy, misquoted

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel