Squeakfoundation November 2002

squeakfoundation@lists.squeakfoundation.org

22 participants
41 discussions

Re: [Squeakfoundation]Order of business ...
by danielv＠netvision.net.il 24 Nov '02

24 Nov '02

Until we have some automatic infrastructure to pick up everything posted, I would not want to commit to us picking everything up - I don't want to be enslaved to a work load we can't keep up with. Pointing the community to what has been gathered, and telling them to tell us what they want sounds good. What do you think the infrastructure should look like so we can get a better process up? given Seaside and related technology, I'm sure someone in the community could help us realize this, if we can post a clear sketch of minimal, critical functionality for a first release. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Thursday, November 14, 2002, at 03:03 PM, danielv(a)netvision.net.il > wrote: > > > Hi Guides (fellow Squeakers in the audience? ;-) > > > > Three issues we should start moving on, IMO: > > 1. Process to take physical ownership of updates. > > * Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to > > settle before handing over the "keys"? > > * Scott, are you interested in some role (as vaguely ;-) postulated by > > goran, or otherwise) under the guidance (sic) of us Guides? > > * If neither of the above, can you explain the current existing tools > > in the image for handling this and the required resources, so we can > > plan a clean transition? > > > > I assume basically we'll need some public readable, Guides writeable > > storage space on updates.squeakfoundation.org, and a final update on > > both all current servers and versions that changes the urls currently in > > the image. Am I missing something? > > This sounds like the right idea. I can contact Scott about this if he > doesn't respond soon, I'm not sure if he's following this list yet (or > keeping up with the torrent of emails & squeak-dev postings :-) ). > > > 2. Start planning the next release, in terms of content. > > * I'll start a thread on the squeak-dev list to hear what people think. > > I'll also outline the process for posting refactorings as I sent to you > > guys on the internal "Re: Fwd: Re: Image factoring" thread, and see what > > people think. > > * Doug, we need to know what's currently on the table of the former > > Harvesters group, so we can decide what to integrate, what to reject, > > and what to punt to the list and SM. > > Well, there were two bundles of fixes harvested by myself and Luciano > about six months ago, which fell off the table somehow before making it > into the 3.3alpha update stream. These were mostly useful fixes & > refactorings. I could look at (non-module) retrofitting these to > 3.4alpha. There haven't been all *that* many updates in the last six > months (which would potentially conflict), so this may not be too hard. > > Other than that, there's the usual swarm of fixes/enhancements submitted > to the list over the last 6 months which still haven't been harvested, > or even put "on the table" (in the sqfixes harvesting tables). (Adding > items to the sqfixes is only a semi-automatic process right now, which > is something in the process that we can definitely improve.) > > I guess I need to think about whether to generate tables for the list > submissions over the last 6 months, or whether to just issue a call to > the list to re-submit items which people think are important. > > > * If you guys have directions you want the image to take in the near > > term beyond what I summarized as "removing constraints", like a merge > > plan to VI4, or whatever, I think now would be a good time to mention > > it. > > * After we get some inputs from all these sources, I suggest we hash > > out a basic release road map. As an initial sketch of it's shape (we'll > > have actual content later) - > > 3.4 - a quicky release to remove some constraints and test our process > > for refactoring and removing a few obvious applications from Squeak. > > 3.5 - a slightly longer release to optimize and continue the process, > > stabilize our work tools. > > 4.0 - New image format... > > This sounds pretty good, at least for 3.4 and 3.5. (I'll let others > comment on 4.0.) > > - Doug > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

5 8

Flow integration
by Daniel Vainsencher 23 Nov '02

23 Nov '02

