Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

Re: [Modules] C and Smalltalk modules
by Anthony Hannan 10 Mar '03

10 Mar '03

Hello again, here's a simpler description of the modules I presented in my previous email. A module is an object that introduces new objects and specifies changes to existing objects in imported modules. When a module is linked its changes are applied to the existing objects. When a module is unlinked its changes are undone. A module is automatically linked when a process that has the module in its environment becomes active. Process has a new instance variable called environment that points to a module. A module is IN an environment iff the environment directly or indirectly imports the module. A module is automatically unlinked when a process that does NOT have the module in its environment becomes active. Pointers that cross module boundaries are converted to identifiers when unlinked and converted back to pointers when linked. For example, a class Foo introduced in ModuleB may have its superclass Bar introduced in ModuleA, an import of ModuleB. When ModuleB is unlinked, Foo's superclass will contain the identifier #Bar. When it is linked back it will contain the class Bar. If there is no global pointing directly to Bar, its identifier will specify a path to Bar from a global, for example #Classes.Bar. Modules only deal with objects and identifiers and is independent of any class (or classless) structure. Thanks, Anthony

7 7

RE: ClassBuilder fix, SqueakMap, and releasing 3.4
by Brent Vukmer 07 Mar '03

07 Mar '03

I apologize, Andreas, I should have asked you first.. Software Composition Group guys, does one of you want to be the maintainer? -----Original Message----- From: Andreas Raab [mailto:andreas.raab@gmx.de] Sent: Friday, February 28, 2003 10:49 AM To: 'The general-purpose Squeak developers list' Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4 Brent, I would appreciate if you could take me out as the "maintainer" at SqueakMap. I'm not going to maintain any of this in honest. If you'd like to be the maintainer of a suite of tests for ClassBuilder feel free to add yourself. Cheers, - Andreas > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On > Behalf Of Brent Vukmer > Sent: Friday, February 28, 2003 2:40 PM > To: The general-purpose Squeak developers list > Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4 > > > BTW, I installed the MetaClassBuilderFix SAR in a 3.4gamma > image, installed the ClassBuilder test suite, and then ran > the ClassBuilder test suite -- 3 out of 3 tests passed. > > -----Original Message----- > From: Brent Vukmer > Sent: Friday, February 28, 2003 8:32 AM > To: Squeak-Dev (E-mail) > Subject: ClassBuilder fix, SqueakMap, and releasing 3.4 > > > Andreas's fix for the ClassBuilder bug is now on SqueakMap. > So is the suite of unit tests that Andreas created to test > ClassBuilder. > > On the docs side, I've created the following chain of Swiki pages: > "Documentation"->"Known Bugs"->"Known Bugs in 3.4"->"Adding > instVar to ClassDescription breaks ClassBuilder" > > We have SqueakMap fix-love and Swiki documentation-love for > the bug. Let's roll with the 3.4 release. > > Cheers, > Brent > > > > >

5 6

RE: Adding Accufonts to the update stream (was Re: LicencesQuestion: Squeak-L Art 6.)
by Daniel Vainsencher 06 Mar '03

06 Mar '03

