I like the way you show the code. Is there a configuration for trying that out ?
Phil 2012/7/6 S Krish <[email protected]> > 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/5721907895325589393?banner=pwa > > * 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/5717749739476813505?banner=pwa > > 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, [email protected] <[email protected]>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 <[email protected]> >> >>> 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 < >>> [email protected]> 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-smalltalk-LONG-tp4638702.html >>>> 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: >> [email protected] | 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: [email protected]| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
