January 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Xtreams updates: positioning, slicing and stitching
by mkobetic＠gmail.com Jan. 2, 2011

Jan. 2, 2011

I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the holidays to catch up with the state on VW side. The primary changes are updates/fixes of the positioning API and a cleanup/extension of the slicing API. The slicers are replaced by much simpler #slicing setup and the inverse, #stitching, was added (the updated documentation can be found in the usual place: http://code.google.com/p/xtreams/wiki/Substreams) More details on the changes below. Enjoy, Martin Positioning updates: * ++/--/+=/-=/position: now return the argument instead of self * they all also skip as far as they can raising Incomplete with the count of the actual amount skipped * this means that the positioning wrapper will advance as far forward as it needs to satisfy the request, in case of -= it means it will advance all the way to the end of the underlying stream. * similarly asking a positioning wrapper for length or available will make it advance to the end * in the other direction, positioning wrapper can't skip past the beginning of its buffer, so if the buffer window moves forward, so does the absolute position; position 0 is always the beginning of the buffer, whereever it is at any given moment * also extended ++ and -- to call the other if the argument is negative (it helps with implementation of the others) All read/write/positioning calls except put:/get/read: now consistently return element counts so that one can use a computation as an argument and then obtain the actual number in response. This simplifies common patterns like: actual := [ stream ++ (x max: y) ] on: Incomplete do: [ :ex | ex count ]. instead of: actual := x max: y. [ stream ++ actual ] on: Incomplete do: [ :ex | actual := ex count ]. Slicing/Stitching updates: Replacing all the -er: slicer creation methods with the new #slicing and adding complementary #stitching. * #slicing is sent to a substream "prototype" and clones it when next slice is needed, e.g. (stream limiting: 3) slicing * #stitching is sent to a read stream of streams and makes it look like one continuous stream [ stream limiting: stream get ] reading stitching * stitching replaces the experimental proto and concatentation streams * ReadStream>>, is now implemented with stitching too

2 1

[Pharo-project] Graph library in Smalltalk - Need for advices
by CÃ©drick BÃ©ler Jan. 1, 2011

Jan. 1, 2011

Hi All (cross-posted squeak and pharo), I'm more and more in need for some graph lib in smalltalk. I need graphs to implement special bayesian networks (specific inference mechanisms which aren't probabilistic) and also influence diagrams [1], and maybe in the future, reliablity tools (markov chains, petri nets, ...)... Do you know any existing smalltalk (open source) projects for graphs? I've only found [2] and [3] from 2005 but don't know them (they don't feel as generic as I would expect). If not, do you know any open-source projects outside of Smalltalk that I may look at ? I've found BGL (C++) [3] which was ported in Ruby (RGL) [4]. Does some of you know this lib ? Do you think it would be interesting to have an equivalent in Smalltalk ? As usual, any comments/advises would be greatly appreciated ;-) ? Cheers, CÃ©drick [1] http://en.wikipedia.org/wiki/Influence_diagram [2] http://www.squeaksource.com/Graph [3] http://www.squeaksource.com/DynaGraph.html [4] http://www.boost.org/doc/libs/1_42_0/libs/graph/doc/index.html [5] http://rgl.rubyforge.org/rgl/index.html

11 26

[Pharo-project] :)
by StÃ©phane Ducasse Jan. 1, 2011

Jan. 1, 2011

roel wuyts sent me that nice snippet :) | wishStream adjectives | wishStream := WriteStream with: 'For 2011 I wish you '. adjectives := { 'fun' . 'exotic' . 'brilliant' . 'extraordinary' }. { 'research' . 'students' . 'artefacts' . 'conferences'} do: [:e | wishStream nextPutAll: adjectives atRandom; space; nextPutAll: e] separatedBy: [wishStream nextPutAll: ', ']. wishStream nextPutAll: ' and of course good health!'. ^wishStream contents

1 0

[Pharo-project] loading of codetalk fails due to
by Enrico Spinielli Jan. 1, 2011

Jan. 1, 2011

