Sent from my iPhone at last the handheld that works!
On 17 Sep 2009, at 22:30, Michael Sparks <[email protected]> wrote:
>
> Hi Erisian,
>
>
> Let me just say that I think this is awesome,
++1
I've been mulling over the feasability of an objective-c
implementation on and off lately following on from your work it should
be emminently do-able. Thanks again.
> and I'm very glad to hear that
> Kamaelia's been helpful to you here.
>
> I've always viewed the current implementation of Kamaelia/Axon to be
> just
> that - an implementation of the ideas, with the idea of remainable
> tractable
> & applicable in other languages, so I think this is really awesome :)
>
> On Wednesday 16 September 2009 00:26:48 erisian wrote:
>> Michael and friends...
>>
>> I've been a fan of Kamaelia for a couple years now and when I needed
>> to come up with a componentized, flow-based development environment I
>> modeled it after Axon for two reasons:
>>
>> 1. The excellent level of tutorial documentation
>> 2. The straightforward architectural approach used by Axon.
>>
>> I actually just followed the "write your own axon" tutorial and
>> implemented it in D. Of course, implementing an axon-like subsystem
>> in a statically typed language was, well, challenging.
>
> I can understand that! There's a deliberately very naive C++
> implementation in
> the repository here...
>
> http://tinyurl.com/n3gsnz
>
> ... so I can understand the challenges involved in doing something
> more
> useful :-) (incidentally this was also written based on following the
> mini-axon tutorial :-)
>
>> I now have MicroProcess, MicroScheduler, Inbox, Outbox and Component
>> working. It's pretty simple right now, but I've run a basic test
>> that
>> creates three components (an even integer producer, an odd integer
>> producer and an integer printer consumer), links them up and cycles
>> the scheduler through about 1000 yield events.
>>
>> It works like a charm and it's incredibly fast.
>
> That's really cool to here.
>
>> This was all done using free tools (SciTE editor, llvm ldc d
>> compiler,
>> D language and the Tango Foundation Class Library).
>
> I've not used/written any D nor really aware of it's language specific
> foibles, but I *am* aware of what LLVM is, so I suspect that this
> could
> actually really fly.
>
>> Yields in D are implemented using the Tango "Fiber" class. I believe
>> the assembler created generates setjmp/longjmps.
>
> That would make sense. As you may see from the C++ version I've
> hacked up
> before this essentially uses a class attribute to control syntactic
> sugar for
> a switch statement (builds on duffs device...), which can under the
> hood be
> optimised in a similar way.
>
>> I don't think I could have done it easily in other languages static
>> OO
>> languages.
>
> I'd agree with this, having tried it - it's possible though :-)
>
> There is also a Java mini-axon floating out there, which was doable,
> but my
> understanding was that aspects of Java did indeed make it harder.
>
>> One of the reasons I used D was that it compiles all the
>> way down to the metal and its support for generic programming using D
>> templates are second to none. Some of it's introspection features
>> were inspired by Python, Scheme and Lua.
>
> I guess I ought to take a better look at D then :)
>
>> Here's the current simple definition of Component:
>>
>> class Component : MicroProcess
>> {
>> Inbox!(SIGNAL) controlBox;
>> LinkedList!(IntrFace) inboxes;
>> LinkedList!(IntrFace) outboxes;
>>
>> this(char[] _name) {
>> super(_name);
>> inboxes = new LinkedList!(IntrFace);
>> outboxes = new LinkedList!(IntrFace);
>> controlBox = new Inbox!(SIGNAL);
>> inboxes.append(controlBox);
>> }
>>
>> // same as in parent
>> void run() {
>> Fiber.yield();
>> }
>>
>> }
>>
>> Just thought you might like to know. Hopefully I can get it to alpha
>> release quality in the near future.
>
> If you would like to use the kamaelia code repository to work on
> this, you are
> very welcome to do so.
>
> To help you decide if that makes sense for you, the three places
> there I'd
> normally suggested would be:
> /trunk/Sketches/{your initials}/
>
> ... for development/playing around.
>
> /branches/private_{your initials}_anything
>
> ... for feature branches (if appropriate).
>
> and...
> /trunk/Code/D/
>
> For the specific implementation. (mirroring the idea behind
> /trunk/Code/Python, /trunk/Code/CPP, /trunk/Code/Ruby - even if
> the only practical version at present is the python version)
>
> If that's helpful, please let me know. If you use elsewhere, please
> do let us
> know, I'd like to link to your code :)
>
>> If I can make it relatively compatible with Axon, it may be
>> straightforward
>> to port Kamaelia components. Eventually I hope to integrate it with
>> GTK.
>
> This sounds really good, and I'm more than willing to do what I can
> to support
> you with this :-)
>
>> If you have any questions, feel free to email me.
>>
>> have a good one,
>
> You too! Many thanks for getting in touch like this - it's very much
> appreciated.
>
> Best Regards,
>
>
> Michael.
> --
> http://yeoldeclue.com/blog
> http://twitter.com/kamaelian
> http://www.kamaelia.org/Home
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
