Re: [racket-users] Racket News - Issue 36

[Paulo Matos]

Thanks for that version. I will update it today.

On Tuesday, 4 August 2020 at 12:06:12 UTC+2 laurent...@gmail.com wrote:

> Thanks Paulo, very interesting and useful as usual!
>
> This version of the featured paper "Hygienic macro expansion" is a little 
> more readable:
> https://prl.ccs.neu.edu/img/kffd-tr-1986.pdf
>
> Or would Matthias be able to provide a freshly compiled version maybe? :) 
> (I would be truly impressed if the tex file still existed somewhere!)
>
> On Tue, Aug 4, 2020 at 10:41 AM Paulo Matos  wrote:
>
>> Racket News Issue 36 is here!
>> https://racket-news.com/2020/08/racket-news-issue-36.html
>>
>> Grab yourself your favourite cup and pour in some good ol'coffee.
>> Enjoy!
>>
>> Paulo Matos
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/81b9b4d9-5e81-41b6-83dc-b33f3f67dab0n%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/545681b4-a56d-4bfc-bc74-e390659984fan%40googlegroups.com.

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Robert D Kocisko]

Awesome, I didn't know about thread groups.  I'll check into that as an 
option.  I appreciate all your help!

On Tuesday, August 4, 2020 at 2:14:17 PM UTC-6, Matthew Flatt wrote:
>
> At Tue, 4 Aug 2020 14:01:20 -0600, Robert D Kocisko wrote: 
> > My only concern with this is whether that single thread might get mildly 
> > starved compared to other racket threads given that it technically 
> > represents hundreds of 'green threads' inside itself all implemented in 
> C 
> > whereas every other racket thread represents one green thread.  Is there 
> > any way to hint to the thread scheduler that a particular thread needs 
> > higher scheduling priority than others? 
>
> If you can arrange for all other threads to be in a separate group, 
> then all those threads together will have the same scheduling weight as 
> your one thread. I think that's the only mechanism for adjusting 
> weights, currently. 
>
> > Also, in this scenario would unsafe-poller give any underlying 
> > performance benefit compared to using unsafe-fd->evt and sync? 
>
> Probably not, since the `unsafe-fd->sync` uses `unsafe-poller` fairly 
> directly. 
>
>
> Matthew 
>
>

-- 
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/302e380d-6e4f-405c-b220-d7437900a6edo%40googlegroups.com.

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Matthew Flatt]

At Tue, 4 Aug 2020 14:01:20 -0600, Robert D Kocisko wrote:
> My only concern with this is whether that single thread might get mildly
> starved compared to other racket threads given that it technically
> represents hundreds of 'green threads' inside itself all implemented in C
> whereas every other racket thread represents one green thread.  Is there
> any way to hint to the thread scheduler that a particular thread needs
> higher scheduling priority than others?

If you can arrange for all other threads to be in a separate group,
then all those threads together will have the same scheduling weight as
your one thread. I think that's the only mechanism for adjusting
weights, currently.

> Also, in this scenario would unsafe-poller give any underlying
> performance benefit compared to using unsafe-fd->evt and sync?

Probably not, since the `unsafe-fd->sync` uses `unsafe-poller` fairly
directly.


Matthew

-- 
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/20200804141413.252%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Robert D Kocisko]

Genius! I had forgotten that the FD returned from epoll_create can itself
be polled to indicate when any of the currently registered fds are ready to
be processed.  That simplifies everything for sure.

Given all the above I'm planning to pass the epoll FD to unsafe-fd->evt and
then sync on it in a single thread which then calls the C code to process
all the fd changes registered with that epoll instance.

My only concern with this is whether that single thread might get mildly
starved compared to other racket threads given that it technically
represents hundreds of 'green threads' inside itself all implemented in C
whereas every other racket thread represents one green thread.  Is there
any way to hint to the thread scheduler that a particular thread needs
higher scheduling priority than others?

Also, in this scenario would unsafe-poller give any underlying performance
benefit compared to using unsafe-fd->evt and sync?


