April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SmalltalkHub going beta in a week

by Geert Claes

Randal L. Schwartz wrote: > > OK, so if this is a general replacement for Squeaksource, the "tagging" > issue comes up again. How do we identify which branch of Squeak a package > might be for? And can we maintain forks for those things that > require it? > That's where the ConfigurationOf...'s and Metacello come in to ensure dependencies, versions and Smalltalk implementations. -- View this message in context: http://forum.world.st/SmalltalkHub-going-beta-in-a-week-tp3430480p3432602.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 7, 2011

[Pharo-project] [ANN] Pharo Release 1.2.1

by Adrian Lienhard

The Pharo Project is proud to announce the release of Pharo 1.2.1, the third major release of this clean, innovative, open-source Smalltalk environment. Static URL for this ANN: http://www.pharo-project.org/pharo-download/release-1-2-1 French translation: http://code.google.com/p/pharo/wiki/Pharo12FrenchAnnouncement * Update #12345 On Tuesday, March 29th 2011, update #12345 was issued to Pharo's 1.2 development line, a line that started back in June 2010 and was frozen in January 2011. Next, Pharo's continuous integration machinery successfully started building various artifacts based on this 'Pharo Core 1.2', the most important one being 'Pharo 1.2' proper, the full featured development image. Pharo Core 1.2.1 passes 7.836 unit tests, Pharo 1.2.1 no less than 10.760. A large, international community of developers worked hard for several months to iron out all problems and to make Pharo compatible with various Smalltalk libraries and frameworks, among them Seaside 3.0.3 which passes its 1.599 tests. * Pharo Core Changes True to the Pharo philosophy, this release contains numerous small changes, refactorings, cleanups and bugfixes improving the overall quality. Important changes include: â Cleaned the Pluggable hierarchy â Added new undo framework â Cleaned Morph and PasteUpMorph â Added DummyUIManager, a UIManager for operating without a UI â Added NewTextMorph â Removed left overs from MVC: PopUpMenu, SelectionMenu and CustomMenu â Cleaned Utilities, Preferences and TheWorldMenu â Included SimpleMorphic preview â Removing empty classes â Added new TextEditor and SmalltalkEditor â Added new, clean and simple Glamorous, Glamorous Orange GUI Themes â Added new Pro GUI Theme â Added Cog compliant behavior â Added better blocks debugging â Better support for separating SmalltalkImage and SystemDictionary â Fixed package dependencies, providing a good platform for kernel images â Removed old JIT experiments â Migrated to MethodReferenceWithSource and friends â Added more pages under the Help system â Improved the number of commented classes â New Finder tool (replacing Messages Names and Method Finder) â New Recent Changes tool (replacing Recent Submissions) â Improved SpaceTally â Fixed pointer finders tools â Integrated SUnit 4 Started Continuous Integration: use Hudson/Jenkins to automatically build images, run tests, and compile VMs For the Core 1.2 Image development line, 693 issues were resolved. * Pharo Changes The full featured Pharo development image is built automatically by loading the Metacello configuration aptly called ConfigurationOfPharo. Important changes include: â Updated to latest Metacello and all configurations used to use symbolic versions â New tools: Metacello Configuration Browser, Memory Monitor, and Autotest â Updated versions of Shout, RoelTyper, OCompletion, OmniBrowser, AutomaticMethodCategorizer, RefactoringBrowsers, Nile, ProfStef â Added XML-Support, and more Help â Removed NewInspector For the Full Dev 1.2 Image development line, 57 issues were resolved. * Downloads: see http://www.pharo-project.org/pharo-download * Success Stories Pharo has a large user base spread all over the world. Hence there is a growing collection of success stories (www.pharo-project.org/about/success-stories) projects using Pharo that choose to go public with this. Recently, the following were added: DrGeo - an award winning interactive geometry application also used for teaching primary and secondary level students Issys Tracking - a workflow platform to support authorization procedures for the medical practice for a large social organization/health insurance in Argentina Inceptive's Custom ERP - an application for the event planning and resource management administration of a large cultural centre in Flanders __________________________ www.adrian-lienhard.ch twitter.com/adrianlienhard

April 7, 2011

Re: [Pharo-project] On fixed release planning [was: Actions done in 1.3]

by laurent laffont

