Re: [racket-users] Some DrRacket preferences unreadable

2022-12-30 Thread Robby Findler
I am sorry to hear that. But it may be something specific to that
particular font. My favorite fixed width font is Inconsolata but there are
a lot of good options out there. Might be worth trying some others?

Robby

On Fri, Dec 30, 2022 at 5:45 AM AvW  wrote:

> Indeed I did change the system font a while ago.
> The reason for that was that I very much like to have a non-proportional
> font (especially in the explorer).
>
> And yes, reverting it to the default font is the solution!
>
> But maybe is would be possible to change this behaviour of DrRacket.
> Since in most tabs of the Preferences Window it does work out-of-the-box,
> I cannot understand why in those cases it works differently ...
>
> Anyway, many thanks.
> Now I must cope with that ugly proportional font :-)
>
> Op donderdag 29 december 2022 om 15:26:02 UTC+1 schreef Robby Findler:
>
>> For those shown portions of the UI, I believe DrRacket is trying to use
>> the system font. It looks like that font is reporting size information in a
>> way that confuses something, somehow (I am not sure how).
>>
>> Has the system font been changed? Can you reset it back to a default to
>> see if that improves the situation?
>>
>> Robby
>>
>> On Thu, Dec 29, 2022 at 7:48 AM Jens Axel Søgaard 
>> wrote:
>>
>>> This looks odd indeed.
>>>
>>> Does it help to:
>>>   1. Change the font DrRacket uses
>>>   2. Restart DrRacket
>>>
>>>
>>> Den tor. 29. dec. 2022 kl. 13.54 skrev AvW :
>>>
>>>> Hi,
>>>>
>>>> after having installed Racket 8.7 (Windows 64 bit) I cannot read 3 tabs
>>>> of the preferences window; the other tabs appear to be OK.
>>>>
>>>> See attachments.
>>>>
>>>> Some relevant data:
>>>> - Windows 11 Pro 22H2 build 22621.963
>>>> - Racket installation: racket-8.7-x86_64-win32-cs.exe
>>>>
>>>> Any ideas?
>>>>
>>>> TIA,
>>>>Arie
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Racket Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to racket-users...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/racket-users/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com
>>>> .
>>>>
>>>> Beyond the Racket Users Google Group, Racket Discussions take place on
>>>> Discourse ( https://racket.discourse.group/ ) and Discord (
>>>> https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes
>>>> place on the Racket Slack https://racket.slack.com/ ( sign up at
>>>> https://racket-slack.herokuapp.com/ ), and IRC #racket
>>>> https://kiwiirc.com/nextclient/irc.libera.chat/#racket
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Racket Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to racket-users...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/racket-users/4ba70e7b-e7ac-4720-898a-d9548dbc8426n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/racket-users/4ba70e7b-e7ac-4720-898a-d9548dbc8426n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> --
>>> Jens Axel Søgaard
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com
>>> .
>>>
>>> Beyond the Racket Users Google Group, Racket Discussions take place on
>>> Discourse ( https://racket.discourse.group/ ) and Discord (
>>> https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes
>>> place on the Racket Slack https://racket.slack.com/ ( sign up at
>>> https://racket-slack.herokuapp.com/ ), and IRC #racket
>>> https://kiwiirc.com/nextclient/irc.libera.chat/#racket
>>> ---
>>> You rec

Re: [racket-users] Some DrRacket preferences unreadable

2022-12-29 Thread Robby Findler
For those shown portions of the UI, I believe DrRacket is trying to use the
system font. It looks like that font is reporting size information in a way
that confuses something, somehow (I am not sure how).

Has the system font been changed? Can you reset it back to a default to see
if that improves the situation?

Robby

On Thu, Dec 29, 2022 at 7:48 AM Jens Axel Søgaard 
wrote:

> This looks odd indeed.
>
> Does it help to:
>   1. Change the font DrRacket uses
>   2. Restart DrRacket
>
>
> Den tor. 29. dec. 2022 kl. 13.54 skrev AvW :
>
>> Hi,
>>
>> after having installed Racket 8.7 (Windows 64 bit) I cannot read 3 tabs
>> of the preferences window; the other tabs appear to be OK.
>>
>> See attachments.
>>
>> Some relevant data:
>> - Windows 11 Pro 22H2 build 22621.963
>> - Racket installation: racket-8.7-x86_64-win32-cs.exe
>>
>> Any ideas?
>>
>> TIA,
>>Arie
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com
>> .
>>
>> Beyond the Racket Users Google Group, Racket Discussions take place on
>> Discourse ( https://racket.discourse.group/ ) and Discord (
>> https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes
>> place on the Racket Slack https://racket.slack.com/ ( sign up at
>> https://racket-slack.herokuapp.com/ ), and IRC #racket
>> https://kiwiirc.com/nextclient/irc.libera.chat/#racket
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/4ba70e7b-e7ac-4720-898a-d9548dbc8426n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> --
> Jens Axel Søgaard
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com
> .
>
> Beyond the Racket Users Google Group, Racket Discussions take place on
> Discourse ( https://racket.discourse.group/ ) and Discord (
> https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes
> place on the Racket Slack https://racket.slack.com/ ( sign up at
> https://racket-slack.herokuapp.com/ ), and IRC #racket
> https://kiwiirc.com/nextclient/irc.libera.chat/#racket
> ---
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CABefVgyCS3Wg4Sh2vTy3d7gQJeUTNbzpzqRkMSH1DEjVwPQnhg%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/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com.

Beyond the Racket Users Google Group, Racket Discussions take place on 
Discourse ( https://racket.discourse.group/ ) and Discord ( 
https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes place on 
the Racket Slack https://racket.slack.com/ ( sign up at 
https://racket-slack.herokuapp.com/ ), and IRC #racket 
https://kiwiirc.com/nextclient/irc.libera.chat/#racket
--- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOEhO5AMjpkcuqK_i0%3DxGJ1%3DAmpyQ-kzgryriVuPXNHkw%40mail.gmail.com.


Re: [racket-users] [meta] Please review pending member requests?

2022-06-30 Thread Robby Findler
I've just approved the ones who wrote sensible comments. If that wasn't the
one to approve, please let me know and I'll approve that one, too.

We had a serious spam problem on this list due to bots (I presume)
subscribing, so I'm a bit gunshy about adding folks. There are other list
admins too who might have some better predicate than mine for identifying
actual people to let in, tho!

Robby


On Thu, Jun 30, 2022 at 10:10 AM thomas_d...@alumni.brown.edu <
thomas_dicker...@alumni.brown.edu> wrote:

> thanks for the heads up - I'll pass it along :)
>
> On Thursday, June 30, 2022 at 10:30:23 AM UTC-4 jry...@gmail.com wrote:
>
>> I am not a list admin, so I can't help with your original request,
>> but... I thought it would be good to highlight that nearly all Racket
>> discussion has moved away from these mailing lists and over to the
>> Discourse-based forum at https://racket.discourse.group. I would
>> recommend moving over there instead as you're more likely to get
>> replies.
>>
>> - Ryan
>>
>> On Thu, 30 Jun 2022 at 15:24, thomas_d...@alumni.brown.edu
>>  wrote:
>> >
>> > Hi Admins - If you could approve pending subscription requests for the
>> listserv that would be great. One of my interns has been stuck in the queue
>> for more than a week
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to racket-users...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/ddaac2fb-8ac5-4a79-84a6-adad2053a690n%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/4b27b303-a7b6-4f46-bd8d-c800e8ac55acn%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/CAL3TdOPML40TNeuZtCae1pjopKsRAWa%3D7OktLqk7Q-Xf%2BRmLeg%40mail.gmail.com.


[racket-users] Re: Combining contract checking with normalization?

2022-03-06 Thread Robby Findler
I have certainly have thought that developing a library along these lines
is a good idea for many years!

Robby

On Sun, Mar 6, 2022 at 9:47 AM Alexis King  wrote:

> Hello,
>
> As a user of the Racket contract system, I sometimes find myself thinking
> about the potential utility of “coercing” or “canonicalizing” contracts. In
> Racket programs, we often idiomatically allow values to be provided to a
> function in a non-canonical form for the sake of convenience. One example
> is the commonly-used path-string? contract, which is morally equivalent
> to using path? but allows the caller to omit an explicit use of
> string->path. Another example is the commonly-used failure-result/c
> contract, which allows the caller to omit wrapping non-procedures in a
> thunk.
>
> While this idiom does make life easier for one party to the contract, it
> ultimately just transfers the burden of canonicalizing the value to the
> other party. This is unfortunate, because it results in a duplication of
> both logic and work:
>
>-
>
>Code to canonicalize the value must be written separately and kept in
>sync with the contract, which is error-prone.
>-
>
>The value ends up being inspected twice: once to determine if it
>satisfies the contract, and a second time to convert it to canonical form.
>
> (In the nomenclature of a popular blog post I wrote a few years ago, these
> contracts are validating, not parsing
> .)
>
> In theory, it is perfectly possible to implement a canonicalizing contract
> using the current contract system. However, such a contract has several
> practical downsides:
>
>-
>
>It is necessarily an impersonator contract, not a chaperone contract.
>This prevents its use in places that demand a chaperone contract, such as
>the *key* argument to hash/c.
>-
>
>It moves actual logic into the contract itself, which means using the
>uncontracted value directly is less convenient. This encourages placing the
>contract boundary close to the value’s definition to create a very small
>contracted region (e.g. via define/contract), even though blame is
>generally more useful when the contract boundary corresponds to a boundary
>between higher-level components (e.g. via contract-out).
>-
>
>There is no way to write such contracts using the combinators provided
>by racket/contract, so they must be implemented via the lower level
>make-contract/build-contract-property API. This can be subtle to use
>correctly, and it makes it unlikely that contract violations made by the
>contract itself will be blamed properly according to the “indy” blame
>semantics used by ->i.
>
> All this is to say that the current contract system clearly discourages
> this use of contracts, which suggests this would be considered an abuse of
> the contract system. Nevertheless, the coupling between validating values
> and converting them to a normal form is so enormously tight that allowing
> them to be specified together remains incredibly compelling. I therefore
> have two questions:
>
>1.
>
>Has this notion of “canonicalizing” contracts been discussed before,
>whether in informal discussions or in literature?
>2.
>
>Is there any existing work that explores what adding such contracts to
>a Racket-style, higher-order contract system in a principled fashion might
>look like?
>
> Thanks in advance,
> Alexis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMO3%2BEApMTyTmjxhzOZJ%2BUGE5P6h%3Dx1xTqDi7AgB3mggQ%40mail.gmail.com.


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

2022-01-12 Thread Robby Findler
Great! I think I get moderation messages too, and I'm happy to help out in
letting people in.

Robby

On Wed, Jan 12, 2022 at 12:25 PM Sage Gerard  wrote:

> 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 <
> sa...@indiana.edu> 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 reco

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

2022-01-11 Thread Robby Findler
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 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.&q

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

2022-01-11 Thread Robby Findler
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
> >> > 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.
> >> >
> >> >
> >> >
> >

Re: [racket-users] Formal semantics of PLT Redex

2021-12-21 Thread Robby Findler
There was a bug in the matcher; I've pushed a fix.

With that fix, you'll get

(list
 (match
  (list
   (bind 'A '(hole (hole hole)))
   (bind 'x '(hole (hole hole))

as the result. That's different than the matcher because the pattern `A` is
really shorthand for something like `(name A (nt A))`, where the `name`
part introduces the name and the `nt` pattern matching construct matches
only non-terminals without binding a name.

Thanks for finding the bug!

Robby


On Tue, Dec 21, 2021 at 2:50 PM Mallku Ernesto Soldevila Raffa <
mallkuerne...@gmail.com> wrote:

> Just to clarify, I understand that the several binds of x correspond to
> the several patterns name in the productions, and the pattern against with
> we are matching, but I would have expected for the firsts to be discarded,
> or, if still considered in the resulting match for some reason, that I
> don't
> know, I would have expected for the application of the constraint of
> names,
> that would have rendered #f the match.
>
> thanks!,
> Mallku
>
> El martes, 21 de diciembre de 2021 a las 17:38:28 UTC-3, Mallku Ernesto
> Soldevila Raffa escribió:
>
>> Hi to everyone!,
>> I'm trying to test the mechanization of Redex's semantics done in [1],
>> against the present version of racket, 8.3. I'm using the 
>> random-match-test.rkt
>>
>> module from [1] to generate random grammars, patterns and terms, and to
>> test them
>> using the proposed mechanization of Redex in [1] and the actual
>> implementation of
>> it, in racket 8.3.
>>
>> In doing it, I've found an example that I cannot explain in terms of my
>> understanding
>> of the behavior of the name pattern:
>>
>> (define-language L [A (name x B)]
>>[B (hole (name x (hole hole)))])
>>
>> (redex-match L (name x A)
>>(term (hole (hole hole
>>
>> The result of the previous match is:
>>
>> (list (match (list
>>   (bind 'A '(hole (hole hole)))
>>   (bind 'x '(hole hole))
>>   (bind 'x '(hole (hole hole)))
>>   (bind 'x '(hole (hole hole))
>>
>> Which shows that 'x' is bound to different, non-equivalent, terms. While
>> I've never used the pattern name explicitly in such a way, while defining
>> grammars, I'm still curious about what is going on here. Even more, I
>> would
>> have thought that the following match would return the same result as the
>> previous:
>>
>> (redex-match L (name x (name x B))
>>(term (hole (hole hole
>>
>> where I just replaced the non-term A by the rhs of its only production,
>> but
>> what I obtain is:
>>
>> #f
>>
>> As a side note, the mechanization of Redex in [1] just returns something
>> equivalent to:
>>
>> (bind 'x '(hole (hole hole)))
>>
>> In both cases. Does anyone understand the behavior of the shown example
>> under racket 8.3?
>>
>> Thanks in advance!,
>> Mallku
>>
>> [1] : https://link.springer.com/chapter/10.1007%2F978-3-642-25318-8_27
>> El jueves, 9 de diciembre de 2021 a las 13:20:31 UTC-3, Mallku Ernesto
>> Soldevila Raffa escribió:
>>
>>> Thanks a lot for the info! If I found any mismatches, I'll report it.
>>>
>>> Regards,
>>> Mallku
>>>
>>> El miércoles, 8 de diciembre de 2021 a las 23:32:25 UTC-3, Robby Findler
>>> escribió:
>>>
>>>> I'm sorry, my sentence was ambiguous! I'm saying that I don't know of
>>>> any other work that is specifically focused on the semantics of Redex. (Of
>>>> course, there may be work I'm not aware of.)
>>>>
>>>> The paper is still a good match, I believe, yes. You're right that the
>>>> syntactic checks for well-formed grammars have tightened since that era,
>>>> but if the program is valid, then I think it should match; the underlying
>>>> algorithms have not changed, only bug fixes have happened.
>>>>
>>>> Of course, if you find that this isn't the case, I'd be very interested
>>>> to hear more :)
>>>>
>>>> Robby
>>>>
>>>>
>>>>
>>>> On Wed, Dec 8, 2021 at 6:34 PM Mallku Ernesto Soldevila Raffa <
>>>> mallku...@gmail.com> wrote:
>>>>
>>>>> I beg your pardon!, I'm not understanding the answer, what is it that
>>>>> might be specific of Redex?
>>>>>
>>>>> I suspect that the answer is that there isn't some recent work on
>>>>> formal
&g

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

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

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

2021-12-18 Thread Robby Findler
+1! Thank you.

Robby

On Sat, Dec 18, 2021 at 1:43 PM Matthew Flatt  wrote:

> The "members" option sounds right to me. Thanks for tracking down a way
> to improve the situation!
>
> At Sat, 18 Dec 2021 19:35:23 +, Sage Gerard wrote:
> > Core team,
> >
> > Sam asked me to issue bans for a troublesome spammer. I've done so, even
> > just today. I understand I need quorum for larger decisions. This is why
> > I have not yet reconfigured the list to permanently stop the spammer.
> > After researching the problem further, I need your urgent attention.
> >
> > I found that the spam messages sometimes link to other Google group
> > posts affected by the spammer. A recent trail leads to a
> > comp.lang.python Google message in 2017. I suspect that email addresses
> > are scraped in unmoderated lists that freely hand out membership. After
> > checking the list settings, I found that this is one of those lists. I
> > hypothesize that our email addresses are being scraped and
> > cross-referenced for use in other unmoderated lists.
> >
> > It's one thing to flatly complain about a spammer on this list, and
> > another to willingly maintain a transmission vector. We need to stop
> > automatically handing out group membership with our current settings. We
> > can have  issue list memberships. I need you all to fill in the
> > blank with "moderators" or "members." I'll translate the settings
> > accordingly.
> >
> > Given the holidays, I respect your time. Please reciprocate with respect
> > for the urgency this problem creates. I will revoke my own mailing list
> > privileges and membership in three weeks, on January 8th, 2022. I will
> > leave the settings however they read at the time to prevent
> > interruption, and request that own messages then be deleted to limit the
> > role my email address plays for the spammer.
> >
> > I am not volunteering to moderate membership applications, and I am not
> > commenting on how to verify the impact of possible email leaks. Between
> > the Discourse move and (majority?) perspective towards email, I'm not
> > sure how I would be useful doing either. If my opinion holds weight, I'd
> > advise the answer be "members" so that any available moderators can
> > focus on rule breakers while the community grows at a self-directed
> speed.
> >
> > Let me know, and thank you.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/racket-users/5fa6a8bb-88e4-37c6-f0b9-2ed372bc
> > e8fe%40sagegerard.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20211218124300.343%40sirmail.smtps.cs.utah.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMCXH4Zio1%2B96Nj_Zgj2vByetG-%3D8i93%3DLYjTpaBrw8DA%40mail.gmail.com.


Re: [racket-users] Formal semantics of PLT Redex

2021-12-08 Thread Robby Findler
I'm sorry, my sentence was ambiguous! I'm saying that I don't know of any
other work that is specifically focused on the semantics of Redex. (Of
course, there may be work I'm not aware of.)

The paper is still a good match, I believe, yes. You're right that the
syntactic checks for well-formed grammars have tightened since that era,
but if the program is valid, then I think it should match; the underlying
algorithms have not changed, only bug fixes have happened.

Of course, if you find that this isn't the case, I'd be very interested to
hear more :)

Robby



On Wed, Dec 8, 2021 at 6:34 PM Mallku Ernesto Soldevila Raffa <
mallkuerne...@gmail.com> wrote:

> I beg your pardon!, I'm not understanding the answer, what is it that
> might be specific of Redex?
>
> I suspect that the answer is that there isn't some recent work on formal
> semantics specifically about Redex. In that case, does anybody know if the
> already mentioned paper [1] is still a good match for today's semantics of
> Redex? The paper provides a mechanization of the model in Redex, together
> with some tools to test it. Of interest is a tool that asks Redex to
> generate
> random patterns and terms that match against them, and tests if the
> mechanized model is capable of reproducing the matching (or that is what
> I suspect that the tests are doing :P ). It was possible to run the
> mechanization
> on a recent version of Redex, but the generated patterns are ill-formed
> (e.g., in-hole p1 p2, where p1 contains more than 1 hole). Of course I
> could
> provide more details about the error, but I don't know if it is of
> interest, it's
> a mechanization written for the Redex version that comes with Racket 5.*
> or something like that.
>
> Thanks!,
> Mallku
>
>
> [1] : https://link.springer.com/chapter/10.1007%2F978-3-642-25318-8_27
>
> El miércoles, 8 de diciembre de 2021 a las 21:03:44 UTC-3, Robby Findler
> escribió:
>
>> I think that might be it specifically about redex, I am sorry to say.
>>
>> Robby
>>
>> On Wed, Dec 8, 2021 at 5:28 PM Mallku Ernesto Soldevila Raffa <
>> mallku...@gmail.com> wrote:
>>
>>> Hi community!,
>>> I'm interested in understanding the semantics of PLT Redex, since we are
>>> working on a tool
>>> to translate fragments of Redex models to Coq. At the moment, we just
>>> have a
>>> mechanization in Coq of the semantics proposed in a ~10 years old paper
>>> [1]. Does
>>> anybody know if there is an updated work on formal semantics of Redex?
>>>
>>> Thanks in advance!,
>>> Mallku
>>>
>>> [1] : https://link.springer.com/chapter/10.1007%2F978-3-642-25318-8_27
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/d794dd4d-34c7-4de8-a4cd-a437dfcc630cn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/d794dd4d-34c7-4de8-a4cd-a437dfcc630cn%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/eba71355-dd8b-4eaa-8f0a-934a50d05ccen%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/eba71355-dd8b-4eaa-8f0a-934a50d05ccen%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/CAL3TdOOxK%3Dwo6B0a2PDzVc86G4%3Dc9b%3DxHc7AqYuBD_4KOc1_Aw%40mail.gmail.com.


Re: [racket-users] Formal semantics of PLT Redex

2021-12-08 Thread Robby Findler
I think that might be it specifically about redex, I am sorry to say.

Robby

On Wed, Dec 8, 2021 at 5:28 PM Mallku Ernesto Soldevila Raffa <
mallkuerne...@gmail.com> wrote:

> Hi community!,
> I'm interested in understanding the semantics of PLT Redex, since we are
> working on a tool
> to translate fragments of Redex models to Coq. At the moment, we just have
> a
> mechanization in Coq of the semantics proposed in a ~10 years old paper
> [1]. Does
> anybody know if there is an updated work on formal semantics of Redex?
>
> Thanks in advance!,
> Mallku
>
> [1] : https://link.springer.com/chapter/10.1007%2F978-3-642-25318-8_27
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/d794dd4d-34c7-4de8-a4cd-a437dfcc630cn%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/CAL3TdOMcaBdpksLf2u4o-sw1EW2%3DpYTMgnNaCdaHR_K5uev4cA%40mail.gmail.com.


Re: [racket-users] Typesetting Redex definitions

2021-10-26 Thread Robby Findler
The only way to do that currently is to use the compound rewriters (they
rewrite anything with parens) and the atomic rewriters (they rewrite
anything without parens). The interface that redex provides is pretty
low-level and I'd like to find time to improve it, but in the meantime
there are some libraries on the package server that build higher-level ways
to do this.

There's an example of with-compound-rewriter here:
https://docs.racket-lang.org/redex/reference.html#%28form._%28%28lib._redex%2Fpict..rkt%29._with-compound-rewriter%29%29
and redex doesn't care if the thing it is rewriting is defined as a
judgment form or as the syntax of a term; it'll apply the rewriter in
either case.

As for what Redex generates, it isn't generating latex, it is generating
picts (which basically boils down to postscript-style drawing commands when
you think about them from the perspective of interoperating with other
tools -- one nice thing to do is to use scribble (which generates latex) as
it has handling to make them look nice in the rendered output, although
getting the right fonts set up can sometimes be tricky).

hth,
Robby


On Tue, Oct 26, 2021 at 1:55 PM Mallku Ernesto Soldevila Raffa <
mallkuerne...@gmail.com> wrote:

> Hi community!,
> a colleague of mine is trying to typeset a grammar from a model in Redex,
> using redex/pict. So far, he has obtained a nice-looking typesetting of
> the productions, but with the inconvenience that they are not abstract. In
> particular, there are parentheses around every list of symbols,
> as in Redex. Since it seems that redex/pict does not generate the latex
> code
> (or does it?), we are not able to get rid of those concrete-syntax
> details. Is
> there any known/simple way of doing it?
>
> Thanks in advance!,
> Mallku
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/3c6330fe-a048-4561-98bf-495c9b92e06an%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/CAL3TdOOUxqO8c1DrdBkuCXwU7U5W35ZjMBr3PFzpxfpdfbY4Xw%40mail.gmail.com.


Re: [racket-users] How to require untrusted module?

2021-10-22 Thread Robby Findler
On Fri, Oct 22, 2021 at 12:43 PM Matthew Flatt  wrote:

> At Thu, 21 Oct 2021 07:37:12 -0700 (PDT), "kalime...@gmail.com" wrote:
> > I've read about protect-out and  current-code-inspector, but I still
> cannot
> > understand, how to require a module and forbid it to run protected
> modules.
> >
> > Something like (require untrusted-foo) (foo-proc) but to forbid foo-proc
> to
> > use ffi/unsafe.
>
> If you use
>
>  (current-code-inspector (make-inspector))
>  (require untrusted-foo)
>
>
Just in case: I think Matthew as thinking of two subsequent REPL
interactions (or calls to eval or suchlike). If you put those two together
into a file in #lang racket, say, you won't be protected against
untrusted-foo.

Robby


> and assuming that `untrusted-foo` hasn't been loaded earlier, then
> `untrusted-foo` will not be able to use protected binding.
>
> That sequence will also disable the use of protected bindings by
> anything that `untrusted-foo` depends on and that hasn't already been
> loaded. So, if you want those dependencies to be able to use untrusted
> things, you need to load the before `(current-code-inspector
> (make-inspector))`.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20211022114302.3e4%40sirmail.smtps.cs.utah.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOU-X5K1iy2%3DCw64eSgHi2kbCkBr%3Dz%2BuQxhnrwNCwdHOw%40mail.gmail.com.


Re: [racket-users] Having trouble getting documentation to generate

2021-09-28 Thread Robby Findler
I'm not quite following from the thread, but it sure sounds like there is a
bug in raco setup (or similar) somewhere that isn't reporting an error
properly. Is that the case?

Robby


On Tue, Sep 28, 2021 at 4:12 PM David Storrs  wrote:

>
>
> On Tue, Sep 28, 2021 at 3:30 PM Ben Greenman 
> wrote:
>
>> On 9/28/21, David Storrs  wrote:
>>
>> > Also, any ideas on why the remove fails?
>> >
>> > $ raco pkg remove try-catch
>> > raco pkg remove: invalid `deps' specification
>> >   specification: '("base" racket/format racket/string)
>> >
>> > That is not the deps specification from the info.rkt file so I don't
>> know
>> > where it's getting that.
>>
>> Some package somewhere must have that bad info.rkt file.
>>
>> A plain "raco setup" might be the quickest way to find the bad one.
>> That should print the name of every package as it goes through them.
>
>
> It did show them right up to the point where it bonked but did not show
> the name of the one it bonked on.  Fortunately, since you told me what the
> issue was I was able to find it with a simple:
>
> $ find . -name official-racket -prune -o -name info.rkt -exec grep -l
> 'racket/format' \{} \;
>
> Thanks!
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/CAFUu9R5%3DCL-_wfB52aG82Vg9y%2B9HKpQhxk_dX08ub5Ln948QGQ%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/CAE8gKoevcaM26JaaBYVZCORxsXJXVUO9zZNJYR2UPcH_94Rb8Q%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/CAL3TdOP9gkGbi%3DnN7s1SeTTDebpFU1wxt1a%2BYaR6L_1xPwPzMQ%40mail.gmail.com.


Re: [racket-users] What is the correct name for non-list parenthesized forms?

2021-09-24 Thread Robby Findler
Another approach is to give it a name in the documentation and use that
name (following Jay's earlier message).

Robby


On Fri, Sep 24, 2021 at 1:37 PM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> I think I wouldn’t say “accepts”; I usually reserve this term for
> functions, but that’s a minor quibble.
>
> I think I would call these “clauses”, as in
>
> “With-handlers allows the user to specify exception-handling clauses. Each
> one includes two parts: a predicate, indicating whether blah blah blah, and
> a handler, which is called blah blah blah.”
>
> No?
>
> John
>
> > On Sep 24, 2021, at 11:28, David Storrs  wrote:
> >
> >
> >
> > On Fri, Sep 24, 2021 at 1:49 PM Jay McCarthy 
> wrote:
> > I think the word you're looking for is "syntax". Many people think that
> languages like Racket "don't have syntax" or "have uniform syntax", but
> this is an example of how that is incorrect. Each macro has its own unique
> syntax and this is an example of how `let` has a unique syntax where `(`
> does _not_ mean "apply a function" or "apply a macro".
> >
> > As a poor analogy, many human languages have a wide set of phonemes and
> you combine those in certain rules (like you can't have 27 consonant sounds
> in a row) and then use them in wider situations that we call grammar. I
> like to think that languages like C has lots of phonemes and little
> grammar, because there are lots of rules about how to form "C words" but
> basically no rules for how to form "C sentences", because there's a lot of
> uniformity in how expressions and statements combine. In contrast,
> languages like Racket have very few phonemes (this is what I think people
> mean why they say "there is no syntax") but many varied rules (in fact,
> arbitrary, because macros can customize them) for combining those smaller
> units.
> >
> > So there's no specific term for this structure?  I was looking for a
> standardized way to say something like "with-handlers accepts a group of
> two-element groups where each subgroup consists of a predicate and an
> action."
> >
> > Jay
> >
> > --
> > Jay McCarthy
> > Associate Professor @ CS @ UMass Lowell
> > http://jeapostrophe.github.io
> > Vincit qui se vincit.
> >
> >
> > On Fri, Sep 24, 2021 at 1:25 PM David Storrs 
> wrote:
> > Racket has a number of forms that include what look like lists of lists
> but are not.  For example:  (let ((foo 7) (bar 8)) ...)
> >
> > What would the '(foo 7)' and '(bar 8)' elements be called?  Groups,
> maybe?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAE8gKodX800fK45c_dyVFCNB-AKmYmK26DxC42ZRDVHdzJ2Q7g%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/CAE8gKoeM6YYgpj-4Ey%2BoSSKRS%2BfMch3d0GDu85f9mwHmtxwVig%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/11a531ce-22f2-4f23-8246-46c6c77ffae7%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/CAL3TdOOx5LWptTUbHzxFp5BbcS73ikkq%2B4FMm25YmGdVY3N1VA%40mail.gmail.com.


Re: [racket-users] What is the correct name for non-list parenthesized forms?

2021-09-24 Thread Robby Findler
An answer to a third question that might also have been the one that was
asked :)

You might call it a "sequence".

Robby


On Fri, Sep 24, 2021 at 12:50 PM Jay McCarthy 
wrote:

> I think the word you're looking for is "syntax". Many people think that
> languages like Racket "don't have syntax" or "have uniform syntax", but
> this is an example of how that is incorrect. Each macro has its own unique
> syntax and this is an example of how `let` has a unique syntax where `(`
> does _not_ mean "apply a function" or "apply a macro".
>
> As a poor analogy, many human languages have a wide set of phonemes and
> you combine those in certain rules (like you can't have 27 consonant sounds
> in a row) and then use them in wider situations that we call grammar. I
> like to think that languages like C has lots of phonemes and little
> grammar, because there are lots of rules about how to form "C words" but
> basically no rules for how to form "C sentences", because there's a lot of
> uniformity in how expressions and statements combine. In contrast,
> languages like Racket have very few phonemes (this is what I think people
> mean why they say "there is no syntax") but many varied rules (in fact,
> arbitrary, because macros can customize them) for combining those smaller
> units.
>
> Jay
>
> --
> Jay McCarthy
> Associate Professor @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> Vincit qui se vincit.
>
>
> On Fri, Sep 24, 2021 at 1:25 PM David Storrs 
> wrote:
>
>> Racket has a number of forms that include what look like lists of lists
>> but are not.  For example:  (let ((foo 7) (bar 8)) ...)
>>
>> What would the '(foo 7)' and '(bar 8)' elements be called?  Groups, maybe?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/CAE8gKodX800fK45c_dyVFCNB-AKmYmK26DxC42ZRDVHdzJ2Q7g%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/CAJYbDamFTUsORe%3D07H9FROrA0bcYFbFv0PqFdapey0JqsQ-bPQ%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/CAL3TdONf2uFBvn7gK62Sm2S8TQa%3DSM-Pefp-khWJ9st2PnFytA%40mail.gmail.com.


Re: [racket-users] Find the source location of the syntax error in DrRacket

2021-08-14 Thread Robby Findler
I'm not 100% sure but I think that's right: the marks clobber each other so
that you see the inner frame and a `let`'s body is in tail position wrt to
the let itself. So in this program:

#lang racket/base

(define (f x) (car x))

(let ()
  (let ()
(+ (let ()
 (let ()
   (f #f))


You see the stack frames for the + and for the call to `car`, but not for
the `let`s or the call to `f`.

Robby



On Sat, Aug 14, 2021 at 10:00 AM Shu-Hung You 
wrote:

> Cool! I thought the existing syntax/loc have already put the correct
> source location on the output of the macro, but the inner let is
> taking over the stack frame.
>
> On Sat, Aug 14, 2021 at 12:49 AM Sorawee Porncharoenwase
>  wrote:
> >
> > Isn’t that a matter of putting more syntax/loc? I tried:
> >
> > (-define-syntax let-syntaxes
> > (lambda (stx)
> >   (syntax-case stx ()
> > [(_ ([(id ...) expr] ...) body1 body ...)
> >  (with-syntax ([((tmp ...) ...)
> > (map
> >  generate-temporaries
> >  (syntax->list (syntax ((id ...) ...])
> >(with-syntax ([inner-body
> >   (syntax/loc stx
> > (letrec-syntaxes+values
> > ([(id ...)
> >   (values
> >(make-rename-transformer (quote-syntax
> tmp))
> >...)] ...)
> > ()
> >   body1 body ...))])
> >  (syntax/loc stx
> >(letrec-syntaxes+values ([(tmp ...) expr] ...) ()
> >  inner-body])))
> >
> > and the button now functions as you expect.
> >
> >
> > On Fri, Aug 13, 2021 at 7:45 PM Shu-Hung You 
> wrote:
> >>
> >> Here are two syntax errors that behave differently in DrRacket:
> >>
> >> #lang racket
> >>
> >> (define-syntax (m-late stx)
> >>   #'(let () (define x 0)))
> >> (define-syntax (m-early stx)
> >>   #'(let-syntax () (define x 0)))
> >>
> >> ; (m-late)
> >> ; (m-early)
> >>
> >> DrRacket *correctly* highlights the source location of the errors in
> >> both cases. Additionally, for (m-early) I can click on the X button to
> >> jump to the error location.
> >>
> >> However, for (m-late) the X button brings me to internal Racket code.
> >> What's going on here?
> >>
> >> In case it helps, here are the error messages when I run the code in
> terminal:
> >>
> >> ;; m-late
> >> errstx.rkt:4:4: begin (possibly implicit): no expression after a
> >> sequence of internal definitions
> >>   in: (begin (define x 0))
> >>   location...:
> >>/Volumes/ramdisk/errstx.rkt:4:4
> >>/Volumes/ramdisk/errstx.rkt:4:12
> >>
> >> ;; m-early
> >> /racket/private/letstx-scheme.rkt:38:17: begin (possibly
> >> implicit): no expression after a sequence of internal definitions
> >>   in: (begin (define x 0))
> >>   location...:
> >>/racket/private/letstx-scheme.rkt:38:17
> >>/Volumes/ramdisk/errstx.rkt:6:19
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAMTzy%2BZtpWGdtkZkvzF4%3D25kpqUqGKsBcCDf4T%3DY3S2hV0v_GA%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/CAMTzy%2BY%3DgzoDviM5q8OhSsUcJnDUSxfnAVc7uZv2ZR97ckOnXA%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/CAL3TdOMEsqCXSL%3DiXpE5b%3DqTmyZ3x7pqncm3XNzE2svvqiNVbQ%40mail.gmail.com.


Re: [racket-users] Pousse Player Programs

2021-08-07 Thread Robby Findler
I see that in 8.2 but I'm not seeing it in a more recent build. Maybe try a
snapshot? https://snapshot.racket-lang.org/

There is information about how to make players here:
https://github.com/racket/games/blob/master/pousse/robots.txt I didn't try
it out, but if you do and run into problems, let us know.

hth,
Robby



On Sat, Aug 7, 2021 at 7:15 PM Jeff Sepeta 
wrote:

> Greetings! My father is a retired professor. He taught several courses
> including Scheme, C, C+, Bioinformatics, and AI. Recently he's shown me
> what I believe to be a bug within the Pousse program which we would like to
> bring to your attention.
>
> Pousse on the Mac in PLT Games.app has the option to select a program for
> Player X or Player 0. When selecting "Smart", the timer starts but the AI
> never actually makes a move. Is there a way to fix this? This behavior is
> the same whether Smart is selected for Player X or Player 0. On a dual Xeon
> Mac running OS X 10.14.6 & DrRacket 8.2 / Pousse 1.1.3 we ran the app for
> several minutes with no response from the Smart player program. We achieved
> identical results running DrRacket 7.x/PLT Games.app on a MacBook Pro.
>
> Are there additional Player Programs available? Where would one attain
> such a thing? Is there example code we could use to better understand how
> player programs work, in order to create our own player program?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/cf46f357-e97a-4c33-8843-ca2b23f0317cn%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/CAL3TdOMoLBeSQD%2B5YWL%2BxNT9ukEz1GHjnkOB_hnFvT2Y9J2suw%40mail.gmail.com.


Re: [racket-users] Question from a beginner. Why Racket Over Scheme?

2021-07-13 Thread Robby Findler
I would say that the stuff in HtDP is teaching you the fundamentals of
programming; it isn't (about) teaching you a specific programming language.
These fundamentals apply to any programming language you might wish to
program in. And, of course, the book does use a (set of) languages to teach
you, but that's more about having something so that you can practice than
it is about teaching you the specifics of BSL.

If your goal is to learn how to program, just in general, I think HtDP is
the book for you. If your goal is something else, then HtDP may not be for
you.

I should also add that I think that the learning the fundamentals of how to
program is a wonderful thing and I am very happy that I have learned them.
It is even better than my job overlaps with my favorite hobby (which
happens to be programming); I consider myself extremely lucky because of
that!

best,
Robby


On Tue, Jul 13, 2021 at 10:12 AM joseph turco 
wrote:

> I see. The stuff in HtDP, does it transfer over to any Racket syntax?
>
> On Tue, Jul 13, 2021 at 10:56 AM George Neuner 
> wrote:
>
>>
>> On 7/13/2021 10:13 AM, joseph turco wrote:
>>
>> Hello,
>>
>> Im am looking at learning a programming language, and have been
>> bouncing around with scheme/racket/dyalog APL/squeak. upon investigation of
>> scheme and racket, i found that in regards to racket, there really isn't a
>> "Beginners book" that teaches the language. The only beginner book i could
>> really see being close to teaching the language is HtDP, but that doesn't
>> *technically* teach racket, but BSL. For scheme, im able to find
>> beginner books, unless im not looking deep enough. Maybe if you fine folk
>> don't mind pointing me in the right direction? Please excuse my ignorance.
>>
>> -- Joseph T
>>
>>
>> Welcome.
>>
>> Racket[*] largely is based on Scheme, and so much of what you learn about
>> Scheme will transfer.  Racket supports R5RS and R6RS Scheme as legacy
>> languages, so you can learn about Scheme /using/ Racket and its tools.
>> Then when you are more comfortable, you can transition to using the Racket
>> module language instead.
>>
>> George
>> [*]  At least the untyped Racket language.  Racket really is a /suite/ of
>> languages: there also is a typed Racket, a lazy Racket, and various DSLs
>> (domain languages) which compile to and (mostly) freely intermix with
>> Racket.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CADhp54TpmGXSVDTjbcL%3DYqxiQDmytrMotcxJ7oKgTnniPQOwmg%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/CAL3TdONjgSWi3fpY9yAyvzpsFqW-cCzqQYCbhpUeMK_te_R49w%40mail.gmail.com.


Re: [racket-users] parenthesis colours

2021-07-05 Thread Robby Findler
I chose the paren default color to deemphasize the parentheses. I'm not
sure that emphasizing them would be a good change. I can see how, on some
monitors, the deemphasis might have been too much but I'm not quite ready
to change that design choice!

Robby


On Mon, Jul 5, 2021 at 11:07 AM Hendrik Boom  wrote:

> On Mon, Jul 05, 2021 at 07:52:39AM -0500, Robby Findler wrote:
> > Glad to hear it! Sorry the defaults looked bad.
>
> They look pretty enough.  They just aren't useful.
> I turned the parentheses bright yellow.
> Unless yellow comflicts with some other use of the same colour,
> may I recommend it ne made default?
>
> -- hendrik
>
> >
> > Robby
> >
> > On Mon, Jul 5, 2021 at 7:02 AM Hendrik Boom 
> wrote:
> >
> > > On Sun, Jul 04, 2021 at 08:18:24AM -0500, Robby Findler wrote:
> > > > If you go to the preference dialog, choose "Colors", and then choose
> > > > "Racket" you should be able to adjust each color independently.
> > > >
> > > > There are also some themes for DrRacket in dark mode that have
> different
> > > > color schemes; I think Tol's is installed by default and there are
> more
> > > on
> > > > the pkg server.
> > > (offlist)  Thank you.  Much. much better now.
> > >
> > > -- hendrik
> > > >
> > > > hth,
> > > > Robby
> > > >
> > > >
> > > > On Sun, Jul 4, 2021 at 7:26 AM Hendrik Boom 
> > > wrote:
> > > >
> > > > > I use drracket in what I call night mode -- dark backgroun and
> bright
> > > > > letters.
> > > > > It's easier on the eyes,
> > > > > except when I have to see parentheses.
> > > > > They are presented in a dark shade of red.
> > > > > Given how crucial parentheses are in Racket, this is an obstacle,
> > > > > especially when the error-reporting mechanism highlights a part of
> the
> > > > > code it thinks is in error -- using red highlighting, obscuring the
> > > > > possibly unbalanced parentheses completely.
> > > > >
> > > > > Is it possible to set parenthese to be some other colour, such as,
> say,
> > > > > a bright green or white?
> > > > >
> > > > > -- 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/20210704122648.hbztacmpzcjvc3hd%40topoi.pooq.com
> > > > > .
> > > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > Groups "Racket Users" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> send
> > > an email to racket-users+unsubscr...@googlegroups.com.
> > > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/racket-users/CAL3TdOP7m7MsbRw8MDjevLuB5z9TDDp_AZCL5suTQbNJb9dujQ%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/20210705160659.fbyng6drfono7cow%40topoi.pooq.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOOmZK0U8kDKeK0eaabD_D-2W2%3D1zUH9vSxwNHLrSgWmA%40mail.gmail.com.


Re: [racket-users] parenthesis colours

2021-07-04 Thread Robby Findler
If you go to the preference dialog, choose "Colors", and then choose
"Racket" you should be able to adjust each color independently.

There are also some themes for DrRacket in dark mode that have different
color schemes; I think Tol's is installed by default and there are more on
the pkg server.

hth,
Robby


On Sun, Jul 4, 2021 at 7:26 AM Hendrik Boom  wrote:

> I use drracket in what I call night mode -- dark backgroun and bright
> letters.
> It's easier on the eyes,
> except when I have to see parentheses.
> They are presented in a dark shade of red.
> Given how crucial parentheses are in Racket, this is an obstacle,
> especially when the error-reporting mechanism highlights a part of the
> code it thinks is in error -- using red highlighting, obscuring the
> possibly unbalanced parentheses completely.
>
> Is it possible to set parenthese to be some other colour, such as, say,
> a bright green or white?
>
> -- 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/20210704122648.hbztacmpzcjvc3hd%40topoi.pooq.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOP7m7MsbRw8MDjevLuB5z9TDDp_AZCL5suTQbNJb9dujQ%40mail.gmail.com.


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

2021-07-04 Thread Robby Findler
Ah, sorry about this. It should be up now.

Robby


On Fri, Jul 2, 2021 at 11:05 PM Shu-Hung You 
wrote:

> The PLaneT website (https://planet.racket-lang.org/) is currently
> unreachable. The error message is ERR_CONNECTION_REFUSED.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAMTzy%2Bb9GkCr_rpFnwUUTrB1PCoXsb%2BCBnEv1cbxNtqK2nKF9A%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/CAL3TdOMW7p%3D1b9GstEHFiAy%3DVvhO3Xfuav7YhwfSOXRicHf3gg%40mail.gmail.com.


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

2021-06-29 Thread Robby Findler
A little more information about these things.

I'd say that there are two obstacles to having the racket/contract library
actually be the source of the contract checks in all functions exported by
the racket language/library:

1) dependency layering. The racket/contract library is really a library. So
if that library needs something to actually implement the contract system
(eg string manipulation libraries, which are handy for constructing error
messages), then it can't have a contract that is implemented by the library

2) performance. The contract system has gobs of special cases to get quite
close in various situations but it still doesn't quite ever achieve the
performance of just writing a simple check at the start of the function
(unfortunately). It can be difficult to predict which cases those are (and
there are plenty of situations when the raw overhead of the contract
checking isn't what matters for the performance) but this is an area I'd
like to improve somehow.

One consequence is that some care has been taken, both in the contract
system and in functions like number->string, to make the error messages
look uniform. A giveaway, however, is the "blaming" line, which the
racket/contract contract checking always has and the simple number->string
function checks do not. Including that line forces us to give up on the
performance benefits of just doing the simple check (since that line
requires a precise accounting of who called whom and we have only an
approximate accounting of that from a stacktrace unless we add what has
been deemed (quite reasonably, IMO) unacceptable overhead).

hth,Robby


On Tue, Jun 29, 2021 at 11:11 AM Sam Tobin-Hochstadt 
wrote:

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

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

2021-06-28 Thread Robby Findler
I think you found a slowdown that's just a severe as the one we've been
talking about and, once that one'd been cleared up, you might have seen the
other one, perhaps in the calls to string-append. But you are right that
some costs (like gc) are smeared out across the whole computation and thus
hard to identify with profiling (hence Bogdan's helpful hint about gc
logging).

Robby


On Mon, Jun 28, 2021 at 2:18 PM Alessandro Motta  wrote:

> On 27.06.21 19:34, Robby Findler wrote:
> > On Sun, Jun 27, 2021 at 11:58 AM Alessandro Motta  > <mailto:amott...@gmail.com>> wrote:
> >
> > I also like Jens' code for its pure functional elegance. I'm
> surprised
> > that building up a long list of short strings before joining them is
> so
> > much faster. After all, isn't the final `string-join` essentially
> doing
> > what the original code snipped did? (Clearly not! I will have a look
> at
> > the implementation.)
> >
> > This is a classic O(n^2) gotcha. Cons is constant work (in terms of the
> > size of its inputs) and string-append is linear in the size of all of
> > its arguments. So if you repeatedly string-append in a loop, you'll get
> > the 1+2+3+4+5+6+7+8++n which is O(n^2), but if you collect all the
> > arguments in a list and then call string-append once at the end, it will
> > be linear (which implies than string-append isn't naive when it gets a
> > lot of arguments; it looks at them twice. Once to know how much to
> > allocate before a second pass to filling in the string).
>
> Thank you for these explanations, Robby and Jens! The parenthetical
> remarks about the two-pass approach of `string-append` were particularly
> helpful. That makes sense now.
>
> One thing that is still puzzling / worrying me: I completely failed to
> identify the actual bottleneck when profiling the code.
>
> Did I simply misinterpret the profiling output / flame graph? Or is the
> problem rather that memory allocations and garbage collection are not
> tracked by the profiler?
>
> Thinking about it: Does garbage collection also pause the profiler's
> sampler thread? That would explain the lack of samples from these code
> paths, of course.
>
>
> All the best,
> Alessandro
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMpMpfY4CW8y%2BUZHJFm3Wyv0yYdDhFSvXEfSg6zaDFKNA%40mail.gmail.com.


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

2021-06-27 Thread Robby Findler
On Sun, Jun 27, 2021 at 11:58 AM Alessandro Motta 
wrote:

>
> I also like Jens' code for its pure functional elegance. I'm surprised
> that building up a long list of short strings before joining them is so
> much faster. After all, isn't the final `string-join` essentially doing
> what the original code snipped did? (Clearly not! I will have a look at
> the implementation.)
>
>
This is a classic O(n^2) gotcha. Cons is constant work (in terms of the
size of its inputs) and string-append is linear in the size of all of its
arguments. So if you repeatedly string-append in a loop, you'll get the
1+2+3+4+5+6+7+8++n which is O(n^2), but if you collect all the
arguments in a list and then call string-append once at the end, it will be
linear (which implies than string-append isn't naive when it gets a lot of
arguments; it looks at them twice. Once to know how much to allocate before
a second pass to filling in the string).

hth,
Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOkJjkH7Qoayjm%2BVhZ6aK9_vnDOZ_1cvFJ_RSxZJRTDNA%40mail.gmail.com.


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

2021-06-27 Thread Robby Findler
Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for
`y` eliminates the overhead of contracts and brings about another 4x
speedup on my machine.

That may not work, tho, depending on Alessandro's original usecase, since
the strings are different.

I was also going to, as Bogdan does, recommend ports. In other languages,
strings are a sophisticated data structure, but in Racket they are just
linear arrays. The ports abstraction is the best place to situate streaming
stuff (especially if you're going to write the result to a file in the
end). String and byte ports are great for unit testing too -- you can just
drop in a file port in the same place for the real code, minimizing the
amount of code you need that's only for testing.
Robby


On Sun, Jun 27, 2021 at 9:10 AM Bogdan Popa  wrote:

> Hi Alessandro,
>
> Here is a version of your program that is about 30 times faster on my
> machine (9s -> 300ms):
>
> #lang racket/base
>
> (require racket/flonum
>  racket/format
>  racket/port)
>
> (define (xy-vectors->string x-vec y-vec)
>   (call-with-output-string
>(lambda (out)
>  (for ([i (in-naturals)]
>[x (in-flvector x-vec)]
>[y (in-flvector y-vec)])
>(unless (zero? i)
>  (write-char #\space out))
>(write-string (~r x #:precision 1) out)
>(write-char #\, out)
>(write-string (~r y #:precision 1) out)
>
> (time
>  (let ([x (make-flvector 10)]
>[y (make-flvector 10)])
>(xy-vectors->string x y)))
>
> All the calls to `string-append` in your original program end up
> allocating larger and larger strings and then immediately discarding
> them on subsequent iterations, which is costly over many iterations.
>
> Hope that helps,
> Bogdan
>
> Alessandro Motta writes:
>
> > Hi racket-users!
> >
> > I've recently become interested in Lisp/Scheme and have started to hack
> > in Racket. The excellent documentation, the fast integrated search, and
> > DrRacket have made that a real pleasure.
> >
> > Thank you for that!
> >
> > I've been working on a tool to convert notes from the reMarkable 2
> > tablet to SVG files. At the core is the conversion of (x, y) coordinate
> > pairs from two `flvector`s to a string of the form "x1,y1 x2,y2 x3,y3".
> >
> > ```
> > (define (xy->string x y)
> >   (string-append
> >(~r x #:precision 1) ","
> >(~r y #:precision 1)))
> >
> > (define (xy-vectors->string x-vec y-vec)
> >   (for/fold ((coordinates "")
> >  (separator "")
> >  #:result coordinates)
> > ((x (in-flvector x-vec))
> >  (y (in-flvector y-vec)))
> > (values (string-append
> >  coordinates
> >  separator
> >  (xy->string x y))
> > " ")))
> > ```
> >
> > This is currently the bottleneck for large conversion jobs.
> >
> > Profiling these functions with `profile-flame-graph` resulted in
> >
> https://gist.githubusercontent.com/amotta/cfe4b19e24455af219521c9e94455c67/raw/dbbc87bd2f6dd4e27c33831749baa90fffdaed55/flvector-to-coordinates-string-flamegraph.svg
> >
> > The full profiling script is available at
> > https://gist.github.com/amotta/e76197082bb1bf63538ede01872917f3
> >
> > Roughly 90% of time is spent in `contract/private/arrow-val-first.rkt`.
> > Based on my very limited understanding of Racket, it seems that ~38% of
> > time is spent handling keyword arguments (presumably `#:precision 1`?).
> > The `catnp` function (the conversion from flonum to string, I think)
> > takes up only ~11% of time.
> >
> > Is this interpretation of the flame graph correct? If so, are there any
> > obvious blunders on my part? Any ideas for how to speed up this code?
> >
> >
> > Best wishes,
> > Alessandro
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/m2v95zcs9v.fsf%40defn.io.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOM7YZ8P3E7WUH6fg4FF%2BgsXupbCYy8apNtbF97itFg1fw%40mail.gmail.com.


Re: [racket-users] Plot Problem: No Line; Bounds not found

2021-06-15 Thread Robby Findler
While I completely agree that testing one's function is the best practical
advice here, it also seems worth an improvement to plot. Perhaps, in
addition to saying "could not determine sensible plot bounds", it could
also say something like "because there were no points" and perhaps even
follow up with "tried these points, but they all raised exceptions: ".

Robby


On Tue, Jun 15, 2021 at 2:19 PM Ben Greenman 
wrote:

> On 6/15/21, Britt Anderson  wrote:
> > Thanks for the help to my specific problem. More generally, what should
> > have clued me in to a contract or type error when the only message
> received
> > had to do with y plot bounds? Just looking for practical advice to help
> me
> > figure out things on my own going forward.
>
> There's nothing in this program that could have clued you in besides
> the empty plot.
>
> Next time, I'd write tests for my function before sending it to plot's
> `function` renderer.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAFUu9R5FF6%3D4c0-KnkycMBeL0AaU9PHnKRELOH33J8b9NSXqzQ%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/CAL3TdOMvGZhpY6aFR%2BMGAgvQ-pDYCMUzBHDFZp2%3DyiGKB3ZX6Q%40mail.gmail.com.


Re: [racket-users] macros in Racket repository

2021-05-09 Thread Robby Findler
Here's one way to write it in modern Racket:

#lang racket
(require (for-syntax syntax/parse))

(module+ test (require rackunit))

(define-syntax (my-and stx)
  (syntax-parse stx
[(_) #'#f]
[(_ e:expr) #'e]
[(_ e1:expr e2:expr ...)
 #'(if e1 (my-and e2 ...) #f)]))

(module+ test
  (check-equal? (my-and) #f)
  (check-equal? (my-and 1) 1)
  (check-equal? (my-and 1 2) 2)
  (check-equal? (my-and 1 #f 2) #f))



On Sun, May 9, 2021 at 9:30 AM Jens Axel Søgaard 
wrote:

> Hi Tim,
>
> In this case Ryan's method leads to:
>
>
> https://github.com/racket/racket/blob/master/racket/collects/racket/private/qq-and-or.rkt#L440
>
> But in case you are wondering about the style used in that file:
> at the point where "qq-and-or.rkt" is used, none of the usual
> syntax tools (such as syntax-case and syntax-parse) are available,
> so it is written using only primitive constructs.
>
> That is, that particular file does not represent the usual style of macro
> writing.
>
> /Jens Axel
>
>
> Den søn. 9. maj 2021 kl. 16.13 skrev Ryan Culpepper <
> rmculpepp...@gmail.com>:
>
>> Here are the three most convenient ways I know of to find that
>> information (which is "$RACKET/collects/racket/private/qq-and-or.rkt" in
>> this specific case):
>>
>> If you use DrRacket, then open a file that uses `and`, right-click on an
>> occurrence of `and`, and choose "Open Defining File" (which changes to
>> "Jump to Definition (in Other File)" once DrRacket opens the file.
>>
>> If you use Emacs with racket-mode, go to an occurrence of `and` and hit
>> "M-." (that is, hold down Meta/Alt and press the period key). You can also
>> use "M-x racket-visit-definition". That opens the defining module and jumps
>> to the definition.
>>
>> If you have the `whereis` package installed, run the command `raco
>> whereis -b racket/base and` and it will print the path of the defining file.
>>
>> Ryan
>>
>>
>> On Sun, May 9, 2021 at 3:26 PM Tim Meehan  wrote:
>>
>>> Where in the repository are macros like "and" and "or" defined?
>>> I tried searching for "and" and "or" ... but you probably know how that
>>> worked out.
>>>
>>> Thanks folks!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/CACgrOxK6S8EOAGk_rPbE%2B_wMLJiSbpwMhVd4AeRL8C9%2BDW3mgg%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/CANy33q%3DsLEH-ooUJxTay6pG1GNcRLZDUotNJ23L1HRTC1XqHwA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> --
> Jens Axel Søgaard
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CABefVgzgqRPzx6ct6LrN-TAfE18vsdqnopun0B63LmqqKxerAQ%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/CAL3TdOOSKK_ae-JiObMc%2B7SJDYWZg%3Depw43HiD9oa%2B2kLTro7g%40mail.gmail.com.


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

2021-05-05 Thread Robby Findler
I think the issue is that you should not use "tests/private" as your
collection path. You should probably either "tests/my-collection/private"
or "my-collection/tests/private" as the name.

Robby


On Wed, May 5, 2021 at 4:38 PM Siddhartha Kasivajhula 
wrote:

> That makes sense. Is there a recommended way to exclude test paths from
> being part of the package modules? I have a `compile-omit-paths`
> declaration in the info.rkt
> 
> file. Since this is structured as a multi-collection package, could it be
> that these declarations need to be at the package-level info.rkt file
> instead of the collection-specific one to take effect on the package index?
> Another option I can think of is to move the `tests` folder which is
> currently at the package level down to the collection level, might that
> work?
>
> FTR re: the lazytree package, I assume it's showing conflicts because
> although it hasn't been changed recently, it depends on the relation
> package which depends on both on-macro and social-contract, which are in
> conflict per the above.
>
> Re: mischief, I've encountered some weird errors in the past with building
> docs, for instance see this comment
> .
> I wonder if that's related to the conflicting names.
>
>
> On Wed, May 5, 2021 at 1:38 PM Sam Tobin-Hochstadt 
> wrote:
>
>> I think there's two things you're seeing.
>>
>> 1. The results hadn't yet updated for your typed-compose change. I no
>> longer see a conflict here: https://pkg-build.racket-lang.org/
>> 2. The conflicts page is for _all_ the packages in the whole package
>> catalog. That's why it always mentions mischief.
>>
>> The issue for on-macro and social-contract is that they both have a
>> file tests/private/util.rkt, which means they can't be installed at
>> the same time.
>>
>> Finally, mischief has that issue intentionally -- there are two
>> versions of it on the pkg server, one of which is the development
>> branch. It's true that it hasn't been updated recently, but that's the
>> idea.
>>
>> Sam
>>
>>
>> On Wed, May 5, 2021 at 4:08 PM unlimitedscolobb
>>  wrote:
>> >
>> > Hi,
>> >
>> > I'd like to chime back in and say that renaming manual.rkt to
>> typed-compose.rkt didn't seem to affect much the list of install conflicts
>> for typed-compose.  I also get a lot of conflicts with mischief (but not
>> only), even though typed-compose doesn't depend on it, or doesn't even
>> define names which would be similar to what mischief defines.
>> >
>> > That's puzzling.
>> >
>> > -
>> > Sergiu
>> >
>> > On Wednesday, May 5, 2021 at 9:16:14 PM UTC+2 Siddhartha Kasivajhula
>> wrote:
>> >>
>> >> Hi,
>> >> I'd like to report that I'm seeing conflicts being reported on my
>> packages as well. I haven't made recent changes to these packages so the
>> conflicts seem to have appeared spontaneously.
>> >>
>> >> Here is one example: https://pkgs.racket-lang.org/package/lazytree
>> >> Clicking into the "conflicts" results in a 404.
>> >>
>> >> Another example: https://pkgs.racket-lang.org/package/on-macro
>> >> Here, clicking into "conflicts" seems to implicate, believe it or not,
>> the `mischief` package, of which it appears there are two separate versions
>> on the package index. This does seem rather mischievous, and maybe raco
>> doesn't like it? Yet, it doesn't look like either mischief or mischief-dev
>> have been changed in years, so I'm not sure why it should complain now
>> about these longstanding shenanigans.
>> >>
>> >> A third example: https://pkgs.racket-lang.org/package/social-contract
>> >> Clicking into "conflicts" once again seems to implicate mischief, but
>> mischief isn't even in the dependencies for this package so this just seems
>> unfair!
>> >>
>> >> On other packages that I've uploaded, the conflicts link was a 404.
>> >>
>> >> Similar questions as OP - should I fix something here, for instance by
>> avoiding the mischief dependency? Should mischief itself be updated in some
>> way? Or is this (as seems likely) caused by a recent change in the package
>> index, and if so, how should package authors respond (assuming it isn't a
>> bug)? What to do about the 404s -- e.g. is there a command to generate the
>> conflicts locally?
>> >>
>> >> Thanks,
>> >>
>> >>
>> >>
>> >> On Sun, May 2, 2021 at 6:59 AM unlimitedscolobb 
>> wrote:
>> >>>
>> >>> Hi Jay,
>> >>>
>> >>> Thanks a lot for helping me read that file!
>> >>>
>> >>> I didn't know Scribble outputs shared the same namespace.  I renamed
>> the documentation file to typed-compose.scrbl as you suggest and I'm
>> waiting for build reports from the package catalog.
>> >>>
>> >>> In fact, I hesitated between manual.scrbl and typed-compose.scrbl
>> initially, and couldn't find a reason to prefer one over the other. Now I
>> have a reason :-)
>> >>>
>> >>> 

Re: [racket-users] Re: scribble: referencing two identifiers with the same name?

2021-05-03 Thread Robby Findler
Oh! Thanks!

Perhaps DrRacket's button should include the +m flag.

Robby


On Mon, May 3, 2021 at 10:37 AM Sam Caldwell  wrote:

> Ah, I meant what happens when I open up my scribble file in DrRacket and
> press the "Scribble HTML" button. Maybe it would be more accurate to
> describe that as a plugin than DrRacket itself?
>
> -Sam Caldwell
>
> On Mon, May 3, 2021 at 11:24 AM Robby Findler 
> wrote:
>
>> On Mon, May 3, 2021 at 10:19 AM Sam Caldwell  wrote:
>>
>>> When I first ran Ryan's example, the reference to `racket:let` did not
>>> resolve to the proper link. After further investigating, this appears to be
>>> due to scribble's default behavior of not loading extra cross-referencing
>>> information [1]. If instead of `raco scribble`, I run `raco scribble +m`
>>> the link does resolve to the proper location. It also appears that DrRacket
>>> uses the +m option by default.
>>>
>>>
>> Just a minor point of clarification: DrRacket uses the documentation
>> built by `raco setup`; it doesn't build the docs itself. This is the same
>> build of the docs you see with `raco docs`.
>>
>> Robby
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CALuKBHvJFmaJB9nf9%2BSDRAR6HUNa2pXeC0eaRfJ7VQ1quiC4_w%40mail.gmail.com
> <https://groups.google.com/d/msgid/racket-users/CALuKBHvJFmaJB9nf9%2BSDRAR6HUNa2pXeC0eaRfJ7VQ1quiC4_w%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/CAL3TdONURvPexFUbFeRPeNap8Y%2B4cRjRS-XBMWPK-hOPQFqVGQ%40mail.gmail.com.


Re: [racket-users] Re: scribble: referencing two identifiers with the same name?

2021-05-03 Thread Robby Findler
On Mon, May 3, 2021 at 10:19 AM Sam Caldwell  wrote:

> When I first ran Ryan's example, the reference to `racket:let` did not
> resolve to the proper link. After further investigating, this appears to be
> due to scribble's default behavior of not loading extra cross-referencing
> information [1]. If instead of `raco scribble`, I run `raco scribble +m`
> the link does resolve to the proper location. It also appears that DrRacket
> uses the +m option by default.
>
>
Just a minor point of clarification: DrRacket uses the documentation built
by `raco setup`; it doesn't build the docs itself. This is the same build
of the docs you see with `raco docs`.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMVtxi6wjwRpPAPOB70pqAY36UjB2Cry0H0PpqoRcbE5Q%40mail.gmail.com.


Re: [racket-users] Something is going slightly wrong visually with the Linux version

2021-04-13 Thread Robby Findler
Right -- looks like I was barking up the wrong herring.

Robby


On Tue, Apr 13, 2021 at 2:00 PM Bruce O'Neel 
wrote:

> Hi,
>
> I think that the label foreground and background colours are ok.
>
> #lang racket
> (require racket/gui/base)
> (define bg (get-label-background-color))
> (define fg (get-label-foreground-color))
>
>
> Produces
>
> > (send bg red)
> 255
> > (send bg green)
> 255
> > (send bg blue)
> 255
> > (send fg red)
> 0
> > (send fg green)
> 0
> > (send fg blue)
> 0
> >
>
> which is bg white, fg black, right?
>
> cheers
>
> bruce
>
>
>
>
> *13 April 2021 20:43 Robby Findler  > wrote:*
>
> And I should have added that that function's result is based on a
> luminance computation of this function:
>
>
> https://docs.racket-lang.org/gui/Windowing_Functions.html?q=get-label-background#%28def._%28%28lib._mred%2Fmain..rkt%29._get-label-background-color%29%29
>
> and the foreground one. So if there is some way you're controlling those
> that defeats that computation, that might explain why you're getting the
> bad colors.
>
> Robby
>
>
> On Tue, Apr 13, 2021 at 1:41 PM Robby Findler 
> wrote:
>
>> This looks to me like racket believes the OS is in dark mode but it
>> really isn't. Does this program produce true or false?
>>
>> #lang racket
>> (require mrlib/panel-wob)
>> (white-on-black-panel-scheme?)
>>
>> Robby
>>
>>
>> On Tue, Apr 13, 2021 at 1:38 PM Bruce O'Neel 
>> wrote:
>>
>>> Hi,
>>>
>>> The most recent snapshot version built on Linux x86-64, Arm32, and Arm64
>>> all have funny black blocks in the UI of Dr Racket.
>>>
>>> While this display was captured from a MacOS X11 server it is the same
>>> on the Linux X11 servers as well as directly on the console screen.
>>>
>>> Thanks.
>>>
>>> bruce
>>>
>>> 
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/1618339098-36f9ab5b7d7507d1da5b3d5d4e45a7b0%40pckswarms.ch
>>> <https://groups.google.com/d/msgid/racket-users/1618339098-36f9ab5b7d7507d1da5b3d5d4e45a7b0%40pckswarms.ch?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/CAL3TdOMcr7TMhMr4ZkSQTuEJhf%2B7DHZOG1bcPsaxzuqGgO1%2BWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/racket-users/CAL3TdOMcr7TMhMr4ZkSQTuEJhf%2B7DHZOG1bcPsaxzuqGgO1%2BWg%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/1618340401-c8cecdb594e934e3b5454c7f010926db%40pckswarms.ch
> <https://groups.google.com/d/msgid/racket-users/1618340401-c8cecdb594e934e3b5454c7f010926db%40pckswarms.ch?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/CAL3TdOMq9nZ0N%2BKCxnkdF9WvLLQzoGsTVywRUk9cfBPofLLQQA%40mail.gmail.com.


Re: [racket-users] Something is going slightly wrong visually with the Linux version

2021-04-13 Thread Robby Findler
And I should have added that that function's result is based on a luminance
computation of this function:

https://docs.racket-lang.org/gui/Windowing_Functions.html?q=get-label-background#%28def._%28%28lib._mred%2Fmain..rkt%29._get-label-background-color%29%29

and the foreground one. So if there is some way you're controlling those
that defeats that computation, that might explain why you're getting the
bad colors.

Robby


On Tue, Apr 13, 2021 at 1:41 PM Robby Findler 
wrote:

> This looks to me like racket believes the OS is in dark mode but it really
> isn't. Does this program produce true or false?
>
> #lang racket
> (require mrlib/panel-wob)
> (white-on-black-panel-scheme?)
>
> Robby
>
>
> On Tue, Apr 13, 2021 at 1:38 PM Bruce O'Neel 
> wrote:
>
>> Hi,
>>
>> The most recent snapshot version built on Linux x86-64, Arm32, and Arm64
>> all have funny black blocks in the UI of Dr Racket.
>>
>> While this display was captured from a MacOS X11 server it is the same on
>> the Linux X11 servers as well as directly on the console screen.
>>
>> Thanks.
>>
>> bruce
>>
>> [image: Screenshot 2021-04-13 at 20.35.22.png]
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/1618339098-36f9ab5b7d7507d1da5b3d5d4e45a7b0%40pckswarms.ch
>> <https://groups.google.com/d/msgid/racket-users/1618339098-36f9ab5b7d7507d1da5b3d5d4e45a7b0%40pckswarms.ch?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/CAL3TdOMcr7TMhMr4ZkSQTuEJhf%2B7DHZOG1bcPsaxzuqGgO1%2BWg%40mail.gmail.com.


Re: [racket-users] Something is going slightly wrong visually with the Linux version

2021-04-13 Thread Robby Findler
This looks to me like racket believes the OS is in dark mode but it really
isn't. Does this program produce true or false?

#lang racket
(require mrlib/panel-wob)
(white-on-black-panel-scheme?)

Robby


On Tue, Apr 13, 2021 at 1:38 PM Bruce O'Neel 
wrote:

> Hi,
>
> The most recent snapshot version built on Linux x86-64, Arm32, and Arm64
> all have funny black blocks in the UI of Dr Racket.
>
> While this display was captured from a MacOS X11 server it is the same on
> the Linux X11 servers as well as directly on the console screen.
>
> Thanks.
>
> bruce
>
> [image: Screenshot 2021-04-13 at 20.35.22.png]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/1618339098-36f9ab5b7d7507d1da5b3d5d4e45a7b0%40pckswarms.ch
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOPmxHoejvgz3g5LxzRjJuybBg%2B86KYVMgp8xcy_EBDm8Q%40mail.gmail.com.


Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
The idea is that a contract violation is not merely telling you "oh,
someone said that you should get an integer? here and you didn't." That is
what an assert macro might do. But contracts offer more.

Contracts are also giving you information to help you hone in on where the
error actually is in your code. The rough idea is that you think of your
program as partitioned into a bunch of pieces. And then contracts "stand
guard" between those pieces, attempting to stop bogus stuff from crossing
over from one piece to another piece. (Simplest form of "piece" for Racket:
a file (containing a module).) So when you put a boundary between `f` and
its containing module, you station guards there -- they tell you "something
bogus came out of f" or "something bogus went into f". For the former/first
one of those errors, it is clear: f is wrong. For the second, however, we
have to decide -- who is this guard standing between? In this code, when we
use define/contract, the other side of the boundary is the rest of the
module containing f. But then, you say -- what happened with b.rkt?! Well,
there was no guard on that boundary! So a.rkt didn't put anything to guard
that boundary, so no checks happened and off the value went -- but now,
hiding inside that value is the guard, and that guard knows only that
boundary it started on, so when that bad input comes in, it blames a.rkt.
a.rkt _could_ have protected itself (using contract-out to station a guard
on the boundary between a.rkt and b.rkt, but it didn't --coulda shoulda
woulda).

Anyway, that's the original idea, dating back to about 2002. More recently,
Christos Dimoulas together with Lukas Lazarek has started an ambitious
research program to try to actually verify that this way of erecting
boundaries actually helps the programmer. Here's a paper on the topic if
you're interested: https://dl.acm.org/doi/10.1145/3371133

Robby


On Wed, Apr 7, 2021 at 6:28 PM Raoul Duke  wrote:

> Clueless newb here. Wait, why can't we have both? As a joe programmer
> on the street I would want the blame to be on b.rkt, and also on any
> function calling f() incorrectly from inside a.rkt. Reading this
> thread it sounds to me like that's not easily available?
>
> On Wed, Apr 7, 2021 at 4:22 PM Robby Findler 
> wrote:
> >
> > No, I don't think it is a bad move if that's your goal! (I usually work
> at the file-level granularity but different code calls for different
> things.) I inferred from epi's message that that wasn't what was going on
> (perhaps incorrectly).
> >
> > Robby
> >
> > On Wed, Apr 7, 2021 at 4:37 PM David Storrs 
> wrote:
> >>
> >> I've always liked define/contract because it guarantees the safety of
> >> the function from erroneous calls by other functions in the module,
> >> which helps with debugging and testing.  It sounds like you think
> >> that's a bad move?
> >>
> >> On Wed, Apr 7, 2021 at 4:35 PM Robby Findler 
> wrote:
> >> >
> >> > The short answer: you probably should use (provide
> (contract-out)) instead of define/contract.
> >> >
> >> > The slightly longer answer: when you write a contract, you are not
> just describing what the legal inputs and outputs are, you are also
> establishing a *boundary* between two regions of code. In the case of
> define/contract, you are establishing a boundary between the function
> (here: f) and the module that it contains (here the file "a.rkt"). In the
> case of (provide (contract-out  ...)) the boundary is between a.rkt and
> b.rkt.
> >> >
> >> > The slightly uncomfortable answer: it is my (not completely solid
> yet) opinion that the boundary that is drawn for define/contract is perhaps
> not the right / best one. In a theoretical/mathematical sense it is a
> completely fine and completely defensible one. But it trips people up
> sometimes. (There are examples others have posted in the past that are
> perhaps even stranger than yours but boil down to the same specific design
> choice for define/contract.)
> >> >
> >> > Robby
> >> >
> >> >
> >> >
> >> > On Wed, Apr 7, 2021 at 2:10 PM epi via Racket Users <
> racket-users@googlegroups.com> wrote:
> >> >>
> >> >> Hello Racket users,
> >> >>
> >> >> I am trying to understand a contract violation message that I am
> getting.
> >> >> Here is the file a.rkt:
> >> >>
> >> >> #lang racket
> >> >> (provide f)
> >> >> (define/contract (f a)
> >> >>   (-> boolean? any/c)
> >> >>   '())
> >> 

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
No, I don't think it is a bad move if that's your goal! (I usually work at
the file-level granularity but different code calls for different things.)
I inferred from epi's message that that wasn't what was going on (perhaps
incorrectly).

Robby

On Wed, Apr 7, 2021 at 4:37 PM David Storrs  wrote:

> I've always liked define/contract because it guarantees the safety of
> the function from erroneous calls by other functions in the module,
> which helps with debugging and testing.  It sounds like you think
> that's a bad move?
>
> On Wed, Apr 7, 2021 at 4:35 PM Robby Findler 
> wrote:
> >
> > The short answer: you probably should use (provide (contract-out))
> instead of define/contract.
> >
> > The slightly longer answer: when you write a contract, you are not just
> describing what the legal inputs and outputs are, you are also establishing
> a *boundary* between two regions of code. In the case of define/contract,
> you are establishing a boundary between the function (here: f) and the
> module that it contains (here the file "a.rkt"). In the case of (provide
> (contract-out  ...)) the boundary is between a.rkt and b.rkt.
> >
> > The slightly uncomfortable answer: it is my (not completely solid yet)
> opinion that the boundary that is drawn for define/contract is perhaps not
> the right / best one. In a theoretical/mathematical sense it is a
> completely fine and completely defensible one. But it trips people up
> sometimes. (There are examples others have posted in the past that are
> perhaps even stranger than yours but boil down to the same specific design
> choice for define/contract.)
> >
> > Robby
> >
> >
> >
> > On Wed, Apr 7, 2021 at 2:10 PM epi via Racket Users <
> racket-users@googlegroups.com> wrote:
> >>
> >> Hello Racket users,
> >>
> >> I am trying to understand a contract violation message that I am
> getting.
> >> Here is the file a.rkt:
> >>
> >> #lang racket
> >> (provide f)
> >> (define/contract (f a)
> >>   (-> boolean? any/c)
> >>   '())
> >>
> >> and this is b.rkt:
> >>
> >> #lang racket
> >> (require "a.rkt")
> >> (f 3)
> >>
> >>
> >> I would expect that the caller is blamed for the contract violation,
> but the error message that I get is as follows:
> >>
> >>
> >> f: contract violation
> >>   expected: boolean?
> >>   given: 3
> >>   in: the 1st argument of
> >>   (-> boolean? any/c)
> >>   contract from: (function f)
> >>   blaming: /home/epi/snippets/a.rkt
> >>(assuming the contract is correct)
> >>   at: /home/epi/snippets/a.rkt:3.18
> >>   context...:
> >>/usr/share/racket/collects/racket/contract/private/blame.rkt:347:0:
> raise-blame-error
> >>
> /usr/share/racket/collects/racket/contract/private/arrow-higher-order.rkt:379:33
> >>body of "/home/dan/snippets/blameme.rkt"
> >>
> >> So, I am a bit surprised that the error message blames the file a.rkt.
> >> What am I missing here?
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/149cfc632cd666ff1a92177dce90296b%40disroot.org
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAL3TdONLMx%3Dy_cgfDsY_k9L9yaX_touO52phiK9scziW_jGrOA%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/CAE8gKofSq%3DvzFV3jt3fkMbzMqV%3Dt9%2BHtj1y02Nsku_ZXF6%2BB5A%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/CAL3TdOO3P5eYn_GW8jmKO82haXvXNbKWJodeRh1%2BZ58y3SH%3DsQ%40mail.gmail.com.


Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
The short answer: you probably should use (provide (contract-out))
instead of define/contract.

The slightly longer answer: when you write a contract, you are not just
describing what the legal inputs and outputs are, you are also establishing
a *boundary* between two regions of code. In the case of define/contract,
you are establishing a boundary between the function (here: f) and the
module that it contains (here the file "a.rkt"). In the case of (provide
(contract-out  ...)) the boundary is between a.rkt and b.rkt.

The slightly uncomfortable answer: it is my (not completely solid yet)
opinion that the boundary that is drawn for define/contract is perhaps not
the right / best one. In a theoretical/mathematical sense it is a
completely fine and completely defensible one. But it trips people up
sometimes. (There are examples others have posted in the past that are
perhaps even stranger than yours but boil down to the same specific design
choice for define/contract.)

Robby



On Wed, Apr 7, 2021 at 2:10 PM epi via Racket Users <
racket-users@googlegroups.com> wrote:

> Hello Racket users,
>
> I am trying to understand a contract violation message that I am getting.
> Here is the file a.rkt:
>
> #lang racket
> (provide f)
> (define/contract (f a)
>   (-> boolean? any/c)
>   '())
>
> and this is b.rkt:
>
> #lang racket
> (require "a.rkt")
> (f 3)
>
>
> I would expect that the caller is blamed for the contract violation, but
> the error message that I get is as follows:
>
>
> f: contract violation
>   expected: boolean?
>   given: 3
>   in: the 1st argument of
>   (-> boolean? any/c)
>   contract from: (function f)
>   blaming: /home/epi/snippets/a.rkt
>(assuming the contract is correct)
>   at: /home/epi/snippets/a.rkt:3.18
>   context...:
>/usr/share/racket/collects/racket/contract/private/blame.rkt:347:0:
> raise-blame-error
>
>  
> /usr/share/racket/collects/racket/contract/private/arrow-higher-order.rkt:379:33
>body of "/home/dan/snippets/blameme.rkt"
>
> So, I am a bit surprised that the error message blames the file a.rkt.
> What am I missing here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/149cfc632cd666ff1a92177dce90296b%40disroot.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONLMx%3Dy_cgfDsY_k9L9yaX_touO52phiK9scziW_jGrOA%40mail.gmail.com.


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

2021-03-15 Thread Robby Findler
Depending on what you're doing, a nack guard evt might be helpful. It lets
do a form of chaining evts together. It definitely isn't and in the sense
you describe but it is easy to overlook.

Robby

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

> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
> > Is there a corresponding event for a logical conjunction (I was looking
> for
> > something like `all-evt` or `every-evt`), which requires that all of its
> > members be ready for synchronization at the same time?
>
> No. (Although `replavce-evt` is a weak kind of "and", it's not what
> you're looking for.)
>
> > If not, is there a fundamental barrier to its implementation with the
> > ConcurrentML approach?
>
> Yes, at least in the sense that it's not possible to implement N-way
> rendezvous given only CML's rendezvous.
>
> So, N-way rendezvous would have to be implemented in the core. I'm
> certain that some languages have implemented that, but I have forgotten
> the examples.
>
> > Related to this, I've been reading "Kill-Safe Synchronization
> Abstractions"
> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found it
> > notable that the swap channel couldn't be implemented in a way that was
> > both kill-safe and break-safe (not ruining `sync/enable-break`'s
> > exclusive-or guarantee).  I'm wondering if both forms of safety could be
> > achieved by using a hypothetical `all-evt` that behaves as I've
> described.
>
> Probably so. The citation of [17] in that part of the paper is meant to
> allude to the CML-style rendezvous versus N-way rendezvous constraint.
>
>
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONtWDeMgWUzXB%3DWc-fN%3DRi2pj%2BMC7-kg5pWhJOc2bzgjA%40mail.gmail.com.


Re: [racket-users] Is it safe to `read` untrusted input?

2021-02-28 Thread Robby Findler
Leaving aside bugs, the intention with those parameters you mention (-lang,
-reader, -compiled) is to help with security. They certainly would allow
for code execution and they are off by default precisely because they allow
that. I think that the general principle (read should, with the default
parameter values, not evaluate any code) is one that is unlikely to change.

Robby

On Sun, Feb 28, 2021 at 1: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
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOPu7ycrz%2BEMvUP9%2Bh%2BYn7d%2BOb4r8bfb6SJ3g_BxqLKJYQ%40mail.gmail.com.


Re: [racket-users] Parenthesizing infix expressions in Redex renderings?

2021-02-24 Thread Robby Findler
Yeah, I've been meaning to integrate those parts of that library into Redex
proper but just haven't found the time.

Also, I've thought it would be nice if Redex were able to look at the
context of a particular, say, "or" or "then" expression and figure out if
it needed parens. Sadly, for now you have to specialize the rewriting based
on specific examples you're rendering (or just have too many parens, sigh).

Robby


On Wed, Feb 24, 2021 at 4:46 AM David Thrane Christiansen <
da...@davidchristiansen.dk> wrote:

> Thanks Ryan!
>
> There's all sorts of nice goodies in that library, like
> current-atomic-rewriters and friends.
>
> David
>
> Den ons. 24. feb. 2021 kl. 11.29 skrev Ryan Culpepper <
> rmculpepp...@gmail.com>:
>
>> The `binary-rw` function from unstable/gui/redex library has some support
>> for optionally parenthesizing its arguments.
>>
>> Ryan
>>
>>
>> On Wed, Feb 24, 2021 at 11:07 AM David Thrane Christiansen <
>> da...@davidchristiansen.dk> wrote:
>>
>>> Hello all,
>>>
>>> I'm working on coding up a little language model in Redex, and I'd like
>>> to get it to render things in the form that my colleagues are used to. This
>>> means some infix operators as well as dealing with parenthesizing based on
>>> operator precedence.
>>>
>>> Here's a boiled-down sample of what I'm up to:
>>>
>>> #lang racket
>>>
>>> (require redex pict)
>>>
>>> (define-language L
>>>   (C success (then C C) (or C C)))
>>>
>>> (with-compound-rewriters
>>>   (['or (match-lambda [(list _ _ x y _) (list "" x " or " y "")])]
>>>['then (match-lambda [(list _ _ x y _) (list "" x " then " y "")])])
>>>   (vl-append
>>>20
>>>(render-language L)
>>>(render-term L (then (or success success) success
>>>
>>> I've attached the result. The resulting rendering of L looks
>>> appropriate, but the nesting of then and or in the rendered term does not
>>> indicate the nesting. I'd like to be able to specify precedence and
>>> associativity and have parentheses inserted appropriately; failing that, a
>>> reasonable backup would be parenthesizing sub-expressions that are not
>>> atomic.
>>>
>>> Can anyone point me at the right resource to use to figure out how to do
>>> this?
>>>
>>> Thank you!
>>>
>>> David
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/CAF_itEtHuJP6i%3DR3_ggKTn1%3DRDmswZfCiFMYJqBwcHqpXB7fpw%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/CAF_itEt9JUSZBUZ_09keQmXpUo0HJbYahN4dXD%2Bjp8jp9A2cXw%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/CAL3TdOPbTBf6eSm14anTdgh1s2siUE8RRr0yuYC3zxs3msoEvg%40mail.gmail.com.


Re: [racket-users] exporting example code from slideshow documents

2021-02-21 Thread Robby Findler
I often end up writing macros that both quote some code and expand into
that code where the first one is usually via `racket` or one of the
code-rendering libraries, and the second one gets used to write tests for
the code in my slideshow. These tend to be short and fairly ad hoc macros
because I end up customizing them in various ways to support the
presentation. I haven't found an idea for a nice general purpose library
that does this. In the meantime, there's a bare bones example below. I
usually end up starting like that but then doing various fancy things to
support the specific examples in good ways.

hth,
Robby

#lang racket
(require slideshow
 slideshow/code
 syntax/parse/define)
(module+ test (require rackunit))

(define-simple-macro
  (code+run e)
  (values (code e) e))

(define-values (x^2+1-pict x^2+1-func)
  (code+run
   (λ (x)
 (+ (* x x)
1
(module+ test
  (check-equal? (x^2+1-func 0) 1)
  (check-equal? (x^2+1-func -1) 2))

(slide x^2+1-pict)



On Sun, Feb 21, 2021 at 8:05 AM David Bremner  wrote:

>
> I mostly use emacs org-mode documents for making (latex beamer) slide
> decks. This allows me to "tangle" the example code from the slides,
> along with whatever needed supporting material, to generate example
> programs that I can share with students.  Is there a (pre-built?) way to
> do something similar with a #lang slideshow document? I guess in
> principle I could embed my slideshow program in an org-mode document,
> but I wondered if this could be accomplished with racket, and with less
> levels of compiling.
>
> 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/87o8gdplce.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/CAL3TdOPZPhpfL%3DELhd1k9Z%2B130XDBC7rPcF9%2BE09VA0ei79MkA%40mail.gmail.com.


Re: [racket-users] put-image

2021-02-07 Thread Robby Findler
Okay, I've added it. It is pretty straightforward to define it in your own
code in the meantime, Patrick:

(define (put-image i1 x y i2)
  (place-image i1 x (- (image-height i2) y) i2))

Robby


On Sun, Feb 7, 2021 at 5:32 AM Stephen De Gabrielle 
wrote:

> +1
>
>
> On Sun, 7 Feb 2021 at 03:41, Robby Findler 
> wrote:
>
>> Any objection to adding it to 2htdp/image?
>>
>> Robby
>>
>> On Sat, Feb 6, 2021 at 6:32 PM Sorawee Porncharoenwase <
>> sorawee.pw...@gmail.com> wrote:
>>
>>> As explained in documentation of WeScheme
>>> <https://www.wescheme.org/doc/wescheme.html#%28def._%28%28lib._2htdp%2Fimage..rkt%29._place-image%29%29>,
>>> put-image is only available in WeScheme. Racket and its libraries don’t
>>> have this function.
>>>
>>> It’s easy to implement it yourself, however, by using place-image and
>>> image-height. Both are available in 2htdp/image
>>>
>>> On Sat, Feb 6, 2021 at 3:24 PM patric...@gmail.com <
>>> patrick.es...@gmail.com> wrote:
>>>
>>>>
>>>> What do I need to do to be able to use the "put-image" method from
>>>> WeScheme? I am starting off my program with:
>>>>
>>>>
>>>>
>>>> *#lang htdp/bsl(require 2htdp/image)*
>>>>
>>>> Is there another package I need to use?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Racket Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to racket-users+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/racket-users/c8788557-0fe6-46a2-be1a-1dbb432ab939n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/racket-users/c8788557-0fe6-46a2-be1a-1dbb432ab939n%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/CADcuegvDB8a%2BN13xcr6dcgDo4z92sDqDA%2BkU%3DhjnHffGN1h8Vg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/racket-users/CADcuegvDB8a%2BN13xcr6dcgDo4z92sDqDA%2BkU%3DhjnHffGN1h8Vg%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/CAL3TdOPsOKNE6VF606sgX2TZMwug5siPXEiXuVhjSZTfD4JP5A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/racket-users/CAL3TdOPsOKNE6VF606sgX2TZMwug5siPXEiXuVhjSZTfD4JP5A%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/CAGHj7-KsQQsx0be-m6mG4ORsMgr9zr2qWh2JZc3QH%2B_RZG7YZA%40mail.gmail.com
> <https://groups.google.com/d/msgid/racket-users/CAGHj7-KsQQsx0be-m6mG4ORsMgr9zr2qWh2JZc3QH%2B_RZG7YZA%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/CAL3TdOPRqZts5WF-_ibtutNjkBwoyL%2BBvrk-iQmRrbHDrD8jng%40mail.gmail.com.


Re: [racket-users] put-image

2021-02-06 Thread Robby Findler
Any objection to adding it to 2htdp/image?

Robby

On Sat, Feb 6, 2021 at 6:32 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> As explained in documentation of WeScheme
> ,
> put-image is only available in WeScheme. Racket and its libraries don’t
> have this function.
>
> It’s easy to implement it yourself, however, by using place-image and
> image-height. Both are available in 2htdp/image
>
> On Sat, Feb 6, 2021 at 3:24 PM patric...@gmail.com <
> patrick.es...@gmail.com> wrote:
>
>>
>> What do I need to do to be able to use the "put-image" method from
>> WeScheme? I am starting off my program with:
>>
>>
>>
>> *#lang htdp/bsl(require 2htdp/image)*
>>
>> Is there another package I need to use?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/c8788557-0fe6-46a2-be1a-1dbb432ab939n%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/CADcuegvDB8a%2BN13xcr6dcgDo4z92sDqDA%2BkU%3DhjnHffGN1h8Vg%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/CAL3TdOPsOKNE6VF606sgX2TZMwug5siPXEiXuVhjSZTfD4JP5A%40mail.gmail.com.


Re: [racket-users] [Redex] Side conditions in Reduction Relations

2021-02-05 Thread Robby Findler
Ah. And even more it is something like "submultiset" or something, since
(term (1 1)) should not be considered a subthingy of (term (1)).

Great!

Robby


On Fri, Feb 5, 2021 at 2:18 PM Beatriz Moreira 
wrote:

> Yes a subset ! Sorry !
> Yours didn't do exactly what i wanted but it helped a lot, as i didn't
> understand how i could also use judgments as guards in reduction relations.
> Thank you again :D
> Beatriz Moreira
>
> A quarta-feira, 3 de fevereiro de 2021 à(s) 22:17:50 UTC, Robby Findler
> escreveu:
>
>> You mean it should be a subset, not a subsequence? (And yes, the example
>> I sent was one where I was guessing that mine did not do what you want!)
>>
>> Robby
>>
>>
>> On Wed, Feb 3, 2021 at 4:14 PM Beatriz Moreira 
>> wrote:
>>
>>> My definition allows it to go backwards because for what im trying to do
>>> the order does not matter. So I evaluate the head of the sequence, and then
>>> recursively the tail.
>>> I tested your example you gave me just now and it passed :D
>>> Beatriz
>>>
>>> A quarta-feira, 3 de fevereiro de 2021 à(s) 18:41:53 UTC, Robby Findler
>>> escreveu:
>>>
>>>> Oh, I see -- you want (1 2 3) to be a subsequence of (1 4 2 4 3 4), for
>>>> example.
>>>>
>>>> But does your definition allow you to go "backwards"? Maybe you need a
>>>> helper judgment that captures "a subsequence that starts here"  and then
>>>> subsequence can try that one at each position?
>>>>
>>>> Robby
>>>>
>>>>
>>>> On Wed, Feb 3, 2021 at 10:33 AM Beatriz Moreira 
>>>> wrote:
>>>>
>>>>> Yes, I had to make some adjustments to the judgement you sent me but
>>>>> this helped me a lot!
>>>>> This was what I ended up using:
>>>>>
>>>>> (define-judgment-form L
>>>>>   #:mode (subsequence I I)
>>>>>   #:contract (subsequence (ts ...) (ts ...))
>>>>>
>>>>>   [--
>>>>>(subsequence (ts_1 )
>>>>> (ts_2 ... ts_1  ts_3 ...))]
>>>>>
>>>>>   [(subsequence (ts_1 ...)
>>>>> (ts_2 ... ts_3 ...))
>>>>>--
>>>>>(subsequence (ts_0 ts_1 ...)
>>>>> (ts_2 ... ts_0 ts_3 ...))])
>>>>>
>>>>> Thank you so much! :D
>>>>>
>>>>> A sábado, 30 de janeiro de 2021 à(s) 20:08:17 UTC, Robby Findler
>>>>> escreveu:
>>>>>
>>>>>> Is this what you have in mind?
>>>>>>
>>>>>> #lang racket
>>>>>> (require redex/reduction-semantics)
>>>>>>
>>>>>> (define-language L
>>>>>>   (ts ::= variable number))
>>>>>>
>>>>>> (define-judgment-form L
>>>>>>   #:mode (subsequence I I)
>>>>>>   #:contract (subsequence (ts ...) (ts ...))
>>>>>>
>>>>>>   [--
>>>>>>(subsequence (ts_1 ...)
>>>>>> (ts_2 ... ts_1 ... ts_3 ...))])
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence () (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (1) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (2) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (1 2) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (2 3) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (3 4) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (2 3 4) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (1 2 3) (1 2 3 4)))
>>>>>>
>>>>>> (test-judgment-holds
>>>>>>  (subsequence (1 2 3 4) (1 2 3 4)))
>>>>>>
>>>>>> (test-equal
>>>>>>  (judgment-holds (subsequence (5) (1 2 3 4))) #f)
>

Re: [racket-users] [Redex] Side conditions in Reduction Relations

2021-02-03 Thread Robby Findler
You mean it should be a subset, not a subsequence? (And yes, the example I
sent was one where I was guessing that mine did not do what you want!)

Robby


On Wed, Feb 3, 2021 at 4:14 PM Beatriz Moreira 
wrote:

> My definition allows it to go backwards because for what im trying to do
> the order does not matter. So I evaluate the head of the sequence, and then
> recursively the tail.
> I tested your example you gave me just now and it passed :D
> Beatriz
>
> A quarta-feira, 3 de fevereiro de 2021 à(s) 18:41:53 UTC, Robby Findler
> escreveu:
>
>> Oh, I see -- you want (1 2 3) to be a subsequence of (1 4 2 4 3 4), for
>> example.
>>
>> But does your definition allow you to go "backwards"? Maybe you need a
>> helper judgment that captures "a subsequence that starts here"  and then
>> subsequence can try that one at each position?
>>
>> Robby
>>
>>
>> On Wed, Feb 3, 2021 at 10:33 AM Beatriz Moreira 
>> wrote:
>>
>>> Yes, I had to make some adjustments to the judgement you sent me but
>>> this helped me a lot!
>>> This was what I ended up using:
>>>
>>> (define-judgment-form L
>>>   #:mode (subsequence I I)
>>>   #:contract (subsequence (ts ...) (ts ...))
>>>
>>>   [--
>>>(subsequence (ts_1 )
>>> (ts_2 ... ts_1  ts_3 ...))]
>>>
>>>   [(subsequence (ts_1 ...)
>>>     (ts_2 ... ts_3 ...))
>>>--
>>>(subsequence (ts_0 ts_1 ...)
>>> (ts_2 ... ts_0 ts_3 ...))])
>>>
>>> Thank you so much! :D
>>>
>>> A sábado, 30 de janeiro de 2021 à(s) 20:08:17 UTC, Robby Findler
>>> escreveu:
>>>
>>>> Is this what you have in mind?
>>>>
>>>> #lang racket
>>>> (require redex/reduction-semantics)
>>>>
>>>> (define-language L
>>>>   (ts ::= variable number))
>>>>
>>>> (define-judgment-form L
>>>>   #:mode (subsequence I I)
>>>>   #:contract (subsequence (ts ...) (ts ...))
>>>>
>>>>   [--
>>>>(subsequence (ts_1 ...)
>>>> (ts_2 ... ts_1 ... ts_3 ...))])
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence () (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (1) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (2) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (1 2) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (2 3) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (3 4) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (2 3 4) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (1 2 3) (1 2 3 4)))
>>>>
>>>> (test-judgment-holds
>>>>  (subsequence (1 2 3 4) (1 2 3 4)))
>>>>
>>>> (test-equal
>>>>  (judgment-holds (subsequence (5) (1 2 3 4))) #f)
>>>>
>>>> (test-equal
>>>>  (judgment-holds (subsequence (3 2) (1 2 3 4))) #f)
>>>>
>>>> (test-equal
>>>>  (judgment-holds (subsequence (4 1) (1 2 3 4))) #f)
>>>>
>>>> (test-results)
>>>>
>>>>
>>>>
>>>> On Sat, Jan 30, 2021 at 11:46 AM Beatriz Moreira 
>>>> wrote:
>>>>
>>>>> Hi !
>>>>> I have a reduction relation where I have to match a pattern *ts* to
>>>>> two sequences, where the first one contains the other one. What I tried to
>>>>> do was something like this:
>>>>> 1st seq:  (*ts_all1 ... ts ts_all2 ...*) 2nd seq:   (*ts_x1 ...
>>>>> ts ts_x2 ...*),  where *ts_x* *⊆ **ts_all*.
>>>>> But the problem is that with the pattern matching is that *ts_x1*
>>>>> doesn't match all elements of *ts_all1* .
>>>>> I'm trying to use side conditions but i can't seem to get it right :c .
>>>>> Any advice?
>>>>>
>>>>> Thank you , Beatriz :)
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Racket Us

Re: [racket-users] [Redex] Side conditions in Reduction Relations

2021-02-03 Thread Robby Findler
Oh, I see -- you want (1 2 3) to be a subsequence of (1 4 2 4 3 4), for
example.

But does your definition allow you to go "backwards"? Maybe you need a
helper judgment that captures "a subsequence that starts here"  and then
subsequence can try that one at each position?

Robby


On Wed, Feb 3, 2021 at 10:33 AM Beatriz Moreira 
wrote:

> Yes, I had to make some adjustments to the judgement you sent me but this
> helped me a lot!
> This was what I ended up using:
>
> (define-judgment-form L
>   #:mode (subsequence I I)
>   #:contract (subsequence (ts ...) (ts ...))
>
>   [--
>(subsequence (ts_1 )
> (ts_2 ... ts_1  ts_3 ...))]
>
>   [(subsequence (ts_1 ...)
> (ts_2 ... ts_3 ...))
>--
>(subsequence (ts_0 ts_1 ...)
> (ts_2 ... ts_0 ts_3 ...))])
>
> Thank you so much! :D
>
> A sábado, 30 de janeiro de 2021 à(s) 20:08:17 UTC, Robby Findler escreveu:
>
>> Is this what you have in mind?
>>
>> #lang racket
>> (require redex/reduction-semantics)
>>
>> (define-language L
>>   (ts ::= variable number))
>>
>> (define-judgment-form L
>>   #:mode (subsequence I I)
>>   #:contract (subsequence (ts ...) (ts ...))
>>
>>   [--
>>(subsequence (ts_1 ...)
>> (ts_2 ... ts_1 ... ts_3 ...))])
>>
>> (test-judgment-holds
>>  (subsequence () (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (1) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (2) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (1 2) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (2 3) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (3 4) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (2 3 4) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (1 2 3) (1 2 3 4)))
>>
>> (test-judgment-holds
>>  (subsequence (1 2 3 4) (1 2 3 4)))
>>
>> (test-equal
>>  (judgment-holds (subsequence (5) (1 2 3 4))) #f)
>>
>> (test-equal
>>  (judgment-holds (subsequence (3 2) (1 2 3 4))) #f)
>>
>> (test-equal
>>  (judgment-holds (subsequence (4 1) (1 2 3 4))) #f)
>>
>> (test-results)
>>
>>
>>
>> On Sat, Jan 30, 2021 at 11:46 AM Beatriz Moreira 
>> wrote:
>>
>>> Hi !
>>> I have a reduction relation where I have to match a pattern *ts* to two
>>> sequences, where the first one contains the other one. What I tried to do
>>> was something like this:
>>> 1st seq:  (*ts_all1 ... ts ts_all2 ...*) 2nd seq:   (*ts_x1 ... ts
>>> ts_x2 ...*),  where *ts_x* *⊆ **ts_all*.
>>> But the problem is that with the pattern matching is that *ts_x1*
>>> doesn't match all elements of *ts_all1* .
>>> I'm trying to use side conditions but i can't seem to get it right :c .
>>> Any advice?
>>>
>>> Thank you , Beatriz :)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/1f9a3f57-787b-43b9-9fb4-560e425c1cdan%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/1f9a3f57-787b-43b9-9fb4-560e425c1cdan%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/0c6555d8-9c60-4371-9369-30bd93e3027fn%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/0c6555d8-9c60-4371-9369-30bd93e3027fn%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/CAL3TdOOB-KE3OnF3rHUnYHyGnavSpYR_4QjBhgSFbmDyRGQ4mg%40mail.gmail.com.


Re: [racket-users] [Redex] Side conditions in Reduction Relations

2021-01-30 Thread Robby Findler
Is this what you have in mind?

#lang racket
(require redex/reduction-semantics)

(define-language L
  (ts ::= variable number))

(define-judgment-form L
  #:mode (subsequence I I)
  #:contract (subsequence (ts ...) (ts ...))

  [--
   (subsequence (ts_1 ...)
(ts_2 ... ts_1 ... ts_3 ...))])

(test-judgment-holds
 (subsequence () (1 2 3 4)))

(test-judgment-holds
 (subsequence (1) (1 2 3 4)))

(test-judgment-holds
 (subsequence (2) (1 2 3 4)))

(test-judgment-holds
 (subsequence (1 2) (1 2 3 4)))

(test-judgment-holds
 (subsequence (2 3) (1 2 3 4)))

(test-judgment-holds
 (subsequence (3 4) (1 2 3 4)))

(test-judgment-holds
 (subsequence (2 3 4) (1 2 3 4)))

(test-judgment-holds
 (subsequence (1 2 3) (1 2 3 4)))

(test-judgment-holds
 (subsequence (1 2 3 4) (1 2 3 4)))

(test-equal
 (judgment-holds (subsequence (5) (1 2 3 4))) #f)

(test-equal
 (judgment-holds (subsequence (3 2) (1 2 3 4))) #f)

(test-equal
 (judgment-holds (subsequence (4 1) (1 2 3 4))) #f)

(test-results)



On Sat, Jan 30, 2021 at 11:46 AM Beatriz Moreira 
wrote:

> Hi !
> I have a reduction relation where I have to match a pattern *ts* to two
> sequences, where the first one contains the other one. What I tried to do
> was something like this:
> 1st seq:  (*ts_all1 ... ts ts_all2 ...*) 2nd seq:   (*ts_x1 ... ts
> ts_x2 ...*),  where *ts_x* *⊆ **ts_all*.
> But the problem is that with the pattern matching is that *ts_x1* doesn't
> match all elements of *ts_all1* .
> I'm trying to use side conditions but i can't seem to get it right :c .
> Any advice?
>
> Thank you , Beatriz :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/1f9a3f57-787b-43b9-9fb4-560e425c1cdan%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/CAL3TdOMKZrDQ%2BUh0u9bVe6H2dzfS%3DcYDhx26yHSFCb3nzOpJTA%40mail.gmail.com.


Re: [racket-users] 32bit linux downloads

2021-01-26 Thread Robby Findler
The Northwestern snapshot builds (roughly nightly, built from git) have
ubuntu and debian 32 bit builds and the utah one has ubuntu 32 bit builds.
You can find the snapshot sites by following links from the download site
but here they are for convenience:

https://www.cs.utah.edu/plt/snapshots/

https://plt.eecs.northwestern.edu/snapshots/

Robby


On Tue, Jan 26, 2021 at 4:51 PM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> I don’t think we were planning on having those. It looks like the last
> time we made 32-bit binaries available was for version 7.3, in May 2019.
>
> John Clements
>
> > On Jan 26, 2021, at 5:31 AM, Ed Kademan  wrote:
> >
> >
> > Will Racket 8 have 32-bit linux binaries available for download?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/062354f4-a83b-4c61-adfc-61204fa97c50n%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/5052fc24-2e2f-427e-b8a0-6830e68c5a84%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/CAL3TdOP3%3D3VGNPh-ZtsLxDmFu3_sGY%3DM%3DahtFQj9zdV-3DTGMA%40mail.gmail.com.


Re: [racket-users] Moving a Rust/Haskell abstract algebra library to Racket?

2021-01-19 Thread Robby Findler
I'm no expert on algebras, but I think the way to work on this is not to
think "what Racket constructs are close that I might coopt to express what
I want?" but instead to think "what do I want my programs to look like" and
then design the language from there, reusing libraries as they seem helpful
or designing new ones that do what you want. Racket's
language-implementation facilities are pretty powerful (of course, if there
is nothing like what you end up needing, there will still be actual
programming to do ;).

Robby


On Tue, Jan 19, 2021 at 4:58 PM Stuart Hungerford <
stuart.hungerf...@gmail.com> wrote:

> Hi Racketeers,
>
> I'd like to try re-implementing a library for experimenting with abstract
> algebraic structures in Racket (that is groups, fields, rings etc, not
> algebraic data types like sum or product types). With Racket's strong
> numeric hierarchy and programmable programming language philosophy it seems
> like a good environment for experimenting with mathematical structures.
>
> This library was originally developed in Rust and more recently Haskell
> and made heavy use of Rust traits and Haskell typeclasses to implement
> these structures for the builtin numeric types as a well as my own derived
> numeric types (e.g. finite fields). I understand Racket is not Haskell (or
> Rust) and naively trying to emulate typeclasses or traits in Racket will
> likely lead to un-idiomatic code. Having said that, what Racket idioms
> would be most useful for this kind of project?
>
> A typical typeclass (from the Haskell version) would be:
>
> ```
> class Monoid a => Group a where
>
>   inverse :: a -> a
>
>   power :: Int -> a -> a
> ```
>
> Thanks,
>
> Stu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/a1ce47b2-9dab-4b33-b50b-557bfef7e331n%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/CAL3TdOM_pt6EfuXvov8jWb_%3D9u%2BqaKh2UN7bhaaYFYruaQmfJg%40mail.gmail.com.


Re: [racket-users] side-conditions

2021-01-07 Thread Robby Findler
I'm not sure without seeing more of your code (one annoying thing about
Redex is that it is not always clear when you "in redex" and when you are
"in racket" and your code might be mixing those up) but here is an example
along the lines I think you're working towards. Note that it might be
better to define in-dom as a judgment form (this would require you to
define a metafunction that checks if two names are different) but I did it
as a metafunction to show how that would work.

Robby


#lang racket
(require redex/reduction-semantics)

(define-language L
  (e ::= (+ e e) x)
  (x y ::= variable-not-otherwise-mentioned)
  (Γ ::= · (x Γ)))

(define-judgment-form L
  #:mode (closed-by I I)
  #:contract (closed-by Γ e)

  [(closed-by Γ e_1) (closed-by Γ e_2)
   ---
   (closed-by Γ (+ e_1 e_2))]

  [(side-condition (in-dom x Γ))
   -
   (closed-by Γ x)])

(define-metafunction L
  in-dom : x Γ -> boolean
  [(in-dom x ·) #false]
  [(in-dom x (x Γ)) #true]
  [(in-dom x (y Γ)) (in-dom x Γ)])

(test-judgment-holds (closed-by (c ·) c))
(test-judgment-holds (closed-by (b (c ·)) b))
(test-judgment-holds (closed-by (b (c ·)) c))
(test-judgment-holds (closed-by (a (b (c ·))) (+ a (+ b c
(test-equal (judgment-holds (closed-by · a)) #false)
(test-equal (judgment-holds (closed-by · (+ a (+ b c #false)

(test-results)


On Thu, Jan 7, 2021 at 10:52 AM Beatriz Moreira 
wrote:

> I have tried to use a metafunction to represent s∉dom(env-ß) in a side
> condition,* (side-condition (notinenv ((ß_1 ...) env-ß ...) x))*,  but
> the error message *notinenv: illegal use of syntax in: (notinenv ((ß_1
> ...) env-ß ...) x) value at phase 1: #* appears and i don't
> understand why.
>
> I defined *notinenv* as a simple metafunction just for testing:
> (define-metafunction FS
>   notinenv : env-ß x -> any
>   [(notinenv (((x -> _) ß_1 ...) env-ß ...) x) #f]
>   [(notinenv ((ß_1 ...) env-ß ...) x) #t])
>
> Thank you :)
>
> A segunda-feira, 21 de dezembro de 2020 à(s) 15:05:37 UTC, Robby Findler
> escreveu:
>
>> I recommend you define a metafunction or judgment form that captures what
>> you want exactly and then use that.
>>
>> Robby
>>
>>
>> On Mon, Dec 21, 2020 at 8:32 AM Beatriz Moreira 
>> wrote:
>>
>>> Hi,
>>> I have been using side-condition to check if a sequence of variables
>>> exist is in an environment , like this :
>>>
>>> *(side-condition (not (member (term ((s : _) ...)) (term (env-ß_1
>>> ...)*
>>>
>>> being s a state variable and _ a value that i don't know. But it doesn't
>>> seem to work as expected, as it returns #t even when it shouldn't.
>>> Is it there a better way of doing it?
>>>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/c8632f31-98c2-46cb-8231-2ca272ae2b8an%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/c8632f31-98c2-46cb-8231-2ca272ae2b8an%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/30754357-0563-4709-8d88-f0f8ef5d8b63n%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/30754357-0563-4709-8d88-f0f8ef5d8b63n%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/CAL3TdOOjKuczdg0S6XhHeCi9QuJRtFLb8EBOUzQWVqhJfbsyCQ%40mail.gmail.com.


Re: [racket-users] Tools and Syntax Highlighting

2021-01-04 Thread Robby Findler
I think a good first question here is "what do you want to happen when you
are running the program from outside DrRacket?". DrRacket is, in a general
sense, designed to reflect extra information about how a program runs when
it can glean that information, but it isn't meant to be the only way that
Racket programs run, merely one of them. So what you want to think about
is: how can a program offer up information about itself (and what
APIs/values/data should that be)? and then: how can DrRacket (or other
things that run Racket programs, eg Racket Mode, or command-line racket or
a standalone executable, etc) get a hold of that information to show it in
a meaningful way?

There are some examples of success following generally this pattern: test
coverage is a means whereby a program is expanded, then instrumented by
some tool (via rewriting the program) such that the instrumented program
produces information about what parts of the program actually ran to its
context (which might be DrRacket but might also be the "cover" library).
Check Syntax (which runs automatically these days) expands the program and
records information about it (notably binding and bound occurrences of
variables) and then DrRacket and Emacs Mode let you work with that
information.

Robby



On Mon, Jan 4, 2021 at 1:46 PM Ben Ryjikov  wrote:

> I’m sorry - I didn’t explain what kind of highlighting we’re looking for.
>
> We’re building a new #lang, and we want it so that sometimes when you run,
> DrRacket highlights a part of the program you are running. But we only want
> that in certain situations, so we want to create a function which we can
> call that would do the highlighting on demand.
>
> Are there any functions or libraries which can do that?
>
> We’ve managed to get highlighting through a tool (which is listed in
> info.rkt), but we’re struggling to get it on demand because we can’t easily
> find a way for the tool and the program to share code.
>
> Is there a way for a tool to access code which outside of the tool at
> runtime?
>
> -Ben
>
> On Jan 4, 2021, at 9:04 AM, Stephen De Gabrielle 
> wrote:
>
> On Mon, Jan 4, 2021 at 12:32 AM Ben Ryjikov  wrote:
>
>> Hi Racket,
>>
>> Is it possible for a tool invoked by info.rkt to access code which is
>> outside of the tool?
>>
>> We’re building a #lang and would like to have on-demand syntax
>> highlighting.
>> We’ve tried using a tool, and have successfully made a button and a menu
>> item that do it, but we’d like to activate the highlighting
>> programmatically at runtime instead of by clicking on something.
>> We also are hoping to have multiple highlights at once if possible.
>>
>> Is there any way to get on-demand syntax highlighting without using a
>> button or menu item? Are there any pre-existing Racket tools or functions
>> that would do this?
>>
>
> I think datalog does this;
>
> 
>
>
>
>
>>
>> Thanks for your time and Happy New Year!
>>
>> Best,
>> Ben
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/BA1B6C4F-8172-462F-9E2D-8F6F2A9C6BB4%40gmail.com
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/C549A2BB-8999-496B-B119-70239EB13EDB%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONeC8-gcw%3D5dRjY7J73EdYXja3P%3Ddrkb1GTo2JN305FsA%40mail.gmail.com.


Re: [racket-users] Why is my sandbox trying to access /etc/ssl/certs.pem?

2021-01-04 Thread Robby Findler
Complicated systems are surprising! Somehow each little step wasn't
completely crazy  and yet  there must be a lesson in here
somewhere. :)

Robby


On Mon, Jan 4, 2021 at 6:45 PM 'William J. Bowman' via Racket Users <
racket-users@googlegroups.com> wrote:

> Ah! I didn’t know about the module browser, thanks! And I guess this chain
> makes sense.
>
> --
> Sent from my phoneamajig
>
> On Jan 4, 2021, at 16:27, Robby Findler  wrote:
>
> 
>
> If you open a file that requires scribble/manual with the module browser
> (available via the Racket menu item in DrRacket), you'll see that ssl is
> needed by the code that opens urls (presumably to do https) which is needed
> by the code that handles planet requires (since planet requires may involve
> http requests) which is needed by the code that handles tags (presumably
> these tags go via require paths, maybe?) in scribble. At least, I think I
> might be getting that right.
>
> Robby
>
>
> On Mon, Jan 4, 2021 at 6:15 PM Sage Gerard  wrote:
>
>> 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 <
>> racket-users@googlegroups.com> 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

Re: [racket-users] Why is my sandbox trying to access /etc/ssl/certs.pem?

2021-01-04 Thread Robby Findler
If you open a file that requires scribble/manual with the module browser
(available via the Racket menu item in DrRacket), you'll see that ssl is
needed by the code that opens urls (presumably to do https) which is needed
by the code that handles planet requires (since planet requires may involve
http requests) which is needed by the code that handles tags (presumably
these tags go via require paths, maybe?) in scribble. At least, I think I
might be getting that right.

Robby


On Mon, Jan 4, 2021 at 6:15 PM Sage Gerard  wrote:

> 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 <
> racket-users@googlegroups.com> 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.
> > > > > To unsubscribe from this 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] PLT Redex: how to falsify the judgment in define-judgment-form

2021-01-03 Thread Robby Findler
I think this boils down to a question about how redex executes judgment
forms. Leaving aside modeless judgment forms (where redex will only check a
derivation for you but won't ever make them up), redex is turning each
judgment form into a (fancy) function from the inputs to sets of the
outputs and, based on how that function goes, will build a derivation for
you.

So, in the example in your message, think of `infer` as a function that
consumes the first thing and produces the second thing, where the part
below the bar is a kind of case/choice and the part above the bar are
recursive calls. So, if we want to use that rule, we'll be given "C" and
have to come up with "B". To make the recursive call to infer for the
premise, we have to supply an "A" which will then give us a "B". And now
we're stuck because we don't have that "B".

Of course, there are many other ways that one could think of turning
judgment forms into something that is, at least in some sense, executable.
Doing something like prolog is an obvious choice (although Redex is more
expressive than the standard/original prolog so there are some tricks
required) and Redex does indeed use a prolog-inspired solver when it is
generating random derivations that satisfy a judgment form (see Burke
Fetscher's dissertation). One might also try to turn it into a SMT query,
but Redex doesn't currently do that (and there aren't any plans to do
that). Perhaps there is another way too.

So, as to your specific question, the answer is "it depends". If you can
formulate your judgment form in a way that respects the mode, then yes, you
can use premises to constrain the sets of valid judgments. If not, you
can't.

hth,
Robby


On Sun, Jan 3, 2021 at 2:59 AM Xu Xue  wrote:

> Hi, Racketeers
>
> Since Redex can calculate all possible results in the judgment, Can I add
> some negative premise to help derive the output? like
>
> (define-judgment-form Lambda
> #:mode (infer I O)
> [(infer A B)
> *(not (infer number B)*
> -
> (Infer C B)]
>
> I tried to replace bold line with (side-condition (not (judgment-holds
> (infer number B, which is disallowed in Redex since B is in the output
> position.
>
> So any standard way to express this intention?
>
> more concrete example is in
> https://github.com/juniorxxue/applicative-intersection-semantics/blob/main/definition.rkt#L94
>
> Regards
> Xu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/25e4ec2e-ba34-4a53-8284-37cbac422ae2n%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/CAL3TdONOr5pJCtmH53bT-7tH3OuyVeKm_P61M0KSAegsx%3DQa%3Dg%40mail.gmail.com.


Re: [racket-users] Unsafe structs

2021-01-02 Thread Robby Findler
On Sat, Jan 2, 2021 at 4:34 PM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

> Hello Racketeers (and Robby especially)!
>
> On 22. 12. 20 1:30, Robby Findler wrote:
> > Is Typed Racket able to prove that your use of unsafe accessors is
> > actually safe?
>
> Short answer: YES.
>
> One question for a start: And what now?
>
>
That's great! (And I can sympathize about the sarcastic thank you-- getting
a machine to verify a proof of something you know to be true is really a
lot of work!)

As for what now, my hope was that if TR could provide that your uses were
good then you could rely on TR to follow up with the actual optimizations.
Did you find that to be the case? I see you had to give up on the
parallelism for other reasons so I guess there is still a ways to go. I'm
not going to recommend that you follow this path further, but I guess that
if you did there would be grateful people, perhaps starting with Sam.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOxQobkq9XPtRynXb8OfWs4r0t5n_LUxxJkfr6-ZzcXVQ%40mail.gmail.com.


Re: [racket-users] Unsafe structs

2020-12-21 Thread Robby Findler
Is Typed Racket able to prove that your use of unsafe accessors is actually
safe?

Robby

On Mon, Dec 21, 2020 at 3:36 PM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

>
> On 21. 12. 20 18:07, David Storrs wrote:
> > 
> > The struct-plus-plus module also provides reflection, so you might take
> > a look to see if there are any ideas in there that would be useful for
> > your own module.  Accessors are included, as are constructors, rules,
> > wrappers, default values, and predicates.  spp has two primary
> > limitations:  You cannot use a base type and you cannot mark individual
> > fields mutable, only the entire struct.
> Nice one! The per-field #:mutable keyword was one of the things that
> made me look into it more :)
>
> I will look into the sources and some of the ideas there will help me
> implement it in a cleaner way. That said, I am mostly interested in
> providing the unsafe accessors/mutators transparently.
>
>
> Cheers,
> Dominik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/19db4267-edd6-6eea-778d-8b15643789a1%40trustica.cz
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOPFRE5tDp_ceyTTBOQ4B3xnNRWnXJGtF%3D0ACA9_J4Hchw%40mail.gmail.com.


Re: [racket-users] side-conditions

2020-12-21 Thread Robby Findler
I recommend you define a metafunction or judgment form that captures what
you want exactly and then use that.

Robby


On Mon, Dec 21, 2020 at 8:32 AM Beatriz Moreira 
wrote:

> Hi,
> I have been using side-condition to check if a sequence of variables exist
> is in an environment , like this :
>
> *(side-condition (not (member (term ((s : _) ...)) (term (env-ß_1 ...)*
>
> being s a state variable and _ a value that i don't know. But it doesn't
> seem to work as expected, as it returns #t even when it shouldn't.
> Is it there a better way of doing it?
>
> 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/c8632f31-98c2-46cb-8231-2ca272ae2b8an%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/CAL3TdOMRF%2BkoLmEz3m1-u9VwmYAByRz0NBgtCbJ%3Dgb0TUpSisA%40mail.gmail.com.


Re: [racket-users] Trouble with `set-copy`

2020-12-08 Thread Robby Findler
Sorry for the earlier confusion!

On Tue, Dec 8, 2020 at 6:48 PM Nathaniel W Griswold 
wrote:

> Ok. Thanks.
>
> > On Dec 8, 2020, at 6:47 PM, Robby Findler 
> wrote:
> >
> > Right, it is probably both things. I ran your program on yesterday's git
> build and it still returns #false, but for the mutability reason, not the
> bug that Jon mentioned.
> >
> > Robby
> >
> >
> > On Tue, Dec 8, 2020 at 6:45 PM Nathaniel W Griswold 
> wrote:
> > I think it is something more. The copied set is giving completely
> different elements. If i loop over the copied set i get 32 values from 0 to
> like 31, when i have in fact added 1000 random elements to the original set
> before copying.
> >
> > Nate
> >
> > > On Dec 8, 2020, at 6:43 PM, Robby Findler 
> wrote:
> > >
> > > No, I don't think that's it. The issue is that one is a mutable set
> and the other isn't, so they aren't equal (even if their elements aren't
> equal).
> > >
> > > > (equal? (mutable-seteqv) (list->seteqv '()))
> > > #f
> > >
> > > Maybe you wanted to call list->mutable-seteqv? Or maybe just start
> with an immutable set?
> > >
> > > Robby
> > >
> > >
> > > On Tue, Dec 8, 2020 at 6:40 PM Nathaniel W Griswold
>  wrote:
> > > Thanks. Switching to 7.9 now.
> > >
> > > Nate
> > >
> > > > On Dec 8, 2020, at 6:38 PM, Jon Zeppieri  wrote:
> > > >
> > > > I think that's this bug
> > > > [
> https://github.com/racket/racket/commit/543dab59640fa5e911443baaadaae471406dbf40
> ],
> > > > which should be fixed in 7.9. - Jon
> > > >
> > > > On Tue, Dec 8, 2020 at 7:19 PM Nathaniel W Griswold
> > > >  wrote:
> > > >>
> > > >> I don’t know if i’m missing something or what, but the following is
> confusing me:
> > > >>
> > > >> (let ([test (mutable-seteqv)])
> > > >>  (for* ([i (in-range 1000)]
> > > >> [j (random 0 1000)])
> > > >>(set-add! test j))
> > > >>  (let ([test-copy (set-copy test)])
> > > >>(printf "test-copy=~a\n" (set->list test-copy))
> > > >>(printf "Equal from stream is ~a\n" (equal? (list->seteqv
> (set->list test-copy)) test
> > > >>
> > > >> prints something like:
> > > >> test-copy=(31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
> 12 11 10 9 8 7 6 5 4 3 2 1 0)
> > > >> Equal from stream is #f
> > > >> Equal regular is #t
> > > >>
> > > >>
> > > >> Why is this?
> > > >>
> > > >> Thanks
> > > >>
> > > >> Nate
> > > >>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > > >> To unsubscribe from this group and stop receiving emails from it,
> send an email to racket-users+unsubscr...@googlegroups.com.
> > > >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/ED9A219D-41D8-42BF-9C67-9887ADFB268B%40manicmind.earth
> .
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/B11A3C69-794C-4E45-8C56-311DEB07164C%40manicmind.earth
> .
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAL3TdON3V6Qrq3U2xdemoxYzpgXUkDhRsBT3gN%3DYHjZ8aCFfgg%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/0AED1D31-2FE2-4637-908D-D57808D55CFB%40manicmind.earth
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOO3Gh16Bsd_mSco_aJDDqS1x8nRgWdV0rUhTxFaeNxycQ%40mail.gmail.com.


Re: [racket-users] Trouble with `set-copy`

2020-12-08 Thread Robby Findler
Right, it is probably both things. I ran your program on yesterday's git
build and it still returns #false, but for the mutability reason, not the
bug that Jon mentioned.

Robby


On Tue, Dec 8, 2020 at 6:45 PM Nathaniel W Griswold 
wrote:

> I think it is something more. The copied set is giving completely
> different elements. If i loop over the copied set i get 32 values from 0 to
> like 31, when i have in fact added 1000 random elements to the original set
> before copying.
>
> Nate
>
> > On Dec 8, 2020, at 6:43 PM, Robby Findler 
> wrote:
> >
> > No, I don't think that's it. The issue is that one is a mutable set and
> the other isn't, so they aren't equal (even if their elements aren't equal).
> >
> > > (equal? (mutable-seteqv) (list->seteqv '()))
> > #f
> >
> > Maybe you wanted to call list->mutable-seteqv? Or maybe just start with
> an immutable set?
> >
> > Robby
> >
> >
> > On Tue, Dec 8, 2020 at 6:40 PM Nathaniel W Griswold 
> wrote:
> > Thanks. Switching to 7.9 now.
> >
> > Nate
> >
> > > On Dec 8, 2020, at 6:38 PM, Jon Zeppieri  wrote:
> > >
> > > I think that's this bug
> > > [
> https://github.com/racket/racket/commit/543dab59640fa5e911443baaadaae471406dbf40
> ],
> > > which should be fixed in 7.9. - Jon
> > >
> > > On Tue, Dec 8, 2020 at 7:19 PM Nathaniel W Griswold
> > >  wrote:
> > >>
> > >> I don’t know if i’m missing something or what, but the following is
> confusing me:
> > >>
> > >> (let ([test (mutable-seteqv)])
> > >>  (for* ([i (in-range 1000)]
> > >> [j (random 0 1000)])
> > >>(set-add! test j))
> > >>  (let ([test-copy (set-copy test)])
> > >>(printf "test-copy=~a\n" (set->list test-copy))
> > >>(printf "Equal from stream is ~a\n" (equal? (list->seteqv
> (set->list test-copy)) test
> > >>
> > >> prints something like:
> > >> test-copy=(31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
> 12 11 10 9 8 7 6 5 4 3 2 1 0)
> > >> Equal from stream is #f
> > >> Equal regular is #t
> > >>
> > >>
> > >> Why is this?
> > >>
> > >> Thanks
> > >>
> > >> Nate
> > >>
> > >> --
> > >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > >> To unsubscribe from this group and stop receiving emails from it,
> send an email to racket-users+unsubscr...@googlegroups.com.
> > >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/ED9A219D-41D8-42BF-9C67-9887ADFB268B%40manicmind.earth
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/B11A3C69-794C-4E45-8C56-311DEB07164C%40manicmind.earth
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAL3TdON3V6Qrq3U2xdemoxYzpgXUkDhRsBT3gN%3DYHjZ8aCFfgg%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/0AED1D31-2FE2-4637-908D-D57808D55CFB%40manicmind.earth
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOCzogZxAk3W0n66Tqg%3DHJG-g-mm%3DQwCDQzp8vj7yp3Eg%40mail.gmail.com.


Re: [racket-users] Trouble with `set-copy`

2020-12-08 Thread Robby Findler
No, I don't think that's it. The issue is that one is a mutable set and the
other isn't, so they aren't equal (even if their elements aren't equal).

> (equal? (mutable-seteqv) (list->seteqv '()))
#f

Maybe you wanted to call list->mutable-seteqv? Or maybe just start with an
immutable set?

Robby


On Tue, Dec 8, 2020 at 6:40 PM Nathaniel W Griswold 
wrote:

> Thanks. Switching to 7.9 now.
>
> Nate
>
> > On Dec 8, 2020, at 6:38 PM, Jon Zeppieri  wrote:
> >
> > I think that's this bug
> > [
> https://github.com/racket/racket/commit/543dab59640fa5e911443baaadaae471406dbf40
> ],
> > which should be fixed in 7.9. - Jon
> >
> > On Tue, Dec 8, 2020 at 7:19 PM Nathaniel W Griswold
> >  wrote:
> >>
> >> I don’t know if i’m missing something or what, but the following is
> confusing me:
> >>
> >> (let ([test (mutable-seteqv)])
> >>  (for* ([i (in-range 1000)]
> >> [j (random 0 1000)])
> >>(set-add! test j))
> >>  (let ([test-copy (set-copy test)])
> >>(printf "test-copy=~a\n" (set->list test-copy))
> >>(printf "Equal from stream is ~a\n" (equal? (list->seteqv (set->list
> test-copy)) test
> >>
> >> prints something like:
> >> test-copy=(31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12
> 11 10 9 8 7 6 5 4 3 2 1 0)
> >> Equal from stream is #f
> >> Equal regular is #t
> >>
> >>
> >> Why is this?
> >>
> >> Thanks
> >>
> >> Nate
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/ED9A219D-41D8-42BF-9C67-9887ADFB268B%40manicmind.earth
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/B11A3C69-794C-4E45-8C56-311DEB07164C%40manicmind.earth
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdON3V6Qrq3U2xdemoxYzpgXUkDhRsBT3gN%3DYHjZ8aCFfgg%40mail.gmail.com.


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

2020-12-02 Thread Robby Findler
Oh, and I should have pointed out that, at least for the read level,
DrRacket already is incremental and can recover from errors. This helps
only with the syntax coloring, however.

Robby


On Wed, Dec 2, 2020 at 9:10 AM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> IIUC, many tools (Racket Mode <https://www.racket-mode.com/>, drcomplete
> <https://github.com/yjqww6/drcomplete>) do exactly what Robby said: cache
> the most recent successfully expanded code.
>
>
> On Wed, Dec 2, 2020 at 7:08 AM Robby Findler 
> wrote:
>
>> I'm not sure this approach is going to work for Racket. Being able to run
>> `read` when the input is malformed is going to only get you so far, as the
>> macro expansion seems unlikely to work and this is a point of extension for
>> programers using Racket.
>>
>> Maybe a better approach would be to help DrRacket be better at keeping
>> information from the last time the expansion was successful and apply that
>> information to a program that has been edited since then?
>>
>> Robby
>>
>>
>> On Wed, Dec 2, 2020 at 8:53 AM nicobao  wrote:
>>
>>> Hi!
>>>
>>> The Racket Reader and the Racket Expander always return "Error : blabla"
>>> when you send it a bad Racket source code.
>>> As a consequence, when there is a source code error, DrRacket and the
>>> Racket LSP cannot provide IDE functionalities like "find references", "info
>>> on hover", "find definition"...etc.
>>> This is an issue, because 99% of the time one write code, the code is
>>> incorrect. Other languages (Rust, Typescript/JS, Java, OCaml...etc) rely on
>>> an incremental parser than can provide a tree even if the source code is
>>> wrong. Basically it adds an "ERROR" node in the tree, and go on instead of
>>> stopping everything and returning at the first error.
>>> Currently this compiler issue is blocking the Racket IDE to provide
>>> better user experience.
>>> For my practical use case of Racket, it is important.
>>>
>>> I would like to help working towards that direction.
>>> I see two possible solutions to that:
>>> 1) improve the recursive descent parser of the Reader, as well as the
>>> Expander to make them incremental and fault-tolerant
>>> 2) re-writing the parser in something like tree-sitter or Menhir, at the
>>> cost of having to re-write the Reader/Expander logic (!!!)
>>>
>>> Both solutions are daunting tasks.
>>>
>>> For solution 1), could you point me to the Racket's recursive descent
>>> parser source code? What about the Expander ?
>>>
>>> For solution 2), I was thinking of writing a tree-sitter grammar for
>>> racket. However, I can't find a formal description of the grammar, like
>>> Scheme did here:
>>> https://www.scheme.com/tspl4/grammar.html#APPENDIXFORMALSYNTAX
>>> Of course, the Racket documentation is still quite comprehensive, but it
>>> would be nice if anyone could tell me if there is such formal document
>>> somewhere?
>>> Besides, I wonder whether Racket/Scheme could even be described using a
>>> LR(1) or a GLR grammar?
>>>
>>> Finally, is any work have been started towards this direction?
>>>
>>> Totally off-topic, but has anyone ever thought of compiling Racket down
>>> to OCaml, in order to reuse js_of_ocaml and produce optimized JS code from
>>> Racket?
>>> I was wondering whether it would be feasible.
>>>
>>> Final note: I know all of that is _very_ ambitious!
>>>
>>> Kind regards,
>>> Nicolas
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/d77440e3-1876-44e5-b52b-323d5715df66n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/d77440e3-1876-44e5-b52b-323d5715df66n%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/CAL3TdOOB-8qUncNcRz_NFqvQVEK5rT5jeRY8jfq1W6mN2h40eg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/racket-users/CAL3TdOOB-8qUncNcRz_NFqvQVEK5rT5jeRY8jfq1W6mN2h40eg%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/CAL3TdOP50wVHMhD7LPjnWuKXL8MUdc8zVdpcN2fGZ13D5M%2B-TQ%40mail.gmail.com.


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

2020-12-02 Thread Robby Findler
I'm not sure this approach is going to work for Racket. Being able to run
`read` when the input is malformed is going to only get you so far, as the
macro expansion seems unlikely to work and this is a point of extension for
programers using Racket.

Maybe a better approach would be to help DrRacket be better at keeping
information from the last time the expansion was successful and apply that
information to a program that has been edited since then?

Robby


On Wed, Dec 2, 2020 at 8:53 AM nicobao  wrote:

> Hi!
>
> The Racket Reader and the Racket Expander always return "Error : blabla"
> when you send it a bad Racket source code.
> As a consequence, when there is a source code error, DrRacket and the
> Racket LSP cannot provide IDE functionalities like "find references", "info
> on hover", "find definition"...etc.
> This is an issue, because 99% of the time one write code, the code is
> incorrect. Other languages (Rust, Typescript/JS, Java, OCaml...etc) rely on
> an incremental parser than can provide a tree even if the source code is
> wrong. Basically it adds an "ERROR" node in the tree, and go on instead of
> stopping everything and returning at the first error.
> Currently this compiler issue is blocking the Racket IDE to provide better
> user experience.
> For my practical use case of Racket, it is important.
>
> I would like to help working towards that direction.
> I see two possible solutions to that:
> 1) improve the recursive descent parser of the Reader, as well as the
> Expander to make them incremental and fault-tolerant
> 2) re-writing the parser in something like tree-sitter or Menhir, at the
> cost of having to re-write the Reader/Expander logic (!!!)
>
> Both solutions are daunting tasks.
>
> For solution 1), could you point me to the Racket's recursive descent
> parser source code? What about the Expander ?
>
> For solution 2), I was thinking of writing a tree-sitter grammar for
> racket. However, I can't find a formal description of the grammar, like
> Scheme did here:
> https://www.scheme.com/tspl4/grammar.html#APPENDIXFORMALSYNTAX
> Of course, the Racket documentation is still quite comprehensive, but it
> would be nice if anyone could tell me if there is such formal document
> somewhere?
> Besides, I wonder whether Racket/Scheme could even be described using a
> LR(1) or a GLR grammar?
>
> Finally, is any work have been started towards this direction?
>
> Totally off-topic, but has anyone ever thought of compiling Racket down to
> OCaml, in order to reuse js_of_ocaml and produce optimized JS code from
> Racket?
> I was wondering whether it would be feasible.
>
> Final note: I know all of that is _very_ ambitious!
>
> Kind regards,
> Nicolas
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/d77440e3-1876-44e5-b52b-323d5715df66n%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/CAL3TdOOB-8qUncNcRz_NFqvQVEK5rT5jeRY8jfq1W6mN2h40eg%40mail.gmail.com.


Re: [racket-users] DrRacket caret blink

2020-11-29 Thread Robby Findler
It would be nice to have DrRacket pay attention to the os-level preference
when it exists.

Robby

On Sun, Nov 29, 2020 at 2:52 AM 'Mark' via Racket Users <
racket-users@googlegroups.com> wrote:

> It is easy to get the OS preference for Windows and Gtk. But it is
> actually _better_ to just have a config option since macOS doesn't offer
> any global config for this.
>
> On Saturday, November 28, 2020 at 11:22:21 PM UTC Robby Findler wrote:
>
>> I've pushed a change to DrRacket so you can set a preference in it to
>> turn the blink off. As Philip says, the more difficult part will be getting
>> the preference from the OS but at least that's a start.
>>
>> Robby
>>
>>
>> On Sat, Nov 28, 2020 at 2:49 PM Philip McGrath 
>> wrote:
>>
>>> On Sat, Nov 28, 2020 at 3:10 PM 'Mark' via Racket Users <
>>> racket...@googlegroups.com> wrote:
>>>
>>>> (But it is still a pity that there's no config option to turn off
>>>> blinking in DrRacket.)
>>>>
>>>
>>> I agree that this would be a valuable feature to add, not just to
>>> DrRacket but to `racket/gui` in general. It seems the blinking behavior is
>>> controlled with a hard-coded interval here:
>>> https://github.com/racket/gui/blob/aa5ebfec7402bdcbc3813f822caedb4a3ceb2c4c/gui-lib/mred/private/wxme/editor-canvas.rkt#L84-L104
>>> Probably the hard part of a solution would be detecting the user's
>>> preference properly across platforms.
>>>
>>> In the meantime, I think it would be possible for a DrRacket plugin
>>> <https://docs.racket-lang.org/tools/Extending_the_Existing_DrRacket_Classes.html>
>>> to use `drracket:get/extend:extend-interactions-text` and
>>> `drracket:get/extend:extend-definitions-text` to override the
>>> `blink-caret`
>>> <https://docs.racket-lang.org/gui/editor___.html#(meth._(((lib._mred%2Fmain..rkt)._editor~3c~25~3e)._blink-caret))>
>>> method with a no-op.
>>>
>>> -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...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/01000176109e430d-5ed26ea0-2ae2-440b-b2f3-1c1c3115f50c-00%40email.amazonses.com
>>> <https://groups.google.com/d/msgid/racket-users/01000176109e430d-5ed26ea0-2ae2-440b-b2f3-1c1c3115f50c-00%40email.amazonses.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/6cec713b-f619-40a0-a0f1-e1c020ff47b3n%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/6cec713b-f619-40a0-a0f1-e1c020ff47b3n%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/CAL3TdONq-Q_goNRrvEpcsJwWmwPi80izo6OPQB9OSm2aire-Ng%40mail.gmail.com.


Re: [racket-users] DrRacket caret blink

2020-11-28 Thread Robby Findler
I've pushed a change to DrRacket so you can set a preference in it to turn
the blink off. As Philip says, the more difficult part will be getting the
preference from the OS but at least that's a start.

Robby


On Sat, Nov 28, 2020 at 2:49 PM Philip McGrath 
wrote:

> On Sat, Nov 28, 2020 at 3:10 PM 'Mark' via Racket Users <
> racket-users@googlegroups.com> wrote:
>
>> (But it is still a pity that there's no config option to turn off
>> blinking in DrRacket.)
>>
>
> I agree that this would be a valuable feature to add, not just to DrRacket
> but to `racket/gui` in general. It seems the blinking behavior is
> controlled with a hard-coded interval here:
> https://github.com/racket/gui/blob/aa5ebfec7402bdcbc3813f822caedb4a3ceb2c4c/gui-lib/mred/private/wxme/editor-canvas.rkt#L84-L104
> Probably the hard part of a solution would be detecting the user's
> preference properly across platforms.
>
> In the meantime, I think it would be possible for a DrRacket plugin
> 
> to use `drracket:get/extend:extend-interactions-text` and
> `drracket:get/extend:extend-definitions-text` to override the
> `blink-caret`
> 
> method with a no-op.
>
> -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/01000176109e430d-5ed26ea0-2ae2-440b-b2f3-1c1c3115f50c-00%40email.amazonses.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/CAL3TdOOJTbHarVP-jW-7JF%3DjD_e3jN_btJ1uk-ZWufD_mChiWw%40mail.gmail.com.


Re: [SPAM] Re: [racket-users] snappier place startup time

2020-11-24 Thread Robby Findler
On Tue, Nov 24, 2020 at 12:09 PM Nathaniel W Griswold 
wrote:

> racket/fixnum, racket/flonum, and racket/vector are needed by
> “private/th-place.rkt”, which is required by racket/place. Not sure why
> DrRacket is saying that it’s not needed.
>
>
Ah, sorry: DrRacket was merely saying that the exports of those modules
weren't used by the racket/place module.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOkdBjyxjUOnUE6_CmsuioHfCx7OJn5Bh6dqS4uQm78yA%40mail.gmail.com.


Re: [racket-users] snappier place startup time

2020-11-24 Thread Robby Findler
I didn't check to see if removing those has a significant performance
effect, but the remaining requires seem pretty minimal.

Robby


On Tue, Nov 24, 2020 at 10:26 AM 'Nathaniel W Griswold' via Racket Users <
racket-users@googlegroups.com> wrote:

> Cool. If this is indeed the case it might be nice for someone (maybe me)
> to cut it down, since any nontrivial place will of course require
> racket/place and that is kind of a long time.
>
> Nate
>
> On Nov 24, 2020, at 9:52 AM, Robby Findler 
> wrote:
>
> DrRacket thinks that there are no references to a number of the requires
> in racket/place, including racket/fixnum, racket/flonum, racket/vector, and
> racket/runtime-path. Not sure if that's an error on DrRacket's part (and I
> don't see why those would be needed for their effects).
>
> Also, the only use of racket/match seems to be this, which seems simple to
> rewrite out.
>
> (match name
>   [(? symbol?) `(submod (quote ,name) ,submod-name)]
>   [(? path?) `(submod ,name ,submod-name)]
>   [`(,p ,s ...) `(submod ,(if (symbol? p) `(quote ,p) p) ,@s
> ,submod-name)])
>
> Robby
>
>
> On Tue, Nov 24, 2020 at 8:58 AM Nate Griswold 
> wrote:
>
>> Oh, interesting. So compilation breaks the submodule out from the modules
>> if possible?
>>
>> So anyway, it sounds like breaking my modules out into separate files
>> will improve performance in most cases.
>>
>> Unfortunately, i need racket/place in the module that is my startup
>> bottleneck. If i modify the previous program to require racket/place and
>> compile, it takes around 180ms.
>>
>> This is about what i can expect for a module that requires racket/place,
>> then?
>>
>> Nate
>>
>>
>> On Tue, Nov 24, 2020 at 8:48 AM Matthew Flatt  wrote:
>>
>>> Just to elaborate a little more:
>>>
>>> The difference is because the `test` submodule can be loaded
>>> independently from the compiled form. Loading the submodule from source
>>> requires loading the enclosing module, too (which depends on
>>> `racket/place` and more).
>>>
>>> At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote:
>>> > Awesome, thanks!
>>> >
>>> > Nate
>>> >
>>> >
>>> > On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt <
>>> sa...@cs.indiana.edu>
>>> > wrote:
>>> >
>>> > > Almost certainly the problem is expansion time. If I run that program
>>> > > on my machine, it takes about 200 ms. But if I compile the file to zo
>>> > > first with `raco make`, then it takes about 40 ms, basically
>>> identical
>>> > > to `racket/base`.
>>> > >
>>> > > Sam
>>> > >
>>> > > On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold <
>>> nategrisw...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > Oops, i am having some issues with not getting to the list from my
>>> other
>>> > > email address. Here is a reply i sent for the record.
>>> > > >
>>> > > > ---
>>> > > >
>>> > > > Thank you, Matthew.
>>> > > >
>>> > > > The following code takes around 250ms on my machine. Any idea why?
>>> I was
>>> > > expecting it to be fast since the module is based on racket/base.
>>> > > >
>>> > > > #lang racket/base
>>> > > >
>>> > > > (require syntax/location)
>>> > > > (require racket/place)
>>> > > >
>>> > > >
>>> > > >
>>> > > > (module test racket/base
>>> > > >  (provide place-main)
>>> > > > racket
>>> > > >  (define (place-main pch)
>>> > > >   (void)))
>>> > > >
>>> > > > (time (place-wait (dynamic-place (quote-module-path test)
>>> 'place-main)))
>>> > > >
>>> > > > Nate
>>> > > >
>>> > > >
>>> > > > On Tue, Nov 24, 2020 at 8:35 AM Nathaniel W Griswold
>>> > >  wrote:
>>> > > >>
>>> > > >> Thank you, Matthew.
>>> > > >>
>>> > > >> The following code takes around 250ms on my machine. Any idea
>>> why? I
>>> > > was expecting it to be fast since the module is based on racket/base.
>>> > >

Re: [racket-users] snappier place startup time

2020-11-24 Thread Robby Findler
DrRacket thinks that there are no references to a number of the requires in
racket/place, including racket/fixnum, racket/flonum, racket/vector, and
racket/runtime-path. Not sure if that's an error on DrRacket's part (and I
don't see why those would be needed for their effects).

Also, the only use of racket/match seems to be this, which seems simple to
rewrite out.

(match name
  [(? symbol?) `(submod (quote ,name) ,submod-name)]
  [(? path?) `(submod ,name ,submod-name)]
  [`(,p ,s ...) `(submod ,(if (symbol? p) `(quote ,p) p) ,@s
,submod-name)])

Robby


On Tue, Nov 24, 2020 at 8:58 AM Nate Griswold 
wrote:

> Oh, interesting. So compilation breaks the submodule out from the modules
> if possible?
>
> So anyway, it sounds like breaking my modules out into separate files will
> improve performance in most cases.
>
> Unfortunately, i need racket/place in the module that is my startup
> bottleneck. If i modify the previous program to require racket/place and
> compile, it takes around 180ms.
>
> This is about what i can expect for a module that requires racket/place,
> then?
>
> Nate
>
>
> On Tue, Nov 24, 2020 at 8:48 AM Matthew Flatt  wrote:
>
>> Just to elaborate a little more:
>>
>> The difference is because the `test` submodule can be loaded
>> independently from the compiled form. Loading the submodule from source
>> requires loading the enclosing module, too (which depends on
>> `racket/place` and more).
>>
>> At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote:
>> > Awesome, thanks!
>> >
>> > Nate
>> >
>> >
>> > On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt <
>> sa...@cs.indiana.edu>
>> > wrote:
>> >
>> > > Almost certainly the problem is expansion time. If I run that program
>> > > on my machine, it takes about 200 ms. But if I compile the file to zo
>> > > first with `raco make`, then it takes about 40 ms, basically identical
>> > > to `racket/base`.
>> > >
>> > > Sam
>> > >
>> > > On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold > >
>> > > wrote:
>> > > >
>> > > > Oops, i am having some issues with not getting to the list from my
>> other
>> > > email address. Here is a reply i sent for the record.
>> > > >
>> > > > ---
>> > > >
>> > > > Thank you, Matthew.
>> > > >
>> > > > The following code takes around 250ms on my machine. Any idea why?
>> I was
>> > > expecting it to be fast since the module is based on racket/base.
>> > > >
>> > > > #lang racket/base
>> > > >
>> > > > (require syntax/location)
>> > > > (require racket/place)
>> > > >
>> > > >
>> > > >
>> > > > (module test racket/base
>> > > >  (provide place-main)
>> > > > racket
>> > > >  (define (place-main pch)
>> > > >   (void)))
>> > > >
>> > > > (time (place-wait (dynamic-place (quote-module-path test)
>> 'place-main)))
>> > > >
>> > > > Nate
>> > > >
>> > > >
>> > > > On Tue, Nov 24, 2020 at 8:35 AM Nathaniel W Griswold
>> > >  wrote:
>> > > >>
>> > > >> Thank you, Matthew.
>> > > >>
>> > > >> The following code takes around 250ms on my machine. Any idea why?
>> I
>> > > was expecting it to be fast since the module is based on racket/base.
>> > > >>
>> > > >> #lang racket/base
>> > > >>
>> > > >> (require syntax/location)
>> > > >> (require racket/place)
>> > > >>
>> > > >>
>> > > >>
>> > > >> (module test racket/base
>> > > >>  (provide place-main)
>> > > >> racket
>> > > >>  (define (place-main pch)
>> > > >>   (void)))
>> > > >>
>> > > >> (time (place-wait (dynamic-place (quote-module-path test)
>> 'place-main)))
>> > > >>
>> > > >> Nate
>> > > >>
>> > > >> On Nov 24, 2020, at 8:16 AM, Matthew Flatt 
>> wrote:
>> > > >>
>> > > >> The bottleneck for place startup is loading modules into the new
>> place,
>> > > >> including modules like `racket/base`.
>> > > >>
>> > > >> For example,
>> > > >>
>> > > >>  (place-wait (dynamic-place 'racket 'void))
>> > > >>
>> > > >> takes around 200ms on my machine, while
>> > > >>
>> > > >>  (place-wait (dynamic-place 'racket/base 'void))
>> > > >>
>> > > >> takes around 30ms and
>> > > >>
>> > > >>  (place-wait (dynamic-place 'racket/kernel 'void))
>> > > >>
>> > > >> takes around 10ms.
>> > > >>
>> > > >> It sounds like you're already aware that the complexity of the
>> module
>> > > >> loaded into a place matters, though. Beyond using a minimal set of
>> > > >> modules, I don't have any way to make place startup faster.
>> > > >>
>> > > >> Matthew
>> > > >>
>> > > >> At Tue, 24 Nov 2020 05:04:19 -0600, Nate Griswold wrote:
>> > > >>
>> > > >> Is there any way to make places startup faster? Even if i do an
>> explicit
>> > > >> round trip using place-channel-put and place-channel-get on both
>> sides,
>> > > it
>> > > >> takes on the order of centiseconds for near empty places to start
>> up.
>> > > >>
>> > > >> My program requires the threads for a couple places to be set up
>> before
>> > > it
>> > > >> can operate, so this impacts my startup time by quite a bit.
>> > > >>
>> > > >> I have one place that has a very simple module and one place with
>> a more
>> > > >> 

Re: [racket-users] Messages going to spam?

2020-11-24 Thread Robby Findler
I might have approved one (and when I did I also marked the email address
is came from as always allowed to post so hopefully it won't happen again).

Robby


On Tue, Nov 24, 2020 at 9:16 AM Nate Griswold 
wrote:

> Thanks, Sam. That is what i wanted.
>
> Is there any way to allow all messages from that account from now on?
>
> Nate
>
>
> On Tue, Nov 24, 2020 at 9:08 AM Sam Tobin-Hochstadt 
> wrote:
>
>> Yes, those messages have been going to spam. I didn't approve them
>> separately since I just saw the notification and you had already
>> posted them with your gmail account.
>>
>> Sam
>>
>> On Tue, Nov 24, 2020 at 9:59 AM Nate Griswold 
>> wrote:
>> >
>> > No rush but can an admin for the list check if my messages from my
>> other email are being flagged suspicious? The other email is
>> nate@manicmind.earth. I don't want to use my gmail account.
>> >
>> > Sorry if there is a better place to ask this.
>> >
>> > Nate
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to racket-users+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/CAM-xLPoQ6uv_w%3Dtsz%3DD8uXfEhysfano9ZRBFo1CxNNtHN8zTrQ%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAM-xLPrBDaWoVsBU9TGELtrX0MCNYUf_ctwH1GHNEWMjE4aG-Q%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/CAL3TdOND3HwbpaeEJG_AEmauH_-hewhJ4mHt%3Dqm3VOM-x8ZqVw%40mail.gmail.com.


Re: [racket-users] F1 key for custom language

2020-11-17 Thread Robby Findler
Currently, F1 doesn't actually prioritize anything based on the content of
the window (well, except for the teaching languages which use a mechanism
that's has not worked out very well in practice). It does need to know
something about the syntax of your identifiers, bit it gets that from the
colorer that you can supply with your #lang.

Robby


On Tue, Nov 17, 2020 at 2:48 PM Dmitry Pavlov  wrote:

> Hello,
>
> When I press F1 in DrRacket, I get a nice new browser tab with search
> results from ~/.racket//doc/ directory.
>
> I would like to have a thing like this for my custom non-sexp language.
> So I am going to write some Scribble, and then... will it be
> automatically searchable after I install my Scribble docs via raco, or
> should I override something DrRacket-specific in my language
> definitions?
>
> How can I prioritize the search results so that when F1 is pressed in a
> #lang mylang file, the non-mylang search results are shown second, or
> are not shown at all?
>
> Best regards,
>
> Dmitry
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/2385c6bb229c761fe5b510da0b5859ea%40iaaras.ru
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOH-hDZBF4kDXHdwRZM7XpNAwEVTAzTDSsJ_hQ7teYj8A%40mail.gmail.com.


Re: [racket-users] Spell checking in DrRacket for Windows

2020-11-15 Thread Robby Findler
Two thoughts: after installing ispell, did they restart DrRacket? In their
shell, when they install ispell, what path is located at? (The second
question is because the normal way one starts up DrRacket, it does not
inherit the PATH settings that one gets in the Terminal window, so DrRacket
has to have a list of likely places to look and it may be missing one or
two or a dozen for all I know. :)

Robby



On Sun, Nov 15, 2020 at 9:57 AM Rebelsky, Samuel 
wrote:

> Dear Racket Community,
>
> One of my students is running DrRacket on Windows and getting a strange
> error message when they try to use the spell checker.  They report "It says
> something about needing ispell or aspell.  But when I install aspell, it
> still doesn't work."
>
> I'm on a Mac and don't encounter the same roblems.  And I'll admit that I
> don't use Windows.  Does anyone have a recommendation on how to solve this
> problem?  My quick Web search didn't reveal anything.  (The student didn't
> like my suggestion that they install Linux on their computer and use the
> DrRacket on Linux.)
>
> Thanks!
>
> -- SamR
>
> Samuel A. Rebelsky - He/Him/His (
> http://www.cs.grinnell.edu/~rebelsky/pronouns.html)
> Professor and Chair of CS, Grinnell College
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/72615CF2-03D3-4F4F-96EC-FAD58A18A5FF%40grinnell.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONaNcW--GeE6nP1NPVm%2BKdvKZcgS4FCecRPPR3sDc%2B7Bw%40mail.gmail.com.


Re: [racket-users] After installing new racket version it seems that I need to find and delete all 'compiled' dirs...

2020-11-01 Thread Robby Findler
On Sun, Nov 1, 2020 at 4:12 PM George Neuner  wrote:

>
> On 11/1/2020 4:45 PM, Robby Findler wrote:
> > It is true that running just "racket x.rkt" will not notice some
> > situations where your .zo files are wrong and thus lead to the bad
> > behavior George describes below but I find it quite handy to use .zo
> > files during development, as they can speed things up considerably
> > depending on what's happening in your application. If you are working
> > at the command line and using something like "racket x.rkt" to run
> > your program, then changing to "raco make x.rkt && racket x.rkt" will
> > keep your .zo files all sync'd up.
>
> Dunno ... too many times debugging in DrRacket I've run into situations
> where having .zo files screwed up tracing calls across modules in
> different source files.
>

I'm not sure it would affect tracing but there definitely is a bug in
DrRacket where it manages the .zo files for you, but in certain situations
it will screw them up :( That's a problem I've long had on my list.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOFY82utjdRwAKrrQr-ri_ztvhbbrjO2LkG9vUb25mmPw%40mail.gmail.com.


Re: [racket-users] After installing new racket version it seems that I need to find and delete all 'compiled' dirs...

2020-11-01 Thread Robby Findler
It is true that running just "racket x.rkt" will not notice some situations
where your .zo files are wrong and thus lead to the bad behavior George
describes below but I find it quite handy to use .zo files during
development, as they can speed things up considerably depending on what's
happening in your application. If you are working at the command line and
using something like "racket x.rkt" to run your program, then changing to
"raco make x.rkt && racket x.rkt" will keep your .zo files all sync'd up.

Robby


On Sun, Nov 1, 2020 at 3:27 PM George Neuner  wrote:

>
> On 11/1/2020 11:34 AM, infodeveloperdon wrote:
> > so that when I run Racket it recreates the 'compiled' directories
> > using the latest compiler.
> > Or is there a better way?
>
> Yeah ... don't use 'compiled' directories for development - they can get
> out of sync and screw up your debugging.
>
> They really are only useful for performance testing or for deployment in
> situations where you don't want to (or can't) build a single executable.
>
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/b83b03b4-f2a8-2b6c-7ac8-00caa1e6d104%40comcast.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOPf70L21NT%2Bn4%2B62OHYQtRXJA1wP%2BTVE-HzjenjQsS1Tw%40mail.gmail.com.


Re: [racket-users] Should I be posting questions about Racket in us...@racket-lang.org?

2020-10-31 Thread Robby Findler
Yes.

On Sat, Oct 31, 2020 at 9:36 AM Don Green 
wrote:

> Should I be posting questions about Racket in us...@racket-lang.org?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CANeurs%2BSLZLDXDpK_OsePowNuT%3DAQycJPnqLG_K-qFfZ8Gaw%3DA%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/CAL3TdOMHK-Tb7EGYmYUYyMPVSYR4geKfuchpGfq5xb5yB7CFCw%40mail.gmail.com.


Re: [racket-users] Re: large hash/dc errors (was: Contracts for (partially) specifying dictionary key -> value-predicates)

2020-10-31 Thread Robby Findler
I'm still thinking about Ben's example but I'm seeing the description right
at the top in the examples below. What am I missing?

Robby

#lang racket

(module m racket
  (provide
   (contract-out
[f (->i ([x integer?])
#:pre/desc (x)
(or (> x 5)
"must be larger than 5")
#:pre/desc (x)
(or (even? x)
"must be even")
any)]))
  (define (f x) x))

(require 'm)

(display
 (exn-message
  (with-handlers ([values values])
(f 1

(newline)
(newline)

(display
 (exn-message
  (with-handlers ([values values])
(f 7



On Sat, Oct 31, 2020 at 5:53 AM jackh...@gmail.com 
wrote:

> I have the same issue for ->i contracts. I'll write multiple #:pre/desc
> checks with nice messages, which are promptly rendered useless by the fact
> that ->i prints out the whole contract instead of just the precondition
> check that failed.
> On Friday, October 30, 2020 at 7:16:59 PM UTC-7 Ben Greenman wrote:
>
>> > Ben: if you have an example of the bad hash/dc error message I'd be
>> > interested to see it.
>> >
>> > Robby
>>
>> Here's the kind of message that turned me off:
>>
>> ```
>> ctc.rkt:34:0: broke its own contract
>> promised: (hash/dc (k (or/c (quote a) (quote b) (quote c))) (v (k)
>> (config-value/c k)) #:immutable #t #:kind (quote flat))
>> produced: '#hash((a . 1) (b . #t) (c . #))
>> in: (hash/dc
>> (k (or/c 'a 'b 'c))
>> (v (k) (config-value/c k))
>> #:immutable
>> #t
>> #:kind
>> 'flat)
>> contract from: +
>> blaming: +
>> (assuming the contract is correct)
>> ```
>>
>> It prints the whole hash and contract, leaving me to figure out the
>> two key parts: (1) what piece of the hash failed, and (2) what the
>> contract expected for that piece.
>>
>> Now that I think of it ->* is bad in the same way --- especially for
>> `plot` functions.
>>
>>
>> Here's the code that made that error message. The #;(lambda )
>> comment is the contract that I ended up using instead of hash/dc (it
>> still doesn't explain bad values well).
>>
>> ```
>> #lang racket/base
>>
>> (require racket/contract)
>>
>> (provide config/c)
>>
>> (define config-key/c
>> (or/c 'a 'b 'c))
>>
>> (define (config-value/c k)
>> (case k
>> ((a)
>> string?)
>> ((b)
>> boolean?)
>> ((c)
>> void?)))
>>
>> (define config/c
>> #;(lambda (h)
>> (for ((k (in-list (list 'a 'b 'c
>> (unless (hash-has-key? h k)
>> (raise-arguments-error 'config/c "missing key" "key" k "hash" h))
>> (define v (hash-ref h k))
>> (unless ((config-value/c k) v)
>> (raise-arguments-error 'config/c "bad value for key" "key" k
>> "value" v "hash" h))
>> (void)))
>> (hash/dc
>> [k config-key/c]
>> [v (k) (config-value/c k)]
>> #:immutable #true
>> #:kind 'flat))
>>
>> (contract
>> config/c
>> (hash 'a 1 'b #true 'c (void))
>> '+
>> '-)
>> ```
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/3b0ed32b-4875-4cfa-9b2b-e4398e4318d1n%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/CAL3TdOPW48XF3Q7UvMaCDF73FMXPonOBRWMbvyHZdqXSdkr_0w%40mail.gmail.com.


Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates

2020-10-30 Thread Robby Findler
On Fri, Oct 30, 2020 at 2:08 PM William J. Bowman 
wrote:

> Let me aid this discussion by copying in the ~10 lintes of code in
> question:
>
> > (define-syntax (dictof syn)
> >   (syntax-parse syn
> > [(_ (k:id pred?) ...)
> >  (quasisyntax/loc syn
> >(dictof/proc `((k . ,pred?) ...)))]))
> >
> > (define ((dictof/proc spec) h)
> >   (and (eq? (dict-keys h) (dict-keys spec))
> >(for/and ([(k pred?) (in-dict spec)])
> >  (pred? (dict-ref h k)
>
> The macro is merely a syntactic transformation to 1 line of code that
> implements
> the functionality of the contract at run-time.
> Is there some reason to avoid macros in this particular case?
>
>
I don't think so.

But I do think that you'd need more checking so things like (dictof
(,(something scary) i-am-not-a-procedure)) give reasonable error messages.
And eq? is probably not the right comparison (consider large integers for
example).

Robby


> --
> William J. Bowman
>
> On Fri, Oct 30, 2020 at 03:04:04PM -0400, George Neuner wrote:
> >
> > On 10/30/2020 1:14 PM, William J. Bowman wrote:
> > > Thanks! One follow-up:
> > >
> > > > 1. make these functions, not macros
> > > The main implementation is a procedure, but I think I need a macro to
> get the
> > > syntactic interface I want.
> > >
> > > Is there some reason to avoid macros?
> >
> > You certainly can use macros in the implementation, but just remember
> that
> > macros evaluate at compile time and most contracts have to be checked at
> > runtime: so a contract can't *exclusively* be a macro ... runtime code
> has
> > to be generated.
> >
> > Robby's comment about code size is relevant also:  contracts are not
> debug
> > mode only like assertions in C ... Racket's contracts live on in release
> > mode compiles, so you want to minimize the amount of runtime code
> required
> > to implement them.
> >
> > George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20201030190826.GA1988871%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/CAL3TdOOOcb0MnmWnj7bWP5SwnDzGr0zCTdcs_5hRWutGmHpF0Q%40mail.gmail.com.


Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates

2020-10-30 Thread Robby Findler
I didn't look at the code yet myself, but generally you want to minimize
the amount of code you compile into (and so using a function is pretty
minimal). Another reason is that a lot of stuff "just works" when you use
functions (because they would be documented as functions and so come with
certain expectations). Debugging stuff, other little details.

But in the case of the contract system you might want macros because that
way you can cooperate with the check syntax blame annotations (which need
work in other parts of the contract library).

Ben: if you have an example of the bad hash/dc error message I'd be
interested to see it.

Robby


On Fri, Oct 30, 2020 at 12:14 PM William J. Bowman 
wrote:

> Thanks! One follow-up:
>
> > 1. make these functions, not macros
> The main implementation is a procedure, but I think I need a macro to get
> the
> syntactic interface I want.
>
> Is there some reason to avoid macros?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20201030171407.GP1611044%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/CAL3TdOOGgigtq%2BP_fr5tmFf9M%3DvOKN64v-e3QBy3Enb5q%2BCkYw%40mail.gmail.com.


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

2020-10-26 Thread Robby Findler
v is for "value" I believe.

Robby

On Mon, Oct 26, 2020 at 8:01 PM Sam Tobin-Hochstadt 
wrote:

> That page actually suggests they're inherited from Common Lisp, which
> seems very likely (and probably from some other Lisp before that).
>
> Sam
>
> On Mon, Oct 26, 2020 at 8:59 PM Sorawee Porncharoenwase
>  wrote:
> >
> > I had this question too. It looks like they are inherited from Scheme.
> >
> > ~a = any
> > ~s = s-expression
> >
> > See http://wiki.call-cc.org/eggref/5/format#documentation.
> >
> > There's no ~v. IIUC, there's no `print` in Scheme.
> >
> > On Mon, Oct 26, 2020 at 5:50 PM primer  wrote:
> >>
> >>
> >> I'm reading the documentation about formatted output where it says:
> >> ~a or ~A displays the next argument
> >> ~s or ~S writes the next argument
> >> ~v or ~V prints the next argument
> >>
> >> I can't help thinking these would be more intuitive if they were
> spelled ~d, ~w, and ~p.
> >>
> >> Perhaps I can remember them better if someone could explain where the
> letters come from.  Can anyone explain?
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/979731d3-0a48-484c-8269-f10a807fe6aan%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CADcuegvoXQCZDCJhwZa9rfvJrfWWw6OfvMy9atpvpx2vggnJDA%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BZ-bHkLApiKSKmSH_4gEDBKM-Oe6eTe2wh8Vm2%2Bc8SRZw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMvFxgx0R9urZ7vW1yONS6k_b2ybJ584DbfTKzDzmYMKg%40mail.gmail.com.


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

2020-10-22 Thread Robby Findler
Sam has started an issue to keep track of everything:
https://github.com/racket/racket/issues/3457

On Tue, Oct 20, 2020 at 10:46 PM Robby Findler 
wrote:

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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOkpSxPF4h5V1MdWpxFFWP287APBvY73n-hjGadXGyL1g%40mail.gmail.com.


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

2020-10-20 Thread Robby Findler
The NWU snapshots are (mostly) working again and we've gotten a pkg-build
using the CS build to go through. The results are here:

  https://plt.eecs.northwestern.edu/pkg-build/

Some pkgs are newly failing their tests (or other problems) because they're
now running on CS.

Robby


On Tue, Sep 29, 2020 at 2:33 PM Robby Findler 
wrote:

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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMC5ua5YxF7YXo2RheQhuTfYy2MgFBQBQbxkFpgwfuo%3Dw%40mail.gmail.com.


Re: [racket-users] Re: curly-fn language syntax not recognized in the repl

2020-10-20 Thread Robby Findler
I don't remember. :(

On Tue, Oct 20, 2020 at 9:13 AM Greg Hendershott 
wrote:

> It looks like this works neither in Dr Racket nor Racket Mode's REPLs.
>
> From a hasty, shallow look, it seems that the curly-fn package <
> https://docs.racket-lang.org/curly-fn/index.html> uses a convention or
> protocol defined by the namespaced-transformer package <
> https://docs.racket-lang.org/namespaced-transformer/index.html>.
>
> As a quick experimental hack, if I namespace-require the
> namespaced-transformer module before entering read-eval-print-loop -- so
> that the #%namespaced syntax transformer is defined -- then this does work
> in Racket Mode's REPL.
>
> So I could... just add that. But I don't know the history of this. Is this
> a convention that Alexis proposed be adopted by Dr Racket? If so, was it
> not adopted simply due to lack of time, or, for technical reasons like
> gotchas or some other ideas about how to approach this?
>
> Maybe someone like Alexis or Robby remembers?
>
> On Monday, October 19, 2020 at 10:38:57 AM UTC-4, primer wrote:
>>
>> If I run this program:
>>
>> #lang curly-fn racket
>> (map #{/ 1}  '(1 2 3))
>>
>> I get the expected result in the repl.  But in the repl after the run, if
>> I type:
>> (map #{/ 1}  '(1 2 3))
>>
>> I get an error:
>> #%namespaced: undefined;
>>  cannot reference an identifier before its definition
>>
>> Is there a way to make this work in the repl?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/cbc697a3-9e82-4a4b-8f6b-6e93b6ed14dco%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/CAL3TdOMuG%3DZc%3DNfP-Bi0qBN_beFWhAMe-bdv%2B2ZQWYHXNKRnHw%40mail.gmail.com.


Re: [racket-users] How hard is it to add @-exp support to racket:text%?

2020-10-15 Thread Robby Findler
If the buffer contains #"lang scribble/base" at the start, then it should
"just work", no?

Robby

On Thu, Oct 15, 2020 at 8:19 AM Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

> This isn't super high priority... but Morgan and I are working on the
> first mini virtual worlds demo for Spritely, and I've put the extremely
> nice racket:text% to use for code editing:
>
>   https://dustycloud.org/gfx/goodies/fairy-forest-ui-mockup2.png
>
> Since there's so much text, it would be even better if I could enable
> at-exp support.  It doesn't look like the defaults for the racket:text%
> editor support it nicely though.
>
> Just out of curiousity, has anyone already done the work of figuring out
> how to add such functionality to make the scribble-style at-exp
> highlighting/indentation/etc look nice with racket:text%?  If not I can
> just put this off and not provide that feature, but it would be nicer
> with it I think.
>
>  - Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/875z7b4oi3.fsf%40dustycloud.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOO_KX5UuceaW6akox8kW_21yxdTfpw84A2TU4Gb%2BBKa%3Dg%40mail.gmail.com.


Re: [racket-users] #:kind (list ... ) in defthing and defproc

2020-10-07 Thread Robby Findler
Ah, sorry! I missed that `content?` was okay. Thanks, Matthew!

Robby


On Wed, Oct 7, 2020 at 8:40 AM Matthew Flatt  wrote:

> A recent commit added a contract on `defthing` and `defproc` to enforce
> the documented constraint that `#:kind` should be a string. But the
> implementation is happy with content in the sense of `content?`.
>
> Since it's easy to adjust the contract and documentation to restore
> this capability, I'll do that, and then this example works again.
>
> Matthew
>
> At Sat, 26 Sep 2020 21:06:20 +0200, Jos Koot wrote:
> > The following works well in DrRacket, version 7.8 [3m]
> >
> > #lang scribble/manual
> > @deftogether[
> > (@defthing[#:kind "constant false/on/high" F trit? #:value '0]
> >  @defthing[#:kind (list "constant true/off/low" (hspace 1)) T trit?
> #:value
> > '1]
> >  @defthing[#:kind "constant indeterminate" ? trit? #:value '?]
> >  @defthing[#:kind (list "constant" (hspace 13)) trits (list/c trit? trit?
> > trit?) #:value (list F T ?)]
> >  @defthing[#:kind (list "constant" (hspace 13)) in-trits sequence?
> #:value
> > (in-list trits)]
> >  @defproc[#:kind (list "predicate" (hspace 12)) (trit? (obj any/c))
> > boolean?]
> >  @defproc[#:kind (list "predicate" (hspace 12)) (F? (obj any/c))
> boolean?]
> >  @defproc[#:kind (list "predicate" (hspace 12)) (T? (obj any/c))
> boolean?]
> >  @defproc[#:kind (list "predicate" (hspace 12)) (?? (obj any/c))
> > boolean?])]{}
> >
> > I use hspace for alignment of the kinds.
> >
> > But in version 7.8.0.10--2020-09-25(515012525c/a) [3m] I get:
> >
> > . . C:\Program Files\Racket-7.8.0.10\collects\syntax\contract.rkt:101:21:
> > defthing: contract violation
> >   expected: (or/c string? #f)
> >   given: ("constant true/off/low" #(struct:element hspace (" ")))
> >   in: (or/c string? #f)
> >   macro argument contract on #:kind argument
> >   contract from:
> >   (lib scribble/private/manual-proc.rkt)
> >   blaming: E:\circuits\circuit-manual.scrbl
> >(assuming the contract is correct)
> >   at: E:\circuits\circuit-manual.scrbl:416.18
> >
> > Because I don't know whether or not this is a known issue, I post it on
> > this list.
> > If this is a known issue or an intentional change, then ignore this
> email,
> > please.
> > If not I can post it as a racket issue.
> > Let me know, please.
> > 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/CAL6KNi3P251G%2BBMQqDbo2qt6K22Gw
> > _OOgjjnHDboLLuC3qKrGg%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/20201007074018.1a7%40sirmail.smtps.cs.utah.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONrEQoOmJaQqTyftX_QONjhp5TK-RnSzN9%3Dqx1K9uhrxQ%40mail.gmail.com.


Re: [racket-users] Differences running HtDP programs from DrRacket IDE vs racket command line

2020-10-06 Thread Robby Findler
Great! No guarantee, but probably this is the right repo:
https://github.com/racket/htdp/issues

Robby


On Tue, Oct 6, 2020 at 9:04 AM Nick Lee  wrote:

> Thanks again Robby! I will create issues on the drracket github issues
> page.
>
> On Tuesday, October 6, 2020 at 9:23:49 AM UTC-4 Robby Findler wrote:
>
>> On Tue, Oct 6, 2020 at 1:50 AM Nick Lee  wrote:
>>
>>> Thank you very much Robby for the quick reply! I should have mentioned
>>> that our students are using Beginning Student by setting the Language to
>>> that, rather than adding #lang htdp/bsl.
>>>
>>
>> Right, I got that. I merely meant to say that those are likely to be the
>> same bug.
>>
>>
>>> It appears this makes a difference. So the whole file looks like:
>>>
>>> ;; The first three lines of this file were inserted by DrRacket. They
>>> record metadata
>>> ;; about the language level of this file in a form that our tools can
>>> easily process.
>>> #reader(lib "htdp-beginner-reader.ss" "lang")((modname file)
>>> (read-case-sensitive #t) (teachpacks ()) (htdp-settings #(#t constructor
>>> repeating-decimal #f #t none #f () #f)))
>>> (define (quasiquote x) x)
>>> (define (f x) 123)
>>> `(f 888)
>>>
>>> Running this file in command line with "racket file.rkt" doesn't show
>>> any errors for me. I'm using DrRacket 7.8 if it matters.
>>>
>>>
>> Ah, oops. I had mistakenly tested with BSL+. I see this error too, now.
>>
>> Robby
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/f86ec3c9-e0c3-4616-b242-cc419ef33059n%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/f86ec3c9-e0c3-4616-b242-cc419ef33059n%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/CAL3TdONTR%2Bd-8RsVHWbRaMZ%3DLjDktVsuriOuxXd1CA12soKTUg%40mail.gmail.com.


Re: [racket-users] Differences running HtDP programs from DrRacket IDE vs racket command line

2020-10-06 Thread Robby Findler
On Tue, Oct 6, 2020 at 1:50 AM Nick Lee  wrote:

> Thank you very much Robby for the quick reply! I should have mentioned
> that our students are using Beginning Student by setting the Language to
> that, rather than adding #lang htdp/bsl.
>

Right, I got that. I merely meant to say that those are likely to be the
same bug.


> It appears this makes a difference. So the whole file looks like:
>
> ;; The first three lines of this file were inserted by DrRacket. They
> record metadata
> ;; about the language level of this file in a form that our tools can
> easily process.
> #reader(lib "htdp-beginner-reader.ss" "lang")((modname file)
> (read-case-sensitive #t) (teachpacks ()) (htdp-settings #(#t constructor
> repeating-decimal #f #t none #f () #f)))
> (define (quasiquote x) x)
> (define (f x) 123)
> `(f 888)
>
> Running this file in command line with "racket file.rkt" doesn't show any
> errors for me. I'm using DrRacket 7.8 if it matters.
>
>
Ah, oops. I had mistakenly tested with BSL+. I see this error too, now.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOYXWE_FMyzcEdwEG%3DpcRjAEzSuq%2B7X%2BMCwoUSmEcDxEA%40mail.gmail.com.


Re: [racket-users] Differences running HtDP programs from DrRacket IDE vs racket command line

2020-10-05 Thread Robby Findler
On Mon, Oct 5, 2020 at 4:32 PM Nick Lee  wrote:

>
> Hello,
> I noticed there are differences when I run HtDP programs in DrRacket IDE
> vs the "racket" command line.
>
> For example, the following program's test passes in DrRacket IDE:
>
> ;; file.rkt - Set to Beginning Student
> (check-expect (exact? (string->number "1.0")) true)
>
> But when I run "raco test file.rkt", the test fails.
>
>
This looks like a bug to me. Probably related is that this program prints
#false and not #true.

#lang htdp/bsl
(exact? (string->number "1.0"))


> As another example, the follow Beginning Student program generates an
> error when run in DrRacket IDE (the error being read-syntax: illegal use of
> ```):
>
> ;; file.rkt - Set to Beginning Student
> (define (quasiquote x) x)
> (define (f x) 123)
> `(f 888)
>
> But when I run "racket file.rkt", no error is generated, and 123 is
> printed.
>
>
This one behaves the same for me. It says "quasiquote: this name was
defined in the language or a required library and cannot be re-defined".



> Is there a way I can run HtDP programs from the command-line and get
> behavior that's the same as when I click "Run" button in the IDE?
>
>
This is supposed to work. Sorry for the bugs!

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOP7rCUuDTUCtd5iF%3D3-eci3CSvggo47xEcu1V-B0bbRnw%40mail.gmail.com.


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

2020-09-29 Thread Robby Findler
The Northwestern natipkg build will be changed to be a CS build so I
believe that means that the pkg builds will now running on top of CS (and
otherwise unchanged).

Robby


On Tue, Sep 29, 2020 at 2:41 PM Sam Tobin-Hochstadt 
wrote:

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

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

2020-09-29 Thread Robby Findler
I'm finally catching up and switching the Northwestern snapshots to BC by
default. I've made the change and the changes will kick off tonight at
midnight, Chicago time (probably failing horribly but maybe in a week or
two we'll be back in business and the next paragraph will be accurate when
that all settles).

All of the existing links should continue to work (let me know if you
notice that didn't happen) but they will generally be CS where they were BC
builds before. In particular, we're going to continue to have windows BC
and CS, 64 and 32 bit builds; 64 bit BC and CS Mac OS builds, and 32 bit BC
Mac OS builds. I've added Debian 64 bit CS builds, so we'll have 64 bit BC
and CS as well as 32 bit BC builds for debian. For the rest, the 64 bit
versions will all become CS builds and the 32 bit versions will all stay
BC.

There will be explicit links ending with -bc and -cs as well as aliases
that do not include the VM specifier that go to whatever is available, as
Matthew describes for the Utah snapshots and "min-racket" will also change
to "racket-minimal" (but still with an alias to avoid breaking old links).

Robby


On Tue, Aug 11, 2020 at 5:24 PM Matthew Flatt  wrote:

> As you may know, the Racket Git repo recently switched to Racket CS as
> the default build. That is, if you check out the repo and `make`, then
> you get an in-place Racket CS build instead of Racket BC.
>
> The next step in moving toward Racket CS is to try switching the
> snapshot builds. Out current plan is to switch the Utah build on August
> 13. The Northwestern snapshot build will be unchanged, for now. This
> change will have no effect on the regular, release downloads.
>
> The layout of the page at
>
>  https://www.cs.utah.edu/plt/snapshots/
>
> will change so that CS and BC builds are grouped together, more like
> the Northwestern snapshot layout, but an installer that doesn't have
> "BC" in its link will download a Racket CS installer.
>
> If you have an automated process that pulls from the snapshot site,
> then it probably downloads something like
>
>
> https://www.cs.utah.edu/plt/snapshots/current/installers/racket-current-x86_64-linux-precise.sh
>
> As of August 13, that will download a Racket CS installer instead of a
> BC installer, because there's no "-bc" suffix in the name.
>
> Racket BC builds will still be available; you'll just have to
> specifically select a download option with "BC" in the link name or
> "-bc" in the URL. For example,
>
>
> https://www.cs.utah.edu/plt/snapshots/current/installers/racket-current-x86_64-linux-precise-bc.sh
>
> will download a Racket BC installer. For now, 32-bit Windows and Mac OS
> installers will be available only for BC, because we view those as
> legacy platforms.
>
> For consistently, you'll be able to access the CS installers using a
> "-cs" suffix. The installer name without a "-cs" or "-bc" suffix is an
> aliases for one with "-cs". Of course, the "current" names are all
> aliases for installers that have a specific version number.
>
> While we're adjusting installer names, the canonical name for Minimal
> Racket installers will change to "racket-minimal-..." instead of
> "min-racket-...". The new name matches the names used for releases. For
> the foreseeable future, "min-racket-..." aliases will still work, but
> you should migrate to "racket-minimal-..." if you have an automated
> process that uses "min-racket-...".
>
>
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20200811162420.18d%40sirmail.smtps.cs.utah.edu
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOw%2BBkMj%2B-vN_mfbe%2Bt2MMuwuVtpyQDJyeOUoyjOWkHpA%40mail.gmail.com.


Re: [racket-users] Trouble opening File

2020-09-26 Thread Robby Findler
I recommend going to the Racket website and following the download link.

https://racket-lang.org/

Robby

On Sat, Sep 26, 2020 at 1:29 AM Paul Kneeland 
wrote:

> How do you update Raxket?
>
> Sent from my iPhone
>
> On Sep 25, 2020, at 5:58 PM, Robby Findler 
> wrote:
>
> 
>
> This may be bad advice. Make sure you and your partner are both using the
> same version of Racket!
>
> Robby
>
>
> On Fri, Sep 25, 2020 at 4:53 PM Robby Findler 
> wrote:
>
>> That sounds like the file was in the wxme format (i.e. it probably had
>> images in it) and then something got garbled in the file.
>>
>> If your partner can still open it fine, then probably the simplest thing
>> is for them to compress it and send you the compressed file (e.g. nowadays
>> you can usually right click on a file and select "compress" and you'll get
>> a .zip file out). As them to send the zip file and then see if you can
>> uncompress and then open it.
>>
>> Robby
>>
>>
>> On Fri, Sep 25, 2020 at 4:38 PM Paul Kneeland 
>> wrote:
>>
>>> Hello all,
>>>
>>> My partner sent me a racket file to look at (homework)
>>>
>>> When I download the file and go to open it, I get this message:
>>> There was an error loading  - FUNDIES HW2 Final.rkt.
>>>
>>> *insert-file in text%: error loading the file
>>> (read-editor-global-head-failed)*
>>>
>>> Why did this happen and how can I fix this? Any advice appreciated.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>>
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>>
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/f53303ca-4dde-4b4f-9f25-7b93745a825en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/f53303ca-4dde-4b4f-9f25-7b93745a825en%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/CAL3TdONABzBjCAA3sX-ZMP4ydq8iRRrMrYHwBdzTDcz761mqrQ%40mail.gmail.com.


Re: [racket-users] Trouble opening File

2020-09-25 Thread Robby Findler
This may be bad advice. Make sure you and your partner are both using the
same version of Racket!

Robby


On Fri, Sep 25, 2020 at 4:53 PM Robby Findler 
wrote:

> That sounds like the file was in the wxme format (i.e. it probably had
> images in it) and then something got garbled in the file.
>
> If your partner can still open it fine, then probably the simplest thing
> is for them to compress it and send you the compressed file (e.g. nowadays
> you can usually right click on a file and select "compress" and you'll get
> a .zip file out). As them to send the zip file and then see if you can
> uncompress and then open it.
>
> Robby
>
>
> On Fri, Sep 25, 2020 at 4:38 PM Paul Kneeland 
> wrote:
>
>> Hello all,
>>
>> My partner sent me a racket file to look at (homework)
>>
>> When I download the file and go to open it, I get this message:
>> There was an error loading  - FUNDIES HW2 Final.rkt.
>>
>> *insert-file in text%: error loading the file
>> (read-editor-global-head-failed)*
>>
>> Why did this happen and how can I fix this? Any advice appreciated.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/f53303ca-4dde-4b4f-9f25-7b93745a825en%40googlegroups.com
>> <https://groups.google.com/d/msgid/racket-users/f53303ca-4dde-4b4f-9f25-7b93745a825en%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/CAL3TdOMOK098LMUrPZfGJb-k5Bas7YbbBRQLMHpq%2BwWWjQ%2Ba-A%40mail.gmail.com.


Re: [racket-users] Trouble opening File

2020-09-25 Thread Robby Findler
That sounds like the file was in the wxme format (i.e. it probably had
images in it) and then something got garbled in the file.

If your partner can still open it fine, then probably the simplest thing is
for them to compress it and send you the compressed file (e.g. nowadays you
can usually right click on a file and select "compress" and you'll get a
.zip file out). As them to send the zip file and then see if you can
uncompress and then open it.

Robby


On Fri, Sep 25, 2020 at 4:38 PM Paul Kneeland 
wrote:

> Hello all,
>
> My partner sent me a racket file to look at (homework)
>
> When I download the file and go to open it, I get this message:
> There was an error loading  - FUNDIES HW2 Final.rkt.
>
> *insert-file in text%: error loading the file
> (read-editor-global-head-failed)*
>
> Why did this happen and how can I fix this? Any advice appreciated.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/f53303ca-4dde-4b4f-9f25-7b93745a825en%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/CAL3TdOOOGuwr2HaRTufyr%2BpzFUfdMX8rVGRo8zH8efME-dY7Gg%40mail.gmail.com.


Re: [racket-users] strange error message with debugging enabled

2020-09-25 Thread Robby Findler
Thanks, Jos. I think that this has been fixed (recently, since 7.8 was
released). You might try a snapshot build and see if things are better for
you there:

https://snapshot.racket-lang.org/

Robby


On Fri, Sep 25, 2020 at 9:57 AM Jos Koot  wrote:

> file b.rkt
> #lang racket
> (require "a.rkt")
> (err 5)
>
> file a.rkt
> #lang racket
> (require "a.rkt")
> (err 5)
>
> Run file b.rkt from DrRacket.
> Normal error message when debugging on file b.rkt is not enabled.
> With debugging enabled:
> -- #(struct:exn:fail:contract "vector-ref: contract violation\n  expected:
> vector?\n  given: ((error 'err \"blah blah ~s\" x)
> # 3 16 44 29)\n  argument position:
> 1st\n  other arguments...:\n   0" #)
> exception raised by error display handler: vector-ref: contract violation
>   expected: vector?
>   given: ((error 'err "blah blah ~s" x) #
> 3 16 44 29)
>   argument position: 1st
>   other arguments...:
>0; original exception raised: err: blah blah 5
>
> Maybe this has already been posted as a racket issue.
> Therefore I post this here.
> If not yet an issue, I'll post a racket issue.
> 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/CAL6KNi0-QB%2BZYkq3U%2B-z%3D_Fip9CpP7rZaq%2B2kiT1L5EfNbpgyg%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/CAL3TdONkpvt2kgiKDCkf2OtPd9c-T1gUoGyLV%2BTC79gc_-4DLA%40mail.gmail.com.


Re: [racket-users] [relation-rules] found the same binder

2020-09-23 Thread Robby Findler
I'm not sure exactly what you're trying to accomplish so take this with a
grain of salt, but that error message means that redex doesn't really know
how to interpret your rules. Here's a simpler example that has the same
error message.

  (reduction-relation
   L
   (--> (+ (+ n ...) n)
5))

In this case you might be intending to say that all of the "n"s inside the
inner plus should be the same and should also be the same as the one in
outer plus.

Redex's pattern matcher isn't smart enough to do that for you, so you'd
need to write something explicitly that makes sure you get what you want,
running example below.

Maybe in your actual code you can use a similar idea. I would also say that
your patterns look huge so it is probably in your interest to introduce
something to break things down into simpler pieces somehow and
judgment-forms are one tool to help with that.

hth,
Robby


#lang racket
(require redex)

(define-language L
  (e ::= (+ e ...) n)
  (n ::= natural))

(define red
  (reduction-relation
   L
   (--> (+ (+ n_2 ...) n_1)
5
(judgment-holds (matching n_1 (n_2 ...)))
)))

(define-judgment-form L
  #:mode (matching I I)
  #:contract (matching n (n ...))

  [---
   (matching n ())]

  [(matching n_1 (n_2 ...))
   
   (matching n_1 (n_1 n_2 ...))])


(test--> red
 (term (+ (+ 1 1 1 1) 1))
 5)


On Tue, Sep 22, 2020 at 12:18 PM Beatriz Moreira 
wrote:

> Hello,
> I have a bunch of relation rules, but in one of them i need to check if
> f_0 is the same as i have in one of the environments, but the error  
> *reduction-relation:
> found the same binder, f_0, at different depths, 0 and 1 ... F_01 ... (T
> f_0 ((T_00 x_00) ...) (return e)) F_02 ...)) (contract C_2 ((T_2 x_21) ...
> K_2 F_2... *appears and i would like to know if there's an alternative.
>
> The part of the code where the error is is below and the link for the
> repository is this :
> https://bitbucket.org/beatrizmoreira/msc/src/master/fwsollast.rkt
>
> Thank you!
>
>
> (--> [(in-hole E (c -> f -> value (n) ((s : (c_0 -> f_0)) ...))) env-ß
> env-σ ((contract C_1 {(T_1 x_11) ... K_1 F_1 ...}) ... (contract C {(T_0
> x_01) ... K F_01 ... (T f_0 ((T_00 x_00) ... ) {return e}) F_02 ...})
> (contract C_2 {(T_2 x_21) ... K_2 F_2 ...}) ...)]
> [(in-hole E (return (call env-ß CT c
>   (top-σ env-σ) f n ((s : (c_0 -> f_0))
> ... (decl (uptbal (uptbal env-ß (ref env-ß c) n) (top-σ env-σ) ,(-
> (term 0)(term n))) ((s -> (c_0 -> f_0)) ...)) (call-σ env-σ (ref env-ß c))
> ((contract C_1 {(T_1 x_11) ... K_1 F_1 ...}) ... (contract C {(T_0 x_01)
> ... K F_01 ... (T f_0 ((T_00 x_00) ... ) {return e}) F_02 ...}) (contract
> C_2 {(T_2 x_21) ... K_2 F_2 ...}) ...)]
> (side-condition)
> "CALL2")
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/6ab63e3a-72f8-4ae9-a43a-64dcb07a9320n%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/CAL3TdONnHzwwZm3NTT5swuF%2B7mD5MNSxXE4ybbGF6RcV-O_1Hg%40mail.gmail.com.


Re: [racket-users] [racket users] raise-user-error question

2020-09-19 Thread Robby Findler
That's some internal error "uh oh, something's wrong ... print out some
hints to help people debug!" message.

It looks like that's been fixed since, however as I don't see it in git
build.

Robby


On Sat, Sep 19, 2020 at 5:31 PM Kevin Forchione  wrote:

> Hi guys.
>
> Using Racket 7.8 [cs[, If I create a module called error.rkt with the
> following code
> #lang racket
>
> (provide foo)
> (define foo (λ () (raise-user-error "foo")))
>
> And then a module called error-test.rket with the following code
> #lang racket
>
> (require "error.rkt")
>
> (foo)
>
> And execute error-r-test.rkt I get the following
>
> Welcome to DrRacket, version 7.8 [cs].
> Language: racket, with debugging; memory limit: 1024 MB.
> -- #(struct:exn:fail:contract "vector-ref: contract violation\n  expected:
> vector?\n  given: '((raise-user-error \"foo\")
> # Documents/com~apple~CloudDocs/Racket/utils/conspiracy/error.rkt> 4 18 47
> 24)" #)
>   ("condition->exn" . #f)
>   ("do-raise" . #f)
>   ("dynamic-wind" . #f)
>   ("errortrace-stack-item->srcloc" . #(struct:srcloc
> # 168 0 6297 203))
>   ("pick-first-defs" . #(struct:srcloc
> # 331 0 13000 425))
>   ("get-exn-source-locs" . #(struct:srcloc
> # 585 0 23184 391))
>   (#f . #(struct:srcloc # 486 18
> 20735 32))
>   ("error-display-handler/stacktrace" . #(struct:srcloc
> # 362 2 15076 2612))
>   ("debug-error-display-handler" . #(struct:srcloc
> # 341 4 14358 566))
>   ("default-uncaught-exception-handler" . #f)
>   ("loop" . #f)
>   ("call-in-empty-metacontinuation-frame" . #f)
>   ("call-with-values" . #f)
>   ("call-in-empty-metacontinuation-frame" . #f)
>   (|body of "/Users/lysseus/Library/Mobile
> Documents/com~apple~CloudDocs/Racket/utils/conspiracy/error-test.rkt"| . #f)
>   ("temp35_0" . #f)
>   ("run-module-instance!" . #f)
>   ("perform-require!" . #f)
>   (#f . #(struct:srcloc # 115 30
> 4709 11))
>   ("call-with-stack-checkpoint" . #(struct:srcloc
> # 82 0 3329 442))
>   ("call-in-empty-metacontinuation-frame" . #f)
>   ("*init" . #(struct:srcloc # 463 8
> 22165 762))
>   ("call-with-break-parameterization" . #(struct:srcloc
> # 148 2 4909 517))
>   ("call-in-empty-metacontinuation-frame" . #f)
>   (#f . #(struct:srcloc # 1180 9 49153 5062))
>   (#f . #(struct:srcloc # 1493 15 64385 1548))
>   (#f . #(struct:srcloc # 435 6 19067 1056))
>   ("call-in-empty-metacontinuation-frame" . #f)
>   ("call-in-empty-metacontinuation-frame" . #f)
>   (#f . #(struct:srcloc # 486 32 21054 120))
>   ("call-with-break-parameterization" . #(struct:srcloc
> # 148 2 4909 517))
>   ("call-in-empty-metacontinuation-frame" . #f)
>   ("eventspace-handler-thread-proc" . #(struct:srcloc
> # 370 11 16515 690))
>   ("call-in-empty-metacontinuation-frame" . #f)
>   ("call-with-empty-metacontinuation-frame-for-swap" . #f)
> exception raised by error display handler: vector-ref: contract violation
>   expected: vector?
>   given: '((raise-user-error "foo") # Documents/com~apple~CloudDocs/Racket/utils/conspiracy/error.rkt> 4 18 47
> 24); original exception raised: foo
>   context...:
>loop
>dynamic-wind
>.../private/stack-checkpoint.rkt:168:0: errortrace-stack-item->srcloc
>.../private/stack-checkpoint.rkt:331:0: pick-first-defs
>.../private/stack-checkpoint.rkt:585:0: get-exn-source-locs
>.../private/arrow-val-first.rkt:486:18
>.../private/debug.rkt:362:2: error-display-handler/stacktrace
>.../private/debug.rkt:341:4: debug-error-display-handler
>default-uncaught-exception-handler
>loop
>call-in-empty-metacontinuation-frame
>call-with-values
>call-in-empty-metacontinuation-frame
>body of "/Users/lysseus/Library/Mobile
> Documents/com~apple~CloudDocs/Racket/utils/conspiracy/error-test.rkt"
>temp35_0
>run-module-instance!
> >
>
> Is this what I should expect?
>
> Kevin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/F848340C-7BBC-4C13-A94F-723AB4B941DA%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3Td%2BE3s7MSVSPzD1ZxT-LsHZcLpuycVe3ztch0MAgF6g%40mail.gmail.com.


Re: [racket-users] Scribbling hexadecimal values

2020-09-19 Thread Robby Findler
I don't have any good hints but the reader supplies span information that
can be used to disambiguate the original versions of some things (notably
"#t" vs "#true"). I doubt this is enough for numbers in any general sense
but following the path of actually carrying more information from the
reader through scribble to the rendered output may be an approach worth
considering.

Robby

On Sat, Sep 19, 2020 at 2:29 AM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

> Hi Eric,
>
> thank you. Actually I was already using unsyntax for putting the default
> values in optional arguments list and didn't recognize that I can use
> anything from the scribble API at that point. Now the formatting of
> default values is simple and yields expected results. In my case:
>
> (()
>((argb #,(racketvalfont (format "#x~x" (arithmetic-shift alpha-max
> 24))
>
> This is really cool.
>
> However, for the contract part, I think the only solution would be
> adding a parameter that would change the behavior of
> proc-doc-transformer and proc-doc/names transformer or more generally
> add support to *defproc's do-one' arg-contracts handling code.
>
> This basically goes down to racketblock0 rendering of numbers.
>
> I am afraid that this needs some with more experience with scribble
> internals to implement. I think that adding parameter to configure the
> rendering of numbers inside define-code-like forms will be rather easy.
> But how to parameterize in provide block and not mess with any of those
> proc-doc*transformer code is currently beyond my understanding.
>
> I would appreciate any hints though.
>
>
> Cheers,
> Dominik
>
> On 19. 09. 20 3:40, Eric Griffis wrote:
> > Hi Dominik,
> >
> > If you put the hex number in a string, many of the formatting functions
> > in the Scribble manual, section 4.2.1.4 will work:
> >
> >   (proc-doc/names
> >name
> >(->* () (integer?) void?)
> >(()
> > ((argument #,(racketvalfont "#x1f"
> >@{ some description }))
> >
> > Eric
> >
> >
> > On Fri, Sep 18, 2020 at 2:23 PM Dominik Pantůček
> > mailto:dominik.pantu...@trustica.cz>>
> wrote:
> >
> > Hello Racketeers,
> >
> > I am struggling to make scribble typeset default values in
> > proc-doc/names in hexadecimal. An example would be:
> >
> > (proc-doc/names
> >   name
> >   (->* () (integer?) void?)
> >   (()
> >((argument #x1f)))
> >   @{ some description }) ; yes, at-exp reader
> >
> > The same applies to values in nested contracts of ->* - like
> (integer-in
> > 0 #x1f).
> >
> > Of course #,(~a "~x" #x1f) will produce the string with appropriate
> > contents - but enclosed in parentheses which does not help much.
> Also it
> > is not just a matter of typesetting because the provide form really
> > contracts the procedure being provided and the actual values should
> > actually be present.
> >
> > I would love to see some documentation-stage parameter where I could
> > just (parameterize ((numbers-as-hexadecimal #t)) (integer-in ...)
> ...)
> > and it would keep the values as they are for contract purposes and
> > render them hexadecimal. Of course, this is quite specific - more
> > generic solution is probably more appropriate, this is just to
> explain
> > the problem I am trying to solve.
> >
> >
> > Cheers,
> > Dominik
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to racket-users+unsubscr...@googlegroups.com
> > .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/racket-users/aca5b2ab-36b6-98c6-0747-9d5447ae9766%40trustica.cz
> .
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/23557632-fe68-567e-3a2e-c9abf6df5779%40trustica.cz
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONQ0qhD-CMijbX9F_CXqziCqNuTSMhwBMc7M6dUqgWqRg%40mail.gmail.com.


Re: [racket-users] UTF-8 encoding error when opening files in DrRacket on Windows 10

2020-09-17 Thread Robby Findler
I know only that we didn't get the report with earlier versions.

BTW, if one click on the dialog that has the error message, there should be
a "copy" option that will let you get some potentially valuable debugging
information. If it is easy to get a student who is having the problem to do
that, it may be helpful to report it back.

Robby


On Thu, Sep 17, 2020 at 8:46 AM breanndan@gmail.com <
breanndan.o.nuall...@gmail.com> wrote:

> Thanks Robby. We'll experiment with that.
>
> Any  idea if it's just the current version fo DrRacket? We could have them
> try installing the previous version for the time being.
>
> On Thursday, 17 September 2020 at 14:45:06 UTC+2 Robby Findler wrote:
>
>> We have had one other report yes. It looks like something is going wrong
>> with the open file dialog. It may be possible to open files by double
>> clicking on them to sidestep the bug I am not sure.
>>
>> Sorry about this.
>>
>> Robby
>>
>> On Thu, Sep 17, 2020 at 6:29 AM breanndan@gmail.com <
>> breanndan@gmail.com> wrote:
>>
>>> I have two students who just installed DrRacket on Windows 10 and get
>>> this error when they try to open files:
>>>
>>> bytes->string/locale: string is not a well-formed UTF-8 encoding
>>> string: #"\340lU\1"
>>>
>>> Has anyone else encountered 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...@googlegroups.com.
>>>
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/cef31834-11d8-4bc3-b03d-c63d2868f097n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/racket-users/cef31834-11d8-4bc3-b03d-c63d2868f097n%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/9b1a259b-1aa0-4b7c-b902-78376ccc9253n%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/9b1a259b-1aa0-4b7c-b902-78376ccc9253n%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/CAL3TdOM2S50KnFHhYQb89qXFmojxzNh%3Dc5hPPAhvO0CdTTA1Dw%40mail.gmail.com.


Re: [racket-users] UTF-8 encoding error when opening files in DrRacket on Windows 10

2020-09-17 Thread Robby Findler
We have had one other report yes. It looks like something is going wrong
with the open file dialog. It may be possible to open files by double
clicking on them to sidestep the bug I am not sure.

Sorry about this.

Robby

On Thu, Sep 17, 2020 at 6:29 AM breanndan@gmail.com <
breanndan.o.nuall...@gmail.com> wrote:

> I have two students who just installed DrRacket on Windows 10 and get this
> error when they try to open files:
>
> bytes->string/locale: string is not a well-formed UTF-8 encoding
> string: #"\340lU\1"
>
> Has anyone else encountered 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/cef31834-11d8-4bc3-b03d-c63d2868f097n%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/CAL3TdOPjFL0h5xcO_b%3DcE0vgD3yEw4O8YhbP-9ktoRHDpwzU6Q%40mail.gmail.com.


Re: [racket-users] package manager woes on Windows 10?

2020-09-15 Thread Robby Findler
The change I made is in the gui-pkg-manager repo (well there may be one
more word in the name).

Yes, it does just strip. I didn't see any code that was doing what you
describe but I also didn't look for it!

Robby

On Tue, Sep 15, 2020 at 8:39 AM John Clements 
wrote:

> I have a question about the new behavior.
>
>
>
> (ObResearch: actually, I checked the drracket, racket, and gui repos, and
> I couldn’t find any new push, so I couldn’t check the code myself.)
>
>
>
> Does it simply strip newlines, as Jack suggested, or does it signal an
> error? The latter seems less likely to silently cause weird problems /
> vulnerabilities / etc.
>
>
>
> Also, I notice that the (current) behavior changes when there’s a branch
> specified explicitly; it seems that in this case, the URL parser happily
> splits at the hash and dumps the rest (including newlines) into the
> “branch” without any message about invalid characters. That might be an
> error in our URL parsing… or maybe URLs are allowed to have newlines in
> that part? That would be strange. Either way, I suspect that that bug (if
> it’s a bug) will be hidden by this fix.
>
>
>
> Finally, a million thanks for fixing this; I always have students (and it
> happened again yesterday!) that run into this.
>
>
>
> John
>
>
>
>
>
>
>
> > On Sep 15, 2020, at 07:38, Robby Findler 
> wrote:
>
> >
>
> > I just worry about backwards compatibility. There are probably places
> that already do something about this problem woutside of the control-- how
> will they interact?
>
> >
>
> > Maybe if someone were to audit existing code on the pkg server then we
> would know that changing the behavior in a certain way would work out.
>
> >
>
> > Robby
>
> >
>
> >
>
> > On Tue, Sep 15, 2020 at 12:46 AM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
> > Can you explain why you are not sure? Under what circumstances do you
> think the current 'single style behavior is useful?
>
> >
>
> > We can add 'single-no-return (though I dislike it because 'single means
> no return already!) and change existing places that use 'single. However,
> without switching the default style from 'single to 'single-no-return,
> people will make mistakes again in the future. But if we will change the
> default style to 'single-no-return too, why don't we simply directly change
> the behavior 'single?
>
> >
>
> > On Sun, Sep 13, 2020 at 1:36 PM Robby Findler 
> wrote:
>
> > I'm not sure. I would probably add a 'single-no-return style and then
> grep the codebase for places that use 'single and change them (as
> appropriate).
>
> >
>
> > Robby
>
> >
>
> >
>
> > On Sun, Sep 13, 2020 at 3:15 PM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
> > I meant, wouldn’t it be better to fix text-field% itself, instead of
> only some instances of it? Sorry if that was confusing.
>
> >
>
> >
>
> >
>
> >
>
> > On Sun, Sep 13, 2020 at 1:12 PM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
> > Should the fix apply to all 'single styled text-field% too?
>
> >
>
> >
>
> >
>
> >
>
> > On Sun, Sep 13, 2020 at 7:50 AM Robby Findler 
> wrote:
>
> > Yea, I agree. I'd made that change locally but hadn't pushed because I
> couldn't make the bad behavior happen reliably. Perhaps that lack shouldn't
> stop us! Pushed now.
>
> >
>
> > Robby
>
> >
>
> >
>
> > On Sat, Sep 12, 2020 at 11:15 PM jackh...@gmail.com <
> jackhfi...@gmail.com> wrote:
>
> > Could we make the "do what I mean" box just automatically strip any
> newlines pasted into it? It seems sensible to me to require that it only be
> a single line input.
>
> >
>
> > On Friday, September 11, 2020 at 6:22:59 AM UTC-7 hen...@topoi.pooq.com
> wrote:
>
> > On Thu, Sep 10, 2020 at 10:27:39AM -0400, George Neuner wrote:
>
> >
>
> >
>
> > >
>
> >
>
> >
>
> > >
>
> >
>
> >
>
> > > On 9/10/2020 10:06 AM, Philip McGrath wrote:
>
> >
>
> >
>
> > > > Also, this is happening over encrypted HTTPS: no one is sniffing the
>
> >
>
> >
>
> > > > User-Agent header.
>
> >
>
> >
>
> > >
>
> >
>
> >
>
> > > While it may not be the issue here, you need to understand that
> appliance
>
> >
>
> >
>
> > > firewalls CAN

Re: [racket-users] package manager woes on Windows 10?

2020-09-15 Thread Robby Findler
I just worry about backwards compatibility. There are probably places that
already do something about this problem woutside of the control-- how will
they interact?

Maybe if someone were to audit existing code on the pkg server then we
would know that changing the behavior in a certain way would work out.

Robby


On Tue, Sep 15, 2020 at 12:46 AM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> Can you explain why you are not sure? Under what circumstances do you
> think the current 'single style behavior is useful?
>
> We can add 'single-no-return (though I dislike it because 'single means no
> return already!) and change existing places that use 'single. However,
> without switching the default style from 'single to 'single-no-return,
> people will make mistakes again in the future. But if we will change the
> default style to 'single-no-return too, why don't we simply directly change
> the behavior 'single?
>
> On Sun, Sep 13, 2020 at 1:36 PM Robby Findler 
> wrote:
>
>> I'm not sure. I would probably add a 'single-no-return style and then
>> grep the codebase for places that use 'single and change them (as
>> appropriate).
>>
>> Robby
>>
>>
>> On Sun, Sep 13, 2020 at 3:15 PM Sorawee Porncharoenwase <
>> sorawee.pw...@gmail.com> wrote:
>>
>>> I meant, wouldn’t it be better to fix text-field% itself, instead of
>>> only some instances of it? Sorry if that was confusing.
>>>
>>>
>>>
>>> On Sun, Sep 13, 2020 at 1:12 PM Sorawee Porncharoenwase <
>>> sorawee.pw...@gmail.com> wrote:
>>>
>>>> Should the fix apply to all 'single styled text-field%
>>>> <https://docs.racket-lang.org/gui/text-field_.html> too?
>>>>
>>>>
>>>>
>>>> On Sun, Sep 13, 2020 at 7:50 AM Robby Findler <
>>>> ro...@cs.northwestern.edu> wrote:
>>>>
>>>>> Yea, I agree. I'd made that change locally but hadn't pushed because I
>>>>> couldn't make the bad behavior happen reliably. Perhaps that lack 
>>>>> shouldn't
>>>>> stop us! Pushed now.
>>>>>
>>>>> Robby
>>>>>
>>>>>
>>>>> On Sat, Sep 12, 2020 at 11:15 PM jackh...@gmail.com <
>>>>> jackhfi...@gmail.com> wrote:
>>>>>
>>>>>> Could we make the "do what I mean" box just automatically strip any
>>>>>> newlines pasted into it? It seems sensible to me to require that it only 
>>>>>> be
>>>>>> a single line input.
>>>>>>
>>>>>> On Friday, September 11, 2020 at 6:22:59 AM UTC-7
>>>>>> hen...@topoi.pooq.com wrote:
>>>>>>
>>>>>>> On Thu, Sep 10, 2020 at 10:27:39AM -0400, George Neuner wrote:
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>> > On 9/10/2020 10:06 AM, Philip McGrath wrote:
>>>>>>>
>>>>>>>
>>>>>>> > > Also, this is happening over encrypted HTTPS: no one is sniffing
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>> > > User-Agent header.
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>> > While it may not be the issue here, you need to understand that
>>>>>>> appliance
>>>>>>>
>>>>>>>
>>>>>>> > firewalls CAN and routinely DO examine data inside encrypted
>>>>>>> connections.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Using man-in-the-middle attacks?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- hendrik
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> You received this mess

Re: [racket-users] package manager woes on Windows 10?

2020-09-13 Thread Robby Findler
I'm not sure. I would probably add a 'single-no-return style and then grep
the codebase for places that use 'single and change them (as appropriate).

Robby


On Sun, Sep 13, 2020 at 3:15 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> I meant, wouldn’t it be better to fix text-field% itself, instead of only
> some instances of it? Sorry if that was confusing.
>
> On Sun, Sep 13, 2020 at 1:12 PM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
>> Should the fix apply to all 'single styled text-field%
>> <https://docs.racket-lang.org/gui/text-field_.html> too?
>>
>> On Sun, Sep 13, 2020 at 7:50 AM Robby Findler 
>> wrote:
>>
>>> Yea, I agree. I'd made that change locally but hadn't pushed because I
>>> couldn't make the bad behavior happen reliably. Perhaps that lack shouldn't
>>> stop us! Pushed now.
>>>
>>> Robby
>>>
>>>
>>> On Sat, Sep 12, 2020 at 11:15 PM jackh...@gmail.com <
>>> jackhfi...@gmail.com> wrote:
>>>
>>>> Could we make the "do what I mean" box just automatically strip any
>>>> newlines pasted into it? It seems sensible to me to require that it only be
>>>> a single line input.
>>>>
>>>> On Friday, September 11, 2020 at 6:22:59 AM UTC-7 hen...@topoi.pooq.com
>>>> wrote:
>>>>
>>>>> On Thu, Sep 10, 2020 at 10:27:39AM -0400, George Neuner wrote:
>>>>> >
>>>>> >
>>>>> > On 9/10/2020 10:06 AM, Philip McGrath wrote:
>>>>> > > Also, this is happening over encrypted HTTPS: no one is sniffing
>>>>> the
>>>>> > > User-Agent header.
>>>>> >
>>>>> > While it may not be the issue here, you need to understand that
>>>>> appliance
>>>>> > firewalls CAN and routinely DO examine data inside encrypted
>>>>> connections.
>>>>>
>>>>> Using man-in-the-middle attacks?
>>>>>
>>>>> -- 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/84b16cf0-7837-4d54-9423-c1286f5e2b7an%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/racket-users/84b16cf0-7837-4d54-9423-c1286f5e2b7an%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/CAL3TdON46%3DPR6_-iyppSMLsfEvNEveq3uGu64gQ3Lu1or7QgNw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/racket-users/CAL3TdON46%3DPR6_-iyppSMLsfEvNEveq3uGu64gQ3Lu1or7QgNw%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/CADcuegtFzzeErTTqi3m9Hyr%2Bu1m8YEo0cnAEw2onhKXGnTzHOg%40mail.gmail.com
> <https://groups.google.com/d/msgid/racket-users/CADcuegtFzzeErTTqi3m9Hyr%2Bu1m8YEo0cnAEw2onhKXGnTzHOg%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/CAL3TdOMGpAWz8Df5CAJNvhdfCyb7CL%2BNocZGYtga6YtZMrjDqg%40mail.gmail.com.


  1   2   3   4   5   6   7   8   9   >