From robbie at robbiebow.co.uk Sun Oct 1 00:30:17 2006 From: robbie at robbiebow.co.uk (Robbie Bow) Date: Sun, 01 Oct 2006 08:30:17 +0100 Subject: Meeting: Tuesday 26th September 2006 In-Reply-To: References: <001701c6e1c1$ffa26b90$6c01a8c0@metis> <451AC604.3000000@robbiebow.co.uk> Message-ID: <451F6E89.3080800@robbiebow.co.uk> Paul Mooney wrote: > I just looked up what BOINC is... The SETI type stuff doesn't play > nice in my field of work as we need CPU, memory /and/ bandwidth :( > Each worker program can access a database quite a lot so working over > a home users 1Mb broadband connection with its relatively high latency > isn't ideal. SETI stuff is more about small data set, small memory, > high CPU work. > > The EC2 instances "predictably provides" 1.75Gb of RAM which is pretty > good but not enough for some of the things I run. Also if I had a > central MySQL server running on an EC2 instance its physical storage > is somewhere else in S3 world so access would be slow. If you're DB > fits within the "free" 250Gb disk space you could copy the DB back and > forth before and after the work is done I suppose :/ > > But... you really can borrow super computer like resources for any > purpose. World Domination is within my reach!! > Fair enough. Just that I saw there's a protein folding project using BOINC and assumed that your kind of work would be similar. Just goes to show how little I know! From tom at eborcom.com Mon Oct 2 11:43:33 2006 From: tom at eborcom.com (Tom Hukins) Date: Mon, 2 Oct 2006 19:43:33 +0100 Subject: Technical Meeting: Tuesday 10th October Message-ID: <20061002184332.GA60585@eborcom.com> It's been a while, so we're due another technical evening of presentations about what we've been up to with Perl. This time round we have four talks: * Doing something useful with the secrets of life: structural bioinformatics (Lee Larcombe) * Playing Games (Robbie Bow) * What I learned at YAPC Europe (Tom Hukins) * Using the SVK version control system (Nik Clayton) As usual, the meeting takes place at SpiraHellic Multimedia: http://www.spira.co.uk/map.htm Please arrive at 7pm so we can start the talks at 7.15 (latecomers may get glared at or ostracised). Speakers, please let me know which presentation software, if any, you want to use for your slides and mail me your slides ASAP. Also, let me know if I've got the title of your talk wrong. And of course, thanks again for offering to talk. I look forward to seeing you all soon. Please ask if you have any questions or would like to know more about any of the talks. Tom From nik at ngo.org.uk Wed Oct 4 12:40:46 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Wed, 04 Oct 2006 20:40:46 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? Message-ID: <45240E3E.5010909@ngo.org.uk> Hi all, I'm seeking opinions. I'm in the middle of writing some code that wraps someone else's SOAP API. The SOAP API returns XML that looks a bit like this: ... ... ... ... ... ... Basically, CamelCase all over the shop. I'm turning that in to an object, with accessors for the various elements[1]. One accessor per XML element. Assuming you were writing to this API, would you prefer to use: $ml->get_optimistic_lock() $ml->get_OptimisticLock() $ml->getOptimisticLock() to retrieve the value, or something else? At the moment, I'm leaning towards the first. It's simple and regular, but it does mean that the programmer has to translate in their head from the original API documentation. The second lessens that translation slightly, but then the symbol inconsistently uses CamelCase and '_' to separate components. That last one, to my eyes, just looks ugly. N [1] No, not just a hash ref -- debugging "$foo->get_optimistc_lock()" is much nicer than debugging "$foo->{optimistc_lock}". From peter at dragonstaff.com Wed Oct 4 14:49:04 2006 From: peter at dragonstaff.com (Peter Edwards) Date: Wed, 4 Oct 2006 22:49:04 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> Message-ID: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> I usually prefer get_optimistic_lock() as a style of function naming and that's what I use for perl, though I use the getOptimisticLock style if I'm writing VB/VC++ as it's easier for other developers to maintain. In this case the semantic meaning is "get" and the following part looks like an argument to an XPath search pattern so maybe it would be worth considering the calling interface in http://search.cpan.org/~samtregar/Class-XPath-1.4/XPath.pm Or you could use XML::Simple to map to a perl structure and auto-generate some accessor methods from a list of keywords if the XML structure is simple enough. Regards, Peter -----Original Message----- From: miltonkeynes-pm-bounces+peter=dragonstaff.com at pm.org [mailto:miltonkeynes-pm-bounces+peter=dragonstaff.com at pm.org] On Behalf Of Nik Clayton Sent: 04 October 2006 20:41 To: London.pm Perl M[ou]ngers; Milton Keynes Perl Mongers Subject: Opinions: API wrapping, how close to original API should you stay? Hi all, I'm seeking opinions. I'm in the middle of writing some code that wraps someone else's SOAP API. The SOAP API returns XML that looks a bit like this: ... ... ... ... ... ... Basically, CamelCase all over the shop. I'm turning that in to an object, with accessors for the various elements[1]. One accessor per XML element. Assuming you were writing to this API, would you prefer to use: $ml->get_optimistic_lock() $ml->get_OptimisticLock() $ml->getOptimisticLock() to retrieve the value, or something else? At the moment, I'm leaning towards the first. It's simple and regular, but it does mean that the programmer has to translate in their head from the original API documentation. The second lessens that translation slightly, but then the symbol inconsistently uses CamelCase and '_' to separate components. That last one, to my eyes, just looks ugly. N [1] No, not just a hash ref -- debugging "$foo->get_optimistc_lock()" is much nicer than debugging "$foo->{optimistc_lock}". _______________________________________________ MiltonKeynes-pm mailing list MiltonKeynes-pm at pm.org http://mail.pm.org/mailman/listinfo/miltonkeynes-pm From andy at hexten.net Wed Oct 4 12:47:33 2006 From: andy at hexten.net (Andy Armstrong) Date: Wed, 4 Oct 2006 20:47:33 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> Message-ID: On 4 Oct 2006, at 20:40, Nik Clayton wrote: > At the moment, I'm leaning towards the first. It's simple and > regular, but it does mean that the programmer has to translate in > their head from the original API documentation. > > The second lessens that translation slightly, but then the symbol > inconsistently uses CamelCase and '_' to separate components. > > That last one, to my eyes, just looks ugly. The first - by exposing the API in perl you're already making it perlish - so you should use perlish naming conventions. The mapping is regular between perl names and api names - so it shouldn't be too huge a leap for anyone. -- Andy Armstrong, hexten.net From robin.berjon at expway.fr Wed Oct 4 14:43:52 2006 From: robin.berjon at expway.fr (Robin Berjon) Date: Wed, 4 Oct 2006 23:43:52 +0200 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> Message-ID: On Oct 04, 2006, at 21:40, Nik Clayton wrote: > Assuming you were writing to this API, would you prefer to use: > > $ml->get_optimistic_lock() > > $ml->get_OptimisticLock() > > $ml->getOptimisticLock() > > to retrieve the value, or something else? The last. I assume that if you're asking this question, you're not going for your own preferences, and you don't know what the user's preferences are. I'm also assuming that she'll know at least a little from a distance about the original XML. Using something as close as possible to that is probably the most helpful, and easiest to remember. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/ From ian at indecorous.com Wed Oct 4 14:54:52 2006 From: ian at indecorous.com (Ian Malpass) Date: Wed, 04 Oct 2006 16:54:52 -0500 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> Message-ID: <45242DAC.7020806@indecorous.com> Nik Clayton wrote: > Assuming you were writing to this API, would you prefer to use: > > $ml->get_optimistic_lock() > > $ml->get_OptimisticLock() > > $ml->getOptimisticLock() > > to retrieve the value, or something else? Could you support both 1 and 3? Or would that just cause confusion? Ian From abw at wardley.org Thu Oct 5 01:04:26 2006 From: abw at wardley.org (Andy Wardley) Date: Thu, 05 Oct 2006 09:04:26 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> Message-ID: <4524BC8A.2010303@wardley.org> Nik Clayton wrote: > At the moment, I'm leaning towards the first. It's simple and regular, > but it does mean that the programmer has to translate in their head from > the original API documentation. It depends on your target audience. If you're writing something that is an add-on/wrapper for this particular API then you should probably stick as close to the original API as possible, howEverBadlyBrokenItIs. If you're writing something to integrate this API into another project then you should provide a wrapper that is consistent with your existing naming standards for the project. A From dom at happygiraffe.net Thu Oct 5 06:07:26 2006 From: dom at happygiraffe.net (Dominic Mitchell) Date: Thu, 5 Oct 2006 14:07:26 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45242DAC.7020806@indecorous.com> References: <45240E3E.5010909@ngo.org.uk> <45242DAC.7020806@indecorous.com> Message-ID: <20061005130726.GB31835@gimli.happygiraffe.net> On Wed, Oct 04, 2006 at 04:54:52PM -0500, Ian Malpass wrote: > Nik Clayton wrote: > > >Assuming you were writing to this API, would you prefer to use: > > > > $ml->get_optimistic_lock() > > > > $ml->get_OptimisticLock() > > > > $ml->getOptimisticLock() > > > >to retrieve the value, or something else? > > Could you support both 1 and 3? Or would that just cause confusion? That's what XML::Twig does. :) -Dom From nik at ngo.org.uk Thu Oct 5 01:23:01 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Thu, 05 Oct 2006 09:23:01 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> References: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> Message-ID: <4524C0E5.6090608@ngo.org.uk> Peter Edwards wrote: > Or you could use XML::Simple to map to a perl structure and auto-generate > some accessor methods from a list of keywords if the XML structure is simple > enough. That's (sort of) what I'm doing -- my library is making SOAP requests, and SOAP::SOM converts the XML in the SOAP response to a hash ref for me. But I don't want to return this hash ref from my library, because it leads to run time bugs like this: my $lock = $user->{OptimisticLck}; # <-- typo, missing 'o' So my code is converting the hash ref in to a very simple Object::InsideOut object with accessors (no setters) for each hash key[1]. Since the hash keys are used exactly once (when the object is created) there's only one place where I need to verify that the spelling is correct. This will lead to user code like this: my $lock = $user->get_optimistic_lck(); which will result in a friendly(ish) compile time error, rather than an irritating, hard to track down run-time error. N [1] As an aside, there's quite a lot of tedious make-work code involved in doing this. Before I sit down and write one, is anyone aware of a simple mechanism to take a hash and a mapping of hash keys to method names, and generate a simple object from the two? From nik at ngo.org.uk Thu Oct 5 01:15:09 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Thu, 05 Oct 2006 09:15:09 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45242DAC.7020806@indecorous.com> References: <45240E3E.5010909@ngo.org.uk> <45242DAC.7020806@indecorous.com> Message-ID: <4524BF0D.8030406@ngo.org.uk> Ian Malpass wrote: > Nik Clayton wrote: > >> Assuming you were writing to this API, would you prefer to use: >> >> $ml->get_optimistic_lock() >> >> $ml->get_OptimisticLock() >> >> $ml->getOptimisticLock() >> >> to retrieve the value, or something else? > > Could you support both 1 and 3? Or would that just cause confusion? It's easy enough to do. I'm not sure it'll lead to maintainable code in the future though (in the sense of consumers of this object, rather than the object itself). N From nik at ngo.org.uk Thu Oct 5 13:04:12 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Thu, 05 Oct 2006 21:04:12 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <4524C0E5.6090608@ngo.org.uk> References: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> <4524C0E5.6090608@ngo.org.uk> Message-ID: <4525653C.9090301@ngo.org.uk> Nik Clayton wrote: > my $lock = $user->get_optimistic_lck(); > > which will result in a friendly(ish) compile time error, rather than an > irritating, hard to track down run-time error. s/compile time error/run time error that immediately points to the cause of the problem/ N From peter at dragonstaff.com Thu Oct 5 13:31:50 2006 From: peter at dragonstaff.com (Peter Edwards) Date: Thu, 5 Oct 2006 21:31:50 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <4525653C.9090301@ngo.org.uk> Message-ID: <008001c6e8bd$51839a40$6c01a8c0@metis> To generate compile time errors in this kind of situation I normally use closures, which will catch typos. sub SOAPOptimisticLock { 'OptimisticLock'; } sub SOAPId { 'Id'; } sub get { my $arg = shift || confess 'expected arg'; my $code = &$arg || confess 'unknown SOAP function: typo in arg '.$arg.'?'; $soapobj->"get_${arg}"; } If there are more than a handful of tokens it's easier to write entries in the symbol table straight from an array using some madness like this #!/usr/bin/perl use strict; use warnings; BEGIN { my @key = qw( FOO BAR BLETCH ); no strict 'refs'; for my $k (@key) { *{__PACKAGE__.'::'.$k} = sub { $k; } } use strict 'refs'; } sub get { "here's your $_[0]"; } print get(FOO), "\n"; Regards, Peter -----Original Message----- From: Nik Clayton [mailto:nik at ngo.org.uk] Sent: 05 October 2006 21:04 To: Nik Clayton Cc: Peter Edwards; miltonkeynes-pm at pm.org Subject: Re: Opinions: API wrapping, how close to original API should you stay? Nik Clayton wrote: > my $lock = $user->get_optimistic_lck(); > > which will result in a friendly(ish) compile time error, rather than an > irritating, hard to track down run-time error. s/compile time error/run time error that immediately points to the cause of the problem/ N From robbie at robbiebow.co.uk Thu Oct 5 14:29:50 2006 From: robbie at robbiebow.co.uk (Robbie Bow) Date: Thu, 05 Oct 2006 22:29:50 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <4524C0E5.6090608@ngo.org.uk> References: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> <4524C0E5.6090608@ngo.org.uk> Message-ID: <4525794E.2090306@robbiebow.co.uk> > Nik Clayton wrote: > [1] As an aside, there's quite a lot of tedious make-work code involved in > doing this. Before I sit down and write one, is anyone aware of a simple > mechanism to take a hash and a mapping of hash keys to method names, and > generate a simple object from the two? How about using Class::Accessor e.g. use base qw(Class::Accessor::Fast); use strict; { my $hash = { foo => 1, bar => 2, }; $_ = "get$_" keys %$hash; my @methods = keys %$hash; __PACKAGE__->mk_ro_accessors(@methods); } sub new { my $class = shift; my %hash = @_; return __PACKAGE__->new(\%hash); } From ian at indecorous.com Thu Oct 5 13:17:53 2006 From: ian at indecorous.com (Ian Malpass) Date: Thu, 05 Oct 2006 15:17:53 -0500 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <4524BF0D.8030406@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> <45242DAC.7020806@indecorous.com> <4524BF0D.8030406@ngo.org.uk> Message-ID: <45256871.4020405@indecorous.com> Nik Clayton wrote: > Ian Malpass wrote: >> Nik Clayton wrote: >> >>> Assuming you were writing to this API, would you prefer to use: >>> >>> $ml->get_optimistic_lock() >>> >>> $ml->get_OptimisticLock() >>> >>> $ml->getOptimisticLock() >>> >>> to retrieve the value, or something else? >> >> Could you support both 1 and 3? Or would that just cause confusion? > > It's easy enough to do. Mm, yes. I suppose my use of "could" was more "given that you can, should you or would you want to" :) > I'm not sure it'll lead to maintainable code in > the future though (in the sense of consumers of this object, rather than > the object itself). You could explicitly separate the interfaces - have a Foo::Bar with a Foo::Bar::CamelCase for those who wanted it. At least then users would have opted for one or the other, rather than mixing the two willy-nilly. Ian From rafiq at dreamthought.com Thu Oct 5 16:18:03 2006 From: rafiq at dreamthought.com (Raf) Date: Fri, 6 Oct 2006 00:18:03 +0100 (BST) Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <45240E3E.5010909@ngo.org.uk> References: <45240E3E.5010909@ngo.org.uk> Message-ID: <20061005234851.K70334@joshua.dreamthought.com> On Wed, 4 Oct 2006, Nik Clayton wrote: > Assuming you were writing to this API, would you prefer to use: > $ml->get_optimistic_lock() > > $ml->get_OptimisticLock() > > $ml->getOptimisticLock() I think that the only thing that matters is that you stick to a consistent and meaningful style. When writing similar wrapper API's, I tend to assume that someone familiar with the underlying/native interface, 'may' have an idea of contract and behaviour 'that this API should be "capable" of exposing.' This, however, shouldn't become a constraint on my style of naming methods. All of the above options - even the unsightly second - succeed in conveying the semantic meaning and do not drift too far from the underlying data. Thus, it's better, imho, to remain consistent with the style of your greater code-base and allow those utilising your API to become familar with its own style ( + its own quirk and documentation ). Just my late night thoughts. Raf From nik at ngo.org.uk Fri Oct 6 08:15:21 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Fri, 06 Oct 2006 16:15:21 +0100 Subject: Opinions: API wrapping, how close to original API should you stay? In-Reply-To: <4525794E.2090306@robbiebow.co.uk> References: <002401c6e7fe$f0b8cc30$6c01a8c0@metis> <4524C0E5.6090608@ngo.org.uk> <4525794E.2090306@robbiebow.co.uk> Message-ID: <45267309.2000006@ngo.org.uk> Robbie Bow wrote: >> Nik Clayton wrote: > >> [1] As an aside, there's quite a lot of tedious make-work code involved in >> doing this. Before I sit down and write one, is anyone aware of a simple >> mechanism to take a hash and a mapping of hash keys to method names, and >> generate a simple object from the two? > > How about using Class::Accessor e.g. Ah, I wasn't clear enough. I meant using Object::InsideOut. Currently my subclasses are created something like this: package main { my %hash = func_that_returns_hash(); # %hash has keys 'Foo', 'Bar', 'Baz' my $obj = Class->new(%hash); }; package Class { use Object::InsideOut; my @foo :Field :Arg(Mandatory => 1, Name => 'Foo') :Get(get_foo); my @bar :Field :Arg(Mandatory => 1, Name => 'Bar') :Get(get_bar); my @baz :Field :Arg(Mandatory => 1, Name => 'Baz') :Get(get_baz); }; That works, but it's a bit tedious. Short of eval'ing everything in to existence iterating over a list of field names there doesn't seem to be handy O::I shortcut. N From tom at eborcom.com Mon Oct 9 14:34:10 2006 From: tom at eborcom.com (Tom Hukins) Date: Mon, 9 Oct 2006 22:34:10 +0100 Subject: Technical Meeting: Tuesday 10th October In-Reply-To: <20061002184332.GA60585@eborcom.com> References: <20061002184332.GA60585@eborcom.com> Message-ID: <20061009213410.GA56141@eborcom.com> Hi all. Just a quick reminder that tomorrow's technical meeting takes place at 7pm at SpiraHellic. Please see the Web site for details: http://miltonkeynes.pm.org/ Let me know if you have any questions: I hope to see lots of you tomorrow. We'll be in the meeting room as we haven't managed to get hold of a projector, although as it's not summer any more it shouldn't get too stuffy. Maybe some heroic volunteer has a projector we could borrow. Tom From r.t.c.norfor at open.ac.uk Wed Oct 11 01:12:36 2006 From: r.t.c.norfor at open.ac.uk (Rod Norfor) Date: Wed, 11 Oct 2006 09:12:36 +0100 (BST) Subject: Technical Meeting: Tuesday 10th October In-Reply-To: <20061009213410.GA56141@eborcom.com> References: <20061002184332.GA60585@eborcom.com> <20061009213410.GA56141@eborcom.com> Message-ID: Thanks to everyone who presented last night, lots of things to digest, and to Tom for organising. Cheers. Rod From nik at ngo.org.uk Sat Oct 14 16:02:39 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Sun, 15 Oct 2006 00:02:39 +0100 Subject: Syntax highlighting in Perl Message-ID: <45316C8F.7080206@ngo.org.uk> Can anyone recommend any modules (or an external tool that's efficient) that can do HTML syntax highlighting -- at least diffs, but ideally source code in various languages, HTML itself, and so on. I've looked at Syntax::Highlight::Engine::Kate, but it looks as though if I want to change the look of the highlighting I need to subclass a bunch of modules, which is effort I'd like to avoid if possible. Syntax::Highlight::Universal looks interesting, but doesn't build on my local FreeBSD box. That doesn't bode well for it being easy to install for people who are going to be using my code that depends on it. It also looks like it introduces a dependency on Java, which is a bit heavier than I really want. Cheers, N From oliver.gorwits at computing-services.oxford.ac.uk Sat Oct 14 17:06:16 2006 From: oliver.gorwits at computing-services.oxford.ac.uk (Oliver Gorwits) Date: Sun, 15 Oct 2006 01:06:16 +0100 Subject: Syntax highlighting in Perl In-Reply-To: <45316C8F.7080206@ngo.org.uk> References: <45316C8F.7080206@ngo.org.uk> Message-ID: <45317B78.3090102@computing-services.oxford.ac.uk> Nik Clayton wrote: > Can anyone recommend any modules (or an external tool that's efficient) that > can do HTML syntax highlighting I use vim's :TOhtml macro thingy, which produces something like this: http://users.ox.ac.uk/~oliver/data/files/vimrc.html More info at `:help 2HTML` in vim. HTH, regards, oliver. -- Oliver Gorwits, Network Infrastructure Group, Oxford University Computing Services From paul at pjcj.net Sun Oct 15 08:00:18 2006 From: paul at pjcj.net (Paul Johnson) Date: Sun, 15 Oct 2006 17:00:18 +0200 Subject: Syntax highlighting in Perl In-Reply-To: <45316C8F.7080206@ngo.org.uk> References: <45316C8F.7080206@ngo.org.uk> Message-ID: <20061015150018.GA18946@pjcj.net> On Sun, Oct 15, 2006 at 12:02:39AM +0100, Nik Clayton wrote: > Can anyone recommend any modules (or an external tool that's efficient) > that can do HTML syntax highlighting -- at least diffs, but ideally source > code in various languages, HTML itself, and so on. Ooh - syntax highlighting in Svn::Web? I was looking at trac just last week thinking how nice that would be in Svn::Web. And now a half-hearted moan. Every since I upgraded apache on debian a few weeks back SVN::Web seems to be displaying only what would have been in the body of the html. And also when any revision is requested the apache process hangs using 100% cpu. Since I can't even be bothered to investigate this enough to make a proper bug report I don't expect an answer, but I suppose there's an off chance that someone might be able to say, "oh yes, that's because of X, just do Y". Yeah, well, maybe. Or if I had spent the time it has taken to write this on investigating the problem I might even have fixed it my now. Dear LazyML, please help. Oh, and by the way, I'm interested in the highlighting solution too for Devel::Cover which has two flavours of Perl highlighting, but nothing for anything else (which currently means C, or anything with embedded Perl or C (such as Mason or XS)). -- Paul Johnson - paul at pjcj.net http://www.pjcj.net From nik at ngo.org.uk Sun Oct 15 10:10:17 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Sun, 15 Oct 2006 18:10:17 +0100 Subject: Syntax highlighting in Perl In-Reply-To: <20061015150018.GA18946@pjcj.net> References: <45316C8F.7080206@ngo.org.uk> <20061015150018.GA18946@pjcj.net> Message-ID: <45326B79.9010308@ngo.org.uk> Paul Johnson wrote: > On Sun, Oct 15, 2006 at 12:02:39AM +0100, Nik Clayton wrote: >> Can anyone recommend any modules (or an external tool that's efficient) >> that can do HTML syntax highlighting -- at least diffs, but ideally source >> code in various languages, HTML itself, and so on. > > Ooh - syntax highlighting in Svn::Web? Yes. The next version of SVN::Web will support browsing remote repositories (i.e., repos that are can be accessed with http:// or svn:// URIs, as well as file:///). One of the things I've done is use the Subversion libraries for diffing, instead of Text::Diff and Text::Diff::HTML. This is *much* faster, but means that I can only display a raw diff. It's relatively easy to take the raw diff and convert it to HTML, but before I go that route I'm looking for a more general solution that can take text in various formats (obviously, one of them being diff) and convert them to marked up HTML. > And now a half-hearted moan. Every since I upgraded apache on debian a > few weeks back SVN::Web seems to be displaying only what would have been > in the body of the html. And also when any revision is requested the > apache process hangs using 100% cpu. > > Since I can't even be bothered to investigate this enough to make a > proper bug report I don't expect an answer, but I suppose there's an off > chance that someone might be able to say, "oh yes, that's because of X, > just do Y". > > Yeah, well, maybe. Or if I had spent the time it has taken to write > this on investigating the problem I might even have fixed it my now. > > Dear LazyML, please help. Apache 1 or Apache 2? What version of SVN::Web? Is it 100% reproducible? Does it affect all revisions, or just a subset of them? Does it happen with svnweb-server? N From abw at wardley.org Mon Oct 16 01:30:01 2006 From: abw at wardley.org (Andy Wardley) Date: Mon, 16 Oct 2006 09:30:01 +0100 Subject: Syntax highlighting in Perl In-Reply-To: <73158E23-A276-4E04-8EAF-40AC9DB00C6A@hexten.net> References: <45316C8F.7080206@ngo.org.uk> <73158E23-A276-4E04-8EAF-40AC9DB00C6A@hexten.net> Message-ID: <45334309.3030407@wardley.org> Andy Armstrong wrote: > What would be really nice would be an implementation of the TextMate > syntax highlighter that handles nested languages gracefully. I TextMate. This is the feature that really sets it apart. > It makes > PHP slightly less unbearable when you're working with a file that > contains HTML, PHP /and/ Javascript and the editor handles them all > correctly. Ditto for TT. I've set mine up to recognise TT directives in HTML, CSS, JS, Apache config files, and the various other document types I often find myself templating. The context-dependent features like syntax highlighting, command completion and so on, make the whole editing process almost bearable. Furthermore, it took less than an hour to go from wondering "How do I add TT support to TextMate?" to releasing the TT bundle. If you know how to write a Perl regex, then you can write a TextMate grammar extension. There's still a few niggling things that it doesn't do as well as Emacs: no async shell commands, sub-optimal reformatting/flowing and a reliance on the mouse for certain operations, to name a few off the top of my head. But it's being actively developed and is improving all the time. Its author, Allan Odgaard, is clearly one smart cookie. Alas, it's not Open Source and it's only available for Macs. But it's worth buying a Mac for. A Just Another TextMate Fan-Boy From tom at eborcom.com Fri Oct 27 10:22:26 2006 From: tom at eborcom.com (Tom Hukins) Date: Fri, 27 Oct 2006 18:22:26 +0100 Subject: Meeting: Tuesday 31st October 2006 Message-ID: <20061027172226.GB45331@eborcom.com> On Tuesday 31st October we will meet again! As usual, we'll meet in Wetherspoon's near the railway station (not the one in the snow dome). I'll show up around 8pm, but feel free to arrive whenever suits you: http://miltonkeynes.openguides.org/?J.D_Wetherspoon%2C_Central_Milton_Keynes If you've not been along before and you would like my mobile number to help find us please ask off list. Everyone's welcome regardless of their knowledge of Perl: the conversation usually covers all sorts of things. It's a special meeting as we held our first ever meeting a year ago, in October 2005. You might have noticed that the Web site is offline: it will come back when I get ADSL in my new house on Monday. Hopefully. See you soon, Tom