July 2012 - Pharo-users - lists.pharo.org

Weird behavior with my 1.4 image - windows not responding anymore

by phil＠highoctane.be

I've been experiencing a weird behavior with an image. This is an image from 25/6/12 that I left in a corner. I opened it back with the same VM I was using (CogVM on Mac) and windows were there and all but unresponsive. I can get the list of morphs with a shift-click on the background and delete them but they otherwise appear dead (not reacting to clicks, keystrokes etc). But the world menu shows and opens new windows without problems. These windows do work. I activated TWM, which sees the objects and is able to layout things properly. But this doesn't help in getting things active again. Anybody having experienced that? It is a 1.4 image. Phil

July 12, 2012

Re: [Pharo-users] Announcements - where do I start?

by Sven Van Caekenberghe

Hi Phil, Announcement are very simple, there is not much to it. It is all about decoupling. If you read some basic overview and looked at the code, you known probably more than enough to start. Another example you could look at it the Zn logging mechanism, category 'Zinc-HTTP-Logging'. At the system level there are some finer/subtle points, but for normal code it is pretty straightforward I think. Sven On 12 Jul 2012, at 12:51, phil(a)highoctane.be wrote: > I have been reading about announcements but can't really get how they work. > > Is there someone having a little sample or two for me? The PBE2 book sheds some light on the subject but not enough to comprehend for me. I need some samples to work from. > > Where should I look? > > Phil

July 12, 2012

Announcements - where do I start?

by phil＠highoctane.be

I have been reading about announcements but can't really get how they work. Is there someone having a little sample or two for me? The PBE2 book sheds some light on the subject but not enough to comprehend for me. I need some samples to work from. Where should I look? Phil

July 12, 2012

ss3.gemstone.com MAINTENANCE downtime Friday July 13 from 1-2pm PDT

by Dale Henrichs

We will be adding more disk space to the ss3.gemstone.com site on Friday July 13 at 1pm PDT. The site is expected to be down for an hour while the new drives are being added. Dale

July 11, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by Patrik Sundberg

I've done a bit more studying and I think a combination of SystemAnnouncer events to catch method changes, pragmas to mark "graph nodes" and use of method wrappers could create a very nice way to shield the user of my graph API from thinking of identity caches and graph node details. The other cool feature of use is the new class builder and custom slots. For nodes that are not dynamic/calculations (what I call properties or relationship nodes) I think custom slots could be interesting but need to test out some ideas to organize thoughts. Obviously won't work for calculated/dynamic nodes since I need ability to take arguments for those and can't map to a slot. In principle all I'm after is to have an identity map and a graph (DAG) in the background whose management is hidden away from user so he can focus on domain logic and not graph stuff. Going on holiday for a week and a bit, shall start experimenting after that. P.S found some friend of friend who worked on kapital, will explore if they use a graph etc when I get a chance. On Jul 6, 2012 1:16 PM, "Patrik Sundberg" <patrik.sundberg(a)gmail.com> wrote: > On Fri, Jul 6, 2012 at 12:38 PM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > >> You should read as much as you can about Kapital of JPMC. It does more or >> less what you describe for esoteric Prime Interest Derivatives and very >> scalably .. >> >> > I've heard of that one. Never worked at JPM so haven't seen it first hand > though. I'll see what I can find. In terms of concepts I'm fully on top of > it (have a background with other companies using similar ideas, but not in > smalltalk but their own in-house language). So the good part is that I know > exactly what I want conceptually, but I'm not stuck into smalltalk enough > to know the natural way to implement the concepts. It may sound like a > huge endeavour but I've done a lot of it in ruby and even as a side project > to my real job we're talking about a couple of months to have something > useful. > > >> I doubt if there is much in the public domain, but the fact that Kapital >> is the golden standard in this product line talks highly of why Smalltalk >> is THE platform for this kind of product. >> >> > I wouldn't say it's the golden standard, that's taking it a bit far, there > are others that I rate higher bit I'm also biased :) But I do agree that > smalltalk is a reasonably natural platform for these types of concepts, > hence why I'm exploring it. > > >> It would be nice to have a Pharo based derivative product that can easily >> beat Ruby/ Java / .Net at this dynamic visualization using standard >> browsers, where Nautilus too can serve your purpose.. or a home grown tree >> based browser.../ Grids.. >> >> > That's my hunch, that the tooling work would be much cut down. In my > current ruby mockup I'm kind of creating a poor man's image like experience > - it's jruby on the JVM, vim + vim-slime to send code fragments to the > "runtime", git, and most likely homegrown GUI to navigate the graph and > play with it (not done anything on that yet). I'll be keeping jruby as a > dear tool as right now it's a fantastic glue tool in terms of interacting > with anything out there in the world (i.e. I can easily work with the > bloomberg java API), but I'm very keen to explore pharo for my graph + > tooling around that. > > (slight tangent - coming from outside the smalltalk world it'd be HUGE to > me to have git backend for packages and use of github for collaboration. > seen that mentioned in other threads. I think it'd be HUGE for community's > ability to attract more people). > > > >> Once I have completed my run at a PharoTabletIDE/ PharoMorphicView >> framework, I would love to collaborate on your endeavour to see if it can >> be modelled on it and exposed.. >> >> > Cool. Early days yet and we'll see where I end up. Not familiar with those > projects, I shall take a look. > > > Patrik > > > > >> On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg < >> patrik.sundberg(a)gmail.com> wrote: >> >>> Hi, >>> >>> First of all, sorry for the long email as my first email to the list. >>> Hopefully some people will find it an interesting discussion :) >>> >>> I'm a long time programmer that has been studying smalltalk and pharo >>> over >>> the last year. It's a beautiful language I'm liking the image style of >>> development a whole lot. I've been looking for a good test case to try >>> out >>> in pharo and I've got something in mind. I've used ruby since around 2000 >>> and given how much it has been inspired by smalltalk it's not a big leap. >>> >>> My real job is being a commodities trader but I build my own tools and >>> something I'm always working on is improved risk and pricing tools. Lots >>> of >>> that comes down to 2 things: >>> 1. evaluating a "function" (in a general sense) with inputs that are >>> picked >>> depending on time. e.g. I want to price a security and I want to pick up >>> prices for time X as inputs to the pricing model. >>> 2. calculating a derivative of the "function" above with respect to >>> inputs >>> >>> What I tend to do in order to keep things consistent by design, plus add >>> natural caching, is create a calculation graph. I define all the >>> dependencies and create an in-memory graph where each node is unique >>> using >>> an identity map. I then perform a calculation where the calculations >>> trickle >>> down the graph starting from the node I'm interested in down all it's >>> dependencies. To calculate the derivative I then find the node >>> representing >>> the input I want the derivative with respect to and use finite >>> differences, >>> e.g. move it's value, and recalculate the top level node. On the second >>> valuation of the graph only the parts that are affected by me changing >>> that >>> 1 value will need to be evaluated, the rest is cached an unaffected. It >>> makes it very easy to ask questions like "How much will I be affected by >>> X >>> changing by Y?" since I can take the top level node of the graph, search >>> for >>> X, and if found change it by Y and recalculate. >>> >>> How the graph is constructed in memory depends on time (and a few other >>> things). I always store all previous states of the world so that I can >>> recreate any calculation I did in the past. Very useful for diagnosing >>> problem. Hence if I for example change what model I use to model >>> something, >>> that change is recorded in a way such that if I set my "time" to before >>> the >>> change happened the graph will get created as it would have with the old >>> model, and for a time after the change it'll create a different graph >>> reflecting the new model. Hence the graph can only be known at runtime >>> when >>> the "time" etc is known. >>> >>> I currently have a ruby mockup of this. It's a DSL that looks like this: >>> >>> ----------- EXAMPLE >>> >>> class ExampleObject >>> include GraphEntity # includes a module with functionality for objects >>> participating in the graph, including #property and #calc used below >>> >>> property :foo do >>> 123 # this is the default value for this property which will be used >>> before a value has been set and saved >>> end >>> >>> calc :bar do |arg| >>> foo.value + arg # take the value of the arg property and add the >>> argument given to the calculation node >>> end >>> end >>> >>> o = ExampleObject.new >>> # this will kick of the graph being built in memory and setup the >>> dependency >>> between bar and foo nodes >>> o.bar(1).value # -> 124 >>> # this will be a "cache lookup" since nothing in the graph that bar >>> depends >>> on has changed (i.e. the "expensive" calculation is not performed again >>> o.bar(1).value # -> 124 >>> >>> o.foo.set_value(2) >>> o.bar(1).value # -> 125, realizes that foo changed and performs a recalc >>> -------------------------------------------------------- >>> >>> To accomplish this I use dynamic code generation like the below for >>> #property and similar for other types of nodes: >>> >>> # NOTE: it's a class level method, hence how I can call it when >>> defining the class in the example >>> >>> def property(name, time = CdrEnv.instance.time, &block) >>> clear_property(name) >>> getter_method_body = <<-EOF >>> def #{name} >>> init_block = self.class.property_init_block_for(:#{name}) >>> time_for_property = >>> self.class.property_time_dependency_for(:#{name}) >>> if init_block.nil? >>> CdrEnv.instance.get_property_node(self, :#{name}, >>> time_for_property) >>> else >>> CdrEnv.instance.get_property_node(self, :#{name}, >>> time_for_property, &init_block) >>> end >>> end >>> EOF >>> setter_method_body = <<-EOF >>> def #{name.to_s}=(value) >>> #{name.to_s}.mutate(value) >>> end >>> EOF >>> class_eval getter_method_body >>> class_eval setter_method_body >>> register_property_node(name, time, &block) >>> end >>> >>> Don't worry about the details or all the unfamiliar ruby, the main point >>> is >>> that it creates an instance method that uses the singleton >>> CdrEnv.instance >>> to either get or create the node representing the property from the graph >>> identity cache depending on if it exists or not. >>> >>> From a tooling point of view I think I'd love to work with this kind of >>> thing in pharo. Building my own browsers for inspecting and debugging my >>> dynamic graph should be very good fit. However, I'd appreciate some >>> pointers >>> to idiomatic smalltalk to attack this kind of problem in terms of >>> implementing the graph itself - I obviously want the user (even if it's >>> me) >>> to just have to focus on the domain model and hide as much as possible of >>> the graph bits under the covers the same way I've done with the code >>> generation stuff in my ruby example. >>> >>> Any input into this would be much appreciated, >>> Patrik >>> >>> P.S. >>> Btw, the persistence backend for this is the neo4j graph database, but >>> it's >>> fronted by a service slotting into my own service framework built using >>> ZeroMQ and services exchanging messages in protobuf format. One can use >>> it >>> from any language as long as one can send protobuf messages over zeromq. >>> I >>> see there's a zeromq ffi library available on SS that I'll check out, but >>> I'm not finding a protobuf implementation. It'd be easy enough for me to >>> port a ruby protobuf implementation but I may as well ask if someone has >>> already done any work on protobuf for smalltalk? >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> >

