On 1/22/2012 9:45 PM, David Mertens wrote:
To all -
I've changed the original subject. I hope this doesn't bother anybody too
much.
Subject change is ok, but you dropped the thread
so users don't see the earlier part of this
discussion to which this appears to be a response.
The first:
-------- Original Message --------
Subject: Re: PDL book checking
Date: Sun, 22 Jan 2012 16:18:32 -0500
From: chm <[email protected]>
To: Matthew Kenworthy <[email protected]>
CC: [email protected] <[email protected]>
On 1/22/2012 3:57 PM, Matthew Kenworthy wrote:
I forgot to point out that =ff is just what is
needed to put page breaks at the start of each
chapter...
Ah! Good to know :)
I'm confused. Yes, the plan was to have a PDL::Book
distribution, which, by definition, would include the
PDL::Book.
I thought the ultimate idea was to put PDL::Book into the PDL-2.4.10
tarball, but the discussion about the sizes of the included images nixed
that idea. YOu can revive the diea by having PDL::Book only have text and
image generating scripts. I think that your point is to keep PDL::Book a
separate distribution entirely, which is where our confusion comes in.
OK. There seems to be an enormous amount of
interest in "putting" the PDL Book into the
PDL distribution.
While it _seems_ simple to just add it into
the current "kitchen sink" PDL has, the reality
is that if PDL were split into a core distribution
and a number of other, separate, distributions
corresponding to the external dependencies, we
would be *much* better off:
(1) The core would already be 100% ported since
it is mostly the external libraries and programs
that are difficult to get working consistently
across all platforms.
For example, a win32 PDL still takes
significant guru expertise to do. I *still*
can't do it. Although, if I took the time,
I could follow Rob's instructions and build
it eventually...
We work around that through Rob's generosity
to build and make available up-to-date PPD
versions of PDL CPAN releases, including the
latest developers release.
(2) Code improvement in PDL modules could happen
faster without having to wait for the entire
PDL distribution. By releasing frequent git
snapshots as developers releases, I've been
able to reduce some of the impact of this.
However, the developers releases are even
farther from 1-click installs then the CPAN
official releases.
(3) The full on, kitchen sink version of PDL
could still be bundled up and distributed
as a single distribution rather than the
possibly dicey use of cpan or cpanm to
build all the dependencies correctly.
(4) For similar reasons, having the PDL-Book-0.0.1
distribution works better: more frequent or
needed updates can be made as required, issues
of format generation and image generation will
continue to be worked out, a book isn't the
same thing as on-line help or documentation
(although they could be viewed with the same
utilities),...
Cheers,
Chris
And, I should add, at this point, this is a Good Idea.
The issue of generating the figures occurred to
me when I saw that the full size image looked
fine but that the scaled html image had lines
that were too thin and hard to see. It would
be better to have a separate NxN for HTML and
800x800 for PDF output.
Hmm, I think that good displayable single source images are possible with
HardLW=>5 and HardCH=>2 for illustrations. But that's something for the
release after this upcoming one!
Matt
And the second, additional points:
-------- Original Message --------
Subject: Re: [Perldl] PDL book checking
Date: Mon, 23 Jan 2012 00:10:11 +0100
From: Henning Glawe <[email protected]>
To: [email protected]
On Sun, Jan 22, 2012 at 04:18:32PM -0500, chm wrote:
While it _seems_ simple to just add it into
the current "kitchen sink" PDL has, the reality
is that if PDL were split into a core distribution
and a number of other, separate, distributions
corresponding to the external dependencies, we
would be *much* better off:
(1) The core would already be 100% ported since
[ ... ]
(4) For similar reasons, having the PDL-Book-0.0.1
With my Debian Developer's hat on (those points mainly refer
to the 'bleeding edge' of debian development, i.e.
testing/unstable):
(5) a problem with a single dependency would not kick all of pdl
and all packages it depends on from our testing branch,
which has happened recently due to portability problems with plplot.
(6) Less problems with SONAME transitions, as only the relevant
interface module packages would need to be updated.
(7) Easier/more reliable way to automatically create package
dependency lists (each interface module depends on the
corresponding library packages). As mentioned recently on this
list, the dependency list of debian's pdl package is a bit
long; I have to do the splitting into depends, suggests
and recommends manually, that's maybe why a bit too much
slipped through... this would be a lot easier if we had
a 'core' with minimal external dependencies and interface
distributions.
--
c u
henning
And this reply (in context):
This is a well-worn discussion. The last time this was thoroughly discussed
was on the porters list: see the porters' archives starting from October
31, 2009, and running into November. These are from the days when I spent a
lot of effort stirring the pot, and a bit less at actually writing code.
[Note: November 2009 has one of the largest collection messages in the
archives, and my pot stirring has been bested by no less than the great
Daniel Carrera, whose ability to stir a pot (and get docs and code written)
still impresses me.] I have since repented my lack of code writing and I've
tried hard to focus more on writing code and less on stirring pots. If you
don't believe me, just wait for PDL::Graphics::Prima. :-)
Back in late 2009 when we last discussed this, nearly everybody was in
favor of splitting PDL into multiple pieces. Judd Taylor voiced a
dissenting opinion, stating that PDL needs to have a large collection of
numerical capabilities built-in so that it appeals to new folks. If people
have to install lots of modules to get what they want, they'll just walk
away. He also claimed that the lack of an install-everywhere 2D plotting
library was a big issue. Read his email and others' responses to get a
fuller picture:
http://mailman.jach.hawaii.edu/pipermail//pdl-porters/2009-November/001617.html
These days, I stand by my original statement, that PDL would be best served
split into many smaller pieces. BioPerl underwent a similar transitions a
few years ago, and many major frameworks (Test comes to mind) were built
like this from the ground up, providing a simple core upon which others can
build. We are a Perl technology, and I believe we would do well to embrace
the current trend in Perl modules to provide simpler distributions that
target specific goals.
I see two issues:
1) Quality Assurance. Whenever somebody makes a change to the core, they
run the *whole* test suite. If we split the core, changes made in one
component will not be easily tested against other components. Solutions
include (1) CPAN testers, which should be able to pick out bad interactions
within a few days to a week, and (2) a continuous integration server
specifically for PDL. For the latter, jitterbug, a Perl-based continuous
integration system comes to mind. It would be amazing, it would take time
to set up, and it would cost $$ to host the server unless somebody out
there has a box sitting idle on a static IP. (Lately I have been thinking
about purchasing a $7/month VPS for this very idea, and for hosting the IRC
bot.)
2) Knowing where to find things. If we split things up, we must have
documentation about where to find information about different PDL
capabilities. This is all the more important if users are installing PDL,
and need to know what to install. Installation itself is becoming much
easier with local::lib, perlbrew, and the Alien packages (shout out to Joel
for his recent work on Alien::Base). The current docs are not very tied
together and may not give the user and idea of where (in monolithic PDL)
where to look, but they do have an Index document that knows about all the
installed modules. The solution to this is simple, but hard: write better
docs that make thorough references to what's out there.
I believe that the benefits greatly outweigh the costs, but the greatest
missing piece is commitment by PDL porters and users to make it happen.
Back then, I began working on Module::Build::PDL, but I lost steam when I
was told that M::B::PDL would have to build the entire PDL distribution. I
have since figured out that what I had accomplished with M::B::PDL can be
as easily achieved using Module::Build with well crafted .pm.PL files. My
opinion is now this: if we can't achieve our split of PDL into pieces that
M::B can handle, then the pieces are still too big.
So, here's what I say: let us kvetch! We will move forward with 2.4.10 and
the close follow-up of 2.4.11, but everybody should lay out their thoughts
about splitting up PDL (or not). After the dust has settled, as 2.4.11 is
taking form, those us of who are truly interested can re-read the
discussion and decide how to move forward. In particular, I would *love* to
send out another survey, this time asking about what people want and *how
many hours people are willing to commit to make it happen.*
David
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
