drakma
drakma copied to clipboard
edicl
puri is bringing drakma down
There is a latent bug in puri that is being brought to the fore by the latest version of ASDF (3.3.0). Since drakma depends on puri, and since the ASDF team has no interest in keeping ASDF compatible with the bad behavior that puri exhibits, I thought you would be interested in an early warning.
With the latest version of asdf (3.3.0) puri no longer compiles. The following compiler error is thrown:
SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable. [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
In:
0: (SET-DISPATCH-MACRO-CHARACTER ## #\u #<FUNCTION PURI::SHARP-U> #<READTABLE {100002D6C3}>)
The code:
(defun sharp-u (stream chr arg) (declare (ignore chr arg)) (let ((arg (read stream nil nil t))) (if read-suppress nil (if* (stringp arg) then (parse-uri arg) else (internal-reader-error stream "#u takes a string or list argument: ~s" arg)))))
(set-dispatch-macro-character ## #\u #'puri::sharp-u)
Backing up to the next most recent release of asdf makes the problem go away:
dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1 dev-lisp/uiop-3.2.1:0
I think there is something nondeterministic in the loading of puri files that makes the issue intermittent. The ASDF people also could not reproduce. Yet they recognized the problem regardless and just pushed a patch. This patch is a temporary fix. They made it clear that puri should not attempt pollute the default readtable, and one should expect the problem to come back in the future if puri is not fixed.
Which raises a question: is puri a dead project? Can it ever be fixed?
I just came across this issue yesterday while trying to run my own code that depends heavily on drakma. I narrowed the manifestation of the bug down to a difference in two ASDF versions, but I investigated no further. I would have to get clearance from my manager to spend work hours on this. Working on opensource projects is something he promotes, but on lisp? That would be an interesting conversation. He would tell me to rewrite the app in python. I do not want to do that. So I will not have that conversation, and the weekend is the earliest that I can spend any more time on this.
The first thing I will look at, once I have time, is whether puri defines its own readtable somewhere but it's just not being loaded before the above set-dispatch-macro-handler call because of some nonexplicit ordering in the asd file or some such. But let's not get too dragged down into the weeds and forget to look at the big picture. If puri is doing something bad and it cannot be fixed, where does that leave drakma? That's the question I am urging you to consider.
Hi @ckonstanski , regarding your question:
Which raises a question: is puri a dead project? Can it ever be fixed?
Quicklisp takes its sources from kmr-git which happens to stand for Kevin Rosenberg's git repository.
It should also be noted that PURI still suffers from a tiny flaw with non latin-1 character encodings in the request URL.
P.S. there has been an unsuccessful attempt some years ago to replace PURI with QURI in Drakma: #65.
