Re: [racket-dev] creating executables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/11 10:03, Marijn wrote: > Hi Vincent, > > On 09/02/11 19:33, Vincent St-Amour wrote: >> At Fri, 02 Sep 2011 09:15:20 +0200, Marijn wrote: >>> I just tried with latest git and nothing has changed for me. >>> Neither the wrong message, nor the failing executable. > >> You're building executables from DrRacket, right? > >> Does it work if you build them from the command-line, with `raco >> exe'? > >> Vincent > > No, it doesn't work either: > > $ cat hello.rkt #lang racket > > (print "hello") $ raco exe -o hello hello.rkt $ ./hello read failed > to read all 885871033 bytes from file > /home/marijn/racketzooi/./hello Aborted The above bug is still manifested in today's git. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zD/EACgkQp/VmCx0OL2x/WQCghFgPgeOSEbk3PtVuYyHHAgJI q4cAoIfLXgXIKanGJ3DZ9VDsQBaOO/f+ =UzdE -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] list-box% not properly sized
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/11 11:16, Marijn wrote: > Hi Matthew, > > On 09/01/11 10:31, Marijn wrote: >> Hi list, >> >> list-box%es are not properly sized; the following code: > > I think you pushed a patch to change this. Currently the list-box > as coded below has a minimum size of three items. Unfortunately the > scroll bar seems to have a minimum size which is unusably large. > There are 8 items in the list, but only 3 are shown and the scroll > bar at ~99% size and only serves to scroll to the last 3 items. > Scrolling back up doesn't work (the small ^ and v seem to work > fine). With today's git checkout it works fine, so thanks to whoever fixed it. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zELAACgkQp/VmCx0OL2y6JACfcssE7KpbeRbNfYziSG/0SWPQ 4XoAoKK+UUFCZfz7nqQGynU7/Ipiv8Lz =S9zU -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Racket docs and data-driven design
I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, "So why doesn't the Racket language Web site agree with you?" http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for "[else".) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
The same is true of HtDP: http://htdp.org/2003-09-26/Book/curriculum-Z-H-13.html#node_chap_9 and HtDP 2e: http://www.ccs.neu.edu/home/matthias/HtDP2e/htdp2e-part2.html . (search for "[else" in a similar way). On Fri, Sep 16, 2011 at 11:52 AM, Shriram Krishnamurthi wrote: > I introduced templates today. Almost as if on cue, one student asked > whether he could use else instead of (cons? l). I told them I was > going to make a MORAL judgment about why it was EVIL, and spent ten > minutes talking about all that. > > As class ended, one of my students came up and said, > > "So why doesn't the Racket language Web site agree with you?" > > http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html > > (Look for "[else".) > > Shriram > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
Why is else evil? I can see how it might be pragmatic to avoid it in a language without contracts, but I'm having trouble seeing evil. Robby On Fri, Sep 16, 2011 at 10:52 AM, Shriram Krishnamurthi wrote: > I introduced templates today. Almost as if on cue, one student asked > whether he could use else instead of (cons? l). I told them I was > going to make a MORAL judgment about why it was EVIL, and spent ten > minutes talking about all that. > > As class ended, one of my students came up and said, > > "So why doesn't the Racket language Web site agree with you?" > > http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html > > (Look for "[else".) > > Shriram > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
I don't like it either because it makes the function a contract violator: (define (listy l) (cond [(empty? l) ...] [else ... (first l) ...])) (define (f x) ... (listy 5) ...) f breaks listy's contract, but it goes undetected in most of Racket and all of HtDP and listy gets blamed for breaking first's contract. A student sees an error message about first, not listy. If you had [(cons? ...) ...], then you'd get "all questions were false" inside listy, which is nicer. I understand that signatures are meant to solve this, but they aren't part of HtDP yet. On the other hand, if the contracts are there, I like else because each cond eliminates one variant and there is finally just one variant left. (Note: I only like this if it is unlikely I will add more variants. I dislike that type-case from PLAI has else, for example.) Jay On Fri, Sep 16, 2011 at 10:13 AM, Robby Findler wrote: > Why is else evil? I can see how it might be pragmatic to avoid it in a > language without contracts, but I'm having trouble seeing evil. > > Robby > > On Fri, Sep 16, 2011 at 10:52 AM, Shriram Krishnamurthi > wrote: >> I introduced templates today. Almost as if on cue, one student asked >> whether he could use else instead of (cons? l). I told them I was >> going to make a MORAL judgment about why it was EVIL, and spent ten >> minutes talking about all that. >> >> As class ended, one of my students came up and said, >> >> "So why doesn't the Racket language Web site agree with you?" >> >> http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html >> >> (Look for "[else".) >> >> Shriram >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
In addition to what Jay said, when the datatype evolves, it's harder for someone reading the code to tell whether the "else" was meant to cover only one other case (and now there's two, and someone forgot to update the function) or truly all the other cases. When you have crisp predicates, I see no excuse for using else -- it's intellectually sloppy and causes both missed early-errors (as Jay shows) and later pain. For really complex predicates, it makes sense: (cond [(prime (foo (bar x))) ...] [else ...]) offers many advantages over (cond [(prime (foo (bar x))) ...] [(not (prime (foo (bar x ...]) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
I admit sloppiness. On Sep 16, 2011, at 12:49 PM, Shriram Krishnamurthi wrote: > In addition to what Jay said, when the datatype evolves, it's harder > for someone reading the code to tell whether the "else" was meant to > cover only one other case (and now there's two, and someone forgot to > update the function) or truly all the other cases. > > When you have crisp predicates, I see no excuse for using else -- it's > intellectually sloppy and causes both missed early-errors (as Jay > shows) and later pain. For really complex predicates, it makes sense: > > (cond > [(prime (foo (bar x))) ...] > [else ...]) > > offers many advantages over > > (cond > [(prime (foo (bar x))) ...] > [(not (prime (foo (bar x ...]) > > Shriram > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] online check syntax: now disabled by default
On Thu, Sep 15, 2011 at 8:13 PM, Robby Findler wrote: > Yes, certainly! Core files (or just stack traces) are useful, I expect. > I've been seeing a freeze roughly once a day. DrRacket gets permanently stuck with the OS X rainbow pinwheel as the cursor, and SIGKILLs won't kill it. I have to hard reboot. It eventually occurred to me to run DrRacket out of a terminal to look for interesting output, and sure enough, it's a segfault. I have a core dump, but I'm not getting a useful stacktrace. I'm not sure if it's because the stack is corrupt or because I'm using gdb wrong. I did this: $ gdb path/to/drracket /cores/core.221 saw this message: This GDB was configured as "i386-apple-darwin"..."/Users/clklein/git/new-redex-semantics/bin/drracket": not in executable format: File format not recognized then a bunch of messages like this one: warning: Could not find object file "/Users/mflatt/tmp/newest-libs/pixman-0.21.6/pixman/.libs/pixman-access.o" - no debug information available for "pixman-access.c". and eventually the gdb prompt. The backtrace command shows the following: #0 scheme_set_cont_mark (key=Cannot access memory at address 0xbfffb9a0 ) at eval.c:993 Cannot access memory at address 0xbfffb99c Let me know if I can provide any more information. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] online check syntax: now disabled by default
On 2011-09-16 14:49:12 -0500, Casey Klein wrote: > On Thu, Sep 15, 2011 at 8:13 PM, Robby Findler > wrote: > > Yes, certainly! Core files (or just stack traces) are useful, I expect. > > > > I've been seeing a freeze roughly once a day. DrRacket gets > permanently stuck with the OS X rainbow pinwheel as the cursor, and > SIGKILLs won't kill it. I have to hard reboot. FWIW, I've had segfaults on Linux recently as well so it's not just OS X. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] online check syntax: now disabled by default
Two hours ago, Casey Klein wrote: > > I did this: > > $ gdb path/to/drracket /cores/core.221 > > saw this message: > > This GDB was configured as > "i386-apple-darwin"..."/Users/clklein/git/new-redex-semantics/bin/drracket": > not in executable format: File format not recognized You need the actual binary executable there, not the wrapper script. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] foreign struct access different in 5.1.3?
I'm trying to backport working FFI code to 5.1.3, and I'm having trouble referring to elements of a C struct. Specifically, in the presence of this definition (define-cstruct _rack-audio-closure ([sound _pointer] [cur-sample_ulong] [num-samples _ulong] [stop-now _bool] [stop-sema-ptr _pointer])) using the function (rack-audio-closure-cur-sample) on the result of an FFI call with signature (_fun _pointer _ulong _pointer -> _rack-audio-closure-pointer) produces this error: rack-audio-closure-cur-sample: expected argument of type ; given # in 5.1.3, but it works just fine in the git head. Git log suggests to me that you (Kevin) might have changed/fixed this in a810b30b872787a1365c, so here's the question: is there some workaround to access the elements of a C struct in 5.1.3? Many thanks, John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] online check syntax: now disabled by default
On Fri, Sep 16, 2011 at 4:37 PM, Eli Barzilay wrote: > Two hours ago, Casey Klein wrote: >> >> I did this: >> >> $ gdb path/to/drracket /cores/core.221 >> >> saw this message: >> >> This GDB was configured as >> "i386-apple-darwin"..."/Users/clklein/git/new-redex-semantics/bin/drracket": >> not in executable format: File format not recognized > > You need the actual binary executable there, not the wrapper script. > Oh, good to know! I still get the same stack trace when I provide the actual executable. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] foreign struct access different in 5.1.3?
On Sep 16, 2011, at 3:06 PM, John Clements wrote: > I'm trying to backport working FFI code to 5.1.3, and I'm having trouble > referring to elements of a C struct. Specifically, in the presence of this > definition > > (define-cstruct _rack-audio-closure > ([sound _pointer] > [cur-sample_ulong] > [num-samples _ulong] > [stop-now _bool] > [stop-sema-ptr _pointer])) > > using the function (rack-audio-closure-cur-sample) on the result of an FFI > call with signature > > (_fun _pointer _ulong _pointer -> _rack-audio-closure-pointer) > > produces this error: > > rack-audio-closure-cur-sample: expected argument of type > ; given # > > in 5.1.3, but it works just fine in the git head. More research suggests that the problem is more limited; it looks like a problem of generativity. That is, if I have two modules that declare the "same" cstruct (same name, same fields, same types) then cpointers to these structures returned by functions from the first module cannot be accessed in the other module. AFAICT, This is not the case in more recent versions; that is, these cstructs are not generative. Assuming this is deliberate, I could document it. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
