- Pharo-dev - lists.pharo.org

[Pharo-project] A bit of publicity :)

by GermÃ¡n Arduino

I asked to add Pharo, Seaside and Pier on http://www.findbestopensource.com/ Seems that are added!

Sept. 2, 2010

Re: [Pharo-project] Problems in loading GLORP

by Alberto Bacchelli

> BTW, last week I wrote a metacello configuration group to load GlorpDBX with the native postgres driver. You can evaluate first: > > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfGlorpDBX'; > load. > > and then > > (ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native > Hi, I followed your instructions and I've been able to load GLORP on a Moose Nightly Built image [1]. I run the 844 tests. 839 of them passed (wow), 4 failed and 1 generated an error. These are the problematic ones: GlorpManyToManyDBTest>>#testReadNodeAndDeleteChildWithSaveAndContinue GlorpRowMapForMementosCollectionTest>>#testRBSmallDictionary GlorpDateTest>>#testDate GlorpObjectMappedToImaginaryTableTest>>#testReadBackEntireExample GlorpUnitOfWorkTest>>#testRollbackOneToManyAfterAdd Are these tests failing also on other Pharo images (i.e., they are known "problems")? Do you know the impact of these failures? will GLORP be reliable without them? Moose developers, would you include GLORP in the images built by hudson? I think 839 passing tests are good enough for the development image. Ciao, Alberto [1] http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/

Sept. 2, 2010

Re: [Pharo-project] Metacello for pharo 1.2

by Cyrille Delaunay

Yes it seems to work, thanks :) 2010/9/1 Dale Henrichs <dhenrich(a)vmware.com> > Mariano Martinez Peck wrote: > >> Try (ConfigurationOfMetacello project version: '1.0-beta.27-baseline' ) >> load >> >> 2010/9/1 Cyrille Delaunay <cy.delaunay(a)gmail.com <mailto: >> cy.delaunay(a)gmail.com>> >> >> >> When I try to load moose in a pharo 1.2 image, Metacello is loading >> (via ConfigurationOfMetacello) an ancient version of OB which is no >> longer compatible with pharo 1.2 (at least for the use of >> 'Preferences'). Does anyone know if there is a version of metacello >> working for 1.2? >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > ...Except that when you do that, you may get Metacello work in progress. I > am working on 1.0-beta.27.4 right now and you could end up with code that I > am attempting to debug which could lead to unexpected results for you:) > > If you load in a version of OmniBrowser that is compatible with 1.2, > before loading the Metacello UI that should work ... A safer course of > action would be to do this...load the latest packages from OmniBrowser and > then the latest _released_ version of Metacello: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOmniBrowser'; > package: 'ConfigurationOfMetacello'; > load. > then: > > (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. > (ConfigurationOfMetacello project latestVersion) load: 'UI'. > > You'll get an OmniBrowser that runs in 1.2 and the OB-Metacello tools. I've > tried this and it appears to work fine... > > Dale > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 2, 2010

Re: [Pharo-project] programmatically update a Pharo image

by Cyrille Delaunay

Both, updater and solution of yanni are doing what I was expecting. Thanks :) 2010/9/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi cyrille > > I published a read to be tested version of UpdateStreamer. > Please have a look this is in PharoTaskForces/Updater > > I'm a little class inspired heavily from Utilities that download > update.list and launch update. > > you can tell me to update throw a given number of update or to be verbose. > > > UpdateStreamer new > beVerbose; > updateFromServer > > This will update all the updates available and show up dialogs > > > UpdateStreamer new > beSilent; > upToNumber: 13000; > updateFromServer > > let me know if this is working. I tested it and it seems so. > Once we are a bit more confident :), we can use it in pharo and nuke (yeah) > Utilities. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 2, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by StÃ©phane Ducasse

What we started to do and got stalled (for RPackage) is to implement SystemAnnouncement a hierarchy that wrap event and should be ready to replace SystemChangeNotifier. Alain told me that he wants to help for RPackage so we should get some speed on that. Alain if you load ConfigurationOfRPackage in PharoTaskForces you will see what I mean. Stef On Sep 1, 2010, at 10:48 PM, Henrik Sperre Johansen wrote: > Just remember to add corresponding deregistration in shutdown if SystemChangeNotifier is reimplemented using Announcements :) > > (hint: Announcers do not care if objects register multiple times to the same Announcement) > > Cheers, > Henry > > On 01.09.2010 22:41, StÃ©phane Ducasse wrote: >> muchas gratias. >> >> >> Stef >> >> On Sep 1, 2010, at 9:08 PM, Adrian Lienhard wrote: >> >>> I created a changeset and attached it to the appropriate ticket: http://code.google.com/p/pharo/issues/detail?id=2896 >>> >>> Adrian >>> >>> On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: >>> >>>> seems like we should do something :) >>>> >>>> Begin forwarded message: >>>> >>>>> From: John M McIntosh<johnmci(a)smalltalkconsulting.com> >>>>> Date: September 1, 2010 1:12:28 AM GMT+02:00 >>>>> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>>> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >>>>> Reply-To: johnmci(a)smalltalkconsulting.com >>>>> >>>>> In case this gets overlooked being hidden in a update for The Trunk: System-eem. >>>>> >>>>> The EndianCache does need to be cleared at shutdown versus in startup. >>>>> I can't speak for the SystemChangeNotifier since I'm not sure what the bug is.. >>>>> >>>>> Of course I'm not quite sure if anyone in the Pharo group looks and the trunk updates and moves things across? >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: commits(a)source.squeak.org >>>>>> Date: August 31, 2010 5:47:35 PM PDT >>>>>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>>>>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>>>>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>>>>> >>>>>> Eliot Miranda uploaded a new version of System to project The Trunk: >>>>>> http://source.squeak.org/trunk/System-eem.366.mcz >>>>>> >>>>>> ==================== Summary ==================== >>>>>> >>>>>> Name: System-eem.366 >>>>>> Author: eem >>>>>> Time: 31 August 2010, 10:47:17.97 am >>>>>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>>>>> Ancestors: System-nice.365 >>>>>> >>>>>> Make sure system notifications for Smalltalk are up-to-date >>>>>> on start-up. >>>>>> Fix voiding of Smalltalk's endian cache which needs to be done >>>>>> in a timely manner. >>>>>> >>>>>> =============== Diff against System-nice.365 =============== >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- >>>>>> startUp >>>>>> + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! >>>>>> - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." >>>>>> - EndianCache := nil. >>>>>> - ! >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- >>>>>> processShutDownList: quitting >>>>>> + "Send #shutDown to each class that needs to wrap up before a snapshot. >>>>>> + Also void the endianness chace; this can't safely be done on start-up because >>>>>> + Smalltalk is too late in the start-up sequence." >>>>>> - "Send #shutDown to each class that needs to wrap up before a snapshot." >>>>>> >>>>>> + EndianCache := nil. >>>>>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! >>>>>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. >>>>>> - ! >>>>>> >>>>>> >>>>> -- >>>>> =========================================================================== >>>>> John M. McIntosh<johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>> =========================================================================== >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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

