- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-project] A solution to manage units like inches and centimeters in Pharo?

by StÃ©phane Ducasse

Excellent! Stef > Its not just you, I don't used to write to the lists. > > Phil, thanks for the repo location. > Stef, Aconcagua and Chalten are now on the 2.0 metaRepo. > > > 2013/7/30 Igor Stasenko <siguctua(a)gmail.com> > On 31 July 2013 00:00, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > Hi Igor, > > > > Something about me. > > Well, I'm from Buenos Aires, Argentina. I'm fan of the greatest football > > team in the world: Boca Juniors. And I'm a smalltalker since early of the > > 2000. > > > So, you been around for quite a while? :) > Or it is just me, who never seen your name in list? > > Anyways, nice to see people doing useful stuff. > > > I'd been working with Hernan (WiIkinson) when we develop the ancestors of > > Aconcagua and Chalten for one of the financial applications of the company > > for wich we work. > > Then, when I starts my thesis work, I migrate these two frameworks from > > VisualAge to other Smalltalk flavors (VisualWorks, Squeak/Pharo). When we > > publish both frameworks, we named as Aconcagua to the measure model and > > Chalten to the gregorian dates model. > > Then, specificly for my thesis, I extended this initial version of Chalten > > with more abstractions, calendars, behavior and other stuff. > > > > Now, a couple of months ago, I upload both models to SmalltalkHub with some > > packages renamed and with the implementation of ConfigurationOfAconcagua and > > ConfigurationOfChalten for loading it in a easy way. > > > > Thanks for giving us some info :) > > > Regards. > > Maxi. > > > > > > 2013/7/30 Igor Stasenko <siguctua(a)gmail.com> > >> > >> On 30 July 2013 16:23, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > >> > Hi Stef, people. > >> > > >> > Maybe is a little late to answer to this, but I already migrate > >> > Aconcagua, > >> > and Chalten too, to SmalltalkHub. > >> > Here: > >> > http://smalltalkhub.com/#!/~maxi/Aconcagua > >> > http://smalltalkhub.com/#!/~maxi/Chalten > >> > > >> .. and lurkers do all the hard work :) > >> > >> Hi, mr. Lurker. Please can you tell us about yourself , so we can > >> welcome you properly? > >> > >> :) > >> > >> > >> > Regards. > >> > Maxi > >> > > >> > > >> > 2013/2/24 stephane ducasse <stephane.ducasse(a)free.fr> > >> >> > >> >> Yes I would like to migrate Aconcagua to SmalltalkHub :) > >> >> > >> >> On Feb 23, 2013, at 3:47 PM, Mariano Martinez Peck > >> >> <marianopeck(a)gmail.com> > >> >> wrote: > >> >> > >> >> Yes, I was going to suggest that. > >> >> Maybe Hernan can say more. > >> >> > >> >> > >> >> On Fri, Feb 22, 2013 at 11:04 PM, Ben Coman <btc(a)openinworld.com> > >> >> wrote: > >> >>> > >> >>> Frank Shearar wrote: > >> >>>> > >> >>>> On 22 February 2013 15:45, Guillaume Larcheveque > >> >>>> <guillaume.larcheveque(a)gmail.com> wrote: > >> >>>> > >> >>>>> > >> >>>>> Does something exists because I looked and don't find anything. > >> >>>>> > >> >>>> > >> >>>> > >> >>>> Something like these? > >> >>>> * http://map.squeak.org/package/b546b6af-984e-4e89-a7a5-875ce0435710 > >> >>>> * http://map.squeak.org/package/8664cb28-916b-4e8a-8cd6-b6db73f5024c > >> >>>> > >> >>>> frank > >> >>>> > >> >>>> > >> >>>> > >> >>> > >> >>> I had Aconcagua running on Pharo a year ago before I got sidetracked. > >> >>> Can't remember if or what I needed to tweak, but I found a mcz with my > >> >>> name > >> >>> on it. > >> >>> > >> >>> cheers -ben > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Mariano > >> >> http://marianopeck.wordpress.com > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Guillermo Polito

