Squeakfoundation April 2003

squeakfoundation@lists.squeakfoundation.org

17 participants
30 discussions

Delete Entry
by Florian Bruhin 23 Apr '03

23 Apr '03

Dear Webmaster Please delete following old entry from my message board because I never was a so called squatter, and do not own the domain name smalltalk.net anymore. The entry appears in search engines under my name an does hurt my reputation. Many thanks in advance & best Regards Florian Bruhin ENTRY: [Squeakfoundation]smalltalk.net John M McIntosh squeakfoundation(a)lists.squeakfoundation.org Tue, 15 May 2001 16:02:06 -0700 a.. Previous message: [Squeakfoundation]Advogato? b.. Next message: [Squeakfoundation]Away on a trip c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- FYI in case someone wants to pursue this. smalltalk.net is currently allocated to a squatter. It expires Oct 4th 2001. At 3:22 PM +0000 2/9/01, Florian Bruhin wrote: >Delivered-To: stlkjohn(a)vrx.net >X-Originating-IP: [165.222.186.194] >From: "Florian Bruhin" <chinadns(a)hotmail.com> >To: johnmci(a)smalltalkconsulting.com >Subject: Re: smalltalk.net >Date: Fri, 09 Feb 2001 15:22:57 -0000 >X-OriginalArrivalTime: 09 Feb 2001 15:22:57.0345 (UTC) >FILETIME=[2E324310:01C092AC] >Status: > >It is ! > >The negotiating basis for this domain name is USD 10'000.-- > >Best Regards > >Florian Bruhin also maybe flo_bruhin(a)hotmail.com, see whois for information, which as an address and phone number in Mettmenstetten -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== -------------------------------------------------------------------------------- a.. Previous message: [Squeakfoundation]Advogato? b.. Next message: [Squeakfoundation]Away on a trip c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

6 6

Will be away
by goran.hultgren＠bluefish.se 19 Apr '03

19 Apr '03

