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

Re: [Pharo-project] Issue 3254 in pharo: [Repackage] "Regular expressions" should be well structured

by pharo＠googlecode.com

Comment #1 on issue 3254 by Torsten....(a)astares.de: [Repackage] "Regular expressions" should be well structured http://code.google.com/p/pharo/issues/detail?id=3254 Slice is in SLICE-Issue-3254-RepackageRegexpressions-TorstenBergmann.1

Nov. 12, 2010

[Pharo-project] Issue 3254 in pharo: [Repackage] "Regular expressions" should be well structured

by pharo＠googlecode.com

Status: Fixed Owner: Torsten....(a)astares.de CC: stephane.ducasse Labels: Milestone-1.2 New issue 3254 by Torsten....(a)astares.de: [Repackage] "Regular expressions" should be well structured http://code.google.com/p/pharo/issues/detail?id=3254 Pharo 1.2a 12235: I now reorganized the regular expression package: - tests are now in 'Regex-Tests-Core' (closer to the code than in the general Test package) - categories now start with 'Regex-...' instead of 'VB-Regex-...' (so nobody should think its a port from VisualBasic ;) - there was an RxParser "Documentation" method category => this has been converted to a help book - missing class comments were added and the note regarding the specific Documentation method category was removed Install the two changesets. After that you should have: - a new "Regex-Core" package - a changed package "Tests" since tests are now repackaged close to the code - a new "Regex-Help" package => this has to be SAVED - a "Regex-Tests-Help" package => this has to be SAVED - the package "VB-Regex" is obsolete then Attachments: 01 Reorg Regex.1.cs 9.6 KB 02 Enhance Regex.1.cs 44.1 KB

Nov. 12, 2010

Re: [Pharo-project] Issue 3252 in pharo: [Repackage] "Announcements" should be well structured

by pharo＠googlecode.com

Comment #1 on issue 3252 by Torsten....(a)astares.de: [Repackage] "Announcements" should be well structured http://code.google.com/p/pharo/issues/detail?id=3252 The slice is ready for integration: SLICE-Issue-3252-RepackageAnnouncements-TorstenBergmann.1.mcz

Nov. 12, 2010

Re: [Pharo-project] Howto measure memory footprints of functions/objects/libraries in Pharo?

by Max Leske

