February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by Igor Stasenko

Few more words. Deltas/packages. All we need for Delta is to identify the starting point (an image state, from where you started changing it). In contrast to DeltaStreams model, where it tries to capture both an 'old' and 'new' state, so it can be reverted, we don't need it anymore, since we can directly see what was the image state before we applied the changes to it. Having all of the history preserved and tracked is very powerful thing! So, Delta only needs to reference to starting point (URI or some ID, which identifies it, and in case of need can be easily found on the web). What is cool about it? Suppose, initially, all images started from some release (say Pharo 1.0), so all users sharing the same sources/image state. Now what happens when you start forking or making changes? Users creating a deltas and storing them in the database , and their images now knowing that they are derived from Pharo 1.0 point but also has some changes stored in separate branch or 'fork'. Now, what happens if user wants to load the changes made by another user: system can easily find the common ancestral point (since all deltas knowing its own ancestral point). And there is two use cases: a) you doing a full synchronization with some remote source. This is useful, when all of us want to use the very same image. This is primarily a good thing for team-based development or Releases(R). b) you doing a partial synchronization (or merge) with remote source. In this case you creating own fork, which derived from , say Pharo 1.0 + some changes from user Foo, Bar, Baz etc and getting own, unique version of image. So no matter in what way you hacking/mixing the changes, you never lost track of the system history, which means that for any two images which derived from some common ancestral point we could could always automatically generate a diff between them. It means that no matter how far you went in your hacking - others could always load or cherry-pick your code! Packages? Since model, i describing, operating at lower granularity level (individual changes to methods/classes/doits), which means that any package can be represented as a set of those methods/classes/doits, there should be no problem integrating/interacting at a package level. -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2010

[Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by StÃ©phane Ducasse

After the lengthly discussion about the fact that Smalltalk implementation is a balkan region (cf "what Pharo/squeak do not parse 16rFF) > Authorize - at any position in binary selectors (like VW 7.7) > See http://bugs.squeak.org/view.php?id=3616 > Address the problem of compiling 1@-2 with following strategy: > > If compiler is non interactive, then compile with backward compatibility 1 @ (-2). > If compiler is interactive, propose a menu to disambiguate and insert a proper space. > 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 > 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 > > Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... > I didn't do anything to support this vicious Squeakism, and by now the semantics are change. I was wondering what do we do with that kind of changes. Is it useful? what is the end user case? what are the binary operators that we could invent with -~- -| -@ nicolas do you have a case in mind? what VW people use it for? Now do we want this in pharo? What is the cost? Impact / broken code? > Stef

Feb. 24, 2010

Re: [Pharo-project] hex

by StÃ©phane Ducasse

Nicolas and others I was thinking also about the implication of the 16rFF changes on 16r8e7 http://code.google.com/p/pharo/issues/detail?id=2068 I would really like to take the time to think and discuss it as a community to see what we want to do. What is the current situation in squeak? Stef On Feb 23, 2010, at 11:16 PM, Nicolas Cellier wrote: > The main reason for not using lowercase in squeak was Dan extension of > number with radix plus exponent. > 16r8e7 -> 16r8 * (16 raisedTo: 7) > and the Float variations... > > If you decided to abandon this notation, then go with either upper or lower. > But a bit of consistency could help... Yes

Feb. 24, 2010

Re: [Pharo-project] 16rff broke 16r8e7

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2068 On Feb 14, 2010, at 9:22 PM, Nicolas Cellier wrote: > As you may know, with 16rff change, we cannot anymore use a radix > notation combined with an exponent notation. > At least for base > 14, the exponent letter is taken as an ordinary digit. > The options are: > > 1) revert the change > > 2) abandon combined radix+exponent notation > all the code for printing Float with different radix, and also for > scanning can be removed > Or I can provide a subclass of SqNumberParser for backward compatibility. > > 3) find a new syntax for radix+exponent > > For example, 16r7f_e6 16r7f^6 16r7f#6 > None of these is ambiguous with existing code. > > Or maybe use an uppercase R for uppercase only digits... > > 4) use q exponent to at least enable base 16 > This is hackish and not universal, but I guess hardly anybody ever > used a base > 16. > > ------------------------------------- > > What would squeak/pharo folks choose ? > > ------------------------------------- > Personnally, I'm OK with 1) and 2). > But 2) deserves a bit more discussion > After all this is a change of Squeak syntax. > I find Dan's notation educative and fun, especially for writing tests. > But it is a non portable Squeakish thing, rarely used, and it does not > really has much value for industrial usage, > On the other hand, is it really necessary to parse 16rff ? > > I dislike 3) because I find my own propositions bad. > Also, if we remove Squeak-specific syntax for compatibility reasons, > why the hell adding a new uncompatible syntax? > Previous usage of e notation was far better because just extending an > existing syntax, not creating a new one. > Maybe you'll have other ideas... > > Nicolas > > ------------------------------------- > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] [ANN] Magma 1.0 release 44

