Re: RFD: Built-in testing
Hi
I assume that BDD(Behavior Driven Development) and the vocabulary that
it implies is not a good choice
at this stage ?
:describe("");
$x.should be(1e5) :it("");
and that a module based on the core testing facilities can be built if
someone feels like to.
Well, the vocabulary that it implies is really nice anyway if it can be
of any inspiration^^
http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
Dave Whipp wrote:
I do agree that a prelude.pm should be written atas higher level as
possible, but I would not that Perl6 is not a "declarative" language.
Using the most powerful operators available (I'd like to see more of
them) is about the best you can do: as soon at you start using
codeblocks to define things, you get beyond the realm where compile-time
analysis is possible in a dynamic language.
Lets imagine I want to define a "sqrt($x)" function in a declarative
style in perl6 (and lets image we've defined a Real type with
Real::Epsilon being the precision of the representation). The
declarative version of sqrt must say to find a value within the set of
Real numbers that, when squared, is closest to $x:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
I would declare sqrt this way instead (the body is the important change):
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
$x ** (1/2)
}
My point with this example is that any time there exists 2 operators for which
one is a more specialized case of the other, or the other is a more generalized
case of the first, then the specialized one is defined in terms of the
generalized one.
So defining sqrt as just a special case of exponentiation makes for a simple
declarative solution.
I think when I said "define in terms of higher level", I also meant to say
"define in terms of the most generalized operators applicable".
Note also that, as I've defined it, sqrt is still defined in exact terms rather
than approximate / precision-varying terms, and so each underlying
implementation can easily interpret this as an exact math operation if it is
itself capable of exact math, and otherwise it still has enough information to
know how to do it in approximate math.
-- Darren Duncan
Re: RFD: Built-in testing
Larry observed:
> My feeling on this is that the compiler should simply hardwire this
> particular adverb so that all the tests can be autogenerated, and the
> multi system never needs to see those versions.
I strongly agree.
> We are merely hijacking the adverb syntax so that is clear which
> operator is being modified. There is no need for the late binding of
> multi. It's just a "reserved adverb" if you will. Which probably means
> it should be something unlikely to collide with user-defined adverbs.
> Maybe something in all caps. For what it's worth, :OK<> can be typed
> with one hand while the other holds down the shift key. :)
Typical right-hander fascism!
We do indeed want to encourage testing by making it easy to write tests,
but naming it :TEST<> makes it far easier to *read* tests, which seems
to me a better long-term optimization.
We would probably also want a mechanism for switching tests on or off in
a given compilation unit, or globally, so they can be placed in (and left in!)
production code. Perhaps we could use the same mechanism for PRE{...}
and POST{...} blocks as well? Which also suggests that a general TEST
{...} block (which only runs if testing is enabled) might be valuable?
Damian
Re: RFD: Built-in testing
Hi, I pretty much like this idea. Very perl6ish :) - I don't think it's important whether it is called :ok, :OK or :test or :wellhowdidthatworkout. I assume people who will be testing their modules/code/etc. will be using more advanced modules for testing anyway. This is for testing the implementation against the specs, and they *will* know how it works :) - I don't think we should be concerned whether to implement :ok is difficult. Implementations in early stage are totally broken anyway :), they won't even *parse* the tests well - they will have have their own, limited tests. Later they can chose to do some magic to make :ok work... and finally implement it. - I like "ok" better than "test", as the former kind of implies a boolean "was that true?" to me. YMMV, though. - Fagzal
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz wrote:
> 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');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
>
> multi sub infix:<==>($left, $right, :$ok) {
>$*TEST_BACKEND.proclaim($left == $right, $ok)
>or $*TEST_BACKEND.diag(
>"Got: «$left.perl()»; Expected: «$right.perl»");
> }
>
> (Daniel Ruoso also proposed to call the adverb :test
> instead of :ok, making it easier to read but a bit
> longer; my happiness doesn't depend on the exact name,
> but of course we can discuss it once we have settled
> on this scheme, if we do so).
I like this idea and with it built into the language itself, there will be
much less of an excuse to skip testing. I like the adverb form, which seems
more perl6 than C. Naming it something like :test is a better idea than :ok
as that seems a bit more direct.
There isn't much in the spec concerning namespaces, other than the default *
namespace. Is there any reason why the testing framework can't go in it's
own namespace?
> * We nearly double the number of built-in operators
> by adding an :ok multi
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
> * Testing of operators becomes somewhat clumsy. If you
> * want to test infix:<==>, you won't write
> '2 == 2 :ok("== works")', because you test a
> different multi there. Instead you'd have to write
> something like '?(2 == 2) :ok("== works")', where
> :ok is an adverb on prefix:.
>
These are mostly disadvantages to implementors, not users of the testing
framework. I'd rather the implementations struggle to implement a built-in
testing functionality than users of the language struggle to use the
built-in testing.
> I'll send another mail on the subject of pluggable
> testing backends in order to allow different emitters
> (TAP output, storage into databases, whatever)
This is a requirement for me. Having only TAP emitters may not integrate
well. It would be nice if the spec, if added, would allow flexibility in
this realm. I would actually like to see a flexible system that allowed me
to define a new emitter, say for the cases where you want to integrate perl6
testing into an existing testing framework (think automated builds and
tests).
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 08:08:57PM +0100, Moritz Lenz wrote: : * We nearly double the number of built-in operators :by adding an :ok multi My feeling on this is that the compiler should simply hardwire this particular adverb so that all the tests can be autogenerated, and the multi system never needs to see those versions. We are merely hijacking the adverb syntax so that is clear which operator is being modified. There is no need for the late binding of multi. It's just a "reserved adverb" if you will. Which probably means it should be something unlikely to collide with user-defined adverbs. Maybe something in all caps. For what it's worth, :OK<> can be typed with one hand while the other holds down the shift key. :) Larry
Re: A Logo design for Rakudo Perl 6
Perl wrote: > One of the main fears with this name, "Rakudo Perl 6" - at least when > it first came out, is that describing Rakudo Perl as, "An > implementation (one of possibly, many) of the Perl 6 Specification, > built on top of the Parrot Virtual Machine", will leave people going, > > "Huh?!" > > I think this is a good reason as anything, to think of getting a > visual representation of this, somewhat complicated idea out ASAP. 100% agreement here. [...] > One of the, well, the third letter in their alphabet is, "gimmel", > which comes from the word gamel, which, if you didn't guess already > means, "Camel"! It looks either like the neck of a camel - or, perhaps > it's hump. If you think of, "gimmel" as our, "C" you can sort of still > see a hump of a camel, if you just turn the, "C" 90 degrees, clockwise. And for those of you who use UTF-8 enabled mail programs and have Hebrew fonts installed: A gimel looks like this: ג (it's actually pretty close to a small Greek lambda). > Early written languages like Proto-Sinaitic are sort of the beginning > where pictograms that stood for what things looked like, where changed > into a way of writing about an idea - a lot of these early letters > still hold a lot of the original meanings. Hebrew, for instance still > does and each character is rich in back history. I like the Proto- > Sinaitic link, since it's less loaded quite as intensely as Hebrew, > which is invariably tied to major traditions and religions. > > The, "Gimmel" character is no exception. Start from, "Mysteries of > the Alphabet" > -- > :: Original Meanings > Carrying the Primal Power beyond, outside the domestic setting > > :: Derivative Meanings > Outgoing, break, carry to another, do good, return a favor > > :: Acquired Meanings, Perpetuated By The Hebrew Language > > Ripen, Ween, Enable to ripen > Release Oneself, Break Away From > -- > > Which I think beautiful illustrates a nice connection between Perl 5 > and Perl 6, Rakuda-do/Rakudo and haiga pen-names - and the, "Big > Picture" of what exactly Perl 6 is all about - standing apart from the > lineage, but still being, well, "Perl", using the Camel (gimmel) as a > fundamental icon from way WAY back in time there - > > and it all sounds so Perlish of picking and choosing the best from > many ideas and languages. I found the idea fascinating of using the gimel someway in association with Perl 6 and Rakudo - but I guess for most people it will just look like a weirdly shaped lambda. (That's not a bad things, just worth to mention IMHO) > Taking a step back from this soup of ideas and thinking of a logo > itself, it seems that it would help to produce something that's made > of somewhat interlocking and inter-related pieces: Perl on Parrot has > two separate pieces that come together and complete an idea. But > there's other things that could take, "Perl's" place, so it's really, > > $x on Parrot > > It seems that if a logo would be made, we can modularize, say, that > Parrot part and use it for other things - same with the Perl part, if > you get into it. Modularization is a way of getting ready for the > future. It also allows us to be lazy: we can use other people's work > already and - well, you all know this already. It would be an > interesting idea to use common programming best practices in the logo > of Perl itself. > > I bring that all up, because when I look at the various Perl projects, > they all look extremely interesting, but fragmented. It would almost > make sense to create a logo where pieces can be reused for related > thingies. Starting from a logo for Rakudo Perl, one could make a > simple Style Guide even, with easy-to-acquire graphic elements that > say, an application written using Rakudo Perl could use (at their > discretion) to enhance their own project and tie it back into Rakudo > Perl (and Perl in general). Taking the Perl 6 design goals to the logo - very nice! > So that's sort of the other thing I'm proposing: not only designing a > logo for Rakudo Perl, but having the concept of modularization of the > logo's basic elements part of the logo design itself and the sharing > and remixing of the design elements for related projects, to help > strengthen the, (and I'm not a fan of using this word) > "branding" (sigh) of Perl and making it not so much the "invisible > language that glues everything together", but have it where it > belongs: in a positive light with the general (geeky) public. > > Right now, all that means to me is perhaps a simple style guide and > the image and graphic resources easy to grab in open formats. It would be great if you could come up with such things - I fear I can't really help on that matter. My overall thoughts
Re: [perl #62478] C-style for loop does not give an error
> > prints 2 instead of giving an intelligent error message that one should
use loop
> > or better yet for 1..3 -> $i { }
> Presumably "say $_" would also yield 2, since I gather the for
is looping over ($i).
$ perl6 -e ' for (my $i = 1; $i <= 3; $i++) { say $i; }'
2
$ perl6 -e ' for (my $i = 1; $i <= 3; $i++) { say $i; say $_ }'
2
1
So the "++" is applied before the loop body but after the assignment to $_
a
---
Andy Bach
Systems Mangler
Internet: andy_b...@wiwb.uscourts.gov
Voice: (608) 261-5738; Cell: (608) 658-1890
History will have to record that the greatest tragedy of this period
of social transition was not the strident clamor of the bad people,
but the appalling silence of the good people.
Martin Luther King, Jr.
RFD: Built-in testing
A few months ago Larry proposed to add some testing
facilites to the language itself, because we want to
culturally encourage testing, and because the test
suite defines the language, so we need to specify the
behaviour of our testing facilities anyway.
We also discussed some possible changes to the current
testing syntax, please read the IRC discussion starting
from here:
http://irclog.perlgeek.de/perl6/2008-10-09#i_613827
There are some problems with the current approach,
especially if we make it built-in:
* the word 'is' is overloaded in Perl 6, it is used
for traits (class A is rw { ... }),
implementation types (my @a is TiedArray) and
inheritance (class A { is B; ... }). Especially
the the last one can appear in the same position
as an is() test, and means something completely
different
* if we export subs is() and ok(), we clutter the
namespace with subs with short names - not very nice
* is() is rather imprecise; it doesn't say *how*
things are compared. Currently two options seem to
be open for the comparison semantics: either
string based, or deep structural equality (with
infix:). Both are very problematic: The
stringification of some structures can be
implementation specific (for example for Ranges),
and it often looses lot of information. Also pugs
used to stringify hashes in insertion order, but
that's not forced by the spec, so many tests
relied on that behaviour, ie they were wrong.
Comparison by infix: is dangerous, because it
is very strict, and things that were identical in
the early stages of the compiler become distinct
later on. Consider 'sub f { return 1, 2, 3}; say
f() eqv (1, 2, 3)'. Pugs says this is true,
because it doesn't implement return() as returning
a capture (or in turn thinks that lists are eqv to
captures), and testers would rely on this.
Future versions of a compiler would contradict the
previous results, and thus put an additional burden
on the test suite maintainers (ie mostly me). There
are other subtle distinctions (like between List
and Array) that make it hard to write tests
with infix: correctly.
So we want to get rid if the is() test function. The
current workaround is to use ok() and an explicit
comparison operator like this:
ok $x == 1e5, 'with explicit numeric comparison';
However this just tells us if a test fails, not how it
fails - it would be nice to have something like
Test::More's output "Expected 1e5, got 1e4". The only
way that ok() could produce such diagnostics would be
to declare it a macro that peeks into the AST of its
first argument and tries to find the two values. But
that's very advanced magic, and might not even be
possible in a DWIMmy way in the general case.
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');
This is an adverb on the infix:<==> operator, and might
desugar to something like this:
multi sub infix:<==>($left, $right, :$ok) {
$*TEST_BACKEND.proclaim($left == $right, $ok)
or $*TEST_BACKEND.diag(
"Got: «$left.perl()»; Expected: «$right.perl»");
}
(Daniel Ruoso also proposed to call the adverb :test
instead of :ok, making it easier to read but a bit
longer; my happiness doesn't depend on the exact name,
but of course we can discuss it once we have settled
on this scheme, if we do so).
So every operator that returns a boolean would get a
multi with the named argument :ok, which could be
autogenerated for most operators, but hand-written for
others that need more verbose diagnostics (for example
the smart match operator could tell you which of its
hundred possible comparisons it used). That's not just
limited to infix operators, ok($x, '$x is true') could
be written as ?$x :ok('$x is true'), where the :ok is
an adverb on prefix:;
This approach gives us
* good and easy diagnostics
* exactness by forcing the explicit choice of
comparison semantics
* nice integration into the Perl 6 syntax
* no cluttering of the namespace with short subs
However nothing in life is free, we pay for it with a
few disadvantages:
* We nearly double the number of built-in operators
by adding an :ok multi
* We force implementors to handle operator adverbs
and named arguments very early in their progress
(don't know how easy or hard that is)
* Testing of operators becomes somewhat clumsy. If you
* want to test infix:<==>, you won't write
'2 == 2 :ok("== works")', because you test a
different multi there. Instead you'd have to write
something like '?(2 == 2) :ok("== works")', where
:ok is an adverb on prefix:.
So I'd like to hear your opinions: do you think
adverb-based testing is a good idea? If you don't like
it, do you see any other good way to tackle the
problems I mentioned above?
I'll send another mail on the su
[perl #62528] Match.keys method returns nothing.
# New Ticket Created by "Eric Hodges"
# Please include the string: [perl #62528]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62528 >
use v6;
rule test {test};
"test" ~~ //;
say '$/.keys => ', $/.keys.perl;
say '%($/).keys => ', %($/).keys.perl;
# outputs
# $/.keys => []
# %($/).keys => ["test"]
Same could be said for .values and .kv
It would be very DWIM for it to act like a hash in these cases by default.
[perl #62540] [BUG] $*ERR has stopped giving access to the standard error stream
# New Ticket Created by mbere...@flashmail.com # Please include the string: [perl #62540] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62540 > perl6 -e '$*ERR.say: "hello";' # writes to stderr This diagnostic type statement was very useful to insert into potentially buggy code, but between r35309 (good) and r35568 (bad) began to fail with: Cannot write to a filehandle not opened for write
[perl #62530] Assinging a $/ to a scalar and then accessing its extened .keys method produces a "Null PMC" error
# New Ticket Created by "Eric Hodges"
# Please include the string: [perl #62530]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62530 >
class Match is also { method keys () {return %(self).keys }; };
rule a {H};
say "Hello" ~~ //;
say $/.keys.perl;
my $x = $/; $x.keys.perl.say;
Produces:
H
["a"]
Null PMC access in find_method()
[perl #45999] [TODO] Handle multi-methods in Parrot_ComposeRole()
On Tue Oct 02 11:01:32 2007, pcoch wrote: > In src/objects.c:Parrot_ComposeRole() there is the todo item: > > * XXX TODO: multi-method handling. */ > > I think this means that multi-method handling neds to be handled at this > point in the code. > Indeed. Done this in r35820. Thanks, Jonathan
Re: New perl6 wiki
Oh,... i see. Fixed That! On 19 ene, 15:09, mor...@faui2k3.org (Moritz Lenz) wrote: > Hi, > > dev.null.box wrote: > > Yes, yes, i know. There is an official perl6 wiki. But, i think a more > > "friendly" wiki is needed, so i just started a new mediawiki one in > >http://perl6.wikia.com > > I appreciate your effort, and at the same time I'd like to ask you (and > your fellow contributor(s)) to actually test what you write, whenever > possible. For example onhttp://perl6.wikia.com/wiki/ArrayI found at > least three errors that could have easily been trapped by running the > examples in Rakudo (or pugs, for that matter). > > Cheers, > Moritz
Unofficial Perl 6 Prelude for Rakudo
Since I can write Perl 6 better than most other languages, and I want to contribute to Rakudo, and I want some features *now*, and I'm an impatient bastard... I started an unofficial Perl 6 Prelude project for Rakudo: http://code.google.com/p/rakudo-prelude/ The intent is to write and collect specced, built-in subs and methods in Perl 6 that work *now*, at least to some extend. Since there's no Prelude feature in Rakudo yet, it means that you have to use List; use Match; ... first to use them. My hope is that this will be useful for some users today, and maybe other projects copy or import part of it. And when Rakudo finally gets a prelude, we might use some of the things I've assembled so far. If you want commit access, just tell me your google ID. (I didn't put it into the parrot repo because I didn't want to have any dead (not yet used and tested) code in there, didn't want to hassle with codingstd tests and so on). Cheers, moritz
rakudo on cygwin
Is there a rakudo package for cygwin? There's parrot and parrot-languages, but none of them seems to include anything that looks like "rakudo" or "perl6". Do i have to build it myself to try it? Or didn't i look well enough? Thanks in advance. -- Amir Elisha Aharoni heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com "We're living in pieces, I want to live in peace." - T. Moore
Re: Ops Review
On Tue, Jan 20, 2009 at 2:20 PM, Jonathan Worthington wrote: > chromatic wrote: >> On Monday 19 January 2009 14:13:22 Bob Rogers wrote: >> >>> Do you think that would be fast enough? The usual way for dynamic >>> languages to get fast compiled numeric code is to bind variables to >>> hardware types at compile time, and then inline numeric operations in >>> order to use that information. That seems to require op_i_i_i and >>> op_n_n_n versions of these ops, which are not language-dependent. >>> >> >> I don't see how Parrot can be fast enough in general without JIT. With JIT, >> if these ops are implemented in terms of other ops, there's no speed penalty. >> >> > I think one criteria to consider is, are their architectures out there > (that we're targeting now or likely to) that have the equivalent op > implemented at a CPU instruction level, such that we could JIT it in the > future? If so, there's probably benefit in it staying a Parrot op. > > Jonathan > > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > I would rather defer that until we actually target those OSes; let's stick with our core platforms for now (especially since we don't even support JIT on all of our core platforms.) -- Will "Coke" Coleda
Re: Ops Review
chromatic wrote: On Monday 19 January 2009 14:13:22 Bob Rogers wrote: Do you think that would be fast enough? The usual way for dynamic languages to get fast compiled numeric code is to bind variables to hardware types at compile time, and then inline numeric operations in order to use that information. That seems to require op_i_i_i and op_n_n_n versions of these ops, which are not language-dependent. I don't see how Parrot can be fast enough in general without JIT. With JIT, if these ops are implemented in terms of other ops, there's no speed penalty. I think one criteria to consider is, are their architectures out there (that we're targeting now or likely to) that have the equivalent op implemented at a CPU instruction level, such that we could JIT it in the future? If so, there's probably benefit in it staying a Parrot op. Jonathan
Re: Ops Review
On Monday 19 January 2009 14:13:22 Bob Rogers wrote: >On Monday 19 January 2009 13:41:21 Bob Rogers wrote: >> Math ops: >> - ceil/floor >> - transcendental ops >> - gcd/lcm/fact >> >> What are you suggesting as replacements? Or (with the probable >> exception of fact) must every language reinvent these wheels? > >I had in mind the idea that they could become members of a PBC library. > Do you think that would be fast enough? The usual way for dynamic > languages to get fast compiled numeric code is to bind variables to > hardware types at compile time, and then inline numeric operations in > order to use that information. That seems to require op_i_i_i and > op_n_n_n versions of these ops, which are not language-dependent. I don't see how Parrot can be fast enough in general without JIT. With JIT, if these ops are implemented in terms of other ops, there's no speed penalty. >And possibly of other ops as well. Speed should certainly not be an > issue for Parrot 1.0, so I can see not wanting to add new numeric ops, > but I don't see the point of removing ops we already have only to decide > we need them later. That's a fair point, though it can be difficult to remove ops later. -- c
Re: first real perl6 use
Richard (>): > Just wanted to say that this afternoon I used rakudo for a real world need. > > It was only a simple script to extract data from a text file. But it took > all of 5 min from start to finish. > > Could have done it in perl5, but it really was easier to do it in perl6. > > As far as I am concerned, this marks a milestone for perl6. One I have been > waiting for for years. I have similar experiences, but I created my first utility scripts -- whose function it was to test me on weekly batches of Chinese characters -- sometime early in the autumn. I remember feeling that it was a big step using Perl 6 to scratch a day-to-day itch. The script pulled out 10 random words out of the forty or so I had each week. In other words, thank you Perl 6 for teaching me a couple hundred Chinese words and characters! I might add that .pick() is a really useful function for this type of thing. :) // Carl
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tuesday 20 January 2009 09:50:56 Patrick R. Michaud wrote: > > > What's the replacement opcode for n_neg ? > > If we remove n_neg, the replacement is likely a two-step operation: > > > > clone $P1, $P2 > > neg $P1 > > Please, not this -- it's terribly inconsistent. > > When we got rid of the other n_* opcodes, their non-n_* counterparts > were given the "create a new PMC" semantics that the n_* version had. > We should do the same for n_neg, such that what was previously > > n_add $P0, $P1, $P2# construct $P0 as sum of $P1 and $P2 > n_neg $P0, $P1 # construct $P0 as negation of $P1 > > is now > > add $P0, $P1, $P2 # construct $P0 as sum of $P1 and $P2 > neg $P0, $P1 # construct $P0 as negation of $P1 Hm, now that I look closer, this already exists and works that way. Thus the replacement is to use: neg $P0, $P1 -- c
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tue, Jan 20, 2009 at 09:33:17AM -0800, chromatic wrote: > On Tuesday 20 January 2009 07:27:53 Patrick R. Michaud wrote: > > > On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: > > > > I've done most of this in r35787, but we can't get rid of n_neg entirely > > > until someone updates PCT and NQP not to use it for prefix:- rules. I > > > poked at that, but couldn't make them work. > > What's the replacement opcode for n_neg ? > > If we remove n_neg, the replacement is likely a two-step operation: > > clone $P1, $P2 > neg $P1 Please, not this -- it's terribly inconsistent. When we got rid of the other n_* opcodes, their non-n_* counterparts were given the "create a new PMC" semantics that the n_* version had. We should do the same for n_neg, such that what was previously n_add $P0, $P1, $P2# construct $P0 as sum of $P1 and $P2 n_neg $P0, $P1 # construct $P0 as negation of $P1 is now add $P0, $P1, $P2 # construct $P0 as sum of $P1 and $P2 neg $P0, $P1 # construct $P0 as negation of $P1 Pm
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tuesday 20 January 2009 07:27:53 Patrick R. Michaud wrote: > On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: > > I've done most of this in r35787, but we can't get rid of n_neg entirely > > until someone updates PCT and NQP not to use it for prefix:- rules. I > > poked at that, but couldn't make them work. > What's the replacement opcode for n_neg ? If we remove n_neg, the replacement is likely a two-step operation: clone $P1, $P2 neg $P1 -- c
Re: first real perl6 use
Hey, On Tue, Jan 20, 2009 at 11:58 PM, Richard Hainsworth wrote: > Just wanted to say that this afternoon I used rakudo for a real world need. > > It was only a simple script to extract data from a text file. But it took > all of 5 min from start to finish. > > Could have done it in perl5, but it really was easier to do it in perl6. > > As far as I am concerned, this marks a milestone for perl6. One I have been > waiting for for years. > > Would you mind to share your codes? I am interested why it is easier to do it in perl6.
first real perl6 use
Just wanted to say that this afternoon I used rakudo for a real world need. It was only a simple script to extract data from a text file. But it took all of 5 min from start to finish. Could have done it in perl5, but it really was easier to do it in perl6. As far as I am concerned, this marks a milestone for perl6. One I have been waiting for for years.
Re: [perl #62504] AutoReply: Rakudo segfault on multi type mismatch
Forgot to mention this is with r31857
- Original Message
From: Parrot via RT
To: is...@yahoo.com
Sent: Monday, January 19, 2009 11:01:42 PM
Subject: [perl #62504] AutoReply: Rakudo segfault on multi type mismatch
Greetings,
This message has been automatically generated in response to the
creation of a parrotbug regarding:
"Rakudo segfault on multi type mismatch"
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [perl #62504].
Please include the string:
[perl #62504]
In the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
parrotbug
http://rt.perl.org/rt3/Ticket/Display.html?id=62504
-
MIME-Version: 1.0
X-Ymail-Osg:
GyjYK0MVM1nthnl7OcUyU_xH3ItJLjqOQE2VZyJKIxWiPPYtfkNoFk4mBm3l4avhmYEX92RgU_oE4qKFboYesobs_L06NYYKSG7mGm1QMKEeeE0V8G7Y_B9jOVTBWUrXIe_PoVSpeMD8Z7BreSelOuurbNM-
X-Spam-Status: No, hits=0.0 required=8.0
tests=DK_POLICY_TESTING,DK_SIGNED,DK_VERIFIED
X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1
X-Yahoo-Newman-ID: 79239.86581...@omp101.mail.ac4.yahoo.com
X-Old-Spam-Check-BY: la.mx.develooper.com
Message-ID: <519046.67736...@web59905.mail.ac4.yahoo.com>
content-type: text/plain; charset="utf-8"
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 32347 invoked by alias); 19 Jan 2009 21:00:52 -
Received: (qmail 32335 invoked from network); 19 Jan 2009 21:00:52 -
Received: from localhost (HELO la.mx.develooper.com) (127.0.0.1) by localhost
with SMTP; 19 Jan 2009 21:00:52 -
Received: (qmail 32332 invoked by alias); 19 Jan 2009 21:00:52 -
Received: from la.mx.develooper.com (HELO x1.develooper.com) (63.251.223.176)
by la.mx.develooper.com (qpsmtpd/0.28) with SMTP; Mon, 19 Jan 2009 13:00:43
-0800
Received: (qmail 32274 invoked by uid 225); 19 Jan 2009 21:00:39 -
Received: (qmail 32268 invoked by alias); 19 Jan 2009 21:00:38 -
Received: from n7a.bullet.mail.ac4.yahoo.com (HELO
n7a.bullet.mail.ac4.yahoo.com) (76.13.13.70) by la.mx.develooper.com
(qpsmtpd/0.28) with SMTP; Mon, 19 Jan 2009 13:00:30 -0800
Received: from [76.13.13.26] by n7.bullet.mail.ac4.yahoo.com with NNFMP; 19 Jan
2009 21:00:26 -
Received: from [76.13.10.160] by t3.bullet.mail.ac4.yahoo.com with NNFMP; 19
Jan 2009 21:00:26 -
Received: from [127.0.0.1] by omp101.mail.ac4.yahoo.com with NNFMP; 19 Jan 2009
21:00:26 -
Received: (qmail 68788 invoked by uid 60001); 19 Jan 2009 21:00:23 -
Received: from [87.69.10.102] by web59905.mail.ac4.yahoo.com via HTTP; Mon, 19
Jan 2009 13:00:23 PST
Delivered-To: rt-par...@x1.develooper.com
Delivered-To: bugs-par...@netlabs.develooper.com
Delivered-To: parrot...@parrotcode.org
Subject: Rakudo segfault on multi type mismatch
Return-Path:
Domainkey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
b=vaIdVkYcVtKO02cAR7uq9/MbS8ljtxxq4WmpwzjiSfkQ/yvnriLvZu7UMYdyBT6OtaAkSduMdE5XL6c5OPCarz7WeXMpl/xYNxuwtrtM6kXMvb3p7yGabrEnqNB+w2BqgFyv6PDJ6xE29LAlX2zOV6q4TS0mDngf029r3Nkio3E=;
X-Spam-Check-BY: la.mx.develooper.com
X-Old-Spam-Status: No, hits=0.0 required=8.0
tests=DK_POLICY_TESTING,DK_SIGNED,DK_VERIFIED
Date: Mon, 19 Jan 2009 13:00:23 -0800 (PST)
To: parrotbug
From: isop
X-RT-Original-Encoding: us-ascii
Following perl6 code segfaults:
multi foo($x where { $x == 5 }) { say 'yum' }
foo 8;
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: > I've done most of this in r35787, but we can't get rid of n_neg entirely > until someone updates PCT and NQP not to use it for prefix:- rules. I > poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? Pm
Re: How do I help?
fREW Schmidt wrote: > I just recently read Ovid's post on use Perl about how we can help by > fixing PUGS tests. I was a little clear on what he meant and I am a > little anxious to do something. I checked out the code for parrot > already and I am getting the pugs code while I write this. Anyone > have any ideas for stuff that's easy enough for a regular old perl5 > guy to do but boring enough not to be done? Since the tests are all written in Perl 6, you have to learn at least a bit of the language. In the pugs repo there's a file in t/TASKS that contains a list of things to be done - maybe you can start there. In case of doubt join our IRC channel (irc.freenode.org/#perl6) and ask for guidance there. Cheers, Moritz
[svn:parrot-pdd] r35789 - in trunk: docs/pdds languages/perl6 src
Author: infinoid Date: Mon Jan 19 22:51:44 2009 New Revision: 35789 Modified: trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/languages/perl6/Test.pm trunk/src/library.c Log: [cage] Fix some codingstd failures. Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Mon Jan 19 22:51:44 2009 @@ -822,8 +822,8 @@ class is a non-aggregate type, the _keyed_* methods should throw an exception. If you do not implement the *_keyed_int and *_keyed_str functions, the default -will convert the INTVAL or STRING * into a key PMC * and call the corresponding -*_keyed functions. +will convert the INTVAL or STRING * into a key PMC * and call the +corresponding *_keyed functions. =over 4
[perl #62506] Rakudo segfault on missing method
# New Ticket Created by I Sop # Please include the string: [perl #62506] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62506 > Following perl6 code segfaults with r31857: say 8.bla;
[perl #62504] Rakudo segfault on multi type mismatch
# New Ticket Created by I Sop
# Please include the string: [perl #62504]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62504 >
Following perl6 code segfaults:
multi foo($x where { $x == 5 }) { say 'yum' }
foo 8;
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
Darren Duncan wrote:
1. What we *should* be doing with the Prelude, like with STD.pm, is
write under the assumption that the implementation is also written in
Perl 6.
We should write the Prelude in as declarative a manner as possible,
saying *what* we want to happen rather than how, such as you do when
writing in a functional language.
We should make use of Perl's higher-level tools like hyper-operators and
reduce-operators etc and write in a fashion that is developer focused,
same as writing normal Perl 6.
I do agree that a prelude.pm should be written atas higher level as
possible, but I would not that Perl6 is not a "declarative" language.
Using the most powerful operators available (I'd like to see more of
them) is about the best you can do: as soon at you start using
codeblocks to define things, you get beyond the realm where compile-time
analysis is possible in a dynamic language.
Lets imagine I want to define a "sqrt($x)" function in a declarative
style in perl6 (and lets image we've defined a Real type with
Real::Epsilon being the precision of the representation). The
declarative version of sqrt must say to find a value within the set of
Real numbers that, when squared, is closest to $x:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
(This assumes that Array::min will one day accept a code-block, just
like grep, to define the property of the input list to be minimized).
The code would give a correct answer (the positive sqrt), and is written
as a fairly direct implementation of the declarative formulation. What
I'm not so sure of is that it would be a good way to write prelude.pm:
running the test suite would probably take quite a while.
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
Re: New perl6 wiki
Hi, dev.null.box wrote: > Yes, yes, i know. There is an official perl6 wiki. But, i think a more > "friendly" wiki is needed, so i just started a new mediawiki one in > http://perl6.wikia.com I appreciate your effort, and at the same time I'd like to ask you (and your fellow contributor(s)) to actually test what you write, whenever possible. For example on http://perl6.wikia.com/wiki/Array I found at least three errors that could have easily been trapped by running the examples in Rakudo (or pugs, for that matter). Cheers, Moritz
Re: How do I help?
> Since the tests are all written in Perl 6, you have to learn at least a > bit of the language. I figured that; I just wanted to start off with perl6 before I did anything in PIR. > In the pugs repo there's a file in t/TASKS that contains a list of > things to be done - maybe you can start there. In case of doubt join our > IRC channel (irc.freenode.org/#perl6) and ask for guidance there. I'll see if I can take care of some of these. The one that looks like I could learn a lot from and definitely do is the one where you test builtin functions with named parameters as most of these having been tested that way yet. I hope it helps! -- -fREW