Hi guys! I am going to be unavailable until friday morning the 25th. If SM would have any hickup during the week you can drop a mail to jonas.ohrn at bluefish.se. Tell him there are instructions to restart SM etc. in a document called "omstart" in my home directory on marvin (the reason for this is that my trip is a secret so I can't give him the instructions). When I get back I will make sure to move SM to Cees care. Also, Doug - this means that I can't help out with compiling the 3.6 plan until friday earliest. regards, Gran

1 0

Open letter to the harvesters
by Stephane Ducasse 16 Apr '03

16 Apr '03

Hi guys I'm diving in systemDictionary and other dark places of Squeak and I would really appreciate that in the future you ***REJECT*** any goodies, cool add-ons that violates basic OO principles. Such as: - Favor subtyping versus subclassing: a Tool should not inherit from List. A tool is not a List it is composed from a list - Avoid: Direct access to Smalltalk - Avoid: Direct access to super super super instance - Avoid: use of super with a different selectors - Avoid: Adding methods to the wrong places - Avoid: Violate basic layering principles - Add PopUp in DOMAIN classes (SmartStreamRef should not refer to PopUp, this is the client of SmartStreamRef to do the work,) - Classes that mixes UI and Domain - trash classes Sorry I had to say that, the OO programmers inside me what exploding..... Stef Sometimes I feel sad but this is fun to clean..... Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes "The best way to predict the future is to invent it..." Alan Kay. Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

1 0

RE: [Squeakfoundation]License Poll
by Daniel Vainsencher 15 Apr '03

15 Apr '03

Brent Vukmer <bvukmer(a)blackboard.com> wrote: > Hmm.. What Daniel did was not what I intended -- I meant for people to just put their name under one license. An if I don't care between MIT and BSD, but strongly object to artistic license? By rating, you can get a more expressive poll, and there's a way to treat it as a fair election. > I realize there are a whole bunch of issues here, including sub-licensing. It just seemed like it would be helpful to get a sense from the community of what kind of license would be preferred.. I agree it's a good idea, but the results will be more meaningful if they really refer to *kinds* of licenses, and not specific licenses, which we probably can't have. Daniel

1 0

RE: [Squeakfoundation]License Poll
by Brent Vukmer 15 Apr '03

15 Apr '03

Hmm.. What Daniel did was not what I intended -- I meant for people to just put their name under one license. I realize there are a whole bunch of issues here, including sub-licensing. It just seemed like it would be helpful to get a sense from the community of what kind of license would be preferred.. Goran, I'd be happy to help you pull together info to update the license FAQ. > -----Original Message----- > From: goran.hultgren(a)bluefish.se [mailto:goran.hultgren@bluefish.se] > Sent: Monday, April 14, 2003 7:19 PM > To: Discussing the Squeak Foundation > Subject: Re: [Squeakfoundation]License Poll > > > "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > > http://swiki.squeakfoundation.org/squeakfoundation/100 > > First of all I don't understand this page at all. What are > the numbers? > Perhaps Daniel misunderstood it, I don't know. > > Furthermore, this page below that Brent just made > unfortunately makes it > sound much simpler than it is. > > http://swiki.squeakfoundation.org/squeakfoundation/87 > > It doesn't really matter if we get Apple to change their > license. Apple > only owns a small part (I have heard the number 20% - accuracy unknown > but you get the point) of current Squeak and they can not change the > license for the rest. And who owns the major part of the rest? Have a > guess. And do we really want to knock on that door? Personally I would > say no. > > I would be much more interested in investigating sublicensing staying > within Squeak-L. > > regards, Göran > > PS. I also have an old thread with a license FAQ draft I once wrote > collecting dust. Should polish it up and complement it with the facts > that we have learned this time around - there were a few eyeopeners - > like for example the simple fact I outlined above. And then we should > put this on minnow IMHO. Brent, if you are interested - could you help > me out sorting through it all?

1 0

Re: [Squeakfoundation]License Poll
by Daniel Vainsencher 15 Apr '03

15 Apr '03

Good points. Maybe Daniel didn't misunderstand, but interpreted it loosely ;-) I just put my rated preferences, as in a condorcet vote. Anyway, Goran is right in that the options should probably be limited to what appears to be our best bet, which is sublicensing. Considering which, we need to find out our real, precise legal options (probably by hiring a lawyer). So maybe the real question is "what are peoples preferences between the targets we might be able to achieve?" under those constraints. As in "DFSG compliant", "OSI Compliant" and "Leave it as is". Daniel goran.hultgren(a)bluefish.se wrote: > "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > > http://swiki.squeakfoundation.org/squeakfoundation/100 > > First of all I don't understand this page at all. What are the numbers? > Perhaps Daniel misunderstood it, I don't know. > > Furthermore, this page below that Brent just made unfortunately makes it > sound much simpler than it is. > > http://swiki.squeakfoundation.org/squeakfoundation/87 > > It doesn't really matter if we get Apple to change their license. Apple > only owns a small part (I have heard the number 20% - accuracy unknown > but you get the point) of current Squeak and they can not change the > license for the rest. And who owns the major part of the rest? Have a > guess. And do we really want to knock on that door? Personally I would > say no. > > I would be much more interested in investigating sublicensing staying > within Squeak-L. > > regards, Göran > > PS. I also have an old thread with a license FAQ draft I once wrote > collecting dust. Should polish it up and complement it with the facts > that we have learned this time around - there were a few eyeopeners - > like for example the simple fact I outlined above. And then we should > put this on minnow IMHO. Brent, if you are interested - could you help > me out sorting through it all? > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

License Poll
by Brent Vukmer 15 Apr '03

15 Apr '03

http://swiki.squeakfoundation.org/squeakfoundation/100

2 1

Re: [Squeakfoundation]How to proceed for the kernel cleaning harvesting
by Daniel Vainsencher 09 Apr '03

09 Apr '03

Ok, now we're talking. Send in a mail with changesets 9,7,4, and I'll approve them, I've already seen that part. The others until 10 are either tests (which no longer go into the image, since we'll be removing SUnit into a package), or your internal tools, or already in the image. When you've reviewed another bunch, let me know which. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Ok so let us know. I think that making a try on the current changes > could help to tighten the process and see if we can work this way. > What I suggest is the following (depending on the availability of > Noury's and Roel's time there is a deadline for ESUG for the end of the > week) > > 1. we proceed to an internal/external review as soon as possible. > 2. we let you know. > 3. you try to assess the changes as fast as you can and report how we > can improve communication. > 4. If in the meantime you/harvesters evaluate the proposed changes > which are simple (the only design point is that we introduced a new > class for the navigation and UI related actions that the tools can > reuse), and accept them we just pass to the next ones. > > > Stef > > > > Prof. Dr. Stéphane DUCASSE > http://www.iam.unibe.ch/~ducasse/ > "if you knew today was your last day on earth, what would you do > different? ... especially if, > by doing something different, today might not be your last day on > earth" Calvin&Hobbes > > "The best way to predict the future is to invent it..." Alan Kay. > > Open Source Smalltalks: http://www.squeak.org, > http://www.gnu.org/software/smalltalk/smalltalk.html > Free books for Universities at > http://www.esug.org/sponsoring/promotionProgram.html > Free Online Book at > http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Re: [Squeakfoundation]3.6 MasterPlanner!?
by Daniel Vainsencher 09 Apr '03

