Squeakfoundation June 2001

squeakfoundation@lists.squeakfoundation.org

17 participants
15 discussions

Re: [Squeakfoundation]An architecture for sustainable Squeaking
by danielv＠netvision.net.il 02 Jun '01

02 Jun '01

Hi, Joseph. Glad you decided to stay on this list. Joseph Pelrine <jpelrine(a)acm.org> wrote: > Quoting you - ("Sorry, newcomer X, but your code's just too shaky, we'll > have to pass on that for now") > > Please start by reading the numerous writings on modularity in Smalltalk > before posting things like this. Modularity is only part of the story here. I just posted an example describing problems integrating a goodie I wrote. This Goodie isn't even worthy of a module, it's just a few changes needed to several places that belong in different modules. So if the goodie isn't accepted into the various modules, it's dead as a nail. Getting accepted requires gatekeepers that can say "Well, Daniel, that thing just isn't getting into my module without SUnit tests and removing the MethodSubstitute specific stuff from PluggableListMorph". Modularity is a neccessary but insufficient condition to letting people contribute things effectively. (As your keep-off-my-mind-meld posts show you very well know...) > Joseph Daniel

2 1

Re: [Squeakfoundation]An architecture for sustainable Squeaking
by danielv＠netvision.net.il 02 Jun '01

02 Jun '01

I'd like to make this more concrete, if you don't mind - I've posted recently modifications to the Browser (See HintingBrowser). In a word, this code annotates method names in the Browser according to how complicated they are. I wrote experimental all over them in big red ink, because they change the Browser, and they are hacks (made it work, have not made it "right"). My hope was to see whether someone else thinks this might be useful, and if so, I'd refactor them enough to put in the image, or at least for me to recommend them to anyone. This experience raises several questions - 1. How deep is the Browser? it's an application, but editing it sure felt like modifying core. What standards should apply to it? 2. How do we see people making modifications such as this? Whos the Browsers keeper (near-pun alert ;-), and what standards should he hold code to? Here's a short analysis of my modification (the anatomy of a quick hack) - I changed two classes - Browser (Application, but central) and PluggableListMorph (Middle-deep) And added one - MethodSubstitute (Could be used by various different tool, but it isn't, because it's taken from BobsBrowser, that never quite made it into the image. A MethodSubstitute identifies a compiled method by knowing it's class and name and whether it's on the class side). The Browser mods - #messageList was made to return lists of MethodSubstitutes instead of Strings. This makes it higher-level, refering to domain objects rather than to Strings, so it's not intrinsically bad, but it also makes it incompatible with PluggableMorphLists, which expect to get strings. #selectedMethodName was changed to convert the selected MethodSubstitute into a String. The PluggableListMorph mods - in #list:, I extracted a method for the creation of Morphs representing the list items. This protects the code somewhat from my changes to this functionality. #morphForItem: uses #stringForMethod: and methodPrefix: to implement the actual creation of morphs that display MethodSubstitutes appropriately. Of course the functionality of these two (three?) latter methods has nothing to do with PluggableListMorph. They're there temporarily, waiting to be replaced by a Strategy object or something similar. Basically, the problem I met doing this code is this - I can do the changes quickly, but in a way that would hurt important code. I can also make the changes be nice refactorings, but who said these refactorings ARE acceptable changes to such important code? maybe someone can think of something better. So before I invest time in doing these right, let's see what people say... So for now the result for now is we have Yet Another Goodie. Life expectancy - Zilch. I think we're in need of a Linus here... (technically respected person that's willing to put in Major Time and Effort in doing quality and integration work). We're very lucky in the legend-class-affiliated-programmers department, but their interests focus elsewhere... 1. Any takers? 2. How do people think these needs get solved? including under the onion-regime. Henrik Gedenryd <Henrik.Gedenryd(a)lucs.lu.se> wrote: > My idea is that we need a simple but powerful overall principle of > organization. > > (According to this proposal) we should adopt a variant of the well-known > "layered" or "onion-skin" architecture, along with a principle that ensures > sustainability: > > (1) Architectural law: Modules may only depend on (use code in) modules > "further in"/closer to the core. (Outward dependencies are forbidden.<*> > Dependencies should be made explicit.) > > (2) Principle of sustainability: In a sustainable system, the more central a > module is, the less volatile and more conservative it needs to be. > > That's all, technically, and these are not fascist laws but mere natural > necessities. > > > Comments: > > Obviously, closer to the core are more essential things. Outermost would be > "applications" that are entirely optional. > > The further out, the more you can do what you want (because the less others > depend on you), but also the more work for you to adapt to changes in the > inner layers. (But these should also change less.) > > As code moves inwards, it gains importance, grows in value for others, but > also takes on responsibilities. > > The closer to the core: > - The more the quality, stability, etc. of Squeak depends on it (Squeak: the > program, the community, all the uses of Squeak) > - The more sensitive the contents > - The slower should code change. Use maximum foresight. Not haque du jour. > - The higher standards should be imposed on changes (bug fixes yes, good > code a must, "good to have" additions & quick toss-ins nope, code that > doesn't belong there--no way José) > - The more a module needs to be the "joint responsibility" of Squeak > > Outermost would be Applications, which: > - literally noone else depends on > - are free do whatever they wish, > - but are the sole responsibility of their authors to maintain > > > There is no longer any sharp line for what goes "into" Squeak here. This is > very different from today's either-or-image situation. > > (*) This means no more "String asUrl", because this makes the core module > with String depend on the much less vital module PWS or whatever, so you > have to load PWS to use strings. _Maybe_ we need to allow outer layers to > add code in inner-layer-classes, but this creates spurious sideways > interactions between modules. Perhaps only applications should be allowed to > do this. > > Pieces like Celeste the mail reader app would most likely become > multi-layered, with the UI outermost, and more generally useful code in > separate, more inward layers--e.g. code for sending e-mail, which may be > useful in many other contexts, notably for posting code to a list or so. > > There should be code that can validate that a (new) piece of code doesn't > violate these rules, to automate things. > > There would need to be separate update streams for each module (and updating > mechanisms would need to be provided by the system as well). You choose > which ones you want. > > Up to today if you want the essential bug fixes you will get SqC's latest > experimental code tossed in for free. And if you opt not to be an alpha > pilot then basically you won't benefit from the community any longer (in > effect you do the f-word). This ain't a good situation. > > Note that many of SqC's experiments would become "far-out" layers (how > appropriate). Or rather, SqC would need to divide their stuff into layers of > well-behavedness too, if they want to contribute to the official system, so > to speak. Otherwise the stuff would remain as applications. > > This will be extra work for them and I don't know if they will want to do > that. It would make SqC have to play by the same rules as everyone else, > essentially. This is the part that I have been uncertain about whether it > will happen, but I think this is necessary. We are at the point where > pioneer town X needs to start collecting taxes and erecting law and order in > order to keep growing. Well you've all played SimCity so you know. > > Henrik > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: How to get stuff into Squeak?
by Henrik Gedenryd 02 Jun '01

