Great!
On Sat, May 11, 2013 at 2:11 PM, Jon Zeppieri wrote:
> Ok, I fixed this problem. I had just left out tests for immediates in
> a number of places. I think I was confused because certain expressions
> like
>
> (syntax? #\c)
>
> ... seemed to be working just fine, but I think they were not
Ok, I fixed this problem. I had just left out tests for immediates in
a number of places. I think I was confused because certain expressions
like
(syntax? #\c)
... seemed to be working just fine, but I think they were not actually
working in the JIT. I suspect they were constant-folded before eve
Something to do with syntax, I think, but I'm not sure what:
> (datum->syntax #f #\c)
#
> ((current-prompt-read))
> #\c
#
> (read-syntax)
#\c
#
> (syntax #\c)
Segmentation fault: 11
> (quasisyntax #\c)
Segmentation fault: 11
They all work when the JIT is disabled.
-Jon
On Sat, May 11, 201
On Sat, May 11, 2013 at 1:31 PM, Robby Findler
wrote:
> Relatedly, does this crash?
>
> (parameterize ([current-input-port (open-input-string "#\\c")])
> (read-eval-print-loop))
Yes, it does. I will take a look at the code in misc.rkt. Thanks!
-Jon
_
Racket Developers l
Relatedly, does this crash?
(parameterize ([current-input-port (open-input-string "#\\c")])
(read-eval-print-loop))
Robby
On Sat, May 11, 2013 at 12:28 PM, Robby Findler wrote:
> Did you try to pull out and simplify read-eval-print-loop until you can
> get a stand-alone program that crashes?
Did you try to pull out and simplify read-eval-print-loop until you can get
a stand-alone program that crashes? (The impl is in
racket/private/misc.rkt.)
Robby
On Sat, May 11, 2013 at 12:19 PM, Jon Zeppieri wrote:
> I did:
>
> @@ -1555,9 +1570,9 @@ typedef void (*Scheme_Invoke_Proc)(Scheme_Env
I did:
@@ -1555,9 +1570,9 @@ typedef void (*Scheme_Invoke_Proc)(Scheme_Env
*env, intptr_t phase_shift,
/* Exploit the fact that these should never be dereferenced: */
#ifndef FIRST_TWO_BYTES_ARE_LEGAL_ADDRESSES
-# define MZ_EVAL_WAITING_CONSTANT ((Scheme_Object *)0x2)
-# define MZ_APPLY_WAITING
Wild guess: Did you change the pseudo-values MZ_EVAL_WAITING_CONSTANT
and MZ_MULTIPLE_VALUES_CONSTANT to make sure they're not mistreated as
immediates --- or that a character is not mistreated as a pseduo-value?
At Sat, 11 May 2013 13:12:54 -0400, Jon Zeppieri wrote:
> These all work:
>
> -> (wr
On Sat, May 11, 2013 at 1:12 PM, Jon Zeppieri wrote:
>
>
> 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:
Er... "repl loop."
_
Racket Developers list:
http://
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
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
On Fri, May 10, 2013 at 9:19 PM, Jon Zeppieri wrote:
[snip]
>
> Any idea where to look or what debugging tools might be useful?
Sorry, I should have mentioned that the segfault does appear to occur
in jitted code. And it occurs trying to treat the character as a
pointer and dereference it. Here'
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
13 matches
Mail list logo
