July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] request for the new merge tool :)

by Damien Cassou

On Mon, Jul 6, 2009 at 10:07 AM, Gary Chambers<gazzaguru2(a)btinternet.com> wrote: > Should be straightforward... > Any other menu options you'd like? Please Gary... add labels on top of the code areas. I want to know what is displayed on the left and what is on the right :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 6, 2009

[Pharo-project] Fwd: [squeak-dev] SkipLists removal

by Damien Cassou

---------- Forwarded message ---------- From: Ken Causey <ken(a)kencausey.com> Date: Sat, Jul 4, 2009 at 8:08 PM Subject: [squeak-dev] SkipLists removal To: Squeak Devel List <squeak-dev(a)lists.squeakfoundation.org> Cc: stephane ducasse <stephane.ducasse(a)free.fr>, Tom Koenig <tomkoenig(a)mindspring.com> SkipLists contains code under SqueakL as well as under MIT. Â Two contributors have not signed the agreement and appear to be uncontactable. Â SkipLists are not used in the image and are easily extractable. Â To that end I have done so and published a new version of Collections without them and an external package. References: http://bugs.squeak.org/view.php?id=7359 http://source.squeak.org/trunk/Collections-klc.93.mcz http://www.squeaksource.com/SkipLists.html Ken -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 6, 2009

[Pharo-project] clean out Undeclared

by Pavel Krivanek

Hi, the patch in the issue http://code.google.com/p/pharo/issues/detail?id=637cleans out Undeclared in the image 10342. -- Pavel

July 6, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Janko MivÅ¡ek

Hi Reinout, Just to say - I'm in pretty similar position as you, trying to use Squeak and friends for my commercial work (which is still on VisualWorks for now), that's why I really like the progress Pharoers did so far and I'm supporting them as much as I can. Which does not mean I stopped supporting Squeak, as I like any good progress in any Smalltalk. We need to stand by the guys doing great work on a tools which we "commercial" guys then use for a living :) Best regards Janko Reinout Heeck pravi: >> Please note that Pharo is not even yet in beta, so some of the snags >> you mention will no doubt get fixed as the feature list finalizes. >> As an open source project, there will be a certain amount of bias >> toward what is important to the heavy contributors. I hope those >> will include organizations such as yours to push Pharo in the >> direction of a stable performance-oriented environment on top of >> which a mix of commercial and academic projects will flourish. > > Yes, yes, yes :-) > This is why I showed up here, at the moment it is just me probing > around in my private time but the motivation is to lobby for > considering its use at my work. > I assume there will be loads of additions required before we can even > use it in the small there and clearly such additions won't just appear > unless we contribute heavily towards them ourselves. (Off the cuff I'm > thinking of requirements like full SOAP(all versions!) with support > tools, multiple windows, COM interfacing etc, etc, but I need to cut > my teeth on the basics first before I want to start discussing such > things here). > > Baby steps will do just fine ;-) > > > Thanks! > > Reinout > ------- -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

July 6, 2009

Re: [Pharo-project] request for the new merge tool :)

by Gary Chambers

The version option is already there (existing versions in changes/sources files). It might be possible for non-conflicting methods to have the "Keep current version"/"Use incoming version" options enabled to effectively manage the same as the proposed "Install" option. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, July 06, 2009 10:34 AM Subject: Re: [Pharo-project] request for the new merge tool :) Thanks gary. may be version Install is really important because it allows one to somehow cherry pick changes when we should not load the complete changes set. Stef On Jul 6, 2009, at 10:07 AM, Gary Chambers wrote: > Should be straightforward... > Any other menu options you'd like? > > Regards, Gary > > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, July 04, 2009 5:02 PM > Subject: [Pharo-project] request for the new merge tool :) > > >> hi gary >> >> it would be important to be able to install a method by clicking on >> it >> as we could do it in the old one. >> >> 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by StÃ©phane Ducasse

