June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about ~=

by Ben Coman

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by Ben Coman

GOUBIER Thierry wrote: > What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? > > I'd look into the package tree structure and updates. > > Thierry > In the past to investigate similar stuff I've used a bad hack like this... 1. In Workspace evaluate: Smalltalk at: #senders put: Bag new. 2. Define method... PackageTreePackageNodeModel class>>new | senderString | senderString := thisContext sender printString , '<--' , thisContext sender sender printString , '<--' , thisContext sender sender sender printString . "to whatever depth is useful" (Smalltalk at: #senders) add: senderString. ^ super new. I've also output the senderStrings to a log file and loaded into Excel to munge things for pattern matching. Very agricultural approach, but it turned up some results (though I can't remember what it was for.) However I've never actually plugged that sort of thing into #new, so YMMV. Also note that if you happen to step through the above code with the debugger, thisContext might not be set properly [1], although it works fine outside the debugger. [1] https://pharo.fogbugz.com/f/cases/12980/ cheers -ben > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de stepharo [stepharo(a)free.fr] > EnvoyÃ© : dimanche 29 juin 2014 10:38 > Ã : Pharo Development List > Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 > > I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances > size]' before starting a load and right after a load that just does not > crash the image. I noticed the following number of new instances that > were still being referenced (i.e. not garbage collected). > > The following lists the number of _added_ instances during the load with > the largest first. I include all of them but some are obviously more > indicative than others. > > Float->3580540 > Point->2149989 > Rectangle->818991 > Array->573089 > MorphExtension->309932 > TableLayoutProperties->204571 > ByteString->108891 > OrderedCollection->107527 > IdentityDictionary->103768 > ImageMorph->102338 > StringMorph->102318 > Morph->102313 > DependentsArray->102309 > TableLayout->102308 > RowLayout->102259 > MorphTreeNodeMorph->102252 > PackageTreePackageNodeModel->102250 > Association->26405 > Duration->14081 > CompiledMethod->11191 > MethodChangeRecord->11131 > IdentitySet->10843 > .... > > > >

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by GOUBIER Thierry

What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? I'd look into the package tree structure and updates. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de stepharo [stepharo(a)free.fr] EnvoyÃ© : dimanche 29 juin 2014 10:38 Ã : Pharo Development List Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected). The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others. Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....

June 29, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Sebastian Sastre

check this out: http://runtimejs.org sebastian o/ > On 26/06/2014, at 13:44, stepharo <stepharo(a)free.fr> wrote: > > Running Pharo on JS VM would be interesting too. > > Stef

June 29, 2014

Re: [Pharo-dev] New Cog VMs available

by stepharo

thanks eliot. Esteban is on his way back to France and we will sync with him probably tuesday. Stef On 29/6/14 06:02, Eliot Miranda wrote: > ...in http://www.mirandabanda.org/files/Cog/VM/VM.r3021/. > > In particular, these fix VM crashes when running the AllocationTest in > Spur. > > CogVM source as per VMMaker.oscog-eem.787/r3021 > > Fix mixup of old & young spaces in primitiveVMParameter, and > comment some new parameters. > > Fix return types for positive[64/32]BitValueOf:. > positive32BitValueOf: must answer a usqInt, > positive64BitValueOf: must answer a usqLong. > > Use positiveMachineIntegerValueOf: to decode arg in primitiveNewWithArg > and ensure positiveMachineIntegerValueOf: is inlined there-in. > > win32: > Set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header of the > Windows > executables to allow e.g. Spur to allocate more than 2Gb. > > Spur: > Fix sign and overflow issues in instantiating larger objects > and determining the size of large instances. > > Fix some freeChunk accesses that used fetchPointer:ofObject:. > > Cog ARM: > Fix prim return for compileInterpreterPrimitive: on RISCs. On return from > interpreter prim, ret pc is in instructionPointer and must return to > whence > it came, which is the stack on CISC and the LinkReg on RISC. Hence > restoring > the receiver reg requires different offsets in the two cases. > > Rework the rotatable quick constant logic a little and clean up users. > Fix concretizeMoveRXbrR to do byte not word loads. > Fix concretizeConditionalJumpLong: to actually be conditional. Oops. > > Correct mistaken callersaved reg stuff for ARM > Fix concretizedRetN to not over-bump the SP > > The method abort trampolines shouldn't pop anything, especially > now we have the pushLinkreg: arg to manage the LinkReg more easily. > > Slang: > Rip out the UseRightShiftForDivide optimization. It gets unsigned > division > wrong, and C compilers can and will optimize this correctly themselves. > > > -- > best, > Eliot

June 29, 2014

Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by Tudor Girba

