Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Jens Axel Søgaard
2015-05-11 2:24 GMT+02:00 Robby Findler :

> But if you have a specific destination in mind you can make the bitmap
> first and then draw the 2htdp/image into it (or anything into it!)


When I use my own game-loop it is easy enough to use the make-bitmap method
of the canvas.

I did see a significant improvement in responsiveness, so I thought maybe
the same trick could be used in the implementation of big-bang. It's
tricky though since the user produces the bitmaps, not the big-bang loop
itself.

FWIW: On OS X the difference between the two methods is so large the game
went from unplayable to playable (due to a single call to draw-bitmap).
I saw times between 7-9 milliseconds for the call.

/Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Jens Axel Søgaard
2015-05-11 0:56 GMT+02:00 Matthew Flatt :

> At Mon, 11 May 2015 00:30:05 +0200, Jens Axel Søgaard wrote:
> > 2015-05-11 0:07 GMT+02:00 Matthew Flatt :
> >
> > > If you're on OS X, try creating the bitmap with
> > >
> > >  (send canvas make-bitmap screen-width screen-height)
> > >
> > > instead of
> > >
> > >  (make-object bitmap% screen-width screen-height)
> > >
> > > Roughly, using the `make-bitmap` method creates a bitmap that's on the
> > > graphics card instead of main memory.
> >
> >
> > Two thoughts:
> >   - will make-screen-bitmap work too?
>
> No, only the `make-bitmap` method.
>
> See also
>  http://docs.racket-lang.org/draw/overview.html#%28part._.Portability%29
>

Ok.


> >   - If I insert images in the teaching languages,
> > do they become screen-bitmaps automatically?
>
> No, I don't think so.
>
> It's possible that it would make sense for `freeze` to use
> `make-bitmap`-method bitmaps. The `pict->pre-render-pict` function is
> similar to `freeze`, except that it's for picts in Slideshow, and it
> does use the `make-bitmap` method of Slideshow's canvas. (As you might
> guess, Slideshow was the original motivation for the feature.) I'm not
> certain that using a `make-bitmap` method would make as much sense even
> for `freeze`, since those images are less tied to a specific
> destination.
>

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] [racket][off-topic] what's the official meaning of *.rktl and *.rktd?

2015-05-10 Thread WarGrey Gyoudmon Ju
Get it!
Thank you Sam.

On Mon, May 11, 2015 at 9:53 AM, Sam Tobin-Hochstadt 
wrote:

> .rktl is for files intended to be used with 'load', which is what the l
> stands for.
>
> .rktd is for files used with 'read', and the d stands for data.
>
> Sam
>
> On Sun, May 10, 2015, 9:40 PM WarGrey Gyoudmon Ju 
> wrote:
>
>> Sorry it's hard to find the official definition of **.rktl* and **.rktd*
>> except both of them are racket source file extensions as well as **.rkt*.
>> My dim memory shows that *l* means *load* or *link*? *d* means *D*
>> *rRacket*? and these two ones are used for configuration.
>>
>> In my web htdocs, there are *servlet*.*rkt*, *literate-programming.**rkt
>> *and *s-exp-configuration*.*rkt*. That would be great if they all have a
>> conventional file extension instead of randomly choosing one on my own.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Environment Shuffling and 3D Syntax

2015-05-10 Thread Matthias Felleisen

Probably off-topic: you might be interested in 

 http://repository.readscheme.org/ftp/papers/sw2003/Scmxlate.pdf

Start with the title and then the summary at the end. Dorai has used this 
package to make his programs available in Schemes and Common Lisps. 

 -- Matthias


On May 8, 2015, at 10:56 AM, Philip Blair wrote:

