On Aug 19, 2014, at 7:37 AM, Matthias Felleisen wrote:
>
> I have fixed the bug, thanks to a thorough code review with Robby. The next
> release of DrRacket will create executables for big-bang (and universe)
> programs whose window remains open after stop-when (or equivalent action)
> halt
I have fixed the bug, thanks to a thorough code review with Robby. The next
release of DrRacket will create executables for big-bang (and universe)
programs whose window remains open after stop-when (or equivalent action) halt
the execution.
If you are eager to test this, you may wish to try
On Aug 4, 2014, at 9:31 AM, Matthias Felleisen wrote:
> #lang racket/gui
>
> (require 2htdp/universe 2htdp/image)
>
> (define (render ws) ws)
>
> (define (halt ws) #t)
>
> (big-bang (rectangle 600 400 'solid 'gold)
> (to-draw render)
> (stop-when halt render))
>
> (yield (m
I can confirm the behavior, which is visible under both *SL and Racket and all
methods for creating executable.
For a workaround, use this for now:
#lang racket/gui
(require 2htdp/universe 2htdp/image)
(define (render ws) ws)
(define (halt ws) #t)
(big-bang (rectangle 600 400 'solid 'gold
When you run big-bang in Dr Racket and the stop-when evaluates true the window
remains open to display the final image (when specified) and must be manually
closed by the user. However, running the racket executable created for
distribution closes the window and returns you to terminal as soon a
For the record, Matthew pushed a fix involving `cairo_fill` and
`cairo_paint_with_alpha`:
https://github.com/plt/racket/commit/54e42664dfd2aeafbe41c2ff424d86affe171962
Laurent
On Mon, Apr 21, 2014 at 4:00 PM, Laurent wrote:
> I have a 2htdp/universe program that used to run fast enough a few m
At Tue, 22 Apr 2014 09:15:07 -0500,
Robby Findler wrote:
> Those are probably all errortrace-based stacktraces. And the profiler uses
> the internal ones not the errortrace based ones. Figuring out how to get
> you internal stacktraces is probably a good idea.
>
> But I think Vincent has adjusted
Thanks for the help.
Actually, I'm using the "nouveau" drivers as the nvidia ones apparently
don't like my screen and go on strike (just tested again, they still don't
work).
I have rebooted several times since yesterday, and the behavior of the
program is still the same, so it's probably not cach
Yes, the `main` version runs normally fast, while the `main2` version is
slow.
On Tue, Apr 22, 2014 at 4:15 PM, Matthias Felleisen wrote:
>
> The attached file is from a vignette that I have been working on
> ("Programming with Class"). It simulates 'big-bang' without a lot of the
> student prot
This probably isn't a help, but just in case...
Also check the xorg conf file and syslog for which driver it's using (it
often autodetects nowadays, and picks from among applicable installed
drivers).
In addition to which driver it's picking up, also check for whether it
was able to load any
Those are probably all errortrace-based stacktraces. And the profiler uses
the internal ones not the errortrace based ones. Figuring out how to get
you internal stacktraces is probably a good idea.
But I think Vincent has adjusted the profiler to be able to use the
errortrace stacks. I am not sure
The attached file is from a vignette that I have been working on ("Programming
with Class"). It simulates 'big-bang' without a lot of the student protections
and the machinery needed to make it compatible with the stepper etc. It also
cuts out some of the software engineering playing I did (but
Indeed, I have no stacktrace for the program `#lang racket (error "auie")`
without `-l errortrace` (but I have one with it) on the command line.
(exceptions are printed, but line numbers are not)
When I run it inside DrRacket (where I do have traces) I still get an empty
profile:
Profiling results
When I tried this on my machine I didn't get an empty profile so that is
strange.
Do you get (non errortrace) stacktraces for errors in general?
Robby
On Tuesday, April 22, 2014, Laurent wrote:
> No luck (empty profile). I also tried with errortrace and with
> providing/requiring main instead
No luck (empty profile). I also tried with errortrace and with
providing/requiring main instead of dynamic-require and calling main in the
profiling, but same effect.
I had actually already tried also before posting, and this is why I used
these explicit `time` and `current-milliseconds` calls.
I
I'm not sure if this will work, but here's an attempt to profile a
2htdp/universe program. If you put your program in one file called,
say, tmp.rkt and then run the program below (closing the big-bang
window after a while), you should get a profile of something. Maybe it
will be useful.
#lang rack
Perhaps it isn't big-bang per se. I need to wrap up some end-of-semester
things this week, but
1. I'll will try to find some time to profile your program possibly with
Vincent's spanking-new feature-specific profiler. If we find a good set up,
we'll send instructions.
2. Since I am working
Thank you all for your answers. The problem seems to be on my end then.
However, some other graphic programs that draw in a canvas are not slow on
my computer.
Does `big-bang` do something in particular regarding graphics?
Laurent
On Mon, Apr 21, 2014 at 10:29 PM, David Vanderson wrote:
> It
It's fast for me - Linux Mint, both Racket 6.0 and 6.0.1.5 (from git
just now) with cairo 2.11200.2.
Dave
On 04/21/2014 11:10 AM, Laurent wrote:
My version of Cairo is 2.11000.2. What's yours, Sean?
(probably: ls /usr/lib/i386-linux-gnu/libcairo.so*)
On Mon, Apr 21, 2014 at 4:51 PM, Robby Fi
Hello
on my laptop seem very fast
but Mint 16 (ubuntu 13.10) core i7/16Go
Racket 6.0.1.4--2014-04-18(ccefa53/a)
Cairo /usr/lib/i386-linux-gnu/libcairo.so.2.11200.16
to-draw at 334
to-draw: cpu time: 2 real time: 3 gc time: 0
on-key d at 442
to-draw at 442
to-draw: cpu time: 1 real time: 1 gc time:
My version of Cairo is 2.11000.2. What's yours, Sean?
(probably: ls /usr/lib/i386-linux-gnu/libcairo.so*)
On Mon, Apr 21, 2014 at 4:51 PM, Robby Findler
wrote:
> If the versions of Cairo are the same, then that eliminates one
> possible route of inquiry.
>
> Robby
>
> On Mon, Apr 21, 2014 at 9:4
If the versions of Cairo are the same, then that eliminates one
possible route of inquiry.
Robby
On Mon, Apr 21, 2014 at 9:45 AM, Laurent wrote:
> Thanks Sean.
> (I forgot to mention that I was testing on Racket 6.0.1.4).
> Apparently it does not lag on your machine, so it might be particular to
Thanks Sean.
(I forgot to mention that I was testing on Racket 6.0.1.4).
Apparently it does not lag on your machine, so it might be particular to my
machine then? Strange.
On Mon, Apr 21, 2014 at 4:32 PM, Sean Kanaley wrote:
> Here's my log after pasting the source into command-line racket 6.0,
Here's my log after pasting the source into command-line racket 6.0, Ubuntu
12.04 32-bit:
to-draw at 1649
to-draw: cpu time: 0 real time: 2 gc time: 0
on-key a at 2934
to-draw at 2934
to-draw: cpu time: 0 real time: 2 gc time: 0
on-key s at 2970
to-draw at 2970
to-draw: cpu time: 4 real time: 3 gc
I have a 2htdp/universe program that used to run fast enough a few months
ago, but now it is very slow and not usable.
The slowness seems to be because of the on-screen rendering, and not
because of the generation of the image.
Here is a stripped-down version that shows this behavior:
https://gist
On Nov 29, 2010, at 6:56 PM, Gregor Kiczales wrote:
> In merging the mutable variables part of 1e with the universe of 2e, one
> thing we do is move world state into a state variable. Doing that is nice
> because it shows a classic use of mutable variables.
Exactly. And it is even better to do
In merging the mutable variables part of 1e with the universe of 2e, one thing
we do is move world state into a state variable.
Doing that is nice because it shows a classic use of mutable variables.
But its awkward to have to tell students something like "to keep big-bang happy
we have to let
27 matches
Mail list logo