02 Jun '01

> Absolutely. There are two models: the "benevolent dictator" model, where one > person decides at whim and the community reverse engineers the rules from > that, and the "committee of judges" model, with a set of rules laid out and > multiple people having write access to the repository work through > contributions and make their decisions based on the public rules. > > I think the latter is more suited to the Squeak Community, iff SqC decides to > give up full control (it's quite silent from there at the moment, I hope this > means something good's brewing :-)). At the moment, they embody a sort of > "benevolent central committee" model... Alright peoples, Now you got me subscribed so I can chip in on this. No need to reinvent the wheel, and we've had update collection in the past. Stefan Matthias Aust (sma) took care of update collection, well still does but not actively for the moment I guess :-) He posted good guidelines for this. Also I volunteered to step in for a while last fall so I have one piece of experience of doing this. SqC doesn't really collect updates, they just grab one here and there if they see a particular reason for it. I remember getting some discussion & guidelines on how to make the selection, but even given that, in my experience there can be no clear-cut set of rules. The guy who does the (hard, unrewarding) work of collecting and fixing up people's rather ill-behaved postings gets to pass the final judgement on this. That's the only "reward" and frankly it just made me wary that I'd let the wrong things into the image. Many times you can give good reasons (and sma even posted them publicly). But sometimes you can't, or you don't even want to. ("Sorry, newcomer X, but your code's just too shaky, we'll have to pass on that for now") Trouble #1 in my view is that so few people volunteer to do these utterly unselfish chores. Loads of these have to be done to get the stable image up to par with 3.1, and people will absolutely have to change about this, or stable Squeak will give in to the infant death syndrome. Since sma has had good reasons to pass on his duties, in effect no contributions have gone into Squeak since last fall (I think it was). Personally I think the quality of the image degraded badly through 2.9 and 3.0 alpha. Due to the rushed release of 3.0 I think that 3.0 may be the most buggy Squeak image ever, ironically enough, since it's distributed on the book CD. I also have a few ideas about how to organize the system. I'll put them in their own posting. Henrik

