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

[04:54] *** Lawouach_ has joined #kamaelia

[06:59] *** salmon_ has joined #kamaelia

[07:07] < Lawouach_> That KeyboardInterrupt really complicates my life right now :/

[08:32] < MS-> If you want to take a look at where to put it into the Scheduler, please do, and give some hints as to where you like it...

[08:36] < MS-> Being rather blase about it, you could potentially wrap lines 447 - 555 in a try/except KeyboardInterrupt, and if caught, so the same thing as lines 558-560

[08:36] < MS-> In this:

[08:36] < MS-> http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/Scheduler.py

[08:36] < MS-> That may actually do what you want.

[08:37] < MS-> I suspect though that in order to have "correct" behaviour in general

[08:37] < MS-> that after doing that you'd want to re-raise the KeyboardInterrupt.

[08:39] < MS-> One thing that can't be ignored is that simply carrying on looping is valid - because you can't know which component the KeyboardInterrupt was raised inside

[08:39] < MS-> That generator will have had its stack frame deactivated by python - since there's no concept in python of resumeable exceptions.

[08:40] < MS-> The alternative you'd need, thinking about it, is to write a signal handler.

[08:40] < MS-> That signal handler, can then call scheduler.run.stop()

[08:41] < MS-> To tell the primary scheduler to shut down, allowing all components to shutdown cleanly.

[08:41] < MS-> That would probably need to ideally set a timer signal to get the system to recall the handler

[08:41] < MS-> so it can kill the scheduler properly if it fails to shutdown, due to (say) a rogue component.

[08:42] < MS-> Thinking about it, this is probably what vlc does internally

[09:44] < Lawouach_> hello guys

[09:44] < Lawouach_> oops

[09:44] < Lawouach_> sorry

[09:44] < Lawouach_> I didn't realise you had replied

[09:44] < Lawouach_> reading

[09:45] < Lawouach_> right it makes sense

[09:45] < Lawouach_> I think I'm more annoyed at how little leverage you get from Python on a SIGINT

[09:46] < Lawouach_> From Axon, I suppose I'd just want my component to be shutdown cleanly, or at least get to call scheduler.stop properly indeed

[09:46] < Lawouach_> But this isn't blocking me in any way, just not friendly

[09:57] *** MS- nods

[09:58] < MS-> I get the impression though that if we catch the SIGINT signal, we could probably do something relatively intelligent

[10:04] < Lawouach_> that'd be nice :)

[10:11] < MS-> I'll bung on my bugs list. I'm treating it as a todo list, and so far seems a pretty good approach

[10:16] < Lawouach_> :)

[13:05] *** eikenberry has joined #kamaelia

[13:08] *** salmon_ has joined #kamaelia

[16:02] *** vmlemon_ has joined #kamaelia

[16:04] < vmlemon_> Hi

[16:06] < Lawouach> hi vmlemon_

[16:33] < MS-> evening

[16:46] < eikenberry> MS-. Ever get any feedback on that syntactic sugar post. I keep meaning to...

[16:48] < MS-> I haven't had anything specific. I've got some thoughts, but would welcome thoughts of others :-)

[16:49] < eikenberry> I had various thoughts... mainly outsider beginner things as I haven't done much more than the axon tutorial and some reading.

[16:49] < MS-> Those are fine :-)

[16:51] < eikenberry> Want them here or would you prefer the list?

[16:52] < MS-> Things like syntactic sugar tend to work best on the list IMO.

[16:52] < MS-> It's alot easier to discuss examples there

[16:53] < eikenberry> cool. context wise... I'm looking at the various pipeline systems in relation to a project I'm starting. I want to use it but and still thinking about how to do it.

[16:54] < eikenberry> I've been stuck in zope2 land for years so am quite reticent about getting locked into a framework.

[16:54] < MS-> I can understand that.

[16:54] < Lawouach> eikenberry: Kamaelia will free your mind :)

