- Pharo-users - lists.pharo.org

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Damien Cassou

On Thu, Oct 2, 2014 at 8:43 PM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > BTW: Is there any guide regarding the kind of language (e.g. tonality) of > the book. I'd change the it given the fact that the blog entry is pretty > informal which is IMHO not appropriate for a book ... no such guide exist. Do your best and we will do another pass on it afterwards. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 6, 2014

Android VM update

by Jean Baptiste Arnaud

Hi, I just comeback from holiday, and I realise that I do not have done a announcement yet. Now the prototype of the Pharo Android VM work. - Event is managed - Resolution up to 1080p is managed. - Most of the plugins seems worked. - File plugin allow you to browse the sd card. Next: - fix the generator then jenkins. Merge with Pharo/Cog main and Make it available for the public. - die under the mountain of bug entry open by the first public release. First release will be perfect and bugless. - allow easy personalisation of the packaging, allow you to rename and change icon easily (for your own application, Squeak/Pharo Android VM, Phratch, DR geo, etc.). - refined the jumpout logic for have a better graphical update and a better idle process (less consumption, faster reactive UI, UI updating during heavy computation, etc. ). - package the android feature in the android plugin, show/hide the keyboard via primitive, etc. etc. + init configuration. - a lot of cool idea but later Here is a youtube video to show the result: http://youtu.be/lB9UV9Z7Kss You can forward this to other mailing list, I do not have access to all of them. Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

Oct. 6, 2014

Re: [Pharo-users] Spur images

by Benjamin Pollack

On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Working with WideStrings is way slower than working with ByteStrings, > there is just no way around that. What is especially slow is the > automagic switch from ByteString to WideString, for example in a > String>>#streamContents: because a #becomeForward: is involved. If that > happens for every line or every token, that would be crazy. > > Apart from that, the tokenisation is not very efficient, #lines is a > copy of your whole contents, so is the #split: and #trimmed. The > algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye > for performance might yield better results. > > But I guess this is not really an exercise in optimisation. If it is, > you should give us the dataset and code (and maybe runnable python code > as reference), with some comments. Meh, optimizing the languages maybe, but not the code. The Python code I'm comparing against (and the "sane" C++ code I keep around, for that matter) makes these exact same decisions in the interest of readability. Indeed, the equivalent from my Python code for that line is with open(path) as f: lines = [[word.strip() for word in line.split(',')] for line in f] This does avoid loading the whole into RAM just to split it, but is otherwise identical (i.e., strip() allocates an extra string, split() allocates lots of extra strings, and the list comprehension is analogous to the #collect: call, etc.), so it seems a fair comparison to me. If you're curious, the maximum speed I've been able to get out of a carefully crafted, but not unreadable, C that simply passes around a bunch of (start, stop) tuples, rather than strings, comes down to about 40ms. I know I can get better than that, but I lost interest in rewriting all the string routines. I figure another 10ms-20ms could come off, at which point it'd finally be as much I/O bound as anything else. --Benjamin

Oct. 5, 2014

Re: [Pharo-users] Spur images

by Sven Van Caekenberghe

Hi Benjamin, On 05 Oct 2014, at 22:37, Benjamin Pollack <benjamin(a)bitquabit.com> wrote: > On Sun, 05 Oct 2014 10:36:31 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> How come you got WideStrings ? >> What does the input look like, can you give a partial example ? > > I'm guessing I got WideStrings because the file is indeed in UTF-8, with lots of characters outside the lower 128 code points. A sample couple of lines might look like > > åç°åº·å¸,The National,Sarah McLachlan,å¨æ°å«,Indochine,Rise Against,City and Colour,CÃ¦cilie Norby,El Cumbanchero,Death Letter > The Beatles,The Who,Barenaked Ladies,The Doors,Bob Dylan > > These are two play lists, one per line; each comma-delimited element is a band on that play list. > > The full line for reading and tokenization is just "pathToFile asFileReference contents lines collect: [ :line | (',' split: line) collect: [ :ea | ea trimmed ]]." Based on the profile indicating that a lot of time is lost on things like WideString>>copyFrom:to:, I wasn't optimistic about trying to stream the contents instead of just calling "contents lines", but I admit I didn't try. > > --Benjamin Working with WideStrings is way slower than working with ByteStrings, there is just no way around that. What is especially slow is the automagic switch from ByteString to WideString, for example in a String>>#streamContents: because a #becomeForward: is involved. If that happens for every line or every token, that would be crazy. Apart from that, the tokenisation is not very efficient, #lines is a copy of your whole contents, so is the #split: and #trimmed. The algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye for performance might yield better results. But I guess this is not really an exercise in optimisation. If it is, you should give us the dataset and code (and maybe runnable python code as reference), with some comments. Sven