> >> the update is only working for the core because OB is not part of >> pharo but an add-on. >> And the add-on are not managed by the pharo stream of changes but by >> an update of >> the projects in the pharo Universe (yes this is complex but we do not >> want that people can >> say that we are hijacking squeak tools). > > The motivation is fair, but the current solution seems untenable... Yes > > I think we should consider cribbing from the model that Linux distros > use: > > Load (more precisely: use -- we might not be able to load it) a / > specific/ version of the Squeak tool, and then apply a separate > (Pharo- > maintained) set of patches to make it Pharo compliant. but only the developer of the tool can do that. > Define a process to specify how bug fixes are to be pushed upstream, > and how enhancements are pulled downstream -- reassessing the Pharo > patches each time a new version is pulled downstream. > > This way the tool is never hijacked but Pharo has a clear story on how > it remains stable/unbreakable. > If pushing bug fixes upstream is supported directly by tools we might > even be able to make the argument that Pharo is helping the tool > builders make better Squeak tools ;-) :) >>> >> >> Yes >> Normally with Squeak, severe bugs and selected one where retrofitted >> in old versions. This way seaside 3.8 users got important fixes when >> we did 3.9. > > It depends on how often Pharo wants to do a 'stable' release, if that > is once every two years I don't see a problem with this model. we could see that. It also depends on the pace of changes. because Pharo 1.0 got a lot of deep changes like closures. I do not expect that huge changes in the future. > But if that happens more often we will need to maintain a lot of older > releases to make them viable for commercial use, thus spreading our > resources thin. Hence my desire to pick only select releases that are > designated to receive 'long term support' so bugfix back-porting > efforts are concentrated on only one or two older releases to keep > those alive for say 3+ years. Yes I see. > [...for version management] >> The vision is bytecode loader > > Pleas don't go there. Byte-code loading is a very nice-to-have in > deployment scenarios (lazy plugin loading, live update delivery to > deployed apps etc) but if there is one thing that using VW's Store has > taught me it is that it definitely should not be part of a code > repository that is used for development code version management. This is in VW store is bad. I do not see why a package MCZ could not ship with a byte-code synchronized version of the source. Then we could have a stripper or a synchronizer that recompile the source code and produce new bytecode. > In the case of VW+Store standardizing on using only source-loading has > served us well, it is definitely fast enough. > Building our 'refactoring' image that holds all our projects (almost > 100 MB image -- just code) takes less than an hour which is quite > alright in a scenario where one uses nightly builds and updates the > resulting image during the day-time development cycle. I suggest to > get source-loading/diffing et al up to speed first. we will start by fixing packageInfo stef

July 6, 2009

Re: [Pharo-project] Tests

by StÃ©phane Ducasse

traits at work :) Stef On Jul 5, 2009, at 12:36 PM, Adrian Lienhard wrote: > Running the tests in the latest core (10371), I get the following > results: > 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors > > Comparing to the last result in 10292cl [1]: > 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors > > > > I wonder how it is possible to get from 3029 to 5154 tests? > > Cheers, > > Adrian > > > > [1] http://code.google.com/p/pharo/wiki/BaselineTestResults > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] request for the new merge tool :)

by StÃ©phane Ducasse

Thanks gary. may be version Install is really important because it allows one to somehow cherry pick changes when we should not load the complete changes set. Stef On Jul 6, 2009, at 10:07 AM, Gary Chambers wrote: > Should be straightforward... > Any other menu options you'd like? > > Regards, Gary > > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, July 04, 2009 5:02 PM > Subject: [Pharo-project] request for the new merge tool :) > > >> hi gary >> >> it would be important to be able to install a method by clicking on >> it >> as we could do it in the old one. >> >> 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

July 6, 2009

Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate

by StÃ©phane Ducasse

