asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[Asdf-devel] mkcl and asdf
by Faré 20 Apr '14

20 Apr '14

Dear JCB, I managed to compile MKCL from git, but only after I updated its ASDF. Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!) In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Compulsory apologies mostly train children to say things they don't mean — that is, to lie. ― Alfie Kohn, 'Unconditional Parenting'

3 11

[Asdf-devel] Please Review! Many updates to the documentation
by Robert P. Goldman 08 Apr '14

08 Apr '14

The version of the manual that's in the docs branch is good enough to release. For those who would like a look, but aren't interested in building it themselves, the current draft is on the web site at: http://common-lisp.net/project/asdf/draft-asdf-manual.pdf or you can navigate to it from the ASDF homepage. PLEASE, PLEASE, PLEASE, if you have a few cycles, I would be very grateful to anyone who would review the manual and send me suggestions or repairs. [If you want to submit patches, use the 'docs' topic branch.] I'm going to set up another test machine and do some hard-core testing this week, but after that we should release. That means testing the latest version of ASDF against your systems -- especially "dark" systems that aren't in Quicklisp or are for local use only -- would be A Great Thing. Best to all...

1 0

[Asdf-devel] :FORCE
by Robert P. Goldman 06 Apr '14

06 Apr '14

In the discussion of CLEAR-SYSTEM, I see the following parenthetical: (It was once conceived that one should provide a list of systems the recompilation of which to force as the @code{:force} keyword argument to @code{load-system}; but this has never worked, and though the feature was fixed in ASDF 2.000, it remains @code{cerror}'ed out as nobody ever used it.) Is that correct? I thought that :FORCE *did* accept these? I'm commenting this out for now.

2 1

[Asdf-devel] TEST-OP
by Robert P. Goldman 06 Apr '14

06 Apr '14

I have just pushed to the docs topic branch a complete rewrite of the recommendations for TEST-OP. I think this rewrite better maintains abstraction, because the testing methods are on the test library, rather than on the library to be tested. I also explained why one should have a separate test library. I have abandoned any attempt at ASDF 2 compatibility, also. It makes the presentation too cumbersome and twisty. I welcome inspection of this changed definition and suggestions for improvement. Best, r

2 1

[Asdf-devel] LOAD-SOURCE-OP
by Robert P. Goldman 06 Apr '14

06 Apr '14

The documentation of LOAD-SOURCE-OP seems contradictory. At first it says that loading source only (and never compiling) is "not workable." But later it describes LOAD-SOURCE-OP as doing just exactly the thing that we say is unworkable. If that is not what LOAD-SOURCE-OP does, what *does* it do? thanks, r

2 1

[Asdf-devel] Chipping away at the manual
by Robert P. Goldman 06 Apr '14

06 Apr '14

If you are interested in the current status, see the 'docs' topic branch. You will see there some work products, particularly a marked up copy of the old manual, with my thoughts about what needs to be done, and a ledger of exported symbols, which should be documented in the manual. Comments and suggestions welcomed. Patches also welcomed, but for that perhaps it's best you contact me. I'd be happy to cede parts of the manual to others. Best, r

2 3

[Asdf-devel] syntax control
by Faré 03 Apr '14

03 Apr '14

Dear CL hackers, compile-file and load already bind *readtable*, which means that for asdf itself to bind *readtable* should be a no-op in the common case, and a BIG save for those who want to switch the readtable at the REPL. In its current state, the syntax-control branch does just that, but it also defines several mechanisms by which the user can do more than that: 1- by setting the *cl-reading-hook* to something else than call-with-shared-readtable you can do less (setting the hook to just call-function), or more (setting it to call-with-asdf-syntax or even call-with-standard-io-syntax). 2- by defining per-system variables with :variables ((a . ainitfun) (b . binitfun) ...) where ainitfun is evaluated by call-function which allows for easy constants such as nil or t, or late-reading of the function definition as in "(lambda () future-package:*variable*)" 3- by defining methods on call-with-action-context (o c thunk), which should be chained according to the pattern (defmethod call-with-action-context ((o my-op) (c my-comp) thunk) (call-next-method o c #'(lambda () (some-wrapping around (call-function thunk))))) so that we don't have to define a magic method combination which might not work on all implementations. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You live and learn. Or you don't live long. — Robert Heinlein, "Time Enough For Love"

4 5

Re: [asdf-devel] ASDF:SYSTEM-RELATIVE-PATHNAME in deployment scenarios
by Erik Huelsmann 04 Apr '13

04 Apr '13

Resending in order to get the message on asdf-devel@ On Thu, Apr 4, 2013 at 11:33 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi, > > > Today Mark and I were discussing the new ASDF3 capabilities which should > help with deployment: the monolithic-fasl-op, binary-op and others. > > While I do see lots of potential for the monolithic fasl op for code-only > deployment situations, Mark and Anton brought up scenarios where a system > may consist of code and resources. The code may choose to access such > resources at run time through the use of the SYSTEM-RELATIVE-PATHNAME > facility. > > Because I don't have an immediate answer myself yet (I'm just now learning > about this facility), I'm directing our discussion to asdf-devel@. How do > see this scenario? > > > Bye, > > Erik. >

2 1

Re: [asdf-devel] [armedbear-devel] ASDF-JAR vs ASDF3 deployment support
by Mark Evenson 04 Apr '13

04 Apr '13

On 4/4/13 12:39 PM, Erik Huelsmann wrote: […] > Well, systems should declare the resources they want packaged into their > applications in their system files. That's a requirement both ECL and > ABCL now put forward, but I think other implementations which are able > to deliver more or less stand alone programs would want the same. Updating the ASDF documentation on how to use the new ops as well as recommendations for ASDF definitions would be good steps in this direction. When time and resources are available, of course… […] > But because "universal distribution" (i.e. for the majority of users of > a given system) has more-or-less subsumed by Quicklisp, there is no real > constraint on the developers of system definitions to ensure that all > components are so enumerated: loading the system from Quicklisp works > so nothing is broken, right? > > > Surely we can add tests for that in cl-test-grid as well? Maybe we could implement an ASDF/LINT that checks the "well-formedness" of a given .asd file, reporting potential problems? Conceptually such checking needs to be maintained "closer" to ASDF than CL-TEST-GRID. Implementation is the sincerest form of flattery, of course… […] > And even if one discarded this possiblity, often > directory hierarchies share multiple ASDF definitions, so one would > package "source" components that aren't really source components. > > > I'm sorry, I don't understand this bit. Could you try to explain your > concern with different words? Think of the ABCL-TEST-LISP definition in abcl.asd: it only references files in the test/lisp/abcl sub-directory. So, if one one were to treat the pathname of the .asd file it is defined in, one would include the abcl Java source, possibly the build artifacts, etc. which is probably not what one wants. Or consider CFFI with the cffi-ffi.asd definition, which needs one specific subdirectory. > So, assuming that "deployment outside of Quicklisp from an ASDF > definition" would be a greater good for the community, we seem to be > stuck at a bootstrap problem. I can't think of a way to force ASDF > authors to enumerate their static components, but until such enumeration > is widespread, I can't demonstrate its utility by developing an > ASDF/BUNDLE operation. > > > Well, there is no need to develop the ASDF/BUNDLE operation: Fare did. > Buth other than that, the fact that I can now succesfully package > bordeaux-threads which we couldn't with ASDF-JAR, I think this is really > a step ahead? Conceptually, it sounds like a step ahead but how do I use it. Could you write up a quick document on how to use it? I'm still not sure how things like ASDF:SYSTEM-RELATIVE-PATHNAME would work in the monolithic fasl scenario, so I would like to get my hands dirty a bit here. > > Any ideas? > > > [I actually started writing this mail bottom to top, so what's below may > be a reiteration...] > > Well, the great thing about the solution that Fare has now rolled out is > that I was able to package and load Bordeax-threads even though it is > problematic because it uses the #. reader macro and does not include the > version.lisp-sexp in the ASDF definition... > > The infrastructure I've added to ABCL has been hooked up into ASDF with > his new release. Much more doesn't seem to be required to get it all > correctly packaged. Package providers can simply use #. reader macros to > inject the list of :static-files they need to be distributed with their > code and asdf will pick it up. We'll need to work and test ASDF + ABCL > to see if everything works as intened though. And then deprecate ASDF-JAR? In some ways, I thought that being able to present ABCL components as jar files (abcl.jar, abcl-contrib.jar, hunchentoot-all-1.2.14.jar) would be a more natural fit to typical Java server deployment scenarios. Other than this more natural fit to JVM deployments (whereby the pointy-headed boss would be none-the-wiser as "everything just looks like jar dependencies") the only advantage of using a jar format that still might exist would be to leverage the ["One Jar" approach][one-jar] to actually use a custom classloader to make JVM artifacts (libraries, resources, etc.) packaged in the deployment as well. With this sort of approach we could include the jna.jar needed for CFFI in the deployment artifact, as opposed to needing to override going for the resolving the Maven dependency at deployment runtime. [one-jar]: http://one-jar.sourceforge.net/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

Re: [asdf-devel] [armedbear-devel] ASDF-JAR vs ASDF3 deployment support
by Mark Evenson 04 Apr '13

04 Apr '13

On 4/4/13 12:44 AM, Anton Vodonosov wrote: […] > General note about deployment CL systems. > > Often the deployment package should contain not only compiled code, > but also resources: web libraries and frameworks often contain .css, > .html, .javascript; bordeaux-threads uses version.lisp-sexp files, > and so on. > > In addition to the #. reader macro as used in bordeaux-threads, > applications/libraries access their resources during run-time using > asdf:system-relative-pathname or similar functions. In other words, > such libraries assume presence during run-time of their full source > control checkout . > > A general purpose deployment solutions should account this aspect. > > One way to deploy applications with full content of the dependencies > code and resources: > 1. install quicklisp in a custom directory, > 2. (ql:quickload :my-application) > 3. copy the directory of my-application, the custom quicklisp > directory and probably prebuild .fals files to server. > > A little bit more docs and example of this approach is here: > https://github.com/avodonosov/heroku-buildpack-cl2 In my opinion of "the right way", system definitions should contain a comprehensive listing of all the resources in the DEFSYSTEM form. Anything referenced by ASDF:SYSTEM-RELATIVE-PATHNAME or as a target of a CL:SHARPSIGN-DOT reader macro should be declared as a STATIC-FILE ASDF component. If this were somehow universally the case, then we could reliably use the machinery of ASDF3 to transverse its components, and determine both the "source" and the "compiled" components. But because "universal distribution" (i.e. for the majority of users of a given system) has more-or-less subsumed by Quicklisp, there is no real constraint on the developers of system definitions to ensure that all components are so enumerated: loading the system from Quicklisp works so nothing is broken, right? After Xach, Anton probably has the most practical experience with packaging ASDF definitions for deployment due to his pioneering work on CL-TEST-GRID. I find Anton comments to be a succinct summary of the issues involved in packaging a given ASDF system in Quicklisp. But when facing deployment for an ASDF system that is not in Quicklisp, but has dependencies on Quicklisp systems, Anton's approach won't work so well. One would have to find the .asd definition on the filesystem, then transverse its sub-directories to find the source files. This has the problem that there is no guarantee that the components of an asd definition exist in subdirectories, as theoretically the PATHNAME could point to an ancestor. And even if one discarded this possiblity, often directory hierarchies share multiple ASDF definitions, so one would package "source" components that aren't really source components. So, assuming that "deployment outside of Quicklisp from an ASDF definition" would be a greater good for the community, we seem to be stuck at a bootstrap problem. I can't think of a way to force ASDF authors to enumerate their static components, but until such enumeration is widespread, I can't demonstrate its utility by developing an ASDF/BUNDLE operation. Any ideas? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel