module-build-general — General discussion about Module::Build project

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5891 - in Module-Build/trunk: . lib/Module/Build

[Ken W. <ke...@ma...>]

On Apr 11, 2006, at 6:46 PM, Randy W. Sims wrote:

> Ken Williams wrote:
>> Hey,
>> I wonder whether we should check for executability with "-x $file"  
>> rather than "(stat $file)[2] & 0111".  Besides being simpler, it  
>> seems like it might DTRT on more platforms, where stat values  
>> might be nontrustworthy.
>
> You mean like so:
>
>  $mode = 0444 | ( -x $file ? 0111 : 0 );

Yup, I'll make the change.

  -Ken

[Module::Build] [Fwd: Smoke [5.9.4] 27752 FAIL(X) AIX 4.3.3.0/ML11 (PPC/1 cpu)]

[Randy W. S. <ml...@th...>]

The failure below has nothing to do with Module::Build, but we are 
leaving some files behind on AIX. I think, looking at 
ExtUtils::MkSymlists, that aix is the only place where these are created.

Does this cleanup patch look correct? I don't have AIX to test on; but 
if it looks okay, maybe we can get someone to try it out?

Randy.


-------- Original Message --------
Subject: Smoke [5.9.4] 27752 FAIL(X) AIX 4.3.3.0/ML11 (PPC/1 cpu)
Date: Tue, 11 Apr 2006 12:32 +0200
From: h.m...@xs... ("H.Merijn Brand")
To: smo...@pe...
Newsgroups: perl.daily-build.reports

Automated smoke report for 5.9.4 patch 27752
i2: PPC_604e (PPC/1 cpu)
     on        AIX - 4.3.3.0/ML11
     using     gcc version 3.4.4
     smoketime 18 hours 52 minutes (average 2 hours 21 minutes)

Summary: FAIL(X)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:       - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

    27752     Configuration (common) -Dcc=gcc
----------- ---------------------------------------------------------
O X O O
O O O O     -Duse64bitint
O O O O     -Duseithreads
O O O O     -Duseithreads -Duse64bitint
| | | +----- PERLIO = perlio -DDEBUGGING
| | +------- PERLIO = stdio  -DDEBUGGING
| +--------- PERLIO = perlio
+----------- PERLIO = stdio

Locally applied patches:
     SMOKE27752

Failures: (common-args) -Dcc=gcc
[perlio]
Inconsistent test results (between TEST and harness):
     ../ext/Time/HiRes/t/HiRes.t.............FAILED at test 17

MANIFEST did not declare 'lib/ExtUtils/CBuilder/compilet.exp'
MANIFEST did not declare 'lib/ExtUtils/CBuilder/compilet.exp_old'
MANIFEST did not declare 'lib/ExtUtils/ParseXS/t/XSTest.exp'
MANIFEST did not declare 'lib/ExtUtils/ParseXS/t/XSTest.exp_old'
MANIFEST did not declare 'lib/ExtUtils/ParseXS/t/compilet.exp'
MANIFEST did not declare 'lib/ExtUtils/ParseXS/t/compilet.exp_old'
MANIFEST did not declare 'patchlevel.bak'
MANIFEST did not declare 'rm.sh'
MANIFEST did not declare 'rmf.sh'
MANIFEST did not declare 't/compilet.exp'
MANIFEST did not declare 't/compilet.exp_old'

Re: [Module::Build] .modulebuildrc documentation out of sync with code

[David G. <da...@hy...>]

Randy W. Sims wrote:
>>> Instead of search for the first valid "HOME" directory, we should 
>>> probably be looking for the first one that contains the file we need 
>>> since all of the directories usually exist.
>>
>> Agreed.
> 
> Does the attached patch resolve this issue?

 From visual inspection, that looks workable.

Regards,
David Golden

