Re: [racket-dev] possible 5.2.900.1 bug involving rest argument
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 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: '(# . #) > argument position: 2nd > other arguments...: > # > 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
Re: [racket-dev] possible 5.2.900.1 bug involving rest argument
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: '(# . #) argument position: 2nd other arguments...: # 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
Re: [racket-dev] testing for v5.3
Matthew Flatt writes: > I haven't been able to replicate this crash on a NetBSD 6.0_BETA2 i386 > install. > > Does it crash consistently for you? Did you provide any arguments to > `configure'? Sure. --enable-pthread --prefix=/usr/pkg --build=i486--netbsdelf --mandir=/usr/pkg/man -- HE CE3OH... _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] testing for v5.3
I haven't been able to replicate this crash on a NetBSD 6.0_BETA2 i386 install. Does it crash consistently for you? Did you provide any arguments to `configure'? Thanks! At Wed, 25 Jul 2012 11:55:07 +0400, Aleksej Saushev wrote: > Ryan Culpepper writes: > > > Just a reminder that testing for release v5.3 begins Monday. > > Tests crash on NetBSD 6.0_BETA2 i386: > > 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(numbers) > Section(unsafe) > Section(object) > Section(struct) > Section(unit) > Section(unit/sig) > Section(threads) > Section(logger) > Section(synchronization) > Section(deep) > Section(continuation-marks) > Section(prompt) > Section(wills) > Section(namespaces) > Section(modprot) > Section(chaperones) > Section(parameters) > Section(port) > Section(file) > Section(udp) > Section(file-after-udp) > Section(path) > Section(optimization) > Seg fault (internal error) at 0x96ee31a4 > > Backtrace: > > Core was generated by `racket3m'. > Program terminated with signal 6, Aborted. > #0 0xbbb94f37 in _lwp_kill () from /usr/lib/libc.so.12 > #0 0xbbb94f37 in _lwp_kill () from /usr/lib/libc.so.12 > #1 0xbbb94ef3 in raise () from /usr/lib/libc.so.12 > #2 0xbbb946dd in abort () from /usr/lib/libc.so.12 > #3 0x082111b7 in fault_handler () > #4 > #5 0x081be156 in chaperone_struct_ref () > #6 0x08178e02 in setup_graph_table () > #7 0x08178d54 in setup_graph_table () > #8 0x08178e19 in setup_graph_table () > #9 0x08178e19 in setup_graph_table () > #10 0x08178e19 in setup_graph_table () > #11 0x0817edb4 in print_to_string () > #12 0x0817f4d5 in print_to_port () > #13 0x0817f582 in scheme_internal_write () > #14 0x081748e9 in display_write () > #15 0x08085e22 in scheme_do_eval () > #16 0x081b5e45 in scheme_do_format () > #17 0x081b63cd in sch_printf () > #18 0xbba6cfdc in ?? () > #19 0xbba82080 in ?? () > #20 0x08086154 in scheme_do_eval () > #21 0x080950b2 in finish_apply_with_prompt () > #22 0x08084e8a in scheme_do_eval () > #23 0x080a368f in scheme_finish_apply_for_prompt () > #24 0x080a37cb in scheme_apply_for_prompt () > #25 0x080a6fcb in call_with_prompt () > #26 0x08085e22 in scheme_do_eval () > #27 0x0809c069 in do_call_with_prompt () > #28 0x080a396a in do_apply_with_prompt () > #29 0x0816e9b3 in do_load_handler () > #30 0x080a4ef6 in scheme_dynamic_wind () > #31 0x0816e539 in default_load () > #32 0x08085e22 in scheme_do_eval () > #33 0x08175a79 in scheme_load_with_clrd () > #34 0x08175abe in load () > #35 0xbba89532 in ?? () > #36 0x08086154 in scheme_do_eval () > #37 0x080950b2 in finish_apply_with_prompt () > #38 0x08084e8a in scheme_do_eval () > #39 0x080a368f in scheme_finish_apply_for_prompt () > #40 0x080a37cb in scheme_apply_for_prompt () > #41 0x080a6fcb in call_with_prompt () > #42 0x08085e22 in scheme_do_eval () > #43 0x0809c069 in do_call_with_prompt () > #44 0x080a396a in do_apply_with_prompt () > #45 0x0816e9b3 in do_load_handler () > #46 0x080a4ef6 in scheme_dynamic_wind () > #47 0x0816e539 in default_load () > #48 0x08085e22 in scheme_do_eval () > #49 0x08175a79 in scheme_load_with_clrd () > #50 0x08175abe in load () > #51 0xbba89532 in ?? () > #52 0x08086154 in scheme_do_eval () > #53 0x080950b2 in finish_apply_with_prompt () > #54 0x08084e8a in scheme_do_eval () > #55 0x080a368f in scheme_finish_apply_for_prompt () > #56 0x080a37cb in scheme_apply_for_prompt () > #57 0x080a6fcb in call_with_prompt () > #58 0x08085e22 in scheme_do_eval () > #59 0x0809c069 in do_call_with_prompt () > #60 0x080a396a in do_apply_with_prompt () > #61 0x0816e9b3 in do_load_handler () > #62 0x080a4ef6 in scheme_dynamic_wind () > #63 0x0816e539 in default_load () > #64 0x08085e22 in scheme_do_eval () > #65 0x08175a79 in scheme_load_with_clrd () > #66 0x08175abe in load () > #67 0xbba89532 in ?? () > #68 0xbba82860 in ?? () > #69 0xbba8955f in ?? () > #70 0x08087e12 in _scheme_apply_multi_from_native () > #71 0xbba89503 in ?? () > #72 0x08086154 in scheme_do_eval () > #73 0x080a368f in scheme_finish_apply_for_prompt () > #74 0x080a37cb in scheme_apply_for_prompt () > #75 0x080a6fcb in call_with_prompt () > #76 0x08085e22 in scheme_do_eval () > #77 0x0808598a in scheme_do_eval () > #78 0x080950b2 in finish_apply_with_prompt () > #79 0x08084e8a in scheme_do_eval () > #80 0x080a368f in scheme_finish_apply_for_prompt () > #81 0x080a37cb in scheme_apply_for_prompt () > #82 0x080a6fcb in call_with_prompt () > #83 0x08085e22 in scheme_do_eval () > #84 0x0809c069 in do_call_with_prompt () > #85 0x080a396a in do_apply_with_prompt () > #86 0x0816e9b3 in do_load_handler () > #87 0x080a4ef6 in scheme_dynamic_wind () > #88 0x0816e539 in default_load () > #89 0x08085e22 in scheme_do_eval () > #90 0x08175a79 in scheme_load_with_clrd () > #91 0x08175abe in load () > #92 0x08085e22 in scheme_do_eval () > #93 0x0809516a in apply_k () > #9
Re: [racket-dev] Racket 5.3 pre-release impressions?
I've tried all of my packages and had one major snag that Matthew thinks he has fixed. For my large simulations, it seems to execute faster, but that is just an impression. Many of them are actually constrained by quick and dirty plots that may be rendering tens or hundreds of thousands of points. Doug On Sat, Jul 28, 2012 at 12:56 PM, Neil Van Dyke wrote: > Regarding Racket 5.3, I am more cautious than I recall being about a > previous Racket minor version release. > > The information I have so far is mixed, rather that overwhelmingly > reassuring. > > If anyone has comments on their sense of 5.3 reliability at this point, that > might help me. > > Some good news: one of my consulting clients had me do some preliminary > testing of their large code base with the Racket 5.3 pre-release, and there > has been no problem with that testing so far. > > However, in testing 5.3 pre-releases with my personally-owned code, rather > than clients' code, so far I've found what looks like 2 bugs in the 5.3 > pre-release. This was surprising to me, since I expected 0 bugs. I have > not yet tried the majority of my personally-owned code. > > Until I get a better sense, I would expect to keep production servers at > 5.2.1 for a while after the 5.3 release. I'm also probably going to go to > some trouble to avoid using new 5.3 features in some code that might be > deployed to production in the very near term. > > More information might be reassuring to me. > > Neil V. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.3 pre-release impressions?
FWIW, I just tested 16 or so additional PLaneT packages in DrRacket 5.3 pre-release, and no problems. Neil Van Dyke wrote at 07/28/2012 02:56 PM: Regarding Racket 5.3, I am more cautious than I recall being about a previous Racket minor version release. The information I have so far is mixed, rather that overwhelmingly reassuring. If anyone has comments on their sense of 5.3 reliability at this point, that might help me. Some good news: one of my consulting clients had me do some preliminary testing of their large code base with the Racket 5.3 pre-release, and there has been no problem with that testing so far. However, in testing 5.3 pre-releases with my personally-owned code, rather than clients' code, so far I've found what looks like 2 bugs in the 5.3 pre-release. This was surprising to me, since I expected 0 bugs. I have not yet tried the majority of my personally-owned code. Until I get a better sense, I would expect to keep production servers at 5.2.1 for a while after the 5.3 release. I'm also probably going to go to some trouble to avoid using new 5.3 features in some code that might be deployed to production in the very near term. More information might be reassuring to me. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket 5.3 pre-release impressions?
Regarding Racket 5.3, I am more cautious than I recall being about a previous Racket minor version release. The information I have so far is mixed, rather that overwhelmingly reassuring. If anyone has comments on their sense of 5.3 reliability at this point, that might help me. Some good news: one of my consulting clients had me do some preliminary testing of their large code base with the Racket 5.3 pre-release, and there has been no problem with that testing so far. However, in testing 5.3 pre-releases with my personally-owned code, rather than clients' code, so far I've found what looks like 2 bugs in the 5.3 pre-release. This was surprising to me, since I expected 0 bugs. I have not yet tried the majority of my personally-owned code. Until I get a better sense, I would expect to keep production servers at 5.2.1 for a while after the 5.3 release. I'm also probably going to go to some trouble to avoid using new 5.3 features in some code that might be deployed to production in the very near term. More information might be reassuring to me. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] possible 5.2.900.1 bug involving rest argument
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. Racket 5.2.1 does not give these install/compile-time errors, as is also shown below. $ /usr/local/racket-5.2.900.1-20120727/bin/raco planet remove neil charterm.plt 3 0 [...] $ /usr/local/racket-5.2.900.1-20120727/bin/racket -p neil/charterm:3:=0 andmap: contract violation expected: list? given: '(#keydec-id> . #keysets>) argument position: 2nd other arguments...: # andmap: contract violation expected: list? given: '(#keydec-id> . #keysets>) argument position: 2nd other arguments...: # raco setup: error: during making for /neil/charterm.plt/3/0 (CharTerm) raco setup: andmap: contract violation raco setup: expected: list? raco setup: given: '(#keydec-id> . #keysets>) raco setup: argument position: 2nd raco setup: other arguments...: raco setup: # raco setup: error: during Building docs for /home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/doc.scrbl raco setup: andmap: contract violation raco setup: expected: list? raco setup: given: '(#keydec-id> . #keysets>) raco setup: argument position: 2nd raco setup: other arguments...: raco setup: # $ $ /usr/local/racket-5.2.1/bin/raco planet remove neil charterm.plt 3 0 [...] $ /usr/local/racket-5.2.1/bin/racket -p neil/charterm:3:=0 [...no output...] $ Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3
It was working on the same machine the next day. So, it may have been a cache issue or some other transient. On Saturday, July 28, 2012, Eli Barzilay wrote: > Is it possible that this is something that is resolved by a forced > refresh? if not, what's tthe url is not found? > > > On Wednesday, Doug Williams wrote: > > The download page still failed with the same error. The static page > > worked fine. > > > > On Wed, Jul 25, 2012 at 8:24 AM, Ryan Culpepper > > > > wrote: > > > I just tried downloading the Racket package for Windows (x86, > > > 64-bit), and it worked for me. Can you try again and let me know > > > if it still fails? Also, if you can't download from the form, can > > > you try the "static table" link (just under the usual download > > > form, on the right side) and see if you can download it from the > > > link on that page? > > > > > > On 07/25/2012 10:05 AM, Doug Williams wrote: > > >> > > >> Attempting to download the 64 bit windows version gives a Page > > >> Not-Found error and the following. > > -- > ((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] racket-5.2.900.1-20120725 read ill-formed code error ?
Matthew Flatt wrote at 07/26/2012 06:36 PM: I've pushed a repair. Thanks for the report! Thanks, Matthew. Today, I plan to run a large pile of code through the 20120727 pre-release. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3
Is it possible that this is something that is resolved by a forced refresh? if not, what's tthe url is not found? On Wednesday, Doug Williams wrote: > The download page still failed with the same error. The static page > worked fine. > > On Wed, Jul 25, 2012 at 8:24 AM, Ryan Culpepper wrote: > > I just tried downloading the Racket package for Windows (x86, > > 64-bit), and it worked for me. Can you try again and let me know > > if it still fails? Also, if you can't download from the form, can > > you try the "static table" link (just under the usual download > > form, on the right side) and see if you can download it from the > > link on that page? > > > > On 07/25/2012 10:05 AM, Doug Williams wrote: > >> > >> Attempting to download the 64 bit windows version gives a Page > >> Not-Found error and the following. -- ((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
