- Pharo-dev - lists.pharo.org

[Pharo-project] PharoConf 2013 @ Bern?
by StÃ©phane Ducasse Dec. 5, 2012

Dec. 5, 2012

Hello Pharoers The software composition group of the university of Bern proposed to organize the next pharo conf at berne during the week of 2-3 of April 2013. We are really happy of this proposal. Now we would like to know what you think about it before committing to the date and location. The Pharo board and crew

2 2

[Pharo-project] Vim Keys?
by âking Dec. 5, 2012

Dec. 5, 2012

Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! ââ

13 38

[Pharo-project] Open Source and Constraints | Documentation is King
by Sven Van Caekenberghe Dec. 5, 2012

Dec. 5, 2012

Well written: http://kennethreitz.org/open-source-and-constraints.html I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

8 11

[Pharo-project] using a long running native thread - NativeBoost or Plugin?
by drush66 Dec. 5, 2012

Dec. 5, 2012

Would it be possible to start native thread inside pharo? This thread would run (for quite a long time) some event loop (like the libev), and post some info to the SharedQueue. Smalltalk code would in turn be reading stuff from this queue. You could say it would be pumping events from libev to SharedQueue instance for Smalltalk code to consume. Is this doable? With NativeBoost or Plugin? I have also found some info on threaded VM, but if I understand it correctly it seems more oriented to provide a thread to execute FFI call on it. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plu… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 3

[Pharo-project] Performance Tip: Using buffered streams
by Sven Van Caekenberghe Dec. 5, 2012

Dec. 5, 2012

Hi, <short-version> When doing complex IO, like writing or parsing protocols, to non-memory streams, like file streams (and probably socket streams), buffering can make an important difference. ZnBufferedWriteStream and ZnBufferedReadStream are an easy solution to experience the difference. </short-version> And now the long version: first some measurements (code based on latest versions of Zinc, NeoCSV, NeoJSON and STON): NeoJSON | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :stream | (NeoJSONWriter on: stream) nextPut: data ] ] timeToRun. 22152 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoJSONWriter on: stream) nextPut: data ] ] ] timeToRun. 5147 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | (NeoJSONReader on: stream) next ] ] timeToRun. 3502 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun. 1214 STON | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :stream | STON writer on: stream; nextPut: data ] ] timeToRun. 22275 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | STON writer on: stream; nextPut: data ] ] ] timeToRun. 5501 [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :stream | STON reader on: stream; next ] ] timeToRun. 3632 [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | STON reader on: stream; next ] ] ] timeToRun. 1367 NeoCSV | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] timeToRun. 20916 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] ] timeToRun. 5559 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addFloatField; addFloatField; addField; upToEnd ] ] timeToRun. 1290 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addFloatField; addFloatField; addField; upToEnd ] ] ] timeToRun. 970 The reason for these non-trivial speedups is that buffering is missing and/or buffer management is suboptimal in the standard file stream classes. Simply wrapping the stream with a 64Kb buffer yields results like this. We already knew this for writing (and Fuel adapted it as well), but it seems to make a similar, although smaller difference when reading. <side-note> Attentive, curious readers might ask why in this particular benchmark the reading is so much slower than the writing - normally it should be the inverse or at least they should be closer to each other. Lo and behold: another performance issue: float printing (as opposed to parsing) is extremely slow (probably partially due to its reliance on LargeInteger arithmetic) ! Here is a similar benchmark with only Integers: | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each + 100000. each - 100000. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] ] timeToRun. 311 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addIntegerField; addIntegerField; addField; upToEnd ] ] ] timeToRun. 396 </side-note> If ZnBufferedWriteStream or ZnBufferedReadStream were useful in speading up your code, please let us know. Sven PS: There is one ZnBufferedReadStream limitation: by design, #position, #position: or #skip: -1 and everything on top of that are NOT supported - IMHO real streams should not (and cannot) provide these operations. A sad consequence is that NumberParser and its subclasses (and thus Number class>>#readFrom:) do not work. NeoJSON and STON do their own number parsing, NeoCSV relies on a new class, NeoNumberParser, that is independently usable, though restricted to normal numbers as opposed to the full Smalltalk syntax. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

