- Pharo-dev - lists.pharo.org

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

On May 16, 2010, at 11:17 PM, Mariano Martinez Peck wrote: > > > On Sun, May 16, 2010 at 11:00 PM, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: > Mariano, > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a Pharo1.1 from a core, and it works perfectly, including condenseChange. > > > No, it doesn't work perfectly ;) > All the mails I sent to the mailing list was the "things" I found while building Pharo 1.1. > We still have problems with network for example. Where? The ping did not work in 3.9, squeaktrunk, pharo10 and pharo1.1 so :) lukas sent an email last week and we got NO feedback. > Not too much indeed. I need to update a little some configurations. I just tested with the new vms and today I was testing how to install external packages like seaside to see if the welcome workspace that explains how to install them deserves an update. > > What I need is that someone: > > - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge there are none that are showstoppers > - to create a section in the website specially for 1.1 where we mention we are in alpha1 blah blah I started and we should continue > - in that section we include new VMs. > - For windows it is the same we have for 1.0: http://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip > - For linux: http://squeakvm.org/unix/release/Squeak-4.0.3.2202-linux_i386.tar.gz > - For mac we are waiting a new one from John, but for the moment we should use: ftp://ftp.smalltalkconsulting.com/Squeak%204.2.4beta1U.app.zip > - Finally we add in that section the Pharo image I build. > > I have updated my build scripts to work with Pharo 1.1 and I build a dev, Excellent > > So...once those points are done, I just create the image and update it to website. > > But we will need help from people to test it and report bugs, feedback and all kind of issues. There are still failing and error tests (they are even in PharoCore). > > Cheers > > Mariano > > > Cheers, > Alexandre > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > We are basically ready > > Waiting for feedback on network. > > > > Stef > > > > > > On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > > > >> We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: > >> > >> - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image > >> - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) > >> - Make publish all new VMs (for each OS) > >> > >> Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) > >> > >> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). > >> > >> Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. > >> > >> now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? > >> > >> Cheers > >> > >> Mariano > >> _______________________________________________ > >> 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 > > > _______________________________________________ > 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

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Igor Stasenko

2010/5/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> check the network problem. >> But we can release rc1 anytime now. >> > > No, please. We are not in a RC yet. We should first go as alpha, then beta > and finally RC. > We cannot go in a RC with the first build ever. > Yes , we can. Its only a conventions, what you calling alpha , beta or RC. But sure thing, more testing and packaging won't hurt. > Cheers > > Mariano > > >> -- Best regards, Igor Stasenko AKA sig.

May 17, 2010

Re: [Pharo-project] [squeak-dev] Re: Problem with variable capture in blocks or ? #7532

by Levente Uzonyi

