1. Do you know 2htdp/image and 2htdp/universe? That should make the small
project straightforward.
2. Take a look at 2htdp/batch-io and see whether it is good enough or whether
you need modifications that help with this.
-- Matthias
On Dec 20, 2010, at 4:12 PM, Ken Hegeland wrote:
> I
Oh, probably you can recover that by judicious use of the unsafe
primitives (unsafe-fx+ and unsafe-fx= for example). The for macro is
not doing anything you can't do yourself, fwiw. (Also, fwiw, unless
you have a simple loop body, it probably won't matter too much
anyways.)
Robby
On Mon, Dec 20,
Thanks for all the attention Robby, and I am glad that I could help find
some improvement space.
The sad part is that for the new loop there is an increase of about 100%
in the processing time, I guess it is because of the efficiency provided
by the in-vector inside the for.
Cool list, as usual.
At Mon, 20 Dec 2010 16:17:38 -0600, Robby Findler wrote:
> I don't think your changes had anything to do with the "doens't look
> very good". But since you asked, if you look at the fully expanded
> version of
>
> (λ (v) (for ([x (in-vector v)]) x))
>
> you'll see it begins like this:
>
>
On Mon, Dec 20, 2010 at 3:56 PM, Noel Welsh wrote:
> On Mon, Dec 20, 2010 at 9:51 PM, Robby Findler
> wrote:
>> The expanded code doens't look very good, imo, tho, so perhaps whoever
>> recently was working on this can clean this part up too.
>
> I have a name ;-P Perhaps you could elaborate on
On Mon, Dec 20, 2010 at 9:51 PM, Robby Findler
wrote:
> The expanded code doens't look very good, imo, tho, so perhaps whoever
> recently was working on this can clean this part up too.
I have a name ;-P Perhaps you could elaborate on "doesn't look very
good". I spent a little bit of time optimi
On Mon, Dec 20, 2010 at 3:48 PM, Robby Findler
wrote:
> and, sure enough, looking at the expansion of the loop:
>
> (for ([i (in-vector some-data)]) i)
>
> I see that it uses multiple values which, I believe are not safe for futures.
>
> I believe that this is a recent change and hopefully whoeve
On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani wrote:
> My output to your suggested approach is
>
> GC [minor] at 1514740 bytes; 818464 collected in 4 msec
> GC [minor] at 2142928 bytes; 678980 collected in 4 msec
> GC [minor] at 4424700 bytes; 1509104 collected in 12 msec
> GC [minor] at 499930
I wasn't quite sure what to name this, it is a two part question.
I am nearly done with HTDP, and I am starting a small project of my own to make
a simple turn based rpg. Its mostly structure mutation. My goal is to use draw
mazes on the canvas and then have a character item(most likely a solid
Good to hear you got it working!
N.
On Mon, Dec 20, 2010 at 6:44 PM, Russell Adams
wrote:
> I'm pleased to say I got it working, with a tremendous speedup.
>
> As it turns out, I had incorrectly placed:
>
> (provide (all-from-out (planet untyped/snooze:2))
>
Changing the suite to
(test-suite "with futures"
(check-equal?
(time (let ([f (future (λ _ (read-data DATA)))])
(read-data DATA)
(touch f)))
(void)))
Did no help it very much, I still get the same results a
And as a general rule of thumb, you should call collect-garbage
(perhaps a few times) before running anything you wish to time in
order to be sure that the gc time is being correctly attributed.
Robby
On Mon, Dec 20, 2010 at 1:12 PM, Robby Findler
wrote:
> Oh. You have the touch first. Try putti
Oh. You have the touch first. Try putting it second.
Robby
On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani wrote:
> Thanks for the prompt reply.
>
> Disregard the noncollectable thing, that was a confusion on my side.
> Still, my doubt remains about why my futures version is slower and not
> pa
Thanks for the prompt reply.
Disregard the noncollectable thing, that was a confusion on my side.
Still, my doubt remains about why my futures version is slower and not
parallel. I did read about the futures, but alas, I'm still in the dark
as to why it is behaving like it is.
My output to your s
I'm not sure about the uncollectable issue, but for the rest, try
running in racket, enabling the debug log. Eg, if you save the file in
x.rkt and do this:
racket -W debug x.rkt
then you should see some messages telling you what is causing your
future to get stuck.
Also, do be sure to read thi
Hello all
I am trying to understand futures, and I have generated to following
code to see how I would create reader futures. Unfortunately my futures
are not running in parallel and are taking more time that the serial
version. Besides that it seems to capture the vector in a way that it
becomes
On Mon, Dec 20, 2010 at 07:31:59AM +, Noel Welsh wrote:
> Hi Russell,
>
> You'll find examples of transactions in the tests for it:
>
>
> http://planet.plt-scheme.org/package-source/untyped/snooze.plt/2/8/snooze-transaction-test.ss
>
> It should be fairly simple to get working. Note that Sn
uri-encode only works on strings, so you need to convert to a string.
The decoding problem is caused by the the bytes to UTF-8 conversion --
that byte string isn't a valid UTF-8 string (or something). The URI
encoding functions really should work on bytes, but when they were
written a million years
Give a byte string, for example (bytes 211) , how do I encode it to
"%D3" , using uri-encode , or
any other existing function in racket.
Also when i try to do (uri-decode "%D3") , it complains that :
"bytes->string/utf-8: string is not a well-formed UTF-8 encoding: #"\323"
Thanks
_
19 matches
Mail list logo
