Re: crossing lists
If PDL-like threading syntax is adopted, this is trivial. In PDL:
$a = pdl(1,2);
$b = pdl(3,4);
$c = $a->(*1) * $b;
print $c;
yields the output:
[
[3 4]
[6 8]
]
The '(*1)' inserts a dummy dimension into $a, making it a 1x2-array
rather than a 2-array. Then
the threading engine makes the appropriate outer product.
I strongly encourage the use of threading syntax (see the very nice
PDL::NiceSlice module) rather than a specific outer-product operator:
threading syntax turns out to be the answer to a rather large
collection of problems.
On Oct 28, 2005, at 12:21 AM, Darren Duncan wrote:
Not sure if this matter was resolved on a previous discussion, but
here goes ...
I would like to have a simple way to combine 2 array where every
element of each array is combined with every element of the other
array; this can also chain or scale to handle any number of arrays.
For now lets name it 'cross', since it behaves similarly to the set
operation that SQL calls a cross-join.
What I'm not yet sure about is whether this would be better as
something resembling the zip() operator or a hyper-operator.
One thing I would like to be able to do is this:
@baz = cross([1,2],[3,4]); # yields ([1,3],[1,4],[2,3],[2,4])
And alternately, this:
for cross([1,2],[3,4]) -> $foo,$bar { ... } # loop has 4 iterations
More examples:
cross() # yields ()
cross([],[1]) # yields ()
cross([1,2]) # yields ([1],[2])
cross([1,2],[3]); # yields ([1,3],[2,3])
cross([1],[2],[3]) # yields ([1,2,3])
cross([1],[2],[3,4]) # yields ([1,2,3],[1,2,4])
The order of the output elements is determined by the order of the
input elements.
If one were to be able to use this as a simple joining mechanism,
then each combination would have to be returned as an array, so
that 'map' or 'grep' etc would work properly. For example:
@A = ('red shirt', 'white shirt');
@B = ('blue pants', 'black pants');
@C = map { "going with $_[0] and $_[1] today" } cross(@A,@B);
On the other hand, perhaps something I actually want is something
like the hyper-operation but with appropriately different syntax:
['a','b'] >>~<< ['c','d']
But that it returns ['ac','ad','bc','bd'] rather than ['ac','bd'].
So is there a similarly terse way to do combinations already, and
if not then would you consider it commonly used enough to add?
-- Darren Duncan
crossing lists
Not sure if this matter was resolved on a previous discussion, but
here goes ...
I would like to have a simple way to combine 2 array where every
element of each array is combined with every element of the other
array; this can also chain or scale to handle any number of arrays.
For now lets name it 'cross', since it behaves similarly to the set
operation that SQL calls a cross-join.
What I'm not yet sure about is whether this would be better as
something resembling the zip() operator or a hyper-operator.
One thing I would like to be able to do is this:
@baz = cross([1,2],[3,4]); # yields ([1,3],[1,4],[2,3],[2,4])
And alternately, this:
for cross([1,2],[3,4]) -> $foo,$bar { ... } # loop has 4 iterations
More examples:
cross() # yields ()
cross([],[1]) # yields ()
cross([1,2]) # yields ([1],[2])
cross([1,2],[3]); # yields ([1,3],[2,3])
cross([1],[2],[3]) # yields ([1,2,3])
cross([1],[2],[3,4]) # yields ([1,2,3],[1,2,4])
The order of the output elements is determined by the order of the
input elements.
If one were to be able to use this as a simple joining mechanism,
then each combination would have to be returned as an array, so that
'map' or 'grep' etc would work properly. For example:
@A = ('red shirt', 'white shirt');
@B = ('blue pants', 'black pants');
@C = map { "going with $_[0] and $_[1] today" } cross(@A,@B);
On the other hand, perhaps something I actually want is something
like the hyper-operation but with appropriately different syntax:
['a','b'] >>~<< ['c','d']
But that it returns ['ac','ad','bc','bd'] rather than ['ac','bd'].
So is there a similarly terse way to do combinations already, and if
not then would you consider it commonly used enough to add?
-- Darren Duncan
Re: Deprecation warning - last call: newsub
On Oct 28, 2005, at 0:02, Patrick R. Michaud wrote: On Tue, Oct 25, 2005 at 04:56:57PM +0200, Leopold Toetsch wrote: .const .Sub corou = "_pge_rule_coroutine" I tried the .Sub constant and I get an error: The .const line is only valid inside a subroutine. And we can't do much against this syntax restriction. The line expands to: set_p_pc $P0, As PMC constants are not permutated on all opcodes, this opcode is needed and hence a subroutine that surrounds it. Better still, is there an easy way for a sub (coroutine) to get its own PMC when it's running? Is C the right way to do it? What I'd like to do now is the equivalent of... Yep .include "interpinfo.pasm" $P0 = interpinfo .INTERPINFO_CURRENT_SUB Thanks, Pm leo
Role Method Conflicts and Disambiguation
Hello all,
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we will use this later :)
}
role Bar {
method foo { ... }
}
role FooBar {
does Foo;
does Bar;
}
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do not throw an error until a
role is composed into a class. This means that when I do this:
class MyClass does FooBar {}
an exception is thrown. Unless of course MyClass has a &foo method,
which will disambiguate the conflict. My question then is, can FooBar
(the role) disambiguate the &foo conflict?
role FooBar {
does Foo;
does Bar;
method foo { ... }
}
Now, on the surface this seems obvious, of course the FooBar role
should be able to disambiguate. However, when we expand the example
other issues show up.
role Baz {
does Foo;
}
class MyClass2 does FooBar does Baz {} # Will this die?
Now, since MyClass2 actually does Foo twice, does that mean &bar
creates a conflcit? Since &bar would be found through FooBar and Baz.
I would think the answer here would be no, and that we would build
some kind of unique list of roles so as to avoid repeated consumption
like this.
But thats not all, we have a potential problem with &foo again. Baz
will provide &foo from Foo, but FooBar will provide it's own &foo
(which we used to disambiguate). So our disambiguation is not
ambiguated again.
/ Possible Solutions /
A (deceptively) simple solution to this is that MyClass2 needs to
disambiguate. But this means that our roles are not really black
boxes anymore. In order to properly disambiguate this we need to know
where all the &foo methods are coming from (Foo, Bar and FooBar), and
potentially what is inside these &foo methods (especially in the case
of FooBar since it is attempting to disambiguate, it's behavior could
be very specific). It probably would also become important to know
what other methods &foo interacts with since we potentially have 3
different expected versions of &foo.
In the end, we will have probably looked inside every method defined
in Foo, Bar, FooBar and Baz in order to properly write MyClass2.
IMHO, this is sort of defeating the usefulness of roles at this point.
Another simple (but maybe slightly unintuitive) solution would be to
not allow roles to disambiguate at all.
(Quick side note: Doing this means that roles like FooBar (which
carry with them a "suspended" conflict) would be restricted in what
types of behaviors they can provide. Basically they would only be
able to provide new behaviors which are unrelated to those provided
by Foo and Bar. If it were to try to use methods from Foo or Bar, it
would really end up needing to disambiguate.)
This actually makes MyClass2 somewhat simpler now, since it only need
to disambiguate between &foo from Foo, and &foo from Bar. Of course
this is only marginally better, since you would still need to look
inside all the methods of Foo, Bar, FooBar and Baz to see how &foo is
being used so you could disambiguate properly.
...
So what do you all think??
Stevan
Re: Compiling parrot with c++
On Thu, Oct 27, 2005 at 11:22:40PM +0200, Leopold Toetsch wrote: > > On Oct 27, 2005, at 22:31, Nick Glencross wrote: > > >There are a few cases of -1 being assigned to unsigneds. Anyone know > >if that's deliberate? > > Yup. Some special out-of-band values. I suspect that gcc4 will give a warning on that. Wouldn't UINT_MAX or ULONG_MAX be slightly more correct? -J -- pgpv4bncPnCU9.pgp Description: PGP signature
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/27/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote:
> : Will I be able to do something like:
> :
> : package Foo;
>
> Hmm, you just started in Perl 5 mode.
>
> : $*VERSION = 1.3.2;
>
> Perl 5 would get confused here, so I'm presuming Perl 6. But Perl 6
> isn't likely to let you override the global run-time Perl version.
>
> : use Foo-1.3.1;
>
> That I think I understand.
>
> : role My::Foo { does Foo; ... }
>
> Okay, My::Foo does Foo here. Presumably it must "do" the Foo alias
> that the use just installed. And presumably the Foo you just used
> is a role that can be "done". Certainly you can't "do" the global
> package Foo, assuming that's what your original package declared.
>
> : alias My::Foo -> Foo; # Or whatever the syntax should be
>
> I have no clue where you're intending to install that alias.
> Are you trying to install a *Foo alias? A bare Foo is going to first
> find the local alias to the Foo you used, and that hides the global
> Foo that it would have found otherwise. I suspect you're trying to
> say
>
> *Foo := My::Foo;
>
> : And, in my other code, "use Foo;" will DWIM?
>
> I don't know quite what you mean, so I don't know if it'll do what
> you mean. If you're trying to establish a policy that defaults a
> particular name to a particular version, the library interface will
> probably give you a more straightforward way to set that up.
Sorry. I'm not up on the syntax. I should do some serious backlog reading.
What I'm trying to do is load role Foo 1.0, have My::Foo do Foo, then
call My::Foo version 2.0 of Foo so that anyone else in my program will
see My::Foo instead of the original Foo. Is this possible?
Rob
Languages smoke testing
Hi, as failing test are in popular demand, I have added a 'languages-smoke' target to the main Makefile. So make languages-smoke should send a smoke report for languages testing to the smokeserver. Recent smoke reports are then available under http://smoke.parrotcode.org/smoke/. Enjoy, and thanks to creators and maintainers of smoke-server, Bernhard
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote:
: Will I be able to do something like:
:
: package Foo;
Hmm, you just started in Perl 5 mode.
: $*VERSION = 1.3.2;
Perl 5 would get confused here, so I'm presuming Perl 6. But Perl 6
isn't likely to let you override the global run-time Perl version.
: use Foo-1.3.1;
That I think I understand.
: role My::Foo { does Foo; ... }
Okay, My::Foo does Foo here. Presumably it must "do" the Foo alias
that the use just installed. And presumably the Foo you just used
is a role that can be "done". Certainly you can't "do" the global
package Foo, assuming that's what your original package declared.
: alias My::Foo -> Foo; # Or whatever the syntax should be
I have no clue where you're intending to install that alias.
Are you trying to install a *Foo alias? A bare Foo is going to first
find the local alias to the Foo you used, and that hides the global
Foo that it would have found otherwise. I suspect you're trying to
say
*Foo := My::Foo;
: And, in my other code, "use Foo;" will DWIM?
I don't know quite what you mean, so I don't know if it'll do what
you mean. If you're trying to establish a policy that defaults a
particular name to a particular version, the library interface will
probably give you a more straightforward way to set that up.
Larry
Re: Compiling parrot with c++
Leopold Toetsch wrote: On Oct 27, 2005, at 22:31, Nick Glencross wrote: There are a few cases of -1 being assigned to unsigneds. Anyone know if that's deliberate? Yup. Some special out-of-band values. I thought as much. Nothing to worry about there then... One other thing I forgot to ask if anyone had a solution to... Is there a proper way of doing forward declarations of statics in C/C++? I've had to use extern for the timebeing, even though that changes what was trying to be achieved. e.g. In ops2c.pl there's a 'static op_lib_t var' at the top, which is forward declaring the variable, but C++ (with good reason) doesn't like that. Nick
Re: Is there a way to generate an object without new?
On Thu, Oct 27, 2005 at 01:30:44PM -0600, Luke Palmer wrote:
: On 10/27/05, Yiyi Hu <[EMAIL PROTECTED]> wrote:
: > What I want to do, is a bit like...
: >
: > class A {
: > has $.b;
: > method show { "$.b".say };
: > };
: >
: > A( b => 5 ).show;`
:
: Yes, I definitely want this to be the way that case type instances are
: created: all those .news everywhere could get annoying.
On the other hand, it potentially makes these mean very different things:
A @x
A(@x)
and that's a problem. Semantically, it would certainly be possible
to teach any "kind" to respond to .() and attempt to clone or bless
itself into a new object, but syntactically if we introduce A as a
list operator we can never use it as a bare type mark on a variable
like @x without some declarator out front. So either we rule out
bare "A $x" as a coercion or cast, or we rule out bare "A" as a list
operator, which would make the parens required.
But even with parens, we can't easily make A([EMAIL PROTECTED]) mean both of
these simultaneously:
@args[0].as(A)
A.new([EMAIL PROTECTED])
Well, okay, maybe if we're really sneaky about our MMD, we could make
that work most of the time. But it kind of loses the distinction
of making a new A out of something else vs making the current thing
look like an A without necessarily cloning it. That probably needs
syntactic relief anyway. Maybe A! is a hard cast and A? is a soft cast.
Needs more waffling. Er, more thought.
: Anyway, assuming that class and sub namespaces are separate, which may
: be a dubious assumption:
:
: our &A ::= &A::new.assuming(A);
The "variables" are separate in the symbol table, but both of them
try to warp the grammar to recognize a bare 'A'. It's not clear
what will happen in that case. If the original ^A is really ^*A,
then defining &A will likely just hide the outer meaning of A. On the
other hand, with our definition of package aliasing, the global name
includes version and author, and the current scope has an A alias to
that long name, and that might collide with the A name of &A in
the current scope.
: Or, more explicitly (and more readably IMO):
:
: sub A (\$x) { A.new(*$x) }
Sorry, &A is introduced immediately, so you've just written a nice
infinite recursion. I'd suggest
sub A (\$x) { ::A.new(*$x) }
Larry
Re: Compiling parrot with c++
On Oct 27, 2005, at 22:31, Nick Glencross wrote: There are a few cases of -1 being assigned to unsigneds. Anyone know if that's deliberate? Yup. Some special out-of-band values. Cheers, Nick leo
Re: Compiling parrot with c++
Gabriel Dos Reis wrote: Matt Fowles <[EMAIL PROTECTED]> writes: | Nick~ | | On 10/26/05, Nick Glencross <[EMAIL PROTECTED]> wrote: | > Guy, | > | > As a follow-up to a discussion a few days ago about binding parrot to | > C++ functions, is making it possible to compile parrot with a C++ | > compiler a 'Bad Thing'? | | I like the idea, but I tend to like C++ more than reason would dictate. I have some personal interests in the idea, and in general I think it may brings substantial benefits to and perspectives on the code base. I've made a start on it here: http://www.glencros.demon.co.uk/parrot_c++-patch.txt I'm still trying to find a portable way of doing enum_var |= enum_mask which will suite both C and C++ (as I know that enum_var = (enum) (enum_var | enum_mask) is rather wordy) . I thought that (int) enum_var |= enum_mask was good enough, but find that C gives a warning about it being deprecated, and a version of g++ that I tried it on today didn't like it at all! I'm probably going to have a quick sidetrack on nci, so if anyone wants to improve on it or look at imcc, there won't be any overlap of effort. There are a few cases of -1 being assigned to unsigneds. Anyone know if that's deliberate? Cheers, Nick
Re: Is there a way to generate an object without new?
Matt Fowles skribis 2005-10-27 15:52 (-0400): > > This is how some other language construct objects, but not how Perl does > > it. In other words: you should not want this. > How does that logically follow? They are two ways of expressing what I think. If they said exactly the same thing, I wouldn't have felt the need to use both :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Is there a way to generate an object without new?
Juerd~
On 10/27/05, Juerd <[EMAIL PROTECTED]> wrote:
> Yiyi Hu skribis 2005-10-28 3:17 (+0800):
> > class A {
> > has $.b;
> > method show { "$.b".say };
> > };
> > A( b => 5 ).show;`
>
> This is how some other language construct objects, but not how Perl does
> it. In other words: you should not want this.
How does that logically follow?
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: [perl #37546] [BUG] parrot crashes with subs compiled using compreg op
On Oct 27, 2005, at 17:45, Patrick R. Michaud wrote: On Thu, Oct 27, 2005 at 05:28:36PM +0200, Leopold Toetsch wrote: The return result of the compilation (an Eval PMC) isn't stored anywhere and get's GCed. This also kills the compiled subroutine. FWIW, I think the "natural" expectation is that a compiled sub (and its associated Eval PMC) will both remain alive through the global symbol table entry until it's released -- either by removing the symbol table entry or replacing it with a different PMC. So be it now. I've updated the sub structure to contain an eval_pmc field, which is used to mark a "surrounding" eval PMC . Therefore a sub in compiled code should now only die, when the global entry is replaced or removed. The rule for :anon subs remain the same, as these aren't DOD-anchored anywhere except in the returned code object (the Eval PMC). This creates a nice reference loop as a Sub marks the Eval PMC and vice versa. But due to our non-refcount based GC this isn't a problem ;-) Pm leo
Re: Is there a way to generate an object without new?
Yiyi Hu skribis 2005-10-28 3:17 (+0800):
> class A {
> has $.b;
> method show { "$.b".say };
> };
> A( b => 5 ).show;`
This is how some other language construct objects, but not how Perl does
it. In other words: you should not want this.
Perhaps it is possible to have a class export a sub to its "use"r.
class A {
has $.b handles { 'show' => 'say' };
eval "sub $?CLASS is export { $?CLASS.new(\$?ARGS) }";
}
Not sure about the existence of $?ARGS, or how else to write it. Well,
@_, but the signature might be different.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Is there a way to generate an object without new?
On 10/27/05, Yiyi Hu <[EMAIL PROTECTED]> wrote:
> What I want to do, is a bit like...
>
> class A {
> has $.b;
> method show { "$.b".say };
> };
>
> A( b => 5 ).show;`
Yes, I definitely want this to be the way that case type instances are
created: all those .news everywhere could get annoying.
Anyway, assuming that class and sub namespaces are separate, which may
be a dubious assumption:
our &A ::= &A::new.assuming(A);
Or, more explicitly (and more readably IMO):
sub A (\$x) { A.new(*$x) }
Luke
Is there a way to generate an object without new?
What I want to do, is a bit like...
class A {
has $.b;
method show { "$.b".say };
};
A( b => 5 ).show;`
Thanks,
Xinming
Re: [perl #37545] [BUG] pbc_merge, tcl, subdirectories:
On Oct 27, 2005, at 7:27, Will Coleda (via RT) wrote: But if I try this from languages/tcl, I get: ../../parrot -o foo.pbc foo.pir ../../parrot -o bar.pbc bar.pir ../../pbc_merge -o whee.pbc foo.pbc bar.pbc Couldn't load 'tcl_group': unknown reason Setting a breakpoint at Parrot_load_lib reveals that this a bit nasty. The HLL info is needed to compile loaded types, i.e. that "$P0 = new .TclString" et al works. This syntax should or course work inside PBcs too, which means that at runtime dynamic class libraries have to be loaded in same order as compile-time. To achieve this the HLL info is created during unpacking PMC constants, which causes loading of the "tcl_group" shared lib. But as pbc_merge is obviously linked with null_config, loading the lib fails. Changing the link line to use parrot_config should help. Better would be to not load the shared lib, if not running inside parrot, as it's AFAIK not needed to load it. leo
Re: Compiling parrot with c++
Matt Fowles <[EMAIL PROTECTED]> writes: | Nick~ | | On 10/26/05, Nick Glencross <[EMAIL PROTECTED]> wrote: | > Guy, | > | > As a follow-up to a discussion a few days ago about binding parrot to | > C++ functions, is making it possible to compile parrot with a C++ | > compiler a 'Bad Thing'? | | I like the idea, but I tend to like C++ more than reason would dictate. I have some personal interests in the idea, and in general I think it may brings substantial benefits to and perspectives on the code base. -- Gaby
Re: "All tests successful" considered harmful
On Thu, 2005-10-27 at 10:26 -0700, jerry gay wrote: > we're missing some parts of a testing framework. we don't have the > ability to write test files in PIR, so we're dependent on a perl > install for testing. perl's a great language for writing tests anyway, > and right now we're dependent on perl for parrot's configure and build > as well. that said, breaking this dependency will make parrot just a > bit closer to standing on its own. We have a Test::Builder port in PIR. I will move up my plan to port Parrot::Test to use it. Making a list of the features of Parrot::Test you need in PIR would help me. -- c
Re: Devel::Cover: Can't find digest for blib/lib/A/B.pm
On 10/27/05, Paul Johnson <[EMAIL PROTECTED]> wrote: > > cover -delete > > export DEVEL_COVER_OPTIONS= > > "-coverage statement,branch,condition,path,subroutine,time" > > This is the problem. You want a comma after -coverage instead of a > space. The documentation could be more clear on this topic. hmm, giving the options in the correct format certainly improves the results. thanks for your help Gabor
Re: Devel::Cover: Can't find digest for blib/lib/A/B.pm
On Thu, Oct 27, 2005 at 06:21:53PM +0200, Gábor Szabó wrote: > actually I think this happens to be with any module, eg.: > > > [EMAIL PROTECTED]:~/Spreadsheet-ParseExcel-Simple-1.03$ cov > Deleting database /home/gabor/Spreadsheet-ParseExcel-Simple-1.03/cover_db > No root path(s) specified at > /usr/local/lib/perl/5.8.7/Devel/Cover/DB.pm line 110 > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/01..ok 1/11Can't find digest for > blib/lib/Spreadsheet/ParseExcel/Simple.pm at > /usr/local/lib/perl/5.8.7/Devel/Cover/DB/Structure.pm line 253. > t/01..ok > > > where cov contains the following: > > cover -delete > export DEVEL_COVER_OPTIONS= > "-coverage statement,branch,condition,path,subroutine,time" This is the problem. You want a comma after -coverage instead of a space. The documentation could be more clear on this topic. The bug is due to a combination of dodgy option handling and incorrect (or at least unhelpful) behaviour with non-standard options. I may yet completely overhaul the option handling. That this is a possibility is the major reason I still call the code alpha. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
"All tests successful" considered harmful
don't worry, you can stop rolling your eyes and wondering "what's this jerk gonna rant about?" this isn't another 'foo considered harmful' essay. if it were, i would have instead opened it with something pithy, like "while some developers have fixed parrot's bugs, others have added new ones." instead, i'll just get to my points. parrot has too few tests. in recent times, the normal build cycle has more often than not included the message 'All tests successful' at the end of 'make test'. that, in itself isn't bad, if it's accompanied with a message like ' (1 subtest UNEXPECTEDLY SUCCEEDED).' but in parrot development, this is rarely the case. surely parrot needs more tests. although major portions of parrot remain unspecified and therefore untestable, existing parts of parrot are only partially tested (as evidenced by the almost daily discovery of bugs by HLL designers and other parrot users.) there need to be more tests, including TODO tests for unimplemented and non-working bits. i've discovered that i like adding tests. it's something that i feel confident that i can contribute without making too much of a mess, and the results are immediately visible when 'make test' is run on any platform. writing tests is a task that's always been offered as low-hanging fruit for the willing. i've written a few in the past, here and there, but now i've added quite a number in the past week, and have gotten enough positive feedback that i'm encouraged to do more. parrot development should be more 'test-conscious'. i'm not saying 'test-driven', that doesn't work for all people (although my personal development style is trending toward that method.) i am saying that when implementing a new widget, whenever possible, tests should be written that cover the widget's basic behavior, edge cases, as well as invalid input. if those tests can't be written, for any reason, try to make a comment in the test file to that effect. and, if you can, add a TODO ticket with a short summary of what needs to be done. then others can more easily pick up a small task that somebody else left behind. we're missing some parts of a testing framework. we don't have the ability to write test files in PIR, so we're dependent on a perl install for testing. perl's a great language for writing tests anyway, and right now we're dependent on perl for parrot's configure and build as well. that said, breaking this dependency will make parrot just a bit closer to standing on its own. we're also missing other fancy things like test coverage analysis tools, etc, but these things are not necessary at this stage of test development. there are certain components that require more testing than others at this point. string related functions like escaping still have bugs to be worked out, as do the unicode-related charset and encoding functions. PGE is in need of comprehensive tests, as it's development is active and it's userbase is growing. tests for the parrot ops are incomplete... not all edge cases, invalid input, etc is tested for each op. libraries (pcre, etc) can use more tests, too. of course, there's more, but those are what i see as the most critical. i'm directing my testing efforts firstly at PGE. i'm using S05 / A05 as a reference to develop a comprehensive test suite (including many, many TODO tests.) i see this as a great opportunity not just to improve PGE, but for me to further my understanding of the new and complex perl6 rules syntax. i see no better way to learn it than to systematically test every part. lastly, i'd like to encourage others to join me in adding tests to parrot. parrot tests have been submitted by a large number of developers already, and the suite continues to grow. but your help can make parrot more reliable, maintainable, and better understood by all. ~jerry
Re: Devel::Cover: Can't find digest for blib/lib/A/B.pm
actually I think this happens to be with any module, eg.: [EMAIL PROTECTED]:~/Spreadsheet-ParseExcel-Simple-1.03$ cov Deleting database /home/gabor/Spreadsheet-ParseExcel-Simple-1.03/cover_db No root path(s) specified at /usr/local/lib/perl/5.8.7/Devel/Cover/DB.pm line 110 PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01..ok 1/11Can't find digest for blib/lib/Spreadsheet/ParseExcel/Simple.pm at /usr/local/lib/perl/5.8.7/Devel/Cover/DB/Structure.pm line 253. t/01..ok where cov contains the following: cover -delete export DEVEL_COVER_OPTIONS= "-coverage statement,branch,condition,path,subroutine,time" HARNESS_PERL_SWITCHES=-MDevel::Cover make test cover -report html This is perl, v5.8.7 built for i486-linux-gnu-thread-multi Devel::Cover is 0.55 This is already a differenc computer than the one I used for the previous report. Gabor
Re: [perl #37546] [BUG] parrot crashes with subs compiled using compreg op
On Thu, Oct 27, 2005 at 05:28:36PM +0200, Leopold Toetsch wrote: > Patrick R.Michaud (via RT) wrote: > > >.sub main :main > >$P0 = open "sf8-sub.pir", "<" > >$S0 = read $P0, 65535 > > > >$P1 = compreg "PIR" > >$P1($S0) > > The return result of the compilation (an Eval PMC) isn't stored anywhere > and get's GCed. This also kills the compiled subroutine. > > $P2 = $P1($S0) > register $P2# or store_global ... > > This is maybe not the correct way to deal with compiled code, OTOH: > Parrot doesn't know anything about the planned life-time of the compiled > code and keeping it alive by default might be as undesriable. FWIW, I think the "natural" expectation is that a compiled sub (and its associated Eval PMC) will both remain alive through the global symbol table entry until it's released -- either by removing the symbol table entry or replacing it with a different PMC. If a compiled sub is marked :anon, then it doesn't create an entry in the global symbol table and is therefore GCed as normal -- generally around the time the Eval PMC gets GCed (i.e., when there are no more live references to the Eval PMC). But now that I know what is happening, I can work with whatever gets decided. Many thanks for the quick fixes, Pm
Re: parrot callbacks
Leopold Toetsch wrote: On Oct 25, 2005, at 23:32, Nick Glencross wrote: I was looking at callbacks the other evening. Am I right in thinking that only two callback prototypes are supported, or have I missed a trick there as well? That's right. There are 2 callbacks (functions with 2 arguments only), one with the *transparent* (void *) user argument first, and one with it as second arg. Before including one or more 3 arg variants, I'd prefer to have some investigations (and results ;-) WRT possible alternatives like libffi. As a bit of background to my original posting, I was trying to write a nice NCI example using Glut/GL. Many of the Glut callbacks have no arguments what-so-ever, so this is currently out of the question. While libffi provides a flexible calling framework, I'm still trying to find if it provides a scheme for callbacks or introspection of arguments passed to a function. It's difficult to find the latest version as it is now part of gcc. Although I haven't fully evaluated it yet, I like the look of ffcall: http://www.haible.de/bruno/packages-ffcall.html It seems to provide all the functionality that we would want. I still can't see how it works under the hood, but it allows you to create a magic function pointer which has values bound to it. We would then be able to create an ffcall callback with a single unified C trampoline, and bind the parrot target, its signature and any userdata. This could then be registered as the library callback. When the C trampoline is called, it need do little more than extract values and call Parrot_runops_fromc_args. The point is (unless I've misunderstood the documentation), that we could even support libraries that have awkward callbacks (such as ones that don't have any user attributes) and multi argument prototypes. Its licensing might be a problem -- GPL. Everything else looks perfect. I'll see if I can come up with a proof of concept over the next few days. Nick
Re: [perl #37546] [BUG] parrot crashes with subs compiled using compreg op
Patrick R.Michaud (via RT) wrote: .sub main :main $P0 = open "sf8-sub.pir", "<" $S0 = read $P0, 65535 $P1 = compreg "PIR" $P1($S0) The return result of the compilation (an Eval PMC) isn't stored anywhere and get's GCed. This also kills the compiled subroutine. $P2 = $P1($S0) register $P2# or store_global ... This is maybe not the correct way to deal with compiled code, OTOH: Parrot doesn't know anything about the planned life-time of the compiled code and keeping it alive by default might be as undesriable. leo
Re: [perl #37540] [TODO] core - document 'new_pad' op
On Oct 27, 2005, at 11:13 AM, Leopold Toetsch wrote: Matt Diephouse wrote: via RT jerry gay <[EMAIL PROTECTED]> wrote: there have been questions lately about the use of the 'new_pad' op. will coleda provided a failing example, which i've included below. upon investigating, i found no tests for new_pad. furthermore, i found no documentation for new_pad in order to start writing tests. so, before tests can be written, the documentation needs to be found or written. here's the failing code snippet: And here's a simpler snippet that displays the same failure: .sub _main :main .local pmc pir pir = compreg "PIR" new_pad 0 $S0 = <<"END_PIR" .sub a $P1 = find_lex 1, '$a' There is no lexical '$a' and it seems that the find_lex *1* is digging one nesting too deep (Pad index out of range). find_lex 0 or find_lex -1 works, that is it can't find '$a'. leo But before this is called, new_pad -1 is called, which should create a pad at level 1. (which should then, yes, give us the lexical not found error.).
Re: [perl #37540] [TODO] core - document 'new_pad' op
Matt Diephouse wrote: via RT jerry gay <[EMAIL PROTECTED]> wrote: there have been questions lately about the use of the 'new_pad' op. will coleda provided a failing example, which i've included below. upon investigating, i found no tests for new_pad. furthermore, i found no documentation for new_pad in order to start writing tests. so, before tests can be written, the documentation needs to be found or written. here's the failing code snippet: And here's a simpler snippet that displays the same failure: .sub _main :main .local pmc pir pir = compreg "PIR" new_pad 0 $S0 = <<"END_PIR" .sub a $P1 = find_lex 1, '$a' There is no lexical '$a' and it seems that the find_lex *1* is digging one nesting too deep (Pad index out of range). find_lex 0 or find_lex -1 works, that is it can't find '$a'. leo
Devel::Cover: Can't find digest for blib/lib/A/B.pm
In a project I am running with Devel::Cover I get the following error message: Can't find digest for blib/lib/A/B.pm at /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi/Devel/Cover/DB/Structure.pm line 253. t/01-configok All tests successful. Files=1, Tests=2, 8 wallclock secs ( 8.21 cusr + 0.29 csys = 8.50 CPU) Reading database from /home/gabor/work//cover_db Devel::Cover: Can't find digest for blib/lib/A/B.pm Then it does not create any reports. Any idea what's the cause and how to solve it? Gabor
Re: +$arg changed to :$arg
HaloO,
Juerd wrote:
This aside, you could of course just double the colon. Or use a
semicolon.
Semicolon would give me the mnemonic of 'end of statement' seperating
the dispatched part from the checked part of the signature. Or it
reminds one of the array and hash slicing. Should we call dispatch
call or code slicing?
:( Int, Int ; Str, Num --> Foo )
A slot call would then retrieve the method from the object first
:( Item ^X --> ^X ; Foo, Bar --> Ret )
Assuming we use ^ instead of ¢ as the captured type sigil. Which
leaves the question how arrow type invocant methods relate to
non-arrow type invocant methods? Hmm, non-arrow types can always
be regarded as :( void --> ^X ) and the usual contra-variant subtyping
rule would make :( ^X --> ^X ) more specific if void were more specific
than ^X. But I think the opposite is true! That is any value can go
to void context and be ignored. In other words void is a type close to
the universal type. By the same argument any method is more specific
than subs which have void as invocant type.
I like the outcome that a free method on the same type has higher
dispatch precedence than the corresponding slot call. YMMV, though.
OTOH, the free method might not have the privileged access that a
'inside class definition' method has. But then such a outside overrider
might just delegate to the insider routine through explicit slot access.
But how does that look like? I think
method bar (Foo $x) # all params dispatched, hence ^ optional
{
say "outside Foo :)";
$x.Foo::bar(); # slot call
}
should do the trick. But then again, there might be no free methods
in Perl6.
I just really wouldn't like : to have two very different meanings in very
similar places.
I'm split on the issue because of the similarity to the label syntax. The
indirect object syntax is then the call continuation after the dispatch
target selection and invocants binding or some such.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: [perl #37546] AutoReply: [BUG] parrot crashes with subs compiled using compreg op
On Wed, Oct 26, 2005 at 11:37:17PM -0700, pmichaud wrote: > Parrot seems to have trouble with subs compiled and loaded using > the C op. My test involves three files: > [...] I've now added a test for this to the repository (r9588). Pm
Re: [perl #37537] [BUG] coroutine segfaults
Patrick R.Michaud (via RT) wrote: corou = clone corou coroutine.pmc was missing a clone method. It did reuse Sub.clone(), which created corrupted coro pmcs. Fixed r9591 Thanks for the test case leo
[perl #37546] [BUG] parrot crashes with subs compiled using compreg op
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37546]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37546 >
---
osname= linux
osvers= 2.4.21-27.0.2.elsmp
arch= i386-linux-thread-multi
cc= gcc 4.0.0 20050516 (Red Hat 4.0.0-6)
---
Flags:
category=core
severity=high
ack=no
---
This may be related to #37537 ("coroutine segfaults") but it's
different enough that I'm submitting a separate ticket for it
and some new test diagnostics to evoke the bug.
Parrot seems to have trouble with subs compiled and loaded using
the C op. My test involves three files:
sf8-sub.pir contains a simple subroutine called "outer" in
the "XYZ" namespace.
.sub outer
.param pmc mob
.local pmc corou
.return (mob)
.end
Both sf8-include.pir and sf8-compreg.pir have a main subroutine
that simply looks up "outer" in the "XYZ" namespace, and then
enters an infinite loop calling the outer subroutine. The difference
is that sf8-include.pir uses an C< .include "sf8-sub.pir" >
directive to compile the code, while the sf8-compreg.pir version
loads sf8-sub.pir into a string register, then uses the C
op to compile and load the code.
The sf8-include.pir program (using ".include") appears to work
just fine. The sf8-compreg.pir program (using "compreg" op)
aborts after ~1100 iterations:
[EMAIL PROTECTED] trunk]$ ./parrot sf8-compreg.pir | wc -l
No code segment to switch to
1112
[EMAIL PROTECTED] trunk]$
Turning on tracing causes it to fail after just 14 iterations,
and no longer produces the "No code segment to switch to" message
(although it still aborts):
[EMAIL PROTECTED] trunk]$ ./parrot -t sf8-compreg.pir 2>xxx | wc -l
14
[EMAIL PROTECTED] trunk]$
The last thing in the trace output is a "DOD / GC" pair.
Pm
---
Summary of my parrot 0.3.0 (r9586) configuration:
configdate='Thu Oct 27 00:50:23 2005'
Platform:
osname=linux, archname=i386-linux-thread-multi
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl
Compiler:
cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
---
Environment:
HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
.sub main :main
$P0 = open "sf8-sub.pir", "<"
$S0 = read $P0, 65535
$P1 = compreg "PIR"
$P1($S0)
$P0 = find_global "XYZ", "outer"
loop:
$P1 = $P0("abc")
print $P1
print "\n"
goto loop
.end
.sub main :main
$P0 = find_global "XYZ", "outer"
loop:
$P1 = $P0("abc")
print $P1
print "\n"
goto loop
.end
.include "sf8-sub.pir"
.namespace [ "XYZ" ]
.sub outer
.param pmc mob
.local pmc corou
.return (mob)
.end
[perl #37542] [TODO] core - document behavior of multiple :load subpragmas in same compilation unit
# New Ticket Created by jerry gay # Please include the string: [perl #37542] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37542 > the behavior of multiple subroutines marked with the ':load' subpragma in the same compilation unit is currently undefined. PGE currently uses a workaround for this limitation, as seen in compilers/pge/PGE.pir. once this behavior is defined, tests canbe added (to imcc/t/syn/pcc.t) ~jerry
Re: +$arg changed to :$arg
On 10/27/05, TSa <[EMAIL PROTECTED]> wrote: > HaloO, > > Larry Wall wrote: > > > : Yes, and dispatch as a runtime keyed access into a code multitude. > > : The covariant part of the method's sig! The code equivalent to keyed > > : data access into hashes. > > > > Um, yeah. Won't play in Peoria, though. > > Where or what is Peoria? It's an expression in the US. Peoria is a town in the state of Illinois. It has a reputation for being conservative and a "keeper of American Values" (whatever that means). So, when you say something "won't play in Peoria", you're saying that it's unlikely to be accepted by the masses. Rob
Re: +$arg changed to :$arg
HaloO,
Larry Wall wrote:
: Yes, and dispatch as a runtime keyed access into a code multitude.
: The covariant part of the method's sig! The code equivalent to keyed
: data access into hashes.
Um, yeah. Won't play in Peoria, though.
Where or what is Peoria?
What I mean with the covariant part of a method sig stems from
the paper "G. Castagna. Covariance and contravariance: conflict
without a cause" available from
ftp://ftp.di.ens.fr/pub/users/castagna/covariance.ps.gz
: The left --> is just the virtualizer call. I tend to call
: that slot accessor. The return value of a dispatch is the
: not yet invoked but curried on the invocant(s) method. This
: two stage propcess is in my eyes nicely indicated by the
: two -->. But we could also but a : in the dispatch arrows
: like -:-> or :-> or -:> which all look somewhat ugly.
I kind of like : for that, actually. :-)
I have no objections. Actually I associate it with
the label syntax. But I hope we have the same understanding
what
multi method abc (A $a: B $b: C $c: X $x, Y $y) {...} #1
means in comparison to
multi method abc (A $a, B $b, C $c: X $x, Y $y) {...} #2
where I think that #1 is a mono method on A that yields a
mono method on B which in turn yields a mono method on C.
That is *three* successive dispatches which could branch out
into different targets in each step. E.g. with D a subtype of B
multi method abc (A $a: D $b: C $c: X $x, Y $y) {...} #3
The #2 target OTOH is a *single* target on the 3-tupel type :(A,B,C).
We could call the #1 and #3 dispatches tree-dispatch and #2
lattice-dispatch. Question is how do they relate to each other?
I would opt for :(A,B,C) beeing more specific than :(A). In other
words the cascaded dispatch competes in each step with n-tupel types.
E.g.
multi method abc (A $a: D $b, C $c: X $x, Y $y) {...} #4
outperforms :(B) from #1 and :(D) from #3 with its :(D,C) (sub)signature.
Note that
multi method abc (A $a: B $b, C $c: X $x, Y $y) {...} #5
would be ambigous in a pure regime because :(B,C) is not a strictly
more specific type than :(D).
After the successful selection of the target out of the targets #1
to #5 the contravariant part of the sig :(X,Y) is checked and then
the invocation procedes with binding the args to the params.
: method doit (...) on (invocant sig) { ... }
I don't see how that relates.
Take the example #2 from above which could be written
multi method abc (X $x, Y $y) on (A $a, B $b, C $c) {...}
and the cascading version as
multi method abc (X $x, Y $y) on (A $a) on (B $b) on (C $c) {...}
or with the invocants at the front
multi method on (A $a, B $b, C $c) abc (X $x, Y $y) {...}
But I'm not a native who could decide if 'method on' is the right
choice of preposition. Perhaps it should be 'method in'? But that
would further the conception of methods beeing inside of classes
which they are only in the special case of a dispatch implementation
through vtbls carried around by the objects. My old problem of 'is
the object or the method in charge'.
The metaphor that illustrates my point is that $ball.throw() looks
funny in my mind if you think of the $ball throwing itself. Compare
with $Larry.talk() where the talking style is inherent in $Larry.
: Well, we could take the ¢ sigil to form invocant twigils ¢$, ¢@, ¢%, ¢&
: which look a bit nicer with ^ though: ^$, ^@, ^%, ^&. The association
: with $^, @^, %^, &^ in placeholders is a bonus in my eyes because they
: are post dispatch on void invocants :)
Don't know what that means either.
'post dispatch on void' was a poor attempt to paraphrase that I see
a sub as a *very* unspecific method. That is a sub call in method style
$x.foo();
dispatches to the sub foo only if there is no other applicable method at
all. Submethods in that view are methods that are specialized on Undef of
the respective class.
BTW, is ($x,$y).foo(1,2) valid multi method invocation syntax? Note that
if there is nothing else but
sub foo ([EMAIL PROTECTED]) {...}
in scope it could be selected and called with
@bar[0] = $x;
@bar[1] = $y;
@bar[2] = 1;
@bar[3] = 2;
: The guiding theme in my line of thinking about twigils is that there's
: a void between their two chars. A "pair" of type constraint and uncaptured
: actual invocant type so to say. Well and we could capture it with
:
: method doit ( Constraint ^Actual $foo, NonInvocant $blahh ) {...}
:
: to deal have it available inside. Am I makeing sense? Which impact all
: this has an the self method discussion I don't know, but ^. and .^ come
: to mind. The former would make ^.foo a method on the current invocant
: and a bare .^ would dispatch the current method on the topic or some such.
I haven't the foggiest clue if you're making sense. And that's the
scary part.
OK, forget the part about self calls inside the method implementation and
let's look at the type variable aspect only. If I understand the concept
correctly then ^ splits the type aspect of a v
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote:
> : On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
> :
> : > Plus, the argument is a straw man. Instead of:
> : >
> : > class Some::Class is also {
> : > }
> : >
> : > you would do:
> : >
> : > class My::Version {
> : > does Some::Class;
> : > }
> : >
> : > Problem solved.
> :
> : Don't forget the fun of modifying all existing uses of Some::Class to
> : use My::Version instead, if that's even possible.
>
> That should mostly be handled by virtualized class names.
Will I be able to do something like:
package Foo;
$*VERSION = 1.3.2;
use Foo-1.3.1;
role My::Foo { does Foo; ... }
alias My::Foo -> Foo; # Or whatever the syntax should be
And, in my other code, "use Foo;" will DWIM?
Re: Rough thoughts on the Object Space
On Wed, Oct 26, 2005 at 11:00:55 -0700, Larry Wall wrote:
> Yes, Perl 5 is conceptually a 3-pass compiler, but the passes have to
> be interwoven to do the "literate compilation" thing that Perl demands.
But it's recursively interwoven If it was nonrecursive things
would be much uglier ;-)
IMHO, to ammend to stevan's mail, one fundamental step is linking.
This happens in the middle of the type checking phase - some type
info is extracted from a single unit, and other type info is
extracted from already compiled units that are being linked.
In Perl 5 linkage was completely ad-hoc, and was imperative, and
side effect reliant, as opposed to declarative:
*{$sym} = $subref;
The reason this part is fundamental is that it implies the
separation between the bits of code.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpmCOR5vHTHf.pgp
Description: PGP signature
Re: Ways to add behavior
On Wed, 26 Oct 2005, Rob Kinyon wrote:
I'd like to take this moment and point to my somewhat hand-wavy
metamodel proposal from last week. When Stevan and I were talking
about this, we called it a "quark." "Atom" also works quite nicely,
but quarks are cooler.
They're also colorful. Does this mean we will have a colour trait? But
most importantly, who is supposed to be $Muster_Mark?
Seriously, "quark" was originally chosen as a name because of the
appearance of _three_ (somewhat "mysterious") "objects". Now it would
indeed be cool to borrow the term in a CS context, especially in Perl, but
it would be better suited in a "naturally ternary" (say,
{property,structure}-wise) context.
Michele
--
Il tempo e' denaro, ma anche il denaro e' denaro.
- William Gibson, "L'accademia dei sogni".
