freenode/#clasp - IRC Chatlog
Search
12:30:20
DVSSA
I seem to running into some issues when writing/reading with clasp. It seems to ignore the first time I try to read, when writing I don't get the correct formatting I'd expect but only for the first thing I'm writing (the rest print fine)
13:20:39
DVSSA
Debugger received error of type: SIMPLE-PROGRAM-ERROR The symbol COMMON-LISP-USER::PROMPT-READ has no function bound to it Error flushed.
13:24:22
DVSSA
Sorry wrong paste, If i use (read-line *query-io*) it still doesn't give chance to interact (seems to just be reading in a blank without me actually doing anything)
13:29:19
DVSSA
I also get format issues when printing for the first time (~10t) is ignored for the first print.
13:56:38
attila_lendvai
that ita guy over at #waf is the author of waf, right? he's not very friendly, nor open for constructive criticism...
13:58:51
attila_lendvai
well, that criticism is borderline a bug... but anyway, I found the last outstanding issue I know in the build-refactor branch
18:24:50
Bike
or more likely whatever stupid thing i did that's breaking destructuring bind somehow is also hitting lambda lists
19:03:02
frgo
Hm - clbind uses boost::shared_ptr and core uses std::shared_ptr? May this cause problems?
19:14:51
Bike
drmeister: dvssa was having trouble with read-line returning immediately on ubuntu - do you have any hints about that? it seems to work properly on os x
19:35:55
drmeister
DVSSA: I haven't spent much time on the command line - are you familiar with emacs?
19:38:17
drmeister
Understood - I was pointing him to the best interface in case he wasn't aware of it.
19:42:53
drmeister
So what's the deal with it then. When I go (read-char)2 --> #\2 it's reading the next thing in the stream. (read-char) <enter> --> #\NEWLINE
19:43:41
stassats
drmeister: pressing RET makes (read) finish but still leaves the character in the stream
19:43:49
drmeister
On SBCL (read-char)<enter> pauses and waits for input. Are we forgetting to eat a character from the input stream when we type it into a terminal?
19:47:04
drmeister
It's here... https://github.com/drmeister/clasp/blob/dev/src/core/primitives.cc#L1239
19:51:59
drmeister
I'm building a debug version of iclasp-boehm so I can step through what it is doing.
19:57:16
drmeister
read_lisp_object is calling read_lisp_object and the second time it will pass recursive_p as true https://github.com/drmeister/clasp/blob/dev/src/core/lispReader.cc#L1018
19:59:37
drmeister
That appears to be the case - and I think that makes it think it's doing a read-preserving-whitespace
20:01:13
stassats
(progn (read-char) (read) (listen)) and (progn (read-char) (read-preserving-whitespace) (listen)) return different results
20:01:17
drmeister
I think once we fix this it will fix another long standing bug that has annoyed the crap out of me - the extra close parenthesis bug.
20:05:55
Bike
so what is this non recursive read bit doing? resets the iteration depth, then sets up a #= table?
20:17:17
stassats
(read-from-string "abc " nil nil :preserve-whitespace T) and NIL return 3 and 4 correctly
20:31:17
drmeister
* If y is a whitespace[2] character, then it terminates the token. First the character y is unread if appropriate (see read-preserving-whitespace), and then step 10 is entered.
20:32:53
stassats
read for some reason is setting that variable to the previous value if recursive-p is t
20:41:24
drmeister
stassats: Thanks for looking at this - if you dig deeper I'll read your comments in the log before proceeding.
20:42:24
Bike
on sbcl read and read-preserving-whitespace go through the same path, but read also eats one more character at the end sometimes. that seems simple enough
20:45:04
drmeister
So eating the whitespace after the read_lisp_object call in the non recursive case was a workable idea?
20:53:04
stassats
sbcl: (with-input-from-string (*standard-input* "#.(progn (read *standard-input* t nil t) (read-char))abc j") (read)) => #\Space
20:55:26
stassats
"read-preserving-whitespace is exactly like read when the recursive-p argument to read-preserving-whitespace is true."
21:06:55
stassats
the example provided by clhs doesn't produce the correct results if the result of the previous snippet is #\Space
21:13:56
specbot
The RECURSIVE-P argument: http://www.lispworks.com/reference/HyperSpec/Body/23_acb.htm