[JOB] Yahoo! News (in California)

[Simon Wistow]

Dunno if this is useful 


--- begin job ---


We're looking for a senior developer to contribute to our site including
efforts in RSS feeds, weather integration, advanced categorization and
other future stuff. If you know anyone that would be qualified, please
drop me a note.

   Jeff


+http://jobs.brassring.com/EN/ASP/TG/cim_jobdetail.asp?jobId=138477&type=search&JobReqLang=1
+&recordstart=1


  Descriptive Technical Yahoo - News
  Title
  Job Engineering
  Function
  LocationSunnyvale, CA
  PositionFull-time
  Type
  Job We're looking for an experienced, self-motivated,
  Description enthusiastic software engineer to join the Yahoo! News
  and Weather team. You'll be part of a team that's
  responsible for the world's largest news site, combining
  content from over 80 sources on the web. Tasks include
  feed processing, template generation, database design,
  new feature brainstorming, development, monitoring, and
  troubleshooting. You'll be called on to provide 24x7
  operational support for several very high-traffic
  destinations on Yahoo!

  This position requires a fast learner with a strong
  foundation in software design and building
  fault-tolerant systems. A BSCS/MSCS and at least 5 years
  experience with large scale systems are also required.
  Knowledge of PHP, MySQL, Perl/DBI and security concepts
  is a strong plus. Interest and experience with HTTP,
  XML, Apache, web services and network programming is
  helpful.




--- end job ---


-- 
sometimes i don't know whether to laugh, cry or reboot

Re: [JOB] Yahoo! News (in California)

[Dave Cross]

From: Simon Wistow <[EMAIL PROTECTED]>
Date: 7/8/03 8:48:57 AM

> LocationSunnyvale, CA

So close :)

Dave...
-- 


"Let me see you make decisions, without your television"
   - Depeche Mode (Stripped)

Re: Is dynamic inheritance bad?

[Jon Reades]

Tim Sweetman wrote:
Jon Reades wrote:

You assume that I think DBI is a good model for OO design. ;)
Well it does seem to be kinda useful...
I certainly wouldn't deny the usefulness of the DBI/DBD modules, I was 
expressing the desire that they had been designed slightly differently.

Does mean you can do things like
SESSION_DBI_DATASOURCE=DBI:DBD:informix
or whatever & it works[1] without having to monkey with the CPAN module 
source.


