Squeakfoundation June 2001

squeakfoundation@lists.squeakfoundation.org

17 participants
15 discussions

The Natives are Restless
by Dan Ingalls 12 Jan '02

12 Jan '02

Folks - Speaking as one who wants to see SqF take advantage of the community urge for a truly open Squeak, I have some concern for the pace of bringing SqF into existence. What I see is the Stable Squeak experiment reaching completion in not much more time than we have spent deliberating over the definition of SqF, and a number of people who *would support* an SqF looking elsewhere for it when it is right under their nose. Why? Because we haven't yet declared the existence of SqF. With no disrespect for the goals or even the process represented by the dialog on this list so far, what I'm wondering is: Why wait for all the chaordic process and exact definitions to declare the existence of SqF? Instead, why not Declare that SqF exists, Appoint a number of "acting" officers Declare a couple of active projects one of which is to converge on a more formal def of the organization I think I could even raise a few $$ to carry us through the interim period As token "Old Fart" I'm willing to be put in any role. I'll even appoint myself and everybody else if no one wants to do this. And I'll make up a project list (you can guess from prior messages). That doesn't sound very democratic ("open"), but I'm just wanting to "jump-start" the organization so that it can be accreting respect and definition while it is still being born, and so that we can channel the open Squeak urges into a coherent future, rather than fighting fires on the Squeak mail list and dissipating energy in twenty splinter efforts. What do others feel? - Dan PS: This may sound critical, but I don't feel that way at all. I'm happy with the current participants and process. I just feel the need for an interim solution.

13 18

Automated monthly posting
by Doug Way 27 Jun '01

27 Jun '01

One other question about the posted-monthly mini-FAQ: Would someone be able to do the actual automated monthly posting (to the main Squeak list), if I provide the FAQ text? Or are there free services available that will do this? It should be a pretty trivial task for someone with access to a Unix or other server to set up a cron job to do this, but I don't happen to have access to one at the moment. Thanks, - Doug

5 5

Concrete SqF projects
by Andreas.Raab＠gmx.de 17 Jun '01

17 Jun '01

