small patch to STD.pm

2009-01-23 Thread Mark Lentczner
This fixes a typo and enables X>>+< X | X -| X +| X ] = $; }>

Re: RFD: Built-in testing

2009-01-23 Thread Brandon S. Allbery KF8NH
On 2009 Jan 21, at 7:35, Carl Mäsak wrote: Moritz (>): So Larry and Patrick developed the idea of creating an adverb on the test operator instead: $x == 1e5 :ok('the :ok makes this is a test'); I'm trying to explain to myself why I don't like this idea at all. I'm only partially successfu

[svn:parrot-pdd] r35945 - in trunk: . docs/pdds src/pmc t/pmc t/steps

2009-01-23 Thread coke
Author: coke Date: Fri Jan 23 22:05:05 2009 New Revision: 35945 Modified: trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Removed: trunk/src/pmc/pair.pmc trunk/t/pmc/pair.t Modified: trunk/MANIFEST trunk/PBC_COMPAT trunk/t/steps/auto_pmc-01.t Log: TT

Re: RFD: Built-in testing

2009-01-23 Thread jason switzer
On Fri, Jan 23, 2009 at 6:39 PM, Dave Whipp wrote: > A spec-test is (or should be) different from an ad-hoc test. I want to be > able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a > nicer name). Unique identifiers allow comparisons of specific tests across > multiple imp

Re: RFD: Built-in testing

2009-01-23 Thread Dave Whipp
jerry gay wrote: i don't understand the drive to have unique test identifiers. we don't have unique identifiers for every code statement, or every bit of documentation. why are tests so important/special/different that each warrants a unique id? that aside, this functionality sounds like it can

Re: RFD: Built-in testing

2009-01-23 Thread jerry gay
On Fri, Jan 23, 2009 at 12:37, Dave Whipp wrote: > I could also imagine writing code that reads from an Sqlite database, and > imposes that info onto the test. Whatever mechanism is used, I think we need > a language-defined mechanism to supply a stable unique identifier for each > test, so that i

Re: RFD: Built-in testing

2009-01-23 Thread Dave Whipp
Larry Wall wrote: module MyTests { sub group1 { ok foo :name; ## Q - would a label be better? } } >> ## Elsewhere >> MyTests.group1.test_foo is also broken; I guess I don't see offhand what you're trying to do with that. ... We must keep a clean separation between code t

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

2009-01-23 Thread Darren Duncan
Dave Whipp wrote: I actually agree that your explicit definition (a simple/efficient implementation in terms of other operators) is better for prelude than my "declarative" form (which isn't really declarative, because Perl6 isn't a declarative language). My only disagreement was with your ear

Re: RFD: Built-in testing

2009-01-23 Thread Larry Wall
On Fri, Jan 23, 2009 at 11:16:21AM -0800, Dave Whipp wrote: > I can see that. So the alternative is to give things names and/or tags, > so that we can attach parameters remotely. Hmm, well, we also decided not to use any solutions that encourage putting the metadata too far away from the place i

Re: RFD: Built-in testing

2009-01-23 Thread Dave Whipp
Larry Wall wrote: On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote: For example, I could conceive of a trait: ok foo, :broken which might downgrade the error to a warning on rakudo, but not on other implementations. On the surface that seems like a good idea, and pugs started o

Re: [perl #48014] [DEPRECATED] PMC union struct

2009-01-23 Thread Allison Randal
Christoph Otto wrote: So you're saying that multiple inheritance in its current state should be allowed to continue, and that there's only a problem with ATTRs if a PMC tries to extend two PMCs, both of which have their own ATTRs? I'm saying that multiple inheritance between two C-level PMCs

Re: RFD: Built-in testing

2009-01-23 Thread Larry Wall
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote: > For example, I could conceive of a trait: > > ok foo, :broken > > which might downgrade the error to a warning on rakudo, but not on other > implementations. On the surface that seems like a good idea, and pugs started out doing thi

Re: RFD: Built-in testing

2009-01-23 Thread Dave Whipp
Timothy S. Nelson wrote: method foo() does assume { ... } method bar() does ensure { ... } Is "ensure" equivalent to the "assert" that you describe above? Yes. "does ensure" was meant to be an englishification of "postcondition"; and "does assume" is "precondition". From the perspec

Re: perl6 Testing

2009-01-23 Thread Carl Mäsak
fREW (>), Moritz (>>), fREW (>>>): >> > And should I >> > just mail patches to rakudo...@perl.org? >> >> In general if you find a bug: yes. >> In this case not, because it's a known limitation. > > Where do I mail the patches for the tests? The Pugs repository (containing the Perl 6 test suite) h

Re: perl6 Testing

2009-01-23 Thread fREW Schmidt
> > And should I > > just mail patches to rakudo...@perl.org? > > In general if you find a bug: yes. > In this case not, because it's a known limitation. Where do I mail the patches for the tests? -- -fREW

Re: [perl #61880] //= not understood by Rakudo

2009-01-23 Thread Patrick R. Michaud
On Mon, Jan 19, 2009 at 02:18:46PM -0800, jn...@jnthn.net via RT wrote: > On Wed Dec 31 08:44:02 2008, masak wrote: > > Rakudo r34703: > > > > $ perl6 -e 'my $year; $year //= 2009' > > get_iter() not implemented in class 'Integer' > > > > This looks like a misparse, interpreting '//= 2009' as '//

Re: [perl #62506] Rakudo segfault on missing method

2009-01-23 Thread isop
- Original Message > From: isop > To: parrotbug-follo...@parrotcode.org > Sent: Friday, January 23, 2009 10:27:05 AM > Subject: Re: [perl #62506] Rakudo segfault on missing method > > > > - Original Message > > From: Moritz Lenz via RT > > To: is...@yahoo.com > > Sent: Tu

Re: [perl #62506] Rakudo segfault on missing method

2009-01-23 Thread isop
- Original Message > From: Moritz Lenz via RT > To: is...@yahoo.com > Sent: Tuesday, January 20, 2009 9:06:03 AM > Subject: [perl #62506] Rakudo segfault on missing method > > On Mon Jan 19 13:04:17 2009, isop wrote: > > Following perl6 code segfaults with r31857: > > > > say 8.bla;

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

2009-01-23 Thread Dave Whipp
Darren Duncan wrote: I don't quite follow you. Are you saying your version of sqrt is an implicit declaration; maybe I don't understand how that differs from an explicit definition in this case? In any event, right at this moment I can't think of an answer to your question. Go ahead with wh

[PATCH] Updated trim() functions

2009-01-23 Thread Ovid
This patch provides trim_start() and trim_end() per earlier discussions. trim() is rewritten in terms of those. There were some discussions about how other data structures should be handled, so until there's a spec or a much clearer agreement on the lists, I'm leaving that off. Tests for this