Ok, we are looking at that with marcus. So, one thing that may be causing problems is that there are some usages of #onAnnouncement: anAnnouncement do: aBlock. And since we don't have ephermerons, the usage of blocks in announcements is leaking references. Also, looking at the usages of onAnnouncement:do:, we found NECController>>setEditor:, which is called for every keystroke in when using autocompletion :D. Maybe the cause is around here? On Thu, Aug 1, 2013 at 1:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Yes, I think the announcers of morph might be the cause of the problem... > > > On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> I did a little run on those MorphExtensions and got the output file in >> annex. >> >> Cursor wait showWhile: [ >> (FileSystem disk workingDirectory / 'MorphExtensions.txt') >> asFileReference writeStreamDo: [ :s | >> MorphExtension allInstancesDo: [ :each | >> each printOn: s. >> s lf >> ] >> ] >> ]. >> >> Looks like there are a lot of Announcers. >> >> Phil >> >> >> On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: >>> >>> Doing the flushCaches... >>> >>> Image size before cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 >>> Image size after cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 >>> Image size before cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 >>> Image size after cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 >>> Image size before cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 >>> Image size after cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 >>> Image size before cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300 >>> Image size after cleaning a MCSmalltalkhubRepository( >>> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868 >>> >>> Definitely not going down... >>> >>> >>> No, we already saw that in your case the reason are many,many instances >>> of MorphExtension without the Morphs hanging around. >>> (which should not happen as MorphExtensions are only referenced by the >>> Morph they extend). >>> >>> Your case is not a case of caches, there is a real problem somewhere. >>> >>> Marcus >>> >>> >> > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Aug. 1, 2013

Re: [Pharo-dev] New PharoVM built

by Max Leske

I'm using the US international layout. Not working: - delete button - diaeresis (for umlauts); option + u (+ any character that accepts diaeresis) - probably more (didn't go through more) On 01.08.2013, at 11:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 August 2013 10:27, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> Keyboard: Belgian french >> >> Key combination that doesn't work: hit the caret key... hit fn-Backspace... >> both things pretty standard. >> > ah, i think its same as for me, when i found my Delete key stop working. > >> Phil >> On Thu, Aug 1, 2013 at 9:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> still works for me... looks like a keyboard distribution problem, we'll >>> check (bah, Guille will do it :) soon :) >>> >>> can you send which keyboard layour do you use? >>> >>> and exactly which key combinations are you trying? >>> >>> thanks, >>> Esteban >>> >>> On Aug 1, 2013, at 12:01 AM, phil(a)highoctane.be wrote: >>> >>> Same for me with the backspace. >>> >>> Caret impossible to type ( ^ ... needless to say, bad...) >>> >>> Umlauts and ~ not working either. >>> >>> Smalltalk vm version 'NBCoInterpreter >>> NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >>> acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 >>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >>> acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 >>> git://gitorious.org/cogvm/blessed.git Commit: >>> 746b609f0323a8db5de2f1aa36f3eed07e312dfe Date: 2013-07-19 13:54:47 +0200 By: >>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14619 >>> ' >>> >>> >>> erfeklfefeefeâ¦â¦â¦â¦â¦â¦ferf e >>> >>> The things with xes is what I get from copy/pasting the string. >>> >>> 'azeâ¦â¦â¦uiop' asByteArray #[0 0 0 97 0 0 0 122 0 0 0 101 0 0 35 38 0 0 35 >>> 38 0 0 35 38 0 0 0 117 0 0 0 105 0 0 0 111 0 0 0 112] >>> >>> >>> >>> Phil >>> >>> >>> >>> On Wed, Jul 31, 2013 at 10:49 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> I'm seeing the same with latest 3.0. The problem starts occuring as of >>>> build 165. 164 is still ok. >>>> >>>> >>>> On 31.07.2013, at 18:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> On 31 July 2013 17:55, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> >>>>>> On 31.07.2013, at 17:44, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> works for me. In which platform are you testing? >>>>>> >>>>>> OS X 10.8.4, 64 bit, Pharo 1.3 >>>>> >>>>> can you try it in 3.0 image? >>>>> >>>>>> >>>>>>> >>>>>>> On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>> >>>>>>>> There seems to be an issue relating to the keyboard. I can't type >>>>>>>> any umlauts (option + u) and the delete button produces a question mark. >>>>>>>> >>>>>>>> Max >>>>>>>> >>>>>>>> On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Will do. Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I builded new versions of the vm, integrating latest changes from >>>>>>>>>> Eliot. >>>>>>>>>> This integration should fix some issues, between them the annoying >>>>>>>>>> "SmallInteger" problem. >>>>>>>>>> >>>>>>>>>> You can find it here: >>>>>>>>>> >>>>>>>>>> wget -O- get.pharo.org/20+vmLatest >>>>>>>>>> >>>>>>>>>> or directly here: >>>>>>>>>> >>>>>>>>>> http://files.pharo.org/vm/pharo/ >>>>>>>>>> >>>>>>>>>> (choose the one that fits the best for you, always the "latest") >>>>>>>>>> >>>>>>>>>> can you download and check? >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Marcus Denker