On Sun, 16 May 2010, Eliot Miranda wrote: > On Sun, May 16, 2010 at 3:32 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > >> Hi Ken - >> >> Very interesting. Looks like an issue with OutOfScopeNotification. The >> problem appears to be that this code: >> >> "..." [ :a | a ]. >> "..." a. >> >> generates an OutOfScopeNotification that is being suppressed in workspaces >> (I'm not exactly sure why that is). This is of course is interesting because >> of the highly unusual situation of a temp shadowing a global instead of >> another temp / ivar. For example, this wouldn't compile: >> >> | a | >> [ :a | a ]. >> >> But stranglely, this does: >> >> [ :Object | Object ]. >> >> so your example code is roughly equivalent to running: >> >> b := [ :Object | Object ]. >> c := b value: Object. >> >> When you run this line by line it works 'as expected' and when you run it >> as a single doIt you get the result of c being a "[closure] in >> UndefinedObject>>DoIt" due to the OutOfScopeNotification. >> >> Hope this explains the issue - as for how to fix it, I have no clue :-) >> > > Yes, the bug is that Encoder>>encodeVariable:sourceRange:ifUnknown: doesn't > continue from a caught OutOfScopeNotification by answering the ifUnknown: > action. Instead it returns the out-of-scope block temp. This is a rather > serious compiler bug that I'd left unfixed because it only bites in > workspaces (apologies) and I didn't have a small example to analyse before > (thanks Ken!). The code generated is actually equivalent to > > b := [ :a | a ]. > c := b value: <temp 0>. > > Since there aren't any temps, temp 0 is top of stack, which just happens to > be the closure just created by the preceding bytecode. e.g. look at > bytecode 49 in the following: > > a := 4. b := [ :a | a ]. c := b value: a. { a. b. c } thisContext method > symbolic > > The fix is simple. When an OutOfScopeNotification is caught the Encoder > should still answer what ever it should for an out of scope variable. In > Encoder>>encodeVariable:sourceRange:ifUnknown: the statements > > (varNode isTemp and: [varNode scope < 0]) ifTrue: [ > OutOfScopeNotification signal ifFalse: [ ^self notify: 'out of scope']. > ]. > ^ varNode > > should read > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode > > Find attached: > > !Encoder methodsFor: 'encoding' stamp: 'eem 5/16/2010 17:33'! > encodeVariable: name sourceRange: range ifUnknown: action > | varNode | > varNode := scopeTable > at: name > ifAbsent: > [(self lookupInPools: name > ifFound: [:assoc | varNode := self global: assoc name: name]) > ifTrue: [varNode] > ifFalse: [^action value]]. > range ifNotNil: > [name first canBeGlobalVarInitial ifTrue: > [globalSourceRanges addLast: { name. range. false }]]. > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode! ! > > P.S. this is probably applicable to any Squeak bytecode compiler (including > eToys). The only change in my closure compiler from Andreas' 2003 version > was changing "name first isUppercase" to "name first canBeGlobalVarInitial". > > > P.P.S. Again Ken, thanks for a comprehensible example. It always bit me in > huge doits I was using to analyse the entire system's compiled methods, and > invariably crashed the VM. I never took the time to isolate the bug, I just > fixed the doit and continued. Turns out to be very simple. > > best > Eliot I would also expect the following to compile if temporaries can shadow instance variables: Foo >> #foo | b | a := 1. b := [ :a | a ]. ^b value: a. Where a is an instance variable of Foo. But I get: ^b value: out of scope ->a. Which doesn't make much sense IMHO. Levente > > >> Cheers, >> - Andreas >> >> >> >> On 5/16/2010 12:35 PM, Ken Causey wrote: >> >>> Well, it's nothing new but this one has stumped me: >>> >>> http://bugs.squeak.org/view.php?id=7532 >>> >>> Initially I (and Frank) thought the reporter was mistaken until we >>> understood that the problem shows up when you execute the main code all >>> in one do-it. I've since modified the original report to make this >>> clearer. >>> >>> So here it is: >>> >>> a := 4. >>> b := [ :a | a ]. >>> c := b value: a. >>> >>> If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial >>> detail). The result is that a is 4, b is a BlockClosure, and c is a >>> BlockClosure not 4 as expected. Execute each statement separately and c >>> is 4. >>> >>> Alternately, from a suggestion from jmckeon, if you specify a different >>> symbol for the block argument: >>> >>> a := 4. >>> b := [ :d | d ]. >>> c := b value: a. >>> >>> when executed all at one time works as you would expect: a is 4, b is a >>> BlockClosure, and c is 4. (and d is nil) >>> >>> So what's up? >>> >>> Ken >>> >>> >>> >>> >> >> >

May 17, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by David T. Lewis

On Fri, May 14, 2010 at 09:58:57PM +0300, Igor Stasenko wrote: > On 14 May 2010 04:27, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Fri, May 14, 2010 at 02:33:38AM +0300, Igor Stasenko wrote: > >> 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Thu, May 13, 2010 at 8:26 PM, St??phane Ducasse > >> > <stephane.ducasse(a)inria.fr> wrote: > >> >> > >> >> mariano > >> >> > >> >> i just released a fix could you stress the system? > >> > > >> > wiiiiiii > >> > > >> > My .changes is now 36MB. It seems to work ok. > >> > > >> Don't climb too high , failing would be painfull :) > > > > Actually you should keep climbing! The address mapping needs to > > do strange things on the 32MB boundaries for backward compatibility > > with the original 32MB address mapping. So keep loading those > > Seaside packages until you get to at least 150MB or so, just be > > to sure it keeps working over 32MB -> 64MB -> 96MB -> 128MB ... > > > > Isn't it would be wiser to do a simple numerical tests, instead of > manually tossing bunch of code into the .changes? Of course numerical tests are needed, which is why I provided the tests in ExpandedSourceFileArrayTest. I'm sure that Pharo will pass all those tests. But the test that did not pass was a real user adding to a real changes file, which triggered a side effect unrelated to the numerical conversion. So I would have to say that skipping the crude manual test was not wiser in this case. Dave

May 17, 2010

Re: [Pharo-project] [Metacello] Managing Pharo external packages with Metacello, please read!

by Miguel Enrique CobÃ¡ Martinez

