Re: [PROPOSAL] MMD: multi sub syntax
Bob Rogers <[EMAIL PROTECTED]> wrote: > What if one wants the first and third arguments to be the invocants? > Then the first syntax gives >.sub foo @MULTI > .invocant Integer a > .param pmc b > .invocant String c That should better be >.sub foo @MULTI > .invocant Integer a > .invocant pmc b > .invocant String c Invocants are positional arguments, there isn't a case where the first and the third are invocants in a Perl6 function signature. It of course boils down to the same, namely that the second argument is a wildcard (Perl6 Any) but it's for the dispatcher nethertheless a dispatch on three invocants. > But it's not as obvious how to do that for the second one, unless you > use "pmc" as the explicit type name for "any": >.sub foo multi(Integer, pmc, String) >.param pmc a >.param pmc b >.param pmc c > In that case the first syntax strikes me as cleaner . . . I'm not sure. But there is still another thingy. A12 allows multiple colons to separate invocant "classes". If there is a tie, the secondary invocants are used as tie breakers, which could be written as: .sub foo multi(Integer, pmc: String) .param pmc a .param pmc b .param pmc c - try to dispatch on the first two types in the first place - if there is a tie, consider the type of the 3rd argument leo
Re: [perl #34373] [PATCH] Parrot 0.1.2 with MinGW32
François" PERRAD <[EMAIL PROTECTED]> wrote: > -win32-mingw > +win32-mingw-gcc3.2.3 YYY - - YY/7 20050307 Just 7 failing can't be quite right, when all tests are failing that used dynamic loading. leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>the method call in PIR can be written as:
>>
>> d = x."cos"() # normal method call
>> d = Float."cos"(x) # class method, argument shifted down
>> d = P6Num."cos"(x) # same
>> d = cos x # PIR opcode syntax [1]
>> cos d, x # PASM opcode syntax [1]
>>
>>There'll be a table of such builtins with name, namespace, signature, so
>>that the current opcodes can be transparently replaced by methods.
>>
>>
> This looks like it's taking
> multi method Num::cos (Num|Str +$base) returns Num
> and generating
> multi sub cos (Num $x, Num|Str +$base) returns Num
No. The above "lowlevel" C isn't aware of C nor of C<$_> and
nothing is autogenerated in Parrot. The C is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by C (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
leo
Re: Calling PIR from a PMC
William Coleda <[EMAIL PROTECTED]> wrote: > If only the first character is the return value, how does one deal > with subroutines that return multiple values? Well, you can't access multiple return values from within the C function, where you are calling the PIR code. OTOH, if the PIR code did return more values, we should get them back to the caller. We should probably have a new return signature for this, e.g. "@" - collect all return values, stuff them into an array and return that. OTOH you could use Parrot_runops_fromc() and pick up return values from the returned frame pointer C. leo
Behavior of PAST compiler
Hi, I have been adding a PIR implementation and three 'Hello World' tests to 'languages/parrot_compiler'. Code is taken from STDIN, compiled by a builtin compiler, and the resulting Eval PMC is invoked. This works as expected for PASM and PIR. For PAST, Parrot abstract syntax tree as simple text, I get behavior that I don't understand: cd languages/parrot_compiler/ make make test cd ../../ ./parrot languages/parrot_compiler/parrot_compiler.imc --language=PAST < languages/parrot_compiler/t/basic/hello_3.code ./parrot languages/parrot_compiler/parrot_compiler.pbc --language=PAST < languages/parrot_compiler/t/basic/hello_3.code Calling 'parrot_compiler.imc' gives the expected result "Hello Pirate". Calling 'parrot_compiler.pbc' seems to print the generated PASM code. It looks like the compiled sub knows whether it is being rum by PIR or by PBC. Is that that the intended behavior? CU, Bernhard -- /* [EMAIL PROTECTED] */ SMS bei wichtigen e-mails und Ihre Gedanken sind frei ... Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
Re: [perl #34430] [PATCH] MRO breaks Tcl
Will Coleda <[EMAIL PROTECTED]> wrote: > Attached is a patch that allows "(cd languages/tcl && make test)" to work > again. Looks like an unguarded access in MRO. Didn't self apply so Leo could > poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. The C is defined as an abstract class, i.e. it has no VTABLE. Per convention, such abstract classes should be lower case. Is there a specific reason that it's an abstract PMC? I tried to get rid of "abstract noinit" in that PMC, which produced these failing tests: cmd_break.t 1 256 21 50.00% 2 cmd_continue.t1 256 21 50.00% 2 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_string.t 6 1536356 17.14% 26-27 29-31 34 leo
Re: Namespaces
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> t/pmc/namespace.t
> Please have a look at the supported syntax constructs. Are these
> sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method is stored:
.namespace ["Foo"]
.sub bar
...
This does effectively (during bytecode loading)
store_global "Foo", "bar", pmc_of_sub_bar
where the C is living in the constant table.
The general way (and the only one, if the function is in another
bytecode segment), to call the function, is:
$P0 = find_global "Foo", "bar"
$P0()
Ok so far.
But what happens, if the PIR file contains just a plain
bar()
The implementation looks into the current namespace and then in other
namespaces present in the compiled source file, which seems to be quite
wrong to me. Below is a test program [1] that shows how it's working
now.
The opcode to get at the sub "bar" is:
set_p_pc $P0, "bar"
where the symbol "bar" (the PMC constant of the sub) is located in the
source file.
The C shorthand call syntax could now look into the current
namespace only. But that seems to restricted to me - or it would make
the shortcut almost useless.
I think that the C shortcut should emit a new opcode:
$P0 = find_name "bar"
or maybe:
$P0 = HLL."find_name"("bar") # HLL := a Perl6, Python, ... PMC
The C opcode could now look into the current lexicals, the
current namespace aka package, the globals, and finally into the
builtins in that order.
Further: to be able to search the current package namespace, the
interpreter has to know, in which namespace it's currently executing.
This is also needed for MMD function search. To achieve that, all
subroutines would need to remember their namespace and when calling the
sub, that namespace could be placed into the interpreter context.
Comments very welcome,
leo
[1]
$ cat s.imc
.namespace ["Main"] # try it with and w/o this line
.sub main @MAIN
print "calling foo\n"
foo()
print "calling Foo::foo\n"
$P0 = find_global "Foo", "foo"
$P0()
print "calling baz\n"
baz()
.end
.sub foo
print " foo\n"
bar()
.end
.sub bar
print " bar\n"
.end
.sub fie
print " fie\n"
.end
.namespace ["Foo"]
.sub foo
print " Foo::foo\n"
bar()
fie()
.end
.sub bar
print " Foo::bar\n"
.end
.sub baz
print " Foo::baz\n"
.end
$ parrot s.imc
calling foo
foo
bar
calling Foo::foo
Foo::foo
bar # or Foo::bar
fie
calling baz
Foo::baz
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Michal Jurosz <[EMAIL PROTECTED]> wrote:
> TortoiseCVS patch file attached.
> SKIP: {
[ ... ]
> -}
Please always test your patches.
Thanks, applied.
leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
> # --- Some other ideas: ---
> $ perl -e "print $^O"
> msys
> --- config\init\hints.pl
> sub runstep {
> + my $O = lc($^O);
> + $O = 'mswin32' if $O =~ /^(msys|mingw)/;
> - my $hints = "config/init/hints/" . lc($^O) . ".pl";
> + my $hints = "config/init/hints/" . $O . ".pl";
This would make MinGW in all aspects identical to a native window build,
wouldn't it? Seems dangerous.
When I follow the instructions what I've published in parrot/README.win32,
the builded perl program gives :
$ perl -e "print $^O"
MSWin32
For me, mingw is not a platform (MSWin32 and cygwin are a platform), just
the GCC compiler under MSWin32.
$mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
So, the case $is_mingw in config/init/hints/mswin32.pl is the good way to
handle this compiler.
Francois Perrad.
> S pozdravem Michal Jurosz
Thanks for the detailed report,
It would be great if folks with windows installed could have a look at
these issues.
leo
Parrot_Exec_OS_Command interface ?
When I analyse the failure of t/pmc/sys.t with MinGW32, I see that this script generates a command depending of the OS on MSWin32, cmd = ".\parrot temp.imc" on *nix, cmd = "./parrot temp.imc" (So with MinGw, the generation of Makefile needs /, and the execution needs \) The bug can be fixed in ConfigureLand or in Parrot_Exec_OS_Command function. And the dilemma is : the interface of Parrot_Exec_OS_Command is OS native command as now, or is OS independent, like "open dirname/filename" Francois Perrad.
Re: Parrot 0.1.2 with MinGW32 (some experimets)
François PERRAD wrote:
When I follow the instructions what I've published in parrot/README.win32,
the builded perl program gives :
$ perl -e "print $^O"
MSWin32
For me, mingw is not a platform (MSWin32 and cygwin are a platform),
just the GCC compiler under MSWin32.
$mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
So, the case $is_mingw in config/init/hints/mswin32.pl is the good way
to handle this compiler.
README.win32: "As Configure.pl extracts configuration from the perl
program, first build/install perl with MinGW (no binary distribution
available)."
But more obtainable/common are:
# run: cmd.exe
C:\>perl -e "print $^O"
MSWin32
C:\>perl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread
Binary build 810 provided by ActiveState Corp.
C:\>set PATH=%PATH%;C:\mingw\bin
C:\>gcc -v
gcc version 3.2.3 (mingw special 20030504-1)
# run: C:\msys\msys.bat
$ perl -e "print $^O"
msys
$ perl -v
This is perl, v5.6.1 built for msys
$ which gcc
/mingw/bin/gcc
$ gcc -v
gcc version 3.2.3 (mingw special 20030504-1)
# run C:\cygwin\cygwin.bat
$ perl -e "print $^O"
cygwin
$ perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
$ which gcc
/usr/bin/gcc
$ gcc -v
gcc version 3.3.3 (cygwin special)
See attached win32-env.txt for full listings.
I was thinking about merge cygwin.pl with mswin32.pl.
my $O = lc($^O);
$O = 'mswin32' if $O =~ /^(msys|cygwin)/;
my $hints = "config/init/hints/" . $O . ".pl";
See attached mswin32.pl
See also http://xrl.us/fddn (MJWiki:Build Parrot with MinGW)
S pozdravem Michal Jurosz
C:\usr>perl -e "print $^O"
MSWin32
C:\usr>perl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
Copyright 1987-2004, Larry Wall
Binary build 810 provided by ActiveState Corp. http://www.ActiveState.com
ActiveState is a division of Sophos.
Built Jun 1 2004 11:52:21
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.
C:\>set PATH=%PATH%;C:\mingw\bin
C:\usr>gcc -v
Reading specs from C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-
exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)
#
msys
This is perl, v5.6.1 built for msys
Copyright 1987-2001, 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.
/mingw/bin/gcc
Reading specs from c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj
-exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)
#
C:\cygwin>perl -e "print $^O"
cygwin
C:\cygwin>perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
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.org/, the Perl Home Page.
C:\cygwin>which gcc
/usr/bin/gcc
C:\cygwin>gcc -v
$ ./env.bat 2>&1 > des
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefi
x=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/s
hare/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj --with-system-zli
b --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj
lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
{
my %args;
@[EMAIL PROTECTED]@_;
my($cc,
Re: Behavior of PAST compiler
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Hi, > ./parrot languages/parrot_compiler/parrot_compiler.pbc --language=PAST < > languages/parrot_compiler/t/basic/hello_3.code > Calling 'parrot_compiler.pbc' seems to print the generated PASM code Yes. When you run the .imc version of the program, C is called in imcc/main.c:526, which sends the output to the to be generated PBC. If you run the .pbc version of your compiler, the emit_open() function isn't executed and the default emitter (number 0) is used, which produces assembly listings (as parrot -o- does). > Is that that the intended behavior? The problem is that such output options can't be passed on to secondary compile runs. They use just what imcc/main used. We probably need a scheme to pass options from the C opcode to the compiler. > CU, Bernhard leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
François PERRAD <[EMAIL PROTECTED]> wrote:
> For me, mingw is not a platform (MSWin32 and cygwin are a platform), just
> the GCC compiler under MSWin32.
> $mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
> So, the case $is_mingw in config/init/hints/mswin32.pl is the good way to
> handle this compiler.
Ok. What about the reported problem that the object file ending
o => '.o'
has to be changed in the hints file?
> Francois Perrad.
leo
[perl #34441] [TODO] Clean up 'imcc' targets from main Makefile?
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #34441] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34441 > Hi, there are a lot of potentially confusing targets in the main Makefile. In order to simply the Makefile, I propose to remove the 'imcc' targets. Does anybody care for these targets? test_imcc: Run the test suite only for IMCC tests. test_imcc: Run the IMCC test suite with a specific core fulltest_imcc: Run IMCC test suite with various options test_imcc-clean imcc-clean The functionality of running only a subset of tests will of course remain, e.g perl t/harness -C imcc/t/*/*.t CU, Bernhard -- /* [EMAIL PROTECTED] */ DSL Komplett von GMX +++ Supergïnstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
[perl #34442] [TODO] *BooleanArray PMCs should use single bit per bool
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #34442] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34442 > This was mentioned by Leo in Ticket 34934 and 30230: > Oh well, while at it, the *BooleanArray should just use one bit per item > not an INTVAL. I'll tackle that. First I'll propable take a look at Bit::Vector in Perl5, as there are propably a lot of interesting methods on a boolean array. There are even CPUs with processor instructions for counting set bits. Does that call for some inline assembler in PMC C-code? CU, Bernhard -- /* [EMAIL PROTECTED] */ DSL Komplett von GMX +++ Supergïnstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
Re: [perl #34430] [PATCH] MRO breaks Tcl
Switching tclobject seems to work fine here. I suspect you might have something else going on. Committed the change to tclobject, removed my local hack to src/pmc.c, passes 100% now. Regards. Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: Attached is a patch that allows "(cd languages/tcl && make test)" to work again. Looks like an unguarded access in MRO. Didn't self apply so Leo could poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. The C is defined as an abstract class, i.e. it has no VTABLE. Per convention, such abstract classes should be lower case. Is there a specific reason that it's an abstract PMC? I tried to get rid of "abstract noinit" in that PMC, which produced these failing tests: cmd_break.t 1 256 21 50.00% 2 cmd_continue.t1 256 21 50.00% 2 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_string.t 6 1536356 17.14% 26-27 29-31 34 leo
Re: [PROPOSAL] MMD: multi sub syntax
From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Tue, 15 Mar 2005 08:52:38 +0100 Bob Rogers <[EMAIL PROTECTED]> wrote: > What if one wants the first and third arguments to be the invocants? > Then the first syntax gives >.sub foo @MULTI > .invocant Integer a > .param pmc b > .invocant String c That should better be >.sub foo @MULTI > .invocant Integer a > .invocant pmc b > .invocant String c Invocants are positional arguments, there isn't a case where the first and the third are invocants in a Perl6 function signature. It of course boils down to the same, namely that the second argument is a wildcard (Perl6 Any) but it's for the dispatcher nethertheless a dispatch on three invocants. Thanks for clearing that up. (FWIW, your answer accords well with my personal biases, too. ;-) > . . . > In that case the first syntax strikes me as cleaner . . . I'm not sure. But there is still another thingy. A12 allows multiple colons to separate invocant "classes". If there is a tie, the secondary invocants are used as tie breakers, which could be written as: .sub foo multi(Integer, pmc: String) .param pmc a .param pmc b .param pmc c - try to dispatch on the first two types in the first place - if there is a tie, consider the type of the 3rd argument leo I've only read half of A12 by now, and am still digesting what I've read (and that may take a while), but the section headed "multi sub * (tradition multimethods)" seems to say that the dispatcher never considers anything after the last colon. So perhaps you meant: .sub foo multi(Integer, pmc: String:) .param pmc a .param pmc b .param pmc c Or is that wrong? The next question is, what happens if you define a method with the "long name": .sub bar multi(Integer, Float: Float) and I define one with .sub bar multi(Integer: String, Integer) That would mean that the "long names" have different "name length" in this case. It seems to me that can't work, but if A12 rules it out, I couldn't find it. If this is supposed to work, then how should MMD handle disagreement about invocant groups? And if the answer is simply to ignore it, and treat each method independently, doesn't this screw up the distance metric? The distance to your method will be computed on the first two values, whereas the distance to mine will be computed on only the first, so the two distances will be incommensurable, true? TIA, -- Bob Rogers http://rgrjr.dyndns.org/
Re: [perl #34441] [TODO] Clean up 'imcc' targets from main Makefile?
Bernhard Schmalhofer (via RT) wrote: there are a lot of potentially confusing targets in the main Makefile. In order to simply the Makefile, I propose to remove the 'imcc' targets. Does anybody care for these targets? I don't test_imcc: Run the test suite only for IMCC tests. test_imcc: Run the IMCC test suite with a specific core fulltest_imcc: Run IMCC test suite with various options test_imcc-clean imcc-clean The functionality of running only a subset of tests will of course remain, e.g perl t/harness -C imcc/t/*/*.t Yep. Go ahead. Thanks, leo
Re: [perl #34442] [TODO] *BooleanArray PMCs should use single bit per bool
Bernhard Schmalhofer (via RT) wrote: This was mentioned by Leo in Ticket 34934 and 30230: Oh well, while at it, the *BooleanArray should just use one bit per item not an INTVAL. I'll tackle that. First I'll propable take a look at Bit::Vector in Perl5, as there are propably a lot of interesting methods on a boolean array. Great, thanks. There are even CPUs with processor instructions for counting set bits. Does that call for some inline assembler in PMC C-code? Not yet IMHO. But I can imagine that PGE might need all available speed hacks. Let's see. CU, Bernhard leo
Re: [PROPOSAL] MMD: multi sub syntax
Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> Syntax proposal: >>.sub foo @MULTI >> .invocant Integer a >> .invocant Float b >> .param pmc c >> ... > Alternate syntax: > .sub foo multi(Integer, Float) > .param pmc a > .param pmc b > .param pmc c And another one: .multi sub foo .sub foo__Int_Num_Str Integer,Float:String .sub foo__Num_Int_Any Float,Integer,pmc .endmulti .sub foo__Int_Num_Str ... .sub foo__Num_Int_Any ... The C<.multi> defines a group of multi subs with it's short name. The members are plain subroutines with their long names. Name mangling is done by Perl6. leo
Re: [PROPOSAL] MMD: multi sub syntax
Bob Rogers <[EMAIL PROTECTED]> wrote: >From: Leopold Toetsch <[EMAIL PROTECTED]> >.sub foo multi(Integer, pmc: String) > .param pmc a > .param pmc b > .param pmc c >- try to dispatch on the first two types in the first place >- if there is a tie, consider the type of the 3rd argument >leo > I've only read half of A12 by now, and am still digesting what I've read > (and that may take a while), but the section headed "multi sub * > (tradition multimethods)" seems to say that the dispatcher never > considers anything after the last colon. So perhaps you meant: >.sub foo multi(Integer, pmc: String:) It depends: if the C just contains the MMD signature my version is fine. >The next question is, what happens if you define a method with the > "long name": >.sub bar multi(Integer, Float: Float) > and I define one with >.sub bar multi(Integer: String, Integer) > That would mean that the "long names" have different "name length" in > this case. It seems to me that can't work, but if A12 rules it out, I > couldn't find it. If the multi sub is called with an Integer argument (or a class derived from Integer) all "bar" methods of these classes are included in the candidate list. The different "long name length" doesn't matter for that. >If this is supposed to work, then how should MMD handle disagreement > about invocant groups? And if the answer is simply to ignore it, and > treat each method independently, doesn't this screw up the distance > metric? The distance to your method will be computed on the first two > values, whereas the distance to mine will be computed on only the first, > so the two distances will be incommensurable, true? Seems so yes. Except, if shorter (not so specific) long names get a penalty. This seems to need clarification from p6l. >TIA, > -- Bob Rogers leo
Re: [perl #34430] [PATCH] MRO breaks Tcl
William Coleda <[EMAIL PROTECTED]> wrote: > Switching tclobject seems to work fine here. I suspect you might have > something else going on. I don't have any diffs WRT CVS. Strange. leo
