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

2020-10-01 Thread 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?

2020-09-17 Thread 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

2020-09-15 Thread 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.


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

2020-09-14 Thread Matthew Flatt
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 thread (which
> has not been shut down, and by using racket_apply or some such) then gc can
> happen. But i do not know about the other threads that racket has spawned.

In Racket CS, you can enable GC without the main thread by deactivating
the thread. At the Racket level, use `#blocking? #t` for a foreign
function to deactivate the current thread while calling the function.
At the C level, you can use `Sdeactivate_thread` and
`Sactivate_therad` from Chez Scheme's API.

Racket BC doesn't have a notation of deactivating a thread. Most GCs
with BC can run in separate places even without the main thread active,
but the main thread is needed when there has been enough shared-space
allocation that all threads must be involved.

One caution for both CS and BC, though: Some foreign-library bindings
use `#:in-original-place?` to make use of the foreign library
single-threaded by routing all calls through the main place. That
requires the main thread to be active.


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


Re: [racket-users] Create C functions for embedded Racket CS

2020-09-03 Thread Matthew Flatt
At Wed, 2 Sep 2020 14:05:11 -0700 (PDT), dotoscat wrote:
> There are a function such scheme_make_prim_w_arity 
>  _arity%29>
> for the CS version? The idea is to use Racket
> as a scripting language for a C program.

There's currently no support in the C API of Racket CS for constructing
a Scheme procedure that calls a C procedure. You have to work from the
Scheme side using `foreign-procedure` to create a wrapper for a C
function.


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


Re: [racket-users] ARM32 binaries for CS, or building on ARM 32

2020-08-24 Thread Matthew Flatt
I've fixed the memory fence on 32-bit Arm for the next release to use
an instruction that works on ARMv6, so you won't need to use
`--enable-mach=arm32le` in the future.

Also, the Utah snapshot site now provides ARMv6 builds for Racket CS:

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

Unfortunately, DrRacket CS uses enough additional memory (maybe in part
because places are enabled) that it fails soon after startup on my old
Pi B. So, just in case its useful to someone, the ARMv6 BC builds will
return in the next snapshot build.

At Tue, 18 Aug 2020 07:36:28 -0700 (PDT), "joey.e...@gmail.com" wrote:
> Alright, after compiling for approximately 16 hours, it looks like this 
> works. Thanks so much!
> 
> On Tuesday, August 11, 2020 at 3:02:54 PM UTC-7 Matthew Flatt wrote:
> 
> > Ah, that makes sense.
> >
> > Does configuring with `--enable-mach=arm32le` work? 
> >
> > Using "arm32le" instead of the inferred "tarm32le" avoids memory-fence
> > instructions, so it should solve this problem, but I'm not certain the
> > rest of the build will adapt correctly.
> >
> > At Tue, 11 Aug 2020 14:35:49 -0700 (PDT), Joey Eremondi wrote:
> > > I'm on an old RPi B (maybe a B+). It's pretty ancient, so I might be 
> > > pushing my luck. Here's my CPU info:
> > > 
> > > pi@raspberrypi:~ $ cat /proc/cpuinfo
> > > processor : 0
> > > model name : ARMv6-compatible processor rev 7 (v6l)
> > > BogoMIPS : 697.95
> > > Features : half thumb fastmult vfp edsp java tls 
> > > CPU implementer : 0x41
> > > CPU architecture: 7
> > > CPU variant : 0x0
> > > CPU part : 0xb76
> > > CPU revision : 7
> > > 
> > > Hardware : BCM2835
> > > Revision : 000e
> > > Serial : e9b1ce2d
> > > Model : Raspberry Pi Model B Rev 2
> > > 
> > > Running GDB gives the illegal instruction as 
> > >  instruction: 0xf57ff05a
> > > which looks to be a "Data Memory Barrier" instruction? Sounds like a 
> > > plausible culprit.
> > > 
> > > Thanks!
> > > 
> > > 
> > > 
> > > On Tuesday, August 11, 2020 at 2:14:28 PM UTC-7, Matthew Flatt wrote:
> > > >
> > > > Which model Pi are you using? I'm able to build on a Pi 3, so I wonder 
> > > > if it's a difference in processors, where the Arm32 backend is using 
> > > > something that it shouldn't. 
> > > >
> > > > Whether or not that guess is right, can you try running `gdb` in the 
> > > > "ChezScheme" directory like this? 
> > > >
> > > > env SCHEMEHEAPDIRS=tarm32le/boot/tarm32le/ \ 
> > > > gdb tarm32le/bin/tarm32le/scheme 
> > > >
> > > > Disassembling around the failed instruction address (with 
> > `disassemble` 
> > > > in gdb) should clarify what instruction is misused. 
> > > >
> > > > Thanks, 
> > > > Matthew 
> > > >
> > > > At Tue, 11 Aug 2020 10:58:03 -0700 (PDT), Joey Eremondi wrote: 
> > > > > I'm wondering, does anybody have any prebuilt 32-but ARM binaries 
> > for 
> > > > > Racket on Chez? I'm trying to run a little web-server on a raspberry 
> > pi, 
> > > > > and I'd prefer to use the Chez version, but I can't seem to get it 
> > to 
> > > > build. 
> > > > > 
> > > > > Alternately, if anybody knows why it won't build and can help, that 
> > > > would 
> > > > > help. With eiether --enable-csracket or --enable-csonly, it gets 
> > stuck 
> > > > > compiling the forked version of ChezScheme. Surprisingly, it doesn't 
> > > > seem 
> > > > > to be an out of memory error. Is the illegal instruction error 
> > because 
> > > > it's 
> > > > > ARMv6 and not AArch32? 
> > > > > 
> > > > > ... 
> > > > > gcc -Wpointer-arith -Wextra -Werror -Wno-implicit-fallthrough -O2 -g 
> > > > -O2 - 
> > > > > Wall -DELF_FIND_BOOT_SECTION -pthread -rdynamic -o 
> > > > ../bin/tarm32le/scheme 
> > > > > ../boot/tarm32le/main.o ../boot/tarm32le/libkernel.a -lm -ldl 
> > -lpthread 
> > > > -lrt 
> > > > > -luuid ../zlib/libz.a ../lz4/lib/liblz4.a -pthread 
> > > > > (cd s && make bootstrap) 
> > > > > make allx 
> > > > > rm -f *.tarm32le xpatch patch *.patch *.so *.covin *.asm script.all 
> > > > header.tmp 
> > >

Re: [racket-users] Can OpenSSL be upgraded for the next Racket release?

2020-08-20 Thread Matthew Flatt
Hi Andre,

For information and build scripts, see

  https://github.com/racket/racket/tree/master/racket/src/native-libs

As an intermediate step, I direct the libraries to a checkout of

  https://github.com/racket/libs/

which has the built libraries in package form and some upload scripts
for registering the updated packages.

The time-consuming part is preparing a set of environments where the
builds can work, including having all of the source archives at hand. I
start with a Mac that has old Mac OS SDKs and MinGW cross compilers
installed, so I can build 32-bit and 64-bit Mac and Windows libraries
in one place. I have a Debian 7 VM for the natipkg build. Probably
there's a more modern, Docker-based strategy that would make this
easier.

Matthew

At Thu, 20 Aug 2020 14:17:43 +0100, Andre Garzia wrote:
> Thanks a lot for the quick turnaround, Matthew.
> 
> I want to get more involved with Racket maintaining, specially for Windows
> platform, and before you replied here, I was trying to do this update
> myself. I saw the packages:
> 
> https://pkgs.racket-lang.org/package/racket-win32-i386
> https://pkgs.racket-lang.org/package/racket-win32-x86_64
> 
> But I couldn't find a repository or instructions on how to build them.
> Could you point me in to some instructions? In the future, instead of
> asking for upgrades, I'd like to maybe send a PR or something.
> 
> Best
> Andre
> 
> 
> 
> On Wed, 19 Aug 2020 at 00:42, Matthew Flatt  wrote:
> 
> > Yes --- done.
> >
> > Matthew
> >
> > At Mon, 17 Aug 2020 17:46:49 +0100, Andre Garzia wrote:
> > > Hi Folks,
> > >
> > > The OpenSSL DLLs being shipped with Racket (in version 7.7 at least) is
> > > v1.1.0.8 which has already been EOLd. Version 1.1.1 is the stable
> > version.
> > > Version 1.1.1 is LTS and supported until 2023. In theory 1.1.1 is a
> > drop-in
> > > replacement for 1.1.0.8 since it is ABI and binary compatible with the
> > > older version. Having that version available would allow us to benefit
> > from
> > > TLSv1.3:
> > >
> > > https://wiki.openssl.org/index.php/TLS1.3
> > >
> > > And also benefit from many other bug fixes.
> > >
> > > Best
> > > Andre
> > >
> > >
> > >
> > > --
> > > https://www.andregarzia.com <http://www.andregarzia.com>
> > > Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
> >
> 
> 
> -- 
> https://www.andregarzia.com <http://www.andregarzia.com>
> Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAF3jwTn--b58kKAOkWZhhTSFp7PMdhZ
> MD7cqiFHgJ87uOw-WGg%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/20200820075134.91%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Unfortunate error message for wrong number of arguments to a format string in printf

2020-08-19 Thread Matthew Flatt
Thanks for the report! This has been fixed for the next release.

Matthew

At Wed, 19 Aug 2020 12:16:24 -0400, William Byrd wrote:
> To wit:
> 
> Chez Scheme Version 9.5.3
> Copyright 1984-2019 Cisco Systems, Inc.
> 
> > (printf "~s")
> 
> 
> Exception in printf: too few arguments for control string "~s"
> Type (debug) to enter the debugger.
> >
> 
> Process scheme finished
> 
> 
> Welcome to Racket v7.8 [cs].
> > (printf "~s")
> 
> ; /: division by zero [,bt for context]
> >
> 
> Cheers,
> 
> --Will
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CACJoNKGKzuTt0DdLjOLDv6jbjwxTmga
> UzAmrvL6cfwdz%3Dfsypg%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/20200819102010.3a6%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Can OpenSSL be upgraded for the next Racket release?

2020-08-18 Thread Matthew Flatt
Yes --- done.

Matthew

At Mon, 17 Aug 2020 17:46:49 +0100, Andre Garzia wrote:
> Hi Folks,
> 
> The OpenSSL DLLs being shipped with Racket (in version 7.7 at least) is
> v1.1.0.8 which has already been EOLd. Version 1.1.1 is the stable version.
> Version 1.1.1 is LTS and supported until 2023. In theory 1.1.1 is a drop-in
> replacement for 1.1.0.8 since it is ABI and binary compatible with the
> older version. Having that version available would allow us to benefit from
> TLSv1.3:
> 
> https://wiki.openssl.org/index.php/TLS1.3
> 
> And also benefit from many other bug fixes.
> 
> Best
> Andre
> 
> 
> 
> -- 
> https://www.andregarzia.com 
> Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia

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


Re: [racket-users] emoji in source code

2020-08-18 Thread Matthew Flatt
It turns out that the commit below is not part of the main Cairo
branch. (It builds on other commits that haven't been merged, and there
appear to be issues.) So, it's not as simple as upgrading Cairo.


At Mon, 20 Jul 2020 09:02:50 -0600, Matthew Flatt wrote:
> The emoji problem on Mac OS has to do with the system-level drawing
> function, CGContextShowGlyphsAtPoint, that used at the Cairo layer, at
> least in the version of Cairo that we're using. That function doesn't
> support emoji glyphs.
> 
> A newer version of Cairo handles emoji glyphs:
> 
> https://gitlab.freedesktop.org/cairo/cairo/commit/416a0005ab6a2b9a709d05281025e
> 3581d612989?expanded=1
> 
> So, I've put "upgrade Cairo" on my todo list.
> 
> 
> At Sun, 19 Jul 2020 16:36:53 -0500, Robby Findler wrote:
> > I'm not sure what's going on, but this smily works: ☺
> > 
> > Robby
> > 
> > 
> > On Sun, Jul 19, 2020 at 10:55 AM Shriram Krishnamurthi 
> > wrote:
> > 
> > > I wrote the following program:
> > >
> > >   (define /: ')
> > >
> > > which at least on my screen looks like
> > >
> > >
> > >
> > > in Aquamacs and in my browser (modulo dark/light mode).
> > >
> > > However, no matter which mode I use in OS X AND which color mode I use in
> > > DrRacket, the emoji just isn't visible:
> > >
> > >
> > >
> > > Not the most pressing problem in the world, but figured this is probably
> > > not desirable.
> > >
> > > 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/af814198-b86b-4905-a741-4b59d605
> > ca8co%40googlegroups.com
> > > 
> > 
> <https://groups.google.com/d/msgid/racket-users/af814198-b86b-4905-a741-4b59d60
> > 5ca8co%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/CAL3TdOMS5KWw0cj_jzzWpeO1icNZ1Ez
> > %2BKkjZt%2B3PLiY96BwoaA%40mail.gmail.com.
> > 
> > 
> > 
> --
> > [image/png "AutoGeneratedInlineImage1"] [~/Desktop & open] [~/Temp & open]
> > .
> > 
> > 
> > 
> --
> > [image/png "AutoGeneratedInlineImage2"] [~/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/20200720090250.1da%40sirmail.smt
> p.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/20200818174229.2b5%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Package Server Update Status

2020-08-18 Thread Matthew Flatt
Something was wrong. The pkg-builder service stopped working a week ago
due to network trouble. I rebooted it.

Meanwhile, I now realize that I haven't been getting the service-status
email that would have alerted me, because my department's SMTP
configuration changed a week ago. That's now fixed, too.

At Tue, 18 Aug 2020 07:57:33 -0700 (PDT), Deren Dohoda wrote:
> Hi team,
> 
> I notice on the very nice about page, 
> https://pkg-build.racket-lang.org/about.html, it does not give an 
> indication of when packages are rebuilt. I had a package that had doc 
> problems and conflicts that I resolved (the ol' manual.scrbl curse). It 
> appeared from me browsing information on a few packages that things were 
> rebuilt approximately once per week but it has now been over a week. The 
> status seems to indicate that a fresh package was noticed on my repository 
> but it hasn't been reflected in the build.
> 
> Is there a problem with the server at the moment or am I simply being 
> impatient?
> 
> Thanks,
> Deren
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/63c0a0eb-c797-49a1-8cf6-020e774e
> 3833n%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/20200818091632.15a%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Scribble and examples can't read racket-prefs.rktd

2020-08-16 Thread Matthew Flatt
Sandboxed filesystem and unsafety access is too strict for many
purposes. For documentation, I recommend using a trusted sandbox by
wrapping the sanebox creation with
`call-with-trusted-sandbox-configuration`.

Matthew

At Sun, 16 Aug 2020 00:45:46 -0700 (PDT), Deren Dohoda wrote:
> Hi Racketeers,
> 
> I'm going in absolute circles trying to understand what I might be doing 
> wrong. I can use the command line scribble to generate html, which works 
> fine except a problem showing # instead of an actual plot/pict image. 
> And for that matter the package installs fine using a local install. But 
> trying to run the scribble file in DrRacket always gives me errors like 
> "cannot read racket-prefs.rkt" or other errors like "cannot reference an 
> identifier without a definition" and sometimes it will give me errors like 
> I have used (protect-out ...) somewhere but I am definitely not as I didn't 
> even learn about this kind of provide until I saw this error.
> 
> Does anyone using Windows have experience getting rid of this message or 
> have an idea what I might be doing wrong? I have a feeling that this 
> message isn't actually the problem and it's something to do with sandbox 
> somehow.
> 
> @(define this-eval (parameterize ((sandbox-output 'string)
>   (sandbox-error-output 'string)
>   (sandbox-memory-limit 100))
>  (make-evaluator 'racket/base #:requires '("main.rkt" 
> "fit.rkt" plot/pict)
>  (print-as-expression #f) 
>  )))
> 
> Thanks,
> Deren

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


Re: [racket-users] Scribble and structs

2020-08-12 Thread Matthew Flatt
At Wed, 12 Aug 2020 08:32:25 -0400, Deren Dohoda wrote:
> If I remove the @defproc of polynomial? then I do not get the error, though
> then of course that definition never appears in the document. However, if I
> instead remove the @defstruct* then the error also disappears. But
> @defstruct* does not document the automatically generated procedure so it
> seems that it shouldn't introduce it as far as scribble is concerned. Is
> this a bug?

A `@defstruct*[polynomial .]` form does document `polynomial?`.
Although the word `polynomial?` doesn't appear on the page, it's
implied by the `struct` form on the page.

As another example, if you search the docs for `exn?`, you'll arrive at
a `struct` declaration for `exn`, and not a separate `exn?` entry.


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


Re: [racket-users] Scribble and structs

2020-08-12 Thread Matthew Flatt
At Wed, 12 Aug 2020 04:07:58 -0700 (PDT), Deren Dohoda wrote:
> I have two questions. The first is: is there a way to have scribble / 
> sandbox use the gen:custom-write property of a structure? When I use 
> @examples the output is just the bare structure output, not using the 
> gen:custom-write procedure.
> 
> Second, I am working on a very simple polynomial library using 7.7 and 
> during the creation of the docs I receive this warning:
> "WARNING: collected information for key multiple times: '(dep ((lib 
> "simple-polynomial/main.rkt") polynomial?)); values: #t #t"
> among other similar warnings all seeming to point to the procedure 
> polynomial?.
> 
> This would lead me to believe I have somehow required or defined things 
> multiple times. However my "main.rkt" is just a one file require and an 
> all-from-out. The underlying library does not use (provide (struct-out 
> ...)), I only (provide polynomial?). 
> 
> Do structs somehow mess with scribble here?

Structs should not cause any particular problem for Scribble. I'm
puzzled by the problem with `gen:custom-write`, because that should
certainly work with sandboxes and `@examples`.

The "collected information multiple times" error would be caused by
multiple declarations of `polynominal?` in the docs, as opposed to
multiple definitions in the code. Depending on when the error happens,
though, it could be due to multiple instances of a whole document, as
Laurent suggests.


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


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

2020-08-12 Thread Matthew Flatt
CS will be built on Precise, so the "current" alias with "precise" will
continue to work, and BC will continue to be built on Precise.

But CS will also be built on Xenial --- mostly because that build is
set up, but maybe it's a step toward migrating the build.

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

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


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

2020-08-11 Thread Matthew Flatt
As you may know, the Racket Git repo recently switched to Racket CS as
the default build. That is, if you check out the repo and `make`, then
you get an in-place Racket CS build instead of Racket BC.

The next step in moving toward Racket CS is to try switching the
snapshot builds. Out current plan is to switch the Utah build on August
13. The Northwestern snapshot build will be unchanged, for now. This
change will have no effect on the regular, release downloads.

The layout of the page at

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

will change so that CS and BC builds are grouped together, more like
the Northwestern snapshot layout, but an installer that doesn't have
"BC" in its link will download a Racket CS installer.

If you have an automated process that pulls from the snapshot site,
then it probably downloads something like

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

As of August 13, that will download a Racket CS installer instead of a
BC installer, because there's no "-bc" suffix in the name.

Racket BC builds will still be available; you'll just have to
specifically select a download option with "BC" in the link name or
"-bc" in the URL. For example,

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

will download a Racket BC installer. For now, 32-bit Windows and Mac OS
installers will be available only for BC, because we view those as
legacy platforms.

For consistently, you'll be able to access the CS installers using a
"-cs" suffix. The installer name without a "-cs" or "-bc" suffix is an
aliases for one with "-cs". Of course, the "current" names are all
aliases for installers that have a specific version number.

While we're adjusting installer names, the canonical name for Minimal
Racket installers will change to "racket-minimal-..." instead of
"min-racket-...". The new name matches the names used for releases. For
the foreseeable future, "min-racket-..." aliases will still work, but
you should migrate to "racket-minimal-..." if you have an automated
process that uses "min-racket-...".


Matthew

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


Re: [racket-users] ARM32 binaries for CS, or building on ARM 32

2020-08-11 Thread Matthew Flatt
Ah, that makes sense.

Does configuring with `--enable-mach=arm32le` work? 

Using "arm32le" instead of the inferred "tarm32le" avoids memory-fence
instructions, so it should solve this problem, but I'm not certain the
rest of the build will adapt correctly.

At Tue, 11 Aug 2020 14:35:49 -0700 (PDT), Joey Eremondi wrote:
> I'm on an old RPi B (maybe a B+). It's pretty ancient, so I might be 
> pushing my luck. Here's my CPU info:
> 
> pi@raspberrypi:~ $ cat /proc/cpuinfo
> processor: 0
> model name: ARMv6-compatible processor rev 7 (v6l)
> BogoMIPS: 697.95
> Features: half thumb fastmult vfp edsp java tls 
> CPU implementer: 0x41
> CPU architecture: 7
> CPU variant: 0x0
> CPU part: 0xb76
> CPU revision: 7
> 
> Hardware: BCM2835
> Revision: 000e
> Serial: e9b1ce2d
> Model: Raspberry Pi Model B Rev 2
> 
> Running GDB gives the illegal instruction as 
>  instruction: 0xf57ff05a
> which looks to be a "Data Memory Barrier" instruction? Sounds like a 
> plausible culprit.
> 
> Thanks!
> 
> 
> 
> On Tuesday, August 11, 2020 at 2:14:28 PM UTC-7, Matthew Flatt wrote:
> >
> > Which model Pi are you using? I'm able to build on a Pi 3, so I wonder 
> > if it's a difference in processors, where the Arm32 backend is using 
> > something that it shouldn't. 
> >
> > Whether or not that guess is right, can you try running `gdb` in the 
> > "ChezScheme" directory like this? 
> >
> >env SCHEMEHEAPDIRS=tarm32le/boot/tarm32le/ \ 
> > gdb tarm32le/bin/tarm32le/scheme 
> >
> > Disassembling around the failed instruction address (with `disassemble` 
> > in gdb) should clarify what instruction is misused. 
> >
> > Thanks, 
> > Matthew 
> >
> > At Tue, 11 Aug 2020 10:58:03 -0700 (PDT), Joey Eremondi wrote: 
> > > I'm wondering, does anybody have any prebuilt  32-but ARM binaries for 
> > > Racket on Chez? I'm trying to run a little web-server on a raspberry pi, 
> > > and I'd prefer to use the Chez version, but I can't seem to get it to 
> > build. 
> > > 
> > > Alternately, if anybody knows why it won't build and can help, that 
> > would 
> > > help. With eiether --enable-csracket or --enable-csonly, it gets stuck 
> > > compiling the forked version of ChezScheme. Surprisingly, it doesn't 
> > seem 
> > > to be an out of memory error. Is the illegal instruction error because 
> > it's 
> > > ARMv6 and not AArch32? 
> > > 
> > > ... 
> > > gcc  -Wpointer-arith -Wextra -Werror -Wno-implicit-fallthrough -O2 -g 
> > -O2 - 
> > > Wall -DELF_FIND_BOOT_SECTION -pthread -rdynamic -o 
> > ../bin/tarm32le/scheme 
> > > ../boot/tarm32le/main.o ../boot/tarm32le/libkernel.a -lm -ldl  -lpthread 
> > -lrt 
> > > -luuid ../zlib/libz.a ../lz4/lib/liblz4.a -pthread 
> > > (cd s && make bootstrap) 
> > > make allx 
> > > rm -f *.tarm32le xpatch patch *.patch *.so *.covin *.asm script.all 
> > header.tmp 
> > > *.html 
> > > rm -rf nanopass 
> > > cp -p -f ../boot/tarm32le/petite.boot ../boot/tarm32le/sbb 
> > > cp -p -f ../boot/tarm32le/scheme.boot ../boot/tarm32le/scb 
> > > make all 
> > > echo '(reset-handler abort)'\ 
> > >  '(base-exception-handler (lambda (c) (fresh-line) 
> > > (display-condition c) (newline) (reset)))'\ 
> > >  '(keyboard-interrupt-handler (lambda () (display 
> > > "interrupted---aborting\n") (reset)))'\ 
> > >  '(optimize-level 3)'\ 
> > >  '(debug-level 0)'\ 
> > >  '(commonization-level (commonization-level))'\ 
> > >  '(compile-compressed #t)'\ 
> > >  '(compress-format (compress-format))'\ 
> > >  '(compress-level (compress-level))'\ 
> > >  '(generate-inspector-information #f)'\ 
> > >  '(subset-mode (quote system))'\ 
> > >  '(compile-file "cmacros.ss" "cmacros.so")'\ 
> > >  | ../bin/tarm32le/scheme -q 
> > > Error: illegal instruction 
> > > () 
> > > make[10]: *** [Mf-base:375: cmacros.so] Error 1 
> > > make[9]: *** [Mf-base:179: allx] Error 2 
> > > make[8]: *** [Mf-base:196: bootstrap] Error 2 
> > > make[7]: *** [Makefile:22: build] Error 2 
> > > make[6]: *** [Makefile:20: build] Error 2 
> > > make[6]: Leaving directory '/home/pi/gh/racket-7.8/src/ChezScheme' 

