Re: [racket-users] The Racket programming language mailing list has moved!!

[Sam Tobin-Hochstadt]

We're using the free-for-open-source plan from Discourse:
https://free.discourse.group/

Sam

On Fri, Jul 21, 2023 at 1:13 PM Ryan Johnson  wrote:

> Thanks
>
> How did you guys get a discourse.group subdomain? I visited
> discourse.group and the domain is unreachable.
>
> What software is it running?
> On 7/21/2023 11:49 AM, Racket Users wrote:
>
> The Racket programming language mailing list is deprecated and gets very
> little traffic.
>
> Forum/mailing list discussion has moved to https://racket.discourse.group/
> - this is a web forum that supports use via email like a mailing list.
>
> Please use this invitation:
> https://racket.discourse.group/invites/VxkBcXY7yL
> The welcome post includes a link mailing list access guidance for those
> who prefer it.
>
> Best regards
>
> Stephen
>
> --
> This group is deprecated and retained as an archive.
>
> Racket discussions have moved to the Racket Discourse at
> https://racket.discourse.group/ .
>
> ---
> 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.
> ---
> 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/7fafdede-dba2-4afc-9343-91266ea0ad2bn%40googlegroups.com
> 
> .
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_5314016891397136404_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> --
> This group is deprecated and retained as an archive.
>
> Racket discussions have moved to the Racket Discourse at
> https://racket.discourse.group/ .
>
> ---
> 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.
> ---
> 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/edde0187-15c8-bcc9-4ce1-32e44c646297%40gmail.com
> 
> .
>

-- 
This group is deprecated and retained as an archive. 

Racket discussions have moved to the Racket Discourse at  
https://racket.discourse.group/ .

---
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.
--- 
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%2BauRLNYQOFJLiaZHLH3Vs5N-3BYj1eQ7iWce9qQ9crO5Q%40mail.gmail.com.

Re: [racket-users] how do I remove a specified collection?

[Sam Tobin-Hochstadt]

I don't think that you need to remove `t`. Instead, your problem is
that somewhere something is calling `collection-path` with "t" as an
argument. If you provide more information about the context and the
error message, it would be easier to help here.

Sam

On Mon, Aug 8, 2022 at 11:31 AM Don Green  wrote:
>
> $ raco setup ?
> collection-path: collection not found
>   collection: "t"
>
> How do I go about finding and removing: collection: "t"  ?
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/57fecc34-3485-415b-8c9d-fcb57ef4d15cn%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/CAK%3DHD%2BaR8KjNn%2BCLeJ-UV%2BHrA-FFG5vU_hZ3pQ7r8xVq%2B%2B9wGg%40mail.gmail.com.

Re: [racket-users] Core Team: I need you decide what I should do about the spammer.

[Sam Tobin-Hochstadt]

On Wed, Jan 12, 2022 at 1:14 PM Sage Gerard  wrote:
>
> Yes. I assumed was that (b) was not true, since I thought volunteers
> were hard to come by for most community tasks. "Ask only" makes more
> sense if someone can be found and made available at any time.
>
> All: I normally wait for a go-ahead from a quorum before applying
> changes like this. If I don't need to wait, then please tell me.

I think if you're good with this approach, you should move forward with it.

Sam

> Sam: You mentioned someone got a 404 from an invite link. 404s sometimes
> disguise permission issues, so I suspect that switching to "ask to join"
> will make that problem go away too.
>
> On 1/12/22 1:00 PM, Sam Tobin-Hochstadt wrote:
>
> > Here's my suggestion: we switch to "ask to join" on Google Groups. I
> > think that will notify all the moderators, and thus (a) more people
> > can potentially respond (eg, I think I currently get those emails too)
> > and (b) if someone can no longer take on this responsibility, it's
> > easy to have someone else step up. The alternative where we specify a
> > specific email requires potentially changing that email address when
> > the responsibility changes.
> >
> > Does that seem like a reasonable approach?
> >
> > Sam
> >
> > On Tue, Jan 11, 2022 at 2:30 PM Sage Gerard  wrote:
> >> No no, that was helpful, thank you. We do need to figure this part out.
> >>
> >> On 1/11/22 2:22 PM, Robby Findler wrote:
> >>
> >> Sorry, I probably shouldn't have jumped in here.  I'm happy with whatever 
> >> you folks decide is best!
> >>
> >> Robby
> >>
> >>
> >> On Tue, Jan 11, 2022 at 1:09 PM Sage Gerard  wrote:
> >>> Makes sense.
> >>>
> >>> I'll repeat one key difference in the context of Google Groups
> >>>
> >>> Ask to join
> >>>
> >>> Racket volunteer must be available for vetting requests, on receiving 
> >>> them. Member starts process in Google Groups
> >>>
> >>> Invite only
> >>>
> >>> Racket volunteer may vet first, but must initiate contact with member. As 
> >>> Sam said, strangers can't start that process.
> >>>
> >>> If you publish an email to request invites, then the process is going to 
> >>> be "ask to join" no matter what, so the mailing list configuration is 
> >>> relevant for a different reason. Do we want members to start the process 
> >>> in Google Groups, or by sending an email to a fixed address?
> >>>
> >>> On 1/11/22 1:51 PM, Robby Findler wrote:
> >>>
> >>> Probably people find out about the mailing list by the website, right? We 
> >>> could post an email address or two there where asks should go?
> >>>
> >>> Robby
> >>>
> >>>
> >>> On Tue, Jan 11, 2022 at 12:41 PM Sam Tobin-Hochstadt  
> >>> wrote:
> >>>> One thing to note here: it's now not possible to _request_ to join the
> >>>> list. If someone wants to join the list, they have to know someone who
> >>>> is already a member and ask them to join.
> >>>>
> >>>> It looks like another option is "Anyone on the web can ask" to join.
> >>>> It's not immediately clear who gets the emails when people ask, but
> >>>> this seems like it might be a good intermediate position.
> >>>>
> >>>> Sam
> >>>>
> >>>> On Sun, Dec 19, 2021 at 12:32 PM Sage Gerard  wrote:
> >>>>> Alright, thanks to all of you for the quick replies. As of this 
> >>>>> writing, the list has been reconfigured to create an explicit perimeter 
> >>>>> between the non-members and members. The public can no longer let 
> >>>>> themselves in.
> >>>>>
> >>>>> Not totally out of the woods yet.
> >>>>>
> >>>>> Someone please confirm if you can invite others using Members page -> 
> >>>>> "Add Member". If not, then please follow up with me.
> >>>>> This model can be compromised by someone going rogue and inviting a 
> >>>>> bunch of spammers. I'm expecting that our communal trust is high enough 
> >>>>> to make this unlikely.
> >>>>>
> >>>>> Considering the risk profile seems less scary, disregard request to 
> >>>>> delete my em

Re: [racket-users] Core Team: I need you decide what I should do about the spammer.

[Sam Tobin-Hochstadt]

Here's my suggestion: we switch to "ask to join" on Google Groups. I
think that will notify all the moderators, and thus (a) more people
can potentially respond (eg, I think I currently get those emails too)
and (b) if someone can no longer take on this responsibility, it's
easy to have someone else step up. The alternative where we specify a
specific email requires potentially changing that email address when
the responsibility changes.

Does that seem like a reasonable approach?

Sam

On Tue, Jan 11, 2022 at 2:30 PM Sage Gerard  wrote:
>
> No no, that was helpful, thank you. We do need to figure this part out.
>
> On 1/11/22 2:22 PM, Robby Findler wrote:
>
> Sorry, I probably shouldn't have jumped in here.  I'm happy with whatever you 
> folks decide is best!
>
> Robby
>
>
> On Tue, Jan 11, 2022 at 1:09 PM Sage Gerard  wrote:
>>
>> Makes sense.
>>
>> I'll repeat one key difference in the context of Google Groups
>>
>> Ask to join
>>
>> Racket volunteer must be available for vetting requests, on receiving them. 
>> Member starts process in Google Groups
>>
>> Invite only
>>
>> Racket volunteer may vet first, but must initiate contact with member. As 
>> Sam said, strangers can't start that process.
>>
>> If you publish an email to request invites, then the process is going to be 
>> "ask to join" no matter what, so the mailing list configuration is relevant 
>> for a different reason. Do we want members to start the process in Google 
>> Groups, or by sending an email to a fixed address?
>>
>> On 1/11/22 1:51 PM, Robby Findler wrote:
>>
>> Probably people find out about the mailing list by the website, right? We 
>> could post an email address or two there where asks should go?
>>
>> Robby
>>
>>
>> On Tue, Jan 11, 2022 at 12:41 PM Sam Tobin-Hochstadt  
>> wrote:
>>>
>>> One thing to note here: it's now not possible to _request_ to join the
>>> list. If someone wants to join the list, they have to know someone who
>>> is already a member and ask them to join.
>>>
>>> It looks like another option is "Anyone on the web can ask" to join.
>>> It's not immediately clear who gets the emails when people ask, but
>>> this seems like it might be a good intermediate position.
>>>
>>> Sam
>>>
>>> On Sun, Dec 19, 2021 at 12:32 PM Sage Gerard  wrote:
>>> >
>>> > Alright, thanks to all of you for the quick replies. As of this writing, 
>>> > the list has been reconfigured to create an explicit perimeter between 
>>> > the non-members and members. The public can no longer let themselves in.
>>> >
>>> > Not totally out of the woods yet.
>>> >
>>> > Someone please confirm if you can invite others using Members page -> 
>>> > "Add Member". If not, then please follow up with me.
>>> > This model can be compromised by someone going rogue and inviting a bunch 
>>> > of spammers. I'm expecting that our communal trust is high enough to make 
>>> > this unlikely.
>>> >
>>> > Considering the risk profile seems less scary, disregard request to 
>>> > delete my emails. :)
>>> >
>>> > On 12/18/21 3:02 PM, Matthias Felleisen wrote:
>>> >
>>> >
>>> > +2! And many thanks. (I was personally spared this spam until very 
>>> > recently. No clue why)
>>> >
>>> > — Matthias
>>> >
>>> >
>>> >
>>> >
>>> > On Dec 18, 2021, at 2:55 PM, Robby Findler  
>>> > wrote:
>>> >
>>> > +1! Thank you.
>>> >
>>> > Robby
>>> >
>>> > On Sat, Dec 18, 2021 at 1:43 PM Matthew Flatt  wrote:
>>> >>
>>> >> The "members" option sounds right to me. Thanks for tracking down a way
>>> >> to improve the situation!
>>> >>
>>> >> At Sat, 18 Dec 2021 19:35:23 +, Sage Gerard wrote:
>>> >> > Core team,
>>> >> >
>>> >> > Sam asked me to issue bans for a troublesome spammer. I've done so, 
>>> >> > even
>>> >> > just today. I understand I need quorum for larger decisions. This is 
>>> >> > why
>>> >> > I have not yet reconfigured the list to permanently stop the spammer.
>>> >> > After researching the problem further, I need your urgent attention.
>>> >&g

Re: [racket-users] Core Team: I need you decide what I should do about the spammer.

[Sam Tobin-Hochstadt]

One thing to note here: it's now not possible to _request_ to join the
list. If someone wants to join the list, they have to know someone who
is already a member and ask them to join.

It looks like another option is "Anyone on the web can ask" to join.
It's not immediately clear who gets the emails when people ask, but
this seems like it might be a good intermediate position.

Sam

On Sun, Dec 19, 2021 at 12:32 PM Sage Gerard  wrote:
>
> Alright, thanks to all of you for the quick replies. As of this writing, the 
> list has been reconfigured to create an explicit perimeter between the 
> non-members and members. The public can no longer let themselves in.
>
> Not totally out of the woods yet.
>
> Someone please confirm if you can invite others using Members page -> "Add 
> Member". If not, then please follow up with me.
> This model can be compromised by someone going rogue and inviting a bunch of 
> spammers. I'm expecting that our communal trust is high enough to make this 
> unlikely.
>
> Considering the risk profile seems less scary, disregard request to delete my 
> emails. :)
>
> On 12/18/21 3:02 PM, Matthias Felleisen wrote:
>
>
> +2! And many thanks. (I was personally spared this spam until very recently. 
> No clue why)
>
> — Matthias
>
>
>
>
> On Dec 18, 2021, at 2:55 PM, Robby Findler  wrote:
>
> +1! Thank you.
>
> Robby
>
> On Sat, Dec 18, 2021 at 1:43 PM Matthew Flatt  wrote:
>>
>> The "members" option sounds right to me. Thanks for tracking down a way
>> to improve the situation!
>>
>> At Sat, 18 Dec 2021 19:35:23 +, Sage Gerard wrote:
>> > Core team,
>> >
>> > Sam asked me to issue bans for a troublesome spammer. I've done so, even
>> > just today. I understand I need quorum for larger decisions. This is why
>> > I have not yet reconfigured the list to permanently stop the spammer.
>> > After researching the problem further, I need your urgent attention.
>> >
>> > I found that the spam messages sometimes link to other Google group
>> > posts affected by the spammer. A recent trail leads to a
>> > comp.lang.python Google message in 2017. I suspect that email addresses
>> > are scraped in unmoderated lists that freely hand out membership. After
>> > checking the list settings, I found that this is one of those lists. I
>> > hypothesize that our email addresses are being scraped and
>> > cross-referenced for use in other unmoderated lists.
>> >
>> > It's one thing to flatly complain about a spammer on this list, and
>> > another to willingly maintain a transmission vector. We need to stop
>> > automatically handing out group membership with our current settings. We
>> > can have  issue list memberships. I need you all to fill in the
>> > blank with "moderators" or "members." I'll translate the settings
>> > accordingly.
>> >
>> > Given the holidays, I respect your time. Please reciprocate with respect
>> > for the urgency this problem creates. I will revoke my own mailing list
>> > privileges and membership in three weeks, on January 8th, 2022. I will
>> > leave the settings however they read at the time to prevent
>> > interruption, and request that own messages then be deleted to limit the
>> > role my email address plays for the spammer.
>> >
>> > I am not volunteering to moderate membership applications, and I am not
>> > commenting on how to verify the impact of possible email leaks. Between
>> > the Discourse move and (majority?) perspective towards email, I'm not
>> > sure how I would be useful doing either. If my opinion holds weight, I'd
>> > advise the answer be "members" so that any available moderators can
>> > focus on rule breakers while the community grows at a self-directed speed.
>> >
>> > Let me know, and thank you.
>> >
>> >
>> >
>> > --
>> > 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/5fa6a8bb-88e4-37c6-f0b9-2ed372bc
>> > e8fe%40sagegerard.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/20211218124300.343%40sirmail.smtps.cs.utah.edu.
>
>
> --
> 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/CAL3TdOMCXH4Zio1%2B96Nj_Zgj2vByetG-%3D8i93%3DLYjTpaBrw8DA%40mail.gmail.com.
>
>
> --
> You received this message because you 

Re: [racket-users] Discourse - Mailing list mode

[Sam Tobin-Hochstadt]

It appears that enabling this is quite simple. I believe I have set it
up so that emailing racket+uncategorize...@discoursemail.com should
create a new topic in the Uncategorized category. Feel free to test it
out.

Sam

On Thu, Dec 9, 2021 at 8:27 AM Stephen De Gabrielle
 wrote:
>
> > it’s becoming apparent to me that setting up posting via email is frankly 
> > difficult; I think that monitoring the list using mailing-list mode is 
> > plausible, but posting, at this point, is not.
>
> I had a chat with a Discourse consultant and they thought posting by email 
> was possible if you self host, but self hosting with mailing list would 
> require both a hosting provider, and a send mail provider (he uses digital 
> ocean with sendgrid or mailgun). Receiving email is handled by the 'mail 
> receiver container' if you are self hosting.
>
> It was a casual conversation, and I don't know him well.  It would be good to 
> know if other PL communities have done this
>
> stephen
>
>
>
> On Wed, Dec 8, 2021 at 6:47 PM 'John Clements' via Racket Users 
>  wrote:
>>
>> Your points are well taken, and moving away from a traditional mailing list 
>> is not a decision that we took lightly; the fact is that we were simply 
>> *failing* when it came to moderating the mailing list as run by google 
>> groups, and running one through mailman was even worse. It appears that 
>> discourse will allow us to spread the load of moderating the group across 
>> the members of the group, rather than depending on one or two points of 
>> failure.
>>
>> BTW, lest you think that I think that discourse solves all our problems: 
>> it’s becoming apparent to me that setting up posting via email is frankly 
>> difficult; I think that monitoring the list using mailing-list mode is 
>> plausible, but posting, at this point, is not. I guess I shouldn’t be 
>> shocked: that’s the whole problem with email, it’s not authenticated in any 
>> reasonable or widely used way.
>>
>> Regardless, I’m happy with the move: we have about 181 people registered, 
>> and the volume there looks robust and sustainable.
>>
>> John
>>
>> > On Dec 8, 2021, at 13:16, George Neuner  wrote:
>> >
>> >
>> > On 12/8/2021 12:34 PM, James Platt wrote:
>> >> On Dec 8, 2021, at 10:45 AM, George Neuner wrote:
>> >>
>> >> > It's a big deal if you are (or were) following multiple groups.
>> >>
>> >> I don't understand.  Why is this an issue?  I find it very convenient to 
>> >> filter each group into it's own folder in email.  If this were a 
>> >> non-technical group, you wouldn't expect everyone to know how to do that 
>> >> but anyone who is a programmer ought to have no problem configuring 
>> >> filters and folders.
>> >
>> > If you had continued reading, you would have seen my comment that NOT ALL 
>> > news groups support list distribution or posting via email. NNTP is not 
>> > email.  Usenet group moderators[*] can choose how to make their groups 
>> > available: the default is via list distribution and NNTP both, but the 
>> > moderator can deliberately disable one or the other - or only enable 
>> > digests via email, or disable posting.
>> >
>> > My complaint is having to read some things via NNTP and others through 
>> > email because, while there are programs that do both, I haven't found any 
>> > single program that does BOTH WELL.  And that is without even considering 
>> > the growing number of ... don't want to confuse by saying "groups", let's 
>> > call them "crowds" ... that have abandoned Usenet entirely in favor of web 
>> > forums.
>> >
>> > George
>> >
>> > [*] even unmoderated groups have a moderator/administrator - by default it 
>> > is whoever started the group.
>> >
>> >
>> > --
>> > 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/5f17-59b4-a381-ddd7-25b435887694%40comcast.net.
>>
>> --
>> 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/bacee3b2-b372-4dd0-af60-c657ba984936%40mtasv.net.
>
> --
> 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/CAGHj7-LurQpXeyr_Q4cbZZyceOO3x3hiymu4n2rEWNYA0cAK3w%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To 

[racket-users] Looking for system admin help for the package system

[Sam Tobin-Hochstadt]

Currently, the implementation of https://pkgs.racket-lang.org as well
as https://pkg-build.racket-lang.org (see Notes) is primarily
maintained by Matthew Flatt, although much of it was originally
written by Jay McCarthy and Tony Garnock-Jones (for pkgs in
particular). Matthew of course wears a lot of hats and maintains lots
of things, and he's tired of this job.

As a result, I'm going to take over the sysadmin role, but I'm looking
for additional people who can help out as well -- this is a key part
of Racket infrastructure and one person is probably not enough. Anyone
with experience with system admin, web servers, the Racket web server,
AWS, Docker, etc would be great, or but expertise is _not_ required,
just a willingness to help out.

Of course, there are many ways to improve the system as well, and
helping to maintain it is a great way to get started on that.

If you're willing to volunteer some time to help with this, let me
know, either here or by messaging me (@samth) on Discord or Slack.

Sam

### Notes:

The implementation of pkgs.racket-lang.org is a front-end here:
https://github.com/racket/racket-pkg-website and a backend here:
https://github.com/racket/pkg-index/. They both run on the same EC2
instance, and store almost all of the state (including the index of
packages) in S3.

The implementation of pkg-build.racket-lang.org is a separate
continously-running EC2 instance running the `pkg-build` package,
implemented here: https://github.com/racket/pkg-build

-- 
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%2Ba5zFaHMGijuhCZ_jb7g1aEmukMwyXfxHYiErEWU%2B5aFQ%40mail.gmail.com.

[racket-users] Security advisory for racket/sandbox; fixed in v8.2

[Sam Tobin-Hochstadt]

The Racket team recently became aware of a security vulnerability in
the `racket/sandbox` library. Code evaluated using a sandbox could
cause system modules to incorrectly use attacker-created modules
instead of their intended dependencies. This could allow system
functions to be controlled by the attacker, giving access to
facilities intended to be restricted.

The official advisory is at
https://github.com/racket/racket/security/advisories/GHSA-cgrw-p7p7-937c

To address this vulnerability, anyone who uses a sandbox to evaluate
untrusted code should upgrade to version 8.2. This includes all uses
of the Handin server.

For users of the Handin server, it now provides an API to restrict
`require`s for uses of teaching languages. We strongly encourage using
this API [1], which can prevent exploiting this bug as well as other
problems that access to full Racket or other installed modules might
expose.

Feedback on this advisory, and any security issues discovered in
Racket, is welcome at secur...@racket-lang.org

[1] the `#:requires` argument to `make-evaluator`, or the `requires`
arguments to `make-evaluator/submission` and similar.

Sam, for the Racket team

-- 
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%2BZ5rnpqW1g27AzSEOSfmLLGqr86GQzkmjaw4cc7xtD4QQ%40mail.gmail.com.

Re: [racket-users] Moving a function into a different `place?`

[Sam Tobin-Hochstadt]

Ah, this must be a case where different platforms behave differently,
because I still see other threads running even with
`finder:std-get-file` on Linux.

Sam

On Thu, Jul 1, 2021 at 2:58 PM David Storrs  wrote:
>
>
>
> On Thu, Jul 1, 2021 at 2:42 PM Sam Tobin-Hochstadt  
> wrote:
>>
>> Your "only remaining idea" is what I'd recommend for telling another
>> place what function to run (that's how dynamic-place works in the
>> first place). But your [details] sounds worrying. I just tested on my
>> machine and it didn't happen for me, and I don't think it's supposed
>> to happen on other platforms either.
>
>
> *frowns*
> *goes and checks*
>
> My mistake, I misremembered the details.  It only happens if you want the 
> platform-specific version of the dialog.  If you use the Racket version it's 
> fine but then your interface doesn't match what the user is expecting.
>
> https://groups.google.com/g/racket-users/c/wexYxYYU7GE/m/3zXxn6NoAwAJ?pli=1
>
>>
>> Sam
>>
>> On Thu, Jul 1, 2021 at 2:36 PM David Storrs  wrote:
>> >
>> > What is the best way to pass a function into a child `place`?
>> >
>> > I've got a server function that accepts a dispatch function as one of its 
>> > arguments and I need to be able to run the server in a separate `place` 
>> > (in the dynamic-place sense) because it's part of a GUI application. 
>> > [details]
>> >
>> > My initial thought was to start the place and then use 
>> > place-channel-(put/get) to move the run-time argument from the main place 
>> > over into the child.  I immediately realized that doesn't work because 
>> > functions are not `place-message-allowed?` values.  Next I thought about 
>> > using a parameter, but parameters in a child place are set to their 
>> > *initial* values, not their run-time values.  (Barring a few special 
>> > cases.)
>> >
>> > I considered passing a string or symbol list and then eval'ing it in the 
>> > child place.  I immediately rejected this idea and told my brain that it 
>> > was being bad and it got no cookies.
>> >
>> > At this point my only remaining idea is to place-channel-(put/get) a 
>> > module name that can be dynamic-required in the child place in order to 
>> > get the dispatch function.  Is there a better way?
>> >
>> >
>> > [details]
>> > The Racket GUI library has an issue where e.g. launching an 'Open File' 
>> > dialog will freeze all of Racket until the user closes the dialog.  This 
>> > can cause the server to time out.  Since it's all of Racket that's being 
>> > frozen and not just the current thread it's necessary to put the server 
>> > code into an entirely different `place`.
>> >
>> > --
>> > 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/CAE8gKoemyTeoP2GW5-_h6rGxW_1YcfyCQfHSs9ee98h3pRE4mg%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/CAE8gKoemg5DpdSx-iGcmu-5huM19zCtrdZXkjHHE2JhK7aGpXg%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/CAK%3DHD%2BZ5rS_a%3Dc71OHuzFkEY_Ln4HcZLfodtWYKSg_ca8YMz7g%40mail.gmail.com.

Re: [racket-users] Moving a function into a different `place?`

[Sam Tobin-Hochstadt]

Your "only remaining idea" is what I'd recommend for telling another
place what function to run (that's how dynamic-place works in the
first place). But your [details] sounds worrying. I just tested on my
machine and it didn't happen for me, and I don't think it's supposed
to happen on other platforms either.

Sam

On Thu, Jul 1, 2021 at 2:36 PM David Storrs  wrote:
>
> What is the best way to pass a function into a child `place`?
>
> I've got a server function that accepts a dispatch function as one of its 
> arguments and I need to be able to run the server in a separate `place` (in 
> the dynamic-place sense) because it's part of a GUI application. [details]
>
> My initial thought was to start the place and then use 
> place-channel-(put/get) to move the run-time argument from the main place 
> over into the child.  I immediately realized that doesn't work because 
> functions are not `place-message-allowed?` values.  Next I thought about 
> using a parameter, but parameters in a child place are set to their *initial* 
> values, not their run-time values.  (Barring a few special cases.)
>
> I considered passing a string or symbol list and then eval'ing it in the 
> child place.  I immediately rejected this idea and told my brain that it was 
> being bad and it got no cookies.
>
> At this point my only remaining idea is to place-channel-(put/get) a module 
> name that can be dynamic-required in the child place in order to get the 
> dispatch function.  Is there a better way?
>
>
> [details]
> The Racket GUI library has an issue where e.g. launching an 'Open File' 
> dialog will freeze all of Racket until the user closes the dialog.  This can 
> cause the server to time out.  Since it's all of Racket that's being frozen 
> and not just the current thread it's necessary to put the server code into an 
> entirely different `place`.
>
> --
> 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/CAE8gKoemyTeoP2GW5-_h6rGxW_1YcfyCQfHSs9ee98h3pRE4mg%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/CAK%3DHD%2BYhymxGozm2VjBcSOLE7RSXY%3DzY7gPCrHqYQVPcFJEQ6Q%40mail.gmail.com.

Re: [racket-users] machine and network outage at Northeastern

[Sam Tobin-Hochstadt]

Unfortunately, this has had larger impact than we expected, because a
number of places linked directly to mirror.racket-lang.org, which
normally hosts downloads. That machine will be down until July 2. In
particular, this seems to affect the setup-racket GitHub Action and
the homebrew formula for Racket.

The main download site, download.racket-lang.org, still works as
normal, and linking to that site will continue to work.

Sam

On Wed, Jun 30, 2021 at 9:11 AM  wrote:
>
>
> Northeastern has taken down its research machines and network for major 
> repairs.
> The outage will last from today June 30 through July 2. We have been reassured
> that it will come back then several times.  The most observable effect for 
> Racket
> Users is the absence of  `planet`.
>
> — Matthias
>
> --
> 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/FFF48AE0-6271-4151-969D-3A825CDC9C6D%40ccs.neu.edu.

-- 
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%2BaCTT2mFgJ%2Bp0-zgVvunn2vJM8rWYXvgHC82-Osd38oEg%40mail.gmail.com.

Re: [racket-users] Speeding up the conversion of flvectors to string

[Sam Tobin-Hochstadt]

