Squeakfoundation January 2003

squeakfoundation@lists.squeakfoundation.org

20 participants
15 discussions

Possible extra text for Welcome window in 3.4
by Doug Way 24 Mar '03

24 Mar '03

Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma. I thought it might be helpful to at least have a mention of SqueakMap somewhere in one of the introductory windows of the image. So, here's a proposed paragraph blurb introducing SqueakMap. I thought it might be best located in the "Welcome to..." window, after the very first section but before the "Morphic" section. (The "*here*" link would be a DoIt link which would execute "TheWorldMenu openPackageLoader".) Or, it could go in ReadMe.txt or somewhere else, but I think the Welcome window might be best. Feel free to improve the wording, etc. (In theory, we could also have an introduction to the Guides, but I'm not sure that's as important. There's not really any mention of Squeak Central in the intro windows, anyway.) - Doug --------------------------------------- <bold>What's new in Squeak 3.4</bold> An exciting feature which has been made available in the 3.4 release is SqueakMap, a package catalog system for Squeak. As of this release, over 100 packages/applications have been added to SqueakMap by members of the Squeak community. You can easily browse and install these packages directly in Squeak by using the SqueakMap Package Loader, which is available from the "open..."/"Package Loader" menu (or, by clicking *here*). For more information on SqueakMap, see *http://minnow.cc.gatech.edu/squeak/squeakmap*.

5 16

The update stream, 3.4, 3.5, harvesting
by Doug Way 05 Feb '03

05 Feb '03

Hello all. Several items... Just to keep everyone posted, Scott has given me instructions on how to add updates to the Squeak update stream. So, SqC has "handed over the keys" so to speak, and I am now the official maintainer of the update stream, more or less. Of course, my manual handling of the update stream is somewhat temporary... the idea being that with the upcoming harvesting tool, the addition of items to the update stream will become more automated, with a process known to the community. (Although it will probably always require some manual tweaking on occasion.) I'm about to start working on this harvesting tool (based on SqueakMap 1.05), but it's hard to say when it would be ready to use. I'll shoot for having something ready within a month or so. (with input from this list, of course) But in the meantime, we probably shouldn't let 3.5alpha stagnate, so I'm going to add some harvesting tables of recent submissions to the ol' superswiki pages one more time. The harvesters/guides/SqC can then review items for inclusion in 3.5alpha, as was the process several months ago. I'll post again as soon as I've added these tables. Which brings up a question: Who in general should be able to review/approve items to be harvested? I would say the current harvesters + the guides + the SqC folks would be a good starting point. But there are other qualified Squeakers out there, too. For now, if someone else really wants to volunteer to help with harvesting, I could add them to the list of harvesters, and they can help with the swiki tables. However, once the better harvesting tool is in place, harvesting should be somewhat easier (editing the swiki tables is a bit of a pain), so that might be a better time to get more volunteers. (And yes, eventually, once the image is split up into packages, we want to have different people in charge of approving what goes into each package, and maybe have an update stream for each package, if desired. But the first version of the harvesting tool probably won't be package-specific yet.) Aside from harvesting, there are more general plans which need to be discussed for 3.5. Such as how much of the image should we try to break off into packages, which larger enhancements should be considered, what would be an approximate release date, etc. Someone other than me should lead this discussion, I have enough to do myself. ;-) Daniel led some discussion on this in the past, so perhaps he could continue. In other news, the 3.4gammaOne image has been out there now for over a week. There haven't been any major bugs reported with it, so I'm thinking that we could probably make this the 3.4 final image in a few days, and then release it on squeak.org. (Of course, a lack of feedback may also mean that not many folks have tested it. I would encourage everyone to at least give it a quick test. The differences in the image itself are relatively minor compared with an image updated from 3.4beta, though... e.g. the contents of the welcome windows have changed a bit. See ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.4gamma/ ) As we approach the 3.4 final release, we'll want to make sure a few things are in order: * Make sure that the VM's for various platforms (Mac & Windows at least) are decided upon as the 3.4 VM's to be included in the bundles on squeak.org. Bruce O'Neel would then put the bundles together and update the squeak.org download page accordingly, when we are ready to release. * Make sure the 3.4 release is announced in all the right places, as described on the "External Relations" SqF swiki page. Cees de Groot is in charge of this. * Anything else? Ok, I think that's it for now. - Doug

3 5

[ENH][3.4] Enhanced IRC client
by Robert Withers 20 Jan '03

20 Jan '03

all, I realize it is *very* late in the game, but the standard IRC client is lacking. The enhanced irc client, from Steve Wessels I believe, is proven as a file-in. I think it would really help new users access the #squeak channel in style, so that we can bring them up to speed faster. A recent newbie, by the nick of oxblood, came on and saw the light with examples of numeric auto-coercion and gained a fast exposure to the browser features. Please consider a fast track exception on including this, since it goes directly to helping the beginners that these releases are ultimately for. One change should be to include irc.freenode.net:6667 as the default irc server in the Profile, with perhaps an initial pop-up (Profile Dialog) when the irc client is started. The profile could have a checkbox to auto-logon, whenever the client is started. thanks, rob

1 1

Re: [Squeakfoundation]Failed to clean virus file id4[2].pif
by Maarten Maartensz 16 Jan '03

16 Jan '03

Hello, Thanks for notifying me - BUT: (1) I did NOT send a file to squeakfoundation lately (2) I have meanwhile - over the past several months - received several mails that started "[squeakfoundation"] but were obviously by Nigerian frauds (i.e. "we give you several millions of dollars if you help us pass some money by giving us your details" - if you are moron enough to believe this). I neglected (2) since I take it everybody on this list is clever enough to see through it, but it is obvious that the present list is abused. Also, I repeat (1): I did NOT send a file to squeakfoundation lately. However, I am interested in knowing for sure that my email address is abused. Regards, Maarten. ----- Original Message ----- From: <postmaster(a)lists.squeakfoundation.org> To: <squeakfoundation(a)lists.squeakfoundation.org> Sent: Thursday, January 16, 2003 6:52 PM Subject: [Squeakfoundation]Failed to clean virus file id4[2].pif > The file you have sent was infected with a virus but InterScan E-Mail VirusWall > could not clean it. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation > >

1 0

Ameritrade has received your e-mail inquiry (KMM12360583V39570L0KM)
by Ameritrade Customer Service 16 Jan '03

16 Jan '03

We thank you for using this channel to contact us. It is our goal to provide you with unsurpassed e-mail support. Your inquiry has been received and an Ameritrade representative will respond shortly. The case number for your inquiry is 5864189. Please refer to this number in future correspondence regarding this issue. The answers to many questions can be found online by clicking on the Help? Button in the blue bar at the top of each page, or the FAQ link found under the Education heading on the yellow side menu. Thank you for choosing Ameritrade.

1 0

Failed to clean virus file id4[2].pif
by postmaster 16 Jan '03

16 Jan '03

The file you have sent was infected with a virus but InterScan E-Mail VirusWall could not clean it.

1 0

condenseChanges glitch
by Scott Wallace 16 Jan '03

16 Jan '03

When putting the finishing touches on a "freshly built" 3.4gamma, I had occasion to condenseChanges twice, and encountered an error, or rather a hang, the second time. I tracked this down to a bug in update 5158clsCommentFixes, which I have now hastened to fix with update 5169commentFixFix, which is currently available on the internal servers. Unless there are objections, I would expect to externalize that update on Wednesday night (15th January,) and subsequently, also Wednesday night, finally post the "fresh" 3.4gamma image, with changes properly condensed ;-) Cheers, -- Scott

2 1

Re: "Internal" updates (was: RE: [Squeakfoundation]Possible extra text
by Daniel Vainsencher 16 Jan '03

16 Jan '03

I'm not sure which would be better, but I'm sure of this - if you update into alpha it means you can afford to d/l a fresh image and update again after we've fixed the mess. I think we really should agree to some rule like 1 reviewer for fix/2 for ENH, etc, since we're not very consistent in who's available to handle these things, so lots of coordination will hurt us. OTOH, we should also have a veto rule - anyone can say no, and that stands until 3 agree otherwise or he changes his mind. We want to be able to move forward quickly, but it's important not to become desensitized to what goes in. As an example I noticed late that I'm not really very happy with the fix we accepted for UUID. It makes the quality of UUIDs hard to predict, SM, AFAICT, could live without that being in the core, and, IMO, we just can do better - just say no to quick satisfying hacks that'll hurt us in the morning. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Monday, January 13, 2003, at 01:23 PM, Tim Rowledge wrote: > > > goran.hultgren(a)bluefish.se appears to have written: > > > >> Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > >> [SNIP] > >>> I think we should definitely convert, for the 3.5 cycle, to one update > >>> stream. We already have mechanisms to protect the wary - stop updating > >>> when you get to a "Continue updating for 3.5a" question. > > [snip lots] > > The problem I have with this approach is the high probability of needing > > to retract changes. How? > > a) take it out of the update stream and tell people to restart from the > > last release? Oh, and what about intermediate changes that relied on > > some parts of the retracted one? > > b) add another update that undoes it; with the added need to compensate > > for any > > intermediate changes that have touched the same area? > > I think it would probably have to be option b. That's what SqC has done > with changes that made it out to the public stream which then had to be > reverted. > > Getting rid of the internal update stream sounds okay to me, actually. > If the number of "problem" updates (in need of reverting) doubles or > triples relative to when SqC handled things, I don't think that would be > be a big problem. We would have retractions more frequently. > Intermediate changes touching the same area would be reasonably rare. > > > I posutlate that we need several holding areas: one (like the current > > sqfixes page but up to date) for offered changes, another for changes > > considered of interest by at least one guide and another for changes > > agreed on by at least two guides. This last would essentially be the > > internal update stream used for a last opportunity to check things. It > > _could_ be seen as an alpha stream and made accessible to any brave > > fools willing to put with whatever is the chosen solution to the above > > problem. > > Something equivalent to this might be good for the harvesting tool being > written. But do we want to do this in the next month or so before the > tool is finished, with the sqfixes pages? > > For bug fixes, I tend to agree with Goran that approval by one > harvester/guide (who is NOT the author of the fix) is probably > sufficient. Perhaps for enhancements, approval by two guides makes more > sense. With the harvesting tool, we could do some cool stuff like > having approval of the quality of the source code be separate from the > approval of the appropriateness of the fix/enhancement. > > But in the meantime, we need to figure out what to do in the next few > weeks, before any harvesting tool is ready. Should we go ahead and make > some sqfixes swiki tables just to get some important fixes/enhancements > in over the next few weeks? > > - Doug > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

