[perl #132784] [BUILD] make install fail on termux/Android 6.0.1
I suggest check out below links:
https://github.com/mickael-kerjean/filestash/issues/61
https://github.com/termux/termux-packages/issues/307
Good luck,
On Mon, 29 Jan 2018 13:24:45 -0800, myforumem...@arcor.de wrote:
> Device: Onyx Boox Max2, Android 6.0.1, cpu rk3288
> termux is a prefixed linux, device is not rooted
> make install fails for both rakudo-star-2017.10 and rakudo-2017.12
>
> Using a cross-compiled MoarVM it's possible to make nqp and rakudo,
> but make install hangs, after that install dir usr/share/perl6 has
> some precomp
> binaries, whatever that is.
>
> $ make install
> mkdir -p -- /data/data/com.termux/files/usr/bin
> mkdir -p -- /data/data/com.termux/files/usr/share/nqp/lib/Perl6
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> blib/Perl6/ModuleLoader.moarvm blib/Perl6/World.moarvm
> blib/Perl6/Grammar.moarvm blib/Perl6/Ops.moarvm
> blib/Perl6/Actions.moarvm blib/Perl6/Optimizer.moarvm
> blib/Perl6/Pod.moarvm blib/Perl6/Compiler.moarvm
> blib/Perl6/Metamodel.moarvm blib/Perl6/BOOTSTRAP.moarvm
> blib/Perl6/DebugPod.moarvm
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/ModuleLoader.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/World.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Grammar.moarvm
> rm -f //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Ops.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Actions.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Optimizer.moarvm
> rm -f //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Pod.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Compiler.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Metamodel.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/BOOTSTRAP.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/DebugPod.moarvm
> cp -- blib/Perl6/ModuleLoader.moarvm blib/Perl6/World.moarvm
> blib/Perl6/Grammar.moarvm blib/Perl6/Ops.moarvm
> blib/Perl6/Actions.moarvm blib/Perl6/Optimizer.moarvm
> blib/Perl6/Pod.moarvm blib/Perl6/Compiler.moarvm
> blib/Perl6/Metamodel.moarvm blib/Perl6/BOOTSTRAP.moarvm
> blib/Perl6/DebugPod.moarvm
> /data/data/com.termux/files/usr/share/nqp/lib/Perl6
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/lib
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/runtime
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> CORE.setting.moarvm CORE.d.setting.moarvm RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/CORE.setting.moarvm
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/CORE.d.setting.moarvm
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> perl6.moarvm perl6-debug.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> rm -f /data/data/com.termux/files/usr/share/perl6/runtime/perl6.moarvm
> rm -f /data/data/com.termux/files/usr/share/perl6/runtime/perl6-
> debug.moarvm
> cp -- CORE.setting.moarvm CORE.d.setting.moarvm
> RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> cp -- perl6.moarvm perl6-debug.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/runtime/dynext
> cp -- dynext/libperl6_ops_moar.so
> /data/data/com.termux/files/usr/share/perl6/runtime/dynext
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6/vendor
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6/site
> ./perl6-m tools/build/install-core-dist.pl
> /data/data/com.termux/files/usr/share/perl6
> ^Cmake: *** [Makefile:635: m-install] Interrupt
--
Matt Zand
https://coding-bootcamps.com/
https://myhsts.org/
https://dcwebmakers.com/
[perl #131025] [STAR][BUG] p6doc does not work on Mac OS X dmg
Confirmed bug still appears in Rakudo 2017.04 Mac OS X .dmg install. None of the examples given in the p6doc command help actually work. Given that a dmg install is the first thing a newbie would try, this is important to growing the Perl 6 community. Based on a clean install on a new 2016 MacBook Pro. This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda implementing Perl 6.c.
Re: threads?
On Oct 12, 2010, at 9:22 AM, Damian Conway wrote: Perhaps we need to think more Perlishly and reframe the entire question. Not: What threading model do we need?, but: What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks? I watched a presentation by Guy Steele at the Strange Loop conference on Thursday where he talked about non-sequential programming. One of the interesting things that he mentioned was to use the algebraic properties of an operation to know when a large grouping of operations can be done non-sequentially. For example, we know that the meta reduction operator could take very large lists and split them into smaller lists across all available cores when performing certain operations, like addition and multiplication. If we could mark new operators that we create with this knowledge we could do this for custom operators too. This isn't a new idea, but it seems like it would be a helpful tool in simplifying non-sequential programming and I didn't see it mentioned in this thread yet. Here are the slides to the talk to which I'm referring: http://strangeloop2010.com/talk/presentation_file/14299/GuySteele-parallel.pdf ~Matt
Re: [perl #78032] AutoReply: Two things that seem like bugs
It has occurred to me I missed some vital information. This is true for versions: * Rakudo Perl 6, version 2010.08-49-g8cf7fcd built on parrot 2.7.0 r48628 * The version of rakudo that matches to whatever p6eval runs when the output starts with rakudo be80e9 * Rakudo Star 2010-08 Sorry, Matt Follett On Sep 24, 2010, at 2:46 PM, perl6 via RT wrote: Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: Two things that seem like bugs, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [perl #78032]. Please include the string: [perl #78032] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, perl6-bugs-follo...@perl.org - Hey *, I have come across two cases that seem like bugs. First, this: my $j='A'|'B'; my $pair = $j='k'; $pair.kv.say prints out: any(A, k, B) Is that what it is supposed to do? The second issue is similar, if I do this: my $junc = 'A' | 'B' | 'C'; my %foo = $junc = 'a value'; say %foo I get: C a value Obviously, accessing anything other than %fooC returns Any() whereas accessing %fooC actually returns 'a value'. Maybe these aren't bugs and I just don't know any better. Thanks, Matt Follett
Re: [perl #51806] [PATCH] Fix test failures
On Mon, Mar 17, 2008 at 10:14:58AM -0700, James Keenan via RT wrote: It means I didn't do anything with it one way or the other. Since it pertains to a different test, it probably would have been better off in a separate RT. If someone else can look at it prior to tomorrow's release, they can handle it. Otherwise, I'll look at it later in the week. Ah, OK. Thanks for the explanation. -- Matt
Re: [perl #51806] [PATCH] Fix test failures
On Mon, Mar 17, 2008 at 04:28:26AM -0700, James Keenan via RT wrote:
On Sun Mar 16 19:28:53 2008, kraai wrote:
Howdy,
t/examples/pasm.t fails because examples/pasm/fact.pasm now outputs 30
factorials, whereas the test case only expects it to output 6.
I was just at the point of filing a separate bug report on the failure
in t/examples/pasm.t when I saw your post. I applied your patch, but
got inconsistent results with it between Darwin and Linux.
On Darwin, test #4 (the factorial test) once again passed. But on
Linux, this was my result:
$ prove -v t/examples/pasm.tt/examples/pasm..
[snip test output]
To the best of my memory, I have never installed a bigint library on
this Linux box; I'm not quite sure what that is. But, in any case,
shouldn't the test be smart enough to do the right thing in either case
(having or not having bigint)?
I had the development package for GMP installed (on Debian unstable,
it's libgmp3-dev). Once I'd uninstalled it, the test failed for me
too in the same way as it failed for you.
The attached patch makes it skip the factorial test if GMP isn't
available. There must be something wrong with the makefiles, though,
because I had to perform a make clean and rebuild everything before
the test would succeed after reinstalling GMP.
t/perl/Parrot_IO.t fails because it skips the Subversion-specific
tests only when run in a Subversion working copy. The attached patch
fixes both problems.
Perhaps because I'm usually working in a Subversion working copy, I
haven't experienced this error. So I did not test out this patch.
Does this mean you will or won't check it in?
--
Matt
diff --git a/t/examples/pasm.t b/t/examples/pasm.t
index 3e74d0f..2b9e03b 100644
--- a/t/examples/pasm.t
+++ b/t/examples/pasm.t
@@ -34,40 +34,6 @@ Ft/examples/pir.t
# Set up expected output for examples
my %expected = (
-'fact.pasm' = 'END_EXPECTED',
-fact of 0 is: 1
-fact of 1 is: 1
-fact of 2 is: 2
-fact of 3 is: 6
-fact of 4 is: 24
-fact of 5 is: 120
-fact of 6 is: 720
-fact of 7 is: 5040
-fact of 8 is: 40320
-fact of 9 is: 362880
-fact of 10 is: 3628800
-fact of 11 is: 39916800
-fact of 12 is: 479001600
-fact of 13 is: 6227020800
-fact of 14 is: 87178291200
-fact of 15 is: 1307674368000
-fact of 16 is: 20922789888000
-fact of 17 is: 355687428096000
-fact of 18 is: 6402373705728000
-fact of 19 is: 121645100408832000
-fact of 20 is: 243290200817664
-fact of 21 is: 5109094217170944
-fact of 22 is: 11240007260768
-fact of 23 is: 2585201673888497664
-fact of 24 is: 62044840173323943936
-fact of 25 is: 1551121004333098598400
-fact of 26 is: 40329146112660563558400
-fact of 27 is: 106945041835216076800
-fact of 28 is: 30488834461171386050150400
-fact of 29 is: 884176199373970195454361600
-fact of 30 is: 26525285981219105863630848000
-END_EXPECTED
-
'hello.pasm' = 'END_EXPECTED',
Hello World
END_EXPECTED
@@ -114,6 +80,44 @@ END_EXPECTED
);
+SKIP: {
+skip( 'GMP is not available', 1 ) unless $PConfig{gmp};
+
+$expected{'fact.pasm'} = 'END_EXPECTED'
+fact of 0 is: 1
+fact of 1 is: 1
+fact of 2 is: 2
+fact of 3 is: 6
+fact of 4 is: 24
+fact of 5 is: 120
+fact of 6 is: 720
+fact of 7 is: 5040
+fact of 8 is: 40320
+fact of 9 is: 362880
+fact of 10 is: 3628800
+fact of 11 is: 39916800
+fact of 12 is: 479001600
+fact of 13 is: 6227020800
+fact of 14 is: 87178291200
+fact of 15 is: 1307674368000
+fact of 16 is: 20922789888000
+fact of 17 is: 355687428096000
+fact of 18 is: 6402373705728000
+fact of 19 is: 121645100408832000
+fact of 20 is: 243290200817664
+fact of 21 is: 5109094217170944
+fact of 22 is: 11240007260768
+fact of 23 is: 2585201673888497664
+fact of 24 is: 62044840173323943936
+fact of 25 is: 1551121004333098598400
+fact of 26 is: 40329146112660563558400
+fact of 27 is: 106945041835216076800
+fact of 28 is: 30488834461171386050150400
+fact of 29 is: 884176199373970195454361600
+fact of 30 is: 26525285981219105863630848000
+END_EXPECTED
+}
+
while ( my ( $example, $expected ) = each %expected ) {
example_output_is( examples/pasm/$example, $expected );
}
[perl #41511] Parrot_call_sub* Incompatible with Multisubs
On Sun Mar 16 10:57:07 2008, [EMAIL PROTECTED] wrote: Matt, chromatic: This test is still in TODO status as of r26404. Can you provide us with an update as to the ticket's status? Thank you very much. kid51 Sure. I investigated the issue a while back, and the whole thing is basically stalled. The code surrounding the issue (the packfile code) is a bit of a mess, which made finding a real fix difficult. I started to work on refactoring that code in order to find a fix here, but it's large, hairy, and difficult to work with. This bug should either remain open or be changed to stalled. To recap, I think this bug will require a substantial refactoring and cleanup of the packfile code. For now, I believe it's a non-trivial bug (except, perhaps, for someone with a more thorough understanding of the packfile code). My involvement with Parrot has been minimal as of late, but I'm willing to retain ownership of the ticket and fix the issue if packfile code gets cleaned up. -- Matt Diephouse
[perl #51300] [PATCH] t/perl/Parrot_Test.t fails because of incompatible Test::Builder output
On Sun Mar 09 19:32:32 2008, [EMAIL PROTECTED] wrote: Matt Kraai's contributions appear to have resolved the problem. t/perl/Parrot_Test.t has been passing for me and for reliable smoke-testers for the past week. So I am resolving this ticket. The final test in t/perl/Parrot_Test.t still fails for me. It's a TODO test, so it can't use test_fail. The attached patch should handle all versions of Test::Builder, but I've only tested it with version 0.32. patch Description: Binary data
Re: [perl #51300] [PATCH] t/perl/Parrot_Test.t fails because of incompatible Test::Builder output
On Tue, Mar 11, 2008 at 08:29:04AM -0700, James Keenan via RT wrote: On Mon Mar 10 23:12:23 2008, kraai wrote: The final test in t/perl/Parrot_Test.t still fails for me. It's a TODO test, so it can't use test_fail. The attached patch should handle all versions of Test::Builder, but I've only tested it with version 0.32. Patch applied in r26315. I'm using Test::Builder 0.72 and it worked for me. Thanks for applying it. -- Matt
Re: [perl #44395] Lexical scopes are too coarse-grained for loops.
On 8/3/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
A naive PIR implementation of this loop is included as the second
attachment. It fails miserably, because PIR can't distinguish between
the different scopes for $i and $n.
sub make_closures_loop {
# Return n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
[...]
## Return n closures, each with lexical references to I and N'.
.sub make_closures_loop
.param pmc n
.lex $n, n
.lex $i, $P42
[...]
.sub internal_make_closures_loop_0 :outer('make_closures_loop')
find_lex $P42, $i
find_lex $P43, $n
[...]
This seems wrong to me -- shouldn't $i be scoped to the internal
loop instead of the outer one? In other words, I think the PIR
code should read:
.sub make_closures_loop
.param pmc n
.lex $n, n
...
and then
.sub internal_make_closures_loop_0 :outer('make_closures_loop')
.lex $i, $P42
find_lex $P43, $n
...
No, this is different. Your code puts the scope of $i inside the
anonymous sub. In other words, it's this:
for (1..$n) {
push(@result, sub { my $i = ...; print Called sub $i out of $n.\n; });
}
Except there's way to initialize $i in this case. (Initializing it
from $_ inside the anonymous sub just moves the problem to a different
variable.)
Otherwise, the reason that PIR isn't able to distinguish the
scopes is because in PIR you're actually defining them to be
in the same scope.
I believe that's exactly Bob's point.
However, I must confess that I still haven't grokked all of the
ramifications of lexicals and closures in PIR yet -- and I may
even be interpreting the p5 translation incorrectly. It just
looks to me as though the naive translation isn't being faithful
to the original p5 source, and so perhaps that's causing the
problem you're seeing.
Again, I believe this is what Bob was saying: it's not possible to be
faithful to the original p5 source without creating a separate
subroutine for every loop body. And there are reasons why that's a bad
idea (even if that's what they are in Perl 6):
- It introduces extra overhead in terms of the compiled code
- It's extra work for the compiler – introducing an extra pass for
lexical analysis
The alternative (which Bob is suggesting) is to reintroduce
push_pad/pop_pad so you can create new lexical scopes without using
subroutines for loop bodies.
His suggestion seems reasonable to me. We won't run into this
particular problem with Tcl, but I think most languages will.
--
Matt Diephouse
http://matt.diephouse.com
Re: [perl #44229] [CAGE] Review Dominance Computations in IMCC
On 7/28/07, via RT chromatic [EMAIL PROTECTED] wrote: # New Ticket Created by chromatic # Please include the string: [perl #44229] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44229 Profiling some of the PGE tests reveals that our register allocation is fairly expensive. Most of the time is in computing our dominators, and most of that time goes through repeated calls to set_contains. I don't know enough about graphs and sets to see if we're using the naive O(n^2) algorithm, or the Cooper, Harvey, Kennedy algorithm; someone who likes CS more than I do and loves algorithms should peruse the paper and the code: http://www.hipersoft.rice.edu/grads/publications/dom14.pdf compilers/imcc/reg_alloc.c. Did you use the -O flag when you were profiling? Parrot has two different register allocators. It normally uses the vanilla register allocator, but the -O flag tells parrot to use the older register allocator. I don't know the specifics of the older algorithm, but the vanilla allocator definitely looks like it's O(n^2). There were some problems with the older allocator on large subroutines, so it was disabled. -- Matt Diephouse http://matt.diephouse.com
Re: [svn:parrot] r20343 - in trunk: include/parrot src
On 7/31/07, Nicholas Clark [EMAIL PROTECTED] wrote:
On Mon, Jul 30, 2007 at 09:20:27PM -0700, Matt Diephouse wrote:
On 7/30/07, chromatic [EMAIL PROTECTED] wrote:
On Monday 30 July 2007 00:21:09 [EMAIL PROTECTED] wrote:
Author: mdiep
=== --- trunk/src/inter_run.c (original)
+++ trunk/src/inter_run.c Mon Jul 30 00:21:07 2007
@@ -167,9 +167,7 @@
{
opcode_t offset, *dest;
parrot_context_t *ctx;
-/*
- * FIXME argument count limited - check strlen of sig
- */
+
char new_sig[10];
const char *sig_p;
parrot_context_t * const old_ctx = CONTEXT(interp-ctx);
I think this comment meant Hey, allocating a ten-character array on the
stack
might put us in danger of overruns.
I removed it because down later in the source, the strlen of sig *is*
checked:
const size_t len = strlen(sig);
if (len 8) {
real_exception(interp, NULL, 1, too many arguments in
runops_args);
}
The string is only copied after this check is made.
So shouldn't that 8 be sizeof(new_sig) - 1 ?
No. More context is needed again.
const size_t len = strlen(sig);
if (len 8) {
real_exception(interp, NULL, 1, too many arguments in
runops_args);
}
new_sig[0] = 'O';
strcpy(new_sig + 1, sig + 1);
sig_p = new_sig;
Right now there are two magic numbers, one of which is actually off by one,
and no clear linking of the two.
That's a reasonable idea though. I haven't got the time to do it until
later tonight. Someone else can feel free to do so in the meantime.
--
Matt Diephouse
http://matt.diephouse.com
Re: [svn:parrot] r20343 - in trunk: include/parrot src
On 7/30/07, chromatic [EMAIL PROTECTED] wrote:
On Monday 30 July 2007 00:21:09 [EMAIL PROTECTED] wrote:
Author: mdiep
Date: Mon Jul 30 00:21:07 2007
New Revision: 20343
Modified:
trunk/include/parrot/exit.h
trunk/src/exit.c
trunk/src/inter_run.c
Log:
A couple more small cleanups
Modified: trunk/src/inter_run.c
===
=== --- trunk/src/inter_run.c (original)
+++ trunk/src/inter_run.c Mon Jul 30 00:21:07 2007
@@ -167,9 +167,7 @@
{
opcode_t offset, *dest;
parrot_context_t *ctx;
-/*
- * FIXME argument count limited - check strlen of sig
- */
+
char new_sig[10];
const char *sig_p;
parrot_context_t * const old_ctx = CONTEXT(interp-ctx);
I think this comment meant Hey, allocating a ten-character array on the stack
might put us in danger of overruns.
I removed it because down later in the source, the strlen of sig *is* checked:
const size_t len = strlen(sig);
if (len 8) {
real_exception(interp, NULL, 1, too many arguments in
runops_args);
}
The string is only copied after this check is made.
--
Matt Diephouse
http://matt.diephouse.com
Re: [perl #44193] tcl doesn't build (r20250)
On 7/26/07, via RT Will Coleda [EMAIL PROTECTED] wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #44193] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44193 $ make SNIP perl tools/gen_inline.pl src/builtin/while.tmt src/builtin/while.pir ../../parrot ../../compilers/pge/pgc.pir --output=src/grammar/expr/ expression.pir src/grammar/expr/expression.pg ../../parrot ../../compilers/tge/tgc.pir --output=src/grammar/expr/ past2pir.pir src/grammar/expr/past2pir.tg ../../parrot ../../compilers/tge/tgc.pir --output=src/grammar/expr/ pge2past.pir src/grammar/expr/pge2past.tg perl tools/gen_builtins.pl runtime/builtins.pir ../../parrot --output=runtime/tcllib.pbc runtime/tcllib.pir tclint.c:864: failed assertion `my_enum_class_0 != enum_class_default' make: *** [runtime/tcllib.pbc] Abort trap Fixed in r20257. The pmc2c code was to blame. It looks like the code has been refactored heavily; but somewhere along the way someone didn't translate the code accurately. :-/ -- Matt Diephouse http://matt.diephouse.com
[perl #43231] [BUG] :slurpy :named after :optional fails
Fixed in r19073. -- Matt Diephouse
Re: P6 String Assertion Failure (diagnosis and fix)
On 6/7/07, chromatic [EMAIL PROTECTED] wrote: When I run the t/01-sanity/06-use.t test in languages/perl6, I get an assertion failure: parrot: src/string.c:2028: string_hash: Assertion `s-encoding s-charset !(((s)-obj.flags) b_PObj_on_free_list_FLAG)' failed. Assertions like this really ought to be broken up in the source. By using multiple assertions, it's immediately obvious which assertion as actually failing. I've been meaning to split this up for quite some time but never got around to it. This happens when trying to hash a string (specifically the string 'Perl6::Grammar::quote_term'). I dug into this a little bit. It's the last test that fails; the string IS on the free list. Something isn't marking it as live appropriately. snip The test then passed. The assertion was okay. The String is obviously live, after it gets marked as live. I then wondered if strings get marked as live when they're created. The answer was in new_string_header() in src/headers.c: PObj_get_FLAGS(string) |= flags |PObj_is_string_FLAG|PObj_is_COWable_FLAG; I changed it: PObj_get_FLAGS(string) |= flags | PObj_is_string_FLAG | PObj_is_COWable_FLAG | PObj_live_FLAG; Adding the live flag fixed the problem (r18855). Good work! This has been the cause of a number of Perl 6 GC errors. I spent some time trying to track it down before but never made it as far as you did. Here's hoping that this is the last GC bug. ;-) -- Matt Diephouse http://matt.diephouse.com
Re: [perl #42865] [BUG] There's no way to set a vtable function with a Sub at runtime
Allison Randal [EMAIL PROTECTED] wrote: For classes, the 'add_method' method takes a named parameter to say whether it's a vtable function. And, vtable functions aren't stored in the namespace at all anymore, but in a data structure inside the class, so you wouldn't have 'root' and 'hll' variants. I can see potentially see adding an 'add_vtable' vtable function, parallel to add_method, add_attribute, etc. After the recent decoupling of vtable functions from methods (with the addition of the :vtable pragma), why would you want to re-couple them? I see the two as distinct features, each with their own uses. Sometimes there's shared behavior, but there ought to be the ability to have them behave differently. What's the use case for modifying a low-level PMC's vtable entries at runtime? Or, are you only talking about overriding vtable functions in a class? The latter. It seems like there should be a way to override them without using eval -- particularly since there's nothing preventing it technically. -- Matt Diephouse http://matt.diephouse.com
Re: [perl #42864] [BUG] Copying a :vtable sub also copies :vtable information
Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: In a way, when copying it, it does make sense all attributes are copied as well (it seems clean) Indeed. Let's categorize this bug as a feature. Are you sure? It seems like this bug/feature will go away when pdd15 is implemented. At that point, setting a Sub in a namespace will no longer modify the methods or vtable functions of a class. As a feature, this could do a world of hurt. I'm not sure how much sense it makes to copy a method from one class to another, but I'd hate to see vtable functions trampled over. Imagine this: you copy a method from one class to another. Unknown to you, that method was also acting as the get_string vtable function. By copying the method, you also replaced that vtable function in the destination class. Now when your language tries to stringify an object using the get_string vtable function, it gets something other than the string it should have gotten. -- Matt Diephouse http://matt.diephouse.com
Re: [perl #42792] GC bug added in r18323
chromatic [EMAIL PROTECTED] wrote: On Sunday 29 April 2007 11:18:20 Joshua Isom wrote: I've done realclean a few times actually. If I run with r18322, it runs just fine, but r18323, which dealt with zero length mallocs for strings, caused it to start crashing. Here's a backtrace. This is one of those tests where with -G it succeeds, so you'll have to make sure that gc is enabled. I'm not having any trouble on my darwin/ppc machine, but my only two running platforms are darwin/ppc and freebsd/amd64. Here's a patch that fixes a related bug in Tcl on certain platforms. How does it fare for you? I committed this patch to trunk in r18377. -- Matt Diephouse http://matt.diephouse.com
[perl #42795] [PATCH] NULL function pointer should be a pointer
Applied in r18355. Thanks! -- Matt Diephouse
Re: [perl #42776] [BUG] is isa ok?
On 4/27/07, via RT Jerry Gay [EMAIL PROTECTED] wrote:
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42776]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42776
there are two 'isa' ops, defined in src/ops/object.ops
one takes a string param, and the other a pmc. it seems the string
variant is used frequently throughout the source and tests, but the
pmc variant is much less frequently used, and i haven't come across
any tests, either. it seems these two ops don't agree on return
value... which is problematic.
D:\usr\local\parrot\headparrot -
.sub main
.local pmc class, obj
class = new 'Class'
obj = class.'new'()
$I0 = isa obj, 'Object'
print $I0
.local pmc cl
cl = new 'String'
cl = 'Object'
$I1 = isa obj, cl
print $I1
.end
^Z
10
why? iunno. but this is causing me problems when using 'isa_ok' in
'Test/More.pir', since it uses the pmc variant.
It looks like the PMC variant is correct in this case, because Object
isn't actually a class. There's a class flag for PMCs that sets
whether or not they are a class and Object doesn't have this set.
When you call the PMC variant of isa, it calls Parrot_object_isa, and
that has this code:
/* if this is not a class */
if (!PObj_is_class_TEST(pmc)) {
pmc = VTABLE_get_class(interp, pmc);
}
So since Object isn't a class, it calls the get_class vtable and gets
the Class pmc. It then tests the object to see if it's a Class, which
it obviously isn't.
Contrast this to the String isa variant. It calls the isa vtable
function. Object inherits whatever default isa implementation is
provided. I'm not sure where that code is (it's a little harder to
find), but I'm guessing it just does a string comparison on the PMC
names without testing if the PMC is a class.
--
Matt Diephouse
http://matt.diephouse.com
[perl #42558] [PATCH] add runtime_prefix for interpinfo and use it in config.pir
On Mon Apr 16 13:07:22 2007, [EMAIL PROTECTED] wrote: Without this patch, for runtime/parrot/library/config.pir to work, parrot has to be run in its root directory (in fact, there was an XXX note in there saying so.) I changed Parrot_get_runtime_prefix not to return a const value because the value should be free'd later on. Also, here's an example PIR file to demonstrate. Looks good. Applied in r18343. Thanks! -- Matt Diephouse
[perl #42300] [PATCH] t/pmc/sub.t: test for creation of lex by clone op
First, the test (rearranged to include only the relevant parts): +.sub main :main +.local string ok, not_ok +ok = ok +not_ok = not ok + +# if 'not ok' is printed, it means that the lexical environment +# for the first closure in each pair, (where out = ok) +# was overwritten by the lexical environment created for the +# second closure (where out = not ok) + +$P10 = makebar_clone(ok) +$P20 = makebar_clone(not_ok) +$P10() +.end + +.sub makebar_clone +.param pmc out +.lex 'out', out +.const .Sub s = 'bar' +$P0 = clone s +.return($P0) +.end + +.sub bar :outer(makebar_clone) +$P0 = find_lex 'out' +say $P0 +.end (This prints not ok. The test in the patch expects ok.) You're arguing that the different copies of bar that are returned from makebar_clone should have different lexical environments. I'm pretty sure that this is not the case. Without using newclosure, there's no closure so the lexical environments are the same. What the :outer does in this case is rearrange the lexical stack so that makebar_clone appears in the lexical stack for bar. So we're using the lexical environment from the last time that makebar_clone was called. It's bizarre that this even works because without the closure, I'd think that the lexical environment would have destroyed. I'm not sure how intentional this is. The PDD isn't clear (to me) about what :outer means in the absence of newclosure. I'd definitely be interested in seeing why this would be a useful feature. More detail in the PDD would be nice. Thanks for the interesting patch. -- Matt Diephouse
[perl #42407] [PATCH] refactor vtable overriding, delegate.c generation
On Mon Apr 23 13:39:40 2007, [EMAIL PROTECTED] wrote: Gracias. I attached one more small patch that gets rid of two seemingly unnecessary lines in smop_init() - they're easy to miss when one's looking at the big picture. Applied in r18321. Thanks! -- Matt Diephouse
Re: [perl #42320] [BUG] Memory leak with String pmc
Leopold Toetsch [EMAIL PROTECTED] wrote: Am Montag, 23. April 2007 20:23 schrieb chromatic: On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote: The next program causes a memory leak for me. .sub main :main loop: $P0 = new .String goto loop .end That's an endless loop. How does one measure, if it's leaking memory? Presumably, every iteration of the loop uses the same physical register. This should free up the String from the previous iteration for collection. If there's a leak, memory would climb higher and higher; if there's not, it should level out. -- Matt Diephouse http://matt.diephouse.com
Re: [PATCH] Re-work Parrot_process_args
chromatic [EMAIL PROTECTED] wrote:
On Sunday 22 April 2007 17:38, Matt Diephouse wrote:
The attached patch completely reworks Parrot_process_args. The changes
are extensive and I think they make the code much clearer. Rather than
just check it in, I thought I'd try to get feedback here to make sure
that it is clearer to everyone else and not just to myself.
It's a lot clearer.
Good.
This patch also fixes a few bugs:
#40490: Flat/Slurpy Named Parameter Passing Errors
Yay!
I thought you might like that. :)
A couple todo'd error condition tests
I'm sure there is more that can be done to clean things up, but this
is at least a start. I've already spent 15+ hours on this patch, so
I'm ready to check things in and leave further improvements for
another time.
I only noticed one thing (besides large swaths of removed code, which is
always nice). This code occurs multiple times:
+/* if the :flat arg is empty, just go to the next arg */
+if (!st-src.slurp_n) {
+st-src.mode = ~CALL_STATE_FLATTEN;
+st-src.i++;
+}
It's three lines; is it worth extracting somehow?
It could definitely be placed inside start_flatten(), but that would
make the code a little misleading, I think. I'm not sure it's worth
placing it in a function of its own; the transparency may be worth
something in this case. Having said that, I think this section of the
code could be cleaned up more with further refactoring down the road.
There's also a large ~20 line section of code that is repeated in this
patch that I'll move to a function before I commit.
--
Matt Diephouse
http://matt.diephouse.com
[PATCH] Re-work Parrot_process_args
The attached patch completely reworks Parrot_process_args. The changes are extensive and I think they make the code much clearer. Rather than just check it in, I thought I'd try to get feedback here to make sure that it is clearer to everyone else and not just to myself. This patch also fixes a few bugs: #40490: Flat/Slurpy Named Parameter Passing Errors A couple todo'd error condition tests I'm sure there is more that can be done to clean things up, but this is at least a start. I've already spent 15+ hours on this patch, so I'm ready to check things in and leave further improvements for another time. -- Matt Diephouse http://matt.diephouse.com arg-handling.patch Description: Binary data
Re: [perl #42406] [PATCH] improper null testing in Parrot_instantiate_object
Alek Storm [EMAIL PROTECTED] wrote: On 4/19/07, Allison Randal via RT [EMAIL PROTECTED] wrote: Do you have a test case that shows where the current behavior is incorrect? The attached test case... Looks like either (a) you forgot to attach the patch or (b) RT ate it. Care to try again? :) -- Matt Diephouse http://matt.diephouse.com
Re: Error on Debian distrib
On 4/17/07, chris [EMAIL PROTECTED] wrote: I am installing Parrot both on Mandriva ans Debian. This error only occurs on Debian distrib. ./miniparrot config_lib.pasm runtime/parrot/include/config.fpmc real_exception (severity:2 error:30): Complex: malformed string likely reason: argument count mismatch in main (more than 1 param) make: *** [runtime/parrot/include/config.fpmc] Erreur 30 Unfortunately, it's difficult to know what the cause of this error would be without access to the machine you're getting it on. It sounds like you're trying to install Parrot using apt. If that is the case, you may want to try building from a release tarball or checking out a copy using subversion (instructions available here: http://www.parrotcode.org/source.html ). Alternatively, it'd be great if you wanted to try to figure out the cause of the issue (using gdb). There is usually someone around on irc.perl.org#parrot who could help you debug if you need it. Best of luck! -- Matt Diephouse http://matt.diephouse.com
Parrot 0.4.11 released
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.11 Tax Bird. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.11 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.4.11 News: - Compilers: + IMCC: added documentation for C-based Parrot Calling Conventions, refactorings and bug fixes + PGE: new perl6regex front end reflecting recent S05 syntax changes + PIRC: new prototype PIR parser - Languages: + Updated Lua, PHP (Plumhead), BASIC, pynie + Lua implements environment - Design: + PDD15 Objects - details added, and draft approved - Documentation: + Added guidelines for PMC documentation - Implementation: + PDD15 implementation is largely complete, including role-based composition, introspection, and C3 method resolution order + new Exporter PMC for importing globals between namespaces + new string utilities for radix conversion + PCCINVOKE and Parrot_PCCINVOKE allow calling using the full Parrot Calling Conventions from PMCs and C code respectively - Build: + Refactorings and improvements in test coverage for 'Configure.pl' - Misc: + many bugfixes, enhancements, and code cleanup + added example subversion config file + extended support for gcc, icc, and other compilers + extended support for Solaris and other platforms Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! -- Matt Diephouse
Release Code Slush
With the next release roughly a day away, please refrain from making any major changes in trunk. If you have major changes, hold on to them, create a branch, or create a [PATCH] ticket. Generally, just keep the release in mind while making any commits. Any bug fixes or changes to HLLs or documentation are welcome, as always. Thanks! -- Matt Diephouse http://matt.diephouse.com
Bug Day: Saturday, 14 April 2007
-- From http://rakudo.org/parrot/index.cgi?bug_day_2007_04_14 -- Bug Day On Saturday, 14 April 2007, please join us on IRC in #parrot (irc.perl.org) to work on closing out as many RT (https://rt.perl.org/rt3/ ) tickets as possible in the parrot queue. This will help us get ready for the next release of parrot 0.4.11, scheduled for Tuesday 17 April 2007. You'll find C, parrot assembly, perl, documentation, and plenty of tasks to go around. Core developers will be available most of the day (starting at around 10am GMT) to answer questions. No experience with parrot necessary. -- From: http://rakudo.org/parrot/index.cgi?planned_release_april_17_2007 -- There's a milestone ticket here: http://rt.perl.org/rt3/Ticket/Display.html?id=41582 Which contains all the tickets I'd like to see resolved in 0.4.11. If you just want to view the unresolved tickets, you can use this saved search: http://xrl.us/veso If you've got something you're working on that you think you'll be getting done before the release, please - add a ticket for it (if necessary); - add it as a dependency for this ticket Thanks in advance for your patches and commits. ^_^ ... Speaking of patches, we should also get through as many of these (accept or reject) as possible. http://www.parrotcode.org/openpatches.html Thanks! -- Matt Diephouse
[perl #41763] [PATCH]: fix clone method for iterators
On Fri Mar 09 09:27:22 2007, [EMAIL PROTECTED] wrote: I noticed that if you cloned an iterator that you had already shifted, the clone started at the beginning, rather than at the original's current location. Applied in r17691 with one change: C89 specifies that all variable declarations have to be at the beginning of a block, so I had to move one of the lines so that this was the case. Please watch for this in the future. Thanks! -- Matt Diephouse
Re: [PATCH] Avoid //-style comments.
Andy Dougherty [EMAIL PROTECTED] wrote: Please avoid //-style comments. Older compilers don't understand them. Thanks. We have a test for //-style comments, but evidently it doesn't catch all of our generated code. I've changed it to a C-style comment in r17692. -- Matt Diephouse http://matt.diephouse.com
Countdown to 0.4.11
Now that 0.4.10 has been released, it's time to start work on 0.4.11. Following Will's lead, I've put together a list of tickets I'd like to see resolved for the upcoming release: http://xrl.us/veso The list includes tickets of all kinds (bugs, todos, cage items, patches) in all languages (PIR, C, Perl). It's a fairly long list, but I think we can get all the issues resolved in the next month. Let the patching begin! -- Matt Diephouse http://matt.diephouse.com
[perl #41790] [PATCH] Change sub's get_string to return short name
Applied in r17484 with updated tests and a test for the get_namespace() method.
Re: [perl #41790] [PATCH] Change sub's get_string to return short name
Jonathan Worthington [EMAIL PROTECTED] wrote: Will Coleda (via RT) wrote: So, since we can we can already get the current namespace with: current_ns = interp['namespace'] This isn't a full replacement of the functionality we'd lose, since you may want to get the namespace of a sub other than the one you're currently executing. There may already be a way to do that, though...if not, maybe the sub PMC needs a get_namespace method. Actually, it already has one. I vote we change Sub's get_string to return the simple name instead of the full name. Gets my vote too. Mine too. I almost changed this myself a couple weeks ago. Below is a patch to do just that (mdiep++). Hearing no objections (anyone?), I'd like to get this into 0.4.10. With it applied, there are ~13 core subtest failures, those will need to be fixed to expect the new behavior. Just to be clear - are they tests of what Sub stringifies to rather than failures as a result of other bits of the core expecting Sub to stringify to something including the namespace? Not that both can't be fixed, just curious. There's some of both, I think. I recently had to change a test to expect the long name of a Sub because there was no way to get the short name. -- Matt Diephouse http://matt.diephouse.com
[perl #41739] [PATCH]: add clone method for iterators
Thanks! I couldn't get patch to apply the patch, so I applied it by hand. Committed in r17411.
[perl #41733] invoke :vtable - execution stops
On Wed Mar 07 17:02:47 2007, mdiep wrote:
This gets us close to what I want:
void* invoke(void *next) {
STRING *meth = CONST_STRING(interp, __invoke);
STRING *meth_v = CONST_STRING(interp, invoke);
PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
if (PMC_IS_NULL(sub))
sub = find_or_die(interp, pmc, meth);
(void*) Parrot_run_meth_fromc_args(interp, sub,
pmc, meth, ??, next);
return next;
}
We all missed the obvious solution: just invoking the sub, rather than entering
a new
runloop. This has the benefits of not creating a new runloop and of handling
parameters and
return values properly. It may even make invoke work with :multi (it might need
a bit more
work for that).
Fixed in r17385.
--
Matt Diephouse
void* invoke(void *next) {
STRING *meth = CONST_STRING(interp, __invoke);
STRING *meth_v = CONST_STRING(interp, invoke);
PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
if (PMC_IS_NULL(sub))
sub = find_or_die(interp, pmc, meth);
INTERP-current_object = SELF;
return VTABLE_invoke(interp, sub, next);
}
Re: [perl #41733] invoke :vtable - execution stops
Alek Storm [EMAIL PROTECTED] wrote:
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke method takes and
returns an opcode_t*, and PIR can't handle that, so I've attached a
patch correcting the problem by converting the argument and return
value so the PIR plays nice.
Any ParrotObject overriding the invoke vtable method is probably not
going to care about addresses. Luckily, all we have to do is return
the address we're given, so everything goes back to normal after the
method's finished. The downside is that you're going to have to come
with a more creative workaround in order to be passed any arguments
that the method is called with.
I don't think that's the right route to take. Exposing the pc to PIR-land
code seems dangerous and I don't think there's much point. As a PIR user, I
want the invoke vtable to behave just like any other PIR subroutine.
This gets us close to what I want:
void* invoke(void *next) {
STRING *meth = CONST_STRING(interp, __invoke);
STRING *meth_v = CONST_STRING(interp, invoke);
PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
if (PMC_IS_NULL(sub))
sub = find_or_die(interp, pmc, meth);
(void*) Parrot_run_meth_fromc_args(interp, sub,
pmc, meth, ??, next);
return next;
}
I've tested it and it works with the original code that Richard gave. The
only thing left to do is handle return values; I'm still working on that. If
I can get return values working properly, I'll check in a fix.
--
Matt Diephouse
http://matt.diephouse.com
Re: [perl #41511] Parrot_call_sub* Incompatible with Multisubs
via RT chromatic [EMAIL PROTECTED] wrote: # New Ticket Created by chromatic # Please include the string: [perl #41511] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41511 Hi there, Here's a complex one. Define a multisub in PIR, then try to call it from C. I assume that you get the PMC for the (multi) sub, then use Parrot_call_sub*() to invoke it. The problem is that the layout of a Sub PMC is different from the layout of a MultiSub PMC, especially when the code tries to do: CONTEXT(interp-ctx)-constants = PMC_sub(sub)-seg-const_table-constants; For a normal Sub, PMC_sub(sub)-seg is a pointer. For a MultiSub, PMC_sub(sub)-seg is the number of multi variants. Crash! Boom! Removing this code doesn't help, because then it gives argument mismatch errors. Similarly, setting this code within invoke() in MultiSub doesn't seem to avoid the crash either for some reason. I suspect that there was a similar problem avoided earlier when MultiSubs first appeared, or that there's a better way to initialize context when running code from C. I can provide more code if necessary, unless this looks like an obvious fix to someone. If you wanted to send me some sample code that invoked both a normal sub and a MultiSub, I'd certainly take a look. I'm pretty sure the whole idea of invoke-able objects was never really thought out -- some of the logic in Sub.invoke() should be elsewhere. -- Matt Diephouse http://matt.diephouse.com
Re: __init vs. __init_pmc
Leopold Toetsch [EMAIL PROTECTED] wrote: Hi, some changes not too long before the release did break pg.t. I was now able to track it down: now the object constructor: $I0 = find_type ['Pg';'Conn'] o_con = new $I0, con does _not_ call .sub init :vtable :method anymore it's calling init_pmc instead. This change is just adding more mess to object construction and argument passing. I've made several attempts to unify object construction with new calling convs but no one seems to be listening :-( That was a change I made (with Allison's approval). The purpose of the change was to eliminate differences between PMCs and objects. It's confusing for PMCs and objects and objects that subclass PMCs to behave differently. Given that PMCs can have two different init functions, how does it make sense for objects to have only one? Does providing an init function for a subclass of a PMC override both of the parent's init functions? -- Matt Diephouse http://matt.diephouse.com
Re: Subject: Parrot 0.4.8 Released
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: chromatic wrote: On Saturday 20 January 2007 10:36, Jarkko Hietaniemi wrote: I can't help the feeling that Parrot is a nice linux x86 experiment. Of course one can make the claim that not fixing the problems is my problem. I so do; want commit access? To which I say: I knew that would get your attention; and no, I'm past caring. Alternatively, if you (or anyone else) wanted and were able to provide developer access to a Tru64 box, existing committers could try to fix the problems. And yes, I would be willing to take a shot at it (realizing that I may or may not be successful). AFAICT, we're limited not just by volunteer labor, but also by the boxes that are available to those volunteers. -- Matt Diephouse http://matt.diephouse.com
Re: [perl #41237] [TODO] PMC Class name IDs will require a dot in front
Allison Randal via RT [EMAIL PROTECTED] wrote: PMC Class name IDs ... will require a dot in front My preference is to eliminate the dot in classname IDs. Lodge your objections now, before it's made fact in 0.4.9. Allison I actually prefer the dot. I don't like the possible ambiguity between types and local variables: .local string MyClass MyClass = '...' $P0 = new MyClass # is this a type or a string? Capitalized variable names may be rare and/or bad practice, but it's bound to happen. There was talk on #parrot about how this still conflicts with macros, but those are rarer than variables. Also, if we decide that anything starting with a dot that doesn't have parens is a type, I could write: $I0 = typeof $P0 if $I0 == .Foo goto bar I know we're not optimizing PIR for human readability, but I've written a lot of it, so I appreciate the little things. :) -- Matt Diephouse http://matt.diephouse.com
Re: Tcl windows make problems
Klaas-Jan Stol [EMAIL PROTECTED] wrote: hello, yesterday I had a look at why tcl does not build on windows. Although I haven't been able to fix it, I'd like to share the issues I found, so you don't have to look for it yourself. there were several problems with the makefile line 123: ops: src\binary.o , should be binary$(O) this is fixed by particle. line 126: @cd $(OPSDIR) $(OPSBUILD) linklibs tcl ..\binary$(O) makes that the system will look for binary.obj_ops_switch.obj changing it into ..\ops\tcl will fix that problem Furthermore, the next problem is that the ops file won't link correctly because binary.obj is not linked. To solve the problem, I added binary.obj to the tools/build/dynoplibs.pl script, but of course that is not a good solution. I haven't been able to solve it. Maybe it's an idea to just put the source from binary.c into the ops file itself, if that's possible. Ah, I see what happened here. I had to change things around in the first place to be able to link in another object file with my dynamic opcodes. I ended up changing dynoplibs.pl to link arguments differently if they were object files. But my fix looked for .o files, so it didn't work on Win32. I just committed a fix that should make it work. If that's corrected, you'll find 1 more problem: if binary.obj is linked, it can't resolve the symbol _PMCNULL. As a quick hack, I #define'd PMCNULL as NULL. After these fixes, it worked. Okay, I just changed the occurrences of PMCNULL to NULL. Things should work now. Hope this helps you further. regards, klaas-jan It was very helpful, thanks! -- Matt Diephouse http://matt.diephouse.com
[perl #41197] Does change to config/gen/makefiles/dynoplibs_pl.in cause make to fail?
This was fixed a few minutes ago in r16458. You'll need to re-up and re-configure. Sorry for the inconvenience. -- Matt Diephouse
Bind to an Unspecified Port
I've been looking through the sockets code while writing a PIR socket
library and I've noticed one major deficiency: if you pass 0 as the
port you wish to bind to, the OS will choose a port for you. But
there's no way in Parrot to find out which port that is.
Right now, bind just returns 0 on success (and -1 on failure). I'd
like to change bind to return the port it's bound to on success. The
patch below adds this code for the unix sockets code. The windows code
looks like it'd be the same, but I can't test it so I'd have to find
someone to help with that.
--
Matt Diephouse
http://matt.diephouse.com
Index: src/io/io_unix.c
===
--- src/io/io_unix.c(revision 16202)
+++ src/io/io_unix.c(working copy)
@@ -776,7 +776,18 @@
return -1;
}
-return 0;
+/* bind was successful. return the port number we're bound to. */
+if (io-local.sin_port)
+return ntohs(io-local.sin_port);
+else {
+struct sockaddr_in server;
+int length;
+
+if (getsockname(io-fd, (struct sockaddr *)server, length) == -1)
+return 0;
+else
+return ntohs(server.sin_port);
+}
}
/*
Re: p6 variable binding in Parrot
Patrick R. Michaud [EMAIL PROTECTED] wrote: Does anyone have any suggestions about what sort of PIR code and/or PMCs we need to be able to do make the following Perl 6 code work...? Sure. I think Tcl handles this pretty nicely at the moment (although Leo disagrees - he likes the Ref PMC route). The main idea is that aliasing/binding enters the same PMC under a different name and that assignment morphs the PMC. my @a; @a[4] = 'Hello'; my $b := @a[4]; say $b;# says Hello @a[4] = [1, 2]; say $b;# says 1 2 Here are the pieces I can fill in: my @a; new $P0, .Perl6List .lex '@a', $P0 @a[4] = 'Hello'; find_lex $P1, '@a' # (in general case we autovivify @a here if needed) set $P1[4], 'Hello' my $b := @a[4]; find_lex $P2, '@a' $P2 = $P2[4] .lex '$b', $P2 say $b;# says Hello say $b @a[4] = [1, 2] $P2 = 'list'(1, 2) # create a list find_lex $P3, '@a' # (in general case we autovivify @a here if needed) set $P3[4], $P2 With this scheme, you'd have to use assign in this last case instead of set (with a morph to really make it safe) because you need to reuse the same PMC: @a[4] = [1, 2] $P2 = 'list'(1, 2) find_lex $P3, '@a' $P3 = $P3[4] morph $P3, .Undef assign $P3, $P2 If you're only assigning your own PMCs, you can drop the morph (which isn't technically safe anyway). -- Matt Diephouse http://matt.diephouse.com
Re: Re: p6 variable binding in Parrot
Patrick R. Michaud [EMAIL PROTECTED] wrote: On Fri, Dec 08, 2006 at 05:05:00PM -0500, Matt Diephouse wrote: Patrick R. Michaud [EMAIL PROTECTED] wrote: Does anyone have any suggestions about what sort of PIR code and/or PMCs we need to be able to do make the following Perl 6 code work...? Sure. I think Tcl handles this pretty nicely at the moment (although Leo disagrees - he likes the Ref PMC route). The main idea is that aliasing/binding enters the same PMC under a different name and that assignment morphs the PMC. Does this basically assume that every PMC knows how to morph into any other type? (In the example I gave the PMC would need to be able to morph from an integer to a list, but in the general case it could be converting to any type.) No, it assumes that every PMC knows how to morph into an Undef. Once you have an Undef, you can safely use assign. Undef's assign morphs to the type of the second PMC and then calls assign again, so that each type only needs to handle one type in assign -- itself. With this scheme, you'd have to use assign in this last case instead of set (with a morph to really make it safe) because you need to reuse the same PMC: @a[4] = [1, 2] $P2 = 'list'(1, 2) find_lex $P3, '@a' $P3 = $P3[4] morph $P3, .Undef assign $P3, $P2 If you're only assigning your own PMCs, you can drop the morph (which isn't technically safe anyway). I don't think I can assume I'm only assigning my own PMCs. (This is being handled in PAST-pm, and so it probably needs to work with PMCs in general.) And I know that morphing isn't safe, which is why I've been avoiding it. Hmm... perhaps what we really need is an opcode or sequence of opcodes that convert a PMC into a value-based copy (clone?) of another PMC, but keeping the first PMC as the same PMC so that other references to it will see the new value and type. I would like to see some sort of morph opcode that isn't a vtable function. This fits in to my transparent references proposal (which I haven't quite finished). I'm not sure what the use case of the morph vtable function is supposed to be. Note that using Ref PMCs isn't completely safe either, as they use the set_pmc vtable function. -- Matt Diephouse http://matt.diephouse.com
Re: [perl #40966] [BUG] Parrot core dumps in perl6 (possible GC/pointer bug?)
via RT Patrick R. Michaud [EMAIL PROTECTED] wrote:
With the latest changes to the perl6 compiler I'm starting to see
miscellaneous core dumps from Parrot. I think it's likely GC or
pointer related, as the program in question runs correctly with the
-G flag present.
The core dump appears for me in r15764. The steps to build perl6.pbc:
1. build parrot
2. cd languages/perl6
3. make
After building the perl6.pbc compiler, running perl6.pbc on
t/00-parrot/07-op-string.t produces the core dump:
$ ../../parrot perl6.pbc t/00-parrot/07-op-string.t
parrot: src/string.c:2086: string_hash: Assertion `s-encoding s-charset
!(((s)-obj.flags) b_PObj_on_free_list_FLAG)' failed.
Aborted (core dumped)
While I didn't get this error here, I got it on one of the other Perl6
tests and spent some time debugging. The portion of the assertion that
fails is
!(((s)-obj.flags) b_PObj_on_free_list_FLAG
which means that this string has been garbage collected. I saw a
couple different instances of this problem and in all of them, the
string in question was a constant (some were C-level and others were
PIR-level).
So the underlying problem is that constant strings are getting
collected when they shouldn't. The easy fix is to not collect *any*
constant PObj headers (see patch below). Is this correct? Or is there
a case when they should get collected? If it's the later, does somehow
know how to fix the issue?
--
Matt Diephouse
http://matt.diephouse.com
Index: src/dod.c
===
--- src/dod.c (revision 15920)
+++ src/dod.c (working copy)
@@ -553,6 +553,8 @@
for (i = nm = 0; i cur_arena-used; i++) {
if (PObj_on_free_list_TEST(b))
; /* if its on free list, do nothing */
+else if (PObj_constant_TEST(b))
+; /* if its a constant, do nothing */
else if (PObj_live_TEST(b)) {
/* its live */
total_used++;
Re: Re: [perl #40966] [BUG] Parrot core dumps in perl6 (possible GC/pointer bug?)
Leopold Toetsch [EMAIL PROTECTED] wrote:
Am Dienstag, 5. Dezember 2006 20:39 schrieb Matt Diephouse:
The portion of the assertion that
fails is
!(((s)-obj.flags) b_PObj_on_free_list_FLAG
which means that this string has been garbage collected. I saw a
couple different instances of this problem and in all of them, the
string in question was a constant (some were C-level and others were
PIR-level).
So the underlying problem is that constant strings are getting
collected when they shouldn't.
constants reside, when correctly created, in different object pools than
GC-able items (constant_pmc_pool, constant_string_header_pool). PMCs in the
constant_pmc_pool are marked during GC. No constant pool item is swept during
GC, i.e the are only collect on interpreter shutdown.
Constant PMCs are marked, but are constant STRINGs?
If above assert triggers, then some item are created in the wrong pool and
then stored as constants.
To track that further down, it'll be helpful to have some information about
the origin contents of the GC-ed constant, but typically such creation code
is in imcc or packfile.
I'm on my laptop atm and it's not exhibiting the error, but the
constant in question was in a method call:
$P0.'method'('string constant that was getting collected', ...)
--
Matt Diephouse
http://matt.diephouse.com
[perl #41047] [BUG] :multi doesn't work with :outer
Fixed in r15971. The MMD code checks that the sub is a Sub PMC so it can get the signature. I expanded the check to work with Closure PMCs as well.
Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Leopold Toetsch [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. What native type optimizations? Using S, I, and N registers? If using an I register is faster, wouldn't you want to unbox an Integer PMC and use an I register anyway? Is there a specific case you have in mind? -- Matt Diephouse http://matt.diephouse.com
Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Patrick R. Michaud [EMAIL PROTECTED] wrote: On Wed, Nov 29, 2006 at 04:43:59PM -0500, Matt Diephouse wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. What native type optimizations? Using S, I, and N registers? If using an I register is faster, wouldn't you want to unbox an Integer PMC and use an I register anyway? Sure, but Parrot is unboxing for us already, without us having to do anything special: .sub 'foo' :multi(_, String) .param int abc .param pmc xyz ... .end foo(1, 'xyz') # boxes 'xyz', leaves 1 alone foo($P0, $P1) # unboxes $P0 to an int, leaves $P1 alone That's the point I was trying to make. I can't think of any case where you would want to have a different param type based on whether you passed a native type: .sub 'foo' :multi(int) .param int abc ... .end .sub 'foo' :multi (Integer) .param pmc abc ... .end Because what would be the point? If using a native type in the sub is faster, then use it no matter what: unbox the PMC. If it's not faster, then there's no optimization and you may as well autobox to a PMC when a native type is passed in. I'm not at all an expert on the topic of multis, but it sounds to me as though :multi is being somehow conflated with when to auto[un]?box. I think :multi should limit itself to being a way of selecting which sub(s) to call, while autoboxing should be based solely on the arguments of the caller and parameters of the called sub (once that sub has been chosen by :multi). Even with the patch, :multi limits itself to being a way of selecting which sub(s) to call, so no worries there. It's not that I have my heart set against dispatching on native types, but I would like to see a reason for it. Leo mentioned optimization, but I don't see how that applies. We've basically run into the fact that there's no spec for MMD. I'll see if I can provide a patch that just makes _ match native types, but I think it'll be somewhat more involved than this one. -- Matt Diephouse http://matt.diephouse.com
Re: Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Matt Diephouse [EMAIL PROTECTED] wrote: We've basically run into the fact that there's no spec for MMD. I'll see if I can provide a patch that just makes _ match native types, but I think it'll be somewhat more involved than this one. It ended up being easier than expected -- implemented in r15910. -- Matt Diephouse http://matt.diephouse.com
Re: [perl #41000] Can't compile simple parrot example with latest stable parrot
On 11/27/06, via RT Bob Wilkinson [EMAIL PROTECTED] wrote: # New Ticket Created by Bob Wilkinson # Please include the string: [perl #41000] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket /Display.html?id=41000 My second 10 line parrot program didn't compile, so I looked at the examples at http://www.parrotcode.org/examples/pasm.html, and pasted the following into a file. [EMAIL PROTECTED]:~/src/parrotcode$ cat ex1.pasm new P0, .PerlInt set P0, 123 new P1, .PerlInt set P1, 321 add P1, P1, P0 print P1 print \n end [EMAIL PROTECTED] :~/src/parrotcode$ ../parrot-0.4.7/parrot ex1.pasm error:imcc:syntax error, unexpected DOT in file 'ex1.pasm' line 1 I am not sure how to proceed. This example doesn't work anymore because PerlInt is no longer a builtin PMC. The examples need to be updated. Replacing PerlInt with Integer makes it work: new P0, .Integer set P0, 123 new P1, .Integer set P1, 321 add P1, P1, P0 print P1 print \n end -- Matt Diephouse http://matt.diephouse.com
Re: Re: :anon Subs and Namespaces
Allison Randal [EMAIL PROTECTED] wrote: Okay, so we're basically solving the same problem as Perl 5's main routine, which it stuffs in an obscure C variable internal to the interpreter, not accessible from the symbol table. (Talk about less-than-transparent introspection.) Huh. I don't know anything about Perl 5's internals, but that's interesting and it makes a lot of sense. I don't fully grok Tcl, so a few questions (which may or may not be relevant): Where do mainstream implementations of Tcl store that executable main block of code? Or, more importantly, where do they store 'number' in the case without the namespace and the case with the namespace? The official Tcl implementation is an interpreter, not a compiler. So I suspect the answer to your question is it doesn't. But without a namespace, 'number' is stored in the root HLL namespace; it could also be accessed absolutely (C $::number ). One common use of anonymous subs in a dynamic language is for later exporting them into another package (or multiple different packages). In that case, you really don't want the sub to retain a link to its defining namespace, you want it to fully adopt the namespace it's pushed into. Which has everything to do with the earlier Perl example of creating anonymous subroutines, but little to do with creating main routines, since they don't change packages. (Code examples are helpful.) I'm struggling to understand what you're saying here. You noted before that Perl 5's anonymous subroutines are full dynamic closures. As such, they don't ever fully adopt the namespace they're pushed into. Are you thinking of a different language? or am I missing a case? Let's see... for :main, :load, :method, and :vtable compilation units it makes sense to default lookups to the namespace where they were defined, even if they're anonymous. For an ordinary :anon .sub (with no :vtable, :method, :load, :main, etc) I could argue it either way, but with the other uses remaining tied to the namespace where they were defined, let's default to your fix (consistency is good). I was hoping you'd say that. :-) Then for exporting (and other dynamic tricks), let's look into a feature that allows you to change the namespace a compilation unit uses for default lookups, after it's compiled. That seems like a good idea. -- Matt Diephouse http://matt.diephouse.com
:anon Subs and Namespaces
Let's try this again, starting from the Tcl side of things. Tcl code
can exist outside of subroutines. This, for example, is a valid Tcl
program:
set number 5
puts $number
In order to compile this to PIR, we have to put it into a subroutine.
The only problem with putting it into a subroutine is that we don't
want to pollute our namespace. So, naturally, we make it an :anon sub.
Here is an extremely simplified version (that represents the ideal,
but probably unattainable, emitted PIR):
.HLL 'tcl', 'tcl_group'
.namespace
.sub 'main' :anon :main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
That doesn't look too bad. This actually works and correctly stores
the number variable in the root HLL namespace. But things get a
little hairier when we start using namespaces in Tcl:
namespace eval test {
set number 5
puts $number
}
This is the equivalent of running the first example in a different
namespace. So, again, the simplified, ideal PIR is:
.HLL 'tcl', 'tcl_group'
.namespace ['test']
.sub 'main' :anon :main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
But here we run across the behavior that led me to file RT#40955: I
have an anon namespace that uses the notion of the current namespace.
The code is the same, but the PIR example doesn't work because the
current namespace inside the :anon sub is the root HLL namespace. So
while
set_global 'number', number
would normally be equivalent to
set_hll_global ['test'], 'number', number
in this case, it's actually equivalent to
set_hll_global 'number', number.
All this because when Parrot sees an :anon sub it attaches the root
HLL namespace to it (or did, before I applied my fix). It's not that
it doesn't attach any namespace to it, it's that always attaches the
root HLL namespace regardless of the namespace it's declared in.
That, at least, ought to change. If there is no notion of a current
namespace in an :anon sub outside of a closure, then trying to use one
ought to make things blow up so I can see the error in my ways. :-)
Still, I'm curious to see what reasons there are for not attaching a
namespace to an :anon sub when (1) it seems convenient and (2) all of
Parrot's tests still pass. Does this break anything? Or did this just
signal to you that there may a problem here that needs its own
solution?
--
Matt Diephouse
http://matt.diephouse.com
set_pmc + setref/deref: anyone using them?
Would anyone be inconvenienced if the set_pmc vtable and the setref and deref opcodes were removed? Note that if you are using set _pmc but are not using assign_pmc, then you may not be inconvenienced because right now the default assign_pmc vtable calls set_pmc. These opcodes were added to make transparent references possible, but they weren't really specced out or desisign ed properly. As such, they're a little broken and we'd like to remove them. -- Matt Diephouse http://matt.diephouse.com
Re: Re: classnames and HLL namespaces -- help!
Allison Randal [EMAIL PROTECTED] wrote:
Matt Diephouse wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
a relic of the past and I think it needs to change. I'm pretty sure
that HLL classes will have to go into the HLL's root namespace (this
needs to happen anyway to prevent namespace pollution). That leaves us
with the question of how to differentiate core PMCs from HLL PMCs. I'm
not sure how to handle that, but that's what a spec is for.
Why is the differentiation necessary -- wouldn't core PMCs simply
be part of the 'parrot' HLL?
That's the place to put them. But how do you make the core PMCs
visible to the compiler and not to the user? I expect the Perl 6
compiler will want to use a ResizablePMCArray in places without making
it a builtin Perl 6 class. But how can you if there's only one new
opcode?
If we have a strict separation between the HLL namespace and the Parrot
namespace (and I think we should), then the only way instantiate a core
Parrot class/PMC from within an HLL is to first retrieve the 'parrot'
namespace, and preferably through the typed interface. Speculatively:
$P0 = get_root_namespace ['parrot']
$P1 = $P0.find_class('ResizablePMCArray')
$P2 = new $P1
$P2.INIT()
I think we have to keep in mind here that there will be a *lot* of
hand-written code that needs to create PMCs from the Parrot core. I
don't want to have to use the above snippet in all my hand written
code; it adds a lot of bulk and is a huge pain.
Patrick threw out the idea of letting .Type constants refer to core
PMCs. That's a reasonable idea, I think. It lets me create them easily
and doesn't get in the way of HLL classes. And I don't think there's
any way to get those constants to work with anything but core PMCs
anyway.
How Perl 6 (or some other HLL) chooses to distinguish loading a module
written in the same HLL from loading a module written in a different HLL
is an open question. It will need some syntax. One earlier proposal
suggested separating the HLL from the rest of the name with a single
colon ('python:NLTK-Lite::Parse::LamdaCalculus').
This is included in PDD21. Perl 6 will strip off the language, split
the module name and end up with a string (python) and an array
(['NLTK-Lite', 'Parse', 'LamdaCalculus']). It can use the string to
load the correct compiler (this is still unimplemented, by the way).
The compiler object it gets will take the array and load the
appropriate library (this is also unimplemented atm).
Perl 6 could presumably install the class into it's own HLL, which
makes instantiation easy.
--
Matt Diephouse
http://matt.diephouse.com
Re: classnames and HLL namespaces -- help!
Patrick R. Michaud [EMAIL PROTECTED] wrote: According to pdd21, each HLL gets its own hll_namespace. PGE is really a form of HLL compiler, so it should have its own hll_namespace, instead of using parrot's hll namespace: .HLL 'pge', '' I don't know that that's necessarily the case, but it's definitely an option. You can just as easily argue that it's a library. Now then, the 'PGE::' prefixes on the classnames were just implementation artifacts of working in a globally flat namespace -- as a high-level language PGE really ought to be referring to its classes as 'Match', 'Exp', 'Literal', etc. So, if we're in the PGE HLL, we ought to be able to drop the 'PGE::' prefix from our classnames and namespaces. So, here's the revised version of the code to create the classes: .HLL 'pge', '' .sub __onload :load $P0 = newclass 'Exp' $P0 = subclass 'Exp', 'Literal' $P0 = subclass 'Exp', 'Group' $P0 = subclass 'Exp', 'CGroup' $P0 = subclass 'Exp', 'Subrule' $P0 = subclass 'Exp', 'Closure' # ... .end This code fails when run from parrot, because Parrot seemingly already has a class named 'Closure': $ ./parrot ns.pir Class Closure already registered! current instr.: '__onload' pc 19 ( ns.pir:9) $ So, this brings me to my question: What is the official best practice pattern for HLLs to create their own classes such that we avoid naming conflicts with existing classes in Parrot and other HLLs? This is unspecced. ATM, all classes go into the 'parrot' HLL. This is a relic of the past and I think it needs to change. I'm pretty sure that HLL classes will have to go into the HLL's root namespace (this needs to happen anyway to prevent namespace pollution). That leaves us with the question of how to differentiate core PMCs from HLL PMCs. I'm not sure how to handle that, but that's what a spec is for. We discussed some of this briefly at the OSCON hackathon, when we talked about changing the class internals so that a Class isa Namespace. That discussion hasn't led to any changes yet as Chip has been kidnapped by his Real Life (tm). I think the object model needs a thorough going over in general -- for the reasons above and because it's an unproven system. I'm not convinced that it will handle all of Perl 6's needs as is. No serious OO language has been implemented yet on Parrot; everything up to this point has been either procedural or functional. -- Matt Diephouse http://matt.diephouse.com
Re: Re: classnames and HLL namespaces -- help!
Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
a relic of the past and I think it needs to change. I'm pretty sure
that HLL classes will have to go into the HLL's root namespace (this
needs to happen anyway to prevent namespace pollution). That leaves us
with the question of how to differentiate core PMCs from HLL PMCs. I'm
not sure how to handle that, but that's what a spec is for.
Why is the differentiation necessary -- wouldn't core PMCs simply
be part of the 'parrot' HLL?
That's the place to put them. But how do you make the core PMCs
visible to the compiler and not to the user? I expect the Perl 6
compiler will want to use a ResizablePMCArray in places without making
it a builtin Perl 6 class. But how can you if there's only one new
opcode?
Perhaps this will be clearer if I demonstrate with code. I imagine
that this Perl 6:
my $obj = Perl6Object.new()
will translate to something like this PIR:
.lex '$obj', $P0
$P0 = new 'Perl6Object' # do Perl6 classes have sigils?
$P0.INIT()
But that means if the user writes this Perl 6:
my $obj = ResizablePMCArray.new()
this PIR will be generated:
.lex '$obj', $P0
$P0 = new 'ResizablePMCArray' # oh no! this isn't an actual Perl6
class - it's namespace pollution!
$P0.INIT()
We need to somehow differentiate between Perl6Object and
ResizablePMCArray. Especially given the possibility that the user will
write this:
class ResizablePMCArray { ... }
Does that break the compiler when it tries to create a
ResizablePMCArray to use internally? Or die because there's already a
ResizablePMCArray class? Remember that no matter how much name
mangling you do in this case, there's probably a language that doesn't
want to do any.
This isn't too much different from using keyed class names like
['pge'; 'Closure'] like you guessed in your first email. But this
places classes next to their namespaces, which is a good thing. But we
probably do need keyed class names to support this:
class Foo::Bar { ... }
HTH,
--
Matt Diephouse
http://matt.diephouse.com
Re: Re: class interface of roles
Jonathan~ On 10/7/06, Jonathan Lang [EMAIL PROTECTED] wrote: TSa wrote: Dispatch depends on a partial ordering of roles. Could someone please give me an example to illustrate what is meant by partial ordering here? Sets demonstrate partial ordering. Let denote the subset relation ship. If A B and B C, then A C for any A, B, and C. However, it is not necessarily the case that A B, or B A, or B == A for any particular A and B. Thus transitivity is preserved, but there is not a guarantee of comparability between elements. http://en.wikipedia.org/wiki/Partial_ordering Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Re: FYI compiling PIR function calls
Allison Randal [EMAIL PROTECTED] wrote:
.local string abc
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
obj.{S0}() # call method indicated by S0
obj.$S0()# call method indicated by $S0
Having obj.abc() always mean obj.'abc'() seems to me like it's
most in line with what PIR-authors expect.
Yup.
Why not handle this like we handle subroutines? That is, why don't we
have a find_method opcode that returns a bound method? That simplifies
parsing for IMCC and makes PIR a little simpler.
obj.'abc'() # call 'abc' method of obj
obj.abc() # same as above
$P0 = find_method obj, abc # get bound method indicated by abc symbol
$P0() # actually call it
--
Matt Diephouse
http://matt.diephouse.com
Re: Re: RFC: Consolidate stack-unwinding code
Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Mon, 18 Sep 2006 11:53:36 +0200
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
The attached patch consolidates most of the existing stack-unwinding
code into Continuation:invoke; previously, RetContinuation:invoke and
find_exception_handler also did stack-unwinding, and none of the three
did it quite the same way.
Very good.
Thanks.
Unfortunately, this patch breaks Tcl. There seems to be some bug with
exceptions.
Here's the Tcl used for this example:
proc test {} {uplevel #0 {append}}
test
[uplevel] executes its argument in another scope. In this case, it's
executing [append] in the global scope. This [append] call will throw
an exception because it hasn't passed enough arguments. [uplevel]
catches the exception so it can restore the call stack and then
rethrows the exception.
The code for this can be found in
languages/tcl/runtime/builtin/uplevel.pir (the actual catch happens on
line 68). The .catch() and .rethrow() macros are defined in
languages/tcl/src/macros.pir.
What's actually happening when I run this code is that the [uplevel]
code restores the call stack and rethrows the exception... and then
somehow catches it again (this is the bug), which causes a
ResizablePMCArray can't pop from empty array error.
I tried to write up a small test case demonstrating what the problem
was, but none of my guesses of what's causing it were correct. I hope
I've given you enough information to fix it. If I haven't, let me know
what else I can provide.
Thanks,
--
Matt Diephouse
http://matt.diephouse.com
Re: Re: Re: RFC: Consolidate stack-unwinding code
Bob Rogers [EMAIL PROTECTED] wrote: Try the attached patch. If it works, then we have a problem, because here's the original comment (which I deleted) that went with this line of code: /* * During interpreter creation there is an initial context * and the context of :main, created by runops_fromc_args * Therefore, it seems, we have the main context twice * and an exception handler in main can catch the same * exception twich e.g. after rethrow * * The same problem can arise after a tailcall. * * So invalidate entry_type. */ But I can't see that either of these conditions could possibly apply here. So we have a mystery. Possibly this was hiding some other bug, which it would be better to identify and fix instead. Leo? That *does* work. I haven't applied it because it's not necessarily urgent that Tcl work in trunk. I'm okay with waiting a couple days to see if an actual fix can be found - instead of merely using a workaround. You can feel free to apply it yourself, of course. Thanks, -- Matt Diephouse http://matt.diephouse.com
Re: Re: Re: Re: RFC: Consolidate stack-unwinding code
Bob Rogers [EMAIL PROTECTED] wrote: From: Matt Diephouse [EMAIL PROTECTED] Date: Sat, 23 Sep 2006 20:21:32 -0400 Bob Rogers [EMAIL PROTECTED] wrote: Try the attached patch . . . That *does* work. I haven't applied it because it's not necessarily urgent that Tcl work in trunk. I'm okay with waiting a couple days to see if an actual fix can be found - instead of merely using a workaround. You can feel free to apply it yourself, of course. I have found the real problem, but I'm glad you tested my patch, because it gives me confidence that the real fix will work for you. So I've committed it as r14697; please let me know how it goes. That works great. Thanks! -- Matt Diephouse http://matt.diephouse.com
Re: Re: PMC Methods, Inheritance, and User-visible Classes
Joshua Juran [EMAIL PROTECTED] wrote: On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote: I would like to add some sort methods as well: quicksort(), mergesort(), etc. But as methods, there is potential for these to end up in a user-visible space. Say for example, that I add a mergesort method to AbstractPMCArray. Ruby's array class wouldn't be able to use AbstractPMCArray as a base class because there is no mergesort method on an Array in Ruby. Any thoughts? How about requiring array classes to implement swap(), and then implementing sort algorithms in terms of that, as in C++? Adding swap() would remove a level or two of indireciton, but this ignores the underlying problem of methods on PMCs leaking into user-visible spaces. -- Matt Diephouse http://matt.diephouse.com
Why does writing PMCs suck?
It's been said that writing PMCs sucks. This is your chance to tell the world why. Because for things to get better, we have to know what sucks. I'll get things started: 1) pmc2c.pl is very fragile - when it gets input it doesn't like, it just ignores it (see RT#39313) 2) You can't use :slurpy, :optional, or :named arguments. Even if there's support under the hood, there's no way to write a PMC with these arguments. -- Matt Diephouse http://matt.diephouse.com
PMC Methods, Inheritance, and User-visible Classes
I'm going to start working on an AbstractPMCArray PMC class that can provide some default array vtable functions for other PMCs to inherit. This will give array classes some functionality for free. AbstractPMCArray will implement splice, for example, which can be implemented using an array's external interface. I would like to add some sort methods as well: quicksort(), mergesort(), etc. But as methods, there is potential for these to end up in a user-visible space. Say for example, that I add a mergesort method to AbstractPMCArray. Ruby's array class wouldn't be able to use AbstractPMCArray as a base class because there is no mergesort method on an Array in Ruby. Tcl has it easy because there's no OO support (everything is a string, not an object). So we're mainly interested in adding methods that make our lives easier and don't have to worry about user-visible methods. And I can imagine that other compiler writers would want to use methods like these without having to expose them. One possible route is two implement two classes: an AbstractPMCArray class that only provides vtable functions and an AbstractPMCArrayWithMethods class that inherits from AbstractPMCArray and adds methods into the mix. But then there's also the question of how FixedPMCArray and ResizablePMCArray should behave. Should they have methods on them (which will be user-visible)? They do right now, but that's not correct if compiler writers are expected to use these as the basis for their array classes. Would these each need to be split into 2 classes as well? If so, we'd want to make multiple inheritance really work with PMCs. Any thoughts? -- Matt Diephouse http://matt.diephouse.com
Re: Re: Re: resizablepmcarray, assign.
Bob Rogers [EMAIL PROTECTED] wrote: FWIW, the Common Lisp system I'm writing takes a third tack. It defines a ParrotObject container associated with the name that refers indirectly to the current value. Of course, Common Lisp symbol objects are part of the language spec (and aliasing is not), so I have to at least make it look like I'm doing it this way. But indirection still seems more natural than morphing -- I don't have to worry about whether morphing will produce unintended side-effects. And the best thing is that I can do it all in PIR and Lisp. So when I said using PMCs as values rather than as containers, I really meant to suggest separating the container from the value. But I have no clue whether this would be easier than the other options. Okay, that makes much more sense. It's not ideal, especially for Tcl, but it does work. Technically, any time we use something other than a TclString PMC it's an optimization. After looking at the code in the Array, Scalar, and String PMCs, I've managed to get things working to my satisfaction using an iterate-and-copy method for array-like objects and morphing for Strings (and soon for other types as well). So if anyone ever finds himself or herself in the same position, a look at TclList's (languages/tcl/src/pmc/tcllist.pmc) assign_pmc method would probably be in order. -- Matt Diephouse http://matt.diephouse.com
Re: Re: a premature optimization
Will Coleda [EMAIL PROTECTED] wrote: On Aug 6, 2006, at 4:08 PM, Leopold Toetsch wrote: invalid_1559: .local pmc interactive interactive = get_root_global ['tcl'], '$tcl_interactive' # you might cache that once - it's probably used in zillion of places This is a user visible variable that could theoretically change anywhere, so any caching scheme has to take that into account. It should work to just find this once. Since we (have to) use assign for variables, any changes that happen happen to the actual PMC. So caching this is fine. Also, we can cache the 'tcl' and '_tcl' namespaces to prevent that key lookup when we're looking for globals. I'll look at doing that. unless interactive goto err_command1559 .local pmc unk unk=find_global 'unknown' # same here and just do ... 'unknown'(...) ... call it instead of ... unk($P1566, $P1560, $P1561, $P1563) my 2 c leo I'll investigate just using the 'foreach'() syntax in both cases, and there's probably some wins there. Except this only works when the user is in the root HLL namespace or when the user is executing code in the current namespace. That doesn't mean it's not a valid option; just that it's not always valid. -- Matt Diephouse http://matt.diephouse.com
Re: Re: resizablepmcarray, assign.
Bob Rogers [EMAIL PROTECTED] wrote: I finally found the definition of __set (my tagfile-building recipe was deficient), and, on a hunch, made the tweak shown below, with the following result: [EMAIL PROTECTED] ../../parrot tcl.pbc -e 'set a [list a b]; set x $a; set a b; puts $a; puts $x' b a b [EMAIL PROTECTED] This tweak may break other stuff (I didn't check), so take it with a grain of salt. However, this may be a hint that you are better off using PMCs as values rather than as containers. HTH, Right. So what you did was change Tcl so that we no longer use the assign opcode. This fixes this error, but causes a handful of other ones. AFAICT, we have to use assign so that we don't break aliasing (which is rather important). If you have the same variable in two different scopes -- or under two different names -- merely replacing one of those variables with a new PMC (using PMCs as values) won't change the other variable. You have to use assign to morph the PMC into the new type. Among other things, this will break Tcl's [global] and [variable] commands and it isn't really a viable solution. PMCs *are* containers; they're designed that way. This leaves two options: 1) Fixing the set_pmc vtable method for TclList and/or ResizablePMCArray and FixedPMCArray 2) Using a hybrid list/string PMC that behaves in a similar way to Perl 5's scalars Option 1 is preferable, IMO, if it's doable. But it's a little out of my reach as far as C goes, unfortunately. Otherwise I'd have fixed it already. :-) Thanks for taking a look at this. -- Matt Diephouse http://matt.diephouse.com
Re: RE: wiki
I'll be honest, I was willing to put in some effort for something substantial and original, but I'm not too keen on just remaking or porting an old solution. M.T.
Re: RE: wiki
IMHO, this isn't a matter of either-or, but of concurrent development along 2 related tracks: You're right, it doesn't have to be either-or. [snip] It would be good to have (1) ASAP. There's no reason that people who are interested in (2) have to be interested in (1) or vice versa. I agree that this makes sense, and if you did this it wouldn't be a problem whatsoever. However, I think that, with rapid prototyping and whatnot, we can actually get an original, minimal, working wiki, and build from there. The database design will go together quickly, some kind of architecture can go up quickly (scaffolding, if you will), and then development on the most important, essential parts will come first. Then, as the wiki is being used concurrently with the development of it, you have a good deal of immediate feedback on what's wrong and what needs to be changed. But, really, that's my idea of how it should be done: I am neither the one with the money, nor the one capable of doing it all on my own. I just really loathe the idea of having to go from the one to the next, when the latter will do what we need just as well with a little bit of effort. It's important to start the project with a certain goal for quality, but doing it rapidly. But, as of right now, nobody's really been thinking the same (or those that have haven't spoken up) so I can't get a community moving on it just yet. And, personally, I've been pretty swamped with work so learning Perl6 has been on the backburner (along with Haskell and Scheme, unfortunately). M.T.
Re: [svn:parrot-pdd] r13740 - in trunk: . docs/pdds
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: allison Date: Tue Aug 1 13:00:29 2006 New Revision: 13740 Modified: trunk/docs/pdds/pdd21_namespaces.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Namespace opcodes now accept arrays to select multidimensional namespaces again. The namespace object methods for setting/retrieving namespaces and globals are eliminated as redundant. How does this handle the case where namespaces have a sigil or some other sort of name mangling? Aren't the get/set namespace methods an essential part of the typed interface? -- Matt Diephouse http://matt.diephouse.com
Re: Re: Checkin #13345
chromatic [EMAIL PROTECTED] wrote:
On Tuesday 18 July 2006 19:43, Matt Diephouse wrote:
I know I'm a little late to the game here, but in the future it would
be useful to mention this sort of info in a comment in the source. :-)
And a comment might be a nice addition even now.
(You mentioned being more clear in the svn log, but a comment would
really be the most useful.)
Something like this?
This is what I ended up applying (inlined because it's already ci'd).
I wanted to get more into why having -o means that we can't tell what
the user forgot to pass. (And having not written any of the code, I
could tell what wasn't immediately clear :-)
--
matt diephouse
http://matt.diephouse.com
--- compilers/imcc/main.c (revision 13376)
+++ compilers/imcc/main.c (working copy)
@@ -368,8 +368,17 @@
usage(stderr);
exit(EX_USAGE);
}
-/* reached the end of the option list and consumed all of argv */
+/* if we reached the end of the option list and consumed all of argv,
+ * we don't have the name of a program to run */
if (*argc == opt.opt_index ) {
+
+/* If the user passed the -o flag -- the only flag that must take a
+ * parameter -- then we can't be sure that the user forgot the name of
+ * the program. it could be that the user forgot to give the argument
+ * for -o and the rest of argv got slurped up as flags. (If -o appeared
+ * with no argument, the getopt check would have complained earlier.)
+ *
+ * Given that, this was the best error message we could come up with */
if (interp-output_file) {
fprintf(stderr, Missing program name or argument for -o\n);
}
Re: Checkin #13345
chromatic [EMAIL PROTECTED] wrote: ... provides quite misleading results: $ parrot -o file.pir Option file.pir expects an argument parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] file I don't believe there's a working heuristic for guessing which parameter the user failed to provide. That's why I didn't write the original version that way. I know I'm a little late to the game here, but in the future it would be useful to mention this sort of info in a comment in the source. :-) And a comment might be a nice addition even now. (You mentioned being more clear in the svn log, but a comment would really be the most useful.) -- Matt Diephouse http://matt.diephouse.com
[perl #39778] Segfault when using a Namespace with an Iterator
mdiep wrote: Trying to use an Iterator with a NameSpace makes Parrot segfault: mini:~/Projects/parrot mdiep$ cat test.pir .sub main :main .local pmc iter, ns ns = get_namespace iter = new .Iterator, ns loop: unless iter goto loop_end $P0 = shift iter $S0 = $P0 print $S0 print \n goto loop loop_end: end .end mini:~/Projects/parrot mdiep$ parrot test.pir Segmentation fault mini:~/Projects/parrot mdiep$ FYI, changing C $P0 = shift iter to C $S0 = shift iter makes this example work corrrectly (of course, you also have to remove C $S0 = $P0 ). -- Matt Diephouse
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Patrick R. Michaud [EMAIL PROTECTED] wrote: On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote: On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote: On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote: Relative is the usual apposite to absolute, but we have a three-way logic here, so appositives don't really work. I think that hll is the best I can think of, and given the existing .HLL directive, its meaning is immediately clear: .HLL 'perl5', perl5_group .namespace ['Foo'] $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x'] $P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x'] $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x'] What's the status on the above...has it been blessed/implemented yet? This looks to me like exactly what is needed/desired for the various HLL's I'm working with. Allison has blessed it except for the detail of the _hll_ in the HLL selection. I haven't started implementing it yet, though nothing stands in my way technically. I've suggested that get_namespace follow exactly the same pattern, but so far she hasn't commented on that suggestion at all. I really like both of these suggestions. We also noted on #parrot that get_hll_global would really simplify things for the Tcl folks, which currently go through a macro to achieve the same effect. You mean get_abs_global, actually. The proposed get_hll_global opcode mirrors the existing find_global exactly. :-) -- matt diephouse http://matt.diephouse.com
Re: Re: [perl #39777] Large Subroutine Segfaults IMCC
Vishal Soni [EMAIL PROTECTED] wrote: Hi Matt, This patch is because the number of .constant decls in IMCC is limited to 4096. This is a todo to make this dynamic. The evil code seems to have about 4200 .constant decls being generated. Here is the patch to fix it. For now I bumped up the limit to 8192 and it works. But this is a TODO for sure. Thanks for investigating this, Vishal. Coke mentioned on IRC that he had bumped this number up once before. I'll change the ticket in RT to document the real problem. In the meantime, would it be possible to die with an error saying too many .constants instead of just segfaulting? Thanks again, -- matt diephouse http://matt.diephouse.com
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg [EMAIL PROTECTED] wrote:
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
found. (particle++ for the finding) }
chip++ :-)
On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
Agreed, with a note of balance that we also want to avoid the pain of
XS. Sometimes you need to poke into the guts of the system, and when you
do, you want it to be pleasant to work with, even though it's not fancy.
Point well taken. Pain is acceptable but not a goal.
Good points.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
This is non-evil. :)
grin/
I would rename 'get_cur_global' to 'get_global'. The selected namespace
indicates that most of the code belongs in that namespace, so it's
likely that most of the variables do too. (There are variations, but
that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
Works for me too. I'm not sure that I like the rename (I can't
decide), but the name itself doesn't matter much. The new opcodes (the
presence of get_cur_global) may actually make things easier for Tcl if
we ever compile to 100% inlined PIR.
This is a different route than I was trying to take us, but it should
be almost functionally equivalent, so I'm happy with it.
--
matt diephouse
http://matt.diephouse.com
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Allison Randal [EMAIL PROTECTED] wrote: Chip Salzenberg wrote: --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED -- On the other hand, we could extend the key PMC to represent emptiness, i.e. zero dimensions. This seems useful for namespaces and could even prove useful for real keys. And this makes keys even more compatible with the Array interface, which I think they might need to implement someday anyway. Allison, what do you think of zero-length keys, i.e. having [] construct a Key PMC describing no dimensions of lookup? If we use those we can get rid of the current null-string hack. Fundamentally altering the way keyed access works seems like a pretty extreme solution when the problem is just the root HLL namespace doesn't have a name. (Actually, it does have a name: 'parrot', 'tcl', 'perl6', etc. A sort of key who must not be named, if I won't be shot for making terrible Harry Potter references at 1am.) I don't think fundamentally altering the way keyed access works is a fair description of what Chip proposed (and what I was asking for). 0-dimensional keys seem like a logical extension to multi-dimensional keys, IMO. Chip actually forgot that there is another way to get to the root HLL namespace besides using the null string hack: $P0 = new .ResizablePMCArray # this can be any array type $P1 = get_namespace $P0 But arrays fill a different niche than keys do. Arrays are a runtime solution and keys are a compile time solution. Writing out arrays when you're writing code is painful and making keys at runtime is impossible AFAICT. So for the runtime (this is the HLL runtime, not the PIR runtime, btw) we're all set. Arrays fill the need perfectly and let us access the root HLL namespace. That makes me think that we don't need any new opcodes. It's just the compile time time -- the code that humans actually have to write -- that is giving us trouble. That's a bit of a simplification because in many cases compiler writers can optimize the code and use keyed access in the output code, but it's just as simple in that case to use any old hack. That's why I was asking for C $P0 = get_namespace [] -- because I actually have to write it. And I think it's a worthy goal to make compiler writer's lives good. Adding 0-dimensional keys would also let us get rid of the C .namespace special case and replace it with C .namespace [] . It's simpler to give the root HLL namespace a name. I disagree on two counts here. First, I think C [] *is* a name. Second, any solution which involves giving the HLL namespace a different name will have to either (a) add new opcodes, (b) add more code for all the other cases by making all referencing originate at the root, or (c) add a special syntax, none of which is simple. -- matt diephouse http://matt.diephouse.com
Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: On Sat, Jul 01, 2006 at 12:22:56AM -0700, [EMAIL PROTECTED] wrote: Another FAILING namespace test: $P0 = new .ResizableStringArray $P0[0] = '' $P1 = get_namespace $P0 I think I (or the pdd) may have been misunderstood: The get_namespace opcode currently accepts keys (and strings). The compiler.'get_namespace'() method accepts arrays. So unless I've missed something in the purpose of your test, it's testing behavior that Parrot isn't trying to provide. At the top of the pdd: - Add a get_namespace opcode (that takes an --array-- or a multidimensional hash index) A bit further down: =item $P0 = get_namespace $P1 =item $P0 = get_namespace Get the namespace $P1 (an --array-- of names or a multidimensional hash index) or the current namespace. To get the Foo::Bar namespace, one would use this: $P0 = split ::, Foo::Bar $P1 = get_namespace $P0 It's definitely in the pdd; even the example here uses arrays (not too surprising, since I wrote it. ;-). Arrays are the easiest way to be able to get a namespace at runtime... which translates to the easiest way for Tcl to use namespaces. -- matt diephouse http://matt.diephouse.com
Re: Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. It looks like IMCC treats C .namespace [''] as the root HLL namespace (and not as the namespace '' inside of that). So that's where the bug really lies. mini:~/Projects/parrot mdiep$ cat test.pir .namespace [''] .sub main :main $P0 = get_namespace $P0 = $P0.'name'() $S0 = join ::, $P0 print $S0 print \n end .end mini:~/Projects/parrot mdiep$ parrot test.pir parrot mini:~/Projects/parrot mdiep$ -- matt diephouse http://matt.diephouse.com
Re: Re: Re: test of get_namespace opcode vs. arrays
Chip Salzenberg [EMAIL PROTECTED] wrote: I've rooted out that bug, but then discovered there's no way left to designate the root HLL namespace, so I've invented .namespace # no key to mean the HLL root. That resolves the other ticket I opened yesterday (good). But I'd prefer to have C .namespace [] so that we could also have the matching C find_global [], 'foo' . Otherwise find_global becomes a two step operation for finding globals in the root HLL namespace. Oh, and I've committed some more failing tests. :-) -- matt diephouse http://matt.diephouse.com
Re: Re: Namespaces Redux
Chip Salzenberg [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote: The get_namespace opcode gets namespaces from the root namespace. Should it get namespaces from the HLL namespace instead? The PDD isn't explicit either way [...] It is, actually: =head2 Namespace Opcodes Note that all namespace opcodes operate from the local HLL root namespace. Navigating outside one's own HLL namespace requires either the Cinterpinfo .INTERPINFO_NAMESPACE_ROOT opcode or the get_namespace() compiler PMC method. All namespace opcodes. Dunno how I missed that. But that is very good news. Is there any reason that [...; ''] and [...] couldn't refer to the same namespace? The design as it stands avoids any special meaning for *any* string. Any string whatsoever is a valid key; any valid key is a valid namespace name. This is a design goal that would be compromised by the '' special case. Tcl uses C .namespace [''] to refer to the root namespace (correctly, I think) and I can't think of any language that would want to differentiate between the two. All you need to disprove this speculation is one counterexample, and the counterexample doesn't even have to exist yet. Fair enough. But one question remains: how do you tell IMCC that you want to be in the root HLL namespace? C .namespace [] is a parse error. Also, is there any reason we can't/shouldn't add find_global variants that lookup globals in HLL's? Right now we have find_global_p_p_s. Adding find_global_p_s_p_s would let me reach into Tcl's private very easily instead of having to crawl the namespaces myself. It's three steps rather than one, but it's not crawling, and it's already in the pdd, mostly: .local pmc tcl tcl = compreg tcl .local pmc ns ns = tcl.'get_namespace'(['Foo';'Bar']) I'm cheating a little here because I'm showing you an example with a key (which the docs don't specifically allow) rather than an array (which they do allow), but the point is to demonstrate compiler.get_namespace(). This doesn't work for *private* namespaces -- only public ones. ParTcl currently uses a macro to crawl its private namespaces, which AFAIK is the *only* way to access the helper subs it has in private namespaces. Thanks, -- matt diephouse http://matt.diephouse.com
Namespaces Redux
I've started implementing namespace support in Tcl this week (yay!). But I've run into a bit of trouble, so I have a couple questions: The get_namespace opcode gets namespaces from the root namespace. Should it get namespaces from the HLL namespace instead? The PDD isn't explicit either way, but the usage I had in mind works better if it works from the HLL namespace. I've added a failing test that tries to get a namespace from the HLL. Is there any reason that [...; ''] and [...] couldn't refer to the same namespace? Tcl uses C .namespace [''] to refer to the root namespace (correctly, I think) and I can't think of any language that would want to differentiate between the two. It would simplify code generation for Tcl to have '' act like this. Here's some Perl that models what I'm trying to write for Tcl in PIR: my $command = ...; my @namespace = split /::+/, $command; $name = pop @namespace; my $namespace = get_namespace(@namespace); my $sub = find_global($namespace, $name); $sub-(); Without the changes, I'll have to unshift 'tcl' to the front of every array I use to lookup namespaces, as well as check for empty strings (consider the input ::puts, which should refer to the puts global in the '' namespace). It's a lot of code that's not really necessary. Also, is there any reason we can't/shouldn't add find_global variants that lookup globals in HLL's? Right now we have find_global_p_p_s. Adding find_global_p_s_p_s would let me reach into Tcl's private very easily instead of having to crawl the namespaces myself. $P0 = find_global '_tcl', ['Foo'; 'Bar'], baz Thanks, -- matt diephouse http://matt.diephouse.com
Re: [perl #39597] Problems with string constants in method calls
via RT Matt Diephouse [EMAIL PROTECTED] wrote: # New Ticket Created by Matt Diephouse # Please include the string: [perl #39597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39597 The following code in lines 108-110 of languages/tcl/src/class/ tclcommand.pir are giving parrot some trouble: inlined.emit( if epoch != %0 goto dynamic_%1, epoch, label_num) inlined .= retval inlined.emit( goto end_%0, label_num) It looks like pbc_merge is the actual source of the trouble here. If I change languages/tcl/src/tclsh.pir to load the individual bytecode files instead of the merged file, it works as expected. -- matt diephouse http://matt.diephouse.com
Re: lexical lookup and OUTER::
jerry gay [EMAIL PROTECTED] wrote: audreyt++ pointed out on #parrot that there doesn't seem to be a way to specify where to start finding lexicals, in support of perl's OUTER::. eg. (from S04): my $x = $OUTER::x; or my $x = OUTER::$x; i propose this should be specified using a three-arg form of find_lex find_lex_p_s_i where the third parameter is an integer specifying which level in the lexical chain to start the lookup. While you can't do this with find_lex currently, you *can* do it. Tcl walks the lexpads to find lexicals. (See languages/tcl/runtime/variables.pir): .sub find_lex_pdd20 .param string variable_name .local pmc interp, lexpad, variable .local int depth interp = getinterp depth = 2 # we know it's not us or our direct caller. get_lexpad: # Is there a lexpad at this depth? lexpad = interp[lexpad;depth] unless_null lexpad, got_lexpad # try again inc depth goto get_lexpad got_lexpad: variable = lexpad[variable_name] .return(variable) .end Of course, that doesn't mean that I wouldn't like an opcode to do it for me. :-) -- matt diephouse http://matt.diephouse.com
Re: Name of this wiki
A simple, if naive fix could be to make the logo a phonetic representation (or whatever it's called). Just a simple pseudo-solution. M.T.
Re: Name of this wiki
I really like these. I think you're on to something. I'm definitely in favor of Momi Wiki, or just Momi. Maybe we can even be very corny and call it 'Aloha Wiki'... Hmm. Yes, Bikini Wiki sounds sexy. I like how they both 'lie' in the pacific ocean... as opposed to being worn... ;) M.T.
Re: Perl++ Wikicosm (was: OT: wiki engine architecture)
I'll be honest and say that I'm not too concerned with the prize/grant, so that may be the reason I want to go beyond that minimal ideal. I'm specifically concerned with a poorly designed (or at least slightly clumsy to upgrade) wiki, all in for the sake of speed, minimal functionality, and money. At least, it has the potential to become this very quickly. Like I said, I'm not concerned with the monies: I'd be happy to work with the community on a well-designed, well-developed modular system. (Therefore, it may well be more appropriate to create a new thread?) Then again, I'm not proposing something obscenely complex, either. I've developed an MVC framework similar to what I've described here in PHP5 and I know implementation of the (pseduo) framework part can be done quickly. In retrospect, I think my biggest thought here is on going ahead and getting the interfaces established, interconnecting the pieces. Yes, this is definitely development-centric as my role serves best for. I'm just having a hard time thinking that a goal like quickly-as-possible can coexist with to-be-used-thereafter without a great deal of (violent) refactoring. My goal in that was to keep that from happening. I hope I've addressed something close to what you were saying. Hopefully we (I, really) can get back on topic! :D Now, to the requirements talk: how important is the availability of revision history in this bare-bones wiki? Text formatting is important (if relatively easy to hook up), but is being discussed, implementation-wise. What kind of authorship and administration would you (the granter or whomever, really) prefer? Every writer must have an account? Are there any accounts other than an administrator? I won't even get into admins, moderators, readers, editors, etc. How about RSS feeds (which is usually more appropriate for versioned pages, et al, but is useful even for recently-updated pages)? Do you want it to work with the concept of pages/topics or is there another way you want to represent the data? What kind of categorization do you want to support? What kind of control do you want over the visual aspects (CSS, HTML, et al)? Did you have something in mind other than a web administration interface? What kind of moderation privileges would you like? What basic actions do you want to perform for a page (or whatever)? That's a lot to answer, I know. Think of it as a good example of the stuff that needs to be thought about (even if not implemented). M.T.
Re: Perl++ Wikicosm (was: OT: wiki engine architecture)
1) Understood. I've been disconnected from Perl for a while, and this is really the first time I've been participating in the Perl community. Thanks for the heads-up. :) 2) I agree that it is both important and pertinent to get the general requirements down for the project, but I do see a need and a benefit to having the architecture forming in the meanwhile. I see how these things can be connected, obviously, but with a fairly flexible architecture it can be easy to expand or change it as needed. If we have the skeletal system in place, we can add the muscle and the skin on as needed. [Read more of my comments below.] 3) I'll be honest and say that I'm not a big fan of the 'Wikicosm' part, but the Perl++ part works for me. I particiularly like simple names. Maybe we could go with something distinctive, much like 'Joomla' is or 'Drupal', etc. Something different, and not nearly as explicit. Mainly speaking on point number 2 again, I agree that we need to be discussing and deciding on the minimal features, but this is does not mean that the architecture should be poorly designed. Even with a weakly implemented yet well designed base, it would be easier to take this minimal wiki and upgrade it into something very powerful. I guess what my very first recommendation (before even a name) is that we have a flexible, well-designed archiecture, preferrably with an MVC pattern, with RESTful-like (URL) mapping, etc. I believe that this will be integral to the successful adoption in the community because it allows for very expansive modification. I will be looking over some other features to recommend. Wherein shall we officially submit our recommendations? Here? And is there a specific way to do so? (This is more of a conversation-generating question.) M.T.
Re: OT: wiki engine architecture (was: $1,000 prize for Perl 6 Wiki written in Perl 6)
I would recommend using a templating system as opposed to having calls to include files in numerous pages. Even though it's minimal, it's still duplication, and it can get rather messy. I know that some people don't know about or don't like it, but I would recommend setting things up in a Model-View-Controller pattern, partially to approach the templating thing. If we sequester the database-specific stuff from the templating-specific stuff and the primary logic, it provides for a more orthogonal system. However, MVC is just one solution. I'm open to others. Regardless, though, I know we need to find a structure that inherently works well in modular development with a big (if somewhat disparate) team. Also, what is the best place to begin learning the Perl6 syntax? A tutorial would be great, as a dry technical specification of the language doesn't teach very well. M.T.
Re: OT: wiki engine architecture
I was just reading the AES referenced above and I can say now that I'm really happy about some changes to Regexes, and that a grammar may well be what we're looking for. However, even with this great tool, we still have to handle the implementation. Though I can see the benefit of using the grammar, the problem is still which syntax to use, and then having to define the syntax in grammars. I can definitely see it as an eventuality, possibly a necessity, but it doesn't solve the problem at hand of _which formatting syntax to use_. Then again, this is only a facet of the whole thing. There still is the persistence layer, the architecture, and a myriad of other problems. Maybe this would be a good time to (semi-)formalize some form of recommendations for the project? M.T. P.S. -- MVC, I think, is the way to go.
Re: OT: wiki engine architecture
Honestly, I'm not familiar with the Perl way of doing things, but I'm open to learn especially because I see the Perl community going through a (much-needed) reform. Thusly, I'm not familiar with the RFCs (Request For Change?) but I do see the merit for something similar. However, as far as the judge is concerned, I don't think that it could work any other way than having a dialog on each RFC (or otherwise). A general concensus must be reached for each proposal. A wiki or some form thereof should be set up for everyone to have a place to submit RFCs and also as a source to find out the decisions on those RFCs. Indeed, depending on the Wiki used, discussion for the RFC could be held on there, though I like using the list-serv (as discussion is its sole purpose). In summary, we the community will need to both make the proposals and collectively decide (by matter of majority vote or something to that effect). If someone could briefly describe the aspects of an RFC, that would help clear things up in my mind and give us some kind of standard. As an aside, I'm coming from the PHP community which has left a very bad taste in my mouth. The community and the project itself is stale and not open to change (they're cheering about adding Unicode support as their big new feature for version 6, which is great, but pathetic at the same time). However, I'm also partly in the Ruby community, and I feel quite at home there. I'm hoping to get into Perl again. I've not used it since version 4! M.T. P.S. -- I'm working on a proposal (of sorts) for the beginning of the architecture.
Re: OT: wiki engine architecture
[Sorry Michael, I didn't mean to send it you twice. :) ] I like the RFC idea. I will read up on them and see, if it is a particular format, how to simplify it. But, most definitely, the community must have dialog about the requests. For each request really. On the architecture note, I've written up a quick article about a possible implementation of the MVC pattern for the wiki. Indeed, it's a very flexible implementation and really resembles a framework. (To be honest, it's from my work on my PHP framework.) Please take a moment to look through it and let me know what you folks think. It's not meant to be anything other than a starting point, if for nothing else then for discussion. http://www.maraby.com/lang/perl6/wiki/architecture.html Again, let me know what you think. M.T.
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Iraq invasion indeed wait, shouldn't go there. I particularly like the syntax of Textile or even Markdown (preferring the former). In Ruby-land, these exist as RedCloth and BlueCloth. I understand porting isn't fun, but I think that this is a viable option, if not a great choice. Not that this is a great example, but Instiki uses the Textile/RedCloth syntax for textual formatting. As an aside, I must apologize for interrupting in a conversation that I've only been privileged to see the last four responses. I'm extremely interested in learning Perl6 and in particular seeing this Wiki come to fruition (if not participating myself). Thought I'd offer up my suggestion about syntax. I'll wait on participating more until I've read more of what's already been said. M.T.
Re: OT: my wiki syntax is better than yours (was: $1,000 prize for Perl 6 Wiki written in Perl 6)
There are alternatives to using tables for side-by-side using paragraphs. Simply having one cell for each line, for instance, allows for highlighting green the added lines and red the removed ones, etc. Also realize that it is not necessarily the duty of Textile (et al) to handle that aspect beyond text formatting. A diff or history-revision view goes beyond the context of the tool. Lastly, I'm not sure paragraphs belong in table cells. You could certainly argue that a paragraph could full well be tabular data, but I find it hard to believe that it fits the bill. (This is speaking on an XHTML 1.0 Strict basis.) So, in that regard, I don't believe that this is an issue. The real reason to use Textile (for instance) is the natural ease of using it for most things we need. Just a thought. M.T.