Re: [Module::Build] .modulebuildrc documentation out of sync with code

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> 
> On Apr 6, 2006, at 1:21 PM, Randy W. Sims wrote:
> 
>> David Golden wrote:
>>> I posted this to RT, but I'll copy here as well:
>>> Documentation for the location of .modulebuildrc says .modulebuildrc 
>>> should be placed in $ENV{HOME}, but the code actually searches the 
>>> following environment variables: APPDATA HOME USERPROFILE WINDIR 
>>> SYS$LOGIN.
>>> This is particularly confusing because HOME isn't listed first, so a
>>> .modulebuildrc file place in $ENV{HOME} just mysteriously fails to work
>>> on Win32 where $ENV{APPDATA} exists.
>>
>> Instead of search for the first valid "HOME" directory, we should 
>> probably be looking for the first one that contains the file we need 
>> since all of the directories usually exist.
> 
> Agreed.

Does the attached patch resolve this issue?

Randy.

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5891 - in Module-Build/trunk: . lib/Module/Build

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> Hey,
> 
> I wonder whether we should check for executability with "-x $file" 
> rather than "(stat $file)[2] & 0111".  Besides being simpler, it seems 
> like it might DTRT on more platforms, where stat values might be 
> nontrustworthy.

You mean like so:

  $mode = 0444 | ( -x $file ? 0111 : 0 );

Yeah, that probably is clearer.

Randy.

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 11, 2006, at 15:32, Randy W. Sims wrote:

> Any ideas on how to best abbreviate  
> 'yes_i_know_default_isnt_in_options'?
>
> allow_nonoption_default
> allow_odd_default

nonoption_default_ok?

> I'm going to try my best to get this one wrapped up and committed  
> tonight, possibly including some of the mentioned extensions.

Cool.

David

[Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5891 - in Module-Build/trunk: . lib/Module/Build

[Ken W. <ke...@ma...>]

Hey,

I wonder whether we should check for executability with "-x $file"  
rather than "(stat $file)[2] & 0111".  Besides being simpler, it  
seems like it might DTRT on more platforms, where stat values might  
be nontrustworthy.

  -Ken

On Apr 11, 2006, at 3:30 AM, ra...@cv... wrote:

> ====================================================================== 
> ========
> --- Module-Build/trunk/lib/Module/Build/Base.pm	(original)
> +++ Module-Build/trunk/lib/Module/Build/Base.pm	Tue Apr 11 01:30:57  
> 2006
> @@ -3933,12 +3933,10 @@
>
>    $self->log_info("$file -> $to_path\n") if $args{verbose};
>    File::Copy::copy($file, $to_path) or die "Can't copy('$file',  
> '$to_path'): $!";
> -  # preserve mode & timestamps; copied from  
> ExtUtils::Install::pm_to_blib
> -  my($mode, $atime, $mtime) = (stat $file)[2,8,9];
> -  my $mtime_adj = ($self->os_type eq 'VMS') ? 1 : 0;
> -  utime($atime, $mtime + $mtime_adj, $to_path);
> +  # mode is read-only + (executable if source is executable)
> +  my $mode = (stat $file)[2];
>    $mode = 0444 | ( $mode & 0111 ? 0111 : 0 );
> -  chmod($mode, $to_path);
> +  chmod( $mode, $to_path );
>
>    return $to_path;
>  }

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 11, 2006, at 02:23, Randy W. Sims wrote:
> 
>> Another options would be to require the user to flag the default if it 
>> is not in the options list. In effect, the user must declare she knows 
>> the string entered is not in the options and that she knows exactly 
>> what she's doing.
> 
> Yeah, that'd be okay.
> 
>> $answer = Prompter->ask(
>>     prompt  => "What is your user name?\n",
>>     default => '!guest',
>> );
>>
>> (The first character of the default string is an exclamation mark.)
> 
> Why use a mini-language? Why not just another parameter?
> 
>   yes_i_know_default_isnt_in_options => 1,

Ok, I think I'm having one of those "what was I thinking (or drinking)?" 
moments. Yep, feeling rather foolish now.

Any ideas on how to best abbreviate 'yes_i_know_default_isnt_in_options'?

allow_nonoption_default
allow_odd_default