Yes, I think the announcers of morph might be the cause of the problem... On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I did a little run on those MorphExtensions and got the output file in > annex. > > Cursor wait showWhile: [ > (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference > writeStreamDo: [ :s | > MorphExtension allInstancesDo: [ :each | > each printOn: s. > s lf > ] > ] > ]. > > Looks like there are a lot of Announcers. > > Phil > > > On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: >> >> Doing the flushCaches... >> >> Image size before cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 >> Image size after cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 >> Image size before cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 >> Image size after cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 >> Image size before cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 >> Image size after cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 >> Image size before cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300 >> Image size after cleaning a MCSmalltalkhubRepository( >> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868 >> >> Definitely not going down... >> >> >> No, we already saw that in your case the reason are many,many instances >> of MorphExtension without the Morphs hanging around. >> (which should not happen as MorphExtensions are only referenced by the >> Morph they extend). >> >> Your case is not a case of caches, there is a real problem somewhere. >> >> Marcus >> >> > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Goubier Thierry

Interestingly, in a base 2.0 image, there isn't any user of caseOf: and very few users of caseOf:otherwise: A sample: ^ places caseOf: {[0]->[1] . [1]->[0.1] . [2]->[0.01] . [3]->[0.001] . [4]->[0.0001] . [5]->[0.00001] . [6]->[0.000001] . [7]->[0.0000001] . [8]->[0.00000001] . [9]->[0.000000001]} otherwise: [(10.0 raisedTo: places negated) asFloat] It looks like your average Pharo programmer is good at avoiding the use of caseOf: :) Thierry Le 01/08/2013 13:15, Frank Shearar a Ã©crit : > On 1 August 2013 12:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> we should not use caseOf: in the image. >>> So I will start removing them. >> >> Other than switching on _type_, what is the problem? >> >> foo caseOf: { >> [1] -> ['one']. >> [2] -> ['two']. >> } otherwise: ['three'] >> >> What's wrong with this? > > I can see a reason for removing #caseOf:, precisely because it doesn't > force you to consider a failed match. (#caseOf:otherwise: is always > exhaustive, in other words.) > > frank > >>> Stef >>> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 12:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> we should not use caseOf: in the image. >> So I will start removing them. > > Other than switching on _type_, what is the problem? > > foo caseOf: { > [1] -> ['one']. > [2] -> ['two']. > } otherwise: ['three'] > > What's wrong with this? I can see a reason for removing #caseOf:, precisely because it doesn't force you to consider a failed match. (#caseOf:otherwise: is always exhaustive, in other words.) frank >> Stef >>

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > we should not use caseOf: in the image. > So I will start removing them. Other than switching on _type_, what is the problem? foo caseOf: { [1] -> ['one']. [2] -> ['two']. } otherwise: ['three'] What's wrong with this? frank > Stef >

Aug. 1, 2013

killing all uses of caseOf: and caseOf:otherwise from the image

by StÃ©phane Ducasse

Hi guys we should not use caseOf: in the image. So I will start removing them. Stef

Aug. 1, 2013

Windows problem with FilePlugin ?

by Benjamin

On my image, when opened in Windows, opening the File Browser leads to a red square of death :s And using the UIManager to popup the file picker leads to an infinite loop of halt :s Do you experienced that too ? Can people using windows try the following line: (FileSystem disk root) directories This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ It seems to come from DiskStore>>#basicEntry:path:nodesDo: [â¦] [ entry isNil ] whileFalse: [ entry at: 1 put: (Primitives decode: entry first). aBlock value: entry. index := index + 1. entry := Primitives lookupEntryIn: encodedPathString index: index ]. So I would say it comes from the primitives. Ben

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

I did a little run on those MorphExtensions and got the output file in annex. Cursor wait showWhile: [ (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference writeStreamDo: [ :s | MorphExtension allInstancesDo: [ :each | each printOn: s. s lf ] ] ]. Looks like there are a lot of Announcers. Phil On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: > > Doing the flushCaches... > > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868 > > Definitely not going down... > > > No, we already saw that in your case the reason are many,many instances of > MorphExtension without the Morphs hanging around. > (which should not happen as MorphExtensions are only referenced by the > Morph they extend). > > Your case is not a case of caches, there is a real problem somewhere. > > Marcus > >

Aug. 1, 2013