Squeakfoundation November 2002

squeakfoundation@lists.squeakfoundation.org

22 participants
41 discussions

Re: moving 3.4 to beta?
by goran.hultgren＠bluefish.se 28 Nov '02

28 Nov '02

Hmmm, now we are doing personal email again. I think we should stick to the SqF mailinglist. Doug Way <dway(a)riskmetrics.com> wrote: [SNIP of stuff sounding good] > (One other small change is the "Package Loader" prompt change that Daniel suggested on the list. That might be okay to add in beta, too.) > > - Doug That code is in the postscript of the SqueakMap package. So it is outside the stream. But I can do a new bugfix-release of SqueakMap including this and some other small tidbits. regards, Göran

2 1

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

28 Nov '02

Hmm, I think it's clear we're not all on the same page here, and I think we better address this sooner rather than later. This is my proposed base policy on what should go into the image * Has to help all Squeakers. Being cool (Connectors) doesn't cut it - that can live on SM. TestRunner ENHs encourage more SUnit tests, so they might go in. * It has to be stable. There is no reason now to integrate unstable code. Young code can live on SM until it's tested. If package maintainers prefer it to what's in the image, let them depend on it. This has two benefits - - Acceptance in the community is not binary - you can have users, even many, before the code is in the image. - The use and testing will make the code stable, at which point, we can put it in the image. * It has to be understandable. Add class comments, reduce class count/size, reduce functionality to the minimum that really needs to be in the image. Just keep it simple. If we let things in the image that make it bloated, or unstable, or even stable but unmaintainable, we're eating the goose. I think if we're commited to making Squeak viable in the long term, we need to keep these things as high priorities. At the same time, to help people that contribute work to squeak to know where to aim, I think we must make the criteria clear, whether we agree they are similar to the above or not. I reviewed the Mission Statement now, and it doesn't say much about it, which I think is a bug. 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. Daniel Andreas.Raab(a)gmx.de wrote: > Hi Guys, > > > 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? > > 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. > > That said, two extra thoughts. For one thing, 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 ;-) > > Secondly, I am scared to death about the issue of backward compatibility. 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. 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. 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 and if you need another instructive example just > try to install flow two times ;-) I can understand that providing a full > compatibility layer in flow may be neither doable nor desirable but that's only > another argument for leaving the current classes intact to the point that > there is at least a chance of running existing code. 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. > > Cheers, > - Andreas > > > (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 > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

5 7

Re: [Squeakfoundation]Guides swiki pages and more
by Daniel Vainsencher 28 Nov '02

28 Nov '02

