Hi
RC2 is out with: - fix squeakmap - fix toggle - pragmas fixes - duplicate halos I hope to get soon some fix for compiledMethod class and we can go final. Stef |
On Oct 13, 2006, at 15:01, stephane ducasse wrote: > Hi > > RC2 is out with: > - fix squeakmap > - fix toggle > - pragmas fixes > - duplicate halos > > I hope to get soon some fix for compiledMethod class and we can go > final. > > Stef > > I just loaded RC2 and when I run SqueakMap I get an error. It's in SMSqueakMap>>categories, instance var objects is undefined. Anyone else this is happening to? ------------------------ Frank Caggiano frankcag at crystal-objects dot com http://www.crystal-objects.com The best education for the best is the best education for all. Robert Maynard Hutchins |
Frank Caggiano a écrit :
> > On Oct 13, 2006, at 15:01, stephane ducasse wrote: > >> Hi >> >> RC2 is out with: >> - fix squeakmap >> - fix toggle >> - pragmas fixes >> - duplicate halos >> >> I hope to get soon some fix for compiledMethod class and we can go final. >> >> Stef >> >> > > I just loaded RC2 and when I run SqueakMap I get an error. It's in > SMSqueakMap>>categories, instance var objects is undefined. > > Anyone else this is happening to? No for me evrything is ok. Thanks a lote Marcus and Steph :) Math |
In reply to this post by stephane ducasse-2
Stef,
I just grabbed 7063 and the current win32 VM, and opened the image. Something is not right with the system window stripe coloring. The active state is somehow not following the keyboard focus. Click in the various workspaces and you should see what I mean. If it is a corrupt instance, I would start looking at the lower right workspace, but that is simply a hunch. One could argue that the lower right workspace appears not to deactivate??? As a related aside, I still recommend flipping the #isActive tests (e.g. appending #not) in #setStripeColorsFrom:. Try it (see below) for a few minutes and I suspect you will see what I mean - suddenly the active window is "stronger" than the inactive ones. Bill setStripeColorsFrom: paneColor "Set the stripe color based on the given paneColor" labelArea ifNotNil: [labelArea color: Color transparent]. self updateBoxesColor: (self isActive not ifTrue: [paneColor] ifFalse: [paneColor muchDarker]). stripes ifNil: [^self]. self isActive not ifTrue: [self fillStyle: (self gradientWithColor: paneColor lighter lighter lighter)] ifFalse: ["This could be much faster" self fillStyle: (self gradientWithColor: paneColor duller)]. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
On 14 oct. 06, at 17:13, Bill Schwab wrote: > Stef, > > I just grabbed 7063 and the current win32 VM, and opened the image. > Something is not right with the system window stripe coloring. The > active state is somehow not following the keyboard focus. Click in > the > various workspaces and you should see what I mean. If it is a corrupt > instance, I would start looking at the lower right workspace, but that > is simply a hunch. One could argue that the lower right workspace > appears not to deactivate??? I do not understand where it comes from. On mac I have the correct behavior or I think I see it. ;) > As a related aside, I still recommend flipping the #isActive tests > (e.g. > appending #not) in #setStripeColorsFrom:. Try it (see below) for a > few > minutes and I suspect you will see what I mean - suddenly the active > window is "stronger" than the inactive ones. This is strange because I get no difference. The topmost is the brightest. Stef > > Bill > > > > setStripeColorsFrom: paneColor > "Set the stripe color based on the given paneColor" > > labelArea ifNotNil: [labelArea color: Color transparent]. > self updateBoxesColor: (self isActive not > ifTrue: [paneColor] > ifFalse: [paneColor muchDarker]). > stripes ifNil: [^self]. > self isActive not > ifTrue: [self fillStyle: (self gradientWithColor: > paneColor lighter lighter lighter)] > ifFalse: ["This could be much faster" > self fillStyle: (self gradientWithColor: > paneColor duller)]. > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: [hidden email] > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > |
In reply to this post by stephane ducasse-2
Stef,
=============================== > I just grabbed 7063 and the current win32 VM, and opened the image. > Something is not right with the system window stripe coloring. The > active state is somehow not following the keyboard focus. Click in > the > various workspaces and you should see what I mean. If it is a corrupt > instance, I would start looking at the lower right workspace, but that > is simply a hunch. One could argue that the lower right workspace > appears not to deactivate??? I do not understand where it comes from. On mac I have the correct behavior or I think I see it. ;) =============================== With the downloaded image, just alternately click between the bottom two workspaces. I am seeing no change in their stripe coloring, suggesting that something is not respecting and/or representing its active/inactive status. =============================== > As a related aside, I still recommend flipping the #isActive tests > (e.g. > appending #not) in #setStripeColorsFrom:. Try it (see below) for a > few > minutes and I suspect you will see what I mean - suddenly the active > window is "stronger" than the inactive ones. This is strange because I get no difference. The topmost is the brightest. =============================== Note that you will need to activate each system window in turn to see the effects. The inactive views will then have lighter stripes, but I maintain that it is much more intuitive that the darker/stronger valued stripe belongs to the active window. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
In reply to this post by Schwab,Wilhelm K
Bill Schwab wrote:
> I just grabbed 7063 and the current win32 VM, and opened the image. > Something is not right with the system window stripe coloring. The > active state is somehow not following the keyboard focus. Click in the > various workspaces and you should see what I mean. If it is a corrupt > instance, I would start looking at the lower right workspace, but that > is simply a hunch. One could argue that the lower right workspace > appears not to deactivate??? The image was saved in a funny state. The lower right window wasn't correctly deactivated. No idea how this happened but to fix it, click on the window title instead of the text in it. Once you've done it, everything should be fine. On a related note: I noticed that activating the top-window takes about a second or so which is due to the absence of the true-type caching fix that I wrote about a year ago (http://impara.de/pipermail/tweak/2005-August/000881.html). See also http://bugs.impara.de/view.php?id=5233 Cheers, - Andreas |
Hi andreas
where is the code? How can we put it in squeak if this is not visible for us? I thought you were the maintainer of Graphics so that you would include it in there. Stef On 14 oct. 06, at 20:57, Andreas Raab wrote: > Bill Schwab wrote: >> I just grabbed 7063 and the current win32 VM, and opened the >> image. Something is not right with the system window stripe >> coloring. The >> active state is somehow not following the keyboard focus. Click >> in the >> various workspaces and you should see what I mean. If it is a >> corrupt >> instance, I would start looking at the lower right workspace, but >> that >> is simply a hunch. One could argue that the lower right workspace >> appears not to deactivate??? > > The image was saved in a funny state. The lower right window wasn't > correctly deactivated. No idea how this happened but to fix it, > click on the window title instead of the text in it. Once you've > done it, everything should be fine. > > On a related note: I noticed that activating the top-window takes > about a second or so which is due to the absence of the true-type > caching fix that I wrote about a year ago (http://impara.de/ > pipermail/tweak/2005-August/000881.html). See also http:// > bugs.impara.de/view.php?id=5233 > > Cheers, > - Andreas > |
stephane ducasse wrote:
> where is the code? How can we put it in squeak if this is not visible > for us? > I thought you were the maintainer of Graphics so that you would include > it in there. Please do me a favor and at least have a peek at the reference I give. I don't do it for my own good. This bug report explains the problem. http://bugs.impara.de/view.php?id=5233 TTCFont and friends are in Multilingual, not Graphics. In other words, I can't touch them. Cheers, - Andreas |
On 15 oct. 06, at 10:08, Andreas Raab wrote: > stephane ducasse wrote: >> where is the code? How can we put it in squeak if this is not >> visible for us? >> I thought you were the maintainer of Graphics so that you would >> include it in there. > > Please do me a favor and at least have a peek at the reference I give. I look at it but it was not on mantis and I'm on the tweak mailing-list. > I don't do it for my own good. This bug report explains the problem. > > http://bugs.impara.de/view.php?id=5233 > > TTCFont and friends are in Multilingual, not Graphics. In other > words, I can't touch them. But if I follow your usual rant "us stupid harvesters do not understand what are package maintainers", we could not move anything to the graphics package either because you are the maintainer of it. So instead of ranting on our stupid practices, if you could admit that a bit of communication and synchronization are necessary in the process and that with the merge mechanism of MC we can publish items in a package and that the maintainer of the package can merge it back (and possibly reject the changes) because else we are stuck. So now concretely how do we proceed for this changes? Because you could have done it also, published two new versions of the packages and notify us. I do not know who is maintaining the package multilangual. So we can do it if the code works because we are in ReleaseCandidate status and this is taking far too much time so we could also postpone it to 3.10. Stef |
Hi Stef -
By now I *really* want you off the helm for any future Squeak release. Your behavior of insulting *every last person* who finds any shortcoming in 3.9 is just unworthy. I find a problem, I post a fix (without btw, requesting any immediate action like including this in the current release) I explain what the deeper problem is and request resolution by filing a bug and you call me ranting? I'm sorry, but in this kind of atmosphere I really have no interest in contributing. Consider my fix withdrawn. Cheers, - Andreas stephane ducasse wrote: > > On 15 oct. 06, at 10:08, Andreas Raab wrote: > >> stephane ducasse wrote: >>> where is the code? How can we put it in squeak if this is not visible >>> for us? >>> I thought you were the maintainer of Graphics so that you would >>> include it in there. >> >> Please do me a favor and at least have a peek at the reference I give. > > I look at it but it was not on mantis and I'm on the tweak mailing-list. > >> I don't do it for my own good. This bug report explains the problem. >> >> http://bugs.impara.de/view.php?id=5233 >> >> TTCFont and friends are in Multilingual, not Graphics. In other words, >> I can't touch them. > > But if I follow your usual rant "us stupid harvesters do not understand > what are package maintainers", we > could not move anything to the graphics package either because you are > the maintainer of it. > > So instead of ranting on our stupid practices, if you could admit that a > bit of communication and synchronization > are necessary in the process and that with the merge mechanism of MC we > can publish items in a package and that the > maintainer of the package can merge it back (and possibly reject the > changes) because else we are stuck. > > So now concretely how do we proceed for this changes? > Because you could have done it also, published two new versions of the > packages and notify us. > I do not know who is maintaining the package multilangual. So we can do > it if the code works because we are in ReleaseCandidate > status and this is taking far too much time so we could also postpone it > to 3.10. > > Stef > > > > > > |
hi andreas
Come on you systematically mentioned that we were not respecting package maintainer... Do you want that I really lose time to go in your emails to show that to you? Of course this should be us that do not understand. > Hi Stef - > > By now I *really* want you off the helm for any future Squeak > release. Your behavior of insulting *every last person* who finds > any shortcoming in 3.9 is just unworthy. I'm not! I think that you over reacted. For once this is not me. We are just in release candidate 2. We got in Gamma for at least some months. So we should stop. I was just showing to you that your statement that we should not publish code in packages that has a maintainer leads to a deadlock. Because you cannot touch multilnagual and we cannot touch graphics. > I find a problem, I post a fix (without btw, requesting any > immediate action like including this in the current release) I > explain what the deeper problem is and request resolution by filing > a bug and you call me ranting? Not in this email. I was referring to some previous ones but not this one. :) > > I'm sorry, but in this kind of atmosphere I really have no interest > in contributing. Consider my fix withdrawn. Cool. This is the perfect attitude! Quite constructive. > > Cheers, > - Andreas > > > stephane ducasse wrote: >> On 15 oct. 06, at 10:08, Andreas Raab wrote: >>> stephane ducasse wrote: >>>> where is the code? How can we put it in squeak if this is not >>>> visible for us? >>>> I thought you were the maintainer of Graphics so that you would >>>> include it in there. >>> >>> Please do me a favor and at least have a peek at the reference I >>> give. >> I look at it but it was not on mantis and I'm on the tweak mailing- >> list. >>> I don't do it for my own good. This bug report explains the problem. >>> >>> http://bugs.impara.de/view.php?id=5233 >>> >>> TTCFont and friends are in Multilingual, not Graphics. In other >>> words, I can't touch them. >> But if I follow your usual rant "us stupid harvesters do not >> understand what are package maintainers", we >> could not move anything to the graphics package either because you >> are the maintainer of it. >> So instead of ranting on our stupid practices, if you could admit >> that a bit of communication and synchronization >> are necessary in the process and that with the merge mechanism of >> MC we can publish items in a package and that the >> maintainer of the package can merge it back (and possibly reject >> the changes) because else we are stuck. >> So now concretely how do we proceed for this changes? >> Because you could have done it also, published two new versions of >> the packages and notify us. >> I do not know who is maintaining the package multilangual. So we >> can do it if the code works because we are in ReleaseCandidate >> status and this is taking far too much time so we could also >> postpone it to 3.10. >> Stef > > |
In reply to this post by Schwab,Wilhelm K
I just published a new cs and a new image
RC2-7064 - I fixed problems with the repository (my mistake :() - included the SMLoader fix Next: eval fix of scott Stef |
On Oct 15, 2006, at 5:40 AM, stephane ducasse wrote: > I just published a new cs and a new image > > RC2-7064 > > - I fixed problems with the repository (my mistake :() > - included the SMLoader fix Yep, I verified that the SMLoader fix is working in 7064. (For some reason, the problem was still there in 7062, even though it looked like the fix was in the changesorter.) Also, the windowing weirdness in 7062 seems to be fixed. > Next: eval fix of scott That's worth a serious look for 3.9, even at this late time. Also, I'd recommend added the window title font fix that I just posted, since it's just a cosmetic tweak. :-) - Doug |
I saw and I will apply in the last batch (I hope) of fixes and
release the steam. Stef On 15 oct. 06, at 19:10, Doug Way wrote: > > On Oct 15, 2006, at 5:40 AM, stephane ducasse wrote: > >> I just published a new cs and a new image >> >> RC2-7064 >> >> - I fixed problems with the repository (my mistake :() >> - included the SMLoader fix > > Yep, I verified that the SMLoader fix is working in 7064. (For > some reason, the problem was still there in 7062, even though it > looked like the fix was in the changesorter.) Also, the windowing > weirdness in 7062 seems to be fixed. > >> Next: eval fix of scott > > That's worth a serious look for 3.9, even at this late time. Also, > I'd recommend added the window title font fix that I just posted, > since it's just a cosmetic tweak. :-) > > - Doug > > |
Free forum by Nabble | Edit this page |