2009/1/27 Frank Gutierrez :
> Can you stream them or post a video online?
Slides will be made available afterwards.
Leon
2009/1/28 Léon Brocard :
> 2009/1/27 Frank Gutierrez :
>> Can you stream them or post a video online?
>
> Slides will be made available afterwards.
Speaking of videos - does anybody have an ETA for the LPW videos being
available.
The nice people behind yapc.tv made it pretty easy for me to upload
Edmund von der Burg wrote:
2009/1/27 Dirk Koopman :
Oh B*gg*r. Clashes with my chainsaw course and I shall be too erm.. tired to
get up to London and back for the following day's gruelling cutting and
moving wood (who needs a gym subscription when one has small wood to
manage).
Chainsaw course
On Wednesday 28 January 2009 09:53:16 Nicholas Clark wrote:
> On Wed, Jan 28, 2009 at 12:10:01AM +, Edmund von der Burg wrote:
> > use the spikes to pivot the blade through the wood. NEVER cut using
> > the top of the blade. (That last bit is actually important).
>
> I'm guessing that there's m
On Tue, Jan 27, 2009 at 10:27:34PM +0100, Philippe Bruhat (BooK) wrote:
> On Tue, Jan 27, 2009 at 07:48:34AM -0800, Ovid wrote:
> >
> > That being said, much OO code is very poorly written.
> >
> > But it's not really the fault of the programmers. I don't see a hell of
> > a lot of stuff out t
2009/1/28 Dirk Koopman :
> Edmund von der Burg wrote:
>> What sort of woodsman are you to accept formal training?
>
> A careful one that wants some insurance and wants to learn how to do it
> properly and get some qualifications.
I applaud you. Anything involving petrol engines and moving blades
d
- Original Message
> From: Philippe Bruhat (BooK)
> Where do we learn about that? Are there some OO tutorials planned at the
> next YAPC?
>
> Every time I write a new CPAN module, I first have to decide on how I'm
> going to do OO this time.
Rather than focusing on advanced tools and
2009/1/28 Simon Cozens :
> Ovid wrote:
>> Rather than focusing on advanced tools and modules, I'd focus on
>> advanced techniques.
>
> I've had this debate a hundred times over since sitting down to
> write APP2ed: these days Perl programming is much more about using
> tools well than using the lan
Ovid wrote:
> Rather than focusing on advanced tools and modules, I'd focus on
> advanced techniques.
I've had this debate a hundred times over since sitting down to
write APP2ed: these days Perl programming is much more about using
tools well than using the language particularly creatively. The
t
On Wed, Jan 28, 2009 at 12:10 AM, Edmund von der Burg
wrote:
> 2009/1/27 Dirk Koopman :
>> Oh B*gg*r. Clashes with my chainsaw course and I shall be too erm.. tired to
>> get up to London and back for the following day's gruelling cutting and
>> moving wood (who needs a gym subscription when one h
On Wed, Jan 28, 2009 at 8:31 AM, Léon Brocard wrote:
> 2009/1/27 Frank Gutierrez :
>> Can you stream them or post a video online?
>
> Slides will be made available afterwards.
Well, some of 'em will be. I don't expect my slides to be all that
illuminating without the accompanying chat.
- Original Message
> From: Simon Cozens
> I've had this debate a hundred times over since sitting down to
> write APP2ed: these days Perl programming is much more about using
> tools well than using the language particularly creatively. The
> techniques you need to know are how to use t
Whoever said, the primary purpose of a compiler is to check for
errors,
and only if there are no errors, create the code, was most
definitely not talking about Perl.
The next time I use == instead of eq to compare two strings, I
will know to expect it will always
On Wed, Jan 28, 2009 at 10:51:11AM +, Piers Cawley wrote:
> On Wed, Jan 28, 2009 at 12:10 AM, Edmund von der Burg
> > Chainsawing is easy: keep the chain sharp and tight, top up petrol and
> > chain oil before you run out, rev the engine before touching the wood,
> > use the spikes to pivot th
Piers Cawley wrote:
On Wed, Jan 28, 2009 at 12:10 AM, Edmund von der Burg
wrote:
2009/1/27 Dirk Koopman :
Oh B*gg*r. Clashes with my chainsaw course and I shall be too erm.. tired to
get up to London and back for the following day's gruelling cutting and
moving wood (who needs a gym subscripti
On 28 Jan 2009, at 10:56, Jonathan Kimmitt wrote:
Whoever said, the primary purpose of a compiler is to check for
errors,
and only if there are no errors, create the code, was most
definitely not talking about Perl.
The next time I use == instead of eq to compar
On 28 Jan 2009, at 10:56, Jonathan Kimmitt wrote:
It would be a trivial matter to return an error or warning if ==
is used for items which aren't numbers
You mean like the one emitted if you happen to have "use warnings" at
the top of your code?
Now obviously perl should emit an error if
On Wed, Jan 28, 2009 at 10:56 AM, Jonathan Kimmitt
wrote:
>Whoever said, the primary purpose of a compiler is to check for
> errors,
>and only if there are no errors, create the code, was most
> definitely not talking about Perl.
>
>The next time I use == instead of eq to c
2009/1/28 Jonathan Kimmitt :
>Whoever said, the primary purpose of a compiler is to check for
> errors,
>and only if there are no errors, create the code, was most
> definitely not talking about Perl.
>
>The next time I use == instead of eq to compare two strings, I
> will k
- Original Message
> From: Jonathan Kimmitt
> The next time I use == instead of eq to compare two strings, I
> will know to expect it will always
> evaluate to true. What other language does this (apart from C,
> which would invariably return false)
> ld be a trivial matter to r
On Wed, Jan 28, 2009 at 10:56:41AM -, Jonathan Kimmitt wrote:
> It would be a trivial matter to return an error or warning if ==
> is used for items which aren't numbers
>
> And this is in a language which is praised for its powerful
> string handling !
Um, it does throw a
On Wed, Jan 28, 2009 at 10:56 AM, Jonathan Kimmitt
wrote:
>The next time I use == instead of eq to compare two strings, I
> will know to expect it will always
>evaluate to true. What other language does this (apart from C,
> which would invariably return false)
PHP, which does it
Jonathan Kimmitt wrote:
Whoever said, the primary purpose of a compiler is to check for
errors,
and only if there are no errors, create the code, was most
definitely not talking about Perl.
The next time I use == instead of eq to compare two strings, I
will know to expect it
On Wed, Jan 28, 2009 at 11:23 AM, Piers Cawley
wrote:
> On Wed, Jan 28, 2009 at 10:56 AM, Jonathan Kimmitt
> wrote:
>>Whoever said, the primary purpose of a compiler is to check for
>> errors,
>>and only if there are no errors, create the code, was most
>> definitely not talking a
2009/1/28 Jonathan Kimmitt :
>
>The next time I use == instead of eq to compare two strings, I
> will know to expect it will always
>evaluate to true. What other language does this (apart from C,
> which would invariably return false)
Unfortunately, this is perl being helpful. Beca
On Wed, Jan 28, 2009 at 11:10 AM, Dirk Koopman wrote:
> Strangely, not kevlar. Actually the protection is provided by what is
> effectively a 1 cm duvet on the front of one's legs (and top of the left
> hand). The idea is that the fine fibre contained therein instantly snarls up
> the chain, stopp
Hello! The February social of the London Perl Mongers is next
Thursday, 5th February 2009. We're going back to the Bridge House,
which is the Adnams place at the south end of Tower Bridge. We have
the upstairs function room booked from 6:30pm.
It's a short walk from both London Bridge and Tower H
On Wed, Jan 28, 2009 at 11:23 AM, Piers Cawley
wrote:
> Actually, I was surprised to find that there isn't a warning for that
> with warnings turned on. Memory proving faulty.
Am I missing something? If I put
if ( $foo == "really" )
Into a script with strict and warnings I get
Argument "really
On Wed, Jan 28, 2009 at 11:31 AM, Dominic Thoreau
wrote:
> 2009/1/28 Jonathan Kimmitt :
>>
>>The next time I use == instead of eq to compare two strings, I
>> will know to expect it will always
>>evaluate to true.
Interesting that everyone's said to "use warnings" but no-one's
que
On Wed, Jan 28, 2009 at 11:31:37AM +, Dominic Thoreau wrote:
> Eg string concatenation in perl is with the . (dot) operator. In some
> other well used languages (Java, for example) the + operator is used,
> which is an overloading of the addition operator.
> I'm taking a series of courses in
On 28 Jan 2009, at 10:56, Jonathan Kimmitt wrote:
It would be a trivial matter to return an error or warning if ==
is used for items which aren't numbers
Not at compile time - it's not generally knowable. At run time you /
do/ get a warning:
perl -w -le 'print q(a)==q(b)'
Argument "b
On 28 Jan 2009, at 12:01, Paul Makepeace wrote:
On Wed, Jan 28, 2009 at 11:31 AM, Dominic Thoreau
wrote:
2009/1/28 Jonathan Kimmitt :
The next time I use == instead of eq to compare two strings, I
will know to expect it will always
evaluate to true.
Interesting that everyone's
On Wednesday 28 January 2009 14:01:22 Paul Makepeace wrote:
>
> Interesting that everyone's said to "use warnings" but no-one's
> questioned what you're saying. Perl appears to me to DTRT:
>
> $ perl -le 'print "yes" if "a" == "2"'
> $ perl -le 'print "yes" if "a" == "a"'
> yes
> $ perl -le 'print
Ovid wrote:
- Original Message
From: Philippe Bruhat (BooK)
Where do we learn about that? Are there some OO tutorials planned at the
next YAPC?
Every time I write a new CPAN module, I first have to decide on how I'm
going to do OO this time.
Rather than focusing on advanced tool
On Wed, Jan 28, 2009 at 12:15 PM, Mark Blackman wrote:
>
> On 28 Jan 2009, at 12:01, Paul Makepeace wrote:
>
>> On Wed, Jan 28, 2009 at 11:31 AM, Dominic Thoreau
>> wrote:
>>>
>>> 2009/1/28 Jonathan Kimmitt :
The next time I use == instead of eq to compare two strings, I
will
2009/1/28 Mark Blackman :
>
> On 28 Jan 2009, at 12:01, Paul Makepeace wrote:
>
>> On Wed, Jan 28, 2009 at 11:31 AM, Dominic Thoreau
>> wrote:
>>>
>>> 2009/1/28 Jonathan Kimmitt :
The next time I use == instead of eq to compare two strings, I
will know to expect it will always
2009/1/28 Jonathan McKeown :
> On Wednesday 28 January 2009 14:01:22 Paul Makepeace wrote:
>>
>> Interesting that everyone's said to "use warnings" but no-one's
>> questioned what you're saying. Perl appears to me to DTRT:
>>
>> $ perl -le 'print "yes" if "a" == "2"'
>> $ perl -le 'print "yes" if "
Most people on this list seem to defend the perl design decision such
that
if ($item == "xyzzy")
should only emit a warning, because after all, a string can be converted
to a number with no loss of meaning (!).
However, what about this one:
for (my $i==0; $i<($tbl_width - 1); $i++) { }
Is
2009/1/28 Jonathan Kimmitt :
> Most people on this list seem to defend the perl design decision such
> that
>
> if ($item == "xyzzy")
>
> should only emit a warning, because after all, a string can be converted
> to a number with no loss of meaning (!).
>
It's not so much a matter of defending the
On 28 Jan 2009, at 12:01, Paul Makepeace wrote:
Can you give an example where perl is doing something surprising to
you?
I assume the OP was surprised by:
$ perl -le 'print "a"=="b"'
1
--
Andy Armstrong, Hexten
On Wed, Jan 28, 2009 at 12:30:20PM -, Jonathan Kimmitt wrote:
>
> However, what about this one:
>
> for (my $i==0; $i<($tbl_width - 1); $i++) { }
>
> Is anybody seriously arguing this could possibly do anything useful. Yet
> it
> is not trapped out as an error unless you add the obscure
On Wednesday 28 January 2009 14:30:20 Jonathan Kimmitt wrote:
> However, what about this one:
>
> for (my $i==0; $i<($tbl_width - 1); $i++) { }
>
> Is anybody seriously arguing this could possibly do anything useful. Yet
> it is not trapped out as an error unless you add the obscure syntax:
>
On 28 Jan 2009, at 12:30, Jonathan Kimmitt wrote:
Most people on this list seem to defend the perl design decision such
that
if ($item == "xyzzy")
should only emit a warning, because after all, a string can be
converted
to a number with no loss of meaning (!).
However, what about this one:
2009/1/28 James Laver :
> If the chain snaps, it's going to be moving at a fair pace. However
> snarled up in cotton wool it's going to be, it's going to hit you
> rather fast.
Chains snapping are not such an issue as it happens - there is a
little hook that takes care of it.
Chain saw safety app
- Original Message
> From: Jonathan Kimmitt
> Most people on this list seem to defend the perl design decision such
> that
>
> if ($item == "xyzzy")
>
> should only emit a warning, because after all, a string can be converted
> to a number with no loss of meaning (!).
>
> However, wh
On Tue, Jan 27, 2009 at 11:33:51PM +, Dirk Koopman wrote:
> Please (nicely) can we have some video/docs for them's that want to
> know, but can't attend.
Also any news on how the video editing is coming along from the LPW?
There's only two talks up on YAPC.tv. Can I help?
--
David Cantrel
2009/1/28 Jonathan McKeown :
> On Wednesday 28 January 2009 14:30:20 Jonathan Kimmitt wrote:
>
>> However, what about this one:
>>
>> for (my $i==0; $i<($tbl_width - 1); $i++) { }
>>
>> Is anybody seriously arguing this could possibly do anything useful. Yet
>> it is not trapped out as an erro
On Wed, Jan 28, 2009 at 10:46:07AM +, Jonathan Stowe wrote:
> 2009/1/28 Simon Cozens :
> > Ovid wrote:
> >> Rather than focusing on advanced tools and modules, I'd focus on
> >> advanced techniques.
> >
> > I've had this debate a hundred times over since sitting down to
> > write APP2ed: these
On Wed, Jan 28, 2009 at 11:40 AM, Matt Jones wrote:
> On Wed, Jan 28, 2009 at 11:23 AM, Piers Cawley
> wrote:
>> Actually, I was surprised to find that there isn't a warning for that
>> with warnings turned on. Memory proving faulty.
>
> Am I missing something?
Nope, I was.
On Wed, Jan 28, 2009 at 12:30:20PM -, Jonathan Kimmitt wrote:
> Most people on this list seem to defend the perl design decision such
> that
>
> if ($item == "xyzzy")
>
> should only emit a warning, because after all, a string can be converted
> to a number with no loss of meaning (!).
>
> H
- Original Message
> From: Abigail
> > That is to say that it is increasingly becoming less about
> > "programming" at all and more about scripting or configuring whatever
> > the application framework du jour might be.
>
> Yeah, all we need now is a GUI where we can just use drag and
>> wrote:>> $ perl -le 'print "yes" if "a" ==
>> "2"'>> $ perl -le 'print "yes" if "a" == "a"'>> yes>> $ perl -le 'print
>> "yes" if "1" == "1"'>> yes>> $ perl -le 'print "yes" if "1" == "0"'>> $ perl
>> -le 'print "yes" if "1" == 1'>> yes>> $ Can you give an example where
>> perl is doin
On 28 Jan 2009, at 11:58, Nicholas Clark wrote:
[...]
Whereas in dynamic languages, a variable doesn't know its type at
run time, so you need two operators to ensure deterministic
behaviour and sanity.)
Python is dynamic and manages this just fine:
$ python
Python 2.5.2 (r252:60911, Aug 6
On 28 Jan 2009, at 12:26, Jonathan Stowe wrote:
2009/1/28 Mark Blackman :
On 28 Jan 2009, at 12:01, Paul Makepeace wrote:
Can you give an example where perl is doing something surprising
to you?
perl -le 'print "yes" if "a" == "b"'
Is the kind of case I suspect he's hit.
I guess that
On 28 Jan 2009, at 14:02, Peter Corlett wrote:
On 28 Jan 2009, at 11:58, Nicholas Clark wrote:
[...]
Whereas in dynamic languages, a variable doesn't know its type at
run time, so you need two operators to ensure deterministic
behaviour and sanity.)
Python is dynamic and manages this just f
On Wed, Jan 28, 2009 at 10:56:41AM -, Jonathan Kimmitt wrote:
> Whoever said, the primary purpose of a compiler is to check for
> errors, and only if there are no errors, create the code, was most
> definitely not talking about Perl.
Or about half the XS on the CPAN. SGI's compilers are pick
On Wed, Jan 28, 2009 at 02:21:45PM +, James Laver wrote:
> On Wed, Jan 28, 2009 at 2:02 PM, Peter Corlett wrote:
> > Python is dynamic and manages this just fine:
> >
> > $ python
> > Python 2.5.2 (r252:60911, Aug 6 2008, 09:17:29)
> > [GCC 4.3.1] on linux2
> > Type "help", "copyright", "cred
On Wed, Jan 28, 2009 at 2:02 PM, Peter Corlett wrote:
> Python is dynamic and manages this just fine:
>
> $ python
> Python 2.5.2 (r252:60911, Aug 6 2008, 09:17:29)
> [GCC 4.3.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
'1' + '2'
> '12'
1 + 2
>
On Wednesday 28 January 2009 15:24:43 Jonathan Stowe wrote:
> 2009/1/28 Jonathan McKeown :
> > On Wednesday 28 January 2009 14:30:20 Jonathan Kimmitt wrote:
> >> However, what about this one:
> >>
> >> for (my $i==0; $i<($tbl_width - 1); $i++) { }
> >>
> >> Is anybody seriously arguing this co
- Original Message
> From: James Laver
> That's because python is strongly typed (though not statically typed
> -- it's a dynamic language).
No offense, but "strongly typed" doesn't have a huge amount of meaning, though
statically typed does. I highly recommend:
http://www.pphsg.o
On Wed, Jan 28, 2009 at 02:46:30PM +, Nicholas Clark wrote:
> On Wed, Jan 28, 2009 at 02:21:45PM +, James Laver wrote:
>
> Fair enough. But it's also that with this Perl:
>
>$c = $a + $b;
>$d = $a . $b;
>
> then at compile time (heck at writing it time) I know what it is going to
On 28 Jan 2009, at 12:23, Simon Wilcox wrote:
Ovid wrote:
- Original Message
From: Philippe Bruhat (BooK)
Where do we learn about that? Are there some OO tutorials planned
at the
next YAPC?
Every time I write a new CPAN module, I first have to decide on
how I'm
going to do OO
On 28 Jan 2009, at 15:27, Ovid wrote:
[...]
The problem with "strongly" and "weakly" typed is that different
people define them differently and they don't have much meaning in
type systems. It's static typing and dynamic typing which is
important.
Wikipedia says that weakly- versus strong
On Wed, Jan 28, 2009 at 4:05 PM, Peter Corlett wrote:
> Wikipedia says that weakly- versus strongly-typed indicates how readily the
> language coerces between types. I'm not sure one can get much weaker than
> Perl on that front.
That's more or less what I based my message on.
Definitions taken
- Original Message
> From: Peter Corlett
> > The problem with "strongly" and "weakly" typed is that different people
> > define
> them differently and they don't have much meaning in type systems. It's
> static
> typing and dynamic typing which is important.
>
> Wikipedia says tha
2009/1/28 Ovid :
> - Original Message
>
>> From: Peter Corlett
>
>> > The problem with "strongly" and "weakly" typed is that different people
>> > define
>> them differently and they don't have much meaning in type systems. It's
>> static
>> typing and dynamic typing which is important
Summary of my perl5 (revision 5 version 8 subversion 9) configuration:
Platform:
osname=linux, osvers=2.6.18-4-xen-amd64,
archname=x86_64-linux-thread-multi
uname='linux pigsty2 2.6.18-4-xen-amd64 #1 smp fri may 4 02:40:51 utc
2007 x86_64 gnulinux '
config_args='-de -Duse6
On Wed, Jan 28, 2009 at 08:47:56AM -0800, Ovid wrote:
> I'm just saying that while type theorists generally agree on the meaning of
> "static" and "dynamic" typing (and all languages contain elements of each),
> "strong" and "weak" typing don't have much meaning there. They only have
> meaning
A Dave wrote:
>
> So I told perl to build itself all 64-bitty, and it defined all the
> right Stuff to do so, but ...
>
> Compiler:
>cc='cc', ...
>...
>intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
>
> Huh? intsize=4?
>
>alignbytes=8, prototype=define
>
> and
Edmund von der Burg wrote:
Chain saw safety appears to be a well trodden topic:
http://en.wikipedia.org/wiki/Chainsaw_safety_features
Thanks for pointing that out. It made me shudder to read it.
I still have vivid memories of climbing to the top of a ladder to cut
the top of a tree with a
Andrew Beattie wrote:
Edmund von der Burg wrote:
Chain saw safety appears to be a well trodden topic:
http://en.wikipedia.org/wiki/Chainsaw_safety_features
Thanks for pointing that out. It made me shudder to read it.
I still have vivid memories of climbing to the top of a ladder to cut
th
On Wed, Jan 28, 2009 at 11:05 AM, Andy Armstrong wrote:
> On 28 Jan 2009, at 12:30, Jonathan Kimmitt wrote:
>>
>> Most people on this list seem to defend the perl design decision such
>> that
>>
>> if ($item == "xyzzy")
>>
>> should only emit a warning, because after all, a string can be converted
On Wed, Jan 28, 2009 at 10:56 AM, Jonathan Kimmitt
wrote:
>The next time I use == instead of eq to compare two strings, I
> will know to expect it will always
>evaluate to true. What other language does this (apart from C,
> which would invariably return false)
Objective C (which
On Wed, Jan 28, 2009 at 2:02 PM, Peter Corlett wrote:
> $ python
> Python 2.5.2 (r252:60911, Aug 6 2008, 09:17:29)
> [GCC 4.3.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
'1' + '2'
> '12'
1 + 2
> 3
1 + '2'
> Traceback (most recent call last)
74 matches
Mail list logo