I'm going to try my best to get this one wrapped up and committed 
tonight, possibly including some of the mentioned extensions.

Randy.

[Module::Build] Re: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Nick Ing-S. <ni...@in...>]

Demerphq <dem...@gm...> writes:
>On 4/9/06, Rafael Garcia-Suarez <rga...@gm...> wrote:
>> On 09/04/06, demerphq <dem...@gm...> wrote:
>> > Notable changes are better Win32 support for in-use files, and support
>> > for an INSTALL.SKIP file to prevent stuff being installed that
>> > shouldnt be. This should be particularly useful for folks that use SVN
>> > and would like to be able to do an install directly from their working
>> > directory without install svn directories into their perl module tree.
>>
>> How does the purpose of this file differ from the one of MANIFEST.SKIP ?
>
>ExtUtils::Install::install() pays no attention to MANIFEST.SKIP and never =
has.

And shouldn't.

In many cases they are inverses!

It is quite reasonable to have something in MANIFEST.SKIP because the=20
build process generates it e.g. exclude Foo when there is a Foo.PL that bui=
lds
it. When you install though you may want to install generated Foo but NOT=
=20
Foo.PL (and later can look like something to install Foo.pl on case ignorin=
g=20
systems.)


>
>MANIFEST.SKIP is to prevent stuff from getting added to MANIFEST when
>you do something like
>
>  make manifest
>
>which is a distinct process from installation.Installation is
>performed by doing stuff like moving all files under one path to
>another path, INSTALL.SKIP allows you to prevent specific filetypes or
>files from being included in such a process.
>
>Examples uses for this could be on Win32 to filter out the
>installation of XS/C compilation byproduct like *.pdb. I personally
>use it for stuff like preventing .bak from getting installed and for
>keeping .svn out of my site/lib tree.
>
>In ex-ExtUtils-Install-1.3702 I made the mistake of letting
>MANIFEST.SKIP be used when no INSTALL.SKIP was present but this
>prevented some packages from installing as their MANIFEST.SKIP
>contained the patter /blib/ which as it is in most install source
>paths meant that nothing would get installed at all. 1.38 fixes this
>problem by using INSTALL.SKIP only, but allows
>EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic
>use.
>
>Cheers,
>Yves

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 11, 2006, at 02:23, Randy W. Sims wrote:

> The only bad thing is open ended questions get a little more  
> verbose. Instead of:
>
> $answer = Prompter->ask(
>     prompt  => "What is your user name?\n",
>     default => 'guest',
> );
>
> You would have to say:
>
> $answer = Prompter->ask(
>     prompt  => "What is your user name?\n",
>     options => ['/guest/'],
>     default => 'guest',
> );

That seems silly. Why force them to use options if it's open-ended?

> Another options would be to require the user to flag the default if  
> it is not in the options list. In effect, the user must declare she  
> knows the string entered is not in the options and that she knows  
> exactly what she's doing.

Yeah, that'd be okay.

> $answer = Prompter->ask(
>     prompt  => "What is your user name?\n",
>     default => '!guest',
> );
>
> (The first character of the default string is an exclamation mark.)

Why use a mini-language? Why not just another parameter?

   yes_i_know_default_isnt_in_options => 1,

?

Best,

David

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

Randy W. Sims wrote:
> Ken Williams wrote:
> 
>> I think this is a decent direction.  I only have a couple of  
>> concerns: one, I do think that the default needs to be one of the  
>> options in an option list, or else people are just going to make too  
>> many mistakes.  
> 
> 
> I debated that decision for a while. The reason I allowed it was that 
> when running an unattended build, none of the choices may be a 
> reasonable default. In that case the default can be set to an empty 
> string or something that make sense to indicate that no choice was made.
> 
> Note also that 'default' may be set to an empty string or to any value, 
> including undef as long as something is passed in.
> 
> One alternative I can think of:
> 
> $answer = Prompter->ask(
>     prompt  => "What is your favorite programming language?\n",
>     options => [qw(Perl Ruby Lua Python C C++ /unknown/)],
>     default => 'unknown',
> );
> 
> Another element is added to 'options' enclosed between slashes (or 
> something). Such elements would not be show when options are displayed. 
> Then default can be set to the "invisible" option.