> That's good to know about namespaces being intended to be for runtime 
> reflection.
> 
> I understand what you mean when you say "bindings and lexical context," but 
> in what specific way do you mean in the context of this issue?
> I also feel that I should mention that I am having difficulty wrapping my 
> brain around is the utility of a couple of the functions listed in the 
> documentation at http://docs.racket-lang.org/reference/stxtrans.html ; 
> specifically, I am unsure what exactly internal definition contexts and 
> syntax introducers are useful for.
> 
> Lastly, as far as what I am attempting to implement, I am dabbling with 
> trying to get at least a somewhat functional CL compatibility layer (I'm 
> calling it `#lang clacket`) written. Since Lisp has s-expressions, I figured 
> that there was no need to build a parser from scratch, but instead that I 
> could bridge the gap between the two languages using syntax transformers. 
> Things are going fairly well; I am just having issues getting this 
> packages/identifier-binding issue sorted out.
> 
> So, to specifically address your final paragraph, it looks like an uphill 
> battle :)
> Any ideas?
> 
> On Thu, May 7, 2015 at 2:33 PM, Matthew Flatt  wrote:
> I agree that those sound goals sound like a poor fit for `module+`.
> It's possible that `racket/package` provides something closer to the
> namespace-management tools that you need.
> 
> Generally, I think you'll find more success by manipulating bindings
> and lexical context (in the sense of `datum->syntax`) instead of trying
> to use namespaces. Racket namespaces are intended more for run-time
> reflection; they're too dynamic for most code-organization tasks.
> 
> I'm struggling to give more specific advice. If you need Common Lisp
> namespaces, I think that a close variant can be implemented in Racket,
> but it looks like an uphill battle. (Common Lisp is better at being
> Common Lisp; Racket is just better. :) Unless you're trying to run CL
> code with minimal modification, I'd encourage you to talk about your
> implementation goals, and maybe the list can offer ideas toward a
> suitable, Rackety abstraction.
> 
> At Thu, 7 May 2015 07:29:48 -0700 (PDT), Philip Blair wrote:
> > On Wednesday, May 6, 2015 at 11:02:33 PM UTC-4, Matthew Flatt wrote:
> > > I wonder whether whether expanding to `module+` might be a better
> > > direction. A rough expansion of your example might be
> > >
> > >  #lang racket/base
> > >   (module+ FOO
> > > (provide (all-defined-out))
> > > (define BAR 2))
> > >
> > >   (module+ FOO
> > > (define BAZ (add1 BAR)))
> > >
> > >   (module+ FOO
> > >  (add1 BAZ))
> > >
> > >   (module+ QUUX
> > > (require (prefix-in FOO: (submod ".." FOO)))
> > > (add1 FOO:BAZ)) ; => 4
> > >
> > >   (module+ main
> > > (require (submod ".." FOO))
> > > (require (submod ".." QUUX)))
> > >
> > > where using `module+` lets you splice together pieces of a submodule,
> > > and the final `main` submodule causes the others to be run.
> > >
> > > At Wed, 6 May 2015 16:04:59 -0700 (PDT), Philip Blair wrote:
> > > > Hello,
> > > >
> > > > I am working on a project in which I am trying to implement a Common
> > Lisp-style
> > > > package system. A simple example of usage would be as follows:
> > > >
> > > >(in-package FOO
> > > >  (define BAR 2))
> > > >; ...
> > > >(in-package FOO
> > > >  (define BAZ (add1 BAR)))
> > > >; ...
> > > >(in-package FOO
> > > >  (add1 BAZ)) ; => 4
> > > >; ...
> > > >(in-package QUUX
> > > >  (add1 FOO:BAZ)) ; => 4
> > > >
> > > > I was able to get something to this effect by doing the following:
> > > >
> > > >1. Create a namespace during phase 1 for each package
> > > >2. Wrap the (in-package ...) body in a submodule
> > > >   (to remove any local bindings in other parts of the file)
> > > >3. Wrap the body in the following:
> > > >   (require (for-syntax syntax/parse) racket/splicing)
> > > >   (parameterize ((current-namespace #,(package-namespace
> > resolved-package)))
> > > >   (splicing-let-syntax ((#%top (λ(stx)
> > > >(syntax-parse stx
> > > >  [(_ . id) #'(namespace-variable-value
> > 'id)]
> > > > #,@#'body))
> > > >
> > > >   This makes all non-local definitions resolve to the current
> > namespace's
> > > > definition.
> > > >
> > > > This works great. I ran into a problem, however, when trying to create a
> > > > provide transformer for the packages. I wrote the transformer and tried 
> > > > to
> > test
> > > > it, only to be greeted by this 

Re: [racket-users] [racket][off-topic] what's the official meaning of *.rktl and *.rktd?

2015-05-10 Thread Sam Tobin-Hochstadt
.rktl is for files intended to be used with 'load', which is what the l
stands for.

.rktd is for files used with 'read', and the d stands for data.

Sam

On Sun, May 10, 2015, 9:40 PM WarGrey Gyoudmon Ju 
wrote:

> Sorry it's hard to find the official definition of **.rktl* and **.rktd*
> except both of them are racket source file extensions as well as **.rkt*.
> My dim memory shows that *l* means *load* or *link*? *d* means *D*
> *rRacket*? and these two ones are used for configuration.
>
> In my web htdocs, there are *servlet*.*rkt*, *literate-programming.**rkt *
> and *s-exp-configuration*.*rkt*. That would be great if they all have a
> conventional file extension instead of randomly choosing one on my own.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Environment Shuffling and 3D Syntax

2015-05-10 Thread Matthew Flatt
I've fought my way a little up the hill, and enclosed is an
implementation that I think works the way you want within a module.
See the enclosed "in-package.rkt".

As you suspected, `make-syntax-introducer` is the piece that you need.
In the terminology of the current macro expander, the function produced
by `make-syntax-introducer` adds a "mark" to its argument syntax
object. Each package has its own mark, and so a package's definitions
are not visible outside the package (where references are missing the
necessary mark to access the definition). To use the definitions of one
package in another in an expression, `letrec-syntaxes` is wrapped
around the expression to map the defined names of the used package to
the names that are otherwise hidden by a mark.

To make this strategy work, a package's definitions need to be
detected, so `in-package` partially expands its body to detect
`define-values`, etc.


I can see a limitation of this implementation: In a package P that uses
package Q, a macro defined in Q cannot expand to a definition in P.
That's because the bindings of a used package can only be made
available to expressions with the `letrec-syntaxes` wrapper, and that
doesn't work for wrapping definitions. (A `splicing-letrec-syntaxes`
wrapper doesn't work, because it interacts badly with the partial
expansion needed to detect definitions.)

As it turns out, we have an experimental variant of the Racket macro
expander that can avoid the limitation. In the terminology of that
expander, the function produced by `make-syntax-introducer` adds a
"scope" to its argument syntax, and each package corresponds to a
scope. Unlike marks, scopes on a syntax object are unordered, and so
they can be added freely to access the content of used packages; no
`letrec-syntaxes` wrapper is needed. I've included a set-of-scopes
variant as "in-package-scopes.rkt" in case you're interested; you
should be able to run it with a snapshot at

 http://www.cs.utah.edu/~mflatt/tmp/scope-snapshot/

For more information on the set-of-scopes expander, see

 http://www.cs.utah.edu/~mflatt/scope-sets-4/


At Fri, 8 May 2015 10:56:16 -0400, Philip Blair wrote:
> That's good to know about namespaces being intended to be for runtime
> reflection.
> 
> I understand what you mean when you say "bindings and lexical context," but
> in what specific way do you mean in the context of this issue?
> I also feel that I should mention that I am having difficulty wrapping my
> brain around is the utility of a couple of the functions listed in the
> documentation at http://docs.racket-lang.org/reference/stxtrans.html ;
> specifically, I am unsure what exactly internal definition contexts and
> syntax introducers are useful for.
> 
> Lastly, as far as what I am attempting to implement, I am dabbling with
> trying to get at least a somewhat functional CL compatibility layer (I'm
> calling it `#lang clacket`) written. Since Lisp has s-expressions, I
> figured that there was no need to build a parser from scratch, but instead
> that I could bridge the gap between the two languages using syntax
> transformers. Things are going fairly well; I am just having issues getting
> this packages/identifier-binding issue sorted out.
> 
> So, to specifically address your final paragraph, it looks like an uphill
> battle :)
> Any ideas?
> 
> On Thu, May 7, 2015 at 2:33 PM, Matthew Flatt  wrote:
> 
> > I agree that those sound goals sound like a poor fit for `module+`.
> > It's possible that `racket/package` provides something closer to the
> > namespace-management tools that you need.
> >
> > Generally, I think you'll find more success by manipulating bindings
> > and lexical context (in the sense of `datum->syntax`) instead of trying
> > to use namespaces. Racket namespaces are intended more for run-time
> > reflection; they're too dynamic for most code-organization tasks.
> >
> > I'm struggling to give more specific advice. If you need Common Lisp
> > namespaces, I think that a close variant can be implemented in Racket,
> > but it looks like an uphill battle. (Common Lisp is better at being
> > Common Lisp; Racket is just better. :) Unless you're trying to run CL
> > code with minimal modification, I'd encourage you to talk about your
> > implementation goals, and maybe the list can offer ideas toward a
> > suitable, Rackety abstraction.
> >
> > At Thu, 7 May 2015 07:29:48 -0700 (PDT), Philip Blair wrote:
> > > On Wednesday, May 6, 2015 at 11:02:33 PM UTC-4, Matthew Flatt wrote:
> > > > I wonder whether whether expanding to `module+` might be a better
> > > > direction. A rough expansion of your example might be
> > > >
> > > >  #lang racket/base
> > > >   (module+ FOO
> > > > (provide (all-defined-out))
> > > > (define BAR 2))
> > > >
> > > >   (module+ FOO
> > > > (define BAZ (add1 BAR)))
> > > >
> > > >   (module+ FOO
> > > >  (add1 BAZ))
> > > >
> > > >   (module+ QUUX
> > > > (require (prefix-in FOO: (submod ".." FOO)))
> > > > (add1 FOO:

[racket-users] [racket][off-topic] what's the official meaning of *.rktl and *.rktd?

2015-05-10 Thread WarGrey Gyoudmon Ju
Sorry it's hard to find the official definition of **.rktl* and **.rktd*
except both of them are racket source file extensions as well as **.rkt*.
My dim memory shows that *l* means *load* or *link*? *d* means *D**rRacket*?
and these two ones are used for configuration.

In my web htdocs, there are *servlet*.*rkt*, *literate-programming.**rkt *
and *s-exp-configuration*.*rkt*. That would be great if they all have a
conventional file extension instead of randomly choosing one on my own.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Robby Findler
But if you have a specific destination in mind you can make the bitmap
first and then draw the 2htdp/image into it (or anything into it!)

Robby

On Sunday, May 10, 2015, Matthew Flatt  wrote:

> At Mon, 11 May 2015 00:30:05 +0200, Jens Axel Søgaard wrote:
> > 2015-05-11 0:07 GMT+02:00 Matthew Flatt  >:
> >
> > > If you're on OS X, try creating the bitmap with
> > >
> > >  (send canvas make-bitmap screen-width screen-height)
> > >
> > > instead of
> > >
> > >  (make-object bitmap% screen-width screen-height)
> > >
> > > Roughly, using the `make-bitmap` method creates a bitmap that's on the
> > > graphics card instead of main memory.
> >
> >
> > Two thoughts:
> >   - will make-screen-bitmap work too?
>
> No, only the `make-bitmap` method.
>
> See also
>  http://docs.racket-lang.org/draw/overview.html#%28part._.Portability%29
>
> >   - If I insert images in the teaching languages,
> > do they become screen-bitmaps automatically?
>
> No, I don't think so.
>
> It's possible that it would make sense for `freeze` to use
> `make-bitmap`-method bitmaps. The `pict->pre-render-pict` function is
> similar to `freeze`, except that it's for picts in Slideshow, and it
> does use the `make-bitmap` method of Slideshow's canvas. (As you might
> guess, Slideshow was the original motivation for the feature.) I'm not
> certain that using a `make-bitmap` method would make as much sense even
> for `freeze`, since those images are less tied to a specific
> destination.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Matthew Flatt
At Mon, 11 May 2015 00:30:05 +0200, Jens Axel Søgaard wrote:
> 2015-05-11 0:07 GMT+02:00 Matthew Flatt :
> 
> > If you're on OS X, try creating the bitmap with
> >
> >  (send canvas make-bitmap screen-width screen-height)
> >
> > instead of
> >
> >  (make-object bitmap% screen-width screen-height)
> >
> > Roughly, using the `make-bitmap` method creates a bitmap that's on the
> > graphics card instead of main memory.
> 
> 
> Two thoughts:
>   - will make-screen-bitmap work too?

No, only the `make-bitmap` method.

See also
 http://docs.racket-lang.org/draw/overview.html#%28part._.Portability%29

>   - If I insert images in the teaching languages,
> do they become screen-bitmaps automatically?

No, I don't think so.

It's possible that it would make sense for `freeze` to use
`make-bitmap`-method bitmaps. The `pict->pre-render-pict` function is
similar to `freeze`, except that it's for picts in Slideshow, and it
does use the `make-bitmap` method of Slideshow's canvas. (As you might
guess, Slideshow was the original motivation for the feature.) I'm not
certain that using a `make-bitmap` method would make as much sense even
for `freeze`, since those images are less tied to a specific
destination.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] scribble namespace landgrab & embedded package documentation

2015-05-10 Thread Neil Van Dyke


Matthew Flatt wrote on 05/07/2015 02:44 PM:

I have no problem with these names --- the `scribble` exports are
unlikely to ever collide, since we rarely resort to capital letters ---
but I can't help thinking that the language of the metadata should
specified explicitly.



Regarding `#lang mcfly racket/base`, an additional reason I want to do 
three-semicolon comments is to *not* have each package depend on the 
documentation package.  It's practically simpler sometimes. (I'm not the 
only one who doesn't fully like the dependency I had on the `mcfly` 
package; I've seen multiple other people copy my package code and strip 
out the McFly `doc` forms, so that they didn't have that dependency.)


If someone else wants to put something other than embedded Scribble in 
three-semicolon comments, the fact that I'm using three-semicolon in a 
particular way won't break them, and they won't break me.  Or, if 
someone in the future wants to scrape my three-semicolon stuff in the 
future, nothing's stopping them, and I'll even give them a small package 
to do that.  I think I understand what you're saying about languages, 
but in this case, I'm pretty sure how I want to do this, and I'm 
comfortable with the longevity of the pragmatic simplifications right now.


(Aside: I think the main advantage to the dependency on the `mcfly` 
PLaneT package was actually sneaky advertising or self-propagation. 
McFly is not a good example, but let's say there's a non-core package X 
that is used by various other packages.  When a person uses a package 
that uses X, directly or indirectly, then documentation for X was added 
to the person's Racket documentation page, for them to stumble upon 
through documentation search and browsing.  Then, the theory goes, that 
person is then more likely to add a new use of that package in packages 
that they write.  So, if we get an ecology of lots of small packages 
using lots of small packages, and package X depends directly and 
indirectly on packages A, B, C, D, E, and F...  the package X author 
doesn't even have to mention in documentation all those supporting 
packages (they often wouldn't even know all of the indirect ones), but 
the supporting packages still get a small bit of fame and propagation 
advantage each time.  This is decentralized, with no authority declaring 
X to be a good package to do the things that X does, but just the little 
documentation-adding mechanism gives the memetics a boost.)


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Jens Axel Søgaard
2015-05-11 0:07 GMT+02:00 Matthew Flatt :

> If you're on OS X, try creating the bitmap with
>
>  (send canvas make-bitmap screen-width screen-height)
>
> instead of
>
>  (make-object bitmap% screen-width screen-height)
>
> Roughly, using the `make-bitmap` method creates a bitmap that's on the
> graphics card instead of main memory.


Two thoughts:
  - will make-screen-bitmap work too?
  - If I insert images in the teaching languages,
do they become screen-bitmaps automatically?

/Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Jens Axel Søgaard
Worked like a charm.

Thanks!

2015-05-11 0:07 GMT+02:00 Matthew Flatt :

> If you're on OS X, try creating the bitmap with
>
>  (send canvas make-bitmap screen-width screen-height)
>
> instead of
>
>  (make-object bitmap% screen-width screen-height)
>
> Roughly, using the `make-bitmap` method creates a bitmap that's on the
> graphics card instead of main memory.
>
> At Sun, 10 May 2015 23:14:08 +0200, Jens Axel Søgaard wrote:
> > Hi All,
> >
> > The attached files are a work-in-progress. Eventually it will become a
> > remake of Cees Kramer's Snoopy for C64.
> >
> > Anyways, the game represents an unmoveable object as a block structure.
> > Today I decided to stop rendering the blocks for every frame. Instead
> > they are rendered once to a background image, and then simply
> > replace (send dc clear) with (send dc draw-bitmap the-background 0 0)
> > in the game loop.
> >
> > To my surprise the frame rate dropped. It seems draw-bitmap is more
> > expensive than I thought.?  Or ... perhaps I am doing something
> > that trips up draw-bitmap?
> >
> > Anyways, I have attached the game. To see the difference: Hold down
> > the space bar.
> >
> > /Jens Axel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Jens Axel Søgaard

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Time for draw-bitmap

2015-05-10 Thread Matthew Flatt
If you're on OS X, try creating the bitmap with

 (send canvas make-bitmap screen-width screen-height)

instead of

 (make-object bitmap% screen-width screen-height)

Roughly, using the `make-bitmap` method creates a bitmap that's on the
graphics card instead of main memory.

At Sun, 10 May 2015 23:14:08 +0200, Jens Axel Søgaard wrote:
> Hi All,
> 
> The attached files are a work-in-progress. Eventually it will become a
> remake of Cees Kramer's Snoopy for C64.
> 
> Anyways, the game represents an unmoveable object as a block structure.
> Today I decided to stop rendering the blocks for every frame. Instead
> they are rendered once to a background image, and then simply
> replace (send dc clear) with (send dc draw-bitmap the-background 0 0)
> in the game loop.
> 
> To my surprise the frame rate dropped. It seems draw-bitmap is more
> expensive than I thought.?  Or ... perhaps I am doing something
> that trips up draw-bitmap?
> 
> Anyways, I have attached the game. To see the difference: Hold down
> the space bar.
> 
> /Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] racket on openwrt

2015-05-10 Thread Neil Van Dyke

Has anyone already made an OpenWRT `.ipk` package of Racket?

Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Time for draw-bitmap

2015-05-10 Thread Jens Axel Søgaard
Hi All,

The attached files are a work-in-progress. Eventually it will become a
remake of Cees Kramer's Snoopy for C64.

Anyways, the game represents an unmoveable object as a block structure.
Today I decided to stop rendering the blocks for every frame. Instead
they are rendered once to a background image, and then simply
replace (send dc clear) with (send dc draw-bitmap the-background 0 0)
in the game loop.

To my surprise the frame rate dropped. It seems draw-bitmap is more
expensive than I thought.?  Or ... perhaps I am doing something
that trips up draw-bitmap?

Anyways, I have attached the game. To see the difference: Hold down
the space bar.

/Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


snoopy.rkt
Description: Binary data


struct-utils.rkt
Description: Binary data


[racket-users] testing with scope-set expander on Travis CI?

2015-05-10 Thread Alexander D. Knauth
I want to test some of my packages on travis with the Matthew Flatt's scope-set 
expander.

Right now I’m using Greg Hendershott’s way of setting up the .travis.yml, 
described here:
http://www.greghendershott.com/2013/07/using-travis-ci-for-racket-projects.html

I tried modifying that to support the scope-set snapshot here:
https://github.com/AlexKnauth/travis-racket/tree/scope-set
But testing that on travis fails with this error:
https://travis-ci.org/AlexKnauth/travis-racket/jobs/61987612
Running ./racket-scope-snapshot.sh to install Racket:
./racket-scope-snapshot.sh: line 1: syntax error near unexpected token `newline'
./racket-scope-snapshot.sh: line 1: `'
The command "cat travis-racket/install-racket.sh | bash" failed and exited with 
2 during .
Your build has been stopped.

First, is there a better way, second, has anybody already done something like 
this, and third, if the answer to the first two were no, how do I get this to 
work?  What am I doing wrong?


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.