July 10, 2012

Re: [Pharo-users] Deploy a Smalltalk HTTP Server with 1 command

by Sven Van Caekenberghe

Hi Phil, Thanks for trying. Yes, sorry, I should have mentioned that. This is meant for servers, which are Linux most of the time (from my standpoint). If you have a PC with a GUI in front of you (Windows, Mac OS X, Linux) it is much easier to just download the One-Click, open the image and evaluate ZnServer startDefaultOn: 1701. Sven On 08 Jul 2012, at 22:39, phil(a)highoctane.be wrote: > Well, Ubuntu only indeed... OSX complains about cogvm not being executable > > Other than that, cool! > > Phil > > 2012/7/8 Sven Van Caekenberghe <sven(a)beta9.be> > Now updated for Pharo 2.0 - the latest and the greatest. > > Deploy a Smalltalk HTTP Server with 1 command > > $ curl http://zn.stfx.eu/zn/pharo-server.sh | bash > > Yes it is that easy. > > Read more > > http://stfx.eu/pharo-server/ > > Enjoy, > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > > > > >

July 8, 2012

Re: [Pharo-users] Deploy a Smalltalk HTTP Server with 1 command

by phil＠highoctane.be

Well, Ubuntu only indeed... OSX complains about cogvm not being executable Other than that, cool! Phil 2012/7/8 Sven Van Caekenberghe <sven(a)beta9.be> > Now updated for Pharo 2.0 - the latest and the greatest. > > Deploy a Smalltalk HTTP Server with 1 command > > $ curl http://zn.stfx.eu/zn/pharo-server.sh | bash > > Yes it is that easy. > > Read more > > http://stfx.eu/pharo-server/ > > Enjoy, > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > > >

July 8, 2012

Deploy a Smalltalk HTTP Server with 1 command

by Sven Van Caekenberghe

Now updated for Pharo 2.0 - the latest and the greatest. Deploy a Smalltalk HTTP Server with 1 command $ curl http://zn.stfx.eu/zn/pharo-server.sh | bash Yes it is that easy. Read more http://stfx.eu/pharo-server/ Enjoy, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 8, 2012

Re: [Pharo-users] Athens Flake Demo

by Igor Stasenko