El dom, 16-05-2010 a las 17:28 +0200, Mariano Martinez Peck escribiÃ³: > Hi folks. We have been discussing a lot what to do with the Metacello > configurations of all projects and MetacelloRepository. > We want several things: > > - Have an specific catalog of the working and tested packages/projects > for each Pharo release (1.0, 1.1, etc). > - Be able to have a hudson server running and testing such > configurations. > - Unified way to load a project. > > For such objectives, we propose the following scheme: > > 1) We create a squeaksource repository called > Pharo10MetacelloRepository > 2) All the Metacello configurations that are known and tested to work > perfect in Pharo1.0, are copied to such repository. (this takes 2 > minutes) > 3) Now, we have the problem of WHICH version from the conf class > should be the one that loads and works in Pharo 1.0. So, once you > copied the configuration, then you have to implement a class side > method "load" that loads the exact version that should work in > Pharo1.0. This version may not be the last. And you already may have > defined "load" to load the last version. In such case, you can just > change it for the version in the Pharo10MetacelloRepository. > Otherwise, we can use another message. Give us your opinion. > > So the idea is that all developers/maintainers of Metacello > configurations, do that and publish it. With this, if you want to know > which projects work on Pharo 1.0 you just browser > Pharo10MetacelloRepository, load the repository you want, and you know > that just doing "ConfigurationOfXXX" load will do the job. > > In addition to this, we are able to have a hudson server that every XX > time, it scans the repository, and for each project it tries to load > it and report if there is a problem. We can even make that "load" > loads also the tests and make Hudson to run the tests. Or if you want > we can use another message than load. > > So...this is just an idea. But we need feedback and hear opinions. > Because Pharo 1.1 will be soon and would be great to have this already > working for Pharo 1.0. > > Thanks > > Mariano I was thinking about the "folders" to store copies of ConfigurationOfXXX for a given release. I think that this will have problems, for example for the simplest package that load fine in 3 consecutive release we will have exactly 3 copies of the ConfigurationOfXXX package (not that the disk space is a problem). On the other side, if a package has 19 versions for a given release (lets say RFB has 19 version methods in the ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a copy of it will be made. This copy will be full, having the 19 version methods, or you just take the last version method. Also, what about the pre/post do its, they will likely be similar or exactly equal between releases of Pharo. If you delete the methods, you also lost the history and the opportunity that new users can learn or use the previous versions. Some time ago I proposed the idea that Metacello should have tags to mark that a version method has been tested in a given fork/release. As the time pass, the tags in a method will grow to mark the version has been tested on. But for this to work, Metacello or the tools (I would prefer Metacello) must honor this tags and before loading the code in a given image by comparing what image is being installed on. Lets put an example: 1. Initial creation of the configuration for package Package for Pharo 1.0 uploaded to MetacelloRepository: ConfigurationOfPackage>>baseline01 "initial baseline" ConfigurationOfPackage>>version01: spec <version: '0.1'> spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ]. 2. A new version for Pharo 1.0 (lets say a bug fix): ConfigurationOfPackage>>version02: spec <version: '0.2'> spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ]. 3. A new Pharo release is made, no changes to the package are needed, that is, it works correctly in Pharo1.0 and Pharo 1.1 ConfigurationOfPackage>>version03: spec <version: '0.3'> spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) ... ]. At this point the ConfigurationOfPackage has four methods: baseline and three versions. Also, before loading, Metacello checks the worksIn: list against a standard release string in the image is working on. If it match it install the package. That is, if I start with a Pharo1.1 image and load the configuration, the only possible candidate version to install is the 0.3, because is the only one marked to work in Pharo1.1. 4. A port to Squeak 5 is made. This likely will need a new baseline because will need squeak specific packages to be included (compatibility packages) and also maybe a Pharo compatibility package will be made. Anyway, a new baseline indicating new packages relationships will be made: ConfigurationOfPackage>>baseline02 "second baseline, it accounts for install in Pharo and Squeak" ConfigurationOfPackage>>version04: spec <version: '0.4'> spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ]. At this point the ConfigurationOfXXX is capable of install the last version in Squeak and Pharo. If I start on Squeak 4.0 then even if I load the ConfigurationOfPackage, no package will be installed because nobody has tested this. If I start on Squeak 5.0 only version 0.4 can be installed. If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed If I start on Pharo 1.3 no package will be installed 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1 ConfigurationOfPackage>>baseline08 "second baseline, it accounts for install in Pharo and Squeak" ConfigurationOfPackage>>version09: spec <version: '0.9'> spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) ... ]. spec for: #pharo do: [ ... ]. 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0: ConfigurationOfPackage>>baseline04 "third baseline, it accounts for install in Pharo and Squeak" ConfigurationOfPackage>>version10: spec <version: '1.0'> spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ]. So the tags come and go as the support for given forks and releases are tested. Different versions of the Package package can work in different forks and in different releases of those forks. It is always the job of the interested parties to add support (that is version methods and baselines, or simply tags to the worksIn: list) for a package in a given combination. What do you think? Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 17, 2010

Re: [Pharo-project] [squeak-dev] Re: Problem with variable capture in blocks or ? #7532

by Eliot Miranda

