# from David Golden
# on Tuesday 25 July 2006 11:04 am:
>http://ali.as/pita/
>
>I think some progress was made at the YAPC hackathon. Adam would have
>to give a more complete update.
new site http://pitatesting.org/
--
[...proprietary software is better than gpl because...] "There is value
in
Ken Williams wrote:
Hmm. Is there some way that we could test new releases in several
combinations of platform/perl-version/installed-modules environments?
I would LOVE that.
http://ali.as/pita/
I think some progress was made at the YAPC hackathon. Adam would have
to give a more complete
On Jul 22, 2006, at 11:11 AM, Eric Wilhelm wrote:
# from John Peacock
# on Saturday 22 July 2006 05:59 am:
The problem is one of communication and insufficient testing
Hmm. Is there some way that we could test new releases in several
combinations of platform/perl-version/installed-modules
John Peacock <[EMAIL PROTECTED]> writes:
> Perl doesn't work like that (at least not until Perl6 at the
> earliest).
So this is the real fundamental problem. Oh well, we'll have to live
with it for a while...
-- Johan
Johan Vromans wrote:
> My suggestion is, that in that case, it would be better to have perl
> expose the necessary entry point(s) so version can call this entry
> point directly, instead of going the (tedious and error-prone) way of
> cut/paste.
Perl doesn't work like that (at least not until Perl
Nicholas Clark wrote:
>> map { unlink $_ if -f $_ } ('test.c','test.o');
>
> Surely that should be "test$Config{obj_ext}" else it's not going to work
> on VMS (and possibly elsewhere.
Duh! I should be smarter than that (since we still have a VMS in production).
I'll make that change momenta
On Mon, Jul 24, 2006 at 01:39:15PM -0400, John Peacock wrote:
> C) The Makefile.PL that now ships with version.pm deletes the test
> object file prior to writing the Makefile:
>
> map { unlink $_ if -f $_ } ('test.c','test.o');
Surely that should be "test$Config{obj_ext}" else it's not go
On Sun, Jul 23, 2006 at 09:37:00AM -0400, David Golden wrote:
> The approach in Params::Validate (and borrowed for version.pm) uses
> ExtUtils::CBuilder, if installed, and otherwise tries manually against
> the configured CC, rather than make:
>
> > system( "$Config{cc} -o test$Config{obj_ext}
Chris Dolan wrote:
For Perl 5.9.x and (someday) 5.10+:
version.pm XS is part of Perl itself
(this is the definitive implementation of version.pm)
version.pm PP is pointless
For Perl 5.8.x and earlier
version.pm XS == "cut-and-paste" code from Perl 5.9.x
version.pm PP == port of
Chris Dolan <[EMAIL PROTECTED]> writes:
>> Wouldn't it then be a better approach to have Perl expose the
>> necessary entry point(s) so you can use them from XS, instead of
>> having to go the way of cutting/pasting?
>
> This question makes no sense to me.
Then I've probably misphrased my questio
Johan Vromans wrote:
Wouldn't it then be a better approach to have Perl expose the
necessary entry point(s) so you can use them from XS, instead of
having to go the way of cutting/pasting?
Don't ready too much into "cut/paste" in this context. My point was
that the code that exists in vutil/v
David Golden wrote:
I can see that. On the other hand, CPAN.pm doesn't "make clean" so the
blib sticks around. One tiny object file wouldn't really bug me and it
would be cleaned up when the cache is cleaned. But I guess it's better
to clean up if one can. (Assuming -o is portable across mo
On Jul 24, 2006, at 3:05 PM, Johan Vromans wrote:
John Peacock <[EMAIL PROTECTED]> writes:
The file vutil/vutil.c is *exactly* the same code as exists in the
bleadperl/v5.10.0 util.c; indeed, when I fix something in vutil.c, I
literally chop out the associated block in bleadperl/util.c and
rep
John Peacock <[EMAIL PROTECTED]> writes:
> The file vutil/vutil.c is *exactly* the same code as exists in the
> bleadperl/v5.10.0 util.c; indeed, when I fix something in vutil.c, I
> literally chop out the associated block in bleadperl/util.c and
> replace it with my code before generating the dif
Nicholas Clark wrote:
On Sun, Jul 23, 2006 at 09:37:00AM -0400, David Golden wrote:
system( "$Config{cc} -o test$Config{obj_ext} test.c" )
Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
not sure why it isn't just "$Config{cc} test.c", but I'm not very
compiler savvy.
Ken Williams wrote:
I don't really get that - what does "reference implementation" give us?
Does it just mean that if there's a bug in it, we can't fix it? Or that
there's not a complete set of documentation describing its behavior?
I'm using "reference implementation" in the same sense that
Ken Williams <[EMAIL PROTECTED]> writes:
> I don't really get that - what does "reference implementation" give
> us? Does it just mean that if there's a bug in it, we can't fix it?
No, it means that this bug has to be implemented in all conformant
implementations as well.
> Or that there's not
On Jul 22, 2006, at 7:59 AM, John Peacock wrote:
Ron Savage wrote:
I don't know all the inner details, but this M::B and version
dancing gives me the strong impression that something is terribly
wrong here at a fundamental design level.
Clearly something's wrong, but it may not be anything b
On Jul 23, 2006, at 8:10 AM, Chris Dolan wrote:
On Jul 23, 2006, at 8:01 AM, Johan Vromans wrote:
John Peacock <[EMAIL PROTECTED]> writes:
The pure Perl implementation is newer, but no less stable.
So what is the reason to continue the XS version, except maybe as a
separate module for the
Chris Dolan <[EMAIL PROTECTED]> writes:
> As John said yesterday, the XS version is the reference
> implementation and the PP version is a port.
He also said that it is 'as stable', so it is as good as the XS
implementation.
> The XS version is already in core for bleadperl, so the PP version
>
demerphq wrote:
On 7/22/06, David Golden <[EMAIL PROTECTED]> wrote:
2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
Params::Validate), but they do require robust compiler detection across
platforms,
Im a little confused about this one. I can think of a few modules that
prov
On 7/22/06, David Golden <[EMAIL PROTECTED]> wrote:
2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
Params::Validate), but they do require robust compiler detection across
platforms,
Im a little confused about this one. I can think of a few modules that
provide dual implemen
On Jul 23, 2006, at 8:01 AM, Johan Vromans wrote:
John Peacock <[EMAIL PROTECTED]> writes:
The pure Perl implementation is newer, but no less stable.
So what is the reason to continue the XS version, except maybe as a
separate module for the few cases that require speed?
As John said yeste
John Peacock <[EMAIL PROTECTED]> writes:
> The pure Perl implementation is newer, but no less stable.
So what is the reason to continue the XS version, except maybe as a
separate module for the few cases that require speed?
A clarification: when distributing (real) Perl applications to (real)
cu
On Sat, 22 Jul 2006 09:00:10 -0400, David Golden wrote:
Hi David
> All three are specific, well-understood (in hindsight) and have now
> been addressed.
We are probably all aware that many things, including hindsight, and clear in
hindsight :-).
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 23/07/
On Sat, 22 Jul 2006 08:59:13 -0400, John Peacock wrote:
Hi John
> The problem is one of communication and insufficient testing, not
> architectural. I didn't think to test on a machine that didn't have
> *either* M::B or version.pm installed (which is the only case where
> there is any problem).
# from John Peacock
# on Saturday 22 July 2006 05:59 am:
>The problem is one of communication and insufficient testing
Hmm. Is there some way that we could test new releases in several
combinations of platform/perl-version/installed-modules environments?
Seems like somebody should build one of
Johan Vromans wrote:
> Dealing with version numbers is not quite trivial, but should be
> fairly straightforward to deal with. I cannot (and for the time being
> I refuse to) believe that it takes 651 releases (652 at the time I
> write this) to get it right.
Nit - CPAN history has 0.50, 0.63, 0.
Ron Savage wrote:
>> I don't know all the inner details, but this M::B and version
>> dancing gives me the strong impression that something is terribly
>> wrong here at a fundamental design level.
>
> Clearly something's wrong, but it may not be anything big, even though it's a
> sort of show-sto
On Sat, 22 Jul 2006 11:26:29 +0200, Johan Vromans wrote:
Hi Johan
> I know I'm not entitled to say this, and it will make me even more
> unpopular than I already am, but nevertheless I'm not going to
> remain silent.
I fully support your speaking up.
> I don't know all the inner details, but th
John Peacock <[EMAIL PROTECTED]> writes:
> Eric Wilhelm pointed out [...], so I released version-0.651 to fix
> that. Then he pointed out [...] I pointed out [...] Consequently, he
> pointed out [...], so I propose the following patch:
I know I'm not entitled to say this, and it will make me even
Thanks, applied.
-Ken
On Jul 17, 2006, at 7:16 PM, John Peacock wrote:
Eric Wilhelm pointed out that the new Makefile.PL doesn't work if
ExtUtils::CBuild isn't installed, so I released version-0.651 to
fix that. Then
he pointed out that the overloaded numification of version objects
didn
32 matches
Mail list logo