I sent, but not in separate topic.. :) Thanks Marcus. (writing sitting in a nice couch at friend's place in Bern) On 7 July 2012 12:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> Hi, >> >> I don't remember if Igor send the link: >> >> https://vimeo.com/45137985 >> >> This demo is very basic, demonstrating a rendering speed of Athens using Cairo backend. >> The scene consists from very simple elements, but on its highest zoom it renders like 3^10 visible elements per frame. >> The output image having transparent background by default, but blitting it to morphic world ignores it (however it works >> when you drag it.. a bit strange ;). Perhaps i should use different blit method for transferring bitmap to display. >> >> > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

July 7, 2012

Athens Flake Demo

by Marcus Denker

> > Hi, > > I don't remember if Igor send the link: > > https://vimeo.com/45137985 > > This demo is very basic, demonstrating a rendering speed of Athens using Cairo backend. > The scene consists from very simple elements, but on its highest zoom it renders like 3^10 visible elements per frame. > The output image having transparent background by default, but blitting it to morphic world ignores it (however it works > when you drag it.. a bit strange ;). Perhaps i should use different blit method for transferring bitmap to display. > > -- Marcus Denker -- http://marcusdenker.de

July 7, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by Krishsmalltalk

There is in the PharoGoodies site, b Sudhakar krishnamachari Extn 91-40403012 Cell 9902104814 On Jul 7, 2012, at 12:39 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > I like the way you show the code. Is there a configuration for trying that out ? > > Phil > > 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> > This is a little old, I have not been able to devote the time reqd to really bring this to usable state. But I am pushing now through weekends to get it out.. > > The MorphicView: > > https://plus.google.com/photos/101656219013170129431/albums/572190789532558… > > * Trying to upgrade the wizard UI Generator, make it capable of remoting , work with DB based modelling and has a lot of other stuff of usual enterprise apps: localization, singleton/ factory creator, configuration file , logger integrated... > > Will need a more active few weeks to run these through to usable state.. > > The PharoTabletIDE: > > https://plus.google.com/photos/101656219013170129431/albums/571774973947681… > > More like a Ubuntu Unity attempt on Pharo..but that is runnable on a tiny core linux with 128 MB RAM. > > Again as above need to devote few actively concentrated weeks on this.. which has been tough to spare last few months.. > > > On Fri, Jul 6, 2012 at 5:53 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > What's that PharoTabletIDE thing? > > I am doing some work with Pharo on iOS. Is it the platform you use? > > Phil > > > 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> > You should read as much as you can about Kapital of JPMC. It does more or less what you describe for esoteric Prime Interest Derivatives and very scalably .. > > I doubt if there is much in the public domain, but the fact that Kapital is the golden standard in this product line talks highly of why Smalltalk is THE platform for this kind of product. > > It would be nice to have a Pharo based derivative product that can easily beat Ruby/ Java / .Net at this dynamic visualization using standard browsers, where Nautilus too can serve your purpose.. or a home grown tree based browser.../ Grids.. > > Once I have completed my run at a PharoTabletIDE/ PharoMorphicView framework, I would love to collaborate on your endeavour to see if it can be modelled on it and exposed.. > > > > On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg <patrik.sundberg(a)gmail.com> wrote: > Hi, > > First of all, sorry for the long email as my first email to the list. > Hopefully some people will find it an interesting discussion :) > > I'm a long time programmer that has been studying smalltalk and pharo over > the last year. It's a beautiful language I'm liking the image style of > development a whole lot. I've been looking for a good test case to try out > in pharo and I've got something in mind. I've used ruby since around 2000 > and given how much it has been inspired by smalltalk it's not a big leap. > > My real job is being a commodities trader but I build my own tools and > something I'm always working on is improved risk and pricing tools. Lots of > that comes down to 2 things: > 1. evaluating a "function" (in a general sense) with inputs that are picked > depending on time. e.g. I want to price a security and I want to pick up > prices for time X as inputs to the pricing model. > 2. calculating a derivative of the "function" above with respect to inputs > > What I tend to do in order to keep things consistent by design, plus add > natural caching, is create a calculation graph. I define all the > dependencies and create an in-memory graph where each node is unique using > an identity map. I then perform a calculation where the calculations trickle > down the graph starting from the node I'm interested in down all it's > dependencies. To calculate the derivative I then find the node representing > the input I want the derivative with respect to and use finite differences, > e.g. move it's value, and recalculate the top level node. On the second > valuation of the graph only the parts that are affected by me changing that > 1 value will need to be evaluated, the rest is cached an unaffected. It > makes it very easy to ask questions like "How much will I be affected by X > changing by Y?" since I can take the top level node of the graph, search for > X, and if found change it by Y and recalculate. > > How the graph is constructed in memory depends on time (and a few other > things). I always store all previous states of the world so that I can > recreate any calculation I did in the past. Very useful for diagnosing > problem. Hence if I for example change what model I use to model something, > that change is recorded in a way such that if I set my "time" to before the > change happened the graph will get created as it would have with the old > model, and for a time after the change it'll create a different graph > reflecting the new model. Hence the graph can only be known at runtime when > the "time" etc is known. > > I currently have a ruby mockup of this. It's a DSL that looks like this: > > ----------- EXAMPLE > > class ExampleObject > include GraphEntity # includes a module with functionality for objects > participating in the graph, including #property and #calc used below > > property :foo do > 123 # this is the default value for this property which will be used > before a value has been set and saved > end > > calc :bar do |arg| > foo.value + arg # take the value of the arg property and add the > argument given to the calculation node > end > end > > o = ExampleObject.new > # this will kick of the graph being built in memory and setup the dependency > between bar and foo nodes > o.bar(1).value # -> 124 > # this will be a "cache lookup" since nothing in the graph that bar depends > on has changed (i.e. the "expensive" calculation is not performed again > o.bar(1).value # -> 124 > > o.foo.set_value(2) > o.bar(1).value # -> 125, realizes that foo changed and performs a recalc > -------------------------------------------------------- > > To accomplish this I use dynamic code generation like the below for > #property and similar for other types of nodes: > > # NOTE: it's a class level method, hence how I can call it when > defining the class in the example > > def property(name, time = CdrEnv.instance.time, &block) > clear_property(name) > getter_method_body = <<-EOF > def #{name} > init_block = self.class.property_init_block_for(:#{name}) > time_for_property = > self.class.property_time_dependency_for(:#{name}) > if init_block.nil? > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property) > else > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property, &init_block) > end > end > EOF > setter_method_body = <<-EOF > def #{name.to_s}=(value) > #{name.to_s}.mutate(value) > end > EOF > class_eval getter_method_body > class_eval setter_method_body > register_property_node(name, time, &block) > end > > Don't worry about the details or all the unfamiliar ruby, the main point is > that it creates an instance method that uses the singleton CdrEnv.instance > to either get or create the node representing the property from the graph > identity cache depending on if it exists or not. > > From a tooling point of view I think I'd love to work with this kind of > thing in pharo. Building my own browsers for inspecting and debugging my > dynamic graph should be very good fit. However, I'd appreciate some pointers > to idiomatic smalltalk to attack this kind of problem in terms of > implementing the graph itself - I obviously want the user (even if it's me) > to just have to focus on the domain model and hide as much as possible of > the graph bits under the covers the same way I've done with the code > generation stuff in my ruby example. > > Any input into this would be much appreciated, > Patrik > > P.S. > Btw, the persistence backend for this is the neo4j graph database, but it's > fronted by a service slotting into my own service framework built using > ZeroMQ and services exchanging messages in protobuf format. One can use it > from any language as long as one can send protobuf messages over zeromq. I > see there's a zeromq ffi library available on SS that I'll check out, but > I'm not finding a protobuf implementation. It'd be easy enough for me to > port a ruby protobuf implementation but I may as well ask if someone has > already done any work on protobuf for smalltalk? > > > -- > View this message in context: http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium

July 7, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by phil＠highoctane.be

I like the way you show the code. Is there a configuration for trying that out ? Phil 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> > This is a little old, I have not been able to devote the time reqd to > really bring this to usable state. But I am pushing now through weekends to > get it out.. > > The MorphicView: > > > https://plus.google.com/photos/101656219013170129431/albums/572190789532558… > > * Trying to upgrade the wizard UI Generator, make it capable of remoting , > work with DB based modelling and has a lot of other stuff of usual > enterprise apps: localization, singleton/ factory creator, configuration > file , logger integrated... > > Will need a more active few weeks to run these through to usable state.. > > The PharoTabletIDE: > > > https://plus.google.com/photos/101656219013170129431/albums/571774973947681… > > More like a Ubuntu Unity attempt on Pharo..but that is runnable on a tiny > core linux with 128 MB RAM. > > Again as above need to devote few actively concentrated weeks on this.. > which has been tough to spare last few months.. > > > On Fri, Jul 6, 2012 at 5:53 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> What's that PharoTabletIDE thing? >> >> I am doing some work with Pharo on iOS. Is it the platform you use? >> >> Phil >> >> >> 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> >> >>> You should read as much as you can about Kapital of JPMC. It does more >>> or less what you describe for esoteric Prime Interest Derivatives and very >>> scalably .. >>> >>> I doubt if there is much in the public domain, but the fact that Kapital >>> is the golden standard in this product line talks highly of why Smalltalk >>> is THE platform for this kind of product. >>> >>> It would be nice to have a Pharo based derivative product that can >>> easily beat Ruby/ Java / .Net at this dynamic visualization using standard >>> browsers, where Nautilus too can serve your purpose.. or a home grown tree >>> based browser.../ Grids.. >>> >>> Once I have completed my run at a PharoTabletIDE/ PharoMorphicView >>> framework, I would love to collaborate on your endeavour to see if it can >>> be modelled on it and exposed.. >>> >>> >>> >>> On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg < >>> patrik.sundberg(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> First of all, sorry for the long email as my first email to the list. >>>> Hopefully some people will find it an interesting discussion :) >>>> >>>> I'm a long time programmer that has been studying smalltalk and pharo >>>> over >>>> the last year. It's a beautiful language I'm liking the image style of >>>> development a whole lot. I've been looking for a good test case to try >>>> out >>>> in pharo and I've got something in mind. I've used ruby since around >>>> 2000 >>>> and given how much it has been inspired by smalltalk it's not a big >>>> leap. >>>> >>>> My real job is being a commodities trader but I build my own tools and >>>> something I'm always working on is improved risk and pricing tools. >>>> Lots of >>>> that comes down to 2 things: >>>> 1. evaluating a "function" (in a general sense) with inputs that are >>>> picked >>>> depending on time. e.g. I want to price a security and I want to pick up >>>> prices for time X as inputs to the pricing model. >>>> 2. calculating a derivative of the "function" above with respect to >>>> inputs >>>> >>>> What I tend to do in order to keep things consistent by design, plus add >>>> natural caching, is create a calculation graph. I define all the >>>> dependencies and create an in-memory graph where each node is unique >>>> using >>>> an identity map. I then perform a calculation where the calculations >>>> trickle >>>> down the graph starting from the node I'm interested in down all it's >>>> dependencies. To calculate the derivative I then find the node >>>> representing >>>> the input I want the derivative with respect to and use finite >>>> differences, >>>> e.g. move it's value, and recalculate the top level node. On the second >>>> valuation of the graph only the parts that are affected by me changing >>>> that >>>> 1 value will need to be evaluated, the rest is cached an unaffected. It >>>> makes it very easy to ask questions like "How much will I be affected >>>> by X >>>> changing by Y?" since I can take the top level node of the graph, >>>> search for >>>> X, and if found change it by Y and recalculate. >>>> >>>> How the graph is constructed in memory depends on time (and a few other >>>> things). I always store all previous states of the world so that I can >>>> recreate any calculation I did in the past. Very useful for diagnosing >>>> problem. Hence if I for example change what model I use to model >>>> something, >>>> that change is recorded in a way such that if I set my "time" to before >>>> the >>>> change happened the graph will get created as it would have with the old >>>> model, and for a time after the change it'll create a different graph >>>> reflecting the new model. Hence the graph can only be known at runtime >>>> when >>>> the "time" etc is known. >>>> >>>> I currently have a ruby mockup of this. It's a DSL that looks like this: >>>> >>>> ----------- EXAMPLE >>>> >>>> class ExampleObject >>>> include GraphEntity # includes a module with functionality for objects >>>> participating in the graph, including #property and #calc used below >>>> >>>> property :foo do >>>> 123 # this is the default value for this property which will be used >>>> before a value has been set and saved >>>> end >>>> >>>> calc :bar do |arg| >>>> foo.value + arg # take the value of the arg property and add the >>>> argument given to the calculation node >>>> end >>>> end >>>> >>>> o = ExampleObject.new >>>> # this will kick of the graph being built in memory and setup the >>>> dependency >>>> between bar and foo nodes >>>> o.bar(1).value # -> 124 >>>> # this will be a "cache lookup" since nothing in the graph that bar >>>> depends >>>> on has changed (i.e. the "expensive" calculation is not performed again >>>> o.bar(1).value # -> 124 >>>> >>>> o.foo.set_value(2) >>>> o.bar(1).value # -> 125, realizes that foo changed and performs a >>>> recalc >>>> -------------------------------------------------------- >>>> >>>> To accomplish this I use dynamic code generation like the below for >>>> #property and similar for other types of nodes: >>>> >>>> # NOTE: it's a class level method, hence how I can call it when >>>> defining the class in the example >>>> >>>> def property(name, time = CdrEnv.instance.time, &block) >>>> clear_property(name) >>>> getter_method_body = <<-EOF >>>> def #{name} >>>> init_block = self.class.property_init_block_for(:#{name}) >>>> time_for_property = >>>> self.class.property_time_dependency_for(:#{name}) >>>> if init_block.nil? >>>> CdrEnv.instance.get_property_node(self, :#{name}, >>>> time_for_property) >>>> else >>>> CdrEnv.instance.get_property_node(self, :#{name}, >>>> time_for_property, &init_block) >>>> end >>>> end >>>> EOF >>>> setter_method_body = <<-EOF >>>> def #{name.to_s}=(value) >>>> #{name.to_s}.mutate(value) >>>> end >>>> EOF >>>> class_eval getter_method_body >>>> class_eval setter_method_body >>>> register_property_node(name, time, &block) >>>> end >>>> >>>> Don't worry about the details or all the unfamiliar ruby, the main >>>> point is >>>> that it creates an instance method that uses the singleton >>>> CdrEnv.instance >>>> to either get or create the node representing the property from the >>>> graph >>>> identity cache depending on if it exists or not. >>>> >>>> From a tooling point of view I think I'd love to work with this kind of >>>> thing in pharo. Building my own browsers for inspecting and debugging my >>>> dynamic graph should be very good fit. However, I'd appreciate some >>>> pointers >>>> to idiomatic smalltalk to attack this kind of problem in terms of >>>> implementing the graph itself - I obviously want the user (even if it's >>>> me) >>>> to just have to focus on the domain model and hide as much as possible >>>> of >>>> the graph bits under the covers the same way I've done with the code >>>> generation stuff in my ruby example. >>>> >>>> Any input into this would be much appreciated, >>>> Patrik >>>> >>>> P.S. >>>> Btw, the persistence backend for this is the neo4j graph database, but >>>> it's >>>> fronted by a service slotting into my own service framework built using >>>> ZeroMQ and services exchanging messages in protobuf format. One can use >>>> it >>>> from any language as long as one can send protobuf messages over >>>> zeromq. I >>>> see there's a zeromq ffi library available on SS that I'll check out, >>>> but >>>> I'm not finding a protobuf implementation. It'd be easy enough for me to >>>> port a ruby protobuf implementation but I may as well ask if someone has >>>> already done any work on protobuf for smalltalk? >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>> >>>> >>> >> >> >> -- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> Belgium >> > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by S Krish

This is a little old, I have not been able to devote the time reqd to really bring this to usable state. But I am pushing now through weekends to get it out.. The MorphicView: https://plus.google.com/photos/101656219013170129431/albums/572190789532558… * Trying to upgrade the wizard UI Generator, make it capable of remoting , work with DB based modelling and has a lot of other stuff of usual enterprise apps: localization, singleton/ factory creator, configuration file , logger integrated... Will need a more active few weeks to run these through to usable state.. The PharoTabletIDE: https://plus.google.com/photos/101656219013170129431/albums/571774973947681… More like a Ubuntu Unity attempt on Pharo..but that is runnable on a tiny core linux with 128 MB RAM. Again as above need to devote few actively concentrated weeks on this.. which has been tough to spare last few months.. On Fri, Jul 6, 2012 at 5:53 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > What's that PharoTabletIDE thing? > > I am doing some work with Pharo on iOS. Is it the platform you use? > > Phil > > > 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> > >> You should read as much as you can about Kapital of JPMC. It does more or >> less what you describe for esoteric Prime Interest Derivatives and very >> scalably .. >> >> I doubt if there is much in the public domain, but the fact that Kapital >> is the golden standard in this product line talks highly of why Smalltalk >> is THE platform for this kind of product. >> >> It would be nice to have a Pharo based derivative product that can easily >> beat Ruby/ Java / .Net at this dynamic visualization using standard >> browsers, where Nautilus too can serve your purpose.. or a home grown tree >> based browser.../ Grids.. >> >> Once I have completed my run at a PharoTabletIDE/ PharoMorphicView >> framework, I would love to collaborate on your endeavour to see if it can >> be modelled on it and exposed.. >> >> >> >> On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg < >> patrik.sundberg(a)gmail.com> wrote: >> >>> Hi, >>> >>> First of all, sorry for the long email as my first email to the list. >>> Hopefully some people will find it an interesting discussion :) >>> >>> I'm a long time programmer that has been studying smalltalk and pharo >>> over >>> the last year. It's a beautiful language I'm liking the image style of >>> development a whole lot. I've been looking for a good test case to try >>> out >>> in pharo and I've got something in mind. I've used ruby since around 2000 >>> and given how much it has been inspired by smalltalk it's not a big leap. >>> >>> My real job is being a commodities trader but I build my own tools and >>> something I'm always working on is improved risk and pricing tools. Lots >>> of >>> that comes down to 2 things: >>> 1. evaluating a "function" (in a general sense) with inputs that are >>> picked >>> depending on time. e.g. I want to price a security and I want to pick up >>> prices for time X as inputs to the pricing model. >>> 2. calculating a derivative of the "function" above with respect to >>> inputs >>> >>> What I tend to do in order to keep things consistent by design, plus add >>> natural caching, is create a calculation graph. I define all the >>> dependencies and create an in-memory graph where each node is unique >>> using >>> an identity map. I then perform a calculation where the calculations >>> trickle >>> down the graph starting from the node I'm interested in down all it's >>> dependencies. To calculate the derivative I then find the node >>> representing >>> the input I want the derivative with respect to and use finite >>> differences, >>> e.g. move it's value, and recalculate the top level node. On the second >>> valuation of the graph only the parts that are affected by me changing >>> that >>> 1 value will need to be evaluated, the rest is cached an unaffected. It >>> makes it very easy to ask questions like "How much will I be affected by >>> X >>> changing by Y?" since I can take the top level node of the graph, search >>> for >>> X, and if found change it by Y and recalculate. >>> >>> How the graph is constructed in memory depends on time (and a few other >>> things). I always store all previous states of the world so that I can >>> recreate any calculation I did in the past. Very useful for diagnosing >>> problem. Hence if I for example change what model I use to model >>> something, >>> that change is recorded in a way such that if I set my "time" to before >>> the >>> change happened the graph will get created as it would have with the old >>> model, and for a time after the change it'll create a different graph >>> reflecting the new model. Hence the graph can only be known at runtime >>> when >>> the "time" etc is known. >>> >>> I currently have a ruby mockup of this. It's a DSL that looks like this: >>> >>> ----------- EXAMPLE >>> >>> class ExampleObject >>> include GraphEntity # includes a module with functionality for objects >>> participating in the graph, including #property and #calc used below >>> >>> property :foo do >>> 123 # this is the default value for this property which will be used >>> before a value has been set and saved >>> end >>> >>> calc :bar do |arg| >>> foo.value + arg # take the value of the arg property and add the >>> argument given to the calculation node >>> end >>> end >>> >>> o = ExampleObject.new >>> # this will kick of the graph being built in memory and setup the >>> dependency >>> between bar and foo nodes >>> o.bar(1).value # -> 124 >>> # this will be a "cache lookup" since nothing in the graph that bar >>> depends >>> on has changed (i.e. the "expensive" calculation is not performed again >>> o.bar(1).value # -> 124 >>> >>> o.foo.set_value(2) >>> o.bar(1).value # -> 125, realizes that foo changed and performs a recalc >>> -------------------------------------------------------- >>> >>> To accomplish this I use dynamic code generation like the below for >>> #property and similar for other types of nodes: >>> >>> # NOTE: it's a class level method, hence how I can call it when >>> defining the class in the example >>> >>> def property(name, time = CdrEnv.instance.time, &block) >>> clear_property(name) >>> getter_method_body = <<-EOF >>> def #{name} >>> init_block = self.class.property_init_block_for(:#{name}) >>> time_for_property = >>> self.class.property_time_dependency_for(:#{name}) >>> if init_block.nil? >>> CdrEnv.instance.get_property_node(self, :#{name}, >>> time_for_property) >>> else >>> CdrEnv.instance.get_property_node(self, :#{name}, >>> time_for_property, &init_block) >>> end >>> end >>> EOF >>> setter_method_body = <<-EOF >>> def #{name.to_s}=(value) >>> #{name.to_s}.mutate(value) >>> end >>> EOF >>> class_eval getter_method_body >>> class_eval setter_method_body >>> register_property_node(name, time, &block) >>> end >>> >>> Don't worry about the details or all the unfamiliar ruby, the main point >>> is >>> that it creates an instance method that uses the singleton >>> CdrEnv.instance >>> to either get or create the node representing the property from the graph >>> identity cache depending on if it exists or not. >>> >>> From a tooling point of view I think I'd love to work with this kind of >>> thing in pharo. Building my own browsers for inspecting and debugging my >>> dynamic graph should be very good fit. However, I'd appreciate some >>> pointers >>> to idiomatic smalltalk to attack this kind of problem in terms of >>> implementing the graph itself - I obviously want the user (even if it's >>> me) >>> to just have to focus on the domain model and hide as much as possible of >>> the graph bits under the covers the same way I've done with the code >>> generation stuff in my ruby example. >>> >>> Any input into this would be much appreciated, >>> Patrik >>> >>> P.S. >>> Btw, the persistence backend for this is the neo4j graph database, but >>> it's >>> fronted by a service slotting into my own service framework built using >>> ZeroMQ and services exchanging messages in protobuf format. One can use >>> it >>> from any language as long as one can send protobuf messages over zeromq. >>> I >>> see there's a zeromq ffi library available on SS that I'll check out, but >>> I'm not finding a protobuf implementation. It'd be easy enough for me to >>> port a ruby protobuf implementation but I may as well ask if someone has >>> already done any work on protobuf for smalltalk? >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by phil＠highoctane.be

What's that PharoTabletIDE thing? I am doing some work with Pharo on iOS. Is it the platform you use? Phil 2012/7/6 S Krish <krishnamachari.sudhakar(a)gmail.com> > You should read as much as you can about Kapital of JPMC. It does more or > less what you describe for esoteric Prime Interest Derivatives and very > scalably .. > > I doubt if there is much in the public domain, but the fact that Kapital > is the golden standard in this product line talks highly of why Smalltalk > is THE platform for this kind of product. > > It would be nice to have a Pharo based derivative product that can easily > beat Ruby/ Java / .Net at this dynamic visualization using standard > browsers, where Nautilus too can serve your purpose.. or a home grown tree > based browser.../ Grids.. > > Once I have completed my run at a PharoTabletIDE/ PharoMorphicView > framework, I would love to collaborate on your endeavour to see if it can > be modelled on it and exposed.. > > > > On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg <patrik.sundberg(a)gmail.com > > wrote: > >> Hi, >> >> First of all, sorry for the long email as my first email to the list. >> Hopefully some people will find it an interesting discussion :) >> >> I'm a long time programmer that has been studying smalltalk and pharo over >> the last year. It's a beautiful language I'm liking the image style of >> development a whole lot. I've been looking for a good test case to try out >> in pharo and I've got something in mind. I've used ruby since around 2000 >> and given how much it has been inspired by smalltalk it's not a big leap. >> >> My real job is being a commodities trader but I build my own tools and >> something I'm always working on is improved risk and pricing tools. Lots >> of >> that comes down to 2 things: >> 1. evaluating a "function" (in a general sense) with inputs that are >> picked >> depending on time. e.g. I want to price a security and I want to pick up >> prices for time X as inputs to the pricing model. >> 2. calculating a derivative of the "function" above with respect to inputs >> >> What I tend to do in order to keep things consistent by design, plus add >> natural caching, is create a calculation graph. I define all the >> dependencies and create an in-memory graph where each node is unique using >> an identity map. I then perform a calculation where the calculations >> trickle >> down the graph starting from the node I'm interested in down all it's >> dependencies. To calculate the derivative I then find the node >> representing >> the input I want the derivative with respect to and use finite >> differences, >> e.g. move it's value, and recalculate the top level node. On the second >> valuation of the graph only the parts that are affected by me changing >> that >> 1 value will need to be evaluated, the rest is cached an unaffected. It >> makes it very easy to ask questions like "How much will I be affected by X >> changing by Y?" since I can take the top level node of the graph, search >> for >> X, and if found change it by Y and recalculate. >> >> How the graph is constructed in memory depends on time (and a few other >> things). I always store all previous states of the world so that I can >> recreate any calculation I did in the past. Very useful for diagnosing >> problem. Hence if I for example change what model I use to model >> something, >> that change is recorded in a way such that if I set my "time" to before >> the >> change happened the graph will get created as it would have with the old >> model, and for a time after the change it'll create a different graph >> reflecting the new model. Hence the graph can only be known at runtime >> when >> the "time" etc is known. >> >> I currently have a ruby mockup of this. It's a DSL that looks like this: >> >> ----------- EXAMPLE >> >> class ExampleObject >> include GraphEntity # includes a module with functionality for objects >> participating in the graph, including #property and #calc used below >> >> property :foo do >> 123 # this is the default value for this property which will be used >> before a value has been set and saved >> end >> >> calc :bar do |arg| >> foo.value + arg # take the value of the arg property and add the >> argument given to the calculation node >> end >> end >> >> o = ExampleObject.new >> # this will kick of the graph being built in memory and setup the >> dependency >> between bar and foo nodes >> o.bar(1).value # -> 124 >> # this will be a "cache lookup" since nothing in the graph that bar >> depends >> on has changed (i.e. the "expensive" calculation is not performed again >> o.bar(1).value # -> 124 >> >> o.foo.set_value(2) >> o.bar(1).value # -> 125, realizes that foo changed and performs a recalc >> -------------------------------------------------------- >> >> To accomplish this I use dynamic code generation like the below for >> #property and similar for other types of nodes: >> >> # NOTE: it's a class level method, hence how I can call it when >> defining the class in the example >> >> def property(name, time = CdrEnv.instance.time, &block) >> clear_property(name) >> getter_method_body = <<-EOF >> def #{name} >> init_block = self.class.property_init_block_for(:#{name}) >> time_for_property = >> self.class.property_time_dependency_for(:#{name}) >> if init_block.nil? >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property) >> else >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property, &init_block) >> end >> end >> EOF >> setter_method_body = <<-EOF >> def #{name.to_s}=(value) >> #{name.to_s}.mutate(value) >> end >> EOF >> class_eval getter_method_body >> class_eval setter_method_body >> register_property_node(name, time, &block) >> end >> >> Don't worry about the details or all the unfamiliar ruby, the main point >> is >> that it creates an instance method that uses the singleton CdrEnv.instance >> to either get or create the node representing the property from the graph >> identity cache depending on if it exists or not. >> >> From a tooling point of view I think I'd love to work with this kind of >> thing in pharo. Building my own browsers for inspecting and debugging my >> dynamic graph should be very good fit. However, I'd appreciate some >> pointers >> to idiomatic smalltalk to attack this kind of problem in terms of >> implementing the graph itself - I obviously want the user (even if it's >> me) >> to just have to focus on the domain model and hide as much as possible of >> the graph bits under the covers the same way I've done with the code >> generation stuff in my ruby example. >> >> Any input into this would be much appreciated, >> Patrik >> >> P.S. >> Btw, the persistence backend for this is the neo4j graph database, but >> it's >> fronted by a service slotting into my own service framework built using >> ZeroMQ and services exchanging messages in protobuf format. One can use it >> from any language as long as one can send protobuf messages over zeromq. I >> see there's a zeromq ffi library available on SS that I'll check out, but >> I'm not finding a protobuf implementation. It'd be easy enough for me to >> port a ruby protobuf implementation but I may as well ask if someone has >> already done any work on protobuf for smalltalk? >> >> >> -- >> View this message in context: >> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

July 6, 2012

Re: [Pharo-users] Nautilus Class Comments Pane

by Benjamin

That could be an interesting feature :) I already have a couple of nice things in the oven, but I will keep this in min d:) Thank you, Ben On Jul 6, 2012, at 2:13 PM, Sven Van Caekenberghe wrote: > Hi Benjamin, > > I simply love Nautilus, including many of the new features that some people complain about, like the bold class button and bold class methods, it just takes some getting used to, but it makes sense. > > I basically like the new/different class comments pane (and the settings options to choose the location). > > But I miss the big class comments pane when reading or writing long class comments (and you know how important they are). > > Would it be a good idea to expand the class pane completely when maybe double-clicking the comments button ? > > Thx, > > Sven

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by Patrik Sundberg

