Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

+ -

  Comment: Makefile generation (Score 1) on 2009.10.01 7:56

by Ed Avis on 2009.10.01 7:56 (#70739)
Attached to: Frozen Bubble begins the journey to the CPAN
To be fair, ExtUtils::MakeMaker is indeed impossible. There was a talk about it called 'MakeMaker is DOOMED' which explains why - although I can't find any working link to it on the web.
Read More 3 comments
Comments: 3
+ -

  Comment: Works for me (Score 1) on 2009.07.17 7:23

I used the MSI to upgrade from the previous stable Strawberry Perl release (installed in the default directory) and it all worked fine.
Read More 20 comments
Comments: 20
+ -

  Comment: lrzip is even better (Score 1) on 2009.07.02 6:54

by Ed Avis on 2009.07.02 6:54 (#69221)
Attached to: The impending death of BZip2
I like lrzip which does a sorting step before LZMA compression, usually giving even better space/speed tradeoff.

XZ is the other plain LZMA-based compressor; it's not clear why both it and lzip need to exist, but hopefully one of them will evolve to support both file formats and thus become the winner.

Read More 4 comments
Comments: 4
+ -

  Comment: Re:Give them their own copy (Score 1) on 2009.06.30 11:09

by Ed Avis on 2009.06.30 11:09 (#69194)
Attached to: Never Let Them Read From Your Database
How about an interface that lets them submit arbitrary SQL queries, but checks them against a whitelist first. So for example your customer might say 'we need to SELECT COUNT(*) FROM FOO' and you would say 'that seems fine, I will add it to the list'. The next day they ask for 'SELECT FRED FROM BAR' and you decide no, the FRED column is an implementation detail I don't want to support forever, so I will not allow them to make that query. That way you have control over what's happening.

If they want a particular query, it's then your call whether to permit it, do the work to add it to your RESTful interface instead, or pick some compromise like making a view for them to use. Or, indeed, deny the request. This gives you more options than allowing or disallowing SQL queries as a whole.

If you want to be especially evil, the SQL gateway can have a mortality rule so that ad-hoc queries are allowed only for one week after they're added, and after that automatically disabled unless re-requested. This could sometimes be better than adding a new documented interface to your API just for a very temporary need.

Read More 9 comments
Comments: 9
+ -

  Comment: Give them their own copy (Score 1) on 2009.06.30 7:11

by Ed Avis on 2009.06.30 7:11 (#69186)
Attached to: Never Let Them Read From Your Database
Why not give them a dump of your whole database and let them load it on their own server? It won't keep up to date, but if ad hoc queries are all they need then that won't matter. Reinventing the wheel by implementing your own home-grown query language instead of SQL may make sense in some cases, but it's not necessarily the best way.
Read More 9 comments
Comments: 9
+ -

  Comment: Alternative tool (Score 1) on 2009.05.20 4:40

by Ed Avis on 2009.05.20 4:40 (#68689)
Attached to: Module Version Vim Binding
You are probably right that most Perl programmers have written such a tool. Mine is distributed as pmq.
Read More 2 comments
Comments: 2
+ -

  Comment: Firefox builds (Score 1) on 2009.05.19 4:35

by Ed Avis on 2009.05.19 4:35 (#68638)
Attached to: Windows? Why?
You might find the prebuilt Firefox binaries from the Mozilla project run faster than the packaged Ubuntu version. (This is just speculation based on my Fedora experience; but it's worth a try.)
Read More 10 comments
Comments: 10
+ -

  Comment: Re:Wishful thinking (Score 1) on 2009.05.13 7:24

by Ed Avis on 2009.05.13 7:24 (#68562)
Attached to: Software Liability Protection
A product does not have negative externalities merely because it harms its owner. You can pour diesel in your own fish tank; only when you pour it in the river does it become an externality.

Of course there is harm to society as a whole from the existence of botnets. But some negative effect or another exists for any product from cars to telephones to books. There are many positive effects on society from the use of software, but makers don't get a special subsidy because of them. The quality of the program (including how secure it is) is taken into account by consumers when deciding what to buy and use.

Now, if consumers aren't able to make an informed judgment there may be a case for regulation. But I find it hard to believe that legislators, government agencies and lawyers would make a better judgment than individuals do. Further, even if you disagree with the government's opinion of what software you are allowed to run, there is no way to get around it. For that reason it's best to let individuals make their own choices.

Read More 14 comments
Comments: 14
+ -

  Comment: Negative externalities (Score 1) on 2009.05.13 7:07

by Ed Avis on 2009.05.13 7:07 (#68561)
Attached to: Software Liability Protection
A product does not have negative externalities merely because it harms its owner. If you want to pour diesel in your own fish tank, so be it; only pouring it into the local river is an externality. So just saying that software makers have a shoddy product is not enough to put them in the same category as noisy concerts, polluting factories, and view-blocking skyscrapers.

Of course, there are negative effects to society as a whole from the existence of botnets, but that is true for almost any product: a car manufacturer is not liable for the effect of traffic jams, although individual car drivers may have to pay congestion charges or taxes. There are also many positive externalities from the use of software, but software makers don't get special subsidies because of those. They make a product and consumers decide whether to buy it or not. The good and bad features of the product are taken into account by consumers when deciding what to buy.

Now, if consumers are not equipped to make an informed decision, or if market distortion such as monopolies stops them exercising a free choice, then there is a case for regulation. However I really doubt that legislators, civil servants or lawyers would do a better job than individuals of choosing which software should be allowed.

Read More 14 comments
Comments: 14
+ -

  Comment: Wishful thinking (Score 1) on 2009.05.13 3:01

by Ed Avis on 2009.05.13 3:01 (#68548)
Attached to: Software Liability Protection

I believe it would fundamentally alter it. Instead of rushing to see how fast we could get our products to market, more time in software testing, penetration testing, fuzz testing, etc.

Do you have any evidence on which to base this belief? Would the natural response not instead be to divert more money to lawyers and compliance officers?

Does this mean you would no longer be able to post code to Github, Sourceforge etc. without first performing security audits and CYA?

Read More 14 comments
Comments: 14
+ -

  Comment: Empty if clauses can serve to document (Score 1) on 2009.03.04 5:46

by Ed Avis on 2009.03.04 5:46 (#67687)
Attached to: Red Flags talk
An empty if-clause with a comment can serve to document your thought processes.

if (is_mungo_sorted @items) {
    # The list is already in the order we need.
}
else {
    # Need to sort them in bogological order.
    @items = rearrange @items;
}

There's often a more elegant way to express things but an explicit do-nothing is sometimes the way I think about the problem, and it's good to have a way to comment that.

BTW, why doesn't the comment box understand <pre>?

Read More 6 comments
Comments: 6
+ -

  Comment: Re:PBP is great, but it's sad it is needed (Score 1) on 2009.01.28 17:08

by Ed Avis on 2009.01.28 17:08 (#67085)
Attached to: I do appreciate the effort...

The semantics of local are quite clear.

Oh, having dynamically scoped variables is very useful and not difficult to understand. I was referring to the semantics of 'local $x;' in particular. What does that statement do? Is it useful and clear, or is it a fairly useless behaviour and a gotcha for the unwary? PBP makes a good argument for the latter.

Read More 31 comments
Comments: 31
+ -

  Comment: Re:PBP is great, but it's sad it is needed (Score 1) on 2009.01.28 10:32

by Ed Avis on 2009.01.28 10:32 (#67074)
Attached to: I do appreciate the effort...
Non-orthogonal features are great. I don't agree with PBP's advice to avoid 'unless', for example. There is a difference between that and things which are just plain useless; or worse than useless - appearing to work most of the time but introducing subtle bugs, for example glob()'s behaviour with spaces in filenames.
Read More 31 comments
Comments: 31
+ -

  Comment: PBP is great, but it's sad it is needed (Score 1) on 2009.01.27 20:15

by Ed Avis on 2009.01.27 20:15 (#67053)
Attached to: I do appreciate the effort...
PBP is an excellent book but it is the most eloquent argument against Perl (and by implication, in favour of Python / Ruby / whatever) that I have read. Pretty much the whole book is a collection of gotchas and workarounds for crufty areas of the language that should have been cleared up years ago. The semantics of 'local $x;' are unclear and can trip up many programmers? OK, here is a sticking plaster. Shouldn't it simply be fixed in the language, with a sensible deprecation timetable and warnings as Python does? Unfortunately that seems to be impossible. Ditto two-arg open or $[ or hundreds of other fossilized linguistic warts which were surely useful in perl 4.036 but mostly serve to obfuscate or create subtle bugs today.

Moose is a great piece of work. But Perl 5 today (and its biggest asset, the CPAN) uses a mishmash of different object systems. In the same timespan Python has successfully moved from one object system to another (so-called "new-style" classes) by first adding the better variant, then marking the old one as deprecated, then adding warnings, and finally (in 3.0) dropping support for the old model.

We end up with a state of affairs where the language to use is not perl, but 'perl that passes perlcritic', where perlcritic is doing the duty of many things that really ought to be fixed in the language proper.

(I think a marketing push in favour of the best CPAN modules is a great idea BTW.)

Read More 31 comments
Comments: 31
+ -

  Comment: Re:Checking permissions is silly (Score 1) on 2009.01.20 11:55

You can open a file, and then stat the file handle...

Doesn't help. The permissions can be changed after you stat and while you still have the file open.

Read More 10 comments
Comments: 10