Re: Binary distributions

> On Sun, 29 Jan 2006 15:05:02 -0800, Tyler MacDonald <[EMAIL PROTECTED]> > said: > Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote: >> Did anybody here have played with CPANPLUS::Dist::Deb? >> http://search.cpan.org/dist/CPANPLUS-Dist-Deb/ >> >> Believing its documentation, i

Re: Binary distributions

> On Sun, 29 Jan 2006 17:13:40 -0800, Tyler MacDonald <[EMAIL PROTECTED]> > said: > Andreas J. Koenig <[EMAIL PROTECTED]> wrote: >> FWIW, we're using dh-make-perl to create debian packages from CPAN >> modules. > Andreas, > I've used this tool a few times when a CPAN module w

Re: Module::Install (Was: YAML and Makefile.PL)

Adam Kennedy writes: [Tels writes:] > > if there is a problem with Module::Install, you have to update all > > your dists with the new version > > But if there is a problem with EU::MM or Module::Build, you have to > update every installation in the entire world with the new version. Not neces

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

Adam Kennedy wrote: A testing system should only be sending FAIL reports when it believes it has a platform that is compatible with the needs of the module, but when it tries to install tests fail. So how, then, do I tell the testing system "this module only works on Unix-like filesystems on

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

Luke Closs wrote: I'm somewhat new to the Perl community, so I don't know much history about PPM + perl, but I think PPM is actually a pretty good tool. The history is that Activestate was originally a Windows-only product. Windows users generally don't have compilers, so they needed a way to

Re: Binary distributions

Tels wrote: On Saturday 28 January 2006 08:20, Tyler MacDonald wrote: That is such an incredibly good idea. I've got plenty of bandwidth to burn and I'm willing to set up debian.cpan.org. Of course you must reliaze that, except for pure-perl modules and very controlled environments, binary dist

Re: Binary distributions

On Sat, Jan 28, 2006 at 09:34:09AM -0800, Tyler MacDonald wrote: > > From what I gather, CPANPLUS is a linear package building > system, whereas YACsmoke is a wrapper around that that tries to build as > many packages as is humanly (er, computerly) possible on a system, with the > si

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > Luke Closs wrote: > PPM is only really useful on Windows. It makes sense for it to bundled > with the main Windows port of perl, but not to include it otherwise. I don't know if I buy that. Im assuming that ppm is bundled with all of the AS

Re: [perl #38348] [PATCH] Accept return values via a Continuation

Bob Rogers (via RT) wrote: It seems that Continuation needs the same set_address magic as Exception_Handler in order to return values. Yep. At least as long we don't have better support for creating limited continuations that are able to return some results. There is of course the 'stand

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > Adam Kennedy wrote: > > > A testing system should only be sending FAIL reports when it believes it > > has a platform that is compatible with the needs of the module, but when > > it tries to install tests fail. > > So how, then, do I tell the

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

demerphq wrote: On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: Adam Kennedy wrote: A testing system should only be sending FAIL reports when it believes it has a platform that is compatible with the needs of the module, but when it tries to install tests fail. So how, then, do I tell

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

David Cantrell wrote: Adam Kennedy wrote: A testing system should only be sending FAIL reports when it believes it has a platform that is compatible with the needs of the module, but when it tries to install tests fail. So how, then, do I tell the testing system "this module only works on

Supporting C static storage

Below are some thoughts WRT C static vars and Perl6 INIT blocks. Comments welcome, leo Supporting C static storage There are some related Perl6 features, namely INIT and FIRST closure traits [1], which aren't really covered by Parrot yet. Parrot supports INIT blocks via :immediate, which allows

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

demerphq wrote: On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: So how, then, do I tell the testing system "this module only works on Unix-like filesystems on Unix-like OSes"? Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; My code is as portable as

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

David Golden wrote: Well, the more generalized problem is how to you signal to an automated test that you're bailing out as N/A for whatever reason? For Perl itself, it's easy enough for the smoke test to check if the required version of Perl is available -- and the smoke test is smart enough

Re: Please revert and explain ":non_volatile"

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote: Please revert this change, Done, along with the docs and test changes relating to it. and refrain from checking in user-visible or design-significant changes to the core until I've OK'd them. Had mentioned this to leo, who said it sounded sane, and

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

On Jan 30, 2006, at 10:04 AM, David Cantrell wrote: [...] for example, on OS X, HFS+ is case-preserving but case- insensitive. UFS is case-sensitive. And FAT16 smashes case. And to make matters even worse (better?) Apple added a case-sensitive mode to HFS+ in 10.4. It's not widely used.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

David Cantrell wrote: David Golden wrote: What's a clean, generic mechanism for a distribution to signal "please check this dependency and abort if it's not satisfied"? die("wrong platform, you didn't read the documentation\n") unless( $Config::capabilities{filesystem}{casesensitive} &&

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

* demerphq <[EMAIL PROTECTED]> [2006-01-30 14:50]: >Hopefully it will be something like: > >$I::don't::bother::to::write::portable::code=1; Yeah, those Win32:: modules are really unportable. It sucks. Wink wink, -- Aristotle Pagaltzis //

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

Moin, On Monday 30 January 2006 14:59, David Golden wrote: > demerphq wrote: > > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > >>Adam Kennedy wrote: > >>>A testing system should only be sending FAIL reports when it > >>> believes it has a platform that is compatible with the needs of the

Re: Some perplexities on S06

On Sat, Jan 28, 2006 at 06:30:06PM +0100, dakkar wrote: : Today I was reading S06 from : http://dev.perl.org/perl6/doc/design/syn/S06.html, and I have some : perplexities on what's written there. : : 1) it's written: : : $pair = :when; : doit $pair,1,2,3; # always a positional arg :

Re: Supporting C static storage

Currently, the .global directive for pir is unimplemented. Other than being in the source code for the imcc compiler, it's absent. Is .global intended to truely store to global, or be more like a mutable constant, applicable to only that file(and then perhaps any that .include it). If it

Re: Supporting C static storage

On Mon, Jan 30, 2006 at 03:54:51PM +0100, Leopold Toetsch wrote: > I think, we should use the constant table and allow storing into > the constant table. I don't know the parrot source code well enough to know whether the constant table is static const at the C level. (Or capable of being compile

Re: Some perplexities on S06

On Sat, Jan 28, 2006 at 06:30:06PM +0100, dakkar wrote: : 4) It's written: : :(Conjectural: Within the body you may also use exists on the : parameter name to determine whether it was passed. Maybe this will have : to be restricted to the ? form, unless we're willing to admit that a : para