To clarify my pie-in-the-sky example -- what I was thinking was that for 
any given database we have: 1) functions that it has in common with all 
other databases worth the name (examples would presumably include: 
select, update, insert, and delete), and 2) functions that are unique to 
it alone (examples might inludes MySQL's LAST_INSERT_ID() function, or 
Oracle's sequence.nextVal call...).

Any given application might rely on functions from only one of the above 
sets, or it might rely on both simultaneously. However, taking the above 
grouping, in the case of '1' I have what is potentially a 
highly-portable application that doesn't really need to care whether 
it's querying a MySQL db or an Oracle db. In the case of '2' I have an 
application that will need some kind of work in order to function in a 
different environment.

So if I were to give a top-level DB class only the set of methods 
defined by grouping '1' above then I have applications that can *only* 
do that which is permitted by all data sources, and any subclass would 
*have* to implement the core set of methods defined by '1'. However, a 
subclass could also offer db-specific hooks into the set of functions 
defined in '2' but these would be clearly distinct and would be 
'unsupported' by the core DB class.

So if you had a case where:

my $db = DB::MYSQL->new()
and
my $db = DB::ORACLE->new()
both returned a generalised DB object (I'll use this instead of DBI so 
as not to focus on what's available now) then they could be used 
interchangeably but *only* as long as you were using the functions that 
were in common to all databases. If I wanted to access MySQL-specific 
functions then that should be made explicit (through some form of 
casting) in such a way as to throw errors if I try to put an Oracle DB 
object in its place. If I were to need to port the application from 
MySQL to Oracle then the areas needing attention would almost have to be 
clearly denoted within the code.

This sort of thing could even (theoretically at least) permit one to 
have a set of cases permitting db-specific functions with equivalent 
return values to be called depending on the db being used:

use Switch; # if perl >= 5.8.0
switch (ref($db)) {
case 'MYSQL' { ...do something to return a value... }
case 'ORACLE' { ... return an equivalent value... }
else die "Unknown db";
}
Two, er, three things:

1. Interdatabase portability appears to me to be an order for a tall can 
of worms. It's not impossible - especially with something simple, like a 
session database of blobs - but it's often entirely untrivial. (And 
stuff that works v. well/fast on mySQL may bork nastily on Oracle).
Agreed. I hope that my example above shows how I would try to work 
around this issue.

The main problems with DB portability, from what I've seen, aren't the 
methods of the DBD calls, but which features are(n't) supported by the 
SQL-driven bit. Tidying the DBD/DBI interfaces to make them more 
consistent is therefore not gonna achieve much, I think.
This is exactly my point (unless I'm misunderstanding your point :) ) -- 
it's often unclear which methods exist at the DBI level but aren't 
supported at the driver level.

2. Parent classes that determine interfaces etc are a powerful idea, but 
not one that Perl does very well. The real strength of this approach is, 
IMHO, probably in design-by-contract - which, afaik, Java doesn't do 
(Perl does, but only weirdly). I'm gonna do a lightning talk on that, 
but I'm still rubbing the clouds together & it's not ready yet.
Again, I agree, and I suspect that my likely ill-advised suggestions for 
'improving' DBI/DBD couldn't be implemented even if I hadn't overlooked 
something big, which I'm sure to have done...

You appear to be falling into the trap[2] of thinking "OO is what 
Java[3] does". OO styles that work well in strongly-typed languages may 
go decidedly Pete[4] in Perl.
Touche.

There *is* more to OO than Java, however I think that there are several 
attractive features of OO *in* Java that are worth co-opting whenever 
possible since Java *does* offer a certain degree of reliability when 
you are building a complex applciation with many moving pieces, not all 
of which you wrote or which you now need to maintain.

OTOH, the proliferation of classes that do *almost* the same thing in 
Java but have never been refactored or use wildly divergent names are 
certainly amongst the features that I'd be happy to leave behind me.

Cheers, and thank you for the thoughtful response

Re: leytonstone.pm

[Andy Mendelsohn]

On Tuesday, June 24, 2003, at 03:02  pm, I wrote:

So, in recognition of the fact that there are perl programmers who 
live in the swampland east of Stratford, but primarily as an excuse to 
drink beer in the convivial surroundings of 'The Hitchcock' on Whipps 
Cross Road, E11, Paul Makepeace and my own decrepit self will be 
holding the inaugural meeting of leytonstone.pm on July 8th. All 
welcome of course. I'll be there from around 7pm(ish).

Just a brief reminder: tonight from 7pmish, The Sir Alfred Hitchcock 
Hotel, 147 Whipps Cross road, Leytonstone

http://www.multimap.com/map/browse.cgi?pc=E111NP

If I'm alone, I'll be the balding, scruffy one in tee-shirt and jeans, 
clutching a technical book of some sort [1].

andy

[1] It might not be Perl [2]
[2] It might even be 'The book of Zope'!

Re: Neural nets

[Toby Corkindale]

On Mon, Jul 07, 2003 at 03:19:46PM +0100, Andy Wardley wrote:
> Toby Corkindale wrote:
> > I'm not convinced Perl is the best language to implement such things.
> 
> Why not?  Performance concerns or something else?

My experience has been that perl stops performing adequately once you're
trying to do math operations over very large quantities of data.
I'm comparing this to C or C++.

memory usage per-node is much higher, and the time taken to run the math over
the node is quite a bit longer. (this vagueness is qualified a bit below)

One could write the main bits in C anyway and get to it from Perl via XS,
though. But I'd probably just stick to C or C++ all the way in that case.


> That's a serious question by the way, not just me being provocative.
> 
> A cow-orker of mine has just implemented a gesture (as in pen stroke, 
> not "up yours matey" or "swivel on this") recognition net in Ruby and
> it seems to be doing the job most admirably.  Quick to implement, 
> fast enough to run.
> 
> Now I realise Perl isn't Ruby, but they're close enough to be compared
> side-by-side against say, C, C++ or Java.

Well, no, actually. There's a significant difference in runtime between the
same program written in Perl or C. Not really distinguishable to the naked eye
until you start scaling up, though.

if you don't need to run huge neural nets, or many recognitions per second,
then you're probably fine to go for Perl/Ruby/java/etc.
Or if someone else has already written an xs interface to a C NN library, then
bonus! :)

-Toby

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold;
Mere anarchy is loosed upon the world.

xslt & perl functions

[Toby Corkindale]

Hi,
any XML::LibXSLT gurus able to help out here?

I have a XSL template that converts XML to XHTML via the XML::LibXSLT module.
So far, fine.

I want to be able to use special tags in the XML to signal the XSLT processor
to call out to registered perl functions. This works, too, as per the following 
extract:

 xml 

  

-

 xsl 

  this is an insert clause:


-

 perl 
$xslt->register_function("urn:insert", "thing", sub { return ''; });
--

Currently, the  tag will insert the plain-text that I return from 
my perl function.

This all works fine. However, what I *want* to do, is replace the value-of with the 
following:

and then, return a bunch of XML from my perl function, which would be processed
by any appropriate matches in the XSL.

This is the bit that is "just not working". I'm hunting thru the source
currently, but I wondered if anyone else has done this before me, with any
success?


Thanks,
Toby

Notes:
"just not working" being defined as blank output from that xsl clause.
The value-of clause will happily display the raw output though, so the
function does appear to get called and return fine; debug output from the
subroutine is successful too. (ie. warn "i am here\n";)

I have also tried returning XML::LibXML::Document objects instead of
plain-text, and am experimenting with XML::LibXML::NodeList objects as well.


-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold;
Mere anarchy is loosed upon the world.

Re: xslt & perl functions

[Elizabeth Mattijsen]

At 07:39 -0700 7/8/03, Toby Corkindale wrote:
any XML::LibXSLT gurus able to help out here?
Possibly...  ;-)


$xslt->register_function("urn:insert", "thing", sub { return ''; });
This all works fine. However, what I *want* to do, is replace the 
value-of with the following:

and then, return a bunch of XML from my perl function, which would 
be processed
by any appropriate matches in the XSL.
Which version of XML::LibXSLT are you using?  If it's CPAN's version 
1.54, then you'll need to remove a line from LibXSLT.xs.  Or you 
could get the version from CVS where this seems to be fixed (both 
just from empirical evidence, rather than from any logic deduction).


This is the bit that is "just not working". I'm hunting thru the source
currently, but I wondered if anyone else has done this before me, with any
success?
With mixed succes, and with (currently) serious memory leaks.  This 
was recently discussed on the Perl XML list.  Basic problem is that 
Perl destruction of SV's is causing parts of the libxml/libxslt 
allocated memory to be freed when it shouldn't yet.


"just not working" being defined as blank output from that xsl clause.
The value-of clause will happily display the raw output though, so the
function does appear to get called and return fine; debug output from the
subroutine is successful too. (ie. warn "i am here\n";)
Have you checked for core dumps?  What usually happens is that the 
execution of the Perl routine works fine, but when that scope is 
left, things are deallocated in libxml/libxslt that are still 
considered "live".  Any further stuff you do in Perl afterwards, will 
cause a segfault sooner or later.


I have also tried returning XML::LibXML::Document objects instead of
plain-text, and am experimenting with XML::LibXML::NodeList objects as well.
Personally I always return NodeLists objects (from findnodes()), but 
mainly because I checked the handling of that type of return object 
in the .xs code of the 1.54 version.

Something else you might want to try (before going into production, 
as this introduces memory leaks), is to keep references of LibXML:: 
objects that you create inside the perl functions:

my @incref;  (somewhere at the package level)

sub incref { push( @incref,\$_[0] ); $_[0] }

and then, for any LibXML:: object that you create and are about to return:

return incref(  $object );

This fixes it for me for the moment.  We're looking at the cause and 
a solution at the XS level, but unfortunately the .xs code is not 
very well documented and to an extent duplicates/interferes with code 
from LibXML.xs.

Liz

Re: xslt & perl functions

[Toby Corkindale]

On Tue, Jul 08, 2003 at 05:15:11PM +0200, Elizabeth Mattijsen wrote:
> At 07:39 -0700 7/8/03, Toby Corkindale wrote:
> >any XML::LibXSLT gurus able to help out here?
> 
> Possibly...  ;-)

