Re: [racket-users] Apple Silicon build errors

[Matthew Flatt]

This is a problem with v8.3 and the latest Apple tools. It's fixed for
the upcoming v8.4 release (so, in the main branch and in the current
snapshot source distributions).

In case you want a minimal patch, commit 0a8b68b286 is the repair and
might apply cleanly to v8.3.

At Mon, 17 Jan 2022 10:16:53 -0600, Nathaniel W Griswold wrote:
> Has anyone else run into this error (see below) when building natively on 
> Apple silicon? I am getting it both on a cleaned checkout with `make 
> unix-style` with prefix at root, as well as when doing a configure with 
> prefix 
> using the source distribution found at 
> https://mirror.racket-lang.org/installers/8.3/racket-8.3-src.tgz
> 
> Monterey 12.1
> 
> Nate
> 
> ---
> make mac-embed-boot-fw EMBED_SRC=raw_racketcs EMBED_DEST=racketcs
> make[5]: Entering directory 
> '/Users/griswold/project/racket/racket/src/build/cs/c'
> rm -f racketcs
> cp raw_racketcs racketcs
> codesign --remove-signature racketcs
> make[5]: Leaving directory 
> '/Users/griswold/project/racket/racket/src/build/cs/c'
> /usr/bin/install_name_tool -change "Racket.framework/Versions/8.3_CS/Racket" 
> "@executable_path/Racket.framework/Versions/8.3_CS/Racket" racketcs
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/
> usr/bin/install_name_tool: fatal error: file not in an order that can be 
> processed (link edit information does not fill the __LINKEDIT segment): 
> racketcs
> ---
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/160A7A66-18BF-4F18-934A-E85C4642
> 1445%40nan.sh.

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

Re: [racket-users] Porting embedded app from BC to CS

[Matthew Flatt]

At Mon, 20 Dec 2021 11:57:29 -0800 (PST), "thomas_d...@alumni.brown.edu" wrote:
> So what happens from the perspective of embedding C code if an exception 
> occurs in Racket code it calls?

It's not defined. In certain cases, control will escape from the C
code, I think, but it depends on how the C code was reached.

> I can't seem to locate `disable-interrupts` or `enable-interrupts`  via 
> searching the docs, but it sounds like if I needed to compose a sequence of 
> several calls into Racket while keeping a consistent view of memory on the 
> C side, I could do something like:
> 
> racket_apply(racket_primitive("disable-interrupts"),Snil);
> // sequence of racket_ function calls
> racket_apply(racket_primitive("enable-interrupts"),Snil);
> 
> Does that sound correct?

Yes. Those are Chez Scheme functions, so you'd have to look in the Chez
Scheme documentation, which is not currently incorporated into the
Racket documentation.

Probably it would make sense to have more direct support for these in
the C API, and I've put that on my to-do list.

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

Re: [racket-users] Porting embedded app from BC to CS

[Matthew Flatt]

At Fri, 5 Nov 2021 08:58:06 -0700 (PDT), "thomas_d...@alumni.brown.edu" wrote:
>  - What are the preconditions and error-handling setup for calling 
> `racket_dynamic_require` and/or other `racket_*` functions?

There's not really anything you can do to catch exception C-side right
now. If you need to catch exceptions, that has to be done Racket-side,
possibly with a helper created via `racket_eval`.

>  - How does one obtain a path from a C string to pass to 
> `racket_dynamic_require`? (i.e. what's the equivalent idiom to 
> `scheme_make_path`?

You can use `Sstring` to create a Scheme string from a C string or use
`Smake_bytevector` plus `memcpy` to create a Racket byte string. For
conversions like `bytes->path`, use `racket_primitive` to get the
Scheme/Racket function and call it.

>  - There don't appear to be documented equivalents to SCHEME_CPTRP and 
> SCHEME_CPTR_TYPE. 
> What does `racket_cpointer_address` do if the argument is not a cpointer, 
> and is there some way to check the type tag without triggering garbage 
> collection?

You can get `cpointer?` using `racket_primitive`. To disable garbage
collection, I don't have a better idea than using `disable-interrupts`
and `enable-interrupts` (again, obtained via `racket_primitive`),
although that's limited in the sense that `disable-interrupts` could
itself allow a GC through before disabling interrupts, at least in
principle.

> - One of the hassles with Racket BC is that the garbage collection 
> algorithm intetionally triggers segfaults and uses a signal handler to 
> resolve them, marking it hard to use GDB on the larger embedded 
> application. Does Racket CS have the same behavior, or is this not a 
> problem anymore?

Racket CS does not do that --- so, that's something easier, for a
change.


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/20211220123425.3fb%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

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.

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

[Matthew Flatt]

Yes, ou can use `dynamic-require` with a limited code inspector like
this:

 (parameterize ([current-code-inspector (make-inspector)])
   (dynamic-require 'untrusted-foo 'foo-provided-name))


At Fri, 22 Oct 2021 12:42:58 -0700 (PDT), "kalime...@gmail.com" wrote:
> Thank you!
> 
> Is it possible to safely load untrusted module with dynamic-require?
> 
> пятница, 22 октября 2021 г. в 22:59:57 UTC+5, 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...@googlegroups.com.
> >>
> > To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/racket-users/20211022114302.3e4%40sirmail.smtp
> s.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/004de0e0-b25f-4bae-be79-9bdd561a1
> e18n%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/20211023102301.11%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] M1 Mac exe SSL error

[Matthew Flatt]

At Fri, 22 Oct 2021 17:24:30 -0400, Mike Engelhart wrote:
> I wanted to build a binary to send to a colleague to test it (who
> isn't a programmer and doesn't have Racket installed) but when I
> build it on my intel Macbook Pro and then send it to my M1 iMac

That should work.

I tried this small experiment:

 ;; ssl.rkt
  #lang racket/base
  (require openssl)

  (define-values (i o) (ssl-connect "www.cs.utah.edu" 443))
  'done

With that "ssl.rkt":

 $ raco exe ssl.rkt
 $ raco dist ssl-dist ssl
 $ tar zcf ssl-dist.tgz ssl-dist
 
 ... copy ssl-dist.tgz to an M1,
 then on that machine ...

 $ tar zxf ssl-dist.tgz
 $ ./ssl-dist/bin/ssl

and that much seemed to work.

Does the little "ssl.rkt" program above work for you? If not, which
version of Racket are you using? Also, just to make sure, are you
creating a distribution to move to the other machine, as opposed to
just an executable file?


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/20211022160205.234%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

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)

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.

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

[Matthew Flatt]

I've adjusted pkgs.racket-lang.org to fix a problem with fetching the
pkg-build status from pkg-build.racket-lang.org. That is, packages were
being built and documentation was incorporated into
docs.racket-lang.org, but pkgs.racket-lang.org wasn't reflecting that.