On Fri, Jul 6, 2012 at 12:38 PM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > You should read as much as you can about Kapital of JPMC. It does more or > less what you describe for esoteric Prime Interest Derivatives and very > scalably .. > > I've heard of that one. Never worked at JPM so haven't seen it first hand though. I'll see what I can find. In terms of concepts I'm fully on top of it (have a background with other companies using similar ideas, but not in smalltalk but their own in-house language). So the good part is that I know exactly what I want conceptually, but I'm not stuck into smalltalk enough to know the natural way to implement the concepts. It may sound like a huge endeavour but I've done a lot of it in ruby and even as a side project to my real job we're talking about a couple of months to have something useful. > I doubt if there is much in the public domain, but the fact that Kapital > is the golden standard in this product line talks highly of why Smalltalk > is THE platform for this kind of product. > > I wouldn't say it's the golden standard, that's taking it a bit far, there are others that I rate higher bit I'm also biased :) But I do agree that smalltalk is a reasonably natural platform for these types of concepts, hence why I'm exploring it. > It would be nice to have a Pharo based derivative product that can easily > beat Ruby/ Java / .Net at this dynamic visualization using standard > browsers, where Nautilus too can serve your purpose.. or a home grown tree > based browser.../ Grids.. > > That's my hunch, that the tooling work would be much cut down. In my current ruby mockup I'm kind of creating a poor man's image like experience - it's jruby on the JVM, vim + vim-slime to send code fragments to the "runtime", git, and most likely homegrown GUI to navigate the graph and play with it (not done anything on that yet). I'll be keeping jruby as a dear tool as right now it's a fantastic glue tool in terms of interacting with anything out there in the world (i.e. I can easily work with the bloomberg java API), but I'm very keen to explore pharo for my graph + tooling around that. (slight tangent - coming from outside the smalltalk world it'd be HUGE to me to have git backend for packages and use of github for collaboration. seen that mentioned in other threads. I think it'd be HUGE for community's ability to attract more people). > Once I have completed my run at a PharoTabletIDE/ PharoMorphicView > framework, I would love to collaborate on your endeavour to see if it can > be modelled on it and exposed.. > > Cool. Early days yet and we'll see where I end up. Not familiar with those projects, I shall take a look. Patrik > On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg <patrik.sundberg(a)gmail.com > > wrote: > >> Hi, >> >> First of all, sorry for the long email as my first email to the list. >> Hopefully some people will find it an interesting discussion :) >> >> I'm a long time programmer that has been studying smalltalk and pharo over >> the last year. It's a beautiful language I'm liking the image style of >> development a whole lot. I've been looking for a good test case to try out >> in pharo and I've got something in mind. I've used ruby since around 2000 >> and given how much it has been inspired by smalltalk it's not a big leap. >> >> My real job is being a commodities trader but I build my own tools and >> something I'm always working on is improved risk and pricing tools. Lots >> of >> that comes down to 2 things: >> 1. evaluating a "function" (in a general sense) with inputs that are >> picked >> depending on time. e.g. I want to price a security and I want to pick up >> prices for time X as inputs to the pricing model. >> 2. calculating a derivative of the "function" above with respect to inputs >> >> What I tend to do in order to keep things consistent by design, plus add >> natural caching, is create a calculation graph. I define all the >> dependencies and create an in-memory graph where each node is unique using >> an identity map. I then perform a calculation where the calculations >> trickle >> down the graph starting from the node I'm interested in down all it's >> dependencies. To calculate the derivative I then find the node >> representing >> the input I want the derivative with respect to and use finite >> differences, >> e.g. move it's value, and recalculate the top level node. On the second >> valuation of the graph only the parts that are affected by me changing >> that >> 1 value will need to be evaluated, the rest is cached an unaffected. It >> makes it very easy to ask questions like "How much will I be affected by X >> changing by Y?" since I can take the top level node of the graph, search >> for >> X, and if found change it by Y and recalculate. >> >> How the graph is constructed in memory depends on time (and a few other >> things). I always store all previous states of the world so that I can >> recreate any calculation I did in the past. Very useful for diagnosing >> problem. Hence if I for example change what model I use to model >> something, >> that change is recorded in a way such that if I set my "time" to before >> the >> change happened the graph will get created as it would have with the old >> model, and for a time after the change it'll create a different graph >> reflecting the new model. Hence the graph can only be known at runtime >> when >> the "time" etc is known. >> >> I currently have a ruby mockup of this. It's a DSL that looks like this: >> >> ----------- EXAMPLE >> >> class ExampleObject >> include GraphEntity # includes a module with functionality for objects >> participating in the graph, including #property and #calc used below >> >> property :foo do >> 123 # this is the default value for this property which will be used >> before a value has been set and saved >> end >> >> calc :bar do |arg| >> foo.value + arg # take the value of the arg property and add the >> argument given to the calculation node >> end >> end >> >> o = ExampleObject.new >> # this will kick of the graph being built in memory and setup the >> dependency >> between bar and foo nodes >> o.bar(1).value # -> 124 >> # this will be a "cache lookup" since nothing in the graph that bar >> depends >> on has changed (i.e. the "expensive" calculation is not performed again >> o.bar(1).value # -> 124 >> >> o.foo.set_value(2) >> o.bar(1).value # -> 125, realizes that foo changed and performs a recalc >> -------------------------------------------------------- >> >> To accomplish this I use dynamic code generation like the below for >> #property and similar for other types of nodes: >> >> # NOTE: it's a class level method, hence how I can call it when >> defining the class in the example >> >> def property(name, time = CdrEnv.instance.time, &block) >> clear_property(name) >> getter_method_body = <<-EOF >> def #{name} >> init_block = self.class.property_init_block_for(:#{name}) >> time_for_property = >> self.class.property_time_dependency_for(:#{name}) >> if init_block.nil? >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property) >> else >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property, &init_block) >> end >> end >> EOF >> setter_method_body = <<-EOF >> def #{name.to_s}=(value) >> #{name.to_s}.mutate(value) >> end >> EOF >> class_eval getter_method_body >> class_eval setter_method_body >> register_property_node(name, time, &block) >> end >> >> Don't worry about the details or all the unfamiliar ruby, the main point >> is >> that it creates an instance method that uses the singleton CdrEnv.instance >> to either get or create the node representing the property from the graph >> identity cache depending on if it exists or not. >> >> From a tooling point of view I think I'd love to work with this kind of >> thing in pharo. Building my own browsers for inspecting and debugging my >> dynamic graph should be very good fit. However, I'd appreciate some >> pointers >> to idiomatic smalltalk to attack this kind of problem in terms of >> implementing the graph itself - I obviously want the user (even if it's >> me) >> to just have to focus on the domain model and hide as much as possible of >> the graph bits under the covers the same way I've done with the code >> generation stuff in my ruby example. >> >> Any input into this would be much appreciated, >> Patrik >> >> P.S. >> Btw, the persistence backend for this is the neo4j graph database, but >> it's >> fronted by a service slotting into my own service framework built using >> ZeroMQ and services exchanging messages in protobuf format. One can use it >> from any language as long as one can send protobuf messages over zeromq. I >> see there's a zeromq ffi library available on SS that I'll check out, but >> I'm not finding a protobuf implementation. It'd be easy enough for me to >> port a ruby protobuf implementation but I may as well ask if someone has >> already done any work on protobuf for smalltalk? >> >> >> -- >> View this message in context: >> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >

July 6, 2012

Nautilus Class Comments Pane

by Sven Van Caekenberghe

Hi Benjamin, I simply love Nautilus, including many of the new features that some people complain about, like the bold class button and bold class methods, it just takes some getting used to, but it makes sense. I basically like the new/different class comments pane (and the settings options to choose the location). But I miss the big class comments pane when reading or writing long class comments (and you know how important they are). Would it be a good idea to expand the class pane completely when maybe double-clicking the comments button ? Thx, Sven

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by S Krish

You should read as much as you can about Kapital of JPMC. It does more or less what you describe for esoteric Prime Interest Derivatives and very scalably .. I doubt if there is much in the public domain, but the fact that Kapital is the golden standard in this product line talks highly of why Smalltalk is THE platform for this kind of product. It would be nice to have a Pharo based derivative product that can easily beat Ruby/ Java / .Net at this dynamic visualization using standard browsers, where Nautilus too can serve your purpose.. or a home grown tree based browser.../ Grids.. Once I have completed my run at a PharoTabletIDE/ PharoMorphicView framework, I would love to collaborate on your endeavour to see if it can be modelled on it and exposed.. On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg <patrik.sundberg(a)gmail.com>wrote: > Hi, > > First of all, sorry for the long email as my first email to the list. > Hopefully some people will find it an interesting discussion :) > > I'm a long time programmer that has been studying smalltalk and pharo over > the last year. It's a beautiful language I'm liking the image style of > development a whole lot. I've been looking for a good test case to try out > in pharo and I've got something in mind. I've used ruby since around 2000 > and given how much it has been inspired by smalltalk it's not a big leap. > > My real job is being a commodities trader but I build my own tools and > something I'm always working on is improved risk and pricing tools. Lots of > that comes down to 2 things: > 1. evaluating a "function" (in a general sense) with inputs that are picked > depending on time. e.g. I want to price a security and I want to pick up > prices for time X as inputs to the pricing model. > 2. calculating a derivative of the "function" above with respect to inputs > > What I tend to do in order to keep things consistent by design, plus add > natural caching, is create a calculation graph. I define all the > dependencies and create an in-memory graph where each node is unique using > an identity map. I then perform a calculation where the calculations > trickle > down the graph starting from the node I'm interested in down all it's > dependencies. To calculate the derivative I then find the node representing > the input I want the derivative with respect to and use finite differences, > e.g. move it's value, and recalculate the top level node. On the second > valuation of the graph only the parts that are affected by me changing that > 1 value will need to be evaluated, the rest is cached an unaffected. It > makes it very easy to ask questions like "How much will I be affected by X > changing by Y?" since I can take the top level node of the graph, search > for > X, and if found change it by Y and recalculate. > > How the graph is constructed in memory depends on time (and a few other > things). I always store all previous states of the world so that I can > recreate any calculation I did in the past. Very useful for diagnosing > problem. Hence if I for example change what model I use to model something, > that change is recorded in a way such that if I set my "time" to before the > change happened the graph will get created as it would have with the old > model, and for a time after the change it'll create a different graph > reflecting the new model. Hence the graph can only be known at runtime when > the "time" etc is known. > > I currently have a ruby mockup of this. It's a DSL that looks like this: > > ----------- EXAMPLE > > class ExampleObject > include GraphEntity # includes a module with functionality for objects > participating in the graph, including #property and #calc used below > > property :foo do > 123 # this is the default value for this property which will be used > before a value has been set and saved > end > > calc :bar do |arg| > foo.value + arg # take the value of the arg property and add the > argument given to the calculation node > end > end > > o = ExampleObject.new > # this will kick of the graph being built in memory and setup the > dependency > between bar and foo nodes > o.bar(1).value # -> 124 > # this will be a "cache lookup" since nothing in the graph that bar depends > on has changed (i.e. the "expensive" calculation is not performed again > o.bar(1).value # -> 124 > > o.foo.set_value(2) > o.bar(1).value # -> 125, realizes that foo changed and performs a recalc > -------------------------------------------------------- > > To accomplish this I use dynamic code generation like the below for > #property and similar for other types of nodes: > > # NOTE: it's a class level method, hence how I can call it when > defining the class in the example > > def property(name, time = CdrEnv.instance.time, &block) > clear_property(name) > getter_method_body = <<-EOF > def #{name} > init_block = self.class.property_init_block_for(:#{name}) > time_for_property = > self.class.property_time_dependency_for(:#{name}) > if init_block.nil? > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property) > else > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property, &init_block) > end > end > EOF > setter_method_body = <<-EOF > def #{name.to_s}=(value) > #{name.to_s}.mutate(value) > end > EOF > class_eval getter_method_body > class_eval setter_method_body > register_property_node(name, time, &block) > end > > Don't worry about the details or all the unfamiliar ruby, the main point is > that it creates an instance method that uses the singleton CdrEnv.instance > to either get or create the node representing the property from the graph > identity cache depending on if it exists or not. > > From a tooling point of view I think I'd love to work with this kind of > thing in pharo. Building my own browsers for inspecting and debugging my > dynamic graph should be very good fit. However, I'd appreciate some > pointers > to idiomatic smalltalk to attack this kind of problem in terms of > implementing the graph itself - I obviously want the user (even if it's me) > to just have to focus on the domain model and hide as much as possible of > the graph bits under the covers the same way I've done with the code > generation stuff in my ruby example. > > Any input into this would be much appreciated, > Patrik > > P.S. > Btw, the persistence backend for this is the neo4j graph database, but it's > fronted by a service slotting into my own service framework built using > ZeroMQ and services exchanging messages in protobuf format. One can use it > from any language as long as one can send protobuf messages over zeromq. I > see there's a zeromq ffi library available on SS that I'll check out, but > I'm not finding a protobuf implementation. It'd be easy enough for me to > port a ruby protobuf implementation but I may as well ask if someone has > already done any work on protobuf for smalltalk? > > > -- > View this message in context: > http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by Patrik Sundberg