Folks, Over the last weeks (basically as long as I'm following this list) there have been a number of (quite high-level) discussions about purpose and principles of the SqF on this list. While I feel that these discussions are useful and necessary, I would like to see a start of more concrete projects. Perhaps it's helpful to try it the other way around and discuss the principles in the context of concrete projects (where the practical issues will ultimately arise). While it may sound complicated to start projects in a phase where no SqF (at least formally) exists and where we also have to avoid certain issues (like money changing hands) I think that there are a number of projects that we could basically start right away, which would benefit the entire Squeak community, and also show that SqF is not only a club for debating chaordic principles (just kidding ;-) Starting some of those projects might also help finding (at least interim) project officers for some of the issues that will stay in the long-term focus of SqF. So what could we start with in practice?! The three issues which I think are obvious no-brainers for the SqF are: * Establish a web-presence of Squeak image releases Meaning a central list pointing out what versions exists, when they were released, what VM to use with it, an FAQ per release, etc. etc. etc. * Establish a web-presence of Squeak VMs Meaning a central list of compiled VMs that are available, references to the source code for each version, telling people that "If the VM for version XYZ hasn't been compiled on ABC, please drop us a copy", FAQs for VMs/platforms, etc. etc. etc. * Establish a web-presence of Squeak packages [GOODIEs] [ADDONs] etc. Meaning a central list of available packages, goodies, add-ons, telling people what this thing does, the Squeak version it has been designed for, the versions it has been successfully tested on, perhaps a swiki for posting bugs etc. The above three are obvious issues that SqF needs to deal with concretely. They do not require any programming, they do not require money, all they do require is a couple of dedicated people for setting up the infrastructure, for making up some web pages, write a few emails, and - most importantly - keep it up-to-date. Also note that the above does require almost no server space - virtually everything is available at UIUC or on some other server world-wide. Later we can think about mirroring this stuff at some SqF server but we don't need this to get started. BTW, I'm thinking about the above mainly as a - critically needed - reorganization of the stuff that's available at the GATech Swiki (perhaps on a more robust server ;-) since there are tons of infomation available at the swiki - they just cannot be found. In addition to these projects we may think about a few others. Two that come to my mind are (there may be more - I'm sure Paul has suggestions ;-) * Review and coordinate a migration of Stable Squeak into the main release Although not yet released (but according to John it'll happen on the weekend) I think that this could be a very valuable task since it brings together the best of both worlds. * Write and post a monthly "Mini Squeak FAQ" to the mailing list For one thing, this FAQ would help many beginners to find information faster (all the mini FAQ has to provide is pointers to URLs answering the questions). For another thing it could be "brought to you by the Squeakfoundation" thus raising the visibility of the SqF and establish it as a central and known entity in Squeakland. Please note that because of my association with Squeak Central I am not volunteering for any of the stuff. If you want me to, then say so and I will, but I'd rather see the community taking the lead here. Cheers, - Andreas -- Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

6 9

Re: [Squeakfoundation]Process for volunteering (was Re: Concrete SqF projects)
by cg＠cdegroot.com 16 Jun '01

16 Jun '01

dway(a)riskmetrics.com said: > Is there a process for volunteering for projects (and mini-projects)? Probably the easiest way is to announce the project as being a project on the Swiki front page and put your name on the page behind it. Like the Camp Smalltalk project pages, I guess. -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B

3 4

Squeak Foundation update
by cg＠cdegroot.com 13 Jun '01

13 Jun '01

A bit late, here's another update. A short one: nothing happened :-). Personally, and I hope people agree, I've stopped pushing the Squeak Foundation until Squeak Central is settled down in whatever their new place is. SqF is, IMO, important, but not so important that we should force the issue before SqC has the time for it again. So, as far as I'm concerned, we should keep discussing SqF issues on the mailing list (and go to http://swiki.squeakfoundation.org/stablesqueak and test the first releases of Stable Squeak!) but I suggest we wait until SqC signals readiness before continuing with important SqF issues (like web consolidation, modularization, and general organizational matters). -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B

1 0

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

09 Jun '01

Joseph Pelrine <jpelrine(a)acm.org> wrote: > You're right, modularity is not everything, but it's a big step in the > right direction. If you want to check out some good reference sources, > start out by reading [snip yummy references] > More recent work can be found in Gamma et al.'s Paper on TeamStreams, > presented at XP 2000 (I'm not sure whether there's a web link to it), I think this is it - http://www.xp2001.org/papers/Chapter9-Lippert+alii.pdf > Most of the work I'm doing for Stable Squeak is involved in implementing > these and other ideas aimed at managing modularity in Squeak. I'm on a roll > now, and may be able to show something next week. Ok, fine, we're *already* salivating. Why are you wasting time answering silly emails? go code! ;-) > On the other hand, code quality can't be learned from a book. I benefited a > lot from having had access to world-class Smalltalkers who would whack me > upside the head if my code was crappy. It became a matter of pride for me > to write clean code. If you're alone, SUnit and full-strength SmallLint > help a lot. I miss having the RB and friends. One thing I missed in those was something telling me my code is too complex - enter the HintingBrowser. Someday soon I hope to have all those together on one image with Celeste... > Cheers > Joseph Daniel

4 4

Operating procedures for a "burn the diskpacks" list?
by Paul Fernhout 08 Jun '01

08 Jun '01