09 Apr '03

Ok, Goran, I can see when I'm beaten :-) Since I'm still not interested in taking this as a fixed role, and you've decided it's needed, I don't mind if you and Doug (or someone else) take it up. Heck, I'll even help along occaisonally. While I'm at it, I'll try to subvert it from a "Plan", to a "statement of the Guides perceived best direction for Squeak n.m" :-) What do I think should happen in 3.6? I think the most important thing for this version is not to get to a specific goal, but to get a few processes going. Here's a partial list. * Restart harvesting using the new process, hopefully removing some backlog. * Get the simulator fixes by Craig back in. * Start merging Anthony's work. Run time stuff is a good place to start. * Start merging MCP's work, as they start to send it to us. Same for KCP, except I for one am less aware of what they're working on, and have less of an idea as to whether they'll have something ready to merge anytime soon. * Networking/Streams/Sockets is something where a few people have put in quite a lot of work. Find a way to start merging at least some of this stuff, in small pieces. Ideally, we should do everything possible without breaking networking applications. Then break networking (start raising exceptions instead of dialogs) in 3.7alpha. * SM 1.1 Daniel goran.hultgren(a)bluefish.se wrote: > Hi all! > > Well, it seems we lost a thread here somewhere. 3.6 is starting up and > we really need to have a Plan for it. No, don't say "we need no plan, > just a date" because that just isn't true. > > We need *both* IMHO. 3.6 is really going to shake things around so I > repeat - We Really Do Need A Plan - ok? > > Good, now that we have that out of the way :-) we also quickly realize > that to get a plan we need someone who crafts it. No, don't say "we > don't want somebody telling us what to do" because that isn't the way it > should be done. > > The plan should of course be worked out on squeak-dev through > discussions (as always) but somebody needs to moderate, collect and > formulate it. So, without further ado - who takes this assignment? > > I have the following suggestions: > > - Ned. But Ned is worth so much more doing harvesting (?) or other > complex debugger-digging, and I don't think Ned really "likes" the > moderation role! :-) > > - Tim. Tim has a lot of good knowledge when it comes to the tougher big > enhancements we have lined up in front of us possibly in part for 3.6 > (think Anthony), what do you say Tim? > > - Me and Doug. Since Daniel (otherwise an obvious choice) has indicated > that he isn't interested (I got that through "readsay") the last > alternative is a combination of me and Doug. We tend to agree on most > things and we are already lined up to take this assignment if Ned and > Tim says no. > > Note: I didn't propose Craig here becuase I think he is busy with Squat > etc and not really interested in this. Just a guess. > > Ok, so lets be quick here - Ned, Tim or Me+Doug? And please don't start > discussing the need for someone doing this - Doug wants someone and he > *is* in charge of the update stream so darnit, just accept the fact that > we need someone doing this. :-) > > As soon as we have this decided the MasterPlanner(s) should probably IMO > start a quick "round up" thread on squeak-dev to collect ideas on what > 3.6 will/should/could be made of. > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 13

