- Pharo-dev - lists.pharo.org

[Pharo-project] Bugs on bugs.squeak.org

by Marcus Denker

Hi, bugs.squeak.org is a mess. (and people wonder why I always stress that doing harvesting was a lot of work... we got the tracker down to 250 entries with 3.9, if I remember correctly). Even for 3.11, they will have some real work ahead to get this in some form of managable shape. Now for Pharo, I don't see that we can benefit from the bug-tracker at all anymore: there is so much stuff, no way to do here anything in a strategic, "all covering" way, as we did for example when moving from BFAV to Mantis. So if someone has reported a bug against Squeak, the only way I see this change ending up in pharo is that the bug is reported again on the pharo tracker. So if you want something to be fixed: http://code.google.com/p/pharo/issues/list (down to 79 open issues, we already fixed and closed 96 reports) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

[Pharo-project] Non-pharo reports in pharo bugtracker...

by Marcus Denker

Hi, There are reports in the pharo tracker that are not solvable because the software the bug is reported about is not part of pharo. I wonder if that makes sense... from the bug-fixing of Squeak, I have found that it's very important to keep the numner of open issues as small as possible. (the nearly 1000 open reports they gatheres when doing 3.10 in Squeak is completely unmanagable, for example). I would suggest to put these reports on a wiki page, instead of the bugstracker. Or report them to the developers of the package. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Alexandre Bergel

> p.s. Alexander, please don't edit Installer and break it for everyone > else. Installer is for all squeak images, not just for Pharo. > p.p.s. Please keep sufficient compatibility in Pharo so at least > Installer can get past the initial bootstrap. Ah!! Some methods are deprecated solely in Pharo. Since Installer is calling some deprecated methods in Pharo, some unit tests related to the authoring go red because these test check there is no call do this deprecated method in the image. Probably this test should be moved somethere else. Maybe having an image verifier or something would help to ensure some basic invariant in the image (such as no call to deprecated method). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

>>> >>>> HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' >>>> > > The LPF script only loads MC1.5 you need to load SystemEditor and > enable > the atomic loading preference. > This will do it. OK > > Installer install: 'Monticello16-Beta'. > >>> - do you have a version of MC1.6 that does not really on LPF >>> (whatever)? >>> >> >> No; LPF is the script to load MC1.5. However, I think I'll try >> moving LPF off of pbwiki and into something that builds a .sar >> file, hosted on svn or squeaksource or something. >> > The first half of the script is the bootstrap of Installer in > http://installer.pbwiki.com/f/LPF.st > > The second half of the script is available via > > Installer view: 'LevelPlayingField'. > > Keith > > p.s. Alexander, please don't edit Installer and break it for everyone > else. Installer is for all squeak images, not just for Pharo. Can you tell us what were the changes? > p.p.s. Please keep sufficient compatibility in Pharo so at least > Installer can get past the initial bootstrap. Sure.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

Hi matthew did you try to load the package I mentioned? > > No; LPF is the script to load MC1.5. However, I think I'll try > moving LPF off of pbwiki and into something that builds a .sar > file, hosted on svn or squeaksource or something. Sounds the way to go. We will never rely on a script on a web site.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Keith Hodges

Matthew Fulmer wrote: > On Fri, Sep 12, 2008 at 05:41:17PM +0200, St?phane Ducasse wrote: > >> Hi matthew >> >> we wanted to see if MC1.6 (the one with actomic loader) could load the >> compiler fixes >> Compiler-md.67 available in pharoInbox >> >> We tried >> >>> HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' >>> The LPF script only loads MC1.5 you need to load SystemEditor and enable the atomic loading preference. This will do it. Installer install: 'Monticello16-Beta'. >> and it broke on us. >> >> so two requests: >> - could you give a try and tell us if you can load the package? >> > > No; it is broken for everybody. I've heard this report a couple > of times. It seems we need to change the hosting of LPF > > No we dont, we just have to slow requests down a bit. I put a couple of delays in it should work now >> - do you have a version of MC1.6 that does not really on LPF >> (whatever)? >> > > No; LPF is the script to load MC1.5. However, I think I'll try > moving LPF off of pbwiki and into something that builds a .sar > file, hosted on svn or squeaksource or something. > The first half of the script is the bootstrap of Installer in http://installer.pbwiki.com/f/LPF.st The second half of the script is available via Installer view: 'LevelPlayingField'. Keith p.s. Alexander, please don't edit Installer and break it for everyone else. Installer is for all squeak images, not just for Pharo. p.p.s. Please keep sufficient compatibility in Pharo so at least Installer can get past the initial bootstrap.