Thanks :)

> >$xslt->register_function("urn:insert", "thing", sub { return ''; });
> >This all works fine. However, what I *want* to do, is replace the 
> >value-of with the following:
> >
> >and then, return a bunch of XML from my perl function, which would 
> >be processed
> >by any appropriate matches in the XSL.
> 
> Which version of XML::LibXSLT are you using?  If it's CPAN's version 
> 1.54, then you'll need to remove a line from LibXSLT.xs.  Or you 
> could get the version from CVS where this seems to be fixed (both 
> just from empirical evidence, rather than from any logic deduction).

That would be the version I'm using.. 
Which line can I try removing?

> >This is the bit that is "just not working". I'm hunting thru the source
> >currently, but I wondered if anyone else has done this before me, with any
> >success?
> 
> With mixed succes, and with (currently) serious memory leaks.  This 
> was recently discussed on the Perl XML list.  Basic problem is that 
> Perl destruction of SV's is causing parts of the libxml/libxslt 
> allocated memory to be freed when it shouldn't yet.

I'll hold off the mod_perl version until that's fixed then.. Seems to have
worked in single-use fine so far for me..

> >I have also tried returning XML::LibXML::Document objects instead of
> >plain-text, and am experimenting with XML::LibXML::NodeList objects as 
> >well.
> 
> Personally I always return NodeLists objects (from findnodes()), but 
> mainly because I checked the handling of that type of return object 
> in the .xs code of the 1.54 version.