All- Since a Squeak "Community" Foundation would be likely to support subgroup mailing lists which may constitute temporary or permanent branches related to Squeak, it seems relevant to discuss operating procedures and legal charters that may be relevant to such lists. Background: I may eventually request a new mailing list under the Squeak Foundation for "blue" plane work I am interested in. Specifically, it would be for building up a "burn the disk packs" system inspired by Squeak from the ground up through an open community process under a more "standard" license (BSD). It is likely Squeak itself as-is may be used to provide scaffolding to help build the next generation system. Both technical "how to" and social "why to" commentary would be encouraged on the list. The system I am contemplating would have a more prototype flavor, would generally favor transparency over efficiency, would support a notion of versions and permissions for changes, events, and transactions, and would support multiple syntaxes (Smalltalk, Scheme, Python, Forth). You can see hints of it in submissions I have made to the Squeak list in terms of the Pointrel Data Repository System, LinksWorld, and Embedded Squeak. Before actually setting up such a list myself, or requesting it be set up (hi Cees! :-), I want to first discuss its operating procedures with people on this list. Here are what I see as the minimum needed for the list charter to produce copyrighted works with at least a reasonable amount of "due diligence". These procedures may be useful for other Squeak Foundation lists, and so I think it generally appropriate to discuss them here, even if I do not proceed with these plans. I would especially appreciate it if anyone with access to legal advice [Dave T?] could get get such a mailing list charter reviewed or imporved, especially considering that contributions will come from individuals in many nations. Note: the choice of license [BSD] is not fixed in stone yet, and I might consider GPL or LGPL or Apache. The work would definitely not be under the Squeak license as is. I would also consider handling the licensing provision differently than by fiat [i.e. allowing various incompatible licenses and sorting it out with config maps.]. ====================== [DRAFT PROPOSAL for a mailing list charter for comments] The intent of this list is to discuss and create new works inspired by the potential demonstrated by Squeak. Here are a few restrictions on the list required as legal due dilligence in creating a new collaborative work by many individuals. Submissions are only accepted by people who have joined the mailing list. By joining the mailing list, every contributor agrees: A. By the act of submitting an email or other future unit of information exchange to the list, the author grants a irrevocable, royalty-free, worldwide license allowing redistribution of that contribution in total in any media, as well as quoting in derived works with attribution. B. By the act of submission of code or other "know how" to the list, the author grants sufficient irrevocable royalty-free, worldwide permission for that code or other "know how" contribution to be placed under a [BSD-revised] license. C. By the act of submission of other "creative work" to the list such as without limitation a logo or bitmap, the author grants a irrevocable, royalty-free, worldwide license allowing redistribution in total in any media, and unless at the time of submission announces the aesthetic work may not be modified without their permission, they also grant permission to distribute derived works (with attribution). D. Contributors assert that to the best of their knowledge either: 1. their contribution is original, and they have any required permission needed to make it from any relevant third party such as without limitation their employer, and it does not infringe any third parties rights, or 2. any non-original contribution is clearly labeled and is accompanied by all needed rights to contribute it to the list for use under the list's licensing policy. E. To be clear, contributors may post emails with links to other work not submitted to the list which is compatible with or relevant to the work developed on the list. Such links shall not cause the work so linked to be considered to be contributed under the terms of the list. F. Should contributors discover one of their contributions is in some way infringing on a copyright or patent or has some other legal problem, they will notify the list of such issues immediately. G. It is understood each contribution comes with NO WARRANTY to the greatest extent possible under applicable laws. H. If the contributor is a minor under local jurisdiction, they have gotten permission from their guardian for participation on the list under these terms. ====================== Comments on the operating procedure anyone? [Please save comments on the project or its advisability for the new list itself.] Also, do people have pointers to similar or better list charters? -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

3 4

List topic focus
by cg＠cdegroot.com 05 Jun '01

05 Jun '01

We've been wandering all over the topic map on this list for the last couple of weeks, and that was Good, because quite a bit has been accomplished. However, I do agree with Joseph Pelrine's remarks on another mailing list (StSq) that we really risk fragmenting too much if all these lists starts treading on each other's ground (so to say). Please let's leave the SqF for organizational matters (the SqF itself, things like web consolidation, etcetera). That bores the hell out of a lot of people on the main list, so there's good reason for keeping it separate. The Squeak main mailing list is the correct place to discuss technical and architectural matters. If we aren't careful where about selecting a list to post, we risk cross-posts, fragmented discussions, etcetera. I think we're doing very good work here, it's a shame to risk blowing up the Squeak community in factions. Regards, Cees -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B

1 0

An architecture for sustainable Squeaking
by Henrik Gedenryd 04 Jun '01

04 Jun '01

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

6 12

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

04 Jun '01

Joseph Pelrine <jpelrine(a)acm.org> wrote: > At 18:05 02.06.2001 , danielv(a)netvision.net.il wrote: > >Joseph Pelrine <jpelrine(a)acm.org> wrote: > > > You're right, modularity is not everything, but it's a big step in the > > > right direction. If you want to check out some good reference sources, > > > start out by reading > >[snip yummy references] > > > More recent work can be found in Gamma et al.'s Paper on TeamStreams, > > > presented at XP 2000 (I'm not sure whether there's a web link to it), > >I think this is it - > >http://www.xp2001.org/papers/Chapter9-Lippert+alii.pdf > Definitely not that paper! I don't know what those guys think they're > doing, but it ain't XP. Why not? >However, they have a reference to Gamma et al.'s > paper in there. Yup, that (and being in XP200X) is what tricked me. My bad. > >I miss having the RB and friends. One thing I missed in those was > >something telling me my code is too complex - enter the HintingBrowser. > >Someday soon I hope to have all those together on one image with > >Celeste... > > Huh? I use the RB all the time for my Squeak work. I even call it from > SUnit to wrap quality control tests in my work. Contact Bob Hartwig - he > did the port, and is doing the StSq version too. Last time I looked, the Squeak port wasn't fun(ctioning). I tried in the StSq prerelease, and extract method (the smoke test) doesn't work. First codePane wasn't set to the TextMorph, after fixing that manually. The refactoring itself asserted in a case that should have worked. You're saying this should work? > - Joseph Pelrine [ | ] Daniel

3 2

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