Comments on: An extensible FARG implementation, Part II http://farg.wordpress.com/2008/02/28/an-extensible-farg-implementation-part-ii/ Musings from the Fluid Analogies Research Group Thu, 16 Apr 2009 15:43:23 +0000 http://wordpress.com/ hourly 1 By: On massively parallel coderacks « FARG Blog http://farg.wordpress.com/2008/02/28/an-extensible-farg-implementation-part-ii/#comment-31 On massively parallel coderacks « FARG Blog Tue, 11 Mar 2008 06:37:27 +0000 http://farg.wordpress.com/2008/02/28/an-extensible-farg-implementation-part-ii/#comment-31 [...] Though I’m not coding this right now, I think my sketched solution might even help the stale codelet problem Abhijit mentioned: We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may [...] [...] Though I’m not coding this right now, I think my sketched solution might even help the stale codelet problem Abhijit mentioned: We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may [...]

]]> By: Eric N. http://farg.wordpress.com/2008/02/28/an-extensible-farg-implementation-part-ii/#comment-18 Eric N. Thu, 28 Feb 2008 18:14:03 +0000 http://farg.wordpress.com/2008/02/28/an-extensible-farg-implementation-part-ii/#comment-18 Thanks for these two posts. A few responses: I like what you said about generative the images from your log files. My default plan is to write similar log files as XML, because many languages give you reading and writing from XML for free -- I can generate the log files with almost zero code. The structure of XML should make it easy to write language-independent tools for analyzing the data. I put in placeholders in my domain-independent library for the two graphs you show above as soon as I saw them running in your program. They seem quite useful. For writing new codelets, I'm trying a combination of using a Workspace and Slipnet API that is easy to call from a new codelet, as well as a set of custom attributes (the .NET language construct) that I can attach to the Codelet subclass definition or particular methods like Run. These custom attributes, along with deriving from the base Codelet class, should make my coding analogous to what you've done, in terms of reducing repetitive code, etc. But that's not done yet so I'm not sure how it'll look in the end. I like the script idea too, and I'm thinking about how to incorporate that at a later date. Probably I'll end up using some "design patterns" idea, but I'll have to understand your scripts more fully first. Thanks for these two posts. A few responses: I like what you said about generative the images from your log files. My default plan is to write similar log files as XML, because many languages give you reading and writing from XML for free — I can generate the log files with almost zero code. The structure of XML should make it easy to write language-independent tools for analyzing the data.

I put in placeholders in my domain-independent library for the two graphs you show above as soon as I saw them running in your program. They seem quite useful.

For writing new codelets, I’m trying a combination of using a Workspace and Slipnet API that is easy to call from a new codelet, as well as a set of custom attributes (the .NET language construct) that I can attach to the Codelet subclass definition or particular methods like Run. These custom attributes, along with deriving from the base Codelet class, should make my coding analogous to what you’ve done, in terms of reducing repetitive code, etc. But that’s not done yet so I’m not sure how it’ll look in the end.

I like the script idea too, and I’m thinking about how to incorporate that at a later date. Probably I’ll end up using some “design patterns” idea, but I’ll have to understand your scripts more fully first.

]]>