These all work: -> (write #\c) #\c -> (print #\c) #\c -> (display #\c) c
It really seems to be the case that only functions that return characters have problems, and then, only those that return to the repo loop. For instance: -> (write (values #\c)) #\c -> (values #\c) Segmentation fault: 11 On Sat, May 11, 2013 at 11:29 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > The last example seems to be the only one that uses `write', while the > others implicitly use `print'. > > Does > > (write #\c) > > crash? How about > > (print #\c) > > ? > > At Fri, 10 May 2013 21:19:25 -0400, Jon Zeppieri wrote: >> My experiment with immediately represented characters has gotten to a >> state where a non-JIT build passes all tests, but a JIT build fails >> (as in, segfaults) on the following program: >> >> #\c >> >> It also fails on: >> >> (integer->char 99) >> >> and: >> >> (define (foo x) (integer->char x)) >> (foo 99) >> >> but not on: >> >> (define (foo x) (write (integer->char x))) >> (foo 99) >> >> So there seems to be a problem returning a character from a jitted >> function back to the repl. I haven't been able to figure out where >> this occurs, though. gdb's stack traces don't seem very useful for >> jitted code, and I can't use Sam's disassembler, because the process >> dies. >> >> Any idea where to look or what debugging tools might be useful? >> >> -Jon >> _________________________ >> Racket Developers list: >> http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