Sept. 16, 2008

Re: [Pharo-project] Call for ideas for a Continuous Integration server

by Alexandre Bergel

Sorry about this email, it essentially says that I need to go to sleep... Alexandre On 16 Sep 2008, at 23:07, Alexandre Bergel wrote: > Dear List, > > Here are the notes I took on AmbientTalk. > > In Ambientalk: > > Table: > >def table[5] { z := z + 1 } > >>[1, 2, 3, 4, 5] > > > Table splicing: > >[1,@[2,3],4] > >>[1, 2, 3, 4] > >def [first, @rest] := [1,2,3,4] > >>[1, 2, 3, 4] > >rest > >>[2, 3, 4] > > > Function > >def square (x) { x*x } > >>nil > >square(5) > >>25 > > There is no check about fulfilling required methods. There is a way > to declare a method as required. > Required method are part of a structural type. Reflection is then > used to ensure that a composition makes sense at composition time. > Aliasing changes the name on the surface (it is not a rename), and > does not create a new entry. > The import clause (which is used to use a trait), may accept any > expression, and not only a trait name. > There is no precedence of the locally defined methods. > > Note that traits are composed when object composer are instantiated. > > Ambientalk may use the same trick than in Smalltalk to declare a > method as required (self requiredMethod), but the lack of precedency > is problematic. > The fact that you do not have precedency, implies that a method used > in a trait needs to be specify as required (using the reflective > trick mentioned above) in case of the composer is likely to not > provide an implementation for this method. Else, better is not mark > the used method as required since the composer will have to exclude > it when using the trait. > > Two methods that are acquired using different import path are not > conflicting since they are the same compiled method. > In Ambientalk, this will always cause a conflict since methods are > âduplicatedâ between composers. In Ambientalk, deep equality (i.e., > comparing bytecode instructions) may not lead to what we want since > methods can be nested. > > The Morphic framework. > Inspired from the Self version and has been influenced by John > Maloneyâs work. > Requirement between traits is specified with for exemple require: > [Trait1, Trait2], in that case, all public methods defined in Trait1 > and Trait2 will be set as required method for the trait that made > the require. > This framework is composed of 18 traits > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2008

[Pharo-project] Call for ideas for a Continuous Integration server

by Alexandre Bergel

