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

Re: [Pharo-project] Call for fixing the network problem

by Schwab,Wilhelm K

Do the comments in the tracker reflect "everything" that has been tried and not worked? That would seem to be an important list. I'll take a look at it later today. I saw mention that all is well in the core; is that true? When I last looked into this, there were still paths to ipv6 primitives not protected by a check on #useOldNetwork - given how the old network flag was set at the time, that was a sure sign of trouble. Gotta run. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, March 01, 2010 7:22 AM To: Pharo-project Development Subject: [Pharo-project] Call for fixing the network problem To release Pharo 1.0, we need to fix the network problem: http://code.google.com/p/pharo/issues/detail?id=1884 Anyone volunteers to help? I can allocate some time but would welcome if somebody would team up to get rid of this issue. Cheers, Adrian ___________________ 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

>> How does one use this formatter? > > aClass compile: (aClass parseTreeFor: aSelector) formattedCode OB-Refactory also provides a UI to format the whole system or individual classes or packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

> Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. It has dozens of settings that you can configure. It is already integrated with the settings framework in Pharo 1.1. > How does one use this formatter? aClass compile: (aClass parseTreeFor: aSelector) formattedCode > Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) You only need AST-Core. You can load it in one image, format the code, commit the changes and load the changes into a fresh Pharo image. Also you could unload AST-Core, it has no overrides. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2010

[Pharo-project] Call for fixing the network problem

by Adrian Lienhard

To release Pharo 1.0, we need to fix the network problem: http://code.google.com/p/pharo/issues/detail?id=1884 Anyone volunteers to help? I can allocate some time but would welcome if somebody would team up to get rid of this issue. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

March 1, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

First, I'm not using Squeak. Second, this is not the first time I've heard that xyz was going to wipe out Smalltalk's place in the world, and I doubt it will be the last. Bill -----Original Message----- From: Eagle Offshore [mailto:eagleoffshore@mac.com] Sent: Monday, March 01, 2010 12:09 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Scamper revival Then what are you doing with Squeak? :-) The browsers support offline development with local databases in HTML 5. This is here, now. They will replace squeak's mission in about another three years. Probably less. On Feb 28, 2010, at 12:04 PM, Schwab,Wilhelm K wrote: > There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Eagle Offshore > Sent: Sunday, February 28, 2010 2:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Scamper revival > > I wouldn't be so sure. > > http://html5demos.com/ > http://jqtouch.com/ > > On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > >> there is no way in hell that HTML+CSS+JavaScript is going to keep up > > > _______________________________________________ > 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

Adrian, Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy." Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, March 01, 2010 6:53 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) Adrian On Feb 28, 2010, at 22:31 , Lukas Renggli wrote: > The configurable formatter can be told from how many keyword messages > on it should put them on multiple lines. Also you can give exceptions > of messages that you always/never want to put on multiple lines. > > Lukas > > On 28 February 2010 22:29, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >> On Feb 28, 2010, at 22:12 , StÃ©phane Ducasse wrote: >>>> --------------- >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) ifTrue: [ >>>> self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) ] ]. >>>> --------------- >>>> >>>> Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. >>> >>> :) >>> >>> why not like that? >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) >>>> ifTrue: [ self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) ] ]. >> >> The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above). >> >> Also it makes formatting of conditionals consistent with the >> formatting of other messages, e.g., >> >> receiver foo: x >> >> instead of >> >> receiver >> foo: x >> >> >> The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines: >> >> receiver >> foo: x >> bar: y >> >> >> Adrian >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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

March 1, 2010

Re: [Pharo-project] about code formatting in pharo