PARROT_IN_EXTENSION

I think that I must be missing something. In ponie, src/pmc/perl5pmcs.h looks like this: -- /* * !!! DO NOT EDIT THIS FILE !!! * * This file is generated automatically from 'various files' * by /home/nick/P

Re: Supporting C static storage

On Jan 30, 2006, at 22:00, Nicholas Clark wrote: On Mon, Jan 30, 2006 at 03:54:51PM +0100, Leopold Toetsch wrote: I think, we should use the constant table and allow storing into the constant table. I don't know the parrot source code well enough to know whether the constant table is stati

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

In article <[EMAIL PROTECTED]>, demerphq <[EMAIL PROTECTED]> wrote: > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > > Adam Kennedy wrote: > > > A testing system should only be sending FAIL reports when it believes it > > > has a platform that is compatible with the needs of the module,

\c[NAMED UNICODE CHARACTER]?

Is it possible to have it as part of Synopsis 02? It's mentioned variously in A05, E05 and E07 (where it permits a \c[2026] form, but should be spelled \d[2026] nowadays), but is not currently part of any Synopses. Audrey

Re: YAML and Makefile.PL (was various topics)

In article <[EMAIL PROTECTED]>, Adam Kennedy <[EMAIL PROTECTED]> wrote: > > And if there is a problem with Module::Install, you have to update all > > your dists with the new version - solve one problem, create two new > > ones :) > But if there is a problem with EU::MM or Module::Build, you ha

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > demerphq wrote: > > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote: > >>So how, then, do I tell the testing system "this module only works on > >>Unix-like filesystems on Unix-like OSes"? > > Hopefully it will be something like: > > $I::

Re: \c[NAMED UNICODE CHARACTER]?

On Tue, Jan 31, 2006 at 12:15:31AM +0800, Audrey Tang wrote: : Is it possible to have it as part of Synopsis 02? It's mentioned : variously in A05, E05 and E07 (where it permits a \c[2026] form, but : should be spelled \d[2026] nowadays), but is not currently part of any : Synopses. Now reads:

Re: testers.cpan.org out of sync with search.cpan.org?

On 1/27/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote: > Usually this clears up in about a day, but in some cases it's been 3 or 4 > days now and search.cpan.org is telling me that tests have run, but > testers.cpan.org doesn't seem to know anything about them. Sorry, I'll prod testers.cpan.org a

[perl #38371] [BUG] t/op/calling.t is failing (IREGs aren't being cleared)

# New Ticket Created by jerry gay # Please include the string: [perl #38371] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38371 > on platforms sensitive to IREGs with junk data, or on any platform when running `TEST_PROG

Re: [perl #38348] [PATCH] Accept return values via a Continuation

From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 05:48:42 -0800 Bob Rogers (via RT) wrote: >It seems that Continuation needs the same set_address magic as > Exception_Handler in order to return values. Yep. At least as long we don't have better sup

Re: YAML and Makefile.PL (was various topics)

brian d foy wrote: In article <[EMAIL PROTECTED]>, Adam Kennedy <[EMAIL PROTECTED]> wrote: And if there is a problem with Module::Install, you have to update all your dists with the new version - solve one problem, create two new ones :) But if there is a problem with EU::MM or Module::Build

Re: YAML and Makefile.PL (was various topics)

On Monday 30 January 2006 20:40, Adam Kennedy wrote: > Incremental releasing is a toolchain problem. Having to rerelease more than one module and making every one of my users upgrade every module that uses this tool -- not just my one or more modules -- rather than making every one who uses the

Re: YAML and Makefile.PL (was various topics)

chromatic wrote: On Monday 30 January 2006 20:40, Adam Kennedy wrote: Incremental releasing is a toolchain problem. Having to rerelease more than one module and making every one of my users upgrade every module that uses this tool -- not just my one or more modules -- rather than making e

Re: YAML and Makefile.PL (was various topics)

chromatic wrote: On Monday 30 January 2006 20:40, Adam Kennedy wrote: Incremental releasing is a toolchain problem. Having to rerelease more than one module and making every one of my users upgrade every module that uses this tool -- not just my one or more modules -- rather than making eve

Re: YAML and Makefile.PL (was various topics)

* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]: >There isn't really any very good way (that I can see at least) >to ensure that an end-user gets an update to EUMM/MB, just the >module packager. So maybe that is the fundamental problem that should be addressed? Regards, -- Aristotle Pagalt

Re: YAML and Makefile.PL (was various topics)

On Monday 30 January 2006 23:15, A. Pagaltzis wrote: > * Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]: > >There isn't really any very good way (that I can see at least) > >to ensure that an end-user gets an update to EUMM/MB, just the > >module packager. > So maybe that is the fundamental

Re: YAML and Makefile.PL (was various topics)

* chromatic <[EMAIL PROTECTED]> [2006-01-31 08:20]: >Perhaps CPAN/CPANPLUS should check for updates? Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an equivalent?) Regards, -- Aristotle Pagaltzis //