On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg
mark.engelb...@gmail.com wrote:
OK, it works when the set! occurs after the super-new. I didn't think set!
would work at all in a class definition (as opposed to within a method); I
was thinking of the whole system of defining classes as more of
Does 'define' really mean 'make a field'? I thought fields had to be
specially designated so that get-field would know about them...
Yes, this program errors:
#lang racket
(define c%
(class* object% ()
(field [x 1])
(define y 2)
(super-new)))
(define o (new c%))
(field-names o)
Yes, sorry -- define is for private fields, not public ones.
(This is something that can easily trip people up, ie making fields
when they really want to be making methods; but I don't have a good
idea of how to fix it.)
Robby
On Thu, Dec 16, 2010 at 7:56 AM, Jay McCarthy jay.mccar...@gmail.com
This seems like a trivial point because the class system doesn't have to
track these things and they are in fact part of the closures of the methods,
so I don't see in what sense they are fields. Perhaps I am blinded by my
reading of the implementation. I certainly agree they are essentially
There is one field per object, but one method (closure) per class.
Otherwise, you're right; and that's just what fields are. :)
Robby
On Thu, Dec 16, 2010 at 8:08 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
This seems like a trivial point because the class system doesn't have to
track these
DrRacket 5.0.2 gave me this error in a program using rackunit:
compiled/drracket/errortrace/rackunit_rkt.zo:1:0: read (compiled):
code compiled for version 5.0.1, not 5.0.2
Is this a bug or a feature?
Carl Eastlund
_
For list-related
Ah ha, I have figured out the problem. I had the .zo file, but *not*
the original .rkt file, so there was nothing for DrRacket to
recompile. Sorry for the false alarm!
Carl Eastlund
On Thu, Dec 16, 2010 at 3:05 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
That shouldn't happen, since
That shouldn't happen, since that is a file created by DrRacket for
its own compilation thingy and when those are created either they are
ignored or they are brought up to date. I don't suppose you can make
this happen on command?
Robby
On Thu, Dec 16, 2010 at 1:51 PM, Carl Eastlund
OK, it works when the set! occurs after the super-new. I didn't think set!
would work at all in a class definition (as opposed to within a method); I
was thinking of the whole system of defining classes as more of a
declarative DSL that only allowed certain constructs.
Now that you point it out
Thanks for the bug reports! I've pushed some fixes to the repo -- more
details and answers below.
At Tue, 14 Dec 2010 20:46:27 -0800, John Boyle wrote:
Problem: The dc% method 'draw-bitmap-section disregards the boundaries of
the drawing section when the 'color argument is the color black.
10 matches
Mail list logo