(This is a draft I think we should post to the squeak-dev to generate the main discussion there. If you guys have comments/additional issues to raise...) As I noted before, a few people have requested that the Flow work by Craig be integrated into the base image. This work: - Replaces the primitive interface to sockets and other External Resources - Refactors the stream hierarchy I've had a few concerns that the changes might create too much change all at once, considering that many things use the stream hierarchy. After speaking to Craig about these issue, it seems that (Craig, please correct me if I'm wrong here)- 1. The new streams implement all the old protocols, so that the main compatibility problem should be direct references to the old class names. This is easy to fix incrementally for packages, and fairly quickly for the image itself. 2. The package as it is now can coexist with the existing libraries, making testing quite feasible at low risk. So I guess this move should be pretty easy. Open questions - 1. Should we do it? 2. How do we test to minimize risk? 3. When? 1. Do or not? If people know of any general objections/problems with this code, it's best to put them in the open now. I'm not qualified to answer about the benefits of the new primitive interfaces, I'm quite ignorant in these things. John M has (IIUC) spoken in favor of it. Could we get some more input from the experts? About the stream refactorings, I think several people have used Flow to develop their own applications. Luciano has mentioned that he's used it for several and liked it. More evaluations would be useful here. 2. Testing As to format, Craig has agreed to post these changes on SM in the precise form he'd prefer to issue the proposed updates. As to how to make sure it doesn't cause problems for this or that package or application - that's up to you guys out there that use your sockets for more than reading mail... ideas? 3. When? Probably not in 3.4 (just to keep the release finite and near), but possibly in 3.5. This depends on Craig posting on SM in the proposed format, and mostly on when we get enough testing input. Daniel

12 24

re: releasing SqueakMap (was "One more update for 3.2.1?"... again...)
by Craig Latta 23 Nov '02

23 Nov '02

Hi Doug-- > Also, I suppose if the goal is to move 3.4 toward a release > relatively soon (in the next month or two?) then getting the SM > bootstrap into the 3.2 series becomes less urgent. Why can't we leave 3.2 alone and make 3.4 the venue of SqueakMap's mainstream debut? Will someone please summarize the rationale for revisiting a "final" release here, and for getting into tertiary version numbers? thanks, -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

6 11

Re: [Squeakfoundation]re: releasing SqueakMap
by Daniel Vainsencher 23 Nov '02

23 Nov '02

