.join on Array
Following up to a thread on p6c regarding method fallbacks and .join:
* What should [1,3,5].join('-') produce?
* How about ([1,3,5], 20).join('-') ?
Thanks!
Pm
Re: .join on Array
Patrick R. Michaud wrote:
> Following up to a thread on p6c regarding method fallbacks and .join:
>
> * What should [1,3,5].join('-') produce?
I'm pretty sure it should be '1-3-5', because [1,3,5] is an Array ref
> * How about ([1,3,5], 20).join('-') ?
Probably the same as (~[1,3,5], 20).join('-')
> Thanks!
>
> Pm
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
[PATCH] json reimplemented with pct
without any internet connection at home you get really bored. that means, time for some fun :-) Included is a patch that implements JSON with the PCT. As JSON is just a data description (sub) language, I was not sure what the TOP rule should contain; I decided for now that it would be just * Running the pct-based JSON language, just input some string on the command line, like [1, 2, 3], and the output is dumped to stdout. kjs json_pct.patch Description: Binary data
Rakudo test miscellanea
This is a more or less random collection of thoughts and questions about
the rakudo testing infrastructure.
First of all I feel that it's in a rather good shape.
I put up a chart of number of tests on http://rakudo.de/ and plan to
update it regularly (via cron job once the admin installs Text::CSV_XS).
"make localtest" is very handy, among other things for fudging new test
files.
But it would be useful to have an option that makes localtest more
verbose. Specifically if a script dies, it's not obvious after which
test it died. Is there an easy way to pass an option for more verbosity?
Or should we introduce localtest-verbose make target?
I have two scripts in my local tools/ directory, both of which aren't
platform independent (only tested on linux so far). One writes a patch
for automagically unfudging tests (aka autounfudge.pl), the other
generates the chart on rakudo.de. What should I do with them? Are they
of general interest, and should live in the parrot repo? if yes, should
I send patches and ask for testing on other platforms before adding? Or
should I put them somewhere else (pugs repo, entirely different repo,
whatever)
isa_ok in pugs and rakudo seem to work differently. Many tests call
isa_ok with a string as the second argument:
isa_ok(0, 'Int');
while rakudo only understands the bare type name:
isa_ok(0, Int);
It seems to me that the latter is more intuitive, but I'd still like
some feedback before changing the tests on a larger scale.
There seems to be a thorough confusion about numeric types. for example
some tests read like this: is (1.1).WHAT, 'Num'; and then in a different
file is (1.1).WHAT, 'Rat'; That raises two questions for me
1) should we test for the value of .WHAT at all (unless for testing WHAT
of course)? It seems to me that a compiler should have the freedom to
return a different subtype (for example 1 could be a PositiveInt as long
as PositiveInt is an Int; that's a contrived example, but you get the
picture)
2) How do we know which numeric type is a class and which is a role? Is
there an explicit spec about the types of number literals? That could
have some impact on type checking in the tests. (Maybe I should prod p6l
with that).
I've attached a list of skip messages from spectest_regression, roughly
sorted into categories, some messages commented by me (in parenthesis).
Finally I'd like to point out some annoyances with rakudo. It's rather
frustrating (for example while fudging a large test file) to get an
error message that can't easily be mapped to a location in the source file.
The two most frequent ones are the Null PMC access in the type checker
(as reported by Ovid), and "Method 'lvalue' not found for invocant of
class 'PAST::Stmts'", which I finally tracked down to ($x, $y) = (1, 2).
The latter seems to fit into the category "not yet implemented". If it
is indeed, it would be nice to have it fail with line number information
(I guess the various Past:: nodes already have line information attached
- would it be possible to print that whenever something fails that
involves Past nodes? Perhaps that information wouldn't be too accurate,
but it's already a success if I know which part of the file I should be
looking at).
Sorry for being a bit lengthy, I'd welcome any comments.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Feature
4 skipped: calling postcircumfix:<()> with a dot
9 skipped: whatever star
1 skipped: whatever star not implemented
7 skipped: prefix:<\>
21 skipped: prefix:<\> not implemented
4 skipped: int, num, undef assign not implemented
1 skipped: Can't compare to undef (?)
3 skipped: {} hash composer not implemented
6 skipped: eqv and {} as hash composer not implemented
1 skipped: @() should be the same as @($/)
9 skipped: CATCH blocks not implemented
4 skipped: No pointy blocks on while loops yet
20 skipped: method fallback to sub unimpl
100 skipped: No method unpolar yet
20 skipped: No method unpolar
5 skipped: promote Int to Num
2 skipped: colon invocant syntax
2 skipped: no hashes at the moment
18 skipped: adverbial closure
6 skipped: adverbial closure
2 skipped: adverbial closure
5 skipped: adverbial closure
2 skipped: method fallback unimplemented
12 skipped: colon invocant syntax
1 skipped: %p doesn't yet throw exception
3 skipped: Inf and NaN not yet implemented
6 skipped: module Num not implemented
2 skipped: NaN not implemented
42 skipped: can't parse pi (actually exp() and prefix:<-> for Complex)
1 skipped: unicode
2 skipped: unicode
2 skipped: unicode
Bugs
2 skipped: lexicals bug RT#56184
4 skipped: weird errors
2 skipped: underscores cause weird IMCC errors
3 skipped: type checking bug
4 skipped: try{} does not keep test from failing
1 skipped: zip and @@ are broken
1 skipped: test passes but Parrot bug gets in the way
1 skipped: Arit
Re: [perl #56230] [PATCH] Multimethods for Complex.
Another question: Vasily Chekalkin (via RT) wrote: > +.sub 'sqrt' :multi(Complex) > +.param pmc a > +a = sqrt a > +.return (a) > +.end Do we actually want a sqrt(Complex)? Somebody who is sufficiently mathematically educated to work with complex numbers should now that sqrt() is ambigous, because there are two possible results, and will revert to roots() for that. Any thoughts? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[svn ci] :lexid(...)
Hi,
So before, this would not work out because it found the wrong outer:
--
.sub main
outer()
.end
.namespace [ 'Foo' ]
.sub outer
say "oops"
.end
.namespace []
.sub outer
$P0 = new 'Integer'
$P0 = 42
.lex '$a', $P0
test()
.end
.sub test :outer('outer')
$P0 = find_lex '$a'
say $P0
.end
--
Now with :lexid, we can mark the subs and use it to refer to them in
outer (note that :lexid defaults to the sub name, so this change is
backward compatible):
--
.sub main
outer()
.end
.namespace [ 'Foo' ]
.sub outer :lexid('foo')
say "oops"
.end
.namespace []
.sub outer :lexid('bar')
$P0 = new 'Integer'
$P0 = 42
.lex '$a', $P0
test()
.end
.sub test :outer('bar')
$P0 = find_lex '$a'
say $P0
.end
--
This gives 42, which is The Answer, so all must be good. (Apart from my
sanity, after hacking on IMCC...)
No new failing tests in Parrot nor Rakudo spectest_regression. In as r28710.
Hope this is what's needed,
Jonathan
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 11:36:05AM +0200, Moritz Lenz wrote: > This is a more or less random collection of thoughts and questions about > the rakudo testing infrastructure. > > First of all I feel that it's in a rather good shape. I agree -- it's looking better all of the time. Many thanks to you, Auzon, and particle for the excellent work! > I put up a chart of number of tests on http://rakudo.de/ and plan to > update it regularly (via cron job once the admin installs Text::CSV_XS). Shiny! I'll make good use of the charts :-). > [...] it would be useful to have an option that makes localtest more > verbose. Specifically if a script dies, it's not obvious after which > test it died. I'm not exactly sure what is meant here -- do you want to know which test file died, or a specific test in the test file? Isn't that normally produced by the test harness summary? (It is on my system.) > I have two scripts in my local tools/ directory, both of which aren't > platform independent (only tested on linux so far). One writes a patch > for automagically unfudging tests (aka autounfudge.pl), the other > generates the chart on rakudo.de. What should I do with them? I think they can go in the tools/ subdirectory for now. > isa_ok in pugs and rakudo seem to work differently. Many tests call > isa_ok with a string as the second argument: > isa_ok(0, 'Int'); > while rakudo only understands the bare type name: > isa_ok(0, Int); > It seems to me that the latter is more intuitive, but I'd still like > some feedback before changing the tests on a larger scale. I can't find any examples in the Synopses where a string is used for 'isa' testing... but I can also see why we'd want to allow strings. I think we need clarification from p6l here. > There seems to be a thorough confusion about numeric types. for example > some tests read like this: is (1.1).WHAT, 'Num'; and then in a different > file is (1.1).WHAT, 'Rat'; That raises two questions for me > 1) should we test for the value of .WHAT at all (unless for testing WHAT > of course)? It seems to me that a compiler should have the freedom to > return a different subtype (for example 1 could be a PositiveInt as long > as PositiveInt is an Int; that's a contrived example, but you get the > picture) > 2) How do we know which numeric type is a class and which is a role? Is > there an explicit spec about the types of number literals? That could > have some impact on type checking in the tests. (Maybe I should prod p6l > with that). This is another place where we probably need guidance from p6l. > I've attached a list of skip messages from spectest_regression, roughly > sorted into categories, some messages commented by me (in parenthesis). Excellent. Note that the tools/test_summary.pl script also produces the skip messages from spectest_regression, and I'll likely add todo messages shortly. > Finally I'd like to point out some annoyances with rakudo. It's rather > frustrating (for example while fudging a large test file) to get an > error message that can't easily be mapped to a location in the source file. > [...] > I guess the various Past:: nodes already have line information attached > - would it be possible to print that whenever something fails that > involves Past nodes? Reporting line number information for errors at runtime is RT#53082, which in turn currently depends on RT#43269. I don't have a feeling that setline/setfile will be fixed in Parrot anytime soon, which means that we probably need to come up with a workaround for PAST. I'm also waiting for an opportunity to refactor PGE to use Cursor objects, which will be able to more efficiently compute line number information for the PAST nodes. Otherwise we end up doing a lot of redundant calculation for line numbers, (which can get expensive on utf8 strings in Parrot). Thanks! Pm
Re: Rakudo test miscellanea
Patrick R. Michaud wrote: > On Thu, Jun 26, 2008 at 11:36:05AM +0200, Moritz Lenz wrote: >> [...] it would be useful to have an option that makes localtest more >> verbose. Specifically if a script dies, it's not obvious after which >> test it died. > > I'm not exactly sure what is meant here -- do you want to know which > test file died, or a specific test in the test file? The latter. > Isn't that > normally produced by the test harness summary? (It is on my system.) I'll check on a system with newer perl + Test::Harness. >> I have two scripts in my local tools/ directory, both of which aren't >> platform independent (only tested on linux so far). One writes a patch >> for automagically unfudging tests (aka autounfudge.pl), the other >> generates the chart on rakudo.de. What should I do with them? > > I think they can go in the tools/ subdirectory for now. Ok, I'll commit them later today. >> isa_ok in pugs and rakudo seem to work differently. Many tests call >> isa_ok with a string as the second argument: >> isa_ok(0, 'Int'); >> while rakudo only understands the bare type name: >> isa_ok(0, Int); >> It seems to me that the latter is more intuitive, but I'd still like >> some feedback before changing the tests on a larger scale. > > I can't find any examples in the Synopses where a string is used > for 'isa' testing... but I can also see why we'd want to allow > strings. I think we need clarification from p6l here. Ok, but as long as bare types aren't wrong I'll keep changing tests as need. If strings are explicitly allowed, we can still have a separate test for that. >> There seems to be a thorough confusion about numeric types. for example >> some tests read like this: is (1.1).WHAT, 'Num'; and then in a different >> file is (1.1).WHAT, 'Rat'; That raises two questions for me >> 1) should we test for the value of .WHAT at all (unless for testing WHAT >> of course)? It seems to me that a compiler should have the freedom to >> return a different subtype (for example 1 could be a PositiveInt as long >> as PositiveInt is an Int; that's a contrived example, but you get the >> picture) >> 2) How do we know which numeric type is a class and which is a role? Is >> there an explicit spec about the types of number literals? That could >> have some impact on type checking in the tests. (Maybe I should prod p6l >> with that). > > This is another place where we probably need guidance from p6l. > >> I've attached a list of skip messages from spectest_regression, roughly >> sorted into categories, some messages commented by me (in parenthesis). > > Excellent. Note that the tools/test_summary.pl script also produces > the skip messages from spectest_regression, and I'll likely add > todo messages shortly. That's what I used to assemble the messages, then I just re-grouped them by hand. >> Finally I'd like to point out some annoyances with rakudo. It's rather >> frustrating (for example while fudging a large test file) to get an >> error message that can't easily be mapped to a location in the source file. >> [...] >> I guess the various Past:: nodes already have line information attached >> - would it be possible to print that whenever something fails that >> involves Past nodes? > > Reporting line number information for errors at runtime is RT#53082, > which in turn currently depends on RT#43269. I don't have a feeling > that setline/setfile will be fixed in Parrot anytime soon, which means > that we probably need to come up with a workaround for PAST. > > I'm also waiting for an opportunity to refactor PGE to use Cursor > objects, which will be able to more efficiently compute line number > information for the PAST nodes. Otherwise we end up doing a lot of > redundant calculation for line numbers, (which can get expensive > on utf8 strings in Parrot). Thanks for your quick response, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 11:36:05AM +0200, Moritz Lenz wrote: > There seems to be a thorough confusion about numeric types. for example > some tests read like this: is (1.1).WHAT, 'Num'; and then in a different > file is (1.1).WHAT, 'Rat'; That raises two questions for me > 1) should we test for the value of .WHAT at all (unless for testing WHAT > of course)? It seems to me that a compiler should have the freedom to > return a different subtype (for example 1 could be a PositiveInt as long > as PositiveInt is an Int; that's a contrived example, but you get the > picture) Right, it's hard to imagine that ever being a correct test. It should probably be using ~~ Num etc. > 2) How do we know which numeric type is a class and which is a role? Is > there an explicit spec about the types of number literals? That could > have some impact on type checking in the tests. (Maybe I should prod p6l > with that). You can't instantiate a role so they're pretty much all classes I think. The only role that I saw specced was Order, and Num does Order so all Num types inherit that. Complex is its own type separate from Num, and everything else descends from Num. See docs/p6types in pugs, it's meant to answer these questions :) -ryan
Type of literals
In the test suite there are some tests like this: is(1.WHAT, 'Int', '1 as a literal is an Int); This seems to imply that we guarantee the direct type of literals. But do we? Actually I see no need for that. All my programs work fine if the literal 1 is of type Foo, and Foo isa Int. What's our policy on that? Will a 1.WHAT always return Int? do we guarantee (1..4).WHAT always to be 'Range'? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
(cross-posting to p6l) Ryan Richter wrote: > On Thu, Jun 26, 2008 at 11:36:05AM +0200, Moritz Lenz wrote: >> 2) How do we know which numeric type is a class and which is a role? Is >> there an explicit spec about the types of number literals? That could >> have some impact on type checking in the tests. (Maybe I should prod p6l >> with that). > > You can't instantiate a role so they're pretty much all classes I think. > The only role that I saw specced was Order, and Num does Order so all > Num types inherit that. Complex is its own type separate from Num, and > everything else descends from Num. See docs/p6types in pugs, it's meant > to answer these questions :) Thanks for the effort, but it also raises new questions. For example: > Int is Num Rakudo doesn't do it that way, because the 'A is B' relation in OO means "Every instance of A is also an Instance of B", which certainly isn't the case with Ints. Int is more like a subset of Num. Which made me think, shouldn't Num be a role? and then 3.14 would be a Rat or a Float or whatever, 42 would be an Int, and Int does Num Rat does Num That way a compiler that only implements classes and roles (and no subset types) can get the hierarchy of numeric types right. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 10:23 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > Thanks for the effort, but it also raises new questions. For example: >> Int is Num > Rakudo doesn't do it that way, because the 'A is B' relation in OO means > "Every instance of A is also an Instance of B", which certainly isn't > the case with Ints. Int is more like a subset of Num. Huh? If Int is a subset of Num, then every instance of Int *is* also an instance of Num. That's what subset means... Maybe you mean they are disjoint types in the type system, but the set of numerical values of all possible Ints is a subset of the set of numerical values of all possible Nums? But then how is type compatibility obtained? > Which made me think, shouldn't Num be a role? and then 3.14 would be a > Rat or a Float or whatever, 42 would be an Int, and > Int does Num > Rat does Num But Int should do Rat, too... > That way a compiler that only implements classes and roles (and no > subset types) can get the hierarchy of numeric types right. ...assuming it's a hierarchy in the first place. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Rakudo test miscellanea
Mark J. Reed wrote: > On Thu, Jun 26, 2008 at 10:23 AM, Moritz Lenz > <[EMAIL PROTECTED]> wrote: >> Thanks for the effort, but it also raises new questions. For example: >>> Int is Num >> Rakudo doesn't do it that way, because the 'A is B' relation in OO means >> "Every instance of A is also an Instance of B", which certainly isn't >> the case with Ints. Int is more like a subset of Num. > > Huh? If Int is a subset of Num, then every instance of Int *is* also > an instance of Num. That's what subset means... Uhm, yes. I was confused, sorry. > Maybe you mean they are disjoint types in the type system, but the set > of numerical values of all possible Ints is a subset of the set of > numerical values of all possible Nums? But then how is type > compatibility obtained? > >> Which made me think, shouldn't Num be a role? and then 3.14 would be a >> Rat or a Float or whatever, 42 would be an Int, and >> Int does Num >> Rat does Num > > But Int should do Rat, too... > >> That way a compiler that only implements classes and roles (and no >> subset types) can get the hierarchy of numeric types right. > > ...assuming it's a hierarchy in the first place. What's the alternative? I don't think it's a good idea to special-case numeric types, and I don't think it's a good idea to define multis for each numeric type either. I assume that 'Num' is meant to be a non-complex. Then it seems to make sense to assume: Int is Rat Rat is Num Num is Complex or am I off again? Anyway, for our work in the test suite it would be nice to have it specced somewhere. Or should I rely on Ryan's docs/p6types? If so, it would be nice to convert it to format that can smartlinked to. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
# New Ticket Created by Will Coleda # Please include the string: [perl #56382] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56382 > I wanted to open a new ticket on this so discussion regarding how we get this in place for smolder is separate from smolder itself. The most expedient solution to getting this working is to simply bundle TH3 with parrot, as we do for other non-core modules we must rely on. I am wondering if it would not be better to more specifically declare our dependencies so we can avoid backsliding on our goal of eliminating CPAN modules from our repository. We have the following types of parrot builders: 1) Those that install from CPAN. This means a pretty trivial dependency listing. 2) Those that install from a package The package builder already has to depend on perl, they can depend on other modules as well. 3) Developers We already have Bundle::Parrot for developers; moving another item into that Bundle shouldn't be an issue. 4) ... everyone else. For someone grabbing a version of parrot off the website (especially if we ever host them away from CPAN) isn't going to have any easy hooks for following dependencies. However, we can just add this as a probe during Configure.pl; if we find any dependencies that are not available with the perl we're running as, we can print out a nice, helpful diagnostic about the minimum required version of the module. (I recommend a single probe that checks for all the perl dependencies for the build. If any modules required for building are missing, die. If any modules used in testing are missing, only warn, and conditionalize all the tests to handle the lack of the module gracefully.) (This step would probably have to be one of the first steps run, since I see File::Which is used during configure.) -- If we went this route, we could avoid including T:H3, and also remove any of the remaining modules we bundle in lib/ Comments? -- Will "Coke" Coleda
Re: Rakudo test miscellanea
In a message dated Thu, 26 Jun 2008, Moritz Lenz writes: I assume that 'Num' is meant to be a non-complex. Then it seems to make sense to assume: Int is Rat Rat is Num Num is Complex or am I off again? S29 seems to have been assuming this, if I'm reading the multis correctly. -- Trey Harris http://www.lopsa.org/ President, LOPSA -- The League of Professional System Administrators Opinions expressed above are not necessarily those of LOPSA.
Re: Rakudo test miscellanea
Trey Harris wrote: > In a message dated Thu, 26 Jun 2008, Moritz Lenz writes: >> I assume that 'Num' is meant to be a non-complex. >> Then it seems to make sense to assume: >> Int is Rat >> Rat is Num >> Num is Complex >> or am I off again? > > S29 seems to have been assuming this, if I'm reading the multis correctly. If it assumed that, why would exp() be defined in class Num, instead of the more general class Complex? It would also imply that the method polar, which is defined in Complex, is available for all other numbers. Don't know if that's intended. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 10:40:53AM -0400, Trey Harris wrote: > In a message dated Thu, 26 Jun 2008, Moritz Lenz writes: > >I assume that 'Num' is meant to be a non-complex. > >Then it seems to make sense to assume: > >Int is Rat > >Rat is Num > >Num is Complex > >or am I off again? > > S29 seems to have been assuming this, if I'm reading the multis correctly. Keep in mind that some of S29's assumptions regarding types may no longer be true, especially since we've decided that many of the builtin methods and functions will now go in "Any" (e.g., C). Pm
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 04:50:21PM +0200, Moritz Lenz wrote: > What's the alternative? > I don't think it's a good idea to special-case numeric types, and I > don't think it's a good idea to define multis for each numeric type either. > > I assume that 'Num' is meant to be a non-complex. > Then it seems to make sense to assume: > Int is Rat > Rat is Num > Num is Complex > or am I off again? Yeah, that looks sane. I should probably put Int under Rat in p6types, and maybe Num under Complex. I believe an implementation can choose to do the inheritance either way: Rat is Num Rat is Any does Num Since both of those end up looking the same to the user, more or less. I tended to use the first form in p6types. > Anyway, for our work in the test suite it would be nice to have it > specced somewhere. Or should I rely on Ryan's docs/p6types? If so, it > would be nice to convert it to format that can smartlinked to. Since it's unofficial and (in theory) just repeats what's in the synopses I don't think tests should refer to it. Or someone could make an S30 (Standard perl library) out of it. -ryan
Re: Rakudo test miscellanea
Moritz Lenz> 3.14 would be a Rat or a Float or whatever That's a good question, actually. Does the literal "3.14" get turned into a Float or a Rat? Float is probably simplest, and matches what e.g. Lisp does, but you could argue either way. Especially since many exact decimal literals become approximations in binary... -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 04:50:21PM +0200, Moritz Lenz wrote: : I assume that 'Num' is meant to be a non-complex. : Then it seems to make sense to assume: : Int is Rat : Rat is Num : Num is Complex : or am I off again? Well, there's this little thing called Liskov substitutability... Neither "is" nor "does" is quite right here, because the mathematicians have seen fit to confuse representation semantics with value semantics. :) I think what we want is something more like Int as Rat Rat as Num Num as Complex where "as" means, A is not a B because it limits the methods that can be applied, and A doesn't do B because it doesn't have the right native representation internally, but A can be used as a B by explicit conversion to a value that either is or does B. This declaration implies the existence of Rat(Int), Num(Rat), and Complex(Num) functions and/or methods, as well as the authorization for any such inferior A type to advertise itself as doing B, where the VM somehow sneaks in the appropriate conversion for us if we actually try to pass an Int to a Rat. An interesting question arises as to whether "as" should be considered transitive, or do we have to say Int as Rat as Num as Complex Rat as Num as Complex Num as Complex to avoid long chains of accidental conversions. One can argue both sides of that: on the one hand, you don't want for type A to have to worry about things regarding type C that are type B's bailiwick. On the other hand, transparency of code suffers under transitive coercion, and the syntax above is no great hardship. Plus we could always add something spectacularly explicit like Int as (Rat.as) if people decide they give one. ;) Larry
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 12:45:39PM -0400, Mark J. Reed wrote: : Moritz Lenz> 3.14 would be a Rat or a Float or whatever : : That's a good question, actually. Does the literal "3.14" get turned : into a Float or a Rat? Float is probably simplest, and matches what : e.g. Lisp does, but you could argue either way. Especially since many : exact decimal literals become approximations in binary... The internal representation of Num is opaque, and Num is allowed to keep some subset of its values in Rat form internally and only convert to floating point lazily when some operation is performed that makes more sense in floating point than in rationals. For some applications you might like to pragmatically enforce that Nums stay in Rat format to some particular fractional value, such as when calculating in fractional currency. The num type, on the other hand, is purely floating-point. We could go as far as to guarantee that Nums do rational arithmetic out to a certain point, but probably what the financial insitutions want is special fixed-point types that assume a divisor anyway. Would any financial institution care to comment? Larry
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 09:55:09AM -0700, Larry Wall wrote: > We could go as far as to guarantee that Nums do rational arithmetic > out to a certain point, but probably what the financial insitutions > want is special fixed-point types that assume a divisor anyway. > Would any financial institution care to comment? IANAFI, but I think that's more or less right. I think they actually tend to use BCD. http://www2.hursley.ibm.com/decimal/decifaq1.html#inexact -ryan
Re: Type of literals
On Thu, Jun 26, 2008 at 04:03:42PM +0200, Moritz Lenz wrote: : In the test suite there are some tests like this: : is(1.WHAT, 'Int', '1 as a literal is an Int); : : This seems to imply that we guarantee the direct type of literals. But : do we? : : Actually I see no need for that. All my programs work fine if the : literal 1 is of type Foo, and Foo isa Int. : : What's our policy on that? Will a 1.WHAT always return Int? do we : guarantee (1..4).WHAT always to be 'Range'? I don't see much problem with the direct type. While we can use any value as a type in a signature, it's really a subset type in that case, and subset types are never reported by WHAT because objects are officially stored in their standard representation for their base type. (Optimizers can cheat, of course.) So True.WHAT is Bool, but True is really a subset of Bool, because (False,True) is an enum of Bool, and enums are subset types. The optimizer is free to deduce that True and False don't really need a bit to represent them, but a Bool is naturally represented as a bit, so that is the offical base type of anything boolean. Likewise just because 1.WHAT returns Int doesn't mean the compiler has to represent 1 the same way it represents 42. But it wants to look that way from the viewpoint of the programmer, who pines for an occasional smattering of foolish consistency. Larry
Re: Rakudo test miscellanea
> "RR" == Ryan Richter <[EMAIL PROTECTED]> writes: RR> On Thu, Jun 26, 2008 at 09:55:09AM -0700, Larry Wall wrote: >> We could go as far as to guarantee that Nums do rational arithmetic >> out to a certain point, but probably what the financial insitutions >> want is special fixed-point types that assume a divisor anyway. >> Would any financial institution care to comment? RR> IANAFI, but I think that's more or less right. I think they actually RR> tend to use BCD. RR> http://www2.hursley.ibm.com/decimal/decifaq1.html#inexact but a rat with a divisor of 100 (or 1000 even) should be fine for their needs. bcd is a pain (i write one in the distant past for PL/I). i once even offered to redo it (and i partially started it) for parrot. so if anyone really wants a fast bcd math lib which can handle arbitrary size and precision, and wants to take it over, let me know. i already have add/subtract working and the designs for * and / are there. just needs more coding in c. i don't have the time, focus and incentive to work on it. a fun and smallish project for anyone with the right interest. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Rakudo test miscellanea
Most financial institutions don't use float, rational or fixed point, they just keep integer pennies. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Larry Wall <[EMAIL PROTECTED]> > Would any financial institution care to comment? > > Larry
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 09:46:25AM -0700, Larry Wall wrote: : the VM somehow sneaks in the appropriate conversion for us if we : actually try to pass an Int to a Rat. I'd point out that this is fundamentally the same decision point that is reached when we want to do boxing, because we basically have int as Int num as Num complex as Complex to manage the representation change. Larry
Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On Thursday 26 June 2008 07:37:46 Will Coleda wrote: > If we went this route, we could avoid including T:H3, and also remove > any of the remaining modules we bundle in lib/ > > Comments? T::H 3 is only a requirement for people who want to type 'make smolder' (and eventually I hope 'make smoke'), so probing for it without bundling it seems eminently sensible to me. -- c
Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
chromatic wrote: > T::H 3 is only a requirement for people who want to type 'make smolder' (and > eventually I hope 'make smoke'), so probing for it without bundling it seems > eminently sensible to me. Agreed. That's what we do with TAP::Harness::Archive. -- Michael Peters Plus Three, LP
Re: Rakudo test miscellanea
On Thu, Jun 26, 2008 at 1:31 PM, <[EMAIL PROTECTED]> wrote: > Most financial institutions don't use float, rational or fixed point, they > just keep integer pennies. I'm not so sure about that. There are lots of financial transactions that deal in sub-$0.01 fractions: taxes, currency conversion, brokerage stuff... -- Mark J. Reed <[EMAIL PROTECTED]>
[perl #38194] [TODO] build - optimize pmc2c.pl
On #parrot I had some discussion about tools/build/pmc2c.pl with bacek and DietCoke. I pasted some output from dprofpp: http://nopaste.snit.ch/13401 http://nopaste.snit.ch/13402 On the basis of these pastes, I was advised to consider using Memoize.pm to memoize the most frequently called functions in the modules underlying pmc2c.pl. However, my preliminary investigation suggests that Memoize is not a good bet here. As I understand Memoize, it is useful in circumstances where you have to have to call a function repeatedly and where there's a high probability that you will call it with the same arguments more than once. Memoize caches the return value associated with a particular set of arguments. But Memoize will only be worth the effort if the time you save by doing cache lookups rather than function calls is greater than the time needed to load Memoize.pm and memoize the function in the first place. But the functions in the modules underlying pmc2c.pl are not this sort of functions. They tend to be OO methods that change the internal state of the object. They tend not to have meaningful return values (i.e., return values other than truth, falseness, undef, etc.) So my hunch is that Memoize is not likely to be useful here -- but I would welcome any cases to the contrary that anyone might cite. Thank you very much. kid51
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
On Thu, Jun 26, 2008 at 2:50 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > On #parrot I had some discussion about tools/build/pmc2c.pl with bacek > and DietCoke. I pasted some output from dprofpp: > > http://nopaste.snit.ch/13401 > http://nopaste.snit.ch/13402 > > On the basis of these pastes, I was advised to consider using Memoize.pm > to memoize the most frequently called functions in the modules > underlying pmc2c.pl. > > However, my preliminary investigation suggests that Memoize is not a > good bet here. As I understand Memoize, it is useful in circumstances > where you have to have to call a function repeatedly and where there's a > high probability that you will call it with the same arguments more than > once. Memoize caches the return value associated with a particular set > of arguments. But Memoize will only be worth the effort if the time you > save by doing cache lookups rather than function calls is greater than > the time needed to load Memoize.pm and memoize the function in the first > place. > > But the functions in the modules underlying pmc2c.pl are not this sort > of functions. They tend to be OO methods that change the internal state > of the object. They tend not to have meaningful return values (i.e., > return values other than truth, falseness, undef, etc.) In that case, Memoize will not help, you're absolutely right. (Might be worth seeing if the code is amenable to a refactor that -would- be amenable to this, but that's probably more work.) > So my hunch is that Memoize is not likely to be useful here -- but I > would welcome any cases to the contrary that anyone might cite. > > Thank you very much. > kid51 > > -- Will "Coke" Coleda
Re: [perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
On Sun, Jun 22, 2008 at 10:35 PM, Will Coleda via RT
<[EMAIL PROTECTED]> wrote:
> Attached find a first pass at converting our perlcritic.t into using
> Test::Perl::Critic.
>
> This patch:
>
> - requires Test::Perl::Critic to do anything useful with the test. (We can
> add it to
> Bundle::Parrot)
> - creates a new perlcritic.conf file that represents declaratively a large
> chunk of the code we
> used to use to manage the policy list.
> - removes the ability to list the policies. (you have the conf file)
> - removes the ability to specify a specific policy (you can roll your own
> with themes)
> - removes the ability to specify a directory to run the policies against (but
> if we do, let's do it
> without File::Find, and just key off the MANIFEST like we do now.)
> - keeps the ability to specify a "group" of tests, but calls it a theme,
> following the lead set by
> Perl::Critic.
> - reports each file as a test, not each policy.
>
> I think the last item there is a big reason we started down the path we did,
> but given how
> much simpler this script is, I don't think it's worth worrying about.
>
> I've tested this on Perl::Critic 1.086; I'd be interested to hear feedback on
> older versions of
> P::C before I apply. (The old version I had installed is no longer available
> for easy download
> on the CPAN)
>
> Feedback in general, as well: This is a reduction in features from the
> original version, but I
> think it's a step forward.
It's been 4 days with no negative feedback; I'll plan on applying the
patch this weekend.
> --
> Will "Coke" Coleda
>
> Index: tools/util/perlcritic.conf
> ===
> --- tools/util/perlcritic.conf (revision 0)
> +++ tools/util/perlcritic.conf (revision 0)
> @@ -0,0 +1,65 @@
> +verbose = 3
> +
> +[BuiltinFunctions::ProhibitStringySplit]
> +add_themes = parrot
> +
> +[CodeLayout::ProhibitDuplicateCoda]
> +add_themes = parrot
> +
> +[CodeLayout::ProhibitHardTabs]
> +allow_leading_tabs = 0
> +add_themes = parrot
> +
> +[CodeLayout::ProhibitTrailingWhitespace]
> +add_themes = parrot
> +
> +[CodeLayout::RequireTidyCode]
> +perltidyrc = tools/util/perltidy.conf
> +add_themes = extra
> +
> +[CodeLayout::UseParrotCoda]
> +add_themes = parrot
> +
> +[InputOutput::ProhibitBarewordFileHandles]
> +add_themes = parrot
> +
> +[InputOutput::ProhibitTwoArgOpen]
> +add_themes = parrot
> +
> +[NamingConventions::ProhibitAmbiguousNames]
> +# remove abstract from the list of forbidden names
> +forbid = bases close contract last left no record right second set
> +add_themes = extra
> +
> +[Subroutines::ProhibitBuiltinHomonyms]
> +add_themes = extra
> +
> +[Subroutines::ProhibitExplicitReturnUndef]
> +add_themes = parrot
> +
> +[Subroutines::ProhibitSubroutinePrototypes]
> +add_themes = parrot
> +
> +[Subroutines::RequireFinalReturn]
> +add_themes = extra
> +
> +[TestingAndDebugging::MisplacedShebang]
> +add_themes = parrot
> +
> +[TestingAndDebugging::ProhibitShebangWarningsArg]
> +add_themes = parrot
> +
> +[TestingAndDebugging::RequirePortableShebang]
> +add_themes = parrot
> +
> +[TestingAndDebugging::RequireUseStrict]
> +add_themes = parrot
> +
> +[TestingAndDebugging::RequireUseWarnings]
> +add_themes = parrot
> +
> +[Variables::ProhibitConditionalDeclarations]
> +add_themes = parrot
> +
> +[Bangs::ProhibitFlagComments]
> +add_themes = extra
> Index: MANIFEST
> ===
> --- MANIFEST(revision 28654)
> +++ MANIFEST(working copy)
> @@ -1,7 +1,7 @@
> # ex: set ro:
> # $Id$
> #
> -# generated by tools/dev/mk_manifest_and_skip.pl Sun Jun 22 17:10:01 2008 UT
> +# generated by tools/dev/mk_manifest_and_skip.pl Mon Jun 23 02:21:20 2008 UT
> #
> # See tools/dev/install_files.pl for documentation on the
> # format of this file.
> @@ -3888,6 +3888,7 @@
> tools/util/dump_pbc.pl []
> tools/util/gen_release_info.pl []
> tools/util/ncidef2pasm.pl []
> +tools/util/perlcritic.conf []
> tools/util/perltidy.conf[]
> tools/util/pgegrep []
> tools/util/release.json []
> Index: t/codingstd/perlcritic.t
> ===
> --- t/codingstd/perlcritic.t(revision 28654)
> +++ t/codingstd/perlcritic.t(working copy)
> @@ -1,256 +1,54 @@
> #! perl
> -# Copyright (C) 2001-2007, The Perl Foundation.
> +# Copyright (C) 2008, The Perl Foundation.
> # $Id$
>
> use strict;
> use warnings;
>
> -use lib qw(. lib ../lib ../../lib);
> +use lib qw{lib};
>
> -use Fatal qw(open);
> -use File::Find;
> use File::Spec;
> -use Test::More;
> -use Parrot::Config qw{%PConfig};
> -use Parrot::Distribution;
> use Getopt::Long;
> +use Parrot::Config qw(%PConfig);
> +use Parrot::Distribut
[perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
FWIW, the part of the patch pertaining to t/codingstd/perlcritic.t did not apply cleanly when I tried it on Linux. That may just indicate that the guts have been ripped out of that file and replaced with mostly new code. Perhaps you could post the complete text of your new version of that file? Thank you very much. kid51
Re: Type of literals
Qui, 2008-06-26 às 16:03 +0200, Moritz Lenz escreveu: > In the test suite there are some tests like this: > is(1.WHAT, 'Int', '1 as a literal is an Int); > This seems to imply that we guarantee the direct type of literals. But > do we? > Actually I see no need for that. All my programs work fine if the > literal 1 is of type Foo, and Foo isa Int. > What's our policy on that? Will a 1.WHAT always return Int? do we > guarantee (1..4).WHAT always to be 'Range'? This is something I've been thinking about for some time. $a.WHAT is the way to test for type identity, but allowing the user to expect a literal to be from a specific given type is probably a bad idea, because (1..4).WHAT should probably be ImplementationSpecificConstantCompactIntRange or something like that. But I really think it's a matter of user expectations, if we define that the effective type of the literals are undetermined, the implementations will be free to use optimized types. I think we should promote (1..4) ~~ Range test, instead of (1..4).WHAT === Range or even (1..4).WHAT eq 'Range' daniel
Re: [perl #56346] [PATCH] Check for valid conditions in debug opcodes
More refactor: in addition to the changes in the previous, this also
moves the PDB_extend_const_table from src/debug.c to
compilers/imcc/pbc.c, because is the only file that uses it and seems
to not be related to the debugger (historical reasons?), renames it
and makes it static, and add a few auxiliar functions to clean his
usage.
--
Salu2
Index: src/ops/debug.ops
===
--- src/ops/debug.ops (revisión: 28719)
+++ src/ops/debug.ops (copia de trabajo)
@@ -44,15 +44,7 @@
=cut
op debug_init() :base_debug {
-PDB_t *pdb;
-
-if (!(interp->pdb)) {
-pdb = (PDB_t *)mem_sys_allocate_zeroed(sizeof (PDB_t));
-
-interp->pdb = pdb;
-pdb->cur_opcode = interp->code->base.data;
-pdb->state |= PDB_RUNNING;
-}
+Parrot_debugger_init(interp);
}
@@ -64,13 +56,7 @@
=cut
op debug_load(inconst STR) :base_debug {
-char *f;
-
-if (!(interp->pdb->state & PDB_BREAK)) {
-f = string_to_cstring(interp, ($1));
-PDB_load_source(interp, f);
-string_cstring_free(f);
-}
+Parrot_debugger_load(interp, ($1));
}
@@ -90,23 +76,7 @@
=cut
op debug_break() :base_debug {
-const char *command;
-
-if (!(interp->pdb->state & PDB_BREAK)) {
-interp->pdb->state |= PDB_BREAK;
-interp->pdb->state |= PDB_STOPPED;
-interp->pdb->cur_opcode = (opcode_t *)cur_opcode + 1;
-PDB_set_break(interp, NULL);
-while (!(interp->pdb->state & PDB_EXIT)) {
-PDB_get_command(interp);
-command = interp->pdb->cur_command;
-PDB_run_command(interp, command);
-}
-/* RT#42378 this is not ok */
-exit(EXIT_SUCCESS);
-}
-interp->pdb->cur_opcode = (opcode_t *)cur_opcode + 1;
-PDB_set_break(interp, NULL);
+Parrot_debugger_break(interp, cur_opcode);
}
Index: src/debug.c
===
--- src/debug.c (revisión: 28719)
+++ src/debug.c (copia de trabajo)
@@ -36,7 +36,51 @@
IMCC_warning(PARROT_INTERP, ARGIN(const char *fmt), ...);
extern void imcc_init(PARROT_INTERP);
+/*
+ * These constants correspond to the debugger commands.
+ * To map command strings to their numeric values,
+ * use the algorithm from parse_command().
+ */
+enum DebugCmd {
+debug_cmd_b = 25245,
+debug_cmd_c = 25500,
+debug_cmd_d = 25755,
+debug_cmd_e = 26010,
+debug_cmd_h = 26775,
+debug_cmd_i = 27030,
+debug_cmd_l = 27795,
+debug_cmd_n = 28305,
+debug_cmd_p = 28815,
+debug_cmd_q = 29070,
+debug_cmd_r = 29325,
+debug_cmd_s = 29580,
+debug_cmd_t = 29835,
+debug_cmd_w = 30600,
+debug_cmd_int = 175185,
+debug_cmd_run = 176460,
+debug_cmd_num = 174675,
+debug_cmd_str = 179265,
+debug_cmd_pmc = 163455,
+debug_cmd_eval= 277950,
+debug_cmd_help= 282540,
+debug_cmd_info= 281775,
+debug_cmd_list= 295035,
+debug_cmd_load= 268005,
+debug_cmd_next= 297330,
+debug_cmd_quit= 294780,
+debug_cmd_break = 409785,
+debug_cmd_print = 441150,
+debug_cmd_stack = 414120,
+debug_cmd_trace = 405705,
+debug_cmd_watch = 416160,
+debug_cmd_enable = 571455,
+debug_cmd_delete = 588285,
+debug_cmd_script_file = 617610,
+debug_cmd_disable = 772140,
+debug_cmd_continue= 1053405,
+debug_cmd_disassemble = 1903830
+};
/* HEADERIZER HFILE: include/parrot/debug.h */
@@ -357,6 +401,83 @@
/*
+=item C
+
+Init the parrot debugger, if not already done.
+
+=item C
+
+Load a Parrot source file for the current program.
+
+=item C
+
+Break execution and drop into the debugger.
+If we are already into the debugger and is the first time we are
+called set a breakpoint.
+
+When you re run/continue the program begin debugged it will pay
+no attention to the debug ops.
+
+RT#42377: clone the interpreter to allow people to play into the
+debugger and then continue the normal execution of the program.
+
+=cut
+
+*/
+
+void
+Parrot_debugger_init(PARROT_INTERP)
+{
+if (!(interp->pdb)) {
+PDB_t * pdb = (PDB_t *)mem_sys_allocate_zeroed(sizeof (PDB_t));
+
+interp->pdb = pdb;
+pdb->cur_opcode = interp->code->base.data;
+pdb->state |= PDB_RUNNING;
+}
+}
+
+void
+Parrot_debugger_load(PARROT_INTERP, ARGIN_NULLOK(STRING *filename))
+{
+if (!(interp->pdb))
+real_exception(interp, NULL, 0, "No debugger");
+else {
+char *f= string_to_cstring(interp, filename);
+PDB_load_source(interp, f);
+string_cstri
[perl #47794] [BUG] objects - :method doesn't work with :outer()
This appears to have been resolved by jonathan++ in r28716. Way to go Jonathan! Pm
Re: [perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
On Thu, Jun 26, 2008 at 4:18 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > FWIW, the part of the patch pertaining to t/codingstd/perlcritic.t did > not apply cleanly when I tried it on Linux. > > That may just indicate that the guts have been ripped out of that file > and replaced with mostly new code. Perhaps you could post the complete > text of your new version of that file? > > Thank you very much. > kid51 > > > Attached. -- Will "Coke" Coleda pc.pl Description: Binary data
[perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
Thanks, Coke. On my Linux VM I did not yet have Test::Perl::Critic installed, so I first tested the patch to see if it would DTRT, i.e., skip all. It did. I then installed Test::Perl::Critic via 'cpan' and retested, successfully. (I might add that since the first files to be tested are Configure.pl and the config/*/*.pm modules I maintain, it was gratifying to see all those "ok"s whiz by!) kid51
[perl #42293] [TODO] t/doc/pod.t vs. tools/doc/pod_errors.pl
On Tue Apr 03 21:29:13 2007, coke wrote: > These two scripts perform the same basic task, but do so inconsistently. > > The tools/ script should be removed, and someone should investigate > how it's checking the pod (it finds errors in the current distro > while the test does not.) > > -- > Will "Coke" Coleda > [EMAIL PROTECTED] > > Removed in r28732; The primary source of differences is that it was checking _every_ file, including those in the .svn directories. Closing ticket. -- Will "Coke" Coleda
[perl #41606] [TODO] Add flag to do runtime check on deprecated ops
On Mon Feb 26 02:32:10 2007, kjs wrote:
> On Fri Feb 23 14:46:17 2007, [EMAIL PROTECTED] wrote:
> > hi,
> >
> > it might be a good idea to add a flag to parrot that checks at runtime
> > whether any deprecated ops are used.
> > the flag should be turned off by default; some ops like find_global are
> > used all over the place, so if it would be
> > turned on, that would give too many warnings.
> >
> > Having this flag will help people to stop using those ops (the flag can
> > be added when doing make test), so we
> > can remove the ops soon.
> >
> > The flag should check at runtime, not compile time, because the check
> > should also be possible when running pbc files.
> >
> > regards,
> > kjs
>
> I did some more thinking about this. The point is, we don't want the
> engine to check all ops being executed whether they are deprecated. This
> would make the runcore slower, so that doesn't really motivate to use
> the flag (--check-deprecated-ops or whatever).
>
> Another thing: it is undesirable to have some list of deprecated ops
> somewhere in the core that should be updated whenever ops are
> deprecated, or after a deprecation cycle, ops are removed (the list to
> be checked should be cleaned up).
>
> A much better approach, IMHO, would be to add some annotation to the
> .ops file.
>
> Now, an instruction is specified as:
>
> op foo(out PMC) {
> /* do something */
> goto NEXT();
> }
>
> If "foo" would be deprecated, just add some tag, for instance like so:
>
> deprecated op foo(out PMC) {
> }
>
> The ops2c.pl script should then check for the tag "deprecated", and if
> present, add this line to the op body: (or something a like)
>
> if(FLAGS(DEPRECATED_OPS)) { /* or whatever a flag check looks like */
> fprintf(stderr, "Warning: instruction 'foo' is deprecated\n");
> }
>
> To summarize the advantages of this approach:
> 1. no messing around with runtime core code
> 2. the solution is isolated to the point where it should be: the source
> of the instruction itself: easy to deprecated ops; easy to remove ops
> (no need to change other files)
> 3. self-documenting .ops files. (is .ops documentation extracted from
> the .ops files? -- if so this would be an additional feature, the docs
> then can add: "DEPRECATED")
> 4. Not too hard to implement (although I don't really understand
> ops2c.pl, it shouldn't be too hard I guess)
> 5. No overhead for non-deprecated instructions.
>
> Comments are most certainly welcome,
> kjs
Attached, find a patch that allows us to specify a ":deprecated" flag (post op,
ala :flow). It
also adds a new parrot warning (configurable with warningson) level called
PARROT_WARNING_DEPRECATED_FLAG. The patch only applies this flag to getclass.
Comments welcome. (Hopefully sooner than it took me to comment on kjs's last
send on this
ticket. =-). The one thing I'm not sure about is that I'm just using fprintf as
in kjs's original
sample. Could probably stand to actually use parrot IO. I'm also not happy that
it doesn't
show the location of the opcode, but I can live with that for now.
You can see the behavior with:
%cat foo.pir
.include 'include/warnings.pasm'
.sub main
$P1 = getclass 'Integer'
say 'ok'
warningson .PARROT_WARNINGS_DEPRECATED_FLAG
$P1 = getclass 'Float'
.end
%./parrot foo.pir
ok
Warning: instruction 'getclass' is deprecated
--
Will "Coke" Coleda
Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 28731)
+++ src/ops/core.ops(working copy)
@@ -974,18 +974,11 @@
Turns on warnings categories. Categories already turned on will stay on.
Initial setting is currently all warnings off. Include F to
-access the categories. They are:
+access the categories. Refer to that file for the current list of warnings
+available.
=over 4
-=item .PARROT_WARNINGS_UNDEF_FLAG
-
-=item .PARROT_WARNINGS_IO_FLAG
-
-=item .PARROT_WARNINGS_PLATFORM_FLAG
-
-=item .PARROT_WARNINGS_ALL_FLAG
-
=back
To turn on multiple categories, OR the category numbers together.
Index: src/ops/object.ops
===
--- src/ops/object.ops (revision 28731)
+++ src/ops/object.ops (working copy)
@@ -366,7 +366,7 @@
=cut
-inline op getclass(out PMC, in STR) :object_classes :flow {
+inline op getclass(out PMC, in STR) :object_classes :flow :deprecated {
PMC * const _class = Parrot_class_lookup(interp, $2);
opcode_t * const next = expr NEXT();
@@ -376,8 +376,6 @@
$1 = _class;
goto ADDRESS(next);
-/* real_exception(interp, NULL, UNIMPLEMENTED,
-"The 'getclass' opcode has been deprecated, use 'get_class'. See RT
#47972.");*/
}
inline op getclass(out PMC, in PMC) :object_classes :flow {
Index: lib/Parrot/Op.pm
===
--- lib/Parrot/Op.pm(revision 28731)
+++ lib/Parrot/Op.pm(working copy)
@@ -168,8 +168,6 @@
$name .= "
[perl #48445] [TODO] [NQP] - report undeclared variable usage
On Mon Dec 10 11:49:08 2007, pmichaud wrote: > > When an NQP program uses a variable that hasn't been > previously declared, it should report a useful error message: > > Use of undeclared variable '$x' at ... > > Pm Looking at this, there doesn't seem to be a way to write a self-hosted test (in nqp) for this since there's no try/catch equivalent. Can someone add a PIR based TODO test for this (in compilers/nqp/t) that shows the desired (but not yet implemented) behavior? -- Will "Coke" Coleda
Re: [perl #41606] [TODO] Add flag to do runtime check on deprecated ops
On Thursday 26 June 2008 20:02:18 Will Coleda via RT wrote: > Attached, find a patch that allows us to specify a ":deprecated" flag (post > op, ala :flow). It also adds a new parrot warning (configurable with > warningson) level called PARROT_WARNING_DEPRECATED_FLAG. The patch only > applies this flag to getclass. > > Comments welcome. (Hopefully sooner than it took me to comment on kjs's > last send on this ticket. =-). The one thing I'm not sure about is that I'm > just using fprintf as in kjs's original sample. Could probably stand to > actually use parrot IO. I'm also not happy that it doesn't show the > location of the opcode, but I can live with that for now. +1 from me as-is. ParrotIO stuff will likely have to change in the medium-term anyway, so we'll probably have to modify this code (if we don't remove the ops altogether) at some point anyway. -- c
[perl #56398] [BUG] lexical inner scope always keeps first lexpad (or something)
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56398]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56398 >
Earlier today Jonathan was able to implement the :lexid proposal
discussed in RT#56274. We've now run into another problem or bug.
I'll demonstrate with code. First, here's the Perl 6 version
of what we're trying to do:
foo('try 1');
foo('try 2');
foo('try 3');
sub foo($x) {
say "outer foo $x";
{
say "inner foo $x";
$x := 'BOGUS!';
}
}
The C subroutine contains a nested immediate block that
prints the contents of C<$x> from its outer scope, then rebinds
<$x> to a new value.
Here's the PIR version of the above:
.sub 'main' :main
foo('try 1')
foo('try 2')
foo('try 3')
.end
.sub 'foo' :lexid('foo')
.param pmc x
.lex '$x', x
print "outer foo "
say x
'inner'()
.end
.sub 'inner' :outer('foo')
.local pmc x
x = find_lex '$x'
print "inner foo "
say x
$P0 = new 'String'
$P0 = 'BOGUS!'
store_lex '$x', $P0
.end
And here's what happens when we run it:
$ ./parrot badlex.pir
outer foo try 1
inner foo try 1
outer foo try 2
inner foo BOGUS!
outer foo try 3
inner foo BOGUS!
$
The first call to foo() works. In the second and subsequent
calls to foo(), execution of the inner-scoped immediate block
still refers to the lexpad that was established during the
first call to C, as opposed to the lexpads creating for
the later calls.
Pm