Oct. 5, 2014

Re: [Pharo-users] Spur images

by Benjamin Pollack

On Sun, 05 Oct 2014 10:36:31 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > How come you got WideStrings ? > What does the input look like, can you give a partial example ? I'm guessing I got WideStrings because the file is indeed in UTF-8, with lots of characters outside the lower 128 code points. A sample couple of lines might look like åç°åº·å¸,The National,Sarah McLachlan,å¨æ°å«,Indochine,Rise Against,City and Colour,CÃ¦cilie Norby,El Cumbanchero,Death Letter The Beatles,The Who,Barenaked Ladies,The Doors,Bob Dylan These are two play lists, one per line; each comma-delimited element is a band on that play list. The full line for reading and tokenization is just "pathToFile asFileReference contents lines collect: [ :line | (',' split: line) collect: [ :ea | ea trimmed ]]." Based on the profile indicating that a lot of time is lost on things like WideString>>copyFrom:to:, I wasn't optimistic about trying to stream the contents instead of just calling "contents lines", but I admit I didn't try. --Benjamin

Oct. 5, 2014

Re: [Pharo-users] Spur images

by Sven Van Caekenberghe

How come you got WideStrings ? What does the input look like, can you give a partial example ? On 05 Oct 2014, at 16:03, Benjamin Pollack <benjamin(a)bitquabit.com> wrote: > On Fri, 03 Oct 2014 16:13:35 -0400, stepharo <stepharo(a)free.fr> wrote: >>> Looking at MessageTally, it seems at least half of that 278ms is spent >>> noodling around in WideStrings and other small things that the Spur >>> object format ought to help with, so it'd be interesting to see how much >>> of a speed boost that gives without any further work. >> tell us more about your algo because we want to know. > > It's not that exciting (it's a problem we give job applicants as a take-home coding test), but I'll describe it, since it highlights a common corner where Pharo does not perform terribly well. > > Basically, we give you a pile of play lists (a text file where each line is "Song1,Song2,Song3" and so on, representing a single play list), and then ask you to tell us which songs appear frequently together (where "frequently" is something we define--say, at least 100 times, for example). While there are interesting complex algorithms, a simple one that works well for small datasets is simply to walk all of play lists and build up a hashtable that maps pairs of bands to a count, then walk the hashtable and print out any keys whose counts are over the threshold. If this sounds like "dump all the permutations of each play list into a Bag and then walk Bag>>valuesAndCounts," you're right. As I said, it's not that complex. > > Python does very well on this because it hits on three things--hashtables, sets, and string processing--for which Python has obscenely good implementations in carefully optimized C. (In fact, the 80ms time I quoted you is surprisingly close to the maximum speed you can get with genuine C or C++ implementation on the sample dataset as well.) > > Pharo struggles to match Python for the same three reasons, but *especially* because its String functions are just much slower. In fact, if you implement the algorithm I described above naÃ¯vely in Pharo, the execution time is about 780ms--nearly ten times slower. After some reflection, I chopped the time to 270ms by converting all the band names to integers as the first step of the process (ArtistLister>>generateMap: in the profile trace below). Not only does this avoid WideString>>hash and friends; it also allows me to bring in IdentityDictionary and IdentitySet in most locations due to Pharo's object format. > > But there's a lot left. I'm attaching the profile output below. Notice that Pharo spends more time reading and processing the file (about 120ms) than the Python program spends executing total. > > --Benjamin > > > - 279 tallies, 279 msec. > > **Tree** > -------------------------------- > Process: (40s) Morphic UI Process: nil > -------------------------------- > 69.2% {193ms} ArtistLister>>groupsIn: > |18.6% {52ms} FileReference(AbstractFileReference)>>contents > | |17.6% {49ms} MultiByteFileStream(FileStream)>>contents > | | 17.6% {49ms} MultiByteFileStream>>next: > | | 5.0% {14ms} ByteString>>at:put: > | | |5.0% {14ms} WideString class>>from: > | | 5.0% {14ms} WideString>>at:put: > | | 5.0% {14ms} primitives > | | 1.4% {4ms} MultiByteFileStream>>next > | | 1.4% {4ms} UTF8TextConverter>>nextFromStream: > |14.7% {41ms} WideString(String)>>lines > | |14.7% {41ms} WideString(String)>>linesDo: > | | 10.0% {28ms} WideString>>copyFrom:to: > | | |5.4% {15ms} WideString(String)>>isOctetString > | | | |3.2% {9ms} WideString>>at: > | | | | |2.2% {6ms} Character class>>value: > | | | |2.2% {6ms} primitives > | | |4.7% {13ms} WideString(String)>>asOctetString > | | | 3.6% {10ms} primitives > | | 4.7% {13ms} WideString(String)>>lineIndicesDo: > | | 4.7% {13ms} WideString(String)>>indexOf:startingAt: > | | 4.7% {13ms} WideString class(String class)>>indexOfAscii:inString:startingAt: > |10.8% {30ms} ByteString(Object)>>split: > | |10.0% {28ms} ByteString(Object)>>split:do: > | | 5.7% {16ms} WideString>>copyFrom:to: > | | |3.2% {9ms} WideString(String)>>asOctetString > | | |2.5% {7ms} WideString(String)>>isOctetString > | | | 1.8% {5ms} primitives > | | 4.3% {12ms} ByteString(SequenceableCollection)>>split:indicesDo: > | | 2.9% {8ms} WideString(SequenceableCollection)>>indexOfSubCollection:startingAt: > | | |2.9% {8ms} WideString(String)>>indexOfSubCollection:startingAt:ifAbsent: > | | | 2.9% {8ms} WideString(String)>>findString:startingAt: > | | | 2.9% {8ms} WideString(String)>>findString:startingAt:caseSensitive: > | | | 2.9% {8ms} WideString(String)>>findSubstring:in:startingAt:matchTable: > | | 1.4% {4ms} primitives > |7.2% {20ms} Set(Collection)>>addAll: > | |5.0% {14ms} Set>>add: > | | |3.6% {10ms} Set>>scanFor: > | | | |3.6% {10ms} ByteString(String)>>= > | | |1.4% {4ms} Set(HashedCollection)>>atNewIndex:put: > | | | 1.4% {4ms} Set(HashedCollection)>>fullCheck > | | | 1.4% {4ms} Set>>grow > | |1.4% {4ms} OrderedCollection>>do: > |5.4% {15ms} ArtistLister>>generateMap: > | |5.4% {15ms} IdentityDictionary(Dictionary)>>at:put: > | | 3.9% {11ms} Dictionary(HashedCollection)>>atNewIndex:put: > | | |3.2% {9ms} Dictionary(HashedCollection)>>fullCheck > | | | 2.5% {7ms} Dictionary(HashedCollection)>>grow > | | | 1.4% {4ms} Dictionary>>noCheckAdd: > | | | 1.4% {4ms} Dictionary(HashedCollection)>>findElementOrNil: > | | 1.4% {4ms} IdentityDictionary(HashedCollection)>>findElementOrNil: > |4.3% {12ms} OrderedCollection>>collect: > | |4.3% {12ms} OrderedCollection>>addLast: > |4.3% {12ms} Dictionary>>at: > | |4.3% {12ms} Dictionary>>at:ifAbsent: > | | 2.2% {6ms} Dictionary(HashedCollection)>>findElementOrNil: > | | |2.2% {6ms} Dictionary>>scanFor: > | | | 1.4% {4ms} ByteString(String)>>= > | | 2.2% {6ms} primitives > |3.9% {11ms} ByteString(String)>>trimmed > | 3.9% {11ms} ByteString(String)>>trimBoth > | 3.2% {9ms} ByteString(String)>>trimBoth: > | 2.2% {6ms} primitives > 19.4% {54ms} ArtistLister>>popularPairsIn:onlyKeeping: > |15.8% {44ms} OrderedCollection(Collection)>>asBag > | |15.8% {44ms} Bag class(Collection class)>>withAll: > | | 15.8% {44ms} Bag(Collection)>>addAll: > | | 13.6% {38ms} Bag>>add: > | | |13.6% {38ms} Bag>>add:withOccurrences: > | | | 10.0% {28ms} Dictionary>>at:put: > | | | |8.6% {24ms} Dictionary(HashedCollection)>>findElementOrNil: > | | | | |7.9% {22ms} Dictionary>>scanFor: > | | | | | 4.7% {13ms} Array(SequenceableCollection)>>hash > | | | | | |3.2% {9ms} primitives > | | | | | 2.5% {7ms} Array(SequenceableCollection)>>= > | | | | | 2.5% {7ms} Array(SequenceableCollection)>>hasEqualElements: > | | | | | 1.4% {4ms} primitives > | | | |1.4% {4ms} Dictionary(HashedCollection)>>atNewIndex:put: > | | | 3.6% {10ms} Dictionary>>at:ifAbsent: > | | | 2.2% {6ms} Dictionary(HashedCollection)>>findElementOrNil: > | | | |2.2% {6ms} Dictionary>>scanFor: > | | | | 1.4% {4ms} Array(SequenceableCollection)>>= > | | | | 1.4% {4ms} Array(SequenceableCollection)>>hasEqualElements: > | | | 1.4% {4ms} primitives > | | 2.2% {6ms} OrderedCollection>>do: > |2.5% {7ms} ArtistLister>>uniquePairs:do: > 4.3% {12ms} ArtistLister>>bandsAboveThresholdIn: > |4.3% {12ms} Bag(Collection)>>addAll: > | 4.3% {12ms} Bag>>add: > | 4.3% {12ms} Bag>>add:withOccurrences: > | 2.5% {7ms} Dictionary>>at:put: > | 1.8% {5ms} Dictionary>>at:ifAbsent: > 3.2% {9ms} Set>>includes: > 2.5% {7ms} Set(HashedCollection)>>findElementOrNil: > 2.5% {7ms} Set>>scanFor: > > **Leaves** > 6.8% {19ms} WideString(String)>>asOctetString > 6.5% {18ms} ByteString(String)>>= > 5.4% {15ms} Dictionary>>at:ifAbsent: > 5.0% {14ms} WideString>>at:put: > 5.0% {14ms} WideString class>>from: > 5.0% {14ms} MultiByteFileStream>>next: > 5.0% {14ms} WideString(String)>>isOctetString > 4.7% {13ms} WideString class(String class)>>indexOfAscii:inString:startingAt: > 4.3% {12ms} OrderedCollection>>addLast: > 3.9% {11ms} WideString>>at: > 3.6% {10ms} Array(SequenceableCollection)>>do: > 3.6% {10ms} OrderedCollection>>do: > 3.2% {9ms} Set>>scanFor: > 3.2% {9ms} Dictionary(HashedCollection)>>atNewIndex:put: > 3.2% {9ms} Array(SequenceableCollection)>>hash > 2.5% {7ms} ArtistLister>>uniquePairs:do: > 2.2% {6ms} Dictionary>>scanFor: > 2.2% {6ms} Character class>>value: > 2.2% {6ms} ByteString(String)>>trimBoth: > 2.2% {6ms} Array(SequenceableCollection)>>hasEqualElements: > 1.8% {5ms} Array class(Behavior)>>inheritsFrom: > 1.4% {4ms} ByteString(SequenceableCollection)>>split:indicesDo: > 1.4% {4ms} SmallInteger>>hashMultiply > 1.4% {4ms} Dictionary(HashedCollection)>>findElementOrNil: > > **Memory** > old +5,124,784 bytes > young -340,984 bytes > used +4,783,800 bytes > free +295,464 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 22 totalling 22ms (8.0% uptime), avg 1.0ms > tenures 15 (avg 1 GCs/tenure) > root table 0 overflows >

Oct. 5, 2014

Re: [Pharo-users] Spur images

by Benjamin Pollack

On Fri, 03 Oct 2014 16:13:35 -0400, stepharo <stepharo(a)free.fr> wrote: >> Looking at MessageTally, it seems at least half of that 278ms is spent >> noodling around in WideStrings and other small things that the Spur >> object format ought to help with, so it'd be interesting to see how much >> of a speed boost that gives without any further work. > tell us more about your algo because we want to know. It's not that exciting (it's a problem we give job applicants as a take-home coding test), but I'll describe it, since it highlights a common corner where Pharo does not perform terribly well. Basically, we give you a pile of play lists (a text file where each line is "Song1,Song2,Song3" and so on, representing a single play list), and then ask you to tell us which songs appear frequently together (where "frequently" is something we define--say, at least 100 times, for example). While there are interesting complex algorithms, a simple one that works well for small datasets is simply to walk all of play lists and build up a hashtable that maps pairs of bands to a count, then walk the hashtable and print out any keys whose counts are over the threshold. If this sounds like "dump all the permutations of each play list into a Bag and then walk Bag>>valuesAndCounts," you're right. As I said, it's not that complex. Python does very well on this because it hits on three things--hashtables, sets, and string processing--for which Python has obscenely good implementations in carefully optimized C. (In fact, the 80ms time I quoted you is surprisingly close to the maximum speed you can get with genuine C or C++ implementation on the sample dataset as well.) Pharo struggles to match Python for the same three reasons, but *especially* because its String functions are just much slower. In fact, if you implement the algorithm I described above naÃ¯vely in Pharo, the execution time is about 780ms--nearly ten times slower. After some reflection, I chopped the time to 270ms by converting all the band names to integers as the first step of the process (ArtistLister>>generateMap: in the profile trace below). Not only does this avoid WideString>>hash and friends; it also allows me to bring in IdentityDictionary and IdentitySet in most locations due to Pharo's object format. But there's a lot left. I'm attaching the profile output below. Notice that Pharo spends more time reading and processing the file (about 120ms) than the Python program spends executing total. --Benjamin - 279 tallies, 279 msec. **Tree** -------------------------------- Process: (40s) Morphic UI Process: nil -------------------------------- 69.2% {193ms} ArtistLister>>groupsIn: |18.6% {52ms} FileReference(AbstractFileReference)>>contents | |17.6% {49ms} MultiByteFileStream(FileStream)>>contents | | 17.6% {49ms} MultiByteFileStream>>next: | | 5.0% {14ms} ByteString>>at:put: | | |5.0% {14ms} WideString class>>from: | | 5.0% {14ms} WideString>>at:put: | | 5.0% {14ms} primitives | | 1.4% {4ms} MultiByteFileStream>>next | | 1.4% {4ms} UTF8TextConverter>>nextFromStream: |14.7% {41ms} WideString(String)>>lines | |14.7% {41ms} WideString(String)>>linesDo: | | 10.0% {28ms} WideString>>copyFrom:to: | | |5.4% {15ms} WideString(String)>>isOctetString | | | |3.2% {9ms} WideString>>at: | | | | |2.2% {6ms} Character class>>value: | | | |2.2% {6ms} primitives | | |4.7% {13ms} WideString(String)>>asOctetString | | | 3.6% {10ms} primitives | | 4.7% {13ms} WideString(String)>>lineIndicesDo: | | 4.7% {13ms} WideString(String)>>indexOf:startingAt: | | 4.7% {13ms} WideString class(String class)>>indexOfAscii:inString:startingAt: |10.8% {30ms} ByteString(Object)>>split: | |10.0% {28ms} ByteString(Object)>>split:do: | | 5.7% {16ms} WideString>>copyFrom:to: | | |3.2% {9ms} WideString(String)>>asOctetString | | |2.5% {7ms} WideString(String)>>isOctetString | | | 1.8% {5ms} primitives | | 4.3% {12ms} ByteString(SequenceableCollection)>>split:indicesDo: | | 2.9% {8ms} WideString(SequenceableCollection)>>indexOfSubCollection:startingAt: | | |2.9% {8ms} WideString(String)>>indexOfSubCollection:startingAt:ifAbsent: | | | 2.9% {8ms} WideString(String)>>findString:startingAt: | | | 2.9% {8ms} WideString(String)>>findString:startingAt:caseSensitive: | | | 2.9% {8ms} WideString(String)>>findSubstring:in:startingAt:matchTable: | | 1.4% {4ms} primitives |7.2% {20ms} Set(Collection)>>addAll: | |5.0% {14ms} Set>>add: | | |3.6% {10ms} Set>>scanFor: | | | |3.6% {10ms} ByteString(String)>>= | | |1.4% {4ms} Set(HashedCollection)>>atNewIndex:put: | | | 1.4% {4ms} Set(HashedCollection)>>fullCheck | | | 1.4% {4ms} Set>>grow | |1.4% {4ms} OrderedCollection>>do: |5.4% {15ms} ArtistLister>>generateMap: | |5.4% {15ms} IdentityDictionary(Dictionary)>>at:put: | | 3.9% {11ms} Dictionary(HashedCollection)>>atNewIndex:put: | | |3.2% {9ms} Dictionary(HashedCollection)>>fullCheck | | | 2.5% {7ms} Dictionary(HashedCollection)>>grow | | | 1.4% {4ms} Dictionary>>noCheckAdd: | | | 1.4% {4ms} Dictionary(HashedCollection)>>findElementOrNil: | | 1.4% {4ms} IdentityDictionary(HashedCollection)>>findElementOrNil: |4.3% {12ms} OrderedCollection>>collect: | |4.3% {12ms} OrderedCollection>>addLast: |4.3% {12ms} Dictionary>>at: | |4.3% {12ms} Dictionary>>at:ifAbsent: | | 2.2% {6ms} Dictionary(HashedCollection)>>findElementOrNil: | | |2.2% {6ms} Dictionary>>scanFor: | | | 1.4% {4ms} ByteString(String)>>= | | 2.2% {6ms} primitives |3.9% {11ms} ByteString(String)>>trimmed | 3.9% {11ms} ByteString(String)>>trimBoth | 3.2% {9ms} ByteString(String)>>trimBoth: | 2.2% {6ms} primitives 19.4% {54ms} ArtistLister>>popularPairsIn:onlyKeeping: |15.8% {44ms} OrderedCollection(Collection)>>asBag | |15.8% {44ms} Bag class(Collection class)>>withAll: | | 15.8% {44ms} Bag(Collection)>>addAll: | | 13.6% {38ms} Bag>>add: | | |13.6% {38ms} Bag>>add:withOccurrences: | | | 10.0% {28ms} Dictionary>>at:put: | | | |8.6% {24ms} Dictionary(HashedCollection)>>findElementOrNil: | | | | |7.9% {22ms} Dictionary>>scanFor: | | | | | 4.7% {13ms} Array(SequenceableCollection)>>hash | | | | | |3.2% {9ms} primitives | | | | | 2.5% {7ms} Array(SequenceableCollection)>>= | | | | | 2.5% {7ms} Array(SequenceableCollection)>>hasEqualElements: | | | | | 1.4% {4ms} primitives | | | |1.4% {4ms} Dictionary(HashedCollection)>>atNewIndex:put: | | | 3.6% {10ms} Dictionary>>at:ifAbsent: | | | 2.2% {6ms} Dictionary(HashedCollection)>>findElementOrNil: | | | |2.2% {6ms} Dictionary>>scanFor: | | | | 1.4% {4ms} Array(SequenceableCollection)>>= | | | | 1.4% {4ms} Array(SequenceableCollection)>>hasEqualElements: | | | 1.4% {4ms} primitives | | 2.2% {6ms} OrderedCollection>>do: |2.5% {7ms} ArtistLister>>uniquePairs:do: 4.3% {12ms} ArtistLister>>bandsAboveThresholdIn: |4.3% {12ms} Bag(Collection)>>addAll: | 4.3% {12ms} Bag>>add: | 4.3% {12ms} Bag>>add:withOccurrences: | 2.5% {7ms} Dictionary>>at:put: | 1.8% {5ms} Dictionary>>at:ifAbsent: 3.2% {9ms} Set>>includes: 2.5% {7ms} Set(HashedCollection)>>findElementOrNil: 2.5% {7ms} Set>>scanFor: **Leaves** 6.8% {19ms} WideString(String)>>asOctetString 6.5% {18ms} ByteString(String)>>= 5.4% {15ms} Dictionary>>at:ifAbsent: 5.0% {14ms} WideString>>at:put: 5.0% {14ms} WideString class>>from: 5.0% {14ms} MultiByteFileStream>>next: 5.0% {14ms} WideString(String)>>isOctetString 4.7% {13ms} WideString class(String class)>>indexOfAscii:inString:startingAt: 4.3% {12ms} OrderedCollection>>addLast: 3.9% {11ms} WideString>>at: 3.6% {10ms} Array(SequenceableCollection)>>do: 3.6% {10ms} OrderedCollection>>do: 3.2% {9ms} Set>>scanFor: 3.2% {9ms} Dictionary(HashedCollection)>>atNewIndex:put: 3.2% {9ms} Array(SequenceableCollection)>>hash 2.5% {7ms} ArtistLister>>uniquePairs:do: 2.2% {6ms} Dictionary>>scanFor: 2.2% {6ms} Character class>>value: 2.2% {6ms} ByteString(String)>>trimBoth: 2.2% {6ms} Array(SequenceableCollection)>>hasEqualElements: 1.8% {5ms} Array class(Behavior)>>inheritsFrom: 1.4% {4ms} ByteString(SequenceableCollection)>>split:indicesDo: 1.4% {4ms} SmallInteger>>hashMultiply 1.4% {4ms} Dictionary(HashedCollection)>>findElementOrNil: **Memory** old +5,124,784 bytes young -340,984 bytes used +4,783,800 bytes free +295,464 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 22 totalling 22ms (8.0% uptime), avg 1.0ms tenures 15 (avg 1 GCs/tenure) root table 0 overflows

Oct. 5, 2014

Re: [Pharo-users] How to create a package via code correctly ?

by Esteban Lorenzano

> On 05 Oct 2014, at 00:04, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-10-04 8:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > (RPackage named: 'ABC') register. > > or > > RPackageOrganizer default registerPackage: (RPackage named: 'ABCâ). > > or > > RPackageOrganizer default registerPackageNamed: âABCâ. > > the 3 ways work (just tested). > If you are not succeeding probably there is another, previous problem (like de-sync caused by some failed operation made before)â¦ > > cheers, > Esteban > > Does this include the SystemOrganization part? > (SystemOrganization addCategory: 'Keks4') > Or is this not neccessary anymore? that includes everything. even MC package registration (since now there is a one-to-one relation between them) Esteban > > > > > > On 04 Oct 2014, at 08:30, Ben Coman <btc(a)openInWorld.com> wrote: > > > > itlists(a)schrievkrom.de <mailto:itlists@schrievkrom.de> wrote: > >> How can I create a package correctly via code ? > >> I tried stuff like > >> PackageOrganizer default registerPackageNamed: 'Keks4' > >> SystemOrganization addCategory: 'Keks4' > >> but the package does not appear in the browser. > >> Marten > > > > I don't have a direct answer for you, since I don't know - but I can tell you how to discover the answer yourself (or at least how I would go about it myself) > > > > 1. Right-click in the package pane, and then bring up the Halos[1] on the menu-item-of-interest e.g. "Add package..." > > > > 2. From the Debug (spanner) halo menu choose "Inspect morph". Scroll down until you see something that looks like a method being called. Go to that method and put a "self halt" at the top. > > > > 3. Invoke the menu-item-of-interest, then in the debugger step through what it does, and copy that for your own purpose. > > > > Please report back if you succeed with this, or otherwise feel free to ask for more assistance. I just believe it helps you more to teach you how to fish :) rather than just give you one someone else caught. > > > > cheers -ben > > > > [1] http://web.cecs.pdx.edu/~black/OOP/Tutorial/Morphic%20Worksheet.html <http://web.cecs.pdx.edu/~black/OOP/Tutorial/Morphic%20Worksheet.html> > >

Oct. 5, 2014

Re: [Pharo-users] Installing GToolkit

by Tudor Girba

Hi Evan, The instructions are a bit wrong. It should be "activateWithoutSaving" instead of "activate". The GTImageSetupCommandLineHandler does more default settings. Just take a look at the activateWithoutSaving method and pick what you want, or use the script that Phil suggested only to install the tools. But, what do you mean when you say that the Playground is not working? Cheers, Doru On Sat, Oct 4, 2014 at 8:07 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Hello, > > I am trying to check out GTPlaygroundl, but I can't seem to get it working > and was wondering if anyone had any idea what I might be overlooking. > > I download a new image with curl get.pharo.org | bash > I run, from http://www.humane-assessment.com/blog/installing-gtoolkit > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > configuration; > loadDevelopment. > #GTImageSetupCommandLineHandler asClass new activate > > It loads for a while and then the image closes. When I open it again the > background is white and my settings have been wiped. The playground does > appear, but it doesn't seem to work properly (there seems to be no way to > advance the miller columns). Am I looking at the wrong installation > information? > > Thanks, > Evan > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-users] NeoCSVReader skipEmptyLines?

by Esteban A. Maringolo

2014-10-04 10:47 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Esteban, > > On 04 Oct 2014, at 02:42, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> Sven, >> >> Is it possible to skip blank/empty lines in NeoCSVReader? >> >> So if a line is empty or contains ",,,,,,,," it would be skipped from >> the iteration. >> >> Does it already provider such feature? (I couldn't find any setting >> related with this). >> >> Esteban A. Maringolo > > Could you elaborate a bit on the use case ? Yes, users upload a CSV file with the proper columns (sometimes they don't, but that's another story), and because they export/copy the CSV from Excel most of the times there are *lots* (might be hundreds) of empty lines at the end, it is, lines with separators only, or even blank lines. > My first reaction would be that you have to deal with these yourself afterwards. When dealing with "array based" records, it is, with no #recordClass defined it would be easier. Because you can check whether all the values of the array are empty or nil. So on each iteration (#next) you could return the value array if it isn't empty or send #next again until you get a record with any data. When working with a record class I think you can't do this, because it seems you instantiate the record before iterating through each field of the record. > What would be the definition of an empty record ? What about empty quoted fields ? An empty record of a four columns CSV file would look like: ,,, or (if some columns are quoted) ,"","", I don't see how a record like that could be of any use. Best regards! Esteban A. Maringolo > PS: I got your other contribution, I think it is OK to add, thanks. Great!

Oct. 5, 2014