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

2020-05-08 Thread Dominik Pantůček

Hello,



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.



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
  2Thread 0x77fcb700 (LWP 19076) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559d7d78)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  3Thread 0x7fffe65a6700 (LWP 19077) "gmain" 
0x77d34c2f in __GI___poll (fds=0x55b82520, nfds=2, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7fffe5da5700 (LWP 19078) "gdbus" 
0x77d34c2f in __GI___poll (fds=0x55b94ce0, nfds=3, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7fffd77fe700 (LWP 19082) "dconf worker" 
0x77d34c2f in __GI___poll (fds=0x55e9e5e0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  8Thread 0x7fffe40d4800 (LWP 19083) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  9Thread 0x7fffd4602800 (LWP 19084) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  10   Thread 0x7fffd4586800 (LWP 19085) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  11   Thread 0x7fffd450a800 (LWP 19086) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  12   Thread 0x7fffd448e800 (LWP 19087) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  13   Thread 0x7fffd4412800 (LWP 19088) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  14   Thread 0x7fffd4396800 (LWP 19089) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  15   Thread 0x7fffd431a800 (LWP 19090) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c499c)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
  16   Thread 0x765b2800 (LWP 21691) "tut22.rkt" 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x559c4998)

at ../sysdeps/unix/sysv/linux/futex-internal.h:80
(gdb) bt
#0  0x557f5064 in mark_backpointers (gc=gc@entry=0x559d10c0) 
at ../../../racket/gc2/newgc.c:4078
#1  0x557edb2b in garbage_collect (gc=gc@entry=0x559d10c0, 
force_full=force_full@entry=0, no_full=no_full@entry=0, 
switching_master=switching_master@entry=0, lmi=lmi@entry=0x0)

at ../../../racket/gc2/newgc.c:5646
#2  0x557f0ff2 in collect_now (nomajor=, 
major=, gc=) at 
../../../racket/gc2/newgc.c:875
#3  0x557f0ff2 in collect_now (gc=0x559d10c0, major=0, 
nomajor=0) at ../../../racket/gc2/newgc.c:855
#4  0x557f9124 in allocate_slowpath (newptr=, 
allocate_size=, gc=) at 
../../../racket/gc2/newgc.c:1607
#5  0x557f9124 in allocate (type=1, request_size=out>) at ../../../racket/gc2/newgc.c:1671
#6  0x557f9124 in allocate (type=, 
request_size=) at ../../../racket/gc2/newgc.c:1636
#7  0x557f9124 in GC_malloc_atomic (s=) at 
../../../racket/gc2/newgc.c:1792
#8  0x557f9124 in GC_malloc_atomic (s=) at 
../../../racket/gc2/newgc.c:1792
#9  0x55605406 in prepare_retry_alloc (p2=, 
p=) at ../../../racket/gc2/../src/jitalloc.c:47
#10 0x55605406 in ts_prepare_retry_alloc (p=, 
p2=) at ../../../racket/gc2/../src/jitalloc.c:73

#11 0x77fbe62b in  ()
#12 0x in  ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x77fcb700 (LWP 19076))]
#0  futex_wait_cancelable (private=, expected=0, 
futex_word=0x559d7d78) at ../sysdeps/unix/sysv/linux/futex-internal.h:80

80  ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory.
(gdb) bt
#0  0x77e202c6 in futex_wait_cancelable (private=out>, expected=0, futex_word=0x559d7d78) at 
../sysdeps/unix/sysv/linux/futex-internal.h:80
#1  0x77e202c6 in __pthread_cond_wait_common (abstime=0x0, 
clockid=0, mutex=0x559d7d28, cond=0x559d7d50) at 
pthread_cond_wait.c:508
#2  0x77e202c6 in __pthread_cond_wait 
(cond=cond@entry=0x559d7d50, mutex=mutex@entry=0x559d7d28) at 
pthread_cond_wait.c:638
#3  0x557209fe in green_thread_timer 
(data=data@entry=0x559d7d10) at ../../../racket/gc2/../src/port.c:6659
#4  0x556bb8be in mzrt_thread_stub (data=0x559d7dc0) at 

