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
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 wrote: > 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 > 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 > >> 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] Compile error from DrRacket
Sounds like DrRacket should delete the .zo file (from its cache, at least) in that case. I've pushed a change that does that. Do let me know if you see problems now. Thanks, Robby On Thu, Dec 16, 2010 at 2:10 PM, Carl Eastlund wrote: > 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 > 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 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 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 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 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] 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 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 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 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
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 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
[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] [racket] Question about fields in Racket OO
At Thu, 16 Dec 2010 07:08:11 -0700, Jay McCarthy 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, Not directly. They are accessible in methods via an implicit `this'. > so I don't see in what sense they are "fields". The example (define o (new (class object% (super-new) (define x (gensym) is analogous to (define o (let () (struct s (x)) (s (gensym In both cases, the `x' field is unused and inaccessible, but the generated symbol is retained as long as `o' is reachable. Both of those are different than (define o (let () (define x (gensym)) (lambda () 10))) where `x' could have been referenced by the `lambda' form, but since it isn't, nothing retains `x'. You could image trying to implement private fields as local bindings that are captured by method closures. That means, though, that you have to create separate method closures for each object --- which is the bad old class system. _ 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 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 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 >> 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 >> > >> > wrote: >> >> >> >> On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg >> >> 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 > 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] 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 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 > 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 > >> 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 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] 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 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 > wrote: >> >> On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg >> 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 > 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] Question about fields in Racket OO
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 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 > wrote: >> >> On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg >> 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 wrote: > On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg > 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 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] Question about fields in Racket OO
On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg 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
