Re: The proper way to open()
Greg McCarroll wrote:
We'd also not have a language that attracts people who like to fly giant
kites (Andy W. and a few others)
/me waves
For the record, the Way I Do It these days is using Badger::Filesystem.
http://badgerpower.com/docs/Badger/Filesystem/File.html
e.g.
print File('wibble.txt')-text
On the subject of TMTOWTDI, it's interesting (and rather disappointing) to note
that I received what can only be described as hate mail after I released
Badger. Some people apparently felt that if it didn't use and actively promote
Moose then it didn't deserve to exist. One correspondent told me that I was
confusing things for Perl users by giving them too much choice. I laughed it
off on the outside and offered them a full refund of the purchase price, but I
cried a little on the inside (only for dramatic effect you understand - no
RealTears[tm] were shed).
A
Re: Gatwick
On 25/07/2011 14:53, Ash Berlin wrote: Curiously I've arrived at gatwick far more often than I've left from there OK, I'll bite. My curiosity is piqued. How can this be? A
Re: Cool/useful short examples of Perl?
On 31/05/2011 15:08, David Cantrell wrote: And Hungarian notation is good! pronounI adjectiveRespectfully verbDisagree. initialA
Re: On-topic: HTML/JS help please
On 11/02/2010 17:28, Richard Huxton wrote: You already have an id attribute on the toggle links (e.g. toggler_1). Add a class on each tr: depends_on_1 and then a couple of lines of jquery or similar should let you toggle the rows on/off. As per my previous response, complete with example: http://london.pm.org/pipermail/london.pm/Week-of-Mon-20100201/019103.html A
Re: On-topic: HTML/JS help please
On 05/02/2010 14:53, David Cantrell wrote:
tr
tda href=javascript:toggle('children_of_this::module')+/a/td
tdthis::module/td
tdblahblahblah/td
/tr
Add all the dependencies to the tr. e.g.
tr class=depends-This-Module depends-That-Module
Then use jQuery to toggle a .hidden CSS class on all the tr elements that
have a particular dependency, like so:
a href=... onclick=$('tr.depends-This-Module').toggleClass('hidden')
Then add a CSS class:
tr.hidden {
display: none;
}
That should degrade gracefully on a browser without JS or CSS.
Here's the full thing:
script
function toggle(module) {
$('tr.depends-' + module.replace(/:+/,'-',1)).toggleClass('hidden');
return false;
}
/script
table
tr
tda href=# onclick=return toggle('this::module')+/a/td
tdthis::module/td
tdblahblahblah/td
/tr
tr class=depends-this-module
tda href=# onclick=return toggle('other::module')+/a/td
tdother::module/td
tdblahblahblah/td
/tr
tr class=depends-this-module depends-other-module
tda href=# onclick=return toggle('yet::another::module')+/a/td
tdyet::another::module/td
tdblahblahblah/td
/tr
div id='children_of_this::module'
tr class=depdends-this-module
tda href=# onclick=return toggle('Test::More')+/a/td
tdTest::More/td
tdblahblahblah/td
/tr
/table
HTH
A
Re: SHA question
On 14/01/2010 17:41, Philip Newton wrote: Yes - you're missing the fact that in order to compute the differences (which it has to if it doesn't want to transfer the whole file), it has to read the entire file over the slow NFS link into your computer's memory in order to compare it with the local file in order to tell which pieces have changed. No, I don't think it does. My understanding[*] is that it computes a checksum for each block of a file and only transmits blocks that have different checksums. That's how it handles incremental changes on large files (e.g. an extra few lines at the end of a log file doesn't require the whole file to be transmitted). Some relevant options are: --checksum always checksum --block-size checksum block size --whole-file transmit the whole file --size-onlycompare file size instead of checksum A [*] which could be flawed
Re: SHA question
On 15/01/2010 20:23, Roger Burton West wrote: And to calculate the checksum on each block of the file, it has to, um, read each block of the file... yes? Sorry, I missed this bit in Philip's message: if both source and destination are on a local file system I was thinking about remote comparisons. In which case the remote rsync daemon computes the checksum. Yes, it has to read the entire file, but not transmit it. A
Re: Mini-LPM Crossword Warmup (Re: help - looking for a crossword compiler (human or computer))
Here are the answers (just on the off-chance that anyone got stuck) along with explanations of the clues for those who don't grok cryptic crosswords (or LPM). [P] [O] [N] [B][U][F][F][Y] [E] [P][I][E][S] [R] 1 Slayer agrees to working memory without hesitation. [5] Buffy, of course. From 'y' (agrees) added onto 'buffer' (working memory) with the 'er' (hesitation) removed. 2 One hundred left spice out of hot meals. [4] Pies. Yummy. One hundred is 'c' in roman numerals. It left 'spice' and the remaining letters 'spie' are an anagram (out of) 'pies' (hot meals). 1 A short ride - everyone wants one. [4] Pony. It's a short horse (a ride). Jolly popular, too. 2 Better put the badger out for a drink [4] Beer. 'Better' with 'TT' (the badger) taken out gives a tasty drink. I'll get my Nothing in feline suggests rainwear [4]... :-) A
Mini-LPM Crossword Warmup (Re: help - looking for a crossword compiler (human or computer))
On 12/12/2009 20:24, Aaron Trevena wrote: for my xmas london.pm crossword.. also anybody to proof read and check it would be appreciated. I saw your message yesterday afternoon and my brane starting ticking. Then this morning I saw your other message saying that it's all now compiled and sent out for review, so it's a little late for me to offer to help. However, as a warm-up to the main event, I present my mini LPM crossword based on the few clues I thought up yesterday evening while trying to avoid Celebrity Pop Factor Dancing Sausage Machine Generic Entertainment Program on Ice. The answers are all things close to LPM's heart. Enjoy A Across -- 1 Slayer agrees to working memory without hesitation. [5] 2 One hundred left spice out of hot meals. [4] Down 1 A short ride - everyone wants one. [4] 2 Better put the badger out for a drink [4] 1 [ ] [ ] 2 [ ] 1[ ][ ][ ][ ][ ] [ ] 2[ ][ ][ ][ ] [ ]
Perl linked list segfault
I've got some code that's making Perl segfault.
I'm creating a linked list using array references as nodes. The first element
in the array ref contains some data, the second item contains a reference to
the next item. Think cons lists.
while (++$n $max) {
$token = [token $n];
$last-[1] = $token if $last;
$last = $token;
}
Using the above code I can create a linked list of 100 million nodes and
everything works just fine (assuming you don't mind twiddling your thumbs
for a few minutes).
However, if I also stuff the nodes into a container list then Perl segfaults
at cleanup time, either when the tokens go out of scope or during global
cleanup.
while (++$n $max) {
$token = [token $n];
$last-[1] = $token if $last;
$last = $token;
push(@tokens, $token);# add this line - BOOM!
}
In this case Perl will reliably segfault with a mere 30,000 nodes.
If I just push them onto @tokens and don't create the linked list then it
also works fine. It's the combination of linked list + container list that
farks things up.
I've tested this on my Macbook using versions 5.8, 5.10.0, 5.10.1 and 5.11.1,
and 5.10 on Linux. They all fail somewhere between the 25k and 40k mark.
Now that I'm convinced it's a real bug, I'm at a bit of a loss as to how to
debug it. The -D flags that I've tried (most of them, in various different
combinations) don't offer much in the way of help and I've got no core dump
to analyse (can anyone explain why this doesn't dump core?). The only thing
that I'm sure of is that the SEGV is happening during memory cleanup.
I'll perlbug it when I get a moment, but I was hoping to be able to
investigate it further myself.
Any suggestions gratefully received.
A
Re: Perl linked list segfault
On 04/11/2009 07:55, Andy Wardley wrote: I've got some code that's making Perl segfault. Here's the complete script in case anyone wants to play along at home: http://wardley.org/perl/linked_list_segfault.pl A
Re: Perl linked list segfault
On 04/11/2009 10:46, Paul LeoNerd Evans wrote: That's highly suspect. That was my first thought. But no, it's not specifically 32,768. It depends on the platform/perl version. In once case, ~25k was enough, and in other it was a shade over 39k. A
Re: Perl linked list segfault
On 04/11/2009 10:45, Matthew Boyle wrote: mine seems to be running out of stack space: [chemn...@10:36 ~]$ gdb perl [...] (gdb) run downloads/linked_list_segfault.pl Starting program: /usr/bin/perl downloads/linked_list_segfault.pl Ah! That's the magic incantation I needed. I was trying these: $ gdb linked_list_segfault.pl $ gdb perl linked_list_segfault.pl And of course, gdb complained that linked_list_segfault.pl wasn't a core file. quarter of a million frames is quite a lot :-) Indeed. I'll try not to be so greedy in future :-) looks like it is a stack issue: [chemn...@10:52 ~]$ ulimit -s 10240 That's another useful tip to remember. Thank you. A
Re: Perl linked list segfault
On 04/11/2009 10:46, Dagfinn Ilmari Mannsåker wrote: It seems to be recursing when freeing @tokens, I'm see the following stacktrace: Aha, that would explain it. I think it's time to take this to p5p. I will. Thanks everyone. A
Re: Beer was Re: Anyone drinking at the moment?
Abigail wrote: That brings up an image of a civil servant stamping glasses. And once a month, a moves for a week from Brussles to Strassbourgh. 20 or so years ago there was a UK Weight and Measures Authority near where I lived in Kingston. Although I never did it myself, a number of my school mates had holiday jobs there checking and approving (or rejecting) pint glasses. It was all done by hand, one glass at a time. I find it hard to imagine that they would still doing it by hand, if indeed they are. But then again, I found it hard to believe that they were doing it by hand back then and the UK civil service moves anything but fast. So it wouldn't surprise me. A few years later the landlord of a local pub told me how much he had to pay for officially stamped glasses (which, of course, you have to have). I forget the figure, but it was more than a quid if memory serves, and that was in olden days money where a pint cost about the same or even less. Whatever the figure, it was ridiculously expensive all because they had to pay someone to check and stamp every single glass by hand. A shiny example of British inefficiency at its best. A
Re: Anyone hiring at the moment?
On 24/09/2009 12:37, Ovid wrote: one of my friends [...] always wears Iron Maiden t-shirts, has an Iron Maiden tattoo Well at least he has good taste in music. :-) I saw a youngster at the skatepark the other day wearing a Number of the Beast T-Shirt. I was about to tell him that I once slept (well, drunk beer) outside Hammersmith Odeon all night to get a front-row seat for the Beast on the Road Tour. But then I realised that this must have happened at least 10 years before he was born and I suddenly felt rather old... A
The Genius of the Perl Programming Language (and a plug for the Perl sub-reddit)
This just in from the Department of Preaching to the Choir: http://aplawrence.com/Girish/perl-cpan.html Python and lua are excellent languages too and I am sure that Python is much better than perl in many many respects but there is one key difference. The difference is CPAN. [...] There is no CPAN in any language other than perl Pats on the back all round. And a tip of the hat to singingfish42 who posted it to Reddit here: http://www.reddit.com/r/perl/comments/9ma94/ For those who don't already know, we have a reasonably active Perl sub-reddit which throws up all sorts of interesting links to articles about Perl. http://www.reddit.com/r/perl/ Self-promotion is actively encouraged, so please feel free to submit links to your own Perl blogs or those of your Perly chums. A
Re: Tricky localization/scope question
On 28 Jul 2009, at 01:01, Randy J. Ray wrote:
The tricky part that I can't seem to quite get right, is how to
properly
localize the changes made to @INC so that it gets properly restored
when the
scope exits. That is, I don't want the user to have to explicitly
undo their
previous calls.
Let me see if I understand... you want code that does the equivalent
of this:
{
local @INC = @INC;
local %INC = %INC;
...your code...
}
But you want that Clocal %INC = %INC to be hidden away and performed
as part of
the call to Ctest_without 'Compress::Zlib'.
As far as I know, there's no way to inject a local variable into
another scope
(i.e. from test_without() into the caller) from Perl. Maybe it's
possible from XS,
but probably not without deep monkeying around (although I would love
to be proved
wrong on this).
However you could invert the problem with a function that takes a
block and adds
the Clocal lines before calling it;
sub local_inc() {
local @INC = @INC;
local %INC = %INC;
$_[0]-();
}
Then:
local_inc {
test_without 'Compress::Zlib';
# ...etc...
};
This will localise any changes to @INC/%INC on the way into the block
and restore
them on the way out.
A
Re: Desperately seeking Javascript help
David Cantrell wrote:
Can anyone point me at a tutorial which will show me how to put a map in
a page, point it at my own map tiles, and Just Work?
points/
http://wardley.org/misc/map_overlay.html
It's not a tutorial but it shows the 20 or so lines of code you need to
create a custom tile overlay in a google map. It's based on the example in
the google maps docs:
http://code.google.com/apis/maps/documentation/overlays.html#CustomMapTiles
You'll also need a script tag in the page header to load the google maps
library and something to call show_map() when the documents loads. You can
do that with body attributes like this:
body onload=show_map(); onunload=GUnload();
Or using jQuery, like this:
script
$(document).ready(show_map).unload(GUnload);
/script
Then all you need to do it write your own function to return the correct
map tile for the lng/lat/zoom:
tiles.getTileUrl = function(point,zoom) {
// return a URL for the tile image at point.x, pointy at
// zoom level zoom
};
HTH
A
Re: [OT] Wrapping methods
Nicholas Clark wrote:
Of course this can also be solved in various other ways,
[...]
but that doesn't feel as elegant an interface.
Perhaps not, but IMHO having two distinct methods is the Right Way To Do It.
Anything else runs the risk of being Too Clever By Far[1].
I would have an external run() method to act as an interface and an internal
_run() method to provide the implementation.
sub run {
# setup
$self-_run(@_);
# cleanup
}
That's the simple, vanilla OO approach. You can tart it up with a bit of
Moose magic if you like, but that should be the dressing on top, not the
cake itself.
That said, I think a better approach in this situation would be to implement
a generic call_method_with_timeout() method/function that you can inherit
from a base class, import from an external module, or mixin using some other
fancy technique.
sub call_method_with_timeout {
my ($self, $method, @args) = @_;
# setup # your timeout code
$self-$method(@args); # goes around this
# cleanup # bit here
}
You can then implement run() as a simple call to the above method.
use Your::Utils 'call_method_with_timeout';
sub run {
# easily skimmable, self documenting code, yummy.
shift-call_method_with_timeout( _run = @_ );
}
If a slick API is your thing then another approach is to use a monad object
to represent the timeout wrapper. Something like this perhaps:
package Method::Timeout;
our $AUTOLOAD;
sub _bind_ {
my ($class, $object) = @_;
bless \$object, ref $class || $class;
}
sub AUTOLOAD {
my $self = shift;
my ($name) = ($AUTOLOAD =~ /([^:]+)$/ );
return if $name eq 'DESTROY';
# setup # your timeout code
my $result = $$self-$name(@_); # goes around this
# cleanup# bit here
return $result;
}
Then in your object class (or imported from another module)
use Method::Timeout;
sub timeout {
Method::Timeout-_bind_(@_);
}
The timeout() method returns a Method::Timeout object wrapped around your
$self object. This wrapper object then delegates all method calls to the
original object, but with the timeout alarm set.
The end result is that you can then call any method with a timeout wrapper
like so:
$object-timeout-run(@args);
You can also pass additional parameters to the timeout method if you like,
e.g.
$object-timeout(10)-run(@args);
You can also reuse the timeout object if you need to:
my $timeout = $object-timeout(10);
$timeout-foo();
$timeout-bar();
$timeout-baz();
And it also works with class methods (as does call_method_with_timeout()):
my $object = My::Class-timeout-new( connect = $a_slow_server );
I find this approach rather satisfying. It clearly separates the method
that you're calling from the way you want the method to be called.
Separation of concerns and all that.
Badger::Base implements the try() method this way. It simply puts an eval { }
wrapper around the method you're calling, effectively downgrading a thrown
exception to an undefined return value [2].
if ($object-try-some_method(@args)) {
print success\n!;
}
elsif ($@) {
print failed: , $object-error, \n;
}
else {
print declined: method returned false value, no error thrown\n;
}
It's not as elegant as proper try/catch blocks, but I think it's nicer
than the Old Skool approach of wrapping eval { } blocks around the method
call.
if (eval { $object-method(@args) }) { # Not as nice, IMHO
...
}
But I digress...
Whichever way you do it, I think it's important to separate the underlying
action being performed (the _run() method or whatever you call it) from the
additional timeout behaviour that is orthogonal to it.
Cheers
A
[1] i.e. clever enough to confuse others
[2] Returning undef to indicate failure is a Bad Thing. Have your methods
throw exceptions by default and let the caller make the decision to
ignore/handle them (using try(), eval { } or whatever) when appropriate.
(for the grandmas who don't already know how to suck eggs :-)
Re: [OT] New Buffy movie
Joel Bernstein wrote: Fell for the bait and top posted with my vamp face on. Did it actually mean something or just random made up word noises? I know a little BuffyL33Tspeak. I will attempt to translate into the Queen's English: I allowed myself to be drawn into this conversation because I am a fan of Buffy the Vampire Slayer. However, in my haste to exude my thoughts on the matter, I committed a social faux pas by typing my reply above the included extract of the poster to whom I was replying. I have now realised the error of my ways and will endeavour henceforth to follow the preferred convention of bottom-posting in order to maintain the correct temporal flow of the ongoing conversation. A
Re: Action address in HTML forms
Zbigniew Lukasiak wrote: Is it then a reasonable rule when writing a 'high level web library/framework' to restrict the forms to always submit to their own address? It's a reasonable default, but not so good as a restriction. I can think of several occasions where my forms don't submit straight back to the place that generated them. For example, I'm working currently on a project where we have an external CMS for customers to use and an internal CMS (with extra wizzy features) for the support staff to use. Image upload from the internal CMS is messy as it requires syncing the files out to the external machine. So instead we have the internal CMS generate a form which submits the image upload to the external CMS along with a hidden parameter which says redirect the user back to *here* when the image upload is done. http://internal.example.com/image/upload - generates form, user submits - http://external.example.com/image/upload - accepts upload (or prints errors), redirects - http://internal.example.com/image/uploaded?status=okimgid=12345 Another scenario is where you have one page with lots of forms on it. Each one changes a different aspect of some data and is handled by separate URLs/actions. +-+ | update blah - url1 | +-+ +-+ | update yada - url2 | +-+ +-+ | update bobo - url3 | +-+ In this case the page generating the forms is not the same page that receives the form data. Otherwise your one handler ends up with lots of separate code branches to process each form. A
Re: Converting an AST back into code
Robin Berjon wrote:
I can certainly see how I can brute-force my way out of this, and I'm
pretty sure it'll involve some of that. But what I was wondering about
is whether there are tricks and good ideas to doing this right/more
easily, and evil traps to be wary of.
The two main approaches that I'm familiar with are tree walking (visitor
pattern) and self-evaluation (interpreter pattern).
Tree walking is usually done via double dispatch. You start off with
a call on the root node, passing a visitor object as an argument.
$root-accept($visitor);
Each node implements an accept($visitor) methods which does something
like this:
$visitor-visit_my_kind_of_node($self, @_);
Nodes with children also do something like this:
$child-accept($visitor)
for $child in @{ $self-{ children } };
The main reason for doing this is to avoid the classic type switch
code smell:
if ($node-type eq 'one_kind') { # not so good
# ...
}
elsif ($node-type eq 'another_kind') {
# ...
}
It also gives you a handy object (the visitor) in which you can maintain
any context-dependent state data.
You have to decide how to collect the output generated by the visitor.
You can have the visitor's visit methods return the results (which
can get a bit tricky when it comes to collation), or you can have
the visitor collect the information itself.
# either
my $result = $root-accept($visitor);
# or
$root-accept($visitor);
my $result = $visitor-result;
The visitor pattern usally works best when you've got things like document
object models that you'll want to walk, manipulate and jiggle about with in
many different ways. It allows you to collect all the methods that relate
to a particular behaviour in one place (i.e. the visitor) instead of dotting
them over umpty different node classes). This is good when it comes to adding
new views because you don't need to make any changes to the nodes.
The other approach is to give each node type a method (or methods) which
implements the behaviour that you want. This is typically used for program
optrees where the common behaviour is evaluate thyself. You may need a
separate context object to maintain the program state.
my $result = $root-evaluate($context);
For example, a node representing an addition operator would do something
like this:
sub evaluate {
my ($self, $context) = @_;
my $lhs = $self-lhs-evaluate($context);
my $rhs = $self-rhs-evaluate($context);
return $lhs + $rhs;
}
And a node for fetching a variable value might do this:
sub evaluate {
my ($self, $context) = @_;
return $context-variables-{ $self-name };
}
This approach can be slightly faster than the visitor pattern as you're
avoiding the extra method call from double dispatch in principle, although
in practice, it rarely makes much difference in the long run, particularly
if your nodes are delegating to a separate context object (so you might as
well make the context and visitor one and the same). The downside is a lack
of flexibility as all methods must be built in to the nodes themselves.
However, don't forget that Perl's packages are open (i.e. extensible by other
modules) so it's not hard to install new methods into existing classes if you
want to.
package My::Tree::View::HTML;
sub My::Node::Type1::to_html {
...
}
sub My::Node::Type2::to_html {
...
}
sub My::Node::Type3::to_html {
...
}
...etc...
use My::Tree::View::HTML;
my $html = $root-to_html;
This approach might be considered a bit more of a hack because it doesn't have
a design pattern named after it But it does give you the flexibility of the
visitor approach with the simpler and faster direct evaluation approach.
HTH
A
use constant SUBJECT = 'Defining Constants'; # was: !0
Peter Corlett wrote:
Like comments, constant names should expand on the meaning of the code
rather than just repeat it, and should mean the same thing in each
place.
I totally agree that constant names shouldn't obfuscate their values,
and they should always have the same, sane value. However, I don't
agree with your first point.
In recent years I've found myself writing more and more constants that
simply repeat the word itself. The Badger::Constants module defines a
bunch of these that I use all the time.
For example:
use Badger::Constants 'ARRAY HASH';
if (ref $foo eq ARRAY) {
...
}
elsif (ref $foo eq HASH) {
...
}
Here ARRAY is a constant definition of 'ARRAY' and likewise for HASH.
In fact, I use this stating-the-bleeding-obvious approach to constants so
much that I added a handy hook to Badger::Class for defining them.
use Badger::Class
words = 'yes no maybe';
if ($response eq yes) {
...
}
elsif ($response eq no) {
...
}
The benefits to me are:
1) If I misytpe the word then Perl tells me at compile time.
2) It saves on typing (and reading) the two extra quote characters.
This adds up over time.
3) My syntax highlighter makes it go black (boring) instead of the
blue (interesting) colour it uses for strings. This reduces the
cognitive load when skimming the code. Skimmable code++
The downside is that all constants are effectively polluting your package
namespace. In Perl, constants are subroutines are methods, so you can call
any constant subroutine as a class or object method. However, this can also
be used to great effect for things like defining default configuration values
for a module:
package Hello;
use constant MESSAGE = 'Hello World';
sub new {
my $class = shift;
my $message = shift || $class-MESSAGE;# looky here
bless { message = $message }, $class;
}
You can then sub-class it like so:
package Bonjour;
use base 'Hello';
use constant MESSAGE = 'Bonjour le Monde';
By resolving the MESSAGE constant against $class (or an $object of $class)
in the new() method, we get the subclass definition of MESSAGE instead of the
base class one. Neat, eh?
BTW, my favourite constant definition of all time is 'PKG' which is defined to
be '::'. For example, the Badger::Class words() method (which defines those
same-named constants in the earlier example) does this:
*{ $pkg.PKG.$word } = sub() { $word };
Instead of the harder-to-type:
*{ $pkg.'::'.$word } = sub() { $word };
Or the even-harder-to-type, gnarlier-to-read, and running-more-slowishly
alternative:
*{${pkg}::${word}} = sub() { $word };
Ah! Perfect timing... my database has just finished importing... back to
work...
Tune in next week for more Constant Definitions I Have Known and Loved. :-)
A
Re: Have at it
I don't know about Moose, but Badger at least has a catchy (annoying) tune :-) Mushrm! Mushrm! Talking of catching tunes, a long time ago in a mailing list far, far away, I wrote [1]: Moose operates at a slightly higher level of abstraction [than Badger]. To stretch the analogy, it's like jumping in a taxi and letting the taxi driver find the best route. In contrast, Badger gives you a bike (it's got a basket, a bell that rings, and things to make it look good) and a map of some nice forest trails with good foraging spots along the way. To which Stevan Moose Little replied [2]: Great, now that that song is in my head its gonna be another Early Floyd/Syd Barrett day in the old iTunes.. hell crazy! But yeah I think your analogy is correct, Moose does try and do a lot for you in comparison to Badger, both exposing the control of these things in a different way. However I think your undercutting Badger a bit, I think that along with a Bike and a map of forest trails, it has also packed a picnic lunch, some energy bars, a snake bite kit and small tent in case you find a nice place to camp. Todd Rinaldo summed up the exchange thusly [3]: I just want to say that I'm very disappointed in you both. I read the first email on this chain. Went to the kitchen to make some popcorn so I could come back and enjoy some good wholesome flameage and I come back to find you guys singing Kum Ba Ya. It's SICK SICK I tell you! :) Badger is a poor man's Moose, but a rich man's Class::Base, Class::Debug, Class::Error, Class::Singleton, Class::Path, Class::Accessor, Class::Facade, Class::Config, Class::Metaclass, and Class::KitchenSink (some which I wrote, some which I didn't, and some which I just made up). There's a good deal of crossover between what Badger and Moose do, but that's more accidental than intentional. I didn't ever intend Badger to be an alternative to Moose - it's just a better version of the stuff I wrote before (mostly TT). Badger skirts around a bunch of tedious things that make Perl programming less fun than it should be, with object construction being just one of them. It's a small but significant feather in Badger's cap, but the functionality is really very basic in comparison to the mighty meta-plumage of the Moose. But either way, Moose and Badger are best friends. They inhabit different parts of the forest, but they love nothing better than getting together to go foraging for nuts and berries, play a nice game of tennis or have a bit of a sing-song. Metaphorically speaking, of course. A [1] http://mail.tt2.org/pipermail/templates/2008-September/010433.html [2] http://mail.tt2.org/pipermail/templates/2008-September/010434.html [3] http://mail.tt2.org/pipermail/templates/2008-September/010435.html
Today's MySQL Suckage
I have a file which defines a MySQL database schema. It looks a bit like this: /* This table defines users of the system who are Buffy fans. */ CREATE TABLE buffy_fans ( ..etc... ); I feed it in thusly: $ mysql my_db_schema.sql And it says: usage: who [-abdHlmpqrstTu] [am I] [file] It's interpreting the line system who are Buffy fans. as a shell command, even though it's inside a comment. Yes, I know. It serves me right for using a database made of cheese. A
Re: Introduction to Perl for non-programming Mac folk
Andy Wardley wrote: Before I go and write this myself, http://wardley.org/computers/perl/intro4mac.html Comments, corrections, additions, etc., welcome. A
Re: Introduction to Perl for non-programming Mac folk
Spiros Denaxas wrote: I would also add an honorary mention to TextMate, a pretty decent editor for Mac OS X [1]. I was first introduced to it by the mighty evdb and have been using it diligently at $work and $home ever since. It's already there. http://wardley.org/computers/perl/intro4mac.html#Writing_Your_First_Perl_Program (Second paragraph) Sound advice, though. Thx. A
Re: Introduction to Perl for non-programming Mac folk
Christopher Jones wrote: What a cunning ruse! I only hope they haven't read that message, and will continue to respond to such provocation. I don't know if this is the wiser people to whom Ovid referred, but it hits the nail on the head: http://bash.org/?152037 Quote: Start the sentence with Linux is gay because it can't do XXX like Windows can. You will have PhDs running to tell you how to solve your problems. So true. :-) A
Re: Introduction to Perl for non-programming Mac folk
Chisel Wright wrote: I don't this should be limited to Mac folk. You accidentally the verb. :-) A
Re: Introduction to Perl for non-programming Mac folk
Chisel Wright accidentally the verb: I don't this should be limited to Mac folk. Paul Makepeace wrote: See how long it takes you to actually come up with a verb that gives a substantially different mearning from the (presumably) original intent... Darn this digital medium! I can't read your tone of voice. I'll assume a defensive posture, while proferring dispute as the verb he might have accidentally, but presumably didn't. For anyone left scratching their heads, it's one of them internet meme thingies. Sorry. In-jokes and all that. Bad form. http://www.reddit.com/search?q=I+accidentally A PS I accidentally my coat... otherwise I'd be fetching it right now.
Introduction to Perl for non-programming Mac folk
Before I go and write this myself, does anyone know of any online or dead-tree resources that give a gentle introduction to using Perl on Mac OSX? I'm working with a couple of web designers who want to learn a bit of Perl, but need a bit of hand-holding when it comes to using the command line and other techy things. The goal is to get them to the point where they can start reading Learning Perl and play along at home (well, work). These are the kind of things that I think need to be covered. * Find the Terminal app and running Perl from the command line. which perl, perl -v, etc. * Using a text editor, writing programs, saving, chmod-ing and running. * Minimal introduction to Perl syntax, Hello World kinda stuff. * Setting up CPAN (o conf make_install_make_command sudo make so you don't need to run as root) * Installing CPAN modules (including knowing how to force install in case tests fails/dependency hell) * Using an OO module (my $x = -new; $x-some_method()), etc. * Knowing where to look for documentation and how to read it. Anything I've missed? Cheers A
Re: Sharding, and all that
Richard Huxton wrote: Hmm - skimming these articles, I'm not hugely impressed. The chap(ess?) behind them is clearly a developer rather than a DBA. You're right. I perhaps should have quantified that better as a good *introduction* to the subject. It was a bit hand-wavy on the detail, but it got me thinking about the subject (speaking as more of a developer than a DBA). He said: Split the database into smaller, specialized db’s. Use a DB for users, one for messanging functionalities, one for product orders, etc. Each of these databases must exist independently, You said: Brilliant! So now your messages don't necessarily have a valid user associated with them. It's a shame he didn't go into the details of how you were supposed to make the must exist independently bit happen. Key management is clearly going to be a critical part of this. My take on this is that you would have to (re-)build your application and underlying DB to be distributed from the start. Your user DB/app would provide an authentication service, perhaps something similar to OpenID, that your message board would use to authenticate users. The problem you mention is that the message.user foreign key then goes out the window. One approach would be to have a local users table in the messaging DB which maps internal user IDs to some kind of external user identifier. That could be their email address (in the simplest case), a URL that identifies the user at your authentication app (e.g. http://auth.your-app.com/joe90) or perhaps a GUUID. Either way, you're explicitly decoupling the internal requirement that a message must have a valid user id (i.e. a record in the users table) from the assumption that you actually know anything valuable about that user that doesn't relate explicitly to the message board. You can then maintain referential integrity in your message DB regardless of what happens in the user DB. It would be possible to delete a user from the user system, for example, without having any *internal* effect on the message board DB (no more cascading delete woes). Of course, there is still an *external* effect, namely a broken link from the user in your message board to the one in your auth app. For example, your message board may have messages written by user 42 who was identified at the time as jo...@example.com, but there's no guarantee that the user still has login access, or even exists. You'll have to go and ask the user application for further information on that *and* accept the implicit assumption that you may get back the SaaS equivalent of a blank stare. I appreciate that decoupling is a fancy way of saying broken, but I'm beginning to see it as a feature rather than a liability in this context. I should point out that I haven't implemented anything like this yet so I could be way off course. But I'm about to implement something like it for a $work project so any pointers on this would be welcome if I'm sailing in the wrong direction. This sort of stuff is very easy to get wrong. Agreed. I don't think there's any easy substitute for proper data design. Scalability doesn't work as an afterthought. A
Reminder: the Perl Reddit
I'm ashamed to admit that I didn't know about http://proudtouseperl.com until the recent thread, and it looks like I wasn't the only one. But visibility aside, it's great to see more Perl site/blogs springing up around the place. Can I take this opportunity to remind people about the Perl Reddit. If you know of any good Perl sites, or find any good Perl articles then please consider submitting links to them here: http://www.reddit.com/r/perl/ You'll notice that the latest proudtouseperl.com article is currently at #1 in the hit parade so hopefully that'll help to give it a bit more limelight. Cheers A
Re: Sharding, and all that
Richard Huxton wrote: Yep - that's what sharding is all about - separate disconnected silos of data. I thought sharding specifically related to horizontal partitioning. i.e. splitting one table across several databases, e.g. records with even row ids in one DB, odd in another. Apologies if my terminology is wrong. I was thinking more specifically about vertical partitioning along the functional boundaries which wouldn't be sharding by my (possibly incorrect) definition. Apologies for being off-topic, too :-) Then you're not maintaining referential integrity. There's no point in having a user-id that doesn't *mean* anything. I'm not suggesting that the user id doesn't mean anything. It means exactly the same thing as it does in any other database - a unique identifier to a user record. I'm saying that the user record in the message DB doesn't need to store email address, username, password, favourite colour, challenge question/response, and all the other cruft that goes with user administration. All it needs is a unique id, an authentication realm (identifying the authentication service) and authentication token (identifying the user at that service). And perhaps any message-board specific niceties such as your local nick and display preferences. Similarly in the authentication DB there's no need to store information in the users table relating to message board preferences. I can see that trivially splitting one user table into two leads to all sorts of integrity problem. But I'm thinking of them as two separate user databases from the outset and accepting that they're potentially disjoint. The best (but poor) example I can think of right now is how my gravatar popped up automatically when I signed up at github. Not because the github user database is referentially at one with the gravatar database, but because I used the same public identifier (my email address) on both systems. So it could be argued that there is *a* point in having a user id (such as email address) that doesn't *mean* anything to the *current* database, because it might have meaning to *other* databases. It's the closest thing we've got to referential integrity in a distributed world. Primary keys, foreign keys and all the other bits and pieces of RI in a SQL database are there to maintain the *meaning* of your data. Sure, I recognise the fact that you lose referential integrity at the boundary between your db and the outside world. But internally, the DB remains referentially intact. The message board still has its own user records for messages to reference. The fact that the authentication realm/token may at some point in the future become invalid is really no different to the current situation where a user's email address changes and they can no longer login or get a password reminder/reset. Before that though, make sure you do have a problem. Pick the right tool for the job - if high concurrency/complex queries/procedural code for constraints is a requirement then it's probably not MySQL. Always consider what an extra couple of grand on hardware will gain you. For this particular project we don't really have a database problem that can't be solved with a bit of replication and a whack of the hardware hammer. The majority of the load will be searches that we're reading from a single read-only table. So we can replicate that easily across as many web heads as required for performance and it gives us simple redundancy in case of machine failure, etc. All the read/write functionality (mostly CMS-like stuff) will happen (initially) on a single server with master read/write database. It'll be fairly low-load and it's not mission critical (in the sense that having the CMS offline for a few hours is an inconvenience not a hanging offence). The impetus was more about turning one large and tangled CMS-like system into several smaller, simpler systems. 90% of the tables fall neatly into one sub-system or the other (front-end search and content delivery, back-end content management, image management, accounting and billing, and so on). It's the last few tables (mostly relating to users, unsurprisingly) that straddle spread-eagled across the database dangling their tools in the works. So I'm really coming at this from the perspective of someone thinking about building distributed apps and wondering how the database is going to work behind the scenes, rather than someone with a database performance problem considering partitioning. Cheers A
Re: Sharding, and all that
Mark Fowler wrote: What's the collective group think on these? There's a good series of articles on sharding starting here: http://lifescaler.com/2008/04/database-sharding-unraveled-part-i/ The conclusion I drew from it was that functional partitioning (where possible) was much easier to implement than horizontal partitioning. A
Re: london.pm.org web site - facelifted (v2)
Mark Blackman wrote: What remains for this shininess to be made live? The gate keeper of the London.pm fortress hath just this hour granted me access after much wrangling with the dragons of ssh and walls of fire. Verily now that I have entered shall I proceed to make shiny the castle walls. A
It Shines! It Shines!
Behold! http://london.pm.org/ There's a few pages not building properly... working on that now. A
Re: It Shines! It Shines!
James Laver wrote: Quick investigation with firebug tells me that firefox thinks the background the text is on is some darkish orange/brown so it chose a nice white background to help it stand out... I assume it's some bizarre div stacking bug. Hmm... it appears to work OK for me on FF (3.0.4 Mac) I've explicitly added a white background to the #body div on top to see if that helps. But I'm playing blind here so you'll need to be my eyes. Oh, and it works fine for me without the fix in IE7, I assume IE6 is equally ignorant of CSS standards in this respect. I must admit, I've only just looked at the site for the first time on IE6 and IE7 (sorry, I was too busy punching myself in the face to get around to it :-) Imagine my great surprise and considerable relief to see that it looked OK (apart from a minor wrap-around issue in the menu bar, which is now fixed). I mean, I like to think I know a bit about browser friendly markup, but really, that's unheard of! I can only assume that somewhere else in the world, a number of cute and fluffy kittens were put to death in rather unpleasant circumstances in order to balance the karma in the universe. Happy days! Unless you're a fluffy kitten, of course. A
Re: Perl Christmas Quiz
David Cantrell wrote: See also http://search.cpan.org/~domizio Which sends you here: http://perl.4pro.net/perlish_coding_style.html My poor eyes. Make it stop. Burn it with fire. A
Re: london.pm.org web site - facelifted (v2)
Paul Makepeace wrote: I'd aim for 950-ish width - not much of a sacrifice from 1024 aolMe Too!/aol 960 is a particularly magical number because it's divisible by 1, 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20 and 24, so it's a good start for grid-based designs, or anything with columns. And as you say, it's got a little bit left over down the side for scroll bars, etc., before you hit 1024. A
Re: london.pm.org web site - facelifted (v2)
Léon Brocard wrote: Andy, care to put your changes live? All checked in. It'll need to be built on the target machine. I've added 3 more colour schemes (light brown, teal and purple) for those who find the orange a bit too garish. I've also added a print stylesheet. The stylesheet switcher and Go Large mode are now sticky and get added via a bit of JS progressive enhancement voodoo. So everything should degrade nicely for those without JS. I kept the design as fixed width because making a fully fluid layout proved to be too much of a PITA for the time I had available. However the Go Large mode is fully fluid, albeit a little sparse, so it's a good second best. Limited preview here: http://wardley.org/london.pm.org/ I haven't yet looked at it in IE. I'm going to go and poke myself in the eye with a sharp stick first. :-) Enjoy! A
Re: london.pm.org web site - facelifted (v2)
Nigel Rantor wrote: I've already poked Andy about this when he put up the initial version. Here's my reply to Nigel, for the benefit of anyone else interested. reply Yes. I've always been a fluid-layout kinda guy. 800x600 is annoyingly narrow when you've got a large monitor, so a fluid layout was a big win when you had to assume a minimum width of 800px. But these days, it's considered officially OK to assume that 1024x768 is the lowest common denominator for screen width, which gives you a nicely sized bit of content-space to play with. Making it fluid upwards of that tends to result in wide wide columns that are hard to read. So although I used to be staunchly anti-fixed width, I guess I've now been swayed towards them. Making it fluid might be a bit tricky, but probably do-able. I'll have a think about it. /reply I did have a play with it, but it was hard to make it look half-decent with the non-repeating header. So it was a case of junking the header (which I really liked) or spending a lot of time creating separate layers and building up a sliding doors effect. That would have been really nice if I could have got the parallax effect to work (like on badgerpower.com - resize the window and watch the clouds), but I couldn't. At least not in the time I had. Anyway, the site *does* have both fixed and fluid layouts. It's just that the fluid layout doesn't have the non-repeating header or the sidebars. :-) A
Re: london.pm.org web site - facelifted (v2)
Nicholas Clark wrote: Whilst we fully support there's more than one way to do it, the availability of different hues of orange should provide more than enough alternatives. :-) Aha! Well the brown design *is* actually orange! It's exactly the same hue as the orange (30 deg), but de-saturated and washed out a bit. But it really is officially orange. The teal version is also orange. It's just been shifted a teensy-weensy bit towards the green end of the spectrum (approx 107 degrees if memory serves). Surprisingly, the purple is also orange, but shifted an ickle-bickle bit in the other direction. A
Clay Shirky on Shinto Shrines, Perl, Love and the Internet
http://www.youtube.com/watch?v=Xe1TZaElTAs quote Perl is a shinto shrine. Perl exists not as an edifice but as an act of love. Perl is a viable programming option again today because millions of people woke up this morning loving Perl. And more importantly, they love one another in the context of Perl. They love one another enough to stop what they're doing and listen to each other. To have a conversation with each other, to answer questions for one another, to diagnose things for one another and sometimes even to write code for one another - Oh I think I see what's going on, here, try this. No contracts are written, no money changes hands and and the work goes on. /quote I would just like to say that I love you all and you're my bestist mate ever. A
Re: Perl Christmas Quiz
I can pick off a few of the easy ones. [SPOILERS] 6) What company was Larry Wall working for when he wrote Perl 1? JPL. 9) When will Perl 6 be released? Christmas 10) Who was the most important pioneer of Perl Poetry? Sharon Hopkins 13) Think of a witty and/or interesting Perl Christmas quiz question and answer it. The Fairmont Hotel. What was the question? A
Perl 5.8.8 segfaulting on comments! How can this be?
I've got a *very* strange problem with Perl segfaulting seemingly at
random, but quite predictably based on things that it really shouldn't
care about (like comments).
It's so weird that my first thought was that it was faulty memory in my
machine. But I've tried it on two machines (both macs) and see the same
problem. I would appreciate it if some other people could verify the
problem and/or throw any light on it. There's a small ( 1k) tgz here
containing the files:
http://wardley.org/perl/broken_glass.tgz
I should mention that this problem only manifests itself on 5.8.8,
and 5.10 seems fine (haven't tried it on any other versions). However,
it is s weird that it's quite possible that I'm just not tickling
it right on 5.10. Of course, it might have been identified and specifically
fixed for 5.10, but I can't see any mention of it on perlbug (although I
didn't look *really* hard).
It's at the point now where deleting or changing a word in a *comment*
is the difference between it segfaulting or not.
Here's my script:
use strict;
use warnings;
use lib qw( . );
use Glass;
Here's the Glass.pm module:
package Glass;
use Broken
hello = {
foo = 1,
foo = 2,
foo = 3,
...etc... all the way to...
foo = 61,
foo = 62,
foo = qr//, # change this to 63 and it works!
foo = 64,
};
Here's the Broken.pm module. It does absolutely nothing at all other
than print a message. It just contains a load of comments.
package Broken;
# The next line is repeated 56 times in total.
# foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
(followed by another 55 lines of foo)
print Got to the end of the Broken.pm module;
1;
If I delete one of those comment lines, then the program stops segfaulting.
In fact, I can delete the final 'foo' on the last line and it works, put it
back in and it segfaults again.
If I change that qr// in the Glass module to the number 63 then it works OK.
If I move the qr// line up a line, down a line, or to indeed to any other
line, then it works OK. If I add a line or remove a line, then it works fine.
The fact that there are 64 entries in the hash is suspicious, although
they've all got the same key, so there's only actually 1.
Before I go digging deeper (having already lost most of the afternoon to
this), can someone confirm the problem for me?
Cheers
A
Re: Perl 5.8.8 segfaulting on comments! How can this be?
Nicholas Clark wrote: Have you tested your code with 5.8.9-RC2 yet? Just tried it now and it works OK. Do you think it's worth perlbugging for the record? Thanks everyone. It's a long time since I found a bug in perl! A
Re: london.pm.org web site - facelifted
Andy Wardley wrote: I can help there. How about this? http://wardley.org/london.pm.org/ I tarted up the layout and styling a bit, added the glass onion (I'm determined to get that on at least one Perl site!), updated some of the content on the Home and About pages (including how to check out the site), and fixed up a few minor rendering bugs. I've just rendered a few pages in the new style, so the Meeting and People tabs don't go anywhere, along with most of the links in the content. A
Re: london.pm.org web site - facelifted
David Dorward wrote: Can features which only work with JS on be added entirely with JS please? Hmmm... the JS *should* be non-JS friendly because onclick will be ignored by non-JS browsers. The Small/Large is switched on CSS rather than JS, but that will fail if you've got CSS disabled. Either way, it's sub-desirable. So yes, I can fix that up to only add the switchy tab if JS is enabled. I was being lazy for the first iteration :-) A
Re: london.pm.org web site - facelifted
Dirk Koopman wrote: Personally I would go for a completely different base colour, or stick to the original orange, rather than shift slightly in the yellow/green direction. It's the same orange, at least the strips down the side are. The darker orange bits in the header are the same hue (30 deg), but with less saturation and brightness. So no shifty business going on there. http://wardley.org/london.pm.org/colour_compare.gif Old at the top, new at the bottom. Different colours are relatively easy, though. e.g. http://tt2.org/ I'll add it to the wishlist. A
Re: Curry tonight: Manchester 19:00ish Oxford Road (and distributed)
James Laver wrote: Distributed curry is definitely a winning idea. Ack. Ours was quite tasty and rather cheap for a meal out in london (even when you factor in we had two bottles of wine between 3 of us). Mine was a rather splendid meal in the Bombay Brasserie in Woking. I dined with a fellow Perl hacker and we talked about Perl, PHP, SQLserver and TT3. Only downside is we failed to find excellent beer within easy reach of the station. Luckily for you I had several pints of pre-curry Red Something in the Weatherspoon's just a few doors down. It was a splendid ale. I think that'll keep our B/C ratio sufficiently high when averaged over the whole group. I'm happy to cover for you this time, but don't let it happen again. Beer must be drunk! So must I be. A
Re: *.perl.org facelift
Léon Brocard wrote: http://slashcode.cvs.sourceforge.net/viewvc/slashcode/ ... which would make it even easier for people to tweak. Any volunteers? I'll gladly take it on, but I haven't heard anything back from pudge to suggest that he's open to the idea. A
Re: Perl is Alive! (Dispatch war rocket AJAX...)
Nigel Hamilton wrote: TPF have never owned the domain perl.com - but they have always had a right to own it. The TPF and the community have a right to get the goodwill back. Tom has never been the owner of the goodwill and trademarks associated with Perl. Tom Christiansen was one of the figureheads of the Perl community long before TPF existed. In particular, he was responsible for much of the core documentation and, of course, the camel book. In my mind, that makes him very much an owner of the goodwill associated with Perl, if not the legal trademark. I believe (but don't have any facts to hand) that he was hosting perl.com before Perl was trademarked. My earliest recollection of Perl being trademarked was around '97 or '98 when ORA started doing Perl conferences and I'm sure perl.com was around before that. I also find it very hard to believe that he would have registered and run perl.com without Larry's consent. So the fact that Larry (presumably) consented to him owning perl.com could be construed by a court of law as a failure on Larry's part to adequately protect his trademark. By not telling Tom to stop with perl.com he may have given up his right to claim that perl.com was an integral part of the Perl[tm] trademark. IANAL but I think that trying to paint Tom as a cyber-squatter would be morally questionable if not legally shaky. return perl.com to its rightful owner. I agree that it would be in Perl's best interests if TPF controlled perl.com but I'm not convinced that they have a right to demand it. A PS I think we should make Perl is Alive! the unoffical secret verbal handshake by which Perl mongers make themselves known to each other (spoken in the style of Brian Blessed in Flash Gordon, of course). The correct response would be something along the lines of Dispatch war rocket AJAX to bring back the document body from a server-side Perl web application handler powered by Catalyst, DBIx::Class, TT, Moose, and many of the other fine modules available from CPAN that make Perl a robust and reliable platform for enterprise-ready solutions. Hmm... might need to make the response a little more snappy... but I think it's got promise :-)
Re: london.pm.org web site
Léon Brocard wrote: http://london.pm.org/ is our web site. It's orange, which is nice. However, I can spot a few things that we can improve: 1) It still lists Greg as leader 2) It doesn't list how to check out the website as below 3) It doesn't have an onion tilted at a jaunty angle 4) It doesn't mention the secret Perl verbal handshake I can help there. brucey Alright my loves, you've got as long as it takes to shake up the london.pm.org web site... starting from... now! /brucey A
Re: london.pm.org web site
Aaron Trevena wrote: My dad was on the Generation Game, I think he was demonstrating carving a swan out of ice. Did he do well? A
Re: Perl is Alive!
Ovid wrote: Marketing is not inherently evil. Can I put in a plug for branding, too. A
Re: *.perl.org facelift
Ovid wrote: Out of curiosity, have you spoken with pudge about this? He hasn't seemed interested, but I could be wrong. I've (just) pinged him a heads-up in case he hasn't seen it, but his other comments in the thread seem to suggest that it's not his highest priority right now. But that's cool. It was really only supposed to be a bit of tentative dabbling to see where inspiration might strike. A couple of people have already expressed an interest in dabbling with it further so it might go somewhere yet. I was also mindful of Andy's comment: However, I'd strongly suggest that you come up with actual prototypes of what you want to change to BEFORE contacting them. Lord knows they've had enough people bluster in and say I want to change perl.org's front page! with no results. With that in mind, I thought it better to sketch out some ideas first before putting my head above the parapet. I suspect that it'll end up being a bikeshed-painting project, but we live in hope. A
Re: *.perl.org facelift
Robin Berjon wrote: Well for one I think it's a clear improvement over what's there today. On the downside I would say: a) you probably didn't intend this but it looks a little bit too much like the default Drupal theme, No, I didn't intend it, but I noticed the similarity straight away. It's that damn onion that looks like the drupal teardrop thingy. Shame, 'cos I quite like the onion. The colours are all easily changeable, though (they're color/gradient overlays on separate layers). b) it has a lot of round stuff in it, and I think that's going to look dated next week. Yep, agreed. I started off from some templates I had from a previous project from a few years ago when roundy-roundy was all the rage. But it ended up looking a bit too Fischer-Price. I think it's a good start though. Thanks. It's the first layer of undercoat on the bike shed. :-) A
*.perl.org facelift
I put a few ideas together for a *.perl.org facelift. http://wardley.org/use.perl.org/test.html At the moment it's just a stick in the ground. It's probably the wrong kind of stick and not in the right place, but it's a start. Pass it on. A
Re: Perl is dead
Dave Hodgkinson wrote: In response to Ovid's post on use.perl: Also see this lively discussion in Reddit. http://www.reddit.com/r/programming/comments/7h3pa/perl_5_is_dying/ A
Re: LPW Slides: Badger Power
Richard Huxton wrote: I must say I'm a bit disappointed that it wasn't about how you were bitten by a radioactive badger and now have the ability to snuffle through hedgerows and spread TB to cattle. That's probably me though :-) Oh that happened too. I just didn't have time to fit it into the talk. A
LPW Slides: Badger Power
The slides for my Badger Power talk are here, complete with extended footnotes. http://badgerpower.com/talks/lpw2008/start.html This culminates in a bit a rambling rant about how hard it is to write generic software, why OO is fundamentally broken, and why coder reuse is more important than code reuse. http://badgerpower.com/talks/lpw2008/slide58.html I only mention this because a) it ties in nicely with something Ovid blogged about a few days ago (coincidentally on the same day I gave the talk, although I missed it until this morning, which was probably a good thing for the people in the audience). He also mentions Schwern's skimmable code talk of which I'm a fanboy. http://use.perl.org/~Ovid/journal/37975 And b) it's an issue that cropped up in several different talks at LPW, including something that Matt Trout said (reported via another talk) along the lines of This isn't fucking rocket science... so why is it so hard to write reusable software?. I don't claim to have any answers, btw. Nor is Badger the panacea for any|all of OO's ills. Far from it. But I do think skimmable/skimpy code is a Good Thing. Pictures of cute animals seems to help, too. And finally, thanks to everyone for making LPW a most enjoyable day. A
Re: Duh v D'oh
Paul Makepeace wrote:
foreach my $given_source (%publication_map_by_name) {
ENOKEYS: You are locked out of the house.
A
Re: Seeking UML tips or alternatives
[EMAIL PROTECTED] wrote: [...] a detailed project plan for the management and also some of the investors. They want it to include clear diagrams and I've been recommended UML, Did the management/investors recommend UML? The reason I ask is that UML diagrams probably won't mean that much to your average executive. Which means they either want the diagrams as evidence that you know what you're doing and have done the proper planning (even if they're not qualified to interpret them), or what they really want is a few warm and fluffy system overview diagrams that they can put in powerpoint presentations to impress other management types. Something like this (googled at random): http://cryptodrm.engr.uconn.edu/adder/diagram.png http://www.walking-productions.com/itj/docs/System_Diagram.gif Either way, I would start by producing such a diagram showing the general architecture of the system. It's a good overview for both you and the suits. The main purpose is to show the boundaries of different parts of the system (i.e. break a big problem down into a number of smaller, but well-defined problems) and to identify what is part of the system and what isn't. You should then produce an Entity Relationship Model (ERM), even if the management don't really want or need it. Wikipedia has enough info to get you started: http://en.wikipedia.org/wiki/Entity-relationship_model This is also a good intro: http://tinyurl.com/yw6f6e The purpose of creating an ERM is to identify the entities (nouns) in your system and the relationships (verbs or adjectives) between them. The entities will (usually) end up being the tables in your database and/or the object classes in the system. It is a relatively simple process to turn an ERM into a data abstraction layer using your ORM of choice (e.g. DBIx::Class). An ERM is the most important diagram you need and *possibly* the only one. Class diagrams are useful to show the inheritance tree of different classes (if you have such a thing), and sequence diagrams can help if you've got some complex interaction between different parts of the system that you want to model. Use case diagrams might also be required to convince yourself (and others) that you're all in agreement about what the system should do from the end-user's perspective. But apart from that, the rest of UML just isn't worth the effort. It's a lot of paperwork designed to increase the billable time of highly paid analysts who can't code. All IMHO, of course. http://en.wikipedia.org/wiki/Class_diagram http://en.wikipedia.org/wiki/Sequence_diagram I'm not sure if plugging one's own business on the list is considered OK or not, but if you're looking for someone to help with this process, or want someone to look over the diagrams you produce to sanity check them, then feel free to email me off list. Cheers A
Re: Perl's lack of 'in' keyword
Paul Makepeace wrote:
Guido eventually Making a Decision.
What's interesting is that python gets ?: without any additional keywords,
or... punctuation: http://www.python.org/dev/peps/pep-0308/
X if C else Y
I don't like having the condition in the middle of the expression.
It would have been better to add a 'then' keyword.
C then X else Y
It's certainly easier on the eyes than this:
C ?? X !! Y# Perl6 - not yummy
Having the condition in the middle is consistent with Guido's ass-backwards
approach to side-effect expressions. Like having guard expressions at the end
of list generators:
[ x for xs if c ]
This looks wrong to me because the expression is non-associative. Whichever
way you group it (mentally, if nothing else) is wrong:
[ (x for xs) if c ]# NOPE
[ x for (xs if c) ]# NOPE
In fact, it really means:
[ (x if c) for xs ] or [ for x { if c { yield x } } ]
I suspect it's down to Guido's insistence on using an LL(1) parser to keep
the language stup^H simple.
A
Re: Perl's lack of 'in' keyword
Paul LeoNerd Evans wrote: my $foo = $a + $b; The meaning of '+' is already known to most people so there's no cognitive overhead there. One of the things _I_ like about Perl is that it accepts the fact that larger alphabets yield shorter sentences. I get what you're saying, and agree to some extent. But you've missed out the words from the linguistic analogy. Larger alphabets like Japanese, for example, do indeed yield shorter sentences. However, they are inscrutable to anyone who hasn't spent several years studying the characters in the alphabet to learn what they all mean. Languages with smaller alphabets like English and other Latin-derived languages are also able to yield small sentences, but they do so by having large lexicons. Instead of inventing new characters to represent new concepts, we take the existing alphabet and make new wordicles and speaklets from them, quite noproblematically. In the extreme case, languages like German are fromseveralwordswholesentencemakers (*cough* Java *cough*). So shorter sentences are yielded by having symbols that represent semantic concepts that are otherwise difficult to express by the fact that they require more elaborate sentence construction. Or, more succinctly: symbols confer meaning. The number of character in the symbol and the alphabet in which it is written are less important than the fact that it exists in the first place. What this comes down to is that @a ~~ @b and @a like @b (for example) are both significantly shorter than writing out the equivalent code in full. The fact that like is 2 characters (but only one keypress) longer than '~~' is, to me, largely irrelevant because I've reduced a whole block of messy code into one expression comprised of a mere 3 symbols. I'm sure that in time my branebox will come to recognise '~~' and just read it the way that it currently just reads the word like and knows what it means. But even then, I might still prefer to write like (or matches or something similar) for the sake of any other non-Perl6 speaking visitors I might have dropping in on my code. It reads like a sentence instead of looking like a graffiti tag. Perl isn't afraid to use symbols if it means they tend to give shorter statements that are quicker to read or write. I like short too. Succinct is good, but cryptic isn't. IMHO, Perl should be choosing more words for those symbols instead of choosing new letters to add to the alphabet. YMMV, of course. A
Re: MVC (Re: DBIx::Class - Related Tables)
Randy J. Ray wrote: Izzat the one what has to do with not getting into a land war in Asia or a battle of wits with a Sicilian[*]? That reminds me of John Cleese's talk on the important of making mistakes. Of course there are true copper bottomed mistakes, like spelling the word “rabbit” with three m’s, or wearing a black bra under a white blouse, or, to make a more masculine example, starting a land war in Asia. http://www.ilstu.edu/~eostewa/Art309/Mistakes.htm A
Re: Perl's lack of 'in' keyword
Aaron Trevena wrote: In fact it's pretty well known that Orwell was no fan of the stalinist communism he saw in Spain, Never mind that. What was his position on the prevalence of non-alphanumeric operators in Perl? :-) A
Re: Perl's lack of 'in' keyword
Nigel Rantor wrote: Let's take ~~ for example. It's arguably harder to type than in. And by that I mean for *me* it is harder to type. I agree. ~~ is particularly hard for me to type on keyboards that put it at the bottom left right next to the shift key (i.e. Macs). 'in' is much easier to type, and also much easier to read. Although ~~ is somewhat easier to read in my head, now that I know it's called wiggly wiggly. ;-) As others have pointed out, '~~' isn't quite the same thing as 'in'. It would be potentially confusing in this kind of situation: @foo ~~ @bar # arrays are identical @foo in @bar # not what it looks like! However, I certainly would be in favour of having an extra 'in' keyword just for those special cases where it does make sense. It would be nice if we could re-use it in for loops, too: print $x for $x in @y; I'm sure it'll be easy to add it in Perl6. A
Re: DBIx::Class - Related Tables
Dave Cross wrote: This is probably simple, This is the general problem that I have with ORMs. You have something which is a fairly straightforward SQL query but can't figure out how to make the ORM generate the query that you already know you want. It's a bit like using a phrasebook to speak a foreign language. They're great for ordering a croissant in a cafe, but are ultimately limited and in some cases, can be counter-productive. A
Re: DBIx::Class - Related Tables
Paul Makepeace wrote:
One aspect, that befalls any abstraction system, is that you run into
a situation where a lot of work is being hidden behind a simple
interface.
True, although this is something that can be easily mitigated with a
bespoke object method or two and an orcish manoeuvre.
package My::User;
use base 'My::Database::Record';
sub roles {
my $self = shift;
return $self-{ roles } ||= {
map { $_-role = $_ }
$self-model-roles-fetch( user_id = $self-{ id } )
};
}
sub has_role {
my ($self, $role) = @_;
return $self-roles-{ $role };
}
These kind of methods can be auto-generated quite easily.
Nevertheless, it does require someone to think about these kind of
issues and design the system accordingly.
A
Re: MVC (Re: DBIx::Class - Related Tables)
Raphael Mankin wrote: If there were many such IF statements in my templates I would tend to use separate templates for the user states (or whatever) and let the controller route to the appropriate one. Sure, but this could be the site/login template, included from the site/sidebar which got pulled in by the site/layout template, and so on. It's probably just one of many different template fragments that render parts of the UI chrome and have little or nothing to do with the application-specific functionality of any particular URL/page/handler. For my controller to make these decisions would require it to know a lot more detail about how I've structured my templates than I would be comfortable with. That's not to say that there aren't times when it's the right thing for the controller to influence the presentation, as long as it can do so relatively cleanly. For example, an application controller might change the INCLUDE_PATH of a template engine to add one or more template directories, so that the user/status template gets magically selected from the right directory, either templates/user/logged_in or templates/user/admin, for example. However, that does tend to cement the presentation architecture and application server quite tightly together. Of course, that may be *exactly* what you need for a particular application (delivering mobile content via handset-specific view objects comes to mind as a recent example of this), but that doesn't mean it's always the best approach. I totally agree that the application controller should decide about selecting the right template based on the task that it has just performed (e.g. displaying the login/failed.html or login/success.html template), but in this case we're talking about the various presentation aspects that aren't necessarily the responsibility of any particular controller or single part of the application. A
Re: DBIx::Class - Related Tables
Aaron Trevena wrote: 99.9% of the time that is either a rare edge case, or a case of not being totally up to speed. Depends on the ORM, though. I'm not knocking DBIC in particular (which is certainly one of the best, IMHO), but there are a lot of other ORMs out there in various different languages, and many fall short of what DBIC can do. It's a case of knowing your tools, Absolutely. Once you know a particular tool, you're laughing. But part of the problem is that there are so many different tools (in the general case) and they're all similar, but different. I think I used a total of 4 different ones last week, 2 in Perl (DBIC and my own), one in Python (SQLAlchemy) and one in PHP (doctrine - not through choice, I hasten to add, but I had to recommend something to a PHP shop). Although many of the basic concepts are portable, figuring out the specific detail can be painful, especially if the documentation isn't up to scratch. Of course, that's a rather exceptional situation. But it does illustrate the point that SQL by itself is a very portable skill because it is (for the most part) standardised. Investing time in learning SQL will never be wasted. Unfortunately we don't have anything approaching even an ad-hoc standard for ORMs, so it's often back to square one every time you pick up a new one. It's particularly difficult with those that require you to learn a whole bunch of new concepts (or adjust your previous idea of similar concepts to a new mental model) before you can get as far as fetching a record from a table. I think most ORMs are guilty of this, although it probably goes with the territory to some extent. You can spend hours, days or even weeks getting up to speed with an ORM only to find out that it falls short of what you actually want. Again, this is a comment on ORMs in general, rather than DBIC. perl ORMs allow you to fall back to using handcoded SQL, or to over-ride default behaviour, Yes, I think that's definitely the right approach. If you already know SQL then an ORM should make it easy for you to use it, or to plug in your favourite SQL generation tool (e.g. SQL::Abstract) to create it for you. But I wonder if that isn't acknowledging that the best ORMs are those that make it easy to break the abstraction and get down'n'dirty with raw SQL. I stand by my phrasebook analogy. An ORM provides you with standard phrases (i.e. queries), written by experts in the field (or generated by code that was written by experts), that you can use to get the job done without having to really understand the underlying language at all. That's not to say that you can't or won't pick up the language as you go along, or that it won't be useful in the long run. But it is the tool by which a lay person can translate their intent (coffee, please / insert this record) to a native format (cafe s'il vous plait / INSERT INTO ...) that can be understood and acted upon. Well, that's how I see it anyway. It wasn't meant to be belittling in the comical My wife has been misplaced by my bagpipes kind of bad translation sense. A
Re: DBIx::Class - Related Tables
Dave Hodgkinson wrote:
Then what's the benefit of an ORM? (general question, not just to you :)
The answer is abstraction. What was the question? :-)
Actually, there's no standard set of benefits because there no such thing
as a standard ORM. It has come to be used as a catch-all term for any code
that talks to your database so you don't have to.
Typical features of ORM-alike modules are:
* Schema definition - so that the ORM code can make assumptions about
what fields to put/get to and from the database tables, what keys are
used to identify records and so on. Some ORMs can create tables from
this schema, others can intuit the schema from existing tables.
The key thing here is abstraction - your schema is written in a generic
language that you can inspect programmatically and translate to specific
formats (e.g. to accommodate differences between MySQL, Postgres, etc)
* SQL generation - with the above information, an ORM can generate SQL
statements to perform simple insert/update/delete/select queries.
$zoo-insert(
animal = 'Badger',
plays = 'Tennis',
eats = 'Nuts and Berries',
);
The key thing here is abstraction. You're saying that you want to
store the information in the zoo, without having to worry about the
specific details of how that is done. Apart from the obvious benefit
of not having to litter your code with SQL, it means you can easily
change the details of the implementation at a later date if you need
to.
* Row data -- object mapping. The true purpose of an ORM is to
handle the mapping between relational data and programming objects.
The generally accepted wisdom here is that there will always be an
impedance mismatch between the OO and Relational paradigms so don't
expect a faithful translation.
my $animal = $zoo-fetch( animal = 'Badger' );
print 'Badger plays ', $animal-plays;
The key thing here is, you guessed it, abstraction. You let the ORM
handle the messy business of doing the mapping so that you don't have
to litter your code with it. You get to work with familiar objects in
programming space and effectively forget about how the information
that they're representing and manipulating is store persistently.
* Relation mapping. An ORM can represent the relations between tables
and hide all the complexity of gnarly JOIN statements behind simple
object methods.
foreach $track ($album-tracks) {
...
}
Yes, our friend abstraction is here again. You don't need to know
if the relation is implemented as a back-link from track to album
(e.g. album.id - track.album_id) or via an album_tracks link table
(album.id - album_track.album_id + album_track.track_id - track.id),
and (in theory) you don't need to worry about any changing the structure
of the database at some point in the future, because you'll only need
to update the relation specification used to generate the tracks()
method.
Hiding implementation details is (usually) a Good Thing. The problem is
that in practice, the more you hide the database, the harder it is to use
its full power.
I'm a big fan of an application-specific wrapper over the d/b that
does what you need, so in Dave's case a get_highest_version() sub
with the SQL inside. Is that now passé?
Me too. When I'm writing my application code I want to talk in business
logic. I specifically *don't* want to know anything about how my data is
stored persistently, be it in a database, YAML files, or encoded in the
arrangement of chocolate sprinkles on a slice of cake.
The approach that I have found works best (for me at least) is to have
one module for each table in the database (subclassed from a generic
DB::Table module), and another for each record (subclassed from a generic
DB::Record module). using one class for both table and record is broken,
IMHO.
The table module defines a schema, implements basic insert, update, select
and delete methods (using auto-generated SQL). The record module
(or ActiveRecord if design pattern parlance is your thing) is used to
represent each instance and has table-specific methods auto-generated.
The nice thing is that you can easily add your own custom methods to either
table or record class, so it allows you to align them closer to your
business logic.
The final part of the equation is an ActiveRelation class (hierarchy actually
- to represent various different relation types). That's where things start
to get, um, interesting.
In practice, this approach takes a little longer because you're building a
bespoke data abstraction layer each time instead of using a more generic
solution (although the dividing line is thin and often disappears when you
look at it directly). However, this is paid back in triplicate when it come to
writing the
Re: perl bless/overload performance problem on RHEL
It seems they've fixed the bug. http://rhn.redhat.com/errata/RHBA-2008-0876.html A
Re: Pub recommendation needed
David Cantrell wrote: Can anyone recommend a pub near Hampton Court for lunch? The Albany is about 10 minutes walk from the station (~3 mins in a car). Lovely location on the river, but popular and often busy. It's Gastro Pub style. Turn left out of the station. Go a few hundred yards, turn left again into Summer Road, over the railway Xing, around the bend, turn left into Queen's Road. It's at the end of the road. http://www.the-albany.co.uk/contact.htm The Lamb and Star is also gastro-pub style. It's usually a bit quieter. Left out of the station and keep going. It's on the right. http://tinyurl.com/4kahmo HTH A
Re: [OT] select and sysread problem on solaris
Paul Johnson wrote:
Recently, another thirty or so pipes have been added to this group and
very occassionally I am noticing a problem whereby select will indicate
that a pipe is ready for reading and sysread will attempt to read from
the pipe, but there is actually nothing there to be read, and so the
sysread call hangs waiting for input.
Could it be a deferred signal? See perldoc perlipc for more info.
From some code I wrote:
while (1) {
$client = $server-accept() || do {
# accept() can fail in Perl 5.7.3 and later thanks
# to safe signals which can interrupt an accept()
# so we detect this and ignore it
next if $!{EINTR};
last;
};
# handle $client request
}
It's not using select(), but it could be a manifestation of the same
issue.
HTH
A
Re: svk v git + possible gig
Paul Makepeace wrote: Anyway, so has anyone moved from svk to git? Any thoughts on the experience? I still use SVN for most of my stuff. I could never figure out SVK. Git and Mercurial are both a doddle to set up and use. If I need to do any complex branching/merging then I'll typically check out a version of the repository from svn, make a mercurial repository from it (`hg init`), do all my branching and merging in mercurial and then commit back into SVN when I'm happy. It is, admittedly, a rather sub-optimal state of affairs to be using two halves of different source control systems. And it only really works for those experimental feature branches that you're planning to merge back in pretty soon or throw away. But anything that avoids having to branch/merge in SVN is usually a good thing IMHO. I haven't upgraded to 1.5 yet, but it looks like they've made branch/merge far less painful to use. A
Re: Getting my TODO list down
Peter Corlett wrote: If a business idea can't justify spending a tenner or so a month on a virtual server, it's surely not worth pursuing? Sure, but not all web sites are businesses, and not all business have people who are comfortable using a command line, or even configuring a server using a fancy web interface. Installing a PHP script is as simple as uploading it to your server (or your ISP's server). It is precisely no harder than uploading an HTML page. That is why it's so widely used (I hesitate to use the word popular). HTML has virtually no barriers to entry. Anyone who can use a text editor (or WYSIWIG editor) can write an HTML page. Lots of people who aren't already designers or programmers do this all the time. Once they've got HTML cracked, PHP is no harder than changing the file extension and adding some new tags to the soup. Lots of people progress from HTML to PHP just this way. When it comes to installing a PHP library, they already know how to do it- just upload it to the server and it's installed! Changing the configuration is as simple as editing a web page! Hey this is easy! Before you know it, those people are calling themselves web designers and web developers and going off to work for companies who build real web sites for other companies. And of course, they use PHP, because it's what they already know. Sure, the programmers typically use better languages because a) they know that better languages exist and b) they're prepared to put the effort in to get the reward back, so they don't mind installing stuff, changing Apache configs, and so on. But most web designers and web developers aren't real programmers. No disrespect or snobbery intended, but to them programming PHP isn't much different to programming HTML or CSS. So it's not that they can't justify spending the extra money for a virtual server, It's more the case that they wouldn't know what to do with it. A
Re: perl bless/overload performance problem on RHEL
Elliot Moore wrote: http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ (https://bugzilla.redhat.com/show_bug.cgi?id=379791) And here: http://use.perl.org/~nicholas/journal/37274 Which says: So to be fair they are still asleep on the job. Where's I'm awake and doing this stuff for free. That's the real tragedy IMHO. Some RedHat dude is getting paid to make a mess of Perl while Nicholas works for free to fix it. They should cut out the middle man. A
Re: [job advert] looking for a perl person to write a web control panel
Chris Jack wrote: Rumour is Ross Perot made his billions on change requests... I love that clown act he does. A
Re: [job advert] looking for a perl person to write a web control panel
Dirk Koopman wrote: I agree. This is something that people that want fixed prices never seem to factor in. The other thing they often forget is fixed spec. I've had clients who think that fixed price equates to an all-you-can-eat buffet with an open bar. A
Re: [ANNOUNCE] Surrey.pm Social, Thursday 25 Sep
Simon Luff wrote: I'm up for this, who else we got? Ooops! A major foul up on my part, I'm afraid. I forgot to check with my Good Lady Wife, and it turns out I'm supposed to be babysitting. Can't find anyone else to take my place at this short notice. Bugger. As they say. I can be there early as long as I'm off by 6.45. Will anyone else be there early enough to make that worthwhile? Or I can be back around 10, if anyone plans on staying that late. Or I'm totally, definately free next thursday if we want to change the date or do it again. Sorry bout that. Consider me slapped. A
Re: [ANNOUNCE] Surrey.pm Social, Thursday 25 Sep
Nicholas Clark wrote: You mean that you don't want to come to the london.pm social meeting that evening? Awww.bollocks! A
Re: Surrey.pm (was: back to the 80's)
Sam Vilain wrote: How about the Weyside? Not an ale pub but a few on tap, and a nice meeting spot. Yep, that works for me. How about next thursday? A
Re: Surrey.pm
Piers Cawley wondered: ..if there's any nearby town in Surrey whose name begins with D. Simon Wistow wrote: Dorking? No, I'm typing with my hands this time. :-) Guildford or Surbiton would be better, being on fast (haha) rail links up t'smoke way. Dorking is a smaller, harder to get to, and generally full of antique shops. I'll look into some of the pubs in the area. Ho ho ho. A
Re: Database setup
Kate L Pugh wrote: So you're starting a new project, and you've designed a database schema, and you want to write some code to set up the tables in the database. I use a template to generate the setup script for me. A
How many lines of Perl code?
Just for fun: How many lines of Perl code have been written? Ever. Here's my back-of-an-envelope guess: First, how many Perl programmers are there? Well, let's say that there are ~200 london.pm members who live in the london catchment area and can be bothered to go to a london.pm meeting. Approx 1 in 5 Perl programmers care about Perl enough to go to a meeting. That suggests there are around 1000 Perl programmers in the London area. The London catchment area covers approx one fifth of the UK population. That suggest there are around 5000 Perl programmers in the UK. There are also lots of programmers who write the occasional bit of Perl code, but we're not worried about them right now. They don't add much to the hill of beans compared to the hackers writing Perl day in, day out. Now, how much Perl does the typical Perl programmer write? Well, I'm guessing that the average Perl programmer has written 50k lines of Perl code. That's only 10k lines a year over 5 years, or 200 lines a week. That suggests that 5k * 50k = 250 million lines of Perl code have been written by UK Perl programmers. If the UK contains roughly 1/4 of Europe's Perl programmers, then that is a billion (1 x 10^9) lines of Perl code in Europe. The US is roughly the same size as Europe. The rest of the World probably accounts for the same again. So my guess is that approximately 3 x 10^9 lines of Perl code have been written. Or in other words, there is one line of Perl code for every 2 people on the planet. Who will you share yours with? Can anyone do any better? Or think of a more original, accurate and/or amusing way of estimating? CPAN must be a rich source of clues. Anyway, I'm off to write the three-billion-and-first line of Perl code A
Surrey.pm (was: back to the 80's)
Richard Atkinson wrote: If you don't mind travelling to Guildford, Surrey [...] I'm rather partial to beer, myself. I live in Guildford, Surrey and I'm also rather partial to beer. I think it must be time to organise the second ever Surrey.pm meeting. A
Re: [OT] accessors pragma
Steve Purkis wrote: # chaining: $obj-foo( $a_value ) -bar( $another_value ); I recognise how useful this can be but I'm not a fan of it. IMHO, the foo() method of an object should return the foo of the object. It shouldn't magically switch to returning the object itself just because you passed a parameter. Of course you can argue that it shouldn't magically switch from getting to setting based on there being a parameter or not, but that doesn't bother me so much. They are both operations on the foo of the object and the method name doesn't make any implication about what kind of operation. The only implication is that you'll get the foo returned back when called. On the other hand, I find it quite acceptable to have get_foo() that returns the foo, and set_foo($new_value) which sets the new value for foo and returns the object. In this case, the action is explicit in the method name. # this is when chaining is good, IMHO $obj-set_foo(10)-set_bar(20)-set_baz(30); Question is: what style should be the default? I'm not looking for a debate here, Ooops, sorry. If you just want numbers, then I'm for classic. I like chainability, but only if the accessor is prefixed with 'set_' or something similar. The foo() should always return the foo(), IMHO. If it doesn't then chainability is broken for accessing items. # why chaining is bad, IMHO $book-author()-name(); # author.name $book-author($a)-name(); # book.name One returns the author name, the other returns the book name. And what if $a is undef? Does that return the book name or author name? Oops, sorry. No debate. I forgot. If you have a preference here, let me know. Dark chocolate and raspberry wheat ale. :-) A
Re: Kibo and Religion - Inventing Deities
Nigel Hamilton wrote: Talking about inventing deities ... was anyone around when the GOD 'Kibo' was invented on Usenet? Yep. I've met and partied with Kibo himself. I have a special Kibo Love Number of 1, reserved for people who have hugged Kibo and have been told by Kibo that he loves them, man. I may have this wrong, but as I understand it a guy grepped Usenet for all instances of the word 'Kibo'. It became known as kibozing the new feed. Larry Wall also did it for any mention of Perl. http://www.kibo.com/ Enter the time tunnel. A
Re: Dave and Religion
James Campbell wrote: If God created the universe, who created God? God didn't create the universe. God is the universe. That's about the only thing that all the religious texts can agree on - that God, or whatever name you chose for the concept, is omniprescient and omnipotent. This implies that God is everywhere and in everything and there can be nothing that is outside of God. This neatly coincides with our definition of Universe - all energy and matter. So if the Universe is God (or at least the part of it that we can experience in these 4 dimensions) then a proof that God exists is simple - all you have to do is prove that the Universe exists. For the purpose of this experiment, reaching out and touching it should be enough to convince you that it, and therefore God, is quite real. Now that we have proved the undeniable existence of God (for my definition of God), it is clear that each and every one of us, being part of the Universe, is also part of God. God is not something that exists elsewhere, looking down on us, or sending bolts of lightning to Zot us. God is right here and right now. I am God, you are God, we are all God. Hello God. So there's no need to invoke religion, spirituality, or the supernatural to understand and appreciate what God is. Just define the term to mean something more familiar like Universe. It is every bit as magical, mystical and awe-inspiring, but a lot easier to get your head around (figurately speaking - not even God could get his head around the Universe). Hmm... I think I may start a religion. I hear there's money in it... :-) A
Re: Dave and Religion
Andy Wardley wrote: That's about the only thing that all the religious texts can agree on - that God, or whatever name you chose for the concept, is omniprescient and omnipotent. This implies that God is everywhere and in everything and there can be nothing that is outside of God. Iain Tatch wrote: Only in Monotheistic religions... I'm sure you're right. I don't really know much about religion at all. In fact, I wasn't being entirely serious. Well, half-serious. I like my definition of God == Universe because it works for me. But the whole point of religion/spirituality/belief is that it is entirely personal. It should be based on your own beliefs, not on what anyone else tells you to believe. I don't want my karma to run over anyone's dogma. :-) Too late: http://members.aol.com/Heraklit1/ May the force be with you. A
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Paul Johnson wrote: I think I wrote my first ever goto code in C yesterday. Way back when I was a teen-geek, I played around writing a few games, mostly in C, with the odd bit of assembler thrown in for bad taste. One of these was a rip-off of the classic Tron light-cycle game. I got myself in an almighty mess trying to write a structured control loop that would handle 2 player input or 1 player and computer. I had to read keyboard scan codes to detect multiple keys being pressed simultaneously. This made it particularly gnarly, although I forget the precise details. Whichever way I carved it up it got ugly. The code resisted all attempts at being structured. After hacking on this same chunk of code for days and getting no further, I suddenly realised that a simple goto made the problem collapse into thin air. I was enlightened. The use of goto is not always considered harmful. A
London.pm identity cards
You know how people are always asking what it means to be a london.pm member? Do you have to live in London? Do you have to attend meetings? Do you have to watch Buffy? Or do you just have to be subscribed to the mailing list? Well I have a great idea! How about we all carry London.pm ID cards? That way, you could walk down any street in any town in the world and instantly know who was a card-carrying London.pm member just by asking to see their ID cards. It's perfect! It would probably save us millions by all but eliminating benefit fraud, mailing list spam, and people typing messages with their winkies. A (Yep, I've got another day off work and it's raining. Idle minds, etc.)
Re: XML XML::LibXML declarations issue
Nicholas Clark wrote: I smell a conspiracy. :-) Sorry, that's my dick again. I'll get my coat. A
Re: XML XML::LibXML declarations issue
Michel Rodriguez wrote: I actually enjoyed this thread. Me too. It has been the most valuable discussion about XML I've had in ages. It prompted me to go and find out more about RelaxNG (ThankYou, ThankYou), RDF::Schema, and various other XML bits that I really should have kept more up-to-date on. XML still sucks for me, because a beautifully simple concept has been tainted by so much complexity. But then again, I can only be bothered to get worked up about things that I care about. If I didn't use XML so much, then I prolly wouldn't care if it was sucky or not. (I count Andy as a person here, just for the sake of the argument). The lifeform previously known as Andy has been replaced by a virtually intelligent entity called winky;, implemented in a dick-shaped chunk of LeonOrange MemoryGel [tm]. But that is a mere implementation detail. It's the abstraction that is important. :-) A
Re: XML XML::LibXML declarations issue
Dave Cross wrote: Was it the excitment of finishing the book that finally sent you completely over the edge? No, I'm fine thanks. But I think my alter ego has got a few problems. :-) A
Re: insidious biometrics, identity crises
Lusercop wrote: This world is very rapidly becoming a really unpleasant place in which to live. I disagree. The world is a wonderful and beautiful place to live. Some of the people who live it in are unpleasant, but they are the tiny minority. Alas they also tend to have most of the power (which is why they are so unpleasant), but it doesn't mean we're all like that. Welcome to the Global Police State, please have your papers at the ready at all times. I've got a new credit card waiting to be signed. This escapade here: http://www.zug.com/pranks/credit/ is making me wonder what I should sign it with. Presumably there's nothing to stop me from signing it Tony Blair is a Goat or I stole this card, as long as I then remember to sign the same signature each time I used it. And I suppose there's nothing to stop me from having a second credit card that I sign Cherie Blair Blows Goats or even I stole this card too. That would be quite amusing for those times when a shop assistant asks me for another card to verify my signature. Ho ho ho. A
