Re: [racket-users] Racket 7.3 Plot Performance Regression

[evdubs]

If anyone is following along here, I recently installed the Racket 7.4 
(non-Chez Scheme) version from the Ubuntu PPA and this performance has been 
acceptable. It is slightly noticeably slower but much better than what I 
had seen in 7.3. This works for me, but I am still clueless in 
understanding what may have caused the performance drop as well as how to 
better profile/uncover what is happening in Racket programs in general.

On Friday, June 7, 2019 at 4:14:08 PM UTC-10, evdubs wrote:
>
>  The paint times for 7.2 seem inconsistent with your previous tests...
>
>
> Correct. That run was a bit of an outlier. The 7.2 runs are mostly in line 
> with 7.3 with respect to paint.
>
> Here's what I get for mouse callback stats with this code 
>  when I use different thresholds for 
> delta:
>
> Version Min Max Mean StdDev 
> 7.2; delta < 2 0 22 3.398 3.968 
> 7.3; delta < 2 0 210 4.795 18.214 
> 7.2; delta < 20 0 22 2.332 3.64 
> 7.3; delta < 20 0 206 9.728 19.46 
> 7.2; delta < 200 0 106 2.961 7.802 
> 7.3; delta < 200 0 239 29.579 34.369 
>
> With a smaller delta, more overlays are able to be shown in 7.3, but it is 
> still noticeably laggy compared to 7.2 (looks like about a third of the 
> frequency of updates). I suppose I can try this approach with my plot code 
> if I upgrade to 7.3, but it's kind of upsetting.
>
> Evan
>
> On Friday, June 7, 2019 at 2:07:26 PM UTC-10, Alex Harsanyi wrote:
>>
>> The paint times for 7.2 seem inconsistent with your previous tests...
>>
>> In any case, it seems mouse event handling takes longer in 7.3 based your 
>> results.  What happens if you update the callback to discard any mouse 
>> events older than, say 50 milliseconds?
>>
>> Alex.
>>
>> On Friday, June 7, 2019 at 7:27:32 PM UTC+8, evdubs wrote:
>>>
>>> I changed the Linux line of code to:
>>>
>>> [time-stamp (current-milliseconds)]
>>>
>>> Is there a reason why you did not want to do that?
>>>
>>> Any way, when I do that, here are the results I get:
>>>
>>> $ ~/racket-7.2/bin/racket chart-lag-test.rkt
>>> Mouse
>>> Min: 0.132080078125
>>> Max: 23.10107421875
>>> Mean: 3.257062241367008
>>> StdDev: 4.589805152078677
>>>
>>> Paint
>>> Min: 0.178955078125
>>> Max: 102.94091796875
>>> Mean: 28.86041259765625
>>> StdDev: 42.84071031974706
>>>
>>> $ ~/racket-7.3.0.4/bin/racket chart-lag-test.rkt
>>> Mouse
>>> Min: 0.126953125
>>> Max: 202.34912109375
>>> Mean: 25.70277455891149
>>> StdDev: 38.4063903237421
>>>
>>> Paint
>>> Min: 0.175048828125
>>> Max: 21.754150390625
>>> Mean: 7.548767089843749
>>> StdDev: 8.728339324923978
>>>
>>> If this modification is okay, I guess this is getting somewhere?
>>>
>>> Evan
>>>
>>> On Wednesday, June 5, 2019 at 5:43:40 PM UTC-10, Alex Harsanyi wrote:



 On Wednesday, June 5, 2019 at 9:23:26 PM UTC+8, Alex Harsanyi wrote:
>
>
>
> On Wednesday, June 5, 2019 at 8:51:48 PM UTC+8, evdubs wrote:
>>
>> I ran the program with your modifications, but counter to the 
>> documentation 
>> ,
>>  
>> the values I get from get-time-stamp don't seem at all similar to 
>> current-milliseconds or current-inexact-milliseconds. I ended up 
>> defining 
>> delta as follows (with 1559695139340 being a guess):
>>
>> (define delta (- (current-inexact-milliseconds) 1559695139340 (send 
>> event get-time-stamp)))
>>
>>
> On my machine, `get-time-stamp` always returns 0 -- this indicates 
> that the event% object itself is copied somewhere along the way but the 
> timestamp is not copied, The 1559695139340 is just the unix timestamp 
> from 
> when you ran the code first time.  I don't think the mouse test is 
> relevant 
> as is...  unfortunately I don't have any more suggestions for now...
>

 It looks like the `get-time-stamp` returns a value that is not what the 
 documentation specifies and it is also platform specific, I created an 
 issue with the relevant details here: 
 https://github.com/racket/gui/issues/132

 For now, I cannot think of a way to determine how old a mouse event is 
 when the callback is invoked.
  

