syntax-control
Due to the readtable bug in ASDF 3.3.0 I updated the "syntax-control" branch that for the last three years was supposed to solve all readtable bugs when building with ASDF. I merged 3.3.0.1 into the branch, but the branch itself is not ready for merging into master: it does either too much or too little, and must be either completed or simplified. I think it stands a better chance of bieng merged soon if it is simplified, so I re-read and re-wrote the documentation for what this branch should be doing, and detailed a "Proposal 1" for minimal changes to ASDF that would go a long way towards bringing sanity in builds of software that modify the syntax. I sollicit your feedback: https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Problem of the day: finding suction cups that don't suck.
Re: Debian package: signing-key.asc
On 13 Oct 2017, at 10:44, Kambiz Darabi wrote: Hello, there are questions from the Debian dev who helps publishing the package about the signing key which is in the debian/ subtree. Can someone please comment? Thank you Kambiz Hm. Is this because you are grabbing tar balls from there, and Debian would like to see those tar balls signed? I should probably modify the make script for releasing to make a pop signature for the tar balls and upload it. I don't really have the capability of going back to regenerate and sign the old tar balls I'm afraid. And anyway, I simply won't do it. I have no idea what key is stored at debian Cheers, r - Forwarded Message - From: "Sébastien Villemot" To: "Kambiz Darabi" Cc: 878...@bugs.debian.org Sent: Friday, 13 October, 2017 5:07:45 PM Subject: Re: Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility Also, there is a GPG key under debian/upstream/signing-key.asc, but I see no signature on upstream website (https://common-lisp.net/project/asdf/archives/). Am I missing something? Or should the key be removed? Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER
On 12 Oct 2017, at 12:09, 73budden . wrote: This tracing tool should help a lot. I believe this tool should be supplied by asdf team. Even I begin to be more positive towards efforts of ASDF team to clean up all the mess that was in ASDF initially, but obviously society is not quite happy with breaking changes, so some small tool with a good manual would make life easier. This will probably not happen for a while -- my work on other aspects, and just staying on top of bugs and testing takes most of the available time. But I think I can provide pieces of a recipe for this kind of debugging and if someone out there could give feedback, I will see to it that the recipe gets into the manual. I think if you want to see the plan that ASDF produces to perform a requested operation, you should use something like: ``` (setf *plan* (asdf/plan:make-plan nil (make-operation 'load-op) (find-system "sysname"))) ``` Then, to figure out what's happening, I would suggest ``` (trace asdf:operation-done-p) ``` ...to see if ASDF is wrong about whether or not it needs to do some operations. Then I would try something like tracing `PERFORM`. I'd have to think a little about what to do if `MAKE-PLAN` gives you a plan you don't expect. cheers, r Printing readtable before loading, I think, requires just a line or two. Dumping log of operations might be one (trace) call, so that's trivial for the person who knows how ASDF is organized. Writing a small two-paragraph addition to manual would relief a lot of pain and stress for all.
Debian package: signing-key.asc
Hello, there are questions from the Debian dev who helps publishing the package about the signing key which is in the debian/ subtree. Can someone please comment? Thank you Kambiz - Forwarded Message - From: "Sébastien Villemot" To: "Kambiz Darabi" Cc: 878...@bugs.debian.org Sent: Friday, 13 October, 2017 5:07:45 PM Subject: Re: Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility Also, there is a GPG key under debian/upstream/signing-key.asc, but I see no signature on upstream website (https://common-lisp.net/project/asdf/archives/). Am I missing something? Or should the key be removed? Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEU5UdlScuDFuCvoxKLOzpNQ7OvkoFAlng1sEACgkQLOzpNQ7O vkr1GxAAkOEUhLmOOHxIQE6/WWIWz5cxj77/Z3Dv2b6uHrljrS+GCWivzzcii9MD yJ3bjdj793MAVK4cXbLywxP5ZXQ9Aw65FuV+mi3kNa9lw3bvNFIbqsyckSgcL5Iz Q7BzUOyJiWOLVe7gOuTlHNDa+0eOvk0pycZ2QFI4nT7harAvj+9rlQW8IL7WwoDX XYDWD7TogpMDRBf0EUb32vYF2lVZomlO9KCU/mD3OmUnxmb9Zfwc23dsJcXCOcMZ 2d67F8sr0fuDZBgpPOHmPU2/+tr7GGlGNQoULML2D2XCawMK0LNBU+JfzZbOY0N/ br1yuIjhEbIlamId+/0q6aMcBZJGh+FxsEZVXQL7ULIP3N6USnhnHghZUNK/NpbU JUZGkrWFnSwC6kH7prMrbB/Jjia+CWDqqa/QIUQm9ixPIUj4VvZ29rnBht9lPq34 HgAYtZb08Xk9JJ9odHHg4HA5wpGTN2W/4DEiHqLfjwZSa3L2aq8NqPglAuDfJr/L kuGHxDXNTahxZHuh5BTREC+vVZekC7kgORffHvfVDma+iypW0xp9z/YZMHpxcG+z ZDDq8TDyOm2S4yIZDpc/LUbZnZyg4OnVDFC8JMMDt7HnD5otOe26HLlucXaPX3e3 9oJ7FnC13StJqdpwdG4NwlOQucl2S50ub0BNG4VJqQZgKibWp+I= =wDBH -END PGP SIGNATURE-
monolithic-concatenate-source-op misses a few dependencies
On SBCL 1.3.11, when producing a monolithic source concatenation with the library "Postmodern", asdf produces a file that needs a Lisp image to need manual calls to (require :usocket) and (require :md5) in order to load completely. Given: concatenatrix.asd as: (asdf:defsystem :concatenatrix :build-operation monolithic-concatenate-source-op :build-pathname "build/full-concatenation" :depends-on (:postmodern) :components ((:file "concatenatrix"))) concatenatrix.lisp as: (defpackage :concatenatrix (:use :cl :postmodern)) (in-package :concatenatrix) (defun wat (it) (format t "~A~%" it)) Concatenated sources produced with: (asdf:make :concatenatrix) Loading tested with: sbcl --noinform --disable-debugger --load build/full-concatenation.lisp Produces: Unhandled SB-C::INPUT-ERROR-IN-LOAD in thread #: READ error during LOAD: Package SB-ROTATE-BYTE does not exist. Line: 221, Column: 29, File-Position: 8706 Stream: # Backtrace for: # 0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK # #) 1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #) 2: (INVOKE-DEBUGGER #) 3: (ERROR #) 4: (SB-C:COMPILER-ERROR SB-C::INPUT-ERROR-IN-LOAD :CONDITION # :STREAM #) 5: (SB-C::%DO-FORMS-FROM-INFO # # SB-C::INPUT-ERROR-IN-LOAD) 6: (SB-INT:LOAD-AS-SOURCE # :VERBOSE NIL :PRINT NIL :CONTEXT "loading") 7: ((FLET SB-FASL::LOAD-STREAM :IN LOAD) # NIL) 8: (LOAD #P"build/full-concatenation.lisp" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :DEFAULT) 9: (SB-IMPL::PROCESS-EVAL/LOAD-OPTIONS ((:LOAD . "build/full-concatenation.lisp"))) 10: (SB-IMPL::TOPLEVEL-INIT) 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-90 :IN SB-EXT:SAVE-LISP-AND-DIE)) 12: ((LABELS SB-IMPL::RESTART-LISP :IN SB-EXT:SAVE-LISP-AND-DIE)) There is another complaint about usocket, which is confusing, as cl-postgres explicitly doesn't require usocket on sbcl by my read ( http://marijnhaverbeke.nl/git/?p=postmodern;a=blob;f=cl-postgres.asd;h=683edf0f131a4ebe172b44425f597d7f67656e70;hb=HEAD#l16 ). Loading is resolved by requiring both libraries in question, as: sbcl --eval "(require :md5)" --eval "(require :usocket)" --load build/full-concatenation.lisp Yours, Benjamin