On Sun, May 16, 2010 at 3:32 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Ken - > > Very interesting. Looks like an issue with OutOfScopeNotification. The > problem appears to be that this code: > > "..." [ :a | a ]. > "..." a. > > generates an OutOfScopeNotification that is being suppressed in workspaces > (I'm not exactly sure why that is). This is of course is interesting because > of the highly unusual situation of a temp shadowing a global instead of > another temp / ivar. For example, this wouldn't compile: > > | a | > [ :a | a ]. > > But stranglely, this does: > > [ :Object | Object ]. > > so your example code is roughly equivalent to running: > > b := [ :Object | Object ]. > c := b value: Object. > > When you run this line by line it works 'as expected' and when you run it > as a single doIt you get the result of c being a "[closure] in > UndefinedObject>>DoIt" due to the OutOfScopeNotification. > > Hope this explains the issue - as for how to fix it, I have no clue :-) > Yes, the bug is that Encoder>>encodeVariable:sourceRange:ifUnknown: doesn't continue from a caught OutOfScopeNotification by answering the ifUnknown: action. Instead it returns the out-of-scope block temp. This is a rather serious compiler bug that I'd left unfixed because it only bites in workspaces (apologies) and I didn't have a small example to analyse before (thanks Ken!). The code generated is actually equivalent to b := [ :a | a ]. c := b value: <temp 0>. Since there aren't any temps, temp 0 is top of stack, which just happens to be the closure just created by the preceding bytecode. e.g. look at bytecode 49 in the following: a := 4. b := [ :a | a ]. c := b value: a. { a. b. c } thisContext method symbolic The fix is simple. When an OutOfScopeNotification is caught the Encoder should still answer what ever it should for an out of scope variable. In Encoder>>encodeVariable:sourceRange:ifUnknown: the statements (varNode isTemp and: [varNode scope < 0]) ifTrue: [ OutOfScopeNotification signal ifFalse: [ ^self notify: 'out of scope']. ]. ^ varNode should read (varNode isTemp and: [varNode scope < 0]) ifTrue: [^OutOfScopeNotification signal ifTrue: [action value] ifFalse: [self notify: 'out of scope']]. ^varNode Find attached: !Encoder methodsFor: 'encoding' stamp: 'eem 5/16/2010 17:33'! encodeVariable: name sourceRange: range ifUnknown: action | varNode | varNode := scopeTable at: name ifAbsent: [(self lookupInPools: name ifFound: [:assoc | varNode := self global: assoc name: name]) ifTrue: [varNode] ifFalse: [^action value]]. range ifNotNil: [name first canBeGlobalVarInitial ifTrue: [globalSourceRanges addLast: { name. range. false }]]. (varNode isTemp and: [varNode scope < 0]) ifTrue: [^OutOfScopeNotification signal ifTrue: [action value] ifFalse: [self notify: 'out of scope']]. ^varNode! ! P.S. this is probably applicable to any Squeak bytecode compiler (including eToys). The only change in my closure compiler from Andreas' 2003 version was changing "name first isUppercase" to "name first canBeGlobalVarInitial". P.P.S. Again Ken, thanks for a comprehensible example. It always bit me in huge doits I was using to analyse the entire system's compiled methods, and invariably crashed the VM. I never took the time to isolate the bug, I just fixed the doit and continued. Turns out to be very simple. best Eliot > Cheers, > - Andreas > > > > On 5/16/2010 12:35 PM, Ken Causey wrote: > >> Well, it's nothing new but this one has stumped me: >> >> http://bugs.squeak.org/view.php?id=7532 >> >> Initially I (and Frank) thought the reporter was mistaken until we >> understood that the problem shows up when you execute the main code all >> in one do-it. I've since modified the original report to make this >> clearer. >> >> So here it is: >> >> a := 4. >> b := [ :a | a ]. >> c := b value: a. >> >> If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial >> detail). The result is that a is 4, b is a BlockClosure, and c is a >> BlockClosure not 4 as expected. Execute each statement separately and c >> is 4. >> >> Alternately, from a suggestion from jmckeon, if you specify a different >> symbol for the block argument: >> >> a := 4. >> b := [ :d | d ]. >> c := b value: a. >> >> when executed all at one time works as you would expect: a is 4, b is a >> BlockClosure, and c is 4. (and d is nil) >> >> So what's up? >> >> Ken >> >> >> >> > >

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Miguel Enrique CobÃ¡ Martinez

