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

[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?

[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?

[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] Werid contract violation blame erros

[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

[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] Werid contract violation blame erros

[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] Something is going slightly wrong visually with the Linux version

[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

[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] Something is going slightly wrong visually with the Linux version

[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] [Redex] Side conditions in Reduction Relations

[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] put-image

[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] exporting example code from slideshow documents

[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] Find the source location of the syntax error in DrRacket

[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] Question from a beginner. Why Racket Over Scheme?

[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] Pousse Player Programs

[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] What is the correct name for non-list parenthesized forms?

[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] What is the correct name for non-list parenthesized forms?

[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] Having trouble getting documentation to generate

[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] Core Team: I need you decide what I should do about the spammer.

[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] Formal semantics of PLT Redex

[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.

[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] Typesetting Redex definitions

[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?

[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] Formal semantics of PLT Redex

[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] Formal semantics of PLT Redex

[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] Core Team: I need you decide what I should do about the spammer.

[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.

[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] Core Team: I need you decide what I should do about the spammer.

[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

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

[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] [meta] Please review pending member requests?

[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.

Re: [racket-users] Some DrRacket preferences unreadable

[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

[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.