Re: Dynamic libs don't seem to work
William Coleda wrote: Can you give us a copy of the generated myconfig file in the top level parrot directory? yep, this is it: = Summary of my parrot 0.1.1 configuration: configdate='Thu Dec 9 23:53:50 2004' Platform: osname=linux, archname=i486-linux jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl5.8.4 Compiler: cc='cc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-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 = thanks, kj Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory error:imcc:Unknown PMC type 'TclString' in file 'languages/tcl/lib/commands/upvar.imc' line 13 included from 'languages/tcl/lib/tcllib.imc' line 1 make: *** [lib/tcllib.pbc] Error 17 Also: - when doing make test, all tests with dynamic pmc seem to fail. - following instructions in dynoplibs and trying to execute the test.pasm in dynoplibs/ doesn't work either. Couldn't load 'myops_ops': myops_ops: cannot open shared object file: No such file or directory Couldn't load 'foo': foo: cannot open shared object file: No such file or directory Couldn't load 'libnci': libnci: cannot open shared object file: No such file or directory error:imcc:parse error, unexpected IDENTIFIER, expecting PARROT_OP in file 'dynoplibs/test.pasm' line 43 Obviously, there is something wrong with dynamic libs. I don't get what I'm doing wrong. This should all work right? Perljam (sorry, don't know his real name) told me on IRC he did a fresh checkout, and it all worked. Any ideas? thanks, klaas-jan
Re: Dynamic libs don't seem to work
Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory Try rebuilding after you issue the following from your top level parrot directory: perl Configure.pl --prefix=`pwd` - Sam Ruby
Re: Python method overloading
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
I continue to disagree with the part of this conclusion where you insert
find_method into the discussion. To give a concrete example: at the
moment the lookup involved in abs_p_p does not involve the use of
find_method.
$ cat abs.imc
.sub main
.local pmc cl, o
cl = newclass A
$I0 = typeof cl
o = new $I0
$P0 = new Undef
$P0 = abs o
print $P0
.end
.namespace [A]
.sub __absolute
.param pmc d
d = ok\n
.end
$ parrot abs.imc
ok
$ parrot -t abs.imc
...
# find_method class 'A' method '__absolute': Sub
# Calling sub '__absolute'
...
But only for classes that inherit from delegate.
If Perl programmers need to know about Parrot method names, then
effectively this beomes part of the Perl language specification. I do
not have the luxury of changing the Python language specification.
If you are targeting Parrot you have to know the opcode names *and* the
reserved method names, sorry.
People writing Python to Parrot translators need to know Parrot
internals. People who merely write in Python should not.
... (BTW, a combined instantiate method
does not map well to Python which has separate __new__ and __init__
methods.
We have the __init hook too. This is separate.
Ultimately, I believe that this will need to be revisited.
$ parrot -t abs.imc
...
6 new P17, I30 - P17=PMCNULL, I30=72
# find_method class 'A' method '__init': no
... My recommendation
is to stick to primitives, and simply provide a new_p_p).
What is the second _p for?
What I am thinking of is something like:
inline op new(out PMC) {
$1 = VTABLE_instantiate(interpreter, $2);
goto NEXT();
}
Where instantiate does not support a variable number of arguments
(Parrot calling conventions). If you then want to init the PMC you have
obtained, you can use the separate init hook (with a variable number of
arguments).
That is only because the design you have in mind conflates Parrot and
language operations. There is no reason that __abs__ couldn't call
VTABLE_abs, or that __add__ can't make use of MMD_ADD.
And if the class implements it's own __absolute or __add, we do a
separate redispatch? And dynclasses/py* does it differently to
dynclasses/perl*. Why don't you just believe me that that's error prone
and slow ;-)
Only in the sense that CoRoutine and RetContinuation provide
incompatible (i.e., different) implementations of invoke. However,
they are very compatible in the only sense that matters: they both
implement the common protocol named invoke.
Arguably, the very reason that a find_method VTABLE entry was provided
was to enable different PMCs to provide different implementations of
this protocol.
The code that backs perl classes can have implementations find_method
that looks for __add methods with a given parameter signature, and the
code that backs python classes can have implementations of find_metho
that looks for __add__ methods with a different parameter signature.
- Sam Ruby
Re: flip flop xx Inf
On Fri, 3 Dec 2004, Larry Wall wrote: On Sat, Dec 04, 2004 at 01:11:30AM +0100, Juerd wrote: : What happens to the flip flop operator? Will .. in scalar context remain : the same? I don't think so. It's definitely a candidate for a longer Huffmanization simply in terms of frequency of use. On top of which, almost no Perl 5 programmers even know what it does. Plus it's Well, I have the vague feeling that you may have some more experience with Perl than I do, however such a claim seems a bit exaggerate to me. For example I do know what it does and even though I consider myself to be at most an advanced beginner rather than an expert, I think that I use it correctly and to great advantage, when I do use it, that is... For sure it can't be just me!! Michele -- DAX ODIA ANCORA - Scritta su diversi muri milanesi
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, 3 Dec 2004, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
Partly it does. The point is that not only the is simple, but that it
is also visually distinctive, which is important IMHO.
Obviously the new proposal of unary C= is just as good from this point
of view...
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
Of course they'd understand better the latter, but I think that there's a
limit to non-Perl-speaking-people-friendship. After all this may be useful
for learning perl, but learning it to a good degree would always involve
getting acquainted with quite a lot of typical idioms, so this does not
make much of a point IMHO, provided that when a typical user becomes
familiar with those idioms he can perceive (i) how good they look in
source code (ii) how useful they result in practice.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
Indeed it's not *purely* a matter of looking OO, but of looking yet
another more-or-less alphabetic string (yes, even with a prepended point:
it's just not as markedly distinctive!). As I said, is deeply etched in
Perl programmers' cortex as an input operator. In other words it may well
be cargo cult, but not in a totally negative acceptation: I mean... till
it works, and works well as it currently does!
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
OTOH, as a side note, but not a totally unrelated one, I guess, one should
pay some attention not to exaggerate following natural languages
principles in designing programming languages: granted, I appreciate their
pervasiveness in (current) perl and indeed probably this is one of the
reasons I love it. But I think that there are some natural limits to this
as well: AFAIK any attempt to overcome them was basically a failure. We
want the *right* mixture of conciseness, intutivity, clarity instead. In
this sense a construct like
while () {
...
}
really doesn't resamble any natural language construct as far as I can
see, but indeed it's an idiom that perl programmers easily become familiar
with and like to use... well, I think so!
Michele
--
I hold a square measuring 10x10 metres away from a person who is standing
100 metres away.
I ask them to shoot the square with a high-accuracy gun.
Don't stand there holding the square when they are shooting...
- Robert Israel in sci.math, Re: Scaling
Re: cvs commit: parrot/t/pmc perlstring.t
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: -=item Cvoid* invoke(void* next) IMHO, all of these can go. The invoke methods need to be on the PMCs returned by get_class. That's exactly how it worked - the PMCs get_class returns a PMC of the same type, so they act as their own class. But the invoke syntax is gone, yes. I leave that to the Py* types. IMHO, the notion of a pythonic slice can go. Yep. - Sam Ruby Thanks for looking through it, leo
Re: state vs my
On Fri, 3 Dec 2004, Brent 'Dax' Royal-Gordon wrote: Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. Personally I'm glad this is going away. I'm not bothered by the caveats of the docs: it's the construct itself that somehow strikes me as innatural, to the point that I've never been bitten in the neck by using it inadvertently for I would have never ever though about doing so... In fact a declaration is fundamentally a way to introduce an object to be used subsequently, and the fact that it can be used also in the same statement in which it is declared doesn't make things really different. So how can I *declare* something depending on a condition?!? I can branch over a condition to execute either one block or another *within* which things can be declared or some such. Not the other way round... Michele -- A question out of curiousity: who is this Green of Green's functions? Is he the same person of Green's theorem? :) Yes. He was also an early environmentalist; hence the current phrases green this and green that... - David C. Ullrich on sci.math, thread Who is Green?
Re: iterators and functions (and lists)
On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have true functions, they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). Michele -- I find the line I am not pestering anybody, I am asking questions on usenet. That's what usenet is for. a classic. It's like I am not talking to you, I am just opening and closing my mouth while standing close to you. That's what a mouth is for. - David Kastrup, on comp.text.tex (slightly edited)
Re: specifying the key Type for a Hash
OT On Mon, 6 Dec 2004, Luke Palmer wrote: Well, there's always domain and range, if we want to be mathematical. [snip] What you want here is domain and codomain. Which leads me to believe that you don't want either. For the record, in most connections range would be just as good. Indeed codomain, especially from the algebraic/categorial point of view is sounds somehow better. /OT Michele -- [ standard bull-shit snipped ] Your friend, Nathan the Great Age 11 The best of your postings is the backside. Please let the front also blank in the future. - Rainer Rosenthal in sci.math, Re: Cantor Paradox :-)
Re: iterators and functions (and lists)
On Mon, 6 Dec 2004, Larry Wall wrote: to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array Hope not to bark something utterly stupid, but... if one iterates over such a list, may it be that on the first Clast one really starts over from the second 0? Well, unless some adverb is given to the point that one really has to last :everything # or somesuch... Michele -- Some time ago,I managed to wipe out almost all of /usr/bin while doing some cleaning (don't drink and root...:-) - Predrag Ivanovic in CRUX mailing list
Re: [CVS ci] class refactoring 1 - Integer
Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: I took a look into this. Apparently, in Perl5, the result of xor'ing undef with anything is undef. I'm not suggesting that this is either right or wrong (it actually was surprising to me), Yep. It doesn't really follow the definition of xor, nor does it match the implementation of other types. I'd leave that to language lawyers. Undef (like null in SQL) could be interpreted to mean I don't know, and a case could be made that I don't know xor'ed with anything is I don't know. Furthmore, the concept of a logical xor seems to be a Perl innovation. Languages like C and Python don't have such a concept. Finally, Perl doesn't seem to be consistent. Anything xor undef always seems to return the leftmost argument. *shrug* Unfortunately, this does not work as inheritance seems to take precedence over defaults. Partly. Specific functions are set last. The precedence seems to be specific functions, inheritance, and then defaults. ... I think that this should be the other way around: a subclass should be able to easily override all MMD operations for a given method. The problem is that the passed in mmd init list has no indication, if a default function is installed or a inherited or a specific one. The passed in mmd init list only has specific and defaults. Finally, I took a look at Parrot_mmd_register_parents. Don't ;-) Oops. ;-) ... This seems more complicated than it needs to be, Well, yes. But I'm not even sure if it's worth the effort to improve it. The static MMD table doesn't handle dynamic inheritance. While you can install a function with mmdvtregister, this is just for a pair of types, which is rather useless for classes that inherit from one of the types. But which other functions for which types should be registered too? This is the reason for the proposal of going fully dynamic with MMD too. OK, I'll leave this alone unless I have a specific problem that I need to fix. Hopefully by then, all this will go away. - Sam Ruby
Re: [CVS ci] class refactoring 1 - Integer
Leopold Toetsch [EMAIL PROTECTED] writes:
Sam Ruby [EMAIL PROTECTED] wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of xor, nor does it match
the implementation of other types.
Which Perl5 (xor, undef) would this be? It does not look like the
result is undef around here:
[EMAIL PROTECTED]:~$ perl -le 'print defined($_)?defined:undef, : «$_»
for map {(undef xor $_), ($_ xor undef), (undef ^ $_), ($_ ^ undef)}
string, , -1, 0, 1 , 2'
defined: «1»
defined: «1»
defined: «string»
defined: «string»
defined: «»
defined: «»
defined: «»
defined: «»
defined: «1»
defined: «1»
defined: «4294967295»
defined: «4294967295»
defined: «»
defined: «»
defined: «0»
defined: «0»
defined: «1»
defined: «1»
defined: «1»
defined: «1»
defined: «1»
defined: «1»
defined: «2»
defined: «2»
[EMAIL PROTECTED]:~$ perl -v
This is perl, v5.8.5 built for i686-linux
Copyright 1987-2004, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
[EMAIL PROTECTED]:~$
--
C++ is the only current language making COBOL look good.
-- Bertrand Meyer
Re: Python method overloading
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
# find_method class 'A' method '__absolute': Sub
# Calling sub '__absolute'
But only for classes that inherit from delegate.
Yes of course. Objects's derived from ParrotObject (i.e. Parrot standard
objects) dispatch to overloaded functions via the meta-class helper
class delegate. Standard PMCs call pmc-vtable-absolute().
But infix operations like the add opcode dispatch via mmd_dispatch_*
and have no delegate functionality.
I've posted a graphic of all these possibilities in one of the mails.
This is the reason why I'm prefering to replace all with just one
scheme that works, i.e. doing full dynamic dispatch at the opcode level.
People writing Python to Parrot translators need to know Parrot
internals. People who merely write in Python should not.
Why on earth should Python writers know Parrot internals? Why do you
come to such a conclusion?
... (BTW, a combined instantiate method
does not map well to Python which has separate __new__ and __init__
methods.
We have the __init hook too. This is separate.
Ultimately, I believe that this will need to be revisited.
What is wrong? Does it not work?
... My recommendation
is to stick to primitives, and simply provide a new_p_p).
What is the second _p for?
What I am thinking of is something like:
inline op new(out PMC) {
$1 = VTABLE_instantiate(interpreter, $2);
There is no second argument on the new signature. But I presume it's a
class PMC. Well doing:
cl = getclass Foo
o = cl.instantiate()
does exactly that - it constructs a new Integer with the default value by
calling pmc_new/init.
OTOH when you have
cl = getclass Foo
o = cl.instantiate(5)
you have two possiblities: implement the instantiate vtable (or let a
user provided overridden method do the initialization) or do the init
stuff in __init, which get's again the arguments according to pdd03.
If you then want to init the PMC you have
obtained, you can use the separate init hook (with a variable number of
arguments).
This is working already.
.sub main
.local pmc cl, o
cl = subclass Integer, A
o = cl.instantiate(5)
print o
print \n
.end
.namespace [A]
.sub __init method
.param int i
self = i
.end
The code that backs perl classes can have implementations find_method
that looks for __add methods with a given parameter signature, and the
code that backs python classes can have implementations of find_metho
that looks for __add__ methods with a different parameter signature.
Sam, there *should* be no difference between a pythonic __add__
and Parrot's __add. Currently calling conventions don't match - I've
posted a mail WRT this and it needs fixing.
And Perl doesn't have an __add or such. Perl5 has use overload '+' =
... Perl6 has a special infix:+ syntax.
So the prerequisit is that Parrot's function signature of overloaded
methods is appropriate for Python and Perl.
We have:
a = b + c
You already did show the Python code, which emits the Parrot opcode
add, which does MMD dispatch. But we both posted an example that
overloads the operator + with a piece of user provided function.
You've stated that the code to provide this functionality is missing in
py*.pmc. But when you write it, you have of course to know, that a
setattribute (or a __dict__ update) with the key __add__ is meaning an
overload of the + operator. Else you wouldn't be able to roll your own
dispatcher.
So when your translator encounters:
def myadd(self, r):
return self - r
class J(int):
__add__ = myadd
i = J(44)
print i, i + 2
you have to know that myadd will be the function that is called, when an
add operation for an object of class J is executed. This is the
place where you would call:
Parrot_store_global(interp, J, __add, myadd);
The subroutine PMC myadd is stored into the namespace of J as
the subroutine labeled __add.
In the current system you would have to call mmdvtregister to
associate the myadd subroutine with the add opcode for the given
types - but that doesn't work for objects derived from class J nor for
mixed types.
So what I'm saying (or I'm trying to) is: when at the opcode level the
add opcode is actually acting as a method call, everything works as
now including dynamic overriding of MMD functions. And there is no need
at all for duplicating a lot of Parrot core functionality in the
py*.pmcs.
I've described that in MMD dispatch. With the help of the inline cache
this scheme is 30% faster then the current static MMD table dispatch.
- Sam Ruby
leo
Re: state vs my
On Sat, 4 Dec 2004 22:03:19 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of state:
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense
: for me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time
through.
third variant is what we get if we replace Cstate with perl5 my $var if
0 here (not exactly, because $var start value would be undef in that
case).
Certainly that one doesn't, since it doesn't refer to any external
lexicals.
Perhaps statehood should be limited to official subs just like
return is.
they must be limited. It would be really strange if
sub test {
for 1..3 {
state $var = 1;
print $var++
}
}
test();test();
and
sub test {
my $a;
for 1..3 {
do_something_with($a);
state $var = 1;
print $var++
}
}
test();test();
would print different results.
But actually I would prefer if state somehow could be made to work other
way, even if closure isn't cloned. I mean, first variant, mentioned at top
of the message. Then we could use state vars in things like:
# I know that _this_ particular task could be solved better
# I'm not good in examplification.
%hash = map {state $k=1; $_ = $k++ } @array;
and always get our keys numbered from 1. And one still get behaviour(2) if
state declaration is at start of subroutine.
(Hmm, but I can't figure if it is possible )
This applies to FIRST {...} blocks too.
for 1..10 {
for 1..3 {
FIRST {...}
...
}
}
I'd expect that FIRST would be fired 10 times, not only once, because
FIRST looks here just as a mere funny loop control structure.
and of course I don't want it to happen once here, and 10 times there,
depending on such a subtle thing as appearance of outer lexical variables
in inner block. hmm.. but I don't want unnecessary cloning either, if it'd
slow down my program. I have a cake, please show me where to bite:)
Re: [CVS ci] class refactoring 1 - Integer
Eirik Berg Hanssen [EMAIL PROTECTED] wrote:
Which Perl5 (xor, undef) would this be? It does not look like the
result is undef around here:
[EMAIL PROTECTED]:~$ perl -le 'print defined($_)?defined:undef, : «$_»
for map {(undef xor $_), ($_ xor undef), (undef ^ $_), ($_ ^ undef)}
string, , -1, 0, 1 , 2'
This xor is returning the bool values, which is quite different to
returning a value according to the xor of the booleans.
perl -le 'print defined($_)?defined:undef, : «$_»
for map {(undef xor $_), ($_ xor undef)}
string, , undef, -1, 0, 1 , 2'
dropping bitwise xor, and including undef xor undef reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 ! $3) ? $2 : ($3 ! $2) ? $3 : 0;
goto NEXT();
}
static void
mmd_fallback_lxor_pmc(Parrot_Interp interp, PMC *left, PMC *right, PMC *dest)
{
INTVAL left_truth, right_truth;
PMC *true;
left_truth = VTABLE_get_bool(interp, left);
right_truth = VTABLE_get_bool(interp, right);
if (left_truth !right_truth)
true = left;
else if (!left_truth right_truth)
true = right;
else {
VTABLE_set_integer_native(interp, dest, 0);
return;
}
VTABLE_set_pmc(interp, dest, true);
}
We need language lawyers ;)
leo
Re: Dynamic libs don't seem to work
Sam Ruby wrote: Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory Try rebuilding after you issue the following from your top level parrot directory: perl Configure.pl --prefix=`pwd` - Sam Ruby thanks, that worked! (what does this --prefix='pwd' do?) dynoplibs still doesn't work, however. is this correct? klaas-jan
New qa.perl.org updates
http://qa.perl.org/testing-guidelines.html is updated. So is http://qa.perl.org/test-modules.html, with new modules and some reorganization. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Dynamic libs don't seem to work
Klaas-Jan Stol wrote: Sam Ruby wrote: Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory Try rebuilding after you issue the following from your top level parrot directory: perl Configure.pl --prefix=`pwd` - Sam Ruby thanks, that worked! (what does this --prefix='pwd' do?) dynoplibs still doesn't work, however. is this correct? Ultimately, when Parrot is released and someone installs it, shared libraries will go into a place like /usr/local/lib. So, by default, that's where Parrot is looking for tcl_group. However, you aren't installing it, or copying these shared libraries. Instead you want Parrot to look *here*. That's where prefix comes in. Configure.pl saves your prefix in src/parrot_config.h where it is used to construct paths used at runtime. `pwd` simply is your current working directory. Sorry, I don't know anything about dynopslibs. - Sam Ruby
Re: [CVS ci] class refactoring 1 - Integer
Leopold Toetsch [EMAIL PROTECTED] wrote
dropping bitwise xor, and including undef xor undef reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 ! $3) ? $2 : ($3 ! $2) ? $3 : 0;
goto NEXT();
}
We need language lawyers ;)
IANAL, but I am a mathematician.Because Cxor necessarily always
depends on *both* its arguments, analogies with Cand and Cor are
inappropriate.Cxor cannot short-circuit, and it is not sensible
to return as result either of the arguments. So the above macro
is misguided nonsense.
Perl5 Cxor always returns a standard boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Mike Guy
Re: S05 question
On Thu, Dec 09, 2004 at 11:18:34AM -0800, Larry Wall wrote:
On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote:
: I'm still going to prefer using :=, simply as a good programming
: practice. My mind sees a big difference between building a parse-tree
: object and just grepping for some word I want in a string. Within a
: rule{} block, there is no place except the rule object to keep your
: data (hypothetically -- haha), so it makes sense to have everything
: capture unless otherwise specified. There's no such limitation in a
: regular code block, so I don't see the need.
Since regex results are lexically scoped in Perl 6, in a regular
code block we can do static analysis and determine whether there's
any possibility that $foo is referenced at all, and optimize it
away in many cases, if it turns out to be high overhead. But as Patrick
points out, so far capture seems pretty cheap.
It might turn out to be worth optimizing only when ALL of the
capture blocks are unused - the saving from avoiding setup
costs together with avoiding the (too small to be a bother
by themselves) incremental costs, might be significantwhen
taken together.
--
Re: New qa.perl.org updates
Two comments: I would add Test::MockModule to the test modules. I've stopped using my Sub::Override since I encountered this very useful tool. On the test guidelines, perhaps there should be an or die recommendation after use_ok. Life gets pretty miserable if that fails but many subsequent tests pass and testa # 217 and beyond fail because the module didn't load properly. You can spend hours debugging because you didn't see the use_ok failure at the top. (I speak from extremely painful personal experience on this.) Cheers, Ovid --- Andy Lester [EMAIL PROTECTED] wrote: http://qa.perl.org/testing-guidelines.html is updated. So is http://qa.perl.org/test-modules.html, with new modules and some reorganization. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
RE: [CVS ci] class refactoring 1 - Integer
Precedence. print(day\n xor night\n); -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED] -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED] Sent: Friday December 10, 2004 13:28 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [CVS ci] class refactoring 1 - Integer Mike Guy wrote: Perl5 Cxor always returns a standard boolean value, i.e. dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same thing. Try: perl -le print 'day' xor 'night' On the version of Perl I have installed, I get day as the result. - Sam Ruby
Re: Undeclared attributes
Dave Whipp wrote:
Attributes are declared with Chas, but also have a unique signil
C$.. So is it strictly necessary to declare them? Or rather, is it
Cno strictly necessary -- i.e. is the following legal?
no strict;
class Foo {
method bar {
say $.a++
}
}
For the standard layout, I'd think it'd be good to declare the
attributes, but perhaps not necessary. An object of class C, IIRC, will
just be an object in the parrot sense; doing an Caddattribute Px, Sy
will cause the attribute to be added to all other objects of that class,
and to all objects that is or does that class; That might involve
a whole lot of work.
But maybe you are asking if Perl6 can intuit that you implied an
unwritten Chas $.a But it could be a Chas $.a or Cour $.a or
Cmy $.a.
BTW, should we be able to write pragmas like this:
class Foo isnt strict{...}
or
class Foo isn't strict{...}
--abhijit
[perl #32996] Register coloring not dirtying registers for method calls properly
# New Ticket Created by Dan Sugalski # Please include the string: [perl #32996] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32996 The register coloring algorithm's not dirtying registers right, and looks to be assuming that things are in registers across method calls when they really aren't. The following test program shows the problem. While it should print In method 1\nIn method 2\n a few dozen times, instead it dies partway through. From a trace it looks like the coloring algorithm assumes that an object is in a register that gets clobbered (correctly) by the method calls. .namespace [Foo] .sub __biginit prototyped, @MAIN newclass $P0, Foo $I1 = find_type Foo $P1 = new $I1 $P1.method1() $P1.method2() $P2 = new $I1 $P2.method1() $P2.method2() $P3 = new $I1 $P3.method1() $P3.method2() $P4 = new $I1 $P4.method1() $P4.method2() $P5 = new $I1 $P5.method1() $P5.method2() $P6 = new $I1 $P6.method1() $P6.method2() $P7 = new $I1 $P7.method1() $P7.method2() $P8 = new $I1 $P8.method1() $P8.method2() $P9 = new $I1 $P9.method1() $P9.method2() $P10 = new $I1 $P10.method1() $P10.method2() $P11 = new $I1 $P11.method1() $P11.method2() $P12 = new $I1 $P12.method1() $P12.method2() $P13 = new $I1 $P13.method1() $P13.method2() $P14 = new $I1 $P14.method1() $P14.method2() $P15 = new $I1 $P15.method1() $P15.method2() $P1.method1() $P1.method2() $P2.method1() $P2.method2() $P3.method1() $P3.method2() $P4.method1() $P4.method2() $P5.method1() $P5.method2() $P6.method1() $P6.method2() $P7.method1() $P7.method2() $P8.method1() $P8.method2() $P9.method1() $P9.method2() $P10.method1() $P10.method2() $P11.method1() $P11.method2() $P12.method1() $P12.method2() $P13.method1() $P13.method2() $P14.method1() $P14.method2() $P15.method1() $P15.method2() end .end .sub method1 prototyped, method print In method 1\n .pcc_begin_return .pcc_end_return .end .sub method2 prototyped, method print In method 2\n .pcc_begin_return .pcc_end_return .end -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #32996] Register coloring not dirtying registers for method calls properly
Dan Sugalski [EMAIL PROTECTED] wrote: The register coloring algorithm's not dirtying registers right, There are still some compatibility hooks inside parrot that set P1 on the caller's end (or on both sides). I'll remove this remenants RSN. leo
Re: [CVS ci] class refactoring 1 - Integer
Mike Guy [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote
dropping bitwise xor, and including undef xor undef reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 ! $3) ? $2 : ($3 ! $2) ? $3 : 0;
goto NEXT();
}
We need language lawyers ;)
IANAL, but I am a mathematician.Because Cxor necessarily always
depends on *both* its arguments, analogies with Cand and Cor are
inappropriate.Cxor cannot short-circuit, and it is not sensible
to return as result either of the arguments.
Cxor can't of course be short-circuit and above code isn't. Both values
are evaluated WRT trueness, always.
... So the above macro is misguided nonsense.
Not quite. It gives one value if one is true or 0 (false). This is more
information then the perl5 implementation returns. The returned value (if
any) is still true but usable, if I just want one of both. Well that's
logical xor - not binary xor.
Perl5 Cxor always returns a standard boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Maybe, IANAL.
Mike Guy
leo
Re: [CVS ci] class refactoring 1 - Integer
On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote: We need language lawyers ;) IANAL, but I am a mathematician.Because Cxor necessarily always depends on *both* its arguments, analogies with Cand and Cor are inappropriate.Cxor cannot short-circuit, and it is not sensible to return as result either of the arguments. Not quite. It gives one value if one is true or 0 (false). This is more information then the perl5 implementation returns. The returned value (if any) is still true but usable, if I just want one of both. Well that's logical xor - not binary xor. Agreed. At some point this probably belongs on perl6-languages (and apologies if this posting to p6i is therefore inappropriate). But if the following hold (Perl 5): print (0 and hello);# outputs 0 print ( and hello); # outputs print (0 or hello); # outputs hello print ( or hello);# outputs hello print ( or 0); # outputs 0 print (0 or ); # outputs print (not( or 0)); # outputs 1 print (not(a and b)); # outputs it seems like one should be able to do: print (0 xor hello);# outputs hello print ( xor hello); # outputs hello print (hello xor 0);# outputs hello print (hello xor ); # outputs hello print (world xor hello); # outputs print (0 xor ); # outputs 1 print ( xor 0); # outputs 1 Just as Cor returns its first non-false argument, the interpretation of Cxor would be that it returns its single non-false argument, or 1 if both (all?) arguments logically evaluate to false. Perl5 Cxor always returns a standard boolean value, i.e. dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same thing. Keep in mind that in Perl 6 the boolean forms of Cand, Cor, and Cxor (the ones that always return 0 or 1) are C?, C?|, and C?^. So perhaps Cxor should be able to return more than just 0 or 1. Pm
Re: [perl #32989] Problem in linux ppc
On Fri, 2004-12-10 at 07:23 -0800, via RT wrote: trying to compile parrot (cvs) in a linux ppc machine I get the following error. It looks like the configure process gets confused and does not compile the ppc jit code when it is under linux: This is a duplicate of #32514, which still awaits the gentle touch of a Configure hacker. -- c
Re: [CVS ci] class refactoring 1 - Integer
[ From p6i ] Patrick R. Michaud writes: On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote: Not quite. It gives one value if one is true or 0 (false). This is more information then the perl5 implementation returns. The returned value (if any) is still true but usable, if I just want one of both. Well that's logical xor - not binary xor. Agreed. At some point this probably belongs on perl6-languages (and apologies if this posting to p6i is therefore inappropriate). But if the following hold (Perl 5): print (0 and hello);# outputs 0 print ( and hello); # outputs print (0 or hello); # outputs hello print ( or hello);# outputs hello print ( or 0); # outputs 0 print (0 or ); # outputs print (not( or 0)); # outputs 1 print (not(a and b)); # outputs it seems like one should be able to do: print (0 xor hello);# outputs hello print ( xor hello); # outputs hello print (hello xor 0);# outputs hello print (hello xor ); # outputs hello print (world xor hello); # outputs print (0 xor ); # outputs 1 print ( xor 0); # outputs 1 Just as Cor returns its first non-false argument, the interpretation of Cxor would be that it returns its single non-false argument, or 1 if both (all?) arguments logically evaluate to false. Well, IAAL. :-) In particular, xor is analogous, operatorwise, to the junctive one(). one() represents its single true value when it evaluates to true in conditionals: my $smin = one(3,6,9,12) 5; So it seems logical that xor do the same. I don't see any loss of generality in doing so, and you're keeping around more information. For the PMC variant, it seems like returning *the* true PMC is the correct thing to do, because the definiton of the canonical true differs from language to language. Parrot has a canonical false. Luke
Re: The split opcode
Patrick R. Michaud wrote: On Fri, Dec 10, 2004 at 01:34:03PM -0500, James deBoer wrote: Currently, the split opcode is declared as 'split(out PMC, in STR, in STR)' where $2 is a regex. PGE, however, currently supports three types of regular expressions, and more are likely going to be added. So, which type of regular expression should split use? [...] A solution: Declare split as 'split(out PMC, in PMC, in STR)' where $2 would be a compiled PGE::Match object. This lets you pick what kind of regular expression you want to use. Slight correction: Thus far a PGE::Match object is the result of performing a match between a rule and target string, not the compiled form of the rule. At present a rule is just a subroutine that returns PGE::Match objects. Eventually we may have a PGE::Rule class for representing compiled rule objects, but we're not there yet. So, $2 would need to be a rule subroutine. Going beyond that, we might want to just have a split method for PGE::Rule objects, and leave the split opcode to do fast separation of strings based on constant strings. But I'm not entirely familiar with Parrot's opcode/MMD semantics so I'll follow others' leads on this one... Pm I would even go further than that and say that if we went with PGE::Rule's split, the split opcode should be obsoleted. I can't think of a place where splitting on constant strings is not a special case of splitting on a regular expression. Evaluating a very simple regular expression (i.e. a constant string) should be fast enough that it is not worth the effort to determine if a pattern can be sent through the split opcode instead of PGE::Rule.split(). However, using a split opcode that accepts a match subroutine has the advantage that the PGE is not strictly required. It would be possible to write your own subroutines if speed or code size were issues or if you had some other crazy requirements. This raises the question: How far do we want to let the PGE into our everyday lives? - James
Re: [CVS ci] class refactoring 1 - Integer
On Fri, Dec 10, 2004 at 01:28:10PM -0500, Sam Ruby wrote: Mike Guy wrote: Perl5 Cxor always returns a standard boolean value, i.e. dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same thing. Try: perl -le print 'day' xor 'night' On the version of Perl I have installed, I get day as the result. Gordon mentioned the precedence problem here. I've not replied to his message because I couldn't be bothered to fix up the quoting and attributions. s/le/wle/ gives the hint too. Mike is quite right of course. And the code which handles this is one of the more simple parts of perl5. Provided you're not too worried about what's going on under the macros, I suppose. if (SvTRUE(left) != SvTRUE(right)) RETSETYES; else RETSETNO; -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #32996] Register coloring not dirtying registers for method calls properly
Leopold Toetsch [EMAIL PROTECTED] wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
The register coloring algorithm's not dirtying registers right,
There are still some compatibility hooks inside parrot that set P1 on
the caller's end (or on both sides). I'll remove this remenants RSN.
Looking a bit deeper into this bug reveals that above sentence doesn't
describe fully what happens, and it additionally depends on the register
allocator (CVS or new).
1) current CVS allocator
* P28 .. P30 are used to allocate temps and not allocated else
* P31 is reserved for spilling
* the old allocator doesn't have the code WRT preserved registers, which
was written for the new one (it could be backported)
* the register allocator needs 3 more registers and allocates P0, P1, P3
(P2 is visible in set P2, Px that moves the object in place)
Now implicit register usage strikes back. The register allocator isn't
aware of the side effect that Ccallmethodcc clobbers P0, P1, and S0.
2) new allocator
* has a list of allocatables usable for temps and has a clear notion
of preserved vs non-preserved registers
static const char assignable[4][5] = {
/* 0 1 2 3 4 */
{ 0, 0, 0, 0, 0, }, /* I */
{ 0, 1, 1, 1, 1, }, /* S */
{ 0, 0, 0, 1, 1, }, /* P */
{ 1, 1, 1, 1, 1, }, /* N */
};
* code would execute correctly, one more used register would cause
spilling
leo
Re: [CVS ci] class refactoring 1 - Integer
Patrick R. Michaud [EMAIL PROTECTED] wrote: Just as Cor returns its first non-false argument, the interpretation of Cxor would be that it returns its single non-false argument, or 1 if both (all?) arguments logically evaluate to false. Yep, except *0* if both evaluate to either true or false. Pm leo
Re: The split opcode
James deBoer [EMAIL PROTECTED] wrote: I would even go further than that and say that if we went with PGE::Rule's split, the split opcode should be obsoleted. All these function/method like opcodes will be refactured somewhen. WRT split (you write): PGE::Rule.split() in general $P0.split(...) where $P0 is a namespace or object that can split. For some bits of more performance a user could do: cl = getclass String cl.split(...) assuming that the current split on strings moves to the String class. This raises the question: How far do we want to let the PGE into our everyday lives? PGE is a Parrot core feature available and usable for all languages using the Parrot engine. - James leo
Re: [CVS ci] class refactoring 1 - Integer
On Sat, Dec 11, 2004 at 04:42:54AM +0100, Leopold Toetsch wrote: Patrick R. Michaud [EMAIL PROTECTED] wrote: Just as Cor returns its first non-false argument, the interpretation of Cxor would be that it returns its single non-false argument, or 1 if both (all?) arguments logically evaluate to false. Yep, except *0* if both evaluate to either true or false. Oh yeah, I got my truth values messed up there--I don't know what I was typing. I stand corrected, although the return value in this case should probably be in a string context (or, to follow Perl 5 somewhat, whatever corresponds to the value of false for the type of the last argument). Pm
Re: [perl #32996] Register coloring not dirtying registers for method calls properly
Dan Sugalski [EMAIL PROTECTED] wrote: The register coloring algorithm's not dirtying registers right, and looks to be assuming that things are in registers across method calls when they really aren't. Fixed and thanks for the test case, leo
RE: New version of Test::LongString
I use Text::Differences for this, as it will show which lines are
different, rather than just the first 50 characters. Much
easier for me to diagnose problems.
Something I put at the top of a lot of my test scripts is:
if(eval require Test::Differences; 1) {
no warnings 'redefine';
*is_deeply = \Test::Differences::eq_or_diff;
}
I think (BICBW) that it was Richard Clamp who first suggested this
idiom.
N
Re: iterators and functions (and lists)
Michele Dondi wrote: On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have true functions, they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). I wasn't intending to be taken seriously with that comment. I hope everyone realised that...
Re: iterators and functions (and lists)
Michele Dondi writes: On Mon, 6 Dec 2004, Larry Wall wrote: to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array Hope not to bark something utterly stupid, but... if one iterates over such a list, may it be that on the first Clast one really starts over from the second 0? Well, unless some adverb is given to the point that one really has to last :everything # or somesuch... Balancing the mathematical preposterousness and the actual usefulness of such a thing, I really don't think that's going to fly. From the finite world, and *2 look exactly the same, and I'm pretty sure that, cool as Perl is, it's still in the finite world. In particular, calling Clast and having the loop not exit is more than a little weird. Whatever you can do with that, you could do with a sligh redesign: return [ 0... ], [ 0... ]; And then your Clast :everything is a Cnext OUTER for a nested loop. Luke
Classes with several, mostly unused, attributes
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry::Triangle.
I know how this can be done in P5. Using the layout Hash things are
easy. How can P6 deal with this, without allocating too much memory to
things that'd never get used? The layout P6Hash could come to the
rescue, but there is still the issue of syntax:
what exactly does Chas $.bisector1 do? IIRC, in the P6Opaque layout,
every instance of the class would have space the size of a PMC allocated
for it. This behavior is not needed for P6Hash, and it should just leave
attributes alone until they are assigned to (where defaults are also
assigns).
In which case, maybe for that layout we can get away without declaring
all attributes, perhaps? (Since the declaration does nothing except help
the parser).
I was thinking whether we could do something like this:
class Triangle is layoutP6Hash does autovivify{
method calculate_bisectors { $.bisector1 = ...;
# $.bisector1 autovivifies
}
}
where it is an error without the autovivify, and only P6Hash supports
autovivification.
--abhijit
Undeclared attributes
Attributes are declared with Chas, but also have a unique signil
C$.. So is it strictly necessary to declare them? Or rather, is it
Cno strictly necessary -- i.e. is the following legal?
no strict;
class Foo {
method bar {
say $.a++
}
}
Re: New qa.perl.org updates
On Fri, Dec 10, 2004 at 10:01:44AM -0800, Ovid ([EMAIL PROTECTED]) wrote: I would add Test::MockModule to the test modules. I've stopped using my Sub::Override since I encountered this very useful tool. On the test guidelines, perhaps there should be an or die recommendation after use_ok. Life gets pretty miserable if that fails but many subsequent tests pass and testa # 217 and beyond fail because the module didn't load properly. You can spend hours debugging because you didn't see the use_ok failure at the top. (I speak from extremely painful personal experience on this.) Patches, please. s/html$/pod/ in the URL for the source. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [CVS ci] class refactoring 1 - Integer
Leopold Toetsch wrote:
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong
inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me), but if Parrot wanted
to provide this behavior, the seemingly obvious way for this to be coded
would be for PerlUndef to have the following:
void logical_xor (PMC* value, PMC* dest) {
MMD_DEFAULT: {
VTABLE_set_pmc(INTERP, dest, SELF);
}
Unfortunately, this does not work as inheritance seems to take
precedence over defaults. I think that this should be the other way
around: a subclass should be able to easily override all MMD operations
for a given method.
Finally, I took a look at Parrot_mmd_register_parents. This seems more
complicated than it needs to be, and that is because it is only looking
at the mmd table (the final results after overriding) instead of at the
specific overrides (the various _temp_mmd_init arrays).
An alternate approach would be for the make process to generate a
function that registers a given class into a given type slot, and code
to call each parent in order (top down) to override their slots as required.
A concrete example might help:
Parrot_PerlInt_mmd_init(interp, entry) {
const MMD_init _temp_mmd_init[] = {...};
Parrot_mmd_register(interp, entry, _temp_mmd_init, N_MMD_INIT);
}
followed later by the following calls:
Parrot_scalar_mdd_init(interp, entry);
Parrot_Integer_mmd_init(interp, entry);
Parrot_PerlInt_mmd_init(interp, entry);
- Sam Ruby
Re: [CVS ci] class refactoring 1 - Integer
Sam Ruby [EMAIL PROTECTED] wrote: I took a look into this. Apparently, in Perl5, the result of xor'ing undef with anything is undef. I'm not suggesting that this is either right or wrong (it actually was surprising to me), Yep. It doesn't really follow the definition of xor, nor does it match the implementation of other types. Unfortunately, this does not work as inheritance seems to take precedence over defaults. Partly. Specific functions are set last. ... I think that this should be the other way around: a subclass should be able to easily override all MMD operations for a given method. The problem is that the passed in mmd init list has no indication, if a default function is installed or a inherited or a specific one. Finally, I took a look at Parrot_mmd_register_parents. Don't ;-) ... This seems more complicated than it needs to be, Well, yes. But I'm not even sure if it's worth the effort to improve it. The static MMD table doesn't handle dynamic inheritance. While you can install a function with mmdvtregister, this is just for a pair of types, which is rather useless for classes that inherit from one of the types. But which other functions for which types should be registered too? This is the reason for the proposal of going fully dynamic with MMD too. An alternate approach would be for the make process to generate a function that registers a given class into a given type slot, and code to call each parent in order (top down) to override their slots as required. I don't think that this would help currently because the mmd_init table already has (defaulted) and other static inheritance. Dunno. - Sam Ruby leo
Re: [CVS ci] class refactoring 1 - Integer
Eirik Berg Hanssen wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Sam Ruby [EMAIL PROTECTED] wrote: I took a look into this. Apparently, in Perl5, the result of xor'ing undef with anything is undef. I'm not suggesting that this is either right or wrong (it actually was surprising to me), Yep. It doesn't really follow the definition of xor, nor does it match the implementation of other types. Which Perl5 (xor, undef) would this be? It does not look like the result is undef around here: My bad. I misinterpreted an empty string as an undef. Here's the test I ran: my $a = undef; $c = $a xor $a; print $c; $c = $a xor 0; print $c; $c = $a xor 1; print $c; $c = 2 xor $a; print $c; $c = 3 xor 4; print $c; $c = 0 xor $a; print $c; $c = 5 xor 0; print $c; $c = 0 xor 6; print $c; print \n; perl -v returns: This is perl, v5.8.4 built for i386-linux-thread-multi - Sam Ruby
[perl #32989] Problem in linux ppc
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #32989] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32989 --- osname= linux osvers= 2.6.9-gentoo-r9 arch= powerpc-linux-thread-multi cc= gcc 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) --- Flags: category=core severity=critical ack=no --- trying to compile parrot (cvs) in a linux ppc machine I get the following error. It looks like the configure process gets confused and does not compile the ppc jit code when it is under linux: c++ -o parrot -L/usr/local/lib -Wl,-E -g imcc/main.o blib/lib/libparrot.a -lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm blib/lib/libparrot.a(jit_cpu.o)(.text+0x2722): In function `Parrot_end_jit': src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2726):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x274e):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2752):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2772):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2776):src/jit_cpu.c:74: more undefined references to `Parrot_ppc_jit_restore_nonvolatile_registers' follow collect2: ld returned 1 exit status make: *** [parrot] Error 1 --- Summary of my parrot 0.1.1 configuration: configdate='Fri Dec 10 15:28:20 2004' Platform: osname=linux, archname=powerpc-linux-thread-multi jitcapable=1, jitarchname=ppc-linux, jitosname=LINUX, jitcpuarch=ppc execcapable=1 perl=/usr/bin/perl5.8.6 Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm' 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=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELC_ALLLD_LIBRARY_PATHLOGDIRPATH SHELL
The split opcode
Currently, the split opcode is declared as 'split(out PMC, in STR, in STR)' where $2 is a regex. PGE, however, currently supports three types of regular expressions, and more are likely going to be added. So, which type of regular expression should split use? The Perl6's split function will likely use slightly different regular expressions than TCL's split function or Python's. Picking any one regular expression (e.g Perl6's) will force the other languages to reimplement split's functionality. A solution: Declare split as 'split(out PMC, in PMC, in STR)' where $2 would be a compiled PGE::Match object. This lets you pick what kind of regular expression you want to use. An example using Perl6's regular expressions: .local string pattern .local string input .local pmc rulesub .local pmc array pattern = [\n ] # pattern to compile rulesub = p6rule_compile(pattern) # compile it to rulesub input = I held out my arm\nbut she laughed split array, rulesub, input # array will be a list of words in input Comments? Is there a simpler solution? Am I making a problem out of nothing? - James
Re: [CVS ci] class refactoring 1 - Integer
Mike Guy wrote: Perl5 Cxor always returns a standard boolean value, i.e. dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same thing. Try: perl -le print 'day' xor 'night' On the version of Perl I have installed, I get day as the result. - Sam Ruby
Re: The split opcode
On Fri, Dec 10, 2004 at 01:34:03PM -0500, James deBoer wrote: Currently, the split opcode is declared as 'split(out PMC, in STR, in STR)' where $2 is a regex. PGE, however, currently supports three types of regular expressions, and more are likely going to be added. So, which type of regular expression should split use? [...] A solution: Declare split as 'split(out PMC, in PMC, in STR)' where $2 would be a compiled PGE::Match object. This lets you pick what kind of regular expression you want to use. Slight correction: Thus far a PGE::Match object is the result of performing a match between a rule and target string, not the compiled form of the rule. At present a rule is just a subroutine that returns PGE::Match objects. Eventually we may have a PGE::Rule class for representing compiled rule objects, but we're not there yet. So, $2 would need to be a rule subroutine. Going beyond that, we might want to just have a split method for PGE::Rule objects, and leave the split opcode to do fast separation of strings based on constant strings. But I'm not entirely familiar with Parrot's opcode/MMD semantics so I'll follow others' leads on this one... Pm
Re: [CVS ci] class refactoring 1 - Integer
Sam Ruby writes:
Mike Guy wrote:
Perl5 Cxor always returns a standard boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Try:
perl -le print 'day' xor 'night'
On the version of Perl I have installed, I get day as the result.
Odd, since xoring two true values should give a false one.
Remember the precedence of xor. This is parsed:
perl -le print('day') xor 'night'
Luke
Re: overloaded operator calling conventions
Leopold Toetsch [EMAIL PROTECTED] wrote: [ fullquote ] A recent discussion with Sam has shown that the current calling conventions for overloaded operators don't match Python semantics (nor Perl6 when I interpret S06 and S13 correctly). The difference is that Parrot is passing in the destination argument while these languages are returning the operator result. E.g. def myadd(self, r): return self - r class I(int): __add__ = myadd i = I(44) print i, i + 2 Parrot is expecting and calling a subroutine like: .sub __add .param left .param right .param dest ... .end and it's run in void context. This calling convention matches the add opcode, where the destination argument has to exist. But it's not suited for HLLs as the HLL compiler can't track the subroutine usage back to overloading and adjust the emitted code. A short-term solution would be to evaluate the return result (if the function returns something) and assign that value to the dest argument. Parrot would call .sub __add .param left .param right .param dest # HLL can use it or create a temp ... .return(temp) # or .return (dest) if HLL knows about dest .end while this is still a bit sub-optimal because of the additional temp, the HLL might create, it would at least match the semantics. A more radical change would be to just adapt these opcodes to create an appropriate PMC with the result. Thinking more about that it seems that we don't have much chance to keep the current scheme that the destination is passed in. a Python snippet: def myadd(self, r): return I(self.v - r) class I(object): __add__ = myadd def __init__(self, v): self.v = v def __repr__(self): return I(%d) % self.v i = I(44) j = i + 2 k = j + 2 print i, j, k The add opcode is overloaded and returns a new object of class I. The current scheme is: $P0 = new Undef $P0 = add i, 2 *If* the HLL compiler can somehow make a connection between the myadd function as an overloaded add opcode, it could try to morph the passed in destination argument. The whole morph code is bulky and slow, changing one PMC into an arbitrary different one needs deallocating the old one (what happens with finalizers?) and constructing a new one in place. But I doubt that a compiler can track such a usage (myadd could be in a different file and imported). That means we are pre-constructing a LHS PMC for nothing with all implications on GC and performance. Second: looking at pmc.c:pmc_reuse() the code isn't able to and can't never return a singleton as the result of an operation, because that would mean to change the address of the argument, where only it's pointer is passed. Comments? leo leo
[ANNOUNCE] CPANPLUS 0.050_02
After quite a bit of feedback on the first beta, I'm pleased to announce the second beta. Get it from: http://cpanplus.xs4all.nl/~kane/CPANPLUS-0.050_02.tar.gz Or soon, a CPAN near you. Changes for 0.050_02Fri Dec 10 15:03:39 CET 2004 * Move CPANPLUS::Dist::(Deb|Ports) to it's on repository * Fix error when Test::Reporter is unavaliable * Various spelling fixes * Added CPANPLUS::Hacking pod with instructions how to hack on CPANPLUS * Added an environment variable 'PERL5_CPANPLUS_IS_RUNNING' which will be set to the current process id, so subprocesses can recognize that they are running under CPANPLUS * Some wordings have changed for the setup, to make things a bit clearer * Add 'do we have test::reporter support' probing code (used in test suite) * Add Mail::Send as a prerequisite for test::reporter support * Don't attempt to actually send test reports from our test suite -- Test::Reporter doesn't do that itself either, we might have failed tests due to Test::Reporter rather than ourselves * Mention 'bundle::cpanplus::test::reporter' which has all the modules needed to have test::reporter support enabled * Improved accuracy for core module detection logic and errors * More support for connecting to remote machines using CPANPLUS::Daemon (not yet released, but will be soon) * Add extra clean up arguments to our own Makefile to remove temp files * Extensive overhaul of CPANPLUS::Dist::Build to get Module::Build support working properly (lots of workarounds for bugs in the M::B API -- we now bundle a custom patched M::B (0.26061) to cope) * Module::Build now accepts buildflags * Seperate inc path for installers (defacto only Module::Build right now) * Update various bundled modules like Object::Accessor, IPC::Cmd, Archive::Extract. * Smarter loading of bundled modules * Various speed optimizations * 't --force' can send a new test::report now * Don't force current installer format onto prereqs, unless it's explicitly requested * Make the default shell be aware when it's running in noninteractive mode, making sure it makes no suggestions with require interactivity * Add a message about where the module was extracted to in verbose mode -- Jos Boumans Whenever you find you are on the side of the majority, it is time to pause and reflect. - Mark Twain CPANPLUS http://cpanplus.sf.net