[16:54] < MS-> That's part of the reason for wanting to make Axon.Handle work better - so that people aren't locked into to one form of code. It also simplifies some circumstances.

[16:56] < eikenberry> So I was looking primarily at either simple generators or coroutines. I'm reconsidering that a bit, but still want to stick as close to idiomatic python as possible.

[16:57] < MS-> I can understand that desire. I'm considering some syntactic sugar which would be relatively close to idiomatic python.

[16:57] < eikenberry> Looking over the 99 bottles page on the concurrency wiki as an example. Kamaelia seems to have a lot of boilerplate compared to say fibra.

[16:57] < MS-> That's because I chose to do it that way

[16:57] < eikenberry> heh.

[16:58] < MS-> It's more an example of idiomatic Axon usage, rather than idiomatic Kamaelia.

[16:58] < MS-> But then it was nice to do it that way because it generated some comments...

[16:59] < eikenberry> Does Kamaelia have decorators for wrapping generators.

[16:59] < eikenberry> ?

[16:59] < eikenberry> Making them into components?

[17:00] < MS-> No, that's the comments I'm looking for on twitter.

[17:00] < MS-> (which is why I prefer specific ideas posted on the mailing list, since they don't get lost :-) )

[17:01] *** eikenberry nods

[17:02] < MS-> This was a similar comment/request: http://twitter.com/atl/status/1846111439

[17:03] < eikenberry> Is that in relation to your blog post? The coroutine to component one.

[17:05] < MS-> yep

[17:09] < eikenberry> cool. I agree. IMO the best system would be one that would look almost just like a system based on generators/coroutines, that you would just decorate into a more capable system. Something akin to beazley's coroutine talk... taking the basic blocks then hooking them into a scheduler and allowing for more easily setting up complex pipelines.

[17:09] < MS-> That's nice, until you realise how the control flow of beazley's coroutines work.

[17:10] < MS-> Specifically they seem to be limited to pipelines.

[17:10] *** eikenberry nods. They are more an example than a working system. I just really liked how they built on idiomatic python rather than a framework.

[17:10] < MS-> The reason is because the last coroutine *pulls* rather than pushes values.

[17:11] < MS-> Mixing push and pull - which kamaelia does - seems to be somewhat harder to do that way

[17:12] *** eikenberry nods.

[17:13] < MS-> I've just posted to the list a piece of code that's a syntax I'm toying with.

[17:14] < MS-> But more ideas as to what you'd like to type would be v useful

[17:14] < eikenberry> cool. reading email.

[17:15] < MS-> There, found the tweet which is similar. http://twitter.com/jessenoller/status/1903052945

[17:15] < eikenberry> Are multiple inboxes and outboxes normal?

[17:16] < MS-> Yes

[17:17] < MS-> Much like each unix process has stdin, stderr and stdout, *and* signals from the OS.

[17:17] < MS-> stdin ~ "inbox" , signals from OS ~ "control", stdout ~ "outbox", stderr ~ "signal" (signals to pass on to next component)

[17:19] < eikenberry> Hmm. I'd almost think it would be clearer to pass the boxes as arguments rather. Make it more function like, less like an unbound method.

[17:21] < MS-> Have a ponder, post something that you think you like :) If its ideal, that's great, if it's not, its a step forward :-)

[17:21] < MS-> I'm very much in favour of trying stuff and seeing :)

[17:22] *** MS- needs to put kids to bed

[17:22] < MS-> biab

[17:22] < eikenberry> I'll see what I can come up with.

[17:23] < MS-> cheers :)

[17:23] < eikenberry> thanks. later. :)

[17:35] < vmlemon_> kamlogbot: date

[17:35] Reply: 2009-06-16

[18:14] *** salmon_ has joined #kamaelia

[19:49] *** vmlemon_1 has joined #kamaelia

[23:53] *** kamlogbot has joined #kamaelia