I agree - The SqF Swiki seems to me to be a pretty natural place to stay. I agree about roles/tasks smearing - some things make me itch to help move along (imag refactorings, Flow), I'm sure each of us has his, making the dividing lines shallow sounds like the way to make the most of it. I don't mind driving the release discussions. Of course, most of the ideas won't be mine, so people - start thinking now about something (smallish) that needs to be done, and a proposal on how to get it started/done in 3.5. One thing though - Scott is pushing 3.4 along quite nicely, but I think we should help more. When the updates were announced for Tuesday, I for one was date-fogged due to vacation and thought it was a weekend, and so "had plenty of time"... and missed it. So, I think we should have someone tracking and doing preliminary testing any proposed updates more or less immediately. If someone has time to do this for 3.4, that's cool. If not, I can do that at weekend boundaries (eg - will test during weekends anything posted by Scott during the week). Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > goran.hultgren(a)bluefish.se wrote: > > > > Hi fellow Guides! > > > > I just refactored our SqF pages a bit ... > > > > I also took the liberty of changing the "Current Foundation Projects" > > into listing the three projects that I think are the current "projects". > > Sounds good. (Btw, I updated a few older pages myself, such as Modular Squeak Discussions, etc., just so they're not misleading. And this led me on a trail of updating some pages over on minnow too, such as the Modules page. Swiki cleanup often leads you around like that. :-) ) > > > and added this btw: > > > > "Currently we use the SqF swiki to keep some Swiki pages on what we do > > and how etc. Eventually this might move over to the main Squeak Swiki, > > we will see how things pan out." > > > > I haven't thought much about this but perhaps we need to figure out > > "where to live" eventually. Perhaps SqF Swiki is fine. Or perhaps we > > should be at minnow. Or perhaps we should have something of our own. I > > don't know. > > The SqF Swiki seems like a fine place for now, since it's more focused on Squeak community/organizational issues. (Perhaps if SqF gets going as a legal entity at some point, we may want to move, or maybe not.) > > > Further I separated the roles page into two. Daniel hasn't "confirmed" > > his role but whatever, the role bit didn't seem to land so well with you > > guys anyway. Feel free though to *change* the roles I outlined to > > something you like yourself and then confirm that. I am happy as long as > > I know what people DO. > > Some comments on my listed role: Mostly it sounds fine. I could be the initial maintainer of the update stream, starting with 3.5alpha, similar to Scott's current role at SqC. Also, I can coordinate the evolution of the new harvesting/update framework. (Even if someone else such as Luciano works on the tool itself.) > > I don't want this role to become *too* expansive, though. :-) There's already enough responsibility for me in the above two tasks. I wouldn't want people to think that I am in charge of deciding which larger items should go in 3.4, or 3.5, for example. That's for all of us to decide, with plenty of input from the community too. Actually, I think Daniel has done a good job so far of acting as a moderator for these decisions (see "3.4 Roadmap" etc. messages), so perhaps he could continue doing that. > > Anyway, I guess I'm just saying that these roles have some overlap, they will need continuous refinement, and we should feel free to work on stuff outside of our roles. But it is good to have these basic roles in place just so that someone is responsible for getting certain things done. > > - Doug > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 5

Re: [Squeakfoundation]Guides swiki pages and more
by Daniel Vainsencher 27 Nov '02

27 Nov '02

> PSS. Yes, a bit irritated. But... wait, wait... yep - smile is back on! > :-) Important skill for anyone into herding cats.... ;-) been doing some serious practice myself in related skills... Daniel > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Guides swiki pages and more
by goran.hultgren＠bluefish.se 26 Nov '02

26 Nov '02

Hi fellow Guides! I just refactored our SqF pages a bit and added this btw: "Currently we use the SqF swiki to keep some Swiki pages on what we do and how etc. Eventually this might move over to the main Squeak Swiki, we will see how things pan out." I haven't thought much about this but perhaps we need to figure out "where to live" eventually. Perhaps SqF Swiki is fine. Or perhaps we should be at minnow. Or perhaps we should have something of our own. I don't know. Further I separated the roles page into two. Daniel hasn't "confirmed" his role but whatever, the role bit didn't seem to land so well with you guys anyway. Feel free though to *change* the roles I outlined to something you like yourself and then confirm that. I am happy as long as I know what people DO. Now I intend to dig through Neds todo-list and add my initials in appropriate places and then I think I will go over Doug's plan for a harvesting tool. regards, Göran

2 2

A Gentle Introduction to the Squeak Community
by cg＠cdegroot.com 25 Nov '02

25 Nov '02

http://swiki.theinternetone.net/squeakfoundation/82 is an attempt to describe the organization of the community by way of a guide for newbies. I just collected bits of content, it's very much a work in progress, but I'd like to have your opinion on whether this is a feasible way to chart how the Squeak community works before really plunging in (and, of course, being the lazy guy I am, I hope someone else completes it before I get a chance ;-)) -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo

6 13

Changes on SqF Swiki
by goran.hultgren＠bluefish.se 25 Nov '02

25 Nov '02

Hi again! I also took the liberty of changing the "Current Foundation Projects" into listing the three projects that I think are the current "projects". :-) The link to the "Release Plan" and the link to the page on image modularization are now on "The Guides" page. regards, Göran