>
> Alex.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/d0170bd1-47a7-4de2-a54b-d79936508720%40googlegroups.com.

[racket-users] Re: Some guidance in setting up Racket as a game scripting language.

[Alex Harsanyi]

Unless your objective is to learn C and SDL, I would recommend writing the 
game entirely in Racket and using the Racket graphics facilities -- you 
will find that the performance will be more than enough for a roguelike 
game that you want to develop. Also, there are more people that can help 
you with Racket graphics questions, should you have any.

There is also a sdl2 package on pkgs.racket-lang.org, if you want to use 
SDL from Racket.

Alex.

On Wednesday, October 2, 2019 at 9:31:09 PM UTC+8, Hans Sjunnesson wrote:
>
> This is a hobby project of mine - a game in C, using SDL. I'd like to only 
> use C for the rendering part - rather use a scripting language for all of 
> the gameplay code. I want to try to use Racket for this - I've been doing 
> enough Clojure that I'm familiar with a lisp. My first approach was to 
> following along "Embedding into a Program" section of the Racket guide. But 
> I'm running into road blocks - and I can't find any good examples of 
> projects which embed Racket in a C program that calls functions in a Racket 
> environment. My initial plan was to define a Racket module that provided an 
> "init", an "update", and a "draw" function, then call those from the C 
> program. The embedding guide points me to using "raco" to generate a C 
> version of "racket/base", and that works - I can eval basic stuff, but I'm 
> getting an error when I (require "test.rkt"). So I'm guessing there's more 
> to be done with setting up the environment.
>
> My "test.rkt" file is this:
>
> #lang racket/base
>
> (printf "Hello World!\n")
>
> And this is the pertinent part of the main.c file, which links libracket.
>
> #include "scheme.h"
> #include "base.c"
>
> static int run(Scheme_Env* e, int argc, char* argv[]) {
> scheme_env = e;
>
> declare_modules(e);
>
> scheme_namespace_require(scheme_intern_symbol("racket/base"));
>
> Scheme_Config* config = scheme_current_config();
> Scheme_Object *curout = scheme_get_param(config, MZCONFIG_OUTPUT_PORT);
> Scheme_Object* v = scheme_eval_string("(+ 1 2)", scheme_env);
> scheme_display(v, curout);
> scheme_display(scheme_make_char('\n'), curout);
>
> scheme_eval_string("(require \"test.rkt\")", scheme_env);
>   
>   return 0;
> }
>
> int main(int argc, char* argv[]) {
> scheme_main_setup(1, run, argc, argv);
> return 0;
> }
>
> The output is:
>
> 3
> standard-module-name-resolver: collection not found
>   for module path: racket/base/lang/reader
>   collection: "racket/base/lang"
>   in collection directories:
>   context...:
>show-collection-err_0
>standard-module-name-resolver
>1/module-path-index-resolve
>do-dynamic-require5_0
>read-syntax3_0
>default-load-handler
>standard-module-name-resolver
>1/module-path-index-resolve
>perform-require!78.1
>for-loop_0
>expand-capturing-lifts
>temp118_0
>temp91_0
>compile15_0
>temp85_0
>
> I'm thinking that the environment isn't correctly setup here, the "in 
> collection directories" lists is empty.
>
> Am I going about this the wrong way though? Would I be better served in 
> setting up all of the game loops, etc. in Racket, then use FFI just for 
> rendering with SDL?
>
> The game I'm making is a roguelike, so performance isn't as critical.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/4e4c300f-de73-496c-822d-41ea67f7da4d%40googlegroups.com.