My experiments in that direction were like
$raw = '';
$xml = $parser->parse_string($raw);
return $xml->findnodes('/foo');

This had the result that the  dumped a bunch of binary
data instead of processing it.. But perhaps this relates to the one-line
change you mentioned above?

> Something else you might want to try (before going into production, 
> as this introduces memory leaks), is to keep references of LibXML:: 
> objects that you create inside the perl functions:
> 
> my @incref;  (somewhere at the package level)
> 
> sub incref { push( @incref,\$_[0] ); $_[0] }
> 
> 
> and then, for any LibXML:: object that you create and are about to return:
> 
> return incref(  $object );
> 
> 
> This fixes it for me for the moment.  We're looking at the cause and 
> a solution at the XS level, but unfortunately the .xs code is not 
> very well documented and to an extent duplicates/interferes with code 
> from LibXML.xs.

many thanks for the help! I owe you a pint..

tjc

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold;
Mere anarchy is loosed upon the world.

Re: leytonstone.pm

[Alex McLintock]

Hi Andy, Paul,

I may only make it along some time after 9pm. Can someone ring me on 07976 
512145 to give me their phone number?

PS I may bring review books!!!

Alex

At 13:45 08/07/03 +0100, you wrote:
Just a brief reminder: tonight from 7pmish, The Sir Alfred Hitchcock 
Hotel, 147 Whipps Cross road, Leytonstone

http://www.multimap.com/map/browse.cgi?pc=E111NP

If I'm alone, I'll be the balding, scruffy one in tee-shirt and jeans, 
clutching a technical book of some sort [1].

andy

Re: xslt & perl functions

[Elizabeth Mattijsen]

At 08:27 -0700 7/8/03, Toby Corkindale wrote:
On Tue, Jul 08, 2003 at 05:15:11PM +0200, Elizabeth Mattijsen wrote:
 > Which version of XML::LibXSLT are you using?  If it's CPAN's version
 1.54, then you'll need to remove a line from LibXSLT.xs.  Or you
 could get the version from CVS where this seems to be fixed (both
 > just from empirical evidence, rather than from any logic deduction).
That would be the version I'm using..
Which line can I try removing?
Hmmm... I mixed up versions there.  CPAN has 1.53 for XML::LibXSLT, 
XML::LibXML is now at 1.54.

In any case, it seems that the machine I thought the patched version 
of LibXSLT.xs was running, actually doesn't have that patch. So I 
think the incref() kludge is actually enough.


 > With mixed succes, and with (currently) serious memory leaks.  This
 was recently discussed on the Perl XML list.  Basic problem is that
 Perl destruction of SV's is causing parts of the libxml/libxslt
 > allocated memory to be freed when it shouldn't yet.
I'll hold off the mod_perl version until that's fixed then.. Seems to have
worked in single-use fine so far for me..
Actually, if you set PERL_DESTRUCT_LEVEL to -1 in mod_perl, this 
should be ok, as it will not cause segfaults (at least, empirically 
in my situation) when children die.


 > >I have also tried returning XML::LibXML::Document objects instead of
 >plain-text, and am experimenting with XML::LibXML::NodeList objects as
 > >well.
 Personally I always return NodeLists objects (from findnodes()), but
 > mainly because I checked the handling of that type of return object
 > in the .xs code of the 1.54 version.
My experiments in that direction were like
$raw = '';
$xml = $parser->parse_string($raw);
return $xml->findnodes('/foo');
That's exactly what I do, but then:

  return incref( $xml->findnodes( '/foo' ) );




This had the result that the  dumped a bunch of binary
data instead of processing it.. But perhaps this relates to the one-line
change you mentioned above?
Does this still happen after applying the incref() kludge?


