Re: [racket-dev] [racket] Question about fields in Racket OO
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 a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
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) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.eduwrote: 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 a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
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 wrote: 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) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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 a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
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 fields, but I can't but think of them as closed-over variables. Jay On Thu, Dec 16, 2010 at 7:00 AM, Carl Eastlund c...@ccs.neu.edu wrote: To quote the class* documentation: ( http://docs.racket-lang.org/reference/createclass.html#%28part._clfields%29 ) Each field, init-field, and non-method define-values clause in a class declares one or more new fields for the class. Fields declared with field or init-field are public. So only the public ones are accessible via get-field. Carl Eastlund On Thu, Dec 16, 2010 at 8:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: 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) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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 a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby -- 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
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 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 fields, but I can't but think of them as closed-over variables. Jay On Thu, Dec 16, 2010 at 7:00 AM, Carl Eastlund c...@ccs.neu.edu wrote: To quote the class* documentation: (http://docs.racket-lang.org/reference/createclass.html#%28part._clfields%29) Each field, init-field, and non-method define-values clause in a class declares one or more new fields for the class. Fields declared with field or init-field are public. So only the public ones are accessible via get-field. Carl Eastlund On Thu, Dec 16, 2010 at 8:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: 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) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.edu wrote: 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 a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby -- 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Compile error from DrRacket
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 administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Compile error from DrRacket
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 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 c...@ccs.neu.edu wrote: Er, sorry, I also had a local module called rackunit.rkt, the error message was probably referring to that rather than the rackunit collection. Regardless, I am still wondering whether the compiler is supposed to raise an error or simply recompile the file. Carl Eastlund On Thu, Dec 16, 2010 at 2:48 PM, Carl Eastlund c...@ccs.neu.edu wrote: 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 administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Compile error from DrRacket
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 c...@ccs.neu.edu wrote: Er, sorry, I also had a local module called rackunit.rkt, the error message was probably referring to that rather than the rackunit collection. Regardless, I am still wondering whether the compiler is supposed to raise an error or simply recompile the file. Carl Eastlund On Thu, Dec 16, 2010 at 2:48 PM, Carl Eastlund c...@ccs.neu.edu wrote: 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 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] Question about fields in Racket OO
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 though, I see there is an example in the guide that does set! on an inherited field. Thanks, Mark On Wed, Dec 15, 2010 at 9:53 PM, Robby Findler ro...@eecs.northwestern.eduwrote: set!? Try it in both positions (the commented out one and the other one): the thing to keep in mind is that the declaration in c% is also kind of like a set! that happens when the object is initialized. Robby #lang racket (define c% (class object% (field [f 1]) (define/public (get-f) f) (super-new))) (define d% (class c% (inherit-field f) (set! f 2) (super-new) ; (set! f 2) )) (send (new d%) get-f) On Wed, Dec 15, 2010 at 11:46 PM, Mark Engelberg mark.engelb...@gmail.com wrote: Thanks. That seems to address the shared private issue. So is there a way to give a new value to an inherited field? --Mark On Wed, Dec 15, 2010 at 9:13 PM, Robby Findler ro...@eecs.northwestern.edu wrote: See define-local-member-name. Robby On Wed, Dec 15, 2010 at 10:38 PM, Mark Engelberg mark.engelb...@gmail.com wrote: I'm playing around with the object-oriented subset of Racket, and have a couple of questions. Ideally, I'd like to equip a class with a field that is visible only to it and its subclasses. As far as I can tell, though, this isn't possible. It seems that I have to make a choice between a completely private field visible only to the class (by just using define) or making a completely public field (by using field). Correct? Now, let's say I make the field public. In the subclass, how do I change the default value of field? For example, in the superclass, I might have (field [a 300]) but in the subclass, I want to do something like (inherit-field [a 200]) However, as far as I can tell, the syntax doesn't support anything other than (inherit-field a) Thanks, Mark _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Bug report and complaint: Bitmap drawing and masks
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. You're right that the color should not have mattered. For a non-black color, `draw-bitmap-section' was taking an unnecessary slow path; the slow path turned out to be more correct than the faster path. I've fixed both the unnecessary indirection and the fast path. Next, I complain about some other weird behavior of bitmaps (this behavior has, I think, existed for a long time). In the following example (code at the bottom of this email), I load a black-and-white bitmap (which seems to load as color), then create two bitmaps inside bitmap-dc%s (one monochrome and the other color), draw the original black-and-white bitmap to each of these bitmap-dc%s, and extract the bitmaps from the bitmap-dc%s. Now I have three black-and-white bitmaps that all look identical: the originally loaded one, the monochrome copy, and the color copy. Now I try to use them as masks to draw the valkyrie bitmaps. What happens? The first one works, the second and third don't. Why is this? I investigated and found that, while the pixels of the copies are identical to those of the original (at least, the color copy is identical to the original), the alpha channel is different: the alpha bytes are all 0 on the original, but they're all 255 on both of the copies. Questions/complaints: 1. Why does the alpha channel of a bitmap matter when it's being used as a mask? It turns out that if a bitmap has an alpha channel, then when the bitmap is used as a mask, only its alpha channel is used for masking. That wasn't documented (and it took me a while to remember); I've fixed the docs. While this rule may seem somewhat arbitrary, it works well with the underlying Cairo API. The idea is that if you want to construct a grayscale mask separate from content to draw, it's really better to think in terms of constructing a suitable alpha channel. 2. Why doesn't drawing a bitmap to another one of the same size produce an exact copy of the first? In the case of `u' versus `cu', you're starting with a bitmap that has no alpha channel and drawing into a bitmap that does have an alpha channel. If you add a #f to the call to `make-bitmap' to disable the alpha channel, then you do get the same bitmap for `cu'. (Or, if, say, the second one is monochrome while the first is color, why doesn't it produce the monochrome equivalent of the first? And vice versa.) The result of drawing with `mu' as a mask was broken. The problem was in `draw-bitmap' with a monochrome target bitmap. A monochome bitmap actually has an alpha channel internally, where drawing with black sets the alpha channel to 255 and drawing with white sets it to 255. The `draw-bitmap' operation wasn't preserving that correspondence, and it's now fixed. There was also a bug related to using a color bitmaps as a mask, drawing on it, and then using the bitmap as a mask again. That's also now fixed. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