Re: [racket-users] for/set

2020-05-08 Thread Hendrik Boom
On Fri, May 08, 2020 at 04:18:24PM -0700, Sorawee Porncharoenwase wrote:
> There’s a search bar in the top left of every doc page.

Somehow I hadn't noticed that.  It's a huge help to know that.

> Typing for/set and
> enter will show you this search result page
> . Here, the first
> result
> 
> is what you want.

Excellemt!

-- hendrik


> 
> On Fri, May 8, 2020 at 4:07 PM Hendrik Boom  wrote:
> 
> > Where is for/set documented?  What does it do?
> >
> > It is mentioned in the typed Racket menual, but oly to say it has
> > the same meaning as the unannotated version.
> >
> > -- 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/20200508230711.llav2273e2ntzegz%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/CADcuegvGez14Nxs9XhgoM_3tNViqWLtbhvikLnN%3D0zH4GEKY%2Bg%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/20200508233743.qmtmeyua2vmvbjvp%40topoi.pooq.com.


Re: [racket-users] for/set

2020-05-08 Thread Stephen De Gabrielle
It’s with the set data type - but I haven’t used it

https://docs.racket-lang.org/reference/sets.html#%28form._%28%28lib._racket%2Fset..rkt%29._for%2Fset%29%29


On Sat, 9 May 2020 at 00:07, Hendrik Boom  wrote:

> Where is for/set documented?  What does it do?
>
> It is mentioned in the typed Racket menual, but oly to say it has
> the same meaning as the unannotated version.
>
> -- 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/20200508230711.llav2273e2ntzegz%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/CAGHj7-LjjJ5C%3D%3D7MkDwFX8GWdBRw59hiWnHQyn0Lv884VjLicQ%40mail.gmail.com.


Re: [racket-users] for/set

2020-05-08 Thread Sorawee Porncharoenwase
There’s a search bar in the top left of every doc page. Typing for/set and
enter will show you this search result page
. Here, the first
result

is what you want.

On Fri, May 8, 2020 at 4:07 PM Hendrik Boom  wrote:

> Where is for/set documented?  What does it do?
>
> It is mentioned in the typed Racket menual, but oly to say it has
> the same meaning as the unannotated version.
>
> -- 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/20200508230711.llav2273e2ntzegz%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/CADcuegvGez14Nxs9XhgoM_3tNViqWLtbhvikLnN%3D0zH4GEKY%2Bg%40mail.gmail.com.


[racket-users] for/set

2020-05-08 Thread Hendrik Boom
Where is for/set documented?  What does it do?

It is mentioned in the typed Racket menual, but oly to say it has 
the same meaning as the unannotated version. 

-- 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/20200508230711.llav2273e2ntzegz%40topoi.pooq.com.


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

2020-05-08 Thread James Platt
Would virtual machines be an option?  You do have to have a pretty good host 
machine with lots of RAM.  I do this mainly to have different development and 
testing environments.  It works pretty smoothly on my Mac Pro, with VirtualBox 
for Linux and Windows guest machines and VMWare for macOS guests.  

James

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0BB22130-12D1-4FF3-9BB1-A79A595E8AF6%40biomantica.com.


Re: [racket-users] How to avoid all packages when building from source?

2020-05-08 Thread Sam Tobin-Hochstadt
For Racket CS, you'd want `make cs` or `make cs-base`.

`PKGS` is what gets built. The `racket/pkgs` directory is packages
that are part of the `racket/racket` repository; it includes things
like tests, the guide and reference, and a few other packages that
make sense to develop in the same repository as the core libraries and
runtime. Mostly that's an implementation detail. Note that some of
those packages (like `racket-doc`) depend on packages not in that
directory (like `scribble-lib`).

Sam


