freenode/#lisp - IRC Chatlog
Search
15:30:11
fiddlerwoaroof
Section 3.2 of that essay is one of my favorite non-technical aspects of Common Lisp
15:30:44
fiddlerwoaroof
I'm pretty tired of dealing with languages and standard libraries that change out from under you.
15:32:02
jackdaniel
yes, I find it pretty amusing that CL programs from '94 work flawlessly on today implementations
16:02:14
edgar-rft
jackdaniel: it's probably more like CL programs from '94 work with *exactly the same bugs as they had then* on today implementations
1:03:25
emaczen
I've had this problem for like 3 weeks -- I've been just "accepting" 1: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "parenscript" "src" "lib" "ps-loop"> as having been successful. -- from the restart
1:06:13
whoman
updates all the things. not sure if that is right command, but that is what i can think of because i have updated recently (because so has QL)
1:07:12
whoman
you may try to delete all the parenscript stuff in ~/quicklisp/ ? that is one thing i would do if it were happening to me
1:13:23
emaczen
whoman: I still get Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("/Users/thutmose/quicklisp/dists/quicklisp/software/Parenscript-2.6/src/lib/ps-loop.lisp"/34 UTF-8) #x30200499554D>, near position 8980, within "(:map) '{}))))
1:18:02
whoman
often times i have been getting "invalid syntax for ||" where there is a random || sitting around, in a few code bases, but they disappeared after starting more fresh. sorry thats a bit abstract but i ithink it is readtable stuff in that situation
1:19:53
whoman
for this kind of thing i would myself honestly go brute-force, rm -rf ~/quicklisp/ then quicklisp.lisp all over again (which sidenote, i would have called quick.lisp)
1:40:40
whoman
hmm, i am 1.3.17 , not much has changed since .16 -- i cant imagine whats wrong ! could you lisppaste a more full error report?
1:50:10
emaczen
whoman: What details do you want? The restart is just a condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR
1:57:54
emaczen
So in this file there is a (destructuring-bind (key val) ....) -- it is telling me that key and val are in a package called :collections, which is one of my own packages which does have reader-macros
1:58:13
emaczen
the question is, why are these two variables saying that they are in my :collections package?
2:08:30
whoman
ah well. it seems your personal/custom code is interfering. i am not sure why you havent considered that
2:09:58
emaczen
for some reason, I am getting a READ error and the code is from one of my own read-macros
2:11:44
whoman
hmm. i am not wise enough to understand the full scope of resolving symbol names or read tables
2:12:21
whoman
thats why i just say "remove ur own code, get parenscript happening, then fix ur code so its not poisoning the rest of the system" as an intuition guides me
2:30:32
Bike
Wait, wait. Have you done something like (setf *readtable* my-readtable) (ql:quickload :parenscript)?
2:33:29
emaczen
Bike: I commented out my reader-macro, quickloaded :parenscript and now it all seems to work.
2:33:59
Bike
i mean if your readtable is in force, the loader will try to use it. it doesn't snap back to the standard readtable or anything.
2:34:59
emaczen
In my .macros files of a system I usually do a (setf *readtable* (copy-readtable nil))
2:36:15
Bike
compile-file will rebind it, but if you're setting it outside of compile-file it'll stick
2:36:36
Bike
for example, if you had (eval-when (:compile-toplevel :load-toplevel :execute) (setf *readtable* ...))
3:03:09
emaczen
Bike: Is output supressed from the terminal? It appears as if nothing happens, I just get another command line prompt.