On Fri, Jul 6, 2012 at 12:10 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Hi Patrik, > > Don't know about all of your specifics but reading through made me think > of: > > 1) Fuel, which has to do with graphs of course (persistence) > > Did you mean to look at code for ideas of working with graphs or actual persistence? Actual persistence I've thought long and hard about and considered every type of DB etc out there (incl Magma and GemStone and every NoSQL out there). A domain specific persistence API with a neo4j backend has tunred out to be the best fit so far. > 2) Moose, which does all kind of fancy things with graphs and > visualizations (check Mondrian Easel and the new Roassal based things) > > Yep, visualization wise I've already made a note of Mondrian. > 3) Teachable > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038279.ht… > > Example: | teachable | > teachable := self new. > teachable > whenSend: #help return: 'ok'; > whenSend: #doit evaluate: [1 inspect]; > acceptSend: #noDebugger; > whenSend: #negate: evaluate: [:num | num negated]. > teachable help. > teachable doit. > teachable noDebugger. > teachable negate: 120 > > Teachable may be interesting for adding some stuff dynamically for your > models. > > Ah, I shall definitely have a look at this one! > For the record, I am interested in gold and silver futures in my spare > time. > > Cool - I've traded most of the commods except base metals. Precious metals is a weird world :) Thanks a lot for the pointers! Patrik > > 2012/7/6 Patrik Sundberg <patrik.sundberg(a)gmail.com> > >> Hi, >> >> First of all, sorry for the long email as my first email to the list. >> Hopefully some people will find it an interesting discussion :) >> >> I'm a long time programmer that has been studying smalltalk and pharo over >> the last year. It's a beautiful language I'm liking the image style of >> development a whole lot. I've been looking for a good test case to try out >> in pharo and I've got something in mind. I've used ruby since around 2000 >> and given how much it has been inspired by smalltalk it's not a big leap. >> >> My real job is being a commodities trader but I build my own tools and >> something I'm always working on is improved risk and pricing tools. Lots >> of >> that comes down to 2 things: >> 1. evaluating a "function" (in a general sense) with inputs that are >> picked >> depending on time. e.g. I want to price a security and I want to pick up >> prices for time X as inputs to the pricing model. >> 2. calculating a derivative of the "function" above with respect to inputs >> >> What I tend to do in order to keep things consistent by design, plus add >> natural caching, is create a calculation graph. I define all the >> dependencies and create an in-memory graph where each node is unique using >> an identity map. I then perform a calculation where the calculations >> trickle >> down the graph starting from the node I'm interested in down all it's >> dependencies. To calculate the derivative I then find the node >> representing >> the input I want the derivative with respect to and use finite >> differences, >> e.g. move it's value, and recalculate the top level node. On the second >> valuation of the graph only the parts that are affected by me changing >> that >> 1 value will need to be evaluated, the rest is cached an unaffected. It >> makes it very easy to ask questions like "How much will I be affected by X >> changing by Y?" since I can take the top level node of the graph, search >> for >> X, and if found change it by Y and recalculate. >> >> How the graph is constructed in memory depends on time (and a few other >> things). I always store all previous states of the world so that I can >> recreate any calculation I did in the past. Very useful for diagnosing >> problem. Hence if I for example change what model I use to model >> something, >> that change is recorded in a way such that if I set my "time" to before >> the >> change happened the graph will get created as it would have with the old >> model, and for a time after the change it'll create a different graph >> reflecting the new model. Hence the graph can only be known at runtime >> when >> the "time" etc is known. >> >> I currently have a ruby mockup of this. It's a DSL that looks like this: >> >> ----------- EXAMPLE >> >> class ExampleObject >> include GraphEntity # includes a module with functionality for objects >> participating in the graph, including #property and #calc used below >> >> property :foo do >> 123 # this is the default value for this property which will be used >> before a value has been set and saved >> end >> >> calc :bar do |arg| >> foo.value + arg # take the value of the arg property and add the >> argument given to the calculation node >> end >> end >> >> o = ExampleObject.new >> # this will kick of the graph being built in memory and setup the >> dependency >> between bar and foo nodes >> o.bar(1).value # -> 124 >> # this will be a "cache lookup" since nothing in the graph that bar >> depends >> on has changed (i.e. the "expensive" calculation is not performed again >> o.bar(1).value # -> 124 >> >> o.foo.set_value(2) >> o.bar(1).value # -> 125, realizes that foo changed and performs a recalc >> -------------------------------------------------------- >> >> To accomplish this I use dynamic code generation like the below for >> #property and similar for other types of nodes: >> >> # NOTE: it's a class level method, hence how I can call it when >> defining the class in the example >> >> def property(name, time = CdrEnv.instance.time, &block) >> clear_property(name) >> getter_method_body = <<-EOF >> def #{name} >> init_block = self.class.property_init_block_for(:#{name}) >> time_for_property = >> self.class.property_time_dependency_for(:#{name}) >> if init_block.nil? >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property) >> else >> CdrEnv.instance.get_property_node(self, :#{name}, >> time_for_property, &init_block) >> end >> end >> EOF >> setter_method_body = <<-EOF >> def #{name.to_s}=(value) >> #{name.to_s}.mutate(value) >> end >> EOF >> class_eval getter_method_body >> class_eval setter_method_body >> register_property_node(name, time, &block) >> end >> >> Don't worry about the details or all the unfamiliar ruby, the main point >> is >> that it creates an instance method that uses the singleton CdrEnv.instance >> to either get or create the node representing the property from the graph >> identity cache depending on if it exists or not. >> >> From a tooling point of view I think I'd love to work with this kind of >> thing in pharo. Building my own browsers for inspecting and debugging my >> dynamic graph should be very good fit. However, I'd appreciate some >> pointers >> to idiomatic smalltalk to attack this kind of problem in terms of >> implementing the graph itself - I obviously want the user (even if it's >> me) >> to just have to focus on the domain model and hide as much as possible of >> the graph bits under the covers the same way I've done with the code >> generation stuff in my ruby example. >> >> Any input into this would be much appreciated, >> Patrik >> >> P.S. >> Btw, the persistence backend for this is the neo4j graph database, but >> it's >> fronted by a service slotting into my own service framework built using >> ZeroMQ and services exchanging messages in protobuf format. One can use it >> from any language as long as one can send protobuf messages over zeromq. I >> see there's a zeromq ffi library available on SS that I'll check out, but >> I'm not finding a protobuf implementation. It'd be easy enough for me to >> port a ruby protobuf implementation but I may as well ask if someone has >> already done any work on protobuf for smalltalk? >> >> >> -- >> View this message in context: >> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