Hi nevin our goal is not predominancy :) It was never. I would be happy that squeak offers a really good multimedia platform. Our goal is to deliver good open source smalltalk. Our goal is to get agile, rethink the system, use good software engineering practices (systematic smallLnt rules), tests.... We want to propose/accept/evaluate new solutions: first class package, first class instance variables, better refactoring support, may be modules, security, new compiler.... Smalltalk deserves a clean and powerful implementation and we will work on that hard. Stef PS: you can forward this answer to squeak-dev if you feel the need. On Jul 6, 2009, at 3:17 AM, Nevin Pratt wrote: > There's no right or wrong answer to the following three questions. > And, > every response is meaningful, because it helps reveal the general > sense > of direction that the community is feeling. > > *********************** > Question #1: Of the various Squeak forks (such as Croquet, Pharo, > etc.), > what is your feeling of their relative popularities at this point in > time, and how does that compare with the current popularity of the > base > Squeak distribution? > > Question #2: This is related to the above-- what is your feeling of > the > relative popularity *trend* of each of the forks, and how does that > compare with your feeling of the *trend* of the future popularity of > the > base Squeak distribution? > > Question #3: What is your justification for your answers to the above > two questions? > ************************ > > I'll begin with my own answers... > > ...I'm beginning to feel like the Pharo fork currently now has maybe > 50% > or more of the popularity of the base Squeak distro, and I'm beginning > to feel like Pharo is headed to become the dominant distribution in > the > future, surpassing the original Squeak distro. And I base that > feeling > on several observations: > > 1. The email traffic comparison on the "Pharo-project" email list > compared to the email traffic on "The general-purpose Squeak > developers > list", and the observed trend in such traffic. > > 2. The number of developers posting on the Pharo-project email list. > > 3. The specific developers posting on the Pharo-project email list > (known Squeakers who have contributed heavily to Squeak in the past). > > 4. The fact that Seaside development has moved to Pharo. > > At one time I wondered if Croquet would become the dominant Squeak > fork, > for the simple reason that it had a business organization "officially" > supporting it, similar to what Squeak had in the Disney days. But > now I > think I would bet my money on Pharo. > > What do you think? And why? > > Also, remember, there's certainly nothing wrong with several > "dominant" > forks existing. But of those, one of them will still be the most > popular overall. And I'm curious about thoughts of which one that is, > and which one that will become, and why you think so. > > Nevin > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] FFI problem

by StÃ©phane Ducasse

Reported by Benoit St-Jean in mailing list. To reproduce it: Download latest Windows VM (Squeak 3.11.2) from Pharo webpage. Then evaluate ScriptLoader loadFFI and try to run FFI tests. The image will crash! Tried in Linux and had no problem. There are crash2.dmp and crash.dmp attached. One from Andreas and another from Benoit St-Jean. Andreas Raab said: "Interesting. This appears to be a Pharo-only problem. I ran the FFI tests using the 3.11.2 VM on the current 3.10.2 release image and they works fine. I've also ran the test against a 3.10.2 closure converted image (on the off-chance that it might be closure related) and the tests pass too. So I don't really think it's an FFI problem. You'll probably have to ask Pharo people to help you with the problem; the FFI appears to be fully functional on both pre- and post-closure images." Comment 1 by amtw...(a)hotmail.com, Jul 04 (44 hours ago) I thought I would take a look at this, but ScriptLoader loadFFI doesn't work anymore. It would appear that this is because http://source.squeakfoundation.org/FFI no longer exists. Delete comment Comment 2 by marianopeck, Yesterday (35 hours ago) You can download it from source.squeak.org now Delete comment Comment 3 by amtw...(a)hotmail.com, Yesterday (32 hours ago) After loading from source.squeak.org and running the tests, I get inconsistent results. Sometimes the image crashes; sometimes I get 1 error and 1 failure. Further investigation shows that FFI-Kernel-ar. 9.mcz has lost its postscript definition and so 'Smalltalk recreateSpecialObjectsArray.' is not run when it is loaded/unloaded. To ensure that it runs correctly, evaluate "Smalltalk recreateSpecialObjectsArray." after loading . Delete comment Comment 4 by marianopeck, Today (14 hours ago) Andrew: I don't know what "Smalltalk recreateSpecialObjectsArray." is, but I evaluated that after loadFFI and tests worked perfect! What we can change is the ScriptLoader>>loadFFI so that it does "Smalltalk recreateSpecialObjectsArray." after installing FFI. What do you think?

July 6, 2009