1 0

How to get stuff into Squeak?
by John M McIntosh 01 Jun '01

01 Jun '01

Ok, I tripped over this from the FreeBSD people. However the issues are the same. How to get contributions in to the image of stable squeak or just bleeding edge squeak? Thus I'd think as part of our (not that I'm volunteering for this) mandate there should be a position like below. PS Of course I realize we do have rules ie [ENH] [FIX} etc and we do have someone doing the job, but lets clarify how it works as part of the process. At 1:41 PM +0930 6/1/01, Greg Lehey wrote: >From: Greg Lehey <grog(a)FreeBSD.org> >To: developers(a)FreeBSD.org, > FreeBSD Stable Users <freebsd-stable(a)freebsd.org>, > FreeBSD current users <FreeBSD-current(a)FreeBSD.ORG> >Subject: The FreeBSD core team needs your help >Organization: The FreeBSD Project >Phone: +61-8-8388-8286 >Fax: +61-8-8388-8725 >Mobile: +61-418-838-708 >WWW-Home-Page: http://www.FreeBSD.org/ ... >Those of you who have been following the mailing lists will have >noticed (or participated in) a thread bemoaning the continued lack of >feedback from the core team. That thread is still very active, but >one suggestion (made by phk) was to send out a message asking for help >getting things done. It's easy to claim that this would work, but >first we need to know if anybody would be interested. Here's phk's >text: > > HELP WANTED > > The FreeBSD core team is looking for an assistant to help with > tracking and recording the issues being worked by core. > > Responsibilities: > > When a request or question is sent to core@ you reply with an > acknowledgement that it has been received, and nag the core team > until it has been decided on and replied to. > > It is also your responsibility to prepare a summary of core@'s > businnes once per month and after cores approval of the text, to > send this to developers@. This summary should be detailed enough to > show the committers which core members participate in the core > business and which don't. > > You will obviously gain insight into the work of and communications > of the core team, but apart from the above mentioned summary, this > information is of course strictly confidential. > > Working hours: > > All. > > Benefits: > > The FreeBSD project has a comprehensive benefits plan which you will > take full advantage off. The benefits include: Lots and lots of > email. birth control (you wont have time to spend with your SO), > sunburn protection (you wont have time to spend away from the > computer). > >Despite the appearances, this is not an official request for >applicants. We just want to know who would be interested in doing >such a thankless task, and whether it's worth core's time to discuss >the exact terms of reference (does the person get elected, for >example, or appointed?). If you're interested, it's your choice >whether you copy -developers, though personally I'd prefer if you just >replied to core@. > >Greg -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

3 3

Another project - hosting the primary Squeak mailing list
by Doug Way 01 Jun '01

01 Jun '01

There have been several problems recently with the Squeak mailing list (squeak(a)cs.uiuc.edu) not delivering email to everyone. Also, the list currently doesn't have an administrator who participates in the list (or much of an administrator at all). For more details, see Ralph Johnson's comments in this message: http://groups.yahoo.com/group/squeak/message/28661 Given this, I'd propose to make this a Squeak Foundation project to host the list. A couple of people (including Cees de Groot) offered to host the list in response to the earlier mail. (If there were no objections I'd personally be happy to see Cees host the new list, since he's already demonstrated that he can host the Squeak Foundation list and archives, and is an active participant in both lists.) One additional minor thing for whoever is in charge of this... it would be nice to keep the existing Yahoo archives (and Georg Gollman's archives) and carry them over to the new list address, if possible. (I'm not sure if this is possible with the Yahoo archives or not.) Thoughts/objections? - Doug Way dway(a)riskmetrics.com

3 4

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 2001