On Fri, May 8, 2020 at 10:11 AM zeRusski  wrote:
>
>
>> You can do "make base" instead, which installs no packages. Or you can do 
>> something like 'make PKGS=drracket' which just installs DrRacket and 
>> dependencies, or similar with other packages.
>
>
> I am installing in-place but racket cs, not racket bc, so IIUC `make base` 
> isn't what I want. PKGS confuses me a bit at least having read both the 
> build.md notes and your comment. From the build notes I understand it 
> controls what gets build (or linked in place) that's already in racket/pkgs 
> dir - that would be the packages that are being developed alongside racket in 
> the same repository. But then the notes say that PKGS defaults to the 
> main-distribution like you said and apparently that brings in stuff beyond 
> the racket/pkgs dir. I guess I can run with PKGS="" and see if indeed the 
> racket/pkgs are still being built and linked, cause I really want them to. 
> They are the ones I'd consider base.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/ca77a5fd-2718-4b11-9cb8-6ed00f719d2c%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/CAK%3DHD%2BYc%3DYg5L4xf8G3Z2cr4K_LUdouDN%2Br5y%3Dzv-7ciHhSqCw%40mail.gmail.com.


Re: [racket-users] How to avoid all packages when building from source?

2020-05-08 Thread zeRusski


> You can do "make base" instead, which installs no packages. Or you can do 
> something like 'make PKGS=drracket' which just installs DrRacket and 
> dependencies, or similar with other packages. 
>

I am installing in-place but racket cs, not racket bc, so IIUC `make base` 
isn't what I want. PKGS confuses me a bit at least having read both the 
build.md notes and your comment. From the build notes I understand it 
controls what gets build (or linked in place) that's already in racket/pkgs 
dir - that would be the packages that are being developed alongside racket 
in the same repository. But then the notes say that PKGS defaults to the 
main-distribution like you said and apparently that brings in stuff beyond 
the racket/pkgs dir. I guess I can run with PKGS="" and see if indeed the 
racket/pkgs are still being built and linked, cause I really want them to. 
They are the ones I'd consider base.

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


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

2020-05-08 Thread Sam Tobin-Hochstadt
You will want to do `handle SIGSEGV nostop noprint` when you start
gdb.  Racket BC uses the SEGV handler to implement the GC write
barrier, so you'll want to skip those.

Sam

On Fri, May 8, 2020 at 9:36 AM Dominik Pantůček
 wrote:
