> I am not sure where to post this HTML::Parser related question but > this list seems to be close and Gisle is frequent here (and the Perl > Monks did not give me a solution) so I hope you'll forgive me:
No reason to forgive :-) This list is the recommended place to raise issued with the HTML-Parser dist as well.
> Using HTML:Parser it is unclear to me how am I supposed to notice when > a tag - that's end tag is missing has indeed ended? It seems that in > some cases I get an explicit end event but in other cases I don't.
The general rule is that HTML::Parser give you back a stream of tags that correspond exactly to the text of the parsed document. If you want implicit tags to be intuited you have to use modules like those found in the HTML-Tree dist.
But there are seven tags that HTML::Parser treat specially; <script>, <style>, <xmp>, <iframe>, <plaintext>, <title> and <textarea>. After one of these start tags have been seen no other tag is recognized until the corresponding end tag is seen.
What you experienced with <title> is the heuristics HTML::Parser uses to recover when it did not find any "</title>" before it hit the end of the document. In this case it inserts a fake </title> just before the first tag found after <title>. The rules for recovery differs between the special tags. For <script> and <style> an empty element is preferred. For <plaintext>, <xmp>, <iframe>, <textarea> all the rest of the document is considered text.
Hope this helps!
Regards, Gisle
> > See the example code: > > use strict; > use warnings; > > use HTML::Parser (); > > sub event_handler { > my ($event, $elem) = @_; > print "$event $elem\n"; > } > > > my $p = HTML::Parser->new(api_version => 3); > $p->handler( start => \&event_handler, "event, tagname"); > $p->handler( end => \&event_handler, "event, tagname"); > $p->parse('<head><title>abc</title></head>'); > $p->eof; > print "----\n"; > $p->parse('<head><title>abc</head>'); > $p->eof; > > print "----\n"; > $p->parse('<ul><li>abc</li><li>def</ul>'); > $p->eof; > exit; > > The result of which is > > start head > start title > end title > end head > ---- > start head > start title > end title > end head > ---- > start ul > start li > end li > start li > end ul > > That is, the missing </title> tag explicitly generated and end-even > while the missing </li> did not. > > > regards > Gabor
> I'm not convinced this is the right thing to do. How did the $path > string end up utf8::upgraded() in the first place here?
The URL was extracted from a page encoded in UTF-8. The first thing I do when reading a page is to decode it, regardless of the encoding. So it almost always ends up with the UTF8 flag on.
> > --Gisle > > On Sun, Aug 15, 2010 at 23:14, Father Chrysostomos <sprout@cpan.org> wrote: >> Perl’s -e ignores the internal UTF8 flag. (See <http://rt.perl.org/rt3/Ticket/Display.html?id=77242>.) >> >> LWP::Protocol::file triggers this bug in this piece of code: >> >> # test file exists and is readable >> unless (-e $path) { >> return new HTTP::Response &HTTP::Status::RC_NOT_FOUND, >> "File `$path' does not exist"; >> } >> >> If you add >> $path =~ /[^\0-\xff]/ or utf8::downgrade($path); # work around perl bug #77242 >> before the ‘unless’ statement, it works. >> >>
I am not sure where to post this HTML::Parser related question but this list seems to be close and Gisle is frequent here (and the Perl Monks did not give me a solution) so I hope you'll forgive me:
Using HTML:Parser it is unclear to me how am I supposed to notice when a tag - that's end tag is missing has indeed ended? It seems that in some cases I get an explicit end event but in other cases I don't.
See the example code:
use strict; use warnings;
use HTML::Parser ();
sub event_handler { my ($event, $elem) = @_; print "$event $elem\n"; }
> On 22/08/10 14:04, Gisle Aas wrote: >> >> There is no way to prevent redirects from being followed with >> lwp-request. I'm usually happy just using lwp-dump for cases like >> this. > I don't want to prevent the redirect from being followed, I want to see the contents of the redirect's header.
That's exactly what 'lwp-dump' gives you; but it sends a "GET" request instead of "HEAD". lwp-dump limits the amount of content it prints and make sure to escape stuff so it does not mess up your terminal.
I'm not convinced this is the right thing to do. How did the $path string end up utf8::upgraded() in the first place here?
--Gisle
On Sun, Aug 15, 2010 at 23:14, Father Chrysostomos <sprout@cpan.org> wrote: > Perl’s -e ignores the internal UTF8 flag. (See <http://rt.perl.org/rt3/Ticket/Display.html?id=77242>.) > > LWP::Protocol::file triggers this bug in this piece of code: > > # test file exists and is readable > unless (-e $path) { > return new HTTP::Response &HTTP::Status::RC_NOT_FOUND, > "File `$path' does not exist"; > } > > If you add > $path =~ /[^\0-\xff]/ or utf8::downgrade($path); # work around perl bug #77242 > before the ‘unless’ statement, it works. > >
On 22/08/10 14:04, Gisle Aas wrote: > On Mon, Aug 16, 2010 at 10:35, Nigel Horne<njh@bandsman.co.uk> wrote: >> How do I get the HEAD of the redirect message using the HEAD(1p) command? >> >> For example: >> >> HEAD http://www.ccdb.org.au/ >> >> gives you the header of the site you've redirected to, >> >> HEAD -S http://www.ccdb.org.au/ >> >> says: >> >> HEAD http://www.ccdb.org.au/ --> 302 Moved Temporarily >> HEAD http://www.ccdb.org.au/xzt25b9/ --> 200 OK >> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, >> pre-check=0 >> Connection: close >> ... >> >> Which doesn't help me, because the command hasn't actually printed the >> contents of the first header :-( > There is no way to prevent redirects from being followed with > lwp-request. I'm usually happy just using lwp-dump for cases like > this. I don't want to prevent the redirect from being followed, I want to see the contents of the redirect's header. > $ lwp-dump http://www.ccdb.org.au/ > HTTP/1.1 302 Found > Connection: Keep-Alive > Date: Sun, 22 Aug 2010 12:57:12 GMT > Location: http://www.ccdb.org.au/xzt25b9/ > Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8e-fips-rhel5 > mod_bwlimited/1.4 > Content-Length: 353 > Content-Type: text/html; charset=iso-8859-1 > Keep-Alive: timeout=5, max=100 > [...] > > If it's important that the method is 'HEAD' you can use something like: > > perl -MLWP -le 'LWP::UserAgent->new(max_redirect=>0)->head(shift)->dump' > http://www.ccdb.org.au/ I'll give that a go. Thanks
On Mon, Aug 16, 2010 at 10:35, Nigel Horne <njh@bandsman.co.uk> wrote: > How do I get the HEAD of the redirect message using the HEAD(1p) command? > > For example: > > HEAD http://www.ccdb.org.au/ > > gives you the header of the site you've redirected to, > > HEAD -S http://www.ccdb.org.au/ > > says: > > HEAD http://www.ccdb.org.au/ --> 302 Moved Temporarily > HEAD http://www.ccdb.org.au/xzt25b9/ --> 200 OK > Cache-Control: no-store, no-cache, must-revalidate, post-check=0, > pre-check=0 > Connection: close > ... > > Which doesn't help me, because the command hasn't actually printed the > contents of the first header :-(
There is no way to prevent redirects from being followed with lwp-request. I'm usually happy just using lwp-dump for cases like this.
On Sun, Aug 15, 2010 at 22:40, Father Chrysostomos <sprout@cpan.org> wrote: > URI::file has this little line in it: > > sub path { shift->path_query(@_) } > > which makes it impossible to test web pages offline (via file: rather than http:). All web browsers I’ve used allow a query string to be added to a file URL, and require %3f to be used for files with question marks in their names. The query string is not entirely useless. It allows information to be passed to scripts embedded in the page. > > Is there any chance this line could be removed?
This seems reasonable. <http://github.com/gisle/uri/commit/d68f48165a1abe746fab5f2844acb23dcef17857>
How do I get the HEAD of the redirect message using the HEAD(1p) command?
For example:
HEAD http://www.ccdb.org.au/
gives you the header of the site you've redirected to,
HEAD -S http://www.ccdb.org.au/
says:
HEAD http://www.ccdb.org.au/ --> 302 Moved Temporarily HEAD http://www.ccdb.org.au/xzt25b9/ --> 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close ...
Which doesn't help me, because the command hasn't actually printed the contents of the first header :-(
which makes it impossible to test web pages offline (via file: rather than http:). All web browsers I’ve used allow a query string to be added to a file URL, and require %3f to be used for files with question marks in their names. The query string is not entirely useless. It allows information to be passed to scripts embedded in the page.
> The sample code at > http://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates, > using an actual apache web server, works fine, so I guess the problem > probably comes from my testing setup.
Sorry to toot the same horn without providing a solution, but can someone on this list give an authoritative answer to the more generic question of how to make sure LWP::UserAgent verifies the server's SSL cert?
The posts at the stackoverflow link above seem to indicate that it might not work, depending on which SSL module is installed (Crypt::, Net::, what-have-you)?
Can someone post package requirements & code to guarantee that the script performs all the SSL checks a browser runs (host name check, root cert check, etc.), given that libwww version X and SSL module Y are installed, regardless of what else is installed on the machine?
Dear Sirs: A how to question: I am trying to access certificates on my Mac laptop using lwp::useragent, openssl, crypt::ssleay in perl. I have populated the $ENV variables to define where the files are located on my machine.
How do I use the Crypt::SSLeay::CTX, Conn, and X509 methods to access these files, and extract the different parts of a certificate?
Right now I am just trying to write a prototype perl program so that can I understand how the methods work and then use them in the near future in a larger application.
Let me know if I need to give you any other info.
Thanks for your timely reply to my questions.
Bob Gonnella BAE Systems Software Engineer Office: 301-669-3224
Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: 22667 The optree builder was looping when constructing the ops ... 22715 Upgrade to FileCache 1.04 22733 Missing copyright in the README. 22746 fix a coredump caused by rv2gv not fully converting a PV ... 22755 Fix 29149 - another UTF8 cache bug hit by substr. 22774 [perl #28938] split could leave an array without ... 22775 [perl #29127] scalar delete of empty slice returned garbage 22776 [perl #28986] perl -e "open m" crashes Perl 22777 add test for change #22776 ("open m" crashes Perl) 22778 add test for change #22746 ([perl #29102] Crash on assign ... 22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ... 22796 [perl #29346] Double warning for int(undef) and abs(undef) ... 22818 BOM-marked and (BOMless) UTF-16 scripts not working 22823 [perl #29581] glob() misses a lot of matches 22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu) 22830 [perl #29637] Thread creation time is hypersensitive 22831 improve hashing algorithm for ptr tables in perl_clone: ... 22839 [perl #29790] Optimization busted: '@a = "b", sort @a' ... 22850 [PATCH] 'perl -v' fails if local_patches contains code snippets 22852 TEST needs to ignore SCM files 22886 Pod::Find should ignore SCM files and dirs 22888 Remove redundant %SIG assignments from FileCache 23006 [perl #30509] use encoding and "eq" cause memory leak 23074 Segfault using HTML::Entities 23106 Numeric comparison operators mustn't compare addresses of ... 23320 [perl #30066] Memory leak in nested shared data structures ... 23321 [perl #31459] Bug in read() 27722 perlio.c breaks on Solaris/gcc when > 256 FDs are available SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 6663288 Upgrade to CGI.pm 3.33 REGEXP0 - fix for UTF-8 recoding in regexps - CVE-2007-5116 6758953 Perl Sys::Syslog can log messages with wrong severity Built under solaris Compiled at May 21 2009 03:59:02 @INC: /usr/perl5/5.8.4/lib/sun4-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/sun4-solaris-64int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl .
I noticed the "scheme" regular expression in LWP::UserAgent used to match the authentication scheme sent in a WWW-Authenticate header does not match the RFC's list of allowed characters for this field.
RFC2617 uses the type "token" from RFC2616, which includes several characters not present in the "scheme" regular expression on line 344 of UserAgent.pm. I believe this regular expression should be expanded to allow the missing characters (which is quite a large list, but namely missing "." and "_").
It's only a one-line change, so I'm not sure if you'd prefer I submit a patch or just report the issue directly.
1 - we have a homegrown URL encoding routine. I am certain there must be something more standard in the LWP distro and would appreciate a pointer to it:
foreach my $field ( keys %$data ) { next if ( $data->{$field} eq '' );
2 - the _Post() routine below works fine when the post is made via the root user. But it fails when run as a different user. I would appreciate any pointers on debugging this problem.
sub _Post { my $self = shift; # Class reference my $data = shift;
# Path to local client cert and key $ENV{HTTPS_CERT_FILE} = APID_CERT_PATH . $self->_GetCertificate; $ENV{HTTPS_KEY_FILE} = APID_CERT_PATH . $self->_GetKey;
# Path to certificate authority file, for comparing the server's certificate. $ENV{HTTPS_CA_FILE} = APID_CERT_PATH . APID_CA_FILE;
if ( ( !defined($data) ) ) { return (undef); }
my $ua = LWP::UserAgent->new();
my $port = APID_POST_PORT;
my $req = HTTP::Request->new( POST => "https://" . $self->_GetUrl . ":$port" . $self->_GetPage );
# Remove the Environment Variables, holding cert files. Was causing problems with SOAP, when # these happened to still be there, using the wrong cert and SOAP bombing out after a DIY call.
On Tuesday 29 Jun 2010 17:00:47 Hauff, Chad wrote: > > My company is using Perl 5.8.8 on a Red Hat Enterprise Linux 5 > distribution. > We have several development and QA servers running version 0.51-11.el5 > via yum and Red Hat's distribution. > My company's Operations group then created a new server and installed > Crypt::SSleay via CPAN, which installed version 0.57. > My company's Operations group found that Red Hat provides version 0.51 > of the module via yum. > Because Red Hat provides support for our servers, the Operations group > installed the module via yum, and then removed the SSLeay.pm file from > the CPAN distribution. > So at first, 0.57 resided in > ..../site_perl/5.8.8/i386-linux-thread-multi/Crypt/ > After the yum install, 0.51 lived at: > ..../vendor_perl/5.8.8/i386-linux-thread-multi/Crypt/ > Operations then tried to 'uninstall' the 0.57 version of the module by > removing ..../site_perl/5.8.8/i386-linux-thread-multi/Crypt/ > But Perl applications that try to use the module get this error: > Crypt::SSLeay object version 0.57 does not match bootstrap parameter > 0.51 at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line > 253. > Compilation failed in require at .... > The Operations group will not budge on going outside of a Red Hat > 'blessed' module, so we're stuck trying to remove the 0.57 version. > > Any guidance on how to remove 0.57 completely?
Attempts to remove .57 may foul the .51 install. You should uninstall .51 before removing. Your first best bet is to see whether the .57 package has a "uninstall" instruction for make. And then hope it actually works. If not, you can determine what was probably installed by inspecting the build directory and removing from the Perl install directories everything you find. After that, you can re-in stall 0.51.
On Tuesday 29 Jun 2010 17:00:47 Hauff, Chad wrote: > Dear Support: > > > > My company is using Perl 5.8.8 on a Red Hat Enterprise Linux 5 > distribution. > > > > We have several development and QA servers running version 0.51-11.el5 > via yum and Red Hat's distribution. > > > > My company's Operations group then created a new server and installed > Crypt::SSleay via CPAN, which installed version 0.57. > > > > My company's Operations group found that Red Hat provides version 0.51 > of the module via yum. > > Because Red Hat provides support for our servers, the Operations group > installed the module via yum, and then removed the SSLeay.pm file from > the CPAN distribution. > > > > So at first, 0.57 resided in > > ..../site_perl/5.8.8/i386-linux-thread-multi/Crypt/ > > > > After the yum install, 0.51 lived at: > > ..../vendor_perl/5.8.8/i386-linux-thread-multi/Crypt/ > > > > Operations then tried to 'uninstall' the 0.57 version of the module by > removing ..../site_perl/5.8.8/i386-linux-thread-multi/Crypt/ > > > > But Perl applications that try to use the module get this error: > > Crypt::SSLeay object version 0.57 does not match bootstrap parameter > 0.51 at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line > 253. > > Compilation failed in require at .... > > > > The Operations group will not budge on going outside of a Red Hat > 'blessed' module, so we're stuck trying to remove the 0.57 version. > > > > Any guidance on how to remove 0.57 completely? >
Try using 'strace -e open' on the perl script to see where it tries to read from and remove those files that don't belong to the Red Hat blessed package.
Regards,
Shlomi Fish
-- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/
God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
My company is using Perl 5.8.8 on a Red Hat Enterprise Linux 5 distribution.
We have several development and QA servers running version 0.51-11.el5 via yum and Red Hat's distribution.
My company's Operations group then created a new server and installed Crypt::SSleay via CPAN, which installed version 0.57.
My company's Operations group found that Red Hat provides version 0.51 of the module via yum.
Because Red Hat provides support for our servers, the Operations group installed the module via yum, and then removed the SSLeay.pm file from the CPAN distribution.
The difference in the two sites behavior turns out to be the "discard" field used by the www.magna.isa.gov.il site. Adding the (...ignore_discard => 1) to the constructor's hash forced a save to the file.
Indeed, your CPAN documentation of HTTP::Cookies includes the following:
$cookie_jar->save( $file )
This method file saves the state of the $cookie_jar to a file. The state can then be restored later using the load() method. If a filename is not specified we will use the name specified during construction. If the attribute ignore_discard is set, then we will even save cookies that are marked to be discarded.
The last sentence alludes to the "discard" field's role in the package. (And there are a few more hints in passing.) But IMHO, this issue of "discard" and no-expired-field merits a more direct treatment. This can be right in the "Description" section or at least under a "NOTES" heading.
On Jun 22, 9:28 am, sandeep.x.ran...@jpmchase.com (Sandeep X Ranjan) wrote: > Hi, > > I need help desperately. I have a perl client program making calls to a web service via SOAP over https. I do have the certificate installed on the UNIX box from where I will be making the calls. But I don't know how to use that certificate in my perl script. >
I haven't used SOAP::Lite for a long time but this isn't too hard as I recall.
You'll need to install Crypt::SSLeay (or IO::Socket::SSL) as well.. See Crypt::SSLeay docs for environment client certificate settings that you'll need.
Something happened between libwww-perl-5.834 and libwww-perl-5.835 that broke this module for my env on solaris.
base/message..............ok 124/125# Test 125 got: <UNDEF> (base/message.t at line 508)
# Expected: '<?xml version="1.0"?>
<root>?ric</root>
'
base/message..............NOK 125# base/message.t line 508 is: ok($m->decoded_content, "<?xml version=\"1.0\"?>\n<root>\xC9ric</root>\n");
base/message..............FAILED test 125
Failed 1/125 tests, 99.20% okay
Per a suggestion at http://www.justskins.com/forums/libwww-perl-5-803-failures-62519.html I Change the
$m->decoded_content
calls to
$m->decoded_content(raise_error => 1); in ./t/base/message.t
I got this:
Unknown encoding 'utf-16-le' at ../blib/lib/HTTP/Message.pm line 378
...propagated at ../blib/lib/HTTP/Message.pm line 393.
I tried a couple different versions of libiconv because I've been wrestling with it with another issue but that does not seem to fix anything... So... for now, I've just changed my build script to use
I need help desperately. I have a perl client program making calls to a web service via SOAP over https. I do have the certificate installed on the UNIX box from where I will be making the calls. But I don't know how to use that certificate in my perl script.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
hai people, i have been trying to understand the http::responce when i got a file to download .. i know it will download in a single stream.... i need to find to know that weather it can be done in multiple ways in perl to download the file ..... i know curl ,aria2 and others have that capability i need to know in perl ... thank you Perl@work
Sorry for not following the issue sooner. I was on vacation for the last couple of weeks.
As I said in my previous and immediate reply, your script, as is, DID generate entries in the "cookie jar" file.
However, just changing the site's address to "http://www.magna.isa.gov.il", without changing anything else, not even a single character, generates the old symptom - no entries in the cookie-jar file and thus no sending of a cookie on any of the subsequent "GET" requests.
(BTW, The Firefox browser does handle right cookies with this internet site.)
What's wrong with this site?
Regards Meir
-----Original Message----- From: Meir Guttman [mailto:meir@guttman.co.il] Sent: Sunday, May 23, 2010 10:29 PM To: 'Gisle Aas' Subject: RE: Cookies not saved to a file (thus no sent)
Hello Gisle!
Thanks for your prompt help.
Yes, it does work for me too! So tomorrow I'll try to copy your example to my situation.
Thanks! Meir Ashdod, Israel
BTW, my understanding is that you are from Norway, isn't it? Last year we took a nature cruse through the Svalbard islands. It is one of my top ten, no less. And I was in many places all over the world, so believe me, I can compare. Please keep it unspoiled for the rest of us...
M.G.
-----Original Message----- From: gisle.aas@gmail.com [mailto:gisle.aas@gmail.com] On Behalf Of Gisle Aas Sent: Sunday, May 23, 2010 9:55 PM To: Meir Guttman Subject: Re: Cookies not saved to a file (thus no sent)
The following example:
use LWP::UserAgent; use HTTP::Cookies; my $jar = HTTP::Cookies->new(file => "lwp.jar", autosave => 1); my $ua = LWP::UserAgent->new(cookie_jar => $jar); $ua->get("http://www.google.com")->dump;
fills the 'lwp.jar' file with a few entries for me. Doesn't it do so for you too?
--Gisle
On Sun, May 23, 2010 at 18:54, Meir Guttman <meir@guttman.co.il> wrote: > Dear LWP wizads! > > > > I began my usage of cookies support in LWP (libwww-perl ver. 5.836) under > Perl, (v5.10.1 for MSWin32-x86-multi-thread) as follows without the > commented-out code: > > > > > use LWP::UserAgent; > > use HTTP::Cookies; > > > > ... > > > > my $browser = LWP::UserAgent->new(); > > > > my $cookies_file = 'LWP_Cookies.lwp'; > > my $cookie_jar = HTTP::Cookies->new({file => $cookies_file, autosave => > 1}); > > # $cookie_jar->load($cookies_file); > > $browser->cookie_jar($cookie_jar); > > # $cookie_jar->add_cookie_header($browser); > > > > # ... some browsing code, including: > > my $response = $browser->get($url_canonical); > > > > # $cookie_jar->extract_cookies($response); > > # $cookie_jar->save($cookies_file); > > > > The result was that the file 'LWP_Cookies.lwp' was created but empty, > despite the HTTP server issuing a "Set-Cookie: xyz" header line. The file > contains just the following text: > > > > #LWP-Cookies-1.0[\n] > > [eof] > > > > (The square brackets signify new-line and end-of-file, respectively, not > literal text.) > > > > Obviously, since the file is empty, on repeat GET requests from that site no > cookies were sent as part of the GET HTTP header. > > > > Question #1: Should the minimal code above be enough to save received > cookies and to retrieve and send cookies? > > > > I then added the above commented out calls to the > $cookie_jar->load($cookies_file) and $cookie_jar->save($cookies_file) > methods with no discernable change. > > > > Question #2: aren't these methods superfluous here? > > > > I then added the $cookie_jar->extract_cookies($response); statement right > before the cookie jar save statement. This didn't change anything either. > The 'LWP_Cookies.lwp' file was still created empty! > > > > I also tried to add $cookie_jar->add_cookie_header($browser) to the request > preparation. That in turn caused an error message "Can't locate object > method "uri" via package "LWP::UserAgent" at > C:/Perl/site/lib/HTTP/Cookies.pm line 42." > > > > Question #3: What is wrong with the invocation of this cookie_jar method? > > > > And generally, what do I do wrong?
---------- Forwarded message ---------- From: Gisle Aas <gisle@aas.no> Date: Sun, May 23, 2010 at 20:54 Subject: Re: Cookies not saved to a file (thus no sent) To: Meir Guttman <meir@guttman.co.il>
The following example:
use LWP::UserAgent; use HTTP::Cookies; my $jar = HTTP::Cookies->new(file => "lwp.jar", autosave => 1); my $ua = LWP::UserAgent->new(cookie_jar => $jar); $ua->get("http://www.google.com")->dump;
fills the 'lwp.jar' file with a few entries for me. Doesn't it do so for you too?
--Gisle
On Sun, May 23, 2010 at 18:54, Meir Guttman <meir@guttman.co.il> wrote: > Dear LWP wizads! > > > > I began my usage of cookies support in LWP (libwww-perl ver. 5.836) under > Perl, (v5.10.1 for MSWin32-x86-multi-thread) as follows without the > commented-out code: > > > > > use LWP::UserAgent; > > use HTTP::Cookies; > > > > ... > > > > my $browser = LWP::UserAgent->new(); > > > > my $cookies_file = 'LWP_Cookies.lwp'; > > my $cookie_jar = HTTP::Cookies->new({file => $cookies_file, autosave => > 1}); > > # $cookie_jar->load($cookies_file); > > $browser->cookie_jar($cookie_jar); > > # $cookie_jar->add_cookie_header($browser); > > > > # ... some browsing code, including: > > my $response = $browser->get($url_canonical); > > > > # $cookie_jar->extract_cookies($response); > > # $cookie_jar->save($cookies_file); > > > > The result was that the file 'LWP_Cookies.lwp' was created but empty, > despite the HTTP server issuing a "Set-Cookie: xyz" header line. The file > contains just the following text: > > > > #LWP-Cookies-1.0[\n] > > [eof] > > > > (The square brackets signify new-line and end-of-file, respectively, not > literal text.) > > > > Obviously, since the file is empty, on repeat GET requests from that site no > cookies were sent as part of the GET HTTP header. > > > > Question #1: Should the minimal code above be enough to save received > cookies and to retrieve and send cookies? > > > > I then added the above commented out calls to the > $cookie_jar->load($cookies_file) and $cookie_jar->save($cookies_file) > methods with no discernable change. > > > > Question #2: aren't these methods superfluous here? > > > > I then added the $cookie_jar->extract_cookies($response); statement right > before the cookie jar save statement. This didn't change anything either. > The 'LWP_Cookies.lwp' file was still created empty! > > > > I also tried to add $cookie_jar->add_cookie_header($browser) to the request > preparation. That in turn caused an error message "Can't locate object > method "uri" via package "LWP::UserAgent" at > C:/Perl/site/lib/HTTP/Cookies.pm line 42." > > > > Question #3: What is wrong with the invocation of this cookie_jar method? > > > > And generally, what do I do wrong?
I began my usage of cookies support in LWP (libwww-perl ver. 5.836) under Perl, (v5.10.1 for MSWin32-x86-multi-thread) as follows without the commented-out code:
use LWP::UserAgent;
use HTTP::Cookies;
...
my $browser = LWP::UserAgent->new();
my $cookies_file = 'LWP_Cookies.lwp';
my $cookie_jar = HTTP::Cookies->new({file => $cookies_file, autosave => 1});
# $cookie_jar->load($cookies_file);
$browser->cookie_jar($cookie_jar);
# $cookie_jar->add_cookie_header($browser);
# ... some browsing code, including:
my $response = $browser->get($url_canonical);
# $cookie_jar->extract_cookies($response);
# $cookie_jar->save($cookies_file);
The result was that the file 'LWP_Cookies.lwp' was created but empty, despite the HTTP server issuing a "Set-Cookie: xyz" header line. The file contains just the following text:
#LWP-Cookies-1.0[\n]
[eof]
(The square brackets signify new-line and end-of-file, respectively, not literal text.)
Obviously, since the file is empty, on repeat GET requests from that site no cookies were sent as part of the GET HTTP header.
Question #1: Should the minimal code above be enough to save received cookies and to retrieve and send cookies?
I then added the above commented out calls to the $cookie_jar->load($cookies_file) and $cookie_jar->save($cookies_file) methods with no discernable change.
Question #2: aren't these methods superfluous here?
I then added the $cookie_jar->extract_cookies($response); statement right before the cookie jar save statement. This didn't change anything either. The 'LWP_Cookies.lwp' file was still created empty!
I also tried to add $cookie_jar->add_cookie_header($browser) to the request preparation. That in turn caused an error message "Can't locate object method "uri" via package "LWP::UserAgent" at C:/Perl/site/lib/HTTP/Cookies.pm line 42."
Question #3: What is wrong with the invocation of this cookie_jar method?
On Tue, May 4, 2010 at 12:33, Ivan Shmakov <ivan@main.uusia.org> wrote: > 1. The questions > > Do I understand it correctly that the most of the libwww HTTP > implementation is tied together by the means of the > LWP::Protocol::http module, while LWP::UserAgent just invokes > scheme-specific protocol handlers?
That's right.
> I need for the libwww HTTP client to use two scalar values as > the read and write buffers for communication instead of a, say, > IO::Socket::INET6 instance. Do I understand it correctly that > in order to do that I will have to:
There are many ways to hook into the protocol machinery. I tried to set it up just by creating my own http-handler and ::Socket package that subclass Net::HTTP::Methods, and then just filled in the missing methods that I found my test program invoked. I then ended up with the attached script. I hope you find it instructive.
On Thu, May 6, 2010 at 3:12 PM, Gisle Aas <gisle@aas.no> wrote: > > I would be nutty
:)
> to make the regular file protocol handler in LWP do > something with posted data. There must be some way for the POST > end-point to define the semantics of this operation. There is no > natural default.
I suppose. I can see big security issues too.... but it would be very useful IMHO.
> If this is just for rigging a test, you could just set up you own > handling code with LWP::Protocol::implementor() and then use whatever > scheme name you want.
yes, I could go that route. But that would mean adding that implementation to PERL5LIB. I don't know if I like that. I'll have to tinker some more. Thanks for the quick feedback.
On Thu, May 6, 2010 at 21:03, Jeff Macdonald <macfisherman@gmail.com> wrote: > I was writing some tests for some code in which a URI can be passed as > an option. This code POSTs to the URI. Instead of having the test > create a local web server, I thought it would be nice if file URI's > could be posted to. Is this a nutty idea? This way the test could just > then read the data created at the specified file URI. > > Something like this: > > POST file:/some/path/data > > would cause all the posted data to show up in data.
I would be nutty to make the regular file protocol handler in LWP do something with posted data. There must be some way for the POST end-point to define the semantics of this operation. There is no natural default.
If this is just for rigging a test, you could just set up you own handling code with LWP::Protocol::implementor() and then use whatever scheme name you want.
Hi all, I was writing some tests for some code in which a URI can be passed as an option. This code POSTs to the URI. Instead of having the test create a local web server, I thought it would be nice if file URI's could be posted to. Is this a nutty idea? This way the test could just then read the data created at the specified file URI.
Something like this:
POST file:/some/path/data
would cause all the posted data to show up in data.
Do I understand it correctly that the most of the libwww HTTP implementation is tied together by the means of the LWP::Protocol::http module, while LWP::UserAgent just invokes scheme-specific protocol handlers?
I need for the libwww HTTP client to use two scalar values as the read and write buffers for communication instead of a, say, IO::Socket::INET6 instance. Do I understand it correctly that in order to do that I will have to:
• define my custom classes (say, LWP::Protocol::http::MyBuffers, …::SocketMethods and …::Socket) based on LWP::Protocol::http, …::SocketMethods and …::Socket, respectively, that overload:
– …::MyBuffers: none, but calls to socket_class () are now ought to return …::MyBuffers::Socket, right?
– …::MyBuffers::SocketMethods: can_read () is to die unless given an argument of zero; sysread () is to no longer call the “real” sysread ();
– …::MyBuffers::Socket: should no longer be based on Net::HTTP (as the latter is derived from IO::Socket::INET), but instead on, say, Net::HTTP::MyBuffers, itself derived from a custom IO::Handle-like class (say, IO::Handle::MyBuffers) and Net::HTTP::Methods;
• define a custom IO::Handle-like class (IO::MyBuffers) implementing the following methods:
– sysread (), syswrite () and print (), as these are used by LWP::Protocol::http for I/O;
– blocking (), peerhost (), peerport (), that are stubs;
– _rbuf ()? I've failed to find where this method is defined?
Also, do I understand it correctly that LWP::Protocol::http::request () won't fit since it uses select ()?
2. Background
Bitflu (a BitTorrent implementation) currently implements an ad-hoc HTTP client, mainly in order to enable .torrent and RSS downloads.
It's my intent to replace this client with an libwww-based one.
By design, a Bitflu plugin should not perform I/O by itself, but should instead rely on the API provided by the Bitflu engine. The latter could roughly be summarized as follows:
• …->NewTcpConnection (%parameters) — establish a connection;
• …->WriteData ($token, $data) — queue data to be written.
There's no function to read data, as the engine invokes a callback function instead.
I guess that I could implement a buffer-based IO::Handle-like class and use it as a (part of the) glue between Bitflu's engine and the libwww HTTP implementation.
3. Acknowledgements
Okay, in the end it seems that the IO-like class mentioned above is way too similar to the String Ports feature, commonly found in Scheme implementations.
On Fri, Apr 23, 2010 at 11:11, Tom Hukins <tom@eborcom.com> wrote: > I have attached a couple of documentation patches to update the > location of LWP's git repository and provide links to related > documents.
Gisle Aas пишет: > On Apr 7, 2010, at 10:02 , Роман Николаев wrote: > >> Hello. Please help me to use your module URI-1.54. I see for URI::_punycode package, but not understand how to use it. >> I need convert domain names from local to punycode. >> >> Example: "кофемашина.su" (some_russian_letters.su) to "xn--80aannhnjd8c2b.su" >> >> I try to: >> >> use URI; >> my $uri = URI->new("some_russian_letters.su", "http"); > > The problem here is that this actually set up the 'path' portion of the URL to be the "some_russian_letters.su". The IDNA stuff only applies to the hostname portion. An example that works (for me) is: > > ----------------------------------------%<------------- > #!perl -lw > use utf8; > use URI; > my $u = URI->new("http://кофемашина.su"); > print $u->host; > ----------------------------------------%<------------- > > This prints "xn--80aannhnjd8c2b.su". > > --Gisle >
Thanks. It`s work =)
> > >> my $a = $uri->canonical; >> or >> my $a = $uri->iri; >> >> but $a is not punycode encoded string, just standart uri encoding: some %xx%xx%xx%xx....su >> >> Can You get me example or link to example? >> >> -- >> >> Roman V. Nikolaev >> >> mail: rshadow@rambler.ru >> icq: 198-364-657 >> jabber: rshadow@jabber.org >> site: http://www.rshadow.ru >
Compiling My Own perl—brian d foy (first page)
FMTIEWTK About Closures—Johan Lodin (first page)
Expecting Perl—Mark Schoonover (first page)
Perl and Undecidability—Jeffrey Kegler (first page)
The Year in Perl, 2007—brian d foy (first page)
Templating My Output—Alberto Manuel Simões (first page)
Making My Own CPAN—brian d foy (first page)
Programming Parrot—Jonathan Scott Duff (first page)
Komodo Test Drive—Jim Brandt (first page)
Named Captures in Perl 5.9.5—brian d foy (first page)
Simple Web Access—Alberto Manuel Simões (first page)
Parrot Status Report—Jonathan Scott Duff (first page)
Mapping Op Codes—Eric Maki (first page)
CPANdeps—David Cantrell (first page)
HTML Slides—Grant McLean (first page)
Alter Egos—Anno Siegel (first page)
Found Perl is section of The Perl Review's website where we posted pictures of Perl paraphernalia or the word "Perl" in the wild. We started it a long time ago, and were very slow in updating it when people would send in photos.
Now "Found Perl" is a photo pool on Flickr. Instead of sending them to TPR, just add them to the pool.
The Perl Review's website has had a section on Schwern's Shirt, the orange monstrosity that brian d foy bought at the charity auction for The Perl Foundation at the 2004 Open Source Convention.
Now we've moved the section of the website to a Flickr group for Schwern's shirt. This way, anyone can add their photos of Schwern's shirt to the group. Instead of being infrequently updated on the website, people can add them as soon as they upload them to Flickr.
If you don't have a Flickr account and don't want to create one, you can still send them to The Perl Review by mailing them to editors@theperlreview.com.
David Pogue had a momentary lapse of judgement when he proclaims in his blog that the date sequence 01:02:03 04/05/06 will only happen once in all of human history.
Besides the obvious gaffes of date formatting (which one is the month and which one is the year?), the red herring of leading zeros (to make the minute and second stand out), and so on, no one who's seen this has made the comment that calendars say whatever we want them to say and the numbers are only special because we set the calendar up that way in this one case. What about the Chinese, Hebrew, and Muslim calendars?
So this seems like a good challenge to publish in The Perl Review: using the Perl Date modules (or not, I guess), in how many different calendars and formats can you make this sequence? What else is special about those days (are they a weekend, fall on a full moon, have a solar eclipse, etc.)?
Powell's Technical Books in Portland (that's the one on 33 NW Park Avenue) is going to carry The Perl Review. It's our first newsstand distribution.
I had to set a newstand price. The deal basically works like this: bookstores keep most of the profit. Magazines make money when the single-issue buyers turn into subscribers. After Powell's cut, which we set at 40%, and my costs, $2 an issue, I have to figure out a price that also motivates people to give the money to The Perl Review directly instead of the book store. That's why you see big discounts for magazines when you subscribe: that's the real price, and everything else is markup. The Powell's price ends up being $5, which is 50 cents more than the subscription price.
That's not to say that newsstands are bad. It's like better-than-free advertising since it sits on the shelf and I cover my costs plus a little more for every issue sold.
Forget about absolute numbers for a moment. At my price point, if they sell 75% of the copies, I break even. That would be fine with me because any copy sitting on the actual magazine display means people see that issue. Some might subscribe later even if they don't buy it. Now that I have a price point, I have to figure out the right number of issues. That's something I just have to guess.
I left 16 copies of the Spring 2005 issue, but I also have to consider that I sold about 10 at the Intermediate Perl book signing. We'll see how that goes.
Now, a good magazine accountant has to keep track of the actual number of newsstand sales too. As much as I'd like to pretend that we sell every single copy, the Post Office wants to know where all the issues went to verfiy that we abide by all the periodical rules. It's not enough for the newsstand to simply tell me what they sold. They certainly aren't going to tell me they sold everything when they didn't since that's money out of their pocket. They can't really tell me they sold nothing because that's money out of my pocket.
If you're a late night person living in a city, you might have seen a bunch of guys tearing off the front pages of newspapers and magazines. Instead of sending back the unused copies, they send back the cover (and they do that for books too). Every cover they don't send back is a sale that they owe me money for.
You might think those unsold issues represent lost money, but they really don't. They are a sunk cost, meaning that I would have spent that money regardless of the sales. That starts way back at the printers when I have to decide how many issues I want. That number includes all subscriptions, complimentary copies, samples to user groups, and all the issues I'll need to fulfill orders for back issues. Not only that, but the more copies I print, the lower the incremental cost (the cost per each copy). Each printing job has a fixed overhead for the job preparation, machine set-up, and so on. That's the make ready. I end up printing many more copies than I need, partly to amoritize the make ready. Not selling at the newsstand is slightly better than not selling while sitting in boxes in the office. At least people see them at the newsstand.
Remember that magazines make money on subscriptions, so that's the goal. I don't care about selling more at the newsstands. If someone subscribes because they see an issue on the newsstand, the profit from the subscription pays for about three unsold newsstand copies, so five subscriptions from people seeing the issue at Powell's would make up for no sells. That's just breaking even, and nobody makes any money. That also means I'm spending $6 to get a new subscriber.
If you're already despondent, you don't want to read about distributors. Most bookstores don't want to deal with every individual publisher. They'd have to keep track of a separate deal for every magazine. Instead, they want to deal with a single source in the same way they deal with books. I know my costs, and I know the newsstands cut, and I have a price point that I can't change to much because people won't buy it at too high a price. If I use a distributor, perhaps to get into the big chain book stores, they are going to want a big cut too. I'll end up either breaking even or losing money on every newsstand copy, and I'll want to convert that to a subscription as soon as possible. That's why you see so many wonderful subscription cards in the magazines.
So far I've just talked about money from sales. We can also sell advertising, which we do for the special friends of the Perl community. Since magazines know they are going to lose money at the newsstand, they make up the difference with paid advertising. Ever wonder why magazines such as Wired are mostly advertisements? That's making up for the money they'll lose on the newsstands. Remember when I talked about keeping track of the number of copies sold? Advertisers want to know those numbers. They don't care how many copies the newsstand bought. They care about the number of copies that shoppers bought. That sets the rate at which the magazines can sell ads. More eyeballs equal more dollars. There's a separate industry of companies that audit magazines to verify the numbers. That's even more money that gets sucked away.
The short story? Subscribe to the magazines you like. It's the only way they can survive.
Last year, I started including interviews with Perl people on The Perl Review website, but I didn't add a feed for that. Now I have and it's on RSS page.
The web site is actually a directory processed by Template Toolkit, so what I really need to do is add indexing support as ttree goes through the directories, then spit out pages as it does that. That sounds like a magazine article...
Every issue I get a couple of book reviews that don't quite cut it. Techies tend to present too many sides of the story: rather than express their opinion, they equivocate by pointing out all the holes in their own opinion. In short, they are entirely too nice.
Being nice isn't a bad thing, but what people really want out a book review is a recommendation. "Should I buy this book?" It doesn't matter if people agree with you as long as you are fair to the book. After that, people want to know the particulars: who, what, when, where, and how.
So far, The Perl Review has taken reviews from several different people, and very few people have provided multiple reviews. That worked when we were first getting started, but now I think we need something different. Since book reviews are about opinions, and the reader doesn't have to agree with the reviewer, I think readers need to know the reputation and leaning of the reviewer to make their own decision. For instance, my wife doesn't agree with movie-reviewer Roger Ebert, but based on his negative reviews she knows which movies she will like. At the same time, she knows the certain people on LiveJournal likes the same sorts of movies she does, so she can trust them.
In line with all that, I think I'm going to move towards recurring book reviewers, and do more to establish their reputation. That also means that I want to get a couple of reviewers who think about books differently so I can give more readers someone that thinks like them. I've approached a couple of people, and we'll see how it turns out.
I've added two guides I hadn't run across previously:
It seems that every time I put out a new issue I have to leave town for a couple weeks. I don't think the two are related. Travel is just too busy this year. Add to that finishing up the Alpaca book and I've had a pretty busy week. I'll be back in the middle of December.
I'm sending out the email announcements as I post this. Once you get the new password, you'll be able to download the latest issue of The Perl Review.
In this issue:
Seven Sins of Perl OO Programming -- chromatic
Hash Anti-Patterns -- Alberto Manuel Simões
Haskell for Perlers -- Frank Antonsen
PerlWar -- Yanick Champoux
books reviews, commentary, news and more...
Some of you neglected to renew, but I won't bug you in email anymore. To find out more about the sampler on the cover, you'll have to renew that subscription.
If you haven't subscribed yet, now's the time because I have to raise prices next year when the US postal rates go up.
The next issue of The Perl Review comes out in a couple of weeks, so it's time to renew if you've already finished your first year subscription!
This may seem odd for some who just recently subscribed, but with the magic of time travel we let you pretend that your subscription started much earlier by allowing you to choose which issue to start your subscription. You may have subscribed yesterday but selected to start with issue 1.0 (Winter 2004), meaning that your issue ran out with our last issue, 1.3 (Fall 2005).
I've found that most new subscribers like to get most of the back issues at first, and it's worked out rather well for us. Now that we're starting our second year, though, I have to figure out how to make that work so people don't have to renew right away. I'll have to add a two-year subscription, I think.
I've been reading lot about magazine renewal rates. A lot of publications seem to be happy to get 25% renewals, and they actually spend a fair bit of money to get that. Ever wonder why you get some many magazine renewal letters in your postal mail?
For TPR, since I don't have a lot of money, I simply used email. The target audience is certainly technology-adept, so that's not so bad. So far I've sent out three renewal emails. One was the week before OSCON, and I got about a 45% response for that. That's already good for magazines, but not quite the 98% renewal rate TPJ had in its first year. I sent out a second email two weeks after that, and another one over the weekend. I think I'm floating somewhere around 75% renewal right now.
I have a list of all of the people who haven't renewed (it's an SQL view ;), and a lot of them should have and I would be surprised if they don't. Although email provided me with a virtually free way to get that 75%, I also think email has a tendency to get lost. First, if the subscriber can't deal with it right awy, it joins the long queue of messages that get ignored forever. Second, it has a pretty good chance of being blocked by a spam filter. Third, some people might get so mucch mail that they just don't get to ever see it. I do send each mail individually since each contains a persoanl renewal code, so I'm not blasting out spam to any user at each domain.
I am considering sending out some postcards to the hold-outs. I figure that will cost me about $50, which means that I need about four renewals to make up for it. If I get four renewals, that's paid for. I'm also going to try emailing people directly. It certainly helps when other people talk about TPR. I notice a big spike in renewals when Ovid talked about his upcoming Logic Programming article.
There's another trick to getting renewals: special promotional subscriptions. Magazines give you a special rate for a limited time then hit you up for the full price as quickly as possible. It's all part of the ad-selling game. Advertisers want to know how many "qualified subscribers" you have, which means how many people actually want your magazine enough to pay for it. Getting people to be full subscribers raises those numbers.
TPR is a bit different because I don't aim to make it an audited magazine, meaning that no one is going to come in and put a stamp on our books saying they verified our subscriber base. I'm not in it to sell advertising (let's see if I'm saying the same thing in three years). So far I've only taken advertising from people the Perl community already loves and trusts. Most of that is just filling up the other full color pages that come along with the cover.
I now have a big stack of emails confirming renewal transactions, and I need to shove those transactions into my local database so people keep getting their magazines.
Most of them are pretty easy because they are keyed on their unique ID in the database. A lot of people skipped the link I sent them and went to the subscription page directly, so I have to match up those with what I see in te database.
So far it works like this and handles 95% of the records:
Get all the matches by name
With one match, we're probably done
With no match, try different parts of the name (last, first)
With multiple matches, we need to match something else too.
From the name matches, compare email addresses. If they match, we're done.
At this point we probably have several candidate matches.
Look at parts of the address (country, city, address). If the first two are matches, we're pretty sure we have a match.
Look at the email if we might have a match and compare the user portion to the new email and the stored email. Do the same for the host portion. This is just to raise the confidence level a bit.
This leaves about 5% that I need to check by hand. It's the first time I've had to go through with this so I'm being very cautious. Thank god for test suites.
Now that we've made it through the first year, it's time to get people to renew. I've sent out renewal emails, but I'm guessing 10% of them will never make it into an inbox. Spam has just about ruined email for anything.
If you've already received four issues, it's time for you to renew, and you can use subscription form and subscribe again.
Either way, I have an interesting task ahead. Since I don't store any personal information on the Pair.com servers that power our website, and we never store credit card information or do recurring billing, I get to match up the renewals with existing subscribers. It's easy to know which transactions are renewals, and each email I've sent has a link with a query string that I can link back to a subscriber. However, people might not follow the link but go directly to the webiste, or all sorts of other things that don't let me see that code. We'll see how that goes.
In related matters, I was rewriting the code bits that parse the email I get so I can shove all that stuff into the database. I was doing fancy things with ergexen, then Template::Extract, and some other things, and although it was a lot of fun, it was a big waste of time. Since I really just wanted to suck it into another program, why not send it as a ready-to-use data structure? It's easy enough to freeze things and unthaw them later. I still see my nicely formatted template, but at the end I include the Perl ready data. Besides the trivial parsing to isolate that, I'm ready to important things into the database. Things can be too simple to be seen sometimes.
I finally got to meet Eric Maki, TPRs designer, in person. We went through the current issue and looked at a lot of the design things we might want to change, and we also have an idea for an upcoming project I'll have details later.
If you haven't seen the latest cover (Summer 2005), get yourself an issue. It's so nice that we're going to make posters of it.
After a long day at YAPC where I taught a 4-day Learning Perl course in a single day, and then a 5 hour boat dinner cruise, Josh McAdams of Perlcast interviewed me about The Perl Review. I'm not sure when he'll publish it.
The cool thing is that Josh is moving to Chicago. I might be able to get on Perlcast a bit more often. :)
I got an advnace copy of The Best Software Writing from Apress. It's a collection of writings compiled by Joel Spolsky. Anyone want to take a whack at reviewing this for the next issue?
The Perl Review Summer 2005 issues should be in the mail today. The printer was screwing around again. They've been a disaster. You know the sort of people: they can't just do something without sending four emails back and forth, each with some new reason why things can't happen right away.
I'm thinking about making a special edition print issue with the best articles from the first two years. Good or bad idea? How much would you pay for that sort of thing? Which articles would you want?
The next issue is scheduled for December 1, and I'm looking for book reviews. Any recent book might work, but I'm specifically interested in reviews of:
Reviews should be 200 to 300 words and should reflect your opinion. Say explicitly who should buy this book and why they should, or that nobody should buy the book. No matter what you say, be nice.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