by StÃ©phane Ducasse

Thanks we will have a look. Note that Installer is not available from ScriptLoader (ScriptLoader is not a public class and nobody should use it) Either use gofer which is the default loader or install installer manually. Stef On Feb 24, 2010, at 5:38 AM, Chris Muller wrote: > Hi Ramiro, something happened between Pharo1.0-10502-rc1dev09.12.2. > and 10508 related to Networking. Please see: > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021912.h… > > I am not sure what happened. Perhaps someone on the Pharo team would elaborate? > > - Chris > > > On Tue, Feb 23, 2010 at 6:54 PM, Ramiro Diaz Trepat > <ramiro(a)diaztrepat.name> wrote: >> Hi Chris, >> Once again, thanks for your work. >> One question though, is this version running fine on the latest Pharo 1.0 ? >> I haven't been able to start a server successfuly, I get a primitive has >> failed. >> It doesn't run on Pharo 1.1 or Squeak trunk but you didn't mention those :) >> I loaded it in a fresh Pharo 1.0 image using: >> ScriptLoader new installer. >> Installer ss project: 'Magma'; >> install: '1.0r44 (server)'. >> >> Cheers >> >> r >> >> On Wed, Feb 17, 2010 at 8:46 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >>> >>> I am pleased to announce the immediate availability of Magma 1.0 >>> release "44" for both Squeak, 3.9, 3.10 and Pharo. Although I am >>> looking into alternatives for future releases, for now I am still >>> distributing Magma in my traditional ways: >>> >>> - On SqueakMap - three one-click installable packages. >>> >>> - In the "1.0r44" Monticello Configuration in the "Magma" project of >>> squeaksource, there are three one-click installable configurations >>> (client, server, tester). >>> >>> - The "r44Final" Monticello Configuration in the "MagmaTester" >>> project of squeaksource is the one-click installable MagmaTester >>> package. >>> >>> As has always been the case, ONLY ONE of the three packages needs to >>> be installed, the full and proper configuration is loaded with >>> one-click. >>> >>> Compared to r43, this is mostly a maintenance release without any >>> major new functionality, but with improved robustness in the HA and >>> luxury querying as well as several other fixes. Here are the specific >>> improvements over 43: >>> >>> - Made several HA fixes and improvements, many identified by Bart >>> Gaquie by testing with more than a two-server Magma Node. Many thanks >>> Bart. >>> - Updated MaQueryExecutor>>#fractionComplete to answer an unreduced >>> Fraction instead of a reduced one. This convey's more information; >>> since the denominator represents the total number of elements in the >>> final result. Thanks again to Bart Gauqie. >>> - Upgraded MagmaCollectionReader>>#release to allow give a >>> well-behaved application much freer access to the "luxury" query >>> features of MagmaCollections. It is essential for applications >>> employing luxury query features of Magma for ad-hoc querying, to >>> #release the Reader returned from the query so that resources on the >>> server can be freed. >>> - Now properly truncating the applied.images file, so it doesn't >>> grow >>> and grow.. >>> - Now, when a repository is opened locally, if it's location has >>> never been set (new repository) or was a different *local* location, >>> then update it to the new aMagmaLocalLocation. If it was formerly a >>> network-hosted server, do not update since we could be here simply >>> just for re-opening that repository. So, to go from a remote >>> repository to a local one, you have to manually update the node's >>> primaryLocation. >>> - Server no longer allows any clients to log in with the system >>> name, >>> since it is sometimes checked for special-purpose server housekeeping. >>> - Updated MagmaSession's standard printing method, again! >>> - Added MagmaCollectionReader>>#sortBy:makeDistinct:descending: and >>> #sortBy:makeDistinct:descending:. >>> - Made MaRepositoryDisconnectRequest asynchronous, it now returns >>> considerably faster! >>> - Fix for a recent MagmaCollection optimization. >>> - Removed hard-reference to OSProcess. >>> - Patch for #removeListener to avoid DependentsArray problem. >>> - Fixed a ReadStrategy regression. >>> _______________________________________________ >>> Magma mailing list >>> Magma(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> >> _______________________________________________ >> Magma mailing list >> Magma(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] hex