Re: [racket-users] Ensuring that channels are GC'd when the child thread terminates

[David Storrs]

Ok, thanks.

On Wed, Oct 2, 2019, 4:16 PM Matthew Flatt  wrote:

> At Wed, 2 Oct 2019 11:06:14 -0400, David Storrs wrote:
> > On Wed, Oct 2, 2019 at 8:42 AM Matthew Flatt  wrote:
> > > It depends on `process-file`. If `process-file` retains `msg` until it
> > > is otherwise done, then yes. But if `process-file` ignores the argument
> > > for `msg` or only uses it for the first part of its work, then `msg`
> > > can get GCed before `process-file` returns.
> >
> > If process-file looked like this:
> >
> > (define (process-file msg ch)
> >   (define the-hash-str (file-info-hash msg))
> >   ...do stuff with the-hash-str...
> > )
> >
> > I think this would mean that msg could get GC'd as early as right
> > after the first line, but it's not guaranteed as to when it would be
> > GC'd.  Yes?
>
> Yes, essentially. But depending on `file-info-hash`, `msg` might be
> GC'd before `file-info-hash` returns, which is even before the second
> line within `process-file`.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKoeHe24fzK6uuZDVrx5_QWAzHrjsTNJEmMzEDSnC7cHfBw%40mail.gmail.com.

Re: [racket-users] Ensuring that channels are GC'd when the child thread terminates

[Matthew Flatt]

At Wed, 2 Oct 2019 11:06:14 -0400, David Storrs wrote:
> On Wed, Oct 2, 2019 at 8:42 AM Matthew Flatt  wrote:
> > It depends on `process-file`. If `process-file` retains `msg` until it
> > is otherwise done, then yes. But if `process-file` ignores the argument
> > for `msg` or only uses it for the first part of its work, then `msg`
> > can get GCed before `process-file` returns.
> 
> If process-file looked like this:
> 
> (define (process-file msg ch)
>   (define the-hash-str (file-info-hash msg))
>   ...do stuff with the-hash-str...
> )
> 
> I think this would mean that msg could get GC'd as early as right
> after the first line, but it's not guaranteed as to when it would be
> GC'd.  Yes?

Yes, essentially. But depending on `file-info-hash`, `msg` might be
GC'd before `file-info-hash` returns, which is even before the second
line within `process-file`.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20191002201621.3C8D0650197%40mail-svr1.cs.utah.edu.

[racket-users] Re: providing classes from a module

[Jack Firth]

(provide fish%) ought to work. Classes created with racket/class are 
values, just like numbers, strings, and functions, so you can provide them 
like you would other values.

On Wednesday, October 2, 2019 at 1:09:40 PM UTC-7, Tim Meehan wrote:
>
> Say for instance, I have a class in "tastyfish.rkt"
>
> #lang racket
> (require racket/class)
>
> ; What `provide` statement would I put here so that another module
> ; (like "market.rkt" for instance) can require fish%?
>
> (define fish%
>   (class object%
> (super-new)
> (init size)
> (define current-size size)
> (define/public (get-size)
>   current-size)))
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/93a0b623-a91b-42ed-a262-23915a8aa1b8%40googlegroups.com.

[racket-users] providing classes from a module

[Tim Meehan]

Say for instance, I have a class in "tastyfish.rkt"

#lang racket
(require racket/class)

; What `provide` statement would I put here so that another module
; (like "market.rkt" for instance) can require fish%?

(define fish%
  (class object%
(super-new)
(init size)
(define current-size size)
(define/public (get-size)
  current-size)))

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACgrOxKFfpGRCPumxgzkiznFGE637ObHVT%3DXM9mt9iRnj-ja9A%40mail.gmail.com.

[racket-users] Rhombus project plan

[Matthew Flatt]

[[NOTE: "Rhombus" is the new name for a design project formerly known
  as "Racket2", but "Rhombus" IS NOT THE FINAL NAME OF THE NEW LANGUAGE.

  "Rhombus" is the name of the project that will develop a language,
  and "Rhombus" is a temporary stand-in for a language name to be
  determined later. Phase 3 of the plan includes the mandatory step of
  picking a new language name.]]