That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused, in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other. So, it's a mere matter of applying the nicest package that's on SM as soon as we're ready to start rolling updates for 3.5. Cool. I love Squeak. Thanks Andreas. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi guys, > > Just to throw in an extra thought into this discussion: If you are concerned > that switching the default encoding for fonts would prevent you from using > any of the existing fonts you are wrong. The fonts in Squeak contain a > character to glyph mapping so that any existing font (in any encoding) can > be used even if the default character set is changed. In other words, all > that's needed for all of the existing fonts is a WhateverWeDecide -> Mac > Roman mapping and that's it. I have used this mechanism (for example) for > the native font support on Windows. > > Cheers, > - Andreas > > > -----Original Message----- > > From: squeak-dev-bounces(a)lists.squeakfoundation.org > > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On > > Behalf Of Ian Piumarta > > Sent: Monday, February 24, 2003 7:52 PM > > To: Daniel Vainsencher > > Cc: squeak-dev(a)lists.squeakfoundation.org > > Subject: Re: Adding Accufonts to the update stream (was Re: > > LicencesQuestion : Squeak-L Art 6.) > > > > > > Daniel, > > > > On Mon, 24 Feb 2003, Daniel Vainsencher wrote: > > > Ian, do you see a problem > > > > I see only opportunities. ;) > > > > > with loading AccuFonts to solve the license issues now > > > > Somebody who has replaced (and lived with) the standard fonts entirely > > with them would be a better judge. But if the glyphs are in the right > > places then the change should be completely transparent as far as the > > image and VMs are concerned. > > > > > and then doing as you guys propose as soon as we have > > > everything lined up? the VMs, image enhancements like > > keyboard shortcut > > > you proposed, and more (reasonable) amount of discussion to > > make sure we > > > didn't miss anything? > > > > The VM changes are minimal. They'd take 15 minutes, tops. > > > > The only thing we (I) missed was that most of the > > _fixed_-width X fonts > > (e.g, xc/fonts/bdf/misc/6x13-ISO8859-1.bdf) come with this copyright: > > > > Public domain font. Share and enjoy. > > > > whereas the proportional fonts (times, helvetica) and courrier are not > > copyright-free, and come with this one (again snipped > > directly from a bdf > > file; e.g., xc/fonts/bdf/75dpi/helvR10-ISO8859-1.bdf): > > > > Copyright 1984-1989, 1994 Adobe Systems Incorporated. > > Copyright 1988, 1994 Digital Equipment Corporation. > > > > Adobe is a trademark of Adobe Systems Incorporated which may be > > registered in certain jurisdictions. > > Permission to use these trademarks is hereby granted only in > > association with the images described in this file. > > > > Permission to use, copy, modify, distribute and sell this software > > and its documentation for any purpose and without fee is hereby > > granted, provided that the above copyright notices appear in all > > copies and that both those copyright notices and this permission > > notice appear in supporting documentation, and that the names of > > Adobe Systems and Digital Equipment Corporation not be used in > > advertising or publicity pertaining to distribution of the software > > without specific, written prior permission. Adobe Systems and > > Digital Equipment Corporation make no representations about the > > suitability of this software for any purpose. It is provided "as > > is" without express or implied warranty. > > > > But that's just standard X boilerplate, entirely Squeak-friendly, and > > as someone pointed out the other day requires only being tacked on the > > end of the license file. > > > > Ian > > > >

6 8

[BUG][3.4b-5156] Cannot load project correctly that has JPEG SketchMorph
by NISHIHARA Satoshi 06 Mar '03

06 Mar '03

hi all 3.4b-5156 can't load a project correctly that has JPEG SketchMorph. 1) create a new project and enter. 2) drop the jpeg file on the world. (*1; published.jpg) 3) publish it. 4) load that project. (*2; afterLoading.jpg) It is never occurred at Squeak3.4b-5138, Squeak3.2-4956, Squeak3.2-4917 images. *** Squeak3.4b-5156 image only *** It seems to be exchanged a form stub and the right bits. Any suggestion? -- -------------------------------------------- 西原聡士 (NISHIHARA Satoshi) e-mail: mailto:nishis@zephyr.dti.ne.jp URL: http://www.zephyr.dti.ne.jp/~nishis/ --------------------------------------------

6 10

SqueakMap vs Debian
by Martin Wirblat 06 Mar '03

06 Mar '03

Hi Göran and all, after rethinking the SqeakMap - Debian analogy, I got more than ever the impression that it is important to have a pipeline like Debian with 'next Core' to concentrate future efforts on one working whole. However the most important thing is, to assure that something what is released, is working like an image today. To make more clear what 'core' is, I added to its name 'release' and the version number. So my suggestion for the packaging categories would be: 'final core release 3.2' <- historic 'actual core release 3.4' <- must work more or less, will become 'final' 'next core release 3.5' <- experimental and in flux, will replace 'actual' 'extra packages' <- every package else The 'core release' is what is now the image, and in future it will be the minimal image + core packages. A 'core release' is characterized by: - core packages can only depend on packages in their core release - a guide or mechanism for possible combinations of core packages e.g. onion-skins - the test of all allowed combinations working together as a customized image - something like a 'guaranty' that every package is maintained - this guaranty has to be made by the community, not a single person - works like a pipeline, with 'actual' -> 'final' and 'next' -> 'actual' - is meant to grow over time ( like Debian ) To keep things simple, I think we can merge 'extra packages', 'normal packages' and 'core replacements' into 'extra packages': - packages can depend on everything, even historic and next releases - hopefully maintained by a single person or team, but no guaranty - this is always the place for something new like Traits - packages with such big impacts can make it only to 'next core release' - packages which are more peripheral may go to 'actual core release' directly The difference between 'core release' vs 'extra' is not about kernel vs tools or applications. Even applications can stay perfectly well in the 'core release' ( see todays image and Debian ). The difference is only this: - only 'core release' is tested and guaranteed to be working now and in future - 'core release' is the evolution path for Squeak - 'extra' is the space of virtual possibilities - 'core release' is what seems valuable for all AND on which many need to depend on This dependance is meant to be not only programmatic. Squeak the visual, collaborative framework depends on tools and applications too. One last thought about guaranty. I think a guaranty can't be given by a single person. At least no one can rely on such a guaranty. If many guaranties like this will be promised, some will be broken. That's why I would suggest to make the 'core release' so that the community is able to take the full responsibility for it. regards, Martin