Sent before finish it, sorry El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribiÃ³: > Hi Mariano, > > > I think Andreas' recent post to squeak-dev is most cogent o this > topic: > I don't see why. Lets see, Andreas said: "While looking into Metacello I also spent some time at the Pharo Metacello repository on Squeaksource. There are many interesting things to be said about it, both good and bad. Good things about it are that it's community maintained. Everyone can update everyone else's contributions and although that's not generally done, it offers a community approach to making sure things work. Something that for example both Universes and Squeakmap lack completely. What's problematic about the repository on the other hand is that for one thing one needs to unconditionally trust the code even before one has even decided to install it (this by far my biggest complaint about Metacello)." I don't buy this, how is this different than loading a package (Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse the full code in SqueakSource (slow as hell), I don't have any guarantees that the code doesn't does a true become: false in some initialization method somewhere. The same applies to the ConfigurationOfXXX packages. The advantage of loading it to your image is that at least you can use a real environment to analyze the code. If you are using the loader to update your critical mission deployment, well, given the current security foundations of Smalltalk, you're betting to the wrong horse. If you want more security is a matter of signing the package in Squeaksource somehow and checking the signature on loading in the image (like every reasonable linux distro does currently on installing packages), or using some kind of sandbox for loading untrused code. But that is completely other issue and has nothing to do with the Metacello way of work. In fact, Metacello it could be enhanced to check some kind of signature before loading and then the trust problem will be real targeted. "Also, I don't think that a single repository is a feasible option in the long term - it seems to me that supporting the cross-product of image and package versions is going to be problematic before too long. And of course browsing repositories with several dozen of packages to find what you need isn't exactly fun either." Of course, nobody denies that, and in fact is an issue that has been discussed several times before in this list. Check the Loader code that is being worked on. It searches, installs, and is easier to write than directly use ConfigurationOfXXX messages. "However, the problems can be turned on their head, and that's actually pretty insightful. Here's the basic idea: What if, instead of having a single repository for all image versions with separate packages for each config, we would instead have a single package simply called Configurations in the trunk? That Configurations package would contain all the "supported" configurations for Squeak (I'll get to that in a minute). The package would be community-maintained, just like any other package in trunk development process. This addresses the trust issues with Metacello, since the package has the same level of trust that all the other packages in a Squeak release have; it has been developed using the same principles." Won't work, because not everybody works on Squeak, in fact, most ConfigurationOfXXX have been created and tested first on Pharo. The idea Andreas propose is to have a Squeak configuration and Pharo a Pharo configuration, that very likely will be a hell of copy & paste of methods. The good thing of having separate ConfigurationOfXXX packages in a neutral repository (MetacelloRepository) is that everybody can add methods (one for each version and for each one of Squeak and Pharo if necessary) to a only one Configuration. What you propose is to forget that there are users of a package in both camps and that your solution propose that the maintainer create two or more configuration packages in distinct repositories (one for Squeak in trunk repo and one for Pharo in MetacelloRepository). This is not funny. Also, this just add other package to the base image, a package that will change a lot between different Squeak releases. Squeak 5 will have a package with 10 configurations, Squeak 6 will have a package with 45 configurations. The idea of core package or base package is that the package is not changing a lot between releases. Current ConfigurationOfXXX only needs Gofer or Installer in the base image. Maybe a future Pharo release will have Gofer and Loader in the base image but Loader doesn't grow unrestricted between Pharo releases. The MetacelloRepository will do. "What that gives us is a mechanism by which we suddenly can include Omnibrowser, Seaside, Magma, FFI and anything else people can come up with in Squeak without having to preload it in the shipping image." This is funny, I haven't realised that to this day it is imposible to have a Pharo Core image without packages installed by default. Good to know that this will be possible soon with this new Configurations package. "What it also means is that we can start removing packages from the image, replacing them with the proper configurations for how to load them back. What it means is that somebody with a new application (be that Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask for the configuration to be part of the next Squeak release, thereby contributing *directly* to that Squeak version." And this is really what I don't understand of the Squeak fellows, why, why should someone *ask* someone (people or board or institution) for permission to add a package to a released Squeak. Why? Why should I wait for the next release for my package to be *accepted*? This is non-sense. The current state of affairs permit me, even now that Pharo 1.0 has been released, to release my own package *aimed* on Pharo1.0 by just testing that works and publishing my ConfigurationOfXXX in the MetacelloRepository. The proposed solution is just plain wrong and completely "Squeakish" (lets have everything in the image) "Most importantly, however, is that we as the community can decide what we feel we want to support and what not. " What you base your judgements on to conclude this. The community decide what ConfigurationOfXXX is created, tested and maintained or supported. "To do that, I'm proposing to create a status of "Community Supported Package" in Squeak. What is that? A community supported package is a piece of software where we feel this is an important/interesting/novel package that should ship with this Squeak version. A community supported package can be loaded in a 'one-click' process directly from within the image. A community supported package is a package where we provide assurance that the package has been tested for this release." How is this different from the current #released, #stable, #development tags you can use in Metacello to mark the status level of a given package in a given released Pharo or Squeak version? "However, that status does not come for free. In return for achieving this status, the software needs follow the rules for community supported packages, which (at least) should include the following: * No conflicts. Neither class names nor -override categories. The rationale is that all community supported packages can be loaded together without creating conflicts." This is an artificial restriction. Debian and derived ones and Red Hat and derived ones distros permit to install conflicting packages from the same universe without problems. You see, is the decision of the user and not the maintainer or distro packager what to install. For example you can't install (well you can, but you shouln't most times) Sendmail at the same time that Exim or Postfix. They are conflicting packages and the system only warns you about the conflicts. But the system permits you install them if you want. The same applies to the overrides. If I want to install two packages that have overrides over the same methods that is my problem. The system should only warn me and let me do what I want. "* Tests mandatory. A community supported package MUST have tests. The rationale is that since we provide the guarantee that the package has been tested, we need to ensure that testing can be automated to the maximum extent possible. It doesn't mean 100% coverage but *some* meaningful set of tests need to be provided or else we can't say if we broke it in the latest update." This is good no matter the package system on hand. But this is also an artificial restriction. A package can work (and for a lot of people can be useful) even if no single test is provided. Would you denied them the posibility of install the package in your image. This only will push users away from your image "4. Provide a better installer than these awful doIts for Metacallo." This is the job of the tools, as Dale has said from the beginning. And there are tools to simplify the install of package both in a workspace doit or with GUI "5. Establish a test server to automatically verify the community standards for supported packages (i.e., load packages randomly, ensure no conflicts, run tests, report results)." This is something also being worked on since a while. A Hudson server has been proposed for this. "At this point, there is another clearly defined way to contribute to Squeak even if you're not a core developer: Develop your software, provide a configuration, ensure your software adheres to the community standards." But this already exists, or we live in different worlds? So, what is really new or advantageous in this proposal? I really don't see it. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Miguel Enrique CobÃ¡ Martinez

