| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| Add this to examples.cl : (publish ath "/insanity":content-type "text/html" :function #'(lambda (req ent) (with-http-response (req ent) (with-http-body (req ent) (html ( rinc-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 ? ( |
|
#2
| |||
| |||
| On Sep 11, 9:25 pm, dan.ms.ch...@gmail.com wrote: > Add this to examples.cl : > > (publish ath "/insanity"> :content-type "text/html" > :function #'(lambda (req ent) > (with-http-response (req ent) > (with-http-body (req ent) > (html ( rinc-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 |
|
#3
| |||
| |||
| nallen05@gmail.com writes: > On Sep 11, 9:25 pm, dan.ms.ch...@gmail.com wrote: >> Add this to examples.cl : >> >> (publish ath "/insanity">> :content-type "text/html" >> :function #'(lambda (req ent) >> (with-http-response (req ent) >> (with-http-body (req ent) >> (html ( rinc-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. |
|
#4
| |||
| |||
| On Sep 11, 9:25 pm, dan.ms.ch...@gmail.com wrote: > (html ( rinc-safe (eq (read-from-string "X") (quote X))))Try printing the symbols with package prefixes: (html ( rin1-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 |
|
#5
| |||
| |||
| dan.ms.chaos@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 |
|
#6
| |||
| |||
| 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 . |
|
#7
| |||
| |||
| On Sep 11, 8:25 pm, dan.ms.ch...@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. |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.