Rhombus is about building on the good parts of Racket and advancing the
frontier of Racket-style language-oriented programming. A significant
part of the experiment is trying a surface syntax other than
parenthesized prefix notation. Another part is simplifying and
generalizing elements of `#lang racket`, such as its data structures
for streams and binding with integrated and extensible
pattern-matching. While some of these goals could be pursued
independently, taking them together offers opportunities to make the
whole language fit together better.

Whether Rhombus will become a suitable alternative for current `#lang
racket` can be determined only as the experiment progresses. It starts
with that ambition, but the project may fail. It may fail for technical
reasons, process reasons, or social reasons:

 - On the technical side, we're trying to do something new.

 - On the process side, we are trying a more visible and open approach
   than we have used for past major changes, even to the point of
   opening up the early exploratory phase.

 - On the social side, we hope that skeptical Racketeers will make room
   for the experiment and understand that putting the experiment in the
   open (and being up-front about development costs) is part of the
   more open process.

Matthew Flatt will lead the project with the guidance and consent of
Racket project leadership. In early phases of the experiment, Matthew
is responsible for delegating and deciding when the next phase starts.
Toward the end of the process, Racket leadership is responsible for
deciding whether to continue. Community participation is built into the
process by keeping the design discussion open and by using an RFC
process for the eventual design elements.


What Will Happen to Racket During Rhombus 
-

The Racket team will continue to maintain the language and its
implementations:

 - The existing ecosystem will continue to function as always.

 - Existing `#lang racket` programs will continue to run, just as in
   the 6.x and 7.x series of releases.

 - The team will release updated versions, occasionally making modest
   incompatibilities with explicit transition paths as needed --- all
   as usual.

This does not mean that the language and its implementation will evolve
at the same speed as it has in the past, but it means that we will
maintain our standard commitment to reliability and quality.


Phase 1: Brainstorming (months)
--

GOAL AND OUTPUT: A design sketch and collection of prototype
implementations that reflect key ideas and design constraints.

PROCESS: This is the current phase --- a discussion of ideas and
potential directions at

 https://github.com/racket/rhombus-brainstorming
  [formerly "racket2-rfcs"]

There will be some implementation in this phase to try things out, but
at first only for exploration purposes.

Initially, we want to address

 - generality in the data structures and libraries, 

 - consistency in the binding names and terminology, and 

 - a surface syntax other than parenthesized-prefix notation. 

We also presuppose a potential transition from `#lang racket`, which
will constrain the space of plausible languages. Depending on how this
phase unfolds, we are willing to consider the addition of goals, their
removal, or their reformulation.

This process will take a while, because the space is very large,
because different participants in the discussion will start with one
set of opinions and end with different ones, and because all of this
brainstorming and exploration will be publicly visible.

Some draft proposals using the RFC template will be useful at this
phase, similar to prototype implementations, but the process will be
informal (so, not really an RFC process). The existing "Racket2 wish
list" is also part of this phase, but some effort will be needed to
select, consolidate, and elaborate wish-list items.

CONCLUSION: The project leader will decide on the point where there's
enough agreement on specific design constraints and the outline of a
design to move to the next phase.

Failure is an option; some of the original goals may be abandoned, and
the project as a whole may be abandoned if the project leader cannot
identify a suitable product to move on to the next phase.

The project leader will also use this first process to identify
contributors and working-group leaders for the second phase.


Phase 2: Iterative Design (years)
-

GOAL AND OUTPUT: Specification and a coherent prototype for the overall
language design, stable enough 

Re: [racket-users] [ANN] RacketScript working for 7.x

[Bogdan Popa]

This is fantastic news!  Thank you!

Stephen Chang writes:

> The RacketScript compiler [1] has been updated to work with Racket 7.x
> programs, ie all tests pass (though we are still working to support
> more primitives).
>
> Try it out here: http://rapture.twistedplane.com:8080/
>
> The next milestone is to improve RacketScript enough to compile the
> Racket expander [2], with the longer term goal being to self-host, so
> programs may be independently compiled and run in the browser.
>
> If anyone is interested in helping out, let me know.
>
>
> [1] https://github.com/vishesh/racketscript
> [2] https://github.com/racket/racket/tree/master/racket/src/expander

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/m2a7ajugmd.fsf%40192.168.0.139.