by Adrian Lienhard

Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) Adrian On Feb 28, 2010, at 22:31 , Lukas Renggli wrote: > The configurable formatter can be told from how many keyword messages > on it should put them on multiple lines. Also you can give exceptions > of messages that you always/never want to put on multiple lines. > > Lukas > > On 28 February 2010 22:29, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >> On Feb 28, 2010, at 22:12 , StÃ©phane Ducasse wrote: >>>> --------------- >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) ifTrue: [ >>>> self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) ] ]. >>>> --------------- >>>> >>>> Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. >>> >>> :) >>> >>> why not like that? >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) >>>> ifTrue: [ self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) ] ]. >> >> The difference is not big, but I prefer the first version because you get one indentation less (and you don't break the rule that an indentation always has only one tab, which is not the case above). >> >> Also it makes formatting of conditionals consistent with the formatting of other messages, e.g., >> >> receiver foo: x >> >> instead of >> >> receiver >> foo: x >> >> >> The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword messages with more than one argument are put on separate lines: >> >> receiver >> foo: x >> bar: y >> >> >> Adrian >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by Mariano Martinez Peck

I saw the issue closed but the message compactAllInstances is not being sent in cleanUnForProduction or cleanUpForRelease. should it be ? On Sat, Feb 27, 2010 at 4:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I updated it > Thanks anyway because this is good to see people pushing some changes from > sqeuak to pharo. > I'm reimplementing my package class right now. > See you later :) > > Stef > > On Feb 27, 2010, at 3:17 PM, Miguel Enrique CobÃ¡ Martinez wrote: > > > El sÃ¡b, 27-02-2010 a las 09:44 +0100, StÃ©phane Ducasse escribiÃ³: > >> :) > >> > >> http://code.google.com/p/pharo/issues/detail?id=2087 > >> > >> :) > > > > :), yes, I was in a hurry and I didn't create a issue, thanks for > > creating it. > > > > Cheers > >> > >> On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > >> > >>> Maybe we can add this to the cleanUpForRelease script. > >>> > >>> Cheers > >>> -- > >>> Miguel CobÃ¡ > >>> http://miguel.leugim.com.mx > >>> > >>> From: commits(a)source.squeak.org > >>> Date: February 26, 2010 6:38:01 PM GMT+01:00 > >>> To: squeak-dev(a)lists.squeakfoundation.org, > packages(a)lists.squeakfoundation.org > >>> Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org > >>> > >>> > >>> Andreas Raab uploaded a new version of Kernel to project The Trunk: > >>> http://source.squeak.org/trunk/Kernel-ar.411.mcz > >>> > >>> ==================== Summary ==================== > >>> > >>> Name: Kernel-ar.411 > >>> Author: ar > >>> Time: 26 February 2010, 7:36:40.257 pm > >>> UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > >>> Ancestors: Kernel-ul.410 > >>> > >>> Add MethodDictionary class>>compactAllInstances to save space in > releases. Compacting all MDs in my images saves 600k in image size which > isn't bad at all. > >>> > >>> =============== Diff against Kernel-ul.410 =============== > >>> > >>> Item was added: > >>> + ----- Method: MethodDictionary class>>compactAllInstances (in > category 'initialization') ----- > >>> + compactAllInstances "MethodDictionary compactAllInstances" > >>> + "Compacts all MethodDictionaries to save space" > >>> + > >>> + | oldInstances newInstances | > >>> + oldInstances := self allInstances. > >>> + newInstances := oldInstances collect:[:md| > >>> + (self new: md size) > >>> + compactCopyFrom: md; > >>> + yourself]. > >>> + oldInstances elementsForwardIdentityTo: newInstances. > >>> + ! > >>> > >>> Item was added: > >>> + ----- Method: MethodDictionary>>compactCopyFrom: (in category > 'private') ----- > >>> + compactCopyFrom: sourceMD > >>> + "Copy the contents of source dictionary without growing" > >>> + > >>> + sourceMD keysAndValuesDo:[:key :value| | index | > >>> + index := self scanFor: key. > >>> + (self basicAt: index) ifNotNil:[self error: 'Something is > horribly broken']. > >>> + self basicAt: index put: key. > >>> + array at: index put: value. > >>> + tally := tally + 1. > >>> + ]. > >>> + self size = self capacity ifTrue:[self grow]. "grow only if we > reach capacity" > >>> + ! > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 >

March 1, 2010

Re: [Pharo-project] Delay startTimerInterruptWatcher in ScriptLoader >> cleanUpMethods -> DNU

by Mariano Martinez Peck

On Sun, Feb 28, 2010 at 1:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I would remove cleanUpMethods and move what is worth and working to > cleanUpForRelease. > > Ok...I've created the issue: http://code.google.com/p/pharo/issues/detail?id=2100 > Cheers, > Adrian > > On Feb 25, 2010, at 13:49 , Mariano Martinez Peck wrote: > > > Try to evaluate ScriptLoader new cleanUpMethods > > > > and you will see that in ScriptLoader >> cleanUpMethods > > > > you do: > > > > Delay startTimerInterruptWatcher. > > > > and there is the DNU as startTimerInterruptWatcher is never implemented. > > > > Solutions ? > > > > 1) Remove Delay startTimerInterruptWatcher. from cleanUpMethods > > > > 2) Maybe the message should be stopTimerEventLoop ?? I have no idea > > > > > > The only thing I found in the issues was this: > > > > http://code.google.com/p/pharo/issues/detail?id=1424 > > > > > > In squeak 3.9 the method is implemented, and like this: > > > > startTimerInterruptWatcher > > "Reset the class variables that keep track of active Delays and > re-start > > the timer interrupt watcher process. Any currently scheduled delays are > > forgotten." > > "Delay startTimerInterruptWatcher" > > > > | p | > > self primSignal: nil atMilliseconds: 0. > > TimingSemaphore == nil > > ifFalse: [TimingSemaphore terminateProcess]. > > TimingSemaphore _ Semaphore new. > > AccessProtect _ Semaphore forMutualExclusion. > > SuspendedDelays _ > > SortedCollection sortBlock: > > [:d1 :d2 | d1 resumptionTime <= d2 resumptionTime]. > > ActiveDelay _ nil. > > p _ [self timerInterruptWatcher] newProcess. > > p priority: Processor timingPriority. > > p resume. > > _______________________________________________ > > 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 >

March 1, 2010

Re: [Pharo-project] SqueakSave on Pharo

by Mariano Martinez Peck

On Sun, Feb 28, 2010 at 2:49 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > laurent laffont wrote: > > On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu > > > > > > Can you put it on squeaksource ? > > > > I'll clean up the package I have, and then ping the author for how > > contributions are to be handled (before forking it on squeaksource). > > BTW, the HPI repository is now back online. > > Okay, it's at: > > http://www.squeaksource.com/SqueakSave > > SqSave-tkow.127.mcz - This version was created from the HPI version by > unzip'ing the .mcz, fixing the issues that prevented it from loading > into Pharo, by editing the source.st file, then re-zip'ing into a .mcz > package. > > SqSave-YanniChiu.135.mcz - This version was developed for my needs at > the time, then clean up somewhat for public release. Using the native > postgres driver (and probably dbx one too), the following 3 tests are > the dbx will work with Blob ONLY in the latests commits...as I have been playing with that few weeks ago. > still failing: > > >>> SqsCTISearchQueryTest.testQueryBlob > >>> SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection > >>> SqsSTISearchQueryTest.testQueryBlob > > > Some class category names were changed, and some example code left out. > The original .127.mcz should be loadable, so you can see what was > changed. The repository is set for global read/write. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2010