The only bad thing is open ended questions get a little more verbose. 
Instead of:

$answer = Prompter->ask(
     prompt  => "What is your user name?\n",
     default => 'guest',
);

You would have to say:

$answer = Prompter->ask(
     prompt  => "What is your user name?\n",
     options => ['/guest/'],
     default => 'guest',
);

Another options would be to require the user to flag the default if it 
is not in the options list. In effect, the user must declare she knows 
the string entered is not in the options and that she knows exactly what 
she's doing.

$answer = Prompter->ask(
     prompt  => "What is your user name?\n",
     default => '!guest',
);

(The first character of the default string is an exclamation mark.)

Opinions?

Randy.

Re: [Module::Build] Wrapup: Are there any open issues I haven't recently addressed?

[Randy W. S. <ml...@th...>]

Yitzchak Scott-Thoennes wrote:
> On Sun, Apr 09, 2006 at 12:20:27PM -0400, Randy W. Sims wrote:
> 
>>After losing my notes, I'm at a little bit of a disadvantage.
>>
>>If there are any open issues that I haven't responded to in the last few 
>>days or that are not already logged in RT, please let me know.
> 
> 
> Don't know if this is the kind of thing you mean, but you didn't weigh
> in on this:

Yes, thanks. I'll probably put this on the list for after 0.28. This 
goes with a class of issues I had wanted to look at at some point in the 
future regarding all files that are generated. For example, should 
META.yml and README (if auto-generated) be created only in the 
'distdir', not generated in the root of the build?

Randy.

> On Mon, Jan 23, 2006 at 07:49:44PM -0600, Ken Williams wrote:
> 
>>On Jan 23, 2006, at 6:43 AM, Yitzchak Scott-Thoennes wrote:
>>
>>
>>>I raised this question once before, in particular about Module::Build
>>>itself.  If a module only has auto_features, not features or
>>>config_data, would it cause any harm to have the ConfigData module
>>>built at the time of distmeta and included in the distribution?
>>
>>Hmm, I never thought about it in exactly those terms before.  I can't
>>think of any problem myself.  I suppose you'd get different results
>>just because the version of M::B that builds the ConfigData module is
>>going to be the one on the author's machine, not the user's, but that's
>>probably not a big deal (or perhaps it's even mildly desirable).
>>
>> -Ken

Re: [Module::Build] Preserving files' executable bits, once more

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> 
> On Apr 10, 2006, at 2:04 AM, Randy W. Sims wrote:
> 
>> Ken Williams wrote:
>>
>>> On Apr 8, 2006, at 11:17 PM, Randy W. Sims wrote:
>>>
>>>>
>>>> Borrowing code from ExtUtils::Install::install() and ::pm_to_blib  
>>>> (), the copy_if_modified() method now preserves file mode and   
>>>> timestamps.
>>>
>>> Sounds good to preserve mode, but I'm not sure we want to  preserve  
>>> timestamps.  Seems like the timestamp can be a useful  indicator of  
>>> when a file got updated.
>>
>>
>> Hmm, I hadn't really thought too much about it. I was copying the  
>> behavior of MakeMaker via ExtUtils::Install, basically copying the  
>> code verbatim from there. I'm not sure too many people would argue  it 
>> either way though.
> 
> 
> Ordinarily I'd defer to the old EU::I behavior too, but it doesn't  make 
> much sense to me in this case.  If you preserve the timestamp  
> blib->install, you get an essentially meaningless timestamp.  If you  
> also preserve lib->blib then you get a potentially dangerous  timestamp, 
> where you could replace files with things that look older.

Ok. I've reverted to only preserving the executable bit of the mode.

Randy

[Module::Build] moleskine pictures

[David G. <da...@hy...>]

OK, I'll shut up about this now.  Here's some grainy pics from my Treo 
camera: http://www.dagolden.com/files/moleskine/

David Golden

Re: [Module::Build] What to do? What to do?

[David G. <da...@hy...>]

demerphq wrote:
> On 4/10/06, Ken Williams <ke...@ma...> wrote:
>> That's pretty awesome, thanks for mentioning it.  I've been in the
>> market for a pocket-sized blank book for about 2 years, but I haven't
>> found one I like.  I'm actually looking for one about half the size
>> of the Moleskine ones (about 5cm x 7cm) with a nice non-spiral
>> binding for my *front* pocket.  But I bought the 13cm x 21cm one for
>> notes for a probability study group I'm leading at work.
>>
>> I might have to join http://www.mnbookarts.org/ and make my own small
>> book. =)
> 
> I too got my first Moleskine this weekend. Actually my GF and I bought several.
> 
> Thanks David. :-)

