September 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] TextLint questions and feedback

by Mariano Martinez Peck

Hi. First, please let me know if this is the correct place to talk about TextLint. I've just used for one paper I am writing and I have some questions/feedback. I am using the one click image. 1) The "An Rule" could be a little more smart and detects commands. For example, in my latex I have " an \emph{inner object}" and that was detected by the rule, althought I shouldn't. So...detecting the slash and ignore what it surrounded by {} would be nice for this rule. 2) When I edit the code inside TextLint and I save it, two bad things happens: 2.a) I lost focus of the text, as it moves when it finishing saving. The line I edited goes to the end of the text area. It would be great if nothing moves nor to loose focus when saving. 2.b) sometimes (I cannot reproduce) the order of the rules changes...and this is not good because I was going in order, one by one, and suddenly they are re-ordered. Maybe you are using a Set for that? using a simple OrderedCollection could help. 3) If you edit the text (and it differs in the amount of characters), and DO NOT save it, the following color highlighting are moved. It seems you keep the position in the file, and until it is saved, rules results are pointing to "unupdated" file. Of course, when I save the file, they are correct. I guess this is from a performance point of view, but maybe you have a little hack to do and make it better. 4) The rule "no white space before punctuation mark" showed me things I didn't understand. For example, it says this line there is a "," (comma) : \item[ Shared object ] In the case of the \emph{shared objects}, it is almost the same as in the \emph{inner objects}. An ..... 5) Rules comments clearer. For example, when you say "Avoid using a lot, it weakens the sentence" It would be better to put "Avoid using "a lot", it weakens the sentence" or "Avoid using *a lot*, it weakens the sentence" or something to clearly mark the words not to use. Because sometimes the words are confused with the context. Or this one: "After an only words beginning with a vowel are allowed. " should be "After "an" only words beginning with a vowel are allowed." 6) For the rules of long sentences/paragraph it would be nice to ignore \fotenote{} 7) Maybe this link is of interest for you: http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words… Apart from all these things, the tool is very useful and I like it. thanks Mariano

Sept. 2, 2010

[Pharo-project] EntryFieldMorph enhancements

by Fernando olivero

SLICE-Issue-2903-EntryFieldHasErrorAndGrayedLabel-FernandoOlivero.1 The idea is to have specialized Editors that know the validity of the contents being edited. For example i'm working on a CompletionEditor, which knows if the contents are a valid class of the system. For now i've added the method Editor>>hasError ^ false. I will push the CompletionEditor, and the CompletionEntryFieldMorph in a new issue. I've also added the grayed out background label , setted by sending #initialContents. Fernando

Sept. 2, 2010

Re: [Pharo-project] [Moose-dev] Re: Problems in loading GLORP

by Mariano Martinez Peck

On Thu, Sep 2, 2010 at 1:23 PM, Alberto Bacchelli <alberto.bacchelli(a)usi.ch>wrote: > > 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")? > Yes. And I don't know how to fix them. If anyone can help, excellent. > Do you know the impact of these failures? > No > will GLORP be reliable without them? > > I really don't know, but I guess that yes. > > Moose developers, would you include > GLORP in the images built by hudson? > I don't think this is a good idea. I think Glorp has nothing to do with Moose on most cases. This is one of the reasons of having a conf, that with one line of code you can load it...So it is not so complicated if you need to do it manually on a normal Moose image. > I think 839 passing tests are good enough for > the development image. > > Ciao, > Alberto > > > [1] http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/ > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Sept. 2, 2010

[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