Hi Alexandre The weird behaviour seems to be related to inline compilation in workspaces. I moved the execution into a method, now everything's back to normal. In the meantime I verified the previously described scenarios with a fresh one-click image (Pharo 1.1). One really dramatic example is this: repo := FSGitRepository on: FSDiskFilesystem current working / 'foo'. MessageTally spyOn: [ repo tagNames ] ---> 3ms for a huge repository with 10 tags. MemoryProfiler viewProfiling: [ repo tagNames ] ---> low space warning (same repository etc.) I hope you might have an idea what's going wrong. Cheers, Max Hi again. Please ignore the last e-mail for the moment. There's something weird going on in my image. I'll run some tests on a fresh official image first and then post back. Max --------------------------------- Thanks Alexandre. Now I tried out your example and they worked perfectly. I have run into two problem though which I don't know how to deal with: 1. When I run anything else than what you suggested, I do get the window for the profiling view but it is empty. E.g when I run this: MemoryProfiler viewProfiling: [ 1 to: 100000 do: [ :i | (FSMemoryFilesystem new root / ('foo', i asString)) writeStreamDo: [ :stream | stream nextPutAll: 'foo' ] ] ] 2. When I run the code I am actually interested I get a low space warning. Example: repo := FSGitRepository on: FSMemoryFilesystem new root / 'foo' MemoryProfiler viewProfiling: [ repo head ] I'll be happy to run any tests you suggest. If you'd like to run the code yourself, get the packages from Gofer: Gofer new squeaksource: 'GitFS'; package: 'FS-Git'; package: 'Filesystem'; load. Cheers, Max On 09.11.2010, at 22:42, Alexandre Bergel wrote: > Hi Max, > >> Um... I should be able to get a visualisation by running somthing like this right (I only installed it, didn't subclass anything)? >> >> MemoryProfiler >> > viewProfiling: [ FSDiskFilesystem current working / foo ]. >> >> I get a window but there's nothing in it... > > The piece of code you want to profile needs is executed twice, and it needs "to be time consuming" (~ 1 second). > For example, try: > > MemoryProfiler > viewProfiling: [ > | view | > > view := MOViewRenderer new. > view nodes: (1 to: 5000). > view root applyLayout ] > > or > > MemoryProfiler > viewProfiling: [ (1 to: 2) collect: [ :i | ConfigurationOfMetacello project currentVersion ] ] > > to get a nice picture > >> Also, is selecting the expression in the block above, right clicking and selecting "memory profile it" equivalent to sending #viewProfiling: ? > > yes > >> Reading your paper I get the idea that this should work, when looking at the instructions on the moose site it rather seems that I need to subclass MemoryProfiler to actually profile anything. > > No need to subclass. > > Cheers, > Alexandre > >> >> >> >> On 09.11.2010, at 15:02, Alexandre Bergel wrote: >> >>> Ok, but please, provide feedback. >>> >>> Alexandre >>> >>> >>> On 9 Nov 2010, at 10:40, Max Leske wrote: >>> >>>> Sounds like what I just needed! I'll try it out. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> On 09.11.2010, at 12:42, Alexandre Bergel wrote: >>>> >>>>> Hi Guido, >>>>> >>>>> We wrote a profiler to keep track of memory consumption. >>>>> >>>>> http://bergel.eu/download/papers/Berg10g-MemoryProfiling.pdf >>>>> >>>>> It will be presented at Smalltalks next week. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> On 8 Nov 2010, at 23:47, Guido Stepken wrote: >>>>> >>>>>> E.g.: Three different solutions for a Euler problem: >>>>>> >>>>>> (1 to: 999) inject: 0 into: [:sum :i | (i \\ 3 = 0) | (i \\ 5 = 0) >>>>>> > ifTrue: [sum + i] >>>>>> > ifFalse: [sum]] >>>>>> >>>>>> >>>>>> (1 to: 999) detectSum: [:i | (i \\ 3 = 0) | (i \\ 5 = 0) ifTrue: [i] ifFalse: [0]] >>>>>> >>>>>> (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)] >>>>>> >>>>>> How do i measure the exact memory footprint of each solution? >>>>>> >>>>>> Pharo claims having reduced memory footprint at many places. Can that be proofed, e.g. with one comparable demo app, once run in old squeak, once in Pharo 1.1/1.2? >>>>>> >>>>>> And no, MessageTally spyOn: does not do right! >>>>>> >>>>>> Tnx in advance, Guido Stepken >>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Nov. 12, 2010

[Pharo-project] Issue 3253 in pharo: Announcer. Extraction ActionSequence creation in subscription logic

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3253 by Dionisiygod: Announcer. Extraction ActionSequence creation in subscription logic http://code.google.com/p/pharo/issues/detail?id=3253 ActionSequence creation in subscribtion logic of announcer should be extracted. With this little change different kind of announcing logic could be simple implemented (for example, asynchronous announcer with its own actionSequence implementation) Announcer>>subscribe: anAnnouncementClass do: aValuable | actions | subscriptions ifNil: [ subscriptions := IdentityDictionary new ]. actions := subscriptions at: anAnnouncementClass ifAbsent: [ self createActionSequence ]. subscriptions at: anAnnouncementClass put: (actions copyWith: aValuable). ^ aValuable Attachments: Announcer-subscribedo.st 479 bytes Announcer-createActionSequence.st 218 bytes

Nov. 12, 2010

Re: [Pharo-project] Howto measure memory footprints of functions/objects/libraries in Pharo?

by Max Leske

