Hi Jonas-
You seem to have renamed an indexed pm file
in your distribution. Did you also change
the name of the module as well: LOCAL -> Local?
Assuming that everything has been changed
consistently, then there may be some case
checks in the indexer which are being
triggered.
BTW, I'm curious
The PDL::FFTW module is out-of-date and has been essentially broken
for a long time without anyone being aware of it. It has been marked
deprecated in favor of PDL::FFTW3 and I think now is the time to finally
remove it from CPAN.
Should I just go ahead an delete it or is there another, intermed
Hi Shlomi-
The biggest issue I've seen with float version strings and triple-dot
versions is with support for older perls.
The other big issue, is make up your mind and stick with one. FYI, the
PDL module got caught with switching between float string and triple dot
versions which made mess
In the run up to a PDL-2.008 release, PDL::Slatec is now being indexed by
the CPAN indexer and since I am not listed as co-maintainer the releases
are now shown as UNAUTHORIZED. I would appreciate if one of the CPAN
admins could add me, CHM, as co-maintainer to PDL::Slatec for the PERLDL
pseudo-au
Thanks! I appreciate all the suggestions. --Chris
On Sat, Dec 13, 2014 at 12:56 PM, Karen Etheridge wrote:
>
> All the suggestions so far are bang on -- I just have one more: prepan.org
> is a great place to post your module and get early feedback on it!
>
All-
I'm working on some new module development
and I would like to make the progress available
via CPAN and for testing, I don't want to start
claiming package namespaces until things
settle down.
I thought I read somewhere that there is a
way to have a "non-comittal" CPAN module
in the sense th
Hi Paul-
This is very intriguing work. PDL as a module is
focused on efficiently calculating for numerical computation.
Ability to compute with more general PDF objects would
be very interesting to the PDL community.
Specifically, the coming PDL3 refactoring to a more general,
flexible, and exte
I would like to factor out the explicit detection and configuration of
the PDL build process on external libraries (such as PROJ4, HDF5,
FFTW3,...) into corresponding Alien::PROJ4 or similar distributions.
The job of these Alien::XXX modules is to check for XXX. or install
XXX, and provide configur
functionality
"by hand".
Now automate that.
--Chris
On Thu, Jan 9, 2014 at 2:25 PM, Paul "LeoNerd" Evans
wrote:
> On Mon, 6 Jan 2014 20:02:31 -0500
> Chris Marshall wrote:
>
>> pkg-config has a standard format. I see no reason why
>> the Alien::unibilium coul
On Mon, Jan 6, 2014 at 5:54 PM, Chris Marshall wrote:
> On Mon, Jan 6, 2014 at 5:32 PM, Paul "LeoNerd" Evans
> wrote:
>> ...
>>
>> This surely limits Alien wrappings to only being useful for C libraries
>> that don't themselves have other C-l
On Mon, Jan 6, 2014 at 6:43 PM, Paul "LeoNerd" Evans
wrote:
> On Mon, 6 Jan 2014 17:54:56 -0500
> Chris Marshall wrote:
>
>> Again, Alien modules are for *perl* to access external dependencies
>> and not for other external dependencies to access eachother---you
On Mon, Jan 6, 2014 at 5:32 PM, Paul "LeoNerd" Evans
wrote:
> On Mon, 6 Jan 2014 17:21:04 -0500
> Chris Marshall wrote:
>
>> Hi Paul-
>>
>> I'm a bit confused by the discussion so far. Alien modules are to
>> provide external dependencies &qu
Hi Paul-
I'm a bit confused by the discussion so far. Alien modules are to
provide external dependencies "wrapped up" for perl modules to use
and not, in general, as a way to resolve C library dependencies.
Once installed, an Alien module should provide all the information
needed to use the libra
Hi-
One option that could be used for immature module distributions
is to release them as CPAN developers releases, e.g. with a
'_01' in the distribution name. That will allow users to install
from CPAN via an explicit distribution request but it will not be
official until the first non-developer
I've been working on an update to the Alien manifesto
to clarify some details of implementation that fall in
the best usage category. In general, an Alien::XXX
module would choose the first applicable option among:
* detect and configure for system XXX if meets
the specific requirements for XXX
See the responsibilities sections of an Alien module
in the Alien documentation:
> On installation, make sure the required package is there, otherwise install
> it.
This is handled at the Alien::libtermkey install. You detect or
install libtermkey (in a perl-local directory) and are able to
pro
Per my previous discussion on this list, I would like to
update the Alien module (manifesto) with current best
practices and adding the capability of detecting an
existing installation as a common-sense default that
would lead to Alien::XXX modules that are much more
likely to support "difficult" p
s? Votes?
> David
>
> On Thu, Aug 15, 2013 at 11:37 AM, David Mertens
> wrote:
>>
>> On Thu, Aug 15, 2013 at 9:20 AM, Chris Marshall
>> wrote:
>>>
>>> How about Devel::TCC for the bindings/interface/control part
>>
>>
>> I looked t
How about Devel::TCC for the bindings/interface/control
part and Alien::TCC (of course) for the detection and
installation?
--Chris
On Thu, Aug 15, 2013 at 8:57 AM, David Mertens wrote:
> Hey everyone -
>
> In short, I have written a set of bindings for the library underlying the
> Tiny C Compil
I usually consider the ASperl and Strawberry perl the
native windows perls and, cygwin falls into the list of
unix perls...
Except, for external bindings, where the package
configuration might "check for windows first" and
abort or do some win32 stuff.
This breaks for cygwin since it does run on
On Thu, Aug 8, 2013 at 4:18 PM, Paul LeoNerd wrote:
> On Thu, 8 Aug 2013 21:21:39 +0200
> Leon Timmermans wrote:
>
>> On Thu, Aug 8, 2013 at 9:16 PM, Aristotle Pagaltzis
>> wrote:
>> > Yeah, that’ll work great until the moment someone supports three
>> > OSes. Or supports all OSes except a speci
Agreed, that idea doesn't work. I think the proposed
improved "best effort" docs and FAIL if the Alien::XXX
could not detect or install then configure XXX is a better
approach.
Thanks for the reply,
Chris
On Thu, Aug 8, 2013 at 3:16 PM, Aristotle Pagaltzis wrote:
> * Chris
t they would be more generally useful. I would
appreciate your thoughts or other suggestions.
Thanks,
Chris
-- Forwarded message ------
From: Chris Marshall
Date: Thu, Aug 8, 2013 at 10:26 AM
Subject: Alien modules for PDL
To: pdl-porters
Here are some threads of discussion on the
On Thu, Aug 8, 2013 at 11:55 AM, David Mertens wrote:
> Hey everyone -
>
> Chris drew my attention to this discussion:
>
> On Wed, Aug 7, 2013 at 7:22 PM, Chris Marshall wrote:
>>
>> On Tue, Aug 6, 2013 at 7:23 PM, Michael G Schwern
>> wrote:
>> >
>&
On Thu, Aug 8, 2013 at 7:43 AM, Paul LeoNerd wrote:
> On Thu, 8 Aug 2013 07:00:07 -0400
> Chris Marshall wrote:
>
>> To the original proposal, I've added the
>> following thoughts:
>>
>> - make test in Alien::XXX should be
>> FAIL if it was not
I think the line should be drawn at my
original proposal (document platforms
where the Alien::XXX works or doesn't
work, and add detect/configure/use a
pre-installed XXX rather than have the
default action be a forced install).
The idea is to simplify the process of
writing a useful Alien module f
at Alien::XXX modules stop being 100% solutions
that cannot be uniformly relied upon to modules with a reasonable
expectation of some level or true cross-platform support (where
possible) even if it bails out but tells you how to fix things on
your own.
I appreciate all the discussion and the
On Sun, Aug 4, 2013 at 11:38 AM, Paul LeoNerd wrote:
> On Sun, 4 Aug 2013 11:29:41 -0400
> Chris Marshall wrote:
>
>> > The approach I take with Alien modules is to bundle the upstream
>> > tarball in the dist, and build/install it directly into perl's
>>
Hi Paul, thanks for the reply
On Sun, Aug 4, 2013 at 10:10 AM, Paul LeoNerd wrote:
> On Sun, 7 Jul 2013 17:08:46 -0400
> Chris Marshall wrote:
>
>> The only alternative is to do the actual install
>> process to see if it "just works" or to drill down
>>
All-
I've been looking at some refactoring for the
planned PDL-3.000 release this Summer based
on replacing hand-coded library detection in the
Makefile.PL processing stages by 'use Alien::XXX;'
instead. That sounds good so far.
Then I took a look at various existing Alien::XXX
modules for ideas
I recommend putting a link in the POD to the PDF on
a web site. A 4X increase in the size of the distribution
is a pretty expensive way to publish. How about a short
synopsis in the POD with the link for more detail if
needed---unless, of course, the Marpa::XS is not usable
without reading the PD
31 matches
Mail list logo