Re: [racket-users] ARM32 binaries for CS, or building on ARM 32

2020-08-11 Thread Matthew Flatt
Which model Pi are you using? I'm able to build on a Pi 3, so I wonder
if it's a difference in processors, where the Arm32 backend is using
something that it shouldn't.

Whether or not that guess is right, can you try running `gdb` in the 
"ChezScheme" directory like this?

   env SCHEMEHEAPDIRS=tarm32le/boot/tarm32le/ \
gdb tarm32le/bin/tarm32le/scheme

Disassembling around the failed instruction address (with `disassemble`
in gdb) should clarify what instruction is misused.

Thanks,
Matthew

At Tue, 11 Aug 2020 10:58:03 -0700 (PDT), Joey Eremondi wrote:
> I'm wondering, does anybody have any prebuilt  32-but ARM binaries for 
> Racket on Chez? I'm trying to run a little web-server on a raspberry pi, 
> and I'd prefer to use the Chez version, but I can't seem to get it to build.
> 
> Alternately, if anybody knows why it won't build and can help, that would 
> help. With eiether --enable-csracket or --enable-csonly, it gets stuck 
> compiling the forked version of ChezScheme. Surprisingly, it doesn't seem 
> to be an out of memory error. Is the illegal instruction error because it's 
> ARMv6 and not AArch32?
> 
> ...
> gcc  -Wpointer-arith -Wextra -Werror -Wno-implicit-fallthrough -O2 -g -O2 -
> Wall -DELF_FIND_BOOT_SECTION -pthread -rdynamic -o ../bin/tarm32le/scheme 
> ../boot/tarm32le/main.o ../boot/tarm32le/libkernel.a -lm -ldl  -lpthread -lrt 
> -luuid ../zlib/libz.a ../lz4/lib/liblz4.a -pthread
> (cd s && make bootstrap)
> make allx
> rm -f *.tarm32le xpatch patch *.patch *.so *.covin *.asm script.all 
> header.tmp 
> *.html
> rm -rf nanopass
> cp -p -f ../boot/tarm32le/petite.boot ../boot/tarm32le/sbb
> cp -p -f ../boot/tarm32le/scheme.boot ../boot/tarm32le/scb
> make all
> echo '(reset-handler abort)'\
>  '(base-exception-handler (lambda (c) (fresh-line) 
> (display-condition c) (newline) (reset)))'\
>  '(keyboard-interrupt-handler (lambda () (display 
> "interrupted---aborting\n") (reset)))'\
>  '(optimize-level 3)'\
>  '(debug-level 0)'\
>  '(commonization-level (commonization-level))'\
>  '(compile-compressed #t)'\
>  '(compress-format (compress-format))'\
>  '(compress-level (compress-level))'\
>  '(generate-inspector-information #f)'\
>  '(subset-mode (quote system))'\
>  '(compile-file "cmacros.ss" "cmacros.so")'\
>  | ../bin/tarm32le/scheme -q
> Error: illegal instruction
> ()
> make[10]: *** [Mf-base:375: cmacros.so] Error 1
> make[9]: *** [Mf-base:179: allx] Error 2
> make[8]: *** [Mf-base:196: bootstrap] Error 2
> make[7]: *** [Makefile:22: build] Error 2
> make[6]: *** [Makefile:20: build] Error 2
> make[6]: Leaving directory '/home/pi/gh/racket-7.8/src/ChezScheme'
> make[5]: *** [Makefile:158: scheme-make-finish] Error 2
> make[5]: Leaving directory '/home/pi/gh/racket-7.8/src/cs/c'
> make[4]: *** [Makefile:148: scheme-make-copy] Error 2
> make[4]: Leaving directory '/home/pi/gh/racket-7.8/src/cs/c'
> make[3]: *** [Makefile:137: scheme] Error 2
> make[3]: Leaving directory '/home/pi/gh/racket-7.8/src/cs/c'
> make[2]: *** [Makefile:60: cs] Error 2
> make[2]: Leaving directory '/home/pi/gh/racket-7.8/src/cs/c'
> make[1]: *** [Makefile:90: racketcs] Error 2
> make[1]: Leaving directory '/home/pi/gh/racket-7.8/src'
> make: *** [Makefile:53: all] Error 2
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/9b0c4921-2155-4f63-bb79-a6b9ea05
> 8ef6o%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/20200811151422.12%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Re: Strange performance behavior

2020-08-08 Thread Matthew Flatt
At Sat, 8 Aug 2020 03:32:57 -0400, George Neuner wrote:
> 
> On 8/8/2020 1:55 AM, Sorawee Porncharoenwase wrote:
> > I even saw people doing `collect-garbage` three times, just to be safe 
> > I guess. And yet theoretically it's not guaranteed that things will be 
> > claimed back properly.
> >
> > Honestly, there should be a function that does this `collect-garbage` 
> > until fixpoint or something, so that we don't need to perform this ... 
> > uh  ritual.
> 
> There may be no documented guarantee, but I *think* the implementation 
> assures that 2 collections, back-to-back, are sufficient to reclaim all 
> objects that were garbage at the beginning of the 1st collection.  At 
> least for BC Racket.

In the absence of finalization, then a single `collect-garbage` would
always be sufficient, and a second `collect-garage` would have no
effect.

For the specific benchmark in this thread as run in plain `racket`, I
think a single `collect-garbage` is sufficient, and that's what I
normally do.

But finalization complicates the picture --- especially finalization
via `register-finalizer`, since the finalizers run in a background
thread. Because of that background thread, in a context that uses a
library like `racket/gui`, I sometimes use repetitions of

 (collect-garbage)
 (sync (system-idle-evt))

It's difficult to know whether the libraries that you use rely on
finalization. Also, finalization means that there is no simple number
of `(collect-garbage)`s and `(sync (system-idle-evt))`s that are needed
to really collect everything that could potentially be collected;
finalization chains can require an arbitrary number of
`(collect-garbage)` cycles to clean up (so libraries should avoid
finalization chains!). The collector is precise and the compiler is
safe-for-space, so you can reason about the reachability of an
individual value, but reasoning precisely about overall memory use
across many libraries is difficult or impossible.

Using an extra `(collect-garbage)` is not ideal and often not
necessary, but it's a reasonable just-to-be-sure habit.


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


Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

2020-08-04 Thread Matthew Flatt
At Tue, 4 Aug 2020 14:01:20 -0600, Robert D Kocisko wrote:
> My only concern with this is whether that single thread might get mildly
> starved compared to other racket threads given that it technically
> represents hundreds of 'green threads' inside itself all implemented in C
> whereas every other racket thread represents one green thread.  Is there
> any way to hint to the thread scheduler that a particular thread needs
> higher scheduling priority than others?

If you can arrange for all other threads to be in a separate group,
then all those threads together will have the same scheduling weight as
your one thread. I think that's the only mechanism for adjusting
weights, currently.

> Also, in this scenario would unsafe-poller give any underlying
> performance benefit compared to using unsafe-fd->evt and sync?

Probably not, since the `unsafe-fd->sync` uses `unsafe-poller` fairly
directly.


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


Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

2020-08-04 Thread Matthew Flatt
You're right: I had momentarily confused epoll with poll. You can just
use the single file descriptor for an epoll object with things like
`unsafe-file-descriptor->semaphore`, or you can use `unsafe-poller`.

I'll note that `unsafe-file-descriptor->semaphore` scales to a large
number of file descriptors as long as you create a thread to block on
each semaphore. Under the hood, creating and triggering fd-semaphores
is implemented by incremental operations on an epoll object (or kqueue
object, etc.), and each blocking thread will be descheduled until a
semaphore post re-schedules it. But if you already have an epoll object
and the code to handle it, then you don't need the semaphore-based
machinery.

Matthew

At Tue, 4 Aug 2020 12:54:56 -0600, Robert D Kocisko wrote:
> Thanks Matthew!  That was my thought but given the number of fds in play
> and the frequency of adding and removing interest in them (they are added
> dynamically as needed) it seems like that option would be rather
> inefficient.
> 
> Is there by chance any 'magic back door' which would allow me to register
> fds directly with Racket's underlying event loop so that I can bypass the
> extra hops of the thread scheduler and the ffi boundaries? Or if not what
> would need to be taken into consideration if I wanted to add such a back
> door via modifying Racket's source?  Are there any concerns with starving
> other threads or other timing issues?
> 
> Also I can't help but be intrigued by (unsafe-poller).  I'm wondering what
> benefits it might give (if any) in comparison with the approach you
> suggested.
> 
> Thanks,
> Bob
> 
> On Tue, Aug 4, 2020, 8:08 AM Matthew Flatt  wrote:
> 
> > Fusing event loops is always tricky, but if you have the option of
> > exposing individual file descriptors to Racket, then `ffi/unsafe/port`
> > is probably the way to go. You can turn a file descriptor into an event
> > using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
> > you can block on a set using `sync`, etc.
> >
> > Matthew
> >
> > At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> > > I have an existing c++ app that is entirely event-loop driven with epoll
> > > and I am trying to figure out how to integrate Racket in the same thread
> > > and allow the existing code to work as-is.  I have read the docs about
> > the
> > > C api and the FFI but so far a straightforward and clean option is not
> > > apparent to me.  The 'embedding' examples that I see appear rather
> > opaque
> > > to me and at best seem to be geared towards an external loop based on
> > > select() rather than epoll(), so I'm assuming that the more
> > straightforward
> > > approach would be to add the existing event handlers onto Racket's event
> > > system.  To that end, it seems there should be a way to register the
> > fd's
> > > of interest with Racket and receive a callback when they are read-ready
> > but
> > > I can't see a way to do that.  For example, how would I maintain a list
> > of
> > > fds to pass to (sync) if I went that route?  Or if it's better to work
> > it
> > > the other way, how would I call (sync) from c code and apply the list of
> > > fds to it?  I vaguely can see a way towards it but it seems at best
> > super
> > > inefficient.  Any thoughts or suggestions would be greatly appreciated!
> > >
> > > Thanks,
> > > Bob Kocisko
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups
> > > "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > an
> > > email to racket-users+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> > 
> https://groups.google.com/d/msgid/racket-users/46fb3804-396c-4921-849f-71fe5a6f
> > > ac7ao%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/20200804133449.2e8%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] Integrating Racket into existing single-threaded event-loop c++ app

2020-08-04 Thread Matthew Flatt
Fusing event loops is always tricky, but if you have the option of
exposing individual file descriptors to Racket, then `ffi/unsafe/port`
is probably the way to go. You can turn a file descriptor into an event
using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then
you can block on a set using `sync`, etc.

Matthew

At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote:
> I have an existing c++ app that is entirely event-loop driven with epoll 
> and I am trying to figure out how to integrate Racket in the same thread 
> and allow the existing code to work as-is.  I have read the docs about the 
> C api and the FFI but so far a straightforward and clean option is not 
> apparent to me.  The 'embedding' examples that I see appear rather opaque 
> to me and at best seem to be geared towards an external loop based on 
> select() rather than epoll(), so I'm assuming that the more straightforward 
> approach would be to add the existing event handlers onto Racket's event 
> system.  To that end, it seems there should be a way to register the fd's 
> of interest with Racket and receive a callback when they are read-ready but 
> I can't see a way to do that.  For example, how would I maintain a list of 
> fds to pass to (sync) if I went that route?  Or if it's better to work it 
> the other way, how would I call (sync) from c code and apply the list of 
> fds to it?  I vaguely can see a way towards it but it seems at best super 
> inefficient.  Any thoughts or suggestions would be greatly appreciated!
> 
> Thanks,
> Bob Kocisko
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/46fb3804-396c-4921-849f-71fe5a6f
> ac7ao%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/20200804080838.2d0%40sirmail.smtps.cs.utah.edu.


Re: [racket-users] in-directory sorted results

2020-08-03 Thread Matthew Flatt
At Sun, 2 Aug 2020 18:38:18 -0700 (PDT), evdubs wrote:
> However, the docs also show:
> 
> > (current-directory (collection-path "info"))
> > (for/list ([f (in-directory)])
>  f)
> '(#
>   #
>   #
>   #)
> 
> Isn't this not getting sorted correctly? I am seeing that calls to 
> (in-directory) do not have sorted results, but calls to (in-directory 
> "path") do have sorted results.

You're right that the documentation's example is incorrect, and I'll
fix that.

Most examples in the documentation are rendered by running them, so the
results can't get out-of-sync like this. Since the `in-directory`
example involves the filesystem, though, the example result is written
out in the documentation source, and it wasn't updated when the sorting
guarantee was added to `in-directory`.

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


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

2020-08-01 Thread Matthew Flatt
At Sat, 01 Aug 2020 03:56:36 -0400, George Neuner wrote:
> On Fri, 31 Jul 2020 20:20:05 -0700 (PDT),
> "wanp...@gmail.com"
>  wrote:
> 
> >I noticed that the size of the CS version is 244% compare to BS 
> >version. Wondering why it became so large. Does that mean Chez Scheme 
> >runtime/vm 100 MB larger than the original one?
> >
> >Racket Mac OS X
> >  64-bit Intel 116.7 MB SHA1: 521b5a264afcfb3f390afacc682987268f650a25
> >
> >Racket CS Mac OS X
> >  64-bit Intel 285.8 MB SHA1: 060f311fc6621c5797a62f98b743499fa4277793
> >
> >https://pre-release.racket-lang.org/
> 
> 
> The CS version compiles to native code rather than portable bytecode,
> so pretty much everything in the distribution is somewhat larger.  It
> adds up quickly.

That's still the best explanation I have, but I also think there must
be something more to it.

For example, the Chez Scheme boot files in uncompressed form add up to
about 8 times the size of compiled Racket BC executable, but Chez
Scheme doesn't have 8 times the functionality of the Racket BC
executable (so it should have 8 times as much machine code). The
machine code generated by Chez Scheme for its boot files is less
compact than machine code generated by GCC or LLVM for Racket BC's
implementation --- but, again, I don't think it's a factor of 8. So,
I'm optimistic that I've so far overlooked something that can make a
big difference.

I've concentrated more on understanding the difference in the run-time
memory footprints, and the difference there is not nearly so large.
Racket CS now sometimes has a smaller memory footprint than Racket BC
(e.g., peak memory use for a distribution build).

Matthew

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


Re: [racket-users] Advice wanted about new opengl binding

2020-08-01 Thread Matthew Flatt
At Fri, 31 Jul 2020 17:05:27 -0400, Hendrik Boom wrote:
> For example, there's glGetCompressedTexImageARB.  It receivees a 
> pointer to an image area and fills it in with a compressed image.
> According the the Racket C interface, the way to write this 
> would be:
> 
> (define-gl glGetCompressedTexImageARB 2 
>   ( (target : _int32)
> (level : _int32) 
> (img : _pointer/intptr)
>   -> _void -> img)
>  (->> exact-integer? exact-integer? gl-pointer?)
>  check-gl-error)

If I understand correctly that `target` and `level` provide enough
information to specify how big `img` should be, then I agree that
something analogous to

   (_fun
 (target : _int32)
 (level : _int32) 
 (img : _pointer/intptr = (malloc (COMPSIZE target level)))
-> _void
-> img)

is a fine way to wrap the function.

But when I work at the level of C APIs, I usually prefer this kind of
interface:

> But the old binding instead used
>  ( (target : _int32)
>(level : _int32)
>(img : _pointer/intptr)
>   -> _void)
> 
> In other words, it ignored the fact that img is used as an output 
> parameter.

Although, when I use this kind of binding, I have to know which
pointers must already be filled with information when I pass it to the
function versus which ones will be filled by the function, exposing the
pointer to to-be-filled memory gives me control over the way that the
memory. It also avoids having to specify anything about the
deallocation rules of the result of a binding (e.g., whether it needs
to be explicitly freed).

Still, I can also see the advantage of building allocation into the
wrapper to make clear that the argument corresponds to to-be-filled
memory.

Perhaps it depends on the overall shape of the API. If the API is going
to be wrapped further to make it more Rackety, then I'd go for less
wrapping at the immediate FFI bindings. If the API looks fairly Rackety
with a few tweaks to arguments and results, then I'd favor more
wrapping in the bindings. I think the old GL binding was in the former
camp: it first exposed GL functions in as raw as possible form, and
then wrapped those with a higher-level library.

> Now what should I do with this?  As I said there are very many such 
> functions.  It's not an isolated case.
> 
> Are all these glGet functions simply something that never happened to 
> get used in Racket code so no one noticed the discrepancy?
> Is there some idiom in Racket programming where all this just works 
> anyway?
> Is there some efficency reason for not recognising output parameters?
> Do they parhaps cause new storage allocation every time they are called?

I wouldn't say there's any "discrepancy" in `img` being an output
argument instead of an input argument. This kind of input--output
distinction doesn't exist at C ABI level, so no distinction is
inherently necessary in the FFI binding. Certainly, though, you can
create FFI wrappers that better reflect the intent of parameters than
the ABI-level types do.

You're right that exposing details like to-be-filled pointer arguments
usually offers the best available performance, but it's not always an
issue. This example looks like one where callers will practically
always allocate the destination memory just before calling the
function, so it will work out the same.


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


[racket-users] Racket CS release plan

2020-07-30 Thread Matthew Flatt
With the improvements in the upcoming v7.8 release, Racket CS provides
all of the functionality of Racket BC (the current default
implementation). Also, end-to-end performance measurements
increasingly favor Racket CS. For example, Racket CS now builds a
distribution slightly faster and in slightly less memory than Racket
BC:

   https://build-plot.racket-lang.org/

   https://build-plot-cs.racket-lang.org/

It's time to consider shifting the Racket release to use Racket CS as
the default --- while Racket BC will remain an option for a long time
to come.

We (the release managers) propose the following rule to trigger the
switch to Racket CS in the default distribution:

   Between this release and the next, if Racket CS testing and use
   uncover no bugs that are more serious than ones typically discovered
   for Racket BC, then Racket CS becomes the default for the next
   release.