7 14

[Pharo-project] Roassal nested nodes withText
by roberto.minelli＠usi.ch Dec. 5, 2012

Dec. 5, 2012

Hi guys, I'm using Roassal to build a visualization that looks like the following: http://www.xconomy.com/wordpress/wp-content/images/2012/11/skeuo-calendar.p… I create two ad-hoc layouts (i.e., extending the ROGridLayout) to individually layout days inside months and months inside years. I have a piece of code that looks something like: > view shape rectangle withText. > > view nodes: nodes forEach: [ :aGroupOfObjects | | innerNodes | > > innerNodes := do something with aGroupOfObjects. > ... > view shape rectangle size: 25; withCenteredText. > ... > view nodes: innerNodes. > view layout: ROMonthLayout new. > ] > > view layout: ROYearLayout new. > > view edges: ... Notice that I want the both the outer node (i.e., the month container) and the inner nodes (i.e., days) with labels. The problem is that when I set both nodes with labels the view takes time to be generated and interactions become impossible (i.e., the whole image actually becomes slow and you can no longer drag around shapes in the view). I explored the issue a little bit and discovered that it might be something related to ROShape>>chainedDrawOn:for: and the way Roassal handles shapes with "nested" shapes (i.e., when 'next' is not a RONullShape . I inspected one of my outer nodes and discovered that I have a chain such that 'outerNode next' is a ROLabel and the ROLabel has a ROChildrenShape as next and the next of the ROChildrenShape is a RONullShape . Have you ever experienced such a problem? Do you know how can I handle that? Do you see any potential problem in the snippet I posted above? Cheers and thanks in advance, Roberto

1 0

[Pharo-project] Some Object methods that could be removed ?
by Sven Van Caekenberghe Dec. 5, 2012

Dec. 5, 2012

Hi Guys, Here are 4 Object methods that could maybe be removed, right ? Object>>#xxxClass no real senders except MethodFinder Object>>#identityHashPrintString 1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either Object>>#mouseUpBalk a does nothing hook, no other implementors only two senders, looks like being related to debugging Object>>#windowReqNewLabel: a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model The last two could be changed to a conditional perform if we want to keep the hooks. If there are no objections, I could produce a slice (or slices). Sven BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

4 7

[Pharo-project] [update 2.0] #20428
by Marcus Denker Dec. 5, 2012

Dec. 5, 2012

20428 ----- Issue 7097: VirtualMachine class improvements http://code.google.com/p/pharo/issues/detail?id=7097 Issue 7095: Add GoferResolvedReference >> #merge method http://code.google.com/p/pharo/issues/detail?id=7095 Issue 7096: Better option protocol for CommandLineHandler http://code.google.com/p/pharo/issues/detail?id=7096 Issue 7094: Removing some Object methods http://code.google.com/p/pharo/issues/detail?id=7094 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.997.diff http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.487.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.752.diff http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.65.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1297.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1263.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.189.diff

2 1

[Pharo-project] PetitSmalltalk: portable number parsing
by Frank Shearar Dec. 5, 2012

Dec. 5, 2012

I've attached a fix to PetitParser, using Number class >> #readSmalltalkSyntaxFrom: instead of Number class >> #readFrom:. The former selector makes clear the intention of reading a Smalltalk number. The latter selector means something slightly different in at least one Smalltalk: in Squeak, Number class >> #readFrom: is more "user facing" in the sense that it accepts a range of number representations that are not valid syntax. This change has no impact for Pharo because it has this selector: http://code.google.com/p/pharo/issues/detail?id=2063 (thanks to Nicolas Cellier). This fix makes PetitSmalltalk's tests all pass in Squeak. frank

1 0

[Pharo-project] Some Object methods that could be removed ?
by Stephan Eggermont Dec. 5, 2012

Dec. 5, 2012

A better way would be to get all source from all the repositories and extract all method sends and symbols, compare that to the list you'd want to remove and mark the packages you don't want to be able to load anymore. You'd still miss some, but at least get a much better idea of impact Stephan

1 0