El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribiÃ³: > Hi Mariano, > > > I think Andreas' recent post to squeak-dev is most cogent o this > topic: > I don't see why. Lets see, Andreas said: "While looking into Metacello I also spent some time at the Pharo Metacello repository on Squeaksource. There are many interesting things to be said about it, both good and bad. Good things about it are that it's community maintained. Everyone can update everyone else's contributions and although that's not generally done, it offers a community approach to making sure things work. Something that for example both Universes and Squeakmap lack completely. What's problematic about the repository on the other hand is that for one thing one needs to unconditionally trust the code even before one has even decided to install it (this by far my biggest complaint about Metacello)." I don't buy this, how is this different than loading a package (Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse the full code in SqueakSource (slow as hell), I don't have any guarantees that the code doesn't does a true become: false in some initialization method somewhere. The same applies to the ConfigurationOfXXX packages. The advantage of loading it to your image is that at least you can use a real environment to analyze the code. If you are using the loader to update your critical mission deployment, well, given the current security foundations of Smalltalk, you're betting to the wrong horse. If you want more security is a matter of signing the package in Squeaksource somehow and checking the signature on loading in the image (like every reasonable linux distro does currently on installing packages), or using some kind of sandbox for loading untrused code. But that is completely other issue and has nothing to do with the Metacello way of work. In fact, Metacello it could be enhanced to check some kind of signature before loading and then the trust problem will be real targeted. "Also, I don't think that a single repository is a feasible option in the long term - it seems to me that supporting the cross-product of image and package versions is going to be problematic before too long. And of course browsing repositories with several dozen of packages to find what you need isn't exactly fun either." Of course, nobody denies that, and in fact is an issue that has been discussed several times before in this list. Check the Loader code that is being worked on. It searches, installs, and is easier to write than directly use ConfigurationOfXXX messages. "However, the problems can be turned on their head, and that's actually pretty insightful. Here's the basic idea: What if, instead of having a single repository for all image versions with separate packages for each config, we would instead have a single package simply called Configurations in the trunk? That Configurations package would contain all the "supported" configurations for Squeak (I'll get to that in a minute). The package would be community-maintained, just like any other package in trunk development process. This addresses the trust issues with Metacello, since the package has the same level of trust that all the other packages in a Squeak release have; it has been developed using the same principles." Won't work, because not everybody works on Squeak, in fact, most ConfigurationOfXXX have been created and tested first on Pharo. The idea Andreas propose is to have a Squeak configuration and Pharo a Pharo configuration, that very likely will be a hell of copy & paste of methods. The good thing of having separate ConfigurationOfXXX packages in a neutral repository (MetacelloRepository) is that everybody can add methods (one for each version and for each one of Squeak and Pharo if necessary) to a only one Configuration. What you propose is to forget that there are users of a package in both camps and that your solution propose that the maintainer create two or more configuration packages in distinct repositories (one for Squeak in trunk repo and one for Pharo in MetacelloRepository). This is not funny. Also, this just add other package to the base image, a package that will change a lot between different Squeak releases. Squeak 5 will have a package with 10 configurations, Squeak 6 will have a package with 45 configurations. The idea of core package or base package is that the package is not changing a lot between releases. Current ConfigurationOfXXX only needs Gofer or Installer in the base image. Maybe a future Pharo release will have Gofer and Loader in the base image but Loader doesn't grow unrestricted between Pharo releases. The MetacelloRepository will do. "What that gives us is a mechanism by which we suddenly can include Omnibrowser, Seaside, Magma, FFI and anything else people can come up with in Squeak without having to preload it in the shipping image." This is funny, I haven't realised that to this day it is imposible to have a Pharo Core image without packages installed by default. Good to know that this will be possible soon with this new Configurations package. "What it also means is that we can start removing packages from the image, replacing them with the proper configurations for how to load them back. What it means is that somebody with a new application (be that Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask for the configuration to be part of the next Squeak release, thereby contributing *directly* to that Squeak version." And this is really what I don't understand of the Squeak fellows, why, why should someone *ask* someone (people or board or institution) for permission to add a package to a released Squeak. Why? Why should I wait for the next release for my package to be *accepted*? This is non-sense. The current state of affairs permit me, even now that Pharo 1.0 has been released, to release my own package *aimed* on Pharo1.0 by just testing that works and publishing my ConfigurationOfXXX in the MetacelloRepository. The proposed solution is just plain wrong and completely "Squeakish" (lets have everything in the image) "Most importantly, however, is that we as the community can decide what we feel we want to support and what not. " What you base your judgements on to conclude this. The community decide what ConfigurationOfXXX is created, tested and maintained or supported. "To do that, I'm proposing to create a status of "Community Supported Package" in Squeak. What is that? A community supported package is a piece of software where we feel this is an important/interesting/novel package that should ship with this Squeak version. A community supported package can be loaded in a 'one-click' process directly from within the image. A community supported package is a package where we provide assurance that the package has been tested for this release." How is this different from the current #released, #stable, #development tags you can use in Metacello to mark the status level of a given package in a given released Pharo or Squeak version? "However, that status does not come for free. In return for achieving this status, the software needs follow the rules for community supported packages, which (at least) should include the following: * No conflicts. Neither class names nor -override categories. The rationale is that all community supported packages can be loaded together without creating conflicts." This is an artificial restriction. Debian and derived ones and Red Hat and derived ones distros permit to install conflicting packages from the same universe without problems. You see, is the decision of the user and not the maintainer or distro packager what to install. For example you can't install (well you can, but you shouln't most times) Sendmail at the same time that Exim or Postfix. They are conflicting packages and the system only warns you about the conflicts. But the system permits you install them if you want. The same applies to the overrides. If I want to install two packages that have overrides over the same methods that is my problem. The system should only warn me and let me do what I want. "* Tests mandatory. A community supported package MUST have tests. The rationale is that since we provide the guarantee that the package has been tested, we need to ensure that testing can be automated to the maximum extent possible. It doesn't mean 100% coverage but *some* meaningful set of tests need to be provided or else we can't say if we broke it in the latest update." This is good no matter the package system on hand. But this is also an artificial restriction. A package can work (and for a lot of people can be useful) even if no single test is provided. Would you denied them the posibility of install the package in your image. There may be some other guidelines that we may want to establish but I'm trying to keep things simple and only the above two are truly crucial - what they allow is to ensure that during ongoing trunk development we will always be able to load all supported packages, run the tests and see if we broke something horribly. So the goal of the process is that if we do this right, we should be able to tell how good (or how bad) a shape we're in regarding the supported packages when we get to ship date. We should be able to encourage people who write libraries or apps with, for, and in Squeak, to contribute directly to the next release by providing a configuration, their code, and the tests so that we can keep things running. In return, we'll help with porting, provide backwards compatibility as required etc. Code that we want to move out of the default image would be moved into a configuration so people can load it if desired, and it remains a part of Squeak instead of rotting away. Since the Configuration package is small and has no dependencies, there's no problem to include that in core/basic images and allow people to tailor custom images from there. Concretely, I'm seeing the following steps as necessary: 1. Establish the status and the rules for "Community Supported Packages". 2. Create the "Configurations" package and start populating it with some examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like. 3. Encourage people to bring their packages up to 'community standards' and include them in the Configurations. From here, there are a few more things that we should do before we can ship the next Squeak version: 4. Provide a better installer than these awful doIts for Metacallo. 5. Establish a test server to automatically verify the community standards for supported packages (i.e., load packages randomly, ensure no conflicts, run tests, report results). At this point, there is another clearly defined way to contribute to Squeak even if you're not a core developer: Develop your software, provide a configuration, ensure your software adheres to the community standards. That's it. You've just made the next Squeak release a little better :-) -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 17, 2010