Re: [racket-users] [ANN] RacketScript working for 7.x

[Hendrik Boom]

On Wed, Oct 02, 2019 at 01:53:46PM -0400, Stephen Chang wrote:
> The RacketScript compiler [1] has been updated to work with Racket 7.x
> programs, ie all tests pass (though we are still working to support
> more primitives).
> 
> Try it out here: http://rapture.twistedplane.com:8080/
> 
> The next milestone is to improve RacketScript enough to compile the
> Racket expander [2], with the longer term goal being to self-host, so
> programs may be independently compiled and run in the browser.

Does that include libraries like Pict, Pict3d, and the universe/world 
game tools? 

-- hendrik

> 
> If anyone is interested in helping out, let me know.
> 
> 
> [1] https://github.com/vishesh/racketscript
> [2] https://github.com/racket/racket/tree/master/racket/src/expander
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAFfiA1LEwkRrYE56j7Y1tM%3D5ZJ4YmWXxtO3R7q26m7g%2Bq0FHRQ%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20191002180411.d4ekgdcp73cepvpq%40topoi.pooq.com.

[racket-users] [ANN] RacketScript working for 7.x

[Stephen Chang]

The RacketScript compiler [1] has been updated to work with Racket 7.x
programs, ie all tests pass (though we are still working to support
more primitives).

Try it out here: http://rapture.twistedplane.com:8080/

The next milestone is to improve RacketScript enough to compile the
Racket expander [2], with the longer term goal being to self-host, so
programs may be independently compiled and run in the browser.

If anyone is interested in helping out, let me know.


[1] https://github.com/vishesh/racketscript
[2] https://github.com/racket/racket/tree/master/racket/src/expander

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAFfiA1LEwkRrYE56j7Y1tM%3D5ZJ4YmWXxtO3R7q26m7g%2Bq0FHRQ%40mail.gmail.com.

Re: [racket-users] Ensuring that channels are GC'd when the child thread terminates

[David Storrs]

