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
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
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
Thanks! I appreciate all the suggestions. --Chris
On Sat, Dec 13, 2014 at 12:56 PM, Karen Etheridge ka...@froods.org 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
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
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
functionality
by hand.
Now automate that.
--Chris
On Thu, Jan 9, 2014 at 2:25 PM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
On Mon, 6 Jan 2014 20:02:31 -0500
Chris Marshall devel.chm...@gmail.com wrote:
pkg-config has a standard format. I see no reason why
the Alien::unibilium could
On Mon, Jan 6, 2014 at 5:54 PM, Chris Marshall devel.chm...@gmail.com wrote:
On Mon, Jan 6, 2014 at 5:32 PM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
...
This surely limits Alien wrappings to only being useful for C libraries
that don't themselves have other C-level dependencies
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
On Mon, Jan 6, 2014 at 5:32 PM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
On Mon, 6 Jan 2014 17:21:04 -0500
Chris Marshall devel.chm...@gmail.com wrote:
Hi Paul-
I'm a bit confused by the discussion so far. Alien modules are to
provide external dependencies wrapped up for perl
On Mon, Jan 6, 2014 at 6:43 PM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
On Mon, 6 Jan 2014 17:54:56 -0500
Chris Marshall devel.chm...@gmail.com wrote:
Again, Alien modules are for *perl* to access external dependencies
and not for other external dependencies to access eachother
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
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
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
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
.
Thoughts? Votes?
David
On Thu, Aug 15, 2013 at 11:37 AM, David Mertens dcmertens.p...@gmail.com
wrote:
On Thu, Aug 15, 2013 at 9:20 AM, Chris Marshall devel.chm...@gmail.com
wrote:
How about Devel::TCC for the bindings/interface/control part
I looked through other modules with the Devel
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
On Thu, Aug 8, 2013 at 7:43 AM, Paul LeoNerd leon...@leonerd.org.uk wrote:
On Thu, 8 Aug 2013 07:00:07 -0400
Chris Marshall devel.chm...@gmail.com wrote:
To the original proposal, I've added the
following thoughts:
- make test in Alien::XXX should be
FAIL if it was not possible to either
On Thu, Aug 8, 2013 at 11:55 AM, David Mertens dcmertens.p...@gmail.com 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 schw...@pobox.com
wrote:
I see two distinct
generally useful. I would
appreciate your thoughts or other suggestions.
Thanks,
Chris
-- Forwarded message --
From: Chris Marshall devel.chm...@gmail.com
Date: Thu, Aug 8, 2013 at 10:26 AM
Subject: Alien modules for PDL
To: pdl-porters pdl-port...@jach.hawaii.edu
Here are some
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 pagalt...@gmx.de wrote:
* Chris
and the abore response collects
the key results as I see them into a more specific plan for
updating the Alien manifesto.
--Chris
That's my thoughts.
On Sat, Aug 3, 2013 at 10:05 AM, Chris Marshall devel.chm...@gmail.com
wrote:
All-
I'm looking for feedback on a post from last month
Hi Paul, thanks for the reply
On Sun, Aug 4, 2013 at 10:10 AM, Paul LeoNerd leon...@leonerd.org.uk wrote:
On Sun, 7 Jul 2013 17:08:46 -0400
Chris Marshall devel.chm...@gmail.com wrote:
The only alternative is to do the actual install
process to see if it just works or to drill down
On Sun, Aug 4, 2013 at 11:38 AM, Paul LeoNerd leon...@leonerd.org.uk wrote:
On Sun, 4 Aug 2013 11:29:41 -0400
Chris Marshall devel.chm...@gmail.com 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
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
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
27 matches
Mail list logo