Re: [Pharo-project] ConfigurationOfExternalWebBrowser working in Squeak and Pharo trunk

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > if this is based on applescript you get the answer :) > It looks like Applescript is only necessary for pre-unix (OS X?) Macs, so this could be removed? Also, Andreas mentioned that even Applescript could be rewritten without its own plugin and use FFI (http://wiki.squeak.org/squeak/1414.diff?id=17) Sean -- View this message in context: http://forum.world.st/ConfigurationOfExternalWebBrowser-working-in-Squeak-a… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Sean P. DeNigris

I posted this on Squeak-dev @ http://forum.world.st/Community-Supported-Packages-td2217473.html#a2218970: I eagerly read all the discussions and offer my humble contribution (posting to Pharo too, because I think the benefit is cross-platform): I'm overjoyed that we are digging in and making packages easily loadable (or clear that they are not). I don't know what I'll do with all the hours I currently spend fishing for working versions ;-) Overall the goals seem to be (put best in a post from Mariano Peck): * have a specific catalog of working and tested projects for each platform (Pharo 1.0, Pharo 1.1, Squeak 4.0, Squeak 4.1...) * Be able to have a hudson server running and testing such configurations. * Unified way to load a project. * (I added this one) have the least amount of effort for the developer The Pharo and Squeak versions both sound intriguing. I suggest one addition that would magnify all of the above, and eliminate the accidental complexity that versioning is adding to the mix: ***Extend Metacello specs to account for platform version (e.g. Pharo 1.0 vs. 1.1)*** In effect, since we are distilling the platforms down to the pure good stuff - each version is a whole different platform; from a developer's perspective, it's the same process porting to different forks and porting to new versions of the same fork - either way, incompatible interfaces. A hypothetical developer perspective: - Porting from Squeak to Pharo: I'm a developer with a project that works on Squeak 4.0. Now, I decide to port it to Pharo 1.0. So I crank up a new image and... wait, how do I load it? I don't have a ConfigOf. So I either alter the Config #squeak to #squeakCommon, or load manually. Now, it doesn't load because there are classes that don't exist in Pharo, so one by one, I move the platform-specific code into Platform.squeak and Platform.pharo. - Pharo 1.0 to Pharo 1.1: Now, Pharo 1.1 is released, with even fewer classes - tight core, yay! So I go through the same process, but now I have *three platforms* - Pharo 1.0, 1.1, and Squeak 4.0. User perspective: simple - I want to have *one* place to go where I know that all the packages there will work in my image, and cut out all the junk. And, if I'm feeling adventurous, I'd like *one* place to see what else is out there, but very clear that it's not up to community standards - for inspiration, to port to my platform, or to steal code :) Once you have Metacello handling the versions * the developers go from fork*version configs to one config * the version problem is handled * all other features of the current plans are preserved This is what I envision at the intersection of what's been proposed and Metacello versioning: * Configs are either: - in one central location; it won't matter because we went from projects*forks*versions Configs to just 1*projects. - or, kept with the projects they reference e.g. pick squeaksource.com, and every project repository keeps its own ConfigurationOf (might diminish the community involvement if read-only repos) >Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473) >Good things about it are that >it's community maintained. Everyone can update everyone else's >contributions and although that's not generally done, it offers a >community approach to making sure things work. * Each platform (fork + version combo) (via hudson server? I don't know much about them) tries to load each Config from the central repository. If it meets the community standards (no conflicts, tests, etc.), either the Config is copied to that platform/fork's list of compatible Configs, or a reference is added. * If it doesn't load, another list could be kept with the result of the attempt to load, so anyone who wants to use or port it has a heads up on the status. So: * we don't need a separate Config for fork*version platforms. Right now, it seems the implementation and behavior are collapsed - we don't care where the actual Configs are (at least in the Pharo plan), as long as we know which ones work. Which resolves Andreas's concern with a single repository: > Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473) > Also, I don't think that a single repository is a feasible option in the long > term - it seems to me that supporting the cross-product of image and > package versions is going to be problematic before too long. And of > course browsing repositories with several dozen of packages to find what > you need isn't exactly fun either. and eliminated manual fiddling with the Config file: > Pharo proposal @ http://groups.google.com/group/metacello/browse_thread/thread/42c088d58acfb… > [developers will copy configs that work in Pharo x.y to] PharoxyMetacelloRepository, then add class>>load for Pharo 1.0 version. * there is still one place to install for a user's platform * you really do get "a standard way to load the packages on such repository: just send the message load" because the spec already knows whether it will work on that platform * you still get a Pharo [and Squeak] release with the correct repository as default (already added in Monticello Browser) - this is your list you copied over Thanks. Sean -- View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-pleas… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2010