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-s
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
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 _bo
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 a
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 pinw
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
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
>
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 n
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
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
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
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 wh
-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
-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
14 matches
Mail list logo