July 2013 - Pharo-users - lists.pharo.org

Packages ... group view example

by Geert Claes

I know I have seen it somewhere but I can't seem to find it. Can someone point me to an example where the packages are parsed by the "-"? e.g. Dsplayed as: v AST v Core > Matching > Nodes > Parser > Pattern > Tokens > Visitors > Interpreter > Tests Instead of: AST-Core AST-Core-Matching AST-Core-Nodes AST-Core-Parser AST-Core-Pattern AST-Core-Tokens AST-Core-Visitors AST-Interpreter-Core AST-Interpreter-Extension AST-Interpreter-Test AST-Tests-Core Thanks! -- View this message in context: http://forum.world.st/Packages-group-view-example-tp4701657.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 31, 2013

Re: [Pharo-users] Git filetree workflow

by Goubier Thierry

Le 31/07/2013 11:52, joerick a Ã©crit : > I'm getting a DNU for UnixFileDirectory on #pathString. Yes. I made a try yesterday and it failed on FileDirectory instead of FileReference (pathString is one of the FileReference method) and also on a Date readFrom: bug. From that, it seems feasible to do a one off (take a recent gitfiletree version and make a mcz adapted by force to Pharo1.4) but harder to reintegrate those adaptations in a proper way inside the filetree distribution. > Additionally, I tried the Gofer #push command with the basic filetree:// > with multiple packages but it failed to save a few and didn't raise an > error. A bit unsettling... filetree is supposed to be 1.4 compatible, yes? Yes, I believe it is 1.4 compatible. Filetree is tested in integration against Pharo1.4. I don't know what the error is then. Can you try with multiple target repositories in Filetree (subdirectories inside your git directory?)? Thierry -- 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

July 31, 2013

Re: [Pharo-users] Git filetree workflow

by joerick

I'm getting a DNU for UnixFileDirectory on #pathString. Additionally, I tried the Gofer #push command with the basic filetree:// with multiple packages but it failed to save a few and didn't raise an error. A bit unsettling... filetree is supposed to be 1.4 compatible, yes? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701651.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 31, 2013

Re: [Pharo-users] Garbage collector & Memory Profiling

by Henrik Johansen

On Jul 31, 2013, at 3:23 , Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > As far as I know, that's not possible in Pharo unless you explicitly register the desired objects in "WeakRegistry default" or similar (and implement #finalize). > I think is the closest you have. > > Cheers, A few clarifications: - You can use a non-default WeakRegistry (usually one specific to your domain, to avoid cluttering of the default one) - You can specify a custom executor (any object which implements #finalize), rather than implement #finalize on objects you're interested in. obj := Object new. executor := ObjectFinalizer receiver: Transcript selector: #show: argument: 'Object GC''d!'. myReg := WeakRegistry new. myReg add: obj executor: executor. obj := nil. Smalltalk garbageCollect. Cheers, Henry

July 31, 2013

Re: [Pharo-users] Garbage collector & Memory Profiling

by Mariano Martinez Peck

As far as I know, that's not possible in Pharo unless you explicitly register the desired objects in "WeakRegistry default" or similar (and implement #finalize). I think is the closest you have. Cheers, On Tue, Jul 30, 2013 at 5:00 PM, Alejandro Infante < alejandroinfante91(a)gmail.com> wrote: > Hello, > We are currently working on memory profiling and we are having troubles to > detect when an object is garbage collected. > > Any ideas? > > Thanks for the help, > Alejandro Infante > -- Mariano http://marianopeck.wordpress.com

July 31, 2013

Re: [Pharo-users] Pharo performance

by phil＠highoctane.be

Yes, as discussed, I am pushing Pharo and discussing business in the open just doesn't work for me.

July 30, 2013

Re: [Pharo-users] Pharo performance

by StÃ©phane Ducasse