On Tue, Aug 4, 2020, 1:34 PM Matthew Flatt  wrote:

> You're right: I had momentarily confused epoll with poll. You can just
> use the single file descriptor for an epoll object with things like
> `unsafe-file-descriptor->semaphore`, or you can use `unsafe-poller`.
>
> I'll note that `unsafe-file-descriptor->semaphore` scales to a large
> number of file descriptors as long as you create a thread to block on
> each semaphore. Under the hood, creating and triggering fd-semaphores
> is implemented by incremental operations on an epoll object (or kqueue
> object, etc.), and each blocking thread will be descheduled until a
> semaphore post re-schedules it. But if you already have an epoll object
> and the code to handle it, then you don't need the semaphore-based
> machinery.
>
> Matthew
>
> At Tue, 4 Aug 2020 12:54:56 -0600, Robert D Kocisko wrote:
> > Thanks Matthew!  That was my thought but given the number of fds in play
> > and the frequency of adding and removing interest in them (they are added
> > dynamically as needed) it seems like that option would be rather
> > inefficient.
> >
> > Is there by chance any 'magic back door' which would allow me to register
> > fds directly with Racket's underlying event loop so that I can bypass the
> > extra hops of the thread scheduler and the ffi boundaries? Or if not what
> > would need to be taken into consideration if I wanted to add such a back
> > door via modifying Racket's source?  Are there any concerns with starving
> > other threads or other timing issues?
> >
> > Also I can't help but be intrigued by (unsafe-poller).  I'm wondering
> what
> > benefits it might give (if any) in comparison with the approach you
> > suggested.
> >
> > Thanks,
> > Bob
> >
> > On Tue, Aug 4, 2020, 8:08 AM Matthew Flatt  wrote:
> >
> > > Fusing event loops is always tricky, but if you have the option of
> > > exposing individual file descriptors to Racket, then `ffi/unsafe/port`
> > > is probably the way to go. You can turn a file descriptor into an event
> > > using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
> > > you can block on a set using `sync`, etc.
> > >
> > > Matthew
> > >
> > > At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> > > > I have an existing c++ app that is entirely event-loop driven with
> epoll
> > > > and I am trying to figure out how to integrate Racket in the same
> thread
> > > > and allow the existing code to work as-is.  I have read the docs
> about
> > > the
> > > > C api and the FFI but so far a straightforward and clean option is
> not
> > > > apparent to me.  The 'embedding' examples that I see appear rather
> > > opaque
> > > > to me and at best seem to be geared towards an external loop based on
> > > > select() rather than epoll(), so I'm assuming that the more
> > > straightforward
> > > > approach would be to add the existing event handlers onto Racket's
> event
> > > > system.  To that end, it seems there should be a way to register the
> > > fd's
> > > > of interest with Racket and receive a callback when they are
> read-ready
> > > but
> > > > I can't see a way to do that.  For example, how would I maintain a
> list
> > > of
> > > > fds to pass to (sync) if I went that route?  Or if it's better to
> work
> > > it
> > > > the other way, how would I call (sync) from c code and apply the
> list of
> > > > fds to it?  I vaguely can see a way towards it but it seems at best
> > > super
> > > > inefficient.  Any thoughts or suggestions would be greatly
> appreciated!
> > > >
> > > > Thanks,
> > > > Bob Kocisko
> > > >
> > > > --
> > > > 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/46fb3804-396c-4921-849f-71fe5a6f
> > > > ac7ao%40googlegroups.com.
> > >
>

-- 
Y

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Matthew Flatt]

You're right: I had momentarily confused epoll with poll. You can just
use the single file descriptor for an epoll object with things like
`unsafe-file-descriptor->semaphore`, or you can use `unsafe-poller`.

I'll note that `unsafe-file-descriptor->semaphore` scales to a large
number of file descriptors as long as you create a thread to block on
each semaphore. Under the hood, creating and triggering fd-semaphores
is implemented by incremental operations on an epoll object (or kqueue
object, etc.), and each blocking thread will be descheduled until a
semaphore post re-schedules it. But if you already have an epoll object
and the code to handle it, then you don't need the semaphore-based
machinery.

Matthew

At Tue, 4 Aug 2020 12:54:56 -0600, Robert D Kocisko wrote:
> Thanks Matthew!  That was my thought but given the number of fds in play
> and the frequency of adding and removing interest in them (they are added
> dynamically as needed) it seems like that option would be rather
> inefficient.
> 
> Is there by chance any 'magic back door' which would allow me to register
> fds directly with Racket's underlying event loop so that I can bypass the
> extra hops of the thread scheduler and the ffi boundaries? Or if not what
> would need to be taken into consideration if I wanted to add such a back
> door via modifying Racket's source?  Are there any concerns with starving
> other threads or other timing issues?
> 
> Also I can't help but be intrigued by (unsafe-poller).  I'm wondering what
> benefits it might give (if any) in comparison with the approach you
> suggested.
> 
> Thanks,
> Bob
> 
> On Tue, Aug 4, 2020, 8:08 AM Matthew Flatt  wrote:
> 
> > Fusing event loops is always tricky, but if you have the option of
> > exposing individual file descriptors to Racket, then `ffi/unsafe/port`
> > is probably the way to go. You can turn a file descriptor into an event
> > using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
> > you can block on a set using `sync`, etc.
> >
> > Matthew
> >
> > At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> > > I have an existing c++ app that is entirely event-loop driven with epoll
> > > and I am trying to figure out how to integrate Racket in the same thread
> > > and allow the existing code to work as-is.  I have read the docs about
> > the
> > > C api and the FFI but so far a straightforward and clean option is not
> > > apparent to me.  The 'embedding' examples that I see appear rather
> > opaque
> > > to me and at best seem to be geared towards an external loop based on
> > > select() rather than epoll(), so I'm assuming that the more
> > straightforward
> > > approach would be to add the existing event handlers onto Racket's event
> > > system.  To that end, it seems there should be a way to register the
> > fd's
> > > of interest with Racket and receive a callback when they are read-ready
> > but
> > > I can't see a way to do that.  For example, how would I maintain a list
> > of
> > > fds to pass to (sync) if I went that route?  Or if it's better to work
> > it
> > > the other way, how would I call (sync) from c code and apply the list of
> > > fds to it?  I vaguely can see a way towards it but it seems at best
> > super
> > > inefficient.  Any thoughts or suggestions would be greatly appreciated!
> > >
> > > Thanks,
> > > Bob Kocisko
> > >
> > > --
> > > 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/46fb3804-396c-4921-849f-71fe5a6f
> > > ac7ao%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/20200804133449.2e8%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Robert D Kocisko]

Thanks Matthew!  That was my thought but given the number of fds in play
and the frequency of adding and removing interest in them (they are added
dynamically as needed) it seems like that option would be rather
inefficient.

Is there by chance any 'magic back door' which would allow me to register
fds directly with Racket's underlying event loop so that I can bypass the
extra hops of the thread scheduler and the ffi boundaries? Or if not what
would need to be taken into consideration if I wanted to add such a back
door via modifying Racket's source?  Are there any concerns with starving
other threads or other timing issues?

Also I can't help but be intrigued by (unsafe-poller).  I'm wondering what
benefits it might give (if any) in comparison with the approach you
suggested.

Thanks,
Bob

On Tue, Aug 4, 2020, 8:08 AM Matthew Flatt  wrote:

