Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
Both racket-users and racket-dev have just now been changed to "Anyone can ask." On 1/12/22 1:17 PM, Sam Tobin-Hochstadt wrote: > 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, th
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
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. 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 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
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
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. >>>>>> > >>>>>> > 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
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
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. >>>> > >>>> > 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 >
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
Someone else wanted to chime in here. This email is just to make the thread easier for them to find. On 12/19/21 8:35 PM, Sorawee Porncharoenwase wrote: > FWIW, here're the settings of racket-users from the About tab: > > Anyone on the web: can see group > > Group owners and managers: can view members > > Anyone on the web: can view conversations > > Group members: can post > > Invited users: can join group > > and here're the settings of racket-dev: > > Anyone on the web: can see group > > Group members: can view members > > Anyone on the web: can view conversations > > Group members: can post > > Anyone on the web: can join group > > It looks like racket-users might need to change "Group owners and managers: > can view members" to "Group members: can view members", and racket-dev might > need to change "Anyone on the web: can join group" to "Invited users: can > join group". > > On Sun, Dec 19, 2021 at 5:25 PM Nadeem Abdul Hamid wrote: > >> In other Google groups that I'm on, when I view the group, the links in the >> left bar read "Conversations", "Members", "About", "My membership settings". >> But in the Racket Users, there isn't a link to the "Members" list. >> >> On Sun, Dec 19, 2021 at 5:24 PM Sage Gerard wrote: >> >>> Looks like I scoped invitation powers to group managers, not members. >>> Checking on this. >>> >>> Sent from ProtonMail mobile >>> >>> Original Message >>> On Dec 19, 2021, 4:17 PM, Nadeem Abdul Hamid < nad...@acm.org> wrote: >>> >>>> I don't have any special privileges... when I view the Google group, I >>>> don't see a "Members" page at all and no where to invite anyone else. All >>>> I can access is a link "My membership settings". >>>> >>>> --- nadeem >>>> >>>> On Sun, Dec 19, 2021 at 3:49 PM Robby Findler >>>> wrote: >>>> >>>>> When I follow the link at the bottom of one of these messages, click on >>>>> members, I see an "add members" button and clicking on it gives me a >>>>> place to add email addresses. I didn't actually add email addresses to >>>>> the list and try to add them, and I might have already had special >>>>> privileges on this list so that might not have been the most useful test. >>>>> >>>>> Robby >>>>> >>>>> On Sun, Dec 19, 2021 at 11:32 AM 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! >>>>>>>>> >>>>>>>>>
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
Looks like I scoped invitation powers to group managers, not members. Checking on this. Sent from ProtonMail mobile Original Message On Dec 19, 2021, 4:17 PM, Nadeem Abdul Hamid wrote: > I don't have any special privileges... when I view the Google group, I don't > see a "Members" page at all and no where to invite anyone else. All I can > access is a link "My membership settings". > > --- nadeem > > On Sun, Dec 19, 2021 at 3:49 PM Robby Findler > wrote: > >> When I follow the link at the bottom of one of these messages, click on >> members, I see an "add members" button and clicking on it gives me a place >> to add email addresses. I didn't actually add email addresses to the list >> and try to add them, and I might have already had special privileges on this >> list so that might not have been the most useful test. >> >> Robby >> >> On Sun, Dec 19, 2021 at 11:32 AM 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 t
Re: [racket-users] Core Team: I need you decide what I should do about the spammer.
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](mailto:racket-users%2bunsubscr...@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](http://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](mailto:racket-users%2bunsubscr...@googlegroups.com). >>> To view this discussion on the web visit >>> https://groups.goo
Re: [racket-users] Surprising but convenient
If I understand this correctly, there's a difference between deleting a reference to 50 GB (like an inode), and actually writing 50 GB. When you write to an output port, you are writing to a buffer in memory. This prevents the slow downs you've witnessed, because storage mediums are comparably slow. "Flushing" with (flush-output) or plumbers on port closure actually sends bytes outside of the process. I wouldn't try using the same port after deleting a file. If Racket and the operating system initially agreed on a file descriptor that is now invalid, then you'll need to address that by opening a new port. Note that I don't Racket's implementation details here. I'm recalling what I've seen happen across languages. On 12/19/21 11:50 AM, Jacob Jozef wrote: > Hi > > I start a thread printing a file. When the file will be very long (say 50 GB) > the thread takes too much time and I kill it when it takes more time than I > want to permit. Outside the thread I clean up. Closing the output-port before > deleting the file takes much time. But to my surprise I can delete the file > before closing the port, which hardly takes time. > > Nice. > > Is this intended behaviour? > > After deleting the file, the port remains open, but writing to it does > nothing. Correct? > > Thanks, 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/EEC04679-E526-4215-B4DE-502B5B10567A%40hxcore.ol](https://groups.google.com/d/msgid/racket-users/EEC04679-E526-4215-B4DE-502B5B10567A%40hxcore.ol?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/076c95f8-1d49-4294-9df8-73b1b39b1f01%40sagegerard.com.
[racket-users] Core Team: I need you decide what I should do about the spammer.
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-2ed372bce8fe%40sagegerard.com.
Re: [racket-users] Possible options for stopping spam
> Wouldn't people asking to be invited be pretty much the same moderation > burden as option 3, but with less support? I guess that's a way of saying I > lean to option 3. I see what you mean. I saw "invite-only" as the option with the most discretionary effort when volunteers are scarce, since a trusted member of this community can add a member with a presumably lower risk of introducing a spammer. Since I'm not going to be available to ban spammers forever, I'm reading these options in terms of minimizing the reasons someone has to drop what they are doing to mess with the list. On 12/14/21 3:53 PM, David Bremner wrote: > Sage Gerard > [](mailto:s...@sagegerard.com) > writes: > >> All, >> >> I've gained administrative privileges over this list to address the spammer. >> I want to hear from others before I touch anything. > > Thanks for putting effort into this. > >> I've been informed that an invite-only approach might not be appropriate, >> but without moderation, the only option I see is to change the privacy >> settings. Here are the choices Google gives us. >> >> - Invited users only >> - Anyone on the web can join >> - Anyone on the web can ask > > Wouldn't people asking to be invited be pretty much the same moderation > burden as option 3, but with less support? I guess that's a way of > saying I lean to option 3. > >> Comments welcome, but note that I do not know the chain of command. If >> it comes down to my judgement, please let me know. > > Pretty sure I'm not in any relevant chain of command. > > d > > -- > 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/87r1aex5zu.fsf%40tethera.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/fe8b2934-a9cd-2d55-2770-9f9fa03c6fb1%40sagegerard.com.
[racket-users] Re: Possible options for stopping spam
Correction: "Invited users only" does have a moderation requirement, but I expect it is not the kind that requires daily interruption. On 12/14/21 1:28 PM, Sage Gerard wrote: > All, > > I've gained administrative privileges over this list to address the spammer. > I want to hear from others before I touch anything. > > The spams continues because moderation is outright disabled for the list. Our > other choices are to apply moderation to non-group members only, or everybody. > > I cannot select the former because it does nothing for us; the list is > configured to allow anyone to join the group. I cannot easily select the > latter because it means accepting moderation overhead, when the community is > already moving to Discourse. > > I've been informed that an invite-only approach might not be appropriate, but > without moderation, the only option I see is to change the privacy settings. > Here are the choices Google gives us. > > - Invited users only > - Anyone on the web can join > - Anyone on the web can ask > > I lean toward "Invited users only" because it's the only option that does not > carry a moderation requirement, which seems prudent given the state of the > community. Assuming that I can give vetted, participating members power to > invite, a path to revival for the mailing list exists without burdening the > Discourse migration. > > Comments welcome, but note that I do not know the chain of command. If it > comes down to my judgement, please let me know. > > Thanks, > ~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/78c6a5e1-65dd-12c0-ace8-c7720e6894f4%40sagegerard.com.
[racket-users] Possible options for stopping spam
All, I've gained administrative privileges over this list to address the spammer. I want to hear from others before I touch anything. The spams continues because moderation is outright disabled for the list. Our other choices are to apply moderation to non-group members only, or everybody. I cannot select the former because it does nothing for us; the list is configured to allow anyone to join the group. I cannot easily select the latter because it means accepting moderation overhead, when the community is already moving to Discourse. I've been informed that an invite-only approach might not be appropriate, but without moderation, the only option I see is to change the privacy settings. Here are the choices Google gives us. - Invited users only - Anyone on the web can join - Anyone on the web can ask I lean toward "Invited users only" because it's the only option that does not carry a moderation requirement, which seems prudent given the state of the community. Assuming that I can give vetted, participating members power to invite, a path to revival for the mailing list exists without burdening the Discourse migration. Comments welcome, but note that I do not know the chain of command. If it comes down to my judgement, please let me know. Thanks, ~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/47831378-fd0c-9d97-47c3-578670005c3e%40sagegerard.com.
Re: [racket-users] Looking for system admin help for the package system
Can assist, but am biased to my own tools and designs. Is there a way to volunteer from that angle? Sent from ProtonMail mobile Original Message On Dec 7, 2021, 4:43 PM, Jacob Jozef wrote: > Hi > > I have no experience with system admin, web servers, the Racket web server, > > AWS, Docker, but may be there are simple things I can do, for example adjust > documentation. > > Jos > > From: [Sam Tobin-Hochstadt](mailto:sa...@indiana.edu) > Sent: martes, 7 de diciembre de 2021 21:31 > To: [Racket Users](mailto:racket-users@googlegroups.com) > Subject: [racket-users] Looking for system admin help for the package system > > 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. > > -- > 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/D5B5F133-B46C-4A5B-9FA5-B3DE18D78A5D%40hxcore.ol](https://groups.google.com/d/msgid/racket-users/D5B5F133-B46C-4A5B-9FA5-B3DE18D78A5D%40hxcore.ol?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/m8fWpfReQVNBRmddVBhznp1c6YoyFwOgB4-gQDXX0316vk_iSKVbgBAB4LeiSwIhXeCis9oxyAaFfK-m3NUEf6Mc5--3LlIPv6P6OMZpY6U%3D%40sagegerard.com.
[racket-users] Regarding the spammer
The spammer's messages unfailingly contain a swastika character for those looking for a simple filter. Beyond that, I volunteer to help ban this account at the list level if someone is willing to trust me with the related access. -- 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/f747fb03-c59c-8c39-123b-db8c5d1f806f%40sagegerard.com.
Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket
Mozilla's notes on their own instance summarizes an email-exclusive workflow well. https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279 On 11/22/21 12:16 PM, 'John Clements' via Racket Users wrote: > Yes, I believe that replies by email are currently enabled. Here, let me test > that. > > … > > Oh, yeah… can’t do that, the incoming email address isn’t the one that I send > from. Sigh. Perhaps someone else can try this? > > One thing that I know isn’t set up yet is starting a new topic by email. I > know it’s possible, but somebody needs to read the docs and check what’s > required in order to set it up. > > John > >> On Nov 22, 2021, at 11:56, Sage Gerard wrote: >> >> Y'all are configuring Discourse to allow replies by emails too, right? >> >> On 11/22/21 11:00 AM, J. Ryan Stinnett wrote: >>> On Mon, 22 Nov 2021 at 15:25, Martin Weigele wrote: >>> A discourse type forum - we had this discussions in other contexts again and >>> again - may be a better choice for persons who have the luxury they can >>> concentrate on very few thingies. For all others, mailinglists are a much >>> better choice, you can follow many developments in one place: your mail >>> client, with a completely standard UI. >>> >>> Discourse has a mailing list mode each user can choose to enable which >>> allows them to receive every post to their mail client, so you can continue >>> to use your mail client workflow for following messages over there as well. >>> >>> - Ryan >>> -- >>> 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/CA%2B952WrzFB-FVWzn0%3DmES3kLd5XsU6gXqG8Vi8gij7Fz0J_Qgw%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/37a16e37-a38f-906f-3f7a-4c008e5a0a76%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/df2d0a47-804e-4275-a4b3-dbfd2116a702%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/afb88687-458a-2516-9f1e-2fef2dfa39d7%40sagegerard.com.
Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket
Y'all are configuring Discourse to allow replies by emails too, right? On 11/22/21 11:00 AM, J. Ryan Stinnett wrote: > On Mon, 22 Nov 2021 at 15:25, Martin Weigele wrote: > >> A discourse type forum - we had this discussions in other contexts again and >> again - may be a better choice for persons who have the luxury they can >> concentrate on very few thingies. For all others, mailinglists are a much >> better choice, you can follow many developments in one place: your mail >> client, with a completely standard UI. > > Discourse has a mailing list mode each user can choose to enable which allows > them to receive every post to their mail client, so you can continue to use > your mail client workflow for following messages over there as well. > > - Ryan > -- > 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/CA%2B952WrzFB-FVWzn0%3DmES3kLd5XsU6gXqG8Vi8gij7Fz0J_Qgw%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CA%2B952WrzFB-FVWzn0%3DmES3kLd5XsU6gXqG8Vi8gij7Fz0J_Qgw%40mail.gmail.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/37a16e37-a38f-906f-3f7a-4c008e5a0a76%40sagegerard.com.
Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket
To add, since I forgot about the spammer: By "leaving the list to die inactive," I am assuming that the list would not be co-opted and would still function just fine as an archive. But I would love to keep the option, even if I only have a small few people to talk to. On 11/22/21 11:40 AM, Sage Gerard wrote: > Since I missed the hallway I'll settle with a belated comment. > > Over my lifetime I have accumulated hundreds of accounts. Breaches led to > incessant spamming. Thankfully I've kept my passwords varied and strong, so > the damage hasn't terrible to contain. I tried to delete accounts to manage > my risk, only to learn just how hard it is to do that as a U.S. citizen. In > the case of Google, I already had a Google account so I didn't figure the > mailing list would worsen my situation much. > > Point is, I do due diligence now. Adding an account means another legal > agreement, another privacy policy, another social structure, and another > increase in my personal attack surface. I know maintaining a mailing list is > a PITA regardless of its usefulness, so I totally understand moving to > Discourse. I just don't understand this habit of "we're doing this, we want > you to do it too" with sunsetting overtones. 1) it sounds like I'm doing > someone a favor, and 2) this sounds like when someone first said "Racket2", > and I should probably get the fuck outta here before someone throws something. > > I know I'm being dramatic, but please consider just leaving the list to die > inactive if that is to be its fate. The messaging I'm seeing keeps messing > with the community messaging about backwards compatibility, and it's super > confusing. > > On 11/22/21 10:24 AM, Martin Weigele wrote: > >> Am Montag, 22. November 2021, 16:16:35 CET schrieb Jens Axel Søgaard: >> >>> There are no plans of closing the mailing list. >>> >>> Things take time. >>> >>> Different forums for communication have different strengths. >> >> Exactly >> >>> Discourse might attract an audience that is unfamiliar to mailing lists. >>> There is no need to rush things however. >>> In due course maybe the number of users on the forum will >>> grow to outshadow the number of participants on the mailing list, >>> but it will take some years. >> >> A discourse type forum - we had this discussions in other contexts again and >> again - may be a better choice for persons who have the luxury they can >> concentrate on very few thingies. For all others, mailinglists are a much >> better choice, you can follow many developments in one place: your mail >> client, with a completely standard UI. >> >> Cheers >> Martin >> >> -- >> 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/2080281.KiezcSG77Q%40castor >> . > > -- > 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/b9684624-d477-ddf1-d434-b34aa9cc89e9%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/b9684624-d477-ddf1-d434-b34aa9cc89e9%40sagegerard.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/e3661078-68de-2e59-8485-ff7b8be47722%40sagegerard.com.
Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket
Since I missed the hallway I'll settle with a belated comment. Over my lifetime I have accumulated hundreds of accounts. Breaches led to incessant spamming. Thankfully I've kept my passwords varied and strong, so the damage hasn't terrible to contain. I tried to delete accounts to manage my risk, only to learn just how hard it is to do that as a U.S. citizen. In the case of Google, I already had a Google account so I didn't figure the mailing list would worsen my situation much. Point is, I do due diligence now. Adding an account means another legal agreement, another privacy policy, another social structure, and another increase in my personal attack surface. I know maintaining a mailing list is a PITA regardless of its usefulness, so I totally understand moving to Discourse. I just don't understand this habit of "we're doing this, we want you to do it too" with sunsetting overtones. 1) it sounds like I'm doing someone a favor, and 2) this sounds like when someone first said "Racket2", and I should probably get the fuck outta here before someone throws something. I know I'm being dramatic, but please consider just leaving the list to die inactive if that is to be its fate. The messaging I'm seeing keeps messing with the community messaging about backwards compatibility, and it's super confusing. On 11/22/21 10:24 AM, Martin Weigele wrote: > Am Montag, 22. November 2021, 16:16:35 CET schrieb Jens Axel Søgaard: > >> There are no plans of closing the mailing list. >> >> Things take time. >> >> Different forums for communication have different strengths. > > Exactly > >> Discourse might attract an audience that is unfamiliar to mailing lists. >> There is no need to rush things however. >> In due course maybe the number of users on the forum will >> grow to outshadow the number of participants on the mailing list, >> but it will take some years. > > A discourse type forum - we had this discussions in other contexts again and > again - may be a better choice for persons who have the luxury they can > concentrate on very few thingies. For all others, mailinglists are a much > better choice, you can follow many developments in one place: your mail > client, with a completely standard UI. > > Cheers > Martin > > -- > 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/2080281.KiezcSG77Q%40castor > . -- 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/b9684624-d477-ddf1-d434-b34aa9cc89e9%40sagegerard.com.
Re: [racket-users] Racket Discourse
Thanks! On 11/22/21 9:58 AM, Sam Tobin-Hochstadt wrote: > On Mon, Nov 22, 2021 at 9:52 AM Sage Gerard wrote: >> Thanks for checking on this. I'd expect something like a CoC more than a ToS >> in this case, but terms are terms :) > The discourse site is hosted by the people who make/run Discourse the > project, you can read about them here: https://www.discourse.org/team > > I believe that this mailing list is covered by the general Google > terms of service, here: https://policies.google.com/terms?hl=en-US and > the Google Groups content policy here: > https://support.google.com/groups/answer/4561696?hl=en > >> If you don't mind, I have a couple of follow up questions. >> >> Were "rank-and-file" Racket contributors alerted to this change in advance? >> Say, in a RacketCon speech? I may have missed it. > I announced it in the State of Racket talk at RacketCon. > >> Did a sponsor play any role in this transition? > The Discourse site is free based on the Free-for-open-source version > of Discourse, but no sponsorship is involved. > > Sam > >> On 11/22/21 9:49 AM, John Clements wrote: >> >> I’m actually very heartened to see the boilerplate here; it sounds like this >> is something we can edit, and not something imposed by Discourse. If that’s >> the case, then it certainly seems likely that we can find some language (or, >> more importantly, *lack* of language) that makes more of us happy. >> >> I, for one, am shocked to see binding arbitration language in here: I think >> binding arbitration is one of the most revolting elements of corporate >> control in our society today, and if we were unable to remove the binding >> arbitration clause, I would likely abandon discourse myself. >> >> Sounds like the next step is to come up with a TOS that’s acceptable to all, >> or find a way to remove it entirely. >> >> John >> >> On Nov 22, 2021, at 04:54, Norman Gray wrote: >> >> >> Greetings. >> >> On 22 Nov 2021, at 4:24, Sage Gerard wrote: >> >> But I have to ask, who wrote the ToS? Who is "the company" in its >> >> context? Discord? One of the Racket team's universities? A sponsor? >> >> I'm not sure who 'the company' is, either, but they appear to be called >> 'company_name' (catchy!), and that users are notified that disputes can only >> be arbitrated in city_for_disputes, under governing_law. *cough* >> >> Such curiosities aside, all of that does represent unappealingly more >> legalese than one expects for a mailing list. But since the current list is >> hosted at googlegroups, and since it's not obvious that Discourse Corp is >> more predatory than Google Corp (indeed, the former is dispensing >> freemium-ware rather than ad-ware, so are more attractive in terms of >> business model), it feels irrational for me to be too put off by it. >> >> Best wishes, >> >> Norman >> >> >> -- >> Norman Gray : https://nxg.me.uk >> SUPA School of Physics and Astronomy, University of Glasgow, UK >> >> -- >> 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/BEC261BF-C274-4221-8F62-C77D181ED1EF%40glasgow.ac.uk. >> >> -- >> 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/8bb7efbe-0d8a-32d8-c423-986e523e343c%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/e88f5bd3-4870-a372-5fdd-d6a9c6069e0e%40sagegerard.com.
Re: [racket-users] Racket Discourse
Gotcha, thanks. As long as we were warned! I thought I remembered Sam mentioning something along the lines of an "AWS grant," but my memory is unreliable here. On 11/22/21 9:57 AM, John Clements wrote: > Good questions: > > 1) Yes, Sam mentioned the discourse group at RacketCon, and there was some > “hallway” discussion about it. > 2) No, no sponsor was involved. Yikes! Indeed, I’m not aware that Racket > *has* any sponsors currently, aside from the research and infrastructure > grants that are being funded by the NSF et cetera. > > John > >> On Nov 22, 2021, at 09:52, Sage Gerard wrote: >> >> Thanks for checking on this. I'd expect something like a CoC more than a ToS >> in this case, but terms are terms :) >> If you don't mind, I have a couple of follow up questions. >> >> • Were "rank-and-file" Racket contributors alerted to this change in >> advance? Say, in a RacketCon speech? I may have missed it. >> • Did a sponsor play any role in this transition? >> On 11/22/21 9:49 AM, John Clements wrote: >>> I’m actually very heartened to see the boilerplate here; it sounds like >>> this is something we can edit, and not something imposed by Discourse. If >>> that’s the case, then it certainly seems likely that we can find some >>> language (or, more importantly, *lack* of language) that makes more of us >>> happy. >>> >>> I, for one, am shocked to see binding arbitration language in here: I think >>> binding arbitration is one of the most revolting elements of corporate >>> control in our society today, and if we were unable to remove the binding >>> arbitration clause, I would likely abandon discourse myself. >>> >>> Sounds like the next step is to come up with a TOS that’s acceptable to >>> all, or find a way to remove it entirely. >>> >>> John >>> >>> >>>> On Nov 22, 2021, at 04:54, Norman Gray >>>> wrote: >>>> >>>> >>>> Greetings. >>>> >>>> On 22 Nov 2021, at 4:24, Sage Gerard wrote: >>>> >>>> >>>>> But I have to ask, who wrote the ToS? Who is "the company" in its >>>>> >>>>> context? Discord? One of the Racket team's universities? A sponsor? >>>>> >>>> I'm not sure who 'the company' is, either, but they appear to be called >>>> 'company_name' (catchy!), and that users are notified that disputes can >>>> only be arbitrated in city_for_disputes, under governing_law. *cough* >>>> >>>> Such curiosities aside, all of that does represent unappealingly more >>>> legalese than one expects for a mailing list. But since the current list >>>> is hosted at googlegroups, and since it's not obvious that Discourse Corp >>>> is more predatory than Google Corp (indeed, the former is dispensing >>>> freemium-ware rather than ad-ware, so are more attractive in terms of >>>> business model), it feels irrational for me to be too put off by it. >>>> >>>> Best wishes, >>>> >>>> Norman >>>> >>>> >>>> -- >>>> Norman Gray : >>>> https://nxg.me.uk >>>> >>>> SUPA School of Physics and Astronomy, University of Glasgow, UK >>>> >>>> -- >>>> 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/BEC261BF-C274-4221-8F62-C77D181ED1EF%40glasgow.ac.uk >>>> . >>>> -- 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/b78997fa-d576-10a9-8911-76035f9bc83a%40sagegerard.com.
Re: [racket-users] Racket Discourse
Thanks for checking on this. I'd expect something like a CoC more than a ToS in this case, but terms are terms :) If you don't mind, I have a couple of follow up questions. - Were "rank-and-file" Racket contributors alerted to this change in advance? Say, in a RacketCon speech? I may have missed it. - Did a sponsor play any role in this transition? On 11/22/21 9:49 AM, John Clements wrote: > I’m actually very heartened to see the boilerplate here; it sounds like this > is something we can edit, and not something imposed by Discourse. If that’s > the case, then it certainly seems likely that we can find some language (or, > more importantly, *lack* of language) that makes more of us happy. > > I, for one, am shocked to see binding arbitration language in here: I think > binding arbitration is one of the most revolting elements of corporate > control in our society today, and if we were unable to remove the binding > arbitration clause, I would likely abandon discourse myself. > > Sounds like the next step is to come up with a TOS that’s acceptable to all, > or find a way to remove it entirely. > > John > >> On Nov 22, 2021, at 04:54, Norman Gray >> [](mailto:norman.g...@glasgow.ac.uk) >> wrote: >> >> Greetings. >> >> On 22 Nov 2021, at 4:24, Sage Gerard wrote: >> >>> But I have to ask, who wrote the ToS? Who is "the company" in its >>> >>> context? Discord? One of the Racket team's universities? A sponsor? >> >> I'm not sure who 'the company' is, either, but they appear to be called >> 'company_name' (catchy!), and that users are notified that disputes can only >> be arbitrated in city_for_disputes, under governing_law. *cough* >> >> Such curiosities aside, all of that does represent unappealingly more >> legalese than one expects for a mailing list. But since the current list is >> hosted at googlegroups, and since it's not obvious that Discourse Corp is >> more predatory than Google Corp (indeed, the former is dispensing >> freemium-ware rather than ad-ware, so are more attractive in terms of >> business model), it feels irrational for me to be too put off by it. >> >> Best wishes, >> >> Norman >> >> -- >> Norman Gray : >> https://nxg.me.uk >> SUPA School of Physics and Astronomy, University of Glasgow, UK >> >> -- >> 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/BEC261BF-C274-4221-8F62-C77D181ED1EF%40glasgow.ac.uk >> . -- 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/8bb7efbe-0d8a-32d8-c423-986e523e343c%40sagegerard.com.
Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket
If anyone here still has demand for a vanilla email list, please reach out to me. On 11/22/21 9:40 AM, David Storrs wrote: > That's sudden. > > On Mon, Nov 22, 2021 at 8:06 AM Etan Wexler wrote: > >> The stewards of [Racket](https://racket-lang.org/) have decided that it’s >> time to give up on the mailing list (that is, >> [racket-users](https://groups.google.com/group/racket-users), to which this >> message is a contribution). The stewards of >> [Racket](https://racket-lang.org/) have designated [another forum for >> Racket](https://racket.discourse.group/) as the successor to >> [racket-users](https://groups.google.com/group/racket-users). [This other >> forum for discussing Racket](https://racket.discourse.group/) has as its >> basis [the software named “Discourse”](https://www.discourse.org/), which is >> open‐source. Enlisting is prerequisite to contributing to [the Discursive >> forum for Racket](https://racket.discourse.group/). Enlisting is >> prerequisite to receiving as Internet mail the contributions to [the >> Discursive forum for Racket](https://racket.discourse.group/). The stewards >> of [Racket](https://racket-lang.org/) have published [a facility for >> enlisting as a participant in the Discursive forum for >> Racket](https://racket.discourse.group/invites/okLTSrQw1T). > > -- > 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/CAE8gKoewCWhqGkxcxq%2BMD7ZUjphXNj9j7bx0bw2%2BzTCWFSSHog%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CAE8gKoewCWhqGkxcxq%2BMD7ZUjphXNj9j7bx0bw2%2BzTCWFSSHog%40mail.gmail.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/1b877517-99b7-4201-a256-58dc580de68e%40sagegerard.com.
Re: [racket-users] Racket Discourse
Also: Apologies. That came off as rude. No offense intended. But I have to ask, who wrote the ToS? Who is "the company" in its context? Discord? One of the Racket team's universities? A sponsor? On 11/21/21 11:20 PM, Sage Gerard wrote: > Thanks for letting us know. When should people expect to unsubscribe? > > I read the ToS, privacy policy, and thoughts. Hard pass. > > On 11/21/21 1:09 PM, 'John Clements' via Racket Users wrote: >> TL;DR: Go to >> >> https://racket.discourse.group/invites/okLTSrQw1T >> >> and sign up for Racket Discourse (https://racket.discourse.group/) >> >> # Thoughts behind the move: >> >> Over time, it has become steadily more apparent that email-only >> mailing lists are an outdated communication medium for the Racket >> community. More recent arrivals in our community have generally >> chosen other platforms like slack or discord to carry on discussions. >> As a result, the signal-to-noise ratio of the racket users mailing list >> has dropped below the level of viability. >> >> In short, it’s time to give up on the mailing list. >> >> After a good deal of research, it looks like there’s room for a whole >> bunch of discussion platforms for Racket, but it also seems as though >> there should be a “permanent” one; it should be archived, it should be >> searchable in its entirety, and it should not tie us to someone else’s >> plan to monetize user data. >> >> Given these criteria, the winner is Discourse, an open-source >> messaging platform built by Jeff Atwood, Robin Ward, and Sam >> Saffron. It has a reasonable business model (they host projects like >> ours unless they get really big, whereupon you can either host it >> yourself or pay them to do it); it’s widely used by other language >> communities; and it appears to do most of what we want. >> >> # So where can I sign up? >> >> Sign up here: https://racket.discourse.group/invites/okLTSrQw1T >> >> The discourse platform has been in a “soft opening” phase for about >> two weeks now, since RacketCon, and we have about a hundred users. >> You’re receiving this message because we’d like to have *YOU* there >> as well. >> >> # Can I still receive messages like a mailing list? >> >> Yes, you can. I have it enabled myself! >> To use discord as a mailing-list: >> Sign up, go to Preferences > Email, and tick “Enable mailing list mode'. >> >> Yours, >> >> John Clements & Stephen De Gabrielle >> >> -- >> 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/9d080367-1b70-4818-8e76-8c6714db404c%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/a07b931b-3a0a-0a29-0582-e899aa335130%40sagegerard.com.
Re: [racket-users] Racket Discourse
Thanks for letting us know. When should people expect to unsubscribe? I read the ToS, privacy policy, and thoughts. Hard pass. On 11/21/21 1:09 PM, 'John Clements' via Racket Users wrote: > TL;DR: Go to > > https://racket.discourse.group/invites/okLTSrQw1T > > and sign up for Racket Discourse (https://racket.discourse.group/) > > # Thoughts behind the move: > > Over time, it has become steadily more apparent that email-only > mailing lists are an outdated communication medium for the Racket > community. More recent arrivals in our community have generally > chosen other platforms like slack or discord to carry on discussions. > As a result, the signal-to-noise ratio of the racket users mailing list > has dropped below the level of viability. > > In short, it’s time to give up on the mailing list. > > After a good deal of research, it looks like there’s room for a whole > bunch of discussion platforms for Racket, but it also seems as though > there should be a “permanent” one; it should be archived, it should be > searchable in its entirety, and it should not tie us to someone else’s > plan to monetize user data. > > Given these criteria, the winner is Discourse, an open-source > messaging platform built by Jeff Atwood, Robin Ward, and Sam > Saffron. It has a reasonable business model (they host projects like > ours unless they get really big, whereupon you can either host it > yourself or pay them to do it); it’s widely used by other language > communities; and it appears to do most of what we want. > > # So where can I sign up? > > Sign up here: https://racket.discourse.group/invites/okLTSrQw1T > > The discourse platform has been in a “soft opening” phase for about > two weeks now, since RacketCon, and we have about a hundred users. > You’re receiving this message because we’d like to have *YOU* there > as well. > > # Can I still receive messages like a mailing list? > > Yes, you can. I have it enabled myself! > To use discord as a mailing-list: > Sign up, go to Preferences > Email, and tick “Enable mailing list mode'. > > Yours, > > John Clements & Stephen De Gabrielle > > -- > 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/9d080367-1b70-4818-8e76-8c6714db404c%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/201d1330-eee7-d440-efc1-8193d2089f8e%40sagegerard.com.
Re: [racket-users] Best way to append an element to a list?
I get these timings on x86_64 GNU/Linux using the following profile program. ; A: cpu time: 7444 real time: 7445 gc time: 716 ; B: cpu time: 9227 real time: 9228 gc time: 884 (module profile racket/base (define target-length #e5e4) (define (A current-list new-element) (append current-list (list new-element))) (define (B current-list new-element) (reverse (cons new-element (reverse current-list (define (profile function) (printf "~a: " (object-name function)) (time (void (for/fold ([l null]) ([n (in-range target-length)]) (function l n) (profile A) (profile B)) On 11/16/21 2:04 PM, David Storrs wrote: > If I want to add an element to the end of an immutable list, is it better to > do: > > (append current-list (list new-element)) > or > (reverse (cons new-element (reverse current-list))) > or > something else? > > I would imagine it's the first one because that should be a single traversal > and link add instead of two traversals and rebuilds, but maybe I'm wrong. > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > [https://groups.google.com/d/msgid/racket-users/CAE8gKocM4jNCg6xKruYwuwFtuOdbOSwugYcgUND1ZD%3DRB1iA0g%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CAE8gKocM4jNCg6xKruYwuwFtuOdbOSwugYcgUND1ZD%3DRB1iA0g%40mail.gmail.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/3a9777e7-4b33-b561-f47e-8fe940699b39%40sagegerard.com.
Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds
> The timezone database lookup logic is in the `tzinfo` package > (https://docs.racket-lang.org/tzinfo/index.html) Thanks. > Jon: I'm guessing you haven't actually tried this > Phillip: I guess the check doesn't happen as part of `tz/c`, but I can tell > you that this program Yes, but I'm talking about code we were asked to give feedback on. I focus on `tz/c` because it is documented as a flat contract that checks for "an identifier from the IANA [tz database](https://www.iana.org/time-zones)", but it does not parse the timezone name to check correctness. My feedback says no validation occurs for the timezone name in a parameter for Splitflap. Joel indicated that parameter will go away below, and I'm glad to know of the tzinfo package. But if a limitation in gregor's contracts would oblige you to use tzinfo for validation, then I'd want to know that so that I can assess how much of gregor I really need. It still seems like the timezone data is the hard part, so use a timezone dependency instead of a dependency that misleads the user into incomplete validation. On 10/26/21 12:39 PM, 'Joel Dueck' via Racket Users wrote: > On Tuesday, October 26, 2021 at 11:01:38 AM UTC-5 Sage Gerard wrote: > >> - Assuming I have the right repository link, gregor's tz/c contract is only >> (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone >> parameter in Splitflap to an arbitrary string and the guard won't stop me. > > Yep — I left feed-timezone out of the docs because I plan to remove it. > Unless I'm missing something? in the end I think it's redundant to tzinfo's > current-timezone parameter. > -- > 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/d202c537-0173-42fd-b75f-082275c57426n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/d202c537-0173-42fd-b75f-082275c57426n%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/f879496a-04c6-e5dd-2501-928a4eff7fb2%40sagegerard.com.
Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds
I can understand wanting gregor for timezone offsets when constructing moments, but... - Assuming I have the right repository link, gregor's tz/c contract is only (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone parameter in Splitflap to an arbitrary string and the guard won't stop me. - The IANA's timezone database changed this month, and gregor's last commit was 2 years ago. My comment was not meant to say that timezone math is easy to replace, or even that gregor isn't a fit. It's to say that I'm not seeing correct answers without a name lookup in front of tz/c, and the latest data from the IANA. But if you were going to do all that in the first place, then I'm not sure what I'd use gregor for outside of relative arithmetic. [1]: https://github.com/97jaz/gregor/blob/91d71c6082fec4197aaf9ade57aceb148116c11c/gregor-lib/gregor/private/moment.rkt#L91 On 10/26/21 11:25 AM, David Storrs wrote: > On Mon, Oct 25, 2021 at 10:25 PM 'Joel Dueck' via Racket Users > wrote: > >> - Removing dependencies: yes, I see the appeal. I’m really not eager to >> reimplement all the timezone handling and temporal comparison stuff in >> gregor, though. >> >> Joel > > Having done a fair bit of datetime programming, my suggestion on the best way > to handle it is to not handle it. Let some purpose-built library such as > gregor do it instead of trying to roll your own, because datetime math is a > nightmare. > >> On Monday, October 25, 2021 at 6:36:30 PM UTC-5 Sage Gerard wrote: >> >>> Thank you for this!! >>> >>> Feedback >>> >>> - I like your podcast-specific entries >>> - The validation logic is refreshing to see >>> - Re: boolean arguments, I'd stick to keyword arguments and ask for any/c, >>> not boolean?, in contracts. That way forms like (and ... (member ...)) >>> won't bug users about a non-threatening contract violation, and it's >>> trivial to cast the value yourself. >>> - Unsure what licenses are compatible with Blue Oak. If you want more >>> licensing options re: IANA media type to extension mappings, here are some. >>> >>> - MIT: https://github.com/mime-types/mime-types-data >>> - Apache 2.0 (From the horse's mouth): >>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types >>> >>> - CC-BY-SA: Scrape MDN's table using the console on >>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types >>> >>> - I normally don't use functions like splitflap-version because I can't >>> assume that a package will define one. I'd use a program that returns a >>> version of a given package. >>> - Why is language-codes a procedure? >>> - You have a lot of local contract boundaries, so values may get checked >>> more than necessary. >>> - Prefer example.com so you don't have to leak your URLs or make up email >>> addresses that actually go to an inbox. >>> - txexpr, gregor, and web-server dependencies don't look terribly difficult >>> to remove >> >> -- >> 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/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%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/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.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/25acca19-5970-1131-c63f-305abd4964e9%40sagegerard.com.
Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds
Thank you for this!! Feedback - I like your podcast-specific entries - The validation logic is refreshing to see - Re: boolean arguments, I'd stick to keyword arguments and ask for any/c, not boolean?, in contracts. That way forms like (and ... (member ...)) won't bug users about a non-threatening contract violation, and it's trivial to cast the value yourself. - Unsure what licenses are compatible with Blue Oak. If you want more licensing options re: IANA media type to extension mappings, here are some. - MIT: https://github.com/mime-types/mime-types-data - Apache 2.0 (From the horse's mouth): https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types - CC-BY-SA: Scrape MDN's table using the console on https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types - I normally don't use functions like splitflap-version because I can't assume that a package will define one. I'd use a program that returns a version of a given package. - Why is language-codes a procedure? - You have a lot of local contract boundaries, so values may get checked more than necessary. - Prefer example.com so you don't have to leak your URLs or make up email addresses that actually go to an inbox. - txexpr, gregor, and web-server dependencies don't look terribly difficult to remove On 10/25/21 2:54 PM, 'Joel Dueck' via Racket Users wrote: > This is a beta release of splitflap, a Racket library for generating valid > Atom and RSS feeds, including podcast feeds. > > - Source: https://github.com/otherjoel/splitflap > > - Documentation (with quick tutorial): > https://docs.racket-lang.org/splitflap/index.html > > The docs are substantially complete but I’m still working on them! Feedback > welcome. > > Joel > -- > 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/55a4e6de-1e08-4219-9675-31e5c598a38dn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/55a4e6de-1e08-4219-9675-31e5c598a38dn%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/668400ac-68ea-073e-04ff-2f7fbc872e6d%40sagegerard.com.
Re: [racket-users] Weird test failures
I got all tests to pass by updating the first clause of pre-escape to use equal? > (and (txexpr? x) (equal? "text" (attr-ref x 'type #f))) My hypothesis is that when you didn't have bytecode, the reference to the literal string "text" just happened to be eq?. I couldn't say why. On 10/24/21 12:09 PM, 'Joel Dueck' via Racket Users wrote: > This is driving me a little batty. I have a package on the package server, > and the package server shows that it is failing some tests[1]. > > Here is the first test that fails: > > FAILURE > name: check-equal? > location: dust.rkt:101:2 > actual: > '(div (div ((type "text")) > "Judy's friend \"George\"" > (div "Judy's friend \"George\""))) > expected: > '(div (div ((type "text")) > "Judy%amp%apos;s friend %amp%quot;George%amp%quot;" > (div "Judy's friend \"George\""))) > > The check in question can be seen in dust.rkt on the Github repo [2]. > > Here’s the weird part. This check does not fail on my local machine (Racket > 8.2 CS on Mac OS 11.6). Well…not true! It *usually* doesn’t fail on my > computer BUT sometimes checks in my tests.rkt which are dependent on this one > will start failing. When that happens, all I need to do is re-save dust.rkt > with no changes (to invalidate the compile cache) and re-run tests.rkt and > the checks all pass again. > > Of what known gotcha have I run afoul here? Or is it an unknown gotcha? > > The function which is the subject of the test is not complicated: > > ;; Recursively pre-escape any string entities in an x-expression that > ;; are direct children of an element whose ‘type’ attribute is “text” > (define (pre-escape x) > (cond > [(and (txexpr? x) (eq? "text" (attr-ref x 'type #f))) > (txexpr > (car x) > (get-attrs x) > (map (λ (c) (if (string? c) (pre-escape-entities c) (pre-escape c))) > (get-elements x)))] > [(txexpr? x) (txexpr (car x) (get-attrs x) (map pre-escape (get-elements x)))] > [else x])) > > [1]: > https://pkg-build.racket-lang.org/server/built/test-fail/splitflap-lib.txt > [2]: > https://github.com/otherjoel/splitflap/blob/11ddfebb96d13b4905d428939ba3bd9bd39e1caa/splitflap-lib/private/dust.rkt#L101-L102 > > -- > 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/10b7621b-c366-4c78-ac86-f011d46a954fn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/10b7621b-c366-4c78-ac86-f011d46a954fn%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/85aa1a42-48a1-1129-269a-be282acd6cc3%40sagegerard.com.
Re: [racket-users] using raco to install executables
Yes. The keyword here is "launcher." See the gracket-launcher* and racket-launcher-* options for info.rkt files in https://docs.racket-lang.org/raco/setup-info.html These options affect `raco setup` in particular. Here's one of my info.rkt files as an example https://github.com/zyrolasting/polyglot/blob/master/polyglot-lib/polyglot/info.rkt On 9/21/21 12:34 PM, Roger Keays wrote: > Can you use raco to install executables on the system path like with > python/pip? > > -- > 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.1898dec7b9.20210921163404.GC5208%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/295fe146-84ad-9c67-3b33-53167a486a0f%40sagegerard.com.
Re: [racket-users] Bootstrap on Racket
Also check koyo and Axio On 9/4/21 12:14 PM, 'John Clements' via Racket Users wrote: > I use Greg Hendershott’s excellent and trouble-free ‘frog’ library. How would > your code relate to this? > > John > >> On Aug 30, 2021, at 10:57, Dexter Lagan wrote: >> >> Hi again, >> >>I've been working on porting my Newstrap Web framework from newLISP to >> Racket. I got most of it done and am about to start work on a router. Here's >> what I got so far: >> >> DexterLagan/rap: Combination of Racket and Bootstrap, RAP is a Web framework >> aiming to produce good-looking pages with ease. (github.com) >> >> based on Newsrap: >> >> DexterLagan/newstrap: A fast, lightweight web framework written in newLISP. >> (github.com) >> >>Does anybody know if something similar already exists? I looked around >> but couldn't find anything production-ready (in Racket). I just want to know >> if I'm wasting my time reinventing the wheel, or if there's value in having >> a bunch of macros generate Bootstrap code. My first goal would be to have a >> static site generator going, followed by a fully-featured framework for >> production use. >> >> Any and all feedback would help me greatly! >> >> Dex >> >> >> -- >> 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/473170ba-624a-4339-b499-9e936765603cn%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/75aa8867-0487-412e-9ce3-22edefb0a1e0%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/21b5e69a-4da7-8878-ef29-f2e22dfd4bf3%40sagegerard.com.
Re: [racket-users] A language for command line interfaces
Thank you for doing this. CLIs are an interesting beast, and I should be available to contribute and/or comment next week. ~slg Original Message On Jul 24, 2021, 1:14 PM, Siddhartha Kasivajhula wrote: > Hello folks, > If you ever have a need to write a command line script in Racket, you may be > interested in the package I've just put up. Normally you'd write such scripts > using Racket's built-in > [command-line](https://docs.racket-lang.org/reference/Command-Line_Parsing.html#%28form._%28%28lib._racket%2Fcmdline..rkt%29._command-line%29%29) > or > [parse-command-line](https://docs.racket-lang.org/reference/Command-Line_Parsing.html#%28def._%28%28lib._racket%2Fcmdline..rkt%29._parse-command-line%29%29) > form. These offer a lot of functionality, but it takes time to learn how > they work and the syntax is somewhat idiosyncratic. So, I've written a #lang > that allows you to achieve the same functionality but with more familiar and > extensible syntax, [#lang cli](https://docs.racket-lang.org/cli/index.html). > > The language is composed of 5 forms - help, flag, constraint, program, and > run. With these 5 forms, you get all of the functionality of the built-in > parse-command-line form, and with syntax that's much simpler. In fact, the > nontrivial forms of the language simply use Racket's normal function > definition syntax, so there's very little to learn -- you basically write > normal functions and they are implicitly wired to accept their inputs via the > command line. > > At the moment, the functionality offered is at parity with the built-in > forms, but there are some planned additions that would make it more powerful, > including [composable > commands](https://github.com/countvajhula/cli/issues/3), [generalized > constraints](https://github.com/countvajhula/cli/issues/6), and [argument > schemas](https://github.com/countvajhula/cli/issues/7). > > So if you write command line scripts, I encourage you to give it a try. > > I also coincidentally came across the package > [natural-cli](https://docs.racket-lang.org/natural-cli/index.html) by Sage > Gerard. Looks like it provides some interesting features and in particular > subcommands, which are absent in #lang cli. It very well may be that this > package should be leveraged for semantics in #lang cli in the future (Sage if > you'd like to add anything about what this package offers, please do). > Enjoy, > -Sid > > -- > 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/CACQBWFnevJaRg61xLv6ayps-ihGpuUFUFEVbLTH7m929tpex3Q%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CACQBWFnevJaRg61xLv6ayps-ihGpuUFUFEVbLTH7m929tpex3Q%40mail.gmail.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/rxdVJcMmBhW1Xtw4KZEtdl0qySeqWsbpKhW5wewaDeXGOm8PyjMWV4Q_fKXCzIitRyxDtZjRx4DtjMTi398FwMM1V3Y4lLX91urE3_N2zlE%3D%40sagegerard.com.
Re: [racket-users] Security advisory for racket/sandbox; fixed in v8.2
Thank you for letting us know. ~slg Original Message On Jul 19, 2021, 2:35 PM, Sam Tobin-Hochstadt wrote: > 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. -- 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/d2foR8gQSc68pALp0iYCn13f6Uq5iEXHu4h9sT8hseKEhnoYGgpYi1sd2Lbmj0CiM4CT-HckGaMt5TdW7hw1wgy9E8Rm1iiuOunKlEvETqU%3D%40sagegerard.com.
Re: [racket-users] Show & Tell - Xiden Documentation Revamp
Yikes, sorry about that. That's what I get for cross-posting HTML from another dark mode app. Looked the same to me. :) Last try. I did a pretty sweeping edit pass on Xiden's documentation. I'm really proud of it, and I'd like to show it off. https://docs.racket-lang.org/xiden-index/index.html?q=xiden%20documentation This revision of the docs uses a Guide [-> Exercises] -> Reference reading flow. It allowed me to delete a lot of extra text, but I don't know if it became easier or harder to understand. Could I get some feedback on just the guide and the transition to the exercises? What do you find clear/confusing? Did the examples work on your machine? etc. On 7/2/21 6:02 PM, Sage Gerard wrote: > Hey folks, > > I did a pretty sweeping edit pass on Xiden's documentation. I'm really proud > of it, and I'd like to show it off. > https://docs.racket-lang.org/xiden-index/index.html?q=xiden%20documentation > This revision of the docs uses a Guide [-> Exercises] -> Reference reading > flow. It allowed me to delete a lot of extra text, but I don't know if it > became easier or harder to understand. Could I get some feedback on just the > guide and the transition to the exercises? What do you find clear/confusing? > Did the examples work on your machine? etc. -- ~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/674c115f-0752-def3-3274-2cee57a05d39%40sagegerard.com.
[racket-users] Show & Tell - Xiden Documentation Revamp
Hey folks, I did a pretty sweeping edit pass on Xiden's documentation. I'm really proud of it, and I'd like to show it off. https://docs.racket-lang.org/xiden-index/index.html?q=xiden%20documentation This revision of the docs uses a Guide [-> Exercises] -> Reference reading flow. It allowed me to delete a lot of extra text, but I don't know if it became easier or harder to understand. Could I get some feedback on just the guide and the transition to the exercises? What do you find clear/confusing? Did the examples work on your machine? etc. -- ~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/35ebe8f7-b8ca-54bb-4ad8-6ecefe403f9b%40sagegerard.com.
Re: [racket-users] Could Racket be used as a "frontend" for a non-Racket language?
Short answer: Yes...ish. I wrote a few code generation programs. It can happen, but the Racket program would be dependent on the target language's toolchain and standard library. Before we get to that, note that not all languages cleanly translate into one another (Some scripting languages actually have features that introduce forward-compatibility problems, see JS and with). The standard library issues become more apparent when you realize that Racket programs have defined value types where other languages don't bother (e.g. complex numbers and path types). If your goal is to generate a few well-defined programs its fine, but if you want a completely correct model for translations with a DSL as a front-end, then that can be a pretty large undertaking. And that's not saying anything about your performance expectations, since Racket's reader/expander probably won't be able to compete with a native compiler. On 6/22/21 10:50 AM, D. Ben Knoble wrote: > No idea if this is what you're looking for, but I have a feeling it wouldn't > be terribly difficult to design a #lang where modules were programs that, > when run, output C# code (kind of like how scribble & pollen can output > HTML). Then you could have a language (w/ or w/o) macros that gets run down > to C# and let the C# compiler and project toolchain take care of the rest? > Essentially it's only a syntax—the semantics is "turn it into this C# code." > -- > 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/a70bff98-e143-4c85-bcc9-2d919927764dn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/a70bff98-e143-4c85-bcc9-2d919927764dn%40googlegroups.com?utm_medium=email_source=footer). -- ~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/81580c35-61e2-cce8-c297-a3e4f61cfca6%40sagegerard.com.
Re: [racket-users] Teaching Racket to kids experiences, syllabus ideas, etc
John Carmack did so for his 10 year old. His notes may be of interest. https://groups.google.com/g/racket-users/c/yjRuIxypUQc On 6/15/21 1:42 PM, Nathaniel W Griswold wrote: > Has anyone taught racket to kids, like middle school and above? > > I see some really basic articles when googling around, but i was wondering if > anyone has experience with this. > > Would you use the picturing-programs book? I see it's built into Racket, > which is nice. > > I was thinking of something smaller though, for a low-pressure introduction > to programming, control flow, making an algorithm, that kinda stuff. > > 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/0FC82045-32B6-434C-BF40-B2C3298BA6C2%40manicmind.earth. -- ~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/65caa817-4bd6-7f2f-6676-03863d840cce%40sagegerard.com.
Re: [racket-users] PLTCOLLECTS env var is not always in effect - Why?
What is the value of ([][use-user-specific-search-paths](https://docs.racket-lang.org/reference/collects.html?q=PLTCOLLECTS#%28def._%28%28quote._~23~25kernel%29._use-user-specific-search-paths%29%29)) in each case? On 6/5/21 6:39 PM, Don Green wrote: > When I run drracket v 8.1 the additional collection is in effect as evidenced > by: > (current-library-collection-paths) returns: > '(# > # #) > > however when I open drracket by clicking on a .rkt file > (current-library-collection-paths) returns: > '( # #) > > How to fix this? > -- > 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/b219d197-9989-4a0e-9f92-ad8bec01fbb0n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/b219d197-9989-4a0e-9f92-ad8bec01fbb0n%40googlegroups.com?utm_medium=email_source=footer). -- ~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/fd85ef5e-f878-6209-8635-8c0ff434e53d%40sagegerard.com.
Re: [racket-users] Defining a function with the same name as a struct with a different constructor name
My understanding is that you can shadow `foo`, but you cannot use `foo` in any expression at the same scope where the struct's bindings appear. In this context, some of `foo`'s lexical information is reserved so that `struct-out` works correctly. On 6/3/21 5:01 PM, flirora wrote: > Am I correct in assuming that given a definition like > > (struct foo (x) #:constructor-name bar) > > I then can't define something named foo in the same module, even though > there's no constructor called foo? > > -- > 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/02598ee4-4461-4815-bd4f-a8ac02c1118cn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/02598ee4-4461-4815-bd4f-a8ac02c1118cn%40googlegroups.com?utm_medium=email_source=footer). -- ~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/76c51dda-b80d-d74a-c691-d92fe11008e8%40sagegerard.com.
[racket-users] Re: How do I debug this "invalid memory reference"?
Credit to @samth on the Discord for noticing that I did not use `_bytes/nul-terminated` on Racket CS byte strings. Doing so fixed the issue. Thanks, Sam! On 6/2/21 10:21 AM, Sage Gerard wrote: > Hi all, > > Consider this small FFI that currently works only on GNU/Linux. > > https://github.com/zyrolasting/xiden/blob/libcrypto/crypto.rkt > https://github.com/zyrolasting/xiden/blob/libcrypto/crypto/crypto.c > > `raco test` intermittently fails this module with "invalid memory reference. > Some debugging context lost". I can silence the error by commenting out all > use of `valid?` in the tests (starts on line 413), which allows me to blame > one of the verification functions. However, I do not understand the nature of > the problem well enough to know where exactly the problem occurred, or what > to do when I find it. > > My current guess is that I passed a pointer to GC-managed memory, and the > pointer referenced an old location. > > Besides continuing to throw prints around, how should I go about debugging > this? > > -- > ~slg -- ~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/a7754519-5b39-a2bb-2d6a-958dac6eedfe%40sagegerard.com.
[racket-users] How do I debug this "invalid memory reference"?
Hi all, Consider this small FFI that currently works only on GNU/Linux. https://github.com/zyrolasting/xiden/blob/libcrypto/crypto.rkt https://github.com/zyrolasting/xiden/blob/libcrypto/crypto/crypto.c `raco test` intermittently fails this module with "invalid memory reference. Some debugging context lost". I can silence the error by commenting out all use of `valid?` in the tests (starts on line 413), which allows me to blame one of the verification functions. However, I do not understand the nature of the problem well enough to know where exactly the problem occurred, or what to do when I find it. My current guess is that I passed a pointer to GC-managed memory, and the pointer referenced an old location. Besides continuing to throw prints around, how should I go about debugging this? -- ~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/424c0500-4f09-784a-eab6-8967310b5869%40sagegerard.com.
Re: [racket-users] Cross-VM method for sending any input port to C runtime?
I'm not sure, but I think I can be content with passing Racket bytes across the foreign interface boundary for the C runtime to use given the u8vector equivalence. Only thing I'm not clear on: Is it a good idea for me to designate the byte string as a _gcpointer on the "*" marked line, or does it not matter? (define-ffi-definer define-ff (ffi-lib doesnt-matter)) (define-ff fill_up (_fun _pointer _int -> _void)) ; * (define size 2) (define buffer (make-bytes size)) (fill_up buffer size) On 5/23/21 8:45 PM, Philip McGrath wrote: > On Sun, May 23, 2021 at 7:57 PM Matthew Flatt wrote: > >> At Sun, 23 May 2021 14:57:42 +, Sage Gerard wrote: >>> Is there a cross-VM way to pass an arbitrary input port to the C >>> runtime (e.g. via open-input-bytes), such that the C runtime can read >>> bytes on its own? >> >> No, not unless you know that the port's implementation is sufficiently >> constrained. In general, reading from a port can involve thread >> switches and synchronization, and those are not allowed in callbacks >> from foreign libraries. > > Off hand, I think some some version of "sanitizing" an arbitrary port for use > from C is used by: > > - `racket/system` > ([here](https://github.com/racket/racket/blob/448b77a6629c68659e1360fbe9f9e1ecea078f9c/racket/collects/racket/system.rkt#L98-L114) > and > [here](https://github.com/racket/racket/blob/448b77a6629c68659e1360fbe9f9e1ecea078f9c/racket/collects/racket/system.rkt#L173-L193)), > where the implementation comes from `racket/private/streams`; > - `racket/draw`, for the various parts of Cairo that can read from or write > to ports, in `racket/draw/unsafe/callback` (and maybe something similar in > `racket/draw/private/write-bytes`?); and > - `readline`, which uses callbacks rather than creating file-stream ports. > > Would it make sense to expose some part of this functionality as a new > primitive? > > (I'm not familiar with all of the constraints in these use-cases: maybe > they're different enough that the answer is "no".) > > -Philip > -- > 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/010001799bd5ab46-d39f83a5-bb2d-49e5-8ce2-3315307742ac-00%40email.amazonses.com](https://groups.google.com/d/msgid/racket-users/010001799bd5ab46-d39f83a5-bb2d-49e5-8ce2-3315307742ac-00%40email.amazonses.com?utm_medium=email_source=footer). -- ~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/31b6053a-e1ed-3cd8-2e2b-d9ebb5a086d5%40sagegerard.com.
[racket-users] Cross-VM method for sending any input port to C runtime?
Hi all, I have a C shared library exposing a simplified interface for computing message digests. Here's a `while` that reads bytes using a callback. https://github.com/zyrolasting/xiden/blob/libcrypto/crypto/crypto.c#L46 A compatible callback provided by Racket might look like this. (λ (buf size) (let ([bytes-read (read-bytes! buf (sync variant))]) (if (eof-object? bytes-read) -1 bytes-read))) I'm also unsure if jumping between the Racket and C runtimes add much overhead, but I did it because it looks like `unsafe-port->file-descriptor` will only function as expected for file ports. Is there a cross-VM way to pass an arbitrary input port to the C runtime (e.g. via open-input-bytes), such that the C runtime can read bytes on its own? -- ~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/ee17c05f-3c89-3094-8f9a-d634ddb1d25d%40sagegerard.com.
Re: [racket-users] Racket News - Issue 50
Thank you for organizing the news and for bringing attention to so many cool projects out there. Definitely cause to celebrate! :) On 5/19/21 10:00 AM, Paulo Matos wrote: > Hello all, > > We have hit 50 issues! :) > https://racket-news.com/2021/05/racket-news-issue-50.html > > Enjoy! > > -- > Paulo Matos > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > [https://groups.google.com/d/msgid/racket-users/e0189491-1514-40c0-bdec-f26b1c8672e9n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/e0189491-1514-40c0-bdec-f26b1c8672e9n%40googlegroups.com?utm_medium=email_source=footer). -- ~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/3c788397-72b6-96f3-2d74-c1e6ac349207%40sagegerard.com.
Re: [racket-users] Redirecting shared lib stdout
Ah, you're right. I'm still acclimated to BC here. Disregard!
On 5/14/21 7:30 AM, Paulo Matos wrote:
>
> Sage Gerard writes:
>
>> I ran into this issue with rsound. I'm not sure how standard output can
>> be directly captured from a lower-level language in a Racket context
>> when that language can freely ignore the Racket printer and write
>> directly to STDOUT within the same operating system process.
>>
>> I'd hate to just add a "me too", but the only way quick way I could
>> think to handle that was to add another subprocess. If I were wanting to
>> solve the problem in one process, I'd probably extend Racket at the C
>> level and integrate my output with ports.
>>
>> https://docs.racket-lang.org/inside/Ports_and_the_Filesystem.html?q=c%20api
> I was thinking about this until I saw Jon's suggestion - specific to
> binaryen bindings.
>
> However, why would you use the C API (which seems to be mostly focused
> on BC)? My approach would be to wrap the function in C, redirect stdout
> using dup2 to a file and bind that wrapper in racket, read from the file
> and send to `current-output-port`.
>
> Kind regards,
>
> Paulo Matos
>
>> On 5/12/21 3:48 AM, Paulo Matos wrote:
>>> Hi,
>>>
>>> I have a shared library for which I am creating some bindings:
>>> https://github.com/pmatos/racket-binaryen
>>>
>>> There's a function BinaryenModulePrint that prints a WebAssembly module
>>> to stdout.
>>>
>>> When I wrap it in racket, if I do something like:
>>> (define mod ...)
>>> (with-output-to-string (lambda () (BinaryenModulePrint mod)))
>>>
>>> The return value will be "" and it will still print the module to
>>> stdout. I understand! However, I don't know how to solve it in Racket.
>>>
>>> In C, things seem easier because I have access to dup2 and pipe in case
>>> I need to redirect things, however in Racket all my attempts have
>>> failed.
>>>
>>> I have created the simple example:
>>> ```hello.c
>>> #include
>>>
>>> void hello(void) {
>>> printf("hello world!\n");
>>> }
>>> ```
>>>
>>> Compile with `gcc -shared -o hello.so hello.c`.
>>>
>>> Then:
>>> ```hello.rkt
>>> #lang racket/base
>>>
>>> (require racket/port
>>>ffi/unsafe
>>>ffi/unsafe/define)
>>>
>>> (define libhello (ffi-lib "/home/pmatos/dev/tmp/ffi-hello-world/hello.so"))
>>> (define-ffi-definer define-hello libhello)
>>> (define-hello hello (_fun -> _void))
>>> (with-output-to-string hello)
>>> ```
>>>
>>> Here's the issue! In C, I can do something like:
>>> ```hello-fix.c
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> extern void hello(void);
>>>
>>> int main(void) {
>>> int filefd = open("test.txt", O_WRONLY|O_CREAT, 0666);
>>> dup2(filefd, fileno(stdout));
>>> hello();
>>>
>>> return 0;
>>> }
>>> ```
>>> Compile with `gcc -o hello hello.c hello-fix.c`
>>>
>>> This will, send the output of hello() to a file. Now, in racket
>>> preferably I want to connect what is sent to raw stdout, fd 1, to
>>> current-output-port.
>>>
>>> My thought was that I could create a dup2 ffi binding, and use
>>> unsafe-port->file-descriptor to install the racket pipe file descriptor
>>> in stdout using the dup2 ffi binding but it doesn't work.
>>>
>>> And it doesn't work because the unsafe-port->file-descriptor returns #f,
>>> even though port-waiting-peer? return #f as well (which sort of hints
>>> that maybe the documentation of unsafe-port->file-descriptor is
>>> incomplete.
>>>
>>> The start of my attempt would look like this:
>>>
>>> ```hello.rkt
>>> #lang racket/base
>>>
>>> (require racket/port
>>>ffi/unsafe
>>>ffi/unsafe/define
>>>ffi/unsafe/port)
>>>
>>> (define libhello (ffi-lib "/home/pmatos/dev/tmp/ffi-hello-world/hello.so"))
>>>
>>> (define-ffi-definer define-libc (ffi-lib #f))
>>> (define-ffi-definer define-hello libhello)
>>>
>>> (define-libc dup2 (_fun _int _int -> _int))
>>> (define-hello hello (_fun -> _void))
>>>
>>> (defi
[racket-users] Re-defined constant when dynamically evaluating module forms
I have a program that takes a (trusted) module form as a list and then pulls out a provided value using this method. I used syntax/modread and generate a pseudorandom id for each value of `trusted` here. (define-namespace-anchor anchor) (define module-namespace (namespace-anchor->namespace anchor)) (define (add trusted) (eval trusted module-namespace) (dynamic-require `',(cadr trusted) 'data)) Full disclosure: I don't know how to do better. I figured that this wasn't the best way to do it to begin with because I get the following error under `raco test`'s runtime configuration. define-values: assignment disallowed; cannot re-define a constant constant: lifted/4 in module:'pkgdef1620873248 I don't know what "lifted/4" is. If I am bringing in module forms that I trust, what's the best way to dynamically evaluate them and pull out a provided value without running into that error? -- ~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/e0a048c8-77ac-5126-5bef-226ecbe906dc%40sagegerard.com.
Re: [racket-users] Redirecting shared lib stdout
I ran into this issue with rsound. I'm not sure how standard output can
be directly captured from a lower-level language in a Racket context
when that language can freely ignore the Racket printer and write
directly to STDOUT within the same operating system process.
I'd hate to just add a "me too", but the only way quick way I could
think to handle that was to add another subprocess. If I were wanting to
solve the problem in one process, I'd probably extend Racket at the C
level and integrate my output with ports.
https://docs.racket-lang.org/inside/Ports_and_the_Filesystem.html?q=c%20api
On 5/12/21 3:48 AM, Paulo Matos wrote:
> Hi,
>
> I have a shared library for which I am creating some bindings:
> https://github.com/pmatos/racket-binaryen
>
> There's a function BinaryenModulePrint that prints a WebAssembly module
> to stdout.
>
> When I wrap it in racket, if I do something like:
> (define mod ...)
> (with-output-to-string (lambda () (BinaryenModulePrint mod)))
>
> The return value will be "" and it will still print the module to
> stdout. I understand! However, I don't know how to solve it in Racket.
>
> In C, things seem easier because I have access to dup2 and pipe in case
> I need to redirect things, however in Racket all my attempts have
> failed.
>
> I have created the simple example:
> ```hello.c
> #include
>
> void hello(void) {
>printf("hello world!\n");
> }
> ```
>
> Compile with `gcc -shared -o hello.so hello.c`.
>
> Then:
> ```hello.rkt
> #lang racket/base
>
> (require racket/port
> ffi/unsafe
> ffi/unsafe/define)
>
> (define libhello (ffi-lib "/home/pmatos/dev/tmp/ffi-hello-world/hello.so"))
> (define-ffi-definer define-hello libhello)
> (define-hello hello (_fun -> _void))
> (with-output-to-string hello)
> ```
>
> Here's the issue! In C, I can do something like:
> ```hello-fix.c
> #include
> #include
> #include
> #include
>
> extern void hello(void);
>
> int main(void) {
>int filefd = open("test.txt", O_WRONLY|O_CREAT, 0666);
>dup2(filefd, fileno(stdout));
>hello();
>
>return 0;
> }
> ```
> Compile with `gcc -o hello hello.c hello-fix.c`
>
> This will, send the output of hello() to a file. Now, in racket
> preferably I want to connect what is sent to raw stdout, fd 1, to
> current-output-port.
>
> My thought was that I could create a dup2 ffi binding, and use
> unsafe-port->file-descriptor to install the racket pipe file descriptor
> in stdout using the dup2 ffi binding but it doesn't work.
>
> And it doesn't work because the unsafe-port->file-descriptor returns #f,
> even though port-waiting-peer? return #f as well (which sort of hints
> that maybe the documentation of unsafe-port->file-descriptor is
> incomplete.
>
> The start of my attempt would look like this:
>
> ```hello.rkt
> #lang racket/base
>
> (require racket/port
> ffi/unsafe
> ffi/unsafe/define
> ffi/unsafe/port)
>
> (define libhello (ffi-lib "/home/pmatos/dev/tmp/ffi-hello-world/hello.so"))
>
> (define-ffi-definer define-libc (ffi-lib #f))
> (define-ffi-definer define-hello libhello)
>
> (define-libc dup2 (_fun _int _int -> _int))
> (define-hello hello (_fun -> _void))
>
> (define-values (in out) (make-pipe))
>
> ;; FAILS because (unsafe-port-> ...) return #f
> (dup2 (unsafe-port->file-descriptor out) 1)
>
> ;;...
> ;; connect the other end of the port to current-output-port
> ;; and use a thread to copy-port
> ```
>
> Surely there must be a better way than this and I would be surprised if
> there isn't already something out there in a library but I haven't found
> anything yet. Any help here would be great.
>
> Thanks,
>
> --
> Paulo Matos
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/87r1icxuhi.fsf%40linki.tools.
--
~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/1abd8d17-a53c-b7fa-8983-57deec760e96%40sagegerard.com.
Re: [racket-users] Is there a good Racket DSL alternative to Image Magick?
I hope that has what Robert is looking for, but I don't recognize that speech. In fact, I have a false memory, because I'm not finding the speech I'm looking for on https://con.racket-lang.org/2018/#speakers On 5/11/21 10:19 AM, Bruce O'Neel wrote: > This might be it. > > [(seventh RacketCon): Leif Andersen -- Movies as Programs: The Story of a > Racket - > YouTube](https://www.youtube.com/watch?v=OZXslNVaCOQ=PLXr4KViVC0qIgkwFFzM-0we_aoOfAl16Y=3) > > 11 May 2021 15:30 Sage Gerard > [](mailto:s...@sagegerard.com) wrote: > >> I don't know of one off hand, but I believe RacketCon 2018 (?) included a >> presenter that showed a PostScript-like DSL for designers and artists. If >> pict not cover your needs, maybe dig into the presentations? >> >> Failing that, can you show what you'd hope the syntax would look like? That >> would probably help point you in the right direction, >> >> On 5/11/21 9:26 AM, Robert Haisfield wrote: >> >>> I have to do a bunch of .jpg and .png image resizings and was looking for a >>> programmatic way to do it. Is their a Racket DSL for this? -- >>> 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/0d576c32-7d4d-4944-9cbc-c12f04406fccn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/0d576c32-7d4d-4944-9cbc-c12f04406fccn%40googlegroups.com?utm_medium=email_source=footer). >> >> -- ~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/6e3aacdc-015b-2484-3bee-0c08e3fb612d%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/6e3aacdc-015b-2484-3bee-0c08e3fb612d%40sagegerard.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/1620742795-01b81de5d6862fd390ec60605ee3bc9d%40pckswarms.ch](https://groups.google.com/d/msgid/racket-users/1620742795-01b81de5d6862fd390ec60605ee3bc9d%40pckswarms.ch?utm_medium=email_source=footer). -- ~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/c911fc49-034e-7159-8a14-7fc5466122b0%40sagegerard.com.
Re: [racket-users] Is there a good Racket DSL alternative to Image Magick?
I don't know of one off hand, but I believe RacketCon 2018 (?) included a presenter that showed a PostScript-like DSL for designers and artists. If pict not cover your needs, maybe dig into the presentations? Failing that, can you show what you'd hope the syntax would look like? That would probably help point you in the right direction, On 5/11/21 9:26 AM, Robert Haisfield wrote: > I have to do a bunch of .jpg and .png image resizings and was looking for a > programmatic way to do it. Is their a Racket DSL for this? -- > 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/0d576c32-7d4d-4944-9cbc-c12f04406fccn%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/0d576c32-7d4d-4944-9cbc-c12f04406fccn%40googlegroups.com?utm_medium=email_source=footer). -- ~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/6e3aacdc-015b-2484-3bee-0c08e3fb612d%40sagegerard.com.
Re: [racket-users] Injecting local contracts for prefab constructors
I hope so! That's what I understood option B to mean. I could adjust the define-message macro according to the info in Ryan and Phillip's attachments, but I'm not well-educated on trapping struct operations. Phillip: Your example and email gives me the impression that when you add a chaperone, you can proxy all struct operations, including the gap left by the chaperone for the constructor. Is that true? The macro I'd want has to preserve all characteristics of all generated struct bindings, which makes things tricky since the options for `struct` normally operate on a strict subset. e.g. #:[extra-]constructor-name seems to operate on the constructor alone, and the #:extra- variant does not preserve the match-expander/super-id characteristics. #:constructor-name is closer, but the original constructor id is no longer directly callable by the declaring module. On 5/10/21 7:05 AM, Hendrik Boom wrote: > On Sun, May 09, 2021 at 10:23:34PM +0000, Sage Gerard wrote: > >> I have a project with 57 prefab structure types. I need to construct >> instances using a local contract (module level contracts do not fit my needs >> here). Since I cannot define guards, the solution is easy enough. >> >> (struct foo (num) #:prefab) >> (define/contract make-foo (-> real? foo?) foo) >> >> Problem: I already have a few hundred constructor calls without >> contracts. I could either A) rewrite them all to use contracted >> constructors, or B) attach local contracts in a sweet spot so that I >> don't have to rewrite anything else. > > Is there any chance you could do the "rewriting" in a macro so you > wouldn't actually have to change the few hundred constructor calls > when you use option A)? > > -- hendrik > >> I prefer option B, but it doesn't look like I can attach a local contract to >> a constructor with `struct` alone, or even with an impersonator. When I hack >> around to rebind or hide the constructor's identifier, I break compatibility >> with `match` and `defstruct*`. >> >> If you were in my position, what would you do? >> >> -- >> >> ~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/0a16cfbe-4789-a939-796e-5f6f9da21626%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/20210510110509.cpg6jnil6th7xbsi%40topoi.pooq.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/94e81fc9-e8a1-e677-bf0e-b49e597313b9%40sagegerard.com.
Re: [racket-users] Injecting local contracts for prefab constructors
Almost forgot, just in case someone asks: I want to avoid checking for invariant violations when I print. That would entail checking a bunch of values in accumulated program output, where it would be awkward to do something non-printing related, let alone raise an error. When I am printing logs, all invariant violations come down to what went a constructor, because all program output is encoded as prefab structures. That's why I want to raise any errors on instantiation. On 5/9/21 8:55 PM, Sage Gerard wrote: > Of course, if you're okay with a longer email. Before that, thank you both > for volunteering your time to code something out. I enjoyed running into a > `define-module-boundary-contract` in the wild for the first time. > > I sometimes print output in a (read)able form because I like analyzing my > logs. The data I print includes prefab structures, with type ids matching the > topic they cover or the statements they make. You can see that I declare > prefab structure (sub)types cutely labeled "messages" here. [1] > > The idea is that I can either print (for example) a $package:output:built > instance as a localized string, or just toss the instance itself into > writeln. When I read instances back from a port, the struct accessors will > help me filter and match. Hopefully all this shows where my head is. > > Now for the problem. Look at [2], but don't worry about what it means. I just > wanted you to see the constructor call in the exception handler. If I made a > mistake and wrote that line such the exception was placed directly in the > instance, then I wouldn't be able to (read) that instance back later! I > cannot allow #<...> forms in my output, or some symbol soup that happens to > be readable, but doesn't constitute the value it used to be. > > TL;DR I want to protect the invariant `(equal? V (read (open-input-string (~s > V` for each V I print to an output port. > > Finally, as to why I didn't want the module boundary contract. The module > that declares prefab structure types is also primarily responsible for > creating all instances of those types. I rarely cross module boundaries when > applying the constructors. > > [1]: https://github.com/zyrolasting/xiden/blob/master/package.rkt#L49 > [2]: https://github.com/zyrolasting/xiden/blob/master/security.rkt#L100 > > On 5/9/21 8:02 PM, Philip McGrath wrote: > >> Here's another minimally-tested sample implementation. A more robust >> solution might try to chaperone the struct type, as well, to protect >> reflective access to the constructor—but I wonder if that really makes sense >> when you are working with prefab structs. If you can explain more about your >> requirements, it might be possible to suggest better approaches. >> >> On Sun, May 9, 2021 at 7:57 PM Ryan Culpepper wrote: >> >>> I'm not clear on what constraints you're working under with respect to >>> modules, but hopefully you can adapt this to your needs. >>> >>> One option is to use a combination of `define-module-boundary-contract` (or >>> `define/contract`) and `define-match-expander` to bind a name that can be >>> used as a contracted constructor and as a match pattern. (If you want to >>> extend the struct type, though, you still need to use the real one.) >>> >>> Another option would be to "forge" a new compile-time struct-info based on >>> the original struct-info but replacing the constructor. >>> >>> Minimally tested sample implementations attached. >>> >>> Ryan >>> >>> On Mon, May 10, 2021 at 12:23 AM Sage Gerard wrote: >>> >>>> I have a project with 57 prefab structure types. I need to construct >>>> instances using a local contract (module level contracts do not fit my >>>> needs here). Since I cannot define guards, the solution is easy enough. >>>> >>>> (struct foo (num) #:prefab) >>>> (define/contract make-foo (-> real? foo?) foo) >>>> >>>> Problem: I already have a few hundred constructor calls without contracts. >>>> I could either A) rewrite them all to use contracted constructors, or B) >>>> attach local contracts in a sweet spot so that I don't have to rewrite >>>> anything else. >>>> >>>> I prefer option B, but it doesn't look like I can attach a local contract >>>> to a constructor with `struct` alone, or even with an impersonator. When I >>>> hack around to rebind or hide the constructor's identifier, I break >>>> compatibility with `match` and `defstruct*`. >>>> >>>> If y
Re: [racket-users] Injecting local contracts for prefab constructors
Of course, if you're okay with a longer email. Before that, thank you both for volunteering your time to code something out. I enjoyed running into a `define-module-boundary-contract` in the wild for the first time. I sometimes print output in a (read)able form because I like analyzing my logs. The data I print includes prefab structures, with type ids matching the topic they cover or the statements they make. You can see that I declare prefab structure (sub)types cutely labeled "messages" here. [1] The idea is that I can either print (for example) a $package:output:built instance as a localized string, or just toss the instance itself into writeln. When I read instances back from a port, the struct accessors will help me filter and match. Hopefully all this shows where my head is. Now for the problem. Look at [2], but don't worry about what it means. I just wanted you to see the constructor call in the exception handler. If I made a mistake and wrote that line such the exception was placed directly in the instance, then I wouldn't be able to (read) that instance back later! I cannot allow #<...> forms in my output, or some symbol soup that happens to be readable, but doesn't constitute the value it used to be. TL;DR I want to protect the invariant `(equal? V (read (open-input-string (~s V` for each V I print to an output port. Finally, as to why I didn't want the module boundary contract. The module that declares prefab structure types is also primarily responsible for creating all instances of those types. I rarely cross module boundaries when applying the constructors. [1]: https://github.com/zyrolasting/xiden/blob/master/package.rkt#L49 [2]: https://github.com/zyrolasting/xiden/blob/master/security.rkt#L100 On 5/9/21 8:02 PM, Philip McGrath wrote: > Here's another minimally-tested sample implementation. A more robust solution > might try to chaperone the struct type, as well, to protect reflective access > to the constructor—but I wonder if that really makes sense when you are > working with prefab structs. If you can explain more about your requirements, > it might be possible to suggest better approaches. > > On Sun, May 9, 2021 at 7:57 PM Ryan Culpepper wrote: > >> I'm not clear on what constraints you're working under with respect to >> modules, but hopefully you can adapt this to your needs. >> >> One option is to use a combination of `define-module-boundary-contract` (or >> `define/contract`) and `define-match-expander` to bind a name that can be >> used as a contracted constructor and as a match pattern. (If you want to >> extend the struct type, though, you still need to use the real one.) >> >> Another option would be to "forge" a new compile-time struct-info based on >> the original struct-info but replacing the constructor. >> >> Minimally tested sample implementations attached. >> >> Ryan >> >> On Mon, May 10, 2021 at 12:23 AM Sage Gerard wrote: >> >>> I have a project with 57 prefab structure types. I need to construct >>> instances using a local contract (module level contracts do not fit my >>> needs here). Since I cannot define guards, the solution is easy enough. >>> >>> (struct foo (num) #:prefab) >>> (define/contract make-foo (-> real? foo?) foo) >>> >>> Problem: I already have a few hundred constructor calls without contracts. >>> I could either A) rewrite them all to use contracted constructors, or B) >>> attach local contracts in a sweet spot so that I don't have to rewrite >>> anything else. >>> >>> I prefer option B, but it doesn't look like I can attach a local contract >>> to a constructor with `struct` alone, or even with an impersonator. When I >>> hack around to rebind or hide the constructor's identifier, I break >>> compatibility with `match` and `defstruct*`. >>> >>> If you were in my position, what would you do? >>> >>> -- >>> >>> ~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/0a16cfbe-4789-a939-796e-5f6f9da21626%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/0a16cfbe-4789-a939-796e-5f6f9da21626%40sagegerard.com?utm_medium=email_source=footer). >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket
[racket-users] Injecting local contracts for prefab constructors
I have a project with 57 prefab structure types. I need to construct instances using a local contract (module level contracts do not fit my needs here). Since I cannot define guards, the solution is easy enough. (struct foo (num) #:prefab) (define/contract make-foo (-> real? foo?) foo) Problem: I already have a few hundred constructor calls without contracts. I could either A) rewrite them all to use contracted constructors, or B) attach local contracts in a sweet spot so that I don't have to rewrite anything else. I prefer option B, but it doesn't look like I can attach a local contract to a constructor with `struct` alone, or even with an impersonator. When I hack around to rebind or hide the constructor's identifier, I break compatibility with `match` and `defstruct*`. If you were in my position, what would you do? -- ~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/0a16cfbe-4789-a939-796e-5f6f9da21626%40sagegerard.com.
Re: [racket-users] Racket - How to define a function that can be used both in syntax transformers and ordinary code?
Wow, I really butchered a sentence. Let me try it again. Old: "That is, there's a compile-time "pass" where Racket is focuses on the code you write and what they can see" New: "That is, there's a compile-time "pass" where Racket focuses on replacing used macros with new code, and that pass has its own set of bindings that only that pass can see." ~slg Original Message ---- On May 9, 2021, 3:14 PM, Sage Gerard wrote: > I'm stretching details a bit, but maybe it would help to think of phases as > "passes." That is, there's a compile-time "pass" where Racket is focuses on > the code you write and what they can see. These passes continue until the > Racket program is fully expanded. > > Where things get tricky is remembering that when you create a binding at one > phase, it is available for that phase. It's a little easier to tell the > difference across module boundaries. > > Let's say you have a library that defines your functions at phase 0, or > runtime. > > ; lib.rkt > #lang racket/base > (provide (all-defined-out)) > (define (my-function x) (+ x 1)) (define (my-macro stx) > (datum->syntax stx (my-function (cadr (syntax->datum stx) > > Now let's have another module use the syntax transformer. I'm handwaving > around some details because `define-syntax` and `define-for-syntax` are not > the same, but I'd like to focus on illustrating how phases operate. > > #lang racket/base > (require "lib.rkt") > (my-macro #'(x 1)) > > The reason this works is because all the bindings are in the same phase. That > is, everything was defined in the same pass. Now let's shift it all one phase > up, which will break the program because it no longer sees my-macro, or even > enough of racket/base to apply functions. > > #lang racket/base > (require (for-syntax "lib.rkt")) > (my-macro #'(x 1)) > > Right now `my-macro` is in phase 1 relative to this module. So we have to > "lift" the rest of the code to match. > > #lang racket/base > (require (for-syntax racket/base "lib.rkt")) > (begin-for-syntax (my-macro #'(x 1))) > > This still isn't particularly useful because most of the time, a module > manages multiple phases at once. It can be harder to visualize, but the > principle is the same: When code runs at a certain phase, is everything that > code needs to run also available at that phase? It's still just Racket. I > like to visualize it as running at a different "layer" on top of the code > that I know will eventually execute at runtime. Here's another example that > can help drive the point home. Run it using the `racket` command. > > #lang racket/base > (require (for-syntax racket/base)) > > (define a "foo") > (define-for-syntax a 1) > > (displayln a) > (begin-for-syntax (displayln a)) > > Notice that you see "1" first, before "foo", even though the displayln for > the "1" is after the displayln for "foo". > > So to answer your question, if you have something you want available across > phases, you need to bind that same value across phases. Here's a simplified > example. > > #lang racket/base > (require (for-syntax racket/base)) > > (define-syntax-rule (define-across-phases id v) > (begin (define id v) > (define-for-syntax id v))) > > (define-across-phases a 1) > > (displayln a) > > (begin-for-syntax (displayln a)) > > Notice that I leverage a phase to define an identifier twice: Once for the > current phase, and once for the phase +1 "layer" up. > > But... I normally do bind across phases using (require) with both for-syntax > and without a phase shift. e.g. (require "lib.rkt" (for-syntax "lib.rkt")). > There are times I'll need cross-phase definitions only within one module, but > it doesn't come up much for me. > > Hope this helps. > > On 5/9/21 3:53 AM, Yushuo Xiao wrote: > >> I am using syntax transformers to define macros in Racket. I want to create >> some helper functions to help me manipulate the syntax. However, the >> functions I defined outside the syntax transformer are not available inside >> the syntax transformer. For example, in the following code >> >> (define (my-function x) (+ x 1)) >> >> (define-syntax my-macro >> (lambda (stx) >> (datum->syntax stx (my-function (cadr (syntax->datum stx)) >> >> I got the error "my-function: reference to an unbound identifier at phase: >> 1; the transformer environment". >> >> After some searching, I am able to write the following code so that &
Re: [racket-users] Racket - How to define a function that can be used both in syntax transformers and ordinary code?
I'm stretching details a bit, but maybe it would help to think of phases as "passes." That is, there's a compile-time "pass" where Racket is focuses on the code you write and what they can see. These passes continue until the Racket program is fully expanded. Where things get tricky is remembering that when you create a binding at one phase, it is available for that phase. It's a little easier to tell the difference across module boundaries. Let's say you have a library that defines your functions at phase 0, or runtime. ; lib.rkt #lang racket/base (provide (all-defined-out)) (define (my-function x) (+ x 1)) (define (my-macro stx) (datum->syntax stx (my-function (cadr (syntax->datum stx) Now let's have another module use the syntax transformer. I'm handwaving around some details because `define-syntax` and `define-for-syntax` are not the same, but I'd like to focus on illustrating how phases operate. #lang racket/base (require "lib.rkt") (my-macro #'(x 1)) The reason this works is because all the bindings are in the same phase. That is, everything was defined in the same pass. Now let's shift it all one phase up, which will break the program because it no longer sees my-macro, or even enough of racket/base to apply functions. #lang racket/base (require (for-syntax "lib.rkt")) (my-macro #'(x 1)) Right now `my-macro` is in phase 1 relative to this module. So we have to "lift" the rest of the code to match. #lang racket/base (require (for-syntax racket/base "lib.rkt")) (begin-for-syntax (my-macro #'(x 1))) This still isn't particularly useful because most of the time, a module manages multiple phases at once. It can be harder to visualize, but the principle is the same: When code runs at a certain phase, is everything that code needs to run also available at that phase? It's still just Racket. I like to visualize it as running at a different "layer" on top of the code that I know will eventually execute at runtime. Here's another example that can help drive the point home. Run it using the `racket` command. #lang racket/base (require (for-syntax racket/base)) (define a "foo") (define-for-syntax a 1) (displayln a) (begin-for-syntax (displayln a)) Notice that you see "1" first, before "foo", even though the displayln for the "1" is after the displayln for "foo". So to answer your question, if you have something you want available across phases, you need to bind that same value across phases. Here's a simplified example. #lang racket/base (require (for-syntax racket/base)) (define-syntax-rule (define-across-phases id v) (begin (define id v) (define-for-syntax id v))) (define-across-phases a 1) (displayln a) (begin-for-syntax (displayln a)) Notice that I leverage a phase to define an identifier twice: Once for the current phase, and once for the phase +1 "layer" up. But... I normally do bind across phases using (require) with both for-syntax and without a phase shift. e.g. (require "lib.rkt" (for-syntax "lib.rkt")). There are times I'll need cross-phase definitions only within one module, but it doesn't come up much for me. Hope this helps. On 5/9/21 3:53 AM, Yushuo Xiao wrote: > I am using syntax transformers to define macros in Racket. I want to create > some helper functions to help me manipulate the syntax. However, the > functions I defined outside the syntax transformer are not available inside > the syntax transformer. For example, in the following code > > (define (my-function x) (+ x 1)) > > (define-syntax my-macro > (lambda (stx) > (datum->syntax stx (my-function (cadr (syntax->datum stx)) > > I got the error "my-function: reference to an unbound identifier at phase: 1; > the transformer environment". > > After some searching, I am able to write the following code so that > `my-function` is available inside the syntax transformer. > > (begin-for-syntax > (define (my-function x) (+ x 1))) > (provide (for-syntax my-function)) > > (define-syntax my-macro > (lambda (stx) > (datum->syntax stx (my-function (cadr (syntax->datum stx)) > > But the problem is, `my-function` is not available outside the syntax > transformer this time. Sometimes I want to check those helper functions in > ordinary code, so I need to be able to call it from both inside and outside > the syntax transformer, just like the function `cadr`. How can I achieve that? > > I know my question has something to do with Racket's syntax model, in > particular the concept of "phase level", but I never really understand it. If > you could provide some easy-to-follow tutorials explaining it I would even be > more grateful. > -- > 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 >
Re: [racket-users] Checking for fallbacks in generic contracts
For the time being I've decided to use this macro and attach contracts to the fallbacks a different way. Please let me know if there's a better solution. (define-syntax-rule (I/weak/c [method-id method-contract] ...) (I/c [method-id (or/c #f method-contract)] ...) On 4/17/21 10:48 PM, Sage Gerard wrote: > Playing with this program. Its output is in the comments. > > ; /tmp/gen.rkt:9:10: assertion violation > ; expected: a procedure > ; given: #f > ; in: method m > ; (I/c (m (-> I? 1))) > ; [...removed the rest of the error...] > ; 1 > > (module gen-contracts racket/base > (require racket/contract racket/exn racket/generic) > (define-generics I [m I] #:fallbacks [(define (m _) 1)]) > (struct noop () #:methods gen:I []) > (struct impl () #:methods gen:I [(define (m _) 1)]) > (define (try ctor) > (displayln > (with-handlers ([exn:fail:contract? exn->string]) > (m (invariant-assertion (I/c [m (-> I? 1)]) (ctor)) > (try noop) > (try impl)) > > I expected the output to be just two "1" lines, because I assumed the > contract combinator from `define-generics` would consider fallback > implementations. I do think it makes sense for `I/c` to fail to apply a > contract to a method in `noop` because `noop` doesn't implement `m`. But I > think the combinator reuses some logic from whatever is making > `#:defined-predicate` work, since it represents missing methods as `#f`, and > doesn't look at the fallbacks. > > But... I wanted a contract that's okay with a missing method if there's a > fallback. The only contracts I can write with the `I/c` combinator seem > require me to either A) write repetitive method definitions that just parrot > the fallback, or B) write its method contracts like `(I/c [m (or/c #f (-> I? > 1))])`, which feels icky. > > Apologies if I'm totally off the mark or just missed something in the manual, > but is there a way to define a contract for a generics implementation that > won't complain if it sees a fallback for a missing method? > > -- > ~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/fed6c561-881b-08af-4318-25750f198133%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/fed6c561-881b-08af-4318-25750f198133%40sagegerard.com?utm_medium=email_source=footer). -- ~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/747816e3-44de-9af8-a284-873007c4e57d%40sagegerard.com.
[racket-users] Checking for fallbacks in generic contracts
Playing with this program. Its output is in the comments. ; /tmp/gen.rkt:9:10: assertion violation ; expected: a procedure ; given: #f ; in: method m ; (I/c (m (-> I? 1))) ; [...removed the rest of the error...] ; 1 (module gen-contracts racket/base (require racket/contract racket/exn racket/generic) (define-generics I [m I] #:fallbacks [(define (m _) 1)]) (struct noop () #:methods gen:I []) (struct impl () #:methods gen:I [(define (m _) 1)]) (define (try ctor) (displayln (with-handlers ([exn:fail:contract? exn->string]) (m (invariant-assertion (I/c [m (-> I? 1)]) (ctor)) (try noop) (try impl)) I expected the output to be just two "1" lines, because I assumed the contract combinator from `define-generics` would consider fallback implementations. I do think it makes sense for `I/c` to fail to apply a contract to a method in `noop` because `noop` doesn't implement `m`. But I think the combinator reuses some logic from whatever is making `#:defined-predicate` work, since it represents missing methods as `#f`, and doesn't look at the fallbacks. But... I wanted a contract that's okay with a missing method if there's a fallback. The only contracts I can write with the `I/c` combinator seem require me to either A) write repetitive method definitions that just parrot the fallback, or B) write its method contracts like `(I/c [m (or/c #f (-> I? 1))])`, which feels icky. Apologies if I'm totally off the mark or just missed something in the manual, but is there a way to define a contract for a generics implementation that won't complain if it sees a fallback for a missing method? -- ~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/fed6c561-881b-08af-4318-25750f198133%40sagegerard.com.
Re: [racket-users] Cannot attach submodule to namespace
No worries. Thank you for the help as always. On 4/16/21 2:11 PM, Matthew Flatt wrote: > Yes, attaching a module instances doesn't `require` it anywhere. > > (Sorry --- I didn't look at your program closely enough to work out > whether you meant to require it, start out with a non-empty namespace, > or something else.) > > At Fri, 16 Apr 2021 18:02:47 +, Sage Gerard wrote: >> Yes. The error changed to "hello: unbound identifier, also no #%app ..." >> for me, so I also had to add `(namespace-require (quote-module-path >> restricted) ns)` to get it working. >> >> Were you expecting that I had to do that too? The docs for the >> `make-base-*-namespace` procedures make it sound like attaching is >> sufficient. >> >> >> On 4/16/21 1:51 PM, Matthew Flatt wrote: >>> The name `'restricted` is allowed as a shorthand in `require` because >>> `require` knows what module it's in. The `namespace-attach-module` >>> function does not try to infer a module context from the namespace >>> argument; it uses the namespace argument only for its registry. So, you >>> need to use the full name of the submodule. >>> >>> The `quote-module-path` form expands to a full name using its syntactic >>> context (i.e., the enclsoing module's name), so >>> >>> (namespace-attach-module (namespace-anchor->namespace a) >>> (quote-module-path restricted) >>> ns) >>> >>> is probably what you want. >>> >>> >>> At Fri, 16 Apr 2021 17:29:28 +, Sage Gerard wrote: >>>> Why does this raise "namespace-attach-module: module not declared (in >>>> the source namespace)"? >>>> >>>> I expected that the `restricted` submodule would be both declared and >>>> instantiated by the time control reached `namespace-attach-module`. >>>> >>>> (module anon racket/base >>>> (module restricted racket/base >>>> (provide #%app #%datum #%top hello) >>>> (define (hello h) h)) >>>> (require 'restricted) >>>> (define ns (make-empty-namespace)) >>>> (define-namespace-anchor a) >>>> (namespace-attach-module (namespace-anchor->namespace a) ''restricted >>>> ns) >>>> (displayln (eval '(hello "world") ns))) >>>> >>>> -- >>>> ~slg >> -- >> ~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/e11dff02-0a27-06bd-9b4c-128f15e65 >> 849%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/20210416121152.2b0%40sirmail.smtps.cs.utah.edu. -- ~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/8325d0ca-999c-e972-49c8-d6d46994069c%40sagegerard.com.
Re: [racket-users] Cannot attach submodule to namespace
Yes. The error changed to "hello: unbound identifier, also no #%app ..." for me, so I also had to add `(namespace-require (quote-module-path restricted) ns)` to get it working. Were you expecting that I had to do that too? The docs for the `make-base-*-namespace` procedures make it sound like attaching is sufficient. On 4/16/21 1:51 PM, Matthew Flatt wrote: > The name `'restricted` is allowed as a shorthand in `require` because > `require` knows what module it's in. The `namespace-attach-module` > function does not try to infer a module context from the namespace > argument; it uses the namespace argument only for its registry. So, you > need to use the full name of the submodule. > > The `quote-module-path` form expands to a full name using its syntactic > context (i.e., the enclsoing module's name), so > >(namespace-attach-module (namespace-anchor->namespace a) > (quote-module-path restricted) > ns) > > is probably what you want. > > > At Fri, 16 Apr 2021 17:29:28 +, Sage Gerard wrote: >> Why does this raise "namespace-attach-module: module not declared (in >> the source namespace)"? >> >> I expected that the `restricted` submodule would be both declared and >> instantiated by the time control reached `namespace-attach-module`. >> >> (module anon racket/base >> (module restricted racket/base >> (provide #%app #%datum #%top hello) >> (define (hello h) h)) >> (require 'restricted) >> (define ns (make-empty-namespace)) >> (define-namespace-anchor a) >> (namespace-attach-module (namespace-anchor->namespace a) ''restricted ns) >> (displayln (eval '(hello "world") ns))) >> >> -- >> ~slg -- ~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/e11dff02-0a27-06bd-9b4c-128f15e65849%40sagegerard.com.
[racket-users] Cannot attach submodule to namespace
Why does this raise "namespace-attach-module: module not declared (in the source namespace)"? I expected that the `restricted` submodule would be both declared and instantiated by the time control reached `namespace-attach-module`. (module anon racket/base (module restricted racket/base (provide #%app #%datum #%top hello) (define (hello h) h)) (require 'restricted) (define ns (make-empty-namespace)) (define-namespace-anchor a) (namespace-attach-module (namespace-anchor->namespace a) ''restricted ns) (displayln (eval '(hello "world") ns))) -- ~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/4a99db87-0ddb-14a7-7240-ec7f03dc9310%40sagegerard.com.
[racket-users] Is it possible to write a macro that acts like namespace-set-variable-value! for implicit forms?
I'd like to use `eval` in terms of a restricted namespace including `#%datum` and `#%app`. For minimalism and security, I want to build that namespace starting from an empty one, without using racket/sandbox, security guards, or attaching racket/base. Under these restrictions, I would normally attach a custom module providing only what I care to expose to the code under evaluation. That's not a problem, but is it possible to avoid creating the extra module and imperatively attach implicit forms? I'm thinking of a macro that behaves like `namespace-set-variable-value!`, but allows implicit forms. -- ~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/f9120eda-8563-dafa-3466-b86c028bae88%40sagegerard.com.
Re: [racket-users] How do I, a client, get a copy of an untrusted server certificate?
Ok, much appreciated. For those reading, I'm pivoting to this phrasing. -- Could not connect to example.com due to an unverified certificate. You can address this by downloading the certificate from a source your operating system trusts (to mitigate man-in-the-middle attacks), then adding the certificate to XIDEN_TRUST_CERTIFICATES. Original exception follows: ... On 4/12/21 10:43 AM, Ryan Culpepper wrote: > Yes, that's right. > > Ryan > > On Mon, Apr 12, 2021 at 4:23 PM Sage Gerard wrote: > >> Understood, thank you. By "trusted location," do you mean a server with a >> certificate that operating systems already trust? >> >> On 4/12/21 10:15 AM, Ryan Culpepper wrote: >> >>> Racket does not provide a way to do that. >>> >>> You can use `openssl s_client -showcerts -connect host:port < /dev/null` to >>> get the server's certificate chain in PEM form (with other logs around it). >>> Of course, an attacker could intercept the connection and send you their CA >>> certificate instead. It would be safer if example.com published their >>> certificate in a (standardly) trusted location. >>> >>> If you do something like this, consider mitigating the danger by having the >>> user add the certificate to a separate location managed by your application >>> rather than the OS trust store. You can extend the >>> `ssl-default-verify-sources` parameter to point to a file containing >>> additional root certificates. >>> >>> Ryan >>> >>> On Mon, Apr 12, 2021 at 3:20 PM Sage Gerard wrote: >>> >>>> When ssl-connect fails due to an untrusted certificate, this error is >>>> raised: >>>> >>>> ssl-connect: connect failed (error:1416F086:SSL >>>> routines:tls_process_server_certificate:certificate verify failed) >>>> >>>> I'd like to give the user a more helpful error, like this: >>>> >>>> Could not connect due to an untrusted certificate. In many cases, it is >>>> not advisable to proceed. However, if you trust the server at >>>> example.com, add /tmp/example.com.cert to your trusted certificates >>>> using this guide: >>>> >>>> How can I get a copy of the offending certificate so that I can do this? >>>> >>>> -- >>>> ~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](mailto:racket-users%2bunsubscr...@googlegroups.com). >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-users/8a55256d-71ed-b47f-5b92-c958438c5659%40sagegerard.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/8edbd1fd-715d-a730-5659-3731518c5fba%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/8edbd1fd-715d-a730-5659-3731518c5fba%40sagegerard.com?utm_medium=email_source=footer). -- ~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/b2afc3a5-876e-61d8-a475-f078306dfccd%40sagegerard.com.
Re: [racket-users] How do I, a client, get a copy of an untrusted server certificate?
Understood, thank you. By "trusted location," do you mean a server with a certificate that operating systems already trust? On 4/12/21 10:15 AM, Ryan Culpepper wrote: > Racket does not provide a way to do that. > > You can use `openssl s_client -showcerts -connect host:port < /dev/null` to > get the server's certificate chain in PEM form (with other logs around it). > Of course, an attacker could intercept the connection and send you their CA > certificate instead. It would be safer if example.com published their > certificate in a (standardly) trusted location. > > If you do something like this, consider mitigating the danger by having the > user add the certificate to a separate location managed by your application > rather than the OS trust store. You can extend the > `ssl-default-verify-sources` parameter to point to a file containing > additional root certificates. > > Ryan > > On Mon, Apr 12, 2021 at 3:20 PM Sage Gerard wrote: > >> When ssl-connect fails due to an untrusted certificate, this error is >> raised: >> >> ssl-connect: connect failed (error:1416F086:SSL >> routines:tls_process_server_certificate:certificate verify failed) >> >> I'd like to give the user a more helpful error, like this: >> >> Could not connect due to an untrusted certificate. In many cases, it is >> not advisable to proceed. However, if you trust the server at >> example.com, add /tmp/example.com.cert to your trusted certificates >> using this guide: >> >> How can I get a copy of the offending certificate so that I can do this? >> >> -- >> ~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](mailto:racket-users%2bunsubscr...@googlegroups.com). >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/8a55256d-71ed-b47f-5b92-c958438c5659%40sagegerard.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/8edbd1fd-715d-a730-5659-3731518c5fba%40sagegerard.com.
[racket-users] How do I, a client, get a copy of an untrusted server certificate?
When ssl-connect fails due to an untrusted certificate, this error is raised: ssl-connect: connect failed (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed) I'd like to give the user a more helpful error, like this: Could not connect due to an untrusted certificate. In many cases, it is not advisable to proceed. However, if you trust the server at example.com, add /tmp/example.com.cert to your trusted certificates using this guide: How can I get a copy of the offending certificate so that I can do this? -- ~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/8a55256d-71ed-b47f-5b92-c958438c5659%40sagegerard.com.
Re: [racket-users] Upgrading installer verification
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.
Re: [racket-users] Upgrading installer verification
Thank you. On 4/1/21 12:42 PM, Sam Tobin-Hochstadt wrote: > 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. -- ~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/f7d2c349-27c1-130d-e6bd-98526ccc691b%40sagegerard.com.
[racket-users] Upgrading installer verification
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.
Re: [racket-users] New package announce: value-evt
I compared the info.rkt files between your thread-with-id library and value-evt. One thing that stands out is the extra empty list in value-evt. I'm wondering if that hid defaults that would otherwise be provided. https://github.com/dstorrs/value-evt/blob/master/info.rkt https://github.com/dstorrs/thread-with-id/blob/master/info.rkt If that's not it, I'd have to take time after work to look more closely. On 4/1/21 12:31 PM, David Storrs wrote: > On Thu, Apr 1, 2021 at 12:18 PM Sage Gerard wrote: >> Neat! Thanks for this. Did you make sure to list your scribble file in >> `scribblings` under info.rkt? >> > I did, yes. > > Although, now that you mention it, when I do raco setup value-evt it > does all the things, says "Building documentation" but the .html file > did not appear in the directory and it's not linked into my local doc > set. I hadn't noticed because I had previously created the file > directly using 'scribble value-evt.scrbl' What might I have done > wrong? > >> On 4/1/21 12:12 PM, David Storrs wrote: >>> Wraps an arbitrary value into a synchronizable event. The >>> synchronization result of the event is the original value, with two >>> exceptions: procedures sync to their return value and lists sync >>> recursively. Both of these values can be disabled via keywords. >>> >>> The package server is telling me that it needs documentation. That >>> confuses me since it has a .scrbl file and the .html was already >>> present in the repository. ISTR that the docs are only built once >>> every 24 hours, so presumably they will pop up at some point? >>> >>> Examples: >>> >>> ; value-evts are both evt? and value-evt?. They sync to their argument >>>> (define e (value-evt 9)) >>>> e >>> # >>>> (evt? e) >>> #t >>>> (value-evt? e) >>> #t >>>> (sync e) >>> 9 >>> ; >>> ; By default, syncing on a procedure syncs to the return value >>>> (define proc (lambda () (+ 2 2))) >>>> (sync (value-evt proc)) >>> 4 >>> ; >>> ; You can instead get the procedure itself back >>>> (sync (value-evt proc #:eval-proc? #f)) >>> # >>> ; >>> ; It's not a problem to specify #:eval-proc? on something that isn't a >>> procedure >>>> (sync (value-evt "eval-proc? keyword is ignored for non-proc" #:eval-proc? >>>> #f)) >>> "eval-proc? keyword is ignored for non-proc" >>> ; >>> ; eventify always returns an evt >>> ; Things that are evts are unchanged >>>> (define ch (make-channel)) >>>> (evt? ch) >>> #t >>>> (eq? ch (eventify ch)) >>> #t >>> ; >>> ; Things that are not evts become value-evts >>>> (evt? 'bob) >>> #f >>>> (evt? (eventify 'bob)) >>> #t >>> ; >>> ; by default, value-evts containing a list sync recursively >>>> (let ([result-ch (make-channel)] >>> [arg-ch1 (make-channel)] >>> [arg-ch2 (make-channel)]) >>> (void (thread (λ () (channel-put result-ch (sync (value-evt (list >>> arg-ch1 arg-ch2))) >>> (channel-put arg-ch1 'arg1-ch-ok) >>> (channel-put arg-ch2 'arg2-ch-ok) >>> (sync result-ch)) >>> '(arg1-ch-ok arg2-ch-ok) >>> ; >>> ; You can ask for it to return the original list >>>> (let ([arg-ch1 (make-channel)] >>> [arg-ch2 (make-channel)]) >>> (sync (value-evt (list arg-ch1 arg-ch2) #:recurse-lists? #f))) >>> '(# #) >>> ; >>> ; all-evt is the same as value-evt but takes a rest argument >>> ; so you don't have to supply your own list >>>> (let ([result-ch (make-channel)] >>> [arg-ch1 (make-channel)] >>> [arg-ch2 (make-channel)]) >>> (define e (all-evt arg-ch1 arg-ch2)) >>> (printf "all-evt returns: ~v" e) >>> (void (thread (λ () (channel-put result-ch (sync e) >>> (channel-put arg-ch1 'arg1-ch-ok) >>> (channel-put arg-ch2 'arg2-ch-ok) >>> (sync result-ch)) >>> all-evt returns: # >>> '(arg1-ch-ok arg2-ch-ok) >>> >>> -- >>> 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...@googlegroup
Re: [racket-users] New package announce: value-evt
Neat! Thanks for this. Did you make sure to list your scribble file in `scribblings` under info.rkt? On 4/1/21 12:12 PM, David Storrs wrote: > Wraps an arbitrary value into a synchronizable event. The > synchronization result of the event is the original value, with two > exceptions: procedures sync to their return value and lists sync > recursively. Both of these values can be disabled via keywords. > > The package server is telling me that it needs documentation. That > confuses me since it has a .scrbl file and the .html was already > present in the repository. ISTR that the docs are only built once > every 24 hours, so presumably they will pop up at some point? > > Examples: > > ; value-evts are both evt? and value-evt?. They sync to their argument >> (define e (value-evt 9)) >> e > # >> (evt? e) > #t >> (value-evt? e) > #t >> (sync e) > 9 > ; > ; By default, syncing on a procedure syncs to the return value >> (define proc (lambda () (+ 2 2))) >> (sync (value-evt proc)) > 4 > ; > ; You can instead get the procedure itself back >> (sync (value-evt proc #:eval-proc? #f)) > # > ; > ; It's not a problem to specify #:eval-proc? on something that isn't a > procedure >> (sync (value-evt "eval-proc? keyword is ignored for non-proc" #:eval-proc? >> #f)) > "eval-proc? keyword is ignored for non-proc" > ; > ; eventify always returns an evt > ; Things that are evts are unchanged >> (define ch (make-channel)) >> (evt? ch) > #t >> (eq? ch (eventify ch)) > #t > ; > ; Things that are not evts become value-evts >> (evt? 'bob) > #f >> (evt? (eventify 'bob)) > #t > ; > ; by default, value-evts containing a list sync recursively >> (let ([result-ch (make-channel)] > [arg-ch1 (make-channel)] > [arg-ch2 (make-channel)]) > (void (thread (λ () (channel-put result-ch (sync (value-evt (list > arg-ch1 arg-ch2))) > (channel-put arg-ch1 'arg1-ch-ok) > (channel-put arg-ch2 'arg2-ch-ok) > (sync result-ch)) > '(arg1-ch-ok arg2-ch-ok) > ; > ; You can ask for it to return the original list >> (let ([arg-ch1 (make-channel)] > [arg-ch2 (make-channel)]) >(sync (value-evt (list arg-ch1 arg-ch2) #:recurse-lists? #f))) > '(# #) > ; > ; all-evt is the same as value-evt but takes a rest argument > ; so you don't have to supply your own list >> (let ([result-ch (make-channel)] > [arg-ch1 (make-channel)] > [arg-ch2 (make-channel)]) > (define e (all-evt arg-ch1 arg-ch2)) > (printf "all-evt returns: ~v" e) > (void (thread (λ () (channel-put result-ch (sync e) > (channel-put arg-ch1 'arg1-ch-ok) > (channel-put arg-ch2 'arg2-ch-ok) > (sync result-ch)) > all-evt returns: # > '(arg1-ch-ok arg2-ch-ok) > > -- > 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/CAE8gKocr0FbpTKwgNcseNjjA_-64f4exQDkgfPPxxvFpR16pww%40mail.gmail.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/99793234-257c-d8e5-7454-a1d911d2ab66%40sagegerard.com.
Re: [racket-users] Re: [ANNOUNCE] Xiden is now in beta
Hi Joel, > On some future day when Xiden is out of beta, what are authors of “normal” > Racket packages doing to make their packages available to Xiden users? Basically cross-posting to zcpkg.com (don't visit, nothing is there yet). I'd expect the bureaucracy of signing/hashing would be handled by a specialized client, since I'm trying to keep Xiden open-ended. The value would be in added safeguards (better crytographic hash functions + hosting signatures), and additional options for transporting artifacts (e.g. torrents). There's also the fact that Xiden handles software in general, not just Racket packages. So I'd give this answer to the same question in other mailing lists. > For example, are we zipping, hashing and signing every “release” and > uploading it somewhere (our own web server or a 3rd party catalog)? Or is the > typical Xiden user manually creating their own catalogs and packages from > others’ code after a thorough vetting? One can do all of that now. I'm not asking for people to try that here, but it would be helpful to know what their experience was like if they tried. Vetting is a case-by-case problem that deals more with trust than Guix-specific knowledge. For example, Racket downloads do not include signatures, and use SHA1 digests. The self-hosting example in the repository installs a self-contained Racket + Xiden stack, and the Racket installation script is signed with my private key. That's why package definitions identify me as a provider (as in "distributor") and not as an author. That's an entirely different picture from a vetting perspective, because someone might trust a Racket distribution simply because it came from racket-lang.org over HTTPS, but they might not want to trust my public key outside of the context of that example. But if this were a Python source release, I'd just paste in the related signature and let the user affirm trust in a public key belonging to Pablo G. Salgado. On 3/20/21 1:39 PM, 'Joel Dueck' via Racket Users wrote: > Racket’s existing package system doesn’t pose any felt problems for me, but I > still find this project very interesting. > > On some future day when Xiden is out of beta, what are authors of “normal” > Racket packages doing to make their packages available to Xiden users? For > example, are we zipping, hashing and signing every “release” and uploading it > somewhere (our own web server or a 3rd party catalog)? Or is the typical > Xiden user manually creating their own catalogs and packages from others’ > code after a thorough vetting? (Maybe if I were more familiar with Guix I > would already know the answer to this) > > On Friday, March 19, 2021 at 3:56:18 PM UTC-5 Sage Gerard wrote: > >> Hi folks, >> >> About a year, 1384 commits, 489 tests, ~10k LOC, and 2" on my waistline >> later, Xiden is in beta. An update is pending on the default catalog. >> >> https://github.com/zyrolasting/xiden >> >> Xiden is a dependency manager I wrote to support use cases that I could not >> get working with `raco pkg`. >> >> Dependency management is hard, so Xiden was something I originally didn't >> want to make. However, it ended up becoming one of my most aspirational >> projects, and I'm proud of how it ended up. If you could take the time to >> read a longer email, I'd like to share a bit about how it might be helpful >> to you. >> >> *** >> >> Like Guix, Xiden supports deterministic and atomic installations. Unlike >> Guix, Xiden is cross-platform. >> >> The Racket programs I write no longer have to assume that code comes in >> collections (outside of the built-in ones). >> >> You can force dependencies of different versions to resolve to the same data >> to avoid issues with non-eq? bindings [multiver]. >> >> Dependencies are accessed by symbolic links with names defined by the >> dependent. So if two packages are called "uri", you can still install them >> both under names that are meaningful to you. Dependencies are fulfilled the >> same way, regardless if the dependent is a human or more software. >> >> Explicit, affirmative consent is fundamental to Xiden's workings. The >> default configuration is zero-trust (a.k.a. "Deny All"). Trust in >> cryptographic hash functions and public keys (or any bytes lacking either) >> must be declared to authenticate bytesfrom any source (even hard coded!). >> Not doing so will cause Xiden to reject data, but print an error that >> helpfully instructs you how to consent to the scenario. For those wanting >> convenience, there are "blanket" configuration options to consent to every >> instance of those scenarios. Th
[racket-users] [ANNOUNCE] Xiden is now in beta
Hi folks, About a year, 1384 commits, 489 tests, ~10k LOC, and 2" on my waistline later, Xiden is in beta. An update is pending on the default catalog. https://github.com/zyrolasting/xiden Xiden is a dependency manager I wrote to support use cases that I could not get working with `raco pkg`. Dependency management is hard, so Xiden was something I originally didn't want to make. However, it ended up becoming one of my most aspirational projects, and I'm proud of how it ended up. If you could take the time to read a longer email, I'd like to share a bit about how it might be helpful to you. *** Like Guix, Xiden supports deterministic and atomic installations. Unlike Guix, Xiden is cross-platform. The Racket programs I write no longer have to assume that code comes in collections (outside of the built-in ones). You can force dependencies of different versions to resolve to the same data to avoid issues with non-eq? bindings [multiver]. Dependencies are accessed by symbolic links with names defined by the dependent. So if two packages are called "uri", you can still install them both under names that are meaningful to you. Dependencies are fulfilled the same way, regardless if the dependent is a human or more software. Explicit, affirmative consent is fundamental to Xiden's workings. The default configuration is zero-trust (a.k.a. "Deny All"). Trust in cryptographic hash functions and public keys (or any bytes lacking either) must be declared to authenticate bytesfrom any source (even hard coded!). Not doing so will cause Xiden to reject data, but print an error that helpfully instructs you how to consent to the scenario. For those wanting convenience, there are "blanket" configuration options to consent to every instance of those scenarios. This makes Xiden a way to educate users on the exact shape and nature of the risks they accept with something from the Internet. In this sense, Xiden does not invent anything new with security. It only aims to get ahead of the "Allow Some" arms-race in other dependency managers like NPM. Customization comes from a plugin module. You can use a plugin to integrate GPG, use a different archive format, or otherwise fill in gaps in Xiden's functionality. Xiden keeps authentication and integrity checking decoupled in this way so that users can transition on their own in the event a smart person finds a collision in a CHF, or cracks a cipher. Similarly, Xiden's data sources are any data type declared with a path to an input port, including queries to a catalog. A neat effect of this is that you can configure your own syntax for data sources in your command lines. Even though I call Xiden a dependency manager, it is generalized enough to be useful as a component for a CI system, as a self-hosted OS development environment, or even as a back-end for a more specialized dependency manager. If this is something that interests you, please consider trying the examples with the guide [ex][guide]. Like all software, Xiden is not perfect, so I depend on your feedback to make Xiden better for you, and to decide what interfaces should be declared stable. [ex]: https://github.com/zyrolasting/xiden/tree/master/examples [guide]: https://docs.racket-lang.org/xiden-guide@xiden/index.html [ethos]: https://groups.google.com/g/racket-users/c/4iI-SanIbzk/m/sGHYijLPAAAJ [multiver]: https://github.com/zyrolasting/xiden/tree/master/examples/01-differing-versions -- ~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/0fcfc4de-6742-e729-73e3-a7e71326991f%40sagegerard.com.
Re: [racket-users] Version metadata on Racket packages
The last sentence of the first paragraph you quoted starts with "A version is intended," but I don't know for sure if it is a complete answer. You'll also notice on the catalog that there are version exceptions, but you may have already read that by now. https://docs.racket-lang.org/pkg/getting-started.html?q=version%20exceptions#%28part._.Version_.Exceptions%29 Beyond what the manual says, the version field really doesn't mean much in the sense I think you're hinting at. There is no query language where you can ask for, say, the latest version within those available within 4.2.x, for example. Even if there was, it wouldn't be that useful since the default catalog does not maintain artifacts (Bogdan's racksnaps improves on this situation). Also remember that it is the collection, not the package, is the real "unit of exchange" in the Racket ecosystem. If you release a version 2.0 that includes a breaking change in a `foo` collection, it will conflict with any version of any package published by anyone that happens to define modules of the same name in the same collection. There are reasons for this, but that's out of the scope for your question. On 3/16/21 6:51 PM, Jeff Henrikson wrote: > Hello racket-users, > > As far as I can tell from reading the Racket documentation, the racket > package manager has only one field to indicate version. I am trying to > understand the intended use of the version field. > > Here the documentation seems to recommend that packages use the version field > to denote a semantic versioning scheme of for the specific package's release > cycle: > >> https://docs.racket-lang.org/pkg/Package_Concepts.html >> a version — a string of the form ‹maj›.‹min›, ‹maj›.‹min›.‹sub›, or >> ‹maj›.‹min›.‹sub›.‹rel›, where ‹maj›, ‹min›, ‹sub›, and ‹rel› are all >> canonical decimal representations of natural numbers, ‹rel› is not 0, ‹sub› >> is not 0 unless ‹rel› is supplied, ‹min› has no more than two digits, and >> ‹sub› and ‹rel› have no more than three digits. A version is intended to >> reflect available features of a package, and should not be confused with >> different releases of a package as indicated by the checksum. > > Here the documentation refers to a "Racket version number," which might be > taken to mean a version number of the Racket language: > >> https://docs.racket-lang.org/pkg/catalog-protocol.html >> 8.1 Remote and Directory Catalogs >> In the case of a remote URL or a local directory naming a package catalog, >> the URL/path is extended as follows to obtain information about packages: >> >> pkg and ‹package› path elements, where ‹package› is a package name, plus a >> version=‹version› query (where ‹version› is a Racket version number) in the >> case of a remote URL. > > It seems natural for packages that tightly depend on quickly evolving > features of the Racket language to have a versioning scheme coupled to > Racket's own versions. On the other hand, for packages that work with a > variety of possible Racket versions, it seems to make sense that said > packages would have their own release cycles, compatibility aspirations, and > semantic versioning contract. > > Note that some package managers for evolving languages have two versioning > coordinates, one for the language version and one for the package version. > > Appended below this message is a small racket program that inspects data from > the https://pkgs.racket-lang.org/pkgs-all HTTP endpoint. According to this > analysis, 21% of published Racket packages version using version numbers of > the Racket language. Fewer than 1% of published Racket packages seem to > version using their own version scheme. And 78% of published Racket packages > have only ever filled the version field with "default". > > As the documentation notes, using checksum instead of a version field is sort > of like saying any feature can change at any time to any degree: "A version > is intended to reflect available features of a package, and should not be > confused with different releases of a package as indicated by the checksum." > > My question is this: What is the intended use of the version field in the > Racket package manager? > > Thanks in advance, > > Jeff Henrikson > >> #lang racket >> >> ;; obtain data with: >> ;; curl https://pkgs.racket-lang.org/pkgs-all > contrib_pkgs-all.sexp >> >> ;; relfin is "contrib_pkgs-all.sexp" or similar. >> ;; >> ;; In practice it's one value that comes over the wire, so >> ;; we'll just take the car now. >> (define (read-pkgs5 relfin) >> (letrec ( >> (fin (open-input-file relfin)) >> (iter (lambda (xs) >> (let ((x (read fin))) >> (if (not (equal? x eof)) >> (iter (cons x xs)) >> (begin >> (close-input-port fin) >> xs)) >> (car (reverse (iter '()) >> >> ;;; Get the versions of a package hash >> (define (versions-of-pkg pkg) >> (hash-keys (hash-ref pkg 'versions))) >> >> ;;; Is there at least one version that appears to be distinct >> ;;; from a
Re: [racket-users] Is something wrong with the documentation site?
There's an issue where if a package build fails, the pretty links to the docs do not resolve. For future reference, you can get around this by going to the package page... https://pkgs.racket-lang.org/package/pollen ...and then clicking "Documentation". That particular URL seems to still work. I cannot speak to what discrepancies may exist between the version that failed to build and the document returned via the package page. On 3/8/21 2:28 PM, Andre Garzia wrote: > Hi Folks, > > I just noticed that I can't seem to find the docs for some packages such as > Pollen anymore. > > https://docs.racket-lang.org/pollen/ > > Is returning a page not found. > > I don't know if it is related, but my Racket 8.0 CS on macOS is also > complaining that "pkg" is not a valid raco command. Did something change? > > Warm regards > Andre > > -- > > [https://www.andregarzia.com](http://www.andregarzia.com) > Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia > -- > 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/CAF3jwTmyyS-qXuKYAMUiG2zfrxXePmOUXpG2kZUWNyAwO3uQAA%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CAF3jwTmyyS-qXuKYAMUiG2zfrxXePmOUXpG2kZUWNyAwO3uQAA%40mail.gmail.com?utm_medium=email_source=footer). -- ~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/f0b85cf9-ee09-7b73-0b95-363c5de5fb6e%40sagegerard.com.
Re: [racket-users] Is it safe to `read` untrusted input?
Typo: "but the library itself leverages the reader" should read "but if the library itself leverages the reader" On 2/28/21 4:20 PM, Sage Gerard wrote: > Does call-with-default-reading-parameterization help? > > https://docs.racket-lang.org/reference/Reading.html?q=accept-compiled#%28def._%28%28lib._racket%2Fprivate%2Fmisc..rkt%29._call-with-default-reading-parameterization%29%29 > > The parameters you are seeing re: accepting -lang, -reader are for when the > reader sees a reference to an extension that it can load and use. In that > sense, code defined for that extension would execute so that the reader is > prepared to process upcoming bytes. So if you are worried that the reader > would execute code as a side-effect of reading, then yes, that can happen. > Unsure what the #~ does, so I can't speak to that. > > Defining a procedure that flips off all parameters related to extensions is a > good step, but I do not know if the linked example serves as a true "Deny > All" equivalent. The docs make it seem like it does. Even so, I think there > are other aspects to a zero-trust policy such as the values of > `current-security-guard` and `current-code-inspector`... but you'll get to > that. > > Using a different data format might work, but the library itself leverages > the reader, then you still would care about enforcing these restrictions > anyway. > > On 2/28/21 2:50 PM, Ryan Kramer wrote: > >> I want to send some Racket structs across a network. I know that I can use >> prefab structs, serializable-structs, or even `eval` with a carefully >> curated namespace. I was trying to think of security problems with the eval >> approach and now I've become more afraid of `read` than I am of eval. And >> read seems necessary for all 3 approaches. >> >> The first concern I thought of was cyclic data. My code assumes there are no >> cycles; if an attacker can get me to process cyclic data my server will >> probably loop forever or crash. This can be solved by setting >> `read-accept-graph` to #f... I think. Right? (I guess another solution is >> "you need to validate the input" which is fair, but it's easy to forget or >> make a mistake.) >> >> This caused me to notice other `read-accept-***` parameters that looked >> scary (-lang, -reader, -compiled). I don't know if there is an attack vector >> here, but I felt safer turning them off also. >> >> Now I'm thinking that even if I can get it working safely today, Racket >> would be well within its rights to make enhancements to the reader in the >> future. So someday there might be new parameters that I would want to turn >> off to preserve my definition of "safe", and I have to remember this when I >> upgrade. >> >> All this makes me think that `read` is not quite the right tool for the job. >> But it's close. If there were a version of read that accepts nothing by >> default and requires the caller to opt-in to everything they want, that >> would probably be perfect. >> >> I could use JSON or XML, but that just seems silly when you have a Racket >> client talking to a Racket server. >> >> Are my concerns founded? Are there any existing solutions? Thanks for any >> advice. >> -- >> 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/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com?utm_medium=email_source=footer). > > -- > ~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/2d8bc7d7-30c0-7952-c4aa-81598998e9a0%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/2d8bc7d7-30c0-7952-c4aa-81598998e9a0%40sagegerard.com?utm_medium=email_source=footer). -- ~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/c7c7533e-ffc7-9c67-ea08-32f28c78cc07%40sagegerard.com.
Re: [racket-users] Is it safe to `read` untrusted input?
Does call-with-default-reading-parameterization help? https://docs.racket-lang.org/reference/Reading.html?q=accept-compiled#%28def._%28%28lib._racket%2Fprivate%2Fmisc..rkt%29._call-with-default-reading-parameterization%29%29 The parameters you are seeing re: accepting -lang, -reader are for when the reader sees a reference to an extension that it can load and use. In that sense, code defined for that extension would execute so that the reader is prepared to process upcoming bytes. So if you are worried that the reader would execute code as a side-effect of reading, then yes, that can happen. Unsure what the #~ does, so I can't speak to that. Defining a procedure that flips off all parameters related to extensions is a good step, but I do not know if the linked example serves as a true "Deny All" equivalent. The docs make it seem like it does. Even so, I think there are other aspects to a zero-trust policy such as the values of `current-security-guard` and `current-code-inspector`... but you'll get to that. Using a different data format might work, but the library itself leverages the reader, then you still would care about enforcing these restrictions anyway. On 2/28/21 2:50 PM, Ryan Kramer wrote: > I want to send some Racket structs across a network. I know that I can use > prefab structs, serializable-structs, or even `eval` with a carefully curated > namespace. I was trying to think of security problems with the eval approach > and now I've become more afraid of `read` than I am of eval. And read seems > necessary for all 3 approaches. > > The first concern I thought of was cyclic data. My code assumes there are no > cycles; if an attacker can get me to process cyclic data my server will > probably loop forever or crash. This can be solved by setting > `read-accept-graph` to #f... I think. Right? (I guess another solution is > "you need to validate the input" which is fair, but it's easy to forget or > make a mistake.) > > This caused me to notice other `read-accept-***` parameters that looked scary > (-lang, -reader, -compiled). I don't know if there is an attack vector here, > but I felt safer turning them off also. > > Now I'm thinking that even if I can get it working safely today, Racket would > be well within its rights to make enhancements to the reader in the future. > So someday there might be new parameters that I would want to turn off to > preserve my definition of "safe", and I have to remember this when I upgrade. > > All this makes me think that `read` is not quite the right tool for the job. > But it's close. If there were a version of read that accepts nothing by > default and requires the caller to opt-in to everything they want, that would > probably be perfect. > > I could use JSON or XML, but that just seems silly when you have a Racket > client talking to a Racket server. > > Are my concerns founded? Are there any existing solutions? Thanks for any > advice. > -- > 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/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com?utm_medium=email_source=footer). -- ~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/2d8bc7d7-30c0-7952-c4aa-81598998e9a0%40sagegerard.com.
Re: [racket-users] Questions Regarding My First Program
I can't speak to DrRacket since I never use it, so I'll focus more on the first question. Functional programming typically deals with these considerations (among others): - Write functions that return values purely in terms of arguments. - Defer side-effects until you can't. A goal to make the program produce the same output given the same input, every time. One example would be to redefine `say` such that it doesn't immediately print. Maybe just return the string you want said. (define (say str) (format "Chatbot: ~a\n" str)) (I'd personally use a struct representing a message, sender, etc. but that's beside the point) This change makes the function "pure" in that the same input returns the same output, and there are no side-effects in doing so. But this creates a problem where you need to "rope in" that value somewhere. How that happens depends on the program. A program that reports download progress will handles side-effects differently than a program that prints a report before stopping. One approach is to update program state in the same (functional) way. If we assume the chat history is a list, where the first element is the most recent message, then this version of `say` adds a string to the chat. (define (say chat-history str) (cons (format "Chatbot: ~a\n" str) chat-history)) I'd start with this kind of thinking until you get to the point where side-effects are unavoidable. Since your program appears interactive, you can still print in the loop. But think about what your program would be like if you print ONLY in that loop. Others can probably say more, but hopefully this helps you start. On 2/23/21 5:59 PM, IF Karona wrote: > Hi everyone, > > I am new here, and I have a couple of questions related to the code that > follows this message. > > 1. I want to learn functional programming. When it comes to solving the > problem of making a simple chatbot such as this, is there an approach that is > more consistent with functional programming? > 2. I would prefer to not have to use multiple spaces every time I want to > indent. Does Dr. Racket have anything comparable to the tab functionality of > other programs? > > Thank you for letting me join your community! > > Karona > > ;example.rkt > > #lang racket > > (require racket/match) > > (define (say str) > (printf "Chatbot: ~a\n" str)) > > (define (handle-input str) > (cond > > [(regexp-match #px"(?i:Hello,* world!)" str) > (say "I would not know about the rest of the world, but I can hear \ > you just fine.")] > > [(regexp-match #px"(?i:I( am|'m) learning how to program in Racket,* world!)" > str) > (say "Racket is a great language, and it is lovely that you are \ > learning it, but does literally everyone need to know?")] > > [(regexp-match #px".*,+\\s*world!" str) > (say "Did the whole world really need to hear that?")] > > [else (say "Did you really just say something without addressing the \ > world? I am so proud of you! :,)")])) > > (let loop () > (display "Input: ") > (define str (read-line (current-input-port) 'any)) > (handle-input str) > (loop)) > -- > 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/2f107ab5-2efd-4c33-83f6-eb5751664cb6n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/2f107ab5-2efd-4c33-83f6-eb5751664cb6n%40googlegroups.com?utm_medium=email_source=footer). -- ~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/d3da9796-979d-cad9-36e5-91380939630c%40sagegerard.com.
Re: [racket-users] Racket v8.0 (!)
So exciting! A massive thank you to everyone making Racket even better. :) ~slg ‐‐‐ Original Message ‐‐‐ On Saturday, February 13, 2021 9:17 PM, 'John Clements' via Racket Users wrote: > *** Racket 8.0 is here! *** > > Racket version 8.0 is now available from > > https://racket-lang.org/ > > Racket 8.0 marks the first release where Racket CS is the default > implementation. Creating, polishing, and adopting Racket CS has been a > 4-year effort involving the entire Racket community. At this point, > Racket CS is faster, easier to maintain and develop, and compatible > with existing Racket programs. Racket CS will continue to improve, but > at this point it is ready to be the primary variant of Racket for all > Racketeers. More details about the current state of Racket CS are > available in the recent blog post (https://blog.racket-lang.org/). > > Other notable changes: > > - Racket CS has better parallel garbage collection, a 10%-30% reduction > in the size of generated code, and various targeted optimizations. > > - A rewrite of the test-engine package allows the `#lang` versions of > teaching languages to produce linked test-failure messages. > > - The release comes with a new mark-up DSL for composing text to > appear in the REPL (simple-tree-text-markup). > > - Redex has an added `define-overriding-judgment` form and improved > error source location reporting. > > - Windows scrolling speed reflects the system preference. > - The db package uses the utf8mb4 charset for MySQL connections. > > The following people contributed to this release: > > Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Bert De > Ketelaere, Bogdan Popa, Cameron Moy, David Van Horn, Davis Silverman, > Dominik Pantůček, Florian Weimer, Fred Fu, Gustavo Massaccesi, Jack > Firth, James Wilcox, Joel Dueck, John Clements, Jonathan Chan, Lîm > Tsú-thuàn, Mark, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, > Mike Sperber, Paulo Matos, Pavel Panchekha, Peter Zhong, Phil Nguyen, > Philip McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, > Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stefan Schwarzer, > Stephen Chang, Stephen De Gabrielle, Walter H. Yang, WarGrey Gyoudmon > Ju, kurinoku, xxyzz, and yjqww6 > > > *** Windows users should note that as of this release date (2021-02-13), > Windows SmartScreen is observed to flag the Racket download bundles > as potentially malicious, based on the low number of times this > bundle has been downloaded and installed. Clicking a label with the > text “more info” appears to be necessary to install Racket > 8.0. We’re hopeful that this issue will go away … soon? *** > > > --- > > 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/06d8e16d-b7d2-41c6-ae76-99e33fecd3bd%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/ukoSR2kZCzf72XmNinyZdHGendc-_ugz7O1PpEbyiZEQf1vzvt6BvqMzZXpfVU0w5poNXTTU1_9pkYWHVowSxgERtbhutX9awcQW-CfXbXk%3D%40sagegerard.com.
Re: [racket-users] Why is my sandbox trying to access /etc/ssl/certs.pem?
I don't know if Scribble needs OpenSSL, but a dependency probably does. The only precondition of that error is that openssl/mzssl appears *somewhere* among the dependencies. I run into that same error for evaluators that have nothing to do with Scribble. ~slg ‐‐‐ Original Message ‐‐‐ On Monday, January 4, 2021 7:10 PM, 'William J. Bowman' via Racket Users wrote: > Thanks for the explanation. > > I can't figure out why scribble/manual needs openssl, but oh well. > > After reading through openssl, I've gone with a slightly less blunt > instrument: > > > (require/expose openssl/mzssl (X509_get_default_cert_file)) > > ... > > [sandbox-path-permissions (append `((exists > > ,(X509_get_default_cert_file))) > > (sandbox-path-permissions))] > > ... > > -- > > William J. Bowman > > On Tue, Jan 05, 2021 at 12:07:12AM +, Sage Gerard wrote: > > > Heads up: My earlier example was missing a closing paren. Also just saw > > that your subject line asked "Why", so I checked. > > openssl/mzssl provides a parameter called `ssl-default-verify-sources'. See > > 1. The parameter is created during module instantiation with a OS-dependent > > default value. > > When you create a sandboxed evaluator, it is impacted by several > > parameters. The default values of those parameters have little to no trust > > in the code, and will deny ALL filesystem access. Also, all Racket modules > > that are not shared with the evaluator are instantiated again. So you need > > to account for what happens as a side effect of all instantiations needed > > to get the evaluator up and running. If some module somewhere happens to > > require openssl/mzssl (even if you don't need it), then you are impacted by > > the permissions on the evaluator. > > My earlier example was crude precisely because it is a blanket grant of > > existential checks for all filesystem paths. For better security habits, > > you can just add one `exists' permission to`(sandbox-path-permissions)' > > based on the value of `(ssl-default-verify-sources)'. > > ~slg > > ‐‐‐ Original Message ‐‐‐ > > On Monday, January 4, 2021 6:53 PM, Sage Gerard s...@sagegerard.com wrote: > > > > > If you just want to silence the error with a blunt instrument, then you > > > could > > > try a parameterization where sandbox-path-permissions is set to: > > > (append (map (λ (p) `(exists ,p)) (filesystem-root-list) > > > (sandbox-path-permissions))) > > > This suffices since it is an existential check, not a file read. > > > ~slg > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, January 4, 2021 6:47 PM, 'William J. Bowman' via Racket Users > > > racket-users@googlegroups.com wrote: > > > > > > > I have a sandbox that loads scribble/manual (indirectly) to render some > > > > HTML. > > > > But it crashes with the following error: > > > > > > > > > racket -e "(require racket/sandbox)" -e "((make-evaluator > > > > > 'racket/base) '(require scribble/manual))" > > > > > > > > file-exists?: `exists' access denied for /etc/ssl/cert.pem > > > > errortrace...: > > > > context...: > > > > do-error > > > > security-guard-check-file > > > > ->host > > > > file-exists? > > > > /racket/racket/collects/openssl/mzssl.rkt:397:0: x509-root-sources > > > > interpret > > > > [repeats 1 more time] > > > > proc > > > > call-in-empty-metacontinuation-frame > > > > body of "/racket/racket/collects/openssl/mzssl.rkt" > > > > interpret-expr > > > > body of top-level > > > > run-module-instance! > > > > [repeats 12 more times] > > > > perform-require! > > > > loop > > > > This is strange, since openssl shouldn't actually be needed. > > > > I could just allow access to the file, but the path depends on which > > > > operating system I'm running on making this slightly complicated, and > > > > the access isn't necessary. > > > > Is there some way to trick Racket into not trying to do this, or else > > > > some parameter I can use to provide access to whatever openssl is going > > > > to try to touch without hardcoding the paths? > > > > William J. Bowman > > > > You received this message because you are subscribed to the Google > > > > Groups "Racket Users" group. > > > >
Re: [racket-users] Why is my sandbox trying to access /etc/ssl/certs.pem?
Heads up: My earlier example was missing a closing paren. Also just saw that your subject line asked "Why", so I checked. openssl/mzssl provides a parameter called `ssl-default-verify-sources'. See [1]. The parameter is created during module instantiation with a OS-dependent default value. When you create a sandboxed evaluator, it is impacted by several parameters. The default values of those parameters have little to no trust in the code, and will deny ALL filesystem access. Also, all Racket modules that are not shared with the evaluator are instantiated again. So you need to account for what happens as a side effect of all instantiations needed to get the evaluator up and running. If some module somewhere happens to require openssl/mzssl (even if you don't need it), then you are impacted by the permissions on the evaluator. My earlier example was crude precisely because it is a blanket grant of existential checks for all filesystem paths. For better security habits, you can just add one `exists' permission to `(sandbox-path-permissions)' based on the value of `(ssl-default-verify-sources)'. [1]: https://docs.racket-lang.org/openssl/index.html?q=ssl-default-verify-sources#%28def._%28%28lib._openssl%2Fmain..rkt%29._ssl-default-verify-sources%29%29 ~slg ‐‐‐ Original Message ‐‐‐ On Monday, January 4, 2021 6:53 PM, Sage Gerard wrote: > If you just want to silence the error with a blunt instrument, then you could > try a parameterization where sandbox-path-permissions is set to: > > (append (map (λ (p) `(exists ,p)) (filesystem-root-list) > (sandbox-path-permissions))) > > This suffices since it is an existential check, not a file read. > > ~slg > > ‐‐‐ Original Message ‐‐‐ > On Monday, January 4, 2021 6:47 PM, 'William J. Bowman' via Racket Users > racket-users@googlegroups.com wrote: > > > I have a sandbox that loads scribble/manual (indirectly) to render some > > HTML. > > But it crashes with the following error: > > > > > racket -e "(require racket/sandbox)" -e "((make-evaluator 'racket/base) > > > '(require scribble/manual))" > > > > file-exists?: `exists' access denied for /etc/ssl/cert.pem > > errortrace...: > > context...: > > do-error > > security-guard-check-file > > ->host > > file-exists? > > /racket/racket/collects/openssl/mzssl.rkt:397:0: x509-root-sources > > interpret > > [repeats 1 more time] > > proc > > call-in-empty-metacontinuation-frame > > body of "/racket/racket/collects/openssl/mzssl.rkt" > > interpret-expr > > body of top-level > > run-module-instance! > > [repeats 12 more times] > > perform-require! > > loop > > This is strange, since openssl shouldn't actually be needed. > > I could just allow access to the file, but the path depends on which > > operating system I'm running on making this slightly complicated, and the > > access isn't necessary. > > Is there some way to trick Racket into not trying to do this, or else some > > parameter I can use to provide access to whatever openssl is going to try > > to touch without hardcoding the paths? > > > > 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/X/OpEPyvzOyzQql2%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/qQRDoCYwXeJy2_f_PXvZkjoBUmmKChpSJzN6XCGWFz11VsXOuhzFEArD2-2FuR4Mui8gx3MAX2v5aX_bF21izapOF9peJ7Y3P0eg3Vei3yM%3D%40sagegerard.com.
Re: [racket-users] Why is my sandbox trying to access /etc/ssl/certs.pem?
If you just want to silence the error with a blunt instrument, then you could try a parameterization where sandbox-path-permissions is set to: (append (map (λ (p) `(exists ,p)) (filesystem-root-list) (sandbox-path-permissions))) This suffices since it is an existential check, not a file read. ~slg ‐‐‐ Original Message ‐‐‐ On Monday, January 4, 2021 6:47 PM, 'William J. Bowman' via Racket Users wrote: > I have a sandbox that loads scribble/manual (indirectly) to render some HTML. > But it crashes with the following error: > > > racket -e "(require racket/sandbox)" -e "((make-evaluator 'racket/base) > > '(require scribble/manual))" > > file-exists?: `exists' access denied for /etc/ssl/cert.pem > errortrace...: > context...: > do-error > security-guard-check-file > ->host > > file-exists? > /racket/racket/collects/openssl/mzssl.rkt:397:0: x509-root-sources > interpret > [repeats 1 more time] > proc > call-in-empty-metacontinuation-frame > body of "/racket/racket/collects/openssl/mzssl.rkt" > interpret-expr > body of top-level > run-module-instance! > [repeats 12 more times] > perform-require! > loop > > This is strange, since openssl shouldn't actually be needed. > > I could just allow access to the file, but the path depends on which > operating system I'm running on making this slightly complicated, and the > access isn't necessary. > > Is there some way to trick Racket into not trying to do this, or else some > parameter I can use to provide access to whatever openssl is going to try to > touch without hardcoding the paths? > > - > > 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/X/OpEPyvzOyzQql2%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/3-wYvswd9nUzA7L0nrfn-oSNXt9AeIYF6hZg65oVNAWsF_N65dmRgKQhc6Unzappdztz-10ui5_hPLqvDUO3pL135g7cqcQsmY1s5EzyuAY%3D%40sagegerard.com.
Re: [racket-users] Why do single-form modules behave differently?
Fantastic, thank you ~slg ‐‐‐ Original Message ‐‐‐ On Sunday, January 3, 2021 12:14 PM, Ryan Culpepper wrote: > It's the consequence of two design goals: > > 1. The `module` form is separate from the `#%module-begin` syntax hook so > that the module's initial language can pick the hook macro that controls the > entire module body. > > 2. Racket's primitive syntax is designed so that it can be re-expanded. (The > `expand` operation should be idempotent.) Some of Racket's tools (for > example, debugging support) work by expanding code, instrumenting it, and > then re-expanding, compiling, and running the result. But a `#%module-begin` > hook macro can transform the module body in non-idempotent ways, so that hook > macro should only be called once. So the answer to "have I already run the > module's `#%module-begin` hook?" must be reflected in the fully-expanded > syntax of the module. > > Ryan > > On Sun, Jan 3, 2021 at 8:40 AM Michael MacLeod > wrote: > >> Oops, sorry about interpreting your question wrong. Unfortunately I don't >> know the answer to your actual question. >> >> On Sat, Jan 2, 2021, 10:24 PM Sage Gerard wrote: >> >>> I know about that. I asked why it was designed that way. >>> >>> Sent from ProtonMail mobile >>> >>> Original Message >>> On Jan 3, 2021, 12:18 AM, Michael MacLeod < michaelmmacl...@gmail.com> >>> wrote: >>> >>>> There's an edge case of 'module' when only one form is provided which >>>> results in that form being partially expanded to determine if such >>>> expansion would lead to a #%plain-module-begin form. Otherwise (more than >>>> one form provided) they are wrapped in #%module-begin with no partial >>>> expansion occurring. >>>> >>>> I think this might be causing the discrepancy you witnessed. >>>> >>>> From the docs (https://docs.racket-lang.org/reference/module.html): >>>> >>>> If a single form is provided, then it is partially expanded in a >>>> module-begin context. If the expansion leads to #%plain-module-begin, then >>>> the body of the #%plain-module-begin is the body of the module. If partial >>>> expansion leads to any other primitive form, then the form is wrapped with >>>> #%module-begin using the lexical context of the module body; this >>>> identifier must be bound by the initial module-path import, and its >>>> expansion must produce a #%plain-module-begin to supply the module body. >>>> Finally, if multiple forms are provided, they are wrapped with >>>> #%module-begin, as in the case where a single form does not expand to >>>> #%plain-module-begin. >>>> >>>> (This response was adapted from one of my earlier replies to the mailing >>>> list. Search racket-users for "perplexed by macro-expansion behavior near >>>> #%module-begin" for more context). >>>> >>>> Best, >>>> Michael >>>> >>>> On Sat, Jan 2, 2021 at 8:26 PM Sage Gerard wrote: >>>> >>>>> Why does Racket handle modules with exactly one form differently? >>>>> >>>>> I ran into a bug where modules in my module language won't expand if the >>>>> modules have exactly one form, so I'm just curious. >>>>> >>>>> (Wild guess: It's Racket's way of checking for a shortcut to end >>>>> expansion earlier) >>>>> >>>>> ~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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.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/CACehHmBvs5KK4vQmwio93D1NZ9hTOoSv-Qkm8XOjF%2B4JWDOiHg%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CACehHmBvs5KK4vQmwio93D1NZ9hTOoSv-Qkm8XOjF%2B4JWDOiHg%40mail.gmail.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/Chmb4Sh3Pm8Y0D-qf19jw8Z0aM6AYGMrDfOZn2FzzrgrDNINR_K7QV5beIaJPiVakohvBLgSeSHoesndVxQOTaj068otESk8ROXGif0RHWY%3D%40sagegerard.com.
Re: [racket-users] I made some videos about Racket (a.k.a the return of Playing the Game with PLT Redex)
Thanks for sharing. I honed in on the review video because I like the philosophical discussions that come from them. I'm not sure about the comments re: toxicity in the community and how that helps one succeed in academia, but I did see some value in discussing the merits of LOP. I spent enough years on JavaScript to see the ecosystem slowly gain features that other languages enjoyed for decades. It seemed wise to learn new tools instead of waiting on a standards committee. Part of my frustration with JavaScript was spending so many hours either A) reinventing the same things, or B) trying to get other people's stuff to do what I thought was advertised. All in the name of achieving some level of productivity that computers are ironically terrible at providing. I noticed after a while that I was trying to use JavaScript to control everything, including other languages and other variants of JavaScript. Racket was attractive because the structure of a "governing" language was already in place, with access to many more features. This made problems A and B seem less significant when I ran into them again, because I always had a way out of a technical corner. I agree with you about adapting tools to what people already know, but not for the same reasons. You mentioned "GUIs and spreadsheets." I think the productivity gains of a GUI do not discount the need for LOP. For example, my wife uses Excel for work, but she took the time to learn SQL, Excel Macros and VBA to address data problems that GUIs won't make easy for her (like making reports using inventory data in different formats from many international entities). She never planned to be a programmer, and she doesn't call herself one, but she became one by the circumstances of a global economy where everybody is doing their own thing. Another example: A lawyer reached out to me due to his interest in Racket, and how it can help him manage his firm's growing collection of evidence and notes. His rules for keeping the documents organized and mutually-reinforcing were sophisticated, but his staff was having trouble working within those rules. They would frequently ask him to clarify where to put a particular PDF. This lawyer (again, someone who does not identify as a programmer) has trouble with the file managers, search features, and the other organizational tools in their disposal. And when I listened to him speak, he was... thinking like a programmer! What does it tell you if my wife, an accountant, has to learn SQL and VBA to be an accountant?What does it tell you if a lawyer independently stumbles onto Racket and wonders what it could do for his business? It tells me that people's work is getting complicated, and you can't just say that Racket is failing to adapt to what people know. If we are going to live in a world of people forced into computer literacy, and GUIs are not able to cover these little openings to deep technical rabbit holes, then we need a way to help people keep moving when the things they know start to fail them. But what do we use to quickly synthesize complex and exact ideas at a moment's notice? Language. Why would I accomodate user's knowledge of tools that were too limited to help them in the first place? I can trust them to communicate, so why not give the words they know power? After all, they'll always have words. I don't know if LOP is the best answer, or the answer that will see the most adoption. All I know is that Racket is the most interesting attempt at the answer I've seen so far. ~slg ‐‐‐ Original Message ‐‐‐ On Sunday, January 3, 2021 4:26 AM, Leandro Facchinetti wrote: > Hi all, > > Here are the videos: > > Playing the Game with PLT Redex: https://youtu.be/NszLQNROdw0 > Understanding the Type of call/cc: https://youtu.be/7Zkt_IJaYOY > Racket: Why I Think It’s a Great Language, and Why I’m Not Using It Anymore: > https://youtu.be/_wY7FBtr7_c > > The first two used to be articles on my website (https://leafac.com), but I > changed the way the website is built and took them down. From time to time > people ask me about it, so here it is, in video form. > > I hope you like it. > > Best. > > -- > 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/16cbbdc6-63e6-4f78-8862-76f7ff52ec01n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/16cbbdc6-63e6-4f78-8862-76f7ff52ec01n%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
Re: [racket-users] Why do single-form modules behave differently?
I know about that. I asked why it was designed that way. Sent from ProtonMail mobile Original Message On Jan 3, 2021, 12:18 AM, Michael MacLeod wrote: > There's an edge case of 'module' when only one form is provided which results > in that form being partially expanded to determine if such expansion would > lead to a #%plain-module-begin form. Otherwise (more than one form provided) > they are wrapped in #%module-begin with no partial expansion occurring. > > I think this might be causing the discrepancy you witnessed. > > From the docs (https://docs.racket-lang.org/reference/module.html): > > If a single form is provided, then it is partially expanded in a module-begin > context. If the expansion leads to #%plain-module-begin, then the body of the > #%plain-module-begin is the body of the module. If partial expansion leads to > any other primitive form, then the form is wrapped with #%module-begin using > the lexical context of the module body; this identifier must be bound by the > initial module-path import, and its expansion must produce a > #%plain-module-begin to supply the module body. Finally, if multiple forms > are provided, they are wrapped with #%module-begin, as in the case where a > single form does not expand to #%plain-module-begin. > > (This response was adapted from one of my earlier replies to the mailing > list. Search racket-users for "perplexed by macro-expansion behavior near > #%module-begin" for more context). > > Best, > Michael > > On Sat, Jan 2, 2021 at 8:26 PM Sage Gerard wrote: > >> Why does Racket handle modules with exactly one form differently? >> >> I ran into a bug where modules in my module language won't expand if the >> modules have exactly one form, so I'm just curious. >> >> (Wild guess: It's Racket's way of checking for a shortcut to end expansion >> earlier) >> >> ~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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.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/KIgkgUi46OgANOqlif1csB0xaQQR2Z9I-jSlYmszXSGWsyFmt_XYpEPAzD7F_XguhZKv8OyU_EIA2pTxn8yvivQIj5hjyVzqgIpX9iNNs7o%3D%40sagegerard.com.
[racket-users] Why do single-form modules behave differently?
Why does Racket handle modules with exactly one form differently? I ran into a bug where modules in my module language won't expand if the modules have exactly one form, so I'm just curious. (Wild guess: It's Racket's way of checking for a shortcut to end expansion earlier) ~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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com.
Re: [racket-users] How do I control where expressions may appear in a module language?
Alright, I think I see how I confused myself. I load modules in my language dynamically. I use sandboxed evaluators instead of dynamic-require. I used replace-context on the entire module body to make the evaluators see values that I defined and provided during expansion. The problem was that in doing so, I coupled what a single module provided with the module language itself. I could not see a way to create a syntax-binding-set from an existing syntax object. Going off [1], I could only start with a blank set and add individual bindings. I used my blunt instrument and moved on because I was trying to design the language around how module evaluators worked, not the other way around. Thank you again, Jay. Your examples helped me see what I was doing. [1]: https://docs.racket-lang.org/reference/stxops.html#%28def._%28%28quote._~23~25kernel%29._syntax-binding-set%29%29 ~slg ‐‐‐ Original Message ‐‐‐ On Friday, January 1, 2021 12:51 PM, Sage Gerard wrote: > Alright, thank you for sticking with this. I'm refactoring now. > > ~slg > > ‐‐‐ Original Message ‐‐‐ > On Friday, January 1, 2021 11:56 AM, Jay McCarthy > wrote: > >> I’d imagine that you would only provide program and the modifiers. >> Everything well work out :) >> >> Jay >> >> On Fri, Jan 1, 2021 at 11:44 AM Sage Gerard wrote: >> >>> Ah, I see. Thank you for that! >>> >>> As for rephrasing my original question: If program were provided as >>> #%module-begin, I expect that syntax-protect would prevent a programmer from >>> using out the phase-0 bindings. But in my version of the program Racket >>> would keep complaining about unbound identifiers unless I provided >>> everything. >>> >>> The thing is, I don't want the user to be able to write things like >>> set-field* in their program just because I'm forced to provide it. >>> That's why I'm trying to figure out a way to say "Ok, this module language >>> happens to include set-field*, but set-field* must only appear >>> in module context, or not at all." >>> >>> ~slg >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Thursday, December 31, 2020 1:40 PM, Jay McCarthy >>> wrote: >>> >>>> I meant like this: >>>> >>>> ``` >>>> #lang racket/base >>>> (require (for-syntax racket/base >>>> syntax/parse) >>>> syntax/parse/define) >>>> >>>> ;; Run-time >>>> (struct state (a b c d) #:transparent) >>>> (define mt (state #f #f #f #f)) >>>> (define-simple-macro (set-field st:expr f:id v:expr) >>>> (struct-copy state st [f v])) >>>> (define-simple-macro (set-field* f:id v:expr) >>>> (λ (st) (set-field st f v))) >>>> >>>> ;; Compile-time >>>> (begin-for-syntax >>>> (define-struct modifier (f))) >>>> >>>> (define-simple-macro (define-modifier (m . args) body) >>>> (begin >>>> (define-syntax m-f >>>> (syntax-parser [(_ args) #'body])) >>>> (define-syntax m (modifier #'m-f >>>> >>>> (define-modifier (the-a-says x:string) >>>> (set-field* a x)) >>>> (define-modifier (the-b-says 'x:id) >>>> (set-field* b 'x)) >>>> (define-modifier (the-c-is x:string) >>>> (set-field* c x)) >>>> (define-modifier (the-d-looks-like x:nat) >>>> (set-field* d x)) >>>> >>>> (define-syntax-parser term >>>> [(_ ((~var m (static modifier? "state modifier")) . args)) >>>> #:with f (modifier-f (attribute m.value)) >>>> #'(f args)]) >>>> >>>> (define-syntax-parser program >>>> [(_) #'mt] >>>> [(_ x . more) #'((term x) (program . more))]) >>>> >>>> ;; Example >>>> (program >>>> (the-a-says "Aaah") >>>> (the-b-says 'Baah) >>>> (the-c-is "Caaah") >>>> (the-d-looks-like 42)) >>>> ``` >>>> >>>> -- >>>> Jay McCarthy >>>> Associate Professor @ CS @ UMass Lowell >>>> http://jeapostrophe.github.io >>>> Vincit qui se vincit. >>>> >>>> On Thu, Dec 31, 2020 at 12:07 PM Sage Gerard wrote: >>>> >>>>> I didn't see an answer to my original question, but I still want to make >>>>> sure I understood you before I rephrase. Thank you for the insights! >>>>> >>>>> By your
Re: [racket-users] Can someone please override the Reply-To so that normal replies go to the list?
Dominik*, apologies. ~slg ‐‐‐ Original Message ‐‐‐ On Friday, January 1, 2021 5:56 PM, Sage Gerard wrote: > > "Proper mail systems" "Now you know the reason" grrr g! > > Relax, I come in peace. > > Clients aren't created equal. I don't have a "reply to list" button. > I have "Reply" and "Reply All". I went through some settings to see > if there's a way to enable the feature, but no luck. > > I do, however, have other features that keep me on this client. > I don't expect the list to change their settings for the sake of one > client any more than others would expect me to change clients for the > sake of a list. That's why this is only a request. > > Going off Dominick's email, it would help to at least make sure the list > appears > in "To:" and not "Cc:", because then users of improper mail systems like me > can > quickly backspace out the individual recipients. As it stands now each of my > replies > has to re-addressed from scratch. I would think that in most cases, the > typical > behavior is to reply to the list and the exceptional behavior is to go off > list. > If that's true, is there something wrong with making the default behavior > more accessible to more clients? > > ~slg > > ‐‐‐ Original Message ‐‐‐ > On Friday, January 1, 2021 2:16 PM, Hendrik Boom hend...@topoi.pooq.com wrote: > > > On Fri, Jan 01, 2021 at 04:31:56PM +, Sage Gerard wrote: > > > > > The Reply-To experience for this list seems wrong. > > > Clicking normal "Reply" sets the reply to the person who last sent an > > > email to the thread, but not the list address. > > > Clicking "Reply All" sends a copy of the email to an increasingly larger > > > list of people, with the mail list CC'd. The extra copies can be annoying > > > for some, but it's a pain to manually edit the email recipients every > > > time such that only the user list is in the To: field. > > > > Proper mail systems use "reply to" indicate that the sender is sending > > from a location that is not where he wants to receive email. This might > > be because he is, for example, temprarily away from home. > > "Reply all" is indeed to send to everybody nvilved in the message. > > Proper mail systems also provide a command "reply to list". The proper > > fix is to make sure your mail system supports reply to list. > > > > > Unless there's a reason to keep it this way, can the email list admin > > > please see if this thread's solution still works for making Reply-To > > > default to us...@racket-lang.org? > > > https://support.google.com/a/thread/11037574?hl=en > > > > Now you know the reason. It makes it possible to reply to the original > > author where he can receive email, and independently to reply to the > > list. > > -- 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/lHKh92bB6DQk_PBQwD-m9XnaLGCHiLNxvsp6CjaWWsS2-ZsHs0uyp129ESe6LqioCh1muBv3dSuweCo-JfQGeQFTYth9YvngMMh0y1kVdnw%3D%40sagegerard.com.
Re: [racket-users] Can someone please override the Reply-To so that normal replies go to the list?
> "Proper mail systems" "Now you know the reason" grrr g! Relax, I come in peace. Clients aren't created equal. I don't have a "reply to list" button. I have "Reply" and "Reply All". I went through some settings to see if there's a way to enable the feature, but no luck. I do, however, have other features that keep me on this client. I don't expect the list to change their settings for the sake of one client any more than others would expect me to change clients for the sake of a list. That's why this is only a request. Going off Dominick's email, it would help to at least make sure the list appears in "To:" and not "Cc:", because then users of improper mail systems like me can quickly backspace out the individual recipients. As it stands now each of my replies has to re-addressed from scratch. I would think that in most cases, the typical behavior is to reply to the list and the exceptional behavior is to go off list. If that's true, is there something wrong with making the default behavior more accessible to more clients? ~slg ‐‐‐ Original Message ‐‐‐ On Friday, January 1, 2021 2:16 PM, Hendrik Boom wrote: > On Fri, Jan 01, 2021 at 04:31:56PM +, Sage Gerard wrote: > > > The Reply-To experience for this list seems wrong. > > Clicking normal "Reply" sets the reply to the person who last sent an email > > to the thread, but not the list address. > > Clicking "Reply All" sends a copy of the email to an increasingly larger > > list of people, with the mail list CC'd. The extra copies can be annoying > > for some, but it's a pain to manually edit the email recipients every time > > such that only the user list is in the To: field. > > Proper mail systems use "reply to" indicate that the sender is sending > from a location that is not where he wants to receive email. This might > be because he is, for example, temprarily away from home. > > "Reply all" is indeed to send to everybody nvilved in the message. > > Proper mail systems also provide a command "reply to list". The proper > fix is to make sure your mail system supports reply to list. > > > Unless there's a reason to keep it this way, can the email list admin > > please see if this thread's solution still works for making Reply-To > > default to us...@racket-lang.org? > > https://support.google.com/a/thread/11037574?hl=en > > Now you know the reason. It makes it possible to reply to the original > author where he can receive email, and independently to reply to the > list. > > -- 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/wHFPsnmmC6fVox7fAvgcYXatz5UhF7ywcCqyAt3TfUfOoa3Yy6mx_-hNW7oPlsDMCp41NDfeJAMZJW66bmnLJ20meRrocoiEwWdseqabBZk%3D%40sagegerard.com.
Re: [racket-users] How do I control where expressions may appear in a module language?
Alright, thank you for sticking with this. I'm refactoring now. ~slg ‐‐‐ Original Message ‐‐‐ On Friday, January 1, 2021 11:56 AM, Jay McCarthy wrote: > I’d imagine that you would only provide program and the modifiers. Everything > well work out :) > > Jay > > On Fri, Jan 1, 2021 at 11:44 AM Sage Gerard wrote: > >> Ah, I see. Thank you for that! >> >> As for rephrasing my original question: If program were provided as >> #%module-begin, I expect that syntax-protect would prevent a programmer from >> using out the phase-0 bindings. But in my version of the program Racket >> would keep complaining about unbound identifiers unless I provided >> everything. >> >> The thing is, I don't want the user to be able to write things like >> set-field* in their program just because I'm forced to provide it. >> That's why I'm trying to figure out a way to say "Ok, this module language >> happens to include set-field*, but set-field* must only appear >> in module context, or not at all." >> >> ~slg >> >> ‐‐‐ Original Message ‐‐‐ >> On Thursday, December 31, 2020 1:40 PM, Jay McCarthy >> wrote: >> >>> I meant like this: >>> >>> ``` >>> #lang racket/base >>> (require (for-syntax racket/base >>> syntax/parse) >>> syntax/parse/define) >>> >>> ;; Run-time >>> (struct state (a b c d) #:transparent) >>> (define mt (state #f #f #f #f)) >>> (define-simple-macro (set-field st:expr f:id v:expr) >>> (struct-copy state st [f v])) >>> (define-simple-macro (set-field* f:id v:expr) >>> (λ (st) (set-field st f v))) >>> >>> ;; Compile-time >>> (begin-for-syntax >>> (define-struct modifier (f))) >>> >>> (define-simple-macro (define-modifier (m . args) body) >>> (begin >>> (define-syntax m-f >>> (syntax-parser [(_ args) #'body])) >>> (define-syntax m (modifier #'m-f >>> >>> (define-modifier (the-a-says x:string) >>> (set-field* a x)) >>> (define-modifier (the-b-says 'x:id) >>> (set-field* b 'x)) >>> (define-modifier (the-c-is x:string) >>> (set-field* c x)) >>> (define-modifier (the-d-looks-like x:nat) >>> (set-field* d x)) >>> >>> (define-syntax-parser term >>> [(_ ((~var m (static modifier? "state modifier")) . args)) >>> #:with f (modifier-f (attribute m.value)) >>> #'(f args)]) >>> >>> (define-syntax-parser program >>> [(_) #'mt] >>> [(_ x . more) #'((term x) (program . more))]) >>> >>> ;; Example >>> (program >>> (the-a-says "Aaah") >>> (the-b-says 'Baah) >>> (the-c-is "Caaah") >>> (the-d-looks-like 42)) >>> ``` >>> >>> -- >>> Jay McCarthy >>> Associate Professor @ CS @ UMass Lowell >>> http://jeapostrophe.github.io >>> Vincit qui se vincit. >>> >>> On Thu, Dec 31, 2020 at 12:07 PM Sage Gerard wrote: >>> >>>> I didn't see an answer to my original question, but I still want to make >>>> sure I understood you before I rephrase. Thank you for the insights! >>>> >>>> By your three step suggestion, is something like this what you meant? I'm >>>> not sure I understood Step 3. It seems like I still have to add new >>>> structure types and macros to define new terms, which is about as >>>> laborious as what I was doing with #:datum-literals and struct-copy. >>>> >>>> (module id racket/base >>>> (require racket/format >>>> (for-syntax racket/base syntax/parse)) >>>> >>>> (begin-for-syntax (struct item (name num))) >>>> >>>> (define (record-item name num) >>>> (~a num ". " name)) >>>> >>>> (define-syntax (term stx) >>>> (syntax-parse stx >>>> #:literals ([stmt item #:phase 1]) >>>> [(_ (stmt name:id num:exact-positive-integer)) >>>> #'(define name (record-item 'name num))])) >>>> >>>> (define-syntax-rule (program x ...) >>>> (begin (term x) ...))) >>>> >>>> ~slg >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Thursday, December 31, 2020 9:45 AM, Jay McCarthy >>>> wrote: >>>> >>>>> Are you trying to take a macro argument and ensure that it is an >>>>> expression? If
Re: [racket-users] How do I control where expressions may appear in a module language?
Ah, I see. Thank you for that! As for rephrasing my original question: If program were provided as #%module-begin, I expect that syntax-protect would prevent a programmer from using out the phase-0 bindings. But in my version of the program Racket would keep complaining about unbound identifiers unless I provided everything. The thing is, I don't want the user to be able to write things like set-field* in their program just because I'm forced to provide it. That's why I'm trying to figure out a way to say "Ok, this module language happens to include set-field*, but set-field* must only appear in module context, or not at all." ~slg ‐‐‐ Original Message ‐‐‐ On Thursday, December 31, 2020 1:40 PM, Jay McCarthy wrote: > I meant like this: > > ``` > #lang racket/base > (require (for-syntax racket/base > syntax/parse) > syntax/parse/define) > > ;; Run-time > (struct state (a b c d) #:transparent) > (define mt (state #f #f #f #f)) > (define-simple-macro (set-field st:expr f:id v:expr) > (struct-copy state st [f v])) > (define-simple-macro (set-field* f:id v:expr) > (λ (st) (set-field st f v))) > > ;; Compile-time > (begin-for-syntax > (define-struct modifier (f))) > > (define-simple-macro (define-modifier (m . args) body) > (begin > (define-syntax m-f > (syntax-parser [(_ args) #'body])) > (define-syntax m (modifier #'m-f > > (define-modifier (the-a-says x:string) > (set-field* a x)) > (define-modifier (the-b-says 'x:id) > (set-field* b 'x)) > (define-modifier (the-c-is x:string) > (set-field* c x)) > (define-modifier (the-d-looks-like x:nat) > (set-field* d x)) > > (define-syntax-parser term > [(_ ((~var m (static modifier? "state modifier")) . args)) > #:with f (modifier-f (attribute m.value)) > #'(f args)]) > > (define-syntax-parser program > [(_) #'mt] > [(_ x . more) #'((term x) (program . more))]) > > ;; Example > (program > (the-a-says "Aaah") > (the-b-says 'Baah) > (the-c-is "Caaah") > (the-d-looks-like 42)) > ``` > > -- > Jay McCarthy > Associate Professor @ CS @ UMass Lowell > http://jeapostrophe.github.io > Vincit qui se vincit. > > On Thu, Dec 31, 2020 at 12:07 PM Sage Gerard wrote: > >> I didn't see an answer to my original question, but I still want to make >> sure I understood you before I rephrase. Thank you for the insights! >> >> By your three step suggestion, is something like this what you meant? I'm >> not sure I understood Step 3. It seems like I still have to add new >> structure types and macros to define new terms, which is about as laborious >> as what I was doing with #:datum-literals and struct-copy. >> >> (module id racket/base >> (require racket/format >> (for-syntax racket/base syntax/parse)) >> >> (begin-for-syntax (struct item (name num))) >> >> (define (record-item name num) >> (~a num ". " name)) >> >> (define-syntax (term stx) >> (syntax-parse stx >> #:literals ([stmt item #:phase 1]) >> [(_ (stmt name:id num:exact-positive-integer)) >> #'(define name (record-item 'name num))])) >> >> (define-syntax-rule (program x ...) >> (begin (term x) ...))) >> >> ~slg >> >> ‐‐‐ Original Message ‐‐‐ >> On Thursday, December 31, 2020 9:45 AM, Jay McCarthy >> wrote: >> >>> Are you trying to take a macro argument and ensure that it is an >>> expression? If so, then you can expand into `#%expression` >>> >>> https://docs.racket-lang.org/reference/__expression.html >>> >>> On the other hand, if you are trying to take a macro argument and ensure >>> that it is NOT an expression... then that means that you know what it is >>> allowed to be, so I don't think there's any better way than to just >>> enumerate what it CAN be. I think I would use a syntax class that specifies >>> the allowable patterns and then use that. For example, in my little >>> teachlog language, I have the `term` syntax class for this purpose >>> >>> https://github.com/jeapostrophe/teachlog/blob/master/main.rkt#L119 >>> >>> Looking at your code, I think what I would do is: >>> 1) Define a phase-1 structure that represents one of these fields and an >>> associated phase-0 function that records its values >>> 2) Define `define-syntax` bindings for each particular field as an instance >>> of these fields >>> 3) Write `update` as a short `syntax-parse` that expects a list where the >>> head is a static instance of the phase-1 structure and expands into an >>> applicat
[racket-users] Can someone please override the Reply-To so that normal replies go to the list?
The Reply-To experience for this list seems wrong. Clicking normal "Reply" sets the reply to the person who last sent an email to the thread, but not the list address. Clicking "Reply All" sends a copy of the email to an increasingly larger list of people, with the mail list CC'd. The extra copies can be annoying for some, but it's a pain to manually edit the email recipients every time such that only the user list is in the To: field. Unless there's a reason to keep it this way, can the email list admin please see if this thread's solution still works for making Reply-To default to us...@racket-lang.org? https://support.google.com/a/thread/11037574?hl=en ~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/LZSkHxy_NLVAztRfSIogMZ4JDZ8w5l_9DJvNSkQFWq74gyA1g5bE5kkdo2CxuQ9SYkLUvjKkNoem1AP2qQSqNLVPiOqjnsKJW4QQqBn0P6I%3D%40sagegerard.com.
Re: [racket-users] How do I control where expressions may appear in a module language?
I didn't see an answer to my original question, but I still want to make sure I understood you before I rephrase. Thank you for the insights! By your three step suggestion, is something like this what you meant? I'm not sure I understood Step 3. It seems like I still have to add new structure types and macros to define new terms, which is about as laborious as what I was doing with #:datum-literals and struct-copy. (module id racket/base (require racket/format (for-syntax racket/base syntax/parse)) (begin-for-syntax (struct item (name num))) (define (record-item name num) (~a num ". " name)) (define-syntax (term stx) (syntax-parse stx #:literals ([stmt item #:phase 1]) [(_ (stmt name:id num:exact-positive-integer)) #'(define name (record-item 'name num))])) (define-syntax-rule (program x ...) (begin (term x) ...))) ~slg ‐‐‐ Original Message ‐‐‐ On Thursday, December 31, 2020 9:45 AM, Jay McCarthy wrote: > Are you trying to take a macro argument and ensure that it is an expression? > If so, then you can expand into `#%expression` > > https://docs.racket-lang.org/reference/__expression.html > > On the other hand, if you are trying to take a macro argument and ensure that > it is NOT an expression... then that means that you know what it is allowed > to be, so I don't think there's any better way than to just enumerate what it > CAN be. I think I would use a syntax class that specifies the allowable > patterns and then use that. For example, in my little teachlog language, I > have the `term` syntax class for this purpose > > https://github.com/jeapostrophe/teachlog/blob/master/main.rkt#L119 > > Looking at your code, I think what I would do is: > 1) Define a phase-1 structure that represents one of these fields and an > associated phase-0 function that records its values > 2) Define `define-syntax` bindings for each particular field as an instance > of these fields > 3) Write `update` as a short `syntax-parse` that expects a list where the > head is a static instance of the phase-1 structure and expands into an > application of the associate phase-0 function on the arguments > > This would allow you to better abstract things so you don't have tie the > `update` function to the particular fields. > > Jay > > -- > Jay McCarthy > Associate Professor @ CS @ UMass Lowell > http://jeapostrophe.github.io > Vincit qui se vincit. > > On Wed, Dec 30, 2020 at 10:20 PM Sage Gerard wrote: > >> I'm trying to learn how to restrict where expressions appear. Those >> expressions might be procedure applications, or macros before expansion. >> >> [1] shows a library I use to help me implement a collection pass for a >> module language. To save you some reading, it uses syntax-parse with a >> lengthy #:datum-literals. That's the only way I know how to restrict what >> expressions appear in module context. >> >> One element of the #:datum-literals happens to share an identifier with a >> bound procedure, so I expand the calls as-is in a module-level expression >> [2][3]. I want that procedure to be applied ONLY in the module context, but >> nothing in the language enforces that. >> >> I don't know what I don't know. Could I please get a link to a part of the >> documentation that teaches me what I need to understand? I'm tied between >> querying syntax properties for a fully expanded module, and writing a second >> set of macros that somehow know where they should be. Not sure which is best. >> >> [1]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt >> [2]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L111 >> [3]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L156 >> >> ~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/bVbaZ_0mwFcWTIaeuwqMUr7TVY6Rhr5dusG9LkbT0gqW7gWIYAb8IOEUYnKQPIVR2ZrDGm9QMGnW-2YvYqw81oUJVCSCuwhuX_Wx2OGVG-w%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/bVbaZ_0mwFcWTIaeuwqMUr7TVY6Rhr5dusG9LkbT0gqW7gWIYAb8IOEUYnKQPIVR2ZrDGm9QMGnW-2YvYqw81oUJVCSCuwhuX_Wx2OGVG-w%3D%40sagegerard.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/AqmR-7s3hD8k0bf_kMXDsZzwswfEDWXltrNMX4L8EmghOzqZdXHsptRiSANiepcq-m_JBjriooGpx8PbJmu9Bppci68ViREo6un9Fv0uXM0%3D%40sagegerard.com.
[racket-users] How do I control where expressions may appear in a module language?
I'm trying to learn how to restrict where expressions appear. Those expressions might be procedure applications, or macros before expansion. [1] shows a library I use to help me implement a collection pass for a module language. To save you some reading, it uses syntax-parse with a lengthy #:datum-literals. That's the only way I know how to restrict what expressions appear in module context. One element of the #:datum-literals happens to share an identifier with a bound procedure, so I expand the calls as-is in a module-level expression [2][3]. I want that procedure to be applied ONLY in the module context, but nothing in the language enforces that. I don't know what I don't know. Could I please get a link to a part of the documentation that teaches me what I need to understand? I'm tied between querying syntax properties for a fully expanded module, and writing a second set of macros that somehow know where they should be. Not sure which is best. [1]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt [2]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L111 [3]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L156 ~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/bVbaZ_0mwFcWTIaeuwqMUr7TVY6Rhr5dusG9LkbT0gqW7gWIYAb8IOEUYnKQPIVR2ZrDGm9QMGnW-2YvYqw81oUJVCSCuwhuX_Wx2OGVG-w%3D%40sagegerard.com.
Re: [racket-users] Using expr/c within one syntax class?
Fantastic, thank you for getting me on my way. I followed your advice where I
do not use string-producing expressions and ended up with a follow up question.
New syntax classes are below for those reading.
(define (unbounded? v)
(equal? "*" v))
(define-syntax-class racket-version-or-*
(pattern (~var bound string)
#:when (let ([v (syntax-e #'bound)])
(or (unbounded? v)
(valid-version? v)
(define-syntax-class racket-version-selection
#:attributes (min max)
(pattern (~and (min:racket-version-or-* max:racket-version-or-*)
(~fail #:unless (let ([min-v (syntax-e #'min)] [max-v (syntax-e #'max)])
(or (unbounded? min-v)
(unbounded? max-v)
(version<=? min-v max-v)))
"minimum Racket version cannot exceed maximum Racket version")))
(pattern (~and (~var v racket-version-or-*)
(~bind [min #'v] [max #'v]
Note the condition set in racket-version-selection that checks for backwards
ranges. From what I understand, it only raises a pattern failure, which means I
only see the ~fail error message for:
(syntax-parse #'(("8.4" "8.3"))
[(v:racket-version-selection ...) #t])
but not
(syntax-parse #'(("8.4" "8.3"))
[(v:racket-version-selection ...) #t]
[_ #f])
In this case, is it better form to use raise-syntax-error in a #:when pattern
directive for a syntax class, or beneath a clause of syntax-parse? I suspect
that syntax classes should not have an opinion about flow control.
~slg
‐‐‐ Original Message ‐‐‐
On Thursday, December 17, 2020 4:52 AM, Ryan Culpepper
wrote:
> Based on what you have written so far, the `versions` macro has no
> sub-expressions, so you shouldn't use `expr/c` at all. It requires version
> bounds to be in the form of literal strings. So you could describe the macro
> using a grammar as follows:
>
> Expression ::= | (versions Version ...)
> Version ::= VersionBound | (VersionBound VersionBound)
> VersionBound ::= String
>
> I think what you want to do is refine VersionBound so that it only accepts
> strings of a certain form. The best way to do that is with a separate syntax
> class that matches a string and then puts additional side-conditions on it
> (using `#:when`, etc). That is, you check the `valid-version?` predicate at
> compile-time.
>
> By the way, you should also avoid treating the literal strings that your
> macro receives as if they were also expressions. A syntax object containing a
> literal string is *not necessarily* a string-valued expression. Once your
> macro views and validates something as a literal string, the proper way to
> convert it to a run-time expression is to explicitly quote it. Consider the
> following test case:
>
> (let-syntax ([#%datum (lambda (stx) #'(exit '0))]) (versions ("7.0"
> "7.7.0.5") "6.5"))
>
> If your macro produces eg (list (make-version-range (quote "7.0") (quote
> "7.7.0.5")) (quote "6.5")), then it's fine; if it produces (list
> (make-version-range "7.0" "7.7.0.5") "6.5"), then it would exit. This
> particular example is unlikely to happen in practice, but I think it is
> useful to think clearly about how interpret each argument of a macro. Treat
> it as a literal string or as an expression, but not both.
>
> A different design would be to say that VersionBound is an expression that
> produces a string. That would cause problems with your current grammar,
> because you couldn't tell whether `(f "1.2.3")` was a single version (whose
> value is produced by a function call) or by a range (whose lower bound is the
> variable f). But you could change the grammar to avoid that problem. Then you
> could use `expr/c` to wrap the expressions to check that at run time they
> produced strings of the proper form.
>
> Ryan
>
> On Thu, Dec 17, 2020 at 12:55 AM Sage Gerard wrote:
>
>> Typos:
>>
>> - "*" remove a bound ==> "*" removes a bound
>> - All examples should read (versions ...), not (version ...)
>>
>> ~slg
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, December 16, 2020 6:27 PM, Sage Gerard
>> wrote:
>>
>>> I'm trying to learn how to write syntax classes. My intended macro
>>> expresses a set of Racket versions, either as inclusive intervals or as
>>> exact versions. In an interval, "*" remove a bound.
>>>
>>> - (version "6.5") means exactly version "6.5", as does (version ("6.5"
>>> "6.5"))
>>>
>>> - (versions ("7.0" "7.7.0.5")) means the inclusive interval between version
>>> 7.0 and 7.7.0.5
>>> - (versions ("7.0" "7.7.0.5&q
Re: [racket-users] Using expr/c within one syntax class?
Typos:
- "*" remove a bound ==> "*" removes a bound
- All examples should read (versions ...), not (version ...)
~slg
‐‐‐ Original Message ‐‐‐
On Wednesday, December 16, 2020 6:27 PM, Sage Gerard
wrote:
> I'm trying to learn how to write syntax classes. My intended macro expresses
> a set of Racket versions, either as inclusive intervals or as exact versions.
> In an interval, "*" remove a bound.
>
> - (version "6.5") means exactly version "6.5", as does (version ("6.5" "6.5"))
>
> - (versions ("7.0" "7.7.0.5")) means the inclusive interval between version
> 7.0 and 7.7.0.5
> - (versions ("7.0" "7.7.0.5") "6.5"): union of the above two items
> - (versions ("6.0" "*")): all Racket versions >= 6.0
> - (versions "*"), (versions ("*" "*")): all Racket versions
>
> I was able to define the syntax class without much issue:
>
> (define-syntax-class racket-version-selection
> #:attributes (min max)
> (pattern (min:string max:string))
> (pattern (~and (~var v string)
> (~bind [min #'v]
> [max #'v]
>
> Now I want each attribute-bound expression V to satisfy (or (valid-version?
> V) (equal? V "*")). Where I'm stuck is how I can use #:declare with (expr/c)
> here. From what I understand, expr/c does not really mean much because it
> accepts an expression (as in the expr syntax-class), not attributes.
>
> The only way I can think to fix this is to perform an additional syntax-parse
> so that I can use the attributes in an expression for expr/c to consume. But
> is it possible to do everything I'm thinking of in just one syntax class?
>
> ~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/syiNcw0zJpSyA16fO8OkClrQmXFOC4qZEwrBm3JwETX-bGJGlALnP6Apn4ttCbIzMZUoobO7AT4MyRDm9ID0oUA648nXXSAZ1nvaCaj2NbI%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/syiNcw0zJpSyA16fO8OkClrQmXFOC4qZEwrBm3JwETX-bGJGlALnP6Apn4ttCbIzMZUoobO7AT4MyRDm9ID0oUA648nXXSAZ1nvaCaj2NbI%3D%40sagegerard.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/nfmcqQmNc3_H9zeCyS49LELvXomDYQF2sJbmyrJchu0kiWG8CXJiyS932ZfQ_eSW3cnEYTTzOwqakNlKL4FF_KR4F7HnAARLdQLDVEGxSI0%3D%40sagegerard.com.
[racket-users] Using expr/c within one syntax class?
I'm trying to learn how to write syntax classes. My intended macro expresses a
set of Racket versions, either as inclusive intervals or as exact versions. In
an interval, "*" remove a bound.
- (version "6.5") means exactly version "6.5", as does (version ("6.5" "6.5"))
- (versions ("7.0" "7.7.0.5")) means the inclusive interval between version 7.0
and 7.7.0.5
- (versions ("7.0" "7.7.0.5") "6.5"): union of the above two items
- (versions ("6.0" "*")): all Racket versions >= 6.0
- (versions "*"), (versions ("*" "*")): all Racket versions
I was able to define the syntax class without much issue:
(define-syntax-class racket-version-selection
#:attributes (min max)
(pattern (min:string max:string))
(pattern (~and (~var v string)
(~bind [min #'v]
[max #'v]
Now I want each attribute-bound expression V to satisfy (or (valid-version? V)
(equal? V "*")). Where I'm stuck is how I can use #:declare with (expr/c) here.
From what I understand, expr/c does not really mean much because it accepts an
expression (as in the expr syntax-class), not attributes.
The only way I can think to fix this is to perform an additional syntax-parse
so that I can use the attributes in an expression for expr/c to consume. But is
it possible to do everything I'm thinking of in just one syntax class?
~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/syiNcw0zJpSyA16fO8OkClrQmXFOC4qZEwrBm3JwETX-bGJGlALnP6Apn4ttCbIzMZUoobO7AT4MyRDm9ID0oUA648nXXSAZ1nvaCaj2NbI%3D%40sagegerard.com.
Re: [racket-users] Re: TLS via make-ssl-connect@?
Missed Ryan's email earlier. Thanks Ryan! ~slg ‐‐‐ Original Message ‐‐‐ On Tuesday, December 15, 2020 3:27 PM, Sage Gerard wrote: > Answering my own question for those searching. > > Yes, make-ssl-connect@ tracks protocol recommendations. [1] shows that > make-ssl-connect@ uses `ssl-make-server-context' with default arguments, > meaning an `auto' protocol. The server context docs point to client context > docs for the meaning of `'auto'. Quote: "Automatically negotiates the > protocol version from those that this library considers sufficiently > secure—currently TLS versions 1.0 and higher, but subject to change." > > [1]: > https://github.com/racket/web-server/blob/ba1b1cf5c49a589f7f4baaa4100db917ed9e1611/web-server-lib/web-server/web-server.rkt#L74 > > ~slg > > ‐‐‐ Original Message ‐‐‐ > On Thursday, December 10, 2020 7:47 PM, Sage Gerard > wrote: > >> I've seen articles say "SSL" when they mean "TLS". When I read the docs for >> make-ssl-connect@, it does not clarify what algorithm backs use of HTTPS. >> Only that OpenSSL is used. >> >> Does make-ssl-connect@ track current recommendations like TLS 1.2 or 1.3, or >> is it fixed to some version of SSL? >> >> ~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/vxXP0HqAp6LwIb9rfxWNqCSwQCvuqAfyCcIWWB2Up0uuce7hDq-oM3zq8Uno5vkjn06i8oU0MxstBrJlEZUsnnnICb6LDbZ-x6wPh98Bv2I%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/vxXP0HqAp6LwIb9rfxWNqCSwQCvuqAfyCcIWWB2Up0uuce7hDq-oM3zq8Uno5vkjn06i8oU0MxstBrJlEZUsnnnICb6LDbZ-x6wPh98Bv2I%3D%40sagegerard.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/Y8h3feSdKUfPG_1VRIChSTGNXJtFN1Vt26yAfwMohO-ZMJFWBejmx0UlaPUPhi5N9sKVfRUrzhG1JIyCiLXBrtm0p7K-BQT9b05hLc4bjEM%3D%40sagegerard.com.
[racket-users] Re: TLS via make-ssl-connect@?
Answering my own question for those searching. Yes, make-ssl-connect@ tracks protocol recommendations. [1] shows that make-ssl-connect@ uses `ssl-make-server-context' with default arguments, meaning an `auto' protocol. The server context docs point to client context docs for the meaning of `'auto'. Quote: "Automatically negotiates the protocol version from those that this library considers sufficiently secure—currently TLS versions 1.0 and higher, but subject to change." [1]: https://github.com/racket/web-server/blob/ba1b1cf5c49a589f7f4baaa4100db917ed9e1611/web-server-lib/web-server/web-server.rkt#L74 ~slg ‐‐‐ Original Message ‐‐‐ On Thursday, December 10, 2020 7:47 PM, Sage Gerard wrote: > I've seen articles say "SSL" when they mean "TLS". When I read the docs for > make-ssl-connect@, it does not clarify what algorithm backs use of HTTPS. > Only that OpenSSL is used. > > Does make-ssl-connect@ track current recommendations like TLS 1.2 or 1.3, or > is it fixed to some version of SSL? > > ~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/vxXP0HqAp6LwIb9rfxWNqCSwQCvuqAfyCcIWWB2Up0uuce7hDq-oM3zq8Uno5vkjn06i8oU0MxstBrJlEZUsnnnICb6LDbZ-x6wPh98Bv2I%3D%40sagegerard.com.
[racket-users] TLS via make-ssl-connect@?
I've seen articles say "SSL" when they mean "TLS". When I read the docs for make-ssl-connect@, it does not clarify what algorithm backs use of HTTPS. Only that OpenSSL is used. Does make-ssl-connect@ track current recommendations like TLS 1.2 or 1.3, or is it fixed to some version of SSL? ~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/t-JBfoazXqCWIYKge0qFCn9IYCYEdzkSQD9F6IrFWT8VcrziFFcgHVz_tZolCnyFd7yq26lpLahbKBNg9Pt_mIBkwMZfjL2iGQw4bZDAVe0%3D%40sagegerard.com.
Re: [racket-users] Why are these @defthing blocks typeset incorrectly?
I opted for the read-syntax based solution. For those reading, it's convenient to use `replace-context` from `syntax/strip-context` to donate lexical info. The form of the transformer I used is: @(define-syntax (reformat stx) (replace-context stx (read-syntax #f (open-input-string (with-output-to-string (lambda () (pretty-write `(begin . [...] ~slg ‐‐‐ Original Message ‐‐‐ On Wednesday, September 23, 2020 8:07 PM, Philip McGrath wrote: > I have encountered this problem. I don't have a real solution, but maybe my > hacky solution will be good enough. > > On Wed, Sep 23, 2020 at 7:37 PM Sorawee Porncharoenwase > wrote: > >> I think Scribble uses source location equipped with syntax objects to figure >> out spacing. Since you generate stuff on the fly, there’s no source >> location, so the rendered text is screwed up. > > This is indeed the explanation. My hacky solution (you can see it > [here](https://github.com/DigitalRicoeur/pydrnlp/blob/666c1e00b67c0cc1ee6b5e3fbcfbec498b3173ac/support/python-lang/stx.rkt#L201-L208)) > is to build up term for Scribble to typeset—the equivalent of what you do > [here](https://github.com/zyrolasting/xiden/blob/cb60c9d3ad06b60097b38e19d2d6f565ff9738c0/docs/reference/settings.scrbl#L37-L42), > I think—using `syntax` rather than `quasiquote`. IIRC (I haven't touched > this code in a while), it didn't work to use `quasisyntax`/`unsyntax`, so I > used `define/syntax-parse` to bind pattern variables to the generated > sub-terms. This way, Scribble picks up the source locations from the template > and uses spaces as it should. > > This is a hack, though: in my case, I'm building a `let*` expression with > potentially several binding pairs, and they will run off the margin of the > page. There are probably various other problems: I remember this code being a > bit annoying to write. > > -Philip -- 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/CiSghugs88ldFptWHmfNDO0714NsRwS52CdG6Gmn8BowdGmT_q_xCdvBbGdzCPoHuxDvALOlqphQ8wnSWXvpLY9m5-m6dtFDOCYh5pOj1eQ%3D%40sagegerard.com.
[racket-users] Why are these @defthing blocks typeset incorrectly?
I attached an image showing the rendered output of https://github.com/zyrolasting/xiden/blob/master/docs/reference/settings.scrbl#L48 I create an application to `(defthing)` as a datum due to circumstances in the surrounding code. The hacky part being `get-contract-datum`, which tries to produce a datum usable as a contract expression. I'm assuming that this leaves no whitespace to preserve, so how do I modify a syntax object to include space in desired spots? ~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/ulye9ZNaZmcspsE7fqy6ctobuGcF21jQvGQ4-PG2Eynt09KBU9AbF_kP9UZ_OgouhcvBOF8JLbaCJpVbnve-6RF_E752tVqp-xR9Va3oRsE%3D%40sagegerard.com.