1 0

I am on IRC btw
by goran.hultgren＠bluefish.se 25 Nov '02

25 Nov '02

Yeah, forgot. I am on irc.openprojects.net/#squeak signed in as "goran". Come on over! The Enhanced IRC client on SM is really nice. Even though it overwrites the dynamic open menu stuff... :-) regards, Göran

1 0

SqF top swiki page is now locked
by Doug Way 24 Nov '02

24 Nov '02

Someone has been persistently uploading mp3's and other files to the SqF top swiki page over the last few weeks (which show up as links at the bottom of the page), so I took the liberty of simply locking the top page. This has worked well so far on the minnow Swiki to stop file-uploading abuse. I hope this is okay with you, Cees. :-) The password for the SqF top page is "squeak" (same as on minnow), for when anyone needs to make changes to it. I'm guessing the uploaders do not follow this mailing list. ;-) See http://swiki.squeakfoundation.org/squeakfoundation/1.history for details on the swiki abuse. - Doug

2 1

Re: [Squeakfoundation]A Gentle Introduction to the Squeak Community
by Daniel Vainsencher 24 Nov '02

24 Nov '02

I feel very strongly we should avoid the statement "OSI approval pending". As Goran said, some people do care about whether software is OSI compliant or not, and though I specifically don't, I would avoid software that is labeled in a misleading manner. There were lots of good enough proposals mentioned. BTW, I for one would be very happy if we could in good conscience remove the offensive paragraphs. FSF/OSI incompatibility is a liability to this community, even if it's not one to us as individuals. Daniel Andreas.Raab(a)gmx.de wrote: > > Andreas.Raab(a)gmx.de wrote: > > > <quote> > > > technically, Squeak isn't Open Source > > > </quote> > > > > Yes, Andreas - that is true. > > Guys, please. Even if it may be technically correct that Squeak is not OSI > approved and therefore not Open Source (tm) Software that's no way to phrase > it. Just imagine what you would think if you read this. If that's the way > you're going to do marketing then good night. For starters change this into "not > OSI approved" instead of "not Open Source" and if someone complains then make > it "open source" (IIRC, then only "Open Source" is tm-ed). In fact, I would > say "OSI approval pending". > > - Andreas > > > Cees tried the SqueakL on the OpenSource > > guys (www.opensource.org) (they have a list for these things) and there > > are two problems: > > > > 1. The font clause must be removed. This is possible to do, but until it > > has been removed SqueakL fails OSD compliance. > > > > 2. Clause 6 fails the non-discrimination test of OSD. > > > > A quote from Matthew Weigel on that: > > > > "IIRC, this actually came up with the APSL too (corrections, anyone? > > was it the Plan 9 license instead?). If that recollection is > > correct, then it seems that it might be 'easy' to point out that > > they have capitulated on that point previously (that's probably not > > the best wording to use around them, though :)." > > > > And Forrest J. Cavalier III: > > > > "Requiring compliance with U.S. laws, even in other jurisdictions is > > unnecessary. But the way paragraph 6 is worded, I think it obviously > > fails the OSD non-discrimination test. > > > > I quote that paragraph: > > > > 6. Export Law Assurances. You may not use or otherwise export or > > reexport the Apple Software except as authorized by United States law > > and the laws of the jurisdiction in which the Apple Software was > > obtained. In particular, but without limitation, the Apple Software > > may not be exported or reexported (i) into (or to a national or > > resident of) any U.S. embargoed country or (ii) to anyone on the U.S. > > Treasury Department's list of Specially Designated Nationals or > > the U.S. Department of Commerce's Table of Denial Orders. By using > > the Apple Software, you represent and warrant that you are not located > > in, under control of, or a national or resident of any such country > > or on any such list.<p> > > > > I am sorry that there are some previous licenses to work with > > here. Squeak is pretty well-known. But my recommendation: > > DEFINITELY DO NOT APPROVE." > > > > regards, Göran > > > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

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