-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
puri is bringing drakma down #86
Comments
It seems to be working here. Any more steps to reproduce? |
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:
Quicklisp takes its sources from 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. |
@ckonstanski , are you using ACL? |
No, SBCL. |
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 # #<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
The text was updated successfully, but these errors were encountered: