Hi,
GitHub and GitLab both have a 'template repository' function
- https://help.github.com/en/articles/creating-a-template-repository
- https://gitlab.com/gitlab-org/project-templates/contributing
I made a racket-package GitHub template repo at:
https://github.com/spdegabrielle/racket-pack
If someone has time to write a Java-subset-to-x86 compiler in Racket,
with certain restrictions, they can make a partly-scientific blog post
or paper that compares it to these:
http://thume.ca/2019/04/29/comparing-compilers-in-rust-haskell-c-and-python/
https://news.ycombinator.com/item?id=201
But yes, this is directly related to the discussion above because with the
field name information, you can write your own accessor.
Yes it will be a way to go in Racket 2.
But for now, https://docs.racket-lang.org/struct-define/index.html might be a
good workaround for your problem.
T
On 6/15/19, Sorawee Porncharoenwase wrote:
> First of all, . won’t work in standard Racket because . has a special
> meaning (see
> https://docs.racket-lang.org/reference/reader.html#%28part._parse-pair%29).
The `read-cdot` parameter can change the standard meaning
https://docs.racket-lang.org/r
I guess one way to look at it is that place-channels have guarantees
that are like [1] when putting and guarantees that are like regular
channels when getting. Or, put another way, you can't sync on sending
with place-channels, only on receiving. So it is a similar idea, yes.
I'm not sure exactly w
> On Jun 15, 2019, at 8:31 AM, Robby Findler wrote:
>
> Place channels are asynchronous, not syncronous (i.e. you don't have
> two-way rendez-vous). So the call to put returns immediately in
> `loopback-p` before the other end receives the result. And now the
> next iteration of the loop's get
Place channels are asynchronous, not syncronous (i.e. you don't have
two-way rendez-vous). So the call to put returns immediately in
`loopback-p` before the other end receives the result. And now the
next iteration of the loop's get is in parallel to the put from the
previous iteration's.
A standa
> On Jun 14, 2019, at 8:15 PM, Matthew Butterick wrote:
>
> But even after approving a lock request from a certain rendering place, the
> lock server would end up with repeat lock requests from there.
BTW here's a minimal example showing the puzzling message-garbling behavior
between places.
thanks,
the whole idea is to localize the identifiers to the for (preferred) or the
let*.
Reaching back to get the whole list when the for has bound the same
identifier is probably asking a bit much.
Within the given strictures I probably need to bind the list in the let*
and use a differen
9 matches
Mail list logo