From mike at stok.ca Tue Dec 1 19:46:20 2009 From: mike at stok.ca (Mike Stok) Date: Tue, 1 Dec 2009 22:46:20 -0500 Subject: [tpm] December meeting - 17th at the Twisted Kilt Message-ID: <03AE0715-A595-48AA-AF04-97ACE889D638@stok.ca> The Twisted Kilt has reserved space for 15 of us under my name from 6:30 PM on Thursday 17 December, 2009. http://to.pm.org has been updated with details. Mike -- Mike Stok http://www.stok.ca/~mike/ The "`Stok' disclaimers" apply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From legrady at gmail.com Wed Dec 2 19:01:17 2009 From: legrady at gmail.com (Tom Legrady) Date: Wed, 2 Dec 2009 22:01:17 -0500 Subject: [tpm] MooseX::Getopt questions Message-ID: <3c9af5830912021901s6d30aea6h5415b59b5a1ec554@mail.gmail.com> I'm trying to work with Moose on a new project. My habit in recent years has been to use Getopt::Long to parse command line arguments, and Pod::Usage to display short --help or very long --man POD output. So I want to use MooseX::Getopt to parse arguments which have been specified / described in Moose-ish style and Moosex::Getopt::GLD to store the command line argument documentation with the Moose attribute. But I can't figure out how to use M::G::GLD. GLD, which I've never used, uses a single data structure to store all the arguments, and to associate a Getopt::Long style description, such as 'firstname=s' to specify --firstname accepting a string argument, and a description string, which, presumably, is output if documentation is required. Moose associates everything to do with one attribute in one place, which is the reverse of associating the getopt strings ans descriptions for all the args into one structure. So how are you supposed to specify things? How do you invoke it? As well if you have an error in command line arguments, it generates an error message and dies. My past experience is to stick --help or --man on the command line, and view some helpful reminder to figure out what I was doing wrong. That's possible because Getopt::Long doesn't go beyond requiring an arg to be string or integer or float or bool. Type information and data subtypes are handled later. That allows an opportunity for POD::Usage to be invoked. So what am i doing wrong, how do I do it right? I don't find Moose is generous with examples ... only a few examples used over and over, so if it doesn't answer your question there's nowhere to turn. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at alteeve.com Wed Dec 9 18:49:25 2009 From: linux at alteeve.com (Madison Kelly) Date: Wed, 09 Dec 2009 21:49:25 -0500 Subject: [tpm] eval oddness Message-ID: <4B2061B5.3020001@alteeve.com> Hi all, This may be due to my ignorance, but I am having a problem that I don't *think* I should be. I've got a set of methods in my module that loads various other modules wrapped in 'eval's so that I can handle missing modules a little more gracefully. All of these work except one. For example; This works: ----------------------------------------- # Script use AN::Tools; my $an=AN::Tools->new(); $an->_load_net_dbus(); # Module sub _load_net_dbus { my $self=shift; eval 'use Net::DBus;'; if ($@) { print "Gak! $@\n"; return (undef); } else { # Good, record it as loaded. $self->_net_dbus_loaded(1); print "Net::DBus loaded.\n"; } return (0); } ----------------------------------------- Now though, I've got one that doesn't... The main difference that I can see is the 'use base ...'. ----------------------------------------- # Script $an->_load_net_dbus_object(); # Module sub _load_net_dbus_object { my $self=shift; eval 'use base qw(Net::DBus::Object);'; if ($@) { print "Gak! $@\n"; return (undef); } else { # Good, record it as loaded. $self->_net_dbus_object_loaded(1); print "Net::DBus::Object loaded.\n"; } return (0); } ----------------------------------------- It *looks* like it loads in that '$@' isn't set. However, when I try to use any of the methods in Net::DBus::Object, it errors. Is there something about 'base' that could be messing this up or is it something else? For testing, if I check that the '$an->_load_net_dbus_object();' call returns '0' and then call: eval 'use base qw(Net::DBus::Object);'; From the main script, it does work, so it doesn't seem to be the eval itself that's the problem. Thanks all! Madi From dave.s.doyle at gmail.com Wed Dec 9 19:27:07 2009 From: dave.s.doyle at gmail.com (Dave Doyle) Date: Wed, 9 Dec 2009 22:27:07 -0500 Subject: [tpm] eval oddness In-Reply-To: <4B2061B5.3020001@alteeve.com> References: <4B2061B5.3020001@alteeve.com> Message-ID: I do not think that means what you think that means. :) Can I ask why you're doing "use base qw(Net::DBus::Object);" as opposed to "use Net::DBus::Object;" ? The 'use base' is nonsensical in this context as it's modifying the @ISA array. It's essentially saying "This class is a subclass of Net::DBus::Object" and not actually making any part of Net::DBus::Object available to you. I suspect just doing use Net::DBus::Object and you'll be fine. Though I'm hardpressed to explain why, using "require" instead of "use" seems to be more canonical when dynamically loading modules. I'm sure someone far smarter than I on this list could explain that. I suspect it's the difference between bareword and string (bareword loads a module, string loads the filename specifically instead of searching %INC for it). There's also import voodoo that won't happen (unless you do the voodoo yourself) but if you're only loading OO modules this shouldn't be a big deal. D -- dave.s.doyle at gmail.com On Wed, Dec 9, 2009 at 9:49 PM, Madison Kelly wrote: > Hi all, > > This may be due to my ignorance, but I am having a problem that I don't > *think* I should be. > > I've got a set of methods in my module that loads various other modules > wrapped in 'eval's so that I can handle missing modules a little more > gracefully. All of these work except one. > > For example; This works: > > ----------------------------------------- > # Script > use AN::Tools; > my $an=AN::Tools->new(); > $an->_load_net_dbus(); > > # Module > sub _load_net_dbus > { > my $self=shift; > > eval 'use Net::DBus;'; > if ($@) > { > print "Gak! $@\n"; > return (undef); > } > else > { > # Good, record it as loaded. > $self->_net_dbus_loaded(1); > print "Net::DBus loaded.\n"; > } > > return (0); > } > ----------------------------------------- > > Now though, I've got one that doesn't... The main difference that I can > see is the 'use base ...'. > > ----------------------------------------- > # Script > $an->_load_net_dbus_object(); > > # Module > sub _load_net_dbus_object > { > my $self=shift; > > eval 'use base qw(Net::DBus::Object);'; > if ($@) > { > print "Gak! $@\n"; > return (undef); > } > else > { > # Good, record it as loaded. > $self->_net_dbus_object_loaded(1); > print "Net::DBus::Object loaded.\n"; > } > > return (0); > } > ----------------------------------------- > > It *looks* like it loads in that '$@' isn't set. However, when I try to > use any of the methods in Net::DBus::Object, it errors. > > Is there something about 'base' that could be messing this up or is it > something else? For testing, if I check that the > '$an->_load_net_dbus_object();' call returns '0' and then call: > > eval 'use base qw(Net::DBus::Object);'; > > From the main script, it does work, so it doesn't seem to be the eval > itself that's the problem. > > Thanks all! > > Madi > _______________________________________________ > toronto-pm mailing list > toronto-pm at pm.org > http://mail.pm.org/mailman/listinfo/toronto-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at alteeve.com Wed Dec 9 19:50:56 2009 From: linux at alteeve.com (Madison Kelly) Date: Wed, 09 Dec 2009 22:50:56 -0500 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> Message-ID: <4B207020.1010006@alteeve.com> Dave Doyle wrote: > I do not think that means what you think that means. :) > > Can I ask why you're doing "use base qw(Net::DBus::Object);" as opposed > to "use Net::DBus::Object;" ? The 'use base' is nonsensical in this > context as it's modifying the @ISA array. It's essentially saying "This > class is a subclass of Net::DBus::Object" and not actually making any > part of Net::DBus::Object available to you. I suspect just doing use > Net::DBus::Object and you'll be fine. > > Though I'm hardpressed to explain why, using "require" instead of "use" > seems to be more canonical when dynamically loading modules. I'm sure > someone far smarter than I on this list could explain that. I suspect > it's the difference between bareword and string (bareword loads a > module, string loads the filename specifically instead of searching %INC > for it). There's also import voodoo that won't happen (unless you do > the voodoo yourself) but if you're only loading OO modules this > shouldn't be a big deal. > > D Hrm, I guess that would explain it. However, I remember reading at some point in the Net::DBus docs that 'use base' was needed... I'll look into that more, thanks for the pointer!! Madi From liam at holoweb.net Wed Dec 9 20:38:47 2009 From: liam at holoweb.net (Liam R E Quin) Date: Wed, 09 Dec 2009 23:38:47 -0500 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> Message-ID: <1260419927.23280.35.camel@desktop.barefootcomputing.com> On Wed, 2009-12-09 at 22:27 -0500, Dave Doyle wrote: [...] > Though I'm hardpressed to explain why, using "require" instead of > "use" seems to be more canonical when dynamically loading modules. That's because, in general, "use" is compile-time, and "require" is done at run-time. If you don't know what module you want until run-time, or you don't know if a particular module will be needed ,"require" is a good option. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org From dave.s.doyle at gmail.com Thu Dec 10 05:38:48 2009 From: dave.s.doyle at gmail.com (Dave Doyle) Date: Thu, 10 Dec 2009 08:38:48 -0500 Subject: [tpm] eval oddness In-Reply-To: <1260419927.23280.35.camel@desktop.barefootcomputing.com> References: <4B2061B5.3020001@alteeve.com> <1260419927.23280.35.camel@desktop.barefootcomputing.com> Message-ID: I dig that, but since the eval is a runtime construct how would something like eval "use Module::Name;" differ from eval "require Module::Name"? Is there any difference in the use of "use" as opposed to "require" in that context? -- dave.s.doyle at gmail.com On Wed, Dec 9, 2009 at 11:38 PM, Liam R E Quin wrote: > On Wed, 2009-12-09 at 22:27 -0500, Dave Doyle wrote: > [...] > > Though I'm hardpressed to explain why, using "require" instead of > > "use" seems to be more canonical when dynamically loading modules. > > That's because, in general, "use" is compile-time, and "require" is > done at run-time. > > If you don't know what module you want until run-time, or > you don't know if a particular module will be needed ,"require" > is a good option. > > Liam > > > > -- > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > Pictures from old books: http://fromoldbooks.org/ > Ankh: irc.sorcery.net irc.gnome.org www.advogato.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at alteeve.com Thu Dec 10 07:44:27 2009 From: linux at alteeve.com (Madison Kelly) Date: Thu, 10 Dec 2009 10:44:27 -0500 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> Message-ID: <4B21175B.6010500@alteeve.com> Dave Doyle wrote: > I do not think that means what you think that means. :) Oops, meant to include the code they use in their docs: ------------------------------------------- use base qw(Net::DBus); sub new { my $class = shift; my $service = shift; my $self = $class->SUPER::new($service, "/music/player/manager"); bless $self, $class; return $self; } ------------------------------------------- Madi From linux at alteeve.com Thu Dec 10 07:41:48 2009 From: linux at alteeve.com (Madison Kelly) Date: Thu, 10 Dec 2009 10:41:48 -0500 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> Message-ID: <4B2116BC.5020606@alteeve.com> Dave Doyle wrote: > I do not think that means what you think that means. :) > > Can I ask why you're doing "use base qw(Net::DBus::Object);" as opposed > to "use Net::DBus::Object;" ? The 'use base' is nonsensical in this > context as it's modifying the @ISA array. It's essentially saying "This > class is a subclass of Net::DBus::Object" and not actually making any > part of Net::DBus::Object available to you. I suspect just doing use > Net::DBus::Object and you'll be fine. > > Though I'm hardpressed to explain why, using "require" instead of "use" > seems to be more canonical when dynamically loading modules. I'm sure > someone far smarter than I on this list could explain that. I suspect > it's the difference between bareword and string (bareword loads a > module, string loads the filename specifically instead of searching %INC > for it). There's also import voodoo that won't happen (unless you do > the voodoo yourself) but if you're only loading OO modules this > shouldn't be a big deal. > > D By the way, +1 point for "The Princess Bride" reference. :D Anywho, I've been re-reading the (sparse) Net::DBus docs and it always shows it's constructor using the "super" method. I know that this has to do with inheritance, but to be honest, I've never really understood the true meaning of this. Could this be why the docs always show 'use base qw(Net::DBus::Object);'? If so, could you (or someone) better explain why this might be needed in general? I feel bad admitting that I don't really get it, as I think this is something relatively basic, but there you go. :) Madi From shlomif at iglu.org.il Thu Dec 10 08:52:22 2009 From: shlomif at iglu.org.il (Shlomi Fish) Date: Thu, 10 Dec 2009 18:52:22 +0200 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> <1260419927.23280.35.camel@desktop.barefootcomputing.com> Message-ID: <200912101852.22663.shlomif@iglu.org.il> On Thursday 10 Dec 2009 15:38:48 Dave Doyle wrote: > I dig that, but since the eval is a runtime construct how would something > like eval "use Module::Name;" differ from eval "require Module::Name"? Is > there any difference in the use of "use" as opposed to "require" in that > context? Well, use will also call Module::Name->import(). Regards, Shlomi Fish > > -- > dave.s.doyle at gmail.com > > On Wed, Dec 9, 2009 at 11:38 PM, Liam R E Quin wrote: > > On Wed, 2009-12-09 at 22:27 -0500, Dave Doyle wrote: > > [...] > > > > > Though I'm hardpressed to explain why, using "require" instead of > > > "use" seems to be more canonical when dynamically loading modules. > > > > That's because, in general, "use" is compile-time, and "require" is > > done at run-time. > > > > If you don't know what module you want until run-time, or > > you don't know if a particular module will be needed ,"require" > > is a good option. > > > > Liam > > > > > > > > -- > > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > > Pictures from old books: http://fromoldbooks.org/ > > Ankh: irc.sorcery.net irc.gnome.org www.advogato.org > -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://shlom.in/file-swap Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ ) From shlomif at iglu.org.il Thu Dec 10 08:52:22 2009 From: shlomif at iglu.org.il (Shlomi Fish) Date: Thu, 10 Dec 2009 18:52:22 +0200 Subject: [tpm] eval oddness In-Reply-To: References: <4B2061B5.3020001@alteeve.com> <1260419927.23280.35.camel@desktop.barefootcomputing.com> Message-ID: <200912101852.22663.shlomif@iglu.org.il> On Thursday 10 Dec 2009 15:38:48 Dave Doyle wrote: > I dig that, but since the eval is a runtime construct how would something > like eval "use Module::Name;" differ from eval "require Module::Name"? Is > there any difference in the use of "use" as opposed to "require" in that > context? Well, use will also call Module::Name->import(). Regards, Shlomi Fish > > -- > dave.s.doyle at gmail.com > > On Wed, Dec 9, 2009 at 11:38 PM, Liam R E Quin wrote: > > On Wed, 2009-12-09 at 22:27 -0500, Dave Doyle wrote: > > [...] > > > > > Though I'm hardpressed to explain why, using "require" instead of > > > "use" seems to be more canonical when dynamically loading modules. > > > > That's because, in general, "use" is compile-time, and "require" is > > done at run-time. > > > > If you don't know what module you want until run-time, or > > you don't know if a particular module will be needed ,"require" > > is a good option. > > > > Liam > > > > > > > > -- > > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > > Pictures from old books: http://fromoldbooks.org/ > > Ankh: irc.sorcery.net irc.gnome.org www.advogato.org > -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://shlom.in/file-swap Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ ) From stuart at morungos.com Thu Dec 10 10:16:37 2009 From: stuart at morungos.com (Stuart Watt) Date: Thu, 10 Dec 2009 13:16:37 -0500 Subject: [tpm] eval oddness In-Reply-To: <4B2116BC.5020606@alteeve.com> References: <4B2061B5.3020001@alteeve.com> <4B2116BC.5020606@alteeve.com> Message-ID: <4B213B05.1070406@morungos.com> If what you're after is changing the parent class dynamically, something like: push @ISA, 'Net::DBus::Object'; is likely to be a better bet than eval "use base ...". This should add Net::DBus::Object to the parent list. @ISA is a funny variable, which has some magic behind it, and it would not surprise me if the eval technique somehow failed to do the right magic. eval() does do some odd things, and @ISA is not just an ordinary variable. One hack that is mentioned is that setting @ISA = @ISA can clear some of the caching on @ISA, and could be that adding that will make things work better. However, generally, changing the inheritance of an object at runtime is an easy way to get in lots of trouble. I did it once, but I didn't get away with it completely, and things were never the same afterwards. In the end, it was much safer to either (a) use a factory style pattern which returns an instance of the class you need, when this class is chosen dynamically, or (b) store the instance of Net::DBus::Object somewhere in a lexical in a facade style instance, and defer method calls to other objects as you need. Inventive use of AUTOLOAD can pass on any method not explicitly defined to this lexical, even checking it can handle it. These increase the number of objects, but should be easier to handle. All the best Stuart From sfryer at sourcery.ca Thu Dec 10 12:42:59 2009 From: sfryer at sourcery.ca (Shaun Fryer) Date: Thu, 10 Dec 2009 15:42:59 -0500 Subject: [tpm] eval oddness In-Reply-To: <4B2116BC.5020606@alteeve.com> References: <4B2061B5.3020001@alteeve.com> <4B2116BC.5020606@alteeve.com> Message-ID: <982579710912101242n7cd84de9yb6aad78bd4b7b5b6@mail.gmail.com> On Thu, Dec 10, 2009 at 10:41 AM, Madison Kelly wrote: > Anywho, I've been re-reading the (sparse) Net::DBus docs and it always > shows it's constructor using the "super" method. I know that this has to do > with inheritance, but to be honest, I've never really understood the true > meaning of this. > hi madison, perhaps this will help you understand a bit more about what SUPER does, and how inheritance works in perl. ####[ START Foo.pm ]### { package Foo; sub new { bless {}, shift } sub says { print shift()->word, "\n" } sub word { 'foo!' } 1 } { package Foo::Bar; use base qw(Foo); sub word { 'bar!' } 1 } { package Foo::Bar::Baz; use base qw(Foo::Bar); sub says { my $self = shift; print __PACKAGE__, " isa Foo\n" if $self->isa('Foo'); print 'Foo::Bar says ', $self->SUPER::word, "\n", __PACKAGE__, ' says ', $self->word, "\n"; } sub word { 'baz!' } 1 } ####[ END Foo.pm ]### bash$ perl -MFoo -e 'Foo->new->says' foo! bash$ perl -MFoo -e 'Foo::Bar->new->says' bar! bash$ perl -MFoo -e 'Foo::Bar::Baz->new->says' Foo::Bar::Baz isa Foo Foo::Bar says bar! Foo::Bar::Baz says baz! bash$ as a general rule though, it's best to avoid "implementation inheritance" ("use base", "push @ISA", "use parent") as much as humanly possible. if at all possible it's much better in practice to use "interface inheritance" ["use Module qw( some interfaces to import )"]. inheritance is intrinsic to OOP, so it's important to understand the design patterns associated with it and the pros and cons of each. cheers, -- Shaun Fryer -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at morungos.com Thu Dec 10 13:58:37 2009 From: stuart at morungos.com (Stuart Watt) Date: Thu, 10 Dec 2009 16:58:37 -0500 Subject: [tpm] eval oddness In-Reply-To: <982579710912101242n7cd84de9yb6aad78bd4b7b5b6@mail.gmail.com> References: <4B2061B5.3020001@alteeve.com> <4B2116BC.5020606@alteeve.com> <982579710912101242n7cd84de9yb6aad78bd4b7b5b6@mail.gmail.com> Message-ID: <4B216F0D.6020900@morungos.com> Shaun Fryer wrote: > as a general rule though, it's best to avoid "implementation > inheritance" ("use base", "push @ISA", "use parent") as much as > humanly possible. if at all possible it's much better in practice to > use "interface inheritance" ["use Module qw( some interfaces to import > )"]. inheritance is intrinsic to OOP, so it's important to understand > the design patterns associated with it and the pros and cons of each. These are interesting points, but can I suggest you maybe went a little far with the "as much as humanly possible" bit. "as much as is appropriate to your purpose" would perhaps be better. (I'd suggest this is the core of quality - fitness for purpose.) Inheritance is not completely intrinsic to OO - there are OO languages without inheritance (e.g., Self) and with limited concepts of inheritance (e.g., JavaScript). OO is really about being to build effective pieces of abstract behaviour. That is, you can hide internal implementation details, and still provide a service to others. I'd say it all depends on what your purpose is. If you are writing code to be used by others, rather than writing code to be extended by others, you typically end up with different structures. If you want your code to be extended by others, inheritance is kind of invaluable. Most frameworks for extension provide many classes you can extend. Catalyst is a great example. DBI is a good contrast: you rarely benefit from extending database access provision, so a well-defined interface is a better choice. Moose makes much of this a lot better, as it adds a few very helpful concepts, such as roles. Having used at least five different OO systems over the years, Moose is probably the one I've had most control over my application architecture with. Just a few thoughts, All the best Stuart From sfryer at sourcery.ca Thu Dec 10 14:12:50 2009 From: sfryer at sourcery.ca (Shaun Fryer) Date: Thu, 10 Dec 2009 17:12:50 -0500 Subject: [tpm] eval oddness In-Reply-To: <4B216F0D.6020900@morungos.com> References: <4B2061B5.3020001@alteeve.com> <4B2116BC.5020606@alteeve.com> <982579710912101242n7cd84de9yb6aad78bd4b7b5b6@mail.gmail.com> <4B216F0D.6020900@morungos.com> Message-ID: <982579710912101412l57c4f6a1s8a62b3147df5e998@mail.gmail.com> well said stuart! I couldn't agree more! for someone with madison's level of oop experience though, what I've said remains a good general rule of thumb. at least it's far better than the multiple inheritance hell that alot of folks run into otherwise... -- Shaun Fryer On Thu, Dec 10, 2009 at 4:58 PM, Stuart Watt wrote: > Inheritance is not completely intrinsic to OO - there are OO languages > without inheritance (e.g., Self) and with limited concepts of inheritance > (e.g., JavaScript). OO is really about being to build effective pieces of > abstract behaviour. That is, you can hide internal implementation details, > and still provide a service to others. > > I'd say it all depends on what your purpose is. If you are writing code to > be used by others, rather than writing code to be extended by others, you > typically end up with different structures. If you want your code to be > extended by others, inheritance is kind of invaluable. Most frameworks for > extension provide many classes you can extend. Catalyst is a great example. > DBI is a good contrast: you rarely benefit from extending database access > provision, so a well-defined interface is a better choice. > > Moose makes much of this a lot better, as it adds a few very helpful > concepts, such as roles. Having used at least five different OO systems over > the years, Moose is probably the one I've had most control over my > application architecture with. > > Just a few thoughts, > > All the best > Stuart > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at stok.ca Wed Dec 16 19:30:48 2009 From: mike at stok.ca (Mike Stok) Date: Wed, 16 Dec 2009 22:30:48 -0500 Subject: [tpm] Xmas social and ideas for January talks Message-ID: This is a reminder that the December social is on Thursday December 17, 2009 at the Twisted Kilt, 1954 Yonge St. If you have any ideas or suggestions for the January meeting then feel free to bring them along and/or discuss them on the list. Cheers, Mike -- Mike Stok http://www.stok.ca/~mike/ The "`Stok' disclaimers" apply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceeshek at gmail.com Fri Dec 18 17:21:18 2009 From: ceeshek at gmail.com (Cees Hek) Date: Fri, 18 Dec 2009 20:21:18 -0500 Subject: [tpm] Xmas social and ideas for January talks In-Reply-To: References: Message-ID: Hi All, I said that I was coming to the TPM social this year, but after attempting some stupid tricks in the snow I ended up in the hospital (apparently I am not as young and agile as I thought I was :). I trust everyone had a good time, and perhaps I'll have to catch uo with everyone next year... Cheers, Cees On Wed, Dec 16, 2009 at 10:30 PM, Mike Stok wrote: > This is a reminder that the December social is on Thursday December 17, 2009 > at the Twisted Kilt, 1954 Yonge St. > If you have any ideas or suggestions for the January meeting then feel free > to bring them along and/or discuss them on the list. > Cheers, > Mike > -- > Mike Stok > http://www.stok.ca/~mike/ > The "`Stok' disclaimers" apply. > > > > > _______________________________________________ > toronto-pm mailing list > toronto-pm at pm.org > http://mail.pm.org/mailman/listinfo/toronto-pm > >