Add this to examples.cl :
(publish :path "/insanity"
:content-type "text/html"
:function #'(lambda (req ent)
(with-http-response (req ent)
(with-http-body (req ent)
(html (:princ-safe
(eq (read-from-string "X") (quote X))
))))))
The source of the generated page (my ip /insanity ) is
<html><head></head><body>NIL</body></html>
I may not be a Lisp guru , but I know (eq (read-from-string "X")
(quote X)) is T .
Can someone please explain me this behavior ? :((
On Sep 11, 9:25 pm, ············@gmail.com wrote:
> (html (:princ-safe (eq (read-from-string "X") (quote X))))
Try printing the symbols with package prefixes:
(html (:prin1-safe (list (read-from-string "X") (quote X))))
> I may not be a Lisp guru , but I know (eq (read-from-string "X")
> (quote X)) is T.
>
> Can someone please explain me this behavior ? :((
Sure, if you promise to give your Lisp tools a bit more credit next
time you see something so "very buggy".
The value of *package* at read time is different from the package that
is current at the time your handler function is evaluated.
net.aserve.examples(34): (defun foo ()
(let ((r (read-from-string "x")))
(list 'x r (eq 'x r))))
foo
net.aserve.examples(35): (foo)
(x x t)
net.aserve.examples(36): (let ((*package* (find-package :user)))
(foo))
(x common-lisp-user::x nil)
net.aserve.examples(37):
The package is different because every request is handled by one of
several "worker" threads. These threads are spawned using mp:make-
process (in function make-worker-thread). Such processes don't inherit
the values of special variables. Details at
<http://franz.com/support/documentation/8.1/doc/
multiprocessing.htm#dynamic-environments-1>. Maybe you want to bind
*package* in the handler function.
- Willem
From: Thomas A. Russ
Subject: Re: Is AllegroServe INSANE ?!(Or at least very buggy .. )
Date:
Message-ID: <ymiwsuwapfb.fsf@blackcat.isi.edu>
············@gmail.com writes:
> I may not be a Lisp guru , but I know (eq (read-from-string "X")
> (quote X)) is T .
Not necessarily.
> Can someone please explain me this behavior ? :((
It depends on what the current package is at two different times:
Symbols encountered by READ are looked up or created in the current
package. But you are now invoking read at two different times. The
first is when READ is used to read in the source file for compilation.
The value of *package* for that read is presumably controlled by an
IN-PACKAGE declaration in the file in which your code containing
(eq (read-from-string "X") 'X)
appears
The second time is when this code is executed and READ-FROM-STRING is
called. Only if *package* is the same as when the file was read during
compilation will you be guaranteed to get T as the result of EQ. (There
are other circumstances where you might get T as well).
For a simple exercise consider the following:
(defpackage "FOO")
(defpackage "BAR")
(let ((*package* (find-package "FOO")))
(let ((sym (read-from-string "X")))
(let ((*package* (find-package "BAR")))
(print (read-from-string "X"))
(print sym)
(eq (read-from-string "X") sym))))
or even more simply:
(defpackage "FOO")
(let ((*package* (find-package "FOO")))
(print (read-from-string "X"))
(print 'x)
(eq (read-from-string "X") 'x))
This is one reason people often like to use keywords for symbol
constants....
--
Thomas A. Russ, USC/Information Sciences Institute
On Sep 11, 9:25 pm, ············@gmail.com wrote:
> Add this to examples.cl :
>
> (publish :path "/insanity"
> :content-type "text/html"
> :function #'(lambda (req ent)
> (with-http-response (req ent)
> (with-http-body (req ent)
> (html (:princ-safe
> (eq (read-from-string "X") (quote X))
> ))))))
>
> The source of the generated page (my ip /insanity ) is
> <html><head></head><body>NIL</body></html>
>
> I may not be a Lisp guru , but I know (eq (read-from-string "X")
> (quote X)) is T .
> Can someone please explain me this behavior ? :((
it works fine for me, dude. my guess is you've got two X's in two
different packages floating around (and *PACKAGE* isn't the same when
this code is compiled vs when the page is served)...
http://www.flownet.com/gat/packages.pdf
hth
Nick
From: Raymond Wiker
Subject: Re: Is AllegroServe INSANE ?!(Or at least very buggy .. )
Date:
Message-ID: <m2lkbdx9q9.fsf@RawMBP.local>
········@gmail.com writes:
> On Sep 11, 9:25 pm, ············@gmail.com wrote:
>> Add this to examples.cl :
>>
>> (publish :path "/insanity"
>> :content-type "text/html"
>> :function #'(lambda (req ent)
>> (with-http-response (req ent)
>> (with-http-body (req ent)
>> (html (:princ-safe
>> (eq (read-from-string "X") (quote X))
>> ))))))
>>
>> The source of the generated page (my ip /insanity ) is
>> <html><head></head><body>NIL</body></html>
>>
>> I may not be a Lisp guru , but I know (eq (read-from-string "X")
>> (quote X)) is T .
>> Can someone please explain me this behavior ? :((
>
> it works fine for me, dude. my guess is you've got two X's in two
> different packages floating around (and *PACKAGE* isn't the same when
> this code is compiled vs when the page is served)...
>
> http://www.flownet.com/gat/packages.pdf
Might also be different readtable settings, no?
readtable-case, for example.
Forgive me for the ... stile in witch my post was written , but after
6 hours of re-rechecking
error free functions , with frustrating results , I wasn't exactly as
calm as usual . Thanx for answering , it's been very helpful .
On Sep 11, 8:25 pm, ············@gmail.com wrote:
> I may not be a Lisp guru , but I know (eq (read-from-string "X")
> (quote X)) is T .
> Can someone please explain me this behavior ? :((
One lesson from this should be: don't call READ in circumstances you
don't trust completely. Those circumstances are at least that you
have full control over everything that controls the reader, and you
more-or-less know what you're reading[*]. Not doing this could easily
result in what I suppose could be called "Lisp injection
vulnerabilities" (by analogy with "SQL injection vulnerabilities").
--tim
[*] you may be able to avoid this if you have a very restrictive
readtable/reader settings, but even then you're trusting a vast mass
of code which probably was not written with security in mind.