(I didn't do more than try to fix this specific problem, though.)

At Fri, 8 Oct 2021 10:40:31 -0700, Siddhartha Kasivajhula wrote:
> Looks like the try-catch package docs still aren't showing up
> <https://pkgd.racket-lang.org/pkgn/package/try-catch>.
> 
> This might be a broader issue with the package index and docs, since I just
> renamed one of my packages that already had docs, and the docs now no
> longer exist on the package index (it says "this package needs
> documentation"). I think this is because the package now reflects as a new
> package and so runs afoul of whatever issue appears to be afflicting new
> arrivals.
> 
> I checked the "New Releases" section of the latest issue of Racket News
> <https://racket-news.com/2021/10/racket-news-issue-54.html#newreleases> to
> validate whether new packages are especially affected, and of the packages
> listed there, a majority of them include scribble docs that we can see
> listed in the package modules, but the docs show up for none of them:
> 
> https://pkgs.racket-lang.org/package/in-out-logged
> https://pkgs.racket-lang.org/package/libansilove
> https://pkgs.racket-lang.org/package/pprint-compact
> https://pkgs.racket-lang.org/package/codepoint
> https://pkgs.racket-lang.org/package/fmt
> https://pkgs.racket-lang.org/package/pareto-frontier
> https://pkgs.racket-lang.org/package/majordomo2
> 
> 
> 
> 
> On Wed, Sep 29, 2021 at 9:01 AM David Storrs  wrote:
> 
> > Cool, thanks.
> >
> > On Wed, Sep 29, 2021 at 11:23 AM Matthew Flatt  wrote:
> >
> >> At Wed, 29 Sep 2021 11:20:47 -0400, David Storrs wrote:
> >> > On Wed, Sep 29, 2021 at 9:57 AM Matthew Flatt 
> >> wrote:
> >> >
> >> > > At Wed, 29 Sep 2021 02:27:53 +, Philip McGrath wrote:
> >> > > > I haven't tried `raco setup` to look at its output, but one possible
> >> > > > improvement would be for whatever code complains about the "invalid
> >> > > `deps'
> >> > > > specification" to always report the invalid file's path.
> >> > >
> >> > > I've pushed that addition.
> >> > >
> >> > >
> >> > Thanks, Matthew.  Is this a "download Racket 8.2" thing or an "update
> >> from
> >> > github" thing?
> >>
> >> The improvement is only in the GitHub repo right now. So, updating from
> >> GitHub gets it now, it will also be part of the next round of
> >> snapshots, and then it will be part of the upcoming v8.3 release.
> >>
> >>
> >> 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/CAE8gKoegBUGVbfmguydZwaVBWgrNOJWJ
> 3CmxTvShROR4-dpvJw%40mail.gmail.com
> > 
> <https://groups.google.com/d/msgid/racket-users/CAE8gKoegBUGVbfmguydZwaVBWgrNOJW
> J3CmxTvShROR4-dpvJw%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/20211008164839.3cc%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

At Wed, 29 Sep 2021 11:20:47 -0400, David Storrs wrote:
> On Wed, Sep 29, 2021 at 9:57 AM Matthew Flatt  wrote:
> 
> > At Wed, 29 Sep 2021 02:27:53 +, Philip McGrath wrote:
> > > I haven't tried `raco setup` to look at its output, but one possible
> > > improvement would be for whatever code complains about the "invalid
> > `deps'
> > > specification" to always report the invalid file's path.
> >
> > I've pushed that addition.
> >
> >
> Thanks, Matthew.  Is this a "download Racket 8.2" thing or an "update from
> github" thing?

The improvement is only in the GitHub repo right now. So, updating from
GitHub gets it now, it will also be part of the next round of
snapshots, and then it will be part of the upcoming v8.3 release.


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/20210929092338.ac%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

At Wed, 29 Sep 2021 02:27:53 +, Philip McGrath wrote:
> I haven't tried `raco setup` to look at its output, but one possible
> improvement would be for whatever code complains about the "invalid `deps'
> specification" to always report the invalid file's path.

I've pushed that addition.

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

[racket-users] Rhombus brainstorming discussion

[Matthew Flatt]

For anyone interested in Rhombus, I'd like to make sure you're aware
that we recently turned on the discussions feature at the GitHub repo:

  https://github.com/racket/rhombus-brainstorming/discussions

More generally, we've accumulated a large number of ideas and wishes at
that repo, mostly in the form of issues. There are a handful of
concrete proposals in the form of pull requests. There is a candidate
experiment prototype based on a group of the proposals. Those proposals
and the implementation have evolved a lot through discussion in the PRs
and issues.

The discussion is ongoing, but we're likely getting to the end of the
brainstorming phase.


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/20210920095909.3fc%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: jest...@gmail.com Trouble installing DrRacket

[Matthew Flatt]

At Tue, 14 Sep 2021 01:54:44 -0400, George Neuner wrote:
> Is there a list somewhere of which chips have successfully run Racket?
> Or a definitive statement of what ISA is targeted?

For Racket CS, there's a list here:

 https://github.com/racket/racket/tree/master/racket/src/ChezScheme

Granted, that's not the most visible place. That location makes sense
when the Racket branch of Chez Scheme is extracted to its own repo, but
probably the documentation should have it's own list or link to that
list.


For Racket BC, the question is murkier. Racket BC should run on any
platform with a C compiler and enough libraries, although having the
right configuration can be an issue. So, historically, Racket BC is
meant to work on all platforms (misconfiguration treated a bug), and
that's why there hasn't been a list. For the JIT, there's a list in the
documentation:

  https://docs.racket-lang.org/guide/performance.html#%28tech._jit%29

That list could be improved because, as you say, "32-bit ARM" is not
really descriptive enough. It should say something like "ARMv4 and up",
and it should clarify that Windows ARM is not supported (where I expect
that it's more than a matter of configuration to support Windows, and
32-bit Windows ARM seems to be rare, anyway).

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

Re: [racket-users] Re: jest...@gmail.com Trouble installing DrRacket

[Matthew Flatt]

Just to clarify: Racket runs on a number of ARM variants when running
Linux and other Unix-like operating systems, but we have not yet ported
to Windows on ARM.

Matthew

At Mon, 13 Sep 2021 11:21:57 -0700 (PDT), Nathan Philippon wrote:
> I think you're right, thanks.
> 
> On Monday, September 13, 2021 at 2:06:03 p.m. UTC-4 gneuner2 wrote:
> 
> >
> > On 9/13/2021 1:02 PM, Nathan Philippon wrote:
> >
> > It's a Samsung GalaxyBook
> >
> > On Monday, September 13, 2021 at 12:48:06 p.m. UTC-4 jest...@gmail.com 
> > wrote:
> >
> >> Yeah, I don't think Racket supports windows on arm devices. I'm guessing 
> >> this is a chromebook or something? HP? Dell? 
> >> On Monday, September 13, 2021 at 8:44:08 AM UTC-7 hockeyfa...@gmail.com 
> >> wrote:
> >>
> >>> I tried replying in the same thread but my messages kept getting 
> >>> deleted. 
> >>> Processor: Snapdragon (TM) 7c Gen 2 @ 2.55 GHz   2.55 GHz
> >>> RAM: 4.00GB
> >>>
> >>
> > Disclaimer:  I am not part of the Racket development team.
> >
> > I don't think Racket is supported on a Chromebook.  Even so, there are a 
> > number of issues with running Racket on ARM ... there simply are too many 
> > variations of ARM chips to test the code on all of them.  Some just can't 
> > run the current codebases (BC or CS), and I am pretty sure BC's JIT 
> > compiler is not supported on any of them.
> >
> > It may be that Racket (currently) just won't work on your chip.  Or it may 
> > be something with ChromeOS.
> >
> >
> > Sorry.  I know this wasn't particularly helpful.
> > George
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e397bdd9-5759-4f9f-a472-5bbb5840a
> af7n%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/20210913203424.221%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] 'compiled' binary still depending on libs?

[Matthew Flatt]

Some libraries have extra run-time files that they refer to with
`define-runtime-path` and similar. I think "gregor" is in that
category, where it needs files like "timezone.xml". Embedding DLLs
can't embed those extra files.

The intent is that you use `raco distribute` to package an executable
along with any needed run-time files into a directory. That whole
directory can then be moved to another machine to run it.

At Mon, 30 Aug 2021 07:47:34 -0700 (PDT), Dexter Lagan wrote:
> Hi folks,
> 
>   I'm getting a strange dependency problem when attempting to run my 
> Invoicer binary on systems with corrupted or missing Racket libs. For 
> example, if I attempt to run the compiled binary (with embedded DLLs, 
> Windows 10 x64) on a system which has Racket installed, but missing Gregor, 
> I get an error claiming the gregor package is missing. Yet I was under the 
> impression that compiling to binary for distribution, especially with 
> embedded DLLs, would not require ANY libs installed. Is there a reason for 
> this?
> 
> Here's the program in question:
> DexterLagan/invoicer: A dead-simple, easy-to-use minimalist billing 
> application. (github.com) 
> 
> Thanks in advance!
> 
> Dexter

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

Re: [racket-users] Obtaining the path of the application program?

[Matthew Flatt]

The analog to the first argument to main in C is

  (find-system-path 'run-file)

I think that's probably what you want.


Something closer to `get-current-source` but adapting to a run-time
file is

 (variable-reference->module-source
  (#%variable-reference))

Here, `(#%variable-reference)` is the primitive form that obtains a
connection to the enclosing module at run time. If you create an
executable with `raco exe`, though, the "source" of the module will be
a symbolic name instead of a path, because a module that's embedded in
an executable doesn't have a file identity anymore.

At Thu, 26 Aug 2021 07:51:35 -0700, Jeff Henrikson wrote:
> Racket users,
> 
> Many software applications use their location in the filesystem to 
> establish filesystem relationships between their executable file, their 
> configuration and their data.  For this purpose, C provides the first 
> element of the string array provided to main, python provides __file__, 
> bash provides ${BASH_SOURCE[0]}, etc.
> 
> Racket strips said value before current-command-line-arguments receives 
> the subsequent command-line arguments from the operating system.
> 
> A related value can be pulled from syntax-source as follows:
> 
> (define-syntax (get-current-source stx)
>    (datum->syntax
>     (quote-syntax here)
>     (syntax-source stx)
>     stx))
> 
> Macro get-current-source works as intended if called at program startup 
> and the program is compiled on the fly with:
> 
> racket program.rkt
> 
> However get-current-source has the unintended property of memorizing the 
> original source location if the program is compiled with raco exe (and 
> then moved).
> 
> Is there a way in racket to obtain the path of the application program?
> 
> 
> Jeff Henrikson
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/a076dfa2-d1a5-3cda-72ae-a30cdb91d
> c31%40gmail.com.

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

Re: [racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset

[Matthew Flatt]

At Fri, 30 Jul 2021 12:56:37 -0700 (PDT), Greg Rosenblatt wrote:
> Is the `parameter * thread * parameterization -> box` part implemented as 
> something like a global weak-hash, or is it built directly into the stack 
> representation?

A parameter holds a key and a thread cell, where the thread cell is
used if the parameter hasn't been `parameterized`. The key is used to
look for a thread cell in a parameterization that's found as a
continuation marks. A thread cell is basically a mutable emphemeron
hash that maps threads to values, plus a default value to use if
there's no mapping for a thread.

So, you probably want something similar, except probably using the key
to look up a continuation mark instead of the parameterization
indirection, and then using "resume cells" instead of "thread cells".

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

Re: [racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset

[Matthew Flatt]

At Sun, 25 Jul 2021 10:35:00 -0700 (PDT), Greg Rosenblatt wrote:
> I was surprised that subsequent re-entries can observe modifications from 
> the earlier ones, since my mental model of dynamic parameters was that 
> their values were retrieved from a fresh dynamic calling context, whose 
> frames are copied each time the delimited continuation is invoked.
> [...]
> I'm also interested in the reasons behind the current design.  Is there a 
> downside to storing parameter bindings directly on the stack, rather than 
> in a thread cell pointed to by the stack?

I think I see what you mean here, but I also think that idea would run
into trouble. A (delimited) continuation is invoked every time you
return a value to a continuation, whether or not that continuation was
captured by `call/cc`. Internally, in fact, the current continuation
frequently gets reified and invoked through returns. I think it would
create a bad interaction among features if a distinction were made
between explicit (applying a captured continuation) and implicit
(returning a value) continuation invocations.

> I'd like to be able to resume that continuation in the same context
> multiple times without observing modifications caused by other
> resumptions. [...] But it looks like dynamic parameters actually rely
> on a shared mutable cell, in this case a thread cell.

Yes, parameters are based on a mapping

   parameter * thread * paramterizization -> box

When you set or look up a parameter value, the thread part comes from
`current-thread`, and the parameterization part comes from a
continuation mark. So, that's why capture and restore within a thread
sees the same box, but capture and restore of a continuation in a
different thread gets a different box.

I think you want to introduce a notion of "resume" that replaces the
thread part of the mapping, plus a replacement notion of
parameterization. That is, each time you resume, the applied
continuation should extend one that maps an internal mark to the
current resume. A replacement for `parameterize` would also install a
mark (with a different key) to identify a "parameterization", while
also mapping the parameter * parameterization * resume to a fresh box.
When you look up a parameter value or mutate a parameter, the current
mark for the resume and the current mark for the parameterization would
let you find the right box.

It may be best to have a "parameterization" specific to each
"parameter" (i.e., a separate mark for each parameter), instead of
aggregating them in the way `parameterize` does. In the case of threads
and parameters, aggregation makes it easier to create a new thread that
inherits the parameterization of the creating thread. But if you don't
need that, aggregation also works less well with delimited continuation
capture, because `parameterize` captures all parameter values and not
just the ones that are set in the `parameterize` form.

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

Re: [racket-users] The history of hygiene for definition contexts

[Matthew Flatt]

At Wed, 28 Jul 2021 02:31:12 -0500, Alexis King wrote:
> So, my question: when was hygiene for internal definitions first worked
> out, and did it make it into any papers, specifications, or documentation?
> Hopefully someone (probably Matthew) can provide some insight.

As far as I know, "Macros that Work Together" was the first attempt to
pin down internal-definition contexts, at least in a form other than a
full macro-system implementation. (The R6RS chapter 10 approach is
mostly "don't do that".)


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/20210728081247.116%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Can I get the behavior of `overment` followed by `augride` with a single class?

[Matthew Flatt]

I agree that this doesn't look possible within a single class, but I
don't see any problem with the pattern (aside from being awkward to
write). As far as I can tell, it would make sense for `class` to
support new a case that fuses your `overment` plus `augride` steps.
Internally, that would create a new index for the method while wiring
`super` in subclasses directly to the superclass implementation.

Are there other useful variants that are not currently supported (at
least directly)? Why wasn't this one a blank space in the table of
possibilities that we sketched in the super+inner paper? I don't know.

At Sat, 17 Jul 2021 00:10:10 -0500, Alexis King wrote:
> Hello,
> 
> While doing some OOP in Racket today, I found myself in a situation that
> would benefit from two seemingly contradictory things:
> 
>1.
> 
>I want to be able to override a superclass method, and I want to be
>certain that I get to handle the method before any of my subclasses do.
>This suggests I want to use inner.
>2.
> 
>At the same time, I want my subclasses to be able to override this
>method, not augment it. If I call inner and my subclass calls super,
>control should jump to *my superclass*.
> 
> In other words, I want to get a sort of “first try” at handling the method
> so that if I choose to, I can neglect to call my subclass’s implementation
> altogether. But if I decide *not* to handle it, then I want super-style
> dispatch to proceed as if my class were never there at all.
> 
> At first, I thought this wasn’t possible using Racket’s class system, since
> if I override my superclass’s method using overment, the subclass
> necessarily cannot use super, violating requirement 2. Yet if I use override,
> I don’t get the “first try” I want, violating requirement 1. However, after
> some thought, I realized it’s possible if I’m willing to use *two* classes
> rather than one:
> 
> (define my-superclass%
>   (class object%
> (define/public (m x) `(foo ,x))
> (super-new)))
> 
> (define my-class%
>   (let ()
> (define-local-member-name super-m)
> (class (class my-superclass%
>  (define/public (super-m x)
>(super m x))
>  (define/overment (m x)
>(if (not x)
>'skip
>(inner (error "impossible") m x)))
>  (super-new))
>   (inherit super-m)
>   (define/augride (m x)
> (super-m x))
>   (super-new
> 
> The trick here is twofold:
> 
>1.
> 
>First, I override m using overment, which ensures method dispatch will
>call my implementation first.
>2.
> 
>Next, I augment my own implementation of m using augride, which makes
>the method overridable again in subclasses. To satisfy the other half of
>requirement 2, my augmentation calls my-superclass%’s implementation of m
>via a sort of secret “side channel,” kept private using
>define-local-member-name.
> 
> Using this trick, subclasses of my-class% can still override m, and as long
> as x is non-#f, my sneaky interposition doesn’t seem to have any effect.
> But if x *is* #f, I can short-circuit the computation immediately:
> 
> (define my-subclass%
>   (class my-class%
> (define/override (m x)
>   `(baz ,(super m x)))
> (super-new)))
> 
> (define obj (new my-subclass%))
> (send obj m #t) ; => '(baz (foo #t))
> (send obj m #f) ; => 'skip
> 
> I think this is kind of cute, since it makes it possible to effectively
> conditionally interpose on method dispatch. However, it’s rather awkward to
> write. This brings me to my question: is there any simpler way to do this?
> And are there any hidden gotchas to my technique?
> 
> Thanks,
> 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/CAA8dsae1HR2CVUNq3aC4nc2vpPU6L9f-
> ENor-074LyZnWXgKYg%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/20210719100827.35e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] build error on the package server for a package whose source is a simple URL (not a Git repo)

[Matthew Flatt]

The checksum doesn't go in an "info.rkt" file, but in a
"download.tar.gz.CHECKSUM" file.

More info is here:

https://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3asource%29


Hope that helps,
Matthew

At Thu, 1 Jul 2021 13:14:36 -0700 (PDT), "je...@lisp.sh" wrote:
> I'm not sure if what I'm seeing is a bug or whether I'm using the package 
> system incorrectly, but here goes:
> 
> I just submitted a package to the package server whose source is a simple 
> URL. It's not a Git repo accessible via HTTPS; it's a Fossil repo, with a 
> server running that serves up a plain old tar-and-gzip'd directory. The 
> error message from the build process:
> 
> pkg: mismatched checksum on package package source: 
> https://example.com/cool-package/tarball/trunk/download.tar.gz expected: "" 
> got: "a5d851da2832c0b43f7530794987da0a080ebe6d"
> 
> The naive way to read this error message is: OK, I need to specify a 
> checksum. But there's no checksum field in the form on the package server. 
> You can specify a URL and nothing else. After some digging, I found that 
> checksums 
> can be specified in an info.rkt file, but to my mind that shouldn't be 
> necessary. My thinking is: if I just give a simple URL, the package server 
> should just download the thing, make some reasonable guess about the 
> content (in this case, it can be inferred from the media type in the 
> server's response, but barring that, calling the `file` utility will reveal 
> it's a gzip'd tar file, etc.), and we're off to the races. Am I thinking 
> about things incorrectly? Are my expectations too high? What can I do? 
> (Please don't tell me to just use Git!)
> 
> Jesse

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

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

[Matthew Flatt]

At Sun, 27 Jun 2021 21:36:09 +0300, Bogdan Popa wrote:
> While I think the complexity piece is important, I feel like it's worth
> pointing out just how much more expensive the allocation -- and its
> ramifications, like the resulting GC pressure and CPU cache misses -- is
> than one might think. Here's a quadratic version of the code that
> avoids allocations:
> [...]
> On my machine (running Racket CS 8.1), this is faster than the
> `call-with-output-string` version I posted earlier by about 50ms.

That doesn't sound right to me.

Your program does run fast on my machine, but I think it's because this
line doesn't have the intended bad effect:

>   (string-copy! dst 0 dst 0 len) ;; intentionally performing pointless
>  ;; work to be n^2

A `string-copy!` like this will eventually use the C library's
`memmove`, which apparently (and sensibly) doesn't do anything if the
source and destination are the same. Try copying to a `dst2` to get
quadratic behavior.

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

Re: [racket-users] Tilde expansion requirement breaks XDG compliance

[Matthew Flatt]

Thanks! I've pushed a change based on your explanation. I was able to
confirm that it made the `XDG_CONFIG_HOME` environment take effect when
it previously did not, at least.

At Fri, 25 Jun 2021 15:44:53 -0700 (PDT), pastel raschke wrote:
> Racket seems to insist on using ~/.racket as its special place, despite the 
> apparent fix that added XDG compliance. This happens even when I have 
> racket folders neatly set up in all my xdg dirs, and clear ~/.racket* every 
> time.
> 
> Stepping through in a debugger, I found the problem was at line 2038 of 
> rktio_fs.c, where rktio_system_path calls rktio_expand_user_tilde on 
> prefer_home_str. When prefer_home_str is set from an appropriate XDG 
> environment variable, it is specifically checked to be an absolute path by 
> starting with a slash, where the default prefer_home_str starts with a 
> tilde.
> 
> This wouldn't be a problem if rktio_expand_user_tilde did not respond to an 
> absolute path by setting RKTIO_ERROR_NO_TILDE and returning null, or if the 
> error were caught in rktio_system_path and prefer_home were set properly, 
> or if prefer_home_str were not tilde expanded after being set to an 
> absolute path at line 2008 in the first place. The current behavior results 
> in the non-compliant ~/.racket being used, to my great frustration.
> 
> Thank you for your work.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e055e79d-9025-421c-ac17-4d44c5076
> e6bn%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/20210625173733.3d0%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] invalid memory error from parameter with contracted guard

[Matthew Flatt]

Procedures with contracts are usually implemented by structs that have
`prop:procedure`. Those applicable structs are not procedures from Chez
Scheme's perspective. So, in the "Rumble" layer that bridges Chez
Scheme and Racket, care must be taken to use a special `|#%app|` form
instead of direct function application when the function to call might
be from the Racket layer and implemented as an applicable struct.

Parameters are implemented in the Rumble layer, but applying a
parameter's guard procedure didn't use `|#%app|` as it should have. The
repair was to add `|#%app|`.

At Thu, 24 Jun 2021 09:55:39 -0400, David Storrs wrote:
> Great! You're the best, Matt.  What was the issue, if it's simple enough to
> explain?
> 
> On Wed, Jun 23, 2021, 11:53 PM Matthew Flatt  wrote:
> 
> > Hi David,
> >
> > Thanks for the report! This is fixed for the next release and in
> > the current snapshots.
> >
> > The repair was commit
> >
> >   cb959879de21406571fb0127ded88c54e171c0eb
> >
> > See also https://github.com/racket/racket/issues/3865
> >
> >
> > Matthew
> >
> >
> > At Wed, 23 Jun 2021 22:30:53 -0400, David Storrs wrote:
> > > I'm seeing an "invalid memory reference.  Some debugging context lost"
> > > error when using a parameter that has a guard function AND the guard
> > > function is user-defined AND the guard function has a contract on it.
> > What
> > > is the right place to file this aside from the list?
> > >
> > > Demonstration:
> > >
> > > #lang racket/base
> > >
> > > (require racket/contract)
> > >
> > > (define p1 (make-parameter ""))
> > > (displayln "before set p1")
> > > (p1 "ok")
> > > (displayln "before read p1")
> > > (p1)
> > >
> > > (define/contract p2 (parameter/c string?) (make-parameter ""))
> > > (displayln "before set p2")
> > > (p2 "ok")
> > > (displayln "before read p2")
> > > (p2)
> > >
> > >
> > > (define/contract p3 (parameter/c string? integer?) (make-parameter "7"
> > > string->number ))
> > > (displayln "before set p3")
> > > (p3 "8")
> > > (displayln "before read p3")
> > > (p3)
> > >
> > > (define (uncontracted-string->number v)
> > >   (string->number v))
> > >
> > > (define/contract (contracted-string->number v)
> > >   (-> string? number?)
> > >   (string->number v))
> > >
> > > (define/contract p4  (parameter/c string? integer?)  (make-parameter "7"
> > > uncontracted-string->number))
> > > (displayln "before set p4")
> > > (p4 "8")
> > > (displayln "before read p4")
> > > (p4)
> > >
> > > (define/contract p5  (parameter/c string? integer?)  (make-parameter "7"
> > > contracted-string->number))
> > > (displayln "before set p5")
> > > (p5 "8")
> > > (displayln "before read p5")
> > > (p5) ; invalid memory reference.  Some debugging context lost
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups
> > > "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > an email
> > > to racket-users+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> > 
> https://groups.google.com/d/msgid/racket-users/CAE8gKoegLAOk9mHjKRNAJniki_6DHXJe
> > > OKcjPFa75vPkJqemjw%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/20210624080402.4e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] invalid memory error from parameter with contracted guard

[Matthew Flatt]

Hi David,

Thanks for the report! This is fixed for the next release and in
the current snapshots.

The repair was commit

  cb959879de21406571fb0127ded88c54e171c0eb

See also https://github.com/racket/racket/issues/3865


Matthew


At Wed, 23 Jun 2021 22:30:53 -0400, David Storrs wrote:
> I'm seeing an "invalid memory reference.  Some debugging context lost"
> error when using a parameter that has a guard function AND the guard
> function is user-defined AND the guard function has a contract on it.  What
> is the right place to file this aside from the list?
> 
> Demonstration:
> 
> #lang racket/base
> 
> (require racket/contract)
> 
> (define p1 (make-parameter ""))
> (displayln "before set p1")
> (p1 "ok")
> (displayln "before read p1")
> (p1)
> 
> (define/contract p2 (parameter/c string?) (make-parameter ""))
> (displayln "before set p2")
> (p2 "ok")
> (displayln "before read p2")
> (p2)
> 
> 
> (define/contract p3 (parameter/c string? integer?) (make-parameter "7"
> string->number ))
> (displayln "before set p3")
> (p3 "8")
> (displayln "before read p3")
> (p3)
> 
> (define (uncontracted-string->number v)
>   (string->number v))
> 
> (define/contract (contracted-string->number v)
>   (-> string? number?)
>   (string->number v))
> 
> (define/contract p4  (parameter/c string? integer?)  (make-parameter "7"
> uncontracted-string->number))
> (displayln "before set p4")
> (p4 "8")
> (displayln "before read p4")
> (p4)
> 
> (define/contract p5  (parameter/c string? integer?)  (make-parameter "7"
> contracted-string->number))
> (displayln "before set p5")
> (p5 "8")
> (displayln "before read p5")
> (p5) ; invalid memory reference.  Some debugging context lost
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAE8gKoegLAOk9mHjKRNAJniki_6DHXJe
> OKcjPFa75vPkJqemjw%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/20210623215345.2b1%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Why would writing to a pipe fail?

[Matthew Flatt]

At Fri, 18 Jun 2021 05:29:14 -0400, George Neuner wrote:
> My point was that the docs for write-bytes-avail et al specifically 
> mention "flush" of data, and in a way that implies (to me) that there is 
> expected to be something else underlying the buffer to "flush" to, e.g., 
> storage media, network connection, etc., ... something.  But, if I 
> understand correctly, Racket pipes are a library construct and really 
> just a named block of memory.

Agreed, but that named block of memory isn't the "buffer" in the sense
of the port API.

The intent for "buffer" in the Racket API is a thing attached to a port
where data in the buffer is not visible outside the specific port. Data
that's buffered on a file port isn't visible by reading from the file,
for example, and data that's buffered for the write end of a pipe (if
the pipe had a buffer) is not visible to the read end.

I see that I misused the word "buffer" myself in my previous response.
Where I wrote "grow the buffer", I should have written "grow the block
or memory that holds a pipe's data", or something like that.

> So it seems like "flush" is being used in the docs to mean insertion of 
> data into the buffer ...

Into the block of memory, yes. But instead of characterizing a pipe as
all buffer and no device, I'd say that pipe is unbuffered and has only
a device (for lack of a better word). All data written to a pipe is
delivered to the "device" and available to the read end of the pipe.

> which is confusing (to me) and at odds with how 
> the word typically is used in discussions of I/O.

FWIW, I really think this is the same notion of buffer as in the C
library. A `FILE*` object potentially has a buffer, `fflush` moves data
from that buffer to the underlying device, and so on. If you wrap a
Unix pipe in a C-library `FILE*`, then `fflush` pushes data from the C
library buffer (assuming the `FILE*` is made buffered) to the OS ---
even though the OS-level device is just some memory, and that memory
tends to be called as "buffer" at the OS level.

> So the limit value passed to  make-pipe  is only a maximum size for the 
> data buffer, which starts [way too] small and then grows as needed up to 
> the maximum.  Although that does make some sense - I think starting at 
> 16 bytes is a wee bit restrictive: many (most?) real world uses would 
> have to grow it very quickly.

I agree that 16 bytes is too small. Given that a port object is already
on the order of a dozen *words*, an initial size closer to 16 words
makes sense.

> Growing the buffer is expensive in any case and particularly when 
> existing data has to be copied.  With pre-allocated buffer, the I/O call 
> will spend only what time is necessary to copy new data.  That would 
> seem to be the fastest implementation possible.

There is some cost to growing a buffer, but there's also a cost to
allocating a too-large buffer, since that increases GC pressure. For
example, one existing use of pipes is in the HTTP library, where a pipe
is used to communicate incoming POST data to a decoding thread. The
pipe's limit is set to 4096 to promote streaming behavior for large
POST data, bu POST data to be much smaller than 4096 bytes in many
uses.

To get a better handle on relative costs, I tried three implementations
for pipes:

 * the current one, where the the pipe memory always grows by a factor
   of two;

 * initializing the pipe memory to 4096 bytes instead of 16 bytes; and

 * starting with 16 or (more sensibly) 64 bytes for the pipe, but grow
   the memory based on the size of the number of bytes in a write
   request instead of always doubling --- at least up to a new size of
   4096 bytes, after which the doubling algorithm takes back over.

I tried a few benchmarks:

 * a program like the one Shu-Hung posted that allocates and writes
   data to a pipe;

 * a program that alternates writes and reads within a single thread;

 * a program that writes in one thread and reads in another thread,
   with and without a limit on the pipe; and

 * a program that untgzs the Racket v8.0 source repo (because untgz
   uses a pipe to deliver unzipped data from one thread to untarring in
   another thread).

There was a measurable difference only in that first benchmark. For
writes in the range 512 to 32768 bytes, the alternative adaptive
implementations outperformed the current one by 30% on the small end of
that range and 10% for the upper end. I used 1 million iterations, and
the run time for that size range was around 100 ms. (Note that if the
data written to a pipe is later read, that would more or less cut the
difference in half.) The difference between the two new implementations
was in the noise.

Overall, although there's not much difference, the revised adaptive
implementation seems like a win for a small and easily maintained
change to the code, so I expect to push that change.

There's likely still room for improvement. Anyone who is interested
might start at "racket/src/io/port/pipe.rkt".

Re: [racket-users] Why would writing to a pipe fail?

[Matthew Flatt]

At Wed, 16 Jun 2021 17:33:56 -0400, George Neuner wrote:
> On 6/16/2021 3:45 PM, Matthew Flatt wrote:
> > At Wed, 16 Jun 2021 14:25:40 -0400, George Neuner wrote:
> > > It looks like the problem 
> > > is that "flush" is not defined ...
> >
> > Yes, "returns without blocking after writing as many bytes as it can
> > immediately flush" is vague, and more or less intentionally so. The
> > intent it really "writes as much as is convenient, with the guarantee
> > that anything written is completely flushed". Maybe the documentation
> > should be revised to say something more like that.
> >
> > There's not intended to be a guarantee that as much is written as could
> > possibly make sense by `write-bytes-avail`. Implementation issues may
> > make writing additional bytes inconvenient enough that it doesn't
> > happen, for example, even if more is always written on the next
> > `write-bytes-avail*` call. Also, ports are meant to be used in
> > concurrent settings where the notion "as much as possible" is prone to
> > race conditions.
> 
> Dumb question ... why should non-blocking I/O worry about "flush" at 
> all.  Why not behave like native I/O where writes are guaranteed only to 
> get to the I/O buffer?

If I understand what you mean, then that's the intent. But I think
you're using "buffer" in the sense of the OS layer. That's different
than the buffer that you have in, say, the C library. The Racket port
model uses "buffer" to mean the one like the one implemented in a C
library, and "flush" is used also used in the C library sense, and not
in terms of a buffer that might exist in the next layer (which might be
the OS or might not).

> > So, the intent is that you use `write-bytes` when you want to wait
> > until all bytes are written (maybe because you know that will be soon
> > enough, for whatever reason). But when using `write-bytes-avail`, be
> > prepared for a fraction of the bytes to be written, for whatever
> > reason.
> 
> It is not a problem, per se, but it is an issue that with a long string, 
> you may be forced to call  write-bytes-avail  multiple times just to be 
> filling up the port buffer.  That seems very inefficient and is at odds 
> with how native non-blocking I/O calls behave (completing or filling the 
> buffer before returning).

Probably this became more clear with experiments that Shu-Hung and you
reported, but that's what happens, except that trying to write to a
pipe whose buffer is full will then grow the buffer. Naturally, the
buffer grows by doubling --- up to the pipe's capacity limit, if any.

An OS pipe tends to have a fixed size (OS-level) buffer that is
allocated up front, and that serves as both the maximum granularity of
writes and the capacity of the pipe. Racket pipes are meant to work in
those kinds of cases, but also adapt to cases where pipes are small and
numerous or where they have no capacity limit, so the write granularity
and capacity are not so tightly coupled.

There's likely room for improvement. Racket BC pipes absorb more in a
non-blocking write, because MzScheme was very slow in the old days, and
it was worth looping and trying harder in the low layers instead of
having to go back out to slow MzScheme code. For Racket CS, that
slow--fast boundary isn't there, and so the lower layer core tries to
stay as fast as possible by branching and looping less internally, but
I don't really know if that's the best choice.

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

Re: [racket-users] Why would writing to a pipe fail?

[Matthew Flatt]

At Wed, 16 Jun 2021 14:25:40 -0400, George Neuner wrote:
> It looks like the problem 
> is that "flush" is not defined ...

Yes, "returns without blocking after writing as many bytes as it can
immediately flush" is vague, and more or less intentionally so. The
intent it really "writes as much as is convenient, with the guarantee
that anything written is completely flushed". Maybe the documentation
should be revised to say something more like that.

There's not intended to be a guarantee that as much is written as could
possibly make sense by `write-bytes-avail`. Implementation issues may
make writing additional bytes inconvenient enough that it doesn't
happen, for example, even if more is always written on the next
`write-bytes-avail*` call. Also, ports are meant to be used in
concurrent settings where the notion "as much as possible" is prone to
race conditions.

The Racket BC and CS pipe implementations find different things
convenient, in this sense, and that's why they behave differently in
the example. (That is, it's not really about the Racket version, but CS
versus BC.)

So, the intent is that you use `write-bytes` when you want to wait
until all bytes are written (maybe because you know that will be soon
enough, for whatever reason). But when using `write-bytes-avail`, be
prepared for a fraction of the bytes to be written, for whatever
reason.

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

Re: [racket-users] Racket v8.1 [cs] -- Memory leaks with IDE in Win10

[Matthew Flatt]

Hi, and thanks for the report!

That sounds like a bug that has been fixed for the next release,
especially if you opened any HTML page (such as documentation) from
DrRacket.

For more information on a previous report and the repair:

  https://github.com/racket/racket/issues/3832

Snapshot versions with the repair:

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


Matthew

At Tue, 15 Jun 2021 05:41:11 -0700 (PDT), J Fuller wrote:
>  Hi!
> 
> I'm having problems with memory consumption in Racket v8.1 [cs], 64 bit on 
> Windows 10.
> 
> I left the IDE running overnight with a one short file open in the editor 
> (less than 30 lines) but nothing actually running and in the morning, I 
> found it it had consumed over 20GB of RAM (see attached screenshot from 
> Process Explorer). 
> 
> Is there any way I can troubleshoot what's causing this?
> What's the best information to supply to make a good bug report?
> 
> Thanks very much! 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/94f11c62-5e1c-498c-8550-bbda0e70f
> 2b4n%40googlegroups.com.
> 
> 
> --
> [image/png "Screenshot 2021-06-15 082515.png"] [~/Desktop & open] [~/Temp & 
> open]
> .

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

Re: [racket-users] Re: config.rktd

[Matthew Flatt]

At Fri, 4 Jun 2021 14:29:29 -0700 (PDT), Don Green wrote:
> Now that I have learned of: config.rktd,
> I think I'd rather use it, if it can be used to set 
> current-library-collection paths.
> Should I just add to the config.rktd hash list:
>  (current-library-collection paths . 
> '(# 
> # #)) 

To go this route, you will want something like

 (collects-search-dirs . ("/home/don/.plt-scheme/4.2.1/collects" #f))
 
That is, the syntax is the configuration key `collects-search-dirs`,
and the paths have to be in string form. A `#f` means "default paths
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/20210606064404.3b0%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] This v 8.1 collection path looks incorrect...

[Matthew Flatt]

At Fri, 4 Jun 2021 14:46:00 -0700 (PDT), Don Green wrote:
> 
> (current-library-collection-paths)
> '(# 
> # #)
> 
> I suspect the above is incorrect because I think the 8.1 path should be to 
> dir: /pkgs rather than /collects.  Like this:
> #

Just to clarify, "collects" is as intended there. Packages are found
via `current-library-collection-links` (although, as I mentioned in the
other reply, that's not a parameter that you normally need to set).

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

Re: [racket-users] Regarding collections ...

[Matthew Flatt]

At Fri, 4 Jun 2021 14:15:11 -0700 (PDT), Don Green wrote:
> Sounds like ideally I should begin creating my own pkg(s) that are
> outside a collection path, and link it by specifying a
> current-library-collection-links parameter.

Yes, you should use packages. You normally shouldn't need to set the
`current-library-collection-links` parameter, though. Installing a
package will add to the links that are read via
`current-library-collection-links`

> In the mean time I'd like to add the collection path.
> ---
> Currently,
> When I open DrRacket and run: (current-library-collection-paths) it returns:
> '(# 
> # #) 
> which is correct and no problems, however
> when I click on a .ss file in the file-manager, the file is opened in 
> drracket v.8.1 but
> (current-library-collection-paths) returns only:
> '(# #)

This is really a question about how your OS deals with environment
variables and programs that you launch through its graphical interface.
It looks like you're on a Unix-like platform; unfortunately, I don't
know how quite things will work there.

> Is there a more convenient method to achieve what I am after by making some 
> configuration in racket rather than in my file-manager?

Although it's not the way Racket programmers normally work, there is an
option within DrRacket's GUI:

Open the "Choose Language..." dialog from the "Language" menu, then
select "Show Details". There's a configuration panel roughly in the
middle of the right-hand side for adding collects paths.

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

Re: [racket-users] Regarding collections ...

[Matthew Flatt]

At Thu, 3 Jun 2021 20:26:59 -0700 (PDT), Don Green wrote:
> Using DrRacket in linux:
> When I run DrRacket from a terminal,
> 
> (current-library-collection-paths) returns the expected paths, 3 of them.
> 
> However, when I open one of my .ss files which is associated with drracket,
> 
> the file opens in drracket but (current-library-collection-paths) returns 
> only 2 of the 3 desired collection paths.

I think we're missing some context: Why do you expect 3 paths from
`(current-library-collection-paths)`?

A normal configuration would have just 2 paths, but it's possible to
have more due to command-line flags, environment variables, or
configuration in "config.rktd". Do you expect 3 because you have an
environment variable set, or something like that?


> Should I use info.rkt to specify the 3 desired collection paths?

An "info.rkt" file will not change the collection-paths parameter.
Normally, instead of adding new collection paths, new collections are
added through packages. Those packages are found through the
`current-library-collection-links` parameter, which points to files
that contain more paths.


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/20210604072114.df%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Cross-VM method for sending any input port to C runtime?

[Matthew Flatt]

At Sun, 23 May 2021 14:57:42 +, Sage Gerard wrote:
> Is there a cross-VM way to pass an arbitrary input port to the C
> runtime (e.g. via open-input-bytes), such that the C runtime can read
> bytes on its own?

No, not unless you know that the port's implementation is sufficiently
constrained. In general, reading from a port can involve thread
switches and synchronization, and those are not allowed in callbacks
from foreign libraries.

(BC doesn't prohibit non-atomic callbacks as aggressively as CS, but
interacting with the Racket thread scheduler from a callback can go
wrong in various ways with BC, too.)


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/20210523175706.10c%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] how to convert encoded path to something build-path can use?

[Matthew Flatt]

Yes, the format changed in that commit.

The `decode-link-path` function is not meant to be public, although it
could be exposed. But for an approach that works now and with older
versions, the API you want is `links` from `setup/link`, possibly like
this:

  (links #:file (find-links-file) #:with-path? #t)
  (links #:file (find-links-file) #:root? #t)


At Fri, 21 May 2021 11:33:41 -0400, Stephen Chang wrote:
> Hi,
> 
> It seems that, since 8.1, the format of paths in links.rktd has changed?
> 
> Are there new API fns that deal with this new kind of encoded path? Or
> what is the recommended way to process them?
> 
> Something like this? (Is this `decode-link-path` public? I couldnt find it)
> https://github.com/racket/racket/commit/2ac7e21ad422ee322daa4a7e0db318f9b72b6c48
> #diff-51453f6da842dc20af8fe776f54ec99dd15f4f8b7e9e73cd5d45cdeb96e40ef6R49-R52
> 
> I used to pass the paths directly to `build-path` but now it no longer
> works. Here's an example error:
> 
> build-path: contract violation
>   expected: (or/c path-string? path-for-some-system? 'up 'same)
>   given: '(up up #"pkgs" #"racket-lib")
> 
> Any recommendations would be appreciated. Thanks!
> Steve

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

Re: [racket-users] eq? behavior changed on Racket CS?

[Matthew Flatt]

Yes, this is an expected difference. The Racket documentation still
only promises `eq?` for characters with scalar values in the range 0 to
255, but Chez Scheme characters are always `eq?` when they are `eqv?`.

At Thu, 20 May 2021 19:17:04 -0400, Stephen Chang wrote:
> Hi everyone, Has eq? behavior changed with Racket CS? (ie, 8.0+)
> 
> Specifically:
> 
> $ racket79/bin/racket
> Welcome to Racket v7.9 [bc].
> > (eq? (integer->char 955) (integer->char 955))
> #f
> 
> $ plt/racket/bin/racket
> Welcome to Racket v8.1.0.6 [cs].
> > (eq? (integer->char 955) (integer->char 955))
> #t
> 
> Is this expected behavior?
> 
> (I know this has probably been addressed and I wasn't paying
> attention, but I did a quick search of the list and docs and couldnt
> find anything, so just want to double check. Thanks!)
> 
> Steve
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAFfiA1LQw_ECHrgRN%3DfrK9H%2BE8kS
> FFEqdShqSdvXXmfCmcB0Eg%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/20210520172844.159%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] DrRacket run button needs several clicks to work...

[Matthew Flatt]

Hi Don,

This problem in v8.0 has been fixed in v8.1.

Matthew

At Wed, 19 May 2021 09:44:46 -0700 (PDT), Don Green wrote:
> After upgrading to racket v.8.0, the DrRacket 'run' button does not work 
> consistently with one click.
> Previously, a single click of the 'run' button performed it's function.
> Now, I must cycle between clicking on the 'run' button, then click anywhere 
> in the body of the window and repeat until the 'run' function executes.
> Any suggestions?
> Seems like the run button does not acquire focus reliably.
> Anyone else experiencing this frustrating aspect?
> Thanks
> Don.
> (Racket is installed on Ubuntu v.16.04).

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

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

[Matthew Flatt]

Yes, this approach can work. I don't think the existing Racket tools
will help much with persisting a configuration across versions, though,
so you'd probably have to script that.

One potential drawback of your approach is that executables,
documentation, etc., associated with the extra package will get
rendered into the main installation area instead of the "/opt/Racket"
are. That may be fine for your purposes, but a more strictly layered
installation is meant to be possible. It turns out that some pieces
have been missing for layering, and fixing that is an area of current
work (https://github.com/racket/racket/commit/dfbb7040a).

At Sun, 16 May 2021 23:43:52 -0500, Nathaniel W Griswold wrote:
> Hello,
> 
> I was setting up Racket on my linux box and i realized that there are a lot 
> of 
> options for path configuration and i forgot a lot of what i discovered last 
> time i dug into this. I was trying to set up installation scope but maybe a 
> little cleanly and figured someone might have some input.
> 
> I want a package at roughly installation scope, but i kinda wanted to know 
> what 
> was added by me and what was part of the default installation. Is this 
> reasonable or should i just deal with it and dump stuff in 
> $RACKET/share/pkgs? 
> If it is reasonable then what is the best way to set this up?
> 
> Just FYI I did an in-place install of Racket in "/opt/Racket/Racket\ 8.1" 
> symlinked to /opt/Racket...
> 
> I think maybe what i want is to set  to something like
> 
> (in /opt/Racket/etc/config.rktd)
> 
> #hash(... (pkgs-search-dirs . "/opt/Racket 8.1/share/pkgs-system" #f) 
> (links-search-files . ("/opt/Racket/share/pkgs-system/links.rktd" #f)) ...)
> 
> Then i just did a `sudo /opt/Racket/bin/raco pkg install --scope-dir 
> /opt/Racket/share/pkgs-system rash`
> 
> ... and the new package seems to be working fine for my users.
> 
> Is that what i wanted or is there something better? Is there a way to 
> configure 
> config.rktd additions that will persist across upgrades or will i have to 
> update my config.rktd for every racket release? Do other people do this kind 
> of 
> thing or just dump stuff in the installation scope? Maybe there are more 
> options with a unix-style install, i haven't really tried one yet.
> 
> Thanks!
> 
> Nate

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

Re: [racket-users] Re: preview of a cross-compilation tool

[Matthew Flatt]

At Sat, 15 May 2021 05:18:22 -0700 (PDT), "kamist...@gmail.com" wrote:
> Yes it didn't find the libiconv-2.dll in the distribution "lib" sub-folder, 
> only after I added that to my path.

Oh, right... I had forgotten already that the current release does
*not* cross-build correctly, even for a BC build, when the target needs
native libraries. That problem should be fixed in snapshots.

So, you were on the right track trying to use a snapshot, and it just
happens that neither site at the moment manages to cover the
combination of Linux and 32-bit Windows. We'll get the snapshot sites
in line soon, I hope.


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/20210515065117.2f7%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: preview of a cross-compilation tool

[Matthew Flatt]

At Sat, 15 May 2021 03:10:55 -0700 (PDT), "kamist...@gmail.com" wrote:
> I ran raco-cross 
> (installed on racket cs 8.0 [does this cause trouble for racket cs < 8.2 or 
> is it fine because host and target are both bc?]) 

Yes, it's fine because the target is BC (and a host BC is set up as
needed).

> On windows:
> 1. I had to add the lib subfolder in the dist to the path (else the exe 
> would not find the dlls in there).

The intent in a Windows distribution is that the executable and "lib"
folder stay together, as they are in the archive. Was the executable
not able to find the folder content when kept alongside in the same
directory?

> 2. Copy the dlls from /tmp/todays-snapshot/i386-win32-bc/lib/ to the lib 
> subfolder.

Which libraries were needed? They should have been pulled along in the
distribution's "lib" folder automatically, assuming they're referenced
in a Racket module with `define-runtime-path` (which modules like
`racket/draw` and `racket/gui` do for their libraries).

> I also tried the utah snapshots but they don't have i386 builds and the 
> windows7 vm is 32bit,

The Utah snapshot's 32-bit Windows builds have been having trouble, and
it looks like they will fail again today. The Northwestern site
provides 32-bit Windows builds, but it's Linux builds have a naming
issue (so `raco cross` can't find things) that probably will be
resolved in the next build. Unless you need something new for your
code, though, the v8.l release builds should work for BC.


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/20210515053907.348%40sirmail.smtps.cs.utah.edu.

[racket-users] preview of a cross-compilation tool

[Matthew Flatt]

While `raco exe` in v8.1 very nearly supports cross-builds of Racket
executables[*], it's not easy to pass the right flags and set up the
needed target-platform distributions.

The `raco cross` command provided by the new "raco-cross" package wraps
Racket tools to simplify all of that management. For example,

  raco cross  --target x86_64-linux --vm bc  exe example.rkt

is like running

  raco exe example.rkt

but it cross-builds for x86_64 Linux. That build process involves
downloading a minimal racket tarball for the target platform,
installing "compiler-lib" there, downloading a matching minimal build
of Racket for the host platform, and then running the host Racket in
cross-build mode with installed target distribution --- but, again,
`raco cross` takes care of all that.

Just like using `raco exe` on Linux, the generated executable won't
actually work on other machines until you package it in a distribution
using `raco dist`:

  raco cross  --target x86_64-linux --vm bc  dist example-dist example

Naturally, this second invocation of `raco cross` for the same target
uses the installations prepared by the first `raco cross`, so it's
relatively fast.


I expect that `raco cross` will become more useful after the v8.2
release, which will repair cross-compilation for CS executables and
executables with native libraries (like GUI executables). Meanwhile,
it's possible to use `raco cross` with snapshot builds, but you have to
point it at a snapshot site; see the documentation for more
information.


Because juggling multiple installations and versions is a lot of the
work for cross-compilation, `raco cross` can also be a way to get to a
different version of Racket in minimal form. For example,

  raco cross --version 8.0 racket

starts a Racket v8.0 prompt. (The `racket` command is treated specially
by `raco cross`. All other commands are prefixed by `raco`.)


For more information see

  https://docs.racket-lang.org/raco-cross/index.html


[*] Running a cross-built CS executable fails at the very last step of
startup, and that's due to an expander bug for handling top-level
`begin` forms compiled in machine-independent form. We didn't
detect this problem before, because it wasn't part of Bogdan's use
case for cross builds, and because cross-compilation was painful
enough that we didn't actually try other cases.

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

Re: [racket-users] Re-defined constant when dynamically evaluating module forms

[Matthew Flatt]

I think the problem here is that you're re-defining a module. The
`lifted/4` binding is probably a generated one in the module, and
redeclaring the module would require changing `lifted/4` --- and
probably other bindings that you would recognize, but `lifted/4`
happens to be hit first.

To avoid this kind of problem redeclaring a module, maybe you want a
fresh namespace every time, or maybe you want to parameterize `eval`
with `compile-enforce-module-constants` as #f so that redefinition is
allowed.

At Thu, 13 May 2021 02:40:44 +, Sage Gerard wrote:
> I have a program that takes a (trusted) module form as a list and then
> pulls out a provided value using this method. I used syntax/modread and
> generate a pseudorandom id for each value of `trusted` here.
> 
> (define-namespace-anchor anchor)
> (define module-namespace (namespace-anchor->namespace anchor))
> (define (add trusted)
>    (eval trusted module-namespace)
>    (dynamic-require `',(cadr trusted) 'data))
> 
> Full disclosure: I don't know how to do better. I figured that this
> wasn't the best way to do it to begin with because I get the following
> error under `raco test`'s runtime configuration.
> 
> define-values: assignment disallowed;
>   cannot re-define a constant
>    constant: lifted/4
>    in module:'pkgdef1620873248
> 
> I don't know what "lifted/4" is.
> 
> If I am bringing in module forms that I trust, what's the best way to
> dynamically evaluate them and pull out a provided value without running
> into that error?
> 
> --
> 
> ~slg
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e0a048c8-77ac-5126-5bef-226ecbe90
> 6dc%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/20210512204617.0%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] copy-file does not preserve file attributes on linux version of Racket...

[Matthew Flatt]

At Mon, 10 May 2021 17:16:53 -0700 (PDT), Don Green wrote:
> From Racket doc: "File permissions are transferred from src to dest; on 
> Windows, the modification time of src is also transferred to dest."
> 
> Is the above line meant to imply that a unix/linux version of Racket will 
> NOT preserve file attributes using copy-file?

Yes, that's right.

The intent is to mirror the most common convention for file copies on
each platform. On Unix, `cp` sets the copied file's timestamp to the
current time. On Windows, `copy` gives the copy the original file's
timestamp. (These conventions are also reflected by the system APIs
that racket uses.)


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/20210511051842.d4%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: custom byte encoders?

[Matthew Flatt]

A new custom port sounds like the right idea. The `reencode-input-port`
and ``reencode-output-port` implementations in
"collects/racket/port.rkt" are tied to byte converters, but they should
be the right idea and could be generalized to other conversion
functions. You might have to copy them for now, but you could propose
changes so that future Racket versions would have the right
abstraction.

Matthew

At Fri, 23 Apr 2021 00:20:43 -0700 (PDT), "je...@lisp.sh" wrote:
> The more I read in section 4.5.4 the more it dawns on me that what I'm 
> after may not be possible without (a) a custom patched version of Racket 
> and/or (b) a custom patched version of libiconv. An alternative -- I think 
> -- would be a custom input port, but even that might require (a) and/or (b) 
> above. Naturally, I'd prefer not to have to have a private variant of 
> Racket, and I'd rather not roll my own encoder in C. If there's no other 
> way, I'll do it. But maybe I'm overlooking something simpler.
> 
> On Friday, April 23, 2021 at 7:01:45 AM UTC+2 je...@lisp.sh wrote:
> 
> > Is it possible to make your own byte encoder? Section 4.5.4 of the 
> > reference talks about them and describes the handful of built-in ones. I 
> > don't see a way of making my own byte encoders, though. I'd like to have my 
> > own way of validating bytes and performing replacements, similar to what is 
> > done with the "UTF-8-permissive" encoder (for example, certain junk 
> > characters get replaced by #\uFFFD), but I'd like to do a bit more than 
> > that. For example, I'd like replace some exotic but otherwise valid UTF-8 
> > characters with #\uFFFD. It seems that the only way to do that is to write 
> > my own custom input (or output) port, with the validation/replacement logic 
> > contained within the custom port's peek/read-bytes/write-bytes procedures. 
> > Or perhaps I overlooking something?
> >
> > Jesse
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/2a29be0f-382d-44ee-b691-91c6b527f
> c48n%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/20210423065343.db%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] parts as the top-level unit in books

[Matthew Flatt]

You can use 'grouper as a style property for a `part` that is meant to
be a *part*.

https://docs.racket-lang.org/scribble/core.html?q=part#%28def._%28%28lib._scribble%2Fcore..rkt%29._part%29%29

At Wed, 21 Apr 2021 07:56:33 -0700 (PDT), Shriram Krishnamurthi wrote:
> The Scribble Book format
> 
> https://docs.racket-lang.org/scribble/Book_Format.html?q=scribble%20book
> 
> has the *chapter* as the highest-level unit. For a book with lots of 
> chapters, it's useful to have a higher-level unit, like a *part*. (E.g., *How 
> to Design Programs* is broken down by parts, and the parts contain 
> chapters.)
> 
> What's the cleanest way to configure Scribble to do parts atop chapters?
> 
> Thanks,
> Shriram
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/81334a4e-d6a8-42a5-90b6-212633c39
> fb0n%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/20210421085934.26b%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Cannot attach submodule to namespace

[Matthew Flatt]

Yes, attaching a module instances doesn't `require` it anywhere.

(Sorry --- I didn't look at your program closely enough to work out
whether you meant to require it, start out with a non-empty namespace,
or something else.)

At Fri, 16 Apr 2021 18:02:47 +, Sage Gerard wrote:
> Yes. The error changed to "hello: unbound identifier, also no #%app ..."
> for me, so I also had to add `(namespace-require (quote-module-path
> restricted) ns)` to get it working.
> 
> Were you expecting that I had to do that too? The docs for the
> `make-base-*-namespace` procedures make it sound like attaching is
> sufficient.
> 
> 
> On 4/16/21 1:51 PM, Matthew Flatt wrote:
> > The name `'restricted` is allowed as a shorthand in `require` because
> > `require` knows what module it's in. The `namespace-attach-module`
> > function does not try to infer a module context from the namespace
> > argument; it uses the namespace argument only for its registry. So, you
> > need to use the full name of the submodule.
> >
> > The `quote-module-path` form expands to a full name using its syntactic
> > context (i.e., the enclsoing module's name), so
> >
> >(namespace-attach-module (namespace-anchor->namespace a)
> > (quote-module-path restricted)
> > ns)
> >
> > is probably what you want.
> >
> >
> > At Fri, 16 Apr 2021 17:29:28 +, Sage Gerard wrote:
> >> Why does this raise "namespace-attach-module: module not declared (in
> >> the source namespace)"?
> >>
> >> I expected that the `restricted` submodule would be both declared and
> >> instantiated by the time control reached `namespace-attach-module`.
> >>
> >> (module anon racket/base
> >>     (module restricted racket/base
> >>       (provide #%app #%datum #%top hello)
> >>       (define (hello h) h))
> >>     (require 'restricted)
> >>     (define ns (make-empty-namespace))
> >>     (define-namespace-anchor a)
> >>     (namespace-attach-module (namespace-anchor->namespace a) ''restricted 
> >> ns)
> >>     (displayln (eval '(hello "world") ns)))
> >>
> >> --
> >> ~slg
> 
> --
> ~slg
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e11dff02-0a27-06bd-9b4c-128f15e65
> 849%40sagegerard.com.

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

Re: [racket-users] Cannot attach submodule to namespace

[Matthew Flatt]

The name `'restricted` is allowed as a shorthand in `require` because
`require` knows what module it's in. The `namespace-attach-module`
function does not try to infer a module context from the namespace
argument; it uses the namespace argument only for its registry. So, you
need to use the full name of the submodule.

The `quote-module-path` form expands to a full name using its syntactic
context (i.e., the enclsoing module's name), so

  (namespace-attach-module (namespace-anchor->namespace a)
   (quote-module-path restricted)
   ns)

is probably what you want.


At Fri, 16 Apr 2021 17:29:28 +, Sage Gerard wrote:
> Why does this raise "namespace-attach-module: module not declared (in
> the source namespace)"?
> 
> I expected that the `restricted` submodule would be both declared and
> instantiated by the time control reached `namespace-attach-module`.
> 
> (module anon racket/base
>    (module restricted racket/base
>      (provide #%app #%datum #%top hello)
>      (define (hello h) h))
>    (require 'restricted)
>    (define ns (make-empty-namespace))
>    (define-namespace-anchor a)
>    (namespace-attach-module (namespace-anchor->namespace a) ''restricted ns)
>    (displayln (eval '(hello "world") ns)))
> 
> --
> ~slg

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

Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Matthew Flatt]

Oh, I think I finally get it.

The problem is that the leftover amount is returned by `gen-wheels`.
With scaling by `wheel-scale`, the returned leftover has been scaled
--- but when the leftover is passed back to `gen-wheels` later, it gets
scaled again.

Applying the scale to `WHEEL_DELTA` instead of `amt` solves the
problem, because then the returned leftover amount is on the same scale
as the argument amount.

Thanks for working through this, and I'll push this change!

At Fri, 16 Apr 2021 01:23:16 -0700 (PDT), Dexter Lagan wrote:
> Hi Matt,
> 
>   This works because when amt is smaller than WHEEL_DELTA, the amt value is 
> used directly, see first branch of the cond :
> 
> (cond
>  * [((abs amt) . < . WHEEL_DELTA_S)*
>(case wheel-steps-mode
>  [(one integer) amt]
>  [(fraction)
>   (unless (zero? amt)
> (do-key w msg down lParam #f #f void (/ amt 
> (exact->inexact WHEEL_DELTA_S
>   0.0])]
> 
>   I logged the values with and without the fix. In both cases, I scrolled 
> slowly down  :
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-8
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-40
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-168
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-48
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-200
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-80
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-332
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-92
> 
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-376
> 
>   Amt is often larger than WHEEL_DELTA. After applying the changes 
> (dividing WHEEL-DELTA and removing the wheel-scale mul) :
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-2
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-4
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-6
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-8
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-11
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-13
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-15
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-17
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-19
> 
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-22
> 
> 
> Amt is never above WHEEL_DELTA, which triggers only the first branch of the 
> cond. The amt value is used with no adjustment, hense the precise behaviour.
> 
> Dex
> 
> On Thursday, April 15, 2021 at 1:49:53 PM UTC+2 Matthew Flatt wrote:
> 
> > Thanks for this summary! But I remain puzzled...
> >
> > As I understand it, `wheel-scale` ends up being 4 on your machine. So
> > removing the multiplication by `wheel-scale` means that `amt` is 1/4 of
> > what it used to be. But `amt` is effectively always divided by
> > `WHEEL_DELTA`, which you've also divided by 4 in switching to
> > `WHEEL_DELTA_S`.
> >
> > It seems like those factors of 1/4 would cancel out. Do the numbers
> > passed to `do-key` end up being different in some way that I'm missing?
> >
> > Matthew
> >
> > At Mon, 12 Apr 2021 04:13:16 -0700 (PDT), Dexter Lagan wrote:
> > > I started a new thread as the original topic no longer matched.
> > > I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was 
> > > right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs 
> > in 
> > > DrRacket's editor. The only two changes required to get smooth/accurate 
> > > scrolling on touchpad gestures and trackpoint are therefore:
> > > 
> > > In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels 
> > private 
> > > method:
> > > 
> > > (let loop ([amt (* wheel-scale amt)])
> > > to
> > > (let loop ([amt amt])
> > > 
> > > and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:
> > > 
> > > (define/private (gen-wheels w msg lParam amt down up)
> > > (define WHEEL_DELTA_S (/ WHEEL_DELTA 4))
> > > (let loop ([amt amt])
> > > (cond
> > > [((abs amt) . < . WHEEL_DELTA_S)
> > > (case wheel-steps-mode
> > > [(one integer) amt]
> > > [(fraction)
> > > (unless (zero? amt)
> > > (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> > > WHEEL_DELTA_S
> > > 0.0])]
> > > [(negative? amt)
> > > (case wheel-steps-mode
> > > [(one)
> > > (do-key w msg down lParam #f #f void 1.0)
> > > (loop (+ amt WHEEL_DELTA_S))]
> > > [(integer)
> > > (defin

Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Matthew Flatt]

Thanks for this summary! But I remain puzzled...

As I understand it, `wheel-scale` ends up being 4 on your machine. So
removing the multiplication by `wheel-scale` means that `amt` is 1/4 of
what it used to be. But `amt` is effectively always divided by
`WHEEL_DELTA`, which you've also divided by 4 in switching to
`WHEEL_DELTA_S`.

It seems like those factors of 1/4 would cancel out. Do the numbers
passed to `do-key` end up being different in some way that I'm missing?

Matthew

At Mon, 12 Apr 2021 04:13:16 -0700 (PDT), Dexter Lagan wrote:
>   I started a new thread as the original topic no longer matched.
> I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was 
> right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs in 
> DrRacket's editor. The only two changes required to get smooth/accurate 
> scrolling on touchpad gestures and trackpoint are therefore:
> 
> In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels private 
> method:
> 
> (let loop ([amt (* wheel-scale amt)])
> to
> (let loop ([amt amt])
> 
> and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:
> 
>   (define/private (gen-wheels w msg lParam amt down up)
> (define WHEEL_DELTA_S (/ WHEEL_DELTA 4))
> (let loop ([amt amt])
>   (cond
> [((abs amt) . < . WHEEL_DELTA_S)
>  (case wheel-steps-mode
>[(one integer) amt]
>[(fraction)
> (unless (zero? amt)
>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> WHEEL_DELTA_S
> 0.0])]
> [(negative? amt)
>  (case wheel-steps-mode
>[(one)
> (do-key w msg down lParam #f #f void 1.0)
> (loop (+ amt WHEEL_DELTA_S))]
>[(integer)
> (define steps (quotient (- amt) WHEEL_DELTA_S))
> (do-key w msg down lParam #f #f void (exact->inexact steps))
> (loop (+ amt (* steps WHEEL_DELTA_S)))]
>[else
> (do-key w msg down lParam #f #f void (/ (- amt) (exact->inexact 
> WHEEL_DELTA_S)))
> 0.0])]
> [else
>  (case wheel-steps-mode
>[(one)
> (do-key w msg up lParam #f #f void 1.0)
> (loop (- amt WHEEL_DELTA_S))]
>[(integer)
> (define steps (quotient amt WHEEL_DELTA_S))
> (do-key w msg up lParam #f #f void (exact->inexact steps))
> (loop (- amt (* steps WHEEL_DELTA_S)))]
>[else
> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> WHEEL_DELTA_S)))
> 0.0])])))
> 
> Happy Monday,
> 
> Dex
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/28e13460-c86d-4967-aa25-5527d672e
> 711n%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/20210415054949.249%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

My guess (will investigate) is that I broke things with this commit:

https://github.com/racket/draw/commit/a6558bdc18438e784c23d452ffd877dac867a7fd



At Tue, 13 Apr 2021 13:41:45 -0500, 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-36f9ab5b7d7507d1da5b3d
> 5d4e45a7b0%40pckswarms.ch
> > 
>  d5d4e45a7b0%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/CAL3TdOPmxHoejvgz3g5LxzRjJuybBg%2
> B86KYVMgp8xcy_EBDm8Q%40mail.gmail.com.
> 
> 
> --
> [image/png "Screenshot 2021-04-13 at 20.35.22.png"] [~/Desktop & open] 
> [~/Temp 
> & open]
> .

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

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Sat, 10 Apr 2021 17:26:21 +, Dexter Lagan wrote:
>   By default it’s set to ‘one. 

But for an editor, this line changes it to 'integer:

https://github.com/racket/gui/blob/master/gui-lib/mred/private/wxme/editor-canvas.rkt#L237

Or, at least, it should --- and it does in my installation, which I
checked by logging inside `gen-wheels`. That's why I'm confused that
changing the default would do anything.

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

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Sat, 10 Apr 2021 03:52:47 -0700 (PDT), Dexter Lagan wrote:
> DrRacket feels 

I see that you did say DrRacket, so I remain puzzled. Are you seeing a
value other than 'integer when `gen-wheels` is called in a stock v8.0?


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/20210410112240.2e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

Are you scrolling in DrRacket's editor or in some other application?

I'm surprised that change to the initial value of `wheel-steps-mode`
has an effect, but maybe my confusion is that I'm thinking of DrRacket.
An editor canvas calls `set-wheel-steps-mode` in its constructor to set
the mode to 'integer, so scrolling in DrRacket is using 'integer mode.
But the default of 'one is meant to keep scrolling behavior the way it
used to be for other windows, including a plain canvas, unless a
program requests otherwise by calling `wheel-event-mode` on the window.

The definition of `WHEEL_DELTA` shouldn't change, since that's a
Windows constant. It's interesting that reducing the scaling of wheel
steps makes scrolling behave better for you, though, and I'm not clear
on why.

At Sat, 10 Apr 2021 04:24:36 -0700 (PDT), Dexter Lagan wrote:
>   So in conclusion, only two changes required:
> 
> In const.rkt:
> (define WHEEL_DELTA 120)
> to
> (define WHEEL_DELTA 30)
> 
> In Window.rkt:
> (define wheel-steps-mode 'one)
> to
> (define wheel-steps-mode 'integer)
> 
>   The change to const.rkt may affect a lot more code, I'll let you decide 
> if this change should be left local to gen-wheels.
> It fixes the direction change delay, as well as slow/erratic scrolling on 
> the Thinkpad's trackpoint.
> 
> Dex
> On Saturday, April 10, 2021 at 12:54:33 PM UTC+2 Dexter Lagan wrote:
> 
> >   One precision: this work for Racket 8.0 BC release. There might have 
> > been changes made to current.
> > DrRacket feels as smooth as Sublime Text with this change, a completely 
> > different experience. I'd like to make a proper commit if somebody held my 
> > hand to do so.
> >
> > Dex
> >
> > On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:
> >
> >> Hi again,
> >>
> >>   After playing around with the gen-wheels procedure and comparing its 
> >> code with the WM_HSCROLL handling, I was able to get fast, accurate and 
> >> smooth scrolling for both mouse and touchpad by switching the 
> >> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. 
> >> Here's the updated code :
> >>
> >> 
> >>   (define wheel-steps-mode 'integer)
> >>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
> >>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
> >>
> >>   (define/private (gen-wheels w msg lParam amt down up)
> >> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
> >> (let loop ([amt amt])
> >>   (cond
> >> [((abs amt) . < . AUG_WHEEL_DELTA)
> >>  (case wheel-steps-mode
> >>[(one integer) amt]
> >>[(fraction)
> >> (unless (zero? amt)
> >>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> >> AUG_WHEEL_DELTA
> >> 0.0])]
> >> [(negative? amt)
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg down lParam #f #f void 1.0)
> >> (loop (+ amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
> >> (do-key w msg down lParam #f #f void (exact->inexact steps))
> >> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg down lParam #f #f void (/ (- amt) 
> >> (exact->inexact AUG_WHEEL_DELTA)))
> >> 0.0])]
> >> [else
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg up lParam #f #f void 1.0)
> >> (loop (- amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient amt AUG_WHEEL_DELTA))
> >> (do-key w msg up lParam #f #f void (exact->inexact steps))
> >> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> >> AUG_WHEEL_DELTA)))
> >> 0.0])])))
> >> 
> >>
> >> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt wrote:
> >>
> >>> At Mon, 5 Apr 2021 14:29:22 -0700 (PDT), Dexter Lagan wrote: 
> >>> > I installed the latest build, and it does start. Generated executable 
> >>> is 
> >>> > 80MB vs 32MB for 7.9 BC, about 10MB more than 8.0 release. 
> >>>
>

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Wed, 7 Apr 2021 14:08:00 -0700 (PDT), Dexter Lagan wrote:
> One last thing, I noticed that a small window appears top-left corner of 
> the screen before the full DrRacket window opens since 8.0.0.1x :

That window's full title turns out to be "Recompiling quickscripts...".
It's shown and hidden too quickly to see on my machine (probably
between GUI sync points).

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

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Mon, 5 Apr 2021 14:29:22 -0700 (PDT), Dexter Lagan wrote:
>   I installed the latest build, and it does start. Generated executable is 
> 80MB vs 32MB for 7.9 BC, about 10MB more than 8.0 release.

That difference is again related to the compilation paths, but this
time the likely result is that the v8.1 release will be larger in the
way you saw here.

In the cross-compilation path that the release builds use, there was an
unintended layer of compression. (I noticed the size difference before,
but had not yet investigated.) Checking that again, if the extra layer
is used, the 10% or so savings in file size causes a 5% decompression
slowdown for loading. Compressing just the code, meanwhile, makes load
times faster on machines that I tried. So, I think the current
(non-cross) default is still the best choice for most situations, and
I'll adjust cross-compilation to match.

We can make the extra layer of compression an option for someone who
needs to minimize file size. But a more relevant effect may be the
existing configure-time option to compress boot files...


Compressing embedded boot files would save 30 MB, which would make a
big difference in your case. Compressed boot files take 20-40ms longer
to load on a typical machine, which is significant relative to the
minimal load time, but it's very little time in many situations.

Boot-file compression was already an option for the `configure` way of
building on Unix (but the option had rotted; now fixed). I've updated
the MSVC build to recognize a `PLT_BOOTFILE_COMPRESS` environment
variable to enable boot-file compression when building that way. So, it
will be easier to build Racket with compressed boot files --- but you
would have to build Racket yourself.

It may be that compressed boot files make sense as the default on
Windows. I'm starting to lean in that direction, but I'm not sure, and
I haven't changed the default for now.

>  I understand that there's a difference between bytecode and compiled 
> binary size with CS, but I'm not certain if we're talking about the Racket 
> distribution itself, or generated executables. Is there any hope to 
> eventually get closer to BC's executable size with CS?

Compressing boot files brings the size of the Racket CS executable/DLL
itself closer to Racket BC --- more like a factor of 2 instead of a
factor of 10 --- and that turns out to be almost half of the size in
your case. But the more code you add in terms of embedded ".zo" files,
the more the size difference will approach a factor of 2 overall; I
don't see a route to big improvements there.

> The raco demod option seemed to do miracles on previous versions, but
> never worked on gracket / gui programs for me.

Restoring `raco demod` has been on my list, and I may get to that soon,
but probably not before v8.1. It may be possible to improve `raco
demod` to support `dynamic-require`d pieces like the platform-specific
backends in `racket/gui`.

>   Also, somehow touchpad scrolling has degraded since 7.9 BC (which was 
> decent, and even had momentum). If I scroll downwards, then upwards, it 
> keeps going down for another 1 second before switching direction, and 
> momentum is no longer simulated. If I use the scrollbar, it scrolls fast 
> and smooth, with no direction problem.

I don't know what happened there. Version 8.0 included a change for
handling scroll-wheel events, but I don't think that's the same kind of
event as touchpad scrolling. You could try changing `(* wheel-scale
amt)` in "share/pkgs/gui-lib/mred/private/wx/win32/window.rkt" back to
just `amt` to make sure that change isn't the reason.

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

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

The archive size is misleading for two reasons:

 * the Northwestern snapshots include a lot more overall content by
   including tests, and

 * compression on the installer counteracts the mistake where the
   content of ".zo" files is not individually compressed; uncompressed
   individual ".zo" files end up compressing better as a group.

A new build is ready just now, where DrRacket starts and the size is
changed (i.e., download size is moderately bigger, unpacked size is
much smaller).

At Mon, 5 Apr 2021 03:24:42 -0700 (PDT), Dexter Lagan wrote:
> Looks like it's the opposite. At the moment Utah's is half the size. I'll 
> install the current Utah's and compare generated executables with 8.0 
> release.
> 
> Utah:
> [image: Utah.png]
> 
> Northwestern:
> [image: North.png]
> 
> On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
> 
> > Hi Matthew,
> >
> >   It is indeed the one from Utah. I’ll give the other one a try and report 
> > back. Thanks for looking into this!
> >
> > Dex 
> >
> >
> >
> > On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
> >
> >> Hi Dex, 
> >>
> >> Are you using a snapshot build from the Utah site --- as opposed to a 
> >> snapshot for Northwestern or some other build? 
> >>
> >> I see that the Utah site's compiled code is twice as big as the 
> >> Northwestern site's compiled code. It looks like the build process for 
> >> Racket at Utah (via Visual Studio) misconfigures the "should compiled 
> >> code be compressed?" flag, while the build process used at Northwestern 
> >> (via MinGW) configures that setting correctly. The distribution builds 
> >> are made in the same way as the Northwestern snapshots. 
> >>
> >> I'll fix the compilation path that the Utah snapshot uses, but it would 
> >> be good to know whether that could be the problem. 
> >>
> >> Thanks, 
> >> Matthew 
> >>
> >> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
> >> > I updated to current again, and executable file size has nearly doubled 
> >> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't 
> >> be 
> >> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
> >> production 
> >> > atm, since it produces the smallest executables (12 MB!). 
> >> > 
> >> > Dex 
> >> > 
> >> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
> >> > 
> >> > > Hello there, 
> >> > > 
> >> > > Two things: 
> >> > > 
> >> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB 
> >> for 
> >> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
> >> and 
> >> > > Racket 8.0 (CS). Because of this, startup times from network drives 
> >> also 
> >> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
> >> revert to 
> >> > > 7.9 non-CS for now; 
> >> > > 
> >> > > - Because of this, I have been trying to reduce file sizes to a 
> >> minimum. I 
> >> > > tried replacing racket/gui by a minimal list of requires to no avail. 
> >> I 
> >> > > tried using the raco demod function to demodularize, but it seems to 
> >> be 
> >> > > broken on recent version of Racket (anything beyond hello world will 
> >> quit 
> >> > > prematurely, racket/gui programs won't run at all). I tried GitHub - 
> >> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
> >> > > <https://github.com/bluerider/flattener> without success (seems 
> >> broken as 
> >> > > well). I also tried compressing executables with UPX, but it also 
> >> breaks 
> >> > > them. 
> >> > > 
> >> > > Does anybody know of a way to reduce final Racket executable file 
> >> sizes 
> >> > > / flatten / demodularize while keeping gui functionality ? 
> >> > > 
> >> > > Dex 
> >> > > 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> Groups 
> >> > "Racket Users" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, send 
> >> an email 
> >> > to racket

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

Hi Dex,

Are you using a snapshot build from the Utah site --- as opposed to a
snapshot for Northwestern or some other build?

I see that the Utah site's compiled code is twice as big as the
Northwestern site's compiled code. It looks like the build process for
Racket at Utah (via Visual Studio) misconfigures the "should compiled
code be compressed?" flag, while the build process used at Northwestern
(via MinGW) configures that setting correctly. The distribution builds
are made in the same way as the Northwestern snapshots.

I'll fix the compilation path that the Utah snapshot uses, but it would
be good to know whether that could be the problem.

Thanks,
Matthew

At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote:
>   I updated to current again, and executable file size has nearly doubled 
> again (120MB vs 70MB). I'd be curious to know if startup time wouldn't be 
> affected by file IO at this point. I'm using 7.9 BC 32 bits in production 
> atm, since it produces the smallest executables (12 MB!).
> 
> Dex
> 
> On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote:
> 
> > Hello there,
> >
> >   Two things:
> >
> > - I noticed a doubling of executable file sizes (from 30MB to 70MB for 
> > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) and 
> > Racket 8.0 (CS). Because of this, startup times from network drives also 
> > doubled (from 5 to 10s for gui programs when using CS). I had to revert to 
> > 7.9 non-CS for now;
> >
> > - Because of this, I have been trying to reduce file sizes to a minimum. I 
> > tried replacing racket/gui by a minimal list of requires to no avail. I 
> > tried using the raco demod function to demodularize, but it seems to be 
> > broken on recent version of Racket (anything beyond hello world will quit 
> > prematurely, racket/gui programs won't run at all). I tried GitHub - 
> > bluerider/flattener: Source Code Level Flattener for PLT Racket 
> >  without success (seems broken as 
> > well). I also tried compressing executables with UPX, but it also breaks 
> > them.
> >
> >   Does anybody know of a way to reduce final Racket executable file sizes 
> > / flatten / demodularize while keeping gui functionality ?
> >
> > Dex
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
> 7adn%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/20210404123156.7e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] 8.0.0.13 on Windows

[Matthew Flatt]

Thanks for the report! This bug has been fixed for the next build.

At Sun, 04 Apr 2021 13:40:45 +0200, "Bruce O'Neel" wrote:
> 
> Hi,  
>   
> When I download the minimial tar file and then run   
>   
> raco pkg install --deps search-auto -i main-distribution  
>   
> everything seems fine, but at then end when I try to run DrRacket I get  
>   
> ptr-set!: cannot install value into non-atomic memory   
>   value: #  
>   destination: #  
>   context...:  
>    C:\Users\rdoneelbr\racket-8.0.0.13\collects\ffi\unsafe.rkt:1468:4: loop  
>    body of 
> "C:\Users\rdoneelbr\racket-8.0.0.13\share\pkgs\gui-lib\mred\private\gdi.rkt"  
>   
> [Exited. Close box or Ctrl-C closes the console.]  
>   
> Is this a known problem?  
>   
> It is fine in 8.0 and 8.0.0.12.  
>   
> 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/20210404112146.91%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

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.

Re: [racket-users] racket-launcher-names and easing the user experience

[Matthew Flatt]

The path for executables in user-scope installation is always like
that. As far as I know, think there's not a great answer for where to
put user-scope executables, especially across platforms.

One more option to consider: add a `raco` command. That avoids the PATH
issue by changing the PATH search into a raco-tool search as controlled
by "info.rkt" files.

At Mon, 1 Mar 2021 10:52:42 +, Laurent wrote:
> Hi all,
> 
> I want to share a program with non-racketeers, as a package/collection
> named myprog (say), and I want to make it as simple as possible for the
> user.
> 
> [The Racket Installation instructions need some work by the way, it's not
> very user friendly on linux. It could at least say that `[sudo] apt install
> racket` should work on debian/ubuntu (thanks Asumu!), but also say to
> otherwise download the .sh and run it with `$ sh racket-...sh`]
> 
> My first idea was to have the user run:
> $ racket -l- myprog args ...
> 
> but I'm told `racket-launcher-names
>  x._%28gentag._18._%28lib._scribblings%2Fraco%2Fraco..scrbl%29%29%29>`
> may make it even simpler as the user could invoke
> $ myprog args ...
> 
> which is neat. Unfortunately, it doesn't seem to be so straightforward due
> to PATH issues:
> I installed a snapshot/nightly as a unix distribution (as I always do), and
> the myprog launcher is successfully created at
> /home//.racket/snapshot/bin/myprog
> but this isn't in my PATH, so it can't be found and the 'neat'
> invocation above doesn't work.
> 
> Questions:
> * Is this specific to my weird snapshot+Unix-style installation?
> * Can I expect this to work trouble-free on Windows, Mac, Linux (at least
> debian/ubuntu) when installing a release the way a new user would do?
> 
> If it requires any work by the user to make it work, it seems that asking
> to do
> $ racket -l- myprog
> is simpler.
> 
> Thanks,
> Laurent
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CABNTSaFfh6wio5YwUqjmoCTLPR_CpS14
> C%2BKw8S-pPKdww-ffDg%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/20210301062653.33e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Retrieve name of defined variable in a syntax form in the expr of define form

[Matthew Flatt]

If you're just interested in the symbolic name "x", as opposed to the
binding identifier, then see `syntax-local-name` or
`syntax-local-infer-name`.

If you want the binding identifier, though, that's not available.

Matthew

At Sat, 27 Feb 2021 20:52:23 +0100, Jos Koot wrote:
> Hi
> 
> Consider:
> (define-syntax (my-syntax stx)  blah ...)
> (define x (my-syntax blah ...)
> 
> Is it possible for syntax my-syntax such as to know (at expansion time)
> that is used as the expr of variable x in the expression of the definition?
> Probably this is possible by redefining syntax define, but can I do it
> without touching syntax define?
> Thanks, Jos

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

Re: [racket-users] Racket v8.0 (!)

[Matthew Flatt]

At Wed, 17 Feb 2021 17:31:04 -0500, Hendrik Boom wrote:
> It looks as if there's no Racket on Chez for 32-bit Linux, though there does 
> seem to be one on Windows.

I've added 32-bit i386 Linux CS to the set of snapshots at Utah:

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

https://www.cs.utah.edu/plt/snapshots/current/installers/racket-current-i386-linux-precise.sh


A 32-bit Linux build makes sense as part of the snapshot service, since
part of the job of the service is to make sure things keep working on
various platforms.

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

Re: [racket-users] file/gzip trouble reading

[Matthew Flatt]

At Tue, 16 Feb 2021 16:03:29 -0500, Ben Greenman wrote:
> Sadly, I've already compressed a few files using
> `call-with-output-string` ... is there an easy way to decompress those
> / undo the UTF-8 encoding?

Unfortunately, the underlying `get-output-string` conversion is lossy,
because bytes that don't form a UTF-8 encoding are converted to U+FFFD.

(I see that the docs say #\? instead of #\uFFFD, and I'll fix the docs.)

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

Re: [racket-users] file/gzip trouble reading

[Matthew Flatt]

At Tue, 16 Feb 2021 15:44:54 -0500, Ben Greenman wrote:
> But in my compressed string, the second
> byte is #o357 for some reason. I'm not sure how that could have
> happened ... some kind of encoding issue with string ports?

Yes.

You want `call-with-output-bytes` on the compress size and
`call-with-input-bytes` on the decompress side. Otherwise, you'll get a
UTF-8 decoding of compressed bytes (which is unlikely to be
meaningful).

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

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

[Matthew Flatt]

At Sat, 6 Feb 2021 01:03:54 + (UTC), "Killian Zhuo (KDr2)" wrote:
> Hi, I use `--enable-racket=` because that I found that without it I can't 
> build 
> Racket CS:
> I ran 
> ``` ./configure --enable-cs --enable-bc --enable-csdefault
> make make install```

True --- that won't work. The Git repo is not set up to work with
`configure`, etc., out of the box.

But a plain `make` in the top-level directory of the Git repo will sort
out the needed bootstrapping automatically. Just use `make` at the top
of the repo --- I'm pretty sure that's what you'll want to do.


For more information, see "build.md" at the top of the repo:

https://github.com/racket/racket/blob/master/build.md#1-building-racket-from-source

As it says there, another possibility is to get a source distribution,
and that will work in the `configure`, etc., way that you expect.


Hope that helps,
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/20210205193215.12e%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

Maybe I missed some context, but why are you using `--enable-racket`?
Normally, with a Git checkout, you'd just use `make cs` and/or `make
bc` in the root directory.

Using `--enable-racket` is mostly for cross compilation.

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

Re: [racket-users] Binding a submodule into a sandbox

[Matthew Flatt]

I think the main problem is that `make-evaluator` is a function, which
means that it doesn't know what module it's called in. So, relative
paths like 'sub or (submod "." 'sub) don't work.

You could use `quote-module-path` from `syntax/location` like this:

 #lang racket
 (require racket/sandbox
  syntax/location)

 (module* sub racket
   (provide foo)
   (define foo "foo"))

 (make-evaluator 'racket #:requires (list (quote-module-path sub)))

This can work because the `quote-module-path` form expands to an
expression at compile time that identifies the enclosing module at run
time.

At Fri, 29 Jan 2021 21:29:49 -0800 (PST), Vincent Lee wrote:
> 
> Hi all,
> 
> I'm trying to create a sandbox to which I expose a limited set of functions 
> and values from the outside. So far I have this:
> 
> #lang racket
> 
> (require racket/sandbox)
> 
> (module* sub racket
>   (provide foo)
>   (define foo "foo"))
> 
> However if I now run
> 
> (make-evaluator 'racket #:requires 'sub)
> 
> I get an error. I also get an error if I try
> 
> (make-evaluator 'racket #:requires (submod "." 'sub))
> 
> I expect this to work and for `foo` to be available in the sandbox.
> 
> A normal `(require 'sub)` works fine, but according to the docs #:requires 
> takes the exact same form arguments as `require`, so I'm not sure what I'm 
> missing.
> 
> Alternatively, what's the cleanest way to achieve my goal of providing a 
> fixed set of functions and variables into a sandbox?
> 
> Thanks in advance.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/53fc8114-3348-4d7b-b915-cb37dac1b
> d25n%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/20210130080711.54%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] synchronization with ffi/unsafe/os-thread

[Matthew Flatt]

At Tue, 26 Jan 2021 14:49:22 +0100, Ryan Culpepper wrote:
> Thanks for the pointer! Those sound useful, but in the spirit of maximum
> caution, is there a guarantee that the write to the box from the new OS
> thread will be visible to the original Racket OS thread when the poller
> tries to read it? Is `box-cas!` or one of the memory-order operations
> needed?

I think enough synchronization is implied by `(signal-received)` and
the way it interacts with the scheduler. That is, there's no guarantee
that the waiting thread sees a box change right away, but signaling the
waiting thread will imply a barrier on both the signaling side and
waiting side, so that the next poll iteration after receiving the
signal will definitely see the update at the latest. If that sounds
right, we could make that a guarantee for signaling and polling.

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

Re: [racket-users] synchronization with ffi/unsafe/os-thread

[Matthew Flatt]

At Tue, 26 Jan 2021 10:25:42 +0100, Ryan Culpepper wrote:
> This "works", but is it reliably safe to use place-channel-put from an OS
> thread? 

No. It's not intended to work from an arbitrary OS thread, and because
`place-channel-put` touches the thread scheduler to enter atomic mode,
I can imagine that it might go wrong either now or with some small
future change.

> Or is there a better way to do this?

Probably the only way currently is to use `unsafe-poller`. See
"rktrl.rkt" in "readline" for an example. It would make sense to make
that part of `ffi/unsafe/thread` or a new `ffi/unsafe` library. (It
would also be good to add `unsafe-make-signal-received` to
`ffi/unsafe/schedule`.)


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/20210126052333.3b8%40sirmail.smtps.cs.utah.edu.

[racket-users] Racket compiler and runtime status report

[Matthew Flatt]

In anticipation of the v8.0 release with Racket CS as the default,
here's this year's update on Racket's compiler and runtime system:

 https://blog.racket-lang.org/2021/01/racket-status.html


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/20210124102520.300%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] scheme_eval_string equivalent for racket-cs

[Matthew Flatt]

That will work if your namespace has `open-input-bytes`, etc. It might
be better to use `racket_dynamic_require` to specifically get the
functions from `racket/base`, applying each with `racket_apply`.

A better strategy might be to have a function that combines all of
these pieces in an embedded module, and then there's just one function
to get and call. In general, that fits better with Racket CS, which
really wants as much as possible to be on the Racket side.

Matthew

At Wed, 16 Dec 2020 08:55:06 -0800 (PST), Dan Dexter wrote:
> I'm porting existing code that is embedding racket and I'm going from 
> racket-bc to racket-cs.
> 
> In racket-bc, the code is calling scheme_eval_string() and 
> scheme_eval_string_all().
> 
> I don't see a direct replacement for these functions in racket-cs.  Based 
> on the embedding example in the docs, I'm currently using the following:
> 
> void EvalString(const std::string& str)
> {
> ptr expr = to_bytevector(str.c_str());
> expr = Scons(Sstring_to_symbol("open-input-bytes"), Scons(expr, Snil));
> expr = Scons(Sstring_to_symbol("read"), Scons(expr, Snil));
> expr = Scons(Sstring_to_symbol("eval"), Scons(expr, Snil));
> racket_eval(expr);
> }
> 
> Would this be equivalent?  And also equivalent to scheme_eval_string_all() ?
> --< Dan >--

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

Re: [racket-users] Using current-process-memory with 'cumulative argument

[Matthew Flatt]

At Tue, 15 Dec 2020 17:00:42 -0800 (PST), Alex Harsanyi wrote:
> I am trying to use `(current-process-memory 'cumulative)` to determine the 
> total memory used by an application, including the memory that was 
> reclaimed by the garbage collector.  I would expect the results from the 
> call to be constantly increasing, and this is indeed the case at a "global" 
> scale: [...]
> 
> However, occasionally, there seems to be a drop in the reported memory use, 

I'm able to replicate that with

 #lang racket

 (define (work n)
   (length (let loop ([n n])
 (if (zero? n)
 '()
 (cons (make-vector n) (loop (sub1 n)))

 (let loop ([u (current-memory-use 'cumulative)])
   (work (random 1000))
   (let ([u2 (current-memory-use 'cumulative)])
 (if (u2 . < . u)
 (error "oops")
 (loop u2

which reports an error fairly quickly for me.


The implementation of

  (current-process-memory 'cumulative)

is

  (+ (bytes-deallocated) (bytes-allocated))

It's possible for a GC to happen at the start of the call to
`bytes-allocated`, which I think would produced the blip you see (i.e.,
there could be bytes not yet attributed to `bytes-deallocated`, but
they get shifted there before `bytes-allocated` runs).

The solution is make that arithmetic atomic with respect to a GC by
disabling signals around the arithmetic. I've pushed that change, and
my test program doesn't error anymore, at least.


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/20201215191117.2fc%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Threading question

[Matthew Flatt]

It sounds like you're running into a problem specifically with things
like the file dialog.

Everything in Racket runs in a thread. When your program starts, it
runs in the "main" thread. Normally, a Racket thread that can run will
run, no matter what other Racket threads are doing. When a
foreign-function call blocks its thread, however, then it blocks all
Racket threads --- at least, all threads in the same place.

Places offer one potential way out, because a blocking foreign call in
one thread does not necessarily block other places. In CS, the
foreign-function calls still have to be somewhat cooperative (by using
`#:blocking? #t` at the level of `_fun` or `_cprocedure`), otherwise
they can block even other places when a garbage collection is needed.
The file dialogs are not currently using `#:blocking? #t`, but I think
they could.

In the case of file dialogs, another option is `finder:common-get-file`
and `finder:common-put-file` from `framework`, which are Racket
implementations of those dialogs instead of calling the
platform-specific dialogs through foreign functions. Whether that's a
good option probably depends on your users.

Finally, Racket CS offers access to OS-level threads through
`ffi/unsafe/os-thread`. That's unlikely to be a good option, though,
because it can't cooperate with Racket's I/O layer.

Matthew

At Tue, 15 Dec 2020 13:12:16 -0500, James Platt wrote:
> In Racket, does a given process have to be in a thread in order to give up 
> time 
> to other threads?  In other words, putting code in a thread does not 
> guarantee 
> it will keep running if execution can move into other code that is not 
> threaded?
> 
> Details:
> 
> I am working on documenting and writing examples for a NAT-Traversal package 
> which is to be contributed as a Racket package.  In order to keep a P2P 
> connection alive, the NAT-Traversal (specifically STUN) process needs to keep 
> sending pings back and forth between the peers.  Otherwise, the firewalls 
> involved will close the ports being used for the connection.  To prevent this 
> from happening, the NAT-Traversal code uses a lot of threading.  However, I 
> am 
> still seeing connections drop.  My example GUI chat client has a file 
> transfer 
> utility included but, if you take too much time in the open/save dialog 
> selecting the file to send, it drops the connection and the file transfer 
> fails.  Do I need to put my GUI in a thread?  Is that the issue?  I'm asking 
> here on the list, rather than just trying it, mainly because I want to be 
> sure 
> that I explain the situation correctly in my documentation.
> 
> James
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/01C7C30C-C75A-4498-A8FB-A5F7B1518
> 1E8%40biomantica.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/20201215113441.2a6%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Racket GUI editor: how read and process keyboard input

[Matthew Flatt]

Although key events from `racket/gui` cannot report the press of Caps
Lock as an independent event, each key event reports whether Caps Lock
is currently on, which I think is relevant here.

For example, using

 (define mainTextArea (new (class text%
 (define/override (on-char e)
   (when (send e get-caps-down)
 (bell))
   (super on-char e))
 (super-new

will play a sound every time there's a key press with Caps Lock
reported, and not affect the result otherwise.

Unfortunately, I see that Caps Lock reporting is not consistent across
OSes. On Mac OS and other Unix variants, the event reports whether Caps
Lock mode is on (and that's the useful information here). On Windows,
the event reports whether the Caps Lock key is currently held down
(which is not so useful here).

I think `racket/gui` for Windows should probably change to report the
Caps Lock state instead of whether the key is being pressed. That would
be a backward-incompatible changes, though; it's possible that some
Racket program for Windows currently uses the keypress state of Caps
Lock like other modifier keys.

Matthew

At Sun, 6 Dec 2020 06:08:11 -0800, Sorawee Porncharoenwase wrote:
> IIRC, capslock can’t be handled by applications. When people customize
> capslock to do something else, what they actually do is to ask their OS to
> redirect the capslock keypress to other keys (say, F2), and then intercept
> these other keys instead.
> 
> To catch keypresses like F2, create your own class that has text% as a
> superclass, and override on-default-char.
> 
> On Sun, Dec 6, 2020 at 5:17 AM Christian Lykke  wrote:
> 
> >
> > I would like to create an editor where I can use capslock
> > or some other key to input special commands
> > somewhat similar to M-x in emacs.
> >
> > with capslock (since I never use capslock anyway):
> >
> > every time I write someting in the editor, a function should
> > run that will do something with the input.
> > If capslock is turned off, the text should just be written
> > in the editor normally.
> > if capslock is on, then the text (letters, numbers ect)
> > should instead be written
> > in the field "commandField". if capslock is on and
> > the input is a space or cariagereturn,
> > then anoter function should run that takes the text
> >  in the "commandField" field as its argument and executes a command.
> > The command could be "increasesize" and
> > then the function would run "select all" and then
> > increase
> > the font size by 1, and finally clear the "commandField".
> > How could I do this?
> >
> > with some other key:
> >
> > It might be better to use another key than capslock,
> > for example a function key.
> > How could I create a boolean variable that
> > changes everytime a specific key (for example f2)
> >  gets pressed?
> >
> > Thank you !
> >
> > Here is the editor code I have so far:
> >
> > #lang racket
> > (require racket/gui)
> >
> > ;first frame of the program
> > (define firstFrame (new frame% [label "An editor that allow you to input
> > commands"]
> >   [width 500]
> >   [height 500]))
> >
> > ;the commands you type should be vissible in this message control
> > (define commandField (new message% [parent firstFrame]
> >   [label "no commands yet..."]))
> >
> > ;the text area
> > (define mainCanvas (new editor-canvas% [parent firstFrame]))
> > (define mainTextArea (new text%))
> > (send mainCanvas set-editor mainTextArea)
> >
> > ;A menu bar for ordinary texteditor functionality
> > (define manubar (new menu-bar% [parent firstFrame]))
> > (define editDropdown (new menu% [label "Edit"] [parent manubar]))
> > (define fontDropdown (new menu% [label "Font"] [parent manubar]))
> >
> > (append-editor-operation-menu-items editDropdown #f)
> > (append-editor-font-menu-items fontDropdown)
> > (send mainTextArea set-max-undo-history 100)
> >
> > (send firstFrame show #t)
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > 
> https://groups.google.com/d/msgid/racket-users/f07ba9b2-df26-4402-bb97-722d2c4f8
> d4dn%40googlegroups.com
> > 
>  8d4dn%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/CADcuegudKjEi_a_bnC3SvUnTkVwokiwL

Re: [racket-users] Big Sur and M1 build, *nix compiling

[Matthew Flatt]

Racket now builds and runs on M1 Macs using a Git repo checkout. If all
goes well, snapshots will appear tomorrow at the Utah snapshot site
linked at

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

Meanwhile, I've uploaded an image here (link will last a few days):

https://www.cs.utah.edu/plt/snapshots/20201205-10ea287/installers/racket-7.9.0.10-aarch64-macosx-cs.dmg


Yes, the M1 MacBook Pro is pretty fast --- about x1.5 as fast as a 2018
i7 MacBook Pro for tasks that aren't primarily about loading files:

   i7   M1
  racket -n   0.08s0.07s
  racket -l racket0.27s0.25s
  racket -cl racket/base  2.50s1.60s
  shootout mandelbrot.rkt 1.40s0.94s
  racket -l drracket ... -e '(exit)'  4.42s2.79s
  make base in fresh Git clone[1]  7m02s5m02s
  raco setup[2]   21m08s   14m48s

[1] After `make pb-fetch` to avoid network time
[2] After `make`, `raco setup --clean`, and `rm -r racket/docs`

Since we had an AArch64 backend for Chez Scheme, porting Racket CS was
mostly straightforward. Racket BS also works, but there's no AArch64
JIT in BC, so it can be slow. Some work was needed to conform to W^X
requirements (i.e., can't make memory both executable and writable at
the same time), but unlike other W^X environments that I've tried to
use, the OS provides good support for code-generating programs.
Building third-party libraries like Cairo went better than expected. I
spent most of my porting time and effort being confused about aspects
of code signing, but it seems reasonable enough in the end.

Matthew

At Tue, 1 Dec 2020 20:51:46 -0700, Matthew Flatt wrote:
> There is some information here:
> 
>  https://github.com/racket/racket/issues/3513
> 
> Mostly, though, it's "stay tuned" for at least a few more days.
> 
> 
> At Tue, 1 Dec 2020 16:11:18 -0800 (PST), Tom Sturgeon wrote:
> > 
> > 
> > Racket 7.9 seg faults when starting DrRacket for the built versions.
> > 
> > The operating system is macos Big Sur on the Apple M1.
> > 
> > I tried downloading the source and rebuilding, but I get an error during 
> > the make phase.
> > 
> > Library/Developer/CommandLineTools/usr/bin/make cstartup_./racketcgc -cu 
> > ./src/startup-select.rkt echo "Bad startup choice, probably an error 
> > running startup-select.rkt" Bad startup choice, probably an error running 
> > startup-select.rkt exit 1
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 
> to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/20201201205146.2f5%40sirmail.smtp
> s.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/20201205124642.190%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Big Sur and M1 build, *nix compiling

[Matthew Flatt]

There is some information here:

 https://github.com/racket/racket/issues/3513

Mostly, though, it's "stay tuned" for at least a few more days.


At Tue, 1 Dec 2020 16:11:18 -0800 (PST), Tom Sturgeon wrote:
> 
> 
> Racket 7.9 seg faults when starting DrRacket for the built versions.
> 
> The operating system is macos Big Sur on the Apple M1.
> 
> I tried downloading the source and rebuilding, but I get an error during 
> the make phase.
> 
> Library/Developer/CommandLineTools/usr/bin/make cstartup_./racketcgc -cu 
> ./src/startup-select.rkt echo "Bad startup choice, probably an error 
> running startup-select.rkt" Bad startup choice, probably an error running 
> startup-select.rkt exit 1

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

Re: [racket-users] snappier place startup time

[Matthew Flatt]

Just to elaborate a little more:

The difference is because the `test` submodule can be loaded
independently from the compiled form. Loading the submodule from source
requires loading the enclosing module, too (which depends on
`racket/place` and more).

At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote:
> Awesome, thanks!
> 
> Nate
> 
> 
> On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt 
> wrote:
> 
> > Almost certainly the problem is expansion time. If I run that program
> > on my machine, it takes about 200 ms. But if I compile the file to zo
> > first with `raco make`, then it takes about 40 ms, basically identical
> > to `racket/base`.
> >
> > Sam
> >
> > On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold 
> > wrote:
> > >
> > > Oops, i am having some issues with not getting to the list from my other
> > email address. Here is a reply i sent for the record.
> > >
> > > ---
> > >
> > > Thank you, Matthew.
> > >
> > > The following code takes around 250ms on my machine. Any idea why? I was
> > expecting it to be fast since the module is based on racket/base.
> > >
> > > #lang racket/base
> > >
> > > (require syntax/location)
> > > (require racket/place)
> > >
> > >
> > >
> > > (module test racket/base
> > >  (provide place-main)
> > > racket
> > >  (define (place-main pch)
> > >   (void)))
> > >
> > > (time (place-wait (dynamic-place (quote-module-path test) 'place-main)))
> > >
> > > Nate
> > >
> > >
> > > On Tue, Nov 24, 2020 at 8:35 AM Nathaniel W Griswold
> >  wrote:
> > >>
> > >> Thank you, Matthew.
> > >>
> > >> The following code takes around 250ms on my machine. Any idea why? I
> > was expecting it to be fast since the module is based on racket/base.
> > >>
> > >> #lang racket/base
> > >>
> > >> (require syntax/location)
> > >> (require racket/place)
> > >>
> > >>
> > >>
> > >> (module test racket/base
> > >>  (provide place-main)
> > >> racket
> > >>  (define (place-main pch)
> > >>   (void)))
> > >>
> > >> (time (place-wait (dynamic-place (quote-module-path test) 'place-main)))
> > >>
> > >> Nate
> > >>
> > >> On Nov 24, 2020, at 8:16 AM, Matthew Flatt  wrote:
> > >>
> > >> The bottleneck for place startup is loading modules into the new place,
> > >> including modules like `racket/base`.
> > >>
> > >> For example,
> > >>
> > >>  (place-wait (dynamic-place 'racket 'void))
> > >>
> > >> takes around 200ms on my machine, while
> > >>
> > >>  (place-wait (dynamic-place 'racket/base 'void))
> > >>
> > >> takes around 30ms and
> > >>
> > >>  (place-wait (dynamic-place 'racket/kernel 'void))
> > >>
> > >> takes around 10ms.
> > >>
> > >> It sounds like you're already aware that the complexity of the module
> > >> loaded into a place matters, though. Beyond using a minimal set of
> > >> modules, I don't have any way to make place startup faster.
> > >>
> > >> Matthew
> > >>
> > >> At Tue, 24 Nov 2020 05:04:19 -0600, Nate Griswold wrote:
> > >>
> > >> Is there any way to make places startup faster? Even if i do an explicit
> > >> round trip using place-channel-put and place-channel-get on both sides,
> > it
> > >> takes on the order of centiseconds for near empty places to start up.
> > >>
> > >> My program requires the threads for a couple places to be set up before
> > it
> > >> can operate, so this impacts my startup time by quite a bit.
> > >>
> > >> I have one place that has a very simple module and one place with a more
> > >> complicated module. Is there some sequence that i should do things in
> > for
> > >> the minimal startup time? It seems nothing i do really helps much.
> > >>
> > >> Nate
> > >>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Racket Users" group.
> > >> To unsubscribe from this group and stop receiving emails from it, send
> > an
> > >

Re: [racket-users] snappier place startup time

[Matthew Flatt]

The bottleneck for place startup is loading modules into the new place,
including modules like `racket/base`.

For example,

  (place-wait (dynamic-place 'racket 'void))

takes around 200ms on my machine, while

  (place-wait (dynamic-place 'racket/base 'void))

takes around 30ms and

  (place-wait (dynamic-place 'racket/kernel 'void))

takes around 10ms.

It sounds like you're already aware that the complexity of the module
loaded into a place matters, though. Beyond using a minimal set of
modules, I don't have any way to make place startup faster.

Matthew

At Tue, 24 Nov 2020 05:04:19 -0600, Nate Griswold wrote:
> Is there any way to make places startup faster? Even if i do an explicit
> round trip using place-channel-put and place-channel-get on both sides, it
> takes on the order of centiseconds for near empty places to start up.
> 
> My program requires the threads for a couple places to be set up before it
> can operate, so this impacts my startup time by quite a bit.
> 
> I have one place that has a very simple module and one place with a more
> complicated module. Is there some sequence that i should do things in for
> the minimal startup time? It seems nothing i do really helps much.
> 
> Nate
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAM-xLPpvfCHHDDpfNmuTWQOyfYfEJ7v
> m1c_dS7nj3FxaEFVm2Q%40mail.gmail.com.

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

Re: [racket-users] Questions

[Matthew Flatt]

At Mon, 23 Nov 2020 00:14:56 -0600, Nate Griswold wrote:
> Hello. I have a few questions:
> 
> 1) Why do the docs say that racket_eval and racket_apply eval and apply in
> the “initial” or “original” racket thread? I have verified that the thread
> id returned from pthread_self when using racket_apply in c code called from
> a racket place is different from the thread id of the thread i called
> racket_boot on.

The `racket_apply` function was intended for use only in the OS thread
where Racket is booted, and only "outside" to get Racket started. It's
not intended for use in callbacks from Racket.

That's generally true for functions listed in sections 4-6 of "Inside",
and I see that the intent is not remotely clear there. I'll improve the
documentation.

To call back to Racket from C code, you should use the Racket FFI,
where a Racket function that's passed to C gets converted to a function
pointer for the C side. When you call that callback (as a regular C
function call), various bits of Scheme and Racket state get
configured/restored in a consistent way before jumping to the wrapped
Racket code as a callback.

For simple things, it turns out that `Scall0`, etc. would work to
invoke a callback within the Racket context that had called into C, but
there are many pitfalls, so you shouldn't do that.

You definitely should not use `racket_apply` or `racket_eval` from C
that was called from Racket. It will... well, do something. Take the
uncertainly of using `Scall0` and multiply by 100, since functions like
`racket_apply` specifically attempt to interact with the thread
scheduler.

> 2) I noticed that if i racket_eval in c code called by a racket place, i
> can’t evaluate things that would otherwise (in racket code) be available in
> the place’s namespace. What is the correct way to get at things in the
> place’s racket namespace from c code? Is my problem unique to using a
> place, or would i have this problem in a non-place scenario as well?

I think it's probably not just about places, but let me answer the
"correct way" question with the next bullet.

> 3) (related to 2) I want to be able to put and get from a place channel
> from a long-running c function. If i just pass a place channel to the
> function, that is wrong because if i am correct in my thinking (and in what
> i have witnessed) there is a chance that when i go to use that channel in
> the future, it will have been moved by the garbage collector. Is there any
> way to prevent a specific value from being garbage collected, at least for
> the lifetime of my place? This is related to (2) because i actually don’t
> need this functionality if i can just racket_eval to get at the place
> channel from the namespace of the place’s module in the middle of a
> Sactivate_thread / Sdeactivate_thread session.

The best approach here is to hand the C code a callback, which it will
see as plain old C functions. Maybe there's one callback to get from
the channel and another to put to the channel --- where the channel is
in the closure of the function, although the C side has no idea about
closures. If you go that route, then as long as you retain a reference
to the callback closure on the Racket side, the callback function
itself won't move.

Overall, reasoning about the interaction between Racket/Scheme and C
interaction from the C side is very difficult. The more you can arrange
for the C code to oblivious to Racket, the easier things get, because
the Racket-side tools for interacting with C are much better.

> 3) Is there any way to pass a c callback function into racket so that
> racket can call that function? I defined a ctype for the function, but i
> couldn’t think of a way to cast a pointer value passed into racket from c
> to an instance of my ctype (the `cast` function takes existing ctypes and
> not numeric values). Is there any way to manually make a value for my
> function ctype using an existing pointer value?

You can cast from a numeric value by casting from `_intptr` to a
pointer type. For example, this expression creates a function that
tries to jump to address 16 (and crashes, but in gdb you'd see it
crashing with the instruction pointer at address 16):

   (cast 16 _intptr (_fun -> _void))


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/20201123060111.3b5%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] read-line-evt question

[Matthew Flatt]

At Wed, 18 Nov 2020 12:59:46 -0500, George Neuner wrote:
> 
> On 11/18/2020 9:43 AM, Javier Vivanco wrote:
> >
> > I have a question about a read-line-evt 's behaviour.
> > Is this normal this ?
> > > (sync (read-line-evt (current-input-port))
> > 1234
> > ""
> >
> > I want to use a timeout in read-line via sync/timeout
> >
> > but it always gives me the first character
> >
> 
> You are seeing the return value from 'sync' rather than the event data.

I think that was the intent, though, and I think the expected answer is
"1234". But I see that the `read-line-evt` function is not working
right when a port supplies one byte for each peek, which is what
happens in DrRacket.

We'll get this fixed. Thanks for the report!


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/20201118120855.1dd%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Creating threads that prevent main thread from exiting

[Matthew Flatt]

Probably the right choice is to install a flush handler with the
current plumber:

 (define (thread/wait proc)
   (define t (thread proc))
   (plumber-add-flush! (current-plumber)
   (lambda (h) (thread-wait t)))
   t)

That adds a `thread-wait` in the same sense as flushing a stdout buffer
before exiting.


Another possibility is to extend the `executable-yield-handler`, which
the `racket` executable calls just before `exit`:

  (define (thread/wait proc)
(define t (thread proc))
(let ([old (executable-yield-handler)])
  (executable-yield-handler
   (lambda (v)
 (thread-wait t)
 (old v
t)

On difference between those strategies is that a new place won't call
the exectuable yield handler before the place exits, but a place does
tell its plumber to flush everything before exiting. That is, the
executable yield handler is meant to be specific to the whole process,
while plumbers are meant to be a nestable generalization. Another
difference is that the default exit handler triggered by `(exit)`
doesn't try to yield, but it does tell the plumber to flush.

At Mon, 16 Nov 2020 07:39:09 -0800 (PST), Greg Rosenblatt wrote:
> What is the best way to create threads that will prevent a program from 
> exiting until they have completed their work?   I'd like to be able to do 
> this implicitly, without cooperation from the main thread.
> 
> My first experiment uses `shift` to insert uses of `thread-wait` after the 
> rest of the program:
> 
> ```
> #lang racket
> (require racket/control)
> 
> (define (thread/wait proc)
>   (define t (thread proc))
>   (shift k (k t) (thread-wait t)))
> 
> (define t1 (thread/wait (lambda () (let loop () (displayln "t1") (sleep 2) 
> (loop)
> (define t2 (thread/wait (lambda () (let loop () (displayln "t2") (sleep 3) 
> (loop)
> 
> (displayln "end of main thread")
> ```
> 
> This doesn't work, seemingly due to an implicit `reset`/`prompt` around 
> each top-level definition/expression in a module.
> 
> Wrapping the entire module in a trivial `(let () _)` fixes the issue, but 
> this is not desirable:
> 
> ```
> #lang racket
> (require racket/control)
> 
> (let ()
>   (define (thread/wait proc)
> (define t (thread proc))
> (shift k (k t) (thread-wait t)))
> 
>   (define t1 (thread/wait (lambda () (let loop () (displayln "t1") (sleep 
> 2) (loop)
>   (define t2 (thread/wait (lambda () (let loop () (displayln "t2") (sleep 
> 3) (loop)
> 
>   (displayln "end of main thread"))
> ```
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e67b750a-1d9d-42fa-9712-9c03da54
> 75a8n%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/20201116110601.240%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Namespaces and modules

[Matthew Flatt]

At Thu, 12 Nov 2020 23:35:11 +0100, Dominik Pantůček wrote:
> If I however try to achieve the same goal using module form within my
> module, it always fails:
> 
> (module sandbox racket/base
>   (provide #%app #%datum test)
>   (define (test) (displayln 'test)))
> (parameterize ((current-namespace (make-base-empty-namespace)))
>   (namespace-require ''sandbox)
>   (eval '(test)))

Using ''sandbox as an argument to `namespace-require` to refer to a
local module is something like passing 'x to `eval` to try to refer to
a local variable `x`. The `namespace-require` procedure doesn't know
where it's being called from, so it doesn't work.

Try `quote-module-path`, which expands at compile time to effectively
embed its context:

 #lang racket/base
 (require syntax/location)

 (module sandbox racket/base
   (provide #%app #%datum test)
   (define (test) (displayln 'test)))

 (parameterize ((current-namespace (make-base-empty-namespace)))
   (namespace-require (quote-module-path sandbox))
   (eval '(test)))

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

Re: [racket-users] Ubuntu PPA also updated to v7.9

[Matthew Flatt]

Now I see the problem. It seems to be specific to the source
distribution, but since the PPA is derived from a source distribution,
it affects the PPA, too.


A solution is

 raco pkg config --set catalogs \
  https://download.racket-lang.org/releases/7.9/catalog/ \
  ""

That last empty-string argument chains to pkgs.racket-lang.org after
checking the release-specific catalog.


Alternatively, in DrRacket, open "File" -> "Package Manager...", click
the "Settings" tab, and add "https://pkgs.racket-lang.org/;.


The problem: A source distribution has the initial configuration

 (catalogs . ("https://download.racket-lang.org/releases/7.9/catalog/;))

instead of

 (catalogs . ("https://download.racket-lang.org/releases/7.9/catalog/; #f))

The Utah snapshots have the same problem, which suggests that it's not
just the way the release build is configured.


At Tue, 10 Nov 2020 07:37:02 -0800 (PST), "mvcc...@gmail.com" wrote:
> Hi, I'm having a similar issue with the packages.
> After updating to 7.9, the pie package stopped working and "raco pkg 
> install pie" couldn't find anything on catalogs.
> I had to download the source code and install it locally.
> I'm teaching a class using the pie package. It would be jarring if I have 
> to burden the students with manually installing these packages.
> Is there anyway to make "raco pkg install pie" work automatically after the 
> updating?
> 
> Cheers,
> Weixi
> On Monday, November 9, 2020 at 9:18:03 PM UTC-5 evdubs wrote:
> 
> > $ ls ~/.racket
> > 6.11  6.12  7.0  7.1  7.2  7.3  7.4  7.5  7.6  7.7  7.8  7.9  
> > download-cache  racket-prefs.rktd  snapshot
> >
> > The above looks like the location where my user packages are installed (as 
> > in, the packages from raco pkg install).
> >
> > $ ls ~/.config/racket
> > ls: cannot access '/home/evdubs/.config/racket': No such file or directory
> >
> > Evan
> > On Monday, November 9, 2020 at 4:14:28 PM UTC-10 Matthew Flatt wrote:
> >
> >> At Mon, 9 Nov 2020 18:08:51 -0800 (PST), evdubs wrote:
> >> > So I ran:
> >> > $ raco pkg config --set catalogs https://pkgs.racket-lang.org 
> >> > and now I am able to migrate packages. Thank you, Matthew. Maybe this 
> >> is 
> >> > related to my installation being from the PPA.
> >>
> >> Maybe, but I wonder whether it might have something to do with the
> >> switch to XDG paths. Do you have "~/.racket" and/or "~/.config/racket"
> >> directories?
> >>
> >>
> >> 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/b6a61385-2ba6-4540-aa32-76842ec5
> 91a6n%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/20201110090546.72%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Ubuntu PPA also updated to v7.9

[Matthew Flatt]

At Mon, 9 Nov 2020 18:08:51 -0800 (PST), evdubs wrote:
> So I ran:
> $ raco pkg config --set catalogs https://pkgs.racket-lang.org 
> and now I am able to migrate packages. Thank you, Matthew. Maybe this is 
> related to my installation being from the PPA.

Maybe, but I wonder whether it might have something to do with the
switch to XDG paths. Do you have "~/.racket" and/or "~/.config/racket"
directories?


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/20201109191423.3d8%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Ubuntu PPA also updated to v7.9

[Matthew Flatt]

What does `raco pkg config` say? The resolution search doesn't seem to
be trying

 https://pkgs.racket-lang.org

which is where those packages would be found.

At Mon, 9 Nov 2020 17:43:22 -0800 (PST), evdubs wrote:
> Sorry, I should have just included the full error the first time. I get:
> 
> $ raco pkg migrate 7.8
> Packages to install:
>   binaryio
>   feature-profile
>   gregor
>   html-parsing
>   interactive-brokers-api
>   sxml
>   tasks
>   threading
>   webscraperhelper
> 00: Resolving "binaryio" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 01: Resolving "feature-profile" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 02: Resolving "gregor" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 03: Resolving "html-parsing" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 05: Resolving "sxml" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 06: Resolving "tasks" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 04: Resolving "interactive-brokers-api" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> 07: Resolving "threading" via 
> https://download.racket-lang.org/releases/7.9/catalog/
> raco pkg migrate: cannot find package on catalogs
>   package: threading
> raco pkg migrate: cannot find package on catalogs
>   package: html-parsing
> raco pkg migrate: cannot find package on catalogs
>   package: interactive-brokers-api
> raco pkg migrate: cannot find package on catalogs
>   package: sxml
> raco pkg migrate: cannot find package on catalogs
>   package: tasks
> raco pkg migrate: cannot find package on catalogs
>   package: gregor
> raco pkg migrate: cannot find package on catalogs
>   package: binaryio
> raco pkg migrate: cannot find package on catalogs
>   package: binaryio
> 
> Evan
> On Monday, November 9, 2020 at 3:32:04 PM UTC-10 Matthew Flatt wrote:
> 
> > At Mon, 9 Nov 2020 16:28:32 -0800 (PST), evdubs wrote:
> > > Looking at https://download.racket-lang.org/releases/7.9/catalog/, an 
> > > uncaught exception is being thrown. This error is being returned by 
> > other 
> > > versions, too (7.8 and 7.7 at least).
> >
> > When that URL is used as a catalog by `raco pkg`, it doesn't look for
> > HTML files or "index.html" --- and there's currently no "index.html"
> > installed at that path, so that's why you get an address when using the
> > address directly in a browser.
> >
> > But that catalog works for me. For example,
> >
> > raco pkg catalog-show \
> > --catalog https://download.racket-lang.org/releases/7.9/catalog/ \
> > racket-lib
> >
> > shows information for "racket-lib", and
> >
> > raco pkg catalog-copy \
> > https://download.racket-lang.org/releases/7.9/catalog/ \
> > pkgs-copy/
> >
> > creates a local catalog listing many packages.
> >
> >
> > What package couldn't be migrated?
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/a84f5372-8d83-4186-b998-5f9dd7e2
> 5e86n%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/20201109185659.3a8%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Ubuntu PPA also updated to v7.9

[Matthew Flatt]

At Mon, 9 Nov 2020 16:28:32 -0800 (PST), evdubs wrote:
> Looking at https://download.racket-lang.org/releases/7.9/catalog/, an 
> uncaught exception is being thrown. This error is being returned by other 
> versions, too (7.8 and 7.7 at least).

When that URL is used as a catalog by `raco pkg`, it doesn't look for
HTML files or "index.html" --- and there's currently no "index.html"
installed at that path, so that's why you get an address when using the
address directly in a browser.

But that catalog works for me. For example,

  raco pkg catalog-show \
   --catalog  https://download.racket-lang.org/releases/7.9/catalog/  \
   racket-lib

shows information for "racket-lib", and

  raco pkg catalog-copy \
   https://download.racket-lang.org/releases/7.9/catalog/  \
   pkgs-copy/

creates a local catalog listing many packages.


What package couldn't be migrated?

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

Re: [racket-users] Suspending/resuming threads with custodians/benefactors

[Matthew Flatt]

for the first problem, you've found a bug in the Racket CS thread
scheduler (i.e., Racket BC behaves correctly in this case). Suspending
a thread that is sleeping didn't prevent the thread from being woken up
on its previous schedule. I've pushed a repair as commit 7a12b4ac93.

After fixing that bug and using `thread/suspend-to-kill`, the second
part works as expected. But if `t1` is created with `thread`, the
behavior you describe sounds right: `t2` cannot resume a thread that
was created with `thread` and then terminated by a custodian.

Thanks for the report!
Matthew

At Sat, 7 Nov 2020 15:26:17 -0800 (PST), Greg Rosenblatt wrote:
> I'm experimenting with using custodians to manage threads (on Racket 7.8 
> [cs]) and encountering behavior I don't understand.
> 
> I start a looping thread `t1` under a new custodian `c1`.
> 
> I then shutdown `c1` and expect `t1` to stop looping.  If I started `t1` 
> with `thread` then this expectation is met.  However, if I start it with 
> `thread/suspend-to-kill`, it continues looping even after `c1` is shut 
> down.  Is this the correct behavior?
> 
> Additionally, I later start a new thread `t2` under a new custodian `c2`, 
> which attempts to resume `t1` after the shutdown, using itself as a 
> benefactor.  However, `t1` does not seem to resume.  Is this the correct 
> behavior?
> 
> Here is the code I'm working with:
> 
> ```
> #lang racket
> 
> (define c1 (make-custodian))
> (define c2 (make-custodian))
> (define t1 #f)
> (define t2 #f)
> 
> (parameterize ((current-custodian c1))
>   ;(set! t1 (thread/suspend-to-kill  ;; (custodian-shutdown-all c1) fails 
> to suspend this thread
>   (set! t1 (thread
>  (lambda ()
>(let loop ()
>  (displayln "thread 1")
>  (sleep 2)
>  (loop))
> 
> (displayln "ENTER to continue")
> (read-line)
> 
> (custodian-shutdown-all c1)
> 
> (displayln "ENTER to continue")
> (read-line)
> 
> (parameterize ((current-custodian c2))
>   (set! t2 (thread
>  (lambda ()
>(thread-resume t1 (current-thread))
>(let loop ()
>  (displayln "thread 2")
>  (sleep 2)
>  (loop))
> 
> (displayln "ENTER to continue")
> (read-line)
> 
> (custodian-shutdown-all c2)
> 
> (displayln "ENTER to continue")
> (read-line)
> ```
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/f844779f-9abd-46bd-987f-b2b3ca3d
> 0925n%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/20201107174703.320%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Racket BC versus CS unsafe flonums

[Matthew Flatt]

At Sat, 7 Nov 2020 16:42:43 +0100, Dominik Pantůček wrote:
> My current understanding is that the best performance you get from
> unsafe operations while using safe operations as hints for the flonum
> unboxing algorithm, right?

I'm not sure I understand what you mean, but I don't think unsafe
operations are particularly helpful for unboxing hints.

Let's separate out safety checks from unboxing. For safety checks, I'd
put the unsafe flonum operations into two categories:

 * `fl+`, `fl-`, etc., where the only relevant check is whether an
   argument is a flonum --- In this case, the benefits of unsafe
   variants are small to nothing. Depending on context, the compiler
   can often infer that the arguments are definitely flonums, so the
   generated code is the same. It's only when the compiler cannot infer
   flonumness that an unsafe variant has any performance advantage, and
   then it's just skipping a type-tag check.

 * `flvector-ref` and `flvector-set!` --- In these cases, there's an
   array-bounds requirement that is well beyond the reach of the
   compiler to infer. So, there will be a check on every use of the
   safe variants in a loop, for example. The check also requires more
   instructions than checking flonumness, so it's easier to see some
   speedup with unsafe variants of these operations.

Unboxing is a bigger deal for performance than safety checks, though,
and unboxing is completely driven by what the compiler can infer. Using
unsafe operations provides no more or less information to the
compiler's unboxing inference than safe operations do.


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/20201107145933.fe%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Racket BC versus CS unsafe flonums

[Matthew Flatt]

At Fri, 6 Nov 2020 12:45:46 -0700, Matthew Flatt wrote:
> I will investigate faster option. A primitive without conversion could
> make the safe `flvector-set!` slightly faster, too, by avoiding a
> redundant check.

Long story short, I added flvectors to the Chez Scheme level as of
v7.9.0.4. With that change, `flvector-set!` is faster, and
`flvector-ref` and `flvector-set!` cooperate better with flonum
unboxing.

For example, this microbenchmark now avoids allocation and runs about 8
times as fast:

 (let ([v (make-flvector 100)])
   (time
(for ([j (in-range 10)])
  (for ([i (in-range (flvector-length v))])
(flvector-set! v i (fl+ 1.0 (flvector-ref v i)))

Also, your program now crashes as you intended.


(To make room in Chez Scheme's type encoding for flvectors, I removed
immutable fxvectors. Immutable fxvectors do not seem useful, and
there's no such thing at the Racket level.)


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/20201107073608.45%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Racket BC versus CS unsafe flonums

[Matthew Flatt]

At Fri, 6 Nov 2020 20:14:51 +0100, Dominik Pantůček wrote:
> I assume that CS' unsafe-flvector-set! is actually pretty safe when it
> comes to flonum-convertible numbers. It might be a bit faster because it
> lacks the contract, but definitely it is not a "low level" variant.

Hm, right --- it's implemented by `bytevector-ieee-double-native-set!`,
which is defined to convert its last argument to a flonum (so the
conversion applies even in unsafe mode). I hadn't noticed that before,
so thanks for pointing it out!

I will investigate faster option. A primitive without conversion could
make the safe `flvector-set!` slightly faster, too, by avoiding a
redundant check.

> Also given the fact that unsafe-fl+ and others give no performance
> advantage

I think `unsafe-fl+` can still be faster. For example, the second loop
below is the unsafe one, and it's 10-20% faster. I constructed this
program carefully, though, to avoid flonum inference and to avoid
allocating flonum results (which swamps the cost of checks).

The performance guide is pretty conservative about suggesting
performance improvements via unsafe operations, already, but
suggestions are welcome.

Mathew



#lang racket/base
(require racket/unsafe/ops
 racket/flonum)

(define N 1)

(define (f x)
  (fl< (fl+ x x) 0.0))

(define (u-f x)
  (fl< (unsafe-fl+ x x) 0.0))

(set! f f)
(set! u-f u-f)

(collect-garbage)

(time
 (for/fold ([v #f]) ([i (in-range N)])
   (f 1.0)))

(collect-garbage)

(time
 (for/fold ([v #f]) ([i (in-range N)])
   (u-f 1.0)))

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

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

[Matthew Flatt]

At Thu, 05 Nov 2020 13:01:36 -0500, Christopher Lemmer Webber wrote:
> I'm guessing it's probably due to these error messages:
> 
> $ raco pkg update --scope user --clone scribble-lib
> Inferred package name from given `--clone' path
>   package: scribble-lib
>   given path: scribble-lib
> raco pkg update: package installed in a different scope
>   package: scribble-lib
>   current scope: user
>   installed in scope: installation

The right way to avoid this message in you case is likely to specify
the same scope as the starting "scribble" copy, which is installation
scope, via `-i`.

> I see that I can make it happen using the following steps:
> 
> cwebber@twig:~/devel/scribble/scribble-lib$ raco pkg install --force
> [...]
> 
> I know you've warned me I don't want to do install --force though. :)
> 
> Though... now I've done it for all of the Scribble sub-packages, and
> things seem to work now...
> 
> Might I ask why I shouldn't do the thing I've just done then?

Your installation is now in a state where some packages that depend on
"scribble" are built against the installation-wide copy, while others
are (or will become as you run `raco setup` or more package commands)
built with your user-specific copy.

As long as your work as the same user, and as long as you don't run
anything that constraints effects to installation scope, then it might
all work... until it doesn't. Fundamentally, `raco setup` is not
designed to support dependencies that go backward from installation
scope to user scope, and so it doesn't make that work reliably.

Most likely, the installation is really all your own, and not
multi-user. In that case, you should just work at the level of the
installation to avoid a mismatch.


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/20201105112037.ad%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] benchmarks game

[Matthew Flatt]

Hi,

Can you say more about which version of Racket you're running and on
what platform?

Thanks!
Matthew

At Sun, 25 Oct 2020 03:47:39 -0700 (PDT), Raoul Schorer wrote:
> 
> Hi,
> 
> I got interested into The Computer Language Benchmarks Game.
> 
> The binary-trees benchmark is different between the BC (parallel) and CS 
> (single threaded) versions. On trying to execute the parallel version on 
> RacketCS with the expected commands (`raco make binarytrees`, and then 
> `racket binarytrees 21`), I get nothing printed on stdout while everything 
> is working as expected with the same commands for the single-threaded 
> version. Why is that? 
> 
> As an aside, doing the same without compiling first yields the expected 
> behaviour in both programs and the parallel version seems faster in 
> RacketCS, so it would seem like a worthy change to the benchmarks.
> 
> Cheers,
> Raoul
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 

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

Re: [racket-users] Using Chez Scheme libraries with Racket CS?

[Matthew Flatt]

At Thu, 8 Oct 2020 22:38:04 -0700 (PDT), primer wrote:
> I'm new to Racket and have not yet played with Racket CS.  My question is 
> whether the Chez Scheme libraries are available.  For example, is it 
> possible to do something like (require chezscheme) and then use 
> (fork-thread ...) to create a native thread?

Yes and no.

Yes: The `ffi/unsafe/vm` library provides access to Chez Scheme's
`eval`, so you can use `(vm-eval '(fork-thread ...))`. Even more
directly, you can use the `ffi/unsafe/os-thread` library to create a
Chez Scheme thread.

No: Accessing Chez Scheme directly is unsafe, because you can break
Racket invariants, and there are some limitations on using Chez Scheme
functions in Racket and vice versa. See `vm-primitive` for more
information.


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/20201009070425.22d%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Manually create cpointer value in racket?

[Matthew Flatt]

Probably you want to use `cast`. If you have an integer `addr` that
corresponds to an address, then

 (cast addr _uintptr _pointer)

casts it to a C pointer.

Matthew

At Wed, 7 Oct 2020 10:28:42 -0500, Nathaniel Griswold wrote:
> Related to a question I asked earlier, but this time at the racket side:
> 
> Is there any way to manually construct a cpointer with a raw pointer value? I 
> suppose this would mean being able to construct a chez record in racket.
> 
> My use case is that I have a remote process talking to a racket process, it 
> is 
> sending a pointer to some shared memory and I want to access that shared 
> memory. It’s an array of c structs with some integer data and each has a 
> pointer to some raw bytes.
> 
> Any way to do it?
> 
> 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/CDC4A5DF-6BE1-4B96-BF3A-0B19F2EB
> F0AC%40gmail.com.

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

Re: [racket-users] Security: #%top-interaction in setup/infotab?

[Matthew Flatt]

At Wed, 23 Sep 2020 18:04:01 +, Sage Gerard wrote:
> Is there a security reason behind omitting #%top-interaction from 
> `setup/infotab`?

No, I don't think there is any security issue here. Adding
`#%top-interaction` seems fine.


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/20201007074140.3eb%40sirmail.smtps.cs.utah.edu.

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

[Matthew Flatt]

A recent commit added a contract on `defthing` and `defproc` to enforce
the documented constraint that `#:kind` should be a string. But the
implementation is happy with content in the sense of `content?`.

Since it's easy to adjust the contract and documentation to restore
this capability, I'll do that, and then this example works again.

Matthew

At Sat, 26 Sep 2020 21:06:20 +0200, Jos Koot wrote:
> The following works well in DrRacket, version 7.8 [3m]
> 
> #lang scribble/manual
> @deftogether[
> (@defthing[#:kind "constant false/on/high" F trit? #:value '0]
>  @defthing[#:kind (list "constant true/off/low" (hspace 1)) T trit? #:value
> '1]
>  @defthing[#:kind "constant indeterminate" ? trit? #:value '?]
>  @defthing[#:kind (list "constant" (hspace 13)) trits (list/c trit? trit?
> trit?) #:value (list F T ?)]
>  @defthing[#:kind (list "constant" (hspace 13)) in-trits sequence? #:value
> (in-list trits)]
>  @defproc[#:kind (list "predicate" (hspace 12)) (trit? (obj any/c))
> boolean?]
>  @defproc[#:kind (list "predicate" (hspace 12)) (F? (obj any/c)) boolean?]
>  @defproc[#:kind (list "predicate" (hspace 12)) (T? (obj any/c)) boolean?]
>  @defproc[#:kind (list "predicate" (hspace 12)) (?? (obj any/c))
> boolean?])]{}
> 
> I use hspace for alignment of the kinds.
> 
> But in version 7.8.0.10--2020-09-25(515012525c/a) [3m] I get:
> 
> . . C:\Program Files\Racket-7.8.0.10\collects\syntax\contract.rkt:101:21:
> defthing: contract violation
>   expected: (or/c string? #f)
>   given: ("constant true/off/low" #(struct:element hspace (" ")))
>   in: (or/c string? #f)
>   macro argument contract on #:kind argument
>   contract from:
>   (lib scribble/private/manual-proc.rkt)
>   blaming: E:\circuits\circuit-manual.scrbl
>(assuming the contract is correct)
>   at: E:\circuits\circuit-manual.scrbl:416.18
> 
> Because I don't know whether or not this is a known issue, I post it on
> this list.
> If this is a known issue or an intentional change, then ignore this email,
> please.
> If not I can post it as a racket issue.
> Let me know, please.
> Thanks, Jos
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAL6KNi3P251G%2BBMQqDbo2qt6K22Gw
> _OOgjjnHDboLLuC3qKrGg%40mail.gmail.com.

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

Re: [racket-users] How to redirect only some library documentation in Scribble

[Matthew Flatt]

At Tue, 29 Sep 2020 17:51:42 -0700, "William J. Bowman" wrote:
> I'm writing a large Scribble document which links to package
> documentation. I link to normal Racket documentation, and currently
> redirect those to the main racket-lang documentation using
> --redirect-main "https://docs.racket-lang.org;. But I also link to a
> private library, and would like to redirect references to this
> library's documentation to a separate URL.
> 
> Ideally, I would do this by declaring the root URL for the package, and not by
> manually annotating every usage of @racket[private-library-identifier].
> 
> Is this possible?

As you've no doubt concluded by now, there's not really a way to do
this. It must be technically possible to override methods of the HTML
renderer to make this happen, but it wouldn't be practical.

I'm not sure what a good interface would be for more fine-grained
configuration. If it's worth it to you to look at how HTML renderer
might better support this, look for places in `scribble/html-render`
that use `external-root-url`, since that's what `--redirect-main` turns
into.


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/20201007072437.8d%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] question about places and main thread gc

[Matthew Flatt]

A new manual thread is not a new place. If places in CS change to have
distinct allocators (unlikely) or symbol tables (likely), then I expect
that activation would change to support specifying the place and use
the original place by default. Individual activated threads certainly
would not have separate allocators. It's always fine to use OS-level
synchronization among threads and different places, but beware that
blocking operations can interfere with Racket thread scheduling.

Sharing among activated threads in CS might be simpler than sharing
among places in that you could be guaranteed a shared allocator. Note
that `ffi/unsafe/thread` will let you create new threads of that sort
in CS already (and that won't change) --- it's the same as creating an
OS thread manually and activating it --- but see the caveats in the
documentation for `call-in-os-thread`.

At Thu, 1 Oct 2020 09:17:08 -0500, Nathaniel Griswold wrote:
> Cool. Thanks. I can play around with an activated thread to try and make the 
> calls I want. I guess i wasn’t clear on the difference between an activated 
> manually made thread and a place. Will manually made activated threads always 
> share the same allocator in new versions of racket cs? Will I always be able 
> to share data between these os threads as long as I just use standard 
> synchronization techniques? Is the question of sharing data among manual 
> activated os threads less complicated than places? Is a new manual thread a 
> new racket place or is it not a place at all?
> 
> Thanks!
> 
> > On Oct 1, 2020, at 8:21 AM, Matthew Flatt  wrote:
> > 
> > You're right that the main place is tied to the OS thread that is used
> > to start Racket, so you can't move the place over by activating a
> > different thread for the same place later. You can start Racket on an
> > OS thread other than the process's main thread, though.
> > 
> > The question of sharing allocated data among places is complicated. For
> > BC, different places use different allocators, so it basically doesn't
> > work (although it's possible to use no-moving objects that are GC
> > managed but still retained in the original place as long as they're
> > accessed anywhere else). For CS, there's currently only one allocator
> > for all places. That probably won't change, but it seems likely that CS
> > places will become more distinct in some way in a future
> > implementation, such as having different symbol tables while still
> > having the same allocator.
> > 
> > You can share memory allocated in 'raw mode among places in both BC and
> > CS, since that amounts to calling the C library's `malloc`. Going that
> > direction may end up similar to using something like zeromq, though.
> > 
> > You're right that there's not currently a way exposed to get the
> > identity of the current place or to check for being in the original
> > place.
> > 
> > Matthew
> > 
> > At Thu, 1 Oct 2020 07:38:09 -0500, Nate Griswold wrote:
> >> I looked into it, it seems to be implemented in `src/cs/rumble/foreign.ss`
> >> using chez get-thread-id, comparing it to 0 and using a stored ref to the
> >> original async callback queue, so looks like this is not exposed to the
> >> user. Hm.
> >> 
> >> Nate
> >> 
> >> 
> >>> On Thu, Oct 1, 2020 at 6:58 AM Nate Griswold  
> wrote:
> >>> 
> >>> Thanks, Matthew. That helps. I was working on my project again and this
> >>> came up again, but I still don't quite have my use-case figured out. I 
> >>> have
> >>> two additional (in addition to main thread place) places that i wanted to
> >>> send messages to using standard chez and racket c calls (and not relying 
> >>> on
> >>> something like zeromq or file descriptors). I wanted to allow garbage
> >>> collection and `#:in-original-place?` dependent ffi libs to work 
> >>> correctly.
> >>> Then i guess I need to keep my original place in scheme code and *not*
> >>> `Sdeactivate_thread`ed most of the time to make this work. I had the idea
> >>> from what you said that i might Sactivate_thread a completely different
> >>> os-level thread in order to call into scheme using say racket_apply on
> >>> `place-channel-put`. Can i do this or no? I was thinking no because...
> >>> 
> >>> From the docs for `#:in-original-place?`:
> >>> 
> >>> """
> >>> If in-original-place? is true, then when a foreign callout
> >>> 
> >> 
> <https://docs.racket-lang.org/foreign/foreign_procedures.html#%28tec

Re: [racket-users] question about places and main thread gc

[Matthew Flatt]

You're right that the main place is tied to the OS thread that is used
to start Racket, so you can't move the place over by activating a
different thread for the same place later. You can start Racket on an
OS thread other than the process's main thread, though.

The question of sharing allocated data among places is complicated. For
BC, different places use different allocators, so it basically doesn't
work (although it's possible to use no-moving objects that are GC
managed but still retained in the original place as long as they're
accessed anywhere else). For CS, there's currently only one allocator
for all places. That probably won't change, but it seems likely that CS
places will become more distinct in some way in a future
implementation, such as having different symbol tables while still
having the same allocator.

You can share memory allocated in 'raw mode among places in both BC and
CS, since that amounts to calling the C library's `malloc`. Going that
direction may end up similar to using something like zeromq, though.

You're right that there's not currently a way exposed to get the
identity of the current place or to check for being in the original
place.

Matthew

At Thu, 1 Oct 2020 07:38:09 -0500, Nate Griswold wrote:
> I looked into it, it seems to be implemented in `src/cs/rumble/foreign.ss`
> using chez get-thread-id, comparing it to 0 and using a stored ref to the
> original async callback queue, so looks like this is not exposed to the
> user. Hm.
> 
> Nate
> 
> 
> On Thu, Oct 1, 2020 at 6:58 AM Nate Griswold  wrote:
> 
> > Thanks, Matthew. That helps. I was working on my project again and this
> > came up again, but I still don't quite have my use-case figured out. I have
> > two additional (in addition to main thread place) places that i wanted to
> > send messages to using standard chez and racket c calls (and not relying on
> > something like zeromq or file descriptors). I wanted to allow garbage
> > collection and `#:in-original-place?` dependent ffi libs to work correctly.
> > Then i guess I need to keep my original place in scheme code and *not*
> > `Sdeactivate_thread`ed most of the time to make this work. I had the idea
> > from what you said that i might Sactivate_thread a completely different
> > os-level thread in order to call into scheme using say racket_apply on
> > `place-channel-put`. Can i do this or no? I was thinking no because...
> >
> > From the docs for `#:in-original-place?`:
> >
> > """
> > If in-original-place? is true, then when a foreign callout
> > 
> <https://docs.racket-lang.org/foreign/foreign_procedures.html#%28tech._callout%
> 29>
> > procedure with the generated type is called in any Racket place
> > <https://docs.racket-lang.org/reference/places.html#%28tech._place%29>,
> > the procedure is called from the original Racket place. Use this mode for a
> > foreign function that is not thread-safe at the C level, which means that
> > it is not place-safe at the Racket level. Callbacks
> > 
> <https://docs.racket-lang.org/foreign/foreign_procedures.html#%28tech._callback
> %29>
> > from place-unsafe code back into Racket at a non-original place typically
> > will not work, since the place of the Racket code may have a different
> > allocator than the original place.
> > """
> >
> > I guess this means os threads use completely different allocators and
> > sharing data among different `Sactivate_thread`ed threads doesn't make any
> > sense at all. Is there any way to do this (command my places using the
> > basic chez and racket funcs like racket_eval and Scons and racket_apply) or
> > should i just use messaging over zeromq or an fd to my main thread? Maybe
> > if place descriptors are guaranteed shared among all os-level threads then
> > i can do it. I guess if `#:in-original-place?` exists there must be some
> > way to do it, but maybe it's not exposed to the user. Also, is there any
> > way to get the place descriptor for the current place or the main place? I
> > didn't see any in the docs. I guess i should just start reading the racket
> > source at this point.
> >
> > Also maybe i'm missing a simpler solution. Any help would be appreciated.
> > Thanks.
> >
> > Nate
> >
> >
> > On Mon, Sep 14, 2020 at 6:47 AM Matthew Flatt  wrote:
> >
> >> At Mon, 14 Sep 2020 00:34:08 -0500, Nate Griswold wrote:
> >> > If i understand correctly, in racket cs embedded if i am not currently
> >> > running anything in the main racket thread then gc cannot happen. But
> >> the
> >> > next time i make a call into racket on that reserved racket thre

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

[Matthew Flatt]

A PR to improve `struct->vector` for CS would be welcome. There
relevant code is here:

https://github.com/racket/racket/blob/master/racket/src/cs/rumble/struct.ss#L1221

As you'll see, the synthesized name is currently whatever comes out of
Chez Scheme's `inspect/object` interface. It could instead involve a
case dispatch on fixnums, bignums, etc., to improve on the `simple`
label that `inspect/object` produces. There may also be Chez Scheme
versus Racket terminology to bridge, such as `byte-string` instead of
`bytevector`.

At Thu, 17 Sep 2020 13:30:02 -0400, Sam Tobin-Hochstadt wrote:
> We may change Racket CS so that it produces the same results, but in
> general the results of `struct->vector` on values that are opaque is
> not something that should be relied on.
> 
> The describe library is, I believe, unmaintained, and hasn't been
> updated in many years.
> 
> Sam
> 
> On Thu, Sep 17, 2020 at 1:17 PM Kevin Forchione  wrote:
> >
> >
> >
> > > On Sep 15, 2020, at 3:11 PM, Sam Tobin-Hochstadt  
> wrote:
> > >
> > > This is a difference in behavior between Racket BC and Racket CS, and
> > > not something in the describe library:
> > >
> > > [samth@homer:~/work/teaching/c211 (master) racket-7.8] racket
> > > Welcome to Racket v7.8.
> > >> (struct->vector 5)
> > > '#(struct:fixnum-integer ...)
> > >> ^D
> > > [samth@homer:~/work/teaching/c211 (master) plt] racket
> > > Welcome to Racket v7.8.0.9 [cs].
> > >> (struct->vector 5)
> > > '#(struct:simple …)
> >
> >
> > Is this going to be the go-forward stance for Racket? Or is this still a 
> work in progress? Will it be left up to the code to determine types through 
> predicate checking?
> >
> > Thanks!
> >
> > Kevin
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/F42194F9-ADA3-4158-BCBA-3A65F210
> 8AB4%40gmail.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BaiK06QrfOc2FLjTCFzvvo
> -cPpbSGChQ9yAnon_tp6wVw%40mail.gmail.com.

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

Re: [racket-users] Writing make-sized-byte-string alternative on CS

[Matthew Flatt]

You use `make-bytes` and `memcpy`, instead of writing a new loop. (The
non-copying part of `make-sized-byte-string` is what CS can't support.)

Matthew

At Tue, 15 Sep 2020 21:12:22 +, Sage Gerard wrote:
> The docs for 
> [make-sized-byte-string](https://docs.racket-lang.org/foreign/foreign_pointer-f
> uncs.html?q=free#%28def._%28%28quote._~23~25foreign%29._make-sized-byte-string%
> 29%29) indicate that CS does not support this operation. I'm guessing I just 
> need to fall back to building a loop using ptr-ref, but is there something 
> about CS that would prevent me from doing that too?
> 
> ~slg
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/P-nFrHLWq2Hs3MxhcsA09NoQtGaw0LfG
> 5WE-nC_IHWGSl3rPhToCquz8spEVDUAqg-LJRYweeGmerH12XTUUFhXBOHgBDAabpQk-2b2gFiQ%3D%
> 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/20200915151528.252%40sirmail.smtps.cs.utah.edu.