From hakim.cassimally at gmail.com Thu Jul 5 01:29:20 2012 From: hakim.cassimally at gmail.com (Hakim Cassimally) Date: Thu, 5 Jul 2012 09:29:20 +0100 Subject: [Edinburgh-pm] Pub tonight? Message-ID: Hello one, hello all, I haven't had a drink since, well, Tuesday, and I can already feel a terrible thirst coming on. If anyone fancies helping me avert a catastrophe of epic [1] proportions, how about: Cloisters 7:30pm ? The fate of the world is in your hands, osfameron [1] well, at least web-scale From perl at aaroncrane.co.uk Thu Jul 5 05:14:35 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Thu, 5 Jul 2012 13:14:35 +0100 Subject: [Edinburgh-pm] Pub tonight? In-Reply-To: References: Message-ID: Hakim Cassimally wrote: > I haven't had a drink since, well, Tuesday, and I can already feel a > terrible thirst coming on. ?If anyone fancies helping me avert a > catastrophe of epic [1] proportions, how about: > > ? ? Cloisters 7:30pm ? I'll happily assist in this great undertaking. See you there! -- Aaron Crane ** http://aaroncrane.co.uk/ From perl at aaroncrane.co.uk Sat Jul 7 09:35:35 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Sat, 7 Jul 2012 17:35:35 +0100 Subject: [Edinburgh-pm] YAPC::EU - August 2012, Frankfurt Message-ID: Just thought I'd remind local Perl Mongers about this year's YAPC::EU conference: Monday 20th ? Wednesday 22nd August Frankfurt, Germany http://yapc.eu/2012 Price: ?110, or ?50 for full-time students. There's also an early-bird rate of ?80, but you'll have to be quick ? that offer finishes tomorrow. The call for papers is open for another week, and speakers get free entry. If you're looking at flying from Edinburgh to Frankfurt, the airlines with direct flights are Lufthansa (?150??250 return, depending on dates) or Ryanair (but that takes you to "Frankfurt Hahn" airport ? a 2-hour, ?14-one-way bus journey from the city itself). There don't seem to be any direct routes from Glasgow. -- Aaron Crane ** http://aaroncrane.co.uk/ From oinksocket at letterboxes.org Wed Jul 18 06:15:21 2012 From: oinksocket at letterboxes.org (Nick) Date: Wed, 18 Jul 2012 14:15:21 +0100 Subject: [Edinburgh-pm] a Perl surprise Message-ID: <5006B6E9.6010301@letterboxes.org> Here's a little off-topic on-topicality to clutter the list up. Excuse me for answering my own question. I hadn't an answer when I started writing this (so it served my purpose at least), and I figure I may as well send this. What would you expect this to print? perl -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' 6 right? Nope. Let's see what Deparse says: perl -MO=Deparse -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' BEGIN { $/ = "\n"; $\ = "\n"; } sub wtf ($) { @_; } @a = wtf(('???', '???', '8')); print @a; WTF are those '???' things? Discarded constants I suppose? Anyway, seems that the reason for the surprise is that in this case (with a prototype): wtf qw(6 7 8) is equivalent to: wtf (('6', '7', '8')) A list (as opposed to an array) in scalar context evaluates the to *last* element (a bit of another gotcha I happened to already know about). See also: perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 Note the (absense of) brackets. At least if you turn warnings on you will get a warning about "useless use of a constant". N From bynari at gmail.com Wed Jul 18 06:36:56 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 14:36:56 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006B6E9.6010301@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> Message-ID: <5006BBF8.1070605@gmail.com> Hey, I'd have expected the 8, yeah. It's because there's no such thing as 'array context' in Perl, just scalar context and list context. Arrays can can be called in either context, but they themselves are not a context. So really with the single scalar prototype it's just a list in scalar context, which as I'm sure you know will just store and discard each scalar to the left of a comma. Notice that this is the same as your example: perl -le ' sub wtf($) { $_[0] }; @a = wtf (qw(6 7 8)); print @a;' So what's really happening is qw(6 7 8) is getting assigned to $_[0] rather than @_, then the array, @a gets assigned the value of $_[0]. The fact that wtf qw(6 7 8) is equivalent to: wtf (('6', '7', '8')) On 18/07/2012 14:15, Nick wrote: > Here's a little off-topic on-topicality to clutter the list up. Excuse me for > answering my own question. I hadn't an answer when I started writing this (so it > served my purpose at least), and I figure I may as well send this. > > > What would you expect this to print? > > perl -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' > > 6 right? > > Nope. > > > > Let's see what Deparse says: > > perl -MO=Deparse -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' > > BEGIN { $/ = "\n"; $\ = "\n"; } > sub wtf ($) { > @_; > } > @a = wtf(('???', '???', '8')); > print @a; > > > WTF are those '???' things? Discarded constants I suppose? > > > Anyway, seems that the reason for the surprise is that in this case (with a > prototype): > > wtf qw(6 7 8) > > is equivalent to: > > wtf (('6', '7', '8')) > > > > A list (as opposed to an array) in scalar context evaluates the to *last* > element (a bit of another gotcha I happened to already know about). See also: > > perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 > > > perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 > > Note the (absense of) brackets. > > > > At least if you turn warnings on you will get a warning about "useless use of a > constant". > > > > N > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm From bynari at gmail.com Wed Jul 18 06:40:17 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 14:40:17 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006B6E9.6010301@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> Message-ID: <5006BCC1.8070705@gmail.com> Uhhh, whoops, I hit send accidentally too early! I was saying.. You said: wtf qw(6 7 8) is equivalent to: wtf (('6', '7', '8')) That's actually incorrect and wouldn't be important anyway. '6' is 6 as a string, 6 is 6 as a number, they're not strictly the same thing. They're not stored the same internally and perl certainly won't just convert 6 to '6' unless you try to use 6 as a string. The simple answer as to why what happens happens is internally, by prototyping with a scalar you're just causing a $_[0] = qw(6 7 8) to happen. Hope I was clear in my explanation! Regards, Geoff On 18/07/2012 14:15, Nick wrote: > Here's a little off-topic on-topicality to clutter the list up. Excuse me for > answering my own question. I hadn't an answer when I started writing this (so it > served my purpose at least), and I figure I may as well send this. > > > What would you expect this to print? > > perl -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' > > 6 right? > > Nope. > > > > Let's see what Deparse says: > > perl -MO=Deparse -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' > > BEGIN { $/ = "\n"; $\ = "\n"; } > sub wtf ($) { > @_; > } > @a = wtf(('???', '???', '8')); > print @a; > > > WTF are those '???' things? Discarded constants I suppose? > > > Anyway, seems that the reason for the surprise is that in this case (with a > prototype): > > wtf qw(6 7 8) > > is equivalent to: > > wtf (('6', '7', '8')) > > > > A list (as opposed to an array) in scalar context evaluates the to *last* > element (a bit of another gotcha I happened to already know about). See also: > > perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 > > > perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 > > Note the (absense of) brackets. > > > > At least if you turn warnings on you will get a warning about "useless use of a > constant". > > > > N > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm From perl at aaroncrane.co.uk Wed Jul 18 08:05:30 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Wed, 18 Jul 2012 16:05:30 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006B6E9.6010301@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> Message-ID: Nick wrote: > perl -MO=Deparse -le ' sub wtf($) { @_ }; @a = wtf qw(6 7 8); print @a;' > BEGIN { $/ = "\n"; $\ = "\n"; } > sub wtf ($) { > @_; > } > @a = wtf(('???', '???', '8')); > print @a; > > WTF are those '???' things? Discarded constants I suppose? Yes ? bits of the optree that can never be executed, so they were discarded by the optimiser; but there's still a remnant of them hidden away for Deparse to show. > Anyway, seems that the reason for the surprise is that in this case (with a > prototype): > > wtf qw(6 7 8) > > is equivalent to: > > wtf (('6', '7', '8')) Specifically, the $ prototype character, which (because of this gotcha) is almost never useful. (My rules of thumb for prototypes are (a) & and &@ are occasionally useful; (b) you'll need to match the core's prototype if you're overriding a builtin; and (c) shun other uses of prototypes.) > A list (as opposed to an array) in scalar context evaluates the to *last* > element (a bit of another gotcha I happened to already know about). There isn't really any such thing as a list in scalar context, at least in one reasonable analysis of how all this works. Instead, this is about the behaviour of the comma operator: in list context, the comma operator constructs a list, while in scalar context, it discards the operand on its left-hand side and returns the operand on its right-hand side. qw is defined to give you the same behaviour: it yields a list in list context, or the last element in scalar context). My "no list in scalar context" claim may sound like nitpicking, but it matters for code like this: my @x = (10 .. 12); my $y = (6, 7, @x); Given that lists always flatten, treating the assignment to $y as a "list in scalar context" suggests that it would be the same as my $y = (6, 7, 10, 11, 12); which would set $y to 12, as you've discovered. But in fact, the sequence of events is: - scalar-evaluate 6, 7 (by throwing away the 6) - scalar-evaluate 7, @x (by throwing away the 7) - scalar-evaluate @x (by returning its length) - scalar-assign that value (the length of @x) to my $y so $y ends up containing 3, not 12. > perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 > perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 I don't think your first example there shows what you think it does ? the relative precedence of assignment and comma make it identical to perl -le 'sub wtf { (my @a = 6), 7, 8; @a } print wtf' Parenthesising the list (or using qw, which behaves syntactically like a parenthesised term, despite not necessarily having any parens) gives you this: $ perl -le 'sub wtf { my @a = (6, 7, 8); @a } print wtf' 678 -- Aaron Crane ** http://aaroncrane.co.uk/ From perl at aaroncrane.co.uk Wed Jul 18 08:06:38 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Wed, 18 Jul 2012 16:06:38 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006BCC1.8070705@gmail.com> References: <5006B6E9.6010301@letterboxes.org> <5006BCC1.8070705@gmail.com> Message-ID: Jeff Parsons wrote: > You said: > > wtf qw(6 7 8) > > is equivalent to: > > wtf (('6', '7', '8')) > > That's actually incorrect and wouldn't be important anyway. '6' is 6 as a > string, 6 is 6 as a number, they're not strictly the same thing. Hi, Geoff. I'm not sure I understand the point you're making here. The behaviour of qw(6 7 8) is the same as the list '6','7','8' as far as I can tell. In particular, the values you get from qw(6 7 8) are internally treated as strings (unless and until you try to use them as numbers), just as the values in '6','7','8'. With 6,7,8, on the other hand, the values are internally treated as numbers (unless and until you try to use them as strings). You're right, though, that there are relatively few situations where Perl cares about the distinction between the number 6 and the string '6'. You can use Devel::Peek to see the difference: use Devel::Peek 'Dump'; my @q = qw(6 7 8); my @s = ('6', '7', '8'); my @n = (6, 7, 8); Dump(\@q); Dump(\@s); Dump(\@n); -- Aaron Crane ** http://aaroncrane.co.uk/ From bynari at gmail.com Wed Jul 18 10:03:48 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 18:03:48 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: References: <5006B6E9.6010301@letterboxes.org> <5006BCC1.8070705@gmail.com> Message-ID: <5006EC74.5020708@gmail.com> On 18/07/2012 16:06, Aaron Crane wrote: > Jeff Parsons wrote: >> You said: >> >> wtf qw(6 7 8) >> >> is equivalent to: >> >> wtf (('6', '7', '8')) >> >> That's actually incorrect and wouldn't be important anyway. '6' is 6 as a >> string, 6 is 6 as a number, they're not strictly the same thing. > Hi, Geoff. I'm not sure I understand the point you're making here. > Hi, Aaron. :-) The point I was making was that qw(6 7 8) being 'equivalent' to ('6','7','8') wasn't the reason that 8 was returned by the sub as Nick had suggested, or at least I was under the impression he was suggesting. From bynari at gmail.com Wed Jul 18 10:11:09 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 18:11:09 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: References: <5006B6E9.6010301@letterboxes.org> Message-ID: <5006EE2D.2010609@gmail.com> On 18/07/2012 16:05, Aaron Crane wrote: > > There isn't really any such thing as a list in scalar context, at > least in one reasonable analysis of how all this works. Instead, this > is about the behaviour of the comma operator: in list context, the > comma operator constructs a list, while in scalar context, it discards > the operand on its left-hand side and returns the operand on its > right-hand side. > > qw is defined to give you the same behaviour: it yields a list in list > context, or the last element in scalar context). > > My "no list in scalar context" claim may sound like nitpicking, but it > matters for code like this: > > my @x = (10 .. 12); > my $y = (6, 7, @x); > > Given that lists always flatten, treating the assignment to $y as a > "list in scalar context" suggests that it would be the same as > > my $y = (6, 7, 10, 11, 12); > > which would set $y to 12, as you've discovered. But in fact, the > sequence of events is: > > Yeah, I also used the phrase 'list in scalar context', but I thought it was possibly a bit iffy as yes it's actually the *comma operator* in list context or the comma operator in scalar context. Thanks for the example with the array, that really shows clearly why there's definitely no such thing as a 'list in scalar context'! From oinksocket at letterboxes.org Wed Jul 18 10:31:14 2012 From: oinksocket at letterboxes.org (Nick) Date: Wed, 18 Jul 2012 18:31:14 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006BBF8.1070605@gmail.com> References: <5006B6E9.6010301@letterboxes.org> <5006BBF8.1070605@gmail.com> Message-ID: <5006F2E2.1030608@letterboxes.org> Hello, On 18/07/12 14:36, Jeff Parsons wrote: > I'd have expected the 8, yeah. > > It's because there's no such thing as 'array context' in Perl, just scalar > context and list context. Arrays can can be called in either context, but they > themselves are not a context. True, but I think you mentioned 'array context', not me... :) > So really with the single scalar prototype it's just a list in scalar context, > which as I'm sure you know will just store and discard each scalar to the left > of a comma. > > Notice that this is the same as your example: > > perl -le ' sub wtf($) { $_[0] }; @a = wtf (qw(6 7 8)); print @a;' > > So what's really happening is qw(6 7 8) is getting assigned to $_[0] rather than > @_, then the array, @a gets assigned the value of $_[0]. > > The fact that > > wtf qw(6 7 8) > > is equivalent to: > > wtf (('6', '7', '8')) > [...] > That's actually incorrect and wouldn't be important anyway. '6' is 6 as a > string, 6 is 6 as a number, they're not strictly the same thing. They're not > stored the same internally and perl certainly won't just convert 6 to '6' > unless you try to use 6 as a string. To be honest, the quotes were an afterthought. The real point of that example is the double brackets. wtf(6, 7, 8) gets a compilation error. wtf((6, 7, 8)) does not. And wtf qw(6 7 8) does not either, because of a diabolical combination of Perl's grammar rules. In agreement with General Wisdom, I also tend not to use prototypes, except perhaps things like (&@). However in this case I was attempting to use the ($) prototype to try and force a function not to be "greedy", and instead consume just one single argument. The application is a configuration language - I'm trying to warp Perl into a DSL. # (checks and balances elided) sub with($) { bless $_[0], 'With' } sub without($) { bless $_[0], 'Without' } sub combination { ... } # ... my $combination = combination ( with [qw(toast eggs)], without ['gluten'], with [qw(sauce)], ); I could lose the square brackets and the prototypes and wrap everything in brackets to coerce the functions to eat the right things: with (qw(toast eggs)), without('gluten'), with(qw(sauce)) But I wanted it to be robust so that if the brackets were forgotten, things would fail safely rather than grouping in unintended ways. (No, I'm not convinced my alternative is entirely better, but... this is an experiment.) Also in the name of robustness, I want to highlight potential accidental misuses of 'with' and 'without', such like this: combine with qw(toast egg), without qw(gluten); # Error: 'toast' not eaten Bad syntax should fail instead of doing something surprising. Except to my annoyance, this gave me something even more surprising as discussed: my $stuff = combine with qw(toast eggs), without qw(gluten); Here, 'with' gets 'eggs', but 'toast' gets discarded on the floor, a somewhat obscure warning about void context gets printed, and things charge onwards to disappointment and/or disaster. Not good. > The simple answer as to why what happens happens is internally, by prototyping > with a scalar you're just causing a > > $_[0] = qw(6 7 8) to happen. > > > Hope I was clear in my explanation! Thanks - I think I do understand what's happening retrospectively - it was a mostly rhetorical post - but the design of the grammar perplexes me somewhat - that and its ability to trip me up in cases like this (and I'm not new to Perl by any means). Cheers, N ps > Regards, > Geoff You seem to be both Geoff and Jeff simultaneously? From oinksocket at letterboxes.org Wed Jul 18 10:32:07 2012 From: oinksocket at letterboxes.org (Nick) Date: Wed, 18 Jul 2012 18:32:07 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: References: <5006B6E9.6010301@letterboxes.org> Message-ID: <5006F317.9000907@letterboxes.org> On 18/07/12 16:05, Aaron Crane wrote: >> A list (as opposed to an array) in scalar context evaluates the to *last* >> element (a bit of another gotcha I happened to already know about). > > There isn't really any such thing as a list in scalar context, at > least in one reasonable analysis of how all this works. Instead, this > is about the behaviour of the comma operator: in list context, the > comma operator constructs a list, while in scalar context, it discards > the operand on its left-hand side and returns the operand on its > right-hand side. > > qw is defined to give you the same behaviour: it yields a list in list > context, or the last element in scalar context). > > My "no list in scalar context" claim may sound like nitpicking, but it > matters for code like this: > > my @x = (10 .. 12); > my $y = (6, 7, @x); > > Given that lists always flatten, treating the assignment to $y as a > "list in scalar context" suggests that it would be the same as > > my $y = (6, 7, 10, 11, 12); > > which would set $y to 12, as you've discovered. But in fact, the > sequence of events is: > > - scalar-evaluate 6, 7 (by throwing away the 6) > - scalar-evaluate 7, @x (by throwing away the 7) > - scalar-evaluate @x (by returning its length) > - scalar-assign that value (the length of @x) to my $y > > so $y ends up containing 3, not 12. Yes indeed, another potential surprise. I hadn't thought of it in terms of the "comma operator", and in fact I don't normally consider it an operator so much as a piece of delimiting syntax. I'll try and remember to. I confess I don't find this particular behaviour of commas very useful in practise, and it has the side-effect of the surprising behaviour we're discussing. I'm trying and failing to think of a case where it helps. Can you think of one? >> perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 >> perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 > > I don't think your first example there shows what you think it does ? > the relative precedence of assignment and comma make it identical to > > perl -le 'sub wtf { (my @a = 6), 7, 8; @a } print wtf' Actually, that is in fact what I understood it to mean. This example was meant to show another case where the grammar rules are (in my opinion) surprising, even having learnt them. When would I ever want to silently discard the terms 7 and 8 like this? It seems more practical to either a) have Perl "DWIM" (and assign the values to the list), or perhaps preferably, b) generate a syntax error (so I can alter it to be less ambiguous). If I really wanted to have the terms 7 and 8 evaluated and the result discarded (perhaps with some side effect) I would probably use semi-colons, not commas. N From bynari at gmail.com Wed Jul 18 11:12:47 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 19:12:47 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006F2E2.1030608@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> <5006BBF8.1070605@gmail.com> <5006F2E2.1030608@letterboxes.org> Message-ID: <5006FC9F.3060800@gmail.com> On 18/07/2012 18:31, Nick wrote: > > True, but I think you mentioned 'array context', not me... :) I was just pointing that out as a reminder in case you didn't know. :-) I didn't think you were new to Perl, but sometimes people do think there's an array context. > > > To be honest, the quotes were an afterthought. The real point of that example is > the double brackets. wtf(6, 7, 8) gets a compilation error. wtf((6, 7, 8)) > does not. And wtf qw(6 7 8) does not either, because of a diabolical combination > of Perl's grammar rules. Ah right, it gets a compilation error, yeah, that makes sense. Really what we have is the comma operator in scalar context, thus producing the 8 just like $foo = (6, 7, 8). > In agreement with General Wisdom, I also tend not to use prototypes, except > perhaps things like (&@). However in this case I was attempting to use the ($) > prototype to try and force a function not to be "greedy", and instead consume > just one single argument. The application is a configuration language - I'm > trying to warp Perl into a DSL. > > # (checks and balances elided) > sub with($) { bless $_[0], 'With' } > sub without($) { bless $_[0], 'Without' } > sub combination { ... } > > # ... > > my $combination = combination ( > with [qw(toast eggs)], > without ['gluten'], > with [qw(sauce)], > ); > > I could lose the square brackets and the prototypes and wrap everything in > brackets to coerce the functions to eat the right things: > > with (qw(toast eggs)), without('gluten'), with(qw(sauce)) > > But I wanted it to be robust so that if the brackets were forgotten, things > would fail safely rather than grouping in unintended ways. (No, I'm not > convinced my alternative is entirely better, but... this is an experiment.) > > Also in the name of robustness, I want to highlight potential accidental misuses > of 'with' and 'without', such like this: > > combine with qw(toast egg), without qw(gluten); # Error: 'toast' not eaten > > Bad syntax should fail instead of doing something surprising. Except to my > annoyance, this gave me something even more surprising as discussed: > > my $stuff = combine with qw(toast eggs), without qw(gluten); > > Here, 'with' gets 'eggs', but 'toast' gets discarded on the floor, a somewhat > obscure warning about void context gets printed, and things charge onwards to > disappointment and/or disaster. Not good. Eek. Robustness isn't about stopping other programmers from making syntax errors. Robustness generally is where software will catch a lot of issues and do plenty of checks. Ie, software that's not robust just makes a whole bunch of assumptions about the data it's working with, then things can just mysteriously go wrong. Robust software checks *everything* and then informs the user/programmer if it has something it didn't expect. Robustness is for preventing the programmers/users from misusing an interface, not for preventing them from making syntax errors. If a programmer using your interface forgets brackets then I think they're going to have a whole bunch of problems beyond the scope of what you're trying to prevent!! :-) Gosh, they'd have to be pretty new to Perl to do "combine with toast egg, without gluten;" If someone's doing that then they need to hit the Perl books at chapter 1! Your module will be more robust by having the checks that you can't have toast without gluten(Although you actually can have gluten-free bread, lol!) You should only develop with an intention to prevent programmers from passing incorrect/incompatible things to your interface, not things to prevent them from making potential syntax errors. Definitely just stick with passing a list then shift'ing in the method. An arrayref is superfluous. You'd only ever want to use an arrayref if you wanted to separate out 2 lists. I'm sure you already know that though, but I'll just state it anyway. :) >> Regards, >> Geoff > You seem to be both Geoff and Jeff simultaneously? > > Yes, indeed. I'm magical. :-) From bynari at gmail.com Wed Jul 18 11:26:33 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 19:26:33 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006F317.9000907@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> <5006F317.9000907@letterboxes.org> Message-ID: <5006FFD9.6060503@gmail.com> On 18/07/2012 18:32, Nick wrote: > Yes indeed, another potential surprise. I hadn't thought of it in terms of the > "comma operator", and in fact I don't normally consider it an operator so much > as a piece of delimiting syntax. I'll try and remember to. > > I confess I don't find this particular behaviour of commas very useful in > practise, and it has the side-effect of the surprising behaviour we're > discussing. I'm trying and failing to think of a case where it helps. Can you > think of one? > I personally can't think of a reason when comma operator in scalar context's behaviour is useful, but A) I'm sure there is and B) Perl is all about flexibility and freedom. It's what gives Perl its power but also makes it trickier than other languages like Python. Perl in terms of what you can do is the most powerful out of python/ruby/perl. There's things Perl can do that python/ruby can't like a program modifying its own op tree. It's Perl's flexibility and power that gives us coolness like Moose and MooseX::Declare or even perl5i, which I used to use, but decided not to now. perl5i is still extremely cool though. :-) >>> perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 >>> perl -le 'sub wtf { my $a = (6, 7, 8); $a }; print wtf;' # -> 8 >> I don't think your first example there shows what you think it does ? >> the relative precedence of assignment and comma make it identical to >> >> perl -le 'sub wtf { (my @a = 6), 7, 8; @a } print wtf' > Actually, that is in fact what I understood it to mean. This example was meant > to show another case where the grammar rules are (in my opinion) surprising, > even having learnt them. When would I ever want to silently discard the terms 7 > and 8 like this? It seems more practical to either > > a) have Perl "DWIM" (and assign the values to the list), > > or perhaps preferably, > > b) generate a syntax error (so I can alter it to be less ambiguous). > > If I really wanted to have the terms 7 and 8 evaluated and the result discarded > (perhaps with some side effect) I would probably use semi-colons, not commas. > > the warnings pragma will warn you of this. :-) You'd never do something like @foo = 6, 7, 8 though. It wouldn't be practical for Perl to try to work out every case of "weirdness" and report a syntax error, since it's not a definition, just weirdness. That's what warnings is for though, but warnings is also not just for syntax-weirdness like this, but to help spot bugs where you *think* a value has been filled when really it's not etc. From bynari at gmail.com Wed Jul 18 11:45:46 2012 From: bynari at gmail.com (Jeff Parsons) Date: Wed, 18 Jul 2012 19:45:46 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: References: <5006B6E9.6010301@letterboxes.org> <5006BCC1.8070705@gmail.com> Message-ID: <5007045A.6020203@gmail.com> On 18/07/2012 16:06, Aaron Crane wrote: > > > > You can use Devel::Peek to see the difference: > > use Devel::Peek 'Dump'; > my @q = qw(6 7 8); > my @s = ('6', '7', '8'); > my @n = (6, 7, 8); > Dump(\@q); > Dump(\@s); > Dump(\@n); > Oh and yeah.. I see even when you quote the number it's still just stored as an IV until it's used as a string and then it creates the PV so you're left with both an IV and PV.. That makes sense. Cool. :-) It would be inefficient to immediately create an extra pointer and assign memory on the off-chance the programmer intends to use the number as a string. Best to wait until he actually *does* use it as a string. Thanks! You seem extremely knowledgeable beyond the usual geek-level knowledge! Nice to have a super-geek locally in Scotland! :-) From miles at assyrian.org.uk Wed Jul 18 12:52:38 2012 From: miles at assyrian.org.uk (Miles Gould) Date: Wed, 18 Jul 2012 20:52:38 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006FC9F.3060800@gmail.com> References: <5006B6E9.6010301@letterboxes.org> <5006BBF8.1070605@gmail.com> <5006F2E2.1030608@letterboxes.org> <5006FC9F.3060800@gmail.com> Message-ID: <50071406.8020501@assyrian.org.uk> On 18/07/12 19:12, Jeff Parsons wrote: > Eek. Robustness isn't about stopping other programmers from making > syntax errors. Robustness generally is where software will catch a lot > of issues and do plenty of checks. Ie, software that's not robust just > makes a whole bunch of assumptions about the data it's working with, > then things can just mysteriously go wrong. Robust software checks > *everything* and then informs the user/programmer if it has something it > didn't expect. Robustness is for preventing the programmers/users from > misusing an interface, not for preventing them from making syntax errors. Nick's thinking like a language designer: from that perspective, syntax errors in user code *are* assumption-violations, which the user should be informed about :-) Miles From perl at aaroncrane.co.uk Thu Jul 19 04:06:15 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Thu, 19 Jul 2012 12:06:15 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006F2E2.1030608@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> <5006BBF8.1070605@gmail.com> <5006F2E2.1030608@letterboxes.org> Message-ID: Nick wrote: > But I wanted it to be robust so that if the brackets were forgotten, things > would fail safely rather than grouping in unintended ways. (No, I'm not > convinced my alternative is entirely better, but... this is an experiment.) > > Also in the name of robustness, I want to highlight potential accidental misuses > of 'with' and 'without', such like this: > > combine with qw(toast egg), without qw(gluten); # Error: 'toast' not eaten Yeah; as you've learned, there's no good way to make that behave in an obviously reliable and unsurprising way. Which is sad. Here's an alternative API possibility: require the caller to use a single array ref instead of a list of arguments: combine with [qw(toast egg)], without ['gluten']; You might well point out that, at least aesthetically, this is no improvement over requiring parens round the arguments. But it does have the advantage that your with() and without() definitions can (a) use the ($) prototype to force unary-op parsing, and (b) throw an exception if you call them with something that isn't an array ref (because that's the case that doesn't allow the caller to make it clear to the callee that they understood the grouping rules). Further, you can alleviate the punctuational burden by applying a module like Syntax::Feature::Qwa: use syntax 'qwa'; combine with qwa(toast egg), without qwa(gluten); S::F::Qwa uses Devel::Declare under the hood; effectively, the qwa behaves like a qw, but wraps an array-ref constructor round the qw list. If that still doesn't give you something sufficiently low-ceremony to use as an embedded DSL, your next best option is probably to write things like with() and without() as Devel::Declare-parsed routines themselves. I've never tried that sort of thing, though. > Bad syntax should fail instead of doing something surprising. Except to my > annoyance, this gave me something even more surprising as discussed: > > my $stuff = combine with qw(toast eggs), without qw(gluten); > > Here, 'with' gets 'eggs', but 'toast' gets discarded on the floor, a somewhat > obscure warning about void context gets printed, and things charge onwards to > disappointment and/or disaster. Not good. I agree entirely. Here's a sneaky approach: force your callers to have void-context warnings upgraded to fatal exceptions. You can do that by having your module's import method call warnings->import(FATAL => 'void'); it will get invoked on behalf of the `use`-ing code. It's slightly awkward to do that without breaking normal Exporter stuff, but here's one way; package Sneaky; use strict; use warnings; use Exporter qw; our @EXPORT_OK = ...; # fill this in as normal # Now modify the import() you've imported from Exporter: use Class::Method::Modifiers qw; before import => sub { warnings->import(FATAL => 'void') }; 1; That won't accomplish anything if someone uses Sneaky without letting it import anything, but I think I'd be happy to ignore that possibility, on the grounds that such a person probably knows what they're doing. -- Aaron Crane ** http://aaroncrane.co.uk/ From perl at aaroncrane.co.uk Thu Jul 19 04:06:24 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Thu, 19 Jul 2012 12:06:24 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006F317.9000907@letterboxes.org> References: <5006B6E9.6010301@letterboxes.org> <5006F317.9000907@letterboxes.org> Message-ID: Nick wrote: > Yes indeed, another potential surprise. I hadn't thought of it in terms of the > "comma operator", and in fact I don't normally consider it an operator so much > as a piece of delimiting syntax. I'll try and remember to. > > I confess I don't find this particular behaviour of commas very useful in > practise, and it has the side-effect of the surprising behaviour we're > discussing. I'm trying and failing to think of a case where it helps. Can you > think of one? No, I can't. I think the reason Perl 5 behaves this way is that it misguidedly imports C's comma operator pretty much wholesale, then tweaks it for Perl's notion of context. In C, the comma operator turns out to be helpful for things like the three-part `for` loop, so that you can put multiple expressions in a slot that syntactically accepts only one. But Perl has do{} to help with that, and makes much less use of three-part `for` anyway. It's telling that things don't work this way in Perl 6, I think. >>> perl -le 'sub wtf { my @a = 6, 7, 8; @a }; print wtf;' # -> 6 >> >> I don't think your first example there shows what you think it does ? >> the relative precedence of assignment and comma make it identical to >> >> perl -le 'sub wtf { (my @a = 6), 7, 8; @a } print wtf' > > Actually, that is in fact what I understood it to mean. This example was meant > to show another case where the grammar rules are (in my opinion) surprising, > even having learnt them. When would I ever want to silently discard the terms 7 > and 8 like this? Ah, right, I see what you mean. And, yes, I agree: `my @a = 6,7,8` ought to do what it looks like it does. Larry agrees too, it turns out; Perl 6 adjusts the precedence levels (and a whole lot of other things) to make that work. -- Aaron Crane ** http://aaroncrane.co.uk/ From perl at aaroncrane.co.uk Thu Jul 19 04:06:30 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Thu, 19 Jul 2012 12:06:30 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006FC9F.3060800@gmail.com> References: <5006B6E9.6010301@letterboxes.org> <5006BBF8.1070605@gmail.com> <5006F2E2.1030608@letterboxes.org> <5006FC9F.3060800@gmail.com> Message-ID: Jeff Parsons wrote: > Eek. Robustness isn't about stopping other programmers from making syntax > errors. Well, it's certainly not entirely about that. But an API that's hard to misuse and easy to use correctly is a great boon when trying to build and maintain systems that must behave as intended. And, as Nick's observed, it's all too easy for something like `sub with ($) { ... }` to be accidentally misused in ways that aren't easy to detect in either the caller or the callee. -- Aaron Crane ** http://aaroncrane.co.uk/ From perl at aaroncrane.co.uk Thu Jul 19 04:06:35 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Thu, 19 Jul 2012 12:06:35 +0100 Subject: [Edinburgh-pm] a Perl surprise In-Reply-To: <5006FFD9.6060503@gmail.com> References: <5006B6E9.6010301@letterboxes.org> <5006F317.9000907@letterboxes.org> <5006FFD9.6060503@gmail.com> Message-ID: Jeff Parsons wrote: > You'd never do something like @foo = 6, 7, 8 though. An experienced Perl programmer probably wouldn't, it's true. But sometimes people make mistakes. And not all APIs are aimed solely at experienced programmers. -- Aaron Crane ** http://aaroncrane.co.uk/ From miles at assyrian.org.uk Thu Jul 19 08:54:14 2012 From: miles at assyrian.org.uk (Miles Gould) Date: Thu, 19 Jul 2012 16:54:14 +0100 Subject: [Edinburgh-pm] Young Rewired State Message-ID: <50082DA6.4090405@assyrian.org.uk> So I've just had to pull out of being a mentor for Young Rewired State's Festival of Code (a hackathon, based around the idea of open data, for kids) on the 6th-12th August. Debbie from YRS tells me that they currently have *zero* mentors in Scotland, which means they'll probably have to cancel the Edinburgh and Glasgow centres. Can any of you help? More info at http://youngrewiredstate.org/, or call Debbie (ping me off-list for her mobile number). If so, please sign up soon, for values of "soon" being roughly "today". Please feel free to spread this more widely! Miles From miles at assyrian.org.uk Thu Jul 19 08:55:46 2012 From: miles at assyrian.org.uk (Miles Gould) Date: Thu, 19 Jul 2012 16:55:46 +0100 Subject: [Edinburgh-pm] Young Rewired State In-Reply-To: <50082DA6.4090405@assyrian.org.uk> References: <50082DA6.4090405@assyrian.org.uk> Message-ID: <50082E02.5060503@assyrian.org.uk> Sorry, I should have explained that you don't have to commit for the full week! You can do some days and not others. Miles From perl at minty.org Mon Jul 23 03:22:10 2012 From: perl at minty.org (Murray) Date: Mon, 23 Jul 2012 11:22:10 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder Message-ID: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) onwards. Who's in? From cyocum at gmail.com Mon Jul 23 03:26:11 2012 From: cyocum at gmail.com (Chris Yocum) Date: Mon, 23 Jul 2012 11:26:11 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: <20120723102610.GF11232@gmail.com> On Mon, Jul 23, 2012 at 11:22:10AM +0100, Murray wrote: > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) > onwards. > > Who's in? > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm I am not feeling very well at the moment but that may change by Thursady so count me in but I am probably not in for a heavy night. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From miles at assyrian.org.uk Mon Jul 23 05:26:37 2012 From: miles at assyrian.org.uk (Miles Gould) Date: Mon, 23 Jul 2012 13:26:37 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: <500D42FD.4070308@assyrian.org.uk> On 23/07/12 11:22, Murray wrote: > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) > onwards. > > Who's in? I'll still be in Ali G country, alas. Have fun. Miles PS my fucking L key is mafunctioning. I'm a vi user. This is realy annoying. From anthony.randell at gmail.com Mon Jul 23 05:52:31 2012 From: anthony.randell at gmail.com (Anthony Randell) Date: Mon, 23 Jul 2012 13:52:31 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: Hope to make it, been a while so nice to catch up. Probably will be late-ish, 7:30 or so. On 23 July 2012 11:22, Murray wrote: > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) > onwards. > > Who's in? > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm From asmith9983 at gmail.com Mon Jul 23 06:45:15 2012 From: asmith9983 at gmail.com (A Smith) Date: Mon, 23 Jul 2012 14:45:15 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: I'll probably be along 7:30ish too. -- Andrew On 23 July 2012 13:52, Anthony Randell wrote: > Hope to make it, been a while so nice to catch up. > > Probably will be late-ish, 7:30 or so. > > On 23 July 2012 11:22, Murray wrote: > > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 > (ish) > > onwards. > > > > Who's in? > > _______________________________________________ > > Edinburgh-pm mailing list > > Edinburgh-pm at pm.org > > http://mail.pm.org/mailman/listinfo/edinburgh-pm > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perl at aaroncrane.co.uk Tue Jul 24 03:05:14 2012 From: perl at aaroncrane.co.uk (Aaron Crane) Date: Tue, 24 Jul 2012 11:05:14 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: Murray wrote: > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) > onwards. Who's in? Not sure I'll be able to make it this month, but I'll give it a shot. -- Aaron Crane ** http://aaroncrane.co.uk/ From wim.vanderbauwhede at gmail.com Wed Jul 25 16:52:13 2012 From: wim.vanderbauwhede at gmail.com (Wim Vanderbauwhede) Date: Thu, 26 Jul 2012 08:52:13 +0900 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: I'm in Japan at the moment, so I'll have to pass. Cheers, Wim PS: If you like, pics from Japan at http://wim-v12e.tumblr.com/ On 24 July 2012 19:05, Aaron Crane wrote: > Murray wrote: > > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 > (ish) > > onwards. Who's in? > > Not sure I'll be able to make it this month, but I'll give it a shot. > > -- > Aaron Crane ** http://aaroncrane.co.uk/ > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm > -- If it's pointless, what's the point? If there is a point to it, what's the point? (Tibor Fischer, "The Thought Gang") -------------- next part -------------- An HTML attachment was scrubbed... URL: From alisdair at tullo.me.uk Thu Jul 26 09:29:02 2012 From: alisdair at tullo.me.uk (Alisdair Tullo) Date: Thu, 26 Jul 2012 17:29:02 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: <5011704E.5030005@tullo.me.uk> Hi all, My new job appears to involve some Perl-monging so I'm planning to come along and introduce myself tonight. I may recognise one or two of you (hi Chris!). Just in case, do you have a secret Perl identifier, e.g. a big camel picture? Anyway, will probably head down for ~19h30, maybe a bit earlier to get food since I'm coming straight from work. Cheers, Alisdair From perl at minty.org Thu Jul 26 09:49:01 2012 From: perl at minty.org (Murray) Date: Thu, 26 Jul 2012 17:49:01 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <5011704E.5030005@tullo.me.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> <5011704E.5030005@tullo.me.uk> Message-ID: <20120726164855.GY30699@mooker.vm.bytemark.co.uk> On Thu, Jul 26, 2012 at 05:29:02PM +0100, Alisdair Tullo wrote: > Just in case, do you have a secret Perl > identifier, e.g. a big camel picture? hey -- cool -- welcome! We'll bring a copy of http://www.amazon.co.uk/dp/0596004761/ along and place it on our table. (It's an O'Reilly book, with a Badger on the front, titled "Perl Template Toolkit") From fontani at gmail.com Thu Jul 26 09:57:11 2012 From: fontani at gmail.com (Marco Fontani) Date: Thu, 26 Jul 2012 17:57:11 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120726164855.GY30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> <5011704E.5030005@tullo.me.uk> <20120726164855.GY30699@mooker.vm.bytemark.co.uk> Message-ID: <20120726165711.GA11476@gmail.com> > Just in case, do you have a secret Perl identifier, e.g. a big camel picture? What coincidence! I was reading the other day about a "new" pod page I happened to have stumbled upon. It turns out, there are a *lot* of secret identifiers in Perl! https://github.com/book/perlsecret/blob/master/lib/perlsecret.pod I think we should be prepared for next time we have a similar problem, and bring a print-out of the Flaming X-Wing to be put on our table? @data{@fields} =< $luke >=~ $regexp; I don't think that'd attract people to come to our meetings, though. The badger on the TT book is probably for the best. See you later! -marco- -- Marco Fontani Glasgow Perl Mongers - http://glasgow.pm.org/ Bitcoin: 1QA1K3Ghz9AuJ8na6JKJVudEko3WKx1xC2 Join the RackSpace Cloud at: http://www.rackspacecloud.com/277.html From fontani at gmail.com Thu Jul 26 10:41:02 2012 From: fontani at gmail.com (Marco Fontani) Date: Thu, 26 Jul 2012 18:41:02 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120726165711.GA11476@gmail.com> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> <5011704E.5030005@tullo.me.uk> <20120726164855.GY30699@mooker.vm.bytemark.co.uk> <20120726165711.GA11476@gmail.com> Message-ID: We are at the Cumberland, first room to the right after the bar. Look for the TT book on a table there. On Jul 26, 2012 5:57 PM, "Marco Fontani" wrote: > > Just in case, do you have a secret Perl identifier, e.g. a big camel > picture? > > What coincidence! I was reading the other day about a "new" pod page I > happened to have stumbled upon. It turns out, there are a *lot* of > secret identifiers in Perl! > > https://github.com/book/perlsecret/blob/master/lib/perlsecret.pod > > I think we should be prepared for next time we have a similar problem, > and bring a print-out of the Flaming X-Wing to be put on our table? > > @data{@fields} =< $luke >=~ $regexp; > > I don't think that'd attract people to come to our meetings, though. > The badger on the TT book is probably for the best. > > See you later! > -marco- > > -- > Marco Fontani > Glasgow Perl Mongers - http://glasgow.pm.org/ > Bitcoin: 1QA1K3Ghz9AuJ8na6JKJVudEko3WKx1xC2 > Join the RackSpace Cloud at: http://www.rackspacecloud.com/277.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.randell at gmail.com Thu Jul 26 10:47:43 2012 From: anthony.randell at gmail.com (Anthony Randell) Date: Thu, 26 Jul 2012 18:47:43 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120726165711.GA11476@gmail.com> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> <5011704E.5030005@tullo.me.uk> <20120726164855.GY30699@mooker.vm.bytemark.co.uk> <20120726165711.GA11476@gmail.com> Message-ID: Awesome - love the kite. Sadly not going to make it tonight after all, due to sadness of working. Hopefully will manage next time, enjoy the beer! On 26 July 2012 17:57, Marco Fontani wrote: >> Just in case, do you have a secret Perl identifier, e.g. a big camel picture? > > What coincidence! I was reading the other day about a "new" pod page I > happened to have stumbled upon. It turns out, there are a *lot* of > secret identifiers in Perl! > > https://github.com/book/perlsecret/blob/master/lib/perlsecret.pod > > I think we should be prepared for next time we have a similar problem, > and bring a print-out of the Flaming X-Wing to be put on our table? > > @data{@fields} =< $luke >=~ $regexp; > > I don't think that'd attract people to come to our meetings, though. > The badger on the TT book is probably for the best. > > See you later! > -marco- > > -- > Marco Fontani > Glasgow Perl Mongers - http://glasgow.pm.org/ > Bitcoin: 1QA1K3Ghz9AuJ8na6JKJVudEko3WKx1xC2 > Join the RackSpace Cloud at: http://www.rackspacecloud.com/277.html > _______________________________________________ > Edinburgh-pm mailing list > Edinburgh-pm at pm.org > http://mail.pm.org/mailman/listinfo/edinburgh-pm From robrwo at gmail.com Thu Jul 26 10:48:44 2012 From: robrwo at gmail.com (Robert Rothenberg) Date: Thu, 26 Jul 2012 18:48:44 +0100 Subject: [Edinburgh-pm] Monthly Beer Reminder In-Reply-To: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> References: <20120723102209.GG30699@mooker.vm.bytemark.co.uk> Message-ID: <501182FC.4020603@gmail.com> On 23/07/12 11:22 Murray wrote: > Thursday 26th July ... 4th of the month ... cumberlandbar.co.uk 6.30 (ish) > onwards. > > Who's in? Probably not me.