On 07 April 2005 23:02 Ken Williams wrote:
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed
on a platform so that CPANPLUS or CPAN::YACSmoke can issue an NA
(Not Applicable) report?
CPANPLUS relies on module names
Hello Chris,
Chris Dolan wrote:
On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote:
I would suggest now to name the module Win32::Storage::ReadSummaryInfo.
I like this better than before, but why not Win32::Document::SummaryInfo?
Because not only MS documents can be read? There is also the
Hello Chris,
Chris Dolan wrote:
On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote:
Hello Chris,
Chris Dolan wrote:
On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote:
I would suggest now to name the module
Win32::Storage::ReadSummaryInfo.
I like this better than before, but why not
On Fri, Apr 08, 2005 at 09:08:51AM -0400, Philip M. Gollucci wrote:
Ken Williams wrote:
Agreed - for providing a stable download link of a CPAN package, backpan
is better than CPAN itself. If this could be integrated into the BSD
system itself that would be great.
-Ken
Hi, as a
Chris Dolan wrote:
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on
a platform so that CPANPLUS or CPAN::YACSmoke can issue an NA (Not
Applicable) report?
CPANPLUS relies on module names (e.g. Solaris:: or Win32::) but
David Cantrell wrote:
Let's take my module File::Find::Rule::Permissions as an example. I
know it doesn't work on Windows, but not having access to a Windows
machine, I have *no idea* what $^O should be on that platform,
especially for any odd Windows environments like Cygwin or WinCE. I
Robert Rothenberg wrote:
I'm all for something like this, though I prefer requires_libraries
instead. (Listing libraries distinct from applications is a grey area,
so best to put them under one term.)
Come to think of it, why not recommends_libraries too?
What is needed is some standard set of
Hi All,
We're working on a new module that will allow the following:
* Ability to load a PHP interpreter from Perl and use it to execute PHP
code.
* The PHP interpreter will be able to reach back into Perl to use data,
modules,
etc.
* Yes, this means that PHP folks will be able to use DBI and
On Apr 8, 2005, at 5:57 PM, David Wheeler wrote:
So, other module names we've come up with include:
Embed::PHP
Interp::PHP
Thoughts? Suggestions?
You don't want to use the Inline::PHP namespace?
-Ken
On Apr 8, 2005, at 5:57 PM, David Wheeler wrote:
Anyway, we need a name for this module. The working name is
PHP::Sandwich, but that's a bit cutesy. The PHP namespace is already
taken, which is too bad, because it'd be nice to be able to just do:
my $php = PHP-new;
$php-execute($code);
Wait
On Apr 8, 2005, at 4:43 PM, Ken Williams wrote:
You don't want to use the Inline::PHP namespace?
No, it's not inline PHP, AFACT.
Wait a sec - it looks like the PHP namespace is already taken by a
module that does essentially what you're trying to do. Can you just
work with Dmitry on what it
Same here.
On 08/04/2005 20:02 Ken Williams wrote:
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die NA: $reason;
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author
figure it
out. Its simple and
In article [EMAIL PROTECTED], Randy W. Sims
[EMAIL PROTECTED] wrote:
Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently,
Perhaps we can put this under a namespace like Config:: ?
I imagine that
I don't know. The developers working with me on the project say that
it needs to be something different...George?
PHP::Something is far better than Something::PHP for what you're
talking about. The PHP::* space is filled with lots of PHP crossover
already.
How about PHP::Crossover?
xoxo,
Andy
14 matches
Mail list logo