many thanks for the help! I owe you a pint..
Would a white wine at the YAPC::EU also be ok?   ;-)

Liz

Re: xslt & perl functions

[muppet]

Elizabeth Mattijsen said:
> With mixed succes, and with (currently) serious memory leaks.  This  was
> recently discussed on the Perl XML list.  Basic problem is that  Perl
> destruction of SV's is causing parts of the libxml/libxslt
> allocated memory to be freed when it shouldn't yet.

i just spent quite a bit of time working on a solution to exactly this problem.

the C object i was wrapping was reference-counted[1], and the perl wrapper
took a reference on the object.  thing is, i needed the perl object to stick
around as long as the C object, and there were cases when the C object could
still be alive in the library without the perl wrapper.  the trick (not
supplied by me, but by marc lehmann, who knows the black art much better than
i do) was to treat the perl object and the C object as a unit, and "trade"
refcounts between them.  this resulted in the slightly bizarre situation that
DESTROY can be called more than once on a perl object if the C object is being
kept alive by other code.  incidentally, a beautiful part of the solution was
keeping the pointer to the C object in magic associated with the perl object,
invisible and thus unbreakable from prying perl fingers.

if your C object isn't refcounted, this may prove difficult for you.

for a non-refcounted structure[2], my solution was to provide a two-layer
wrapper.  the perl object is an SvRV->SvIV->C wrapper structure->actual object
of interest.  the C wrapper structure is a throwaway struct which contains
useful information like the type of the pointed-to-object, and whether or not
the pointed-to-object should be destroyed with the wrapper.


there are lots of other tricks, but they all are specific to how you actually
will wind up using the structures you're wrapping and how those structures
behave.  what i've told you may be useless directly, but the concepts may be
applicable indirectly.


hope that's mildly helpful.

*grin*


[1] GObject:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gtk2-perl/gtk2-perl-xs/Glib/GObject.xs?annotate=1.9

[2] GBoxed:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gtk2-perl/gtk2-perl-xs/Glib/GBoxed.xs?annotate=1.4

-- 
muppet 

Re: xslt & perl functions

[Robin Berjon]

Elizabeth Mattijsen wrote:
In any case, it seems that the machine I thought the patched version of 
LibXSLT.xs was running, actually doesn't have that patch. So I think the 
incref() kludge is actually enough.
Which shows it's 100% a destruction problem.

Actually, if you set PERL_DESTRUCT_LEVEL to -1 in mod_perl, this should 
be ok, as it will not cause segfaults (at least, empirically in my 
situation) when children die.
Have you tried to have a callback at the end of each request cleanup the @incref 
array? Or does that still cause segfaults?

Would a white wine at the YAPC::EU also be ok?   ;-)
I sense there's going to be a lot of those :)

--
Robin Berjon <[EMAIL PROTECTED]>
Research Engineer, Expwayhttp://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Re: xslt & perl functions

[Toby Corkindale]

On Tue, Jul 08, 2003 at 05:39:56PM +0200, Elizabeth Mattijsen wrote:
> At 08:27 -0700 7/8/03, Toby Corkindale wrote:
> >On Tue, Jul 08, 2003 at 05:15:11PM +0200, Elizabeth Mattijsen wrote:
> > > Which version of XML::LibXSLT are you using?  If it's CPAN's version
> >> 1.54, then you'll need to remove a line from LibXSLT.xs.  Or you
> >> could get the version from CVS where this seems to be fixed (both
> > > just from empirical evidence, rather than from any logic deduction).
> >That would be the version I'm using..
> >Which line can I try removing?
> 
> Hmmm... I mixed up versions there.  CPAN has 1.53 for XML::LibXSLT, 
> XML::LibXML is now at 1.54.

That's right; I'm running those versions - XML::LibXSLT is internally labelled
as 1.54 according to the CVS ID tags though, so i figured you meant the
version I had..

> In any case, it seems that the machine I thought the patched version 
> of LibXSLT.xs was running, actually doesn't have that patch. So I 
> think the incref() kludge is actually enough.

> > > >I have also tried returning XML::LibXML::Document objects instead of
> >> >plain-text, and am experimenting with XML::LibXML::NodeList objects as
> > > >well.
> >> Personally I always return NodeLists objects (from findnodes()), but
> > > mainly because I checked the handling of that type of return object
> > > in the .xs code of the 1.54 version.
> >My experiments in that direction were like
> >$raw = '';
> >$xml = $parser->parse_string($raw);
> >return $xml->findnodes('/foo');
> 
> That's exactly what I do, but then:
> 
>   return incref( $xml->findnodes( '/foo' ) );

