DrDr seems to be behind by about 8 pushes (in terms of what it is
showing in the UI) currently and is stuck running on push 28468 for 36
hours.
_
Racket Developers list:
http://lists.racket-lang.org/dev
I have seen a crash that looks like this twice recently.
Seg fault (internal error during gc) at 0x19fd08000
I reran the same program and would not get the crash again. Is there
anything that I can do to turn something like this into an
actionable/useful bug report?
_
Ra
Great that explains it and with that information I was able to
simplify my test case to
tmp.rkt
#lang racket
(require "tmp2.rkt")
(define-syntax (go stx)
(foo))
(go)
tmp2.rkt
#lang racket
(provide (for-syntax foo))
(begin-for-syntax
(define (foo) #'3))
So now the question is how do I ru
Thanks for your work, Robby.
--- nadeem
On Friday, April 4, 2014, Robby Findler wrote:
> [ Nadeem sent me the file offline. ]
>
> I've pushed a fix for the bug.
>
> It is possible to work around it: the issue comes up when you copy and
> paste the result of the 2htdp/image images back into the d
[ Nadeem sent me the file offline. ]
I've pushed a fix for the bug.
It is possible to work around it: the issue comes up when you copy and
paste the result of the 2htdp/image images back into the definitions
window. In this case, the image I noticed that does this is a flipped cat.
So you could d
No need to apologize! I'd feel lost if you didn't ask questions that
forced me to explain things better. :)
Do you think it's worthwhile to make it easy for people to get the old
behavior?
Neil ⊥
On 04/04/2014 11:28 AM, Robby Findler wrote:
Oh, I finally understand.
Yes, I agree that this
Oh, I finally understand.
Yes, I agree that this is a good change.
Sorry for the confusion.
Robby
On Fri, Apr 4, 2014 at 10:04 AM, Neil Toronto wrote:
> Yes, the relative size of the font will grow, as well as minor things,
> such as that the lines will thicken a bit. IOW, without the fix, i
The current `_bool` is pre-standard. It specifically reflects (I think)
the absence of a bool type in libffi, which in turn is an artifact (I
assume) of `bool` not existing in a C standard before C99.
Lots of libraries have a "bool" variant that is `int`-sized, so I
imagine that's where the defini
Just checked and _Bool is also 1 byte, same as C++. What i don't
understand yet is to which standard does the current _bool conform? I
couldn't find any platform with int sized bool.
On Fri, 04 Apr 2014 17:10:30 +0200, Matthew Flatt
wrote:
Yes, `_bool` is a problem. I'll add a `_stdboo
Yes, the relative size of the font will grow, as well as minor things,
such as that the lines will thicken a bit. IOW, without the fix, if you
output the same plot to a PDF, SVG, and PNG, the PDF will have a smaller
font and thinner lines than the SVG and PNG.
It can be hard to tell without co
Yes, `_bool` is a problem. I'll add a `_stdbool` that corresponds to
`bool` from C99's , which I imagine must be the same as
`bool` in C++.
At Fri, 4 Apr 2014 08:56:18 +0200, Tobias Hammer wrote:
> Hi,
>
> i guess this shouldn't happen:
>
> $ cat s.cc
> #include
> int main()
> {
> printf("
If I understand the question:
* With 34c3eed615, "pr12644.rkt" can compile and run.
* With d29df205f7, "pr12644.rkt" fails to compile.
* A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can still
run in d29df205f7, because run-time support for "pr12644.rkt" didn't
change.
* W
I'm not completely clear on the precise impact of old papers: will the plot
itself stay the same size, but the relative size of the font (to the other
plot elements) inside the plot change only? Or something else?
Robby
On Fri, Apr 4, 2014 at 12:08 AM, Neil Toronto wrote:
> I did it because I w
13 matches
Mail list logo