On Wed, Oct 2, 2019 at 8:42 AM Matthew Flatt  wrote:
>
> At Tue, 1 Oct 2019 23:52:05 -0400, David Storrs wrote:
> > ; main dispatcher loop in the server.  Receives messages, dispatches
> > to child thread for processing
>
> > 2) This WOULD work:
> > (let loop ()
> > (define msg (get-next-message)) ; e.g. (file-info "sha1-hash-of-file-X")
> > (hash-set! channels msg ch)
> > (thread (thunk (process-file msg ch)
> > (loop))
> >
> > In this case, 'msg' is still reachable from the processing thread, so
> > it remains in the weak hash until the processing thread terminates, at
> > which point it is removed from the weak hash and the corresponding
> > channel is GC'd.
>
> It depends on `process-file`. If `process-file` retains `msg` until it
> is otherwise done, then yes. But if `process-file` ignores the argument
> for `msg` or only uses it for the first part of its work, then `msg`
> can get GCed before `process-file` returns.

If process-file looked like this:

(define (process-file msg ch)
  (define the-hash-str (file-info-hash msg))
  ...do stuff with the-hash-str...
)

I think this would mean that msg could get GC'd as early as right
after the first line, but it's not guaranteed as to when it would be
GC'd.  Yes?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKofmwcrQNVYkWNyd%3DdiPy2gzXBOgpHgYyUiLJ6_iMtrHHw%40mail.gmail.com.

[racket-users] Some guidance in setting up Racket as a game scripting language.

[Hans Sjunnesson]

This is a hobby project of mine - a game in C, using SDL. I'd like to only 
use C for the rendering part - rather use a scripting language for all of 
the gameplay code. I want to try to use Racket for this - I've been doing 
enough Clojure that I'm familiar with a lisp. My first approach was to 
following along "Embedding into a Program" section of the Racket guide. But 
I'm running into road blocks - and I can't find any good examples of 
projects which embed Racket in a C program that calls functions in a Racket 
environment. My initial plan was to define a Racket module that provided an 
"init", an "update", and a "draw" function, then call those from the C 
program. The embedding guide points me to using "raco" to generate a C 
version of "racket/base", and that works - I can eval basic stuff, but I'm 
getting an error when I (require "test.rkt"). So I'm guessing there's more 
to be done with setting up the environment.

My "test.rkt" file is this:

#lang racket/base

(printf "Hello World!\n")

And this is the pertinent part of the main.c file, which links libracket.

#include "scheme.h"
#include "base.c"

static int run(Scheme_Env* e, int argc, char* argv[]) {
scheme_env = e;

declare_modules(e);

scheme_namespace_require(scheme_intern_symbol("racket/base"));

Scheme_Config* config = scheme_current_config();
Scheme_Object *curout = scheme_get_param(config, MZCONFIG_OUTPUT_PORT);
Scheme_Object* v = scheme_eval_string("(+ 1 2)", scheme_env);
scheme_display(v, curout);
scheme_display(scheme_make_char('\n'), curout);

scheme_eval_string("(require \"test.rkt\")", scheme_env);
  
  return 0;
}

int main(int argc, char* argv[]) {
scheme_main_setup(1, run, argc, argv);
return 0;
}

The output is:

3
standard-module-name-resolver: collection not found
  for module path: racket/base/lang/reader
  collection: "racket/base/lang"
  in collection directories:
  context...:
   show-collection-err_0
   standard-module-name-resolver
   1/module-path-index-resolve
   do-dynamic-require5_0
   read-syntax3_0
   default-load-handler
   standard-module-name-resolver
   1/module-path-index-resolve
   perform-require!78.1
   for-loop_0
   expand-capturing-lifts
   temp118_0
   temp91_0
   compile15_0
   temp85_0

I'm thinking that the environment isn't correctly setup here, the "in 
collection directories" lists is empty.

Am I going about this the wrong way though? Would I be better served in 
setting up all of the game loops, etc. in Racket, then use FFI just for 
rendering with SDL?

The game I'm making is a roguelike, so performance isn't as critical.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/7b0bcf81-f826-49fd-9f81-9e0d0b0da398%40googlegroups.com.

Re: [racket-users] Ensuring that channels are GC'd when the child thread terminates

[Matthew Flatt]

At Tue, 1 Oct 2019 23:52:05 -0400, David Storrs wrote:
> ; main dispatcher loop in the server.  Receives messages, dispatches
> to child thread for processing
>  (struct file-info (hash) #:transparent)
>  (define channels (make-weak-hash))
>  (let loop ()
> (define msg (get-next-message)) ; e.g. (file-info "sha1-hash-of-file-X")
> (hash-set! channels (file-info-hash msg) ch)
> (thread (thunk (process-file msg ch)
> (loop))
> 
> 1) Am I correct that this does not work? The string that came out of
> file-info-hash is not eq? to the one stored inside msg, meaning that
> it's not referenced from anywhere else, so it's going to disappear the
> moment it goes into the weak hash.

Right.

> 2) The following also would not work:
> (let loop ()
> (define msg (get-next-message))
> (define the-str (file-info-hash msg))  ;; save the value out before using 
> it
> (hash-set! channels the-str ch)
> (thread (thunk (process-file msg ch)
> (loop))
> 
> The (loop) is in tail position, so this is not a recursive call.  That
> means the stack frame is cleared, so 'the-str' is not reachable and
> it's cleared from the weak hash.

Also right.

This variant would retain the hash string until `process-file`
completes:

 (define the-str (file-info-hash msg))
 (hash-set! channels (file-info-hash msg) ch)
 (thread (thunk (process-file msg ch)
(hash-remove! channels the-str)))

In this case, it's handy that `hash-remove!` is a sensible use of
`the-str`, and that use's effect means `the-str` really must be
retained.

In cases where there's no sensible way to use a value like that, as a
last resort `void/reference-sink` from `ffi/unsafe` can ensure that a
value remains reachable.

> 2) This WOULD work:
> (let loop ()
> (define msg (get-next-message)) ; e.g. (file-info "sha1-hash-of-file-X")
> (hash-set! channels msg ch)
> (thread (thunk (process-file msg ch)
> (loop))
> 
> In this case, 'msg' is still reachable from the processing thread, so
> it remains in the weak hash until the processing thread terminates, at
> which point it is removed from the weak hash and the corresponding
> channel is GC'd.

It depends on `process-file`. If `process-file` retains `msg` until it
is otherwise done, then yes. But if `process-file` ignores the argument
for `msg` or only uses it for the first part of its work, then `msg`
can get GCed before `process-file` returns.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d949b2c.1c69fb81.39696.051cSMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[racket-users] Racket Stories

[Jens Axel Søgaard]

Hi All,

As the Slack users already know, I have created a little web-site to share
interesting stories/links/blogs/packages/papers on everything
Racket-related.

https://racket-stories.com

Click "submit" to submit your own stories.

/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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CABefVgyxcwgPA%3Dwdb2HA8mUaFdAiK1FjfEur%3DoDet4e6s5g4xw%40mail.gmail.com.

Re: [racket-users] Re: i18n / translations

[Alexander Shopov]

String constants:
https://docs.racket-lang.org/string-constants/index.html
https://github.com/racket/string-constants

I agree they do not support plurals and context, which should mean it would
be possible to convert the s-expressions (of Racker messages, not the
general case) to po-file and back again.
There are better tools to edit the translations in po-format compared to
doing that directly as s-expressions.
Kind regards:
al_shopov

На ср, 2.10.2019 г. в 12:43 ч. Roman Klochkov 
написа:

> What is racket's own one? srfi-29? String-constants?
>
> Neither of them support plurals and contexts. Or do you mean something
> else?
>
> вторник, 1 октября 2019 г., 16:06:35 UTC+5 пользователь Alexander Shopov
> написал:
>>
>> We should be able to convert to and from po format to racket's own one.
>>
>> На вт, 1.10.2019 г. в 11:11 ч. Bogdan Popa  написа:
>>
>>> This is great!  Thank you.
>>>
>>> Roman Klochkov writes:
>>>
>>> > Now we have gettext: https://docs.racket-lang.org/gettext/index.html
>>> >
>>> > суббота, 9 февраля 2019 г., 18:56:59 UTC+5 пользователь cwebber
>>> написал:
>>> >>
>>> >> How are people currently translating their programs?
>>> >> I expected to see a gettext library or something, but haven't.
>>> >>
>>> >> I see that DrRacket is translated, but I did a few simple greps
>>> through
>>> >> the DrRacket repo and couldn't figure out how.
>>> >>
>>> >> Am I missing something?  Or is this tooling that needs to be written?
>>> >>  - cwebb
>>> >>
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/m2eezwvnik.fsf%40192.168.0.139
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/3505fe7a-8383-476a-ac85-5b903b6cda40%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAP6f5Mk-sUosXH21ObvBUbRNHnzvQu6ALWXSsxxUGFCLUiDmvg%40mail.gmail.com.

Re: [racket-users] Re: i18n / translations

[Roman Klochkov]

What is racket's own one? srfi-29? String-constants?

Neither of them support plurals and contexts. Or do you mean something else?

вторник, 1 октября 2019 г., 16:06:35 UTC+5 пользователь Alexander Shopov 
написал:
>
> We should be able to convert to and from po format to racket's own one.
>
> На вт, 1.10.2019 г. в 11:11 ч. Bogdan Popa > 
> написа:
>
>> This is great!  Thank you.
>>
>> Roman Klochkov writes:
>>
>> > Now we have gettext: https://docs.racket-lang.org/gettext/index.html
>> >
>> > суббота, 9 февраля 2019 г., 18:56:59 UTC+5 пользователь cwebber написал:
>> >>
>> >> How are people currently translating their programs?
>> >> I expected to see a gettext library or something, but haven't.
>> >>
>> >> I see that DrRacket is translated, but I did a few simple greps through
>> >> the DrRacket repo and couldn't figure out how.
>> >>
>> >> Am I missing something?  Or is this tooling that needs to be written?
>> >>  - cwebb
>> >>
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/m2eezwvnik.fsf%40192.168.0.139
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3505fe7a-8383-476a-ac85-5b903b6cda40%40googlegroups.com.