Eeek.  Sorry for perpetuating this way-off-topic thread, but here's a 
tip on using it:

On advice of my friend -- and it works -- if you haven't written in it 
yet, reserve the first 8 pages as a table of contents.  I number 1-25, 
26-50, etc. up to 192.  As I add stuff, I number and date pages in the 
top corner, add a title on top and make a note in the TOC.  It makes it 
really easy to find stuff later.  Maybe I'll post a picture somewhere.

And make sure you use a waterproof pen!  (I like the Uniball Deluxe 
Micro -- the flat clip slips perfectly into the binding for easy storage 
and ready access.)

Regards,
David Golden

Re: [Module::Build] What to do? What to do?

[Jaap K. <j.g...@st...>]

Nadim Khemir wrote:
.. 8< ..
> I'm having a mail discussion with Jaap and he's definitely into making zIm 
> better. He like the idea of having a the possibility to have an on line/off 
> line mode.
> 
> Drop him a line, it's always nice to know when other use your software or want 
> to make it better (you're all welcome to try my build system by the way ;)
. 8< ..

Already read the thread, I'm a long time sleeper on this list :)

Bit off topic on this list so if anyone has suggestions for improvement 
(or just installation trouble) please mail me personally.

-- Jaap Karssenberg <pa...@cp...>

P.S. Johan maybe see you at A'dam.pm sometime this spring.

Re: [Module::Build] What to do? What to do?

[Eric W. <scr...@gm...>]

# from Ken Williams
# on Monday 10 April 2006 10:08 am:

>The only reservation I'd have about a wiki would be that it would =A0
>dilute the mailing list and RT, so that now there'd be three places =A0
>to look instead of two. =A0But that may not be a very serious problem =A0
>if it brings tangible benefits. =A0And it would also be nice to let =A0
>people use the wiki for cookbook-like postings.

Maybe BP is heading in the direction of integrating these three forums=20
with Jifty?  I think they each serve a particular purpose.

  RT - bugs and coherent (i.e. with tests or patches) feature requests
  ML - ongoing discussions
  Wiki - persistent, somewhat organized, collaborative store of data

Most people are comfortable with their existing mail client and most of=20
those clients have the "offline mode" issue solved (sorry google, gmail=20
is not the way of the future.)

The "everybody has a browser" syndrome doesn't really cut it for me. =20
IMO, most BUI interfaces are somehow crippled compared to what can be=20
done with a desktop client.  Besides the obvious limitation of an=20
offline mode, the fact is that javascript just won't get you *good*=20
cross-browser keyboard shortcuts.  Also, expecting the data to be on=20
the server makes it difficult for anyone to really try a new idea.  I=20
guess you can say I'm holding out for web 3.0 where we realize that=20
network-connected desktop clients are a good thing :-)

To come to a point, maybe something like zim could handle the RT/Wiki=20
aspects.  What's needed is distributed backends to RT and a wiki.  To=20
me, that says that both need to cut ties to the SQL DB, but that's just=20
a guess at a low-level detail.

What should the M::B team do in the meantime?

=2D-Eric
=2D-=20
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] What to do? What to do?

[demerphq <dem...@gm...>]