On Tue, Jun 29, 2021 at 12:04 PM Jonathan Simpson  wrote:
>
> On Monday, June 28, 2021 at 10:25:36 PM UTC-4 Sam Tobin-Hochstadt wrote:
>>
>> On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote:
>> >
>> > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote:
>> >>
>> >> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for 
>> >> `y` eliminates the overhead of contracts and brings about another 4x 
>> >> speedup on my machine.
>> >
>> >
>> > This is because the compiler is able to remove the contract checks, not 
>> > because number->string doesn't have a contract, correct? If it is the 
>> > compiler, is there any rule of thumb to determine when the compiler will 
>> > likely remove the contract checks? Using typed 'for' iterators seems to be 
>> > one case that the compiler optimizes, but can we rely on others?
>>
>> There are two possible meanings for "contract checks" here. One is
>> "does it check that it gets the right kind of arguments, and raise an
>> error if not". In that sense, every function that is not "unsafe" has
>> contracts, certainly including `number->string`. The other meaning is
>> "uses the `racket/contract` library". The `~r` function has a contract
>> in that sense, while `number->string` does not, and that's a
>> significant source of overhead. On my laptop, just removing the
>> contract on `~r` in the source of the `racket/format` library speeds
>> up Bogdan's revised program from 600ms to 200ms.
>>
>> Most of the time, the compiler does not remove either kind of contract
>> check. Sometimes the first kind of contract check can be removed in
>> the simplest of cases; the second kind is basically never removed by
>> the compiler. There are other cases where macros can generate code
>> that omits contract checks, as with the `for` forms when used with
>> sequence generators like `in-list`, but that is again for simple
>> checks.
>>
>> Sam
>
>
> Thanks for the reply. I was under the impression that all of the racket 
> provided functions had full racket/contract contracts implemented at the 
> module boundary, which is what I thought was generating errors of the form:
> ---
> (number->string "aa")
> ; number->string: contract violation
> ;   expected: number?
> ;   given: "aa"
> ---

That error message is generated here:
https://github.com/racket/racket/blob/master/racket/src/cs/rumble/number.ss#L364

It uses the term "contract", and the exception is an instance of
`exn:fail:contract`, but it is not generated by the `racket/contract`
library.

> I take it that the contract error above was generated by a lower-level 
> contract then. I've only glanced at contracts, so I assume this is documented 
> somewhere. Is this section of the Reference referring to the simple contracts 
> that you mention? From https://docs.racket-lang.org/reference/contracts.html:
> ---
> Contracts come in two forms: those constructed by the various operations 
> listed in this section of the manual, and various ordinary Racket values that 
> double as contracts, including...
> ---

That whole section of the reference is about the `racket/contract`
library, and thus the second kind of contracts that I mentioned.

Sam

-- 
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%2BYVJbsqvBzT-52meaoj8vV9XkdXXPFC%3DgL1JTCVxNTizA%40mail.gmail.com.

Re: [racket-users] Speeding up the conversion of flvectors to string

[Sam Tobin-Hochstadt]

On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson  wrote:
>
> On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote:
>>
>> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for 
>> `y` eliminates the overhead of contracts and brings about another 4x speedup 
>> on my machine.
>
>
> This is because the compiler is able to remove the contract checks, not 
> because number->string doesn't have a contract, correct? If it is the 
> compiler, is there any rule of thumb to determine when the compiler will 
> likely remove the contract checks? Using typed 'for' iterators seems to be 
> one case that the compiler optimizes, but can we rely on others?

There are two possible meanings for "contract checks" here. One is
"does it check that it gets the right kind of arguments, and raise an
error if not". In that sense, every function that is not "unsafe" has
contracts, certainly including `number->string`. The other meaning is
"uses the `racket/contract` library". The `~r` function has a contract
in that sense, while `number->string` does not, and that's a
significant source of overhead. On my laptop, just removing the
contract on `~r` in the source of the `racket/format` library speeds
up Bogdan's revised program from 600ms to 200ms.

Most of the time, the compiler does not remove either kind of contract
check. Sometimes the first kind of contract check can be removed in
the simplest of cases; the second kind is basically never removed by
the compiler. There are other cases where macros can generate code
that omits contract checks, as with the `for` forms when used with
sequence generators like `in-list`, but that is again for simple
checks.

Sam

-- 
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%2BZHoN--2uJRVeT%2BMHEtbgcDHWtNMYSD45MKNuutwutrUA%40mail.gmail.com.

Re: [racket-users] Top-level unbound identifiers during expansion

[Sam Tobin-Hochstadt]

This is indeed an issue where "the top-level is hopeless" is the problem [1].