Hi again. Please ignore the last e-mail for the moment. There's something weird going on in my image. I'll run some tests on a fresh official image first and then post back. Max --------------------------------- Thanks Alexandre. Now I tried out your example and they worked perfectly. I have run into two problem though which I don't know how to deal with: 1. When I run anything else than what you suggested, I do get the window for the profiling view but it is empty. E.g when I run this: MemoryProfiler viewProfiling: [ 1 to: 100000 do: [ :i | (FSMemoryFilesystem new root / ('foo', i asString)) writeStreamDo: [ :stream | stream nextPutAll: 'foo' ] ] ] 2. When I run the code I am actually interested I get a low space warning. Example: repo := FSGitRepository on: FSMemoryFilesystem new root / 'foo' MemoryProfiler viewProfiling: [ repo head ] I'll be happy to run any tests you suggest. If you'd like to run the code yourself, get the packages from Gofer: Gofer new squeaksource: 'GitFS'; package: 'FS-Git'; package: 'Filesystem'; load. Cheers, Max On 09.11.2010, at 22:42, Alexandre Bergel wrote: > Hi Max, > >> Um... I should be able to get a visualisation by running somthing like this right (I only installed it, didn't subclass anything)? >> >> MemoryProfiler >> viewProfiling: [ FSDiskFilesystem current working / foo ]. >> >> I get a window but there's nothing in it... > > The piece of code you want to profile needs is executed twice, and it needs "to be time consuming" (~ 1 second). > For example, try: > > MemoryProfiler > viewProfiling: [ > | view | > > view := MOViewRenderer new. > view nodes: (1 to: 5000). > view root applyLayout ] > > or > > MemoryProfiler > viewProfiling: [ (1 to: 2) collect: [ :i | ConfigurationOfMetacello project currentVersion ] ] > > to get a nice picture > >> Also, is selecting the expression in the block above, right clicking and selecting "memory profile it" equivalent to sending #viewProfiling: ? > > yes > >> Reading your paper I get the idea that this should work, when looking at the instructions on the moose site it rather seems that I need to subclass MemoryProfiler to actually profile anything. > > No need to subclass. > > Cheers, > Alexandre > >> >> >> >> On 09.11.2010, at 15:02, Alexandre Bergel wrote: >> >>> Ok, but please, provide feedback. >>> >>> Alexandre >>> >>> >>> On 9 Nov 2010, at 10:40, Max Leske wrote: >>> >>>> Sounds like what I just needed! I'll try it out. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> On 09.11.2010, at 12:42, Alexandre Bergel wrote: >>>> >>>>> Hi Guido, >>>>> >>>>> We wrote a profiler to keep track of memory consumption. >>>>> >>>>> http://bergel.eu/download/papers/Berg10g-MemoryProfiling.pdf >>>>> >>>>> It will be presented at Smalltalks next week. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> On 8 Nov 2010, at 23:47, Guido Stepken wrote: >>>>> >>>>>> E.g.: Three different solutions for a Euler problem: >>>>>> >>>>>> (1 to: 999) inject: 0 into: [:sum :i | (i \\ 3 = 0) | (i \\ 5 = 0) >>>>>> ifTrue: [sum + i] >>>>>> ifFalse: [sum]] >>>>>> >>>>>> >>>>>> (1 to: 999) detectSum: [:i | (i \\ 3 = 0) | (i \\ 5 = 0) ifTrue: [i] ifFalse: [0]] >>>>>> >>>>>> (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)] >>>>>> >>>>>> How do i measure the exact memory footprint of each solution? >>>>>> >>>>>> Pharo claims having reduced memory footprint at many places. Can that be proofed, e.g. with one comparable demo app, once run in old squeak, once in Pharo 1.1/1.2? >>>>>> >>>>>> And no, MessageTally spyOn: does not do right! >>>>>> >>>>>> Tnx in advance, Guido Stepken >>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Nov. 12, 2010

Re: [Pharo-project] Howto measure memory footprints of functions/objects/libraries in Pharo?

by Max Leske

