On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the
On Thu, 2005-11-10 at 20:51 -0800, Jerry Gay via RT wrote:
> i have a sneaking suspicion that this test no longer fails, but there
> are no smoke reports for ppc-linux for me to verify. is there someone
> with that cpu/arch combo who can produce a test result to either prove
> or disprove my claim
Hi there,
I'd like to change where print output and warnings and errors go within
a section of PIR code, like you can change them in C and Perl by closing
and reopening the file descriptor or localizing the typeglob,
respectively.
This is important for the pure-PIR Parrot::Test.
I've looked at t
On Mon, 2005-11-14 at 14:02 -0500, Ivan Tubert-Brohman wrote:
> Hey, this gives me an idea! Let's also add
> released_while_not_under_the_influence. Authors could be required to
> pass a breathalyser test to make sure that they are not drunk while
> uploading to the PAUSE. I'm sure that the inc
On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:
> Yes, I can see that. I could actually have dropped Test::Differences
> "eq_or_diff" and just used the "is_deeply" function from Test::More,
> but when working with large data structures, there's just no comparison
> between the two. I suppose I co
On Tue, 2005-11-15 at 09:22 +1100, Adam Kennedy wrote:
> The question is, what level of deps is "crazy" for something that they
> don't actually need on their computer permanently but only need for 2
> seconds to install something of yours.
I sleep pretty well at night refusing to support peopl
On Tue, 2005-11-15 at 15:23 -0600, Chris Dolan wrote:
> After reading some of the insightful comments posted on my blog, I've
> been convinced that the private tests should be included in the CPAN
> distribution, but disabled in some way (perhaps via a file extension
> other than .t?). That
On Tue, 2005-11-15 at 22:33 -0600, Chris Dolan wrote:
> Beware that M::B has a recursive mode for finding tests. It's set by
> the author, so you should be safe in this case, but it's a point
> worth remembering.
I haven't looked at the code again just now, but wouldn't overriding
find_test_
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote:
> This is a very valid concern, but the problem will not arise
> unless people start mixing these two styles --- something
> which is very obviously not a good idea.
That doesn't mean that people will avoid it, by accident or on purpose.
I
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote:
> Yet you have the choice of where to put your braces, even
> though the braces don't lend themselves to different tasks
> depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of braces
On Sat, 2005-11-19 at 19:31 +0100, Bernhard Schmalhofer wrote:
> Also Punie.pm Python.pm Tcl.pm should be moved from lib/Parrot/Test
> to their respective dir in 'languages'.
How would the library loads in the test files look if this were the
case?
-- c
On Sat, 2005-11-19 at 21:05 +0100, Bernhard Schmalhofer wrote:
> Setting the Perl5 search path can be handled with FindBin. See for
> example languages/m4/t/basic/001_comletely_empty.t:
>
> use FindBin;
> use lib "$FindBin::Bin/../../lib", "$FindBin::Bin/../../../../lib";
That's fairly ugly
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote:
> But my argument was: whenever you
> start introspecting a call frame, by almost whatever means, this will
> keep the call frame alive[1] (see Continuation or Closure). That is:
> timely destruction doesn't work for example...
Destruct
ng diagnostic
+ .local string l_string
+ .local string r_string
+
+ l_string= left
+ r_string = right
+
+ diagnostic = make_diagnostic( l_string, r_string )
+ test.diag( diagnostic )
+ DONE:
+.end
+
+.sub make_diagnostic
+ .param string received
+ .param string expected
+ .local string dia
On Tue, 2005-11-29 at 13:24 +0100, Leopold Toetsch wrote:
> All tests are passing on linux/x86 and linux-64/amd64.
>
> Please make realclean ...
All tests pass on Linux/PPC. There's one bonus in PGE's Unicode, but
that's a happy notice.
-- c
On Mon, 2005-11-28 at 23:00 +0100, Leopold Toetsch wrote:
> chromatic please make that sentence: 'If no one's unhappy, ...'
My goals are more modest than pleasing everyone... but checked in as
#10339.
I'm thinking we need a little harness file to launch the tests in
speci
On Mon, 2005-12-05 at 11:48 -0800, [EMAIL PROTECTED] wrote:
> I am performing some basic arithmetic on some variables and then using
> a numeric equality operator to see if it returns what I think it should
> by.
> I am printing out the results and sure enough it is as expected. My
> problem is wh
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);
Can you do it without givin
On Tue, 2005-12-06 at 20:26 -0500, Michael Cummings wrote:
> I realize I'm talking to myself at this point (last post, promise), but
> my last message failed to explain the paste at the top. On a box without
> svk, using the 0.4.0 released tarball, all is fine (t/perl/manifest.t is
> skipped/faile
On Fri, 2005-12-09 at 00:08 -0800, Brent Fulgham wrote:
> Do I need to pass compiler options to get SDL support? When I try to
> use the tests in the examples directory, it can't seem to find my SDL
> libraries and so forth.
>
> Can a standard search path (e.g., DarwinPorts typical /opt/loca
On Sat, 2005-12-10 at 12:52 -1000, Joshua Hoblitt wrote:
> I think we need to also change Parrot::IO::Directory->relative_path() to
> filter out '' and replace it with '.' or else we'll have to bundle a
> recent version of File::Spec with Parrot, which I'm not too enthusiastic
> about.
>
> A revi
On Sat, 2005-12-10 at 21:30 -0800, Brent Fulgham wrote:
> I think the problem is the weird distinction Mac OS X (Mach Kernel)
> makes between shared libraries and dynamic modules. I have the shared
> library (*.dylib) and the static libraries, but no "loadable" *.so modules.
>
> So this may
On Sun, 2005-12-11 at 11:24 -0800, via RT wrote:
> Index: docs/tests.pod
Thanks, applied as 10451, along with some other spelling corrections.
-- c
On Wednesday 14 December 2005 12:09, Alberto Simoes wrote:
> + printf STDERR "$stats{ok} OK from $stats{tests} tests (%.2f%%
> ok)\n\n",
Interpolating into a sprintf() string apart from %s is a minor security
oopsie. In this case, it's not so bad if you trust the data coming back from
Te
On Wednesday 14 December 2005 12:09, Alberto Simoes wrote:
> Basically, count tests, count tests ok, give rate. Useful if you want to
> run smoke and look to the output just at the end.
Thanks, applied with sprintf() tweaks as #10538.
Perhaps the maintainer of Test::TAP::Model should look at t
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> Therefore, I propose that the default behaviour of Perl 6 be changed
> or maintained such that:
>
> 0. An undefined value should never magically change into a defined
> value, at least by default.
This is fairly well at odds with the princi
On Friday 16 December 2005 22:25, Darren Duncan wrote:
> At 10:07 PM -0800 12/16/05, chromatic wrote:
> >This is fairly well at odds with the principle that users shouldn't have
> > to bear the burden of static typing if they don't want it.
> This matter is unre
On Saturday 17 December 2005 08:23, demerphq wrote:
> It seemed to me that
> a better patch would be to change the way harness handles directives
> so it recognizes TODO & SKIP as being a valid directive.
What would that mean? SKIP tests don't run. TODO tests do.
If the test doesn't run, I thi
On Monday 19 December 2005 05:06, Michele Dondi wrote:
> Speaking of which:
> | The connection between the language in which we think/program and the
> | problems and solutions we can imagine is very close. For this reason
> | restricting language features with the intent of eliminating programme
On Tuesday 03 January 2006 12:05, Will Coleda via RT wrote:
> This warning seems to have vanished: works fine with gcc 3.3 and 4.0 on OS
> X now.
Leo fixed it in #10656. (I thought I accidentally checked it in with another
patch, but fortunately not.)
-- c
On Sunday 08 January 2006 21:23, Matisse Enzer wrote:
> Do people think Test::Unit sucks? Simply not very well known?
It didn't use Test::Builder when I last looked at it, which meant that either
it or I would have had to reinvent lots of other useful modules I use often.
So far, Test::Class h
On Tuesday 17 January 2006 15:01, Andrew Rodland wrote:
> "print print print print 1;" is certainly a valid Perl 5 program; it
> prints a 1 followed by 3 other things (which are defined to be true, and
> which happen to also be the number 1).
Nit: print doesn't *always* return a true value. It'
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
> Do we really still need to retain the old Perl 5 version of &bless?
> What purpose does it serve that p6opaque does not do in a better/
> faster/cleaner way?
Interoperability with Perl 5 code.
Now if you want to write a p6opaque <-> Perl
On Wednesday 18 January 2006 14:53, Joshua Hoblitt wrote:
> > installation of the necessary modules should be checked at configure
> > time, and an informative message should be given to the user if there
> > are missing dependencies.
> That's just another configure step but it had better be run
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote:
> Well, for one thing, you can't write OO code in P5.
I'll play your semantic game if you play my what-if game.
I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5
code to Perl 6 slowly. Everything new is Perl 6 cod
On Wednesday 18 January 2006 18:54, Stevan Little wrote:
> Are you thinking that one would be able to bless a Perl 5 reference
> into a Perl 6 package?
Not really, but depending on the what Perl 6 bless() does it might work.
> I would argue then that we really don't need Perl 6 &bless for this,
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote:
> As for how that will be handled, I would think that it would be as follows:
> - in Perl6, objects created in another language will be treated as
> p6opaque (unless some other unbox is a more suitable $repr).
... and I specify this exactl
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote:
> No, you want to specify the $repr in CREATE(). But, p6hash will still
> not be the same as a ref to an HV. Frankly, I think you're better off
> letting Parrot mediate things the same way it would mediate Ruby and
> Perl6 or Perl5 and Python.
On Thursday 19 January 2006 06:48, Rob Kinyon wrote:
> "Any practical programming language with structural subtyping will
> probably let you create and use aliases for type names (so you don't
> have to write the full form everywhere). However, the underlying type
> system will only consider the s
On Thursday 19 January 2006 13:10, Rob Kinyon wrote:
> &bless was a brilliant idea for Perl5. It's wrong for Perl6.
Perhaps you meant to write "Tagging a reference with a package name worked for
Perl 5. It's wrong for Perl 6."
Certainly I can agree with that.
Yet this whole discussion feels l
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote:
> On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Answer me this then -- under your scheme, can I subclass a Perl 5 class
> > with Perl 6 code, instantiate the subclass, and use that object in Perl 5
> > code a
On Thursday 19 January 2006 19:50, Rob Kinyon wrote:
> Nothing. Just like it's not a problem if Perl6 uses one of the
> Ruby-specific PMCs for storage. In fact, the alternate $repr idea is
> specifically to allow for the use of foreign datatypes as storage.
> Luke's excellent example is to use a C
On Friday 20 January 2006 07:14, Rob Kinyon wrote:
> I think this entire issue is rising out of the fact that very very few
> people in this discussion are familiar with the design of the MOP.
> Stevan and a few others are the primary movers and I'm lucky enough to
> have been Stevan's sounding bo
On Thursday 19 January 2006 21:53, Stevan Little wrote:
> Okay, so when you say alternate storage then you mean that a class
> like this:
>
> class Foo {
> has $.bar;
> method new ($class, %params) {
> $class.bless('p5Hash', %params);
> }
> method baz {
> $.bar +
On Tuesday 24 January 2006 18:53, Jeffrey Thalhammer wrote:
> Greetings,
>
> I've noticed that CPAN authors use a variety of
> techniques to manipulate the run-time environment in
> their test scripts. Usually, it involves changing
> directories and/or altering @INC. This one seem pretty
> popula
On Friday 27 January 2006 14:43, Tyler MacDonald wrote:
> Part of the problem is that a lot of modules out there are fully
> functional even when a few of their tests fail due to assumptions about the
> environment they are being tested in. Another part is that the ActiveState
> perl package
On Friday 27 January 2006 23:40, Adam Kennedy wrote:
> Something like a clean_install metric. If there are any FAIL entries in
> CPAN Testers against the current version of your module, you lose a point.
> The PITA-based (what I'm thinking of calling) Vanilla Testers system is
> intended for a si
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
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
On Tuesday 31 January 2006 08:59, demerphq wrote:
> Harness should provide better info.
Write your own. perldoc Test::Harness::Straps or see the examples in chapter
3 of the Perl Testing book:
http://examples.oreilly.com/perltestingadn/
-- c
On Tuesday 31 January 2006 11:44, A. Pagaltzis wrote:
> * chromatic <[EMAIL PROTECTED]> [2006-01-31 19:40]:
> >Write your own. perldoc Test::Harness::Straps or see the
> >examples in chapter 3 of the Perl Testing book:
>
> That’s not a long-term answer though, is i
On Tuesday 31 January 2006 12:22, A. Pagaltzis wrote:
> I definitely want to be notified automatically of passing TODO
> tests, and apparently at least three others care enough to post
> about it on this list. Conversely, I’m pretty sure that of those
> who don’t *want* it, most simply don’t care,
On Tuesday 31 January 2006 13:31, A. Pagaltzis wrote:
> Hmm. That’s a good point. Maybe the way to approach this would be
> to include a default harness for use by developer tools, which
> would include more chattiness about passing TODO tests.
My perfect developer tool would complain noisily abo
On Wednesday 01 February 2006 00:26, demerphq wrote:
> And I think you've conveniently sidestepped my main point which is
> that TODO tests passing are errors.
I didn't sidestep it. I just disagree.
> Consider you have two TODO tests,
> both of which depend on a common set of functionality. Bo
On Thursday 02 February 2006 10:04, Tyler MacDonald wrote:
> A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> > I was just gonna say. It???s pointless for anyone but the author to
> > check POD or test coverage.
> I agree about the POD coverage. But if I got a different level of
> code coverage o
On Thursday 02 February 2006 02:56, Tyler MacDonald wrote:
> And now that I think about it, I'm not so convinced about that whole
> "concenience for the end user" nonsense. If they're mucking about
> installing perl modules from the CPAN packages by themself, they're
> probably developers th
On Thursday 02 February 2006 17:45, Adam Kennedy wrote:
> Just as a datapoint on this topic, the PITA request objects (as of 5
> minutes ago) now support the ability to explicitly set environment
> variables you want set when running the tests, on top of the
> default-but-overridable ones like AU
On Tuesday 07 February 2006 13:28, Yuval Kogman wrote:
> Right now the biggest problem in Perl 6 land is project management.
I disagree, but even if it were true, I don't think the solution is to add
more project management and design to partition the process into even more
subprojects of nebul
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:
> If we have more steps and clearer milestones for whatever is between
> parrot and the syntax/feature level design implementation will be
> easier.
Parrot has had such milestones for well over a year.
> De-facto we have people running PIL o
On Tuesday 07 February 2006 15:56, Stevan Little wrote:
> The Pugs project and the Parrot project have had very different goals
> actually (at least Pugs did from the early days). Pugs aimed to be
> able to evaluate Perl 6 code, as a way of testing the language
> features and design. It did not re
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote:
> Does this imply that we should think up this process?
Go ahead.
> If I propose a concrete plan for the implementation of Perl 6 in a
> layered fashion it will probably be even more overlooked.
>
> I have no authority, and this is not somet
On Sunday 12 February 2006 17:11, Yiyi Hu wrote:
> For perl 6,
> Array and Scalar are in different namespace.
> So,
> class A { has $.a; has @.a };
>
> what will A.new.a return by default?
>
> An Error? or Scalar has a higher priority?
Seems like a compile-time warning (at least) to me.
-- c
On Tuesday 14 February 2006 05:48, Leopold Toetsch wrote:
> I'd say, we should drop all the '?v' variants. The extra 'v' doesn't
> cover any information, it's just causing an init call to the argument
> passing code.
To avoid confusion, I suggest requiring that functions returning void always
us
esides the t/01-kwalitee.t file, but
using it is straightforward. I'll be sure to add more explanation and such
before releasing it more publicly.
http://wgz.org/chromatic/perl/Test-Kwalitee.tar.gz
-- c
On Wednesday 15 February 2006 12:33, Andreas J. Koenig wrote:
> The prerequisite Module::CPANTS::Analyse can currently not be
> installed because it relies on sme YAML import feature:
Ahh right, I forgot to mention I removed the ':all' import request in that
module manually. Everything still wo
On Monday 20 February 2006 17:54, chromatic wrote:
> The old PIR subroutine attributes ("method", "@MULTI", "@MAIN", "@LOAD",
> "@IMMEDIATE", "@POSTCOMP", and "@ANON") are now deprecated in favor of the
> lower
On Wednesday 22 February 2006 20:35, chromatic wrote
:
> Here's a patch to the test suite and libraries (but nothing in languages/)
> to migrate the attributes. All tests pass for me after applying the patch
> (and making the parser stricter -- but this patch doesn't touc
On Monday 27 February 2006 16:35, Beau E. Cox wrote:
> Is it me or thee? Any ideas out there?
I'm seeing the same thing on Linux PPC.
-- c
Hi there,
I just managed to get Valgrind working on my Linux PPC box. Are Valgrind
(memcheck, cachegrind, etc) reports useful from various platforms? If so, is
there a good example PIR file to run that stresses sufficient code (or should
someone add a new testgrind target that collects these
On Tuesday 28 February 2006 14:19, Will Coleda wrote:
> Running "make test" in languages/tcl should be pretty painful.
Some tests will fail (STDERR is different), but you can set $ENV{VALGRIND} and
anything that uses Parrot::Test will run it. Nifty.
-- c
On Wednesday 01 March 2006 03:27, Jeffrey Thalhammer wrote:
> Thanks for this. I've heard the term "Technical Debt"
> a few times lately and I really like it. Unlike a
> financial debt however, there is a possibility that
> the principal and interest won't have to be paid. A
> poor implementati
On Friday 03 March 2006 02:41, Tim Bunce wrote:
> Any news on this? Is it okay? Should I send it via parrotbug?
It looked good to me. I say check it in and see what the smokes do.
-- c
On Wednesday 01 March 2006 11:19, Beau E. Cox wrote:
> c - Did you have a chance to try my patch? If so,
> did it work?
It bypassed the build error, so that much definitely works better. I haven't
finished running the test suite to see if everything else works.
-- c
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
> On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> [It's worth considering making all the network I/O opcodes use a
> consistent way of marking errors. At the moment, all return an integer
> status code except for C, C, a
On Wednesday 08 March 2006 13:15, Mark Stosberg wrote:
> Kwalitee are precise metrics which strive to approximate quality. The
> name is intentionally different to convey that Kwalitee is related to
> "quality", but not quite the real thing. That's because we don't know
> exactly what quality
Hi all,
In http://rt.cpan.org/Ticket/Display.html?id=17934, a Test::MockObject user
dislikes the t/0-signature.t test that always runs. If the user does not
have Module::Signature installed, no tests run. If the user does have
Module::Signature installed but not configured properly, the test
On Thursday 09 March 2006 20:06, Flavio S. Glock wrote:
> I'll not to be technical - I'm posting links to the programs, and the
> #perl6 conversations are all logged in http://colabti.de - so feel
> free to go read the sources.
That's a big wad of code. Suppose I want to run it so I can see what
On Monday 13 March 2006 20:08, Adam Kennedy wrote:
> I know of at least a few developers that would consider a report to be
> bogus if one of their dependencies cannot install. Now personally, I
> consider that a failure on the part of BOTH of them.
>
> One for failing, and the other for adding a
On Tuesday 14 March 2006 10:02, David Landgren wrote:
> Plus, the code cut and pasted from Synopses winds up with 8 space
> leading indents or whatever, that you have to strip out and/or you
> forget to turn off vi's auto indenting so you have this massive
> staircase effect and the last line star
On Tuesday 14 March 2006 08:03, Chip Salzenberg wrote:
> PIR users: If namespace "foo" and global variable "foo" were no longer
> distinct, so you had to rename one or the other in your code, would
> you suffer any breakage in the first place, and if you did, would you
> have a har
On Tuesday 14 March 2006 14:14, Chip Salzenberg wrote:
> What, you currently use "::" in your namespace names? On purpose? :-)
I've had objects working in my PIR code before even Dan thought they
worked. Once upon a time, that *was* the way to go.
Now get off my lawn!
-- c
On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
> I'm sure I could clean this up by opening a pipe
> instead of using backticks and output redirection.
> But even that doesn't smell very good. I've looked
> around on CPAN, but I have not yet found a Test::
> module that seems appropri
On Wednesday 15 March 2006 18:43, Geoffrey Young wrote:
> I was suggesting the functionality be added to Test::More as compile_ok(),
> rather than runperl() in some separate CPAN module, as it seems to closely
> parallel use_ok() for modules and would be rather useful on a larger scale.
That woul
On Friday 10 March 2006 02:38, Audrey Tang wrote:
> I think it should be like the standard Test::Pod's pod.t and only run
> when an env var is set to true.
>
> Patches... welcome to Module::Signature. :-)
Do you mean that it's valuable only for the author to run (perhaps during
disttest) and rar
On Sunday 19 March 2006 05:32, Bernhard Schmalhofer wrote:
> I tried to use something like:
>
> example_output_like( "examples/benchmarks/arriter.pir",
> $outputs{arriter.pit}, todo => 'syntax error' );
>
> However the 'todo' flag is not honored. My guess is that the TODO
> variable isn't set in
On Sunday 19 March 2006 10:58, Will Coleda wrote:
> in compilers/tge/TGE.pir, we have
>
> .sub '__onload' :load
> # use other modules
> load_bytecode 'compilers/tge/TGE/Rule.pir'
> load_bytecode 'compilers/tge/TGE/Instance.pir'
> load_bytecode "compilers/tge/TGE/Parser.pir"
>
>
On Tuesday 28 March 2006 06:11, Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless you
> have unlimited developer time."
"If you think TDD is expensive, try debugging."
Greg's comments give me the impression that he thinks TDD means writing a
whole pile
On Monday 20 March 2006 11:16, Bernhard Schmalhofer wrote:
> I have put the calls to example_output_like() and example_output_is() as
> comments into t/benchmarks/benchmarks.t.
>
> # XXX use example_output_is() and example_output_like()
> # This does not work yet WRT to TODO
>
On Thursday 30 March 2006 07:32, Adam Kennedy wrote:
> In contrast, as I hear chromatic express it, TDD largely involves
> writing tests in advance, running the tests, then writing the code.
Not quite. It means writing just enough tests for the next testable piece of
the particular f
On Saturday 01 April 2006 03:41, demerphq wrote:
> So you would file a bug with ExtUtils::MakeMaker or Module::Build when
> the pre-build script that accompanies a script has a syntax error in
> it?
Don't forget with every distribution that marked that distribution as a
dependency.
-- c
On Sunday 02 April 2006 21:17, Andy Lester wrote:
> Here's my first patch. Let me know if y'all see this sort of work as
> useful, or if I shouldn't bother.
Please continue.
In the next round of their scans, Coverity may add Parrot to the list of
projects.
For various annoying reasons, I can'
On Monday 03 April 2006 13:29, [EMAIL PROTECTED] wrote:
> Modified: trunk/docs/pdds/clip/pdd07_codingstd.pod
> ===
>=== --- trunk/docs/pdds/clip/pdd07_codingstd.pod (original)
> @@ -760,6 +761,79 @@
> TBC ... Any contr
On Tuesday 04 April 2006 10:32, Tels wrote:
> There is also the point that supporting ancient Perls means you
> can't use all the new, wonderfull features that were added to later
> versions of Perl, like our, warnings etc.
This to me is the biggest problem. After 6 years, is it finally okay for
On Tuesday 04 April 2006 12:16, A. Pagaltzis wrote:
> Is it any wonder that people say core is too big?
Want more heresy?
If the core contained more modules, there'd be even less possibility of
getting managed hosts or hostile system administrators in really picky
environments to install or up
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote:
> Seeing as the worst support cases are about 10 years in a variety of
> countries and situations, I think that is what we should be aiming for
> for highly used CPAN modules.
>
> Which last time I checked is now 5.005.something
>
> So I aim ther
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote:
> But it's also why UNIVERSAL::isa/can and people adding higher-version
> dependencies below their existing lower-dependency modules is bad.
>
> The code used to work just fine, and now it doesn't.
This is a strange definition of "work just fi
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote:
> And now in return, we have new modules that changes the way EVERYBODY
> else's code works, and changes the meaning of that code instead, so
> Test::MockObject gets less spurious bug reports.
You mischaracterize the situation.
There is no po
On Thursday 06 April 2006 14:04, Bernhard Schmalhofer via RT wrote:
> 'punie' seems to be the only maintained language implementation using
> Perl* PMCs.
What about Ponie?
> Also some tests and examples are using the Perl* PMCs.
I agree that they probably shouldn't, except for the tests for th
On Thursday 06 April 2006 17:53, Adam Kennedy wrote:
> UNIVERSAL::isa/can when called as a function does a very specific thing,
> and one that is often misunderstood.
... and never correct, in the face of proxy objects, blessed objects,
overloading, and ties.
> And if you were able to distingui
On Friday 07 April 2006 06:43, A. Pagaltzis wrote:
> I still wonder what’s bad about using
>
> UNIVERSAL::can( $foo, "can" )
>
> as a pre-Scalar::Util-compatible replacement of
>
> blessed( $foo )
>
> that is, purely as a boolean test where only the truthness of the
> return value is of in
1 - 100 of 2084 matches
Mail list logo