Re: "Internal" updates (was: RE: [Squeakfoundation]Possible extra text
by Daniel Vainsencher 14 Jan '03

14 Jan '03

As Andreas said, having any sort of separate pre- stream that is not heavily used is useless. A pre- stream's purpose is to generate quick, expert feedback for the stream without breaking things for a lot of people. This worked well when a group of expert fulltime Squeakers we're always using it. I have used a little early on, but then became busy, and did almost no Squeaking at all. Anyway, the way we're working now, it's broken, and merely delays our getting serious feedback from the list. I think we should definitely convert, for the 3.5 cycle, to one update stream. We already have mechanisms to protect the wary - stop updating when you get to a "Continue updating for 3.5a" question. We could improve one these as mentioned, either using a special marker, or a whole new SM-like update mechanism, but we certainly don't have to wait for either of those. I think SM based update streams would be great for the packages themselves, and possibly maintainance of the Image release could benefit from this mechanism, but I propose we don't tangle these until such a mechanism is pretty well proven. IOW, I propose we * finish up 3.4 as we have so far, * for 3.5 simply convert to a single update stream, so people can decide their own exposure, * and consider alternatives only for the version after 3.5. Another technological fix we should consider is some awareness features notifying people when the updatestream changes - mechanizing the [Updates] mails so that people know when something new is in. Real Alpha pilots might also set their image to pull updates every hour... Daniel goran.hultgren(a)bluefish.se wrote: > cg(a)cdegroot.com (Cees de Groot) wrote: > > Doug Way <dway(a)riskmetrics.com> said: > > >(By the way, Scott just posted the various "fixes before 3.4gamma" updates to the internal update stream today.) > > > > > I don't know what this internal update stream thingy is or who's output port > > you have to kiss in order to get access to it, but I think (exactly for these > > reasons) that it should go. > > :-) I agree Cees but a simple explanation might be in order here - it is > a remnant that we decided to keep until 3.4 is out the door just because > we (or at least I) didn't want to start banging on something and thus > disrupting the "quick" release of 3.4. Since Scott is doing most of the > legwork currently it was easy to let him continue his work as he is used > to. > > But we all agree that there should be no "secret" privileged place for > updates of course. > > > A much better alternative would be to have a marker file on the regular update > > stream indicate the latest 'safe' update (for some value of safe). Cool > > bl33ding edge hackers could ignore the marker, while regular users (using > > 'Update from server') would have their updates stop at the number indicated in > > the marker file. > > > > Then everyone could decide for themselves how bleeding edge they'd like to be, > > and how much they want to contribute to pre-alpha testing. > > > > The absolutely most vital thing if Squeak's to be a success under the new > > model of governance is to make it as transparent as possible. No hidden areas > > for some 'privileged' people, the only privileges we should hand out is > > decision privileges, not information privileges. > > Again I wholeheartedly agree and this is one of the things I really > tried to push in the mission statement. That is also one of the reasons > we keep all discussions on this list and not off list. Consider this a > remnant that will go away very soon. > > I think a focused effort to bring about the new Harvesting tool would be > the best way to proceed. Hacking the update mechanism just seems like a > "hack" that will not give us anything really. We are just about (any > day) to open 3.5alpha and IMHO alpha means on the bl33ding goddamn > hold-on-it's-gonna-blow edge and when we have that stream open I think > we can simply ditch the "secret" internal stream and then just get the > new tool out the door before we try to turn 3.5 into beta (at which > point such a tool will be much more needed). > > Please guys, lets use the new alpha stream as ALPHA is meant to - push > stuff into it and let the ALPHA-testers take the hit. We need to let > FIXes go into it with much less scrutiny in order to keep up. IMHO, the > only scrutiny we really need to do is to verify that it is indeed FIXes > and not additions to the bloating image. > > regards, Göran > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