by StÃ©phane Ducasse

> The main reason for not using lowercase in squeak was Dan extension of > number with radix plus exponent. > 16r8e7 -> 16r8 * (16 raisedTo: 7) > and the Float variations... > > If you decided to abandon this notation, then go with either upper or lower. > But a bit of consistency could help... I'm confused what is the situation now in squeak? Because it seems that hex in squeak now prints and read lowercase? So did 16r8e7 and float so will someone fix squeak to be consistent. I'm a bit confused by the decision process in squeak (even if I should not worried too much). Stef

Feb. 24, 2010

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by StÃ©phane Ducasse

this was not really my question :) I know that a tree does not twice the same node do you know when it changed in squeak or pharo and the reason? Stef On Feb 23, 2010, at 11:02 PM, Nicolas Cellier wrote: > The single inheritance hierarchy is a Tree... > I don't see any interest in answering a Set. > Some tools might expect a Set... > If so, they just have to use withAllSubclasses asSet. > > If my own tool expect a LinkedList, I ain't gonna change the Kernel > library for my conveniency, or am I ? > > Nicolas > > 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Nicolas I remember that we discussed this point or a related one a while ago >> >> Squeak >> >> Point withAllSubclasses >> an OrderedCollection(Point) >> >> >> Pharo >> >> Point withAllSubclasses >> a Set(Point) >> >> Do you remember? >> I forgot? >> >> Stef >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Tudor Girba

Hi Dale, I believe the original problem is that you do not know upfront about where the actual files will be. In this case, perhaps the easiest solution is to provide some scripting facility to provide a repository mapping that should could be modified at loading time, and not be stored in the actual configuration. Suppose you have something like this: ConfigurationOfXXX>>baselineX: spec <version: 'X-baseline'> spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ]. ... ConfigurationOfXXX>>versionX: spec <version: 'X' imports: #('X-baseline')> spec package: 'SomePackage' with: 'SomePackage.tg.1'. ... Maybe a solution would be that when loading you could say: (ConfigurationOfXXX project version: 'X') withRepositoryMapping: 'SOME_URL' -> 'SOME_NEW_URL'; withRepositoryMapping: '...' -> '...'; load What do you think? In this way, the original configuration specifies everything, and the URL works either as the actual URL or as an alias that can be mapped to something else later on when you know the actual URL. Actually, this can already be accomplished at engine level. I believe a simple scripting like above would just make it practical. What do you think? Cheers, Doru On 23 Feb 2010, at 21:18, Dale Henrichs wrote: > > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: > > | > Perhaps Gofer can be provided with a secondary repository location > | in the case when the primary repository fails. > | > | Yes, it can. You just specify multiple repositories and it will use > | them all. If you tell Gofer to #disableRepositoryErrors then it will > | silently ignore repositories that are not available. > > Lukas, > > The only thing that worries about including such repository all of > the time, is the cost of building the cache of repository when > resolving repositories ... the secondary repository would get pretty > large over time and most of the time (only in the case of errors) > would it need to be scanned. > > I suppose Metacello could handle load errors in the code that calls > Gofer and do a retry using the secondary repository...the secondary > repository _could_ be specified as part of the configuration, so > this probably isn't a bad idea... > > Thanks, > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow."

Feb. 24, 2010

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by Igor Stasenko

