syntax-control

2017-10-13 Thread Faré 
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• http://fare.tunes.org
Problem of the day: finding suction cups that don't suck.

Re: Debian package: signing-key.asc

2017-10-13 Thread Robert Goldman 

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

2017-10-13 Thread Robert Goldman 

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

2017-10-13 Thread Kambiz Darabi 
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

2017-10-13 Thread Ben Vulpes 
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