Custom Search
|
Date: May 31, 2005
From: "John Alden" <john.alden@xxxxxxxxx>
It appears that some emails sent to our CPAN address are being dropped along the way and never reaching us. We are looking into this. In the meantime if you've tried contacting us and haven't heard anything in a week then email me directly and I'll make sure it gets attention. Apologies to anyone who has been ignored as a result of this. A new version of Pod::Xhtml should be out sometime this week. Thanks to Brian Cassidy and Shlomi for their patches. John +------------------------------------------+ | John Alden - Software Dev Team Leader | | BBC Learning and Interactive [2502 WC] | | Tel: 0208 752 7296; john.alden@xxxxxxxxx | +------------------------------------------+ -----Original Message----- From: Shlomi Fish [mailto:shlomif@xxxxxxxxxxx] Sent: 29 May 2005 05:01 To: module-authors@xxxxxxxx Cc: CPAN Authors Subject: Contacting the BBC Hi all! The BBC (= British Broadcasting Corporation) CPAN User has a nice module: http://search.cpan.org/dist/Pod-Xhtml/ Problem is that it doesn't generate fully valid XHTML in many cases. To remedy this I wrote a patch, submitted it and filed a bug report: http://rt.cpan.org/NoAuth/Bug.html?id=12718 But I received no reply for it since three weeks ago. I'm getting impatient. I'd rather not fork the module. Regards, Shlomi Fish --------------------------------------------------------------------- Shlomi Fish shlomif@xxxxxxxxxxx Homepage: http://www.shlomifish.org/ Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Date: May 31, 2005
From: Xavier Noria <fxn@xxxxxxxxxxx>
In-reply-to:
<3878FDED-7907-48C1-BC28-4D2644899612@xxxxxxxx>
References:
<3878FDED-7907-48C1-BC28-4D2644899612@xxxxxxxx>
-- fxn
Date: May 31, 2005
From: Nicholas Clark <nick@xxxxxxxx>
On Tue, May 31, 2005 at 03:14:19PM +0530, Sapna Jain wrote:
Hello Sir,I m trying to install optimizer module of Perl, but it make test fails, giving following errors. I have red hat Linux as operating system and Perl5.8.6 installed. I cannot figure out where the actual problem is.
To: cpan-discuss@xxxxxxxx, cpan-testers@xxxxxxxx, module- authors@xxxxxxxx,
module-build-general@xxxxxxxx, modules@xxxxxxxx,
perl-unix-users@xxxxxxxx
Spamming multiple inappropriate lists *isn't* the correct way to
encourage
people to help you. Have you read the fine documentation? The "Author" section gives the current maintainer as Arthur Bergman. Have you tried contacting him? (Also, I don't know the answer to the original problem, so mailing me privately isn't going to help) Nicholas Clark
Date: May 31, 2005
From: Nicholas Clark <nick@xxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0505311426220.411@xxxxxxxxxxxxxxxxxxx>
References:
<Pine.LNX.4.61.0505311426220.411@xxxxxxxxxxxxxxxxxxx>
On Tue, May 31, 2005 at 03:14:19PM +0530, Sapna Jain wrote:
>
>
> Hello Sir,
>
> I m trying to install optimizer module of Perl, but it make test fails,
> giving following errors. I have red hat Linux as operating system and Perl
> 5.8.6 installed. I cannot figure out where the actual problem is.
To: cpan-discuss@xxxxxxxx, cpan-testers@xxxxxxxx, module-authors@xxxxxxxx,
module-build-general@xxxxxxxx, modules@xxxxxxxx,
perl-unix-users@xxxxxxxx
Spamming multiple inappropriate lists *isn't* the correct way to encourage
people to help you.
Have you read the fine documentation? The "Author" section gives the
current maintainer as Arthur Bergman. Have you tried contacting him?
(Also, I don't know the answer to the original problem, so mailing me
privately isn't going to help)
Nicholas Clark
Date: May 31, 2005
From: Sapna Jain <sapna@xxxxxxxxxxxxxx>
Hello Sir,I m trying to install optimizer module of Perl, but it make test fails, giving following errors. I have red hat Linux as operating system and Perl 5.8.6 installed. I cannot figure out where the actual problem is.
Error :
t/01.....................Can't load
'/usr/local/lib/perl5/site_perl/5.8.6/i686-l
Linux/auto/B/Generate/Generate.so' for module B::Generate:
/usr/local/lib/perl5/s
ite_perl/5.8.6/i686-linux/auto/B/Generate/Generate.so: undefined symbol:
fold_co nstants at /usr/local/lib/perl5/5.8.6/i686-linux/DynaLoader.pm
line 230.
at /root/perl-5.8.6/optimizer-0.05/blib/lib/optimizer.pm line 5
So, plz reply asap.
Thanks
--
-----------------------------------------------------------------------------
Only when you believe in your dreams...
you can make them come true !
------------------------------------------------------------------------------
Sapna Jain
Mtech 1 CSE
IITB
------------------------------------------------------------------------------
Date: May 29, 2005
From: Shlomi Fish <shlomif@xxxxxxxxxxx>
Hi all! The BBC (= British Broadcasting Corporation) CPAN User has a nice module: http://search.cpan.org/dist/Pod-Xhtml/ Problem is that it doesn't generate fully valid XHTML in many cases. To remedy this I wrote a patch, submitted it and filed a bug report: http://rt.cpan.org/NoAuth/Bug.html?id=12718 But I received no reply for it since three weeks ago. I'm getting impatient. I'd rather not fork the module. Regards, Shlomi Fish --------------------------------------------------------------------- Shlomi Fish shlomif@xxxxxxxxxxx Homepage: http://www.shlomifish.org/ Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs.
Date: May 24, 2005
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<428F2C3E.50100@xxxxxxxxxx>
References:
<428F2C3E.50100@xxxxxxxxxx>
Robert Rothenberg wrote:
[snip]
In other words, I start off with a proof of concept 'hack' that evolves into a module. (When I start with h2xs, I find I am constantly renaming things, moving them around, etc.)
Is this "constant renaming" and "moving things around" a result of using h2xs? Or is it just your own style of work? And is it necessarily a bad thing?
So the obvious thing to do is to have a kind of 'hack2pack' script that parses the script and generates the appropriate modules, and test file.
How would having a hack2pack script preclude one from "constant renaming" and "moving things around" (or reduce the incidence thereof?)
jimk
Date: May 21, 2005
From: Robert Rothenberg <wlkngowl@xxxxxxxxxx>
Lately I've gotten into the habit of writing modules by starting with a script that usually takes the form:
package Some::Name; ... package Some::Other::Name; ... package main; use Test::More; ...For me it's easier than using h2xs since I'm not always sure what the namespace will be, or how many packages it will have, etc.
In other words, I start off with a proof of concept 'hack' that evolves into a module. (When I start with h2xs, I find I am constantly renaming things, moving them around, etc.)
So the obvious thing to do is to have a kind of 'hack2pack' script that parses the script and generates the appropriate modules, and test file. The script can probably generate most of the POD automatically by looking for subroutines as "sub", and even generate Build.PL/Makefile.PL by looking for "use" and "require". (Yes, it won't be 100% but it will save me a bunch of work.)
What do you all think of the idea? Regards, Rob
Date: May 21, 2005
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<20050520231448.GA5116@xxxxxxxxxxxxxxxxxxxx>
References:
<20050520231448.GA5116@xxxxxxxxxxxxxxxxxxxx>
* Michael G Schwern <schwern@xxxxxxxxx> [2005-05-21 01:20]: > http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.30.tar.gz > or > http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk > or > a CPAN near you. On behalf of at least myself and probably many others, I just wanted to say: Thank you for doing the thankless work on this ugly beast, Michael. :-) The complainers may have the loudest voices, but your work *is* appreciated. Regards, -- Aristotle “If you can’t laugh at yourself, you don’t take life seriously enough.”
Date: May 20, 2005
From: Michael G Schwern <schwern@xxxxxxxxx>
http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.30.tar.gz or http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you. PL_FILES still wasn't quite back the way it was prior to 6.26. Now I believe it is. It turns out the behavior as even more complicated and subtle than I thought. See the PL_FILES documentation for details. Everything should now work the way it did before 6.26. 6.30 Fri May 20 16:05:38 PDT 2005 * PL_FILES behavior tweak again to restore old behavior. Sometimes its supposed to run before pm_to_blib, sometimes after. - Some tests shipped with 'no_plan' which will break on older Test::Harness. 6.29 Thu May 19 14:15:21 PDT 2005 * The behavior of PL_FILES is restored to its pre-6.26 behavior as several CPAN modules depend on this. PL programs run via PL_FILES have INST_LIB and INST_ARCH in their @INC and so can load any just built modules. - Now honors PERL_CORE environment variable. - Testing to ensure FIRST_MAKEFILE is honored. 6.28 Tue Apr 12 16:17:07 PDT 2005 - Fix realclean so it cleans up files installed from ext/ in the core - Fix dir_target() so it doesn't warn should any of the INST_* paths be the same (as with the ext/ modules in the core) - Fix MANIFEST.SKIP so it skips not just _darcs/ but everything inside it and any which happen to be in subdirs. - MM_AIX forgot to import neatvalue() from E::MakeMaker. (bleadperl@24185) - Fixed a minor C<<>> POD nit (Scott Lanning) -- Michael G Schwern schwern@xxxxxxxxx http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Date: May 20, 2005
From: Scott W Gifford <gifford@xxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0505201244220.2071@xxxxxxxxx> (Keith Ivey's message of "Fri, 20 May 2005 12:45:21 -0400 (EDT)")
References:
<qszr7g1dg5b.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0505201244220.2071@xxxxxxxxx>
Keith Ivey <kcivey@xxxxxxxxx> writes: > Should it go under Geo? I should have mentioned that it works on a building-scale, not a city-scale, so Geo(graphy) seemed in appropriate to me, though I could probably be convinced otherwise. ----ScottG.
Date: May 20, 2005
From: Keith Ivey <kcivey@xxxxxxxxx>
In-reply-to:
<qszr7g1dg5b.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<qszr7g1dg5b.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Should it go under Geo? -- Keith C. Ivey <kcivey@xxxxxxxxx> Washington, DC
Date: May 20, 2005
From: Scott W Gifford <gifford@xxxxxxxxx>
Hello, I'm finishing up a module to interface with the Ekahau location sensing system, and I'm trying to figure out a good top-level namespace to put it in. I felt confident people here would have opinions. :) Ekahau is a system that provides location estimates based on a vector of wireless signal strengths, a large set of training data, and a proprietary Bayesian-like statistical model. My module interfaces with it using their own protocol, which runs on TCP and smells a little like XML. I'm tempted to release it as simply Ekahau::*, since a new toplevel namespace seems to be the preferred place to put interfaces to proprietary systems. I considered Net::Ekahau, but it seems plausible to me that Ekahau could release a version of their software that communicated over IPC or a serial port, so I think that's not a great idea. I considered creating a new topleve namespace LocSys for location-sensing systems, but that seems premature, since I don't see any other modules for interfacing with these sorts of systems, and I don't plan on writing any more myself in the immediate future. So: Does anybody have any objections to a new top-level Ekahau namespace, for interfacing with proprietary equipment from Ekahau? ----ScottG.
Date: May 04, 2005
From: Robert Rothenberg <wlkngowl@xxxxxxxxxx>
An initial version of Pod::Readme has been uploaded to CPAN. It can be found at http://search.cpan.org/~rrwo/Pod-Readme-0.01/
This version does not yet have meaningful tests (*gasp*) and does not automatically generate a REQUIREMENTS or INSTALLATION section.
Feedback and suggestions would be appreciated. Rob
Date: May 03, 2005
From: philippe.bruhat@xxxxxxx (Philippe 'BooK' Bruhat)
In-reply-to:
<86ll7brkz7.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<200504211226.06624.ewilhelm@xxxxxxxxxxxxx> <86ll7brkz7.fsf@xxxxxxxxxxxxxxxxxxx>
Le vendredi 22 avril 2005 à 06:37, Randal L. Schwartz écrivait:
> >>>>> "Eric" == Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx> writes:
>
> Eric> Just spent way too much time trying to find a bug when it turns out
> that
> Eric> I just had a full disk.
>
> I check for errors on close about as often as I check for errors on
> print.
I have at least one shell script that uses a Perl one-liner which DOES
check for errors in print (which happen when the disk is full) to die
early.
Since the one-liner basically reads a file and dipatches the lines
in different files (based on a date field), there is a small period
of time where we have the whole (big) file content duplicated on disk
(before the rest of the shell script removes the old file and goes on
with its business). The shell script dies when the perl one-liner does,
leaving a nice message to be be emailed by the cron daemon. The machine
administrator can then make some room and run the shell script again by
hand.
--
Philippe "BooK" Bruhat
Some fair deals are fairer than others.
(Moral from Groo The Wanderer #101 (Epic))
Date: May 01, 2005
From: "Graciliano M. P." <gmpowers@xxxxxxxxxxxx>
Felow developers, I have just released Thread::Isolate/0.05, that is a colection in a single place of resources to work with threads in Perl. With it is possible: - Share any type of data between threads. - Control one thread externally, sending jobs. - Spy the internal state of a thread. - Map a thread package to another thread package. - Isolate the loaded modules from different threads. - ... and much more... Now I think that Thread::Isolate have all the main resources that I need to work with complex thread mechanismes, but for now this was built in a closed box, since I didn't had much feedback about it yet. So, I'm asking for some tests and specially for feedback and suggestions. I will be glad for any help. Thanks in advance. Regards, Graciliano M. P.
Date: May 01, 2005
From: Robert Rothenberg <wlkngowl@xxxxxxxxxx>
Eric Wilhelm wrote:
I always do perldoc -t Module.pod > README, and it works out pretty goodIt looks like what Rob is trying to do is create a README which contains only the "README-like" info, while also causing these sections to be ignored by the standard perldoc. IMO, this is a good idea, and maybe could be builtin to Module::Build. I don't like having INSTALLATION sections in the docs for things that are already installed, and I would prefer not to read about function prototypes when I'm just trying to install a module.
I'm glad somebody understands what I was talking about!I want a middle way between 'perl2text Module.pm > README' and manually updating a README every time.
The important thing is that you don't have to use a special perldoc on the module file and don't have to change the pod text. I'm guessing that's why everything has a '=for readme foo' syntax to it?How do you make a section that both goes in the readme and works with perldoc? Is that what the commands are for?
If you had no '=for readme' formatting codes, it would include the entire POD as if you used 'pod2text Module.pm > README'. You add the
codes to specify what you want skipped, or included only in the readme. Some sections like REQUIREMENTS and INSTALLATION could be generatedautomatically. For requirements, parsing the META.yml should be good enough. For installation, check if there is a Makefile.PL and/or Build.PL.
I think this should cover most cases. Eric: I don't understand the '=for hacking foo' stuff.In my modules I sometimes add '=begin internal/=end internal' sections to document internal methods, but I leave those for anyone hacking a module to find: I don't export them to anything.
Rob