However, there's a better work-around. You can write `(define-syntaxes
(name.r ...) (values))` to forward-declare all those names, and then
the subsequent definitions will work correctly.

Sam

[1] https://lists.racket-lang.org/users/archive/2005-November/010350.html
is a good short description of the problem here.

On Fri, Jun 25, 2021 at 5:34 PM Greg Rosenblatt  wrote:
>
> I've encountered an identifier binding order issue that only manifests in the 
> REPL.  My current workaround is to use forward definitions followed by set!s. 
>  I've heard rumors that the top-level is hopeless, but I'd like to try and 
> make this work without unnecessary workarounds, if possible.
>
>
> To demonstrate the issue, I've defined a syntax transformer that binds 
> temporary names to procedures, and defines wrapper syntax transformers for 
> referencing these procedures.
>
> This syntax works fine within a module, or other non-top-level definition 
> context.  But when used at the top-level, I get an unbound identifier error 
> as the first procedure body is being expanded.  The first procedure 
> references the second via the wrapper.
>
>
> ;; issue.rkt
> #lang racket/base
> (provide issue-syntax)
> (require (for-syntax racket/base))
>
> (define-syntax (issue-syntax stx)
>   (syntax-case stx ()
> ((_ ((name param ...) body ...) ...)
>  (with-syntax (((name.r ...) (generate-temporaries #'(name ...
>#'(begin (define-syntax (name stx)
>   (syntax-case stx ()
> ((_ . args) #'(name.r . args))
> (_  #'name.r))) ...
> (define name.r (lambda (param ...) body ...)) ...)
> ;; eof
>
>
> > racket
> Welcome to Racket v8.0 [cs].
> > (require "issue.rkt")
> > (let ()
> (issue-syntax
>   ((foo x) (bar x 1 2))  ; note the reference to bar
>   ((bar a b c) `(bar: ,a ,b ,c)))
> (foo 'is-the-top-level-hopeless?))
> (bar: is-the-top-level-hopeless? 1 2)
> > (issue-syntax
> ((foo x) (bar x 1 2))  ; note the reference to bar
> ((bar a b c) `(bar: ,a ,b ,c)))
> ; bar4: unbound identifier;
> ;  also, no #%top syntax transformer is bound
> ;   in: bar4
> ; [,bt for context]
> > ,bt
> ; bar4: unbound identifier;
> ;  also, no #%top syntax transformer is bound
> ;   in: bar4
> ;   context...:
> ;/Applications/Racket v8.0/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1493:0
> ;/Applications/Racket v8.0/collects/racket/repl.rkt:11:26
>
>
> I can work around this issue by altering issue-syntax to forward-define names 
> before using set! to initialize them:
>
> (define-syntax (issue-syntax stx)
>   (syntax-case stx ()
> ((_ ((name param ...) body ...) ...)
>  (with-syntax (((name.r ...) (generate-temporaries #'(name ...
>#'(begin (define-syntax (name stx)
>   (syntax-case stx ()
> ((_ . args) #'(name.r . args))
> (_  #'name.r))) ...
> (define name.r #f) ...  ; forward definitions
> (set! name.r (lambda (param ...) body ...)) ...)
>
>
> Is there a better alternative?
>
> --
> 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/cd8675e8-95d0-4552-badc-d4ec7a430109n%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/CAK%3DHD%2BYeXuQP4yErTQe3g7aCSM7iOLfkJpFXDHodZQ29zf_agg%40mail.gmail.com.

[racket-users] An Apology

[Sam Tobin-Hochstadt]

We were saddened to read [Matthew Butterick's recent post]. Matthias
has written his own [apology] in response.

For our part, some of us were present for the interaction between
Matthew Butterick and Matthias Felleisen and some of us learned about
it later. We did not intervene in the way that we should have, and we
are sorry.

If you wish to offer your thoughts to the people named below, the
email address feedb...@racket-lang.org will reach us directly.

Jay McCarthy
John Clements
Matthew Flatt
Robby Findler
Sam Tobin-Hochstadt

[Matthew Butterick's recent post]:
https://beautifulracket.com/appendix/why-i-no-longer-contribute-to-racket.html
[his own apology]: https://felleisen.org/matthias/Thoughts/Apology.html

-- 
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%2BZrg1dw%3Ds1HnO17hBU55x%2B%3D9XkEonLxNjwyi-gu1jrfcw%40mail.gmail.com.

Re: [racket-users] Sharing scope in setup/cleanup for dynamic-wind?

[Sam Tobin-Hochstadt]

I think the key question is what you want to happen if you would need
to re-run the "pre" thunk, because you re-enter the code via a
continuation.

In many cases, you don't want to support that at all, and then it's
pretty easy (although you still need mutation):

(let* ([conn (connect-to-server)]
[started? #f])
 (dynamic-wind
 (lambda () (when started? (error 'fail)) (set! started? #t))
 (lambda () (send-message conn "hi"))
 (lambda () (finalize-connection conn

You could just not do the check in the pre thunk, in which case you'd
get worse error messages but probably nothing else wrong.

Sam


On Tue, May 18, 2021 at 3:42 PM David Storrs  wrote:
>
> Thank you.  Is there a way to do it without the mutation?  I was hoping to 
> use this for macro generation that simplifies combining with-handlers and 
> dynamic-wind with setup/teardown code.
>
> (try [pre
>   (define db (connect-to-db))
>   (define conn (connect-to-server))]
>  [(send-message conn (query-value db "invalid SQL"))]
>  [catch ([exn:fail:contract? (lambda (e) (displayln "contract"))]
>  [exn:fail:network?  (lambda (e) (displayln "network"))]
>  [(and/c exn:fail? (compose1 (curry regexp-match #rx"query") 
> exn-message))
>   (lambda (e) (displayln "database"))])]  ; this should run
>  [finally
>   (finalize-db-connection db)
>   (finalize-server-connection conn)])
>
> The goal is to guarantee that the connections are created/released every time 
> we go in and out of the code (usually via an exception) and also to put the 
> happy path first so that it's easier to see what the code should do before 
> getting into the weeds of error handling.
>
> (I probably should have put these details in the original message but I was 
> trying to keep it simple so as not to make people burn brain cycles.)
>
> On Tue, May 18, 2021 at 2:34 PM Sam Tobin-Hochstadt  
> wrote:
>>
>> It's not quite as convenient, but here's a version of your program
>> that should work:
>>
>> (let ([conn #f])
>>   (dynamic-wind
>> (lambda () (set! conn (connect-to-server))
>> (lambda () (send-message conn "foo"))
>> (lambda () (finalize-connection conn
>>
>> Sam
>>
>> On Tue, May 18, 2021 at 2:08 PM David Storrs  wrote:
>> >
>> > dynamic-wind is nice because it guarantees that the pre- and 
>> > postconditions for a chunk of code will be run regardless of continuation 
>> > jumps, exceptions, etc.  The only issue I have is that the three thunks do 
>> > not share scope, making it difficult to do setup/teardown workflows.  I 
>> > feel like I should be able to make this work with nested dynamic-wind or 
>> > with-handlers but haven't been able to get there without losing the 
>> > guarantee of running.  Is there a way?
>> >
>> > Example of what I'd like to do:
>> >
>> > (my-dynamic-wind
>> >   (thunk (define conn (connect-to-server)))
>> >   (thunk (send-message conn "foo"))
>> >   (thunk (finalize-connection conn)))
>> >
>> > --
>> > 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/CAE8gKodTcogsfeiYKu5iyFbL4H%2Ba3dzuL7rLTfYERD%2BauFD9xQ%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/CAE8gKofbcigfJDFgU8AXVqomQYqmgGT_OEXwAx7m8BQyyoCHqQ%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/CAK%3DHD%2Bb0j3Y4DDHJSBcA8LjjXm3bvRvRNwLrfrNq%3DOs9Z4HpKg%40mail.gmail.com.

Re: [racket-users] Sharing scope in setup/cleanup for dynamic-wind?

[Sam Tobin-Hochstadt]

It's not quite as convenient, but here's a version of your program
that should work:

(let ([conn #f])
  (dynamic-wind
(lambda () (set! conn (connect-to-server))
(lambda () (send-message conn "foo"))
(lambda () (finalize-connection conn

Sam

On Tue, May 18, 2021 at 2:08 PM David Storrs  wrote:
>
> dynamic-wind is nice because it guarantees that the pre- and postconditions 
> for a chunk of code will be run regardless of continuation jumps, exceptions, 
> etc.  The only issue I have is that the three thunks do not share scope, 
> making it difficult to do setup/teardown workflows.  I feel like I should be 
> able to make this work with nested dynamic-wind or with-handlers but haven't 
> been able to get there without losing the guarantee of running.  Is there a 
> way?
>
> Example of what I'd like to do:
>
> (my-dynamic-wind
>   (thunk (define conn (connect-to-server)))
>   (thunk (send-message conn "foo"))
>   (thunk (finalize-connection conn)))
>
> --
> 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/CAE8gKodTcogsfeiYKu5iyFbL4H%2Ba3dzuL7rLTfYERD%2BauFD9xQ%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/CAK%3DHD%2BYaP0GV4JppQs%2BpmoOomFskEY%3D7cJ82Ujero7QrzPst1w%40mail.gmail.com.

Re: [racket-users] I want a package at installation scope but also to keep my install clean

[Sam Tobin-Hochstadt]

You might also be interested in the new `raco-pkg-env` tool:
https://github.com/samdphillips/raco-pkg-env/

Sam

On Tue, May 18, 2021 at 12:20 PM Matthew Flatt  wrote:
>
> Yes, this approach can work. I don't think the existing Racket tools
> will help much with persisting a configuration across versions, though,
> so you'd probably have to script that.
>
> One potential drawback of your approach is that executables,
> documentation, etc., associated with the extra package will get
> rendered into the main installation area instead of the "/opt/Racket"
> are. That may be fine for your purposes, but a more strictly layered
> installation is meant to be possible. It turns out that some pieces
> have been missing for layering, and fixing that is an area of current
> work (https://github.com/racket/racket/commit/dfbb7040a).
>
> At Sun, 16 May 2021 23:43:52 -0500, Nathaniel W Griswold wrote:
> > Hello,
> >
> > I was setting up Racket on my linux box and i realized that there are a lot 
> > of
> > options for path configuration and i forgot a lot of what i discovered last
> > time i dug into this. I was trying to set up installation scope but maybe a
> > little cleanly and figured someone might have some input.
> >
> > I want a package at roughly installation scope, but i kinda wanted to know 
> > what
> > was added by me and what was part of the default installation. Is this
> > reasonable or should i just deal with it and dump stuff in 
> > $RACKET/share/pkgs?
> > If it is reasonable then what is the best way to set this up?
> >
> > Just FYI I did an in-place install of Racket in "/opt/Racket/Racket\ 8.1"
> > symlinked to /opt/Racket...
> >
> > I think maybe what i want is to set  to something like
> >
> > (in /opt/Racket/etc/config.rktd)
> >
> > #hash(... (pkgs-search-dirs . "/opt/Racket 8.1/share/pkgs-system" #f)
> > (links-search-files . ("/opt/Racket/share/pkgs-system/links.rktd" #f)) ...)
> >
> > Then i just did a `sudo /opt/Racket/bin/raco pkg install --scope-dir
> > /opt/Racket/share/pkgs-system rash`
> >
> > ... and the new package seems to be working fine for my users.
> >
> > Is that what i wanted or is there something better? Is there a way to 
> > configure
> > config.rktd additions that will persist across upgrades or will i have to
> > update my config.rktd for every racket release? Do other people do this 
> > kind of
> > thing or just dump stuff in the installation scope? Maybe there are more
> > options with a unix-style install, i haven't really tried one yet.
> >
> > Thanks!
> >
> > Nate
>
> --
> 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/20210518102000.1b1%40sirmail.smtps.cs.utah.edu.

-- 
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%2Ba2G41L5C3v1wPjackfsn0VwtRZEWO7XiW9POS7mWa85Q%40mail.gmail.com.

Re: [racket-users] Package install conflicts on the Racket package catalog

[Sam Tobin-Hochstadt]

I think there's two things you're seeing.

1. The results hadn't yet updated for your typed-compose change. I no
longer see a conflict here: https://pkg-build.racket-lang.org/
2. The conflicts page is for _all_ the packages in the whole package
catalog. That's why it always mentions mischief.

The issue for on-macro and social-contract is that they both have a
file tests/private/util.rkt, which means they can't be installed at
the same time.

Finally, mischief has that issue intentionally -- there are two
versions of it on the pkg server, one of which is the development
branch. It's true that it hasn't been updated recently, but that's the
idea.

Sam


On Wed, May 5, 2021 at 4:08 PM unlimitedscolobb
 wrote:
>
> Hi,
>
> I'd like to chime back in and say that renaming manual.rkt to 
> typed-compose.rkt didn't seem to affect much the list of install conflicts 
> for typed-compose.  I also get a lot of conflicts with mischief (but not 
> only), even though typed-compose doesn't depend on it, or doesn't even define 
> names which would be similar to what mischief defines.
>
> That's puzzling.
>
> -
> Sergiu
>
> On Wednesday, May 5, 2021 at 9:16:14 PM UTC+2 Siddhartha Kasivajhula wrote:
>>
>> Hi,
>> I'd like to report that I'm seeing conflicts being reported on my packages 
>> as well. I haven't made recent changes to these packages so the conflicts 
>> seem to have appeared spontaneously.
>>
>> Here is one example: https://pkgs.racket-lang.org/package/lazytree
>> Clicking into the "conflicts" results in a 404.
>>
>> Another example: https://pkgs.racket-lang.org/package/on-macro
>> Here, clicking into "conflicts" seems to implicate, believe it or not, the 
>> `mischief` package, of which it appears there are two separate versions on 
>> the package index. This does seem rather mischievous, and maybe raco doesn't 
>> like it? Yet, it doesn't look like either mischief or mischief-dev have been 
>> changed in years, so I'm not sure why it should complain now about these 
>> longstanding shenanigans.
>>
>> A third example: https://pkgs.racket-lang.org/package/social-contract
>> Clicking into "conflicts" once again seems to implicate mischief, but 
>> mischief isn't even in the dependencies for this package so this just seems 
>> unfair!
>>
>> On other packages that I've uploaded, the conflicts link was a 404.
>>
>> Similar questions as OP - should I fix something here, for instance by 
>> avoiding the mischief dependency? Should mischief itself be updated in some 
>> way? Or is this (as seems likely) caused by a recent change in the package 
>> index, and if so, how should package authors respond (assuming it isn't a 
>> bug)? What to do about the 404s -- e.g. is there a command to generate the 
>> conflicts locally?
>>
>> Thanks,
>>
>>
>>
>> On Sun, May 2, 2021 at 6:59 AM unlimitedscolobb  
>> wrote:
>>>
>>> Hi Jay,
>>>
>>> Thanks a lot for helping me read that file!
>>>
>>> I didn't know Scribble outputs shared the same namespace.  I renamed the 
>>> documentation file to typed-compose.scrbl as you suggest and I'm waiting 
>>> for build reports from the package catalog.
>>>
>>> In fact, I hesitated between manual.scrbl and typed-compose.scrbl 
>>> initially, and couldn't find a reason to prefer one over the other. Now I 
>>> have a reason :-)
>>>
>>> -
>>> Sergiu
>>>
>>> On Saturday, May 1, 2021 at 3:23:47 PM UTC+2 jay.mc...@gmail.com wrote:

 Howdy Sergiu,

 The conflicts file you link to has all the conflicts for everything
 that `pkg-build` builds. The line relevant for you is:

 ```
 doc "manual":
 bystroTeX cbor print-debug ratchet riff simply-scheme typed-compose
 ```

 The solution is to rename your manual from `manual.scrbl` to
 `typed-compose.scrbl`. Scribble outputs are in a kind of "global"
 namespace.

 Jay

 --
 Jay McCarthy
 Associate Professor @ CS @ UMass Lowell
 http://jeapostrophe.github.io
 Vincit qui se vincit.


 --
 Jay McCarthy
 Associate Professor @ CS @ UMass Lowell
 http://jeapostrophe.github.io
 Vincit qui se vincit.


 On Sat, May 1, 2021 at 5:56 AM unlimitedscolobb
  wrote:
 >
 > Hello,
 >
 > I checked my package 
 > https://pkgd.racket-lang.org/pkgn/package/typed-compose recently and 
 > noticed that it listed some "Conflicts" in the field "Most recent build 
 > results". On the other hand, the separate field "Conflicts" slightly 
 > above says "None".
 >
 > When I open the log shown in "Most recent build results" (attached) it 
 > starts with the line "Install conflicts:", which as far as I get are not 
 > the same thing as "Package Conflicts" explained here in the manual: 
 > https://docs.racket-lang.org/pkg/Package_Concepts.html#(part._concept~3aconflicts)
 >  .
 >
 > What are install conflicts? Should I fix them? What is the command that 
 > generates that log?
 >
 > 

Re: [racket-users] limitation of TR contract translation?

[Sam Tobin-Hochstadt]

This is a bug. It's not the the contract is unsatisfiable, it's that it's
too satisfiable. The contract system could probably make this work, but
Typed Racket should probably avoid this situation.

Sam

On Fri, Apr 30, 2021, 2:07 AM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> It seems that the conversion of TR types to contracts can result in
> contracts like (or/c (cons/c any/c any/c) (cons/c any/c any/c)) that
> apparently cause errors when run.
>
> I’m too tired to do a good job of providing a full example… no, actually,
> it’s pretty easy. Run this program:
>
> #lang racket
>
>
> (module foo typed/racket
>
>   (provide val->autorun-table)
>
>   (define-type Autorun-Result
> (U (Pair 'success Any)
>(Pair 'fail Any)))
>
>   (define-type Autorun-Entry
> (List String Autorun-Result))
>   (define-predicate autorun-entry? Autorun-Entry)
>
>   (define-type Autorun-Table (Listof Autorun-Entry))
>   (define-predicate autorun-table? Autorun-Table)
>
>   (define (val->autorun-table [val : Any])
> : (U False Autorun-Table)
> (cond
>   [(list? val)
>(define first-bad (findf (compose not autorun-entry?) val))
>(when first-bad
>  (fprintf (current-error-port)
>   "not an expected autorun entry:\n~e\n"
>   first-bad))
>(cast val Autorun-Table)]
>   [else
>(error 'maybe-fetch-autorun-results
>   "result of read wasn't a list. moreinfo.")])))
>
> (require 'foo)
>
> (val->autorun-table '(("1234" (fail (zz 1234) (d 9)
>
>
> … see this error:
>
> val->autorun-table: broke its own contract
>   two of the clauses in the or/c might both match: (cons/c any/c Any) and
> (cons/c any/c Any)
>   produced: '(fail (zz 1234) (d 9))
>   in: the 2nd element of
>   an element of
>   a part of the or/c of
>   the range of
>   (->
>any/c
>(or/c
> #f
> (listof
>  (list/c
>   any/c
>   (or/c
>(cons/c any/c Any)
>(cons/c any/c Any))
>   contract from: (anonymous-module foo)
>   blaming: (anonymous-module foo)
>(assuming the contract is correct)
>   at: 38-unsaved-editor:20.11
>
>
> Basically, it looks like the type is getting simplified a bit as it’s
> being translated into a contract, and unfortunately, the resulting contract
> is unsatisfiable?
>
> Is this a bug, or a known limitation?
>
> John
>
>
> --
> 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/295471a4-99d9-4bbe-8e7b-351c1bb75e96%40mtasv.net
> .
>

-- 
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%2BYQymMfEN9yoA_4q8oCLJo2FWaVHw%2B6HQuTJ219-K0d0A%40mail.gmail.com.

Re: [racket-users] Typed Racket: type relations

[Sam Tobin-Hochstadt]

On Mon, Apr 19, 2021 at 3:19 PM Dominik Pantůček
 wrote:
>
> >>>
> >>> However, I would suggest that the right fix here is to use refinement
> >>> types, and specify exactly what you want. Unfortunately, the
> >>> refinement types feature (good intro here:
> >>> https://blog.racket-lang.org/2017/11/adding-refinement-types.html)
> >>> isn't quite able to prove everything you want, but that's the
> >>> direction we should go. For example, it can already prove that rd in
> >>> the rgb-distance^2 function has this type: (define-type PMByte (Refine
> >>> [v : Fixnum] (and (< v 256) (< -256 v
> >>
> >> This is exactly what I was looking at (and for), but I am unable to use
> >> it correctly:
> >
> > I think you need to add #:with-refinements after the #lang line.
>
> Awesome! Now TR can properly reason about the differences.
>
> I guess it is not possible to make TR deduce the proper type of (* rd
> rd) like:
>
> (define-type Byte^2 (Refine [v : Fixnum] (and (>= v 0) (< v (* 255 255)
>
> Are there any plans of adding such reasoning?

I'm not currently working on this, but I'd be happy to help out if you
want to take this on.

The relevant code is here:
https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/typecheck/integer-refinements.rkt#L129-L143.

The problem is that the spec of * is basically to create a linear
expression precisely describing the result, and then say that the
result is equal to that. But such a linear expression doesn't exist
for *, of course. So you'd have to have a different strategy then
(that's when `(Object? product-obj?)` is #f).

> Honestly, when I went through the code for binary fx... operations I
> realized that making them variadic is possible but not straightforward
> at all. Without digging deeper it seems to me that it is actually a lot
> of work. I will look into it again later on.

Here's a first step, which might help get you started:
https://github.com/samth/typed-racket/commit/2514e7107b4da5322a07fe260123432f4055

Sam

-- 
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%2Ba2P_rDZYD_13U4_nifiALycxKOYxfTcJXOVgZqnekJmA%40mail.gmail.com.

Re: [racket-users] Typed Racket: type relations

[Sam Tobin-Hochstadt]

It's a little more complicated than that -- the _constraints_ have to
be linear -- that is, the expressions in the refinements, but the
expressions reasoned about can be more general. However, it doesn't do
very much useful with multiplication by bounded values at the moment.

Sam

On Mon, Apr 19, 2021 at 7:31 AM Hendrik Boom  wrote:
>
> On Sun, Apr 18, 2021 at 09:05:11AM +0200, Dominik Pantůček wrote:
> ...
> ...
> >
> > I would really like to be able to reason about the Integer bounds (and
> > therefore signs) dynamically. So that when you have something like:
> >
> > (: square (-> Fixnum Nonnegative-Fixnum))
> > (define (square x)
> >   (fx* x x))
> >
> > You will get something better than:
>
> >
> > multiplication.rkt:7:2: Type Checker: type mismatch
> >   expected: Nonnegative-Fixnum
> >   given: Fixnum
> >   in: (fx* x x)
> >
> > I will look into the refinements implementation to see what are the
> > current limits and what the future possibilities might be.
>
> Reading the documentation you link to, it seems that the problem is that
> (fx* x x) is not linear in x.
> It says that it can reason only about linear expressions.  This is a
> quadratic form.
>
> -- 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/20210419113103.c4fupxvl6ieb3uub%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%2Bbi1VmQ0zt5RnCnqSojvyzoBA%3D-WMN9CxSun-g1bv%3DJGw%40mail.gmail.com.

Re: [racket-users] Typed Racket: type relations

[Sam Tobin-Hochstadt]

On Sun, Apr 18, 2021 at 3:05 AM Dominik Pantůček
 wrote:
>
> 0. Thank you very much for looking into this.
>
> On 18. 04. 21 4:57, Sam Tobin-Hochstadt wrote:
> > Ok, three parts:
> >
> > 1. Is it possible to make `average` on `Byte` provably produce a
> > `Byte`? This is not going to be possible with plain Typed Racket, even
> > with refinements to the numeric tower. The problem is that maintaining
> > the invariant that a <= (* n 255) is not something that we can express
> > just with the sets of values Typed Racket reasons about.
>
> That is what I was afraid of. Mathematically speaking, the proof is
> almost trivial. But expressing that turned out to be a tough nut to crack.
>
> I looked into base-env-numeric.rkt and I see that there is quite some
> type reasoning already implemented. And it works great for simple cases
> like (fxand 255 anything) - : Byte.
>
> Maybe adding an explicitly ranged Integer type and after reasoning about
> the result match the final range against the set of coarse-grained types
> could be a solution? Albeit not a trivial one in terms of implementing it.
>
> >
> > 2. The rgb-distance^2 issue is really just that there's no negative
> > counterpart to `Byte`, so `Byte` minus `Byte` is `Fixnum`. We could
> > add that, at the cost of extra complexity in the numeric tower
> > generally.
> >
> > However, I would suggest that the right fix here is to use refinement
> > types, and specify exactly what you want. Unfortunately, the
> > refinement types feature (good intro here:
> > https://blog.racket-lang.org/2017/11/adding-refinement-types.html)
> > isn't quite able to prove everything you want, but that's the
> > direction we should go. For example, it can already prove that rd in
> > the rgb-distance^2 function has this type: (define-type PMByte (Refine
> > [v : Fixnum] (and (< v 256) (< -256 v
>
> This is exactly what I was looking at (and for), but I am unable to use
> it correctly:

I think you need to add #:with-refinements after the #lang line.

> > 3. I don't see any boundaries where you describe -- can you say more?
>
> Run typed-performance.rkt and see:

This might be related to https://github.com/racket/typed-racket/issues/289.

Sam

-- 
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%2BYGgTbFjyaTQ8ETuXmRB4%2BsYoW7iYAujjWcFa0FNHEdrg%40mail.gmail.com.

Re: [racket-users] Typed Racket: type relations

[Sam Tobin-Hochstadt]

Ok, three parts:

1. Is it possible to make `average` on `Byte` provably produce a
`Byte`? This is not going to be possible with plain Typed Racket, even
with refinements to the numeric tower. The problem is that maintaining
the invariant that a <= (* n 255) is not something that we can express
just with the sets of values Typed Racket reasons about.

2. The rgb-distance^2 issue is really just that there's no negative
counterpart to `Byte`, so `Byte` minus `Byte` is `Fixnum`. We could
add that, at the cost of extra complexity in the numeric tower
generally.

However, I would suggest that the right fix here is to use refinement
types, and specify exactly what you want. Unfortunately, the
refinement types feature (good intro here:
https://blog.racket-lang.org/2017/11/adding-refinement-types.html)
isn't quite able to prove everything you want, but that's the
direction we should go. For example, it can already prove that rd in
the rgb-distance^2 function has this type: (define-type PMByte (Refine
[v : Fixnum] (and (< v 256) (< -256 v

3. I don't see any boundaries where you describe -- can you say more?

Sam

On Fri, Apr 16, 2021 at 12:06 PM Dominik Pantůček
 wrote:
>
> I wanted to polish things a bit before starting a longer discussion, but
> here we go ;-)
>
> The code in question[1] is part of my work into exchanging unsafe
> modules which can be used either contracted or uncontracted for TR
> modules. The goal is to replace racket/unsafe/ops with TR to provide
> compile-time type consistency and to have modules which are internally
> consistent and if they are used with other TR code the consistency
> remains. More on that later.
>
> On 16. 04. 21 15:51, Sam Tobin-Hochstadt wrote:
> > To improve this, we'd have to extend the type of `fxquotient`, which
> > is reasonable, but I'm not sure what the addition would be. In
> > particular, your addition is not sound:
> >
> > (fxquotient 1024 2) produces 512 which is not a Byte.
>
> Please, take a quick look at the typed-color.rkt in the repository.
>
> The "Color" type is just a Nonnegative-Fixnum. It is a generic RGB value
> with blue in lowest 8 bits, green shifted above blue and red on top. 24
> bits in total. The split-rgb splits it into 3 R,G,B values - where each
> of those values is a byte.
>
> Then the rgb-average function takes an arbitrary number of Color values,
> computes sums of their distinct R,G,B components and divides all of them
> by the number of values before merging them together into one RGB Color
> value.
>
> Average value of (listof Byte) is definitely a Byte again. I am sorry I
> didn't send the whole code in question. I was focused on other parts and
> this is just a side issue in my current work.
>
> Is there a way to express this in TR while still generating a code that
> is on-par with the unsafe version? In theory, TR should excel in this.
>
> A similar problem arises with the rgb-distance^2 function where the
> component difference can be either positive or negative. But definitely
> a square of whatever Integer is positive. And definitely the result
> cannot be bigger than 3*255^2=195075, which is definitely
> Nonnegative-Fixnum on any platform.
>
> Again - is there a way to express this in TR and generate a code that
> has no runtime checks?
>
> The motivation here is that the performance and type soundness should go
> hand in hand. If I prove the code will never get a value of a wrong
> type, there is no need for runtime checks. Actually the more strict
> rules, the better code can be (in theory) generated.
>
> Then the typed/untyped boundaries introduce contracts - or they don't. I
> am really confused, why there is a typed/untyped boundary between
> typed-unsafe-color.rkt and typed-color.rkt. I assume this comes from my
> poor understanding of TR - it will probably get better in the
> forthcoming months as TR has proven to be an invaluable tool for
> improving the quality of performance-oriented modules so far. More on
> that later too...
>
>
> Cheers,
> Dominik
>
> [1] https://gitlab.com/racketeer/typed-racket-performance
>
> --
> 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/d95b9140-fd78-0230-439b-aba654505fd0%40trustica.cz.

-- 
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%2BZ_6fqz3pcXNC0Jm-aG1__zvruHgDz_w0xSVuh1R1pY7w%40mail.gmail.com.

Re: [racket-users] Typed Racket: type relations

[Sam Tobin-Hochstadt]

To improve this, we'd have to extend the type of `fxquotient`, which
is reasonable, but I'm not sure what the addition would be. In
particular, your addition is not sound:

(fxquotient 1024 2) produces 512 which is not a Byte.

Sam

On Thu, Apr 15, 2021 at 6:22 PM Dominik Pantůček
 wrote:
>
> Hello Racketeers,
>
> working on gradually typing some of my modules I encountered an
> interesting problem:
>
> (define-type Color Fixnum)
>
>   (: argb-average (-> Color * Color))
>   (define (argb-average . argbs)
> (let loop ((as : Fixnum 0)
>(rs : Fixnum 0)
>(gs : Fixnum 0)
>(bs : Fixnum 0)
>(n : Fixnum 0)
>(argbs : (Listof Color) argbs))
>   (if (null? argbs)
>   (make-argb (fxquotient as n)
>  (fxquotient rs n)
>  (fxquotient gs n)
>  (fxquotient bs n))
>   (let-values (((a r g b) (argb-split (car argbs
> (loop (fx+ as a)
>   (fx+ rs r)
>   (fx+ gs g)
>   (fx+ bs b)
>   (fx+ n 1)
>   (cdr argbs))
>
> Type Checker: type mismatch
>   expected: Byte
>   given: Fixnum
>   in: (fxquotient bs n)
>
> The only way of fixing this issue was using unsafe-fxquotient which is
> unsafe-require/typed accordingly:
>
> (unsafe-require/typed
>  racket/unsafe/ops
>  (unsafe-fxquotient (-> Fixnum Fixnum Byte)))
>
> Is there a better way?
>
> The relation between Byte and (Nonnegative-)Fixnum is mathematically
> sound here, but making TR understand it is apparently pretty hard...
>
>
> Cheers,
> Dominik
>
> --
> 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/608fdb93-b2ce-37e0-750c-037b47fed102%40trustica.cz.

-- 
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%2BY3JuW%3DN9paE-n5mm51E1qSde1ZCEa5xuxPE7H1_WPXWA%40mail.gmail.com.

Re: [racket-users] Variadic fixnum operations (was: Unsafe structs)

[Sam Tobin-Hochstadt]

On Thu, Apr 15, 2021 at 4:21 PM Dominik Pantůček
 wrote:
>
> Hello Racketeers,
>
> >> * Math/Fixnums/Flonums: All fx+/-/*/... accept two arguments only. No
> >> unary fl-, no variadic-argument fl+ or fxior (this one hurt the most).
> >
> > These definitely became variadic after the type definitions were
> > written, but that's of course not an excuse for not updating them.
> >
>
> are these planned for update anytime soon? Tested with latest git and
> the functions are still two-argument only.
>
> If there are no plans, I can probably have a look into that and send PR
> if I am successful.

A PR extending the types for those functions would be very welcome.
Let me know if you need any help.

Sam

-- 
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%2BY8psYuMMy%3D6OLp6Lw1uW_0r9OiS0LGuym7krX4k3hBdA%40mail.gmail.com.

Re: [racket-users] Upgrading installer verification

[Sam Tobin-Hochstadt]

There is indeed signing for Ubuntu ppas, but that's specific both to apt
and to the ppa system.

Sam

On Fri, Apr 2, 2021, 9:29 PM Sage Gerard  wrote:

> No, I'm just looking for extra confidence when verifying installers.
>
> On that note, did Ubuntu require someone to sign packages to distribute
> packages via apt? Can that be repurposed here?
>
> On 4/2/21 12:26 PM, James Platt wrote:
> >
> > Are you bring this up because of the recent rise of dependency confusion
> attacks?  In any case, it would be good to know where Racket stands with
> that.
> >
> > On Apr 1, 2021, at 12:39 PM, Sage Gerard wrote:
> >
> >> Are there any plans to publish GPG signatures for Racket installers, or
> >> at least upgrade the cryptographic hash function used for the checksums?
> >>
> >> If not, who would be a good person to talk to about contributing that?
> >>
> >> --
> >> ~slg
> >>
> >>
> >> --
> >> 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/70e8acf9-9993-0e7c-3d10-b7964cc6ed03%40sagegerard.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/8DEE7478-3E76-43EC-8691-AA44D016E764%40biomantica.com
> .
>
> --
> ~slg
>
>
> --
> 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/3b144b15-e5a1-8139-496d-c1a36e401117%40sagegerard.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%2BaS_J2_%2BT5nEsCLJpi0rEw4AcEKr3rz_PcKVjRNWcaCLA%40mail.gmail.com.

Re: [racket-users] How to make a sandboxed evaluator in Scribble

[Sam Tobin-Hochstadt]

You might use `(list 'value-evt)` if that's the require you want.

Sam

On Thu, Apr 1, 2021 at 3:41 PM David Storrs  wrote:
>
> I cargo-culted this chunk of code and, predictably, it is now failing
> for reasons I don't understand.  This is in the value-evt scribble
> file; it works fine when I build the file manually but it's failing in
> the package server build:
>
> @(define eval
>(call-with-trusted-sandbox-configuration
> (lambda ()
>   (parameterize ([sandbox-output 'string]
>  [sandbox-error-output 'string]
>  [sandbox-memory-limit 50])
> [make-evaluator #:requires (list "main.rkt") 'racket]
>
> Clearly the issue is with 'main.rkt' as opposed to '../main.rkt'.  I
> had that originally and it worked when I did 'scribble
> value-evt.scrbl' while in the scribblings directory but it failed or
> misgenerated the files when I was in a different directory or I used
> raco setup.
>
> Weirdly, this is being reported as a failing test, which surprised me.
> Why is that?
>
> What should I do instead?
>
> --
> 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/CAE8gKofQXNm%2Bsfkk-07NYZw0drQmw92oqJBZkyq5fQrGBWA9TQ%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/CAK%3DHD%2BYSAdv%3Dv6n1msyrPQaovt7u%2BdzgmoB2HMo-GUMoXG8MOQ%40mail.gmail.com.

Re: [racket-users] Upgrading installer verification

[Sam Tobin-Hochstadt]

I don't think we have plans to start signing installers. The code that
creates installers is in the `distro-build` package, and the use of
sha1 is here: 
https://github.com/racket/distro-build/blob/21ccc39fc14408eea79aff035e508856a66adf89/distro-build-server/pack-built.rkt#L76

Sam

On Thu, Apr 1, 2021 at 12:39 PM Sage Gerard  wrote:
>
> Are there any plans to publish GPG signatures for Racket installers, or
> at least upgrade the cryptographic hash function used for the checksums?
>
> If not, who would be a good person to talk to about contributing that?
>
> --
> ~slg
>
>
> --
> 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/70e8acf9-9993-0e7c-3d10-b7964cc6ed03%40sagegerard.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%2Bbk-AFfBqea1ZpwooO-p%2B%3DpuByuWpNTTKTM9oPOTfEWLg%40mail.gmail.com.

Re: [racket-users] Package server certificate expired

[Sam Tobin-Hochstadt]

This should be fixed now.

Let this be a lesson about ignoring warnings about out-of-date software. :)

Sam

On Thu, Apr 1, 2021 at 11:59 AM David Storrs  wrote:
>
> Not sure where the right place is to report this, but  the certificate for 
> pkgd.racket-lang.org expired on 3/31/2021.
>
> --
> 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/CAE8gKocWHJYQQdYk0BEFx_EPJc%2Bc0yoAZe1NqJ6HNZRSHa2Y5A%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/CAK%3DHD%2BZ%2BHOOYoJFEmVAV24dRd-hKzZOJQJ9jvfCYubTha8MeYw%40mail.gmail.com.

Re: [racket-users] Word Count program/benchmark performance

[Sam Tobin-Hochstadt]

I went from numbers around 1000 ms to 950 ms to 900 ms. There was
variance around those numbers, but it was pretty consistent.

For more precise answers, there are a few things you can try. One is
to measure instructions instead of time (ie, with perf). Another is to
run it a bunch of times and take an average. The `hyperfine` tool is
good for that. But probably the best advice is to make the program
take longer so differences are more apparent -- variation usually
increases sub-linearly.

Sam

On Fri, Mar 19, 2021 at 12:17 PM Laurent  wrote:
>
> Sam: How do you accurately measure such small speed-ups? On my machines, if I 
> run the same program twice, I can sometimes see more than 10% time difference.
>
> On Fri, Mar 19, 2021 at 4:10 PM Sam Tobin-Hochstadt  
> wrote:
>>
>> Use `#:authentic`, and `unsafe-vector*-{ref,set!}` saved about 50 more
>> ms on my machine.
>>
>> Then getting rid of `set!` and just re-binding the relevant variables
>> produced another 50 ms speedup.
>>
>> https://gist.github.com/7fc52e7bdc327fb59c8858a42258c26a
>>
>> Sam
>>
>> On Fri, Mar 19, 2021 at 7:21 AM Sam Tobin-Hochstadt
>>  wrote:
>> >
>> > One minor additional suggestion: if you use #:authentic for the struct, it 
>> > will generate slightly better code for the accessors.
>> >
>> > Sam
>> >
>> > On Fri, Mar 19, 2021, 6:18 AM Bogdan Popa  wrote:
>> >>
>> >> I updated the gist with some cleanups and additional improvements that
>> >> get the runtime down to a little over 1s (vs ~350ms for the optimized C
>> >> and Rust code) on my maxed-out 2019 MBP and ~600ms on my M1 Mac Mini.
>> >>
>> >> Pawel Mosakowski writes:
>> >>
>> >> > Hi Bogdan,
>> >> >
>> >> > This is a brilliant solution and also completely over my head. It 
>> >> > finishes
>> >> > in ~3.75s on my PC and is faster than the Python version which basically
>> >> > delegates all the work to C. I will need to spend some time on
>> >> > understanding it but I am looking forward to learning something new.
>> >> >
>> >> > Many thanks,
>> >> > Pawel
>> >> >
>> >> > On Thursday, March 18, 2021 at 7:22:10 PM UTC bogdan wrote:
>> >> >
>> >> >> I managed to get it about as fast as Python by making it really
>> >> >> imperative and rolling my own hash:
>> >> >>
>> >> >> https://gist.github.com/Bogdanp/fb39d202037cdaadd55dae3d45737571
>> >> >>
>> >> >> Sam Tobin-Hochstadt writes:
>> >> >>
>> >> >> > Here are several variants of the code:
>> >> >> > https://gist.github.com/d6fbe3757c462d5b4d1d9393b72f9ab9
>> >> >> >
>> >> >> > The enabled version is about the fastest I can get without using
>> >> >> > `unsafe` (which the rules said not to do). It's possible to optimize 
>> >> >> > a
>> >> >> > tiny bit more by avoiding sorting, but only a few milliseconds -- it
>> >> >> > would be more significant if there were more different words.
>> >> >> >
>> >> >> > Switching to bytes works correctly for the given task, but wouldn't
>> >> >> > always work in the case of general UTF8 input. But those versions
>> >> >> > appeared not be faster for me. Also, writing my own string-downcase
>> >> >> > didn't help. And using a big buffer and doing my own newline 
>> >> >> > splitting
>> >> >> > didn't help either.
>> >> >> >
>> >> >> > The version using just a regexp matching on a port (suggested by
>> >> >> > Robby) turned out not to be faster either, so my suspicion is that 
>> >> >> > the
>> >> >> > original slowness is just using regexps for splitting words.
>> >> >> >
>> >> >> > Sam
>> >> >> >
>> >> >> > On Thu, Mar 18, 2021 at 11:28 AM Sam Tobin-Hochstadt
>> >> >> >  wrote:
>> >> >> >>
>> >> >> >> Here's a somewhat-optimized version of the code:
>> >> >> >>
>> >> >> >> #lang racket/base
>> >> >> >> (require racket/string racket/vector racket/port)
>> >> >> >>
>> >

Re: [racket-users] Best way to say 'block until true'?

[Sam Tobin-Hochstadt]

Another possibility is to send a message on a channel when the user is
set, and then just wait with `sync` for a message to appear on the
channel.

Sam

On Fri, Mar 19, 2021 at 12:02 PM Jay McCarthy  wrote:
>
> The best thing is to use a semaphore instead of a mutable reference.
> If you can't do that, then I think that you should combine the mutable
> reference with a signaling semaphore. If you can't do that, then I
> can't think of anything but a poll.
>
> --
> Jay McCarthy
> Associate Professor @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> Vincit qui se vincit.
>
> On Fri, Mar 19, 2021 at 11:59 AM David Storrs  wrote:
> >
> > Suppose I have a function that tests for some condition, e.g.
> >
> > (define current-user (make-parameter #f))
> > (define (current-user-set?) (not (false? (current-user)))
> >
> > What is the best way to say "wait until 'current-user-set?' returns true"?  
> > I've been through the Events chapter in the Reference and nothing seems 
> > like a great fit.  I could do polling via sleep or alarm-evt but that seems 
> > inefficient.  Is there a better way?
> >
> > --
> > 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/CAE8gKocbPgjcFAF_o2g6mhZBEH8PpeGyJ4CwznKc3DZkMjY%3DGw%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/CAJYbDanE4zqgFRAFSYs4kdLzjKf9xg3xi0JMNU7VmFREstNBgQ%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/CAK%3DHD%2BZbgPu734nDR408MGnvLG_tbfzeHp8TeiJ0546Fu8zVKQ%40mail.gmail.com.

Re: [racket-users] Word Count program/benchmark performance

[Sam Tobin-Hochstadt]

Use `#:authentic`, and `unsafe-vector*-{ref,set!}` saved about 50 more
ms on my machine.

Then getting rid of `set!` and just re-binding the relevant variables
produced another 50 ms speedup.

https://gist.github.com/7fc52e7bdc327fb59c8858a42258c26a

Sam

On Fri, Mar 19, 2021 at 7:21 AM Sam Tobin-Hochstadt
 wrote:
>
> One minor additional suggestion: if you use #:authentic for the struct, it 
> will generate slightly better code for the accessors.
>
> Sam
>
> On Fri, Mar 19, 2021, 6:18 AM Bogdan Popa  wrote:
>>
>> I updated the gist with some cleanups and additional improvements that
>> get the runtime down to a little over 1s (vs ~350ms for the optimized C
>> and Rust code) on my maxed-out 2019 MBP and ~600ms on my M1 Mac Mini.
>>
>> Pawel Mosakowski writes:
>>
>> > Hi Bogdan,
>> >
>> > This is a brilliant solution and also completely over my head. It finishes
>> > in ~3.75s on my PC and is faster than the Python version which basically
>> > delegates all the work to C. I will need to spend some time on
>> > understanding it but I am looking forward to learning something new.
>> >
>> > Many thanks,
>> > Pawel
>> >
>> > On Thursday, March 18, 2021 at 7:22:10 PM UTC bogdan wrote:
>> >
>> >> I managed to get it about as fast as Python by making it really
>> >> imperative and rolling my own hash:
>> >>
>> >> https://gist.github.com/Bogdanp/fb39d202037cdaadd55dae3d45737571
>> >>
>> >> Sam Tobin-Hochstadt writes:
>> >>
>> >> > Here are several variants of the code:
>> >> > https://gist.github.com/d6fbe3757c462d5b4d1d9393b72f9ab9
>> >> >
>> >> > The enabled version is about the fastest I can get without using
>> >> > `unsafe` (which the rules said not to do). It's possible to optimize a
>> >> > tiny bit more by avoiding sorting, but only a few milliseconds -- it
>> >> > would be more significant if there were more different words.
>> >> >
>> >> > Switching to bytes works correctly for the given task, but wouldn't
>> >> > always work in the case of general UTF8 input. But those versions
>> >> > appeared not be faster for me. Also, writing my own string-downcase
>> >> > didn't help. And using a big buffer and doing my own newline splitting
>> >> > didn't help either.
>> >> >
>> >> > The version using just a regexp matching on a port (suggested by
>> >> > Robby) turned out not to be faster either, so my suspicion is that the
>> >> > original slowness is just using regexps for splitting words.
>> >> >
>> >> > Sam
>> >> >
>> >> > On Thu, Mar 18, 2021 at 11:28 AM Sam Tobin-Hochstadt
>> >> >  wrote:
>> >> >>
>> >> >> Here's a somewhat-optimized version of the code:
>> >> >>
>> >> >> #lang racket/base
>> >> >> (require racket/string racket/vector racket/port)
>> >> >>
>> >> >> (define h (make-hash))
>> >> >>
>> >> >> (time
>> >> >> (for* ([l (in-lines)]
>> >> >> [w (in-list (string-split l))]
>> >> >> [w* (in-value (string-downcase w))])
>> >> >> (hash-update! h w* add1 0)))
>> >> >>
>> >> >> (define v
>> >> >> (time
>> >> >> (for/vector #:length (hash-count h)
>> >> >> ([(k v) (in-hash h)])
>> >> >> (cons k v
>> >> >> (time (vector-sort! v > #:key cdr))
>> >> >> (define p (current-output-port) #;(open-output-nowhere))
>> >> >> (time
>> >> >> (for ([pair (in-vector v)])
>> >> >> (write-string (car pair) p)
>> >> >> (write-string (number->string (cdr pair)) p)
>> >> >> (newline p)))
>> >> >>
>> >> >> It's much more imperative, but also pretty nice and compact. The
>> >> >> `printf` optimization is significant for that portion of the program,
>> >> >> but that isn't much of the running time. The overall running time for
>> >> >> 10 copies of the KJV is about 9 seconds on my laptop.
>> >> >>
>> >> >> I think the remaining difference between Racket and other languages is
>> >> >> likely the `string-split` and `string-downcase` function

Re: [racket-users] Word Count program/benchmark performance

[Sam Tobin-Hochstadt]

One minor additional suggestion: if you use #:authentic for the struct, it
will generate slightly better code for the accessors.

Sam

On Fri, Mar 19, 2021, 6:18 AM Bogdan Popa  wrote:

> I updated the gist with some cleanups and additional improvements that
> get the runtime down to a little over 1s (vs ~350ms for the optimized C
> and Rust code) on my maxed-out 2019 MBP and ~600ms on my M1 Mac Mini.
>
> Pawel Mosakowski writes:
>
> > Hi Bogdan,
> >
> > This is a brilliant solution and also completely over my head. It
> finishes
> > in ~3.75s on my PC and is faster than the Python version which basically
> > delegates all the work to C. I will need to spend some time on
> > understanding it but I am looking forward to learning something new.
> >
> > Many thanks,
> > Pawel
> >
> > On Thursday, March 18, 2021 at 7:22:10 PM UTC bogdan wrote:
> >
> >> I managed to get it about as fast as Python by making it really
> >> imperative and rolling my own hash:
> >>
> >> https://gist.github.com/Bogdanp/fb39d202037cdaadd55dae3d45737571
> >>
> >> Sam Tobin-Hochstadt writes:
> >>
> >> > Here are several variants of the code:
> >> > https://gist.github.com/d6fbe3757c462d5b4d1d9393b72f9ab9
> >> >
> >> > The enabled version is about the fastest I can get without using
> >> > `unsafe` (which the rules said not to do). It's possible to optimize a
> >> > tiny bit more by avoiding sorting, but only a few milliseconds -- it
> >> > would be more significant if there were more different words.
> >> >
> >> > Switching to bytes works correctly for the given task, but wouldn't
> >> > always work in the case of general UTF8 input. But those versions
> >> > appeared not be faster for me. Also, writing my own string-downcase
> >> > didn't help. And using a big buffer and doing my own newline splitting
> >> > didn't help either.
> >> >
> >> > The version using just a regexp matching on a port (suggested by
> >> > Robby) turned out not to be faster either, so my suspicion is that the
> >> > original slowness is just using regexps for splitting words.
> >> >
> >> > Sam
> >> >
> >> > On Thu, Mar 18, 2021 at 11:28 AM Sam Tobin-Hochstadt
> >> >  wrote:
> >> >>
> >> >> Here's a somewhat-optimized version of the code:
> >> >>
> >> >> #lang racket/base
> >> >> (require racket/string racket/vector racket/port)
> >> >>
> >> >> (define h (make-hash))
> >> >>
> >> >> (time
> >> >> (for* ([l (in-lines)]
> >> >> [w (in-list (string-split l))]
> >> >> [w* (in-value (string-downcase w))])
> >> >> (hash-update! h w* add1 0)))
> >> >>
> >> >> (define v
> >> >> (time
> >> >> (for/vector #:length (hash-count h)
> >> >> ([(k v) (in-hash h)])
> >> >> (cons k v
> >> >> (time (vector-sort! v > #:key cdr))
> >> >> (define p (current-output-port) #;(open-output-nowhere))
> >> >> (time
> >> >> (for ([pair (in-vector v)])
> >> >> (write-string (car pair) p)
> >> >> (write-string (number->string (cdr pair)) p)
> >> >> (newline p)))
> >> >>
> >> >> It's much more imperative, but also pretty nice and compact. The
> >> >> `printf` optimization is significant for that portion of the program,
> >> >> but that isn't much of the running time. The overall running time for
> >> >> 10 copies of the KJV is about 9 seconds on my laptop.
> >> >>
> >> >> I think the remaining difference between Racket and other languages
> is
> >> >> likely the `string-split` and `string-downcase` functions, plus the
> >> >> relatively-inefficient string representation that Racket uses.
> >> >>
> >> >> Sam
> >> >>
> >> >>
> >> >> On Thu, Mar 18, 2021 at 10:28 AM Pawel Mosakowski <
> pa...@mosakowski.net>
> >> wrote:
> >> >> >
> >> >> > Hi David,
> >> >> >
> >> >> > Yes, the 21 seconds includes the interpreter startup time. I have
> >> done a simple test to see how long it takes:
> >> >> >
> >> >> > $ time racket -e '(displayln "Hello, world&

Re: [racket-users] Word Count program/benchmark performance

[Sam Tobin-Hochstadt]

Here are several variants of the code:
https://gist.github.com/d6fbe3757c462d5b4d1d9393b72f9ab9

The enabled version is about the fastest I can get without using
`unsafe` (which the rules said not to do). It's possible to optimize a
tiny bit more by avoiding sorting, but only a few milliseconds -- it
would be more significant if there were more different words.

Switching to bytes works correctly for the given task, but wouldn't
always work in the case of general UTF8 input. But those versions
appeared not be faster for me. Also, writing my own string-downcase
didn't help. And using a big buffer and doing my own newline splitting
didn't help either.

The version using just a regexp matching on a port (suggested by
Robby) turned out not to be faster either, so my suspicion is that the
original slowness is just using regexps for splitting words.

Sam

On Thu, Mar 18, 2021 at 11:28 AM Sam Tobin-Hochstadt
 wrote:
>
> Here's a somewhat-optimized version of the code:
>
> #lang racket/base
> (require racket/string racket/vector racket/port)
>
> (define h (make-hash))
>
> (time
>  (for* ([l (in-lines)]
> [w (in-list (string-split l))]
> [w* (in-value (string-downcase w))])
>(hash-update! h w* add1 0)))
>
> (define v
>   (time
>(for/vector #:length (hash-count h)
>([(k v) (in-hash h)])
>  (cons k v
> (time (vector-sort! v > #:key cdr))
> (define p (current-output-port) #;(open-output-nowhere))
> (time
>  (for ([pair (in-vector v)])
>(write-string (car pair) p)
>(write-string (number->string (cdr pair)) p)
>(newline p)))
>
> It's much more imperative, but also pretty nice and compact. The
> `printf` optimization is significant for that portion of the program,
> but that isn't much of the running time. The overall running time for
> 10 copies of the KJV is about 9 seconds on my laptop.
>
> I think the remaining difference between Racket and other languages is
> likely the `string-split` and `string-downcase` functions, plus the
> relatively-inefficient string representation that Racket uses.
>
> Sam
>
>
> On Thu, Mar 18, 2021 at 10:28 AM Pawel Mosakowski  
> wrote:
> >
> > Hi David,
> >
> > Yes, the 21 seconds includes the interpreter startup time. I have done a 
> > simple test to see how long it takes:
> >
> > $ time racket -e '(displayln "Hello, world")'
> > Hello, world
> >
> > real0m0.479s
> > user0m0.449s
> > sys0m0.030s
> >
> > I have also put my code inside a main function and profiled it:
> >
> > Profiling results
> > -
> >   Total cpu time observed: 20910ms (out of 20970ms)
> >   Number of samples taken: 382 (once every 55ms)
> >   (Hiding functions with self<1.0% and local<2.0%: 1 of 12 hidden)
> >
> > ==
> >   Caller
> >  IdxTotal Self  Name+srcLocal%
> > ms(pct)   ms(pct) Callee
> > ==
> >  [1] 20910(100.0%) 0(0.0%)  [running body] 
> > ...word-occurences-profile.rkt":##f
> >   profile-thunk [2] 100.0%
> > --
> >   [running body] [1]100.0%
> >  [2] 20910(100.0%) 0(0.0%)  profile-thunk 
> > ...ket/pkgs/profile-lib/main.rkt:9:0
> >   run [3]   100.0%
> > --
> >   profile-thunk [2] 100.0%
> >  [3] 20910(100.0%) 0(0.0%)  run 
> > ...share/racket/pkgs/profile-lib/main.rkt:39:2
> >   main [4]  100.0%
> > --
> >   run [3]   100.0%
> >  [4] 20910(100.0%)50(0.2%)  main 
> > ...cket/count-word-occurences-profile.rkt:5:0
> >   read-from-stdin-it [5] 98.5%
> >   ??? [6] 0.2%
> > --
> >   main [4]  100.0%
> >  [5] 20606(98.5%)  11796(56.4%) read-from-stdin-it 
> > ...-occurences-profile.rkt:19:6
> >   internal-split [7] 42.8%
> > --
> >   main 

Re: [racket-users] Word Count program/benchmark performance

[Sam Tobin-Hochstadt]

Here's a somewhat-optimized version of the code:

#lang racket/base
(require racket/string racket/vector racket/port)

(define h (make-hash))

(time
 (for* ([l (in-lines)]
[w (in-list (string-split l))]
[w* (in-value (string-downcase w))])
   (hash-update! h w* add1 0)))

(define v
  (time
   (for/vector #:length (hash-count h)
   ([(k v) (in-hash h)])
 (cons k v
(time (vector-sort! v > #:key cdr))
(define p (current-output-port) #;(open-output-nowhere))
(time
 (for ([pair (in-vector v)])
   (write-string (car pair) p)
   (write-string (number->string (cdr pair)) p)
   (newline p)))

It's much more imperative, but also pretty nice and compact. The
`printf` optimization is significant for that portion of the program,
but that isn't much of the running time. The overall running time for
10 copies of the KJV is about 9 seconds on my laptop.

I think the remaining difference between Racket and other languages is
likely the `string-split` and `string-downcase` functions, plus the
relatively-inefficient string representation that Racket uses.

Sam


On Thu, Mar 18, 2021 at 10:28 AM Pawel Mosakowski  wrote:
>
> Hi David,
>
> Yes, the 21 seconds includes the interpreter startup time. I have done a 
> simple test to see how long it takes:
>
> $ time racket -e '(displayln "Hello, world")'
> Hello, world
>
> real0m0.479s
> user0m0.449s
> sys0m0.030s
>
> I have also put my code inside a main function and profiled it:
>
> Profiling results
> -
>   Total cpu time observed: 20910ms (out of 20970ms)
>   Number of samples taken: 382 (once every 55ms)
>   (Hiding functions with self<1.0% and local<2.0%: 1 of 12 hidden)
>
> ==
>   Caller
>  IdxTotal Self  Name+srcLocal%
> ms(pct)   ms(pct) Callee
> ==
>  [1] 20910(100.0%) 0(0.0%)  [running body] 
> ...word-occurences-profile.rkt":##f
>   profile-thunk [2] 100.0%
> --
>   [running body] [1]100.0%
>  [2] 20910(100.0%) 0(0.0%)  profile-thunk 
> ...ket/pkgs/profile-lib/main.rkt:9:0
>   run [3]   100.0%
> --
>   profile-thunk [2] 100.0%
>  [3] 20910(100.0%) 0(0.0%)  run 
> ...share/racket/pkgs/profile-lib/main.rkt:39:2
>   main [4]  100.0%
> --
>   run [3]   100.0%
>  [4] 20910(100.0%)50(0.2%)  main 
> ...cket/count-word-occurences-profile.rkt:5:0
>   read-from-stdin-it [5] 98.5%
>   ??? [6] 0.2%
> --
>   main [4]  100.0%
>  [5] 20606(98.5%)  11796(56.4%) read-from-stdin-it 
> ...-occurences-profile.rkt:19:6
>   internal-split [7] 42.8%
> --
>   main [4]  100.0%
>  [6]51(0.2%)   0(0.0%)  ??? 
> ...cket/collects/racket/private/sort.rkt:369:3
>   generic-sort/key [8]  100.0%
> --
>   read-from-stdin-it [5]100.0%
>  [7]  8810(42.1%)   3528(16.9%) internal-split 
> ...collects/racket/string.rkt:117:0
>   regexp-split [9]   59.9%
> --
>   ??? [6]   100.0%
>  [8]51(0.2%)   0(0.0%)  generic-sort/key 
> .../racket/private/sort.rkt:156:2
>   copying-mergesort [10]100.0%
> --
>   internal-split [7]100.0%
>  [9]  5282(25.3%)   2810(13.4%) regexp-split 
> ...ts/racket/private/string.rkt:338:2
>   loop [11]  46.8%
> --
>   generic-sort/key [8]   10.0%
>   copying-mergesort [10] 90.0%
> [10]51(0.2%)  51(0.2%)  copying-mergesort 
> ...racket/private/sort.rkt:129:8
>   copying-mergesort [10] 90.0%
> --
>   regexp-split [9]  100.0%
> [11]  2471(11.8%)   2471(11.8%) loop 
> 

Re: [racket-users] Synchronizable conjunction of events?

[Sam Tobin-Hochstadt]

Reagents are a generalization of core CML, but Racket extends the basics of
CML considerably. I think there's definitely implementation complexity in
reagents that would need to be added to support conjunction, but I don't
know how much.

Looking back at Aaron's thesis, I see several other systems with forms of
conjunction that are relevant here. First, join patterns, which reagents
are based on, also include conjunction. Second, transactional events
(Donnelly and Fluent) are in some sense exactly what's requested here, the
andThen combinator mentioned here is what I think you originally requested:
http://www.cs.cornell.edu/people/fluet/research/tx-events/

Sam

On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt  wrote:

> Thanks for the help, everyone.
>
> Sam, it looks like you've worked with Aaron a bit on reagents in
> https://github.com/aturon/Caper.  Is there anything CML can express that
> reagents have trouble with?  How does the implementation complexity compare?
>
> On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote:
>
>> I think Aaron Turon's reagents (and more generally k-cas) are an example
>> of N-way rendezvous.
>>
>> Sam
>>
>> On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt  wrote:
>>
>>> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
>>> > Is there a corresponding event for a logical conjunction (I was
>>> looking for
>>> > something like `all-evt` or `every-evt`), which requires that all of
>>> its
>>> > members be ready for synchronization at the same time?
>>>
>>> No. (Although `replavce-evt` is a weak kind of "and", it's not what
>>> you're looking for.)
>>>
>>> > If not, is there a fundamental barrier to its implementation with the
>>> > ConcurrentML approach?
>>>
>>> Yes, at least in the sense that it's not possible to implement N-way
>>> rendezvous given only CML's rendezvous.
>>>
>>> So, N-way rendezvous would have to be implemented in the core. I'm
>>> certain that some languages have implemented that, but I have forgotten
>>> the examples.
>>>
>>> > Related to this, I've been reading "Kill-Safe Synchronization
>>> Abstractions"
>>> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found
>>> it
>>> > notable that the swap channel couldn't be implemented in a way that
>>> was
>>> > both kill-safe and break-safe (not ruining `sync/enable-break`'s
>>> > exclusive-or guarantee).  I'm wondering if both forms of safety could
>>> be
>>> > achieved by using a hypothetical `all-evt` that behaves as I've
>>> described.
>>>
>>> Probably so. The citation of [17] in that part of the paper is meant to
>>> allude to the CML-style rendezvous versus N-way rendezvous constraint.
>>>
>>>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu
>>> .
>>>
>> --
> 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/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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%2BaXvUNarLG%2BtWFB_0Wive-h4dJrOMmPLVoYaWc0qWt0tA%40mail.gmail.com.

Re: [racket-users] Synchronizable conjunction of events?

[Sam Tobin-Hochstadt]

I think Aaron Turon's reagents (and more generally k-cas) are an example of
N-way rendezvous.

Sam

On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt  wrote:

> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
> > Is there a corresponding event for a logical conjunction (I was looking
> for
> > something like `all-evt` or `every-evt`), which requires that all of its
> > members be ready for synchronization at the same time?
>
> No. (Although `replavce-evt` is a weak kind of "and", it's not what
> you're looking for.)
>
> > If not, is there a fundamental barrier to its implementation with the
> > ConcurrentML approach?
>
> Yes, at least in the sense that it's not possible to implement N-way
> rendezvous given only CML's rendezvous.
>
> So, N-way rendezvous would have to be implemented in the core. I'm
> certain that some languages have implemented that, but I have forgotten
> the examples.
>
> > Related to this, I've been reading "Kill-Safe Synchronization
> Abstractions"
> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found it
> > notable that the swap channel couldn't be implemented in a way that was
> > both kill-safe and break-safe (not ruining `sync/enable-break`'s
> > exclusive-or guarantee).  I'm wondering if both forms of safety could be
> > achieved by using a hypothetical `all-evt` that behaves as I've
> described.
>
> Probably so. The citation of [17] in that part of the paper is meant to
> allude to the CML-style rendezvous versus N-way rendezvous constraint.
>
>
> 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/20210315155008.cc%40sirmail.smtps.cs.utah.edu
> .
>

-- 
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%2BYF0eQX%2B0oZCEs_E6XAF6Hv4vaA0tTTfEky%3DL7B7YAj-g%40mail.gmail.com.

Re: [racket-users] Possible bug when reading/writing large inexact numbers

[Sam Tobin-Hochstadt]

I believe it's 
https://github.com/racket/racket/commit/0561d71e60502fa857b0d169f64da723584d96d6

Sam

On Sun, Mar 7, 2021 at 8:52 PM Greg Rosenblatt  wrote:
>
> Great, thanks.  Out of curiosity, where in the reader was this bug 
> originally?  Can you point me to a diff?
>
> On Sunday, March 7, 2021 at 8:42:33 PM UTC-5 sorawe...@gmail.com wrote:
>>
>> This is already fixed. Racket 8.0 doesn't have this issue.
>>
>> On Mon, Mar 8, 2021 at 8:31 AM Greg Rosenblatt  wrote:
>>>
>>> Large inexact numbers may change values after a second round trip between 
>>> read and write.  I was expecting to reach a fixed point after the first 
>>> round trip.  Is this a bug?
>>>
>>> Welcome to Racket v7.8 [cs].
>>> > 4.57030e+53
>>> 4.5703e+53
>>> > 4.5703e+53
>>> 4.57029995e+53
>>>
>>> --
>>> 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/28f2c566-472f-48eb-881f-028dad5b1285n%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/32726ef8-a4fe-4154-b01f-8fc734f1930an%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/CAK%3DHD%2BZXREhazO2D7cjT0SN103K2qKeeXO6tY0NW9L7p3qxg5g%40mail.gmail.com.

Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Sam Tobin-Hochstadt]

On Thu, Mar 4, 2021 at 3:24 PM Dimaugh Silvestris
 wrote:
>
> On Thu, 4 Mar 2021 at 19:29, Sam Tobin-Hochstadt  wrote:
>>
>> It doesn't print that way because that wouldn't turn back into the original 
>> value when evaluated, since it's quoted.
>
>
> Is there any other way?
> If not, I might consider the possibility of having a struct type for each of 
> those ugens, but as I was saying in my first mail - is that sensible? That 
> would mean declaring ~600 struct types.

I'm not totally sure what you want. The goal of `print` is to print
things in roughly a way that evaluating the printed result would
produce the original value. Thus:

Evaluating '(1 2 3) produces a 3-element list.
Evaluating (sinosc: 1 2) sounds like it produces a structure that you want.

But evaluating '(sinosc: 1 2) produces a 3-element list, not a
structure. Thus, you don't want that as the printed result. That means
that if you want to construct a pair of 0 and that structure, you need
to use `cons` and not `quote`.

If you want something else then you might need to construct the
function provided for `gen:custom-write` directly, instead of using
`make-constructor-style-printer`, but I still don't understand what
you want the result to be.

Sam

-- 
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%2BZfBAj7sTP83Ke965r8jXFKiPKNz5jfqv38NiergNHs5w%40mail.gmail.com.

Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Sam Tobin-Hochstadt]

I think you want to add `#:property prop:custom-print-quotable 'never`
to that struct declaration, and then it will behave as you wanted.

Sam

On Thu, Mar 4, 2021 at 11:44 AM Dimaugh Silvestris
 wrote:
>
> I have a struct defined as:
> (struct ugen sc.unit (name rate inputs)
>   #:methods gen:custom-write
>   [(define write-proc
>  (make-constructor-style-printer
>   [λ (x) (let [(rate (ugen-rate x))
>(name (symbol-append (ugen-name x) ':))]
>(cond [(eq? rate 'ar) name]
>  [else (symbol-append
> name rate)]))]
>   [λ (x) (ugen-inputs x)]))] #:transparent)
>
> So that (ugen 'sinosc 'ar (1 2)) prints as (sinosc: 1 2), which incidentally 
> it's the same as the function call that creates that value, that is: (sinosc: 
> 3 4) creates the struct instance (ugen 'sinosc 'ar (3 4)). *
>
> The problem is, within a list it prints like '(#), which is 
> quite ugly.
>
> * I don't know if this is a smart choice. I'm building a SuperCollider 
> client, and in SuperCollider there's hundreds of ugens (unit generators, such 
> as oscillators, filters, etc).
> Because there's hundreds of them, I thought it might be heavy on memory or 
> cpu to declare a specific struct for each one of them; so I choose instead to 
> declare only constructors that build different instances of the ugen struct.
>
> --
> 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/56b85a49-2b64-465a-a58d-3b758aa823c5n%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/CAK%3DHD%2Bb_SSFcT35ohW1TeiDPpcHXiX8CN%3DNNseaRCz_nbSWcLw%40mail.gmail.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[Sam Tobin-Hochstadt]

I think there are two reasons that code gets slower.

1. The `match-define` includes pair and struct checks, which are
omitted for plain accessor uses because of the unsafe declaration.
2. That use of `match` expands to `define-values` which ends up as a
`call-with-values` and a `case-lambda` at the chez layer and is not
removed.

`match` could recognize that it's being compiled with unsafe mode and
omit these checks, although it's not that straightforward. Also
schemify (or Chez) could do more to eliminate the use of multiple
values, although that's hard without eliminating the failure cases.

Sam

On Thu, Mar 4, 2021 at 3:23 AM philngu...@gmail.com
 wrote:
>
> Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to the 
> syntax object variant that incorporated sleepnova's and yjqww6's improvements.
>
> Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's pull 
> request. It makes a noticeable difference. One unsatisfying thing is that in 
> one place, if I replace the 4 separate define clauses with just 
> `(match-define (cons (op o val) rst) parsed)`, the benchmarks are more than 
> twice slower.
>
> On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt wrote:
>>
>> First, there's no longer a difference because yjqww6 just had a PR
>> merged that improves the Racket performance.
>>
>> The performance difference that was there was mostly because the Chez
>> code was run with `--optimize-level 3` which turns off safety. If that
>> was changed to `--optimize-level 2` the timing became much slower.
>>
>> Sam
>>
>> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
>>  wrote:
>> >
>> > There’s this benchmark on BF interpreter where the Racket and Chez Scheme 
>> > implementations are very similar, but Chez Scheme is much faster than 
>> > Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 136s).
>> >
>> > There’s the “Racket (Syntax Object)” variant that directly parses BF’s 
>> > syntax into Racket syntax object, which is faster (3.7s for bench, 82s for 
>> > mandel), but still significantly behind Chez Scheme’s naive interpreter.
>> >
>> > Profiling doesn’t give very illuminating results, saying most of the cost 
>> > is from interpreting BF’s loop instruction.
>> >
>> > Given that Racket is on Chez, could this benchmark reveal some low hanging 
>> > fruit for improving Racket’s performance?
>> >
>> > --
>> > 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/83b2819d-8295-4769-944d-fa0c155976dan%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/a5e77286-68b8-481a-8dea-0f547c5ce968n%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/CAK%3DHD%2BbSp%3Dg-POJ7v9HUksw5WivY6_RbsPSnGv8B6PwfSYZs1A%40mail.gmail.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[Sam Tobin-Hochstadt]

First, there's no longer a difference because yjqww6 just had a PR
merged that improves the Racket performance.

The performance difference that was there was mostly because the Chez
code was run with `--optimize-level 3` which turns off safety. If that
was changed to `--optimize-level 2` the timing became much slower.

Sam

On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
 wrote:
>
> There’s this benchmark on BF interpreter where the Racket and Chez Scheme 
> implementations are very similar, but Chez Scheme is much faster than Racket 
> 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 136s).
>
> There’s the “Racket (Syntax Object)” variant that directly parses BF’s syntax 
> into Racket syntax object, which is faster (3.7s for bench, 82s for mandel), 
> but still significantly behind Chez Scheme’s naive interpreter.
>
> Profiling doesn’t give very illuminating results, saying most of the cost is 
> from interpreting BF’s loop instruction.
>
> Given that Racket is on Chez, could this benchmark reveal some low hanging 
> fruit for improving Racket’s performance?
>
> --
> 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/83b2819d-8295-4769-944d-fa0c155976dan%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/CAK%3DHD%2BY6e%3D7QXJZhOhF8-QbNc5HGu%2BUcrGzr1HhctSp1sA470g%40mail.gmail.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[Sam Tobin-Hochstadt]

When Chez is faster than Racket CS, the usual culprits are either:
- mutable pairs
- very large code size that causes Racket CS to interpret the outer module

However, neither of those seem to be happening here.

Sam

On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
 wrote:
>
> There’s this benchmark on BF interpreter where the Racket and Chez Scheme 
> implementations are very similar, but Chez Scheme is much faster than Racket 
> 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 136s).
>
> There’s the “Racket (Syntax Object)” variant that directly parses BF’s syntax 
> into Racket syntax object, which is faster (3.7s for bench, 82s for mandel), 
> but still significantly behind Chez Scheme’s naive interpreter.
>
> Profiling doesn’t give very illuminating results, saying most of the cost is 
> from interpreting BF’s loop instruction.
>
> Given that Racket is on Chez, could this benchmark reveal some low hanging 
> fruit for improving Racket’s performance?
>
> --
> 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/83b2819d-8295-4769-944d-fa0c155976dan%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/CAK%3DHD%2BY5p%3DW2%2BMrg_QpvVQZVXY%2B3sHW-c%3DGcK1KrTT%3D0hRC9-g%40mail.gmail.com.

Re: [racket-users] Verifying the contract on a function

[Sam Tobin-Hochstadt]

You can use the value-contract function, along with contract-stronger? to
do this.

Sam

On Wed, Feb 24, 2021, 6:03 PM David Storrs  wrote:

> I have some macros that generate functions.  For testing purposes, I'd
> like to be able to ask the function "Do you have this contract
> ?"  Is there a way to do that?  I've been digging through the
> Contracts section and googled for it but I'm not seeing one.
>
> --
> 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/CAE8gKodrApnAtr%3D5BpvSLxiKAAQJjO2bj7HkE_75-VLb25rNgA%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/CAK%3DHD%2BbrrfS9nRwQyw1Q05_6DHfQxECTU0Dvi8wtSTTs7AwEEw%40mail.gmail.com.

Re: [racket-users] public email addresses on packages server

[Sam Tobin-Hochstadt]

Github doesn't require making your email address public.

Sam

On Tue, Feb 23, 2021 at 12:19 PM Hendrik Boom  wrote:
>
> On Sat, Feb 20, 2021 at 11:47:19PM +0700, Roger Keays wrote:
> > Has any consideration been given to concealing email addresses on 
> > pkgs.racket-lang.org for privacy purposes?
>
> Aren't those email addresses available anyway from github?
>
> -- 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/20210223171932.ljgqq77qb5b7wjin%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%2BY840OarKctMC6Hpjb1-TYC6ZLmC6F2aeeZtrmnbykLSg%40mail.gmail.com.

Re: [racket-users] can't create a new package on pkgd.racket-lang.org

[Sam Tobin-Hochstadt]

Unfortunately, it's old versions of Racket that don't support this,
and adding error messages there will have the same problem as fixing
them -- they're already out there and on people's computers. However,
this will be fixed in the next release of Racket.

Sam

On Tue, Feb 23, 2021 at 6:49 AM Roger Keays  wrote:
>
>
> Thanks for the pointer. Adding "main" as the branch fixed the problem with 
> the package submission too. An error message to catch that mistake might save 
> the next person some head-scratching. As far as I remember, github created my 
> repo with main as the default branch rather than master.
>
> On Fri, Feb 19, 2021 at 07:54:51PM +0700, Sorawee Porncharoenwase wrote:
> > For the raco pkg install error, it looks like your branch is named main, so
> > you need to run raco pkg install git://
> > github.com/rogerkeays/racket-dollar#main
> >
> > Ideally, raco pkg install git://github.com/rogerkeays/racket-dollar should
> > also work, but currently it doesn’t
> > .
> >
> > On Fri, Feb 19, 2021 at 6:52 PM Roger Keays  wrote:
> >
> > >
> > > Hi,
> > >
> > > Today I made an account on racket-lang.org to post a package, but when I
> > > submit the form, it just bounces back at me, blank. The package I added
> > > does not appear under "my packages", so it seems the submission failed.
> > > There are no error messages.
> > >
> > > https://pkgd.racket-lang.org/pkgn/create
> > >
> > > I'm submitting an example #lang extension from github for
> > > educational/demonstration purposes:
> > > https://github.com/rogerkeays/racket-dollar
> > >
> > > Could this be because my account is new? I also noticed I get an error
> > > when trying to get raco to install from github:
> > >
> > > $ raco pkg install git://github.com/rogerkeays/racket-dollar#master
> > > Querying Git references for racket-dollar at git://
> > > github.com/rogerkeays/racket-dollar#master
> > > git: could not find requested reference
> > >   reference: master
> > >   context...:
> > >/usr/share/racket/collects/net/git-checkout.rkt:344:0: select-commits
> > >/usr/share/racket/collects/net/git-checkout.rkt:73:8
> > >/usr/share/racket/collects/net/git-checkout.rkt:54:2: retry-loop
> > >/usr/share/racket/collects/pkg/private/stage.rkt:59:2: lookup-normally
> > >/usr/share/racket/collects/pkg/private/stage.rkt:107:0:
> > > stage-package/info46
> > >/usr/share/racket/collects/pkg/private/install.rkt:659:4: for-loop
> > >/usr/share/racket/collects/pkg/private/install.rkt:141:0:
> > > install-packages76
> > >
> > >  
> > > /usr/share/racket/collects/pkg/private/../../racket/private/more-scheme.rkt:261:28
> > >
> > >  
> > > /usr/share/racket/collects/racket/contract/private/arrow-val-first.rkt:430:3
> > >/usr/share/racket/collects/racket/file.rkt:435:8
> > >/usr/share/racket/collects/racket/file.rkt:391:2: loop
> > >/usr/share/racket/collects/pkg/main.rkt:206:16
> > >(submod "/usr/share/racket/collects/pkg/main.rkt" main): [running body]
> > >temp37_0
> > >for-loop
> > >run-module-instance!125
> > >...
> > >
> > > $ racket -v
> > > Welcome to Racket v7.2.
> > >
> > > Suggestions 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/sigid.16823f523d.20210217164232.GA4731%40papaya.papaya
> > > .
> > >
> >
> > --
> > 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/CADcuegtie4M_Cjjycvc15hbfSN98HQxcNZZYH4LUxW5kfPUviA%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/sigid.06852a6d4b.20210220163029.GB8013%40papaya.papaya.

-- 
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%2BZOqsHwjuzJHrBC%2B1A59FjsvnvYDhPsG5HQQot21HiAvA%40mail.gmail.com.

Re: [racket-users] Sticky scrollable nav bar in docs

[Sam Tobin-Hochstadt]

This seems like it would be a nice addition. I think starting with a
PR is the right place to begin.

Sam

On Wed, Feb 17, 2021 at 7:01 PM 'William J. Bowman' via Racket Users
 wrote:
>
> One of my students asked about making the Racket docs navbar sticky and 
> scrollable, to help when navigating very long docs pages. I made a quick hack 
> and deployed it here:
>   https://www.students.cs.ubc.ca/~cs-411/docs/reference/sets.html
>
> Personally I've found it very useful. Would this change make sense for the 
> Racket docs generally? (With some polish by someone who is better at UX than 
> me?)
>
> To implement it, I just replaced `doc-site.css` with the following
>
> .navsettop {
> position: fixed;
> z-index: 1;
> background: #a7b0be;
> height: auto;
> }
>
>
> .tocset {
> position: fixed;
> overflow-y: scroll;
> height: 88%;
> }
>
> --
> William J. Bowman
>
> --
> 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/YC2uQ3BJIsMJTsMP%40williamjbowman.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%2BbTOjeUChyCwN3Zb6Z0f2vGh9zBa_zcD0NgN7W6OKbp3Q%40mail.gmail.com.

Re: [racket-users] Error while starting simple program

[Sam Tobin-Hochstadt]

I think there's a typo in your program -- there's an extra "br" in the
name of `racket/function`.

Sam

On Mon, Feb 15, 2021 at 11:58 AM Gowthaman Basuvaraj
 wrote:
>
> open-input-file: cannot open module file
>  module path: racket/functionbr
>  path: /home/gowthaman/racket/collects/racket/functionbr.rkt
>  system error: no such file or directory; rkt_err=3
>
> unable to wrap my head around whats the issue here
>
> --
> 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/8de019d8-8273-4e4f-8079-12d9bfbf8f53n%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/CAK%3DHD%2BYd1i-dkPr4sweqMb%2BuZNwc7wkmwA7KedoXpK7kFGSZUg%40mail.gmail.com.

Re: [racket-users] Error while compiling Racket BC

[Sam Tobin-Hochstadt]

In general, yes, although you can often get away with slightly older.

On Fri, Feb 5, 2021, 6:52 PM 'Killian Zhuo (KDr2)' via Racket Users <
racket-users@googlegroups.com> wrote:

> Thank you, does that mean I need a v8.0.0.5 to compile a v8.0.0.5?
>
> I thought v7.9 is new enough...
>
> Greetings.
>
> Killian Zhuo (KDr2, https://kdr2.com)
>
>
>
> On Saturday, February 6, 2021, 07:47:41 AM GMT+8, Sam Tobin-Hochstadt <
> sa...@cs.indiana.edu> wrote:
>
>
> This means that you're building with a previous version of Racket that is
> too old (which might be quite recent but is nonetheless too old to use in
> place of bootstrapping).
>
> Sam
>
> On Fri, Feb 5, 2021, 6:44 PM 'Killian Zhuo (KDr2)' via Racket Users <
> racket-users@googlegroups.com> wrote:
>
> Here is my configure command:
>
> ./configure --enable-cs --enable-bc --enable-csdefault
> --enable-racket=$HOME/programs/racket/bin/racket
>
> $HOME/programs/racket/bin/racket is a prebuilt Racket whose version is
> 7.9.
>
> Then I ran `make cs` and `make install-cs`, all worked well.
>
> Then `make bc` it also worked well, but when I ran `make install-bc`, some
> errors occured:
>
> make[4]: Entering directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> if [ "" = "" ]; then \
>   echo "/data/zhuoql/Work/hall/racket/racket/lib"; \
> fi
> /data/zhuoql/Work/hall/racket/racket/lib
> make[4]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> make[3]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src'
> make[2]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src'
> cd bc && make install-setup-3m SELF_ROOT_CONFIG_FLAG="-Z"
> PLT_SETUP_OPTIONS="" SETUP_MACHINE_FLAGS=""
> make[2]: Entering directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> /data/zhuoql/programs/racket/bin/racket -X
> "/data/zhuoql/Work/hall/racket/racket/collects" -G
> "/data/zhuoql/Work/hall/racket/racket/etc"  -Z ../../../../build/config
> --no-user-path -N "raco" -l- setup --no-user
> raco setup: bootstrapping from source...
>  read-compiled-linklet: version mismatch  expected: "7.9"  found:
> "8.0.0.5"  in:
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/compiled/cm-minimal_rkt.zo
> /data/zhuoql/Work/hall/racket/racket/collects/racket/fixnum.rkt:12:9:
> provide: provided identifier is not defined or required
>   at: fx+/wraparound
>   in: (#%provide (expand (provide-trampoline fx->fl fl->fx fxabs fx+ fx-
> fx* fx+/wraparound fx-/wraparound fx*/wraparound fxquotient fxremainder
> fxmodulo fxand fxior fxxor fxnot fxrshift fxlshift fxlshift/wraparound fx>=
> fx> fx= fx< fx<= fxmin fxmax fixnum-fo...
>   location...:
>/data/zhuoql/Work/hall/racket/racket/collects/racket/fixnum.rkt:12:9
>   context...:
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> comp

Re: [racket-users] Error while compiling Racket BC

[Sam Tobin-Hochstadt]

This means that you're building with a previous version of Racket that is
too old (which might be quite recent but is nonetheless too old to use in
place of bootstrapping).

Sam

On Fri, Feb 5, 2021, 6:44 PM 'Killian Zhuo (KDr2)' via Racket Users <
racket-users@googlegroups.com> wrote:

> Here is my configure command:
>
> ./configure --enable-cs --enable-bc --enable-csdefault
> --enable-racket=$HOME/programs/racket/bin/racket
>
> $HOME/programs/racket/bin/racket is a prebuilt Racket whose version is
> 7.9.
>
> Then I ran `make cs` and `make install-cs`, all worked well.
>
> Then `make bc` it also worked well, but when I ran `make install-bc`, some
> errors occured:
>
> make[4]: Entering directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> if [ "" = "" ]; then \
>   echo "/data/zhuoql/Work/hall/racket/racket/lib"; \
> fi
> /data/zhuoql/Work/hall/racket/racket/lib
> make[4]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> make[3]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src'
> make[2]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src'
> cd bc && make install-setup-3m SELF_ROOT_CONFIG_FLAG="-Z"
> PLT_SETUP_OPTIONS="" SETUP_MACHINE_FLAGS=""
> make[2]: Entering directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> /data/zhuoql/programs/racket/bin/racket -X
> "/data/zhuoql/Work/hall/racket/racket/collects" -G
> "/data/zhuoql/Work/hall/racket/racket/etc"  -Z ../../../../build/config
> --no-user-path -N "raco" -l- setup --no-user
> raco setup: bootstrapping from source...
>  read-compiled-linklet: version mismatch  expected: "7.9"  found:
> "8.0.0.5"  in:
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/compiled/cm-minimal_rkt.zo
> /data/zhuoql/Work/hall/racket/racket/collects/racket/fixnum.rkt:12:9:
> provide: provided identifier is not defined or required
>   at: fx+/wraparound
>   in: (#%provide (expand (provide-trampoline fx->fl fl->fx fxabs fx+ fx-
> fx* fx+/wraparound fx-/wraparound fx*/wraparound fxquotient fxremainder
> fxmodulo fxand fxior fxxor fxnot fxrshift fxlshift fxlshift/wraparound fx>=
> fx> fx= fx< fx<= fxmin fxmax fixnum-fo...
>   location...:
>/data/zhuoql/Work/hall/racket/racket/collects/racket/fixnum.rkt:12:9
>   context...:
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:409:15
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:374:0:
> maybe-compile-zo
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:208:0:
> compile-root
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:144:4:
> compilation-manager-load-handler
>
>  
> /data/zhuoql/Work/hall/racket/racket/collects/compiler/private/cm-minimal.rkt:610:0:
> compile-zo*
>...
> Makefile:469: recipe for target 'install-setup-3m' failed
> make[2]: *** [install-setup-3m] Error 1
> make[2]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src/bc'
> Makefile:179: recipe for target 'install-3m' failed
> make[1]: *** [install-3m] Error 2
> make[1]: Leaving directory '/data/zhuoql/Work/hall/racket/racket/src'
> Makefile:114: recipe for target 'install-bc' failed
> make: *** [install-bc] Error 2
>
>
>
> I worked on the head of the master branch, anyone knows how to fix this?
> Thanks.
>
> Greetings.
>
> Killian Zhuo (KDr2, https://kdr2.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/252652007.2153435.1612568669639%40mail.yahoo.com
> 

Re: [racket-users] Typed racket and generics?

[Sam Tobin-Hochstadt]

Unfortunately this isn't supported yet. Right now, you can use struct
type properties directly to build your own generics, but you can't use
the generics library.

Sam

On Sat, Jan 30, 2021 at 4:20 AM Stuart Hungerford
 wrote:
>
> Hi Racketeers,
>
> Is there any way to have Racket code using `define-generics` interact with 
> typed Racket code?  (I think the answer is "no", but I thought I'd check for 
> sure).
>
> Thanks,
>
> Stu
>
> --
> 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/333b7744-85e8-4745-aad2-77272d1e20c5n%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/CAK%3DHD%2BaCU71oM16-naviJ6NhF9J3dmhnOMMNwAT7%3DjvaaV8b2Q%40mail.gmail.com.

Re: [racket-users] Unsafe structs

[Sam Tobin-Hochstadt]

On Wed, Jan 20, 2021 at 5:16 PM Dominik Pantůček
 wrote:
>
> Hi Sam,
>
> I went through all my notes and prepared minimal (sometimes) working
> examples for most of the issues I mentioned. Let's go through it one by
> one. I assume that some of the complications I encountered were because
> my lack of experience with Typed Racket. I hope some of these examples
> will be useful anyway.
>
> All the examples are in a git repository on Gitlab [1].

This is great, thanks! I've opened several issues for fixing some of
these problems.

> >> * Higher-order procedures and polymorphic functions in all imaginable
> >> combinations. That was a total disaster. Yes, the documentation clearly
> >> states that - but typing any code using these is like trying to break a
> >> badly designed cipher. Irregularities here and there. Sometimes simple
> >> `inst' was enough. Sometimes casting both the function and the arguments
> >> was necessary. The biggest trouble is that the error messages are very
> >> cryptic and sometimes even do not point to the offending construct but
> >> only the module file. I will provide MWE to show this if someone wants
> >> to look into it.
> >
> > An example would be great here. In general you should only need one
> > use of `inst` in any of these cases, and you shouldn't ever need a
> > `cast`.
>
> Directory "polymorph". In my use-case, there is a lot of structured
> S-expression data in the format:
>
> (define tagged-data-example
>   '(data-2D
> ((B B B B)
>  (B B B
>
> 9 steps of typing the procedure to calculate the maximum length of the
> 2D matrix are in this directory. All the errors are documented there.
> Yes, many of the intermediate constructs are wrong. The error in
> polymorph4.rkt shows the biggest problem I've seen so far. As a separate
> example, it is pretty easy to fix - but finding the source of the
> problem in a bigger module was not easy at all. Basically I ended up
> bi-partitioning the whole source code with procedure granularity and
> once I found the offending procedure a linear trial-and-error approach
> was the only option that allowed me to find the offending expression.
>
> Yes, the final polymorph9.rkt contains the approach that I actually used
> for resolving the issue.

Yikes, this is pretty terrible. Here's a nice simple version that works, though:

  (define (typed-extract-data (tagged-data : (Pairof Symbol (Listof
(Listof (Listof Symbol)) : Number
  (define data (car (cdr tagged-data)))
  (define lengths (map (inst length Symbol) data))
  1)

What's going on here is:
1. The type for `cadr` is not quite smart enough -- if it knows that
you have an at-least two element list, then it will produce the second
element type. Otherwise, if you have a (Listof T), it produces T. But
if you have a pair of a T and (Listof S), that ends up with (Union S
T).
2. I think there's a missing `syntax/loc` in the implementation of
`cast`, which resulted in the bad error message you saw.

I also think you're jumping too quickly to use `cast` -- before you do
that, you should try `ann`, for example, with the types of `length`
that you tried, which would have accomplished the same thing and
doesn't hide type errors or impose runtime costs.

> The actual problem I was referring to here is nicely shown in the
> "union" directory and it is about typing hash-union procedure.
>
> I do not know what solution should be considered correct if there were
> multiple differently-typed hash-tables in the same module. The explicit
> type information in require/typed is definitely not a good idea - but I
> found no better way.

Well, first we should make `racket/hash`'s exports work automatically.
But absent that, there are a few things going on here:

First, using `Any` is forgetting information, which is why the version
with `Any` everywhere produced an unsatisfactory result. In general,
one misconception I see regularly with Typed Racket users is using a
general type (such as `Any`) and then expecting Typed Racket to
specialize it when it's used. If you want that, you'd need to write a
polymorphic type, like this:

(hash-union (All (a b)
   (-> (Immutable-HashTable a b)
   (Immutable-HashTable a b)
   (Immutable-HashTable a b)

Unfortunately, while this is the type you want, it can't work here
because contracts for hashes are limited in various ways. There are a
couple options to work around that.
1. Use `unsafe-require/typed` from `typed/racket/unsafe`. This works
with the type as written, but obviously if you make a mistake things
can go poorly.
2. Use a more restrictive type, such as `Any` or `Symbol` for the keys.

> >> * Classes: My notes say "". Which roughly says it
> >> all. Although I managed to back down to only using bitmap% class,
> >> properly typing all procedures using it was a nightmare. By properly I
> >> mean "it compiles and runs".
> >
> > More detail here would be 

Re: [racket-users] Unsafe structs

[Sam Tobin-Hochstadt]

Thanks for this detailed account (and for trying it out). I have some
questions inline:


On Sat, Jan 2, 2021 at 5:34 PM Dominik Pantůček
 wrote:
> And now for the worse part. TR rough edges:
>
> * Higher-order procedures and polymorphic functions in all imaginable
> combinations. That was a total disaster. Yes, the documentation clearly
> states that - but typing any code using these is like trying to break a
> badly designed cipher. Irregularities here and there. Sometimes simple
> `inst' was enough. Sometimes casting both the function and the arguments
> was necessary. The biggest trouble is that the error messages are very
> cryptic and sometimes even do not point to the offending construct but
> only the module file. I will provide MWE to show this if someone wants
> to look into it.

An example would be great here. In general you should only need one
use of `inst` in any of these cases, and you shouldn't ever need a
`cast`.

> * Struct: Missing struct generics - when porting code that relies on
> them, there's not much that can be done.

This is indeed a limitation -- struct generics are complex and we
(mostly Fred Fu) are thinking about them, but it's not there yet.

> * Math: there really is just a natural logarithm and no logarithm with
> arbitrary base? Yes, one-line to implement, but why?

I'm not sure why this didn't get added originally, but it's easy to fix.

> * Math/Fixnums/Flonums: All fx+/-/*/... accept two arguments only. No
> unary fl-, no variadic-argument fl+ or fxior (this one hurt the most).

These definitely became variadic after the type definitions were
written, but that's of course not an excuse for not updating them.

> * unsafe/ops: unsafe-vector-* resisted a lot - until I just gave up and
> require/typed it for my particular types. Maybe casting would help, but
> the error messages were different to the classical problems of the
> polymorphic functions in TR.

Can you say more about what happened here?

> * Classes: My notes say "". Which roughly says it
> all. Although I managed to back down to only using bitmap% class,
> properly typing all procedures using it was a nightmare. By properly I
> mean "it compiles and runs".

More detail here would be helpful as well.

> * with-input-from-file does not accept Path or String, only Path-String
> and the conversion rules are either missing or strange at best.
> Basically I ended up with just converting to String and casting to
> Path-String to make everything work.
>
> * with-input-from-file also revealed that procedure signatures as types
> can be very tricky - just passing `read' was not possible, because it
> accepts some optional arguments. Wrapping it in thunk helped though.

I don't understand what the problem was here; for example this works for me:

#lang typed/racket
(with-input-from-file "/tmp/x.rkt" read)

and `Path-String` is just the union of Path and String.

> * order of definitions matters. Not that this is unexpected, it is just
> strange when working with larger code-base where it didn't matter.
> Actually the error messages were helpful here.

What do you mean by "order of definitions matters" here?

> * Type annotations of procedures with variadic arguments. The only place
> where I had to put annotations outside of the procedure definition. It
> is nothing super-problematic, but it feels inconsistent with the rest.

I would encourage type annotations before the procedure definition in
all cases -- the `define` form doesn't really have the right places to
put everything that can go in a function type.

> * More modules need to be required everywhere. If module A provides a
> procedure that accepts a type from module B, all modules using that
> procedure must also require the module B to know the type. In normal
> Racket it does not matter as long as you just pass the opaque data along.

Can you give an example?

> * Syntax macros are extra hard. As I use some syntax trickery to convert
> semi-regular code to "futurized" one, I basically gave up and just ran
> everything single-threaded. The main issue is passing type information
> from the module that uses the macro to the macro and matching it on both
> sides. Also the macro must split the type annotation from argument names
> in the syntax pattern when it defines new procedures - I did some ugly
> hacks to get through it but in the end I just refrained from using them
> when possible (except for the unsafe-struct macro, of course).
> commits, 2292-line diff!) and genuinely (it really helped).

An example here would be great too.

Thanks again,
Sam

-- 
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%2BaB3P6MvY8e4-%3DKxf6z6-kas5ayT4mkxRyy3DB4Vakx_Q%40mail.gmail.com.

Re: [racket-users] Web Server Tutorial Tries to Write to Library Directory

[Sam Tobin-Hochstadt]

I believe this is a bug in `web-server/insta`, but here's a workaround:

Add the following to the beginning of the `app` module:

(require racket/runtime-path)
(define-runtime-path here ".")

Then use `here` instead of `(current-directory)` in the `start` function.

Sam

On Tue, Dec 22, 2020 at 4:56 AM Adam Golding  wrote:
>
> I'm a little confused by this tutorial--when I run the 'persistent model' in 
> section 14 it tries to write a file to the read-only directory the web-server 
> library itself is in...
>
> https://docs.racket-lang.org/continue/
>
> but grabbing the current directory before it loads the web server doesn't 
> seem to work--how do I modify it to make it write to the same folder as the 
> .rkt 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/241d7cd7-8427-40c6-80fe-24f1d910bf76n%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/CAK%3DHD%2BZwvQs6%2B%3D%3DL%3Db5pPqs5Z3v%2BXsN83jqQrBsL0iNrgbrTzw%40mail.gmail.com.

Re: [racket-users] Towards an Incremental Racket Parser for better IDE experience?

[Sam Tobin-Hochstadt]

Hi Nicolas,

I do want to encourage you to keep thinking about this stuff -- some
of the things I described are definitely doable and would be
interesting projects, even if re-writing the entire expander is a big
task.

Sam

On Wed, Dec 9, 2020 at 12:46 PM nicobao  wrote:
>
> Hi all,
>
> I've read with great attention your messages, especially Sam's very 
> comprehensive answer.
> I now clearly understand that it's a research-level work, and I was 
> definitely too ambitious in trying to dig into that - as I have limited time 
> after my day job (and probably too limited knowledge too, but that's a 
> non-problem as it wouldn't be a one-person task anyway).
> Nevertheless, I really appreciate the exchange.
>
> Kind regards,
> Nicolas
>
> On Wednesday, December 2, 2020 at 7:56:58 PM UTC+1 Sam Tobin-Hochstadt wrote:
>>
>> A few thoughts on these topics, which I've been thinking about for a while.
>>
>> First, let's distinguish two things. One is an _incremental_ system,
>> such as a parser, which is one which does less work in response to a
>> small change than it would need to do from scratch. The other is a
>> system with _error recovery_, which is one where in the presence of
>> one error, the system can still provide a useful answer and/or
>> continue on to discover other errors. tree-sitter, for example, aims
>> to do both of these, but they're quite different.
>>
>> With that in mind, several points:
>>
>> 1. It would be relatively straightforward to build an incremental
>> _reader_ -- going from text to s-expressions. You could start from the
>> grammar here: 
>> https://github.com/racket/parser-tools/blob/master/parser-tools-lib/parser-tools/examples/read.rkt
>> which is just for Scheme, and the lexer here:
>> https://github.com/racket/syntax-color/blob/master/syntax-color-lib/syntax-color/racket-lexer.rkt
>> which is for full Racket, which as Robby says is already
>> error-tolerant. The read syntax (in the absence of reader extensions)
>> is definitely context-free and probably LR(1). The code for the reader
>> is here: 
>> https://github.com/racket/racket/tree/master/racket/src/expander/read
>>
>> However, just calling `read` from scratch every time isn't a big
>> bottleneck -- the biggest Racket-syntax file I have around is about
>> 86000 lines and takes 700ms to `read`.
>>
>> 2. As Robby points out, the big challenge is the macro expander, which
>> is (a) not a grammar, (b) large and complicated (the code is here:
>> https://github.com/racket/racket/tree/master/racket/src/expander and
>> it's about 35k lines) and (c) it runs arbitrary Racket code in the
>> form of macros. I'm definitely interested in thinking about what an
>> incremental expander would look like, but that's a big research
>> project and probably would require a different model of macros than
>> Racket has right now. It would not work to use some existing parsing
>> toolkit like tree-sitter. You could perhaps write a new macro expander
>> using an incremental computation framework such as Adapton
>> [https://docs.rs/adapton/0.3.31/adapton/] or write something like
>> Adapton for Racket. How well that would work is an interesting
>> question. You could also rewrite the macro expander to be incremental
>> more directly.
>>
>> 3. An error-tolerant macro expander is more plausible, but would again
>> require substantial changes to the expander. One possible idea is to
>> use the information the macro stepper already uses to reconstruct the
>> partial program right before it went wrong, and supply that to the IDE
>> to use for completion/etc. Another idea would be to replace pieces of
>> erroneous syntax with something that allows the expander to continue
>> (this is how error-tolerant parsers work). There are probably lots
>> more ideas that we could come up with.
>>
>> 4. Compiling to one of the OCaml intermediate languages is an
>> interesting idea -- I've thought about their flambda language as a
>> possible target before. The place to start is the `schemify` layer:
>> https://github.com/racket/racket/tree/master/racket/src/schemify that
>> turns fully-expanded Racket code into Scheme code for Chez Scheme.
>> Changing that to produce flambda would be plausible, although there
>> are a lot of mismatches between the languages that would be tricky to
>> overcome. Another possibility would be to directly produce JavaScript
>> from that layer. You might be interested in the RacketScript project:
>> https://github.com/vishesh/racketscript
>>
>> If you're interested in thinking more about these topics, or worki

Re: [racket-users] [racket users] Detecting characters in symbols in macros

[Sam Tobin-Hochstadt]

Here's an example:

#lang racket

(require (for-syntax syntax/parse))

(define-syntax (foo stx)
  (syntax-parse stx
[(_ arg:id)
 #:when (regexp-match "[$]" (symbol->string (syntax-e #'arg)))
 #'1]
[(_ arg) #'2]))

(foo $abc)
(foo abc)


That prints 1 followed by 2.

Sam

On Wed, Dec 9, 2020 at 12:29 PM Kevin Forchione  wrote:
>
> Hi guys,
> Is there a way to detect a character in a symbol in a macro so that one 
> branch of the syntax-parse would be chosen or discarded based on that?
>
> Here’s roughly what I’m getting at….
>
> #lang racket
>
> (require (for-syntax syntax/parse))
>
> (define-syntax (foo stx)
>   (syntax-parse stx
> [(_ arg) #'(do-$ arg)]
> [(_ arg) #'(do-other arg)]))
>
> (foo $abc)
> (foo abc)
>
> I was thinking expo/c might come into play here, but maybe there’s another 
> approach?
>
> Thanks!
>
> Kevin
>
> --
> 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/FE7ED3FD-EAF0-4F03-8D3C-94D2092A9721%40gmail.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%2Bb%3D1iB_H7Wh0Ti2r%2BhTfDQQPJ_bTHd47ndDVkbjnvJjUA%40mail.gmail.com.

Re: [racket-users] Towards an Incremental Racket Parser for better IDE experience?

[Sam Tobin-Hochstadt]

A few thoughts on these topics, which I've been thinking about for a while.

First, let's distinguish two things. One is an _incremental_ system,
such as a parser, which is one which does less work in response to a
small change than it would need to do from scratch. The other is a
system with _error recovery_, which is one where in the presence of
one error, the system can still provide a useful answer and/or
continue on to discover other errors. tree-sitter, for example, aims
to do both of these, but they're quite different.

With that in mind, several points:

1. It would be relatively straightforward to build an incremental
_reader_ -- going from text to s-expressions. You could start from the
grammar here: 
https://github.com/racket/parser-tools/blob/master/parser-tools-lib/parser-tools/examples/read.rkt
which is just for Scheme, and the lexer here:
https://github.com/racket/syntax-color/blob/master/syntax-color-lib/syntax-color/racket-lexer.rkt
which is for full Racket, which as Robby says is already
error-tolerant. The read syntax (in the absence of reader extensions)
is definitely context-free and probably LR(1). The code for the reader
is here: https://github.com/racket/racket/tree/master/racket/src/expander/read

However, just calling `read` from scratch every time isn't a big
bottleneck -- the biggest Racket-syntax file I have around is about
86000 lines and takes 700ms to `read`.

2. As Robby points out, the big challenge is the macro expander, which
is (a) not a grammar, (b) large and complicated (the code is here:
https://github.com/racket/racket/tree/master/racket/src/expander and
it's about 35k lines) and (c) it runs arbitrary Racket code in the
form of macros. I'm definitely interested in thinking about what an
incremental expander would look like, but that's a big research
project and probably would require a different model of macros than
Racket has right now. It would not work to use some existing parsing
toolkit like tree-sitter. You could perhaps write a new macro expander
using an incremental computation framework such as Adapton
[https://docs.rs/adapton/0.3.31/adapton/] or write something like
Adapton for Racket. How well that would work is an interesting
question. You could also rewrite the macro expander to be incremental
more directly.

3. An error-tolerant macro expander is more plausible, but would again
require substantial changes to the expander. One possible idea is to
use the information the macro stepper already uses to reconstruct the
partial program right before it went wrong, and supply that to the IDE
to use for completion/etc. Another idea would be to replace pieces of
erroneous syntax with something that allows the expander to continue
(this is how error-tolerant parsers work).  There are probably lots
more ideas that we could come up with.

4. Compiling to one of the OCaml intermediate languages is an
interesting idea -- I've thought about their flambda language as a
possible target before. The place to start is the `schemify` layer:
https://github.com/racket/racket/tree/master/racket/src/schemify that
turns fully-expanded Racket code into Scheme code for Chez Scheme.
Changing that to produce flambda would be plausible, although there
are a lot of mismatches between the languages that would be tricky to
overcome. Another possibility would be to directly produce JavaScript
from that layer. You might be interested in the RacketScript project:
https://github.com/vishesh/racketscript

If you're interested in thinking more about these topics, or working
on them, I'm happy to offer more advice.

Sam

On Wed, Dec 2, 2020 at 9:53 AM nicobao  wrote:
>
> Hi!
>
> The Racket Reader and the Racket Expander always return "Error : blabla" when 
> you send it a bad Racket source code.
> As a consequence, when there is a source code error, DrRacket and the Racket 
> LSP cannot provide IDE functionalities like "find references", "info on 
> hover", "find definition"...etc.
> This is an issue, because 99% of the time one write code, the code is 
> incorrect. Other languages (Rust, Typescript/JS, Java, OCaml...etc) rely on 
> an incremental parser than can provide a tree even if the source code is 
> wrong. Basically it adds an "ERROR" node in the tree, and go on instead of 
> stopping everything and returning at the first error.
> Currently this compiler issue is blocking the Racket IDE to provide better 
> user experience.
> For my practical use case of Racket, it is important.
>
> I would like to help working towards that direction.
> I see two possible solutions to that:
> 1) improve the recursive descent parser of the Reader, as well as the 
> Expander to make them incremental and fault-tolerant
> 2) re-writing the parser in something like tree-sitter or Menhir, at the cost 
> of having to re-write the Reader/Expander logic (!!!)
>
> Both solutions are daunting tasks.
>
> For solution 1), could you point me to the Racket's recursive descent parser 
> source code? What about the 

Re: [racket-users] hash-ref in typed Racket

[Sam Tobin-Hochstadt]

That particular pattern, with `(U String (-> String))`, will work, but
your generalized version would be wrong if it worked. Consider:

```
(: unsound : (Immutable-HashTable Symbol (-> String)) -> String)
(define (unsound h)
  ((hash-ref h (gensym) (lambda () "x"

(unsound (hash))
```

This program type checks with your second `require/typed` of
`hash-ref`, but it's wrong. We can see that by using
`unsafe-require/typed`, and we get an error because we can't apply
"x".

Furthermore, you can't generalize to (U T (-> T) either, because if T
is (-> String) then you get the same problem.

Sam

On Wed, Nov 25, 2020 at 7:28 AM Tim Jervis  wrote:
>
> For the record, this seems to work fine:
>
> #lang typed/racket
>
> (require/typed racket
>   [hash-ref ((Immutable-HashTable Symbol
>   (U (-> String)
>  String))
>  Symbol
>  (U String
> (-> String))
>  ->
>  (U String
> (-> String)))])
>
> (let* ([h : (Immutable-HashTable Symbol
>  (U (-> String)
> String))
>   (make-immutable-hash)]
>[h (hash-set h
> 'function
> (thunk "Function value"))]
>[h (hash-set h
> 'string
> "String value")])
>
>   (printf "Fixed string on error:\n")
>   (for ([key (in-list '(function string missing))])
> (printf "key: ~a\tvalue: ~a\n"
> key
> (hash-ref h
>   key
>   "Missed!")))
>   (printf "\n")
>
>   (printf "Thunk on error:\n")
>   (for ([key (in-list '(function string missing))])
> (printf "key: ~a\tvalue: ~a\n"
> key
> (hash-ref h
>   key
>   (thunk "Missed!")
>
>
>
>
> >
> Fixed string on error:
> key: function value: # key: string value: String value
> key: missing value: Missed!
>
> Thunk on error:
> key: function value: # key: string value: String value
> key: missing value: Missed!
>
>
>
>
>
>
> but this attempt to generalise fails:
>
> #lang typed/racket
>
> (require/typed racket
>   [hash-ref (All (K V)
>  (Immutable-HashTable K V)
>  K
>  V
>  ->
>  V)])
>
> (let* ([h : (Immutable-HashTable Symbol
>  (U (-> String)
> String))
>   (make-immutable-hash)]
>[h (hash-set h
> 'function
> (thunk "Function value"))]
>[h (hash-set h
> 'string
> "String value")])
>
>   (printf "Fixed string on error:\n")
>   (for ([key (in-list '(function string missing))])
> (printf "key: ~a\tvalue: ~a\n"
> key
> (hash-ref h
>   key
>   "Missed!")))
>   (printf "\n")
>
>   (printf "Thunk on error:\n")
>   (for ([key (in-list '(function string missing))])
> (printf "key: ~a\tvalue: ~a\n"
> key
> (hash-ref h
>   key
>   (thunk "Missed!")
>
>
>
> >
> ; hash/c: contract violation
> ;   expected: chaperone-contract?
> ;   given: K4
>
>
> On 24 Nov 2020, at 15:20, Tim Jervis  wrote:
>
> Wouldn’t that possibility then have to be part of the type for the values in 
> the hash? Maybe I don’t understand how types work for hashes.
>
> In this code:
>
> #lang typed/racket
>
> (define h : (Immutable-HashTable Integer (-> String))
>   (make-immutable-hash))
>
> (hash-ref h
>   2
>   (thunk "Hit and miss"))
>
>
> I think I’ve set the type of the values of the hash h to be a thunk that 
> returns a string. I’m then trying to access a key in that hash, which misses 
> because the hash has no keys. The third argument works because it’s a 
> function that happens to return a string. It’s funny because it looks like it 
> type-checks, but it doesn’t really.
>
> This code:
>
> #lang typed/racket
>
> (define h : (Immutable-HashTable Integer String)
>   (make-immutable-hash))
>
> (hash-ref h
>   2
>   (thunk "Hit and miss"))
>
>
> also type-checks because even though th

Re: [racket-users] snappier place startup time

[Sam Tobin-Hochstadt]

Here's an in-progress PR: https://github.com/racket/racket/pull/3518

With this, your simple test takes about 150ms with `racket/place` and
50ms with `racket/place/dynamic`. For comparison, just having the
submodule depend on `racket/base` gives a time of about 42 ms, and
just `racket/kernel` is about 12ms.

Sam

On Tue, Nov 24, 2020 at 2:04 PM Sam Tobin-Hochstadt
 wrote:
>
> th-place is used if places are not enabled when Racket is built (this is the 
> default on some platforms).
>
> I'm making progress on shrinking this, hopefully I'll have a patch done soon.
>
> One thing to note is that '#%place can be required directly and will have 
> almost no start-up cost.
>
> Sam
>
> Sam
>
> On Tue, Nov 24, 2020, 1:58 PM Nathaniel W Griswold  
> wrote:
>>
>> I noticed i am using the pl- functions so I replaced th-place.rkt with a 
>> stub and saw more time shaved off, this time about 15ms for each 
>> racket/place import.
>>
>> Under what circumstances is th-place used instead of '#%place and needed?
>>
>> Nate
>>
>> On Nov 24, 2020, at 12:31 PM, Nathaniel W Griswold  
>> wrote:
>>
>> I seem to remember there being some global namespace. Since every reasonable 
>> place will require racket/place, might it be possible to make the 
>> racket/place import a special case and stick it in the global space, to 
>> improve place setup time? It would be nice to be able to only set up 
>> racket/place one time instead of once for each place.
>>
>> Nate
>>
>> On Nov 24, 2020, at 12:24 PM, Nathaniel W Griswold  
>> wrote:
>>
>> Actually, it cuts about 20-25ms off of a single import. Down from 185ms to 
>> 165ms for me. 50ms off my startup time of my app on average, since i 
>> basically stack the import twice and sync on the place being ready.
>>
>> Might be worth including and seeing if there’s anything else that can be 
>> shaved off.
>>
>> Nate
>>
>> On Nov 24, 2020, at 12:09 PM, Nathaniel W Griswold  
>> wrote:
>>
>> I checked into it a bit.
>>
>> racket/fixnum, racket/flonum, and racket/vector are needed by 
>> “private/th-place.rkt”, which is required by racket/place. Not sure why 
>> DrRacket is saying that it’s not needed.
>>
>> racket/runtime-path does not appear to be needed.
>>
>> I tried removing racket/runtime-path and racket/match but didn’t see any 
>> performance gains. It appears the delay is elsewhere.
>>
>> Nate
>>
>> On Nov 24, 2020, at 9:52 AM, Robby Findler  wrote:
>>
>> DrRacket thinks that there are no references to a number of the requires in 
>> racket/place, including racket/fixnum, racket/flonum, racket/vector, and 
>> racket/runtime-path. Not sure if that's an error on DrRacket's part (and I 
>> don't see why those would be needed for their effects).
>>
>> Also, the only use of racket/match seems to be this, which seems simple to 
>> rewrite out.
>>
>> (match name
>>   [(? symbol?) `(submod (quote ,name) ,submod-name)]
>>   [(? path?) `(submod ,name ,submod-name)]
>>   [`(,p ,s ...) `(submod ,(if (symbol? p) `(quote ,p) p) ,@s 
>> ,submod-name)])
>>
>> Robby
>>
>>
>> On Tue, Nov 24, 2020 at 8:58 AM Nate Griswold  wrote:
>>>
>>> Oh, interesting. So compilation breaks the submodule out from the modules 
>>> if possible?
>>>
>>> So anyway, it sounds like breaking my modules out into separate files will 
>>> improve performance in most cases.
>>>
>>> Unfortunately, i need racket/place in the module that is my startup 
>>> bottleneck. If i modify the previous program to require racket/place and 
>>> compile, it takes around 180ms.
>>>
>>> This is about what i can expect for a module that requires racket/place, 
>>> then?
>>>
>>> Nate
>>>
>>>
>>> On Tue, Nov 24, 2020 at 8:48 AM Matthew Flatt  wrote:
>>>>
>>>> Just to elaborate a little more:
>>>>
>>>> The difference is because the `test` submodule can be loaded
>>>> independently from the compiled form. Loading the submodule from source
>>>> requires loading the enclosing module, too (which depends on
>>>> `racket/place` and more).
>>>>
>>>> At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote:
>>>> > Awesome, thanks!
>>>> >
>>>> > Nate
>>>> >
>>>> >
>>>> > On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt 
&g

Re: [racket-users] snappier place startup time

[Sam Tobin-Hochstadt]

th-place is used if places are not enabled when Racket is built (this is
the default on some platforms).

I'm making progress on shrinking this, hopefully I'll have a patch done
soon.

One thing to note is that '#%place can be required directly and will have
almost no start-up cost.

Sam

Sam

On Tue, Nov 24, 2020, 1:58 PM Nathaniel W Griswold 
wrote:

> I noticed i am using the pl- functions so I replaced th-place.rkt with a
> stub and saw more time shaved off, this time about 15ms for each
> racket/place import.
>
> Under what circumstances is th-place used instead of '#%place and needed?
>
> Nate
>
> On Nov 24, 2020, at 12:31 PM, Nathaniel W Griswold 
> wrote:
>
> I seem to remember there being some global namespace. Since every
> reasonable place will require racket/place, might it be possible to make
> the racket/place import a special case and stick it in the global space, to
> improve place setup time? It would be nice to be able to only set up
> racket/place one time instead of once for each place.
>
> Nate
>
> On Nov 24, 2020, at 12:24 PM, Nathaniel W Griswold 
> wrote:
>
> Actually, it cuts about 20-25ms off of a single import. Down from 185ms to
> 165ms for me. 50ms off my startup time of my app on average, since i
> basically stack the import twice and sync on the place being ready.
>
> Might be worth including and seeing if there’s anything else that can be
> shaved off.
>
> Nate
>
> On Nov 24, 2020, at 12:09 PM, Nathaniel W Griswold 
> wrote:
>
> I checked into it a bit.
>
> racket/fixnum, racket/flonum, and racket/vector are needed by
> “private/th-place.rkt”, which is required by racket/place. Not sure why
> DrRacket is saying that it’s not needed.
>
> racket/runtime-path does not appear to be needed.
>
> I tried removing racket/runtime-path and racket/match but didn’t see any
> performance gains. It appears the delay is elsewhere.
>
> Nate
>
> On Nov 24, 2020, at 9:52 AM, Robby Findler 
> wrote:
>
> DrRacket thinks that there are no references to a number of the requires
> in racket/place, including racket/fixnum, racket/flonum, racket/vector, and
> racket/runtime-path. Not sure if that's an error on DrRacket's part (and I
> don't see why those would be needed for their effects).
>
> Also, the only use of racket/match seems to be this, which seems simple to
> rewrite out.
>
> (match name
>   [(? symbol?) `(submod (quote ,name) ,submod-name)]
>   [(? path?) `(submod ,name ,submod-name)]
>   [`(,p ,s ...) `(submod ,(if (symbol? p) `(quote ,p) p) ,@s
> ,submod-name)])
>
> Robby
>
>
> On Tue, Nov 24, 2020 at 8:58 AM Nate Griswold 
> wrote:
>
>> Oh, interesting. So compilation breaks the submodule out from the modules
>> if possible?
>>
>> So anyway, it sounds like breaking my modules out into separate files
>> will improve performance in most cases.
>>
>> Unfortunately, i need racket/place in the module that is my startup
>> bottleneck. If i modify the previous program to require racket/place and
>> compile, it takes around 180ms.
>>
>> This is about what i can expect for a module that requires racket/place,
>> then?
>>
>> Nate
>>
>>
>> On Tue, Nov 24, 2020 at 8:48 AM Matthew Flatt  wrote:
>>
>>> Just to elaborate a little more:
>>>
>>> The difference is because the `test` submodule can be loaded
>>> independently from the compiled form. Loading the submodule from source
>>> requires loading the enclosing module, too (which depends on
>>> `racket/place` and more).
>>>
>>> At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote:
>>> > Awesome, thanks!
>>> >
>>> > Nate
>>> >
>>> >
>>> > On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt <
>>> sa...@cs.indiana.edu>
>>> > wrote:
>>> >
>>> > > Almost certainly the problem is expansion time. If I run that program
>>> > > on my machine, it takes about 200 ms. But if I compile the file to zo
>>> > > first with `raco make`, then it takes about 40 ms, basically
>>> identical
>>> > > to `racket/base`.
>>> > >
>>> > > Sam
>>> > >
>>> > > On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold <
>>> nategrisw...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > Oops, i am having some issues with not getting to the list from my
>>> other
>>> > > email address. Here is a reply i sent for the record.
>>> > >

Re: [racket-users] hash-ref in typed Racket

[Sam Tobin-Hochstadt]

Unfortunately, that doesn't work -- the values in the hash could
include functions.

Sam

On Tue, Nov 24, 2020 at 7:25 AM Tim Jervis  wrote:
>
> For the type of the third argument, rather than "any non-function", could 
> Typed Racket use the type of the values in the hash?
>
> On Tuesday, 21 April 2020 at 15:51:00 UTC+1 Sam Tobin-Hochstadt wrote:
>>
>> The problem here is with the optional third argument to `hash-ref`.
>> Typed Racket only allows `#f` or functions as the third argument.
>> Plain Racket allows any non-function value as a default, or a function
>> which is called to produce the default. Since "any non-function" is
>> not expressible in Typed Racket, it's more restricted here.
>>
>> The best option is to wrap the third argument in a thunk: `(lambda () 
>> 'other)`.
>>
>> As an aside, you probably don't want to use `cast` this extensively in
>> your program.
>>
>> Sam
>>
>> On Tue, Apr 21, 2020 at 10:35 AM Hendrik Boom  wrote:
>> >
>> > In typed Racket I define a hashtable:
>> >
>> > (: vector-to-contract (HashTable TType CContract))
>> >
>> > (define vector-to-contract
>> > (make-hash
>> > (cast '(
>> > (_bytes . bytes?)
>> > (_s8vector . s8vector?)
>> > (_u16vector . u16vector?)
>> > (_s16vector . s16vector?)
>> > (_u32vector . u32vector?)
>> > (_s32vector . s32vector?)
>> > (_u64vector . u64vector?)
>> > (_s64vector . s64vector?)
>> > (_f32vector . f32vector?)
>> > (_f64vector . f64vector?))
>> > (Listof (Pair TType CContract))
>> > )
>> > ))
>> >
>> > And then I try to look something up in it:
>> >
>> > ( hash-ref vector-to-contract (cast '_bytes TType) (cast 'other CContract))
>> >
>> > and I am informed that I cannot, it seems, look up a value of type
>> > TType in a hastable whose type indicates it looks up things of type
>> > TType:
>> >
>> > Type Checker: Polymorphic function `hash-ref' could not be applied to 
>> > arguments:
>> > Types: HashTableTop a (-> c) -> Any
>> > HashTableTop a False -> Any
>> > HashTableTop a -> Any
>> > Arguments: (HashTable TType CContract) TType CContract
>> > Expected result: AnyValues
>> > in: (hash-ref vector-to-contract (cast (quote _bytes) TType) (cast
>> > (quote other) CContract))
>> >
>> >
>> > How *does* one use hashtables in typed Racket?
>> >
>> > -- 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/racket-users/20200421143453.lauuqi3pb4fdgyhh%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/aacb7226-8a0e-4fe0-9481-c1f72143eec2n%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/CAK%3DHD%2BZZU4mNFX1XnfFXYxHjv8baaPw%3DZ%3D-ArO4tNhE%3D7VKqzQ%40mail.gmail.com.

Re: [racket-users] snappier place startup time

[Sam Tobin-Hochstadt]

Almost certainly the problem is expansion time. If I run that program
on my machine, it takes about 200 ms. But if I compile the file to zo
first with `raco make`, then it takes about 40 ms, basically identical
to `racket/base`.

Sam

On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold  wrote:
>
> Oops, i am having some issues with not getting to the list from my other 
> email address. Here is a reply i sent for the record.
>
> ---
>
> Thank you, Matthew.
>
> The following code takes around 250ms on my machine. Any idea why? I was 
> expecting it to be fast since the module is based on racket/base.
>
> #lang racket/base
>
> (require syntax/location)
> (require racket/place)
>
>
>
> (module test racket/base
>  (provide place-main)
> racket
>  (define (place-main pch)
>   (void)))
>
> (time (place-wait (dynamic-place (quote-module-path test) 'place-main)))
>
> Nate
>
>
> On Tue, Nov 24, 2020 at 8:35 AM Nathaniel W Griswold  
> wrote:
>>
>> Thank you, Matthew.
>>
>> The following code takes around 250ms on my machine. Any idea why? I was 
>> expecting it to be fast since the module is based on racket/base.
>>
>> #lang racket/base
>>
>> (require syntax/location)
>> (require racket/place)
>>
>>
>>
>> (module test racket/base
>>  (provide place-main)
>> racket
>>  (define (place-main pch)
>>   (void)))
>>
>> (time (place-wait (dynamic-place (quote-module-path test) 'place-main)))
>>
>> Nate
>>
>> On Nov 24, 2020, at 8:16 AM, Matthew Flatt  wrote:
>>
>> The bottleneck for place startup is loading modules into the new place,
>> including modules like `racket/base`.
>>
>> For example,
>>
>>  (place-wait (dynamic-place 'racket 'void))
>>
>> takes around 200ms on my machine, while
>>
>>  (place-wait (dynamic-place 'racket/base 'void))
>>
>> takes around 30ms and
>>
>>  (place-wait (dynamic-place 'racket/kernel 'void))
>>
>> takes around 10ms.
>>
>> It sounds like you're already aware that the complexity of the module
>> loaded into a place matters, though. Beyond using a minimal set of
>> modules, I don't have any way to make place startup faster.
>>
>> Matthew
>>
>> At Tue, 24 Nov 2020 05:04:19 -0600, Nate Griswold wrote:
>>
>> Is there any way to make places startup faster? Even if i do an explicit
>> round trip using place-channel-put and place-channel-get on both sides, it
>> takes on the order of centiseconds for near empty places to start up.
>>
>> My program requires the threads for a couple places to be set up before it
>> can operate, so this impacts my startup time by quite a bit.
>>
>> I have one place that has a very simple module and one place with a more
>> complicated module. Is there some sequence that i should do things in for
>> the minimal startup time? It seems nothing i do really helps much.
>>
>> Nate
>>
>> --
>> 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/CAM-xLPpvfCHHDDpfNmuTWQOyfYfEJ7v
>> m1c_dS7nj3FxaEFVm2Q%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/CAM-xLPqtJrem4j%3DUi3fbrduoahsXCNNA2JPuB0Tt9dissiu5KA%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/CAK%3DHD%2BY%2BEdpHVg8-AR4SHrLwNF2uZ6nBNpaCTwDx7NaFWpDprw%40mail.gmail.com.

Re: [racket-users] net-lib/ftp enhancement

[Sam Tobin-Hochstadt]

If you found it useful, it's probably reasonable to add it to the
library for everyone.

Sam

On Tue, Nov 17, 2020 at 12:46 PM Dominik Pantůček
 wrote:
>
> Hello Racketeers,
>
> we were working on a module today that uses the net/ftp module for batch
> communication with some remote systems and realized we REALLY could use
> variants of ftp-download-file and ftp-upload-file that would accept
> ports instead of just folders/paths.
>
> So I looked at the source and found out the code is really easy to
> extend this way and added these variants.
>
> You can see the patch in [1].
>
> Do you think that more people would benefit from this? If no, we'll just
> use a patched version of net/ftp in our project. If yes, I will update
> the scribblings as well before submitting a PR.
>
> Any thoughts?
>
>
> Cheers,
> Dominik
>
>
> [1]
> https://github.com/dzoep/racket/commit/277f857566b48037ed57b329443b591024acf43b
>
> --
> 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/a358e1ee-f78f-0148-99ac-4364f7dc6e42%40trustica.cz.

-- 
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%2BaNC0Th0XdQrWgr41uwaXc7YPO%2BFKr4r-VvZxg7MvuZig%40mail.gmail.com.

Re: [racket-users] Developing Scribble as a user when Scribble is installed system-wide

[Sam Tobin-Hochstadt]

Can you post the output of `raco pkg show -l --rx scribble`?

Sam

On Wed, Nov 4, 2020 at 8:10 PM Christopher Lemmer Webber
 wrote:
>
> I've done the following to my git repo of scribble:
>
>   raco pkg update --scope user --clone scribble-lib
>   raco pkg update --scope user --clone scribble-doc
>   raco pkg update --scope user --clone scribble
>
> I also tried removing that and doing:
>
>   raco pkg install --scope user --clone scribble-lib
>   raco pkg install --scope user --clone scribble-doc
>   raco pkg install --scope user --clone scribble
>
> Regardless, like it installed it in userspace.  Okay.
>
> But it seems like running "raco scribble" or importing scribble and
> then checking where the install paths are from, it's still seeming to
> use the system install verison of scribble.
>
> Not sure what I should do... shouldn't it be the case that user packages
> take priority?
>
>  - Chris
>
> --
> 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/87eel87goo.fsf%40dustycloud.org.

-- 
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%2BYeaU1KKwmPKVj1oSRaSqP1J0LEMO8q7O%3D2WTcS%3D9gYNA%40mail.gmail.com.

Re: [racket-users] Is there a function to find and update all compiled directories?

[Sam Tobin-Hochstadt]

On Sun, Nov 1, 2020, 9:11 PM George Neuner  wrote:

>
> On 11/1/2020 6:50 PM, Shu-Hung You wrote:
> > Using the command-line instruction `raco setup` will update all
> > obsolete bytecodes. If you are looking for a programmable interface,
> > `compiler/cm` is a good starting point.
>
> Note that "raco setup" rebuilds *only* Racket's own modules and
> installed extra packages - it does not rebuild any programmer code.
>

`raco setup` rebuilds all collections, including all installed or linked
packages. This includes "programmer code" if you make it a package or
collection, which is usually a good idea for anything long lived.

Sam

>

-- 
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%2BZQxPA3p49Pu9jnLZeRKkJmCOve%2Bie7qLfhiAVa3HC6zQ%40mail.gmail.com.

Re: [racket-users] Why ~a, ~s, and ~v?

[Sam Tobin-Hochstadt]

That page actually suggests they're inherited from Common Lisp, which
seems very likely (and probably from some other Lisp before that).

Sam

On Mon, Oct 26, 2020 at 8:59 PM Sorawee Porncharoenwase
 wrote:
>
> I had this question too. It looks like they are inherited from Scheme.
>
> ~a = any
> ~s = s-expression
>
> See http://wiki.call-cc.org/eggref/5/format#documentation.
>
> There's no ~v. IIUC, there's no `print` in Scheme.
>
> On Mon, Oct 26, 2020 at 5:50 PM primer  wrote:
>>
>>
>> I'm reading the documentation about formatted output where it says:
>> ~a or ~A displays the next argument
>> ~s or ~S writes the next argument
>> ~v or ~V prints the next argument
>>
>> I can't help thinking these would be more intuitive if they were spelled ~d, 
>> ~w, and ~p.
>>
>> Perhaps I can remember them better if someone could explain where the 
>> letters come from.  Can anyone explain?
>>
>>
>> --
>> 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/979731d3-0a48-484c-8269-f10a807fe6aan%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/CADcuegvoXQCZDCJhwZa9rfvJrfWWw6OfvMy9atpvpx2vggnJDA%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/CAK%3DHD%2BZ-bHkLApiKSKmSH_4gEDBKM-Oe6eTe2wh8Vm2%2Bc8SRZw%40mail.gmail.com.

Re: [racket-users] Automated method for making racket package installs consistent?

[Sam Tobin-Hochstadt]

The list of explicitly-installed packages is available from `raco pkg
show`. You could use a script to parse that, or you can use
`installed-pkg-table` from `pkg/lib` to get the list in Racket.

Sam

On Sun, Oct 11, 2020 at 11:03 AM primer  wrote:
>
> On Sunday, October 11, 2020 at 1:35:24 AM UTC-7 William J. Bowman wrote:
>>
>> I'm not sure what you're asking: is your question equivalent to figuring out 
>> which packages are explicitly installed?
>
>
> That's part of the problem.  I have several computers, each with racket 
> installed.  I'd like to get them on the same page in terms of the explicitly 
> installed packages, which are currently different on each machine depending 
> on what I played with at the time.
>
> So I imagine the workflow to be something like this:
> 1.  On machine A, do something that generates a list of explicitly installed 
> packages
> 2.  Do something on machine B to bring in that list of packages and 
> automatically install them, while not disturbing any explicit packages 
> already installed on B
> 3. Repeat steps 1 and 2 starting with the now updated B.  After this A and B 
> should be in sync.
>
> --
> 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/6cbeacf9-cebe-4c1a-9d49-9fe75d2eb39dn%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/CAK%3DHD%2Bbe2rfqCZdThNwdLVbsrU99NBRVKQ-eQTO7GaHrnyp9Mw%40mail.gmail.com.

Re: [racket-users] Clearer code in DrRacket?

[Sam Tobin-Hochstadt]

If you'd like to see different colors for imported identifiers, then
you can click the "Check Syntax" button in DrRacket. The attached
picture shows what it looks like.

Note that there's not a difference between `cons` and `null?` because
those are both functions.

You can adjust the particular colors chosen in the Preferences dialog,
under the Check Syntax tab.

Sam


On Fri, Oct 9, 2020 at 10:12 AM Adam El Mazouari
 wrote:
>
> An example is this:
>
> (define (square-all lst) (if (null? lst)
>
> '()
> (cons (square (car lst))
>
> (square-all (cdr lst)
>
>
> As you can see, you've got:
>
> methods included by default (define, cons)
> booleans (null?)
> user-introduced vars (lst)
>
> shown in the same color. It's really not clear. I'd like for them to be in 
> different colors.
>
> --Adam.
>
> On Fri, Oct 9, 2020 at 3:35 PM Sam Tobin-Hochstadt  
> wrote:
>>
>> Can you give an example of which things you'd like to be different? We
>> usually use "variable" and "identifier" for very similar meanings when
>> discussing Racket, for example.
>>
>> Sam
>>
>> On Fri, Oct 9, 2020 at 8:16 AM Adam El Mazouari
>>  wrote:
>> >
>> > Hello everyone.
>> >
>> > I've started using DrRacket a couple of weeks ago and I can't get used to 
>> > the color theme. Variables, identifiers, methods, all of them are in blue. 
>> > It's really unintuitive. Does anybody know a good plugin that 
>> > differentiates these in a clear way for the human eye?
>> >
>> > Or, if you know something better than DrRacket in that regard, feel free 
>> > to write down.
>> >
>> > Thanks in advance!
>> >
>> > Adam
>> >
>> > --
>> > 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/0ddf205e-c461-40d3-857b-4b5f75e60284n%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/CAK%3DHD%2BZdgni1PJDnUXEv38TD11AnyNoOeTA65wXBqc6YXK%2BesQ%40mail.gmail.com.

Re: [racket-users] Clearer code in DrRacket?

[Sam Tobin-Hochstadt]

Can you give an example of which things you'd like to be different? We
usually use "variable" and "identifier" for very similar meanings when
discussing Racket, for example.

Sam

On Fri, Oct 9, 2020 at 8:16 AM Adam El Mazouari
 wrote:
>
> Hello everyone.
>
> I've started using DrRacket a couple of weeks ago and I can't get used to the 
> color theme. Variables, identifiers, methods, all of them are in blue. It's 
> really unintuitive. Does anybody know a good plugin that differentiates these 
> in a clear way for the human eye?
>
> Or, if you know something better than DrRacket in that regard, feel free to 
> write down.
>
> Thanks in advance!
>
> Adam
>
> --
> 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/0ddf205e-c461-40d3-857b-4b5f75e60284n%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/CAK%3DHD%2BbdbpLX7Ozz8ecORr9VC-BQF3kW0izkCvjJMuia81EaMA%40mail.gmail.com.

Re: [racket-users] Utah snapshots will switch to CS by default

[Sam Tobin-Hochstadt]

How will this affect the pkg-build snapshots?

Sam

On Tue, Sep 29, 2020 at 3:33 PM Robby Findler  wrote:
>
> I'm finally catching up and switching the Northwestern snapshots to BC by 
> default. I've made the change and the changes will kick off tonight at 
> midnight, Chicago time (probably failing horribly but maybe in a week or two 
> we'll be back in business and the next paragraph will be accurate when that 
> all settles).
>
> All of the existing links should continue to work (let me know if you notice 
> that didn't happen) but they will generally be CS where they were BC builds 
> before. In particular, we're going to continue to have windows BC and CS, 64 
> and 32 bit builds; 64 bit BC and CS Mac OS builds, and 32 bit BC Mac OS 
> builds. I've added Debian 64 bit CS builds, so we'll have 64 bit BC and CS as 
> well as 32 bit BC builds for debian. For the rest, the 64 bit versions will 
> all become CS builds and the 32 bit versions will all stay BC.
>
> There will be explicit links ending with -bc and -cs as well as aliases that 
> do not include the VM specifier that go to whatever is available, as Matthew 
> describes for the Utah snapshots and "min-racket" will also change to 
> "racket-minimal" (but still with an alias to avoid breaking old links).
>
> Robby
>
>
> On Tue, Aug 11, 2020 at 5:24 PM Matthew Flatt  wrote:
>>
>> As you may know, the Racket Git repo recently switched to Racket CS as
>> the default build. That is, if you check out the repo and `make`, then
>> you get an in-place Racket CS build instead of Racket BC.
>>
>> The next step in moving toward Racket CS is to try switching the
>> snapshot builds. Out current plan is to switch the Utah build on August
>> 13. The Northwestern snapshot build will be unchanged, for now. This
>> change will have no effect on the regular, release downloads.
>>
>> The layout of the page at
>>
>>  https://www.cs.utah.edu/plt/snapshots/
>>
>> will change so that CS and BC builds are grouped together, more like
>> the Northwestern snapshot layout, but an installer that doesn't have
>> "BC" in its link will download a Racket CS installer.
>>
>> If you have an automated process that pulls from the snapshot site,
>> then it probably downloads something like
>>
>> https://www.cs.utah.edu/plt/snapshots/current/installers/racket-current-x86_64-linux-precise.sh
>>
>> As of August 13, that will download a Racket CS installer instead of a
>> BC installer, because there's no "-bc" suffix in the name.
>>
>> Racket BC builds will still be available; you'll just have to
>> specifically select a download option with "BC" in the link name or
>> "-bc" in the URL. For example,
>>
>> https://www.cs.utah.edu/plt/snapshots/current/installers/racket-current-x86_64-linux-precise-bc.sh
>>
>> will download a Racket BC installer. For now, 32-bit Windows and Mac OS
>> installers will be available only for BC, because we view those as
>> legacy platforms.
>>
>> For consistently, you'll be able to access the CS installers using a
>> "-cs" suffix. The installer name without a "-cs" or "-bc" suffix is an
>> aliases for one with "-cs". Of course, the "current" names are all
>> aliases for installers that have a specific version number.
>>
>> While we're adjusting installer names, the canonical name for Minimal
>> Racket installers will change to "racket-minimal-..." instead of
>> "min-racket-...". The new name matches the names used for releases. For
>> the foreseeable future, "min-racket-..." aliases will still work, but
>> you should migrate to "racket-minimal-..." if you have an automated
>> process that uses "min-racket-...".
>>
>>
>> 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/20200811162420.18d%40sirmail.smtps.cs.utah.edu.
>
> --
> 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/CAL3TdOOw%2BBkMj%2B-vN_mfbe%2Bt2MMuwuVtpyQDJyeOUoyjOWkHpA%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/CAK%3DHD%2Ba4P-LW%3D1%3DvnMZRtf3Cnx5eZ6hUTQqRZbGPbEc1YRmD7g%40mail.gmail.com.

Re: [racket-users] Re: Memory usage of (port->lines ...) is extreamly high

[Sam Tobin-Hochstadt]

port->lines produces a list with all the lines in it. That list is what
uses all the memory. Using in-lines avoids producing the whole list at
once.

Sam

On Thu, Sep 24, 2020, 8:53 AM Hong Yang  wrote:

> Thanks Laurent, I tried (in-lines...), and yes, it's memory-efficient, but
> I still curious and concern why (port->lines ...) takes so many memory.
>
> Best regards
> Hong
>
> On Thursday, September 24, 2020 at 6:55:10 PM UTC+8 laurent...@gmail.com
> wrote:
>
>> Quick comment: of you don't need to load the whole file but want to parse
>> it line by line, use `in-lines` which is memory-efficient.
>>
>> On Thu, Sep 24, 2020, 11:46 Hong Yang  wrote:
>>
>>> Update with memory dump log attached.
>>>
>>> 1. With out (set! input empty), call (collect-garbage) doesn't help
>>> 2. Call (set! input empty) and (collect-garbage), memory reduce
>>> dramaticly.
>>>
>>> ; 214M(VIRT)/101M(RSS) without open any file
>>> (let loop()
>>>   (sleep 5)  ; Waiting here so that I can check it via top/ps
>>>   (dump-memory-stats)
>>>   (collect-garbage)
>>>   (set! input empty)  ; Even not help with this line, it works after
>>> called (collect-garbage) explicity.
>>>   (loop))
>>>
>>> On Thursday, September 24, 2020 at 6:14:55 PM UTC+8 Hong Yang wrote:
>>>
 Hi Racketer

 I'm trying to load a log file which size is 600MB, then I found the
 program exhausted 3 GB resident memory just for load all the content of it
 via (port->lines...). I do have enough RAM but it looks like some thing
 went wrong here, and I do need to load them all into RAM for my use case so
 (read-line ...) doesn't help me.

 Any comment would be preciated.

 Here is may programe:

 #!/usr/bin/racket
 #lang racket

 ; Load input as list of lines
 (define (input-load-lines file-name)
   (if (file-exists? file-name)
   (let* ([input (open-input-file file-name)]
  [lines (port->lines input)])
 (close-input-port input)
 lines)
   empty))

 ; Racket 7.8, compile from source code, (none cs mode)
 ; 100M of log requires 0.5G runtime memory
 ; 300M of log requires 1.5G runtime memory
 ; 600M of log requires 3.0G runtime memory
 ;
 ; Reference
 ;   racket/collects/racket/port.rkt :106
 ;   racket/collects/racket/private/portlines.rkt :11

 (define input (input-load-lines "main.log"))

 ; 214M(VIRT)/101M(RSS) without open any file
 (let loop()
   (sleep 5) ; Waiting here so that I can check it via top/ps
   (set! input empty) ; event not help with this line
   (loop))

 Thanks
 Hong

>>> --
>>> 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/07c41b96-87ba-473a-ad0e-0cec71dc4024n%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/f761c588-da7e-43d4-9b05-b917f64f4b52n%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/CAK%3DHD%2Bb1-goK4tz0Yh8axfZdvwq%3DzNCFfva8zu5Sj46%3Dri6Yjw%40mail.gmail.com.

Re: [racket-users] [racket users] describe variant issue?

[Sam Tobin-Hochstadt]

We may change Racket CS so that it produces the same results, but in
general the results of `struct->vector` on values that are opaque is
not something that should be relied on.

The describe library is, I believe, unmaintained, and hasn't been
updated in many years.

Sam

On Thu, Sep 17, 2020 at 1:17 PM Kevin Forchione  wrote:
>
>
>
> > On Sep 15, 2020, at 3:11 PM, Sam Tobin-Hochstadt  
> > wrote:
> >
> > This is a difference in behavior between Racket BC and Racket CS, and
> > not something in the describe library:
> >
> > [samth@homer:~/work/teaching/c211 (master) racket-7.8] racket
> > Welcome to Racket v7.8.
> >> (struct->vector 5)
> > '#(struct:fixnum-integer ...)
> >> ^D
> > [samth@homer:~/work/teaching/c211 (master) plt] racket
> > Welcome to Racket v7.8.0.9 [cs].
> >> (struct->vector 5)
> > '#(struct:simple …)
>
>
> Is this going to be the go-forward stance for Racket? Or is this still a work 
> in progress? Will it be left up to the code to determine types through 
> predicate checking?
>
> Thanks!
>
> Kevin
>
> --
> 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/F42194F9-ADA3-4158-BCBA-3A65F2108AB4%40gmail.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%2BaiK06QrfOc2FLjTCFzvvo-cPpbSGChQ9yAnon_tp6wVw%40mail.gmail.com.

Re: [racket-users] [racket users] describe variant issue?

[Sam Tobin-Hochstadt]

This is a difference in behavior between Racket BC and Racket CS, and
not something in the describe library:

[samth@homer:~/work/teaching/c211 (master) racket-7.8] racket
Welcome to Racket v7.8.
> (struct->vector 5)
'#(struct:fixnum-integer ...)
> ^D
[samth@homer:~/work/teaching/c211 (master) plt] racket
Welcome to Racket v7.8.0.9 [cs].
> (struct->vector 5)
'#(struct:simple ...)

On Tue, Sep 15, 2020 at 5:47 PM Kevin Forchione  wrote:
>
> Hi guys,
> I’m not sure why the describe library’s variant is always returning ‘simple 
> regardless of numeric value. For instance, the docmentation says:
>
> (variant 1) -> fixnum-integer
>
> But when I run it under Dr Racket 7.8 [cs] it returns ‘simple for this, as 
> well as for 10.3  as well as pi, 2/3, and 0+1i.
>
> Any ideas why this is happening?
>
> Thanks!
>
> Kevin
>
> --
> 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/367E5C0C-FA1C-4546-A586-54135D264C6B%40gmail.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%2Bbwvpu2FGsqTwRkBVJEg9%2B6%2Bb5f1RUzXwofKDjaHsjZNw%40mail.gmail.com.

Re: [racket-users] locally linked package name doesn't match info collection name

[Sam Tobin-Hochstadt]

For that, I recommend "Open require path" in the File menu in DrRacket.

Sam

On Wed, Sep 9, 2020, 9:09 PM Shriram Krishnamurthi 
wrote:

> I'm curious why the Package Manager doesn't also show the collection name
> (or plural)? Wouldn't I need that to trace backwards? "This program in
> #lang foo is behaving oddly, I wonder what foo's source is" — find the
> collection in the PM, trace back to the package, locate the source…?
>

-- 
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%2BYGvMDEpVJjnJHztvkQM2L5Ft_CyYXvKCODSKKFsc_H5w%40mail.gmail.com.

Re: [racket-users] locally linked package name doesn't match info collection name

[Sam Tobin-Hochstadt]

This is all as expected. The package name is mystery-language-uploader, but
the collection name is mystery-language. The info.rkt entry controls the
latter but not the former [1]. If you're linking it on the command line,
you can use a command line option to specify the package name to use.

[1] This is necessary, since you need to know the package name in general
to find the info.rkt file in the first place.

Sam

On Wed, Sep 9, 2020, 9:03 AM Shriram Krishnamurthi 
wrote:

> This is almost certainly intended and/or I may have totally misunderstood
> the semantics of the info file, but this feels a bit confusing:
>
> I have a package on my filesystem in the directory
> mystery-languages-uploader. The "-uploader" part is a local name that's
> not intended for public consumption, so its info.rkt contains this:
>
> (define collection "mystery-languages")
>
> Sure enough, I am able to use the content of that directory using, e.g.,
>
> #lang mystery-languages/…
>
> However, the Package Manager only shows an entry (in the "Name" column)
> for "mystery-languages-uploader", not "mystery-languages". (The "Source"
> column shows the right folder, and the search box under "Currently
> Installed" does not show any other package of similar name.)
>
> I would have expected the collection setting to cause the Name showing in
> the Package Manager to be just "mystery-languages", which would also help
> me understand where that #lang is coming from.
>
> Shriram
>
> --
> 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/f99c0426-cb6e-478b-a794-dec114f8cef7n%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/CAK%3DHD%2Bb1%3Dwwp3w4uJbdfbqFWHt7W1DP-w-4oS06GeP6M1Wx4qA%40mail.gmail.com.

Re: [racket-users] Why is struct/contract so much faster than a guard?

[Sam Tobin-Hochstadt]

The issue is that `struct-guard/c` is slow. If you just write a
function as a guard it's faster than `struct/contract`.

Sam

On Wed, Sep 2, 2020 at 3:41 PM Christopher Lemmer Webber
 wrote:
>
> I tested the following:
>
>   (struct foo (bar baz)
> #:guard (struct-guard/c any/c list?))
>
> and:
>
>   (struct/contract foo ([bar any/c]
> [baz list?]))
>
> With the first:
>
>   test> (time
>  (for ([i 100])
>(foo 'yeah '(buddy
>   cpu time: 2601 real time: 2599 gc time: 7
>
> With the second:
>
>   test> (time
>  (for ([i 100])
>(foo 'yeah '(buddy
>   cpu time: 184 real time: 184 gc time: 13
>
> Wow, what the heck?  That's about a 10x difference.  What?!?!?
> Why would #:guard be so damn slow in comparison?  You'd think they'd be
> doing the same thing.
>
> Unfortunately I can't use #:methods with struct/contract so I'm stuck
> with the slow one if I want a contract on the struct?
>
> --
> 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/873640arw7.fsf%40dustycloud.org.

-- 
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%2BbX8B9vknFmzqsrnQDkyUmcfnDfio7-LoC1efwAuxSfqA%40mail.gmail.com.

Re: [racket-users] Can no longer interactively enter! module from the shell

[Sam Tobin-Hochstadt]

I tried a few more versions of Racket, and this broke between 6.12 and
7.0, probably due to the new expander at that time. I'm surprised that
it works on Racket CS, though.

Sam

On Mon, Aug 10, 2020 at 10:36 AM Greg Rosenblatt  wrote:
>
> Thanks, your output helped narrow down the issue.  It looks like the problem 
> is actually with the regular (non-Chez) variant.
>
>
> When running with Racket v7.8 [cs] I see the same (expected) behavior as you:
>
> > racket -ie '(enter! "example.rkt")'
> Welcome to Racket v7.8 [cs].
> loading example
> "example.rkt"> example
> 5
> "example.rkt">
>
>
> However, the regular variant of Racket v7.8 still has an issue:
>
> > racket -ie '(enter! "example.rkt")'
> Welcome to Racket v7.8.
> loading example
> > example
> ; example: undefined;
> ;  cannot reference an identifier before its definition
> ;   in module: top-level
> ; [,bt for context]
> > ,bt
> ; example: undefined;
> ;  cannot reference an identifier before its definition
> ;   in module: top-level
> ;   context...:
> ;eval-one-top
> ;/Applications/Racket v7.8/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1493:0
> ;/Applications/Racket v7.8/collects/racket/repl.rkt:11:26
>
>
> On Monday, August 10, 2020 at 11:09:09 AM UTC-4, Sam Tobin-Hochstadt wrote:
>>
>> This works for me the way you describe:
>>
>> ```
>> [samth@huor:/tmp cs-snap] r -ie '(enter! "x.rkt")'
>> Welcome to Racket v7.8.0.7 [cs].
>> loading example
>> "x.rkt"> example
>> 5
>> "x.rkt">
>> ```
>>
>> Perhaps there was a problem with 7.3 that you're running into? Can you
>> try with the 7.8 release?
>>
>> Sam
>>
>> On Sun, Aug 9, 2020 at 8:33 PM Greg Rosenblatt  wrote:
>> >
>> > Given a module defined in example.rkt:
>> > ```
>> > #lang racket/base
>> > (provide example)
>> >
>> > (displayln "loading example")
>> >
>> > (define example 5)
>> > ```
>> >
>> > I used to be able to enter example.rkt with an interactive session from 
>> > the shell like this:
>> >
>> > > racket -ie '(enter! "example.rkt")'
>> > Welcome to Racket v7.3.
>> > loading example
>> > > example
>> > ; example: undefined;
>> > ;  cannot reference an identifier before its definition
>> > ;   in module: top-level
>> > ; [,bt for context]
>> > > ,bt
>> > ; example: undefined;
>> > ;  cannot reference an identifier before its definition
>> > ;   in module: top-level
>> > ;   context...:
>> > ;eval-one-top12
>> > ;/Applications/Racket v7.3/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1477:0
>> > ;/Applications/Racket v7.3/collects/racket/repl.rkt:11:26
>> >
>> >
>> > The module still seems to be loading, but my interactive session hasn't 
>> > started in the module context.  Racket 6 used to start my interactive 
>> > session in the module context.
>> >
>> > Was this change in behavior intended?  Is there a new way to achieve what 
>> > I'm trying to do?
>> >
>> > --
>> > 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/bbaf1e21-52e8-4514-9b8c-20db6357fb40o%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/8439126f-f8b8-4a3c-89f2-5973f9932308o%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/CAK%3DHD%2BY_0tfjGxpQ%3DCHBmouo42kSwdue-VzyAKr-Kx5cZg-puQ%40mail.gmail.com.

Re: [racket-users] Can no longer interactively enter! module from the shell

[Sam Tobin-Hochstadt]

This works for me the way you describe:

```
[samth@huor:/tmp cs-snap] r -ie '(enter! "x.rkt")'
Welcome to Racket v7.8.0.7 [cs].
loading example
"x.rkt"> example
5
"x.rkt">
```

Perhaps there was a problem with 7.3 that you're running into? Can you
try with the 7.8 release?

Sam

On Sun, Aug 9, 2020 at 8:33 PM Greg Rosenblatt  wrote:
>
> Given a module defined in example.rkt:
> ```
> #lang racket/base
> (provide example)
>
> (displayln "loading example")
>
> (define example 5)
> ```
>
> I used to be able to enter example.rkt with an interactive session from the 
> shell like this:
>
> > racket -ie '(enter! "example.rkt")'
> Welcome to Racket v7.3.
> loading example
> > example
> ; example: undefined;
> ;  cannot reference an identifier before its definition
> ;   in module: top-level
> ; [,bt for context]
> > ,bt
> ; example: undefined;
> ;  cannot reference an identifier before its definition
> ;   in module: top-level
> ;   context...:
> ;eval-one-top12
> ;/Applications/Racket v7.3/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1477:0
> ;/Applications/Racket v7.3/collects/racket/repl.rkt:11:26
>
>
> The module still seems to be loading, but my interactive session hasn't 
> started in the module context.  Racket 6 used to start my interactive session 
> in the module context.
>
> Was this change in behavior intended?  Is there a new way to achieve what I'm 
> trying to do?
>
> --
> 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/bbaf1e21-52e8-4514-9b8c-20db6357fb40o%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/CAK%3DHD%2BbH482_nKrHMf2UVWhFnB_baDaC2zB3Y-_t653WuzwQHg%40mail.gmail.com.

Re: [racket-users] Proposal: GitHub Issue Triage Party

[Sam Tobin-Hochstadt]

That sounds great. I'm happy to help. I created the #triage channel on
slack, which is a good place to chat about this. I'm happy to help
people figure out issues that should be closed, or reassigned, as
you've started to do. And creating a specific time to work on this
would also be great.

A note on BC vs CS: we aim to continue providing support for Racket BC
for the foreseeable future, certainly for the next several years.

Sam


On Thu, Aug 6, 2020 at 9:29 PM jcmdln  wrote:
>
> Digging through some of the older Issues in 
> https://github.com/racket/racket/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
>  there appear to be many stale issues that may no longer be applicable or 
> have been silently resolved in commits that were not cross-linked.  I've 
> started to respond to some such issues, though due to the low barrier of 
> entry for finding tickets it seems that there would be value in having some 
> sort of formal announcement asking for users to help identify and draw 
> attention such issues. Once idea might be the inclusion of a section in 
> "Racket News" that would list some arbitrary issues to highlight, categorized 
> or simply listed.  Another might be a (virtual) meetup akin to Google Summer 
> of Code where individuals or small groups can pair up with a mentor to 
> resolve non-trivial issues, reminiscent of the "Inside Racket" seminars.
>
> As Racket moves from BC to CS, depending on what level of support can be 
> expected for BC in the relatively near future (ie pre-v8.0) it may be 
> worthwhile to entice users and contributors to donate their time toward doing 
> some belated "spring cleaning".  Consider this my (uninformed) 2 cents as a 
> Racket-curious user and hopeful contributor looking to donate some of my own 
> time.
>
> --
> 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/0b36280f-7995-4974-83a3-bf4d87fd0e9fn%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/CAK%3DHD%2BYe3uVvs9uhKobnRXCa-k595aen52UKK9ohxG1LykHu4g%40mail.gmail.com.

Re: [racket-users] Strange performance behavior

[Sam Tobin-Hochstadt]

What's happening here is that your function takes effectively 0 time,
but when you ran the first version, there was a GC pause during it
(that's why there's the "gc time: 9" there). GC pauses can happen at
any time, basically, so it's not something about what your function is
doing.

Here's a benchmark of your two functions that takes long enough to run
that it avoids some of these issues, and also runs a GC before
benchmarking: https://gist.github.com/7cb4645308d8572e2250833ef7b90b7c

On my machine, I get 40 ms for version 1, and 100 ms for version 2, as
you expected.

Sam

On Wed, Aug 5, 2020 at 11:21 AM wanp...@gmail.com  wrote:
>
> I was working on a exercism problem named Raindrops.
>
> Problem description:
> Convert a number to a string, the contents of which depend on the number's 
> factors.
>
> If the number has 3 as a factor, output 'Pling'.
> If the number has 5 as a factor, output 'Plang'.
> If the number has 7 as a factor, output 'Plong'.
> If the number does not have 3, 5, or 7 as a factor, just pass the number's 
> digits straight through.
>
> I came out with two version.
>
> ; version 1
> (define (convert n)
>   (define pling (divides? 3 n))
>   (define plang (divides? 5 n))
>   (define plong (divides? 7 n))
>   (if (or pling plang plong)
>   (string-append (if pling "Pling" "")
>  (if plang "Plang" "")
>  (if plong "Plong" ""))
>   (number->string n)))
>
> ; version 2
> (define (convert n)
>   (define table '((3 . "Pling") (5 . "Plang") (7 . "Plong")))
>   (define result (for/list ([(k v) (in-dict table)] #:when (divides? k n)) v))
>   (if (empty? result) (number->string n)
>   (string-append* result)))
>
> (require math/number-theory)
>
> I thought version 1 would be faster, but it turned out to be wrong. Running 
> with raco test got following timing information.
>
> version 1
> cpu time: 9 real time: 9 gc time: 9
> version 2
> cpu time: 0 real time: 0 gc time: 0
>
> Then I ran both version in DrRacket, both output following result.
> cpu time: 0 real time: 0 gc time: 0
>
> It's strange, isn't it?
>
> --
> 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/46592171-c357-4897-af1a-bea91c838cacn%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/CAK%3DHD%2BYN9USK2qU4WsoNhkeZtFn%2B5DfS4uNaZR0t%3DvjfZQ%2ByqQ%40mail.gmail.com.

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] Recommended workaround still the same?

[Sam Tobin-Hochstadt]

Yes, I think that's still the best approach.

Sam

On Sun, Aug 2, 2020 at 4:47 PM Nate Griswold  wrote:
>
> Hello. Ran into some problems with typed racket and define-cstruct when 
> adding typed racket layer on top of my ffi bindings.
>
> Is this (https://github.com/racket/typed-racket/issues/766) still the 
> recommended way of working around the issue?
>
> Nate
>
> --
> 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/CAM-xLPoRnfw%3DEwLQjq2Qwqhc56Mx5bZ7wyeaXWD1GWeN3mwG5w%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/CAK%3DHD%2BZf5E0XSoAMCLoccef5dtG7%3DjXEPD%2BUvLjsaLgP_M1ArQ%40mail.gmail.com.

Re: [racket-users] Re: Racket CS release plan

[Sam Tobin-Hochstadt]

Note that Matthew's point was not about bytecode, but about the machine
code in the Racket BC executable vs the machine code in the Chez kernel
plus boot files. Especially if you look pre-7.0, there is very little
bytecode in the Racket BC executable.

Sam

On Sat, Aug 1, 2020, 3:46 PM Gustavo Massaccesi  wrote:

> The human friendly version of the bytecode is explained in
> https://docs.racket-lang.org/raco/decompile.html?q=decompile#%28mod-path._compiler%2Fdecompile%29
> . The human friendly version looks similar to the expanded version of a
> program that you get with the Macro Debugger (when the macros are not
> hidden), but without the syntax scopes and with a few additional quirks.
> (Note that the bytecode production has a few additional steps after
> expansion, for example inlining, constant propagation and folding.)
>
> The disk version is more compact, but IIRC it is not documented.
>
> Gustavo
>
>
> On Sat, Aug 1, 2020 at 3:50 PM George Neuner  wrote:
>
>> Hi Matthew,
>>
>> On 8/1/2020 2:01 PM, Matthew Flatt wrote:
>> > At Sat, 01 Aug 2020 03:56:36 -0400, George Neuner wrote:
>> > > On Fri, 31 Jul 2020 20:20:05 -0700 (PDT),
>> > > "wanp...@gmail.com"
>> > >  wrote:
>> > >
>> > > >I noticed that the size of the CS version is 244% compare to BS
>> > > >version. Wondering why it became so large. Does that mean Chez
>> Scheme
>> > > >runtime/vm 100 MB larger than the original one?
>> > > >
>> > > >Racket Mac OS X
>> > > >  64-bit Intel 116.7 MB SHA1:
>> 521b5a264afcfb3f390afacc682987268f650a25
>> > > >
>> > > >Racket CS Mac OS X
>> > > >  64-bit Intel 285.8 MB SHA1:
>> 060f311fc6621c5797a62f98b743499fa4277793
>> > > >
>> > > >https://pre-release.racket-lang.org/
>> > >
>> > >
>> > > The CS version compiles to native code rather than portable bytecode,
>> > > so pretty much everything in the distribution is somewhat larger.  It
>> > > adds up quickly.
>> >
>> > That's still the best explanation I have, but I also think there must
>> > be something more to it.
>> >
>> > For example, the Chez Scheme boot files in uncompressed form add up to
>> > about 8 times the size of compiled Racket BC executable, but Chez
>> > Scheme doesn't have 8 times the functionality of the Racket BC
>> > executable (so it should have 8 times as much machine code). The
>> > machine code generated by Chez Scheme for its boot files is less
>> > compact than machine code generated by GCC or LLVM for Racket BC's
>> > implementation --- but, again, I don't think it's a factor of 8. So,
>> > I'm optimistic that I've so far overlooked something that can make a
>> > big difference.
>> >
>> > I've concentrated more on understanding the difference in the run-time
>> > memory footprints, and the difference there is not nearly so large.
>> > Racket CS now sometimes has a smaller memory footprint than Racket BC
>> > (e.g., peak memory use for a distribution build).
>> >
>> > Matthew
>>
>> I don't know details of the Racket bytecode, but I'm assuming that it is
>> a mix of simpler operations that map directly to one or a few native
>> instructions, and more complex operations that compile to (the
>> equivalent of) a small function.  Probably some of these functions can
>> be inlined, but I expect there still would be some that can't.
>>
>> To understand the difference in code size, you would need to look at the
>> lengths of bytecode instructions vs their native code equivalents, and
>> account for instances of those operations that can be inlined and for
>> calls to the functions for operations that can't.
>>
>>
>> As I said above, I don't know details of Racket bytecode, but a lot of
>> virtual machines use 8 or 16 bit opcodes and (allowing for immediate
>> operands) have average instruction lengths of 3..4 bytes. Contrast this
>> with, e.g., x86-64 code in which the average instruction is 5..6 bytes
>> [larger if many instructions require length prefixes (e.g., 32-bit ops
>> in 64-bit code)].  The difference can add up very quickly.
>>
>> George
>>
>> --
>> 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/c3324f5f-19cd-1e0f-3d83-08787474bede%40comcast.net
>> .
>>
> --
> 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/CAPaha9My_paizR3P_XWLkRshPmj4hy0m%2B%3DZ0mrjt-p9uXTdtYQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you 

Re: [racket-users] Does Racket interpreter exist?

[Sam Tobin-Hochstadt]

A few thoughts on interpreters vs compilers:

- somewhere, there has to be an interpreter -- the x86 chip in my
laptop is interpreting the x86 code that Racket generates.
- there could certainly be a more direct AST-based interpreter for
(fully-expanded) Racket. My work on Pycket involved writing such an
interpreter, for example.

The best way to distinguish compilers from interpreters is that a
compiler takes a program and produces another program, whereas an
interpreter takes a program (along with some input) and produces an
answer.

Sam

On Mon, Jul 27, 2020 at 12:35 PM zeRusski  wrote:
>
> Thank you for this fantastic reply Sam! I now think I had a very naive model 
> of "interpreter" when I asked the question. My CS degree from the nowhere 
> university has it that language interpreters walk the tree and you know 
> "execute" be it in the host language or generating native code. I feel a bit 
> stupid now. Technically you're absolutely right - there is an interpreter for 
> the bytecode (or whatever), so duh. But there are also a bunch of compilation 
> steps in between. I am now completely lost as to what constitutes a compiler 
> and what makes an interpreter. I always thought of interpreters as something 
> I encountered in PLAI. I remember reading some old paper abound "fast 
> interpreters" and all of them implemented a virtual machine they "compiled" 
> to and I was lost then - how's that not a compiler - as I am lost now.
>
> --
> 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/b183ae65-524d-4e70-9bee-ce0531bf21feo%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/CAK%3DHD%2BZ0G-iYDYAreU2qg1vC%3DDhT777%3DsE2kqT6QC0iQyD3JwQ%40mail.gmail.com.

Re: [racket-users] Does Racket interpreter exist?

[Sam Tobin-Hochstadt]

Hi,

Racket BC (the non-Chez version) does use an interpreter. The pipeline
in Racket BC is

   source code => expanded code => compiled bytecode => interpreter

or

   source code => expanded code => compiled bytecode => JIT compiler
=> machine code

You can turn off the JIT compiler with the `-j` flag, meaning that it
always uses the interpreter. There is also an interpreter for Racket
CS, but that is a little harder to control manually and less
efficient, so I'll ignore it for these purposes.

The compilation time for Racket is quite small, actually, and
typically pays for itself. The "start slow" effect that you see is
mostly 3 things, in varying proportions in different settings:

1. Time to run macro expansion.
2. Time to do IO to load the standard library (such as `racket/base`)
3. Time to execute the modules in the standard library

For example, if we look at the time to run the command `racket -l
racket/base`, which just loads `racket/base` and exits, provided that
you've fully compiled all of `racket/base`, that takes no time under
bullet 1. But it's still somewhat slow, about 70 ms on my machine.
Python, executing a single print command, is an order of magnitude
faster. That's because Python (a) loads many fewer python source files
on startup (`racket -l racket/base` looks at 234 files that are
actually there with `.rkt` in the name, Python looks at 96) and (b) I
believe the Python module loading semantics allows less work at load
time. Additionally, when Racket starts up, it executes the source of
the expander, which is stored as bytecode in the binary.

All these things add up to slower start time. For user programs, if
you time just expansion of the program (with `raco expand`) and also
compiling the program (with `raco make`) you'll see that most of the
time is expansion time. For the JIT compiler, turning it off
_increases_ startup time because JIT compilation is enough of a win
on, for example, the code in the macro expander.

To have a "start-fast" version of Racket, we would need to pursue some
of the following directions:
 1. ways of loading code using `mmap()` instead of doing IO and
parsing bytecode or compiled machine code
 2. ways to indicate that certain modules didn't need to do any real
execution, perhaps because they contain purely definitions
 3. ways to flatten all of a racket program into something that can be
compiled and loaded as a single file, avoiding IO (this accomplishes 2
as well)
 4. ways to make the macro expander substantially faster

Sam


On Sun, Jul 26, 2020 at 1:36 PM zeRusski  wrote:
>
> Hi all. I wonder if such a thing exist or even possible? Question triggered 
> by the trade off between "compile slowly now to run fast later" vs "start 
> fast". Racket like other modern(ish) Scheme derivatives appear to have 
> settled on being in the former camp. Is there anything in the language that 
> would make interpretation infeasible (semantics?) or unreasonably slow 
> (expansion?)? Chez sports an interpreter with some limitations. I think 
> Gambit ships one although I'm not sure how performant that one is. IIRC Guile 
> recently got something. What about Racket?
>
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/dd9dd201-5826-4453-8fbe-babc0c477dcdo%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/CAK%3DHD%2BYyjhB47L0YTxOCTDue%3DNscAef4MWGfHqSH7ZweRFukPg%40mail.gmail.com.

[racket-users] Re: Racket Survey 2020

[Sam Tobin-Hochstadt]

A reminder: there's one more week to take the 2020 Racket Survey.
We've had fantastic response so far, but we don't want to miss anyone.
Fill out the survey here: https://forms.gle/XeHdgv8R7o2VjBbF9

Sam

On Tue, Jun 23, 2020 at 12:22 PM Sam Tobin-Hochstadt
 wrote:
>
> We’re taking a survey! We want to better understand the Racket
> community, from people who have been contributing for decades to those
> who have just joined us, and from seasoned programmers to those just
> starting out.
>
> One of our goals is to help bring in new contributors and make it
> easier to become a part of the community.
>
> Fill out the survey here: https://forms.gle/XeHdgv8R7o2VjBbF9
>
> Completing the survey should take 10–15 minutes, and is anonymous
> (unless you decide to include your name). The survey will be open
> until July 31 and we will report on the results sometime after that.
>
> Please help us spread the word by sharing the survey link on your
> social network feeds, at conferences, around your office, and in other
> communities.
>
> If you have any questions, please let us know at sur...@racket-lang.org.
>
> Stephen De Gabrielle & Sam Tobin-Hochstadt

-- 
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%2BZvZG837q1dSuMUpZksVjqa%2Bhc_f_hisy91zioFqix_rg%40mail.gmail.com.

Re: [racket-users] Re: Combining generators and typed racket

[Sam Tobin-Hochstadt]

To implement support for this, you would mostly need to add types for
the relevant functions -- but those functions are the ones that
generators (or streams) expand to. For generators, the key ones look
to be `create-generator` and `yield`. `create-generator` is not
exported, so you'd have to add the type in
`typed-racket/base-env/base-special-env`. `yield` can be given a type
in `typed-racket/base-env/base-env`. The tricky part will be figuring
out what those types should be.

I'm happy to answer more questions about adding this.

Sam

On Wed, Jul 22, 2020 at 3:22 PM Nate Griswold  wrote:
>
> Ok, thanks for the reply.
>
> I was trying to use this function:
>
> (define (iterate f)
>   (yield (f))
>   (iterate f))
>
> But it seems the only thing i can do is have a separate (calling it 
> "-untyped.rkt") module and putting anything that requires iterate in there.
>
> Are there any papers that would be helpful in trying to address this 
> implementation-wise?
>
> Nate
>
>
> On Wed, Jul 22, 2020 at 1:56 PM Sam Tobin-Hochstadt  
> wrote:
>>
>> Currently, neither `racket/stream` nor `racket/generator` are
>> supported by Typed Racket, unfortunately.
>>
>> Sam
>>
>> On Wed, Jul 22, 2020 at 12:15 AM Nate Griswold  
>> wrote:
>> >
>> > Actually, is there any way at all to use lazy lists of things (streams or 
>> > generators) in typed racket?
>> >
>> > Nate
>> >
>> >
>> > On Tue, Jul 21, 2020 at 8:45 PM Nate Griswold  
>> > wrote:
>> >>
>> >> Do generators and typed racket work together well? It seems (yield) 
>> >> doesn't have a type and i couldn't get my module to work.
>> >>
>> >> Is there a way to make some procedure untyped in the middle of a typed 
>> >> file? Is it just best to break these things into separate files?
>> >>
>> >> Thank you
>> >>
>> >> Nate
>> >
>> > --
>> > 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/CAM-xLPo_c3LzL81Qv6bA2zzJMhQftQ46JR%3DWyZdSJjPJ9rYM5Q%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/CAK%3DHD%2BaUGsFS%2B5AdXB3ZGL759EaKqDLgehnpZ1HcTn0FNUvQ0g%40mail.gmail.com.

Re: [racket-users] Re: Combining generators and typed racket

[Sam Tobin-Hochstadt]

Currently, neither `racket/stream` nor `racket/generator` are
supported by Typed Racket, unfortunately.

Sam

On Wed, Jul 22, 2020 at 12:15 AM Nate Griswold  wrote:
>
> Actually, is there any way at all to use lazy lists of things (streams or 
> generators) in typed racket?
>
> Nate
>
>
> On Tue, Jul 21, 2020 at 8:45 PM Nate Griswold  wrote:
>>
>> Do generators and typed racket work together well? It seems (yield) doesn't 
>> have a type and i couldn't get my module to work.
>>
>> Is there a way to make some procedure untyped in the middle of a typed file? 
>> Is it just best to break these things into separate files?
>>
>> Thank you
>>
>> Nate
>
> --
> 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/CAM-xLPo_c3LzL81Qv6bA2zzJMhQftQ46JR%3DWyZdSJjPJ9rYM5Q%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/CAK%3DHD%2Ba0LPMHFsYmAws6pAvxEp32rD_vF9oNSLdWXZOJDJ-n1A%40mail.gmail.com.

Re: [racket-users] Replace pre-installed rackunit with git source

[Sam Tobin-Hochstadt]

To figure out where things are, I recommend the `raco fc` command,
which is in the `raco-find-collection` package.

Almost certainly what went wrong is that you installed the cloned
`rackunit` directory as a package. Instead, you need to install all
the individual sub-directories as packages. To fix that, first remove
the installed `rackunit` package, and then just re-install the regular
`rackunit`.

To accomplish your original goal, you should use `raco pkg update
--clone rackunit` in whatever directory you want to clone rackunit
(such as `extra-pkgs`). If that complains about `rackunit` not having
a git repository as source, then you should first do `racket pkg
update --lookup --catalog https://pkgs.racket-lang.org rackunit` to
switch from the 7.7 catalog to the pkgs.racket-lang.org one.

Sam

On Wed, Jul 22, 2020 at 9:03 AM zeRusski  wrote:
>
> Hi all. Latest commit to rackunit haven't made it into 7.7 so I attempted to 
> replace the rackunit installed as part of the distribution in 
> racket/share/pkgs by cloning the repo then:
>   cd rackunit
>   raco pkg update --force --type dir
>
>   raco pkg show
> would show the `rackunit` linked as expected, but the pre-installed looked 
> like any require would still go to share/pkgs. Not sure why. Btw is there 
> some API call to check which file was used to find a module?
>
> Tbh having read racket/build.md - section 3.2 I expected this to just work. 
> Perhaps I misunderstood it. I thought `extra-pkgs` dir wasn't anything 
> special.
>
> I then tried to remove the link, then remove the preinstalled 
> share/pkg/rackunit-*, then link from local checkout again
>   raco pkg remove --force rackunit-doc rackunit-test rackunit-typed 
> rackunit-gui etc
>   cd rackunit
>   raco pkg install
>
> Now any setup steps appear to fail complaining:
>   module path: rackunit
>   path: /Users/russki/Code/racket-cs/pkgs/racket-index/rackunit/main.rkt
>
> Is this some docs index missing rackunit deps?
>
> Is there a way to repair my racket installation and have rackunit linked from 
> source? Or should I just wipe racket and start over?
>
> --
> 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/62196fc3-d2d6-4ac4-8d70-7b38d068027do%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/CAK%3DHD%2BafqVx%2BR%3DWhtA-RqZd_Z%2ByWwuq-iPNtzJ%2B4TF4Os-ObhA%40mail.gmail.com.

Re: [racket-users] Embedded racket (cs) question

[Sam Tobin-Hochstadt]

My guess, not having looked further than your email, is that when you don't
include racket/promise, something is supplying a promise to something else
but there are two different instantiations of the promise library, causing
the force call from one not to recognize the promise from the other. Then
force just becomes the identity function, and passes through a promise to
somewhere that isn't expecting one.

Is it possible that some library you're using features promises?
Alternatively, it might be that the embedding code needs an explicit
dependency on promises.

Sam

On Mon, Jul 13, 2020, 10:18 AM Nate Griswold  wrote:

> Hello.
>
> I noticed something and was wondering what the list thinks:
>
> I am using an embedded racket Ics) and i noticed that if i embed a file
> and don't include any libraries (for a very bare bones c file) i have
> problems with a crash on a promise on any dynamic-require:
>
> build-path: contract violation
>   expected: (or/c path-string? path-for-some-system? 'up 'same)
>   given: #
>
> but if i do a (require racket/promise) in my rkt argument to --c-mods OR
> if i do a ++lib racket/promise i get no crash.
>
> So is this expected behavior? Should racket/promise always be included or
> no? And what exactly is going on under the hood here?
>
> Nate
>
> --
> 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/CAM-xLPpg_0Ef8ByjS01Y1pKEeeFMVkFk3dvGcdpRaYo3ZqDb9A%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/CAK%3DHD%2Bb2oNwt5NmekZwJdSyENH0AczxAr%3DCUz8hYBjqykBtxmw%40mail.gmail.com.

Re: [racket-users] Recommended CS replacement for make-sized-byte-string

[Sam Tobin-Hochstadt]

Copying is probably the best option -- this is discussed some in the
following readme:
https://www.github.com/racket/racket/tree/master/racket%2Fsrc%2Fcs%2FREADME.txt

Sam

On Sun, Jul 12, 2020, 12:16 PM Nate Griswold  wrote:

> Maybe i have been up too long, but what is the best replacement for
> make-sized-byte-string in Racket CS? I am using a library that still calls
> it and is failing on me.
>
> I don't mind just copying the whole thing. I could write a function to do
> it i was just thinking there would be something there already...
>
> Thanks
>
> Nate
>
> --
> 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/CAM-xLPrFbKkgR4nNb3qmzFaw%2BRReNr3z%3DiROqMof--x%3DeOjODA%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/CAK%3DHD%2Bb_6XhncCzrt9fJZdxYayPQnAOaVXMoLkR9C3NWRQGODw%40mail.gmail.com.

Re: [racket-users] Gtk initialization failed for display ":0"

[Sam Tobin-Hochstadt]

The usual solution to this problem is to use xvfb to create a virtual
display, which works great in this situation when the display is not really
needed anyway. This is how we run the handin server headless and how all
the racket CI works.

Sam

On Sat, Jul 11, 2020, 12:26 PM Shriram Krishnamurthi 
wrote:

> I'm running headless Racket from a Docker container for auto-grading
> assignments in Gradescope.
>
> The students are writing BSL programs with 2htdp/image. This does not
> cause any problems for most of them.
>
> Two students, however, get an error in file loading with the error message
> in the subject line («Gtk initialization failed for display ":0"»).
>
> I finally localized the problem: it's because they are using the universe
> Teachpack.
>
> I don't know what in universe is causing this, but it seems rather weird
> that *image*, which is fundamentally graphical, does not cause this
> problem but *universe*, which is it fundamentally not, does.
>
> Furthermore, this dependency means that any program that depends on
> universe would likely not be able to be auto-graded (at least in a
> Gradescope-like headless context), which seems a rather severe restriction.
> (And ironic, given that the design of universe is to enable testing, and
> hence also auto-grading.) I don't know how Northeastern does auto-grading
> of universe that gets around this, but it's clearly in a different setting.
>
> I don't have a "question" because I seem to have identified the base issue
> here. This is mostly here for future reference, since I saw some posts from
> looking for that string that didn't answer my need (but were still useful
> in indicating it might be a dependency), so I'm leaving this here for a
> future person who might be searching.
>
> However, it would also be nice if the universe Teachpack could avoid this
> dependency entirely or refactor it into parts that do and don't need it.
>
> Shriram
>
> --
> 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/7e2da814-25e5-4547-b5d9-2c66c087f37eo%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/CAK%3DHD%2Bbac1M7NcL3RtGFdrC8G%2BsadT-J3mjXiWPe%3Do8t6pXDOQ%40mail.gmail.com.

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

[Sam Tobin-Hochstadt]

It turns out it was a brief error by gitlab.

Sam

On Tue, Jul 7, 2020 at 11:42 AM Simon Schlee  wrote:
>
> yes it works again!
>
> --
> 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/0673a1d4-5cf0-4969-97b6-9bb1dbb3c298o%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/CAK%3DHD%2Bae9%3DppHJBUFavH2TPLg639-q9nCMbFcz3mEx5aZt2rdQ%40mail.gmail.com.

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

[Sam Tobin-Hochstadt]

Ah, it is now no longer working for me (it worked earlier this morning).

Sam

On Tue, Jul 7, 2020 at 11:03 AM Simon Schlee  wrote:
>
>
>> I think you probably went to www.racket-news.com, but you should go to
>> racket-news.com (without the www) instead.
>
>
> With or without www I get a certificate error, when I ignore the certificate 
> I get a 502 from gitlab.
> With different browsers and curl all give me the same responses.
> Does racket-news.com work for you? If so what could I check on my end?
>
> (I don't know how reliable this site is but) this also claims that 
> racket-news.com is down
> https://downforeveryoneorjustme.com/racket-news.com
>
> I think the site is hosted via gitlab and something there stopped working.
>
> --
> 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/b1ba1196-027e-4c00-8459-dcb6fc9a6480o%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/CAK%3DHD%2BaDyJ7YxJq_A5D3YLzZP6Zk6th%2B-DERg2pF_Dws9KB2iQ%40mail.gmail.com.

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

[Sam Tobin-Hochstadt]

I think you probably went to www.racket-news.com, but you should go to
racket-news.com (without the www) instead.

Sam

On Tue, Jul 7, 2020 at 10:28 AM Simon Schlee  wrote:
>
> I am getting an error message for the https certificate:
>
>> Websites prove their identity via certificates. Firefox does not trust this 
>> site because it uses a certificate that is not valid for racket-news.com. 
>> The certificate is only valid for the following names: *.gitlab.io, gitlab.io
>
>
>
>
> --
> 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/63e57ecc-63af-44fd-8730-5715b38f4097o%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/CAK%3DHD%2BaUZoe1eENJ4Z3vAf0fg3U7UiLUJZ0oXv5K%2BOGB-FzG4Q%40mail.gmail.com.

Re: [racket-users] FYI, build from HEAD fails in realloc()

[Sam Tobin-Hochstadt]

It should be fine to do both of those in the same directory.

Sam

On Tue, Jun 30, 2020 at 4:47 PM 'John Clements' via Racket Users
 wrote:
>
> D’oh!  Closing the loop on this one… it appears to me that this problem 
> occurred after running a “make” (that is, a BC make) in a directory in which 
> I’d been running “make cs”). I just did it again, which is how I figured it 
> out. It’s a silly mistake on my part. It seems that running “math.scrbl” 
> triggers the problem. Honestly, I have no idea if this is a bug or not.
>
> John
>
> > On Mar 23, 2020, at 04:34, Paulo Matos  wrote:
> >
> > Hi John,
> >
> > Has anyone already looked into this? I haven't seen this problem yet. If
> > it's not solved, can you please open an issue?
> >
> > Thanks,
> >
> > Paulo Matos
> >
> > 'John Clements' via Racket Users writes:
> >
> >> Bang! I was wrong. Here’s another similar trace:
> >>
> >> raco setup: 6 running: 
> >> /pfds/pfds/scribblings/functional-data-structures.scrbl
> >> raco setup: 4 running: /jbc-utils/gradeserver/gradeserver.scrbl
> >> raco setup: 3 running: 
> >> /htdp-doc/scribblings/htdp-langs/htdp-langs.scrbl
> >> raco setup: 2 running: /images-doc/images/scribblings/images.scrbl
> >> raco setup: 0 running: 
> >> /macro-debugger/macro-debugger/macro-debugger.scrbl
> >> raco setup: 7 running: /math-doc/math/scribblings/math.scrbl
> >> raco setup: 5 running: /net-doc/net/scribblings/net.scrbl
> >> raco setup: 1 running: 
> >> /compatibility-doc/mzlib/scribblings/mzlib.scrbl
> >> raco setup: 4 running: /racket-doc/openssl/openssl.scrbl
> >> raco setup: 4 running: 
> >> /optimization-coach/optimization-coach/scribblings/optimization-coach.scrbl
> >> raco setup: 4 running: 
> >> /option-contract-doc/scribblings/option-contract.scrbl
> >> raco setup: 4 running: /net-doc/net/scribblings/osx-ssl.scrbl
> >> raco setup: 5 running: /overeasy/overeasy.scrbl
> >> raco setup: 4 running: /parsack/parsack/parsack.scrbl
> >> raco setup: 1 running: 
> >> /parser-tools-doc/parser-tools/parser-tools.scrbl
> >> raco setup: 5 running: /pict-doc/pict/scribblings/pict.scrbl
> >> raco setup: 1 running: 
> >> /pict-snip-doc/scribblings/pict-snip/pict-snip.scrbl
> >> raco setup: 4 running: 
> >> /picturing-programs/picturing-programs/picturing-programs.scrbl
> >> raco setup: 1 running: /racket-doc/pkg/scribblings/pkg.scrbl
> >> raco setup: 4 running: /plai-doc/scribblings/plai.scrbl
> >> raco setup: 1 running: /planet-doc/planet/planet.scrbl
> >> raco setup: 4 running: /plot-doc/plot/scribblings/plot.scrbl
> >> racket(54631,0x762f) malloc: *** error for object 0x12f96cdc8: 
> >> pointer being realloc'd was not allocated
> >> racket(54631,0x762f) malloc: *** set a breakpoint in 
> >> malloc_error_break to debug
> >> make[2]: *** [in-place-setup] Abort trap: 6
> >> make[1]: *** [plain-in-place] Error 2
> >> make: *** [in-place] Error 2
> >> make  240.77s user 75.70s system 398% cpu 1:19.32 total
> >>
> >>
> >>> On Mar 20, 2020, at 3:11 PM, 'John Clements' via Racket Users 
> >>>  wrote:
> >>>
> >>> Here’s the tail of a build of racket HEAD that just failed during a call 
> >>> to realloc(). I went back far enough to be sure I had a full record of 
> >>> what was running on cores 0-7.
> >>>
> >>> I strongly suspect this is not reproducible, and I don’t think there’s 
> >>> any further information that would be useful here, alas.
> >>>
> >>> John
> >>>
> >>> raco setup: 1 running: 
> >>> /pfds/pfds/scribblings/functional-data-structures.scrbl
> >>> raco setup: 0 running: 
> >>> /future-visualizer/future-visualizer/scribblings/future-visualizer.scrbl
> >>> raco setup: 4 running: /games/scribblings/games.scrbl
> >>> raco setup: 6 running: 
> >>> /racket-doc/scribblings/getting-started/getting-started.scrbl
> >>> raco setup: 6 running: /games/gl-board-game/gl-board-game.scrbl
> >>> raco setup: 0 running: /GLPK/glpk/glpk.scrbl
> >>> raco setup: 5 running: /jbc-utils/gradeserver/gradeserver.scrbl
> >>> read-compiled-linklet: version mismatch  expected: "7.6.0.17"  found: 
> >>> "7.6"  in: 
> >>> /Users/clements/git-clements/pkgs/jbc-utils/gradeserver/compiled/gradeserver_scrbl.zo
> >>> context...:
> >>>  read-linklet-or-directory
> >>>  read-dispatch
> >>>  read-syntax
> >>>  default-load-handler
> >>>  standard-module-name-resolver
> >>>  module-path-index-resolve
> >>>  module-declared?
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1529:27
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:904:0: 
> >>> load-doc/ensure-prefix
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1162:13
> >>>  .../parallel-do.rkt:388:17
> >>>  
> >>> /Users/clements/racket/racket/collects/setup/../racket/private/more-scheme.rkt:261:28
> >>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:441:20: loop
> >>>
> >>> context...:
> >>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:332:4: 
> >>> work-done method in list-queue%
> >>>  

Re: [racket-users] racket-dev problem?

[Sam Tobin-Hochstadt]

There are no currently-pending messages for the racket-dev list, so
your email has not been caught in a spam filter. I have not seen
problems with the list recently.

Can you say more about what has happened?

Sam

On Fri, Jun 26, 2020 at 1:15 PM Jos Koot  wrote:
>
> Sending mail to racket -dev seems not to arrive correctly.
>
> Sending to other addresses does work.
>
> Therefore I try to report via racket-users.
>
> Jos
>
>
>
> --
> 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/94D32D8C-D5A0-4B85-A326-CC3BCABED799%40hxcore.ol.

-- 
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%2BbT_rjJZfd211bkrVSi9CRb4V5w8VGtnK4jrtbO9jt7dQ%40mail.gmail.com.

Re: [racket-users] trying to use futures for some calculations

[Sam Tobin-Hochstadt]

I tried this out, by adding 1.0 as the third argument in `in-range` in
all cases. The performance in Racket BC increased, but there's still
no parallelism. In Racket CS, it appears to have made things slower,
so I need to investigate more.

Sam

On Wed, Jun 17, 2020 at 10:36 AM Matthew Flatt  wrote:
>
> At Wed, 17 Jun 2020 10:24:37 -0400, Sam Tobin-Hochstadt wrote:
> > - on Racket BC, operations like `+` do indeed block
>
> ... which mixing, say, fixnum and flonum arguments, but not when
> operating on all fixnums or all flonums.
>
> In this case, it may be the `in-range` with flonum bounds that results
> in `+` with fixnum 1 and a flonum.
>

-- 
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%2BYoCf8O2aO90peZSSVFYybehgKg-iLqgtQcZBA0DU3WWw%40mail.gmail.com.

Re: [racket-users] trying to use futures for some calculations

[Sam Tobin-Hochstadt]

I have not yet done much investigating on this, but:

- on Racket BC, operations like `+` do indeed block, and effectively
you need to replace them with lower-level operations that don't (such
as `unsafe-fl+`). Typed Racket can help with this, or you can do it
all by hand. As you note, that makes the code more painful to read.
- on Racket CS, operations like `+` do not block, and I see much
better speedup. I changed the third range to 720-800 to get answers
quicker, and I got numbers like:

[samth@homer:/tmp/cp3-exeriments (master) plt] racketcs main.rkt
cp3-baseline:
cpu time: 1947 real time: 1947 gc time: 10
cp3-precomputed:
cpu time: 399 real time: 399 gc time: 4
cp3-precomputed-more:
cpu time: 475 real time: 475 gc time: 3
cp3-futures:
cpu time: 4285 real time: 740 gc time: 11
cp3-precomputed-futures:
cpu time: 785 real time: 138 gc time: 3
cp3-precomputed-more-futures:
cpu time: 876 real time: 153 gc time: 4

So a more than 2x increase in cpu time, but a more than 2x decrease in
wall-clock time.

Certainly more investigation is needed to figure out why things take
so much longer total, but this seems like a promising speedup.

- The futures-visualizer uses logging and a functional graphics
library, both of which will allocate a lot more. You can use
`trace-futures` and `show-visualizer` to separate out the gui display
from execution, which might help.

Sam

On Wed, Jun 17, 2020 at 4:50 AM Alex Harsanyi  wrote:
>
>
> I am trying to speed up an algorithm using futures, but I am getting some 
> unexpected results (and no real speed improvements), and I was wondering if 
> someone more experienced could have a look a the code and tell me what am I 
> doing wrong.
>
> I put up the code in this repository: 
> https://github.com/alex-hhh/cp3-exeriments, unfortunately it is the simplest 
> meaningful example that I can come up with.  Most of the functions, however 
> are just support functions and there are six implementation of the same 
> algorithm.
>
> Basically, the problem I am trying to solve is to fit a model to existing 
> data and this is done by evaluating 2.5 million combinations of parameters.  
> My best, non-futures based, algorithm can do this in about 3 seconds (8 
> seconds in DrRacket).
>
> Given that each of this 2.5 million combination is completely independent 
> from the others, they could all be done in parallel.  Given this, I "sliced" 
> the combinations into 30 groups and tried to perform each "slice" in its own 
> future and select the best among the 30 results produced by these futures.
>
> Unfortunately, while the futures versions of the algorithm produce the 
> correct result, the algorithm runs at the same speed as the non-futures 
> version.  My `processor-count` returns 8, so I would expect at least some 
> level of parallelism.
>
> As a first step, I tried using `would-be-future`, to see if it reported any 
> operations which might block, but nothing was printed out.
>
> I also tried using the futures visualized, and I found the following:
>
> * the code appears to be blocking on primitive operations, such as +, -, < 
> etc.
> * I suspect these operations are inside the code generated by the `for` 
> loops, so I am not sure how to remove them without making the code even more 
> difficult to read.
> * there seems to be a lot more time spent in the garbage collector when 
> running the futures visualizer than without it (DrRacket runs with unlimited 
> memory)
>
> So I am wondering if someone who is more familiar with futures can look at 
> the code and provide some hints about what can be done to make this code run 
> in parallel (or if it cannot, I would like to understand why).
>
> This is already a long message, so I will not add further details here, but 
> the repository at https://github.com/alex-hhh/cp3-exeriments has an 
> explanation of what every function does, and I am happy to provide further 
> clarifications if needed.
>
> Thanks,
> 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/8bf6f7c4-3b2f-4b86-9a8a-be68e82d09cfo%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/CAK%3DHD%2BaKpxBhaRs64yfmats3j_V5kF7KTe3Mb4OsgUpaDvk_WQ%40mail.gmail.com.