Works for me. Doru On Sun, Jun 29, 2014 at 10:49 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Not downloading.... > > Annoying, I wanted to demo Pharo to someone from scratch :-( > > Phil > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014

Re: [Pharo-dev] TaskIT Revealed

by Tudor Girba

And the script:) Gofer new smalltalkhubUser: 'CAR' project: 'TaskIT'; configuration; load. (#ConfigurationOfTaskIT asClass project version: #stable) load: 'full' Cheers, Doru On Sun, Jun 29, 2014 at 11:09 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks! > > This works. > > For reference, here is the loading script: > > > Cheers, > Doru > > > > > On Sun, Jun 29, 2014 at 9:58 AM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Hi Doru! >> >> Download the stable version ConfigurationOfTaskIt stable. >> >> We are going through a refactor that adds new concepts, the last code is >> very unstable. We will try to make them transparent from the API point of >> view, but it will add new concepts in all the aspects. >> >> >> >> >> >> 2014-06-29 7:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >>> >>> This sounds very nice! >>> >>> I am trying to give it a shot, but I encounter a DNU for >>> BlockClosure>>asTask. I have loaded the latest code from all packages, but >>> this method is not defined. >>> >>> Cheers, >>> Doru >>> >>> >>> On Mon, Jun 23, 2014 at 7:32 AM, Santiago Bragagnolo < >>> santiagobragagnolo(a)gmail.com> wrote: >>> >>>> In general terms there are pharo processes. >>>> >>>> val := [2+2] shooitIt. >>>> >>>> val := [2+2] scheduleIt. >>>> >>>> val := [2+2] forkIt. >>>> >>>> >>>> >>>> All of this snippets will give you a future, all will be related with a >>>> pharo process, but each process has different meaning. the firstone is a >>>> common 2+2 block opened in a pharo process. the second one is a block >>>> assigned to one of the by-default two worker pharo processes from the >>>> thread pool. ( in this case the pharo processes do not run directly the >>>> task, but run a process that run tasks. Then, the first one is applied just >>>> there, the second one when is its turn. >>>> >>>> Finally the third one will use osprocess to open the same image (so, by >>>> now, this will work without anyproblem if you have saved the image just >>>> before, or if you didnt change any of the code to be executed) with the >>>> same vm and it will give the block to be executed. In our local image, >>>> there will be spawned a watch pharo process that will check if the third >>>> image has finished, and deploy the future for it. >>>> >>>> >>>> In the behind the scenes, each of this convenient methods is >>>> implemented with a different kind of runner and process reification. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-06-23 0:54 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>>> >>>> are those OS processes or Pharo processes ? >>>>> >>>>> >>>>> On Mon, Jun 23, 2014 at 1:39 AM, Santiago Bragagnolo < >>>>> santiagobragagnolo(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi all, im glad to announce TaskIT. You may already knew about, after >>>>>> all it's not confidential ;) and it has documentation on-going since some >>>>>> months ago. >>>>>> >>>>>> Task IT is package that provides a cool way to deal with processes. >>>>>> Even when this version is stable, it still in design and we want to make it >>>>>> consistent and powerfull. >>>>>> >>>>>> It counts with a chapter in pharo enterprise book and some cool >>>>>> tests. >>>>>> >>>>>> We have moved the main distribution repo to CAR >>>>>> >>>>>> http://smalltalkhub.com/#!/~CAR/TaskIT/ >>>>>> >>>>>> >>>>>> The main easy things to do with this revision are: >>>>>> >>>>>> " closures " >>>>>> val := [ 2+2 ] shootIt. >>>>>> val isKindOf: TKTFuture. >>>>>> val onSuccess: [: rslt | rslt == 4 ] "async" >>>>>> val value == 4. " sync " >>>>>> >>>>>> rslt := [ 2+2 ] shootIt asResult. >>>>>> rslt == 4 "sync on demand" >>>>>> >>>>>> " objects " >>>>>> >>>>>> val := 2 paralellize + 2. >>>>>> val == 4 "sync on demand" >>>>>> >>>>>> >>>>>> " staying in tune " >>>>>> >>>>>> val := [ "some task" ] shootIt asStickyReference. >>>>>> >>>>>> val := nil. >>>>>> " sticky means that if this future is taken by the GC, it will kill >>>>>> the process" >>>>>> >>>>>> >>>>>> >>>>>> " looping " >>>>>> >>>>>> >>>>>> val := server paralellize looping serveOnce: anyParameter >>>>>> asStickyReference. >>>>>> >>>>>> "this will execute in a new process, in a loop, server serveOnce: >>>>>> anyParameter." >>>>>> >>>>>> You can stop it by doing >>>>>> val:= nil. >>>>>> >>>>>> "or using a disgusting magic variable, for that check the samples :). >>>>>> But do not rely on that kind of things, because it will not be supported " >>>>>> >>>>>> >>>>>> >>>>>> For more advanced and cool usages, check the Doc. >>>>>> >>>>>> >>>>>> FAQ: >>>>>> >>>>>> 1- Yes, the "sync" on demand is implemented with a proxy and a >>>>>> become. >>>>>> 2- Yes, we are changing the API of the processes that persist in >>>>>> time. >>>>>> >>>>>> CREDITS >>>>>> All CAR team in general was great inspiration, particularly, Guille >>>>>> Polito full operational commiter and of course is always a good idea to >>>>>> discuss with him, Nick Papoylias, is also great to discuss with him. Luc, >>>>>> Noury, Jannik: several ideas are discussed with them as well, and they >>>>>> always gave me support. >>>>>> >>>>>> and from RMOD Esteban Lorenzano, also discussing and proposing. >>>>>> >>>>>> Thanks all :). >>>>>> >>>>>> >>>>>> OTHERS: >>>>>> If you want to go to the darkside (dark because is not documented >>>>>> yet, but in the case of PoolIT, that it has some doc ) you can also add to >>>>>> your combo: >>>>>> ActIT: a simple Actor extention for taskit. >>>>>> ForkIT: an extention that runs blocks in background image (it adds a >>>>>> nice button to the test runner, letting you run all your tests in a >>>>>> background image and installing the results after the execution) >>>>>> PoolIT: it adds a pool of workers, it consumes tasks and ensure you a >>>>>> limited amount of threads. >>>>>> PlanIT: a basic and not yet full developed algebra for composing >>>>>> processes. >>>>>> >>>>>> >>>>>> >>>>>> I encourage you to use it, it is being used in PhaROS since a lot of >>>>>> time. And please any bug and enhancements, you can contact us. Since we are >>>>>> working on the next version is a good time to define what features are >>>>>> really needed. >>>>>> >>>>>> >>>>>> Salut. >>>>>> >>>>>> >>>>>> Santiago. . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014

Re: [Pharo-dev] TaskIT Revealed

by Tudor Girba

Thanks! This works. For reference, here is the loading script: Cheers, Doru On Sun, Jun 29, 2014 at 9:58 AM, Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > Hi Doru! > > Download the stable version ConfigurationOfTaskIt stable. > > We are going through a refactor that adds new concepts, the last code is > very unstable. We will try to make them transparent from the API point of > view, but it will add new concepts in all the aspects. > > > > > > 2014-06-29 7:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, >> >> This sounds very nice! >> >> I am trying to give it a shot, but I encounter a DNU for >> BlockClosure>>asTask. I have loaded the latest code from all packages, but >> this method is not defined. >> >> Cheers, >> Doru >> >> >> On Mon, Jun 23, 2014 at 7:32 AM, Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> In general terms there are pharo processes. >>> >>> val := [2+2] shooitIt. >>> >>> val := [2+2] scheduleIt. >>> >>> val := [2+2] forkIt. >>> >>> >>> >>> All of this snippets will give you a future, all will be related with a >>> pharo process, but each process has different meaning. the firstone is a >>> common 2+2 block opened in a pharo process. the second one is a block >>> assigned to one of the by-default two worker pharo processes from the >>> thread pool. ( in this case the pharo processes do not run directly the >>> task, but run a process that run tasks. Then, the first one is applied just >>> there, the second one when is its turn. >>> >>> Finally the third one will use osprocess to open the same image (so, by >>> now, this will work without anyproblem if you have saved the image just >>> before, or if you didnt change any of the code to be executed) with the >>> same vm and it will give the block to be executed. In our local image, >>> there will be spawned a watch pharo process that will check if the third >>> image has finished, and deploy the future for it. >>> >>> >>> In the behind the scenes, each of this convenient methods is implemented >>> with a different kind of runner and process reification. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2014-06-23 0:54 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>> are those OS processes or Pharo processes ? >>>> >>>> >>>> On Mon, Jun 23, 2014 at 1:39 AM, Santiago Bragagnolo < >>>> santiagobragagnolo(a)gmail.com> wrote: >>>> >>>>> >>>>> Hi all, im glad to announce TaskIT. You may already knew about, after >>>>> all it's not confidential ;) and it has documentation on-going since some >>>>> months ago. >>>>> >>>>> Task IT is package that provides a cool way to deal with processes. >>>>> Even when this version is stable, it still in design and we want to make it >>>>> consistent and powerfull. >>>>> >>>>> It counts with a chapter in pharo enterprise book and some cool tests. >>>>> >>>>> We have moved the main distribution repo to CAR >>>>> >>>>> http://smalltalkhub.com/#!/~CAR/TaskIT/ >>>>> >>>>> >>>>> The main easy things to do with this revision are: >>>>> >>>>> " closures " >>>>> val := [ 2+2 ] shootIt. >>>>> val isKindOf: TKTFuture. >>>>> val onSuccess: [: rslt | rslt == 4 ] "async" >>>>> val value == 4. " sync " >>>>> >>>>> rslt := [ 2+2 ] shootIt asResult. >>>>> rslt == 4 "sync on demand" >>>>> >>>>> " objects " >>>>> >>>>> val := 2 paralellize + 2. >>>>> val == 4 "sync on demand" >>>>> >>>>> >>>>> " staying in tune " >>>>> >>>>> val := [ "some task" ] shootIt asStickyReference. >>>>> >>>>> val := nil. >>>>> " sticky means that if this future is taken by the GC, it will kill >>>>> the process" >>>>> >>>>> >>>>> >>>>> " looping " >>>>> >>>>> >>>>> val := server paralellize looping serveOnce: anyParameter >>>>> asStickyReference. >>>>> >>>>> "this will execute in a new process, in a loop, server serveOnce: >>>>> anyParameter." >>>>> >>>>> You can stop it by doing >>>>> val:= nil. >>>>> >>>>> "or using a disgusting magic variable, for that check the samples :). >>>>> But do not rely on that kind of things, because it will not be supported " >>>>> >>>>> >>>>> >>>>> For more advanced and cool usages, check the Doc. >>>>> >>>>> >>>>> FAQ: >>>>> >>>>> 1- Yes, the "sync" on demand is implemented with a proxy and a become. >>>>> 2- Yes, we are changing the API of the processes that persist in time. >>>>> >>>>> CREDITS >>>>> All CAR team in general was great inspiration, particularly, Guille >>>>> Polito full operational commiter and of course is always a good idea to >>>>> discuss with him, Nick Papoylias, is also great to discuss with him. Luc, >>>>> Noury, Jannik: several ideas are discussed with them as well, and they >>>>> always gave me support. >>>>> >>>>> and from RMOD Esteban Lorenzano, also discussing and proposing. >>>>> >>>>> Thanks all :). >>>>> >>>>> >>>>> OTHERS: >>>>> If you want to go to the darkside (dark because is not documented yet, >>>>> but in the case of PoolIT, that it has some doc ) you can also add to your >>>>> combo: >>>>> ActIT: a simple Actor extention for taskit. >>>>> ForkIT: an extention that runs blocks in background image (it adds a >>>>> nice button to the test runner, letting you run all your tests in a >>>>> background image and installing the results after the execution) >>>>> PoolIT: it adds a pool of workers, it consumes tasks and ensure you a >>>>> limited amount of threads. >>>>> PlanIT: a basic and not yet full developed algebra for composing >>>>> processes. >>>>> >>>>> >>>>> >>>>> I encourage you to use it, it is being used in PhaROS since a lot of >>>>> time. And please any bug and enhancements, you can contact us. Since we are >>>>> working on the next version is a good time to define what features are >>>>> really needed. >>>>> >>>>> >>>>> Salut. >>>>> >>>>> >>>>> Santiago. . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014

http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by phil＠highoctane.be

Not downloading.... Annoying, I wanted to demo Pharo to someone from scratch :-( Phil

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by phil＠highoctane.be

Ah ah, the return of the MorphExtensions and Floats coming from god knows where... Hope you can find the reason why. Is this related to the fact that you did a load with Nautilus open or not? Could it somehow be related to the progress bars that we see at the top left when loading? It is hard to see where things are generated, even with pointer explorers... Maybe proxying these classes could show who creates such a quantity. How does one do that? I mean creating proxies? There was Ghost, which has no really much documentation as far as I can tell. Pointers? Phil On Sun, Jun 29, 2014 at 10:38 AM, stepharo <stepharo(a)free.fr> wrote: > I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' > before starting a load and right after a load that just does not crash the > image. I noticed the following number of new instances that were still > being referenced (i.e. not garbage collected). > > The following lists the number of _added_ instances during the load with > the largest first. I include all of them but some are obviously more > indicative than others. > > Float->3580540 > Point->2149989 > Rectangle->818991 > Array->573089 > MorphExtension->309932 > TableLayoutProperties->204571 > ByteString->108891 > OrderedCollection->107527 > IdentityDictionary->103768 > ImageMorph->102338 > StringMorph->102318 > Morph->102313 > DependentsArray->102309 > TableLayout->102308 > RowLayout->102259 > MorphTreeNodeMorph->102252 > PackageTreePackageNodeModel->102250 > Association->26405 > Duration->14081 > CompiledMethod->11191 > MethodChangeRecord->11131 > IdentitySet->10843 > .... > >

June 29, 2014