On 4/10/06, Ken Williams <ke...@ma...> wrote:
>
> On Apr 7, 2006, at 11:12 PM, David Golden wrote:
>
> > I also keep a Moleskine square-ruled pocket notebook (http://
> > www.moleskine.co.uk/styles/) for more random jottings.  I wind up
> > doing a lot of brainstorming on the subway and use that to jot
> > ideas down.  A friend turned me onto it as a gift and I was
> > skeptical at first, because I've never been one to keep a journal,
> > but it's small enough to fit in the back pocket of jeans or a
> > jacket pocket.  I get my replacements at Barnes & Noble.  Many of
> > my recent modules (Class::InsideOut, File::pushd, ToolSet) were
> > pretty much sketched out in first-draft form in it on the subway
> > earlier this year.
>
> That's pretty awesome, thanks for mentioning it.  I've been in the
> market for a pocket-sized blank book for about 2 years, but I haven't
> found one I like.  I'm actually looking for one about half the size
> of the Moleskine ones (about 5cm x 7cm) with a nice non-spiral
> binding for my *front* pocket.  But I bought the 13cm x 21cm one for
> notes for a probability study group I'm leading at work.
>
> I might have to join http://www.mnbookarts.org/ and make my own small
> book. =3D)

I too got my first Moleskine this weekend. Actually my GF and I bought seve=
ral.

Thanks David. :-)

Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] What to do? What to do?

[Ken W. <ke...@ma...>]

On Apr 7, 2006, at 7:55 PM, Randy W. Sims wrote:

> Anyway, what I was wondering is would it make sense to set up a  
> tiny little wiki or something that could be used as a developer's  
> notebook? It could be private or public, but I'll warn that some  
> things I note down are best ignored. It would be nice to have it  
> where others can review, notably Ken, so they can comment on items  
> or leave answers to some of the questions I jot down that I haven't  
> had a chance to look up.

As for M::B, my usual M.O. is to use the "read" status flag on my  
inbox, and the tickets in RT, as my issue list.  That means things  
slip through the cracks when I accidentally change my mailbox flags  
and don't respond, or don't solve the requested issue.  Luckily that  
never happens in RT, but then I have to go look at the RT queue...

My actual dream in this area is to develop an "argumentative  
framework" system, which people could use to explicitly structure a  
conversation about issues that are open for discussion among a group  
of people.  But my chances of getting that built anytime soon are  
approximately nil. =)

The only reservation I'd have about a wiki would be that it would  
dilute the mailing list and RT, so that now there'd be three places  
to look instead of two.  But that may not be a very serious problem  
if it brings tangible benefits.  And it would also be nice to let  
people use the wiki for cookbook-like postings.

  -Ken

Re: [Module::Build] What to do? What to do?

[Nadim K. <na...@kh...>]

On Monday 10 April 2006 17.05, Johan Vromans wrote:
> > tuxcards: http://www.tuxcards.de/
>
> Doesn't compile.
the attach screenshot says otherwise

> > knowit: http://knowit.sourceforge.net/index.html
> 404
Sorry: http://knowit.sourceforge.net/

>
> > and last but absolutely not least, zim, the desktop wiki:
> > http://zoidberg.student.utwente.nl/zim/docs/zim/faq.html
>
> Being a Perl addict, this is the perfect answer.
> (And it uses Module::Build for building, nice...)
I'm having a mail discussion with Jaap and he's definitely into making zIm 
better. He like the idea of having a the possibility to have an on line/off 
line mode.