> Fusing event loops is always tricky, but if you have the option of
> exposing individual file descriptors to Racket, then `ffi/unsafe/port`
> is probably the way to go. You can turn a file descriptor into an event
> using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
> you can block on a set using `sync`, etc.
>
> Matthew
>
> At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> > I have an existing c++ app that is entirely event-loop driven with epoll
> > and I am trying to figure out how to integrate Racket in the same thread
> > and allow the existing code to work as-is.  I have read the docs about
> the
> > C api and the FFI but so far a straightforward and clean option is not
> > apparent to me.  The 'embedding' examples that I see appear rather
> opaque
> > to me and at best seem to be geared towards an external loop based on
> > select() rather than epoll(), so I'm assuming that the more
> straightforward
> > approach would be to add the existing event handlers onto Racket's event
> > system.  To that end, it seems there should be a way to register the
> fd's
> > of interest with Racket and receive a callback when they are read-ready
> but
> > I can't see a way to do that.  For example, how would I maintain a list
> of
> > fds to pass to (sync) if I went that route?  Or if it's better to work
> it
> > the other way, how would I call (sync) from c code and apply the list of
> > fds to it?  I vaguely can see a way towards it but it seems at best
> super
> > inefficient.  Any thoughts or suggestions would be greatly appreciated!
> >
> > Thanks,
> > Bob Kocisko
> >
> > --
> > 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/46fb3804-396c-4921-849f-71fe5a6f
> > ac7ao%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/CAGF%3DAeRWq9r_R3Tq8Zr_txYjpi%3DaLUDcEsfrVOYBW%3DTvO66RHA%40mail.gmail.com.

Re: [racket-users] Racket v7.8

[Sorawee Porncharoenwase]

The prop:struct-field-info doc could also be accessed at
https://plt.eecs.northwestern.edu/snapshots/current/doc/reference/structinfo.html?q=prop%3Astruct-field-info#%28def._%28%28lib._racket%2Fstruct-info..rkt%29._prop~3astruct-field-info%29%29
.

