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

Re: [Pharo-project] FFI problem

by StÃ©phane Ducasse

Ok we will check the loadFFI in scriptLoader. Stef > Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908 > > What do you think? > > Thanks! > > Mariano > > On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > > wrote: > I crated the issue so that no to forget about it: > > http://code.google.com/p/pharo/issues/detail?id=908

July 6, 2009

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

by David RÃ¶thlisberger

Hi Reinout > What is the status of the dev-image? As delivered the tools are broken > (because context menus on the source pane raise an UHE that is induced > by OB-Enhancements, issue 904), is it actively used by the main > committers or is the core image the place to be? > Even more confusingly the above issue has been marked as fixed this > night but if I do a World->System->Software Update the bug persists in > my image. You can get the fix by executing 'ScriptLoader loadOBAlpha' in a workspace. See Stephane's answer why this fix is not provided by 'software update'. David

July 6, 2009

Re: [Pharo-project] Tests

by Damien Cassou

On Sun, Jul 5, 2009 at 12:36 PM, Adrian Lienhard<adi(a)netstyle.ch> 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? More tests, less problems, why do you care? :-) -- 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

Re: [Pharo-project] Why does Pharo have both a System Browser and a Class Browser?

by Damien Cassou

On Tue, Jun 30, 2009 at 6:54 PM, Oscar Nierstrasz<oscar(a)iam.unibe.ch> wrote: > In the Tools ... menu there are entries for both a System Browser and > a Class Browser. Â Both give you an OmniBrowser Package Browser. > > Is there a reason for this? Fixed -- 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

Re: [Pharo-project] Tests

by Cyrille Delaunay

It's probably that.I just try to run the tests from FloatArray ( that was not tested at all before), it represent 251 tests. With all collections tested it seems possible that there is like 2000 new tests. 2009/7/6 Marcus Denker <denker(a)acm.org> > > On 05.07.2009, at 12:36, 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? > > > I think this is because of the Traits-based test for Collections > (written > by Cyrille). > > Marcus > > > > > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > 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 Gary Chambers

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

July 6, 2009

Re: [Pharo-project] Tests

by Marcus Denker

On 05.07.2009, at 12:36, 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? > I think this is because of the Traits-based test for Collections (written by Cyrille). Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 6, 2009

[Pharo-project] Squeak Forks Popularity & Trends Estimate

by Nevin Pratt

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

July 6, 2009

Re: [Pharo-project] Fwd: Issue 513 in pharo: UTF8 and file names

by John M McIntosh

I've updated http://code.google.com/p/pharo/issues/detail?id=513 I think you can close it as fixed. There is however still a problem with the clipboard logic, but that is issue http://code.google.com/p/pharo/issues/detail?id=823 ? On 4-Jul-09, at 4:01 AM, StÃ©phane Ducasse wrote: > John or mike can you tell us your point of view on this issue? > > Stef > > Begin forwarded message: > >> From: codesite-noreply(a)google.com >> Date: July 4, 2009 12:22:14 PM CEDT >> To: stephane.ducasse(a)gmail.com >> Subject: Issue 513 in pharo: UTF8 and file names >> >> >> Comment #13 on issue 513 by damien.pollet: UTF8 and file names >> http://code.google.com/p/pharo/issues/detail?id=513 >> >> more info : >> http://developer.apple.com/qa/qa2001/qa1235.html >> http://developer.apple.com/qa/qa2001/qa1173.html >> >> (ps in my tests, sometimes I'd see blank characters at the end of >> the name, sometimes in the middle after an >> accented char, etc) >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 5, 2009

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

by Reinout Heeck

Hi Stef! Thanks for the in-depth answers, some remarks/further questions: > 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... 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. 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 ;-) >> Pharo wants to be agile and be free to change at will (IMO a good >> decision) but if it is to be viable at my job there need to be >> versions that receive long-term support (the 'professional' aspect of >> Pharo). > > 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. 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. [...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. 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. Cheers! Reinout -------

July 5, 2009