July 6, 2012

Re: [Pharo-users] Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by phil＠highoctane.be

Hi Patrik, Don't know about all of your specifics but reading through made me think of: 1) Fuel, which has to do with graphs of course (persistence) 2) Moose, which does all kind of fancy things with graphs and visualizations (check Mondrian Easel and the new Roassal based things) 3) Teachable http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038279.ht… Example: | teachable | teachable := self new. teachable whenSend: #help return: 'ok'; whenSend: #doit evaluate: [1 inspect]; acceptSend: #noDebugger; whenSend: #negate: evaluate: [:num | num negated]. teachable help. teachable doit. teachable noDebugger. teachable negate: 120 Teachable may be interesting for adding some stuff dynamically for your models. For the record, I am interested in gold and silver futures in my spare time. Philippe 2012/7/6 Patrik Sundberg <patrik.sundberg(a)gmail.com> > Hi, > > First of all, sorry for the long email as my first email to the list. > Hopefully some people will find it an interesting discussion :) > > I'm a long time programmer that has been studying smalltalk and pharo over > the last year. It's a beautiful language I'm liking the image style of > development a whole lot. I've been looking for a good test case to try out > in pharo and I've got something in mind. I've used ruby since around 2000 > and given how much it has been inspired by smalltalk it's not a big leap. > > My real job is being a commodities trader but I build my own tools and > something I'm always working on is improved risk and pricing tools. Lots of > that comes down to 2 things: > 1. evaluating a "function" (in a general sense) with inputs that are picked > depending on time. e.g. I want to price a security and I want to pick up > prices for time X as inputs to the pricing model. > 2. calculating a derivative of the "function" above with respect to inputs > > What I tend to do in order to keep things consistent by design, plus add > natural caching, is create a calculation graph. I define all the > dependencies and create an in-memory graph where each node is unique using > an identity map. I then perform a calculation where the calculations > trickle > down the graph starting from the node I'm interested in down all it's > dependencies. To calculate the derivative I then find the node representing > the input I want the derivative with respect to and use finite differences, > e.g. move it's value, and recalculate the top level node. On the second > valuation of the graph only the parts that are affected by me changing that > 1 value will need to be evaluated, the rest is cached an unaffected. It > makes it very easy to ask questions like "How much will I be affected by X > changing by Y?" since I can take the top level node of the graph, search > for > X, and if found change it by Y and recalculate. > > How the graph is constructed in memory depends on time (and a few other > things). I always store all previous states of the world so that I can > recreate any calculation I did in the past. Very useful for diagnosing > problem. Hence if I for example change what model I use to model something, > that change is recorded in a way such that if I set my "time" to before the > change happened the graph will get created as it would have with the old > model, and for a time after the change it'll create a different graph > reflecting the new model. Hence the graph can only be known at runtime when > the "time" etc is known. > > I currently have a ruby mockup of this. It's a DSL that looks like this: > > ----------- EXAMPLE > > class ExampleObject > include GraphEntity # includes a module with functionality for objects > participating in the graph, including #property and #calc used below > > property :foo do > 123 # this is the default value for this property which will be used > before a value has been set and saved > end > > calc :bar do |arg| > foo.value + arg # take the value of the arg property and add the > argument given to the calculation node > end > end > > o = ExampleObject.new > # this will kick of the graph being built in memory and setup the > dependency > between bar and foo nodes > o.bar(1).value # -> 124 > # this will be a "cache lookup" since nothing in the graph that bar depends > on has changed (i.e. the "expensive" calculation is not performed again > o.bar(1).value # -> 124 > > o.foo.set_value(2) > o.bar(1).value # -> 125, realizes that foo changed and performs a recalc > -------------------------------------------------------- > > To accomplish this I use dynamic code generation like the below for > #property and similar for other types of nodes: > > # NOTE: it's a class level method, hence how I can call it when > defining the class in the example > > def property(name, time = CdrEnv.instance.time, &block) > clear_property(name) > getter_method_body = <<-EOF > def #{name} > init_block = self.class.property_init_block_for(:#{name}) > time_for_property = > self.class.property_time_dependency_for(:#{name}) > if init_block.nil? > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property) > else > CdrEnv.instance.get_property_node(self, :#{name}, > time_for_property, &init_block) > end > end > EOF > setter_method_body = <<-EOF > def #{name.to_s}=(value) > #{name.to_s}.mutate(value) > end > EOF > class_eval getter_method_body > class_eval setter_method_body > register_property_node(name, time, &block) > end > > Don't worry about the details or all the unfamiliar ruby, the main point is > that it creates an instance method that uses the singleton CdrEnv.instance > to either get or create the node representing the property from the graph > identity cache depending on if it exists or not. > > From a tooling point of view I think I'd love to work with this kind of > thing in pharo. Building my own browsers for inspecting and debugging my > dynamic graph should be very good fit. However, I'd appreciate some > pointers > to idiomatic smalltalk to attack this kind of problem in terms of > implementing the graph itself - I obviously want the user (even if it's me) > to just have to focus on the domain model and hide as much as possible of > the graph bits under the covers the same way I've done with the code > generation stuff in my ruby example. > > Any input into this would be much appreciated, > Patrik > > P.S. > Btw, the persistence backend for this is the neo4j graph database, but it's > fronted by a service slotting into my own service framework built using > ZeroMQ and services exchanging messages in protobuf format. One can use it > from any language as long as one can send protobuf messages over zeromq. I > see there's a zeromq ffi library available on SS that I'll check out, but > I'm not finding a protobuf implementation. It'd be easy enough for me to > port a ruby protobuf implementation but I may as well ask if someone has > already done any work on protobuf for smalltalk? > > > -- > View this message in context: > http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