Drop him a line, it's always nice to know when other use your software or want 
to make it better (you're all welcome to try my build system by the way ;)


> Thanks for the suggestions.
welcome, Nadim.

Re: [Module::Build] What to do? What to do?

[Ken W. <ke...@ma...>]

On Apr 7, 2006, at 11:12 PM, David Golden wrote:

> I also keep a Moleskine square-ruled pocket notebook (http:// 
> www.moleskine.co.uk/styles/) for more random jottings.  I wind up  
> doing a lot of brainstorming on the subway and use that to jot  
> ideas down.  A friend turned me onto it as a gift and I was  
> skeptical at first, because I've never been one to keep a journal,  
> but it's small enough to fit in the back pocket of jeans or a  
> jacket pocket.  I get my replacements at Barnes & Noble.  Many of  
> my recent modules (Class::InsideOut, File::pushd, ToolSet) were  
> pretty much sketched out in first-draft form in it on the subway  
> earlier this year.

That's pretty awesome, thanks for mentioning it.  I've been in the  
market for a pocket-sized blank book for about 2 years, but I haven't  
found one I like.  I'm actually looking for one about half the size  
of the Moleskine ones (about 5cm x 7cm) with a nice non-spiral  
binding for my *front* pocket.  But I bought the 13cm x 21cm one for  
notes for a probability study group I'm leading at work.

I might have to join http://www.mnbookarts.org/ and make my own small  
book. =)

  -Ken

Re: [Module::Build] What to do? What to do?

[Julian M. <ju...@me...>]

Johan Vromans wrote:
> Nadim Khemir <na...@kh...> writes:
> > knowit: http://knowit.sourceforge.net/index.html
>
> 404

Have you tried omitting the "/index.html" part?

Re: [Module::Build] What to do? What to do?

[Johan V. <jvr...@sq...>]

Nadim Khemir <na...@kh...> writes:

> there is 'basket': http://basket.kde.org/

Cute.

> tuxcards: http://www.tuxcards.de/

Doesn't compile.

> knowit: http://knowit.sourceforge.net/index.html

404

> and last but absolutely not least, zim, the desktop wiki: 
> http://zoidberg.student.utwente.nl/zim/docs/zim/faq.html

Being a Perl addict, this is the perfect answer.
(And it uses Module::Build for building, nice...)

Thanks for the suggestions.

-- Johan

Re: [Module::Build] Capturing test output to please CPANPLUS

[Ken W. <ke...@ma...>]

On Apr 10, 2006, at 1:46 AM, Randy W. Sims wrote:

> Randy W. Sims wrote:
>> Will something like this work for a temporary solution that we can  
>> maybe figure out how to extend in the future to always capture  
>> output?
>
> Regarding Ticket #9793 [1]
>
> Scratch that. I don't really like my previous solution. I'm not  
> sure Module::Build needs to be responsible for capturing output; I  
> can't really see any benifit. Is there a reason CPANPLUS (or  
> CPANPLUS::Dist::Build) can't do this, like below (borrowing again  
> from Jos' patch), or are there other issues I'm not aware of?

Probably as much as possible should go in CPP:D:Build, unless there  
are aspects of it that would also be nice to have in the core, and  
they wouldn't generate too much clutter.

In general I'm leery of messing with filehandles too much in the  
core, because the people can't do their own messing if they want to.

  -Ken

Re: [Module::Build] Preserving files' executable bits, once more

[Ken W. <ke...@ma...>]

On Apr 10, 2006, at 2:04 AM, Randy W. Sims wrote:

> Ken Williams wrote:
>> On Apr 8, 2006, at 11:17 PM, Randy W. Sims wrote:
>>>
>>> Borrowing code from ExtUtils::Install::install() and ::pm_to_blib  
>>> (), the copy_if_modified() method now preserves file mode and   
>>> timestamps.
>> Sounds good to preserve mode, but I'm not sure we want to  
>> preserve  timestamps.  Seems like the timestamp can be a useful  
>> indicator of  when a file got updated.
>
> Hmm, I hadn't really thought too much about it. I was copying the  
> behavior of MakeMaker via ExtUtils::Install, basically copying the  
> code verbatim from there. I'm not sure too many people would argue  
> it either way though.

Ordinarily I'd defer to the old EU::I behavior too, but it doesn't  
make much sense to me in this case.  If you preserve the timestamp  
blib->install, you get an essentially meaningless timestamp.  If you  
also preserve lib->blib then you get a potentially dangerous  
timestamp, where you could replace files with things that look older.

  -Ken