Squeakfoundation June 2003

squeakfoundation@lists.squeakfoundation.org

30 participants
59 discussions

Re: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

Yoshiki.Ohshima(a)acm.org wrote: > Sorry for really slow response, and sloow work on cleaning up the > stuff! I'm kind of embarrassed not finishing this up, but I have to > say that there are more stuff than I can handle... Nothing to be embarrassed about, you're creating good stuff that people appreciate having in the first place. > > (Hmm, I just tried "set font..." on some text in the middle > > of the Welcome window and it appears that TT fonts are a bit buggy when > > mixed with the regular strike fonts. It's fine if I add some TT text at > > the end, though. Or we could add a small standalone demo window. Or > > just not have a demo. ;-) ) > > This bug is known and fixed. Stephane knows how to fix it:-) I think it is very important to release an up to date version with all known fixes - then people can help find and resolve the remaining issues, like performance. > Ah, there going to be some changes, which should come first before > the stuff gets incorporated... Cool, let us know when it's ready. Daniel

1 0

RE: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

Do the "somewhat larger" issues mean problems as soon as we insert the DecPools, or changes when we convert the image? if the second, does this mean it makes sense to insert the code, but convert the rest of the image in 3.7, or do you think this would be confusing? Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Doug, > > > If the DecPools stuff feels like it's "ready", we could put > > it in now, otherwise we can put it in right at the beginning of > > 3.7alpha, which isn't too far away anyway. (It sounds like there > > are still some outstanding issues at the moment...?) > > There are some issues but which fall into two categories: minor problems > (like defining instance side methods) which can be considered "beta > problems" and (somewhat larger) problems making the entire system use > declarative pools. The latter doesn't sound like a problem of the > declarative pools but rather their application in certain dubious > circumstances (the use of TextStyles in TextConstants, or the use of > lower-case globals is not an issue with declarative pools). > > > I originally wanted to get the TrueTypeTextStyle stuff in as > > well, but there may or may not be time for that. > > What's upholding this? Anything I can help with? > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

Re: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

I'll note again that last time the code was reviewed by Goran, Yoshiki wanted to fix some things about it. A quicky partial review of v5 does show some things that could use some cleanup: - at least one method clashes with MCP. - The single GrafPort method sends to super but implicitly returns self. - Paragraph>>asForm does an "isKindOf: TTCFont" So IMO, this code doesn't belong in Basic, yet. A thorough review and patches to Yoshiki would probably help resolve this situation in the fastest way possible. Yoshiki, can you give us an update on the state of the fixes you wanted to do? Daniel Doug Way <dway(a)riskmetrics.com> wrote: > Andreas Raab wrote: > > >Completely agree. > > > >BTW, Tim, does *installing* or *using* the TT fonts slow your system down? > >If the latter I would claim that that's almost normal - the TT fonts require > >more expensive rendering and while a lot of this can (given time) be tweaked > >some of it just can't be changed. > > > > Right. Assuming it's using (not just installing) the TT fonts that > slows things down on slower systems, we could incorporate the TT fonts > changes, but not actually change any of the default fonts to be TT fonts > for now. (Maybe change a default font to be a TT font sometime in 3.7 > if it's working really well.) > > We could change a bit of text in the Welcome window to the ComicSansMS > antialiased font for demonstration purposes, with a hint about how to > change your default font and how to load new TT fonts with the > FileList. (Hmm, I just tried "set font..." on some text in the middle > of the Welcome window and it appears that TT fonts are a bit buggy when > mixed with the regular strike fonts. It's fine if I add some TT text at > the end, though. Or we could add a small standalone demo window. Or > just not have a demo. ;-) ) > > Anyway, I'd want to at least double-check with Yoshiki first to see if > he has any impending changes coming up before incorporating the TT > stuff. (I'm cc-ing him on this message.) > > - Doug > > > >>-----Original Message----- > >>From: squeakfoundation-bounces(a)lists.squeakfoundation.org > >>[mailto:squeakfoundation-bounces@lists.squeakfoundation.org] > >>On Behalf Of Craig Latta > >>Sent: Friday, June 20, 2003 9:31 PM > >>To: Tim Rowledge > >>Cc: Discussing the Squeak Foundation > >>Subject: [Squeakfoundation]re: TrueType font support and 3.6 > >> > >> > >> > >> > >> > >>>[TrueTypeTextStyle] works ok, looks beautiful but seems to slow down > >>>my system quite a bit. We need profiling and improvements to make it > >>>suitable for default usage - something I think very important. > >>> > >>> > >> It doesn't slow mine down, and it's not rediculously > >>faster than yours > >>(mine's 500 MHz, yours is 200?) If profiling reveals this to be > >>something that only affects, e.g., old RiscOS machines, I'd prefer to > >>release it and fix the problem later. This is very important. I would > >>even be happy if we just released it without profiling, since > >>it's fine > >>on all the Unix, win32, and MacOS machines I've tried it on. > >> > >> > >>-C > >> > >>-- > >>Craig Latta > >>http://netjam.org/resume > >>craig(a)netjam.org > >>Smalltalkers do: [:it | All with: Class, (And love: it)] > >>_______________________________________________ > >>Squeakfoundation mailing list > >>Squeakfoundation(a)lists.squeakfoundation.org > >>http://lists.squeakfoundation.org/listinfo/squeakfoundation > >> > >> > >> > > > >_______________________________________________ > >Squeakfoundation mailing list > >Squeakfoundation(a)lists.squeakfoundation.org > >http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 21 Jun '03

21 Jun '03

[Accufonts in if Doug happy with his changes DecPools in or out is Tim's call, KCP in or out my call, 3.7 alpha opens with 3.6 gamma] I agree on these. We enter beta friday the 27th? [other things like TT fonts] >4 Anthony runtime enhancements (split in two - fixes and closures) >5 Craig's simulator fixes >7 TrueTypeTextStyle >8 Diego look style enhancements 4 - I started to review this, and Anthony made a revision, which I haven't looked at yet. I asked for help, and am not getting it, so we can forget about it for 3.6, unless someone does something new. The problems outstanding are - A. I'm don't know enough about exceptions to notice if something there fubars exceptions in some strange case. We need a reviewer that knows the area. B. Anthony for some reason includes in this package myriad changes to existing classes. I think that class library extensions should be discussed on the list, and shouldn't sneak past on the tails of fixes or enhancements. I started reviewing these, but frankly, it's quite tedious, especially since I don't know which, if any, the code we actually want depends on. To be honest, I would be quite glad if someone simply verifies they are not needed, rewrites the code to not need them if the do, and gives us a very short list of changes that are actually needed, if any, with some explanation of what general case this code serves. 5. Were reposted, but we have no review. Berne have expressed some interest in testing this, but nothing more. IMO, this gets pushed from 3.6, though it might be reasonable to accept in beta, since they're fixes. 7. Yoshiki said he's working on a revision. Will need to get reviewed... not 3.6. 8. Avi said he doesn't like something about the scrollbars. These don't have a preference, which Diego said he'd treat as a bug. I don't know of review/testing status. BTW, at some point it was starting to look like we might get some feedback from people working with the m17n work, and be able to get it into 3.6. I guess not, now, but anyone know what's going on with that? Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > Daniel Vainsencher wrote: > > >I disagree with the current calls to delay the release. If we wait for > >everyone to get whatever matters to them in, we might never make a > >release again :-) I don't see anything wrong with stuff waiting for 3.7 > >- DecPools included. > > > >I know a few of us feel "in the middle of" various projects, but I think > >the release process has value too - it reminds us to clean the table > >every so often. I think between the KCP deprecations and the network > >rewrite, we've had enough change that it will do us good to focus on > >stability before we keep moving ahead. > > > > > > I was on the fence somewhat, but this sounds like a reasonable plan. We > will delay beta for a week or so, but stick to our final release date of > August 1st. There is some value in sticking to release dates unless > there is a pretty big problem. > > If the DecPools stuff feels like it's "ready", we could put it in now, > otherwise we can put it in right at the beginning of 3.7alpha, which > isn't too far away anyway. (It sounds like there are still some > outstanding issues at the moment...?) I'll leave it up to Tim as to > when it feels ready. > > I actually wanted to at least get the Accufonts changes in for 3.6alpha > also, which I don't think should be *too* destabilizing, and was on our > 3.6 plan. I was going to work on that right after including the current > batch of approved items (which I'll try to do today). There are a few > tweaks that I think should be made to the Accufonts stuff before it gets > incorporated (for example I don't think it should change the default > text size), so I was going to post my tweaked version as an [ENH] for > people to try before rolling it in as an update. > > I originally wanted to get the TrueTypeTextStyle stuff in as well, but > there may or may not be time for that. The items such as this on the > 3.6 plan which don't make it in will get pushed off to 3.7alpha. But we > could plan on listing them first on the 3.7 plan (say, before further > package removals), so they'll be more likely to actually get done in 3.7. > > >More generally - if we think about the process as a whole, not just the > >particular point in time were in, the only right kinds of reasons to > >delay the move to beta are "it doesn't meet our functionality goals". A > >more specific example is "without this new function, all of this other > >stuff we inserted makes no sense AND it is hard to remove that stuff". > >Only right kind of reason to avoid moving from beta to gamma is "this > >version doesn't meet our stability goals". Which I think should be "this > >version should be stabler than the previous one". > > > > > > ("Previous" meaning 3.6gamma should be stabler than 3.6beta, or stabler > than 3.5gamma?) > > >So a one week delay of beta to insert parts of KCP that relate to what's > >already in makes a little sense. Delaying by a month just to get more > >stuff in now that the harvesting process is livelier, seems unjustified > >to me - we can get that after the version fork. > > > > Yes... we can try to get most of the current KCP changes in this week, > and then the next batch wouldn't go in until 3.7alpha. > > >Speaking of which - at which stage do we create the 3.7 update stream? > >last time we did it on entry to beta, IIRC, yet some might say entry to > >gamma is more reasonable. What do we think? > > > > > > Good question. I'd lean toward opening the 3.7alpha stream when we move > 3.6 to gamma... this is a good way to encourage people to use and test > the beta version so that things actually get fixed. And since the beta > is only ~3 weeks long it doesn't seem like too big a sacrifice to not > have an alpha version during that time. It also simplifies update > stream management a bit. I could go either way on this, though. > > - Doug Way > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

RE: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 20 Jun '03

20 Jun '03

In that case, and given Avi review, I'm assuming Tim is merely being properly coy about approving stuff he's touched, and will approve it in the next few days. Would be nice if one of you guys can create the "simplified tutorial to proper definition of new-style Pools", and post on the list/swiki so people can do the right thing in the future. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > > Do the "somewhat larger" issues mean problems as soon as we insert the > > DecPools, or changes when we convert the image? > > The latter. The problems really come from either somewhat strange uses of > pool dictionaries (e.g., lower-case strings as keys) or from uses where the > pool is extended dynamically (TextConstants). > > > if the second, does this mean it makes sense to insert the code, but > > convert the rest of the image in 3.7, or do you think this would be > > confusing? > > I think it's perfectly reasonable and what I anticipated anyways. Even > though the remaining pools "ought to be converted" there is no requirement > for doing it in 3.6 - we've been living with them for so long and the places > where we had an immediate need for fixing them are fixed. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

About TTF
by Stephane Ducasse 20 Jun '03

20 Jun '03

Hi andreas I think that TTF is important to get decent aliasing stuff. I'm sure you will not disagree. You said that you are willing to help so... can you please check with Yoshiki? help him, profile the stuff so that Tim is happy, make a real review and push it. TTF should be DONE, so that we pass to other. Stef

1 0

Re: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 20 Jun '03

20 Jun '03

Yes, I suspect I phrased thing very badly, somewhat assuming that people already knew my point. Beta is a time for stabilization only. This is why enhancements and risky fixes might not make it in. While KCP is definitely stabilizing in the long term, deprecating stuff does create the short term risk of breaking things, which is not appropriate to introduce in a beta stage, because in practice it will mean that we end up with a release that is not appropriate for demos. Note that my intention is try to get at least part of the outstanding KCP stuff in while we're still in alpha or early enough beta. Especially since some of those things actually fix deprecation-related problems... Regardless, KCP does and will continue to have a relatively easy way to get into the image (me), at least as long as you continue to do such great work, and I haven't started the October term. So stop worrying so much, and continue so that we get in as much stuff as possible in 3.7 :-) Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Why daniel, if you want to get the image clean there is no way that we > will avoid > to deprecate stuff. The sooner we do it the sonner we will fix > everything. > So I do not understand your point. >

2 1

Re: [Squeakfoundation]KCP & 3.6
by Daniel Vainsencher 20 Jun '03

20 Jun '03

Doug Way <dway(a)riskmetrics.com> wrote: > On the subject of KCP, if we want to get another batch of KCP updates in > before 3.6 goes beta, we should probably do that soon. I'll leave it to > Daniel to coordinate harvesting/approving that. (Realistically I think > we need to have one harvester in charge of these types of cleanup > projects... it would be difficult to rely on the regular harvesting > process to individually approve a bunch of cumulatively dependent > changesets.) I've waited before doing the next batch of approvals, in case someone wants to help with reviewing the stuff. So far we don't have any volunteers, so I'll see if I can get in a few hours of review+approvals sometime next week. Considering the feature-deprecating nature of KCP, I'd prefer to not continue bring in that stuff in beta. > Speaking of 3.6beta, technically the planned date for this is in two > days, this Friday the 20th. But I think we could be a little flexible > with that date, since we're now finally moving with harvesting stuff... > definitely move to beta sometime next week though. We should still keep > our final date of August 1st, though, unless we agree now to postpone it > for some reason. I would be partial to postponing beta start by up to one week, without postponing release (yet). I'm not big on playing around with schedules, but since we're still experimenting in this area, so it doesn't seem like a big deal. As to beta itself, I'd say that during it what we should focus on doing is that everyone that maintains/uses packages and can afford to help, should move to using it (if up to now they were using 3.5), and then we harvest only not-too-risky bug fixes. Another things that I would like to see happen is that we get a lot of A. Tests submitted to Marcus' test package. B. Fixes to everything that's red in Marcus' test package. Having the test package green at every release sounds like good practice to me. Daniel

2 1

RE: [Squeakfoundation]KCP & 3.6
by Brent Vukmer 19 Jun '03

19 Jun '03

> -----Original Message----- > From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] > Sent: Thursday, June 19, 2003 1:49 PM > To: squeakfoundation(a)lists.squeakfoundation.org > Subject: Re: [Squeakfoundation]KCP & 3.6 > > > Doug Way <dway(a)riskmetrics.com> wrote: > > > > > Speaking of 3.6beta, technically the planned date for this is in two > > days, this Friday the 20th. But I think we could be a > little flexible > > with that date, since we're now finally moving with > harvesting stuff... > > definitely move to beta sometime next week though. We > should still keep > > our final date of August 1st, though, unless we agree now > to postpone it > > for some reason. > I don't think we're anywhere near ready for beta right now; > just for an example in my area there is the DeclarativePools > stuff to decide on. > I think we should push all dates forward by a month. KCP, Declarative Pools, a lot of stuff to be reviewed in the archive...

1 0

RE: [Squeakfoundation]KCP & 3.6
by Brent Vukmer 19 Jun '03

19 Jun '03

> On the subject of KCP, if we want to get another batch of KCP updates in > before 3.6 goes beta, we should probably do that soon. I'll leave it to > Daniel to coordinate harvesting/approving that. (Realistically I think > we need to have one harvester in charge of these types of cleanup > projects... it would be difficult to rely on the regular harvesting > process to individually approve a bunch of cumulatively dependent > changesets.) Speaking of cumulative changesets -- I would argue that we need to go ahead and roll in the KCP changes currently posted on the KCP Swiki page ... at least until *all* of the SystemNavigation refactoring gets into the image. The current bug with "remove, then show senders" is *really* annoying me right now.. ;)

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation June 2003