On Wed, Apr 6, 2011 at 10:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont(a)gmail.com > > wrote: > >> >> On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> Planning is also important. >>> >>> Time is good, but another thing is i think we should think about, >>> what features we want to be in new release, and do not release until >>> they delivered. >>> >> >> I don't really like this. I prefer rhythm, agility. Timeboxing enables >> maximum value in each release. If a feature is really important, it will be >> on time. If not on time, it means it was no so important. >> > > I couldn't disagree more. Especially with VisualWorks time-boxing has > caused problems with quality and delivery of functionality. Fundamentally > there is no point putting out a release for the sake of it. A release is > about functionality, both new functionality and bug fixes. Without either > of these there is absolutely no point in releasing anything beyond > marketing. Yes, during a release one can make the call that because a > subset of the functionality will arrive much later than the rest of the > functionality it makes sense for that late functionality to slip the release > and arrive in a later one. But that doesn't imply putting out an > essentially empty release for the sake of promptness. > Let me talk about my experience. Quality may suffer with timeboxing without continuous integration and good test coverage. CI + tests enable timeboxing because I can maintain high quality level. And now we have CI it's wonderful. As a user, I like software developed with fixed iterations because I know exactly when it wil be released, plan upgrades and validations. I'm easily in sync. As a developer I like fixed iterations because 1/ We care more about quality. Cannot develop all this feature in the iteration ? do only a part and check that it works well - write missing tests. Not enough time left to integrate this feature ? Just work on the many details that we need to fix and integrate the new feature soon in next iteration. 2/ We maintain energy. No long waiting period of stuff xxxx to be done without realeasing. The more we wait, the less productive we are. 3/ I like to change the planning from "what features this version can't be released without ?" to "what can we develop in 1 / 3 / 6 months (with high quality) ?". 4/ ok I stop here. Even every day at work I'm timeboxing with 25mn iterations (Pomodoro technique) for several years - I cannot live without now. That makes me deliver a lot of energy. I've never seen empty release because of fixed iterations. And even if the release contains only fixed bugs, details adjustment and no new big feature it's great. Details matters a lot. In a former job my team was doing a new features iteration, then a "care about details iteration", then a new features iteration, and so on.... it was a lot of fun and worked. Indeed I would like try and see if it works with Pharo. I also would like Pharo to be a reference of modern agile development - that would be a step forward. Laurent. > > One thing I do approve of is maintennance releases, where some time after > an initial release one puts out a maintennance release that only contains > bug fixes and no new functionality and I think there are good arguments for > and positive experience with scheduling the maintennance release to arrive > at some fixed time after the first release, e.g. 4 to 6 months. But major > releases must IMO be driven by content. > > best > Eliot > > >> >> Always green test is a must-have. >> >> >> >>> Besides bug fixing and minor improvements, there should be some >>> functionality which we want to have in new release, >>> >> >> That should be a goal, but don't delay a release because the feature is >> not here. If releases are often ( for example every 3 months), shorter, it >> won't be a big problem to wait for the next one. >> >> I prefer to have a release *now* without my feature and wait 3 months for >> the next release than no release and waiting for 3 months more with less and >> less energy. >> >> >> Laurent. >> >> >>> so then you could say: 1.x is better than previous because of A,B,C, >>> but not because a,b,c ( capital letters is major stuff, while regular >>> ones is for minor stuff ) :) >>> >>> >>> On 6 April 2011 10:01, Serge Stinckwich <serge.stinckwich(a)gmail.com> >>> wrote: >>> > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont >>> > <laurent.laffont(a)gmail.com> wrote: >>> >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck >>> >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> Yes!!! totally agree. Now that we release 1.2, I would freeze and >>> release >>> >>> PharoCore 1.3 beta. Update the link to stable pharo to that, and >>> start >>> >>> trying to load the dev tools there. >>> >> >>> >> +10 >>> >> And propose a fixed date for release - no compromise, will be release >>> at >>> >> this date. >>> > >>> > +1 >>> > Timeboxing sounds great. >>> > Podomoro for software development ;-) >>> > >>> > Regards, >>> > -- >>> > Serge Stinckwich >>> > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> > Every DSL ends up being Smalltalk >>> > http://doesnotunderstand.org/ >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >

April 7, 2011

Re: [Pharo-project] Decode url form with Zinc-HTTP

by HernÃ¡n Morales Durand