Re: [Squeakfoundation]3.6 MasterPlanner!?
by Daniel Vainsencher 07 Apr '03

07 Apr '03

I agree that we should make sure removal of a package doesn't break either it or other stuff in the image. I don't know whether there's a point in separating the refactorings from the removal package. After all, the removal package is supposed to get rolled into the updatestream. The Celeste removal does the refactorings required and then removes the package, which seemed reasonable to me at the time. If someone thinks this is a problem, I don't mind reworking it so refactorings and removals are separate. Other quality criteria - we should encourage package maintainers to never override code, but we can't enforce it. Right now, there isn't even a warning when loading a package that overrides code. We should provide the tool support first, start pushin the rule later. Agree on Accufonts now, further developments later. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote: > > >> * Apply some number of package removals to the image. (Perhaps you > >> were > >> taking this one for granted.) I don't think we should try to plan > >> exactly > >> which ones will be removed, but we could set a rough goal of a > >> certain number > >> of MB removed from the image, perhaps. > > Before any goals relating to size, number or whatever we should > > establish a _quality_ goal. For example, no removal package is much use > > unless the package can subsequently be installed and actually work. > > This > > relates to the problem I'm having right now with filing out a changeset > > not being even close to filing out the classes individually. Without > > tools that let package maintainers work sensibly we're going to be in > > trouble pretty quick. > > Yes, quality of package removals/additions should be more important > than making sure we reach a specific target number/size of removals. > The size goal for removals could be more of a prediction than a > must-have goal. > > As far as quality criteria for package removals go, we'd have the usual > harvesting criteria as a minimum (externally tested, etc.), which > should hopefully cover things like the package addition being > installable and generally working. > > One other quality criteria for package removals/additions that I was > wondering about: Should we have a strict rule that package removals > can only remove classes and (class-extension) methods, they cannot > overwrite any methods? Conversely, package additions could only add > classes and (class-extension) methods, no method overwrites. This > would of course often require that some refactoring be done in > preparation for the removal, so that registering menus were used, etc. > (And we already have a plan that refactorings should be done prior to > removal, anyway.) However, having this as a general rule might be > unrealistically strict. (?) > > >> * Remove the Apple fonts from the image, and replace them with > >> functionally > >> similar bitmap fonts. We would still need to decide whether this > >> meant the > >> Accufonts, or a move to ISO-8859-1. > > Simplest first I'd say. Just get the Apple fonts out and _something_ > > in. > > Accufonts seem reasonable to me. One could consider use of TTFs since > > there are quite a lot of reasonable TTF free fonts around. That would > > involve some decision on $_ etc. :-( > > I agree that Accufonts seem reasonable. We'd have to agree that the > license was acceptable and Squeak compatible (which I think it is, > IMO). Even after adding the Accufonts, we could have a move toward > supporting ISO-8859-1, as soon as someone did the required work. > > >>> * Restart harvesting using the new process, hopefully removing some > >>> backlog. > > Some explicable process and cleaning up of swiki pages would help here. > > I tried a week or two ago and got lost in a forest of oldlinks and > > irelevant pages. And at the end I still didn't understand where to send > > code I wanted reviewed or to approve. > > ... > > Yes, I've been meaning to clean these pages up and have a good summary > of the process... I will try to get to this ASAP. > > - Doug > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

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 April 2003