yes normally there is one :) Now I will check who is in. What we should pay attention is that we are not really in favor of private discussions (even if I understand it fr business it is important). If you think that this would be good we can create a private business list. Stef > BTW, is there any special consortium list where we can discuss business out of the public eye? > > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Featured on the Software Process and Measurement Cast > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > > > > On Tue, Jul 30, 2013 at 11:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > > > > You could try: > > > > | floats | > > floats := (1 to: 200000) collect: #asFloat. > > [ FloatPrintPolicy > > value: InexactFloatPrintPolicy new > > during: [ > > String new: 1500000 streamContents: [ :stream | > > floats do: [ :each | each printOn: stream ] ] ] ] timeToRun > > > > => 796 ms > > > > I haven't looked at the Postgresql driver in detail, but I would guess that PostgresV2 reads from a String somewhere, which is slow unless care is taken, while psycopg probably does a binary read. That last thing can be done in Pharo as well, but not if the driver is text based somehow. > > > > You are right: Pharo should definitively be in the same range as other dynamically typed languages. But dynamic languages are dangerous: user become lazy / ignorant about performance. > > > > Thanks for pushing this. > > +1 > we need more people to profile and look at these aspects. > I can tell you that we are all working like crazy to improve the system and I hope that one of these days we will have > real regression tests. But well you know it takes a lot of time. > > Stef > >

July 30, 2013

Re: [Pharo-users] Pharo performance

by phil＠highoctane.be

BTW, is there any special consortium list where we can discuss business out of the public eye? --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Jul 30, 2013 at 11:02 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > >> > > > > You could try: > > > > | floats | > > floats := (1 to: 200000) collect: #asFloat. > > [ FloatPrintPolicy > > value: InexactFloatPrintPolicy new > > during: [ > > String new: 1500000 streamContents: [ :stream | > > floats do: [ :each | each printOn: stream ] ] ] ] timeToRun > > > > => 796 ms > > > > I haven't looked at the Postgresql driver in detail, but I would guess > that PostgresV2 reads from a String somewhere, which is slow unless care is > taken, while psycopg probably does a binary read. That last thing can be > done in Pharo as well, but not if the driver is text based somehow. > > > > You are right: Pharo should definitively be in the same range as other > dynamically typed languages. But dynamic languages are dangerous: user > become lazy / ignorant about performance. > > > > Thanks for pushing this. > > +1 > we need more people to profile and look at these aspects. > I can tell you that we are all working like crazy to improve the system > and I hope that one of these days we will have > real regression tests. But well you know it takes a lot of time. > > Stef > >

July 30, 2013

Re: [Pharo-users] [Moose-dev] [ann] a snappier snapshotcello

by StÃ©phane Ducasse

sweet! I should find some time to use it on some projects I have. Stef On Jul 30, 2013, at 11:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > A new version of Snapshotcello is now reachable from your Pharo 2.0 image. Besides snapshotting the current version, you now get the possibility of: > - marking the new version as stable, > - committing the configuration package, and > - pushing the package to the official Pharo repository. > > Here is an example: > Snapshotcello new > configurationClass: ConfigurationOfSnapshotcello; > sourceVersion: #development; > targetVersion: '1.4-snapshot'; > snapshot; > makeStableFor: #'pharo2.x'; > commit; > pushToPharo20Repository > > A more detailed description can be found here: > http://www.tudorgirba.com/blog/snappier-snapshotcello > > We can certainly improve this, and it would be great to have a similar mechanism integrated into Metacello. But, in the meantime, I find myself for the first time literally one do-it away from distributing projects that are developed without much constraints. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

July 30, 2013

Re: [Pharo-users] Pharo performance

by StÃ©phane Ducasse

>> > > You could try: > > | floats | > floats := (1 to: 200000) collect: #asFloat. > [ FloatPrintPolicy > value: InexactFloatPrintPolicy new > during: [ > String new: 1500000 streamContents: [ :stream | > floats do: [ :each | each printOn: stream ] ] ] ] timeToRun > > => 796 ms > > I haven't looked at the Postgresql driver in detail, but I would guess that PostgresV2 reads from a String somewhere, which is slow unless care is taken, while psycopg probably does a binary read. That last thing can be done in Pharo as well, but not if the driver is text based somehow. > > You are right: Pharo should definitively be in the same range as other dynamically typed languages. But dynamic languages are dangerous: user become lazy / ignorant about performance. > > Thanks for pushing this. +1 we need more people to profile and look at these aspects. I can tell you that we are all working like crazy to improve the system and I hope that one of these days we will have real regression tests. But well you know it takes a lot of time. Stef

July 30, 2013