[3.4 is 3.2 + 3.3 critical changes + (SM & fixes)] Doug said: > This sounds roughly right to me. > > However, in an earlier message, Daniel mentioned something about also having a few simple applications (Celeste, IRC, PWS, etc.) removed from the image for 3.4 once they are converted to packages on SqueakMap. Do we still want to do this? It might be nice to have in 3.4 as a demonstration of how the image is going to be broken down, but I guess it depends on how simple we want the 3.4 release to be, and how soon we want to release it. - PWS as released by Colin is almost done. - IRC is trivial (TheWorldMenu removeSelector: #openIRC, and then just remove the categories). - Celeste, I have the code, I'm adapting for a non-3.3 environment. If I'm ready soon, we can try to include, if not, it can wait. - We already seem to have a removal for B3D. We might want to include it, without performing the actual removal yet. Actually, I just wanted them removable, not removed, in 3.4, so 3.5alpha can remove them. Anyway, the removals shouldn't cause a delay. > There seems to be general agreement that we want to release 3.4 relatively soon. Does this mean in 2 weeks? 5 weeks? 8 weeks? Whichever, but let's pick one so we can guesstimate what will go in. > Scott, since you are helping us with the 3.4 release this time around, feel free to chime in with your thoughts as well. > > Also, I was going to solicit people on the squeak-dev list to suggest any important fixes which have been submitted in the last 6 months but not incorporated, so that we could harvest a handful of important items for 3.4. (If I do this, I will do it tomorrow.) Or should this wait until 3.5alpha? I think if there are simple, important ones, we should try to get this process started. Daniel

3 2

re: Flow integration
by Daniel Vainsencher 23 Nov '02

23 Nov '02

Let me summarize the points so far - 1. Missing socket options + "security stuff in file access" - Craig plans to implement within this version, before we start integrating. 2. Categorization imperfect - side effect of 3.3 transitions, will be corrected. 3. Initialization magie prevents loading Flow twice - not really a problem, so long as it's only the magic. We'll require other testing to make sure Flow does everything it's required to. 4. Backwards compatibility - - Flow changes a few names from X to OldX, otherwise everything is intact. - There are many applications refering to the old names, in the image and outside it. - This means that Flow does break everything not explicitly fixed, with fixes being just name changes (correct me if I got this wrong). - An alternative to the current situation is to make flow disjunct from all the existing code and then let people port as they wish. This requires some changes to names. - The old stuff probably should remain loadable as a package even after any transition is "over". 5. Proposals to take the primitive interfaces but not the stream refactoring - I can't summarize this because there were no specific proposal/problems raised (Michael? Goran?) - Inserting an idea here - *if* we agree the stream refactoring leads to a better state than streams are in right now, let's integrate it independently of the "better network primitives" issues. 6. Threads dependency - Flow as is requires OS threads. - Two options are to wait for platforms to aquire them or to work around missing threads in the Smalltalk code. - Some platform don't/shouldn't have preemptive threads (PS/2) - There are reasons to do the thread emulation inside the primitive and outside it. 1 + 2 are relevant to whether the code is actually better, and Craig agrees to fix them. 3 seems to be a non issue, since it's just initialization magic that prevents reloading (not lacking functionality). 4 is about the transition, which I agree we might have to hone a bit in order to prevent breakage, and make porting come after acceptance, and not vice versa. OTOH, these are only relevant if we clarify all the "should we do it at all issues". Which are: 5 - Michael, could you please clarify you intent here? I'm not sure whether your comments here are about transition or the desireability of the refactoring itself. 6 seems to hinge on whether Flow can have reasonable support in the image for emulating threading on platform that lack it, and on whether there's a reason that's not good enough. I think we agree that our goal is Squeak becomes more portable by this change. On the face of it, one implementation of platform agnostic thread emulation in the image is better than many different schemes in the platform specific primitives (our current situation). This is just my impression, and still doesn't prove that such in image emulation is reasonably doable. Daniel Craig Latta <craig.latta(a)netjam.org> wrote: > > Hi Andreas-- > > > From what I can see looking over the primitives, there are two things > > missing. One is support for socket options and one support for > > security stuff in file access. Both are not hard to add but can be > > painful if missing. > > Fair enough; I plan to implement those things for version 2. > > > ...it'd be nice to have a version that doesn't put 82 classes into > > "reorganize me" - makes it really hard to grok this stuff for > > someone who has no idea how to reorganize flow ;-) > > Of course. This is an artifact of the way class categorization got, er, > attacked in Squeak 3.3 (in which I was working for quite a while), > before there was a stable 3.2. I think it was reasonable to leave things > this way for an alpha release (the current Flow release is 2 alpha). I > had planned proper categorization for 2 alpha 2. It'll be easier than I > thought, now that categorization support has emerged unchanged. :) > > > Secondly, I am scared to death about the issue of backward > > compatibility. > > I think the best thing I can say to assuage such fear is that I've > already done "complete" installations of Flow into Squeak, in which I > removed *all* the old stream and socket (and file!) support, in three > days (24 hours' work), without incident. > > Nevertheless... > > > I urge you to consider leaving the current streams and sockets > > basically intact and rather have flow be an _alternative_ to instead > > of a _replacement_ of the current classes. > > Yeah, that's why I currently distribute Flow that way. After installing > Flow, all Flow features and all old features work concurrently. > > > From what I can see there are only very few places affected where > > global names collide and if that's the entire problem someone ought > > to be able to come up with a few alternative names. > > Actually, the current Flow release does this. Anywhere there's an > existing class with a name I want to use, I rename it with "Old" > prepended (e.g., "Stream" becomes "OldStream"). I also fixed all > references to those classes (as of 3.2 final). > > So... > > > With the current version of flow you will instantly break any code > > that - for example - uses "FileStream readOnlyFileNamed: 'foo.bar'" > > or "Socket newTCP" (and believe me, there are plenty of those in > > Croquet... > > That's only true, possibly, for post-3.2final code; in the current > release of Flow I've fixed all appropriate class references as of 3.2 > final. E.g., (FileStream readOnlyFileNamed: 'foo.bar') became > (OldFileStream readOnlyFileNamed: 'foo.bar'), and (Socket newTCP) became > (OldSocket newTCP). > > The new internal stream classes support the protocol of the old ones > completely. The other "name-stealing" ones (e.g., FileStream and Socket) > do this to a lesser degree. I decided it was easy enough to just fix all > the class references. > > > ...if you need another instructive example just try to install flow > > two times ;-) > > That's not a fair example. :) There's some very appropriate but > one-time magic in the Flow installer. Do you really need this > capability? It can be done. > > > The entire situation here strikes me of being amazingly similar to > > the backward compatibility issues with modules - in both cases > > fundamental notions are being replaced instead of augmented. Let's > > try hard not to repeat this debacle. > > I think this situation is very different, since the new and old stuff > runs at the same time. We can be as gradual as we like in adapting > current applications to the new framework. Also note that, as has been > the case since Flow 1.2 (August 2000) no new VM is required (the new > primitives are in a plugin). For me, this is all in marked contrast to > the 3.3 modules experience; for example, class categories and pool > dictionaries just broke. :) (This is not an invitation to reopen a > discussion on modules. ;) > > > I'd be interested in finding out how feasable it is to implement the > > flow socket primitives in a non-threaded way. On PS/2 for example, or > > any *nix with broken pthreads. The code looks like it is relying > > heavily on a threaded implementation. > > Yes, it is, and I think that's a very good thing, from simplicity and > performance standpoints (see http://netjam.org/flow/advocacy.html). As > I've said before, I don't think it's worth compromising on either of > these points for the sake of supporting broken host platforms. I think > it'd be better to support those platforms by augmenting Flow's current > implementation. It seems quite feasible to me, by using Smalltalk > threads that simulate some of what the host threads do in the current > Flow implementation (not entirely unlike what happens in the mainstream > Squeak system currently). > > However, I do consider supporting the thread-capable platforms (e.g., > win32, *BSD, Linux, Macintosh), which are overwhelmingly more widely > used than the others (e.g., PS/2, Acorn), a much higher priority. Flow > works on those popular platforms right now. And I think the work of > supporting the thread-impaired platforms now may be rendered moot in the > near future. I'm not familiar with the details of PS/2, but I know that > there are, for example, people working on pthreads for the Acorn. > > > thanks, > > -C > > -- > Craig Latta > improvisational musical informaticist > craig(a)netjam.org > www.netjam.org/resume > Smalltalkers do: [:it | All with: Class, (And love: it)] > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

5 10

Guides frozen at 6!
by goran.hultgren＠bluefish.se 22 Nov '02

22 Nov '02

Ok, since noone is touching this potato I will do it: When we first formed the Guides we said that 3-4 is a nice figure. Then we grew a bit from that (Craig, Daniel) so we are now 6. Then I wrote that 6 is probably enough - hey, we will rotate etc and you don't need to be a Guide to do stuff. Then I started sketching out roles since I believe that it is VITAL that we have some form of structure in our work and the absolute MINIMAL is to at least have ROLES that we are aware of. When doing that Ned added a few roles I had missed and then I realized we couldn't fill all these roles. So I thought that hey, perhaps we can just pick up one or two more Guides and fill them. I also wrote to that effect. But giving it more thought I think that we should stay at 6 and instead make it absolutely clear that you don't need to be a Guide to do these kind of things. Scott Wallace will hopefully still keep the update stream in order (I hope) for a while at least (together with Doug). Bruce will still keep churning out those downloads of Squeak and Cees will hopefully still want to take responsibility of the external relations aspect. This is important - let's keep the Guides group at the size of 6 so that it can communicate without too much overhead. And instead of being tempted to grow that group - let's put down all these other roles we alread have in the community. We alread have Cees in charge of SqF (more or less), Russel Allen and Ted Kaehler are already in charge of the www.squeak.org website etc. And then in 6 months or something - we rotate - so everybody will get a "chance" of burning away some otherwise perfectly free time that you can spend with friends and family. :-) I also apologize to Cees for "messing it up" like this. ;-) So, Tim, Daniel, Ned, Craig, Doug - let me hear your voices. regards, Göran

5 9

Re: Basic tenets of what goes in the image (was: [Squeakfoundation]Flow integration)
by Daniel Vainsencher 22 Nov '02

22 Nov '02

Goran.hultgren(a)bluefish.se wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: [Blablabla] Goran wrote: > My point being that new stuff should simple NOT go into the image *at > all*! It seems to me that you are perhaps forgetting the base principle > that only fixes+really good enhs+package removals should go into the > base image! It is easy to forget though - we all tend to do that in > these discussions. Well, maybe I didn't make it clear. I agree we don't want new functionality in the image. My post refers to fixes, improvements and refactorings. Why improvements? see below. > For example, TestRunner... Why is that in the image? Cut it out into a > package. We don't have configurations just yet, and we don't have tiny images that load themselves up yet, we're just working on it. If we already have a TestRunner in the image, it's better for it to be more usable. Nevertheless, it should be removable, and at some point, removed from the base (Actually, I think it's removable right now, but I wouldn't hurry to remove it quite yet). > > I'd like comments on this at least from all Guides. > > > > Before we decide how to get there on any specific package, we need to > > make it clear where we're going. > > I strongly urge everyone to keep the focus on *packages* and not the > base image. This also applies to the discussion about 3.4alpha going > into beta and the discussion about putting SM into the base image, btw. > > If people still want to talk about a "base" of some kind then by all > means we should create one! How? By selecting packages that we want to > consider to be the base packages. I think we're all most interested in the transition to a modular Squeak, but we also need to give those modules the best base we can. So we need to do some work on what is in the image. I think it's best to be eager to modularize the parts of the image that are uncontroversial, and wary about the problem parts. What we certainly can't do is remove components that many things still in the image are dependent on. Daniel

2 1

Re: [Squeakfoundation]re: releasing SqueakMap
by Daniel Vainsencher 22 Nov '02

22 Nov '02

There is already a page describing and tracking the refactoring process: http://swiki.squeakfoundation.org/squeakfoundation/77 It's currently up to date. I would really like to include the B3D stuff refactoring in 3.4, but I got zero testing on it so far, so it's not that likely to happen. For the release plan Swiki page, see http://swiki.squeakfoundation.org/squeakfoundation/79 And fix update as needed. Daniel goran.hultgren(a)bluefish.se wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > [3.4 is 3.2 + 3.3 critical changes + (SM & fixes)] > > Doug said: > > > This sounds roughly right to me. > > > > > > However, in an earlier message, Daniel mentioned something about also having a few simple applications (Celeste, IRC, PWS, etc.) removed from the image for 3.4 once they are converted to packages on SqueakMap. Do we still want to do this? It might be nice to have in 3.4 as a demonstration of how the image is going to be broken down, but I guess it depends on how simple we want the 3.4 release to be, and how soon we want to release it. > > > > - PWS as released by Colin is almost done. > > - IRC is trivial (TheWorldMenu removeSelector: #openIRC, and then just > > remove the categories). > > - Celeste, I have the code, I'm adapting for a non-3.3 environment. If > > I'm ready soon, we can try to include, if not, it can wait. > > - We already seem to have a removal for B3D. We might want to include > > it, without performing the actual removal yet. > > > > Actually, I just wanted them removable, not removed, in 3.4, so 3.5alpha > > can remove them. Anyway, the removals shouldn't cause a delay. > > Sounds good. The one that sounds "dangerous" is probably B3D but if we > leave the dangerous step for 3.5alpha it sounds good to me. > > Btw, can you type down this plan on the Guides swiki so that we have it > written down somewhere? > Create a page called "Release plan" or something. > > > > There seems to be general agreement that we want to release 3.4 relatively soon. Does this mean in 2 weeks? 5 weeks? 8 weeks? > > Whichever, but let's pick one so we can guesstimate what will go in. > > Sounds to me that Santa Claus showing up with the presents is a good > deadline! Note though that in Sweden he shows up at Christmas eve... > > > > Scott, since you are helping us with the 3.4 release this time around, feel free to chime in with your thoughts as well. > > Right. > > > > Also, I was going to solicit people on the squeak-dev list to suggest any important fixes which have been submitted in the last 6 months but not incorporated, so that we could harvest a handful of important items for 3.4. (If I do this, I will do it tomorrow.) Or should this wait until 3.5alpha? > > We can wait I think. Otherwise we might just introduce instability. > > > I think if there are simple, important ones, we should try to get this > > process started. > > Ok, but keep the bar raised high so that we don't shoot ourselves in the > foot. > > regards, Gran > > PS. SM is actually a very small change to the base image. Because it's > just a hook. > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

I'll be back around 7pm GMT (EOM)
by Craig Latta 22 Nov '02

22 Nov '02

-- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

re: Basic tenets of what goes in the image
by Daniel Vainsencher 22 Nov '02

22 Nov '02

What you say is true, but very reasonable people may wildly disagree on what that statement means, and I'm trying to eliminate precisely that effect... :-) Daniel PS - Taking the simplifying direction a step further, my day-job team has an expression that seems relevant - "Make Good" ;-) Craig Latta <craig.latta(a)netjam.org> wrote: > > > This is my proposed base policy on what should go into the image... > > That all sounds reasonable. If we want to make policy, I think I would > (somewhat loosely) state it as simply "the released image should contain > things for which omission would cause confusion or inconvenience to a > new user". Note that, as our distribution technology changes (and we get > things like utterly-minimal images, pervasive network installation, > unloading, etc.), the implications of that statement will evolve. > > > -C > > -- > Craig Latta > improvisational musical informaticist > craig(a)netjam.org > www.netjam.org/resume > Smalltalkers do: [:it | All with: Class, (And love: it)] > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

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 November 2002