hi, loading codetalk from potsdam now fails with Error: The spelling dictionary cannot be downloaded from <http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat>. I think this is due to recent changes in RB (which codetalk loads) http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg24201.ht… Any suggestions? Bye Enrico -- Enrico Spinielli "Do Androids dream of electric sheep?"â Philip K. Dick "Hear and forget; see and remember;do and understand."âMitchel Resnick

2 2

[Pharo-project] Proper Smalltalk lots of classes
by Jimmie Houchin Jan. 1, 2011

Jan. 1, 2011

Hello, I am porting the FIX protocol to Squeak/Pharo. http://www.fixprotocol.org/ It is the Financial Information eXchange protocol. It is used by many firms in the financial industries, stocks, forex, etc. There is good documentation and also a semi-reference implementation in Java. http://www.quickfixj.org I have a partial port started but I wanted a check with those who know more than I about proper Smalltalk coding. In the Java implementation there are over 2000 classes. In the protocol there are approximately 90 message types and 956 field types. I am initially creating the message classes as they form the basis of the protocol and the fields are simply instance variables and methods in the message classes. I am not porting the Java library. I am implementing the protocol in Smalltalk from the documentation. Initially I have created a Fix44Field class with its necessary variables. There are several versions of the Protocol and FIX 4.4 is the one required for my application. With this Fix44Field class I am creating a Dictionary with the 956 different field types. I am planning on creating a constructor method which will create the desired field from the information in the dictionary about the field and its properties. Am I way off base here? Should I really create the 956 classes necessary to for each field in addition to the 90 or so message classes, and then I don't know what else I haven't discovered yet. Having 1000+ classes just seems unwieldy and naively it just doesn't feel like the Smalltalk way. I could be wrong, but I haven't seen such an example to my memory. I don't know enough about Java to know if it is good Java form either. When I have a reasonably fleshed out, tested and working solution, I will make the source available under a MIT license. I would love to see Squeak/Pharo become an out of the box viable option for trading applications. Advise and wisdom greatly appreciated. Thanks. Jimmie

3 2

[Pharo-project] about growing streams and allocating buffers
by Philippe Marschall Jan. 1, 2011

Jan. 1, 2011