Sept. 2, 2010

Re: [Pharo-project] Smalltalk Image writer?

by StÃ©phane Ducasse

stupid me I forgot. Stef On Sep 2, 2010, at 4:05 AM, John M McIntosh wrote: > You should look at the > > http://www.squeaksource.com/SystemTracing > SystemTracer64 writeImage: 'squeak64.image'. > > That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... > > > On 2010-09-01, at 6:26 PM, James Ladd wrote: > >> >> >>we are interested in a Smalltalk based image writer too :) >> >> While I work through reading and writing the Smalltalk image myself (in Java) I'll be writing down what I find. >> >> I'd be happy to try and write a Smalltalk based image writer. Please tell me your requirements and I'll try and include them. >> >> Rgs, James. >> >> >> _______________________________________________ >> 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 > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 2, 2010

Re: [Pharo-project] MethodName

by StÃ©phane Ducasse

yes and like that we know if something is really public once it will be published in the different MetaRepoForPharoXX Stef On Sep 1, 2010, at 11:18 PM, Alexandre Bergel wrote: >>> Is there a configuration I can use instead of the gofer invocation? >> >> Why? Does it depend on strange things? > > Using configurations allow me to scripts loading. For example: > > -=-=-=-=-=-=-=-=-= > #('NewInspector' 'Shout' 'OCompletion' 'O2' 'Moose' 'CAnalyzer' 'Spy' 'Adore' 'DependencyView') > do: [:t | > | name | > name := 'ConfigurationOf', t. > Gofer new > squeaksource: 'MetacelloRepository'; > package: name; > load. > ((Smalltalk at: name asSymbol) project perform: #lastVersion) load ]. > -=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

Sept. 2, 2010

[Pharo-project] Network tests coverage (Re: WebClient-Core port to Pharo 1.1 final)

by Andreas Raab

Hi Sven - Good question. It would definitely be good to cover those areas with tests but I fear that may require actual cooperation :-) If there is enough energy (which is hard to say) one might be able to start a "neutral" repository with tests but I'm not sure how well it would work in practice (it would mean the tests are fairly far away from the source it's covering which is generally not a good thing). If anyone has good ideas, please propose. Cheers, - Andreas On 9/1/2010 12:38 PM, Sven Van Caekenberghe wrote: > Andreas, > > Thanks a lot for taking the time to look into these problems and for the patches. > Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? > What would be the procedure to contribute to these tests ? > > Sven > > On 01 Sep 2010, at 06:16, Andreas Raab wrote: > >> Hi Sven - >> >> I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue. >> >> The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header. >> >> Fixes attached. These are of course also broken in Pharo 1.0 and 1.1. >> >> Cheers, >> - Andreas >>

Sept. 2, 2010

Re: [Pharo-project] Smalltalk Image writer?

by James Ladd

Thank John, great suggestion. > Message: 4 > Date: Wed, 1 Sep 2010 19:05:43 -0700 > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: [Pharo-project] Smalltalk Image writer? > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: > <CCE85492-BBB6-4F08-BCC5-84F08A00FA5A(a)smalltalkconsulting.com> > Content-Type: text/plain; charset="us-ascii" > > You should look at the > > http://www.squeaksource.com/SystemTracing > SystemTracer64 writeImage: 'squeak64.image'. > > That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... > >

Sept. 2, 2010

Re: [Pharo-project] Smalltalk Image writer?

by John M McIntosh

You should look at the http://www.squeaksource.com/SystemTracing SystemTracer64 writeImage: 'squeak64.image'. That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... On 2010-09-01, at 6:26 PM, James Ladd wrote: > > >>we are interested in a Smalltalk based image writer too :) > > While I work through reading and writing the Smalltalk image myself (in Java) I'll be writing down what I find. > > I'd be happy to try and write a Smalltalk based image writer. Please tell me your requirements and I'll try and include them. > > Rgs, James. > > > _______________________________________________ > 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 ===========================================================================

Sept. 2, 2010