[UPDATES] Final 3.4beta updates on internal servers
by Scott Wallace 08 Jan '03

08 Jan '03

Dear Guides, Getting very near the end now... I've posted the following updates to the internal 3.4b update servers today. These consist of the items specified by Doug last week, plus two fixes (5158 & 5167) for bugs that recently arose when condensing changes as part of a trial build for 3.4/final and when working with update-server directories in a registering file list. When the last of these updates is loaded, the user is given the option of advancing his image either to 3.4-gamma or to 3.5-alpha. Doug suggests that this "last" batch of 3.4 updates should have only the briefest of pauses on the internal servers before getting externalized, and I agree; so unless objections are heard, I anticipate externalizing these updates on Thursday, 9 January. In the same time frame, hopefully, a "fresh" (as opposed to "evolved") 3.4-gamma image, with updated sample-project content and with standard cleanups performed (e.g. changes compressed) will be posted. Cheers, -- Scott ----------------------------- 5157acornDirFixes2-tpr -- tim(a)sumeru.stanford.edu -- 21 December 2002 Make sure at least one sensible directory appears in directoryContentsFor:. Only affects Acorn machines" 5158clsCommentFixes-sw -- Scott Wallace, Alejandro Magistrello -- 4 January 2003 When condensing changes, preserve not only class comments but also their authoring stamps, for the benefit (e.g) of the class-comment-versions browser. Also, fixes the bug that caused an error when you tried to browse the recent log after a condense changes but before a manual snapshot. Also, restores the ability to file in class comments created in VisualWorks using the #classComment: protocol. Note that 'prior' pointers that point back both for methods and for class comments are lost when a condenseChanges is done. This should be fixed someday. 5159makeSeedFix-dew -- Doug Way -- 6 January 2003 Remove the dependency of UUIDGenerator >> makeSeed on the presence of a TimeStamp class by calling Time totalSeconds rather than TimeStamp current asSeconds 5160morePluginTerm-JMM -- johnmci(a)smalltalkconsulting.com -- 9 August 2002 when we run as a browser plugin we need to know when to terminate the interp main loop. This is done by checking a flag and invoking plugInTimeToReturn which becomes a C macro to issue the return. This was done at on a long unconditional jump, or execution of a new method. However in the case were Squeak is idle, and only the idle processes is running, then the termination code will not run. Therefore I made an additional call in internalExecuteNewMethod to do the check after invoking a primitive. This cleaned up cases of hung Squeak plugins under os-x" 5161ProjectArchiveFixes-nk -- Ned Konz -- 20 December 2002 My recent changes to fileName in ArchiveMember broke project loading in non-Unix systems. This reverts fileName so that it returns the raw Zip name, and adds localFileName for use when you need a name that's compatible with the local file system. 5162testRunnerInMenu-nk -- Ned Konz -- 16 December 2002 This adds the TestRunner to the World menu 5163UUIDGEnBugFix-tpr -- tim(a)sumeru.stanford.edu -- 20 December 2002 Update 5150 tried to fix UUIDGEnerator's use of random seeding but used the wrong way of coping with the lack of /dev/urandom (which only appears to exist on a few unix platforms). Instead of #ifCurtailed: this patch uses [] on: FileStreamException do:[] which will trap any file related problem such as the file not existing or being unreadable. Maybe it will be good enough to help for now. 5164VMMakerNicer-nk -- Ned Konz -- 16 December 2002 VMMaker had a nasty habit of scrolling its plugin lists back to 0 upon selection. This fixes that problem. Also, it adds an open item for VMMakerTool in the WorldMenu. 5165vmParameterTo25-JMM 5166weakMsgSendFixes-nk -- Ned Konz, Rob Withers -- 30 December 2002 CS 5005u16-Events introduced a call to a method isReceiverOrAnyArgumentGarbage in Object>>actionSequence that was only understood (much later, after CS 5155WeakMessageSend2-nk-rw) by WeakMessageSends and WeakActionSequences. Unfortunately, if you had an ActionSequence or a MessageSend around in an action map, this would break, as they don't understand isReceiverOrAnyArgumentGarbage. I removed this call from the methods in Object so that any action maps that can answer asMinimalRepresentation will work. This includes: ActionSequence, WeakActionSequence, MessageSend (added), and WeakMessageSend. 5167serverDirFix-sw -- Scott Wallace -- 7 January 2003 Fixes error seen when changing sort order in a file list for a server directory that had no file selected 5168advanceVersion-sw -- Scott Wallace -- 7 January 2003 This is the last update for version 3.4beta. In its postscript is an executable statement that will set the version forward either to 3.4gamma or to 3.5alpha, at user option. -------------

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