On 23 February 2010 18:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Some kind of graph-based GUI would certainly help in this scenario to > visualise the dependencies/changes... just a thought. > Sure. But this is a little far perspective. ;) At first, we should replace the source code management in image to be able to connect with any facility for storing the sources (be it in file or database or network). The main point that tools & system utils should not know where these sources stored or coming from. Then, we could move on the next stage - design a database/source code managers to fit specific purposes. The one which i described above is only one of the possible ways, actually. > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, February 23, 2010 4:02 PM > Subject: [Pharo-project] Source code management - my vision. (Was: Re: Why > apackage management system) > > >> Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, >> which came into my mind, when i complete coding the method trailers. >> >> I made a method trailers open for future extensions. >> A first step would be to introduce an abstract 'source management' >> layer, which will be responsible for delivering >> a method's and classes sources from some abstract data source. The >> next step is actually implement such data sources. >> >> So, the idea is to abandon hardwiring with .sources and .changes files. >> What new opportunities it gives to us? >> Suppose that instead of storing sources into file, you putting them >> directly to database , such as CouchDB (yes! :). >> >> Now if you imagine that anyone could access to this database on some >> public location, this means that we automagically made a source code >> exchange hub, and could do a very cool things with it. >> >> Suppose that ALL source code is put into a single database. Now >> different users creating own accounts and makind own 'forks' from >> original. What we getting is a number of update streams (methods, >> doits etc etc), which lying in those databases, >> and if one user wants to load/merge code from one of the sources he >> simply points to it and it get loaded into his image. >> We could organize things very closely to what github currently is: >> everyone could create any number of new projects, or forks of existing >> ones. Freely exchange the code, do a cherry picking etc etc. >> And what is most important, that with such organization you can track >> any methods, classes in the image and their evolutionary history back >> to its origin. As well as, you can query database, how an when a >> concrete method/class get deleted (everything is recorded, not just >> current state). >> >> Also, it would allow us to manipulate the code at the lowest level of >> granularity (individual methods/classes/doits, same as DS does), not >> at a package level. >> There are a lot of synergy with DeltaStreams - it could serve as an >> 'offline' format, in same way as git storing the files locally, but >> can reconnect with remote storage (which can be a public database). >> One of the things, which could be made is to allow stashing/popping >> code from stash. Suppose two projects started from a single starting >> point (Squeak 3.9). Now suppose that by clicking a single button you >> could get either trunk image, or Pharo 1.0 image. >> But that's not all! With DeltaStreams, you could then click once more, >> and revert things back from , say Pharo 1.0 to trunk or vice versa :) >> Of course it would be stupid to do things at such large scale, but if >> we put some common 'root' stuff into database, then we could very >> easily track all changes & compare them. This would make cherry >> picking and code exchange much more easier. >> >> This could get us on the next level of code management and system >> organization and organization of community efforts. >> >> >> >> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se>: >>> Hi! >>> >>> GermÃ¡n Arduino wrote: >>>> Hi GÃ¶ran: >>>> >>>> Sorry by my intromision here, but want to say somethings :) >>>> >>>> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se <mailto:goran@krampe.se>> >>> [SNIP] >>>> What I have seen so far in Metacello is indeed nothing new - the >>>> senarios and discussions about dependencies etc go loooong way back. >>>> >>>> >>>> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >>>> packages, >>>> etc, but only discussions on most of cases. I think Metacello solves the >>>> dependencies >>>> questions very well and the other tools not (with exception of Universes >>>> probably, but >>>> abandoned now). Also Metacello provides all the features explained on >>>> the excellent >>>> mail of Torsten, assuring that the configurations will work with the >>>> time not breaking >>>> stuffs. >>>> >>>> The solution of using Metacello+Monticello is, imho, very simple, easy >>>> and productive >>>> and is here, available to us. :) >>> >>> I never claimed otherwise! I am just saying that there is nothing new - >>> and frankly, though I admit not having read carefully, I didn't find the >>> example so... impressive. Perhaps I need to read it again. >>> >>> Again though - I am not saying anything negative about Metacello. >>> >>> [SNIP] >>>> Anyway, "common exchange mechanism" - I am working on Deltastreams which >>>> I even presented at Brest, though unfortunately colliding with the >>>> Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >>>> this problem (fork interchange), and it was born in 2007: >>>> >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… >>>> >>>> I and Igor are the ones working on it - and after Brest we have had very >>>> little time to move it forward. I still think it is a very important >>>> piece of the puzzle though. >>>> >>>> But Deltastreams are ready to use on production systems? >>> >>> Nope, not yet, although very close. But since the topic came up I wanted >>> to mention it. But AFAIK there is no other tool/project aimed at that >>> use case. Again, I may be wrong :) >>> >>> regards, GÃ¶ran >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2010