Cool. Thanks Sven! 2011/4/7 Sven Van Caekenberghe <sven(a)beta9.be>: > HernÃ¡n, > > From the class comment of ZnUrl: > > [...] > > Â Â Â Â The methods in accessing protocols do not do any encoding, those in printing do. > > [...] > > Taking your example: > > Â (ZnUrl fromString: > 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') pathSegments > > Â Â Â Â an OrderedCollection('entrez' 'eutils' 'esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]') > > (ZnUrl fromString: > 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') path > > Â Â Â Â 'entrez/eutils/esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]' > > (ZnUrl fromString: > 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') printString > > Â Â Â Â 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' > > If you inspect a ZnUrl instance you will notice that the internal Smalltalk representation is unencoded. But its #printString and the argument to #fromString: are. You could programmatically build up a ZnUrl using accessors and supplying unencoded (path) elements. > > HTH, > > Sven > > On 06 Apr 2011, at 22:38, HernÃ¡n Morales Durand wrote: > >> Hi Sven, >> >> In WebUtils one can decode an URL this way >> >> ( WebUtils decodeUrlEncodedForm: >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >> ) keys anyOne >> >> resulting in >> >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' >> >> In Zinc-HTTP I didn't find a method for decoding an encoded HTTP address: >> >> ( ZnUrl fromString: >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >> ) .... ? >> >> but there is #unescapePercents in Network package (by the way if it's >> the opposite of #encodeForHTTP shouldn't be #decodeFromHTTP ?) >> >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >> unescapePercents >> >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' >> >> but I want to maximize package dependency and not system dependency. >> Is there a way to decode url's in Zinc-HTTP without use >> #unescapePercents ? >> >> Cheers, >> >> -- >> HernÃ¡n Morales >> Information Technology Manager, >> Institute of Veterinary Genetics. >> National Scientific and Technical Research Council (CONICET). >> La Plata (1900), Buenos Aires, Argentina. >> Telephone: +54 (0221) 421-1799. >> Internal: 422 >> Fax: 425-7980 or 421-1799. >

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Dale Henrichs

Randal, Managing packages on a per platform basis is one of the things that Metacello was designed to do ... Dale On Apr 6, 2011, at 7:48 PM, Randal L. Schwartz wrote: >>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> On Thu, Apr 7, 2011 at 9:38 AM, Randal L. Schwartz > Serge> <merlyn(a)stonehenge.com> wrote: >>>>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: >>> > Serge> Yes, but this SmalltalkHub not PharoHub ;-) >>> >>> Oh, did I miss the parallel announcement on squeak-dev? Sorry. > > Serge> There was no announcement on squeak-dev. > Serge> Nicolas forget about that i guess. > > OK, so if this is a general replacement for Squeaksource, the "tagging" > issue comes up again. How do we identify which branch of Squeak a > package might be for? And can we maintain forks for those things that > require it? > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion >

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Serge Stinckwich

On Thu, Apr 7, 2011 at 9:48 AM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> On Thu, Apr 7, 2011 at 9:38 AM, Randal L. Schwartz > Serge> <merlyn(a)stonehenge.com> wrote: >>>>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: >>> > Serge> Yes, but this SmalltalkHub not PharoHub ;-) >>> >>> Oh, did I miss the parallel announcement on squeak-dev? Â Sorry. > > Serge> There was no announcement on squeak-dev. > Serge> Nicolas forget about that i guess. > > OK, so if this is a general replacement for Squeaksource, the "tagging" > issue comes up again. Â How do we identify which branch of Squeak a > package might be for? Â And can we maintain forks for those things that > require it? At the code level, you can manage several Squeak/Pharo branchs with the help of Metacello. At the repository level, i dunno if this possible to use this kind of information for the web site. And i guess not every projects use (or want to use) Metacello, so suitable tags might be needed. There is no obligation for every communities or projects to be on SmalltalkHub, like every git repositories is not on github. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 7, 2011

[Pharo-project] Pharo 1.2.1 on Windows XP

by Benoit St-Jean

Hello everyone, Just to let you know that an "out-of-the-box" one-click Pharo 1.2.1 image on Windows XP fails one the following SUnit tests in TestRunner (see attached image). Most of the failing test are located in the ImageSegmentTestExport test suite. In every of those cases, the problem is located in #deleteFileNamed:ifAbsent: method. In the meantime, I might have a look at it tomorrow if I have time. Can anyone confirm that this is reproduceable on other Windows machines ? ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by merlyn＠stonehenge.com

>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: Serge> On Thu, Apr 7, 2011 at 9:38 AM, Randal L. Schwartz Serge> <merlyn(a)stonehenge.com> wrote: >>>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: >> Serge> Yes, but this SmalltalkHub not PharoHub ;-) >> >> Oh, did I miss the parallel announcement on squeak-dev? Â Sorry. Serge> There was no announcement on squeak-dev. Serge> Nicolas forget about that i guess. OK, so if this is a general replacement for Squeaksource, the "tagging" issue comes up again. How do we identify which branch of Squeak a package might be for? And can we maintain forks for those things that require it? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Serge Stinckwich

On Thu, Apr 7, 2011 at 9:38 AM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> Yes, but this SmalltalkHub not PharoHub ;-) > > Oh, did I miss the parallel announcement on squeak-dev? Â Sorry. There was no announcement on squeak-dev. Nicolas forget about that i guess. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by merlyn＠stonehenge.com

>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: Serge> Yes, but this SmalltalkHub not PharoHub ;-) Oh, did I miss the parallel announcement on squeak-dev? Sorry. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

April 7, 2011