Thanks Alexandre. Now I tried out your example and they worked perfectly. I have run into two problem though which I don't know how to deal with: 1. When I run anything else than what you suggested, I do get the window for the profiling view but it is empty. E.g when I run this: MemoryProfiler viewProfiling: [ 1 to: 100000 do: [ :i | (FSMemoryFilesystem new root / ('foo', i asString)) writeStreamDo: [ :stream | stream nextPutAll: 'foo' ] ] ] 2. When I run the code I am actually interested I get a low space warning. Example: repo := FSGitRepository on: FSMemoryFilesystem new root / 'foo' MemoryProfiler viewProfiling: [ repo head ] I'll be happy to run any tests you suggest. If you'd like to run the code yourself, get the packages from Gofer: Gofer new squeaksource: 'GitFS'; package: 'FS-Git'; package: 'Filesystem'; load. Cheers, Max On 09.11.2010, at 22:42, Alexandre Bergel wrote: > Hi Max, > >> Um... I should be able to get a visualisation by running somthing like this right (I only installed it, didn't subclass anything)? >> >> MemoryProfiler >> viewProfiling: [ FSDiskFilesystem current working / foo ]. >> >> I get a window but there's nothing in it... > > The piece of code you want to profile needs is executed twice, and it needs "to be time consuming" (~ 1 second). > For example, try: > > MemoryProfiler > viewProfiling: [ > | view | > > view := MOViewRenderer new. > view nodes: (1 to: 5000). > view root applyLayout ] > > or > > MemoryProfiler > viewProfiling: [ (1 to: 2) collect: [ :i | ConfigurationOfMetacello project currentVersion ] ] > > to get a nice picture > >> Also, is selecting the expression in the block above, right clicking and selecting "memory profile it" equivalent to sending #viewProfiling: ? > > yes > >> Reading your paper I get the idea that this should work, when looking at the instructions on the moose site it rather seems that I need to subclass MemoryProfiler to actually profile anything. > > No need to subclass. > > Cheers, > Alexandre > >> >> >> >> On 09.11.2010, at 15:02, Alexandre Bergel wrote: >> >>> Ok, but please, provide feedback. >>> >>> Alexandre >>> >>> >>> On 9 Nov 2010, at 10:40, Max Leske wrote: >>> >>>> Sounds like what I just needed! I'll try it out. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> On 09.11.2010, at 12:42, Alexandre Bergel wrote: >>>> >>>>> Hi Guido, >>>>> >>>>> We wrote a profiler to keep track of memory consumption. >>>>> >>>>> http://bergel.eu/download/papers/Berg10g-MemoryProfiling.pdf >>>>> >>>>> It will be presented at Smalltalks next week. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> On 8 Nov 2010, at 23:47, Guido Stepken wrote: >>>>> >>>>>> E.g.: Three different solutions for a Euler problem: >>>>>> >>>>>> (1 to: 999) inject: 0 into: [:sum :i | (i \\ 3 = 0) | (i \\ 5 = 0) >>>>>> ifTrue: [sum + i] >>>>>> ifFalse: [sum]] >>>>>> >>>>>> >>>>>> (1 to: 999) detectSum: [:i | (i \\ 3 = 0) | (i \\ 5 = 0) ifTrue: [i] ifFalse: [0]] >>>>>> >>>>>> (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)] >>>>>> >>>>>> How do i measure the exact memory footprint of each solution? >>>>>> >>>>>> Pharo claims having reduced memory footprint at many places. Can that be proofed, e.g. with one comparable demo app, once run in old squeak, once in Pharo 1.1/1.2? >>>>>> >>>>>> And no, MessageTally spyOn: does not do right! >>>>>> >>>>>> Tnx in advance, Guido Stepken >>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Nov. 12, 2010

Re: [Pharo-project] Repackaging task force

by Miguel CobÃ¡

Great initiative! -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Nov. 12, 2010

Re: [Pharo-project] Issue 3247 in pharo: Remodel Text Constants

by pharo＠googlecode.com

Comment #2 on issue 3247 by Benjamin.VanRyseghem.Pharo: Remodel Text Constants http://code.google.com/p/pharo/issues/detail?id=3247 A new version is available, where I fix the bug about poolDictionaries and where I fix 3 classes. If someone want to play with it, enjoy ^^

Nov. 12, 2010

Re: [Pharo-project] ob in pharocore 1.2?

by Igor Stasenko

On 12 November 2010 17:02, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > Does anyone have any experience with loading OB in 1.2? > Yes, i were able to load it, and it works. Everything loads ok, except Shout. > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 12, 2010