Re: [racket-dev] Switching to Google Groups
Please contact with gmane to update the info about the lists. I use its service to access to the list with NNTP. On 01/29/2015 01:47 AM, John Clements wrote: Dear developers, PLT would like to get out of the mailing-list administration game. Accordingly, we’re planning to switch to Google Groups. Rather than starting with our largest list, the Racket Users list, we’ve chosen to begin with the dev list, because … well, you’re probably more tolerant, if^H^H when something goes wrong. We would like the transition to be as smooth as possible, and we can use your help with this. Specifically, Google has a daily cap on the number of e-mail addresses that can be bulk-added to a mailing list. For this reason, it would speed the transition greatly if you could take a moment to sign up for the new group yourself, using this URL: https://groups.google.com/forum/#!forum/racket-dev We plan to disable signup for the old group now, and to halt delivery of mail to the existing group address tomorrow. You can post to the new group (after signing up) by sending mail to racket-...@googlegroups.com We plan to manually add or invite the members who do not add themselves, but the daily cap will mean that these users are likely to miss one or more days of postings to this list. Naturally, those posts will be archived, as part of the group. The archive of the existing list will continue to exist, though new messages will not be added to it. Let us know if you run into problems! Many thanks, John Clements PLT _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Racket sometimes fails on openbsd/i386. The person who is in charge of the openbsd i386 packages has seen similar problems since the first day. My usual tricks to build racket is increase the datasize (-d), the number of open files (-n) and the stack size (-s). I only use one job in raco. In contrast to the i386 experience, racket works like a charm on openbsd/amd64. Sincerely, I don't know if the bug is in racket or in openbsd. On 12/29/2014 02:41 PM, Philippe Meunier wrote: Juan Francisco Cantero Hurtado wrote: Works fine on my machine. I've re-built the whole thing several times over the past few days and it does not fail every time. It has failed once out of the last three builds I did. Try with ulimit -d 100. My limit was already set at 1048576 :-) The racket process never reaches that size anyway. Here are two graphs showing the size of the process over time, for two different successful builds: http://www.ccs.neu.edu/home/meunier/chart1.pdf http://www.ccs.neu.edu/home/meunier/chart2.pdf There's one data point every second. The top and right edges of the graphs are the 1048576 KB limit. The maximum size reached (in the second build) was 900116 KB. Interestingly, even tough these two builds succeeded and finished normally, I noticed that they both gave this error message: raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: 814000, 278528, 22 raco setup: rendering: pkgs/racket-doc/scribblings/inside/inside.scrbl In both builds the racket process was about 630 MB in size at the time this error message showed up. The place where this error message showed up is the exact same place in the build where racket failed in my original email... Now here is a graph for a build that failed: http://www.ccs.neu.edu/home/meunier/chart3.pdf It failed again while processing images.scrbl, but during the running part of the build this time, not the rendering part: raco setup: running: pkgs/images-doc/images/scribblings/images.scrbl Seg fault (internal error during gc) at 0xd98004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') The running: pkgs/.../images.scrbl is always the point in the build where the racket process reaches its maximum size (883864 KB in this case), but the process was already back down to about 584 MB when the internal error during gc message showed up. Here is the backtrace from gdb on the core file: (gdb) bt #0 0x04a78b01 in kill () at stdin:2 #1 0x04ae37f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04ae3740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x16e9fc3c in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket #4 signal handler called #5 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66 #6 0x16ea64b9 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x16e7de1f in scheme_register_traversers () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x16ea6b54 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x16ea6c5d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x16ea37a6 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x16ea5df4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x16ea83ca in GC_malloc_atomic () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x16ce7649 in scheme_generate_alloc_retry () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x00236c9b in ?? () #15 0x in ?? () _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
On 12/20/2014 04:17 PM, Philippe Meunier wrote: Juan Francisco Cantero Hurtado wrote: Hi, OpenBSD -current or -stable? amd64 or i386? Stable i386. Works fine on my machine. Try with ulimit -d 100. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Hi, OpenBSD -current or -stable? amd64 or i386? On 12/17/2014 01:56 PM, Philippe Meunier wrote: Hello, I just tried building racket from scratch on OpenBSD 5.6 after cloning the github repository, and raco setup failed: [...] raco setup: rendering: pkgs/html-doc/html/html.scrbl raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: d94000, 278528, 22 unmap failed: d94000, 278528, 22 Seg fault (internal error during gc) at 0xd94004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') Running gdb on the core file gives: (gdb) bt #0 0x04c5bb01 in kill () at stdin:2 #1 0x04cc67f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04cc6740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x17a72afc in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket #4 signal handler called #5 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66 #6 0x17a79379 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x17a49c5e in scheme_init_thread () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x17a79a14 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x17a79b1d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x17a7 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x17a78cb4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x17a79cca in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x17a79df2 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x17a7b810 in GC_malloc_one_tagged () from /home/meunier/lang/racket.new/racket/bin/racket #15 0x1784acc8 in scheme_malloc_fail_ok () from /home/meunier/lang/racket.new/racket/bin/racket #16 0x17953875 in scheme_alloc_flvector () from /home/meunier/lang/racket.new/racket/bin/racket #17 0x179544ee in scheme_integer_length () from /home/meunier/lang/racket.new/racket/bin/racket #18 0x09800fe7 in ?? () #19 0x9794ed58 in ?? () #20 0x9794ed58 in ?? () #21 0x7dff6308 in ?? () #22 0xbc34be90 in ?? () #23 0x9794ed84 in ?? () #24 0x0373e1b4 in ?? () #25 0x9794ed84 in ?? () #26 0xbc34be68 in ?? () #27 0x000d in ?? () #28 0x9794ee14 in ?? () #29 0xb81537a8 in ?? () #30 0x9794ed74 in ?? () #31 0xcfbdf450 in ?? () #32 0x0d46dc40 in ?? () #33 0x0cdcefa8 in ?? () #34 0x9fbfa530 in ?? () #35 0x0004 in ?? () #36 0x050049cf in ?? () #37 0xa0b12d78 in ?? () #38 0x9794edbc in ?? () #39 0x11073456 in ?? () #40 0x4074ce41 in ?? () #41 0x in ?? () Philippe _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Questions about the GC code
On 07/15/14 07:00, Matthew Flatt wrote: The gc directory is Boehm's GC. We've modified it a little (grep for PLTSCHEME), but we try not to maintain the GC itself, except to upgrade every once in a while. Sorry, I should to look the code before of to ask :) . I thought the boehm gc version included with racket was pretty modified. My bad. See http://www.hboehm.info/gc/ for the latest version, the mailing list, etc. I should look again at making Racket work with a stock build of Boehm's GC, so we can get out of the business of upgrading and modifying it. So far, it has been easier to upgrade occasionally than to sort that out. It is a great idea!. Boehm GC on OpenBSD is maintained by competent programmers and they can deal better with bugs than me. Meanwhile, Racket includes a slower and more portable SGC for building the conservative-GC variant of Racket. You can enable it with `--enable-sgc` as a flag to `configure`. Probably we should switch to SGC as the default, since RacketCGC is now mainly used just to build normal Racket. I've not enabled Senora by default because I tried to build racket on hppa and I had the same problem than with boehm. I've asked to another OpenBSD dev to test Racket with Senora on mips64el. At Tue, 15 Jul 2014 04:37:45 +0200, Juan Francisco Cantero Hurtado wrote: I've been reading the code of the files gc/os_dep.c and gc/include/private/gcconfig.h. I've some questions related to OpenBSD. --- In the X86_64 config, the file defines STACKBOTTOM and HEURISTIC2 (unused because racket picks STACKBOTTOM). What's the preferred?. I'm asking because I don't know if the adding of HEURISTIC2 was an error or really there a good reason to select one or other. --- There is some recommended benchmark to test the performance of MMAP vs sbrk? I've tried both with generic code and I don't see the difference. --- OpenBSD only supports MIPS64. Should I add ELFCLASS64 to the MIPS block within gcconfig.h? _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Questions about the GC code
I've been reading the code of the files gc/os_dep.c and gc/include/private/gcconfig.h. I've some questions related to OpenBSD. --- In the X86_64 config, the file defines STACKBOTTOM and HEURISTIC2 (unused because racket picks STACKBOTTOM). What's the preferred?. I'm asking because I don't know if the adding of HEURISTIC2 was an error or really there a good reason to select one or other. --- There is some recommended benchmark to test the performance of MMAP vs sbrk? I've tried both with generic code and I don't see the difference. --- OpenBSD only supports MIPS64. Should I add ELFCLASS64 to the MIPS block within gcconfig.h? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
On 07/03/14 10:07, Matthew Flatt wrote: I've just built Racket for Linux on MIPS without problem, so I don't think it's a misaligned access. Thanks for take a look to the problem :) Be aware linux has code in the kernel to fix misaligned access to memory. You can disable this behaviour in mips64 following this guide http://www.linux-mips.org/wiki/Alignment (or arm https://www.kernel.org/doc/Documentation/arm/mem_alignment). Maybe the problem is in some of the code inside of some C macro related to OpenBSD. I tried Linux because I found QEMU images that made it relatively convenient to try: http://people.debian.org/~aurel32/qemu/mipsel/ I've compiled racket in qemu with that image and with the workarounds mentioned above disabled. Racket builds without problem. The same with linux/armv7. If you can point me to similar images for OpenBSD, I'd be happy to take a closer look. I've been trying during the last days to run OpenBSD mips64/mips64el with qemu but I failed. I will try with other architectures. At Wed, 18 Jun 2014 04:33:46 +0200, Juan Francisco Cantero Hurtado wrote: Sorry for revive an old thread but recently an OpenBSD developer (jturner) has been testing racket on mips64el (loonsong). He sees a SIGBUS at the same point. GDB doesn't show a backtrace. Maybe the interpreter is performing a misaligned access to the memory at some point and the problem is not only related to the growing direction of the stack. It can even hurt slightly the performance on other platforms. HPPA and MIPS64 only permit aligned access to memory, however amd64, arm (almost always) and x86 doesn't have this problem. On 04/30/14 15:49, Juan Francisco Cantero Hurtado wrote: On 04/30/14 02:07, Matthew Flatt wrote: It's been a very long time since I touched a machine where the stack grows up. Does changing `c-cont-buf.stack_size` to `c-stack_size` work? I'm not sure: mkdir xsrc make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/xform.rkt --setup . --cpp cc -E -I./.. -I/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/../include -I/usr/local/include -I/usr/X11R6/include -pthread -I/usr/local/include -DMZ_USES_SHARED_LIB --keep-lines -o xsrc/precomp.h /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/precomp.c Segmentation fault (core dumped) The output of gdb: http://juanfra.info/bl/racket-2014/backtrace-racket-6.0.log At Wed, 30 Apr 2014 00:21:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 21:13, Matthew Flatt wrote: Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I think it should be on by default, but not actually forced, so I've made that repair. More to the point, I've pushed a repair so that CAS is attempted only when futures or places are enabled. I've compiled racket 6.0 with both patches. Now I see another (unrelated) problem: setjmpup.c: In function 'scheme_uncopy_stack' setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf' http://juanfra.info/bl/racket-2014/racket-6.0-3.log At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 20:08, Matthew Flatt wrote: I think `--enable-pthread` is triggering the attempt to use CAS. Can you leave that one out? I tried without enable-pthread. I see the same problem http://juanfra.info/bl/racket-2014/racket-6.0-2.log At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
Sorry for revive an old thread but recently an OpenBSD developer (jturner) has been testing racket on mips64el (loonsong). He sees a SIGBUS at the same point. GDB doesn't show a backtrace. Maybe the interpreter is performing a misaligned access to the memory at some point and the problem is not only related to the growing direction of the stack. It can even hurt slightly the performance on other platforms. HPPA and MIPS64 only permit aligned access to memory, however amd64, arm (almost always) and x86 doesn't have this problem. On 04/30/14 15:49, Juan Francisco Cantero Hurtado wrote: On 04/30/14 02:07, Matthew Flatt wrote: It's been a very long time since I touched a machine where the stack grows up. Does changing `c-cont-buf.stack_size` to `c-stack_size` work? I'm not sure: mkdir xsrc make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/xform.rkt --setup . --cpp cc -E -I./.. -I/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/../include -I/usr/local/include -I/usr/X11R6/include -pthread -I/usr/local/include -DMZ_USES_SHARED_LIB --keep-lines -o xsrc/precomp.h /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/precomp.c Segmentation fault (core dumped) The output of gdb: http://juanfra.info/bl/racket-2014/backtrace-racket-6.0.log At Wed, 30 Apr 2014 00:21:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 21:13, Matthew Flatt wrote: Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I think it should be on by default, but not actually forced, so I've made that repair. More to the point, I've pushed a repair so that CAS is attempted only when futures or places are enabled. I've compiled racket 6.0 with both patches. Now I see another (unrelated) problem: setjmpup.c: In function 'scheme_uncopy_stack' setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf' http://juanfra.info/bl/racket-2014/racket-6.0-3.log At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 20:08, Matthew Flatt wrote: I think `--enable-pthread` is triggering the attempt to use CAS. Can you leave that one out? I tried without enable-pthread. I see the same problem http://juanfra.info/bl/racket-2014/racket-6.0-2.log At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] racket-test: racket doesn't run all the tests when places is disabled
I'm testing the update to racket 6.0.1 and I'm seeing this problem: $ raco pkg install racket-test [..] $ cd .racket/6.0.1/pkgs/racket-test/tests/racket $ racket -f quiet.rktl Section(basic) Section(unicode) Section(rx) Section(reading) Section(readtable) Section(printing) Section(macro) Section(syntax) Section(procs) Section(stx) Section(module) Section(submodule) Section(stxparam) Section(numbers) Section(unsafe) Section(object) Section(struct) Section(threads) Section(logger) Section(synchronization) Section(places) Hello from place Hello form place 2 $ echo $? 99 Racket doesn't run all the tests and I guess the culprit is that I have places disabled. Can someone fix and update the package?. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
On 04/30/14 02:07, Matthew Flatt wrote: It's been a very long time since I touched a machine where the stack grows up. Does changing `c-cont-buf.stack_size` to `c-stack_size` work? I'm not sure: mkdir xsrc make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/xform.rkt --setup . --cpp cc -E -I./.. -I/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/../include -I/usr/local/include -I/usr/X11R6/include -pthread -I/usr/local/include -DMZ_USES_SHARED_LIB --keep-lines -o xsrc/precomp.h /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/precomp.c Segmentation fault (core dumped) The output of gdb: http://juanfra.info/bl/racket-2014/backtrace-racket-6.0.log At Wed, 30 Apr 2014 00:21:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 21:13, Matthew Flatt wrote: Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I think it should be on by default, but not actually forced, so I've made that repair. More to the point, I've pushed a repair so that CAS is attempted only when futures or places are enabled. I've compiled racket 6.0 with both patches. Now I see another (unrelated) problem: setjmpup.c: In function 'scheme_uncopy_stack' setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf' http://juanfra.info/bl/racket-2014/racket-6.0-3.log At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 20:08, Matthew Flatt wrote: I think `--enable-pthread` is triggering the attempt to use CAS. Can you leave that one out? I tried without enable-pthread. I see the same problem http://juanfra.info/bl/racket-2014/racket-6.0-2.log At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
On 04/28/14 21:13, Matthew Flatt wrote: Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I think it should be on by default, but not actually forced, so I've made that repair. More to the point, I've pushed a repair so that CAS is attempted only when futures or places are enabled. I've compiled racket 6.0 with both patches. Now I see another (unrelated) problem: setjmpup.c: In function 'scheme_uncopy_stack' setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf' http://juanfra.info/bl/racket-2014/racket-6.0-3.log At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 20:08, Matthew Flatt wrote: I think `--enable-pthread` is triggering the attempt to use CAS. Can you leave that one out? I tried without enable-pthread. I see the same problem http://juanfra.info/bl/racket-2014/racket-6.0-2.log At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
On 04/28/14 20:08, Matthew Flatt wrote: I think `--enable-pthread` is triggering the attempt to use CAS. Can you leave that one out? I tried without enable-pthread. I see the same problem http://juanfra.info/bl/racket-2014/racket-6.0-2.log At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado wrote: On 04/28/14 01:03, Matthew Flatt wrote: At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? No, I use always both arguments because we don't have support for tls on OpenBSD. Here is the log of the build: http://juanfra.info/bl/racket-2014/racket-6.0.log _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Compile racket without native compare-and-swap support?
I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] assembler code within gmplonglong.h
Hi. The last days I've been reading the code within gmplonglong.h and I've a question/request. Why there is assembler code? Why not just to remove the assembler code and to use the C fallback for every CPU?. These days the racket developers (and users) mostly only test their code on amd64, specially the math code. The file doesn't contain assembler code for amd64, so almost every one is compiling their interpreters with the C code. The old CPUs supported by gmplonglong.h are dead or have a modern C compiler. I doubt the assembler code even gives a better performance to racket than the C version. I'm complaining because I've tried to compile racket 5.3.6 (with some patches related to clang and gmp backported from the master branch) with clang and the build failed. I read the code and I was stunned when I saw the assembler code supporting so old CPUs and the C fallback used by amd64. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] assembler code within gmplonglong.h
I will give a try to your example. I disabled the assembler code in the OpenBSD port because with your last patch to gmplonglong and clang, the 5.3.6 math lib was broken on i386. We will have the CVS lock soon and I want be very careful now. I used initially clang to fix a crash in udp.rktl, now the port uses GCC 4.6. I will report both bugs when I have some of free time, if I can reproduce both with racket 6. It's OK if you want use assembler for the math code, I was just worried when I saw the amount of code for old CPUs, especially because I will work with some of these CPUs pretty soon and I fear there is more untested code for these archs. Compared with the usually elegant use of C macros in racket, that file is really hairy :) . And yes, 50% is a big difference, good to know :) . On 01/12/14 04:22, Matthew Flatt wrote: On the program (time (for/fold ([v (for/fold ([v 1]) ([i (in-range 1)]) (* (add1 i) v))]) ([i (in-range 1)]) (/ v (add1 i when compiling for 32-bit x86 with the latest XCode's clang and using a 2013 MacBook Pro running Mavericks, I get a 50% speed decrease when disabling the assembly code in gmplonglong.h. So, at least for 32-bit x86, I think the assembly code is probably worthwhile. Assembly seems to matter less for 64-bit mode. I copied the x86_64 assembly from the current GMP, and it seems to improve performance by 10%. That's not much of a difference, but enough that I would be inclined add the assembly; I hesitate only because adding more assembly is exactly the opposite of your request. At Sun, 12 Jan 2014 01:31:21 +0100, Juan Francisco Cantero Hurtado wrote: Hi. The last days I've been reading the code within gmplonglong.h and I've a question/request. Why there is assembler code? Why not just to remove the assembler code and to use the C fallback for every CPU?. These days the racket developers (and users) mostly only test their code on amd64, specially the math code. The file doesn't contain assembler code for amd64, so almost every one is compiling their interpreters with the C code. The old CPUs supported by gmplonglong.h are dead or have a modern C compiler. I doubt the assembler code even gives a better performance to racket than the C version. I'm complaining because I've tried to compile racket 5.3.6 (with some patches related to clang and gmp backported from the master branch) with clang and the build failed. I read the code and I was stunned when I saw the assembler code supporting so old CPUs and the C fallback used by amd64. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Backport of patches for clang warnings for racket 6
Hi. If it's not too late, I would like to have these patches included in racket 6: https://github.com/plt/racket/commit/56483c8809811cf31a46677fc63d75f75505c1e0 https://github.com/plt/racket/commit/93b38e25a6aae9fac970f650d36e8e6d881ba700 Thanks. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 6 (git branch release), configure options and dependencies
On 12/01/13 04:00, Matthew Flatt wrote: At Sun, 01 Dec 2013 03:31:32 +0100, Juan Francisco Cantero Hurtado wrote: On 11/25/13 05:10, Juan Francisco Cantero Hurtado wrote: Hi. I'm compiling racket 6 (from the git branch release) on OpenBSD. The configure script includes the options enable-gracket and enable-docs but I don't see the gracket binary and the docs installed after the installation. Someone forgot remove the options or these are usefull for something?. Another question. Racket 5.3 needs gtk, cairo, pango, gtkglext and so forth. What are the dependencies of racket core now?. Nobody? Sorry that I missed your message. Don't worry! These `--enable-docs` and `--enable-gracket` options are not as useful as before, but I haven't sorted out whether they're completely useless, and so they're still there. For example, `--disable-gracket` would avoid building the `gracket` helper executable that goes in lib --- but, then, installing any package with a `gracket`-based executable won't work right. The new way to avoid documentation is to just not install any documentation packages (at the Racket level). Similarly, aside from the `gracket` helper executable, avoid graphics and GUI dependencies by not installing graphics and GUI packages (at the Racket level). I like a lot the new approach :) I'm asking because I would like to add support for more OpenBSD platforms to racket. If I could to compile racket without the dependencies, just with a C compiler, it will help me a lot. I'm not interested in to give support to the GUI on some platforms because probably nobody will run drracket on a headless computer :) . And probably cairo or gtk will have problems on some old platforms, so the package won't compile because doesn't have the dependencies. So, basically I'm asking if racket 6 (and raco pkg) can work correctly without gtk, cairo, pango and others deps. Obviously raco can't generate docs but this isn't important. Any help?. A minimal Racket build doesn't depend on anything except standard tools, like `make` and a compiler, although it will use libiconv when available, and it will also use a pre-built libffi if available (or build one, otherwise). Libraries such as gtk, cairo, and pango are now dependencies of the gui and draw packages. (The `gracket` executable that is put in the lib directory doesn't depend on them.) Documentation builds depend on libsqlite3. Thanks for the help. I'll start the work on the new platforms after of the racket 6 release. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 6 (git branch release), configure options and dependencies
On Mon, Dec 2, 2013 at 2:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Not that you need more to do, I'm sure :), but the builds from the release branch (or just checking it out yourself if that's easier) are probably pretty close to the final release from the perspective of dependencies and OS packaging issues. And that turns out to be wrong, we'd probably be better positioned to fix it before the release goes out I'll wait to the release because I know racket 6 works without problems on amd64/i386 and I want to include the update of the package in the next release of OpenBSD for these platforms. Add more platforms require time and a lot of tests (from me and other people). Meanwhile, I'm working on the update to racket 6 for amd64/i386 :) (that's also the reason for my questions) On Sun, Dec 1, 2013 at 7:19 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 12/01/13 04:00, Matthew Flatt wrote: At Sun, 01 Dec 2013 03:31:32 +0100, Juan Francisco Cantero Hurtado wrote: On 11/25/13 05:10, Juan Francisco Cantero Hurtado wrote: Hi. I'm compiling racket 6 (from the git branch release) on OpenBSD. The configure script includes the options enable-gracket and enable-docs but I don't see the gracket binary and the docs installed after the installation. Someone forgot remove the options or these are usefull for something?. Another question. Racket 5.3 needs gtk, cairo, pango, gtkglext and so forth. What are the dependencies of racket core now?. Nobody? Sorry that I missed your message. Don't worry! These `--enable-docs` and `--enable-gracket` options are not as useful as before, but I haven't sorted out whether they're completely useless, and so they're still there. For example, `--disable-gracket` would avoid building the `gracket` helper executable that goes in lib --- but, then, installing any package with a `gracket`-based executable won't work right. The new way to avoid documentation is to just not install any documentation packages (at the Racket level). Similarly, aside from the `gracket` helper executable, avoid graphics and GUI dependencies by not installing graphics and GUI packages (at the Racket level). I like a lot the new approach :) I'm asking because I would like to add support for more OpenBSD platforms to racket. If I could to compile racket without the dependencies, just with a C compiler, it will help me a lot. I'm not interested in to give support to the GUI on some platforms because probably nobody will run drracket on a headless computer :) . And probably cairo or gtk will have problems on some old platforms, so the package won't compile because doesn't have the dependencies. So, basically I'm asking if racket 6 (and raco pkg) can work correctly without gtk, cairo, pango and others deps. Obviously raco can't generate docs but this isn't important. Any help?. A minimal Racket build doesn't depend on anything except standard tools, like `make` and a compiler, although it will use libiconv when available, and it will also use a pre-built libffi if available (or build one, otherwise). Libraries such as gtk, cairo, and pango are now dependencies of the gui and draw packages. (The `gracket` executable that is put in the lib directory doesn't depend on them.) Documentation builds depend on libsqlite3. Thanks for the help. I'll start the work on the new platforms after of the racket 6 release. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 6 (git branch release), configure options and dependencies
On 11/25/13 05:10, Juan Francisco Cantero Hurtado wrote: Hi. I'm compiling racket 6 (from the git branch release) on OpenBSD. The configure script includes the options enable-gracket and enable-docs but I don't see the gracket binary and the docs installed after the installation. Someone forgot remove the options or these are usefull for something?. Another question. Racket 5.3 needs gtk, cairo, pango, gtkglext and so forth. What are the dependencies of racket core now?. Nobody? I'm asking because I would like to add support for more OpenBSD platforms to racket. If I could to compile racket without the dependencies, just with a C compiler, it will help me a lot. I'm not interested in to give support to the GUI on some platforms because probably nobody will run drracket on a headless computer :) . And probably cairo or gtk will have problems on some old platforms, so the package won't compile because doesn't have the dependencies. So, basically I'm asking if racket 6 (and raco pkg) can work correctly without gtk, cairo, pango and others deps. Obviously raco can't generate docs but this isn't important. Any help?. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket 6 (git branch release), configure options and dependencies
Hi. I'm compiling racket 6 (from the git branch release) on OpenBSD. The configure script includes the options enable-gracket and enable-docs but I don't see the gracket binary and the docs installed after the installation. Someone forgot remove the options or these are usefull for something?. Another question. Racket 5.3 needs gtk, cairo, pango, gtkglext and so forth. What are the dependencies of racket core now?. Thanks. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket segfaults during raco setup on OpenBSD
On 09/16/13 17:10, Matthew Flatt wrote: I think this is a libffi problem, and I guess there's a patch that we still need to add to the Racket copy of libffi (although I sync'd with the latest libffi sson after the last time this was discussed). I've created a pull request with the patch. While we sort that out, you should be able to install the devel/libffi package, then re-running `configure` should pick up the installed libffi instead of building, and then things should work. See also http://lists.racket-lang.org/users/archive/2013-April/057056.html but skip to the end. At Mon, 16 Sep 2013 10:58:13 -0400, Philippe Meunier wrote: Hello, Starting from a clean clone of the git repository, racket3m segfaults on OpenBSD 5.3 while in the middle of doing the raco setup: $ pwd /home/meunier/lang/plt $ make [...] Adding xrepl-test* as pkgs/xrepl-pkgs/xrepl-test Writing racket/etc/config.rktd racket/bin/racket -N raco -l- raco setup raco setup: version: 5.90.0.9 [3m] raco setup: installation name: development raco setup: variants: 3m raco setup: main collects: /home/meunier/lang/plt/racket/collects [...] raco setup: making: pkgs/drracket/gui-debugger raco setup: in pkgs/drracket/gui-debugger Seg fault (internal error) at 0xa866246 *** Signal SIGABRT in . (Makefile:53 'plain-in-place') *** Error 1 in /home/meunier/lang/plt (Makefile:41 'in-place') GDB gives: $ gdb racket/bin/racket racket.core [...] (gdb) bt #0 0x0341bc2d in kill () at stdin:2 #1 0x03487826 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x0348774c in abort () at /usr/src/lib/libc/stdlib/abort.c:70 #3 0x1c1fb8b5 in fault_handler () #4 signal handler called #5 0x0a866246 in sse2_composite_over_n_8_ () from /usr/X11R6/lib/libpixman-1.so.28.0 #6 0x0a844c41 in pixman_composite_glyphs_no_mask () from /usr/X11R6/lib/libpixman-1.so.28.0 #7 0x1001bb48 in composite_glyphs () from /usr/local/lib/libcairo.so.12.1 #8 0x10064978 in composite_glyphs () from /usr/local/lib/libcairo.so.12.1 #9 0x100662ea in clip_and_composite () from /usr/local/lib/libcairo.so.12.1 #10 0x100665b3 in _cairo_traps_compositor_glyphs () from /usr/local/lib/libcairo.so.12.1 #11 0x1000da12 in _cairo_compositor_glyphs () from /usr/local/lib/libcairo.so.12.1 #12 0x1001fed5 in _cairo_image_surface_glyphs () from /usr/local/lib/libcairo.so.12.1 #13 0x100551d2 in _cairo_surface_show_text_glyphs () from /usr/local/lib/libcairo.so.12.1 #14 0x100164ca in _cairo_gstate_show_text_glyphs () from /usr/local/lib/libcairo.so.12.1 #15 0x1000727e in cairo_show_glyphs () from /usr/local/lib/libcairo.so.12.1 #16 0x0846b419 in pango_cairo_renderer_show_text_glyphs () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #17 0x0846b815 in pango_cairo_renderer_draw_glyphs () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #18 0x0ea2204a in pango_renderer_draw_glyphs () from /usr/local/lib/libpango-1.0.so.3200.0 #19 0x0ea2215d in pango_renderer_draw_glyph_item () from /usr/local/lib/libpango-1.0.so.3200.0 #20 0x0ea2280a in pango_renderer_draw_layout_line () from /usr/local/lib/libpango-1.0.so.3200.0 #21 0x0846a028 in _pango_cairo_do_layout_line () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #22 0x08090d73 in ffi_call_SYSV () from /usr/local/lib/libffi.so.0.0 #23 0x08090b7a in ffi_call (cif=0x7e8134a0, fn=0x7d415c20, rvalue=0xcfbe2cf0, avalue=0xcfbe2cb0) at src/x86/ffi.c:326 #24 0x1c1eeb8a in do_ptr_finalizer () #25 0x1c1eedb1 in do_ptr_finalizer () #26 0x033243f2 in ?? () #27 0x0002 in ?? () #28 0x81610754 in ?? () #29 0x89d764a0 in ?? () #30 0xcfbe2d98 in ?? () #31 0x0c4e30ef in ?? () #32 0x8162dc30 in ?? () #33 0x0c4e4074 in ?? () #34 0x in ?? () (gdb) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket should install libracket3m-X.Y.Z.so as libracket3m.so.X.Y.Z
On 09/11/13 10:42, Juan Francisco Cantero Hurtado wrote: The standard on modern unix systems is to name the shared libraries with this pattern: lib + name + .so. + major version + . + minor version. Racket uses libracket-5.3.6.so. It isn't correct. -rwxr-xr-x 1 root wheel 9.0M Aug 17 04:28 /usr/local/lib/libracket3m-5.3.6.so -rw-r--r-- 1 root wheel 14.3M Aug 17 04:28 /usr/local/lib/libracket3m.a -rw-r--r-- 1 root wheel 852B Aug 17 04:28 /usr/local/lib/libracket3m.la lrwxr-xr-x 1 root wheel20B Aug 17 05:51 /usr/local/lib/libracket3m.so - libracket3m-5.3.6.so Look some examples. libpng on OpenBSD: lrwxr-xr-x 1 root wheel10B Sep 10 19:30 /usr/local/lib/libpng.a - libpng16.a -rw-r--r-- 1 root bin 720B Aug 17 02:22 /usr/local/lib/libpng.la lrwxr-xr-x 1 root wheel16B Sep 10 19:30 /usr/local/lib/libpng.so.17.0 - libpng16.so.17.0 -rw-r--r-- 1 root bin 1.2M Aug 17 02:22 /usr/local/lib/libpng16.a -rw-r--r-- 1 root bin 730B Aug 17 02:22 /usr/local/lib/libpng16.la -rw-r--r-- 1 root bin 703K Aug 17 02:22 /usr/local/lib/libpng16.so.17.0 libarchive on Gentoo: lrwxrwxrwx 1 root root 20 May 10 09:12 /usr/lib/libarchive.so - libarchive.so.13.1.2 lrwxrwxrwx 1 root root 20 May 10 09:12 /usr/lib/libarchive.so.13 - libarchive.so.13.1.2 -rwxr-xr-x 1 root root 723968 May 10 09:12 /usr/lib/libarchive.so.13.1.2 Also you should add some easy setting to change the suffix X.Y.Z of the lib. Some projects use variables in configure or the main makefile. The version of the libs is unrelated to the version of the software. On OpenBSD we change the numbers, so we can control when the dependencies require an update. Any comment about this?. Basically, I need to rename libracket3m-5.3.6.so to libracket3m.so.0.0. I've searched where are the version numbers in the makefiles and configure but I've not found it. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket should install libracket3m-X.Y.Z.so as libracket3m.so.X.Y.Z
The standard on modern unix systems is to name the shared libraries with this pattern: lib + name + .so. + major version + . + minor version. Racket uses libracket-5.3.6.so. It isn't correct. -rwxr-xr-x 1 root wheel 9.0M Aug 17 04:28 /usr/local/lib/libracket3m-5.3.6.so -rw-r--r-- 1 root wheel 14.3M Aug 17 04:28 /usr/local/lib/libracket3m.a -rw-r--r-- 1 root wheel 852B Aug 17 04:28 /usr/local/lib/libracket3m.la lrwxr-xr-x 1 root wheel20B Aug 17 05:51 /usr/local/lib/libracket3m.so - libracket3m-5.3.6.so Look some examples. libpng on OpenBSD: lrwxr-xr-x 1 root wheel10B Sep 10 19:30 /usr/local/lib/libpng.a - libpng16.a -rw-r--r-- 1 root bin 720B Aug 17 02:22 /usr/local/lib/libpng.la lrwxr-xr-x 1 root wheel16B Sep 10 19:30 /usr/local/lib/libpng.so.17.0 - libpng16.so.17.0 -rw-r--r-- 1 root bin 1.2M Aug 17 02:22 /usr/local/lib/libpng16.a -rw-r--r-- 1 root bin 730B Aug 17 02:22 /usr/local/lib/libpng16.la -rw-r--r-- 1 root bin 703K Aug 17 02:22 /usr/local/lib/libpng16.so.17.0 libarchive on Gentoo: lrwxrwxrwx 1 root root 20 May 10 09:12 /usr/lib/libarchive.so - libarchive.so.13.1.2 lrwxrwxrwx 1 root root 20 May 10 09:12 /usr/lib/libarchive.so.13 - libarchive.so.13.1.2 -rwxr-xr-x 1 root root 723968 May 10 09:12 /usr/lib/libarchive.so.13.1.2 Also you should add some easy setting to change the suffix X.Y.Z of the lib. Some projects use variables in configure or the main makefile. The version of the libs is unrelated to the version of the software. On OpenBSD we change the numbers, so we can control when the dependencies require an update. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Missing patches in 5.3.6
I think is a good idea to include the next patches in racket 5.3.6. Support for libjpeg version 9: http://git.racket-lang.org/plt/commit/158997cde7 And libpng 1.6: https://github.com/plt/racket/commit/5629a6156a5720e51a277849f75b3135cb93664f https://github.com/plt/racket/commit/f97a7cf1778b74e9f38d97db61e91956565180c3 I've tested release with both patches on OpenBSD and everything is working as expected. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/14/13 15:00, Matthew Flatt wrote: At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote: On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? To clarify (because I now realize this may not have been apparent to others), you have in mind delivering Racket's main distribution as an OpenBSD port, right? I'm not sure yet. I have three options: - One big port with one big tarball. Like the actual port. Easiest in short term, probably a bad choice in the long term. - One port for the racket core + one port for each package from the PLT distro. I should create a port-module ( http://mdoc.su/o/port-modules ) for raco ports. Something similar to the port module of python or ruby. A lot of work for me. - Just one port for racket core. It's my favorite. At Sun, 14 Jul 2013 06:00:17 -0600, Matthew Flatt wrote: This was not been part of the plan. Now that you ask, though, I see how it makes sense to package the core source together with package sources for a given set of packages --- including the main-distribution package, for a site that distributes main-distribution installers. Longer term, I think that OS-level packages/ports should probably reflect a minimal Racket installation, and then further Racket packages would be installed via the Racket package system. But I can also see how a main Racket distribution package/port that resides completely within the OS's system could also make sense, especially in the short term. A core+package source tarball should make that easier. I'm worried about something. What will be the policy related to the bugfix releases of the packages?. Now, if some part of racket is broken on OpenBSD, I temporally patch the port and wait the next release of racket. If I decide go with the third option (only maintain the port of racket core), racket team will release quick bugfix updates to packages without wait to the next release of racket core?. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? [...] From Here to There -- The snapshot site http://www.cs.utah.edu/plt/snapshots/ (Now I understand that you said me about 5.3.900 in the bug of raco pkg, I was confusing the development version with an old X.Y.Z.900 release :) ) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On 06/18/13 19:36, Carl Eastlund wrote: rantI don't understand why version control systems don't take directories and renames more seriously, because this stuff is part of the development cycle and should be recorded like any other change./rant Mercurial tracks renames. Look hg help mv :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On 05/21/13 12:21, Carl Eastlund wrote: On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 05/20/13 23:24, Carl Eastlund wrote: On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: Eventually, when the dust settles, I think we'll want to convert every directory to its own git repo, and then we can incorporate the individual repos as git submodules. One nice thing about the current repo organization is that push notifications for every part of the PLT codebase go to all of the developers. Will that still be available in this organization scheme? (I don't care if it's opt-in too much, but opt-out will hopefully mean more eyes see the code) Cheers, Asumu Overall, I'm really glad to see Racket moving into the package system. I think it will be good for both (the Racket core and the package system). I'd like to mention, though, that git submodules can be a real pain for synchronizing development of multiple repositories. They seem to have been designed primarily for importing upstream repositories, rather than for multiple peer repositories. I'm not much more fond of the alternatives I have tried, either; if we're committing to splitting Racket into multiple repositories as well as multiple packages, we should be aware there may be another minor git learning curve ahead. Thanks to Jay and Matthew for working on all of this! I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic. Thanks for the hard work :) Git submodules imply one repo per package. A submodule is a mechanism that imports external repos into a checkout of a client repo, and records the specific commit of the checkout so that there is a correlation of the commits in each repo stored with the client. If we're going to use multiple repositories, we definitely need something like submodules in order to retain a shared commit history. You're right. I was thinking in git subtree. Sorry for the confusion. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On 05/20/13 23:24, Carl Eastlund wrote: On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: Eventually, when the dust settles, I think we'll want to convert every directory to its own git repo, and then we can incorporate the individual repos as git submodules. One nice thing about the current repo organization is that push notifications for every part of the PLT codebase go to all of the developers. Will that still be available in this organization scheme? (I don't care if it's opt-in too much, but opt-out will hopefully mean more eyes see the code) Cheers, Asumu Overall, I'm really glad to see Racket moving into the package system. I think it will be good for both (the Racket core and the package system). I'd like to mention, though, that git submodules can be a real pain for synchronizing development of multiple repositories. They seem to have been designed primarily for importing upstream repositories, rather than for multiple peer repositories. I'm not much more fond of the alternatives I have tried, either; if we're committing to splitting Racket into multiple repositories as well as multiple packages, we should be aware there may be another minor git learning curve ahead. Thanks to Jay and Matthew for working on all of this! I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic. Thanks for the hard work :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [ANN] RacketCon 2013: 29 September
On 05/08/13 17:49, Asumu Takikawa wrote: RacketCon 2013 -- We are pleased to announce that (third RacketCon) will take place on September 29, 2013 at Northeastern University in Boston. This year, we plan to bring in several speakers from industry, as well as host talks from Racket developers and users. Lunch will be provided. On the Saturday (28th) before RacketCon, we plan to hold a hackathon to work on various Racket projects. Registration will open during the summer, and we will post a detailed schedule of events around the same time. The conference website is at http://con.racket-lang.org/ Asumu Takikawa and PLT Just a side comment. Can you enhance the definition of the videos this year?. The quality of the videos in youtube is very poor. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3.4
On 04/23/13 05:16, Ryan Culpepper wrote:
The release announcement sketch that I have so far is below. Please
mail me new items and/or edits.
--
mflatt:
- added file-truncate (48e05093)
- mach-o: handle some new load commands (a229f292)
- mach-o: code signing fixes (1744a787)
- scribble/latex-properties: add command-extras (17865bfa)
- ffi/com: improve handling of type-described (79266fcf)
- added scribble/book and scribble/report langs (09d4aa3d)
- add _size, _ssize, _ptrdiff, etc (d46411d3)
- add phaseless modules (899a3279)
- improve complexity of hash-iterate-{key-value} (7a8c2ff0)
- add 'so-mode to system-type (cdf0f6b9)
- add interactive to slideshow (454f4c3f)
- ffi/com repairs, including mysterx compat (6e40caa7)
robby:
- added union-find (33747ec9)
- 2d (bb216d14)
- improved jump-to-def (39e4ac15)
jay:
- various pkg (39ae7a83, 9d3a42f1, 6bf03c12)
dyoo:
- parser-tools (9e0fce22, ???)
- fixed readline (f1e70516)
eli:
- add links to old documentation (250880d2)
- add {take,drop}f, splitf-at, etc (bb17b6a8, 2cdfe18b, 3af72eca)
- make configure install docs in standard place (59b18eec)
ryanc:
- added #:datum-literals (d5fe6021)
- added unstable/macro-testing (1ef38458)
- added unstable/socket (b3afbdd4)
- added #:grammar to defform, etc (293b208a)
sstrickl:
- with-contract improvements (539c25bb)
chrdimo:
- support for multiple blame parties (17e419e7)
- added option contracts (5808b0c4)
bfetscher:
- redex-generator: determine bound order automatically (2a9d4221)
stamourv:
- move optimization coach to planet2 (2c8e5f9a)
asumu:
- make srfi/19 compat with date* (d406e2db)
- separate in/out contracts for parameters (3ddde6a7)
Michael Filonenko:
- extflonums (17b80926)
- extflounum unboxing (840fc9c6)
Eric Dobson:
- AnyValues type (aac25b42)
Tobias Hamer:
- readline improvements (0f6a5833)
- support multiple values in wrap-evt and handle-evt (7e2b443f)
Patrick Mahoney:
- move eopl language to racket (b265e260)
Chris Jester-Young:
- fix srfi/61 use of =, else (9e93ee26)
Juan Francisco Cantero Hurtado:
- fix configure for openbsd (292c81a8)
fix configure for GCC 4.7 on OpenBSD is a better description.
Add also Change the default stack size to safe values on OpenBSD
(592d762).
William Bowman:
- changed define-union-language to merge nts (b0db8798, 42847ea5)
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] package install mode
On 01/05/2013 03:58 PM, Matthew Flatt wrote: I have been thinking about how developers who build their own Racket are more likely to want installation-wide packages instead of user- and version-specific packages. This is particularly true for those of us who work from the git respository. Maybe the default for a build `configure'd without `--prefix' (or, more generally, for a non-Unix-style build) should be installation-wide package installs, while the default for our pre-built distributions should be user- and version-specific installs. The default mode would be determined by configuration information in the installation-specific package area, and something like `raco pkg config -i default-mode mode' could change an installation's default. Does this sound like a good idea? I prefer the current defaults :) . If the user knows what he/she is doing, probably also knows how to install software system-wide. In Linux/BSD, to use /home/myuser by default for software compiled manually is always safer for newbies. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
On 11/20/12 02:01, Robby Findler wrote: Oh, I see. If you really need the lists of files to be the same, it is probably best to make both versions have the files (altho don't different architectures have different sets of files in general?). Probably you'll be breaking the distro if you remove files. I've been thinking about the problem and other solution is to generate the files on amd64 and install manually on i386. Of course I can install different files in each arch but I don't want more complexity in the PLIST, now it has +2 files :P Robby On Monday, November 19, 2012, Juan Francisco Cantero Hurtado wrote: On 11/19/12 19:21, Robby Findler wrote: I think it is probably best to have the OpenBSD port be a faithful match to 5.3.1. This isn't a major bug and hopefully you'll just get the fix in 5.3.2 or whatever the next version is called in 2-3 months. Does that sound ok to you? Temporally I'll remove the files affected from the PLIST (the list of files of the package), with this I can avoid the differences between archs. When the bug is fixed, I'll decide if the patch is too invasive or not for add to the port. Obviously this bug isn't a big problem for me :) OpenBSD will release the next version at May 1 and IIRC the frozen of the CVS will occur in February. I want do racket a official package for the next release, so I need fix or at least add a note about the known bugs. Robby On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 03:40, Robby Findler wrote: On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto neil.toro...@gmail.com wrote: It's a problem with the contract boundary. The examples work fine in Typed Racket. The problem type is this: (: flomap-transform (case- (flomap Flomap-Transform - flomap) (flomap Flomap-Transform Integer Integer Integer Integer - flomap))) The contract system claims that `flomap-transform' breaks its own contract. This is clearly bogus, so TR must be generating the wrong contract for it. Still, I should have caught this, and I apologize. I'll do penance by... writing a bug report? Probably not enough. Penance is an antiquated concept. We should do away with it. :) But if you feel bad enough to make a small program that demonstrates the problem that would be a contribution to it's solution! Thanks for to catch the bug guys!. Please send me a mail when you fix the bug and I'll add the patches to the OpenBSD port. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
On 11/19/12 19:21, Robby Findler wrote: I think it is probably best to have the OpenBSD port be a faithful match to 5.3.1. This isn't a major bug and hopefully you'll just get the fix in 5.3.2 or whatever the next version is called in 2-3 months. Does that sound ok to you? Temporally I'll remove the files affected from the PLIST (the list of files of the package), with this I can avoid the differences between archs. When the bug is fixed, I'll decide if the patch is too invasive or not for add to the port. Obviously this bug isn't a big problem for me :) OpenBSD will release the next version at May 1 and IIRC the frozen of the CVS will occur in February. I want do racket a official package for the next release, so I need fix or at least add a note about the known bugs. Robby On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 03:40, Robby Findler wrote: On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto neil.toro...@gmail.com wrote: It's a problem with the contract boundary. The examples work fine in Typed Racket. The problem type is this: (: flomap-transform (case- (flomap Flomap-Transform - flomap) (flomap Flomap-Transform Integer Integer Integer Integer - flomap))) The contract system claims that `flomap-transform' breaks its own contract. This is clearly bogus, so TR must be generating the wrong contract for it. Still, I should have caught this, and I apologize. I'll do penance by... writing a bug report? Probably not enough. Penance is an antiquated concept. We should do away with it. :) But if you feel bad enough to make a small program that demonstrates the problem that would be a contribution to it's solution! Thanks for to catch the bug guys!. Please send me a mail when you fix the bug and I'll add the patches to the OpenBSD port. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket installs more files on amd64 than on i386
I'm seeing a weird behavior of the installation of Racket 5.3.1 on OpenBSD (I don't know if other OS are affected or not). On amd64 Racket installs this files: /usr/local/share/racket/doc/images/pict_168.png /usr/local/share/racket/doc/images/pict_169.png /usr/local/share/racket/doc/images/pict_170.png /usr/local/share/racket/doc/images/pict_171.png /usr/local/share/racket/doc/images/pict_172.png /usr/local/share/racket/doc/images/pict_173.png /usr/local/share/racket/doc/images/pict_174.png /usr/local/share/racket/doc/images/pict_175.png /usr/local/share/racket/doc/images/pict_176.png /usr/local/share/racket/doc/images/pict_177.png /usr/local/share/racket/doc/images/pict_178.png /usr/local/share/racket/doc/images/pict_179.png /usr/local/share/racket/doc/images/pict_180.png /usr/local/share/racket/doc/images/pict_181.png /usr/local/share/racket/doc/images/pict_182.png /usr/local/share/racket/doc/images/pict_183.png On i386 Racket doesn't install these files. I use the same options for to compile both packages. Any idea? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
On 11/19/12 00:08, Robby Findler wrote: What are they? The most of the images say we claim the privilege. One is the US Congress. Robby On Sun, Nov 18, 2012 at 5:01 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: I'm seeing a weird behavior of the installation of Racket 5.3.1 on OpenBSD (I don't know if other OS are affected or not). On amd64 Racket installs this files: /usr/local/share/racket/doc/images/pict_168.png /usr/local/share/racket/doc/images/pict_169.png /usr/local/share/racket/doc/images/pict_170.png /usr/local/share/racket/doc/images/pict_171.png /usr/local/share/racket/doc/images/pict_172.png /usr/local/share/racket/doc/images/pict_173.png /usr/local/share/racket/doc/images/pict_174.png /usr/local/share/racket/doc/images/pict_175.png /usr/local/share/racket/doc/images/pict_176.png /usr/local/share/racket/doc/images/pict_177.png /usr/local/share/racket/doc/images/pict_178.png /usr/local/share/racket/doc/images/pict_179.png /usr/local/share/racket/doc/images/pict_180.png /usr/local/share/racket/doc/images/pict_181.png /usr/local/share/racket/doc/images/pict_182.png /usr/local/share/racket/doc/images/pict_183.png On i386 Racket doesn't install these files. I use the same options for to compile both packages. Any idea? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
On 11/19/12 01:13, Robby Findler wrote: Maybe the difference is that there is a bug on x86, then, as in my copy of that file I see a bunch of errors in the Compositing docs. Do you see errors in one installation and images in the other? Yes. I see errors (red text in the web page) in both archs. Images only on amd64. Robby On Sun, Nov 18, 2012 at 5:48 PM, Ray Racine ray.rac...@gmail.com wrote: file:///usr/local/racket/doc/images/Spatial_Transformations.html?q=Compositing It is being generated and used as part of the standard doc. On Sun, Nov 18, 2012 at 6:39 PM, Ray Racine ray.rac...@gmail.com wrote: I have it as well. Seems to be in the git repo. Google of the phrase is interesting as well. On Sun, Nov 18, 2012 at 6:23 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 00:08, Robby Findler wrote: What are they? The most of the images say we claim the privilege. One is the US Congress. Robby On Sun, Nov 18, 2012 at 5:01 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: I'm seeing a weird behavior of the installation of Racket 5.3.1 on OpenBSD (I don't know if other OS are affected or not). On amd64 Racket installs this files: /usr/local/share/racket/doc/images/pict_168.png /usr/local/share/racket/doc/images/pict_169.png /usr/local/share/racket/doc/images/pict_170.png /usr/local/share/racket/doc/images/pict_171.png /usr/local/share/racket/doc/images/pict_172.png /usr/local/share/racket/doc/images/pict_173.png /usr/local/share/racket/doc/images/pict_174.png /usr/local/share/racket/doc/images/pict_175.png /usr/local/share/racket/doc/images/pict_176.png /usr/local/share/racket/doc/images/pict_177.png /usr/local/share/racket/doc/images/pict_178.png /usr/local/share/racket/doc/images/pict_179.png /usr/local/share/racket/doc/images/pict_180.png /usr/local/share/racket/doc/images/pict_181.png /usr/local/share/racket/doc/images/pict_182.png /usr/local/share/racket/doc/images/pict_183.png On i386 Racket doesn't install these files. I use the same options for to compile both packages. Any idea? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Racket spamming with undefined symbol
On 10/18/12 20:09, Matthew Flatt wrote: At Thu, 04 Oct 2012 03:48:42 +0200, Juan Francisco Cantero Hurtado wrote: Probably you need execute 'export LDFLAGS=-pthread -lcrypto' in your shell before of run ./configure. Thanks for the suggestion, and I see why that would work. Still, I think it's better to change the way that libcryto is opened via `ffi-lib', since the dependency on libcrypto comes from the openssl collection specifically. I've seen a similar issue with libGLU and plt-games. plt-games shows various errors like this: /usr/local/bin/gracket:/usr/X11R6/lib/libGLU.so.7.0: undefined symbol 'glEvalMesh1' A list with all libraries used by racket (via ffi-lib) would be a big help for the maintainers :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Racket spamming with undefined symbol
On Thu, 18 Oct 2012 12:09:25 -0600 Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 04 Oct 2012 03:48:42 +0200, Juan Francisco Cantero Hurtado wrote: Probably you need execute 'export LDFLAGS=-pthread -lcrypto' in your shell before of run ./configure. Thanks for the suggestion, and I see why that would work. Still, I think it's better to change the way that libcryto is opened via `ffi-lib', since the dependency on libcrypto comes from the openssl collection specifically. I've seen a similar issue with libGLU and plt-games. plt-games shows various errors like this: /usr/local/bin/gracket:/usr/X11R6/lib/libGLU.so.7.0: undefined symbol 'glEvalMesh1' It's not a big problem but a list with all libraries used by racket (via ffi-lib) would be a big help for the maintainers :) -- Juan Francisco Cantero Hurtado http://juanfra.info _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Racket spamming with undefined symbol
On 10/02/2012 05:41 PM, Matthew Flatt wrote: It looks like this is a result of the way that libssl is linked on OpenBSD. In particular, it seems to not refer to libcrypto directly, and instead depends on libcrypto supplying it exports in the global namespace. Although the Racket `openssl' library does load libcrypto in advance, it does so without making exported symbols global within the process, and so libssl doesn't see them when it's loaded. The `openssl' library could open libcrypto in a way that makes its exports global, but I'm pretty sure that's the wrong thing for all other platforms that I've tried. Also, the fact that you can start DrRacket suggests that libraries such as Gtk (which I do not have installed in my OpenBSD image) are linked in the usual way. Is special-casing libcrypto on OpenBSD really the right thing? At Tue, 2 Oct 2012 08:34:55 -0400, Lars Engblom wrote: Environment: OpenBSD 5.1 amd64 Problem: Many racket programs spams with undefined symbol for openssl. This makes it almost impossible to to read outputs in the console. Hi Lars!. I never saw this errors in openbsd-current/amd64. Probably you need execute 'export LDFLAGS=-pthread -lcrypto' in your shell before of run ./configure. Or just try the version in openbsd-wip [1], the port compiles a full version of racket now. Cheers. 1. https://github.com/jasperla/openbsd-wip/tree/50781aab760dcf3a1b92e58bd3adeab56b0c77f0/lang/racket PS: Apologies to the list admins, I sent this mail three times :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.2 on OpenBSD and --enable-backtrace
On 07/31/12 15:37, Matthew Flatt wrote: At Mon, 30 Jul 2012 01:50:22 +0200, Juan Francisco Cantero Hurtado wrote: Hi. I've a question about --enable-backtrace in the configure step. Is it useful for the users or only is useful for the racket developers?. This option affect to the performance of racket?. It's potentially useful to users, but it's expensive. You shouldn't include it in a normal build. OK. Disabled. I'm not a scheme/racket developer. I'm just the racket maintainer on OpenBSD [1]. I'm using this configure options: --enable-shared --enable-libffi --enable-gracket --enable-jit --enable-foreign --enable-places --disable-futures --enable-float --enable-docs --enable-backtrace --enable-pthread Unless you have a particular reason to disable futures, I'd enable that one. make install fails with futures enabled. My goal now is to create a stable package of Racket for OpenBSD. I'll open a bug related to futures when I finish the package. Thanks for the help! _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket 5.2 on OpenBSD and --enable-backtrace
Hi. I've a question about --enable-backtrace in the configure step. Is it useful for the users or only is useful for the racket developers?. This option affect to the performance of racket?. I'm not a scheme/racket developer. I'm just the racket maintainer on OpenBSD [1]. I'm using this configure options: --enable-shared --enable-libffi --enable-gracket --enable-jit --enable-foreign --enable-places --disable-futures --enable-float --enable-docs --enable-backtrace --enable-pthread 1. https://github.com/juanfra684/openbsd-wip/blob/racket/lang/racket/Makefile _ Racket Developers list: http://lists.racket-lang.org/dev
