- Pharo-dev - lists.pharo.org

[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

[Pharo-project] realized and learned something today :)
by StÃ©phane Ducasse Jan. 1, 2011

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

[Pharo-project] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]
by Guillermo Polito Jan. 1, 2011

Jan. 1, 2011

Hi, I would like to discuss the UI for shortcuts and not to impose it :). So.. I was exploring the Idea of configuring the shortcuts in settings as the screenshot shows. What do you think of that? I don't think we need a separated tool to configure shortcuts. Settings look ok. Tomorrow I'll be putting a lot of effort on it ;). Cheers! On Mon, Dec 27, 2010 at 6:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 27, 2010 at 12:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> I also would like a cmd+f: search anything... but that needs also an >> application (like algernon, which I'm currently not supporting anymore due >> time issues), not just a command :( >> well, at least a cmd+f: search class would be fine :) >> > > +1 > It sound like a good project for someone with time and wanting to learn :) > > >> >> El 27/12/2010, a las 5:38a.m., StÃ©phane Ducasse escribiÃ³: >> >> > I suggest that you define lists = >> > >> > simple eamcs bindings = >> > ctral a ctrle >> > >> > Windows manipulation >> > cmd W >> > ... >> > >> > Your special binding >> > >> > >> > Then you should have contexts >> > World >> > TextMorph >> > Editor only >> > >> > (of course some list will only be able to be attached to a given >> object programmatically >> > example: for botsinc I wanted specific binding to that morph class >> only -- but you do not care) >> > >> > then a config is >> > >> > (lists, lists) context >> > (mybinding, lists, lists) context >> > >> > where , make sure that mybinding take precedence >> > >> > >> > Does it make sense? >> > >> > Stef >> > >> > >> > >> > On Dec 27, 2010, at 2:37 AM, Guillermo Polito wrote: >> > >> >> What about something like the attach? >> >> >> >> On Sun, Dec 26, 2010 at 7:45 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >> Wow, haha, this is wonderful! So, putting some order: >> >> >> >> 1) shortcuts published as settings with a default? Will that be ok? >> This make me think the following: >> >> - how to share shortcuts. Files? Keymapping used to use SIXX, but >> maybe it is not suitable for a light solution (I don't know much about SIXX) >> >> - downloading a new image (or a new version of a package with >> shortcuts) could make us lose our own-defined shortcuts. >> >> >> >> 2) support for the following shortcuts: >> >> >> >> - a shortcut to bring up the wolrd menu. Not sure which shortcut. >> >> - use ctrl + tab to switch between windows instead of cmd + arrows >> >> - a shortcut for what it is (hidden) now with cmd + shift + click >> (list of opened windows) >> >> - Shortcuts for opening standard tools: Workspace, Transcript, >> TestRunner, etc. >> >> - Shortcut for duplicating a windows >> >> - a shortcut for saving the image (cmd+ shoft + s ?) >> >> - a shortcut for quitting the image with and without saving >> >> - a shortcut to see a list of shortcuts >> >> >> >> I would like to add some more items to #2, and to define the keys that >> triggers them. >> >> #1 seems to be of some work :). I'll work on it ASAP. >> >> >> >> Step by step, as Stef and Mostaza Merlo says :). >> >> >> >> Cheers! >> >> Guille >> >> >> >> >> >> On Sun, Dec 26, 2010 at 7:18 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> + 1 :) >> >> And save them as configuration >> >> >> >>> On Sun, Dec 26, 2010 at 1:13 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> my wishlist: >> >>> >> >>> - a shortcut to see all available shortcuts and change them >> >>> >> >>> + a lot >> >> >> >> >> >> >> >> >> >> <PharoScreenshot.2.png> >> > >> > >> >> >> >

6 13

[Pharo-project] Fireworks 2011
by Alexander LazareviÄ Dec. 31, 2010

Dec. 31, 2010

Just found some old code of mine and pushed it to squeaksource. In a 4.1 Squeak or recent trunk image do (Installer repository: 'http://www.squeaksource.com/Fireworks') install: 'Fireworks'. (Smalltalk at: #FireworksAnimation) start. In a 1.1.1 Pharo image do ((Gofer new squeaksource: 'Fireworks') package: 'Fireworks') load. (Smalltalk at: #FireworksAnimation) start. :D All the best for 2011, Alex PS: ALT-. or CMD-. will help ;)

6 5

[Pharo-project] [ANN] SqueakMovieMorph (Alpha) plays any video file playable by QuickTime
by DeNigris Sean Dec. 31, 2010

Dec. 31, 2010

Installation: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ((Smalltalk at: #ConfigurationOfFFI) project latestVersion) load. Gofer new squeaksource: 'SophieGoldDig'; package: 'SpdQT'; load. Then, blow your mind by playing a video in-image with: aURI := URI fromString: 'file:///path/to/video.ext'. movie := QuickTimeMovie openMovieFromURI: aURI. m := SqueakMovieMorph openOn: movie. Pharo 1.1.1 - there will be two errors â for both, go into the debugger and remove the isFinalizationSupported checks. See http://seandenigris.com/blog/?p=723 for details. Sean DeNigris sean(a)clipperadams.com

3 5

[Pharo-project] are we going to remove MethodFinder and MessagesNames for Pharo 1.2?
by Mariano Martinez Peck Dec. 30, 2010

Dec. 30, 2010

yes, yes, depreacting. But....it is confusing having THREE things for the same stuff. So, since we now have "Finder" and we want to push that, what about removing MethodFinder and MessagesNames for Pharo 1.2? At least, what about removing them from the menu so that not to confuse new comers. And then, those hacky guys that prefer MethodFinder or MessagesNames can add it to the menu or open it by hand. And then, in 1.3 we really remove not only form menu but the code itself. Cheers mariano

5 7