At the earliest, the switch would happen with the release *after* the
soon-to-be-released v7.8. Our expectation is that the switch would
happen with the next release (in October), but we'll see how that
expectation lines up with reality.

This rule is somewhat subjective, in that "more serious" and "typical"
are in the eye of the beholder, but we keep a close eye on the results
of the pkg-build service as well as Racket tests. We'll also count
performance problems as bugs, so Racket CS must not have substantial
known performance problems relative to Racket BC.

Jay, John, Matthew, Matthias, Robby, Ryan, Sam, and Vincent
(the release managers)

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


Re: [racket-users] Re: with-continuation-marks in errortrace

2020-07-27 Thread Matthew Flatt
At Sun, 26 Jul 2020 20:21:56 -0700, Sorawee Porncharoenwase wrote:
> I have been toying with another way to instrument the code. It roughly
> expands to:
> 
> (define-syntax-rule (wrap f)
>   (call-with-immediate-continuation-mark
>'errortrace-k
>(λ (k)
>  (let ([ff (thunk f)])
>(if k
>(ff)
>(with-continuation-mark 'errortrace-k 'f
>  (ff)))

This variant probably generates faster code:

 (define-syntax-rule (wrap f)
   (call-with-immediate-continuation-mark
'errortrace-k
(λ (k)
  (with-continuation-mark 'errortrace-k (or k 'f)
f


> Now, the question: why is the current errortrace implemented in that way?
> Am I missing any downside of this new strategy? Would switching and/or
> integrating with the new strategy be better?

I don't recall there was any careful study of the alternatives. Always
setting the mark is easiest, and so that's probably why the current
implementation always sets the mark. Maybe keeping the first expression
for a frame instead of the last is consistently more useful.

At Sun, 26 Jul 2020 20:39:35 -0700, Sorawee Porncharoenwase wrote:
> (By "integrating" with the new strategy, I meant having two keys: one for
> the new strategy and one for the old strategy. I can see that the first
> entry of the old strategy is useful, and it's missing in the new strategy).

Instead of a separate mark, `or` above could be replaced by some
combinator that keeps more information in the mark value, such as a
first and last call using a pair:

 (define-syntax-rule (wrap f)
   (call-with-immediate-continuation-mark
'errortrace-k
(λ (k)
  (with-continuation-mark 'errortrace-k (let ([here 'f])
  (cons (if k (car k) here)
here))
f

Something other than a pair could keeps the first plus up to 5 most
recent calls. But then you'd probably want the errortrace annotator to
be a little smarter and not useless report syntactically enclosing
expressions, like a sequence of `begin`s in something like

 (begin
   
   (begin
 
 (begin
   
   )))

Overall, your simple change seems clearly worth trying out in
errortrace, and maybe other variants would be interesting to explore.


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


Re: [racket-users] Creating links to Racket docs for functions in user-scope packages

2020-07-24 Thread Matthew Flatt
Hi Joel,

At Tue, 21 Jul 2020 09:25:03 -0700 (PDT), "'Joel Dueck' via Racket Users" wrote:
> It looks like the problem might be in this function 
>  er.rkt#L440-L459> 
> where it always constructs a path that is relative to (find-doc-dir).
> 
> Would it make sense instead to have it check the dest against all the paths 
> returned by (get-doc-search-dirs) and just use the first one that matches? 
> If so maybe I’ll try doing a pull request to that effect.

I don't think that specific approach is going to work. Packages
installed in user scope render documentation within the collections'
directories, and those directories are not included in the result of
`(get-doc-search-dirs)`.

A solution might use something like `path->pkg+subpath+collect+scope`,
where a 'user result for the scope triggers a different path
calculation. For user-scope packages, ocumentation is rendered within
the collection in a "doc" subdirectory, instead of in a common "doc"
directory. Probably the content of the individual "doc" directories
mirrors the main "doc" directory, in which case the relative-path
calculation would be the same, but I may have forgotten a difference.

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/20200724101549.c4%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] emoji in source code

2020-07-20 Thread Matthew Flatt
The emoji problem on Mac OS has to do with the system-level drawing
function, CGContextShowGlyphsAtPoint, that used at the Cairo layer, at
least in the version of Cairo that we're using. That function doesn't
support emoji glyphs.

A newer version of Cairo handles emoji glyphs:

https://gitlab.freedesktop.org/cairo/cairo/commit/416a0005ab6a2b9a709d05281025e3581d612989?expanded=1

So, I've put "upgrade Cairo" on my todo list.


At Sun, 19 Jul 2020 16:36:53 -0500, Robby Findler wrote:
> I'm not sure what's going on, but this smily works: ☺
> 
> Robby
> 
> 
> On Sun, Jul 19, 2020 at 10:55 AM Shriram Krishnamurthi 
> wrote:
> 
> > I wrote the following program:
> >
> >   (define /: ')
> >
> > which at least on my screen looks like
> >
> >
> >
> > in Aquamacs and in my browser (modulo dark/light mode).
> >
> > However, no matter which mode I use in OS X AND which color mode I use in
> > DrRacket, the emoji just isn't visible:
> >
> >
> >
> > Not the most pressing problem in the world, but figured this is probably
> > not desirable.
> >
> > 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/af814198-b86b-4905-a741-4b59d605
> ca8co%40googlegroups.com
> > 
>  5ca8co%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/CAL3TdOMS5KWw0cj_jzzWpeO1icNZ1Ez
> %2BKkjZt%2B3PLiY96BwoaA%40mail.gmail.com.
> 
> 
> --
> [image/png "AutoGeneratedInlineImage1"] [~/Desktop & open] [~/Temp & open]
> .
> 
> 
> --
> [image/png "AutoGeneratedInlineImage2"] [~/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/20200720090250.1da%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] file->bytes with large files

2020-07-15 Thread Matthew Flatt
The `file->bytes` function uses the file size with `read-bytes`, and it
appears that the Mac OS `read` system call errors on requests of 2GB or
more. The right fix is for the `read` call within Racket (at the rktio
layer) to limit the size that it passes, and I'll make that change.

Meanwhile, you could work around the problem by limiting the size of an
individual request: Allocate a byte string and then use a sequence of
`read-bytes!` calls to read the file in increments. Each time, use the
number of read bytes to increment a starting position into the
destination byte string (which is the third argument to `read-bytes!`).

Matthew

At Wed, 15 Jul 2020 15:05:22 -0700 (PDT), Greg Rosenblatt wrote:
> Hi, I'm getting an error while using file->bytes to load a moderately large 
> file:
> 
> > (time (void (file->bytes "my-7.6GB-file")))
> ; error reading from stream port
> ;   port: #
> ;   system error: Invalid argument; errno=22
> ;   context...:
> ;/Applications/Racket v7.7/collects/racket/file.rkt:768:6: temp218
> ;/Applications/Racket 
> v7.7/collects/racket/private/more-scheme.rkt:336:52
> ;eval-one-top
> ;/Applications/Racket v7.7/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1478:0
> ;/Applications/Racket v7.7/collects/racket/repl.rkt:11:26
> 
> Is there a limit to the size of files that can be used with file->bytes?
> 
> I was preferring file->bytes because it seems much faster than manually 
> reading from a port.  If file->bytes is not appropriate here, can somebody 
> recommend another fast approach?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e99edda0-06ed-4164-b7bd-46f8a458
> c6c8o%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/20200715163230.343%40sirmail.smtp.cs.utah.edu.


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

2020-07-13 Thread Matthew Flatt
Thanks for the example! I did not guess correctly about your mixture of
embedded modules and `dynamic-require`.

The short answer is that you should either embed modules or reference
them through an external paths like "/Applications/Racket
v7.7/collects", but not both. Otherwise, the two worlds collide in
confusing ways, in this case along the lines Sam suggested.


Longer answer: When you embed a module, it pulls along a copy of
anything that module depends on. Your "test.rkt" pulls along
`racket/base`, which pulls along `racket/private/promise`, which
defines `force` and the promise datatype. But it doesn't
`racket/promise`, which defines `delay/sync`, and that leads to a
mismatch.


Very long answer: When `server` starts, there are two possible
`racket/private/promise`s available: the emebded copy and the one in
"/Applications/Racket v7.7/collects". As an artifact of the way that
`racket/promise` references `racket/private/promise`, the
`racket/promise` in "/Applications/Racket v7.7/collects" will always
refer to the `racket/private/promise` there. And so `delay/sync` as
used in `setup/private/dirs` will refer to the promise datatype there.
But the `force` used in `setup/private/dirs` goes through `racket/base`
and ends up referring the the embedded `racket/private/promise`, which
has its own promise datatype; since `force` doesn't recognize the
result of `delay/sync` as a promise, it doesn't force the (othe rkind
of) promise, and it instead just returns it. Finally, `planet/config`
is unhappy to get back a promise, because it expects a path.


If you expect a full "collects" directory and more to be around at run
time, then there's no reason to embed code, and just use

 racket_dynamic_require(Sstring("test.rkt"), Sfalse);

to load the module. But if you want to embed everything, then avoid
`dynamic-require` or use `++lib` or `define-module-path-index` to carry
along the dynamically required modules.


Matthew

At Mon, 13 Jul 2020 15:20:18 -0500, Nate Griswold wrote:
> I put up a repo with the bug at https://github.com/nwg/racket-expo
> 
> The stack trace is this:
> 
> build-path: contract violation
>   expected: (or/c path-string? path-for-some-system? 'up 'same)
>   given: #
>   context...:
>do-raise-argument-error
>loop
>build
>proc
>call-in-empty-metacontinuation-frame
>call-with-module-prompt
>body of "/Applications/Racket v7.7/collects/planet/config.rkt"
>temp35_0
>for-loop
>run-module-instance!
>for-loop
>[repeats 1 more time]
>run-module-instance!
>for-loop
>[repeats 1 more time]
>run-module-instance!
> 
> Nate
> 
> 
> On Mon, Jul 13, 2020 at 1:03 PM Ryan Culpepper 
> wrote:
> 
> > I don't know if it helps, but config:installation-name is a promise
> > defined by setup/private/dirs.
> >
> > Ryan
> >
> >
> > On Mon, Jul 13, 2020 at 7:23 PM Matthew Flatt  wrote:
> >
> >> I'm not sure how it could be in `dynamic-require` itself, as opposed to
> >> a library that is loaded by `dynamic-require`, but it sounds like a bug
> >> at some level. Can you provide a small example?
> >>
> >> At Mon, 13 Jul 2020 11:03:41 -0500, Nate Griswold wrote:
> >> > Sam, thanks
> >> >
> >> > To be clear, this crash happened DURING a dynamic-require and judging by
> >> > the stack trace looked to be part of the dynamic-require machinery (and
> >> > this seems to depend on the installation name).
> >> >
> >> > I actually wasn't depending on anything but racket/base, so i don't
> >> believe
> >> > anything i was using was causing a separate dependency on promise.
> >> >
> >> > Nate
> >> >
> >> >
> >> > On Mon, Jul 13, 2020 at 9:32 AM Sam Tobin-Hochstadt <
> >> sa...@cs.indiana.edu>
> >> > wrote:
> >> >
> >> > > My guess, not having looked further than your email, is that when you
> >> > > don't include racket/promise, something is supplying a promise to
> >> something
> >> > > else but there are two different instantiations of the promise
> >> library,
> >> > > causing the force call from one not to recognize the promise from the
> >> > > other. Then force just becomes the identity function, and passes
> >> through a
> >> > > promise to somewhere that isn't expecting one.
> >> > >
> >> > > Is it possible that some library you're using features promises?
> >> > > Alternatively, it might be that the embedding code needs an explicit
> &g

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

2020-07-13 Thread Matthew Flatt
I'm not sure how it could be in `dynamic-require` itself, as opposed to
a library that is loaded by `dynamic-require`, but it sounds like a bug
at some level. Can you provide a small example?

At Mon, 13 Jul 2020 11:03:41 -0500, Nate Griswold wrote:
> Sam, thanks
> 
> To be clear, this crash happened DURING a dynamic-require and judging by
> the stack trace looked to be part of the dynamic-require machinery (and
> this seems to depend on the installation name).
> 
> I actually wasn't depending on anything but racket/base, so i don't believe
> anything i was using was causing a separate dependency on promise.
> 
> Nate
> 
> 
> On Mon, Jul 13, 2020 at 9:32 AM Sam Tobin-Hochstadt 
> wrote:
> 
> > My guess, not having looked further than your email, is that when you
> > don't include racket/promise, something is supplying a promise to something
> > else but there are two different instantiations of the promise library,
> > causing the force call from one not to recognize the promise from the
> > other. Then force just becomes the identity function, and passes through a
> > promise to somewhere that isn't expecting one.
> >
> > Is it possible that some library you're using features promises?
> > Alternatively, it might be that the embedding code needs an explicit
> > dependency on promises.
> >
> > Sam
> >
> > On Mon, Jul 13, 2020, 10:18 AM Nate Griswold 
> > wrote:
> >
> >> Hello.
> >>
> >> I noticed something and was wondering what the list thinks:
> >>
> >> I am using an embedded racket Ics) and i noticed that if i embed a file
> >> and don't include any libraries (for a very bare bones c file) i have
> >> problems with a crash on a promise on any dynamic-require:
> >>
> >> build-path: contract violation
> >>   expected: (or/c path-string? path-for-some-system? 'up 'same)
> >>   given: #
> >>
> >> but if i do a (require racket/promise) in my rkt argument to --c-mods OR
> >> if i do a ++lib racket/promise i get no crash.
> >>
> >> So is this expected behavior? Should racket/promise always be included or
> >> no? And what exactly is going on under the hood here?
> >>
> >> Nate
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Racket Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to racket-users+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> >> 
> https://groups.google.com/d/msgid/racket-users/CAM-xLPpg_0Ef8ByjS01Y1pKEeeFMVkF
> k3dvGcdpRaYo3ZqDb9A%40mail.gmail.com
> >> 
>  Fk3dvGcdpRaYo3ZqDb9A%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/CAM-xLPpaOSxvPEDYzmkAXdFg%2BLTMA
> H1mw57kJt7%3DCe6ipXmXDw%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/20200713112340.24e%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] How to extract

2020-07-13 Thread Matthew Flatt
I see that there's not a good way right now, but here's a workaround
that uses information about the current layout:

A cpointer value is implemented as a Chez Scheme record with either 1
field or 2 fields. There are 2 fields only when the cpointer has an
offset as a result of `ptr-add`, so you can probably ignore that.

To extract the first field, assume that a record has the same layout as
a vector, so use `Svector_ref(p, 0)` to extra the field from the
cpointer `p`.

Then you can use `Sunsigned_value()` to convert that field value to a
pointer-sized integer, then case.

I might have some part of that wrong, but it should be close... Of
course, there should be better support for record-field access and
cpointer extraction, so I'll add to the API.


At Mon, 13 Jul 2020 11:43:35 -0500, Nate Griswold wrote:
> I had a question. In embedded racket, I am passing a _cpointer value back
> to c code by way of racket_apply's return value.
> 
> Looking over https://docs.racket-lang.org/inside/cs-values_types.html ,
> there appears to be a group of functions associated with extracting values
> from ptrs. I do not see one for a pointer ptr there.
> 
> Is there a way to get at a returned _cpointer value from c code?
> 
> Thanks
> 
> Nate
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAM-xLPrKGgAgii7BjyfvCs6i0BmbMp0
> yoo09UoUF0nqVzX_CXQ%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/20200713112050.3cf%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Creating links to Racket docs for functions in user-scope packages

2020-07-13 Thread Matthew Flatt
It's currently not intended to work for packages installed in user
scope --- only for packages in the main installation --- although
probably it shouldn't report a path error for a user-scope package.

I'm not sure how difficult it would be to make redirection work on a
user-scope package's documentation. The function doesn't "just work"
for user-scope, because the location where documentation is rendered is
different for user-scope packages and installation-scope packages. It
might end up being about the same implementation effort to improve the
error message or to make the function work on user-scope packages,
though.

At Sun, 12 Jul 2020 15:16:37 -0700 (PDT), "'Joel Dueck' via Racket Users" wrote:
> Trying to generate URLs for linking into the Racket docs. I get the error 
> below, but only when the package/identifier combo in question are installed 
> in user scope, and only when using the `#:external-root-url` keyword 
> argument:
> 
> > (define x (xref-binding->definition-tag (load-collections-xref) 
> '(deta/query lookup) 0))
> > x
> '(def ((lib "deta/query.rkt") lookup))
> 
> ;; works good:
> > (xref-tag->path+anchor (load-collections-xref) x)
> #
> "(def._((lib._deta/query..rkt)._lookup))"
> 
> > (xref-tag->path+anchor (load-collections-xref) x #:external-root-url 
> "http://docs.racket-lang.org/;)
> . . ../../../../../../Applications/Racket 
> v7.7/collects/racket/private/kw.rkt:1393:47: path-element->string: contract 
> violation
> expected: path?
> given: 'up
> 
> Is this a bug? Or is there a way to make this work for user-scope packages 
> as well?

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


Re: [racket-users] nested-flow and inset

2020-07-11 Thread Matthew Flatt
At Sat, 11 Jul 2020 11:47:22 -0600, Matthew Flatt wrote:
> To construct a style that has 'nested as a property, use `(style #f
> '(nested))` with `style` from `scribble/core`.

Wrong again: That should have been be 'inset as a name, not 'nested as
a property, so `(style 'inset ())`.

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


Re: [racket-users] nested-flow and inset

2020-07-11 Thread Matthew Flatt
At Sat, 11 Jul 2020 10:41:27 -0700 (PDT), Shriram Krishnamurthi wrote:
> My reading of the documentation for `nested-flow`
> 
> https://docs.racket-lang.org/scribble/core.html#%28def._%28%28lib._scribble%2Fc
> ore..rkt%29._make-nested-flow%29%29
> 
> is that I can use 'inset as the first argument. However, when I try to do 
> so, I get a contract error:
> 
> make-nested-flow: contract violation
> 
>   expected: style?
> 
>   given: 'inset
> 
>   in: the 1st argument of
> 
>   (-> style? (listof block?) nested-flow?)
> 
>   contract from: 
> 
>   /scribble-lib/scribble/core.rkt
> 
> This *looks* like it contradicts the documentation, which says that the 
> first argument is any/c:

You're right that the documentation is incorrect: It should say
`style?`. I'll fix that.

To construct a style that has 'nested as a property, use `(style #f
'(nested))` with `style` from `scribble/core`.

Helper functions like `nested` are more flexible and will auto-convert
a style-property symbol to a style, but the `nested-flow` constructor
isn't meant to do that.

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


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

2020-07-11 Thread Matthew Flatt
At Sat, 11 Jul 2020 10:36:33 -0600, Matthew Flatt wrote:
> Following up on Sam's suggestion, I recommend `xfvb-run` as something
> like
> 
>  xfvb-run racket -l handin-server

Should be `xvfb-run`. I always have trouble getting those letters in
the right order.

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


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

2020-07-11 Thread Matthew Flatt
At Sat, 11 Jul 2020 09:26:47 -0700 (PDT), Shriram Krishnamurthi wrote:
> I'm running headless Racket from a Docker container for auto-grading 
> assignments in Gradescope.
> 
> The students are writing BSL programs with 2htdp/image. This does not cause 
> any problems for most of them.
> 
> Two students, however, get an error in file loading with the error message 
> in the subject line («Gtk initialization failed for display ":0"»).
> 
> I finally localized the problem: it's because they are using the universe 
> Teachpack.
> 
> I don't know what in universe is causing this, but it seems rather weird 
> that *image*, which is fundamentally graphical, does not cause this problem 
> but *universe*, which is it fundamentally not, does.

It's helpful help to distinguish between "images" and "GUIs". The
`2htdp/image` library is only about drawing images, so it doesn't need
a GUI context. The `2htdp/universe` library deals with windows and
mouse clicks, so it needs a GUI context.

> Furthermore, this dependency means that any program that depends on 
> universe would likely not be able to be auto-graded (at least in a 
> Gradescope-like headless context), which seems a rather severe restriction. 
> (And ironic, given that the design of universe is to enable testing, and 
> hence also auto-grading.) I don't know how Northeastern does auto-grading 
> of universe that gets around this, but it's clearly in a different setting.

Following up on Sam's suggestion, I recommend `xfvb-run` as something
like

 xfvb-run racket -l handin-server


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/20200711103633.6a%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] suppressing scribble-common.js in Scribble output

2020-07-02 Thread Matthew Flatt
I don't know if there's a way to suppress "scribble-common.js" except
at the level of the rendering object --- that is, not something that
can be done within the document, currently. Also, the initialization
arguments that would replace "scribble-common.js" are probably not
documented. There's a lot of room for improvement there.

But you can add more JS after the built-in pieces: A
`js-style-addition` as a style property specifies JS to load after
other things.

At Thu, 2 Jul 2020 20:09:53 -0700 (PDT), Shriram Krishnamurthi wrote:
> How does one suppress scribble-common.js? I really don't understand why the 
> file loads for all Scribble langs — it contains things like search box 
> support for documentation! 
> 
> In addition, it takes over the window.onload, overriding any previous 
> content. About this, it has the following odd remark:
> 
> // Note: could make a function that inspects and uses window.onload to 
> chain to
> // a previous one, but this file needs to be required first anyway, since it
> // contains utilities for all other files.
> 
> I'm not sure what "all other files" it's referring to, but it actually 
> appears *last* in the load sequence. (E.g., loading additional JS through a 
> custom prefix means those get loaded before scribble-common.js…is there 
> some other way of loading JS files so they are loaded *after*
>  scribble-common.js?)
> 
> 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/e219a0cd-7646-4bdf-a620-ac0d70f3
> 8cceo%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/20200702212417.152%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] suppressing parts of Scribble (HTML) output

2020-07-02 Thread Matthew Flatt
Does the `'no-toc+aux` style property help at all? For example,

  #lang scribble/manual

  @title[#:style '(no-toc+aux)]{Example}

  Some content.

should render with nothing on the left.

At Thu, 2 Jul 2020 18:47:19 -0700 (PDT), Shriram Krishnamurthi wrote:
> I am trying to use Scribble to generate HTML documents (blog-like, but not 
> exactly, so Frog doesn't meet my needs) but would really like to eliminate 
> the material in the left gutter (TOC). (Ideally I'd also like to suppress 
> the author tag.)
> 
> I've spent some time going through the source of Greg Hendershott's Frog 
> and Ryan Culpepper's Scriblogify and both seem to use essentially the same 
> technique, which is a total hack: call Scribble to generate the HTML, then 
> go into it and search for a particular DOM structure to extract the "main 
> content". For instance, Scriblogify does this
> 
> (define (get-blog-entry file)
> 
>   (let* ([doc (call-with-input-file file html->xexp)]
> 
>  [title ((sxpath "//title/text()") doc)]
> 
>  [title (and (pair? title) (car title))]
> 
>  [content
> 
>   ((sxpath 
> "//div[@class='SAuthorListBox']/following-sibling::node()") doc)]
> 
> while Frog does
> 
>   ;; Extract the part we care about -- the elements in the "main" div
> 
>   ;; after the "versionbox" div.  (The `match` might be too fragile
> 
>   ;; way to do this.)
> 
>   (match (~> (build-path dir "frog.html")
> 
>  (with-input-from-file read-html-as-xexprs)
> 
>  cadr)
> 
> ; HTML produced from #scribble/manual
> 
> [`(html
> 
>()
> 
>(head . ,_)
> 
>,(list-no-order
> 
>  `(div ([class "maincolumn"])
> 
>(div ([class "main"])
> 
> (div ([class "versionbox"])
> 
>  (span ([class "versionNoNav"]) ,_))
> 
> . ,xs))
> 
>  _ ...))
> 
>  (adjust-scribble-html xs img-uri)]
> 
> (it actually has different patterns depending on the Scribble language 
> used!).
> 
> What's a better, cleaner way of doing this? I *suppose* one could build a 
> whole renderer, which seems like an insane amount of work. Hopefully 
> there's a way of doing this as a "delta" on the existing renderer, but I 
> haven't had any luck finding an example of a custom renderer that, say, 
> suppresses the printing of the TOC and/or the author list but leaves the 
> rest of the page alone.
> 
> [Yes, I could set up the CSS so that the TOC appears hidden, but it would 
> still be present in the source and could be found by one of several means. 
> I would really like it to not be there. And I hope there's a better way of 
> doing it than modifying the JavaScript to, on load, go and delete the 
> undesired elements…]
> 
> Any ideas/suggestions/pointers? 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/246966eb-3521-40fe-93c5-b4bf6a81
> 379eo%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/20200702210047.d9%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Wills, plumbers, and checking if a port is closed

2020-06-30 Thread Matthew Flatt
At Tue, 30 Jun 2020 16:27:56 -0400, David Storrs wrote:
> I have a port that (my current theory says) is being closed when it
> shouldn't, but I'm having trouble isolating exactly where and when.  I
> thought maybe I could do something Rackety to say "as soon as this port
> gets closed, run this function".  I went digging through Wills and Plumbers
> but I'm having trouble grokking it.  Am I headed in the right direction, or
> is there a better way?

Wills and plumbers will not help.

Do you have control over where the port is used to that you can
substitute another port? In that case, you could wrap the port with
`make-input-port` or `make-output-port`, and then you have control over
the close method.

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


Re: [racket-users] about 《Revenge of the Son of the Li sp Machine》 Appendix

2020-06-20 Thread Matthew Flatt
At Fri, 19 Jun 2020 20:25:47 -0700 (PDT), Yuki Lee wrote:
> https://www2.ccs.neu.edu/racket/pubs/icfp99-ffkf.pdf 
>
> I have read this paper.
> I encountered a problem when I tried to run the code at the end.

Unfortunately, that code that pre-dates the current Racket module
system, so it did not keep running for very long.

Enclosed is a somewhat modernized version of the code that should run
in recent (last 15-20 years?) Racket.


Matthew

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


esq.rkt
Description: Binary data


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

2020-06-17 Thread Matthew Flatt
At Wed, 17 Jun 2020 10:24:37 -0400, Sam Tobin-Hochstadt wrote:
> - on Racket BC, operations like `+` do indeed block

... which mixing, say, fixnum and flonum arguments, but not when
operating on all fixnums or all flonums.

In this case, it may be the `in-range` with flonum bounds that results
in `+` with fixnum 1 and a flonum.

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


Re: [racket-users] Why does this counter behave differently in different runtimes?

2020-06-17 Thread Matthew Flatt
Yes, clearly a BC compiler bug --- and probably almost as old as
Racket. The bug was specific to `set!` on a locally bound variable as
the first subexpression of `begin0`.

I've pushed a repair.

Thanks!

At Wed, 17 Jun 2020 03:35:51 -0500, Alexis King wrote:
> This is quite curious. It appears to be a compiler bug. Here’s a very 
> slightly 
> smaller test case:
> 
> #lang racket/base
> (define count!
>   (let ([i 0])
> (λ () (begin0
> (set! i (add1 i))
> (+ i)
> (count!)
> 
> The fully-expanded program looks fine, so it isn’t the expander’s fault:
> 
> (module counter racket/base
>   (#%module-begin
>(module configure-runtime '#%kernel
>  (#%module-begin (#%require racket/runtime-config) (#%app configure 
> '#f)))
>(define-values
> (count!)
> (let-values (((i) '0))
>   (lambda () (begin0 (set! i (#%app add1 i)) (#%app + i)
>(#%app call-with-values (lambda () (#%app count!)) print-values)))
> 
> But `raco decompile` reveals that begin0 has been mysteriously replaced with 
> begin in the compiled program:
> 
> (module counter 
>   (require (lib "racket/base.rkt"))
>   (provide)
>   (define-values
>(count!)
>(let ((local54 '0))
>  (begin
>(set! local54 (#%box local54))
>(lambda ()
>  '#(count! # 4 4 53 63 #f)
>  '(flags: preserves-marks single-result)
>  '(captures: (val/ref local54))
>  (begin
>(#%set-boxes! (local54) (add1 (#%unbox local54)))
>(+ (#%unbox local54)))
>   (#%apply-values print-values (count!))
>   (void)
>   (module (counter configure-runtime) 
> (require '#%kernel (lib "racket/runtime-config.rkt"))
> (provide)
> (print-as-expression '#t)
> (void)))
> 
> It seems perhaps an optimization has gone awry. The bug appears to be quite 
> old: I can reproduce it as far back as 6.1.1. (I didn’t test any versions 
> earlier than that.) Unsurprisingly, the issue does not occur on Racket CS, 
> which is consistent with the hypothesis that this is a compiler bug.
> 
> Alexis
> 
> > On Jun 17, 2020, at 02:04, Sage Gerard  wrote:
> > 
> > I attached a video demonstrating what I'm seeing. In case it does not load 
> or is not available, I'll summarize here. Forgive any typos; it's been a late 
> night of coding.
> > 
> > Here's a module with an incorrect counter. It's incorrect because it uses 
> begin0, and is therefore expected to return void instead of an incrementing 
> integer.
> > 
> > #lang racket
> > (provide count!)
> > (define count!
> >   (let ([i 0])
> > (λ () (begin0
> > (set! i (add1 i))
> > (~v i)
> > 
> > Notice that I added the ~v to format the return value. If I launch Racket 
> v7.7.0.5 using racket -it prog.rkt, (count!) returns the formatted value. But 
> if I remove the ~v, it behaves as written (returning void).
> > 
> > The video shows the behavior with and without ~v, both in DrRacket and 
> racket. DrRacket is the only environment that consistently runs the code 
> correctly.
> > 
> > ~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/781BE0E5-E6E5-4F0B-8B46-5227FDFB
> 8835%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/20200617071306.bc%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Re: How to make DrRacket interactions window use the same reader as the definitions window?

2020-06-03 Thread Matthew Flatt
At Fri, 29 May 2020 09:25:58 -0700 (PDT), Thomas Dickerson wrote:
> On Friday, May 29, 2020 at 11:29:38 AM UTC-4, Matthew Flatt wrote:
> > DrRacket uses `pretty-print`, which will print numbers using 
> > `number->string`, and so (I think) won't go through your parameter. 
> 
> This sounds like a good lead - curious if this also applies to
> `write` and `display` as well? I was having trouble with all three.

The pretty print hooks apply only to `pretty-print`, `pretty-write`,
and `pretty-display`. They may be most useful when implementing a
printer by calling `pretty-print`, etc., instead of setting the hooks
globally and expecting that pretty-print` is used.

> > I think there may be problems with parametering the core printer, 
> > partly because printing is is sometimes used where `read` is supposed 
> > to work on the result, but I think there may be other issues and I 
> > haven't thought through them enough. 
> >
> 
> The intended use is in a setting where `read` has already been extended 
> (cf. my original question in this thread, which is that the DrRacket 
> interactions window appears to ignore any `read` extensions provided by a 
> #lang)

It's possible to globally extend `read` via a readtable, but there's
also `call-with-default-reading-parameterization`, which various
libraries use to make sure they have the default reader settings (e.g.,
when reading a preferences file). There's not currently anything that
libraries can use like `call-with-default-writing-parameterization`,
which means that globally changing `write` could break libraries.

Meanwhile, it's possible to change the `print` function more globally
through `global-port-print-handler`.

Finally, there's `display`. I think `display` in principle should be
more configurable, because it's meant to about how things are displayed
for humans to read. 

These different approaches, with a relatively flexible reader and and a
relatively inflexible writer, evolved as a result of various pressures.
I think the write side is a little closer to right idea with its
distinction between `write` for serialization, `print` for displaying
values, and `display` for showing things for humans. (On the read,
side, we could have done better by making a cleaner separation between
`read` and `read-syntax`. Still, it's complicated.)

I think a variant of your PR that just affects `display` may be ok, and
it would be worth exploring if that solves a problem. Given that
`print` and `display` seem safely configurable, the question is whether
you want to modify `write` just because that's a third printing
function or because it's important in your target use.

If, for example, your language wants to provide a `write` that isn't
the Racket serialization write, it can always provide a different
function as `write`. That won't affect other libraries that may be
called by programs in your language, but my point is that it generally
shouldn't; those libraries should be using `write` for
serialization-type purposes.

At Fri, 29 May 2020 13:24:17 -0700 (PDT), Thomas Dickerson wrote:
> Quick follow-up: 
> It looks like I may somehow be able to change DrRacket's printing and 
> reading behavior on a per-language basis somehow using the classes here 

I don't think you want that layer of tools. At the DrRacket layer, you
want to stay in the `#lang` world --- so, don't do anything
DrRacket-specific.

At the level of the `#lang`/module system, a language can parameterize
run-time functionality, such as the reader and printer, through a
`configure-runtime` submodule. See

https://docs.racket-lang.org/guide/module-runtime-config.html

and

https://docs.racket-lang.org/reference/running-sa.html#%28part._configure-runtime%29

So, that's the place where you'd update the reader, printer, and
displayer.

> One question - to what extent are pretty-print-print-hooks expected to 
> cooperate with the current value of that parameter when printing compound 
> or recursive values?
> It would be great to install a hook that delegates to the existing hook for 
> everything but numbers, but that approach not working with 
> port-print-handler et al. is what led me to parameterizing over all of 
> print et al.

>From a language implementation perspective where you're setting the
global print handler to use `pretty-print`, your language gets to set
the starting point, and libraries as used by programs in your language
can cooperate with it by extending (instead of replacing) the printer.

So, I think you'd want to make the language use `pretty-print` and
recur as needed (which is not at all for just changing numbers) to
allow library-based extensions.

At Fri, 29 May 2020 17:06:14 -0400, Thomas Dickerson wrote:
> Interesting - does the default #%top-interaction behave differently from
> #%module-begin w.r.t. to a #lang's read?
> Right now my main.rkt is providing the standard

Re: [racket-users] raco setup --only-docs Is there something like this?

2020-06-02 Thread Matthew Flatt
You could use `-n` to skip the ".zo"-building part, and there are
similar arguments for other steps.

You may also find it helpful to use `-j 1`. Although `raco setup`
should be smarter about spinning up places to build multiple documents
in parallel, it currently isn't.

At Tue, 2 Jun 2020 07:40:39 -0700 (PDT), Simon Schlee wrote:
> Hello,
> 
> I like that I can run: 
> raco setup --doc-index my-collection-name
> 
> and it builds the documentation and makes it searchable on my local machine.
> But I was wondering if there is a way to speed-up/skip some of the usual 
> setup stuff that happens before building the documentation?
> 
> Should I use raco scribble instead?
> If so is there a certain set of raco scribble arguments that is equivalent 
> to what raco setup does?
> 
> 
> Simon
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/5bd3ccd6-c5ba-4bca-9bde-8c0efbbd
> d8c2%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/20200602091435.3c4%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Re: How to make DrRacket interactions window use the same reader as the definitions window?

2020-05-29 Thread Matthew Flatt
DrRacket uses `pretty-print`, which will print numbers using
`number->string`, and so (I think) won't go through your parameter.

I think there may be problems with parametering the core printer,
partly because printing is is sometimes used where `read` is supposed
to work on the result, but I think there may be other issues and I
haven't thought through them enough.

Just to make sure, does using the pretty printer and its hooks
(especially `pretty-print-print-hook`) work for your goals?

At Fri, 29 May 2020 07:35:03 -0700 (PDT), Thomas Dickerson wrote:
> On an apparently related note:
> 
> I have modified Racket to allow parameterized control over how numbers are 
> written/printed/displayed ( cf. https://github.com/racket/racket/pull/3222 
> ).
> This works fine from command-line racket, but DrRacket (installed using 
> `raco pkg install -i drracket` of my modified racket) is merrily doing its 
> own thing and printing numbers without invoking my parameterized routine. 
> 
> It doesn't appear to be a case of DrRacket using a separate binary, because 
> I can still read and set the parameter, it just has no effect.
> 
> Thoughts?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/6f260d7e-68e0-454c-9d81-04d74cb7
> 8b9a%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/20200529092932.2e0%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Hunting a possible fsemaphore-post/wait bug

2020-05-23 Thread Matthew Flatt
At Sat, 23 May 2020 18:51:23 +0200, Dominik Pantůček wrote:
> But that is just where the issue is showing up. The real question is how
> the counter gets decremented twice (given that fsemaphores should be
> futures-safe).

I found a configuration that triggered the bug often enough on my
machine. Yes, it was a dumb mistake in the implementation of
fsemaphores. In your example, it wasn't so much that the counter
fsemaphore was decremented twice, but that the lock fsemaphore could go
negative --- so it didn't actually lock.

I've pushed a repair.


FWIW, after looking at this example more, I see why it's still not
enough in principle to make a thread that waits on the result of
`do-start-workers` or to run `do-start-workers` after the enqueue
loops. The `start-workers` function can run a dequeue loop after
starting a future to do the same, and before touching that future. So,
the dependencies aren't as linear as I thought before.

If your real code looks anything like this, consider using a CAS
operation, like `box-cas!`, instead of an fsemaphore as lock for the
queue. The queue's use of an fsemaphore for counting and signaling
seems fine, though.

In any case, the example worked well to expose the fsemaphore bug.

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


Re: [racket-users] Hunting a possible fsemaphore-post/wait bug

2020-05-23 Thread Matthew Flatt
I'm not sure this is the problem that you're seeing, but I see a
problem with the example. It boils down to the fact that futures do not
provide concurrency.

That may sound like a surprising claim, because the whole point of
futures is to run multiple things at a time. But futures merely offer
best-effort parallelism; they do not provide any guarantee of
concurrency.

As a consequence, trying to treat an fsemaphore as a lock can go wrong.
If a future manages to take an fsemaphore lock, but the future is not
demanded by the main thread --- or in a chain of future demands that
are demanded by the main thread --- then nothing obliges the future to
continue running; it can hold the lock forever.

(I put the blame on femspahores. Adding fsemaphores to the future
system was something like adding mutation to a purely functional
language. The addition makes certain things possible, but it also
breaks local reasoning that the original design was supposed to
enable.)

In your example program, I see

 (define workers (do-start-workers))
 (displayln "started")
 (for ((i 1))
   (mfqueue-enqueue! mfq 1))

where `do-start-workers` creates a chain of futures, but there's no
`touch` on the root future while the loop calls `mfqueue-enqueue!`.
Therefore, the loop can block on an fsemaphore because some future has
taken the lock but stopped running for whatever reason.

In this case, adding `(thread (lambda () (touch workers)))` before the
loop after "started" might fix the example. In other words, you can use
the `thread` concurrency construct in combination with the `future`
parallelism construct to ensure progress. I think this will work
because all futures in the program end up in a linear dependency chain.
If there were a tree of dependencies, then I think you'd need a
`thread` for each `future` to make sure that every future has an active
demand.

If you're seeing a deadlock at the `(touch workers)`, though, my
explanation doesn't cover what you're seeing. I haven't managed to
trigger the deadlock myself.

At Sat, 23 May 2020 18:51:23 +0200, Dominik Pantůček wrote:
> Hello again with futures!
> 
> I started working on futures-based workers and got quickly stuck with a
> dead-lock I think does not originate in my code (although it is two
> semaphores, 8 futures, so I'll refrain from strong opinions here).
> 
> I implemented a very simple futures-friendly queue using mutable pairs
> and created a minimal-deadlocking-example[1]. I am running racket 3m
> 7.7.0.4 which includes fixes for the futures-related bugs I discovered
> recently.
> 
> Sometimes the code just runs fine and shows the numbers of worker
> iterations performed in different futures (as traced by the 'fid'
> argument). But sometimes it locks in a state where there is one last
> number in the queue (0 - zero) and yet the fsemaphore-count for the
> count fsemaphore returns 0. Which means the semaphore was decremented
> twice somewhere. The code is really VERY simple and I do not see a
> race-condition within the code, that would allow any code path to
> decrement the fsema-count fsemaphore twice once the worker future
> receives 0.
> 
> I am able to reproduce the behavior with racket3m running under gdb and
> get the stack traces for all the threads pretty consistently. The
> deadlock is apparently at:
> 
>   2Thread 0x77fca700 (LWP 46368) "mfqueue.rkt"
> futex_wait_cancelable (private=, expected=0,
> futex_word=0x559d8e78) at ../sysdeps/nptl/futex-internal.h:183
> 
> But that is just where the issue is showing up. The real question is how
> the counter gets decremented twice (given that fsemaphores should be
> futures-safe).
> 
> Any hints would be VERY appreciated!
> 
> 
> Cheers,
> Dominik
> 
> [1] http://pasterack.org/pastes/28883
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/5dcf1260-e8bf-d719-adab-5a0fd937
> 8075%40trustica.cz.

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


Re: [racket-users] Cross-building Racket applications for 64bit Windows on Linux

2020-05-23 Thread Matthew Flatt
Thinking about this a little more, I don't think all the pieces are in
place for CS. At least, I don't remember setting up all the pieces...

The extra piece needed for Racket CS is a Chez Scheme cross-compiler
that runs on Linux but produces machine code for Windows. That can be
done --- and it is done, because our distributions for Windows are
built on Linux (without wine). But I don't think the cross compilers
are stashed anywhere right now, and we'll need to offer NxM cross
compilers for N host systems and M target systems.

So, if building on a Linux target for Windows works for BC (which is a
different question than trying to run BC on wine), then we can start
thinking about how to fill in the last NxM pieces for CS.

At Sat, 23 May 2020 10:25:31 -0600, Matthew Flatt wrote:
> Have you already tried using `raco exe` on Linux (i.e., using Racket
> for Linux) but generating Windows executables?
> 
>   https://docs.racket-lang.org/raco/cross-system.html
> 
> 
> Note that the "tarball" distributions at places like
> 
>https://download.racket-lang.org/releases/7.7/
> 
> can be handy for setting up a .
> 
> 
> At Sat, 23 May 2020 17:39:58 +0200, Dominik Pantůček wrote:
> > Hello Racketeers,
> > 
> > although I am developing Racket applications on Linux, our customers are
> > usually running Windows. The good thing about Racket (and racket/gui
> > especially) is that it requires virtually no OS-specific code for many -
> > even non-trivial - tasks. However it is not that straightforward to
> > produce binaries for different target platform.
> > 
> > Since last summer, we have been successfully using wine and Racket
> > Windows builds to create 32bit binaries. However with Racket BC it was
> > impossible to make it work with 64bit Windows builds. This is still the
> > case even with latest snapshots and latest wine bundled with Ubuntu 20.04.
> > 
> > It turns out, that Racket CS works flawlessly under wine - including
> > raco.exe exe. And with the latest patches[1] (thanks Matthew and
> > DaLynX), it is possible to produce working 64bit Windows binaries from
> > Racket programs on Linux using wine.
> > 
> > As my work is heavily CPU- and memory-bound, the 32bit address space
> > limit was quite a limit.
> > 
> > However, once we tried to embed the build process into our
> > (Gitlab-based) CI/CD, we failed miserably. Combining wine and Racket
> > windows builds (7.7.0.6 snapshots from University of Utah) turned out to
> > be a terrible nightmare under Docker.
> > 
> > On my workstation, it is absolutely straightforward:
> > 
> > rm -fr ~/.wine # Do not try this without backing up, if you need it
> > wine racket-7.7.0.6-x86_64-win32-cs.exe
> > 
> > Now just click next next next with the installer and you are ready.
> > Building a 64bit Windows binary is just a matter of single:
> > 
> > wine ~/.wine/drive_c/Program\ Files/Racket-7.7.0.6/raco.exe exe --gui
> > --embed-dlls program.rkt
> > 
> > Of course, any packages needed have to be installed using raco.exe pkg
> > in the same wine prefix.
> > 
> > But when you take the ~/.wine prefix and try to run it under docker,
> > nothing works at all and tracing what is happening is extremely
> > difficult with very cryptic results.
> > 
> > We ruled out X11 dependency - raco.exe works just fine after I `unset
> > DISPLAY` on my workstation. And the results in Docker are no different
> > with Xvfb installed and running. We got to a point where the raco.exe
> > actually starts as a process under wine in Docker and it silently fails
> > upon startup.
> > 
> > Any ideas where to look and what to test? I strongly assume Racket is
> > not the root cause of the problem here, but rather the combination of
> > wine under Docker. However, Racket sometimes uses an OS-specific
> > trickery so I am sort of hoping that the described behavior rings a bell
> > for someone :)
> > 
> > 
> > Cheers,
> > Dominik
> > 
> > [1]
> > 
> https://github.com/racket/racket/commit/61cefe693a047e22ca44752eafb9eb9e2e65409
> > f
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/20200523102531.1f5%40sirmail.smt
> p.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/20200523103853.23%40sirmail.smtp.cs.utah.edu.


Re: [racket-users] Cross-building Racket applications for 64bit Windows on Linux

2020-05-23 Thread Matthew Flatt
Have you already tried using `raco exe` on Linux (i.e., using Racket
for Linux) but generating Windows executables?

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


Note that the "tarball" distributions at places like

   https://download.racket-lang.org/releases/7.7/

can be handy for setting up a .


At Sat, 23 May 2020 17:39:58 +0200, Dominik Pantůček wrote:
> Hello Racketeers,
> 
> although I am developing Racket applications on Linux, our customers are
> usually running Windows. The good thing about Racket (and racket/gui
> especially) is that it requires virtually no OS-specific code for many -
> even non-trivial - tasks. However it is not that straightforward to
> produce binaries for different target platform.
> 
> Since last summer, we have been successfully using wine and Racket
> Windows builds to create 32bit binaries. However with Racket BC it was
> impossible to make it work with 64bit Windows builds. This is still the
> case even with latest snapshots and latest wine bundled with Ubuntu 20.04.
> 
> It turns out, that Racket CS works flawlessly under wine - including
> raco.exe exe. And with the latest patches[1] (thanks Matthew and
> DaLynX), it is possible to produce working 64bit Windows binaries from
> Racket programs on Linux using wine.
> 
> As my work is heavily CPU- and memory-bound, the 32bit address space
> limit was quite a limit.
> 
> However, once we tried to embed the build process into our
> (Gitlab-based) CI/CD, we failed miserably. Combining wine and Racket
> windows builds (7.7.0.6 snapshots from University of Utah) turned out to
> be a terrible nightmare under Docker.
> 
> On my workstation, it is absolutely straightforward:
> 
> rm -fr ~/.wine # Do not try this without backing up, if you need it
> wine racket-7.7.0.6-x86_64-win32-cs.exe
> 
> Now just click next next next with the installer and you are ready.
> Building a 64bit Windows binary is just a matter of single:
> 
> wine ~/.wine/drive_c/Program\ Files/Racket-7.7.0.6/raco.exe exe --gui
> --embed-dlls program.rkt
> 
> Of course, any packages needed have to be installed using raco.exe pkg
> in the same wine prefix.
> 
> But when you take the ~/.wine prefix and try to run it under docker,
> nothing works at all and tracing what is happening is extremely
> difficult with very cryptic results.
> 
> We ruled out X11 dependency - raco.exe works just fine after I `unset
> DISPLAY` on my workstation. And the results in Docker are no different
> with Xvfb installed and running. We got to a point where the raco.exe
> actually starts as a process under wine in Docker and it silently fails
> upon startup.
> 
> Any ideas where to look and what to test? I strongly assume Racket is
> not the root cause of the problem here, but rather the combination of
> wine under Docker. However, Racket sometimes uses an OS-specific
> trickery so I am sort of hoping that the described behavior rings a bell
> for someone :)
> 
> 
> Cheers,
> Dominik
> 
> [1]
> https://github.com/racket/racket/commit/61cefe693a047e22ca44752eafb9eb9e2e65409
> f

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


Re: [racket-users] Detecting whether failure-result is used by dict-ref using chaperones?

2020-05-21 Thread Matthew Flatt
Stepping back a little, a chaperone constructor for a datatype often
needs some inside information and cooperation from the dataype
implementation. For example, `chaperone-hash` has the property that you
want --- the filter applied to a `hash-ref` result doesn't get used if
a failure thunk produces the `hash-ref` result --- and that works
because `hash-ref` and `chaperone-hash` are implemented together.

I'm guessing that you don't have access to a dictionary implementation
because new kinds of dictionaries can be created by implementing
`gen:dict`. Maybe `dict/c` based on chaperones can only work for
dictionaries that supply additional implementation hooks by also
implementing `gen:dict-chaperone` (or something like that).

At Thu, 21 May 2020 11:56:15 -0400, Alex Knauth wrote:
> Hello,
> 
> I'm working on a version of `dict/c` with chaperones, but I'm running into a 
> surprising problem that only comes up because of the `failure-result` 
> optional-argument to `dict-ref`.
> 
> When the `failure-result` is used, I don't want the "value" contract to apply 
> to that result. But when the failure-result isn't used, and the "value" 
> result 
> happens to be exactly equal to the failure-result, I do want the "value" 
> contract to apply to it. How do I distinguish those though?
> 
> I tried to take inspiration from Carl Eastlund's `dict/c` implemented in 
> `mischief/contract`, but it doesn't use chaperones so it is free to both add 
> an escape continuation, and change the `failure-result` input to always be a 
> new synthesized procedure. That way the new synthesized failure-result 
> procedure can call the escape continuation. If I'm constrained to chaperones, 
> I don't know how to do either of those things.
> 
> How can I detect whether the `failure-result` is used-or-not by the dict's 
> implementation of `dict-ref`, while keeping the `failure-result` a chaperone 
> of the original failure-result?
> 
> Alex Knauth
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/9612FD20-8FFB-420D-8BAD-8FF0F837
> 7AEC%40knauth.org.

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


Re: [racket-users] How do I properly set current-module-name-resolver for a process?

2020-05-19 Thread Matthew Flatt
At Tue, 19 May 2020 20:10:01 +, Sage Gerard wrote:
> I'm trying to figure out how to set current-module-name-resolver in
> advance of all other code for a process. I'm guessing this would
> require a custom launcher that does (for example) `racket -l
> foo/replace-resolver bar.rkt`.

That can work if

 * you either add a `-t` before `bar.rkt` to load it or
   `foo/replace-resolver` handles command-line arguments; and

 * you don't need to adjust resolution for any modules that are used in
   the implementation of `foo/replace-resolver`.

> In that sense, I expect that a `replace-resolver` of the form below
> wouldn't work because it runs at phase 0, after the expander resolved
> everything for `bar.rkt`.

If you go the route of adding `-t` before `bar.rkt`, the resolution
will not happen until after `foo/replace-resolver` runs.

> How do I do what I mean here across all phases, for all uses of 
> (dynamic-|local-)require everywhere in my program?

If you set the module name resolver, it applies to all phases.

(That's a hole in Racket's phase separation, and we don't like to talk
about it. :)

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


[racket-users] [CfP] DLS 2020 - Dynamic Languages Symposium, submission deadline July 9th

2020-05-18 Thread Matthew Flatt
The 16th Dynamic Languages Symposium (DLS) at SPLASH 2020 is the
premier forum for researchers and practitioners to share research and
experience on all aspects on dynamic languages.

DLS 2020 invites high quality papers reporting original research and
experience related to the design, implementation, and applications of
dynamic languages. Areas of interest include, but are not limited to,

 - innovative language features
 - innovative implementation techniques
 - innovative applications
 - development environments and tools
 - experience reports and case studies
 - domain-oriented programming
 - late binding, dynamic composition, and run-time adaptation
 - reflection and metaprogramming
 - software evolution
 - language symbiosis and multi-paradigm languages
 - dynamic optimization
 - interpretation
 - just-in-time and ahead-of-time compilation
 - soft/optional/gradual typing
 - hardware support
 - educational approaches and perspectives
 - semantics of dynamic languages
 - frameworks and languages for the Cloud and the IoT

Submission Details
--

Submissions must neither be previously published nor under review at
other events. DLS 2020 uses a lightweight double-blind, two-phase
reviewing process.

Papers are assumed to be in one of the following categories:

   **Research Papers:**  
  describe work that advances the current state of the art

   **Experience Papers:**  
  describe insights gained from substantive practical  
  applications that should be of a broad interest

   **Dynamic Pearls:**  
  describe a known idea in an appealing way to remind the  
  community and capture a reader’s interest

The program committee will evaluate each paper based on its
relevance, significance, clarity, and originality.
The paper category needs to be indicated during submission,
and papers are judged accordingly.

Papers are to be [submitted electronically](https://dls20.hotcrp.com/)
in PDF format. Submissions must be in the ACM SIGPLAN conference acmart
format, 10 point font, and should not exceed 12 pages. Please see full
details in the instructions for authors available at:

https://conf.researchr.org/home/dls-2020#Instructions-for-Authors

DLS 2020 will run a two-phase reviewing process to help authors make
their final papers the best that they can be. Accepted papers will be
published in the ACM Digital Library and will be freely available for
one month, starting two weeks before the event.

## Important Deadlines

Abstract Submission (optional): July 2, 2020  
Paper Submission:   July 9, 2020  
First Phase Notification:   August 7, 2020  
Revisions Due:  September 4, 2020
Final Notifications:Septemberr 18, 2020

All deadlines are 23:59 AoE (UTC-12h).

**AUTHORS TAKE NOTE:** The official publication date is the date the
proceedings are made available in the ACM Digital Library. This date
may be up to two weeks prior to the first day of your conference.
The official publication date affects the deadline for any patent
filings related to published work.

Program Committee
-

Alexandre Bergel, U Chile
Shigeru Chiba, U Tokyo
Stéphane Ducasse, Inria
Tim Felgentreff, HPI
Matthew Flatt, U Utah (chair)
Elisa Gonzalez Boix, VUB
Michael Homer, Victoria U Wellington
Mark Marron, Microsoft Research
Anders Møller, Aarhus
Manuel Rigger, ETH
Sukyoung Ryu, KAIST
Jeremy G. Siek, Indiana U
Francesco Zappa Nardelli, Facebook

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


Re: [racket-users] JIT and futures on aarch64

2020-05-16 Thread Matthew Flatt
At Sat, 16 May 2020 17:21:28 +0200, Dominik Pantůček wrote:
> after pushing futures on x86 and x86_64 to their limits (and helping
> fixing two bugs), I turned my focus on ARM. Apparently everything should
> work with 32bit arm without any hurdles (I am going to test that later
> today),

Futures and places are not currently supported on ARM for Racket BC.
I'm not sure how much effort it will be to support, because I'm unclear
on how much the current implementation relies on TSO --- but I suspect
that it's some, and that write fences are be needed in some places.

> Apparently latest versions
> of Lightning support aarch64.
> 
> I am willing to invest some time into porting that, but the question is
> how much work is needed. 

It will not be easy.

> Also - is it relevant for CS variant? (I would
> guess not). 

You're right: support for 64-bit ARM on Racket CS is completely
separate. Jesse Alama and Paulo Matos are working on that:

 https://groups.google.com/forum/#!msg/racket-dev/TaU3S0GZZbo/jtPD4IVTBwAJ

> And of course, how to do the actual porting - it seems to me
> the Racket's port is more than just a few minor changes. Maybe porting
> only the aarch64 part might be a reasonable way to go?

Yes, probably.

Before doing anything, I recommend investigating whether Racket CS is
more the right long-term choice. I think it is, although it has the
same immediate obstacles: no threaded configurations for ARM (just a
configuration issue or deeper?) and no 64-bit ARM. There's potentially
also the extra obstacle that we have not yet put as much effort into
futures for CS, yet, but my experience has been that catching up CS is
easier than improving Racket BC. Also, Chez Scheme doesn't yet unbox
floating-point arithmetic, which may or may not be relevant for your
purposes, but that's next on my list.


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/5ec01188.1c69fb81.ecfaa.350eSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Re: Strange behaviour of ptr-ref + ptr-add(?)

2020-05-10 Thread Matthew Flatt
Although `_double*` isn't currently meant to be handled there ---
there's no `ptr-ref/_double` specialization --- you're right that the
problem is in the `ptr-ref/double` and similar specializations in CS.

I've pushed a repair.

Thanks for the report, Laurent!

At Sun, 10 May 2020 13:57:50 +0200, Jens Axel Søgaard wrote:
> I can confirm that the bug is present in the latest snapshot of Racket CS
> on macOS.
> 
> FWIW  _double* is missing in this list, but I am not sure it whether it is
> supposed to be handled here.
> https://github.com/racket/racket/blob/920c899ba866ce59a0387862286521e3cc1dabfb/
> racket/src/schemify/ptr-ref-set.rkt#L46
> 
> /Jens Axel
> 
> Den søn. 10. maj 2020 kl. 10.51 skrev Laurent :
> 
> > Correction:
> > It's not Mac vs Linux, it's Racket BC (works) vs CS (doesn't work)
> >
> > On Sun, May 10, 2020 at 9:49 AM Laurent  wrote:
> >
> >> Hi all,
> >>
> >> We're trying to figure out why the last case below doesn't work on
> >> Linux, but works on MacOS. Does anyone have an explanation?
> >> The docs suggest that _double* shouldn't be different from _double for
> >> _reading_ values.
> >>
> >> More precisely,
> >>
> >> #lang racket
> >> (require ffi/unsafe)
> >>
> >> (define N 10)
> >> (define pt (malloc N _double 'atomic-interior))
> >> (for ([i (in-range N)])
> >>   (ptr-set! pt _double* i (+ 2. i)))
> >>
> >> ;; works
> >> (for/list ([i (in-range N)])
> >>   (ptr-ref pt _double i))
> >>
> >> ;; works
> >> (for/list ([i (in-range N)])
> >>   (ptr-ref (ptr-add pt i _double) _double*))
> >>
> >> ;; doesn't work!
> >> (for/list ([i (in-range N)])
> >>   (ptr-ref (ptr-add pt i _double) _double))
> >>
> >> --
> >> Output:
> >> (2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0)
> >> (2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0)
> >> (2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.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/CABNTSaFmfgTpTrWzfcxL%2BxQCqtge5
> Ls1eKW%2Bp0ftd%3D0q554ALg%40mail.gmail.com
> > 
>  5Ls1eKW%2Bp0ftd%3D0q554ALg%40mail.gmail.com?utm_medium=email_source=footer>
> > .
> >
> 
> 
> -- 
> -- 
> Jens Axel Søgaard
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CABefVgzNsmOEx3LV%3DvmV--gu3UD6k
> HZsRCfPQm0kn32Vo_ziKw%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/5eb7fc00.1c69fb81.a8f09.1621SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Another futures-related bug hunt

2020-05-09 Thread Matthew Flatt
At Sat, 9 May 2020 07:18:01 +0200, Dominik Pantůček wrote:
> would this be enough to open an issue for that?
> 
> (gdb) info threads
>Id   Target IdFrame
> * 1Thread 0x77c1b300 (LWP 19075) "tut22.rkt" 
> mark_backpointers (gc=gc@entry=0x559d10c0) at 
> ../../../racket/gc2/newgc.c:4078

Yes, this might identify the problem. Being stuck in a linked-list
iteration often means that there was a race updating the list.

The GC's write barrier is implemented by write-protecting pages and
handling SIGSEGV to record the modification (and remove write
protection until the next GC). If that handler is called in different
future threads, though, then there's currently a race on the list of
modified pages.

This race doesn't happen with places, because different places have
different GC instances. And it won't happen on Mac OS, because the
fault is handled at the Mach layer and routes exceptions for all
threads to a single handler thread.

I'll add a lock at lines 1092-1096 of "newgc.c", and we'll see if that
helps.

Thanks very much for your help!
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/5eb6acea.1c69fb81.f6df9.aa57SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Another futures-related bug hunt

2020-05-08 Thread Matthew Flatt
At Fri, 8 May 2020 09:34:32 +0200, Dominik Pantůček wrote:
> Apart from obvious strace (after freeze) and gdb (before/after freeze) 
> debugging to find possible sources of this bug, is there even a remote 
> possibility of getting any clue how can this happen based on the 
> information gathered so far? My thought go along the lines:
> 
> * flonums are boxed - but for some operations they may be immediate
> * apparently it is a busy-wait loop in RTT, otherwise 100% CPU usage is 
> impossible with this workload
> * unsafe ops are always suspicious, but again, the problem shows up even 
> when I switch to the safe versions - it just takes longer time
> * which means, the most probable cause is a race condition

The most useful information here is likely to be a stack trace from
each OS-level thread at the point where the application is stuck.

That could potentially tell us, for example, that it's a problem with
synchronization for a GC (where one of the OS threads that run futures
doesn't cooperate for some reason) or a problem with a the main thread
performing some specific work on a future thread's behalf.

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


Re: [racket-users] How to run multiple Racket installations?

2020-05-08 Thread Matthew Flatt
At Fri, 8 May 2020 01:55:17 -0700 (PDT), zeRusski wrote:
> First, does that even work? I noticed that both of them install packages 
> into ~/Library/Racket/development/ for me. Are both builds so compatible I 
> don't need to worry about packages stepping on each others toes i.e. 
> compiled with one but executed with the other?

No, the builds will collide there.

The intent of development mode is that you install further packages
"installation" scope, etc., to avoid contention at
"~/Library/Racket/development".

But if you need the "~/Library/Racket" space, there are tools like the
one Sam suggested, and there's a specific configuration for this...

> I think I'd rather have the two systems completely separated so I can
> actually compare oranges to oranges. Is there a way to guarantee
> that?

You can use something like

 raco pkg config -u --set name other-development

to give one of your development builds a different name. In this case,
that build would use "~/Library/Racket/other-development".

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


Re: [racket-users] Futures + threads SIGSEGV

2020-05-02 Thread Matthew Flatt
I wasn't able to produce a crash on my first try, but the Nth try
worked, so this is very helpful!

I'm investigating, too...

At Sat, 2 May 2020 08:26:10 -0400, Sam Tobin-Hochstadt wrote:
> I successfully reproduced this on the first try, which is good. Here's
> my debugging advice (I'm also looking at it):
> 
> 1. To use a binary with debugging symbols, use
> `racket/src/build/racket/racket3m` from the checkout of the Racket
> repository that you built.
> 2. When running racket in GDB, there are lots of segfaults because of
> the GC; you'll want to use `handle SIGSEGV nostop noprint`
> 3. It may not work for this situation because of parallelism, but if
> you can reproduce the bug using `rr` [1] it will be almost infinitely
> easier to find and fix.
> 
> I'm also curious about your experience with Racket CS and futures.
> It's unlikely to have the _same_ bugs, but it would be good to find
> the ones there are. :)
> 
> [1] https://rr-project.org
> 
> On Sat, May 2, 2020 at 7:56 AM Dominik Pantůček
>  wrote:
> >
> > Hello fellow Racketeers,
> >
> > during my research into how Racket can be used as generic software
> > rendering platform, I've hit some limits of Racket's (native) thread
> > handling. Once I started getting SIGSEGVs, I strongly suspected I am
> > doing too much unsafe operations - and to be honest, that was true.
> > There was one off-by-one memory access :).
> >
> > But that was easy to resolve - I just switched to safe/contracted
> > versions of everything and found and fixed the bug. But I still got
> > occasional SIGSEGV. So I dug even deeper (during last two months I've
> > read most of the JIT inlining code) than before and noticed that the
> > crashes disappear when I refrain from calling bytes-set! in parallel
> > using futures.
> >
> > So I started creating a minimal-crashing-example. At first, I failed
> > miserably. Just filling a byte array over and over again, I was unable
> > to reproduce the crash. But then I realized, that in my application,
> > threads come to play and that might be the case. And suddenly, creating
> > MCE was really easy:
> >
> > Create new eventspace using parameterize/make-eventspace, put the actual
> > code in application thread (thread ...) and make the main thread wait
> > for this application thread using thread-wait. Before starting the
> > application thread, I create a simple window, bitmap and a canvas, that
> > I keep redrawing using refresh-now after each iteration. Funny thing is,
> > now it keeps crashing even without actually modifying the bitmap in
> > question. All I need to do is to mess with some byte array in 8 threads.
> > Sometimes it takes a minute on my computer before it crashes, sometimes
> > it needs more, but it eventually crashes pretty consistently.
> >
> > And it is just 60 lines of code:
> >
> > #lang racket/gui
> >
> > (require racket/future racket/fixnum racket/cmdline)
> >
> > (define width 800)
> > (define height 600)
> >
> > (define framebuffer (make-fxvector (* width height)))
> > (define pixels (make-bytes (* width height 4)))
> >
> > (define max-depth 0)
> >
> > (command-line
> >  #:once-each
> >  (("-d" "--depth") d "Futures binary partitioning depth" (set! max-depth
> > (string->number d
> >
> > (file-stream-buffer-mode (current-output-port) 'none)
> >
> > (parameterize ((current-eventspace (make-eventspace)))
> >   (define win (new frame%
> >(label "test")
> >(width width)
> >(height height)))
> >   (define bmp (make-bitmap width height))
> >   (define canvas (new canvas%
> >   (parent win)
> >   (paint-callback
> >(λ (c dc)
> >  (send dc draw-bitmap bmp 0 0)))
> >   ))
> >
> >   (define (single-run)
> > (define (do-bflip start end (depth 0))
> >   (cond ((fx< depth max-depth)
> >  (define cnt (fx- end start))
> >  (define cnt2 (fxrshift cnt 1))
> >  (define mid (fx+ start cnt2))
> >  (let ((f (future
> >(λ ()
> >  (do-bflip start mid (fx+ depth 1))
> >(do-bflip mid end (fx+ depth 1))
> >(touch f)))
> > (else
> >  (for ((i (in-range start end)))
> >(define c (fxvector-ref framebuffer i))
> >(bytes-set! pixels (+ (* i 4) 0) #xff)
> >(bytes-set! pixels (+ (* i 4) 1) (fxand (fxrshift c 16)
> > #xff))
> >(bytes-set! pixels (+ (* i 4) 2) (fxand (fxrshift c 8) #xff))
> >(bytes-set! pixels (+ (* i 4) 3) (fxand c #xff))
> > (do-bflip 0 (* width height))
> > (send canvas refresh-now))
> > (send win show #t)
> >
> >   (define appthread
> > (thread
> >  (λ ()
> >(let loop ()
> >  (single-run)
> >  (loop)
> >   (thread-wait appthread))
> >
> > Note: the code is 

Re: [racket-users] Questions about working on DrRacket and gui

2020-05-01 Thread Matthew Flatt
At Fri, 1 May 2020 16:59:22 +0200, Dexter Lagan wrote:
>   I'd like to download DrRacket's source and profile it, say to improve
> scrolling performance or track this post-startup lock-up :

Does the start-time delay happen if you just type a number and hit
return, as opposed to typing an identifier? If not, the delay is
probably in loading documentation as triggered the first time DrRacket
sees an identifier to look up.

> - Do I need to download the entire Racket tree in order to build DrRacket?

You can start with minimal Racket and install DrRacket, as Sorawee
said, but be aware that installing DrRacket will pull in most of a
normal Racket distribution, anyway.

> - Is the DrRacket's built-in profiler solid enough to handle profiling
> DrRacket itself?

Running DrRacket inside of DrRacket is not likely to give you useful
information for something like scrolling, because DrRacket shares the
GUI instance with programs that it runs.

Running DrRacket with `raco profile` is more promising. It doesn't work
as easily as it should, partly because DrRacket wants to be in control,
and partly because `raco profile` doesn't deal with the custodian being
changed or waiting for a GUI program to exit. But I was able to run it
by supplying this wrapper program to `raco profile`:

 #lang racket/base
 (require racket/gui/base)

 (define c (make-custodian))
 (define done (make-semaphore))

 (parameterize ([current-custodian c])
   (parameterize ([exit-handler
   (lambda (v)
 (semaphore-post done)
 (custodian-shutdown-all c))])
 (define e (make-eventspace))
 (parameterize ([current-eventspace e])
   (queue-callback (lambda () 
 ;; here's where we finally start DrRacket
 (dynamic-require 'drracket #f))

 (sync done)


> - Modules in DrRacket's repo don't always have very telling names. Is there
> a document describing what each module does?

There's nothing like that, as far as I know.

> - If I make a change to a source file on my system, yet somebody else
> modifies the same file on their local system. Say both of our changes are
> accepted by whoever manages commits, how will accepted changes to the code
> merged?

We use Git, which provides good tools for merging changes.

>   Also, say I have a suggestion regarding how DrRacket handles compiling
> standalone executables, do I still need to create an issue on its Github?
> For work I compile to standalone all day long, and I really wish DrRacket
> didn't zip the resulting file (it would be better to have the .exe file in
> an automatically created /bin or /output folder). Zipping the file takes
> time, and I have to unzip it each time, which takes more time, this piles
> up when done every few minutes, all day long. I could use raco exe, but I'd
> rather stay in DrRacket, and I'm sure many people would rather have the
> default behavior to not zip, just to have single responsibility on the
> compile function.

That sounds plausible for many cases. (In some cases, depending on the
platform and the program, there are unavoidably multiple output files.)

>  One last questions: I have encountered differences in the behavior of
> macros between the REPL, a launcher and a standalone executable for
> distribution. Is there a document outlining the deeper differences between
> these three ways of executing Racket code?

I think you're probably encountering differences in how the namespace
and module registry is set up for `eval` and/or `dynamic-require`.

Maybe you've already seen these, but if not, they're good starting
points:

  https://docs.racket-lang.org/guide/reflection.html

  https://docs.racket-lang.org/raco/exe.html
  (especially paragraphs 3 through 6 about modules)


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


Re: [racket-users] Rhombus project plan

2020-04-29 Thread Matthew Flatt
At Wed, 29 Apr 2020 12:46:50 -0400, David Storrs wrote:
> In related news, a question for the list:  Once I have a handle on this, I
> would like to write a "How to Contribute to Racket Documentation" guide.
> Where would be the right place for this?  Should it be an expansion to an
> existing document (if so, which), an entirely new one, or...?

I suggest making it part of "Building, Distributing, and Contributing
to Racket":

 https://docs.racket-lang.org/racket-build-guide/index.html

which is also rendered as

 https://github.com/racket/racket/blob/master/build.md


The source is

 https://github.com/racket/racket/tree/master/pkgs/racket-build-guide

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


Re: [racket-users] Rhombus project plan

2020-04-29 Thread Matthew Flatt
At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
>   To the point: what would make Racket2 the ultimate tool (for me):
> Performance. Faster startup times, shorter execution times in general. 
> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps 
> binaries, bypassing the JIT altogether, would be a game-changer. As far as 
> high levels languages with functional concepts and metaprogramming facilities 
> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a 
> Lisp, and it’s not Racket.
> Production-quality, modern and fast GUI facilities. I’ll take properly 
> documented, complete Qt bindings. Racket/GUI is great for internal tools, but 
> it quickly becomes slow, tedious and limited for more complex client-facing 
> UIs.
> One complete, commercial-grade Web framework, inspired from Symphony or 
> Laravel. Security and ease of use first, continuations later.
> Better documentation: Racket docs are aesthetically very pleasing, complete 
> and detailed. However some parts are still very obscure and lacking simple 
> examples (if only the part about Continuations included just one basic 
> example, such as a ‘return’ implementation, on the very first page. If only 
> the Macros documentation started with define-simple-macro and a few very 
> basic, practical examples. Instead we’re greeted with pattern-based macros, 
> which although very powerful, are very hard to comprehend for newcomers).

Which of these things will you be working on?


>   I am well aware that what I’m wishing for isn’t necessarily compatible with 
> Racket’s intended public’s needs (comp-sci teachers and students? That’s the 
> impression I’m getting). But Racket is the most advanced general purpose 
> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to 
> academic use?

https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be

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


Re: [racket-users] How can I write a macro that recognizes arbitrary other macros?

2020-04-16 Thread Matthew Flatt
The main trick in this case is to recognize `define-values` (which is
what `define` expands to) instead of `define`. That's because
`define-values` propagates syntax arming to its identifiers and
right-hand side, which means that your macro is allowed to pull it
apart.

You'll also need to use an expansion context other than 'expression,
though.

At Thu, 16 Apr 2020 18:15:07 -0700 (PDT), Ryan Kramer wrote:
> The following code produces '(1 2 3 4)
> 
> (define-syntax (collect stx)
>   (syntax-case stx (define)
> [(_ (define id val) rest ...)
>  #'(let ([id val])
>  (collect rest ...))]
> [(_ (macro arg ...) rest ...)
>  (syntax-local-value #'macro (lambda () #f))
>  (let ([expanded (local-expand #'(macro arg ...) 'expression (list 
> #'define))])
>(println expanded)
>#`(collect #,expanded rest ...))]
> [(_ a rest ...)
>  #'(cons a (collect rest ...))]
> [(_)
>  #'(list)]))
> 
> (define-syntax-rule (my-define stuff ...)
>   (define stuff ...))
> 
> (collect 1 2 (define x 3) x 4)
> 
> 
> I would like `(collect 1 2 (my-define x 3) x 4)` to produce the same 
> result. But instead I get the error message "let-values: cannot bind 
> tainted identifier in: x"
> 
> "OK, maybe this is impossible" I thought, and moved on to what I should 
> have been working on anyway. But now I see that `class*` does seem to 
> recognize arbitrary macros. The following example shows that `class*` 
> seemingly understands my arbitrary `define-foo` macro:
> 
> (define-syntax-rule (define-foo)
>   (define/public (foo)
> (list this 'foo)))
> 
> (define my-class%
>   (class* object% ()
> (super-new)
> (define-foo)))
> 
> (define c (new my-class%))
> (send c foo)
> 
> How does `class*` understand my `define-foo` macro? And can the same 
> technique be used to fix my `collect` macro?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/0d01f4c1-f0b4-49cb-b9c2-fca7e2ca
> 6429%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/5e991981.1c69fb81.4cebf.da91SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Re: Organizing tests in project

2020-04-15 Thread Matthew Flatt
The machine that formerly ran pkg-build died, so pkg-builds stopped for
a week or two. I moved eventually moved it to a new machine. Since I
had to start over with a v7.6 installer and the current catalog, all
packages were re-built and re-tested.

At Wed, 15 Apr 2020 12:14:31 -0700, Siddhartha Kasivajhula wrote:
> This morning I find that the package referenced above no longer
>  indicates failure. There
> haven't been any new commits, so it appears that the package rebuilt on its
> own without any fresh trigger -- but, notably, after a relatively long
> (weeks long) interval. Does anyone know if this is normal? This section
>  alog%29>
> of the docs appears to suggest that the docs are built daily.
> 
> 
> 
> On Fri, Apr 10, 2020 at 11:07 AM Siddhartha Kasivajhula 
> wrote:
> 
> > Hi, I'm still seeing an error
> >  on the Racket package
> > server, but the build output is from March 31, 2019
> > 
> > and doesn't seem to be showing updated output. I gather that the server
> > builds packages nightly -- any idea why it hasn't rebuilt yet? Or if it
> > has, is there a way to get updated error output?
> >
> >
> >
> > On Mon, Apr 6, 2020 at 3:27 PM Siddhartha Kasivajhula 
> > wrote:
> >
> >> FTR I fixed this by using the `compile-omit-paths` flag:
> >> https://docs.racket-lang.org/raco/setup-info.html
> >> E.g. in info.rkt:
> >>
> >> (define compile-omit-paths '("tests"))
> >>
> >>
> >>
> >>
> >> On Tue, Mar 17, 2020 at 12:25 PM Siddhartha Kasivajhula <
> >> skasi...@gmail.com> wrote:
> >>
> >>> Hi,
> >>> I'm attempting to organize tests in my package into subfolders/modules
> >>> instead of having them in a giant main.rkt test submodule, but am running
> >>> into some issues and was hoping for some advice on the best way to do it. 
> >>> I
> >>> think the primary issue is related to source compilation order in raco, 
> >>> but
> >>> am also curious how other people organize their tests.
> >>>
> >>> I've moved all of the tests into a tests/ subfolder in the main project
> >>> tree. When I build the project using raco setup, it builds both the
> >>> project files as well as the tests contained in the tests/ folder. At this
> >>> point, if I run the tests as is, they result in an error. If instead I
> >>> first delete the compiled/ subfolder in the tests folder, the tests then
> >>> work fine.
> >>>
> >>> I think the tests may be getting compiled against the version of the
> >>> compiled collection which is immediately replaced by a fresh compilation
> >>> during raco setup. This is the error I'm seeing when I run the tests:
> >>>
> >>> default-load-handler: expected a `module' declaration, but found
> >>> something else
> >>>   file:
> >>> 
> /Users/siddhartha/work/lisp/racket/relation/tests/compiled/algebraic-test_rkt.d
> ep
> >>>   context...:
> >>>default-load-handler
> >>>standard-module-name-resolver
> >>>module-path-index-resolve
> >>>module-declared?
> >>>
> >>> I could add a make target to clean the test compiled folder prior to
> >>> running tests, but it seemed like there must be a better way. So my main
> >>> questions are:
> >>>
> >>> 1. Is there a way to exclude certain folders (such as tests) in the raco
> >>> setup stage? For reference, the command I'm using is raco setup
> >>> --no-docs --tidy --pkgs relation.
> >>> 2. Is this a good way to organize tests? Are there any standard
> >>> recommended ways?
> >>>
> >>> Would appreciate any input,
> >>> -Sid
> >>>
> >>>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CACQBWFmoQpDCcX5JThPKwfJ9cJDP9jY
> tWKBfyONG7sB37w7YOQ%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/5e97677b.1c69fb81.9ccf4.c24bSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Examples of sending HTML email w/ Racket?

2020-04-09 Thread Matthew Flatt
At Thu, 9 Apr 2020 07:09:21 -0700 (PDT), Brian Adkins wrote:
> I looked at the net/mime library, but, as the title of the doc page 
> suggests, it seemed to only be about decoding, not creating:
> 
> https://docs.racket-lang.org/net/mime.html?q=net%2Fmime

Ah, right. I think I've made this mistake before.


Encoding is be built into SirMail (very old code):

 https://github.com/mflatt/sirmail/blob/master/sirmail/sendr.rkt#L136

It would make sense to have a better version of this in a package, of
course.

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


Re: [racket-users] Error loading libreadline dll when using readline package

2020-04-09 Thread Matthew Flatt
I think you probably have the "readline-gpl" package installed. That's
where the "libreadline-5.dll" comes from in "private/readline-lib.rkt":

 (define readline-library (ffi-lib "libreadline" '("5" "6" "4" "")))

Even if "7" were added to that list, `ffi-lib` assumes a versioning
convention that adds "-".

One solution is to set the

  PLT_READLINE_LIB

environment variable to point to the full path of "libreadline7.dll".
Note that it will need to be a Windows path, though, not a Cygwin path.

Or you could also try copying "libreadline7.dll" to "libreadline.dll"
(no "7") in the Racket's "lib" directory, but that probably won't work
if "libreadline7.dll" depends on other libraries. And there's a
question of whether a Cygwin libreadline will work at all when loaded
into non-Cygwin Racket. It may work better to get another version of
the libreadline DLL from somewhere and drop it into Racket's "lib"
directory.

At Thu, 9 Apr 2020 00:49:11 -0600, K H wrote:
> I'm running on cygwin on Windows 7 and I have the following error when
> attempting to use the readline package:
> 
> $ racket -il readline
> Welcome to Racket v7.6.
> ffi-lib: couldn't open "libreadline-5.dll" (The specified module could not
> be found.; errid=126)
> > ,ex
> 
> I get the same error either from a cygwin bash prompt or from a windows cmd
> shell prompt.
> 
> The gnu readline installed appears to be at version 7.
> 
> $ ls -l /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libread*
> -rwxr-xr-x  /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libreadline7.dll
> 
> The source at ./share/pkgs/readline-lib/readline/rktrl.rkt seems relevant
> but I'm not smart enough to figure out exactly what is wrong.
> 
> Any ideas on how to continue to debug this?
> 
> Thanks in advance,
> 
> Kieron.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAEEP09AXB4aJecs7eskog-RSDoyEeSW
> z5P_%2B8f4z%2B8%3DS7jEz%3Dw%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/5e8f1cdf.1c69fb81.135cf.f180SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Examples of sending HTML email w/ Racket?

2020-04-09 Thread Matthew Flatt
At Wed, 8 Apr 2020 21:28:11 -0400, George Neuner wrote:
> There's nothing in Racket for MIME that I'm aware of

There's a `net/mime` library.

I'm replying with an attachment so you can see what it generates, since
my email client uses that library.


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/5e8f1949.1c69fb81.5d1a9.7638SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] scribble include

2020-04-07 Thread Matthew Flatt
Use `for-syntax` to import into the transformer environment:

 #lang scribble/base
 @(require (for-syntax racket/base
   (only-in scribble/reader
make-at-reader)))
 @(require racket/include)
 foo
 @(include/reader "si1.inc" (make-at-reader))
 bar


The result of `make-at-reader` starts in S-expression mode where `@`
switches to text mode. You may want "si1.inc" to start out in text
mode, more like `#lang scribble/base`. That's almost as easy as
`(make-at-reader #:inside? #t)`, except that the reader in "inside"
mode returns an empty list for an empty input stream, which doesn't
work quite the right way for `include/reader`. Here's one way to adapt
it:

 @(include/reader "si1.inc"
  (lambda (src in)
(cond
  [(eof-object? (peek-byte in))
   eof]
  [else
   (cons #'begin
 ((make-at-reader #:inside? #t) src in))])))


At Mon, 6 Apr 2020 18:27:22 -0400, Hendrik Boom wrote:
> Once again I'm trying to get @(include ...) working in scribble.
> 
> The trouble with just using @(include filepath) in scribble is that
> the included file is read as racket input instead of syntax and 
> semantics instead of wih scribble's syntax.
> 
> So I thought to try include/reader instead; it has an extra parameter
> that can specify how the other file is to be read.
> 
> #lang scribble/base
> @(require scribble/reader)
> @(require racket/include)
> foo
> @(include/reader "si1.inc" (make-at-reader))
> bar
> 
> But this gives me a completely unexpected problem.  It claims 
> make-at-reader is an unbound identifier.
> 
> If I Use it outside the call to include/reader it's *not* unbound.
> 
> The Racket documentation tells me:
> 
>The reader-expr is evaluated at expansion time in the transformer 
>environment.
> 
> Is there some way of making this work?
> 
> -- hendrik
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/20200406222722.2dvly3zgoi46iack%
> 40topoi.pooq.com.

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


Re: [racket-users] How to compile static racket binaries

2020-04-02 Thread Matthew Flatt
At Thu, 2 Apr 2020 06:28:00 -0700 (PDT), Tristram Oaten wrote:
> I've compiled it on ubuntu 19:10, and am running into this problem on 
> ubuntu:latest (18.04), due to the different versions of libc.

Ah, I didn't realize that the C library version had changed in recent
Linux distributions. (It had been the same for several years.) That's a
pain.

The distributions at https://download.racket-lang.org/ are built with
an old enough Linux distribution to be portable in practice. So, using
that build is one option.

Currently, I guess you're building your own Racket executable on Ubuntu
19.10. That's the point where you can elect to statically link:

 - If you're building from the source distribution, add
  LDFLAGS=--static
   to your `configure` line.

 - If you're building from a Git repo checkout, add
  CONFIGIRE_ARGS_qq="LDFLAGS=--static"
   to your `make` line. In an existing tree, you'll need to
   delete "racket/src/build" to ensure that it's rebuilt.

Make sure the "libffi-dev" package is installed, because the makefiles
for the bundled libffi do not like `--static`.

I'm not sure how well statically linking to the C library will work. I
get several linker warnings like this one:

 warning: Using 'getgrgid' in statically linked applications requires
 at runtime the shared libraries from the glibc version used for linking

For this reason and others, I'm surprised that other language
implementations statically link to the C library, but it's difficult to
keep track.

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


Re: [racket-users] How to compile static racket binaries

2020-04-02 Thread Matthew Flatt
Those ".so"s are OS-supplied dynamic libraries, and I think there's no
way to link to them statically. Of course, the resulting executable
will only work on a sufficiently compatible variant of Linux.

Are you seeing a specific problem when moving the executable among
machines? If so, what are the different Linux distributions on each
end?

At Thu, 2 Apr 2020 01:51:54 -0700 (PDT), Tristram Oaten wrote:
> Hi friends.
> 
> raco exe makes dynamic executables, and raco distribute doesn't change that:
> 
> $ ldd ./tst
> linux-vdso.so.1 (0x7ffc9ed46000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7fbeb4c09000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbeb4a18000)
> /lib64/ld-linux-x86-64.so.2 (0x7fbeb4c67000)
> 
> On windows, it looks like one can --embed-dlls, which is kindof what I 
> want, but for all platforms.
> 
> I'd like to compile statically for ease of distribution and deployment. Is 
> this possible?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5e85d793.1c69fb81.915ca.3992SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Embedding Racket CS

2020-03-29 Thread Matthew Flatt
At Sun, 29 Mar 2020 13:13:08 -0700 (PDT), zeRusski wrote:
> First, CS snapshots in Utah and NW mirrors offer no libracketcs.a so I went 
> ahead and attempted to build CS from the github master. Sadly its `raco` 
> tool is unaware of the `ctool` subcommand, so I'm guessing snapshots are 
> built from your own private fork or something.

Snapshot builds use the public GitHub repo's master.

`raco ctool` is provided by the "cext-lib" package. That package is
part of "main-distribution", but maybe you installed a subset of
packages when building?

> I then started mixing and 
> matching stuff from snapshot and freshly built github:
> - raco, boot files and headers from the snapshot,
> - libracketcs.a from github

That could work.

> Linking against `libracketcs.a` however failed with a bunch of 
> unresolved symbols like e.g. `CFLocaleCopyCurrent` most of them referenced 
> from `rktio_convert.o`. 

You will need to link to some standard libraries and frameworks on Mac
OS: `-framework CoreFoundation`, `-liconv`, and `-lncurses`.

I didn't try to write this down because it varies so much across
platforms, and I expect C programmers to just know. :) But it should be
written down or made more automatic.

> It wouldn't work anyway since `declare_modules` 
> also failed to resolve and I'm guessing I really need the `libracketcs.a` 
> from the snapshot for that.

`declare_modules` should be defined in the file generated by `raco
ctool --c-mods`.

> Another, probably unrelated issue where I'm likely not using the right 
> incantation is linking in Racket.framework. Even with -F path supplied as 
> needed `-framework racket` wasn't found. `man ld` for my platform shows it 
> expects to find (in our case) Racket under Racket.framework so 
> Racket.framework/Racket but all the frameworks you ship have intermediate 
> dirs Version/blabla/Racket. I just copied Racket and boot/ under 
> Racket.framework there to shut the linker up. Am I doing it wrong?

A better strategy may be to use `install_name_tool` to update the
framework reference to be relative to the executable:

  install_name_tool -change \
  "Racket.framework/Versions/7.6.0.18_CS/Racket" \
  "@excutable_path/rel/to/Racket.framework/Versions/7.6.0.18_CS/Racket" \
  path_to_your_executable

I don't know of a flag to the linker that will do this in the first
place.

> https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs.html is atm 
> quite about calling C. Is it possible or at least in the cards? I'd like to 
> use the API defined in C from Racket.

Calling C from Racket is mostly left to the FFI documentation:

  https://docs.racket-lang.org/foreign/index.html

So, if you link your executable in such a way that `(get-ffi-obj name
#f )` can find the functions, then that's all you need.


There's also a way to publish C functions to make them visible at the
Chez Scheme level:

 https://cisco.github.io/ChezScheme/csug9.5/foreign.html#./foreign:s272

Then you'd have to propagate that to the Racket level somehow --- maybe
by using `vm-eval` from `ffi/unsafe/vm` to access Chez Scheme directly
on the Racket side. I haven't given that much thought, so far.

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


Re: [racket-users] Embedding Racket CS

2020-03-27 Thread Matthew Flatt
At Fri, 27 Mar 2020 15:48:13 -0700 (PDT), zeRusski wrote:
> How I might go about embedding Racket CS

The current development version (as reflected by snapshot builds) now
has support and documentation for that:

 https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs-embedding.html

Of course, let me know if you run into any problems.


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/5e7e83f2.1c69fb81.a553d.d5f4SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] questions about top-level-bind-scope in root-expand-context

2020-03-23 Thread Matthew Flatt
At Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen wrote:
> I tried the example you gave for my first question and it resulted in an 
> error.

Oops --- you're right. I lost track of what we try to make work at the
top level.

> I think this is because `(define-values (x) ...)` expands `...` without the 
> top-level-bind-scope, even when expand-context-to-parsed? is #t (according 
> to expander/expand/top.rkt). Is this a bug?

Since the behavior goes far back, I think this is the behavior that we
decided to settle for.

> Related to your answer to my second question, `define-syntaxes` similarly 
> does not add the top-level-bind-scope when expanding `...`. Does this mean 
> that even for `define-syntaxes`, `...` won't use the top-level-bind-scope 
> binding(s) after all?

The way that evaluation, binding, and expansion are interleaved means
that a `define-syntaxes` macro can refer to itself in expansions. The
binding of an identifier in a macro template is resolved after the
macro is applied.

The difference with `define` is that the right-hand side is
expanded/compiled before `define` binds.

> A little bit off-topic, in the definition of define-values (in 
> expander/expand/top.rkt), there is `(define-match m s ...)`, but for 
> define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference 
> significant? Or does define-match not care whether `s` or `disarmed-s` is 
> used?

Using `disarmed-s` in the definition of `define-values` is probably
a better idea, and I'll look into that more.

It think it turns out not to matter, normally, because `define-values`
is transparent to syntax arming via `syntax-arm` with a #t second
argument (which is what the expander does). But it would be better to
not rely on that.

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


Re: [racket-users] questions about top-level-bind-scope in root-expand-context

2020-03-21 Thread Matthew Flatt
At Sat, 21 Mar 2020 00:00:07 -0700 (PDT), Yongming Shen wrote:
> First, in the source file expander/expand/bind-top.rkt, there is a comment 
> that says "When compiling `(define-values (x) ...)` at the top level, 
> we'd like to bind `x` so that a reference in the "..." will point back to 
> the definition, as opposed to being whatever `x` was before." Isn't this 
> the exact opposite of what (define-values (x) ...) should do?

Here's an example scenario that the current rule is meant to cover:

 > (require module-that-defines-fib)

 > fib ; refers to binding from `module-that-defines-fib`

 > (define (fib n)
 (if (< n 2)
 1 
 (+ (fib (- n 1)) (fib (- n 2) ; refers to this definition

 > (fib 27) ; => 514229

If a programmer usually expects the `fib`s in the definition's `...`
region here to refer to the new definition, not to the imported
binding, then the implemented rule is the right one. If programmers
expect that `fib`s in the `...` to refer to the imported binding, then
I'd agree with you. But I think the former is more often the case.

Neither rule is obviously right, and if we make the example more
complicated with more macros involved, I'm pretty sure there's no way
to implement either rule consistently: the top level is hopeless. The
case of a single recursive function seems common enough that we've
picked a rule and implementation to make it work.

> Second, ignoring the comment mentioned above, but still consider 
> `(define-values (x) ...)`. It appears that the binding of `x` to `...` with 
> the top-level-bind-scope is only used by `(#%top . x)` (either explicit or 
> implicit). The only exception seems to be in contexts where neither `x` nor 
> #%top are binded, in which case `x`, not wrapped by #%top, also uses that 
> binding. The case of `(#%top . x)` is confusing because even without the 
> top-level-bind-scope binding of `x`, `(#%top . x)` can still locate 
> `(define-values (x) ...)`, otherwise mutually recursive functions won't 
> work at the top level. As for the exception case, it seems rare enough that 
> it can be ignored. So my question is, what's benefit does the 
> top-level-bind-scope bring?

Just to restate (to make sure I understand), you're pointing out that
an unbound identifier is treated the same as a binding using the
top-level scope (i.e., both refer to a top-level variable) --- so why
bother with the top-level scope?

Although the result is the same for variable references, it's not the
same for macro bindings or for imported bindings. And, then, there's no
way to predict in advance that an identifier will be used as a variable
and omit the top-level scope in that case.

Stepping back a little, it may not be the right design choice to treat
an unbound identifier as a reference to a top-level variable. But some
sort of default is necessary to support the traditional top level. And
treating unbound identifiers this was avoids a[nother] special
treatment of top-level scopes, where an unbound variable could be
treated as a variable reference only if it has a top-level scope.

Really, the only consistent approach that I know is to not have an
interactive top level, but that's not an attractive option.


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/5e7615aa.1c69fb81.fec6a.0fe0SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Scribble citations for art history dissertation (AJA style)

2020-03-19 Thread Matthew Flatt
At Thu, 19 Mar 2020 12:38:39 -0400, Christopher Lemmer Webber wrote:
> I will spend the rest of the day looking at what scriblib's bibliography
> stuff does in further detail and think about how to accomplish what we
> need.  It could be that what I do is build a quicker proof of concept
> that accomplish *Morgan's* needs so we can get her dissertation out the
> door, and then upon examining that, we can think about how to generalize
> it for something more universal.  How does that sound?

That sounds like a good plan.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5e73a06e.1c69fb81.7e62.637aSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Scribble citations for art history dissertation (AJA style)

2020-03-19 Thread Matthew Flatt
At Thu, 19 Mar 2020 11:46:44 -0400, Christopher Lemmer Webber wrote:
> What I thought was the more "Racket'y way" would be to store it as
> abstract data that then could be rendered to the appropriate style
> (that's what BibTeX and everything else does).

Well, perhaps the Rackety way is to store it as abstract *code*. That
abstraction is what the `make-bib`, etc., functions are meant to be.

But you're absolutely right that the language of `make-bib` should be
more extensible. Currently, `location` is clearest the extension point,
but there are still just a bunch of predefined locations, instead of a
protocol for adding new ones. And `location` by itself is probably not
enough extensibility.

And you're right that the way that language renders to references and a
bibliography needs to be configurable and extensible. You can pick
among a few styles in `define-cite`, but that mostly just controls the
way references render, not the bibliography.

You could build something new and better --- or maybe just different
and more applicable to your case. But if you're interested in improving
and generalizing `scribble/scriblib`, I'd be happy to work with you on
it.

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


Re: [racket-users] "invalid memory reference" issue

2020-03-05 Thread Matthew Flatt
I've pushed a repair for the development version of Racket CS. The
problem was related to computing a hash code of an object (i.e., an
instance of a class).

If you need a workaround to keep using the released version of Racket
CS, it may involve supplying explicit equality and hash-code functions
for your `Equal%` class.

Thanks for the report!

At Thu, 5 Mar 2020 04:07:48 -0800 (PST), hashim muqtadir wrote:
> Hello,
> 
> I have some code that uses my library, "remap". It previously used to work, 
> but in Racket CS 7.6, it fails saying "invalid memory reference.  Some 
> debugging context lost".
> Clicking the crosses in DrRacket gives this backtrace:
> 
> invalid memory reference.  Some debugging context lost
> 
> /home/hashim/racket/collects/racket/private/for.rkt: 2020:10 
> (hash-set table key val
> 
> /home/hashim/racket/collects/racket/private/for.rkt: 1503:16 
>   (let-values ([(fold-var ...) (let () expr1 expr ...)])
>   (values fold-var ...)]
> 
> /home/hashim/racket/collects/racket/private/for.rkt: 1543:38 
>   #'(let-values ([(fold-var ...)
> (for/foldX/derived 
> [orig-stx inner-recur nested? #f ()]
>   ([fold-var fold-var] 
> ...)
>   next-k break-k 
> final?-id
>   rest expr1 . body)])
> (if (and post-guard ... (not 
> final?-id))
> (for-loop fold-var ... loop-arg 
> ... ...)
> next-k)))
> 
> My tests, that use the library functions, seem to work, but for some reason 
> when I'm building a hash from my structures.
> The file found 
> https://gitlab.com/hashimmm/remap/-/blob/96f1db518c4d9bb8f2da44ae403ab50332212c
> 9c/issue.rkt 
> is present in the "issue" branch in my repo and running this file in 
> DrRacket will reproduce the problem.
> 
> From the file, removing the measurement-units table definition and its 
> references fixes the problem (the memory error then no longer occurs).
> 
> Any ideas what's up with this? I'd be happy to provide more information to 
> narrow this down, but I'm not really sure how.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/afec7b07-7f96-4d7f-ac59-8eb54446
> 2709%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/5e614817.1c69fb81.73043.5ebdSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] bad response from server

2020-03-02 Thread Matthew Flatt
A snapshot catalog only lasts for a limited time, and v7.4.0.1 was a
very long time ago in snapshot terms.

So, the short answer is to upgrade to a new snapshot --- or switch to a
release, which doesn't time out.

At Mon, 2 Mar 2020 14:46:25 -0500, Hendrik Boom wrote:
> When trying to u[dat catalog I get a message
> 
> get-all-pkg-details-from-catalogs: bad response from server
>   url: 
> https://www.cs.utah.edu/plt/snapshots/20190720-93f4c9226b/catalog/pkgs-all?vers
> ion=7.4.0.1
>   response: #f
> 
>   (for-loop . #(struct:srcloc 
> # 299 2 
> 11021 1759))
>   (for-loop . #(struct:srcloc 
> # 
> 37 4 1350 2495))
>   (pkg-catalog-update-local13 . #(struct:srcloc 
> # 
> 15 0 286 3561))
>   (#f . #(struct:srcloc 
> # first.rkt> 555 3 23822 3167))
>   (for-loop . #(struct:srcloc 
> # ate/catalog-update.rkt> 99 7 3851 437))
>   (.../more-scheme.rkt:261:28 . #f)
> 
> 
> I'm running using an old nightly build.
> Does this mean I need to install a new daily build?
> Or is the regular Racket distribution 
> already more up-tp-date them 2019 07 20?
> 
> -- hendrik
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/20200302194625.bnkor6si3bkecxsx%
> 40topoi.pooq.com.

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


Re: [racket-users] download catalog down?

2020-02-27 Thread Matthew Flatt
The URL

 https://download.racket-lang.org/releases/7.6/catalog/

is a fine catalog configuration. If you use that catalog and query it
with something like

  raco pkg catalog-show racket-lib

then `raco pkg` will form the URL

  https://download.racket-lang.org/releases/7.6/catalog/pkg/racket-lib

and fetch that. Or, if you use something like

 raco pkg catalog-copy

then `raco pkg` will form the URL

  https://download.racket-lang.org/releases/7.6/catalog/pkgs

But fetching the catalog URL without extending it is not part of the
catalog protocol.

At Thu, 27 Feb 2020 15:43:57 -0800, Tom Gillespie wrote:
> Hi Matthew,
>  Thanks, this would seem to suggest that something in the settings
> for raco is misconfigured on my system. Does that make sense? Thanks!
> Tom
> 
> On Thu, Feb 27, 2020 at 3:00 PM Matthew Flatt  wrote:
> >
> > That path isn't served, but something like
> >
> >   https://download.racket-lang.org/releases/7.6/catalog/pkg/racket-lib
> >
> > or
> >
> >   https://download.racket-lang.org/releases/7.6/catalog/pkgs
> >
> > should work (and does work for me).
> >
> > At Thu, 27 Feb 2020 14:22:55 -0800, Tom Gillespie wrote:
> > > Hi,
> > > I (and raco) get a 404 error when trying to access
> > > https://download.racket-lang.org/releases/7.6/catalog/.
> > >
> > > I'm seeing the following error on the page.
> > >
> > > > ((uncaught-exception-handler)
> > >
> > > 
> (*(+(*)(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*(+(*)(*)(*)(*
> > > uncaught exception: 404
> > >
> > > Help? Thanks!
> > > Tom
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/5e5849f7.1c69fb81.93987.1584SMTP
> IN_ADDED_MISSING%40gmr-mx.google.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/CA%2BG3_PPA06VKCc0Wuzu%2B3H-AsPS
> LmZkRiy_DmR5GnghDsZ-%3DRA%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/5e587651.1c69fb81.19a69.26b0SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] download catalog down?

2020-02-27 Thread Matthew Flatt
That path isn't served, but something like

  https://download.racket-lang.org/releases/7.6/catalog/pkg/racket-lib

or

  https://download.racket-lang.org/releases/7.6/catalog/pkgs

should work (and does work for me).

At Thu, 27 Feb 2020 14:22:55 -0800, Tom Gillespie wrote:
> Hi,
> I (and raco) get a 404 error when trying to access
> https://download.racket-lang.org/releases/7.6/catalog/.
> 
> I'm seeing the following error on the page.
> 
> > ((uncaught-exception-handler)
>
> (*(+(*)(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*(+(*)(*)(*)(*
> uncaught exception: 404
> 
> Help? Thanks!
> Tom

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


Re: [racket-users] how to adapt BC code for Racket CS?

2020-02-25 Thread Matthew Flatt
At Tue, 25 Feb 2020 06:48:53 -0800, Matthew Butterick wrote:
> What can you say about places & parallelism under CS vs. BC? This is
> one area that I find CS to reliably underperform BC (by about a
> factor of 2). Place creation seems slower under CS. More
> interestingly however, the utilization of multiple cores seems
> inefficient.

Place creation probably appears slower because loading code is slower.
The creation of places is actually around 10 times as fast. To check
that, try

 #lang racket/base
 (require racket/place)

 (time
  (for ([i (in-range 10)])
(place-wait (dynamic-place '(file "/tmp/go.rkt") 'void

where "/tmp/go.rkt" starts as

 (module m '#%kernel
   (#%provide void))

The loop should run around 10 times as fast in CS. But change
`'#%kernel` in "go.rkt" to `racket/base`, and the CS is only about 2
times as fast. Change it to `racket`, and CS is about the same or
slower.


Utilization of multiple cores is lower primarily (I think) due to a
shared allocation heap in CS:

 * BC gives each place its own allocation heap (with one extra heap for
   shared objects, such as place channels), so different places can
   allocate and GC independently.

   At least, that's true up to the limits of a shared page table. That
   limit becomes significant at around 10 places, because generational
   GC relies on page-level protection, and then OS pagetable operations
   become a bottleneck.

 * CS has a single heap with a single-threaded, stop-the-world GC ---
   so allocation and GC easily become a bottleneck.

   If GHC's experience is any guide, making the GC itself multithreaded
   may address much of this problem.

Locks on shared system data structures may also be a significant
obstacle to CPU utilization with places in CS, but I'm not sure.

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


Re: [racket-users] how to adapt BC code for Racket CS?

2020-02-23 Thread Matthew Flatt
[Replying to three messages]

At Sat, 22 Feb 2020 08:05:28 -0800, Matthew Butterick wrote:
> 1) As a package maintainer with zero exposure to Chez Scheme, how do I start 
> to optimize for Racket CS? Are there certain patterns and idioms from BC that 
> should be systematically eradicated? 

No. For most Racket users, you should *not* try to optimize for Racket
CS, and Racket CS should just do the right thing.

> For instance, how would I "take advantage of ... cheaper function
> calls"?

Jack's answer applies here. That is, you could take advantage of
cheaper function calls by worrying about them even less.

> 2) With Racket BC, I've generally found that the JIT optimizes my code better 
> than I do. So I write the simplest code and ignore the details. Is that less 
> true with CS? Should I be thinking more about manual tuning?

You should treat Racket BC and CS the same in this way.

> 3) Lurking here, I gather, is the bugaboo that even though core
> Racket runs on CS, the existing base libraries are optimized for BC.
> Is it considered important to optimize these for CS, in order to get
> the most benefit from the switch? How can Racket developers
> contribute to this?

I'd say existing libraries are optimized for BC in the sense that they
avoid some things that turn out to be cheaper in CS, so they might not
have avoided those things if started on CS. Meanwhile, for things that
turned out to be cheaper in BC, my strategy has been to make them
cheaper in CS, too.

> 4) Building both BC and CS is easy (thank you). What would be the
> most reliable technique for doing performance comparisons as one
> refactors code? Is it as simple as running `raco test ···` and
> `racocs test ···` in succession?

Yes.


At Sat, 22 Feb 2020 14:13:55 -0800 (PST), Jack Firth wrote:
> I'm no expert, but I have a feeling that optimizing for Racket CS will 
> involve relying more on function calls and indirection, especially to avoid 
> generating (or just writing) large amounts of code.

I'm reluctant to call that "optimizing for Racket CS", though. It's
closer to "not optimizing manually".

> I think a good way to contribute to this 
> effort would be to explore the performance costs of generic interfaces on 
> Racket CS. Make some benchmarks, try using collections other than just 
> lists and hashes, and see what happens in real-world codebases. Don't just 
> look at the speed differences either: consider what impact the flexibility 
> of generic interfaces has on the structure of the codebase.

Agreed.


At Sun, 23 Feb 2020 12:27:42 +0530, Alexis King wrote:
> I’m curious what guarantees I can come to expect from the Racket CS
> optimizer.

I think you have in mind what I would call high-level optimizations,
and there's not much difference between Racket CS and BC at that level.

> But my understanding is that Chez’s optimizer is much more
> sophisticated than Racket BC’s.

I wouldn't characterize it that way. If anything, Racket BC is more
sophisticated and aggressive than Chez Scheme on high-level
optimizations, especially around type reconstruction and cross-module
optimizations. (For Racket CS, Gustavo added a type-reconstruction pass
to Chez Scheme, and schemify handles cross-module optimization.)

Chez Scheme's advantages are more on the back end: register allocation,
calling conventions, and continuation management.

> At the very least, I’d expect it to be able to identify that `v` 
> is never used here and simplify it to this:
> 
> (let loop ([i 0])
>   (define j (add1 i))
>   (if (< j N)
>   (loop j)
>   i))

None of Racket BC, Racket CS, or Chez Scheme by itself will optimize
away the unused loop argument. That kind of interprocedural dead-code
elimination is out of reach for the current compilers, except to the
degree that inlining turns them into intraprocedural questions.

> Now I’d wonder: if N is a known constant, could the optimizer just delete the 
> loop? 

Only for short loops: Racket BC will turn that into a constant for N up
to 15. Racket CS will turn it into a constant only for N as 0. (Well,
almost; both of them leave a `check-range` call behind, because they're
not willing to inline it.) The difference between Racket CS and BC in
this case reflects more aggressive inlining in Racket BC.

> Could the whole thing be optimized to (sub1 N)? Given the performance 
> numbers in the blog post, I’m guessing the answer is no. Is the reason just 
> that Chez doesn’t perform this kind of optimization, or is there something 
> more fundamental?

Converting loops into closed form requires more sophisticated and
general induction reasoning than is typical in a compiler. Or it needs
ad hoc pattern patching to cover a few cases --- which I have seen gcc
do, but I don't think that's very common.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [racket-users] subprocess failure (Windows-specific ?)

2020-02-08 Thread Matthew Flatt
At Sat, 8 Feb 2020 17:46:06 +0100, Bertrand Augereau wrote:
> You're right, but wouldn't using the posix_spawn family have better
> semantics, better performance, and would allow to unify between POSIX and
> Windows behaviours nicely ? :)

It's the usual problem: posix_spawn() doesn't quite support all of the
things Racket does between fork() and exec().

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


Re: [racket-users] subprocess failure (Windows-specific ?)

2020-02-08 Thread Matthew Flatt
At Sat, 8 Feb 2020 17:08:18 +0100, Bertrand Augereau wrote:
> > I'm not sure I completely understand the problem.  You're correct that
> > there's no way to tell whether the value is an exit code from the program
> > or an error from the operating system ... but there also is no way to tell
> > that starting the program from the shell  IF  you rely solely on the exit
> > code.
> >
> 
> That's why CreateProcess and fork/exec return code.

Currently, if fork() fails on Unix (e.g., because there are too many
processes), then `subprocess` will raise an exception. But if fork()
succeeds, then there's normally no way to communicate an error from
exec() except through the exit code, since exec() is in the child
process.[*] So, that's why there's no way to distinguish "program
couldn't start" from "program exited with a non-0 status" on Unix.

You're right that `subprocess` could make a distinction on Windows with
CreateProcess(). Currently, `subprocess` doesn't make a distinction,
mostly because not doing so makes the behavior somewhat more consistent
with conventional Unix behavior.

[*] It seems possible to set up an extra channel of communication to
report whether exec() succeeds. I think that would be tricky at
best, though, because it's not clear how to clean up the channel if
exec() does succeed.

> > But if the idea is to tell whether the program started correctly - even if
> > it since has ended - then something like:
> >
> > (or
> >   (eq? 'running (subprocess-status ps))
> >   (not (= 0 (subprocess-pid ps)))
> >   )
> >
> > should do the trick.
> >
> 
> Yes in practice, it might be good enough.

I agree that this is not a good choice.

For compatibility while also exposing the result of CreateProcess() on
Windows, a new `subprocess-...` operation is probably best. I'll look
into adding that.

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


Re: [racket-users] Porting Racket to IRIX

2020-01-26 Thread Matthew Flatt
And you have enough memory, and there's no system-imposed memory limit
--- as reported by `ulimit -a` in bash, for example?

(Maybe a dumb question, but the last IRIX machine I used, decades ago,
would not have had enough memory to build modern Racket.)

At Sun, 26 Jan 2020 05:48:15 -0800 (PST), Eric Dodd wrote:
> That was (mostly) the problem. I hard-coded the paths in mzssl.rkt, and it 
> proceeded.
> 
> Next, it errors with "out of memory":
> 
> raco setup: making: /deinprogramm-signature/deinprogramm/signature 
> (DeinProgramm - Signatures)
> raco setup:  in /deinprogramm-signature/deinprogramm/signature
> raco setup:  in /htdp-lib/stepper/private
> raco setup:  in /gui-lib/framework
> raco setup:  in /gui-lib/mred
> raco setup:  in /gui-lib/framework/private
> raco setup:  in /scribble-lib/scribble
> raco setup:  in /scheme-lib/scheme/unit/lang
> raco setup:  in /scheme-lib/scheme/unit
> raco setup:  in /syntax-color-lib/syntax-color
> raco setup:  in /gui-lib/mrlib
> raco setup:  in /gui-lib/mrlib/hierlist
> raco setup:  in /scheme-lib/scheme/signature/lang
> raco setup:  in /tex-table
> raco setup:  in /gui-lib/mrlib/private
> raco setup:  in /scheme-lib/scheme
> out of memory
> make[1]: *** [Makefile:221: install-cgc] Error 255
> make[1]: Leaving directory '/usr/people/edodd/buildstuff/racket-7.5/src'
> make: *** [Makefile:119: install] Error 2
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/b1fe9f34-990e-48d0-9ce7-050a3c35
> d560%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/5e2d9b64.1c69fb81.43651.b3faSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Porting Racket to IRIX

2020-01-26 Thread Matthew Flatt
At Sat, 25 Jan 2020 12:36:57 -0800 (PST), Eric Dodd wrote:
> getenv: contract violation
>   expected: string-environment-variable-name?
>   given: #f
>   context...:
>
> /usr/people/edodd/local/share/racket/collects/racket/private/misc.rkt:202:2: 
> getenv
>/usr/people/edodd/local/share/racket/collects/openssl/mzssl.rkt:374:0: 
> x509-root-sources
> 
> In mzssl.rkt, x509-root-sources(), it seems to handle finding openssl. Mine 
> is 
> located in a non-standard location. How do I pass this location in properly?

>From the error, it looks like

  (X509_get_default_cert_file_env)

or

  (X509_get_default_cert_dir_env)

may be returning #f (or NULL at the C level). Is that the case?

If so, probably the solution is to check those results before passing
them on to `getenv`.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5e2d97f5.1c69fb81.79dfd.344bSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] Surprising behavior in The Printer

2020-01-14 Thread Matthew Flatt
The short answer is that you're right: creating new values at
custom-print time creates trouble for graph detection and `print`
quoting. Those operations perform a pass to make decisions about graphs
and quoting based on `eq?` identity, and then they make another pass to
actually print. I'll update the documentation to clarify.

A longer answer is that your example and variations expose several
mismatches between the `racket/pretty` printer, the built-in printer
for current Racket, and the built-in printer for Racket CS. I'm working
on changes and tests to make them more consistent, but the changes
don't produce the result you wanted. If you put `maybe-rebuild` in
`custom-print`, then they more consistently produce the output that you
don't want.

Of course, an even better improvement would collapse the three
different implementations of the printer. One day, we may be able to
use the Racket CS I/O layer in place of the implementation in current
Racket, and then folding in pretty-print support may become practical.

At Fri, 10 Jan 2020 16:58:34 -0800 (PST), Ryan Kramer wrote:
> I have a small program that demonstrates some surprising behavior regarding 
> `prop:custom-print-quotable 'never`. Perhaps it could be considered a bug, 
> although I haven't seen anything in the docs that this violates. I've found 
> that
> 
> 1. When I call `(println y)`, my `custom-display` is called first. And what 
> I do in `custom-display` affects the result of `(println y)`
> 2. The printer is doing something with `eq?` rather than `equal?`. (Does 
> this mean that constructing any new data structure, even a list, during 
> printing is an anti-pattern?)
> 
> In the example below, if `(maybe-rebuild lst)` returns `(identity lst)` 
> then `prop:custom-print-quotable 'never` works as I expected. But if 
> `(maybe-rebuild lst)` returns `(apply list lst)` which is a list that is 
> equal? but not eq? to the original list, then `prop:custom-print-quotable 
> 'never` surprises me.
> 
> #lang racket
> 
> (require racket/struct)
> 
> (struct my-struct (item) #:transparent
>   #:property prop:custom-print-quotable 'never)
> 
> (define (go port mode val)
>   (let ([proc (make-constructor-style-printer
>(λ (me) 'my-class%)
>(λ (me) (list val)))])
> (proc (void) port mode)))
> 
> (define (maybe-rebuild lst)
>   ; Works as expected if we return the same list
>   #;(identity lst)
>   ; But this breaks prop:custom-print-quotable 'never
>   (apply list lst))
> 
> (define my-class%
>   (class* object% (printable<%>)
> (super-new)
> (init-field content)
> (define/public (custom-print port mode)
>   (go port mode content))
> (define/public (custom-write port)
>   (go port #t content))
> (define/public (custom-display port)
>   (go port #f (maybe-rebuild content)
> 
> (define x (list 'CONTENT (my-struct '(1 a
> (println x)
> (define y (new my-class% [content x]))
> (println y)

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


Re: [racket-users] Re: Racket2 and syntax

2020-01-13 Thread Matthew Flatt
The project name is "Rhombus". The language name is TBD.

https://groups.google.com/forum/#!msg/racket-users/-x_M5wIhtWk/V47eL30HCgAJ

At Mon, 13 Jan 2020 07:38:55 -0800 (PST), John Cowan wrote:
> 
> 
> On Sunday, July 14, 2019 at 10:30:04 PM UTC-4, Matthew Flatt wrote:
> 
> At RacketCon today, after summarizing the state of work on Racket CS, I 
> > recommended that we next explore the possibly of changing to an 
> > infix-oriented syntax in "Racket2". 
> >
> 
> I realize that Racket2 is the name of the project, but I think it's very 
> important that the *language* of the project gets its own unique name.  
> Otherwise outsiders will see it as the successor, the important one, the 
> one they should use by default, because they will think Racket1 (which will 
> quickly become the human-oriented name of the existing language) has become 
> obsolete.  Larry Wall just changed the name of Perl 6 to Raku, and this is 
> a Good Thing, because it deflects the "When are you going to replace Perl 
> 5?" question.
> 
> 
> 
> John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
> I don't know half of you half as well as I should like, and I like less
> than half of you half as well as you deserve.  --Bilbo
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/2f002c9e-61f2-4fd4-8014-0cd3d4e6
> 1853%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/5e1c935f.1c69fb81.9e1f7.8c0bSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] What's the point of make-continuation-mark-key?

2020-01-11 Thread Matthew Flatt
It would be reasonable to generalize `chaperone-continuation-mark-key`
to apply in cases where `chaperone-struct` could work, with similar
sorts of evidence that chaperoning is allowed provided by a caller of
`chaperone-continuation-mark-key`. I guess we just didn't think about
it that way when `chaperone-continuation-mark-key` was added, so it was
added in a way more like `chaperone-vector` and other chaperones that
apply to more specialized representations.

Other kinds of keys, like symbols, can't be impersonated because their
representations don't accommodate chaperones. (In other words, they're
like structs declared with `#:authentic`.)

At Sat, 11 Jan 2020 19:48:17 -0800 (PST), Jack Firth wrote:
> Based on my reading of Continuation Frames and Marks 
> , 
> any value at all can be used as a key for a continuation mark. So why does 
> make-continuation-mark-key 
>  ~25kernel%29._make-continuation-mark-key%29%29> 
> exist, and why is there a special continuation-mark-key 
>  ~25kernel%29._continuation-mark-key~3f%29%29> 
> data type? Couldn't you use any arbitrary gensym, or a singleton struct? 
> The docs for make-continuation-mark-key mention that the returned key can 
> be impersonated and other kinds of keys can't, but they don't explain why 
> that would be the case.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/773a2caa-d6b3-48b8-becf-cc3105a6
> 60e0%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/5e1a9a61.1c69fb81.ad6d0.58bcSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] counterintuitive behavior of namespace-require

2020-01-06 Thread Matthew Flatt
The problem is that `namespace-require` has to first resolve the
`racket` module path, and the module name resolver uses the current
namespace as determined by `current-namespace` --- which means that the
resolver loads the `racket` module into the wrong namespace.

I doubt that we can change that behavior without breaking something.
Probably this will need to be addressed with a documentation
improvement that discourages providing a namespace directly except in
limited cases.

At Mon, 6 Jan 2020 19:09:44 -0800 (PST), Yongming Shen wrote:
> Hi, I have encountered a counterintuitive behavior of namespace-require and 
> wonder if it is a bug.
> Basically, namespace-require behaves differently when the target namespace 
> is passed by parameterizing current-namespace, compared to when the 
> optional namespace parameter is used.
> 
> For example, this works:
> 
> (define ns (make-base-empty-namespace))
> (parameterize ([current-namespace ns]) (namespace-require 'racket))
> 
> But this gives an error about unknown module:
> 
> (define ns (make-base-empty-namespace))
> (namespace-require 'racket ns)
> 
> require: unknown module
> module name: # v7.3/collects/racket/main.rkt">
> 
> Am I doing something wrong in the second case?
> 
> Thanks,
> Yongming
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/45e0ee10-0ce0-42a9-997f-ad102e09
> 8ea4%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/5e13fad3.1c69fb81.e0aae.b3e0SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2020-01-01 Thread Matthew Flatt
At Fri, 27 Dec 2019 14:01:33 +0300, Dmitry Pavlov wrote:
> Because on my good ol' Windows XP machine, the Utah i386 nigtly build, while 
> installing successfully, resulted in a Racket executable that the system 
> refused to run, saying that it is not a correct executable. (The message was 
> localized in Russian so I am not sure what is the exact English original 
> message). Same situation with raco.exe so it must be something systematic.
> 
> And your special build works fine. And older stock Racket 7.1 worked fine too.
> 
> I can totally live without WinXP, just curious whether it is a planned 
> behaviour.

The release builds and that special build are cross-compiled using
MinGW. The one that doesn't run from the Utah snapshot is built with
MSVC 2017. I think that must be the difference, with modenr MSVC doing
something to the executable that XP doesn't recognize.

The release builds will continue to use MinGW, so they'll continue to
work on XP.

... at least for "Racket.exe" and "Raco.exe". I see that "DrRacket.exe"
doesn't work on XP, anymore, because glib and related GUI dependencies
use system functions that became available only in Vista. (If someone
really needed to make that work, it's possible that substituting
libraries from an old Racket release work work, but I'm not sure.)

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


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2019-12-22 Thread Matthew Flatt
At Sun, 22 Dec 2019 20:28:41 +0300, Dmitry Pavlov wrote:
> 
> > Thanks! It really is a bug in `scheme_get_long_long_val`, where the
> > extraction can read past the end of a bignum on a 32-bit platform.
> >
> > Repair pushed.
> Great, thank you!
> Given that I do not normally build Racket, should I wait for the next 
> snapshot 
> from UoU or Northwestern to check out the repaired version?
> 
> Or any of the two?

Yes --- but the Northwestern snapshot site is having trouble, so it
will be at the Utah site in about 24 hours.

In case it helps to run earlier, here's a one-off snapshot:

 http://www.cs.utah.edu/~mflatt/tmp/racket-7.5.0.14-i386-win32.exe

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5dffb472.1c69fb81.629ef.25a0SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2019-12-22 Thread Matthew Flatt
At Sat, 21 Dec 2019 11:06:33 +0300, Dmitry Pavlov wrote:
> The error pops out not on the first or second positioning exceeding 1 GB. In 
> fact, it happens on different moments in different runs.

Thanks! It really is a bug in `scheme_get_long_long_val`, where the
extraction can read past the end of a bignum on a 32-bit platform.

Repair pushed.

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


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2019-12-22 Thread Matthew Flatt
At Sat, 21 Dec 2019 00:22:19 -0500, George Neuner wrote:
> Is Racket really writing billions of zeroes rather than creating a 
> sparse file?  It seems to me that this file should only create 2 actual 
> data blocks, and (modulo JIT) the program should finish almost 
> instantly.  What am I missing?

Although NTFS supports sparse files, it looks like the OS creates them
only when an application specifically requests sparse mode. Racket does
not currently request sparse mode for any files that it creates.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5dff97d9.1c69fb81.87b39.9531SMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2019-12-20 Thread Matthew Flatt
At Fri, 20 Dec 2019 23:39:30 +0300, Dmitry Pavlov wrote:
> > The Racket-imposed limit should be 64 bits (more than enough) on all
> > platforms. I can try to replicate the problem later today, but more
> > information on the error message would be helpful.
>
> I do not have access to that Windows 7 machine until Monday.
> I managed to reproduce the problem, though, on a 32-bit Windows XP with 
> Racket 7.1.
> 
> file-position: new position is too large
>    port: #
>    position: 1122398240

I'm not able to replicate the error on a fresh(!) 32-bit Windows 7
installation using v7.1 or v7.5. I also don't think it should happen
based on the implementation. So, I'm missing something.

That error string only appears here:

 https://github.com/racket/racket/blob/master/racket/src/racket/src/port.c#L4093

There could be something wrong with `scheme_get_long_long_val`, but
it's surprising that it could go wrong in a machine-specific way.

Does the error happen for you even in a very short program that tries
to set the file position to 1122398240, or does it only happen in your
full program?

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/5dfd6067.1c69fb81.8e70.772dSMTPIN_ADDED_MISSING%40gmr-mx.google.com.


Re: [racket-users] file-position in Win32 not working beyond 1 GB

2019-12-20 Thread Matthew Flatt
The Racket-imposed limit should be 64 bits (more than enough) on all
platforms. I can try to replicate the problem later today, but more
information on the error message would be helpful.

At Fri, 20 Dec 2019 17:39:37 +0300, Dmitry Pavlov wrote:
> Hello,
> 
> On a fresh 32-bit Racket 7.5 install on 32-bit Windows 7,
> (file-position port number) does not work when number
> is more that 1 GB.
> 
> I can not now say exactly what the error message was,
> because I am away from that system, but IIUC it
> was something about the position being "too large".
> 
> The size of the file, though, is definitely large enough
> to have that position, and (file-position port number)
> on it worked fine until the number grew beyond
> the said limit.
> 
> On 64-bit Linux, everything is fine.
> 
> Can I work this problem around somehow?
> 
> Best regards
> 
> Dmitry
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/22f36172-daf8-7e6f-5f55-9e1c562b
> 8b61%40iaaras.ru.

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


Re: [racket-users] Re: Racket 7.5 does not run on Cent OS cloud computers

2019-12-16 Thread Matthew Flatt
> On Monday, 9 December 2019 23:00:37 UTC+1, edu500ac wrote:
> >
> > A couple of years ago, I was unable to run Racket on my webpage. I 
> > complained on this forum, and the developers fixed the issue. Things worked 
> > fine until version 7.3, when the old problem reappeared. Here is what 
> > happens:
> >
> > ```
> > advo...@advogadosmg.org  [~]# racket-7.5.0.10/bin/racket
> >
> > racket-7.5.0.10/bin/racket: /lib64/libc.so.6: version `GLIBC_2.14' not 
> > found (required by racket-7.5.0.10/bin/racket)
> > ```
> >
> > The old version works:
> >
> > ```
> > advo...@advogadosmg.org  [~/public_html/rkt]# 
> > racket/bin/racket
> > Welcome to Racket v7.3.
> > > (+ (* 3 4) (* 5 6))
> > 42
> > ```
> >
> > Could people in charge fix the problem again?

Probably the reason for the difference in v7.5 is that we were forced
to upgrade from Debian 7 to Debian 8 for the Linux builds. I don't
think we can easily switch back, unfortunately.


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/20191216154633.8A6AB650182%40mail-svr1.cs.utah.edu.


Re: [racket-users] Racket 7.5 DMG file does not open on OSX 10.11

2019-12-11 Thread Matthew Flatt
At the moment, we don't have plans to rebuild v7.5, so the change would
kick in with v7.6.

The snapshot builds use HFS+ --- but they did, anyway, since they're
created with an older version of Mac OS.

At Wed, 11 Dec 2019 10:45:08 -0500, David Storrs wrote:
> Thanks, Matthew,
> 
> The version on the downloads page seems to still be APFS.  Will it rebuild
> at some point?
> 
> On Tue, Dec 10, 2019 at 8:46 PM Matthew Flatt  wrote:
> 
> > I’ve changed the distribution build to use HFS+ going forward.
> >
> > > On Dec 10, 2019, at 6:28 PM, James Platt  wrote:
> > >
> > >
> > >> On Dec 6, 2019, at 9:56 PM, Darth Vadør wrote:
> > >>
> > >> If it isn't too much trouble, I at least would really appreciate this.
> > >> One reason I think this is important is because Homebrew has a cask for
> > Racket, which uses the .dmg distribution. It sets up $PATH (and probably
> > other things I don't know about as well), and can update Racket for you,
> > which is quite pleasant.
> > >>
> > >> If the maintainers of the cask see there is an easy way to support
> > older Macs they might (fingers crossed) consider it.
> > >
> > > I would also like to have an HFS+ formatted dmg as an option.  However,
> > Homebrew has dropped support for El Capitan and earlier but it continues to
> > work (most of the time) if you already had a previous version installed.
> > Everything after El Capitan can read APFS.   So, the maintainers of the
> > cask might decide that any new legacy support would be short lived.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > an email to racket-users+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > 
> https://groups.google.com/d/msgid/racket-users/EDDD1A40-9C10-4F2B-8A07-6933784C
> 5C41%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/FFE82A21-AE9E-49F0-9F55-76E47C32
> D58B%40cs.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/20191211160035.39C1F65019A%40mail-svr1.cs.utah.edu.


Re: [racket-users] Racket 7.5 DMG file does not open on OSX 10.11

2019-12-10 Thread Matthew Flatt
I’ve changed the distribution build to use HFS+ going forward.

> On Dec 10, 2019, at 6:28 PM, James Platt  wrote:
> 
> 
>> On Dec 6, 2019, at 9:56 PM, Darth Vadør wrote:
>> 
>> If it isn't too much trouble, I at least would really appreciate this.
>> One reason I think this is important is because Homebrew has a cask for 
>> Racket, which uses the .dmg distribution. It sets up $PATH (and probably 
>> other things I don't know about as well), and can update Racket for you, 
>> which is quite pleasant.
>> 
>> If the maintainers of the cask see there is an easy way to support older 
>> Macs they might (fingers crossed) consider it.
> 
> I would also like to have an HFS+ formatted dmg as an option.  However, 
> Homebrew has dropped support for El Capitan and earlier but it continues to 
> work (most of the time) if you already had a previous version installed.  
> Everything after El Capitan can read APFS.   So, the maintainers of the cask 
> might decide that any new legacy support would be short lived.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/EDDD1A40-9C10-4F2B-8A07-6933784C5C41%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/FFE82A21-AE9E-49F0-9F55-76E47C32D58B%40cs.utah.edu.


  1   2   3   4   5   6   7   8   9   >