Hi I've been doing some performance work lately in Seaside. Long story short Seaside (and I guess AIDA too) spends of if it's rendering time in WriteStream (#nextPutAll:, #nextPut:). The way WriteStream >> #pastEndPut: behaves is not really ideal for Seaside. It grows the underlying collection by just enough to accommodate the argument collection (or 20 which ever is bigger). Now image the following not very unlikely scenario. You start with a 4k buffer and put on average a 10 element collection (remember all those tags are put individually) until you have a 16k response. You allocate more than a thousand intermediary collections to get there. What would be better suited for Seaside is doubling the required size. In the worst case that would mean wasting 50% of memory but it would make the overhead of creating intermediary collections logarithmic. In the given example that would take us only three allocations to get there. Now I do realize there are other applications for Pharo where this strategy is not ideal and this is not a killer for us. I just wanted to shed some light and this and ask whether other projects are in a similar situation. To get a feel how allocation limited Seaside is: avoiding one allocation of a 16k ByteArray per request can make a difference in throughput between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP Components"). If anybody knows a way to make allocation of large young space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd like to hear it. Cheers Philippe

2 2

Re: [Pharo-project] about growing streams and allocating buffers
by Philippe Marschall Jan. 1, 2011

Jan. 1, 2011

On 01.01.2011 14:39, Levente Uzonyi wrote: > On Sat, 1 Jan 2011, Philippe Marschall wrote: > >> Hi >> >> I've been doing some performance work lately in Seaside. Long story >> short Seaside (and I guess AIDA too) spends of if it's rendering time in >> WriteStream (#nextPutAll:, #nextPut:). >> >> The way WriteStream >> #pastEndPut: behaves is not really ideal for >> Seaside. It grows the underlying collection by just enough to >> accommodate the argument collection (or 20 which ever is bigger). Now > > No it doesn't. The code in #pastEndPut: is > > collection := collection grownBy: ((collection size max: 20) min: 1000000). > > so the argument of #grownBy: is at least 20, at most 1000000 and it's > size of the internal buffer (collection) if it's between 20 and 1000000. > So in most practical cases it's the value of [collection size]. > #grownBy: allocates a new collection that has the size of the > collection's size + the argument, which is 2 * self size in the most > common case. So the size grows exponentially till it reaches 1000000 and > then linearly (with a relatively high constant 1000000). This guarantees > that the cost of #nextPut: is constant in most cases. You're right, I misread the code, that's the behaviour for #nextPut:. However #nextPutAll: does: newEnd := position + aCollection size. newEnd > writeLimit ifTrue: [self growTo: newEnd + 10]. and #growTo: does then: newSize := anInteger + (oldSize // 4 max: 20). grownCollection := collection class new: newSize. aCollection is the argument collection, not the underlying collection. So that's the required size puls ten plus the max of a fourth of the current size and 20. >> image the following not very unlikely scenario. You start with a 4k >> buffer and put on average a 10 element collection (remember all those >> tags are put individually) until you have a 16k response. You allocate >> more than a thousand intermediary collections to get there. > > So just 3: one for 4k (the initial), one for 8k and one for 16k. Yes. >> What would be better suited for Seaside is doubling the required size. > > That's exactly what's happening in most cases. In the #nextPut: case, not in the #nextPutAll: case. >> In the worst case that would mean wasting 50% of memory but it would >> make the overhead of creating intermediary collections logarithmic. In > > The overhead is constant (amortized) in most cases. > >> the given example that would take us only three allocations to get there. >> Now I do realize there are other applications for Pharo where this >> strategy is not ideal and this is not a killer for us. I just wanted to >> shed some light and this and ask whether other projects are in a similar >> situation. >> >> To get a feel how allocation limited Seaside is: avoiding one allocation >> of a 16k ByteArray per request can make a difference in throughput >> between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP >> Components"). If anybody knows a way to make allocation of large young >> space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd >> like to hear it. > > IIRC CogVM's GC is different from SqueakVM's GC in the sense that it is > activated when a predefined amount of data is allocated, not when the > number of allocations since the last GC reaches a predefined limit. So > you have to tune the GC differently on Cog and non-Cog VMs. Do you know where I can find more information about this? Cheers Philippe

1 0

[Pharo-project] [OT] questions answered on stackexchange: Why do good programmers have ugly websites?
by Igor Stasenko Jan. 1, 2011

Jan. 1, 2011

Funny. Really funny. Especially this one: " Just be thankful there's more than just a command-prompt. " I hope that with Pharo we have enough 'bad' programmers, which can make good designs.. otherwise we're in trouble :) -- Best regards, Igor Stasenko AKA sig.

1 0

Jan. 1, 2011

Hi guys I think that over the years I (but also many of you, I know) tried to expose newbies to smalltalk or our culture. And often we get bad reactions, bad windows, bad colors, slow, why not in svn, ..... I think that showing Smalltalk to newbies is the best we can do to ourselves, not really to attract new people but also to get a large kick in the %^&* because most of the time students are not stupid, they are exposed to other technos. So each time we believe we want to show them something cool and they do not really consider it as cool as we believe, we can of course think that they are idiot (some of them are) but most of the time we can also think that may be we stayed too long in our little boxes and the world moved (interfaced well with c, fast, cool frameworks, has cool tools, processes (integration...), cool UIs, web stuff.....). So each time we get down because we do not see the little flame opening in the yes of the others we can think hard and get from them what we missed. I really happy to get exposed to student acid tests, this is a valuable feedback and I wanted to share that with you. Stef

12 19

[Pharo-project] WeakArray>>isFinalizationSupported
by Sean P. DeNigris Jan. 1, 2011

Jan. 1, 2011

As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls. Why was this method removed from Pharo? I want to make sure I understand what I'm doing when I remove these calls. Thanks. Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

11 37