Re: [Pharo-project] [ANN] Magma 1.0 release 44

by Chris Muller

Hi Ramiro, something happened between Pharo1.0-10502-rc1dev09.12.2. and 10508 related to Networking. Please see: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021912.h… I am not sure what happened. Perhaps someone on the Pharo team would elaborate? - Chris On Tue, Feb 23, 2010 at 6:54 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name> wrote: > Hi Chris, > Once again, thanks for your work. > One question though, is this version running fine on the latest Pharo 1.0 ? > I haven't been able to start a server successfuly, I get a primitive has > failed. > It doesn't run on Pharo 1.1 or Squeak trunk but you didn't mention those :) > I loaded it in a fresh Pharo 1.0 image using: > ScriptLoader new installer. > Installer ss project: 'Magma'; > install: '1.0r44 (server)'. > > Cheers > > r > > On Wed, Feb 17, 2010 at 8:46 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> I am pleased to announce the immediate availability of Magma 1.0 >> release "44" for both Squeak, 3.9, 3.10 and Pharo. Â Although I am >> looking into alternatives for future releases, for now I am still >> distributing Magma in my traditional ways: >> >> Â - On SqueakMap - three one-click installable packages. >> >> Â - In the "1.0r44" Monticello Configuration in the "Magma" project of >> squeaksource, there are three one-click installable configurations >> (client, server, tester). >> >> Â - The "r44Final" Monticello Configuration in the "MagmaTester" >> project of squeaksource is the one-click installable MagmaTester >> package. >> >> As has always been the case, ONLY ONE of the three packages needs to >> be installed, the full and proper configuration is loaded with >> one-click. >> >> Compared to r43, this is mostly a maintenance release without any >> major new functionality, but with improved robustness in the HA and >> luxury querying as well as several other fixes. Â Here are the specific >> improvements over 43: >> >> Â Â Â Â - Made several HA fixes and improvements, many identified by Bart >> Gaquie by testing with more than a two-server Magma Node. Â Many thanks >> Bart. >> Â Â Â Â - Updated MaQueryExecutor>>#fractionComplete to answer an unreduced >> Fraction instead of a reduced one. Â This convey's more information; >> since the denominator represents the total number of elements in the >> final result. Â Thanks again to Bart Gauqie. >> Â Â Â Â - Upgraded MagmaCollectionReader>>#release to allow give a >> well-behaved application much freer access to the "luxury" query >> features of MagmaCollections. Â It is essential for applications >> employing luxury query features of Magma for ad-hoc querying, to >> #release the Reader returned from the query so that resources on the >> server can be freed. >> Â Â Â Â - Now properly truncating the applied.images file, so it doesn't >> grow >> and grow.. >> Â Â Â Â - Now, when a repository is opened locally, if it's location has >> never been set (new repository) or was a different *local* location, >> then update it to the new aMagmaLocalLocation. Â If it was formerly a >> network-hosted server, do not update since we could be here simply >> just for re-opening that repository. Â So, to go from a remote >> repository to a local one, you have to manually update the node's >> primaryLocation. >> Â Â Â Â - Server no longer allows any clients to log in with the system >> name, >> since it is sometimes checked for special-purpose server housekeeping. >> Â Â Â Â - Updated MagmaSession's standard printing method, again! >> Â Â Â Â - Added MagmaCollectionReader>>#sortBy:makeDistinct:descending: and >> #sortBy:makeDistinct:descending:. >> Â Â Â Â - Made MaRepositoryDisconnectRequest asynchronous, it now returns >> considerably faster! >> Â Â Â Â - Fix for a recent MagmaCollection optimization. >> Â Â Â Â - Removed hard-reference to OSProcess. >> Â Â Â Â - Patch for #removeListener to avoid DependentsArray problem. >> Â Â Â Â - Fixed a ReadStrategy regression. >> _______________________________________________ >> Magma mailing list >> Magma(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/magma > > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

Feb. 24, 2010