On Tue, Aug 4, 2020 at 7:33 AM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> Yes, there is documentation for this feature! Here are two ways to get it:
>
> 1) On a machine with 7.8 installed, run `raco docs prop:struct-field-info`
> at the command line, or (equivalently) highlight the word in drracket and
> hit F1. Both of these open a web browser window pointed at your local
> documentation installation.
>
> 2) Wait a few days for the 7.8 docs to be installed at
> docs.racket-lang.org.
>
> Best,
>
> John
>
> > On Aug 4, 2020, at 10:28, 'Joel Dueck' via Racket Users <
> racket-users@googlegroups.com> wrote:
> >
> > I'm very interested in the prop:struct-field-info property. Is there any
> documentation on it? I notice docs.racket-lang.org still says 7.7 up at
> the top.
> >
> > Thanks to everyone for this release!
> >
> > On Monday, August 3, 2020 at 12:19:57 PM UTC-5 johnbclements wrote:
> > This release announcement mistakenly omitted two important contributors:
> Tim Brown, and Dionna Amalie Glaze. Many thanks for their help!
> >
> > John Clements
> >
> > > On Aug 3, 2020, at 09:35, John Clements 
> wrote:
> > >
> > > Racket version 7.8 is now available from
> > >
> > > https://racket-lang.org/
> > >
> > >
> > > * Racket CS may become the default Racket implementation in the next
> > > release. With the improvements in this release, Racket CS provides all
> > > of the functionality of Racket BC (the current default
> > > implementation). If, between this release and the next, no bugs are
> > > discovered in Racket CS that are more serious than those typically
> > > discovered in Racket BC, then Racket CS will become the default for
> > > the next release.
> > >
> > > * Racket CS supports AArch32 and AArch64, including places and
> > > futures. The implementation should be considered experimental in this
> > > initial release.
> > >
> > > * Racket CS supports an "incremental" garbage-collection mode that can
> > > eliminate long GC pauses for some applications, such as animations and
> > > interactive games.
> > >
> > > * Racket CS unboxes local floating-point arithmetic (like Racket BC).
> > >
> > > * DrRacket's spell check features lower overhead and has fewer bugs.
> > >
> > > * Web Server performance under high concurrency is [better by up to an
> > > order of magnitude](https://github.com/racket/web-server/pull/94/).
> > > The Web Server is also more resistant to clients attempting to use
> > > unconstrained resources.
> > >
> > > * The math library includes the Kronecker product.
> > >
> > > * Windows supports finer granularity for `sleep` when sleeping for
> short
> > > periods of time, improving performance in animation.
> > >
> > > * The new prop:struct-field-info property provides static information
> > > about field names.
> > >
> > > * Debugging context in Racket CS is limited to 64,000 frames
> > > (approximately the same as Racket BC). This reduces the time taken to
> > > handle out-of-memory failures.
> > >
> > > * In `plot`, the legend font and the plot font can be controlled
> > > independently, and error-bars have an `#:invert?` option.
> > >
> > > * The plot and math libraries have new maintainers: Alex Harsányi for
> > > plot and Pavel Pancheka and Jens Axel Søgaard for math.
> > >
> > >
> > > The following people contributed to this release:
> > >
> > > Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew
> Kent,
> > > Andrew Mauer-Oats, Atharva Raykar, Ben Greenman, Benjamin Yeung, Bert
> De
> > > Ketelaere, Bogdan Popa, David Christiansen, David Florness, Diego
> > > Crespo, Fred Fu, Gary Baumgartner, Georges Dupéron, Gustavo
> Massaccesi,
> > > J. Ian Johnson, Jack Firth, Jay McCarthy, Jens Axel Søgaard, Jesse
> > > Alama, John Clements, Laurent Orseau, Leif Andersen, Luka Hadži-Đokić,
> > > Marc, Matthew Butterick, Matthew Flatt, Matthew Parris, Matthew
> Turland,
> > > Matthias Felleisen, Michael Ballantyne, Mike Sperber, Noah W M, Paulo
> > > Matos, Pavel Panchekha, Philip McGrath, Raphael Das Gupta, Reuben
> > > Thomas, Ricardo Herdt, Robby Findler, Ryan Culpepper, Sam
> > > Tobin-Hochstadt, Sancho McCann, Sorawee Porncharoenwase, Spencer
> > > Florence, Stephen De Gabrielle, Syntacticlosure, frogbird, kryptine,
> > > rsiddharth, and yurkobb
> > >
> > > Feedback Welcome
> > >
> >
> >
> >
> >
> > --
> > 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/c5c0ad1d-d8d5-43c3-bceb-228d89e1d16fn%40googlegroups.com
> .
>
>
>
> --

Re: [racket-users] Racket v7.8

['John Clements' via Racket Users]

Yes, there is documentation for this feature! Here are two ways to get it:

1) On a machine with 7.8 installed, run `raco docs prop:struct-field-info` at 
the command line, or (equivalently) highlight the word in drracket and hit F1. 
Both of these open a web browser window pointed at your local documentation 
installation.

2) Wait a few days for the 7.8 docs to be installed at docs.racket-lang.org.

Best,

John

> On Aug 4, 2020, at 10:28, 'Joel Dueck' via Racket Users 
>  wrote:
> 
> I'm very interested in the prop:struct-field-info property. Is there any 
> documentation on it? I notice docs.racket-lang.org still says 7.7 up at the 
> top.
> 
> Thanks to everyone for this release!
> 
> On Monday, August 3, 2020 at 12:19:57 PM UTC-5 johnbclements wrote:
> This release announcement mistakenly omitted two important contributors: Tim 
> Brown, and Dionna Amalie Glaze. Many thanks for their help! 
> 
> John Clements 
> 
> > On Aug 3, 2020, at 09:35, John Clements  wrote: 
> > 
> > Racket version 7.8 is now available from 
> > 
> > https://racket-lang.org/ 
> > 
> > 
> > * Racket CS may become the default Racket implementation in the next 
> > release. With the improvements in this release, Racket CS provides all 
> > of the functionality of Racket BC (the current default 
> > implementation). If, between this release and the next, no bugs are 
> > discovered in Racket CS that are more serious than those typically 
> > discovered in Racket BC, then Racket CS will become the default for 
> > the next release. 
> > 
> > * Racket CS supports AArch32 and AArch64, including places and 
> > futures. The implementation should be considered experimental in this 
> > initial release. 
> > 
> > * Racket CS supports an "incremental" garbage-collection mode that can 
> > eliminate long GC pauses for some applications, such as animations and 
> > interactive games. 
> > 
> > * Racket CS unboxes local floating-point arithmetic (like Racket BC). 
> > 
> > * DrRacket's spell check features lower overhead and has fewer bugs. 
> > 
> > * Web Server performance under high concurrency is [better by up to an 
> > order of magnitude](https://github.com/racket/web-server/pull/94/). 
> > The Web Server is also more resistant to clients attempting to use 
> > unconstrained resources. 
> > 
> > * The math library includes the Kronecker product. 
> > 
> > * Windows supports finer granularity for `sleep` when sleeping for short 
> > periods of time, improving performance in animation. 
> > 
> > * The new prop:struct-field-info property provides static information 
> > about field names. 
> > 
> > * Debugging context in Racket CS is limited to 64,000 frames 
> > (approximately the same as Racket BC). This reduces the time taken to 
> > handle out-of-memory failures. 
> > 
> > * In `plot`, the legend font and the plot font can be controlled 
> > independently, and error-bars have an `#:invert?` option. 
> > 
> > * The plot and math libraries have new maintainers: Alex Harsányi for 
> > plot and Pavel Pancheka and Jens Axel Søgaard for math. 
> > 
> > 
> > The following people contributed to this release: 
> > 
> > Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, 
> > Andrew Mauer-Oats, Atharva Raykar, Ben Greenman, Benjamin Yeung, Bert De 
> > Ketelaere, Bogdan Popa, David Christiansen, David Florness, Diego 
> > Crespo, Fred Fu, Gary Baumgartner, Georges Dupéron, Gustavo Massaccesi, 
> > J. Ian Johnson, Jack Firth, Jay McCarthy, Jens Axel Søgaard, Jesse 
> > Alama, John Clements, Laurent Orseau, Leif Andersen, Luka Hadži-Đokić, 
> > Marc, Matthew Butterick, Matthew Flatt, Matthew Parris, Matthew Turland, 
> > Matthias Felleisen, Michael Ballantyne, Mike Sperber, Noah W M, Paulo 
> > Matos, Pavel Panchekha, Philip McGrath, Raphael Das Gupta, Reuben 
> > Thomas, Ricardo Herdt, Robby Findler, Ryan Culpepper, Sam 
> > Tobin-Hochstadt, Sancho McCann, Sorawee Porncharoenwase, Spencer 
> > Florence, Stephen De Gabrielle, Syntacticlosure, frogbird, kryptine, 
> > rsiddharth, and yurkobb 
> > 
> > Feedback Welcome 
> > 
> 
> 
> 
> 
> -- 
> 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/c5c0ad1d-d8d5-43c3-bceb-228d89e1d16fn%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/b09bd279-19b3-4c0c-b91f-0a40242eb3d5%40mtasv.net.

[racket-users] Re: Racket v7.8

['Joel Dueck' via Racket Users]

I'm very interested in the prop:struct-field-info property. Is there any 
documentation on it? I notice docs.racket-lang.org still says 7.7 up at the 
top.

Thanks to everyone for this release!

On Monday, August 3, 2020 at 12:19:57 PM UTC-5 johnbclements wrote:

> This release announcement mistakenly omitted two important contributors: 
> Tim Brown, and Dionna Amalie Glaze. Many thanks for their help!
>
> John Clements
>
> > On Aug 3, 2020, at 09:35, John Clements  
> wrote:
> > 
> > Racket version 7.8 is now available from
> > 
> > https://racket-lang.org/
> > 
> > 
> > * Racket CS may become the default Racket implementation in the next
> > release. With the improvements in this release, Racket CS provides all
> > of the functionality of Racket BC (the current default
> > implementation). If, between this release and the next, no bugs are
> > discovered in Racket CS that are more serious than those typically
> > discovered in Racket BC, then Racket CS will become the default for
> > the next release.
> > 
> > * Racket CS supports AArch32 and AArch64, including places and
> > futures. The implementation should be considered experimental in this
> > initial release.
> > 
> > * Racket CS supports an "incremental" garbage-collection mode that can
> > eliminate long GC pauses for some applications, such as animations and
> > interactive games.
> > 
> > * Racket CS unboxes local floating-point arithmetic (like Racket BC).
> > 
> > * DrRacket's spell check features lower overhead and has fewer bugs.
> > 
> > * Web Server performance under high concurrency is [better by up to an
> > order of magnitude](https://github.com/racket/web-server/pull/94/).
> > The Web Server is also more resistant to clients attempting to use
> > unconstrained resources.
> > 
> > * The math library includes the Kronecker product.
> > 
> > * Windows supports finer granularity for `sleep` when sleeping for short
> > periods of time, improving performance in animation.
> > 
> > * The new prop:struct-field-info property provides static information
> > about field names.
> > 
> > * Debugging context in Racket CS is limited to 64,000 frames
> > (approximately the same as Racket BC). This reduces the time taken to
> > handle out-of-memory failures.
> > 
> > * In `plot`, the legend font and the plot font can be controlled
> > independently, and error-bars have an `#:invert?` option.
> > 
> > * The plot and math libraries have new maintainers: Alex Harsányi for
> > plot and Pavel Pancheka and Jens Axel Søgaard for math.
> > 
> > 
> > The following people contributed to this release:
> > 
> > Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent,
> > Andrew Mauer-Oats, Atharva Raykar, Ben Greenman, Benjamin Yeung, Bert De
> > Ketelaere, Bogdan Popa, David Christiansen, David Florness, Diego
> > Crespo, Fred Fu, Gary Baumgartner, Georges Dupéron, Gustavo Massaccesi,
> > J. Ian Johnson, Jack Firth, Jay McCarthy, Jens Axel Søgaard, Jesse
> > Alama, John Clements, Laurent Orseau, Leif Andersen, Luka Hadži-Đokić,
> > Marc, Matthew Butterick, Matthew Flatt, Matthew Parris, Matthew Turland,
> > Matthias Felleisen, Michael Ballantyne, Mike Sperber, Noah W M, Paulo
> > Matos, Pavel Panchekha, Philip McGrath, Raphael Das Gupta, Reuben
> > Thomas, Ricardo Herdt, Robby Findler, Ryan Culpepper, Sam
> > Tobin-Hochstadt, Sancho McCann, Sorawee Porncharoenwase, Spencer
> > Florence, Stephen De Gabrielle, Syntacticlosure, frogbird, kryptine,
> > rsiddharth, and yurkobb
> > 
> > Feedback Welcome
> > 
>
>
>
>

-- 
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/c5c0ad1d-d8d5-43c3-bceb-228d89e1d16fn%40googlegroups.com.

Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

[Matthew Flatt]

Fusing event loops is always tricky, but if you have the option of
exposing individual file descriptors to Racket, then `ffi/unsafe/port`
is probably the way to go. You can turn a file descriptor into an event
using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
you can block on a set using `sync`, etc.

Matthew

At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> I have an existing c++ app that is entirely event-loop driven with epoll 
> and I am trying to figure out how to integrate Racket in the same thread 
> and allow the existing code to work as-is.  I have read the docs about the 
> C api and the FFI but so far a straightforward and clean option is not 
> apparent to me.  The 'embedding' examples that I see appear rather opaque 
> to me and at best seem to be geared towards an external loop based on 
> select() rather than epoll(), so I'm assuming that the more straightforward 
> approach would be to add the existing event handlers onto Racket's event 
> system.  To that end, it seems there should be a way to register the fd's 
> of interest with Racket and receive a callback when they are read-ready but 
> I can't see a way to do that.  For example, how would I maintain a list of 
> fds to pass to (sync) if I went that route?  Or if it's better to work it 
> the other way, how would I call (sync) from c code and apply the list of 
> fds to it?  I vaguely can see a way towards it but it seems at best super 
> inefficient.  Any thoughts or suggestions would be greatly appreciated!
> 
> Thanks,
> Bob Kocisko
> 
> -- 
> 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/46fb3804-396c-4921-849f-71fe5a6f
> ac7ao%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/20200804080838.2d0%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Advice wanted about new opengl binding

[Sam Tobin-Hochstadt]

On Mon, Aug 3, 2020, 7:27 PM Hendrik Boom  wrote:

> On Mon, Aug 03, 2020 at 02:01:16PM -0400, Philip McGrath wrote:
> > Is this what you're looking for?
> https://pkgs.racket-lang.org/package/sgl
> >
> > -Philip
>
> Yes, looks like it.  Is it messing from the index for some good reason?
>

By default, the front page of pkgs.racket-lang.org doesn't show packages
that are in the main-distribution, such as sgl.


> I'm not sure how the packaging works.
>
> I end up at https://github.com/racket/sgl/tree/master
> where I find multiple files, including main.rkt, sgl.rlt, and gl.rkt.
> Am I correct that main.rkt is what I get with (require sgl)
> and that gl.rkt is what I get with (require sgl/gl)?
>

That's correct.

Sam


-- hendrik
>
> >
> >
> > On Sun, Aug 2, 2020 at 5:51 PM Hendrik Boom 
> wrote:
> >
> > > Time to rethink everything before I go further.
> > >
> > > So far I've found several opengl bindings.
> > > There's opengl, documented here:
> > >https://docs.racket-lang.org/opengl/index.html
> > > There are sgl and sgl/gl, documented here:
> > >https://docs.racket-lang.org/sgl/index.html
> > > and there's a typed opengl hidden with in pict3.
> > >
> > > But I cannot find sgl and sgl/gl in the index of packages
> > > at https://pkgs.racket-lang.org/
> > >
> > > Shouldn't they be there?
> > > Are they there in disguise?
> > > Abd where should I look for current source code?
> > > The index is pretty good at identifying source code for other packages.
> > >
> > > -- hendrik
> > >
> > > --
> > > 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/20200802215123.iiqik4wpfusarcw4%40topoi.pooq.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/CAH3z3gYmn4_5sTUNWuZDcpjL5shJmU2quTtgx72%3DoycOXccp5A%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/20200803232728.e4yv7khscvr7c2wl%40topoi.pooq.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/CAK%3DHD%2Ba%3DubOLkjrgU1H5omQSO4p8h3rwiZKh4B7UJiQLtWKc%2Bg%40mail.gmail.com.

Re: [racket-users] Racket News - Issue 36

[Laurent]

Thanks Paulo, very interesting and useful as usual!

This version of the featured paper "Hygienic macro expansion" is a little
more readable:
https://prl.ccs.neu.edu/img/kffd-tr-1986.pdf

Or would Matthias be able to provide a freshly compiled version maybe? :)
(I would be truly impressed if the tex file still existed somewhere!)

On Tue, Aug 4, 2020 at 10:41 AM Paulo Matos  wrote:

> Racket News Issue 36 is here!
> https://racket-news.com/2020/08/racket-news-issue-36.html
>
> Grab yourself your favourite cup and pour in some good ol'coffee.
> Enjoy!
>
> Paulo Matos
>
> --
> 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/81b9b4d9-5e81-41b6-83dc-b33f3f67dab0n%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/CABNTSaFMFZrJPgHg2FyLPmxngz%3D2o2zAFJ4xS1o7vrsRJxwcmA%40mail.gmail.com.

[racket-users] Racket News - Issue 36

[Paulo Matos]

Racket News Issue 36 is here!
https://racket-news.com/2020/08/racket-news-issue-36.html

Grab yourself your favourite cup and pour in some good ol'coffee.
Enjoy!

Paulo Matos

-- 
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/81b9b4d9-5e81-41b6-83dc-b33f3f67dab0n%40googlegroups.com.