>
> Hello,
>
> On 08. 05. 20 14:27, Matthew Flatt wrote:
> > 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.
> >
>
> I am using the build from master branch with the patch for #3145 and
> cannot make it run under gdb:
>
> $ gdb ../racket-lang/racket/racket/bin/racket
> GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>  .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ../racket-lang/racket/racket/bin/racket...
> (No debugging symbols found in ../racket-lang/racket/racket/bin/racket)
> (gdb) run
> Starting program:
> /home/joe/Projects/Programming/racket-lang/racket/racket/bin/racket
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Welcome to Racket v7.7.0.4.
> [New Thread 0x77fcb700 (LWP 6410)]
>
> Thread 1 "racket" received signal SIGSEGV, Segmentation fault.
> 0x555e14fe in scheme_gmp_tls_unload ()
> (gdb)
>
> The same happens for the binary with debug symbols:
>
>   gdb ../racket-lang/racket/racket/src/build/racket/racket3m
> GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>  .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from
> ../racket-lang/racket/racket/src/build/racket/racket3m...
> (gdb) run
> Starting program:
> /home/joe/Projects/Programming/racket-lang/racket/racket/src/build/racket/racket3m
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Welcome to Racket v7.7.0.4.
> [New Thread 0x77fcb700 (LWP 6422)]
>
> Thread 1 "racket3m" received signal SIGSEGV, Segmentation fault.
> scheme_gmp_tls_unload (s=0x76114480, data=0x0) at
> ../../../racket/gc2/../src/gmp/gmp.c:5822
> 5822  s[0] = 0;
> (gdb)
>
> I am running Ubuntu 19.10's default gdb:
>
> $ gdb --version
> GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
>
> I assume gmp is used for bignum implementation (didn't check yet), so it
> might be relevant as well:
>
> ii  libgmp-dev:amd64   2:6.1.2+dfsg-4
>amd64Multiprecision arithmetic library
> developers tools
> ii  libgmp10:amd64 2:6.1.2+dfsg-4
>amd64Multiprecision arithmetic library
> ii  libgmp10:i386  2:6.1.2+dfsg-4
>   

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

2020-05-08 Thread Dominik Pantůček

Hello,

On 08. 05. 20 14:27, Matthew Flatt wrote:

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.



I am using the build from master branch with the patch for #3145 and 
cannot make it run under gdb:


$ gdb ../racket-lang/racket/racket/bin/racket
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../racket-lang/racket/racket/bin/racket...
(No debugging symbols found in ../racket-lang/racket/racket/bin/racket)
(gdb) run
Starting program: 
/home/joe/Projects/Programming/racket-lang/racket/racket/bin/racket

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to Racket v7.7.0.4.
[New Thread 0x77fcb700 (LWP 6410)]

Thread 1 "racket" received signal SIGSEGV, Segmentation fault.
0x555e14fe in scheme_gmp_tls_unload ()
(gdb)

The same happens for the binary with debug symbols:

 gdb ../racket-lang/racket/racket/src/build/racket/racket3m
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
../racket-lang/racket/racket/src/build/racket/racket3m...

(gdb) run
Starting program: 
/home/joe/Projects/Programming/racket-lang/racket/racket/src/build/racket/racket3m 


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to Racket v7.7.0.4.
[New Thread 0x77fcb700 (LWP 6422)]

Thread 1 "racket3m" received signal SIGSEGV, Segmentation fault.
scheme_gmp_tls_unload (s=0x76114480, data=0x0) at 
../../../racket/gc2/../src/gmp/gmp.c:5822

5822  s[0] = 0;
(gdb)

I am running Ubuntu 19.10's default gdb:

$ gdb --version
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3

I assume gmp is used for bignum implementation (didn't check yet), so it 
might be relevant as well:


ii  libgmp-dev:amd64   2:6.1.2+dfsg-4 
  amd64Multiprecision arithmetic library 
developers tools
ii  libgmp10:amd64 2:6.1.2+dfsg-4 
  amd64Multiprecision arithmetic library
ii  libgmp10:i386  2:6.1.2+dfsg-4 
  i386 Multiprecision arithmetic library
ii  libgmpxx4ldbl:amd642:6.1.2+dfsg-4 
  amd64Multiprecision arithmetic library (C++ 
bindings)
ii  python-gmpy:amd64  1.17-4 
  amd64interfaces GMP to Python for fast, 
unbound-precision computations



I will pull latest master and re-try, but that is really just a blind guess.


Cheers,
Dominik

--
You 

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] How to avoid all packages when building from source?

2020-05-08 Thread Sam Tobin-Hochstadt
The default build installs "main-distribution", which is the same as what
you get for a regular (not minimal) Racket install. It does, as you
noticed, install a lot of packages.

You can do "make base" instead, which installs no packages. Or you can do
something like 'make PKGS=drracket' which just installs DrRacket and
dependencies, or similar with other packages.

Note that rerunning "make base" will make all your packages disappear if
you install them after running make base the first time.

Sam

On Fri, May 8, 2020, 6:10 AM zeRusski  wrote:

> I just rebuilt Racket from git repo checkout. It takes a while but most of
> that time is spent in `raco setup` which appears to be building all
> packages in existence. E.g. games, redex-examples, realm of Racket chapter
> 6 (really?), plai, algol, etc. Why do I end up with the entire jungle? Is
> there a way to avoid all these packages? Is there a way to figure where
> these dependencies are coming from?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/869f4d10-eb3a-42c1-a239-d71cdbc10092%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/CAK%3DHD%2BaF%2B%3D7jBfZ9wyADEANM_aGCcF%2B_k7F%2BAqWsRCNpnw52_g%40mail.gmail.com.


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

2020-05-08 Thread Sam Tobin-Hochstadt
This is the tooling I use: https://github.com/takikawa/racket-dev-goodies/

Note that it works primarily with "in-place" installations.

Sam

On Fri, May 8, 2020, 4:55 AM zeRusski  wrote:

> I have two builds of Racket on my local machine. Racket CS resides in one
> directory and was built with `RACKETCS_SUFFIX=""` and stardard Racket also
> built from source in a separate directory. Normally I have my .bashrc setup
> PATH as needed to use e.g. Racket CS. I ran into a problem with an upstream
> package which maybe FFI related, so now I want to test it against standard
> Racket build so I switch over the PATH and run it with non-cs `raco` and
> `racket`.
>
> 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? 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? I don't have a mental model of
> having two builds like this.
>
> How do you run and test multiple builds? Is there a good setup I can steal
> please?
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/195b0260-19f2-45b2-a36d-4edc344fef87%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/CAK%3DHD%2Bbx08tU1FfVpgCefk_i-_8RXKpqvim8HGtWxCfmanFYnQ%40mail.gmail.com.


[racket-users] How to avoid all packages when building from source?

2020-05-08 Thread zeRusski
I just rebuilt Racket from git repo checkout. It takes a while but most of 
that time is spent in `raco setup` which appears to be building all 
packages in existence. E.g. games, redex-examples, realm of Racket chapter 
6 (really?), plai, algol, etc. Why do I end up with the entire jungle? Is 
there a way to avoid all these packages? Is there a way to figure where 
these dependencies are coming from?

Thanks!

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


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

2020-05-08 Thread zeRusski
I have two builds of Racket on my local machine. Racket CS resides in one 
directory and was built with `RACKETCS_SUFFIX=""` and stardard Racket also 
built from source in a separate directory. Normally I have my .bashrc setup 
PATH as needed to use e.g. Racket CS. I ran into a problem with an upstream 
package which maybe FFI related, so now I want to test it against standard 
Racket build so I switch over the PATH and run it with non-cs `raco` and 
`racket`.

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? 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? I don't have a mental model of 
having two builds like this.

How do you run and test multiple builds? Is there a good setup I can steal 
please?
Thanks

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


[racket-users] Another futures-related bug hunt

2020-05-08 Thread Dominik Pantůček

Hello fellow Racketeers,

my spare-time out-of-curiosity venture into using HPR (High-Performance 
Racket) for creating a software 3D rendering pipeline seems to be 
pushing the futures into rough edges.


The scenario is sort of "usual":

* 7 futures + 1 in RTT that form a binary tree
* GUI thread running

But this time, the futures perform not only data-heavy fixnums 
operations, but flonums operations as well.


Something along the lines of 2560x1440 fixnums and the same number of 
flonums is being handled in 8 threads effectively (give or take some 
optimizations that slightly lower the 1440 height usually).


The code in question is relatively short - say 60 lines of code - 
however it does not make much sense without the remaining 2k lines :)


If the operation runs without futures in RTT, nothing happens. But under 
a heavy load and VERY varying amount of time (seconds to hours), it 
completely freezes with:


* 1 CPU being used at 100% (top/htop shows)
* Does not handle socket operations (X11 WM message for closing the window)
* Does not respond to keyboard (or via kill) SIGINT
* Can only be forcibly stopped by SIGKILL (or similar) or forcefully 
closing the window from WM which sort of gets handled probably in the 
lower-level parts of GDK completely without Racket runtime intervention 
(just prints Killed and the exit code is 137)


Based on these observations I can only conclude that it is the RTT that 
gets stuck - but that is only the native thread perspective. From Racket 
thread perspective, it can be either the "main" application thread that 
is in (thread-wait) for the thread that performs the futures stuff and 
it can also be the GUI thread which is created with parameterizing the 
eventspace (that is just some trickery to allow me to send breaks when I 
receive window close event).


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

And that is basically all I can tell right now.

Of course, any suggestions would be really welcome.

Cheers,
Dominik

P.S.: I am really curious, what will I find when I finally put 
fsemaphores into the mix...





--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ca40f468-53c7-6fd2-4e7f-0d963e931a60%40trustica.cz.