Re: [racket-dev] [plt] Push #25105: master branch updated
With all due respect. Was there a reason why parametric imports don't work? They do change behavior in a way that doesn't jive with the TR port-to-typed-without-change-in-semantics philosophy. On Jul 29, 2012, at 9:27 AM, stamo...@racket-lang.org wrote: stamourv has updated `master' from a0e6892d3e to dd02f5eeda. http://git.racket-lang.org/plt/a0e6892d3e..dd02f5eeda =[ One Commit ]= Directory summary: 43.8% collects/tests/typed-racket/succeed/ 56.1% collects/typed-racket/ ~~ dd02f5e Vincent St-Amour stamo...@racket-lang.org 2012-07-29 09:02 : | Fix parametric require/typed in typed/racket/base. | | Closes PR12951. | | Please merge to release. : A collects/tests/typed-racket/succeed/parametric-require-tr-base.rkt M collects/typed-racket/typed-racket.rkt | 2 +- =[ Overall Diff ]=== collects/tests/typed-racket/succeed/parametric-require-tr-base.rkt ~~ --- /dev/null +++ NEW/collects/tests/typed-racket/succeed/parametric-require-tr-base.rkt @@ -0,0 +1,4 @@ +#lang typed/racket/base + +(require/typed racket/base +(values (All (a) (a - a collects/typed-racket/typed-racket.rkt ~~ --- OLD/collects/typed-racket/typed-racket.rkt +++ NEW/collects/typed-racket/typed-racket.rkt @@ -7,7 +7,7 @@ ;; that may appear in the residual program utils/utils.rkt (for-syntax utils/utils.rkt) - utils/any-wrap.rkt unstable/contract) + utils/any-wrap.rkt unstable/contract racket/contract/parametric) (provide (rename-out [module-begin #%module-begin] [top-interaction #%top-interaction]) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible 5.2.900.1 bug involving rest argument
On Jul 28, 2012, at 8:25 PM, Eli Barzilay wrote: andmap: contract violation expected: list? given: '(#syntax:/tmp/zzz:5:19 Y . #syntax:/tmp/zzz:5:23 Z) argument position: 2nd other arguments...: #procedure:void context...: /home/scheme/html/release/racket/collects/syntax/parse/private/residual.rkt:206:0: predicate-ellipsis-parser /tmp/zzz: [running body] and the trace that points at synax/parse/private/residual.rkt was there when I tried your original line, so I think that it's the right error. (I'll let Ryan take it from here, I just did a semi-blind tracking...) Eli, note how contract messages helped shift blame from compiler to syntax/parse. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25105: master branch updated
At Sun, 29 Jul 2012 10:15:17 -0400, Matthias Felleisen wrote: With all due respect. Was there a reason why parametric imports don't work? They do change behavior in a way that doesn't jive with the TR port-to-typed-without-change-in-semantics philosophy. Parametric imports were already in `typed/racket', but were not in `typed/racket/base'. This commit fixes `typed/racket/base' to be consistent with `typed/racket'. It doesn't change the semantics of parametric imports. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.3 pre-release impressions?
Thanks, Doug. From talking with a few people, it sounds like 5.3 is shaping up pretty normally for a release, and the releases have been high-quality. I was just a little spooked by running into two bugs very quickly (two points determine a line, after all), but I haven't found any since those. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] seeing segfaults on build on 64-bit ubuntu
I tried building from scratch again from c9d0319a11cb2aae6d1e81d0c6465b4241a4ecff and see the following: raco setup: 1 running: plot/scribblings/plot.scrbl raco setup: 2 running: preprocessor/scribblings/preprocessor.scrbl raco setup: 2 running: scribblings/quick/quick.scrbl raco setup: 2 running: r5rs/r5rs.scrbl raco setup: 2 running: r6rs/scribblings/r6rs.scrbl *** glibc detected *** racket/racket3m: double free or corruption (!prev): 0x2afccc1395e0 *** *** glibc detected *** racket/racket3m: double free or corruption (!prev): 0x2afccc1395e0 *** === Backtrace: = === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x2afca64ad626] /usr/lib/x86_64-linux-gnu/libpixman-1.so.0(pixman_image_unref+0x17)[0x2afce1314a97] /usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x21fd1)/usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x293cc/usr/lib/x86_64-linux-gnu/libcairo.so.2(cairo_stroke_preserve+0x20)[0x2afce102e250] /usr/lib/x86_64-linux-gnu/libcairo.so.2(cairo_stroke+0x9)[0x2afce102e269] racket/racket3m(/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x1e5)[0x2afca600f435] racket/racket3m(scheme_do_eval+0x295)[0x454bd5] racket/racket3m(ffi_do_call+0x70b)[0x6485eb] racket/racket3m(scheme_do_eval+0x295)[0xAborted (core dumped) make[1]: *** [install-3m] Error 134 make[1]: Leaving directory `/home/dyoo/local/racket/src/build' make: *** [install] Error 2 dyoo@grom:~/local/racket/src/build$ gdb racket/racket3m core GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html 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. For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/... Reading symbols from /home/dyoo/local/racket/src/build/racket/racket3m...done. warning: core file may not match specified executable file. [New LWP 8450] [New LWP 6091] [New LWP 6090] [New LWP 8455] [New LWP 6092] [New LWP 8454] [New LWP 8448] [New LWP 8453] [New LWP 8449] [New LWP 8451] [New LWP 8452] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Core was generated by `racket/racket3m -X /home/dyoo/local/racket/collects -N raco setup -l- setup --n'. Program terminated with signal 6, Aborted. #0 0x2afca6465445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) where #0 0x2afca6465445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x2afca6468bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x2afca64a2e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x2afca64ad626 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x2afce1314a97 in pixman_image_unref () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #5 0x2afce103c965 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #6 0x2afce103e3cc in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #7 0x2afce103f6eb in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #8 0x2afce103fe8b in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #9 0x2afce105d642 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #10 0x2afce1036fd1 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #11 0x2afce102e250 in cairo_stroke_preserve () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #12 0x2afce102e269 in cairo_stroke () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #13 0x2afca600fa14 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #14 0x2afca600f435 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #15 0x006485eb in ffi_do_call (data=optimized out, argc=optimized out, argv=0x2afcddc01998) at xsrc/foreign.c:5246 #16 0x00454bd5 in scheme_do_eval (obj=0x2afd28d11328, num_rands=1, rands=0x2afcddc01998, get_value=-1) at ../../../racket/gc2/../src/eval.c:2991 #17 0x00458603 in _scheme_apply_multi_from_native ( rator=optimized out, argc=1, argv=optimized out) at ../../../racket/gc2/../src/schnapp.inc:87 #18 0x2afca87502fb in ?? () #19 0x2afcbe3260f0 in ?? () #20 0x2afcd7e34aa2 in ?? () #21 0x in ?? () _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
Hi All; We're currently trying to figure out the right way to handle a name conflict in Debian between racket and an rss aggregator named planet-venus. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685 I don't use the command /usr/bin/planet myself, so I was wondering if anybody could explain the likely disruption caused by (hypothetically) renaming it. In particular is it likely to be somether where people are using it from scripts or cron jobs, or would making a shell alias (alias planet planet-racket) suffice to avoid retraining fingers? Thanks David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
The Racket core distribution has already started deprecating the 'planet' command in favour of going through the 'raco' command and the 'planet' subcommand: raco planet ... rather than planet ... The current documentation does not refer to the 'planet' command at all. If users are still using it, then an alias would be sufficient, since it is unlikely that programs (certainly none in the Racket distribution) call 'planet' directly. Jay On Sun, Jul 29, 2012 at 1:46 PM, David Bremner brem...@debian.org wrote: Hi All; We're currently trying to figure out the right way to handle a name conflict in Debian between racket and an rss aggregator named planet-venus. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685 I don't use the command /usr/bin/planet myself, so I was wondering if anybody could explain the likely disruption caused by (hypothetically) renaming it. In particular is it likely to be somether where people are using it from scripts or cron jobs, or would making a shell alias (alias planet planet-racket) suffice to avoid retraining fingers? Thanks David _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco make cannot marshal value error
Maybe it would be good to have official support for safe 3D values. I realized after I wrote the `images/compile-time' module that it was just a special case. It could be extended to handle anything serializable. Having to serialize values at expansion time and unserialize them at runtime makes 3D values pretty safe. Neil ⊥ On 07/27/2012 05:56 AM, Matthias Felleisen wrote: I am almost sure there are additional explanations of 3d syntax and its problems between then and now. When we (re)discovered 3d syntax at IU in 1984, we thought it was better than sliced bread. So it is natural that many other people re-discover it and want to use it in Racket. On Jul 27, 2012, at 5:35 AM, Tobias Hammer wrote: Thanks for the explanation. I think i understand now what i did wrong. The 3D syntax was a good hint for further reading. I digged up a thread* where you already had to explain it 10 years ago :) Tobias * http://www.cs.utah.edu/plt/mailarch/plt-scheme-2002/msg00111.html On Thu, 26 Jul 2012 15:36:44 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: I agree that it's a bug, in a sense, that your program runs even though it cannot be compiled. This is an example of 3-D syntax: you're embedding a value (i.e., an instance of `s') that you can't write as a literal into the result of a macro expansion. I think 3-D syntax probably should not be allowed, but the macro system currently allows it. Most likely, using 3-D syntax is a bad idea. It's possible that you want to replace `#:transparent' with `#:prefab' in your example, since a prefab structure can be written as a literal. More likely, I think you want to generate an expression that constructs an `s' instead of generating an `s' instance in the macro expansion. At Thu, 26 Jul 2012 14:59:41 +0200, Tobias Hammer wrote: Hi, i have the following two files, one that only requires the other and calls a macro and the other one that defines that macro: === main.rkt #lang racket (require err.rkt) (a) === err.rkt #lang racket (begin-for-syntax (struct s (arg) #:transparent) (define (fun arg) (printf arg: ~a\n arg))) (define-syntax (a stx) (syntax-case stx () [(_) (with-syntax ([v #`#,(s 123)]) #'(begin (begin-for-syntax (fun v])) (provide a) When executing 'racket main.rkt' directly i get the expected output arg: #(struct:s 123) but when i try to call 'raco make main.rkt' instead, i get this strange error: arg: #(struct:s 123) write: cannot marshal value that is embedded in compiled code value: (s 123) context...: /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:388:6 /home_local/hamm_to/racket/racket-5.3.0.16/collects/racket/private/more-scheme.r kt:151:2: call-with-break-parameterization /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:188:5 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:508:26 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:501:42 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:466:0: maybe-compile-zo /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:579:2: do-check /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:653:4 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt:7 7:8: for-loop /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/raco.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/main.rkt: [running body] I think i need a little help to understand what is happening here and what i am doing wrong. I had expected that running and compiling works on the same set of programs. Thanks for any clarification. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Feature request: Vector-sort
I would find a sort function for vectors very useful. Thanks, Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request: Vector-sort
A few minutes ago, Harry Spier wrote: I would find a sort function for vectors very useful. Actually, the `sort' code uses a vector to do its work, which is initialized from the input list. But it doesn't help much to make it deal with vectors too, since the vector that is used for the sorting work needs to be bigger than the input -- so to sort a vector you'd still need to create a copy. Given that, you can usually just do the usual (list-vector (sort (vector-list v) )). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25105: master branch updated
On Sun, Jul 29, 2012 at 7:57 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Sun, 29 Jul 2012 10:15:17 -0400, Matthias Felleisen wrote: With all due respect. Was there a reason why parametric imports don't work? They do change behavior in a way that doesn't jive with the TR port-to-typed-without-change-in-semantics philosophy. Parametric imports were already in `typed/racket', but were not in `typed/racket/base'. More specifically, Typed Racket changed to statically depend on less of the contract system at expansion time, but I neglected to ensure that the appropriate `require` of `racket/contract/polymorphic` was maintained for the residual program. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request: Vector-sort
On Sun, Jul 29, 2012 at 6:12 PM, Eli Barzilay e...@barzilay.org wrote: Actually, the `sort' code uses a vector to do its work, which is initialized from the input list. But it doesn't help much to make it deal with vectors too, since the vector that is used for the sorting work needs to be bigger than the input -- so to sort a vector you'd still need to create a copy. Given that, you can usually just do the usual (list-vector (sort (vector-list v) )). Thanks Eli. Thats in fact what I'm presently doing. i.e. vector-list Its on a vector of 26000 structs each consisting of 4 numbers and two very short lists of numbers (0-2 or 3 numbers each). Harry _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible 5.2.900.1 bug involving rest argument
Yes, I fixed the bug. The fix should be in the release build tomorrow. Ryan On 07/28/2012 08:28 PM, Robby Findler wrote: I believe Ryan fixed this a few hours ago. He may be waiting for a release build before commenting. Robby On Sat, Jul 28, 2012 at 7:25 PM, Eli Barzilay e...@barzilay.org wrote: 6 hours ago, Neil Van Dyke wrote: Looks like a minor compiler/optimizer bug in Friday's 5.2.900.1 pre-release. I haven't yet found a simpler test case, but you can reproduce by installing a particular PLaneT package as shown below. The line 1275 it's complaining about is the following, which starts a procedure definition that is later applied at toplevel in the same module: (define (charterm-make-keydec keydec-id . keysets) The demo program for this PLaneT package seems to run correctly despite these install/compile-time error messages. I tried to track this, and I don't think that it's a compiler bug... It looks like it's a failure at the stage of compiling the docs which would explain why the code runs fine. The problem looks like something in syntax/parse -- either there or it doesn't do enough checking of its input. A small example that shows it: #lang racket/base (require syntax/parse) (syntax-parse #'(X Y . Z) [(NAME:id ARGn ...) 1] [else 1]) which produces the following error: andmap: contract violation expected: list? given: '(#syntax:/tmp/zzz:5:19 Y . #syntax:/tmp/zzz:5:23 Z) argument position: 2nd other arguments...: #procedure:void context...: /home/scheme/html/release/racket/collects/syntax/parse/private/residual.rkt:206:0: predicate-ellipsis-parser /tmp/zzz: [running body] and the trace that points at synax/parse/private/residual.rkt was there when I tried your original line, so I think that it's the right error. (I'll let Ryan take it from here, I just did a semi-blind tracking...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
I think it should be okay to remove it. All of the functionality is covered by using raco planet. Robby On Sun, Jul 29, 2012 at 2:46 PM, David Bremner brem...@debian.org wrote: Hi All; We're currently trying to figure out the right way to handle a name conflict in Debian between racket and an rss aggregator named planet-venus. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685 I don't use the command /usr/bin/planet myself, so I was wondering if anybody could explain the likely disruption caused by (hypothetically) renaming it. In particular is it likely to be somether where people are using it from scripts or cron jobs, or would making a shell alias (alias planet planet-racket) suffice to avoid retraining fingers? Thanks David _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
