[Wellington-pm] Roundup of last night's meeting

[Grant McLean]

On Fri, 2007-09-14 at 13:35 +1200, Richard Hector wrote:
> On Fri, 2007-09-14 at 11:35 +1200, Sam Vilain wrote:
> 
> > Hmm... sounds like a call for an evening on multiprocessing.
> > 
> > So in the context of Perl this varies from:
> > 
> >  - fork(), emulated via threads on Windows
> > 
> >  - the varying threads implementation attempts from the 5.004->5.6
> >    Perl series, leading to the current one, interpreter threads
> > 
> >  - co-operative, event/queue-driven systems like Event.pm, or the ones
> >    in Gtk, Tk, etc.  POE can work within all of these FWIW
> > 
> >  - co-operative, task switching systems - co-routines - via Coro in Perl
> >    5 and the "produce" keyword in Perl 6.  These are really neat.
> > 
> >  - semi-pre-emptive/per-opcode multi-threading systems.  I don't know of
> >    any of these for Perl, but it's how Ruby threading works.
> > 
> >  - Software Transaction Memory (STM) - one of the big buzzwords at OSCON
> >    this year.  Done with the "contend { }" keyword in Perl 6.
> 
> My memory is hazy, but doesn't Quantum::Superpositions fit in here
> somewhere?

Not really.  Quantum::Superpositions (or 'junctions' as they're known in
Perl 6) are a fancy way of working with sets of possible values to
answer questions like:

  is the value in $a greater than all of the values in ($b, $c, ...)

It uses operator overloading to reduce concepts that are easy to express
concisely in english to concise snippets of Perl code.  Whether these
concise snippets are as easily understandable as the original english
description is open to debate :-)

Sam's suggestion (which echos Evan's off-list suggestion) was more on
the theme of programs which have to handle multiple concurrent streams
of execution - for example a daemon handling requests for multiple
clients.  

I think this is an excellent suggestion and would be happy to contribute
a short talk on writing such a daemon without any of the fancy modules -
the details of that might make it clearer why the fancy tools are a good
idea.

Sam: with luck Evan will tell us about Event.pm so if you could tell us
about Coro/produce and/or STM then I'd be interested.

If we do end up with 4 talks then we should be aiming for about 15min
each.

Cheers
Grant