July 6, 2012

Dynamic graph exploration - seeking input on idiomatic smalltalk [LONG]

by Patrik Sundberg

Hi, First of all, sorry for the long email as my first email to the list. Hopefully some people will find it an interesting discussion :) I'm a long time programmer that has been studying smalltalk and pharo over the last year. It's a beautiful language I'm liking the image style of development a whole lot. I've been looking for a good test case to try out in pharo and I've got something in mind. I've used ruby since around 2000 and given how much it has been inspired by smalltalk it's not a big leap. My real job is being a commodities trader but I build my own tools and something I'm always working on is improved risk and pricing tools. Lots of that comes down to 2 things: 1. evaluating a "function" (in a general sense) with inputs that are picked depending on time. e.g. I want to price a security and I want to pick up prices for time X as inputs to the pricing model. 2. calculating a derivative of the "function" above with respect to inputs What I tend to do in order to keep things consistent by design, plus add natural caching, is create a calculation graph. I define all the dependencies and create an in-memory graph where each node is unique using an identity map. I then perform a calculation where the calculations trickle down the graph starting from the node I'm interested in down all it's dependencies. To calculate the derivative I then find the node representing the input I want the derivative with respect to and use finite differences, e.g. move it's value, and recalculate the top level node. On the second valuation of the graph only the parts that are affected by me changing that 1 value will need to be evaluated, the rest is cached an unaffected. It makes it very easy to ask questions like "How much will I be affected by X changing by Y?" since I can take the top level node of the graph, search for X, and if found change it by Y and recalculate. How the graph is constructed in memory depends on time (and a few other things). I always store all previous states of the world so that I can recreate any calculation I did in the past. Very useful for diagnosing problem. Hence if I for example change what model I use to model something, that change is recorded in a way such that if I set my "time" to before the change happened the graph will get created as it would have with the old model, and for a time after the change it'll create a different graph reflecting the new model. Hence the graph can only be known at runtime when the "time" etc is known. I currently have a ruby mockup of this. It's a DSL that looks like this: ----------- EXAMPLE class ExampleObject include GraphEntity # includes a module with functionality for objects participating in the graph, including #property and #calc used below property :foo do 123 # this is the default value for this property which will be used before a value has been set and saved end calc :bar do |arg| foo.value + arg # take the value of the arg property and add the argument given to the calculation node end end o = ExampleObject.new # this will kick of the graph being built in memory and setup the dependency between bar and foo nodes o.bar(1).value # -> 124 # this will be a "cache lookup" since nothing in the graph that bar depends on has changed (i.e. the "expensive" calculation is not performed again o.bar(1).value # -> 124 o.foo.set_value(2) o.bar(1).value # -> 125, realizes that foo changed and performs a recalc -------------------------------------------------------- To accomplish this I use dynamic code generation like the below for #property and similar for other types of nodes: # NOTE: it's a class level method, hence how I can call it when defining the class in the example def property(name, time = CdrEnv.instance.time, &block) clear_property(name) getter_method_body = <<-EOF def #{name} init_block = self.class.property_init_block_for(:#{name}) time_for_property = self.class.property_time_dependency_for(:#{name}) if init_block.nil? CdrEnv.instance.get_property_node(self, :#{name}, time_for_property) else CdrEnv.instance.get_property_node(self, :#{name}, time_for_property, &init_block) end end EOF setter_method_body = <<-EOF def #{name.to_s}=(value) #{name.to_s}.mutate(value) end EOF class_eval getter_method_body class_eval setter_method_body register_property_node(name, time, &block) end Don't worry about the details or all the unfamiliar ruby, the main point is that it creates an instance method that uses the singleton CdrEnv.instance to either get or create the node representing the property from the graph identity cache depending on if it exists or not. >From a tooling point of view I think I'd love to work with this kind of thing in pharo. Building my own browsers for inspecting and debugging my dynamic graph should be very good fit. However, I'd appreciate some pointers to idiomatic smalltalk to attack this kind of problem in terms of implementing the graph itself - I obviously want the user (even if it's me) to just have to focus on the domain model and hide as much as possible of the graph bits under the covers the same way I've done with the code generation stuff in my ruby example. Any input into this would be much appreciated, Patrik P.S. Btw, the persistence backend for this is the neo4j graph database, but it's fronted by a service slotting into my own service framework built using ZeroMQ and services exchanging messages in protobuf format. One can use it from any language as long as one can send protobuf messages over zeromq. I see there's a zeromq ffi library available on SS that I'll check out, but I'm not finding a protobuf implementation. It'd be easy enough for me to port a ruby protobuf implementation but I may as well ask if someone has already done any work on protobuf for smalltalk? -- View this message in context: http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 6, 2012

update on the consortium poll

by StÃ©phane Ducasse

Hi pharoers Here is so far the state of replies I compiled. If I miss you or misclassified tell me. By end of July I will build a case to ask for INRIA support. So I will refresh this list and group mails to build a convincing case. Pharo2.0 is going in the right direction. With a mini core, vector graphics, ssh, it is starting to be a nice platform for new challenges. Thanks you all for your trust. Stef So far 4000 gold 8000 silver 5000 bronze 500 sponsor 2500 individual plus 480 individual -------------------- 20480 Euros Gold (4000) RMOD 4000 Silver (2000) 2Denker http://www.Synectique.eu Sanders Cameron company 2Rivers 8000 Bronze (1000) Andy bunnett company Eggermont company MAD-Environment www.FinWorks.biz netStyle.ch 5000 Sponsors (500) Caeasar Systems (May be IMUS)?? 500 Indivudual golden (100) Stephane Ducasse Marcus Denker Schmiedl Miguel Coba Alexandre Bergel Krish Brodbeck (may be bronze) Goran Vasic Guillermo Polito Norbert Harlt Mark Smith Lorenzo schiavina Daniel Galdames Leandro Caniglia Francois Stephany Sean De Nigris John O'Keefe Tudor Girba Luc Fabresse Florent Arrignon Lawrence Trutter Sabine Knofel Yann Monclair Henrik Johanssen Hernan Wilkinson (or bronze to be defined) 2500 Normal 40 Bill schwab Herve verjus Damien cassou McLeod Max Leske Phil Back (bronze may be) Yanni Chiu Andrea BrÃ¼hlmann Stefan Reichhart Niklaus Lutz Max Leske Simon Jakovina 480

July 5, 2012

Re: [Pharo-users] PluggableMultiColumnListMorph broken?

by Benjamin

We have introduced a dispatch in the list, allowing every kinds of object to be displayed if the provide the good interface. Right now, this interface is provided by String, Text, and Morph. On the other hand, the PluggableMultiColumnListMorph is designed to take "real" object as entry, and then the wrapping method is used to specify how to split the object into multiple columns. And by default, the wrappingMethod returns the printString of the object. So in your case, the elements (which are collections) are turned into a String like '#('a' 'b' c')', and when the list iterates over the object, it iterates on characters. Maybe the default behavior should be changed, because if you do not precise, it will hangs. To fix your example, you can do PluggableMultiColumnListMorph on: self list: #actorMultiList selected: nil changeSelected: nil menu: nil keystroke: nil wrapSelector: #wrap: wrap: item ^ item Note that the result will be a b c d 1 2 3 4 alpha 20 beta gamma The list provides rows, not columns anymore Ben On Jul 3, 2012, at 5:50 AM, Jeff Gray wrote: > Is PluggableMultiColumnListMorph broken in 1.4? > > If I have a very simple case within a polymorph window: > > PluggableMultiColumnListMorph on: self list: #actorMultiList selected: nil > changeSelected: nil menu: nil keystroke: nil wrapSelector: nil > > and the actorMultiList method is: > ^ #(('a' 'b' 'c' 'd') ('1' '2' '3' '4') ('alpha' '20' 'beta' 'gamma')) > > then I get the following error: Character(Object) doesNotUnderstand: > #widthToDisplayInList: > > > > -- > View this message in context: http://forum.world.st/PluggableMultiColumnListMorph-broken-tp4637828.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 3, 2012

PluggableMultiColumnListMorph broken?

by Jeff Gray

Is PluggableMultiColumnListMorph broken in 1.4? If I have a very simple case within a polymorph window: PluggableMultiColumnListMorph on: self list: #actorMultiList selected: nil changeSelected: nil menu: nil keystroke: nil wrapSelector: nil and the actorMultiList method is: ^ #(('a' 'b' 'c' 'd') ('1' '2' '3' '4') ('alpha' '20' 'beta' 'gamma')) then I get the following error: Character(Object) doesNotUnderstand: #widthToDisplayInList: -- View this message in context: http://forum.world.st/PluggableMultiColumnListMorph-broken-tp4637828.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 3, 2012

Re: [Pharo-users] Problem with the installation of Magritte

by Olivier Auverlot

okâ¦ Thanks Olivier Le 2 juil. 2012 Ã 12:03, Esteban Lorenzano a Ã©crit : > yes, because Lukas site is down > > On Jul 2, 2012, at 11:23 AM, Olivier Auverlot wrote: > >> Hi, >> >> I'm trying to install Magritte in a image of Pharo 1.4 with Nautilus and Seaside. I'm using the following commands : >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfMagritte2'; >> load. >> >> ((Smalltalk at: #ConfigurationOfMagritte2 ) project latestVersion) load >> >> But this fails with the error : "Could not resolve: Magritte-Model" >> >> Any idea ? >> >> Best regards >> Olivier :) > >

July 2, 2012