[03:01] *** salmon_ has joined #kamaelia

[03:52] *** salmon_ has joined #kamaelia

[04:14] < Lawouach_> RandIter: I doubt it

[04:15] < Lawouach_> both are different beasts if you consider that erlang has concurrency has a language paradigm whereas Kamaelia is a library which is limited by some aspects of Python

[05:51] < MS-> Morning

[05:51] < MS-> reading back

[05:52] < MS-> Thanks for the website pointer.

[05:52] < MS-> Regarding windows, kamaelia installs on windows, but I develop under linux & mac os x. (kamaelia has been reported working under windows)

[05:54] < MS-> Re: Erlang vs Kamaelia - my understanding is that the background to design decisions is similar, but I wasn't aware of erlang when designing kamaelia.

[05:54] < MS-> Kamaelia is influenced more by occam, unix, CSP and being frank, the Amiga.

[05:55] < MS-> (The Amiga's model was based on an OS called Tripos before that)

[05:55] < MS-> Specifically the idea of outboxes is like stdout or outchannels in occam.

[05:56] < MS-> As far as I can tell the idea of mailboxes/inboxes is relatively common, but the idea of outboxes/etc is unusual.

[05:56] < MS-> But it gives you all sorts of things, including extremely loose coupling, whilst enabling efficiencies like direct delivery

[05:56] < MS-> Probably the single biggest difference is the one that Lawouach already mentioned

[05:57] < MS-> in that Kamaelia is a library for components which is naturally concurrent, whereas erlang is a concurrency language.

[05:58] < MS-> The other difference is as obvious as well - one is based in an imperative language with easy access to lots of stuff created by other people, the other is in a functional language

[05:58] < MS-> which has its roots of being built on top of prolog (hence the syntax)

[05:59] < MS-> There are limitations from both directions as a result.

[05:59] < MS-> And a direct result in both cases from the original problems they were designed to solve. (eg string handling in erlang could be more fun)

[06:02] < MS-> Kamaelia also isn't a random library thrown up to be "a concurrency" thing. It was built to solve specific sorts of problems at my work place, and released in the hope it's useful to others. I am still using it daily though, and releasing whatever I can when I can :)

[06:03] < MS-> Sooner or later there will be a problem that forces a bunch of work to make the multiprocess stuff cleaner - but I'm driven like most open source people by need.

[06:04] < MS-> (as well as personal interest :-) )

[06:07] < RandIter> cool, thanks

[06:18] < MS-> Probably also worth remembering BTW that neither Jython nor IronPython have a GIL, so using threads there gives you multi-core friendliness (and access to other libraries).

[06:19] < RandIter> ah yes. wonder how far ironpython is from full 2.6 compatibility

[06:29] < RandIter> which version numbers of python does kamaelia currently support? also 32-bit only or 64-bit also?

[06:32] < RandIter> MS-: ^?

[06:33] < MS-> Sorry, didn't notice channel. (behind windows)

[06:33] < MS-> Kamaelia will run on most versions of python from the past several years

[06:34] < MS-> It works on 2.2.< late> where generators were implemented, but it's a pain to use on 2.2

[06:34] < MS-> I use it on machines with 2.3, 2.5 and 2.6

[06:34] < MS-> And I've heard reports that recent versions of Jython & IronPython will run kamaelia cleanly. :)

[06:35] < MS-> Also, from kamaelia's perspective whether the platform is 32bit or 64 bit is irrelevent since it's pure python. If python runs there and is 2.3 onwards, kamaelia runs there

[06:35] < RandIter> ok

[06:35] < MS-> I am tempted to drop support for pre-2.5 though

[06:36] < RandIter> yeah if it's holding you back from making improvements

[06:36] < MS-> Yep.

[06:38] < RandIter> ironpython seems interesting, although it seems somewhat slower than cpython, so I'm guessing that any reasonable benefit from ironpython+concurrency probably won't be realized until the number of cores is at least 4, versus cpython without concurrency

[06:39] *** Uraeus has joined #kamaelia

[06:39] < RandIter> MS-: i think it might help to state those python versions on the site

[06:40] < MS-> Indeed

[06:40] < MS-> If it's a standard cpython (or stackless python) from the past 5-7 years though it should be fine :)

[06:41] < RandIter> yes, some people including myself also wonder about 3.x compatibility

[06:44] < RandIter> it's not 3.x compatible yet, or is it? the default answer is usually no, so I'm checking despite what you just said

[06:56] < RandIter> MS-:

[06:56] < MS-> 3.x is syntactically different

[06:57] < MS-> trivial examples are print & except

[06:57] < MS-> so not yet is the answer

[06:57] < MS-> exception handling being different is a notable issue

[06:58] < MS-> This bit shows it more clearly:

[06:58] < MS-> http://www.ibm.com/developerworks/linux/library/l-python3-2/#exceptions

[08:44] *** Uraeus has joined #kamaelia

[12:44] *** salmon_ has joined #kamaelia

[15:17] *** vmlemon_ has joined #kamaelia

[18:12] *** vmlemon__ has joined #kamaelia

[18:16] *** vmlemon__ is now known as vmlemon_

[22:15] *** eikenberry has joined #kamaelia

[22:15] *** MS- has joined #kamaelia

[22:15] *** tdobson has joined #kamaelia