3 2

Mythical small kernel images?
by goran.hultgren＠bluefish.se 05 Mar '03

05 Mar '03

Hi all! A while ago around OOPSLA 2002 I think there was some talk about two impressive achievements - one really tiny kernel image by Dan Ingalls weighing in at a mere 246kb (if my memory serves) and one by Andreas Raab just a teeny bit larger. Since I just got a silly challenge from my brother to whip up a small networking non-UI trivial app I thought it would have been cool to both use a minimal image and perhaps even go to the length of making a minimal VM for it. :-) Why? Well, because it could be cool to demo for all those Java-dudes demanding a ~9Mb JRE download. :-) Perhaps Andreas or Dan or anyone else who knows anything could give us a status report? regards, Göran

16 40

[DOCS] RE: Wiki refactoring
by Hannes Hirzel 05 Mar '03

05 Mar '03

As Stephen points out the swiki has something similar like the well known wiki "categories" pages. Actually each page acts as a category page because it has a drop-down menu which shows the pages which link to the page. The problem at the moment is that categorization is not put to systematic use. If someone has a good idea of a categorization scheme please step forward. A least we have the color codes in the title section. And we have some good entry points into the net of interlinked pages. At the moment the documentation team has the focus of removing outdated information, adding current information and creating a comprehensive toc. Later we could think of doing various indexes (som genenerated by scripts). If somebody likes to do this now please join the documentation team. http://minnow.cc.gatech.edu/squeak/808 There are enough ideas to keep you busy. Hannes "Stephen Pair" <spair(a)acm.org> wrote: > Serge, > > On that page you you assert that WikiTags and WikiBadges are not > possible on the Squeak Swiki. They in fact are possible. You can put > WikiTags and WikiBadges on any wiki that support reverse link lookup. > I've added a comment to this effect on: > > http://minnow.cc.gatech.edu/squeak/2352 > > And, I've started a "RefactorMe" badge page at: > > http://minnow.cc.gatech.edu/squeak/3048 > Click the drop down list of links to view all the pages that have been > flagged for refactoring. > > - Stephen > > > -----Original Message----- > > From: squeak-dev-bounces(a)lists.squeakfoundation.org > > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On > > Behalf Of Serge Stinckwich > > Sent: Tuesday, February 25, 2003 3:04 PM > > To: squeak-dev(a)lists.squeakfoundation.org > > Subject: Wiki refactoring > > > > > > Hi all. > > > > I think with all the current Wiki agitation, we also need to > > refactorize the Squeak Wiki. I put some ideas at the end of > > the Wiki refactoring page : http://minnow.cc.gatech.edu/squeak/2352 > > > > > > -- > > Serge Stinckwich -< ) > > multiagent.com > > Université de Caen>CNRS UMR 6072>GREYC>MAD /~\ > > squeak.org > > http://www.iutc3.unicaen.fr/serge/ (/ > > | zope.org > > Smalltalkers do: [:it | All with: Class, (And love: it)] _|_/ > > debian.org

3 3

Re: port of prevayler
by Hannes Hirzel 05 Mar '03

05 Mar '03

Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > > Marco Paga <mail(a)marco-paga.de> wrote: > > > >I like the "prevalence" ideas a lot. My quick summary: > > > > > > 1. The business objects are kept in RAM, yet protected from system > > >crashes by the logging and recovery mechanisms. > > It might be a good idea to do the log in XML format. See SIXX on > SqueakMap. Or as a sequence of Squeak do-its. Hannes

11 16

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Daniel Vainsencher 04 Mar '03

04 Mar '03