Disappointingly, it doesn't seem to be enough for me; but I'll go play some
more and see what I can work out.

Further experimentation without the incref() klduge did manage to produce
some segfaults, now. Using the kludge prevents those, so its improved
something.
Unfortunately I'm still getting no output from the apply-templates tag either
way.

> >This had the result that the  dumped a bunch of 
> >binary
> >data instead of processing it.. But perhaps this relates to the one-line
> >change you mentioned above?
> 
> Does this still happen after applying the incref() kludge?

the random binary data has gone away - but nothing has replaced it.

I'll try with the latest cvs of XML::LibXSLT too, in a moment.

> >many thanks for the help! I owe you a pint..
> 
> Would a white wine at the YAPC::EU also be ok?   ;-)

If only I was going...

tjc

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold;
Mere anarchy is loosed upon the world.

Re: leytonstone.pm

[Ian Malpass]

On Tue, 8 Jul 2003, Andy Mendelsohn wrote:

> Just a brief reminder: tonight from 7pmish, The Sir Alfred Hitchcock
> Hotel, 147 Whipps Cross road, Leytonstone

Erk. Forgot about this one. Plus I've just been asked to work some late
shifts for the rest of this week, so tonight is going to be quality home
time I think.

Sorry to bail on you at short notice.

Ian

-
--


The soul would have no rainbows if the eyes held no tears.

Ian Malpass [EMAIL PROTECTED]

Re: xslt & perl functions

[Toby Corkindale]

On Tue, Jul 08, 2003 at 09:09:27AM -0700, Toby Corkindale wrote:
> > >My experiments in that direction were like
> > >$raw = '';
> > >$xml = $parser->parse_string($raw);
> > >return $xml->findnodes('/foo');
> > 
> > That's exactly what I do, but then:
> > 
> >   return incref( $xml->findnodes( '/foo' ) );
> 
> Disappointingly, it doesn't seem to be enough for me; but I'll go play some
> more and see what I can work out.
> 
> Further experimentation without the incref() klduge did manage to produce
> some segfaults, now. Using the kludge prevents those, so its improved
> something.  Unfortunately I'm still getting no output from the
> apply-templates tag either way.

Hmm.
I have updated to the CVS version of XML::LibXSLT (CVS version 1.55 of
LibXSLT.xs)

This has the curious effect of working perfectly if I *don't* use the incref()
kludge.. If I use the kludge, it produces identical behaviour to
1.53-with-kludge. (ie. doesn't segfault, but doesn't produce output for that
tag either)


Probably something to watch out for when you upgrade, Liz.


Thanks to everyone.. now just have to get this project finished before i go
home.. ;)

tjc

Re: xslt & perl functions

[Robin Berjon]

Toby Corkindale wrote:
That's exactly what I do, but then:

 return incref( $xml->findnodes( '/foo' ) );
the random binary data has gone away - but nothing has replaced it.
Are you certain that 1) findnodes is returning something and 2) that your 
stylesheet has a template that matches those? Either of those could produce no 
output.

--
Robin Berjon <[EMAIL PROTECTED]>
Research Engineer, Expwayhttp://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

[ANNOUNCE] Leytonstone.pm++ July 8th 7pm, Hitchcock Arms

[Paul Makepeace]

[for some reason the announce muppets haven't approved this so I'm
belatedly sending it here]

The inaugural meeting of Leytonstone.pm will be tonite, Tuesday July 08
2003 from 19:00 on at the Sir Alfred Hitchcock Hotel on Whipps Cross Rd,
E11.

http://www.streetmap.co.uk/streetmap.dll?grid2map?x=539750&y=188250&isp=187&ism=500&arrow=y?77,144

Zip:  E11 1NJ
Lat:  N51:34:27 / 51.574259
Long: E00:00:50 / 0.013910

It's served very close indeed by the 257 bus e.g. from Walthamstow
Central, Victoria tube terminus; or a brisk hike from Leytonstone
(zone 3/4) or Snaresbrook (zone 4) tube.

See you there! Paul

-- 
Paul Makepeace ... http://paulm.com/

"What is a haircut? It is never enough."
   -- http://paulm.com/toys/surrealism/

Re: [JOB] Yahoo! News (in California)

[Paul Makepeace]

On Tue, Jul 08, 2003 at 09:48:57AM +0100, Simon Wistow wrote:
> Dunno if this is useful 

Not really without an indication of whether they're hiring H1B visa
applicants.

Paul

-- 
Paul Makepeace ... http://paulm.com/

"What is the point? Two cabbages and a giraffe."
   -- http://paulm.com/toys/surrealism/

Re: [JOB] Yahoo! News (in California)

[Simon Wistow]

On Tue, Jul 08, 2003 at 05:30:53PM +0100, Paul Makepeace said:
> Not really without an indication of whether they're hiring H1B visa
> applicants.

They have done in the past and seem to be fairly willing to for other 
jobs recently. 

Re: xslt & perl functions

[Robin Berjon]

Alex McLintock wrote:
At 07:39 08/07/03 -0700, Toby Corkindale wrote:
This all works fine. However, what I *want* to do, is replace the 
value-of with the following:

and then, return a bunch of XML from my perl function, which would be 
processed by any appropriate matches in the XSL.
Is it possible to do this in two stages? A first stage which generates 
some intermediate XML,
and then a second stage which processes the generated XML?
Yeah, but you're really taking all the fun out of it :p

--
Robin Berjon <[EMAIL PROTECTED]>
Research Engineer, Expwayhttp://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Re: xslt & perl functions

[Alex McLintock]

At 07:39 08/07/03 -0700, Toby Corkindale wrote:
Hi,
any XML::LibXSLT gurus able to help out here?
This all works fine. However, what I *want* to do, is replace the value-of 
with the following:

and then, return a bunch of XML from my perl function, which would be 
processed
by any appropriate matches in the XSL.
Is it possible to do this in two stages? A first stage which generates some 
intermediate XML,
and then a second stage which processes the generated XML?

Alex

Re: [JOB] Yahoo! News (in California)

[Paul Makepeace]

On Tue, Jul 08, 2003 at 05:40:05PM +0100, Simon Wistow wrote:
> On Tue, Jul 08, 2003 at 05:30:53PM +0100, Paul Makepeace said:
> > Not really without an indication of whether they're hiring H1B visa
> > applicants.
> 
> They have done in the past and seem to be fairly willing to for other 
> jobs recently. 

Recent past? Any success actually having a H1B granted? By someone
without a PhD? (Serious question - qualifications count.)

This is, frankly, astonishing considering the thousands of critically
unemployed tech people in the Bay Area. By critically I mean as in
having to move back to their folks in Missouri. Also considering the
current administration's interest in hiring furriners is somewhat less
than zero.

Still, encouraging news for those wishing to get over there. My money's
on waiting for Dean or Kucinich to demonstrate viable Democratic
candidacy...

Paul

-- 
Paul Makepeace ... http://paulm.com/

"What is sewing? Three good friends."
   -- http://paulm.com/toys/surrealism/

Re: xslt & perl functions

[Toby Corkindale]

On Tue, Jul 08, 2003 at 06:16:05PM +0200, Robin Berjon wrote:
> Toby Corkindale wrote:
> >>That's exactly what I do, but then:
> >>
> >> return incref( $xml->findnodes( '/foo' ) );
> >
> >the random binary data has gone away - but nothing has replaced it.
> 
> Are you certain that 1) findnodes is returning something and 2) that your 
> stylesheet has a template that matches those? Either of those could produce 
> no output.

1) Yep, had a debug function running which dumped the findnodes output to
   STDERR.
2) XSLT default template is just print the value, which should have caught
   things in some way; (assuming i was trying some generic selects)

Cheers for the suggestions though.
As it happened, the updated LibXSLT module "just worked". (Took me a bit to
locate the anon cvs server though)


ta,

Toby
(everything appears to have come together now - might be home before it gets
dark tonight)


-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold;
Mere anarchy is loosed upon the world.

Re: xslt & perl functions

[Elizabeth Mattijsen]

At 09:22 -0700 7/8/03, Toby Corkindale wrote:
On Tue, Jul 08, 2003 at 09:09:27AM -0700, Toby Corkindale wrote:
 > Further experimentation without the incref() klduge did manage to produce
 some segfaults, now. Using the kludge prevents those, so its improved
 something.  Unfortunately I'm still getting no output from the
 > apply-templates tag either way.
I have updated to the CVS version of XML::LibXSLT (CVS version 1.55 of
LibXSLT.xs)
This has the curious effect of working perfectly if I *don't* use the incref()
kludge.. If I use the kludge, it produces identical behaviour to
1.53-with-kludge. (ie. doesn't segfault, but doesn't produce output for that
tag either)
Hmmm... strange.  If you're running Linux, could you run it through 
valgrind and make sure it's not doing any bad things?


Probably something to watch out for when you upgrade, Liz.
sub incref is easily replaced by a null operation, so I don't worry 
too much about it...


Thanks to everyone.. now just have to get this project finished before i go
home.. ;)
A project is never finished, don't you know that by now?   ;-)

Liz

Re: [JOB] Yahoo! News (in California)

[Mike Jarvis]

On Tue, Jul 08, 2003 at 05:58:44PM +0100, Paul Makepeace wrote:
> Still, encouraging news for those wishing to get over there. My money's
> on waiting for Dean or Kucinich to demonstrate viable Democratic
> candidacy...

Dean is viable, being the frontrunner in the money race right now.  He
stands a good chance of election because even though it's the lefties
that like him right now, his record is much more centrist than most
people acknowledge yet.  The age old strategy is to run left in the
primaries, and center in the general election.

Kucinich is a non-starter.  

I'm still hoping Clark jumps in, but he's still playing coy.  Should
have a real answer form him by September though.

Sorry to inject US politics.  I'll bet Wesley Clark watches Buffy, and
being from Arkansas, there's a good chance he now owns or has sometime
in the past owned a pony.

-- 
mike  

We're all going on a summer holiday

[Earle Martin]

If you're going to YAPC::Europe, don't forget to pack your bucket and spade!

http://news.independent.co.uk/europe/story.jsp?story=422677



-- 
# Earle Martin http://c2.com/cgi/wiki?EarleMartin
$a="f695a9a2176a7dd1618af6649896ee10f05ea986de18af6277e9a1d8ef4696644569a1d".
"8ef46961ae1e64277e9896eea7d92ea8003e9a1d8ef4696f6950";$b="8ALB6AIA4.BA2";$c=
join"",unpack"C*",$b;$c=~s/7/2/g;@b=split"",$c;foreach$d(@b){$e=hex(substr($a
,$f,$d));while(length($e)<8){substr($e,0,0)=0;}print pack"b8",$e;$f+=$d;}

Re: We're all going on a summer holiday

[[EMAIL PROTECTED] lacravate]

Hi ,

En ce jour du Tue, 8 Jul 2003 20:32:44 +0100,
Earle Martin <[EMAIL PROTECTED]> parlait ainsi :
> http://news.independent.co.uk/europe/story.jsp?story=422677
And bodyguard to make some room ... You won't be alone ... :)

-- 
[EMAIL PROTECTED] lacravate
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Assistez à la prochaine conférence Perl en France
23-25 juillet 2003 au CNAM (PARIS)
http://yapc.mongueurs.net

Problem Connecting to IRC?

[James E Keenan]

Has anyone besides me experienced problems connecting to IRC via rhizomatic?
I tried irc.rhizomatic.net and london.rhizomatic.net and got an "unable to
resolve" message?  (I finally managed to connect thru grou.ch.)  Problem
experienced about 8:45 pm US EDT.

Re: Problem Connecting to IRC?

[Jody Belka]

James E Keenan said:
> Has anyone besides me experienced problems connecting to IRC via
> rhizomatic? I tried irc.rhizomatic.net and london.rhizomatic.net and got
> an "unable to resolve" message?  (I finally managed to connect thru
> grou.ch.)  Problem experienced about 8:45 pm US EDT.

see
http://penderel.state51.co.uk/pipermail/london.pm/Week-of-Mon-20030609/019480.html

I have to admit i also can't get i.r.n to work though. I don't have a
problem connecting to l.r.n personally, but that's just because of a nice
hosts entry on the machine i use (drhyde++)


Jody

Re: Problem Connecting to IRC?

[Paul Makepeace]

On Tue, Jul 08, 2003 at 09:02:54PM -0400, James E Keenan wrote:
> Has anyone besides me experienced problems connecting to IRC via rhizomatic?
> I tried irc.rhizomatic.net and london.rhizomatic.net and got an "unable to
> resolve" message?  (I finally managed to connect thru grou.ch.)  Problem
> experienced about 8:45 pm US EDT.

Try,

$ host irc.london.pm.org
irc.london.pm.org   A   195.82.114.48
$

Paul, friendly neighborhood DNS admin

-- 
Paul Makepeace ... http://paulm.com/

"If stars were close, then do "the Dog", not "the Monkey"."
   -- http://paulm.com/toys/surrealism/