Dear List, Here are the notes I took on AmbientTalk. In Ambientalk: Table: >def table[5] { z := z + 1 } >>[1, 2, 3, 4, 5] Table splicing: >[1,@[2,3],4] >>[1, 2, 3, 4] >def [first, @rest] := [1,2,3,4] >>[1, 2, 3, 4] >rest >>[2, 3, 4] Function >def square (x) { x*x } >>nil >square(5) >>25 There is no check about fulfilling required methods. There is a way to declare a method as required. Required method are part of a structural type. Reflection is then used to ensure that a composition makes sense at composition time. Aliasing changes the name on the surface (it is not a rename), and does not create a new entry. The import clause (which is used to use a trait), may accept any expression, and not only a trait name. There is no precedence of the locally defined methods. Note that traits are composed when object composer are instantiated. Ambientalk may use the same trick than in Smalltalk to declare a method as required (self requiredMethod), but the lack of precedency is problematic. The fact that you do not have precedency, implies that a method used in a trait needs to be specify as required (using the reflective trick mentioned above) in case of the composer is likely to not provide an implementation for this method. Else, better is not mark the used method as required since the composer will have to exclude it when using the trait. Two methods that are acquired using different import path are not conflicting since they are the same compiled method. In Ambientalk, this will always cause a conflict since methods are âduplicatedâ between composers. In Ambientalk, deep equality (i.e., comparing bytecode instructions) may not lead to what we want since methods can be nested. The Morphic framework. Inspired from the Self version and has been influenced by John Maloneyâs work. Requirement between traits is specified with for exemple require: [Trait1, Trait2], in that case, all public methods defined in Trait1 and Trait2 will be set as required method for the trait that made the require. This framework is composed of 18 traits -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Fri, Sep 12, 2008 at 05:41:17PM +0200, St?phane Ducasse wrote: > Hi matthew > > we wanted to see if MC1.6 (the one with actomic loader) could load the > compiler fixes > Compiler-md.67 available in pharoInbox > > We tried > > HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > > and it broke on us. > > so two requests: > - could you give a try and tell us if you can load the package? No; it is broken for everybody. I've heard this report a couple of times. It seems we need to change the hosting of LPF > - do you have a version of MC1.6 that does not really on LPF > (whatever)? No; LPF is the script to load MC1.5. However, I think I'll try moving LPF off of pbwiki and into something that builds a .sar file, hosted on svn or squeaksource or something. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Sept. 16, 2008

Re: [Pharo-project] Re: is pharo ready for production?

by StÃ©phane Ducasse

esteban I think that you can really use pharo for development and give us feedback. for deployment you may switch in alpha phase if needed. The path will be long but the journey is really worth :) Stef On Sep 16, 2008, at 8:06 PM, Esteban Lorenzano wrote: > Hi, > Thanks for the answers. > The main reason I want to run the application on Pharo is because > I'm agree with it's objetives, and I been following the project > advance through the list and I'm very happy with the ongoing work. > Unfortunately, I'm to busy to offer some help... but maybe I can > help on "testing" by using Pharo on a commercial project... > So, following Adrian suggestion, as my project will take 4-5 months > of development, I think the best path should be to wait a little and > start using Pharo in a couple of months. > And of course, I want to produce professional applications, so what > better to use a professional version of squeak? :) > > Cheers, > Esteban > > On 2008-09-16 13:49:48 -0300, Adrian Lienhard <adi(a)netstyle.ch> said: > >> Hi Esteban >> As Stef said, you should not run into major problems because the core >> on which a Seaside application usually depends has not changed >> much. The parts of Pharo that have undergone major changes (or >> that have been totally removed) will likely not affect you. >> I think that you should also take into account when you plan to go >> live. If this is in just another week or two, I would not go for >> Pharo. However, if this is a larger project that takes longer, then I >> suggest to use Pharo. I think we will be fast to fix bugs if you >> report them (whereas at the Squeak side the activity seems to be a >> bit >> less than over here ;)). And over time more and more people will >> start >> to use Pharo in professional projects too. >> Please let us know how you decide and in case you run into any >> troubles that need our attention. >> Cheers, >> Adrian >> On Sep 16, 2008, at 18:02 , StÃ©phane Ducasse wrote: >>> Hi Esteban >>> Lukas is developing seaside on pharo. Netstyle will certainly use it >>> once the first release is out. >>> Now the point is do you need the improvements we are doing? >>> May be 3.9 is good enough or pavel image. >>> From a stability point of view the changes are currently low from >>> api changes - we are cleaning a lot >>> but not changing. And this may change a bit in the >>> future but this is ineluctable. If people want something better they >>> have to ack changes. >>> We will also try to keep changes to the minimum but not less. We >>> want a better system >>> and as such it will change. >>> Stef >>> On Sep 16, 2008, at 5:39 PM, Esteban Lorenzano wrote: >>>> Hi, >>>> I'm planning to start a new commercial, seaside based project in a >>>> few weeks, and I wish to start it in Pharo, but I'm afraid is >>>> not very stable yet... >>>> Can somebody tell me if is usable right now and if not, more or >>>> less when it will be? >>>> Thanks, >>>> Esteban >>>> _______________________________________________ >>>> 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 >

Sept. 16, 2008