Hannes raised an important question - where does time pressure come from? He also raised another important question - why didn't we meet our stated goals? I think these are important enough, they deserve answering, not arguing about them. Time pressure comes from the nature and purpose of releases. One can say that any image at all of Squeak, with any combinations of changesets loaded, is a version of Squeak. What separates a release from any other version is that it's visible. All of it's natural and most important qualities come simply from that: it's rarity causes it to be visible. It's important to remember that people measure the quality of an implementation mostly by it's releases - not by fixes/packages that can be loaded, because probably no two pair of people will apply the same ones. This is meant to change when we have configurations, but that's the way it is now. What that means, is that right now, people measure us by 3.2. Most everyone on the list knows of SM, and loaded it for their 3.2, or just uses 3.4, which is nicely stable enough to load anything that doesn't touch the core as Island or Traits do. So we don't suffer much from the delay of this release. Or rather, not directly. Because newbies surely do. To newbies, loading anything into Squeak is still quite complicated, and the first thing they're likely to be told is not to use the official release, but a development release. That's a sign of a project that's not releasing often enough. If your production and your development are very different, you stop feeling the pains of the production, and you stop being aware of what your product is like, and you focus on the wrong things. If we have bugs (and we have more than just those handful that were mentioned), the solution isn't to delay the release, it is to have SUnit tests, use them, and keep them green. Think longer term - it's not about making a perfect release - that'll always be a good excuse to delay a little more. It's about having many releases, at quite frequent, predictable intervals, that are getting better and better, and keeping production and development close. That'll give us long term properties that will keep Squeak getting better. And no, I don't promise to never break anything that's worked before. First, nobody's ever promised that, neither the previous regime, nor any other maintainer except maybe Knuth. Second, the main technical benefit of an open source project is parallelized testing/debugging. But that is completely dependent on people actually doing it. Third, to promise strictly monotone-improving releases, I'd need SUnit tests with every change that gets submitted. Hmm :-) Now, why didn't all of the refactorings get in? well, there's a page on squeakfoundation swiki, devoted to the status of the intended refactorings. They're almost all done and waiting for (come on, I'm sure you know - ) testing. When people want to see them get in, they'll start testing, and as soon as people tell their authors that they load, or they don't load, or there's this problem or that or it's all very nice, we can actually do the work of clearing them to get in the image. In 3.5, of course. Why didn't we meet our goals? because the goals we stated and the actions of the wider community were not in line. I'm not shocked - this is a community, not an army unit. Also, the new "regime" is pretty new, so us and said community are still getting used to each other. Having alot of these releases, a time when emotions run high and soul searching is popular, will make the adaptation go faster. Daniel Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > Roel Wuyts <roel.wuyts(a)iam.unibe.ch> wrote: > > Somebody needs to decide what is a release and what's get in there, and > > it was decided that these were the Guides. I trust them to do an > > excellent job at this, that is why they are responsible. I can imagine > > that there is some 'bigger plan' for which they want to have this > > release. The question for me is: 'what is this bigger plan'. If it is > > only that it was promised to have a new release by a certain time, then > > I agree with you that we can wait. But I guess the plan for 3.4 was to > > have SM up and running, and that is also important to get out so that > > everybody can enjoy it. > > Yes, adding SM and not breaking existing things. > > > >From http://swiki.squeakfoundation.org/squeakfoundation/79 > <citation> > 3.4 -- The main purpose of this release is to create an up to date, > viable version, that's a good starting point to making Squeak more > modular and it's development more decentralized. > > Changes: > - Includes non-modules related updates from 3.3a, including the dynamic > filelist services refactoring. > - An option to load the SqueakMap package catalog and the base Package > Loader from the net. > - A dynamic open menu so packages can now register there and become > first class applications. > - Refactorings making various parts of the image easily removable. See > Modularizing the Squeak image for the plan and status. > - Various other fixes have been included. > > Release is tentatively set to end of 2002. > </citation> > > > Regarding "Refactoring making various packages easily removable": > > There is just Balloon3DRemoval and GamesRemoval. I do not consider this > goal is met. > > > And breaking an important thing and not including the fix is surely not > good stewardship as well. > > > Again: Where does this time pressure at the expense of quality come > from? > > > Cheers > Hannes > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

[fix] 'file:/etc/profile' asUrl retrieveContents
by Niko Schwarz 03 Mar '03

03 Mar '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 'file:/etc/profile' asUrl retrieveContents fails on unix, because it is converted into a relative filename during fetching. I wrote a fix which hopefully works on windows too. Please take a look, regards, nick - -- "He is now rising from affluence to poverty." -- Mark Twain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+U2+H3P3nmXTVnC8RAurqAJ9cV08ElKC9TCR7mvMo9ZHGpSXu0QCgi7co RPceV874fCJn+3OQVI+bc6w= =EDSB -----END PGP SIGNATURE-----

3 4

← Newer
1
2
3
4
5
6
7
...
77
Older →

Jump to page: