From walter at frii.com Mon Sep 11 12:19:07 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us Message-ID: Anyone interested in a hike one night this week? Tuesday? Based on what I'm seeing from http://riemann.usno.navy.mil/aa/data/docs/RS_OneDay.html I'd guess that 7 PM or so would be a good time to start. I'll suggest Mt. Sanitas as a hike, which is pretty nice for this kind of thing. The moon tends to illuminate the trail, and then sitting at the top overlooking the lights of Boulder is not too bad. Work seems far away . . . Walter From jvanslyk at matchlogic.com Mon Sep 11 12:35:52 2000 From: jvanslyk at matchlogic.com (Jason Van Slyke) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us Message-ID: <5FE9B713CCCDD311A03400508B8B30130171E656@bdr-xcln.is.matchlogic.com> Walter, et al; Sorry, my Tuesdays and Thursdays are booked. You could probably twist my arm the other days though. In fact I've been thinking it was about time for a full moon outing. Jason -----Original Message----- From: Walter Pienciak [mailto:walter@frii.com] Sent: Monday, September 11, 2000 11:19 AM To: boulder-pm-list@happyfunball.pm.org Subject: [boulder.pm] the full moon is uppon us Anyone interested in a hike one night this week? Tuesday? Based on what I'm seeing from http://riemann.usno.navy.mil/aa/data/docs/RS_OneDay.html I'd guess that 7 PM or so would be a good time to start. I'll suggest Mt. Sanitas as a hike, which is pretty nice for this kind of thing. The moon tends to illuminate the trail, and then sitting at the top overlooking the lights of Boulder is not too bad. Work seems far away . . . Walter From rise at ipopros.com Mon Sep 11 12:46:22 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: > I'll suggest Mt. Sanitas as a hike, which is pretty nice for > this kind of thing. The moon tends to illuminate the trail, > and then sitting at the top overlooking the lights of Boulder > is not too bad. Work seems far away . . . Sounds good to me. Were you thinking of leaving from the Mapleton trail head? From the BMP map at http://www.ci.boulder.co.us/bmp/maps/map1.htm it looks like there are three choices of starting point. Jonathan Conway Senior DBA ipoPros.com From walter at frii.com Mon Sep 11 15:18:28 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: On Mon, 11 Sep 2000, rise wrote: > > I'll suggest Mt. Sanitas as a hike, which is pretty nice for > > this kind of thing. The moon tends to illuminate the trail, > > and then sitting at the top overlooking the lights of Boulder > > is not too bad. Work seems far away . . . > > Sounds good to me. Were you thinking of leaving from the Mapleton trail > head? From the BMP map at http://www.ci.boulder.co.us/bmp/maps/map1.htm > it looks like there are three choices of starting point. > > > Jonathan Conway > Senior DBA > ipoPros.com Yup, Mapleton trailhead. I was planning on nailing down that kind of detail once we reached consensus on day/destination. Jason says Tuesday is NG. Would it be better or worse if we tried to do this on Wednesday? or will that disqualify others? Walter From rise at ipopros.com Mon Sep 11 16:15:07 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: > Jason says Tuesday is NG. Would it be better or worse if we tried > to do this on Wednesday? or will that disqualify others? Any day Tuesday through Thursday is fine with me. Jonathan Conway Senior DBA ipoPros.com From walter at frii.com Tue Sep 12 08:09:36 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: On Mon, 11 Sep 2000, rise wrote: > > Jason says Tuesday is NG. Would it be better or worse if we tried > > to do this on Wednesday? or will that disqualify others? > > Any day Tuesday through Thursday is fine with me. Okay, then, Let's take a leisurely hike up Mt. Sanitas on Wednesday. We'll meet at 7 PM at the Mapleton Ave. trailhead. The parking on the right (as you come up from Broadway) will probably be full, so a little further up on the left is a larger overflow area. Water, light jacket (could be breezy on top), maybe a flashlight. See you then, Walter From rise at ipopros.com Tue Sep 12 18:41:50 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: > Let's take a leisurely hike up Mt. Sanitas on Wednesday. We'll meet > at 7 PM at the Mapleton Ave. trailhead. The parking on the right > (as you come up from Broadway) will probably be full, so a little > further up on the left is a larger overflow area. Sounds good to me. Since I don't know any boulder-pm members by sight I find myself wondering about identification methods: perl t-shirts, 'aura of JAPH-hood', 'that certain camel smell'?! Somehow I don't think it's likely to be that big a problem though. :) Jonathan Conway Senior DBA ipoPros.com From jvanslyk at matchlogic.com Wed Sep 13 08:17:04 2000 From: jvanslyk at matchlogic.com (Jason Van Slyke) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us Message-ID: <5FE9B713CCCDD311A03400508B8B30130171E689@bdr-xcln.is.matchlogic.com> I'm easy to spot. The fat old man driving a fire engine red Tahoe. But, I crunched my back last night and am a definite maybe for this evening (now that the rest of you have accommodated my schedule of course). Hope to be there. Jason -----Original Message----- From: rise [mailto:rise@ipopros.com] Sent: Tuesday, September 12, 2000 5:42 PM To: boulder-pm-list@happyfunball.pm.org Subject: Re: [boulder.pm] the full moon is uppon us > Let's take a leisurely hike up Mt. Sanitas on Wednesday. We'll meet > at 7 PM at the Mapleton Ave. trailhead. The parking on the right > (as you come up from Broadway) will probably be full, so a little > further up on the left is a larger overflow area. Sounds good to me. Since I don't know any boulder-pm members by sight I find myself wondering about identification methods: perl t-shirts, 'aura of JAPH-hood', 'that certain camel smell'?! Somehow I don't think it's likely to be that big a problem though. :) Jonathan Conway Senior DBA ipoPros.com From walter at frii.com Wed Sep 13 08:45:04 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: On Tue, 12 Sep 2000, rise wrote: > Sounds good to me. > > Since I don't know any boulder-pm members by sight I find myself wondering > about identification methods: perl t-shirts, 'aura of JAPH-hood', 'that > certain camel smell'?! Somehow I don't think it's likely to be that big a > problem though. :) > > Jonathan Conway > Senior DBA > ipoPros.com I'll wear a shirt that has some Perl or camel logo, and I'll be carrying a small purple rucksack. At the trailhead there's a covered concrete area with (I think) a picnic table. I'll be lurking there. Walter From rise at ipopros.com Wed Sep 13 11:47:34 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] the full moon is uppon us In-Reply-To: Message-ID: > I'll wear a shirt that has some Perl or camel logo, and I'll be carrying > a small purple rucksack. At the trailhead there's a covered concrete > area with (I think) a picnic table. I'll be lurking there. I'll be the really long haired guy with a black and grey back pack, most probably accompanied by a female friend who's just joined the dark side (she used to do TCL and Java, so the transition has been... interesting). Jonathan Conway Senior DBA ipoPros.com From walter at frii.com Wed Sep 13 13:32:45 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] directions for tonight Message-ID: Since I typed directions for a person coming down from Fort Collins, I thought I'd spew them onto the list for anyone else to use: Okay, then . . . Down Diagonal (119) all the way to the K Mart at the intersection of Diagonal and Route 36 (28th St.) Bear slightly right (straight west) at the traffic light onto Iris. Take Iris all the way to Broadway (there's a traffic light). Make a left (south). After a mile or so, make right (NO traffic light) onto Mapleton. The streets on the right preceding Mapleton are Balsam, Alpine, North, Portland, Maxwell. Mapleton is a residential street with stop signs. Take your time, enjoy the views of the Flatirons peeking out between the houses on the left. Mapleton houses cost many dollars. The trailhead (and diagonal parking) will be on the right once you're through the residential section, (1/2 to 3/4 mile) and there's a trailhead sign. There's probably going to be no parking spots, so go further up the road to some overflow parking on the left. At the trailhead, there's a covered concrete pad with (I think) a picnic table underneath. I'll be lurking there and wearing a Perl shirt. The top has a *very* nice view, but can be breezy. See you at 7, Walter From walter at frii.com Thu Sep 14 10:06:02 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] problem with HTML::LinkExtor and Message-ID: Hi, I'm using HTML::LinkExtor to extract links from some HTML documents. Works pretty well. But, when it hits an tag looking like which reflects an actual directory structure of ./classes/Bounce.class it's not reporting back one link to ./classes/Bounce.class or even one link to ./classes/Bounce but rather 2 links to ./classes Bounce Any thoughts, ideas? Both HTML::LinkExtor and HTML::Parser are up to date. Walter From rise at ipopros.com Thu Sep 14 14:07:01 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] problem with HTML::LinkExtor and In-Reply-To: Message-ID: > Hi, > > I'm using HTML::LinkExtor to extract links from some HTML documents. > Works pretty well. [...] > but rather 2 links to > > ./classes > Bounce > > > Any thoughts, ideas? Both HTML::LinkExtor and HTML::Parser are up to > date. Having poked around a bit I still have no real idea how to fix it, but it looks to me like the failure mode is that an applet tag isn't a legal URI and thus HTML::Parser isn't parsing it as a link at all. If that's the case then 'fixing' HTML::LinkExtor would probably mean breaking HTML::Parser's standard's conformance. It's hackish, but have you looked at doing a two pass link extraction: one with LinkExtor and another looking for applet tags. Since they're tags (even if they turn out to not be URIs) you can probably pull them out with HTML::Parser itself and reformat them as a link. Jonathan Conway Senior DBA ipoPros.com/TheStreet.com From walter at frii.com Thu Sep 14 15:00:01 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] problem with HTML::LinkExtor and In-Reply-To: Message-ID: On Thu, 14 Sep 2000, rise wrote: > Having poked around a bit I still have no real idea how to fix it, but it > looks to me like the failure mode is that an applet tag isn't a legal URI > and thus HTML::Parser isn't parsing it as a link at all. If that's the > case then 'fixing' HTML::LinkExtor would probably mean breaking > HTML::Parser's standard's conformance. It's hackish, but have you looked > at doing a two pass link extraction: one with LinkExtor and another > looking for applet tags. Since they're tags (even if they turn out to not > be URIs) you can probably pull them out with HTML::Parser itself and > reformat them as a link. Hi, (Jonathan|Jon|John|rise), Ukkk. I *really* want to avoid writing an handler for HTML::Parser. (In fact, I dislike writing handlers for any of the *::Parser stuff: my mind seems to be organized differently than those things. ;^) Anyway, the context of my comments below is that I'm talking myself into a belief that HTML::Parser has a bug. Here's my thinking: I *do* believe that the applet tag's attributes comprise a legal URI. The format is that of a relative URI. The base URI is derivable via the normative algorithm described in RFC1808, section 8 (and also in RFC2396, I think). Granted, the tag has some unique characteristics, but 1808 states It is beyond the scope of this document to specify how, for each media type, the base URL can be embedded. It is assumed that user agents manipulating such media types will be able to obtain the appropriate syntax from that media type's specification. and the HTML spec I checked (4.01, at http://www.w3.org/TR/html4/struct/objects.html#h-13.4) is very specific about the nature of the suspect attributes: codebase This attribute specifies the base URI for the applet. If this attribute is not specified, then it defaults the same base URI as for the current document. Values for this attribute may only refer to subdirectories of the directory containing the current document. code This attribute specifies either the name of the class file that contains the applet's compiled applet subclass or the path to get the class, including the class file itself. It is interpreted with respect to the applet's codebase. One of code or object must be present. So all that spec-quoting means, to me, that there's no reason for HTML::Parser to be mishandling URIs: attribute specs nail them down unambiguously. I like your suggestion about doing two passes (the second pass would need to identify the stuff, re-create the bogus URLs, delete them from the data structures where they'd been added, and then generate and insert the *correct* URLs. I may go that route. I'm just lazy, that's all . . . I may wind up heaving this onto CLPM and seeing what happens. I can't believe I'm the first person to be dealing with this. Walter From rise at ipopros.com Thu Sep 14 16:19:29 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] problem with HTML::LinkExtor and In-Reply-To: Message-ID: > Hi, (Jonathan|Jon|John|rise), s/\|John//i or (after 'use English;') all of the above with John being the only depracated tag (though still legal). > The format is that of a relative URI. Agreed. [URI spec on subject of handling] [HTML spec: $codebase->isa('URI') returns true] The combination of those two pretty much cinches it. > So all that spec-quoting means, to me, that there's no reason for > HTML::Parser to be mishandling URIs: attribute specs nail > them down unambiguously. Agreed. I wonder if someone involved in HTML::Parser failed to check the same assumption I made. > I like your suggestion about doing two passes (the second pass would need to > identify the stuff, re-create the bogus URLs, delete them from the > data structures where they'd been added, and then generate and insert the > *correct* URLs. I may go that route. I'm just lazy, that's all . . . It's certainly not pretty. > I may wind up heaving this onto CLPM and seeing what happens. I can't > believe I'm the first person to be dealing with this. That might be the best move. After reviewing the spec it looks to me like code and codebase are _two_ URIs, the latter of which happens to be used to override the default base URI for the former. HTML::Parser is correctly parsing this as a pair of URIs but HTML::LinkExtor is not then using the codebase to rewrite the code URI with the base. This is most likely because HTML::LinkExtor is registering callbacks for code and codebase separately. If that's the case then it sees the two as two completely different links (which is the behaviour you get). I'm going to poke into the HTML::LinkExtor source to see if I can find a callback. I'm starting to wonder if this is the expected behaviour (though the far more annoying one from your point of view) since you lose a little bit of information when you combine the two URIs. -- Jonathan Conway Remember, it's always darkest when you've Senior DBA decremented to #000000 and you're about to ipoPros.com/TheStreet.com overflow. From Justin.Crawford at cusys.edu Tue Sep 19 11:01:57 2000 From: Justin.Crawford at cusys.edu (Justin Crawford) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Socket troubles Message-ID: I'm trying to understand sockets. I have set up a server & a client and I can establish a connection, but the communication stops after the first server-->client interaction. So on my terminals it looks like this: server> socket_test.pl Server ready. Waiting for connections... I said hello. client> client_socket_test.pl Someone's there! They said: "Hello?" I asked if I was connected At this point the client should send something back to the server, but it doesn't get there. I read that autoflushing is built in when using IO::Socket (which I am, in version 5.003) so I'm assuming that there is something else I'm forgetting to do. But I don't know enough about IO to say for sure that all the flushing that needs doing is being done. Any ideas out there? Thanks a lot. Justin Crawford Oracle Database Administration University Management Systems 303-492-9083 #SERVER-SIDE interaction #... print $sock "Hello?\n"; #to client print "I said hello.\n"; #to STDOUT my $listening = <$sock>; #from client print "He asked me was he connected, just like this:\n"; #to STDOUT print "\"$listening\"\n"; #to STDOUT print $sock "Yes you're connected.\n"; #to client print "I told him he was.\n"; #to STDOUT ---------------------------------------------------- #CLIENT-SIDE interaction: #... my $listening = <$socket>; #from server print "Someone's there! They said:\n"; #to STDOUT print "\"$listening\""; #to STDOUT print $socket "Am I connected?\n"; #to server print "I asked if I was connected\n";#to STDOUT my $waiting = <$socket>; #from server print "He told me I was, just like this:\n"; #to STDOUT print "\"$waiting\""; #to STDOUT $socket->close; From rise at ipopros.com Tue Sep 19 11:48:07 2000 From: rise at ipopros.com (rise) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Socket troubles In-Reply-To: Message-ID: > At this point the client should send something back to the server, but it > doesn't get there. I read that autoflushing is built in when using > IO::Socket (which I am, in version 5.003) so I'm assuming that there is > something else I'm forgetting to do. But I don't know enough about IO to > say for sure that all the flushing that needs doing is being done. Any > ideas out there? I would tend to think that you're right about flushing being a potential source of the problem, but without the socket related source sections of your code I couldn't tell you more (the parts that use the socket are less relevant than those that set them up). I'd suggest if you haven't done so already that you grab your copy of "The Perl Cookbook" and start running through the examples in chapter 17 (Sockets) for places they're doing it differently. Recipe 17.3 - Non-Forking Servers - is likely to be particularly useful since they jump through hoops with select to do non-blocking I/O with a bunch of PF_INET domain sockets (though it should be easy enough to adapt to PF_UNIX domain if that's what you need. -- Jonathan Conway Remember, it's always darkest when you've Senior DBA decremented to #000000 and you're about to ipoPros.com/TheStreet.com overflow. From Casey.Bristow at xor.com Tue Sep 19 11:50:29 2000 From: Casey.Bristow at xor.com (Casey Bristow) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Socket troubles In-Reply-To: Message-ID: the while loop is your friend.. my $sock = 'IO::Socket::INET'->new( LocalHost => 'localhost', LocalPort => 8001, Listen => SOMAXCONN, Proto => 'tcp', Reuse => 1 ) or die "DIE: unable to bind to port 8001"; $sock->autoflush(1); while ( $newsock = $sock->accept() ) { while ( defined( $buffer = <$newsock> ) ) { foreach ($buffer) { print $_; } } } On Tue, 19 Sep 2000, Justin Crawford wrote: > I'm trying to understand sockets. I have set up a server & a client and I > can establish a connection, but the communication stops after the first > server-->client interaction. So on my terminals it looks like this: > > server> socket_test.pl > Server ready. Waiting for connections... > I said hello. > > client> client_socket_test.pl > Someone's there! They said: > "Hello?" > I asked if I was connected > > > At this point the client should send something back to the server, but it > doesn't get there. I read that autoflushing is built in when using > IO::Socket (which I am, in version 5.003) so I'm assuming that there is > something else I'm forgetting to do. But I don't know enough about IO to > say for sure that all the flushing that needs doing is being done. Any > ideas out there? > > Thanks a lot. > > Justin Crawford > Oracle Database Administration > University Management Systems > 303-492-9083 > > > #SERVER-SIDE interaction > #... > print $sock "Hello?\n"; #to client > print "I said hello.\n"; #to STDOUT > > my $listening = <$sock>; #from client > print "He asked me was he connected, just like this:\n"; #to STDOUT > print "\"$listening\"\n"; #to STDOUT > > print $sock "Yes you're connected.\n"; #to client > print "I told him he was.\n"; #to STDOUT > > ---------------------------------------------------- > #CLIENT-SIDE interaction: > #... > > my $listening = <$socket>; #from server > print "Someone's there! They said:\n"; #to STDOUT > print "\"$listening\""; #to STDOUT > > print $socket "Am I connected?\n"; #to server > print "I asked if I was connected\n";#to STDOUT > > my $waiting = <$socket>; #from server > print "He told me I was, just like this:\n"; #to STDOUT > print "\"$waiting\""; #to STDOUT > > $socket->close; > > > > > -- -Casey From Justin.Crawford at cusys.edu Tue Sep 19 14:24:32 2000 From: Justin.Crawford at cusys.edu (Justin Crawford) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Socket troubles Message-ID: Thanks for your responses, all. I guess this wasn't done automagically when I made the socket, but it was all that I needed to do: $sock->autoflush(1); -----Original Message----- From: Casey Bristow [mailto:Casey.Bristow@xor.com] Sent: Tuesday, September 19, 2000 10:50 AM To: 'boulder-pm-list@happyfunball.pm.org' Subject: Re: [boulder.pm] Socket troubles the while loop is your friend.. my $sock = 'IO::Socket::INET'->new( LocalHost => 'localhost', LocalPort => 8001, Listen => SOMAXCONN, Proto => 'tcp', Reuse => 1 ) or die "DIE: unable to bind to port 8001"; $sock->autoflush(1); while ( $newsock = $sock->accept() ) { while ( defined( $buffer = <$newsock> ) ) { foreach ($buffer) { print $_; } } } On Tue, 19 Sep 2000, Justin Crawford wrote: > I'm trying to understand sockets. I have set up a server & a client and I > can establish a connection, but the communication stops after the first > server-->client interaction. So on my terminals it looks like this: > > server> socket_test.pl > Server ready. Waiting for connections... > I said hello. > > client> client_socket_test.pl > Someone's there! They said: > "Hello?" > I asked if I was connected > > > At this point the client should send something back to the server, but it > doesn't get there. I read that autoflushing is built in when using > IO::Socket (which I am, in version 5.003) so I'm assuming that there is > something else I'm forgetting to do. But I don't know enough about IO to > say for sure that all the flushing that needs doing is being done. Any > ideas out there? > > Thanks a lot. > > Justin Crawford > Oracle Database Administration > University Management Systems > 303-492-9083 > > > #SERVER-SIDE interaction > #... > print $sock "Hello?\n"; #to client > print "I said hello.\n"; #to STDOUT > > my $listening = <$sock>; #from client > print "He asked me was he connected, just like this:\n"; #to STDOUT > print "\"$listening\"\n"; #to STDOUT > > print $sock "Yes you're connected.\n"; #to client > print "I told him he was.\n"; #to STDOUT > > ---------------------------------------------------- > #CLIENT-SIDE interaction: > #... > > my $listening = <$socket>; #from server > print "Someone's there! They said:\n"; #to STDOUT > print "\"$listening\""; #to STDOUT > > print $socket "Am I connected?\n"; #to server > print "I asked if I was connected\n";#to STDOUT > > my $waiting = <$socket>; #from server > print "He told me I was, just like this:\n"; #to STDOUT > print "\"$waiting\""; #to STDOUT > > $socket->close; > > > > > -- -Casey From walter at frii.com Thu Sep 21 16:28:17 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Perl review project (fwd) Message-ID: ---------- Forwarded message ---------- Date: 21 Sep 2000 17:11:38 -0400 From: Crissy_Statuto@prenhall.com To: walter@frii.com Subject: Perl review project Dear Walter, Allow me to introduce myself. My name is Crissy Statuto and I am a computer science project manager at Prentice Hall. We are one of the largest college textbook publishers in the US. We are publishing a book entitled "PERL How to Program" by Harvey and Paul Deitel. They are premier programming language authors, with the best-selling C++ and Java books in the college market place. More information on their suite of publications can be found here: http://www.prenhall.com/deitel I am presently seeking qualified technical reviewers to verify that the Deitel's coverage of PERL in their forthcoming book is accurate. Because we are hoping to have this book published by the end of the year we are operating on a very tight schedule. As such, we would ask you to return each chapter within 3 days of receiving it. In return, we are offering a token honorarium of $75 per chapter. Might you be willing to participate? Could you suggest a colleague that may have an interest? If you have any questions, please do not hesitate to contact me. Thank you in advance for your assistance and consideration. Sincerely, Crissy Statuto Crissy Statuto Project Manager, Computer Science Prentice Hall One Lake Street- #3F54 Upper Saddle River, NJ 07458 Tel: 201-236-6695 Fax: 201-236-7170 Email: crissy_statuto@prenhall.com From walter at frii.com Thu Sep 21 17:35:59 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] Sr. Perl Monger Needed (fwd) Message-ID: ---------- Forwarded message ---------- Date: Thu, 21 Sep 2000 14:42:05 -0700 From: chrish@ravenit.com To: walter@frii.com Subject: Sr. Perl Monger Needed Walter, We need a serious Perl lover out here. Could you help us out? Thank you for your time......Chris Raven Communications, Inc. 2 Saint George Alley, 2nd Floor San Francisco, Ca. 94108 Phone: 415-837-3200 Fax: 415-837-3204 Email: chrish@ravenit.com Hi, this is Chris Herrington with Raven Communications. We are currently recruiting for a Sr. Perl Programmer to work on a Full Time basis in Hayward . Please take a moment to review the job description below. As well as send us an up to date version of your resume in an Office 97 format, or an ASCII text format. Please include your salary requirements ( Hourly/Annual salary ), along with any geographical preferences, if you are interested. If you have the relevant experience and are interested, please let us know ASAP. Job Description Form for Raven.0312 1: Title: Sr. Perl Developer 2: Start Date: Immediate. 3: Location: Hayward, CA. 4: How many people are needed: 1 Person. 5: Contract or Full Time: Full Time. 6: Approved Budget in U.S Dollars, for each Individual needed: $100K Base and up Who You Are: We are looking for Mr/Ms PERL: a programmer who writes PERL in their sleep, dreams algorithms and wakes to the sound of keyboard strokes. In addition these other useful accomplishments should resound - a medley of JavaScript, UNIX Shell, and Oracle. 7 hardcore years at programming, 4 in PERL, understands CGI.pm and PERL5, writes DBI and or DBM for Oracle, SQL databases. Loves to learn, interests in XML, and Java, works well with geeks who are scientists and geeks who shoot nerf guns. That should do it Company Information: Our client is pioneering the construction of a Web-based infrastructure to network a global community. Under the direction of an experienced and successful management team, we have captured early leadership of a multi-billion dollar market. Our board and technical advisors form an assembly of industry leaders. As a result, we have attracted funding from notable venture capitalists and private investors. The Dynamics: Today, our market represents a $50 billion potential world-wide market. By 2004, it could be over $125 billion*. Our dedication to growth, wise investments and diligence keep us in position to lead our market into the next generation of global communication and commerce. Our Web-based applications provide the most complete Internet-enabling solutions available anywhere, at minimal cost - if there is any. Top-tier Venture Capital Funding: Sequoia Capital Comdisco Inc. Thank you, Chris Herrington Technical Recruiter Raven Communications, Inc Main: 415-837-3200 ext. 4201 Fax: 415-837-3204 email : chrish@ravenit.com From walter at frii.com Wed Sep 27 10:17:59 2000 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:24 2004 Subject: [boulder.pm] problem with HTML::LinkExtor and In-Reply-To: Message-ID: On Thu, 14 Sep 2000, rise wrote: > > Hi, (Jonathan|Jon|John|rise), > > s/\|John//i or (after 'use English;') all of the above with John being the > only depracated tag (though still legal). > > > The format is that of a relative URI. > > Agreed. > > [URI spec on subject of handling] > [HTML spec: $codebase->isa('URI') returns true] > > The combination of those two pretty much cinches it. > > > So all that spec-quoting means, to me, that there's no reason for > > HTML::Parser to be mishandling URIs: attribute specs nail > > them down unambiguously. > > Agreed. I wonder if someone involved in HTML::Parser failed to check the > same assumption I made. > > > I like your suggestion about doing two passes (the second pass would need to > > identify the stuff, re-create the bogus URLs, delete them from the > > data structures where they'd been added, and then generate and insert the > > *correct* URLs. I may go that route. I'm just lazy, that's all . . . > > It's certainly not pretty. > > > I may wind up heaving this onto CLPM and seeing what happens. I can't > > believe I'm the first person to be dealing with this. > > That might be the best move. After reviewing the spec it looks to me like > code and codebase are _two_ URIs, the latter of which happens to be used > to override the default base URI for the former. HTML::Parser is correctly > parsing this as a pair of URIs but HTML::LinkExtor is not then using the > codebase to rewrite the code URI with the base. This is most likely > because HTML::LinkExtor is registering callbacks for code and codebase > separately. If that's the case then it sees the two as two completely > different links (which is the behaviour you get). > > I'm going to poke into the HTML::LinkExtor source to see if I can find a > callback. I'm starting to wonder if this is the expected behaviour (though > the far more annoying one from your point of view) since you lose a little > bit of information when you combine the two URIs. Just a followup (and context NOT snipped, for the benefit of those who joined the list in the last week or so): I did heave the problem onto CLPM, and I got a response from Gisle basically saying yup and that a patch would be welcome. I sent him a patch 21 Sept. I don't really want to release it generally, in case he has some changes, but would forward it on an "absolutely no warranty expressed or implied -- it could be a BOMB! and not a patch" basis to individuals via e-mail. Walter