Re: [perl #38914] perl Configure.pl fails on Mac OS X 10.4.6 on Intel iMac
Will --
I closed the ticket right after filing it.
False alarm on my new iMac -- I forgot to install the dev tools, and
was too quick on
the trigger for the ticket.
Regards,
-- Gregor
On Apr 14, 2006, at 12:42 PM, Will Coleda via RT wrote:
What does
% gcc -v
say?
On Apr 13, 2006, at 10:32 PM, Gregor N.Purdy (via RT) wrote:
# New Ticket Created by Gregor N. Purdy
# Please include the string: [perl #38914]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38914 >
$ perl Configure.pl
Parrot Version 0.4.3 Configure 2.0
Copyright (C) 2001-2006 The Perl Foundation. All Rights Reserved.
Hello, I'm Configure. My job is to poke and prod your system to
figure out
how to build Parrot. The process is completely automated, unless you
passed in
the `--ask' flag on the command line, in which case it'll prompt you
for a few
pieces of info.
Since you're running this script, you obviously have Perl 5--I'll be
pulling
some defaults from its configuration.
Checking
MANIFEST.done.
Setting up Configure's default
values.done.
Tweaking settings for
miniparrot...skipped.
Loading platform and local hints
filesdone.
Determining nongenerated header
files.done.
Determining what C compiler and linker to
use.done.
Determining whether make is
installed...no.
Determining whether lex is
installed...skipped.
Determining whether yacc is
installed..skipped.
Determining if your C compiler is actually gcc...
step auto::gcc died during execution: C compiler failed (see
test.cco) at lib/Parrot/Configure/Step.pm line 362
Parrot::Configure::Step::cc_build() called at config/auto/
gcc.pm line 36
auto::gcc::runstep('auto::gcc=HASH(0x8cde0)',
'Parrot::Configure=HASH(0x182bdc0)') called at lib/Parrot/
Configure.pm line 239
eval {...} called at lib/Parrot/Configure.pm line 235
Parrot::Configure::runsteps('Parrot::Configure=HASH
(0x182bdc0)') called at Configure.pl line 442
at Configure.pl line 442
r$ uname -a
Darwin Family.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar 7
16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
r$
Re: More registers
Leo -- I had posted a program a while ago that generates large fake programs for testing such things. Did that not help? I think I still have it in my working directory if you'd like to have a peek at it... Regards, -- Gregor Dan Sugalski wrote: At 12:05 PM +0200 4/13/05, Leopold Toetsch wrote: As of rev 7824 Parrot *should* run with NUM_REGISTERS defined as 64 too. Only some stack tests are failing that do half frame push and pop tests. imcc/t/reg/spill_2 just spills 4 registers instead of 36. Dan, could you please try that with one of your big subroutines and report compile times and functionality. Sure. I'll sync up and give it a shot.
Re: Subversion?
I think Parrot is already about subversion. All your interpreter are belong to us. Ron Blaschke wrote: Just curious. Are there any plans moving parrot to subversion? Ron
Pathological Register Allocation Test Generator
Dan et al. --
I made a new version of the script that creates gen.cpp and gen.imc
(attached). You can run it like this:
perl gen-pra.pl 1000 1
(for 1000 labels and 1 variables) and it will create equivalent
gen.imc and gen.cpp files. You can test-compile them with these
commands:
g++ -c gen.cpp
and
imcc -o x.x gen.imc
on my system, the g++ compiler does eventually finish, but the imcc
compiler is eventually killed.
Maybe this could be used to drive out the underlying problems that
are keeping parrot from compiling Dan's really large subs?
Regards,
-- Gregor
Gregor N. Purdy wrote:
Dan --
Something like this for the .imc generation?
Regards,
-- Gregor
--- snip: gen-imc.pl --
#!/usr/bin/perl -w
use strict;
die "Usage: $0 \n"
unless @ARGV == 2;
my ($total_labels, $total_locals) = @ARGV;
my $labels_so_far = 0;
my $locals_so_far = 0;
print ".sub __MAIN\n\n";
while ($labels_so_far < $total_labels or $locals_so_far < $total_locals) {
my $action = qw(label local arithmetic control)[rand 4];
if ($action eq 'label' and $labels_so_far < $total_labels) {
printf "\n_L_%d:\n", ++$labels_so_far;
}
elsif ($action eq 'local' and $locals_so_far < $total_locals) {
printf " .local int V_%d\n", ++$locals_so_far;
printf " V_%d = %d\n", $locals_so_far, int(rand()) + 1;
}
elsif ($action eq 'arithmetic' and $locals_so_far > 0) {
my $result = 1 + rand $locals_so_far;
my $arg1 = 1 + rand $locals_so_far;
my $arg2 = 1 + rand $locals_so_far;
my $op = qw( + - * )[rand 3];
printf " V_%d = V_%d %s V_%d\n", $result, $arg1, $op, $arg2;
}
elsif ($action eq 'control' and $locals_so_far > 0) {
my $dest = 1 + rand $total_labels;
my $arg1 = 1 + rand $locals_so_far;
my $arg2 = 1 + rand $locals_so_far;
my $op = qw( < <= == != >= > )[rand 6];
printf " if V_%d %s V_%d goto _L_%d\n", $arg1, $op, $arg2, $dest;
}
}
print "\n";
print ".end\n";
print "\n";
exit 0;
- snip
Dan Sugalski wrote:
At 6:50 AM -0700 8/30/04, Gregor N. Purdy wrote:
Dan --
I figured. We could probably write a code-generator that used a PRNG
to generate massive amounts of stereotypical code, spitting out C and
PIR...
That would be easy if it was a bunch of
x = x + y
z = 3 * x
lines that would approximate the structure of your large stuff. Is it
much more complicated than that?
Oh, yeah. :) Or, rather, no, if you factor in the second simple bit,
the massive number of labels and comparisons. Add those into the mix
and I think you'd have it.
-- Gregor
Dan Sugalski wrote:
At 6:46 AM -0700 8/27/04, Gregor N. Purdy wrote:
Dan --
I think it would be interesting to find out how, say, gcc
behaves on the pathological code structures you've run into.
Could your compiler spit out a structurally (although not
semantically! :) equivalent piece of C code that could be
used with a C compiler to see how we do vs. C compilers in
these cases?
That's a good question. While it's not impossible, I'd need to do a
bunch of work on the compiler to get it to emit compilable C instead
of PIR, and I don't think it's something I'll have time for anytime
soon. :(
#!/usr/bin/perl -w
use strict;
die "Usage: $0 \n"
unless @ARGV == 2;
my ($total_labels, $total_locals) = @ARGV;
my $labels_so_far = 0;
my $locals_so_far = 0;
open IMC, ">gen.imc";
open CPP, ">gen.cpp";
print IMC ".sub __MAIN\n\n";
print CPP "int main(int argc, char * arg[])\n{\n";
while ($labels_so_far < $total_labels or $locals_so_far < $total_locals) {
my $action = qw(label local arithmetic control)[int(rand(4))];
if ($action eq 'label' and $labels_so_far < $total_labels) {
my $this_label = ++$labels_so_far;
printf IMC "\n_L_%d:\n", $this_label;
printf CPP "\n_L_%d:\n", $this_label;
}
elsif ($action eq 'local' and $locals_so_far < $total_locals) {
my $this_local = ++$locals_so_far;
my $this_value = int(rand(99)) + 1;
printf IMC " .local int V_%d\n", $this_local;
printf IMC " V_%d = %d\n", $this_local, $this_value;
printf CPP " int V_%d;\n", $this_local;
printf CPP " V_%d = %d;\n", $this_local, $this_value;
}
elsif ($action eq 'arithmetic' and $locals_so_far > 0) {
my $result = 1 + int(rand($locals_so_far));
my $arg1 = 1 + int(rand($locals_so_far));
my $arg2 = 1 + int(rand($locals_so_far));
my $op = qw( + - * )[rand 3];
printf IMC " V_%d = V_%d %s V_%d\n", $result, $arg1, $op, $arg2;
printf CPP " V_%d = V_%d %s V_%d;\n", $result, $arg1, $op, $arg2
Re: Pathological Register Allocation Scenarios
Dan --
Something like this for the .imc generation?
Regards,
-- Gregor
--- snip: gen-imc.pl --
#!/usr/bin/perl -w
use strict;
die "Usage: $0 \n"
unless @ARGV == 2;
my ($total_labels, $total_locals) = @ARGV;
my $labels_so_far = 0;
my $locals_so_far = 0;
print ".sub __MAIN\n\n";
while ($labels_so_far < $total_labels or $locals_so_far < $total_locals) {
my $action = qw(label local arithmetic control)[rand 4];
if ($action eq 'label' and $labels_so_far < $total_labels) {
printf "\n_L_%d:\n", ++$labels_so_far;
}
elsif ($action eq 'local' and $locals_so_far < $total_locals) {
printf " .local int V_%d\n", ++$locals_so_far;
printf " V_%d = %d\n", $locals_so_far, int(rand()) + 1;
}
elsif ($action eq 'arithmetic' and $locals_so_far > 0) {
my $result = 1 + rand $locals_so_far;
my $arg1 = 1 + rand $locals_so_far;
my $arg2 = 1 + rand $locals_so_far;
my $op = qw( + - * )[rand 3];
printf " V_%d = V_%d %s V_%d\n", $result, $arg1, $op, $arg2;
}
elsif ($action eq 'control' and $locals_so_far > 0) {
my $dest = 1 + rand $total_labels;
my $arg1 = 1 + rand $locals_so_far;
my $arg2 = 1 + rand $locals_so_far;
my $op = qw( < <= == != >= > )[rand 6];
printf " if V_%d %s V_%d goto _L_%d\n", $arg1, $op, $arg2, $dest;
}
}
print "\n";
print ".end\n";
print "\n";
exit 0;
- snip
Dan Sugalski wrote:
At 6:50 AM -0700 8/30/04, Gregor N. Purdy wrote:
Dan --
I figured. We could probably write a code-generator that used a PRNG
to generate massive amounts of stereotypical code, spitting out C and
PIR...
That would be easy if it was a bunch of
x = x + y
z = 3 * x
lines that would approximate the structure of your large stuff. Is it
much more complicated than that?
Oh, yeah. :) Or, rather, no, if you factor in the second simple bit, the
massive number of labels and comparisons. Add those into the mix and I
think you'd have it.
-- Gregor
Dan Sugalski wrote:
At 6:46 AM -0700 8/27/04, Gregor N. Purdy wrote:
Dan --
I think it would be interesting to find out how, say, gcc
behaves on the pathological code structures you've run into.
Could your compiler spit out a structurally (although not
semantically! :) equivalent piece of C code that could be
used with a C compiler to see how we do vs. C compilers in
these cases?
That's a good question. While it's not impossible, I'd need to do a
bunch of work on the compiler to get it to emit compilable C instead
of PIR, and I don't think it's something I'll have time for anytime
soon. :(
Pathological Register Allocation Scenarios
Dan -- I think it would be interesting to find out how, say, gcc behaves on the pathological code structures you've run into. Could your compiler spit out a structurally (although not semantically! :) equivalent piece of C code that could be used with a C compiler to see how we do vs. C compilers in these cases? Regards, -- Gregor
Re: Compile op with return values
Hmmm... Wouldn't a C compiler want to return a sub that invoked the main() (if there was one)? And, if there wasn't one, wouldn't the C compiler want to return a sub that raised an exception? Regards, -- Gregor Dan Sugalski wrote: At 11:03 PM -0700 8/21/04, Steve Fink wrote: I am experimenting with registering my own compiler for the "regex" language, but the usage is confusing. It seems that the intention is that compilers will return a code object that gets invoked, at which time it runs until it hits an C opcode. But what if I want to return some values from the compiled code? Here's what's supposed to happen. The compile op only compiles the code passed in, it doesn't execute it. The returned sub object represents the entire code chunk that was compiled, and likely ought to be immediately executed itself. As a perl example, the eval function should give code like: compiler = compreg "Perl5" eval_pmc = compile compiler, my_source eval_pmc() though the eval_pmc() call ought to check and see if it got anything in return. This does mean that if you skip the invocation of the returned PMC that things may not happen. This is fine. And for many languages the returned PMC won't actually do anything at all when invoked. It's important to note that the returned PMC does *not* represent any particular sub in the source -- rather it represents the entire source module. So if the language was C, for example, the returned PMC wouldn't do anything since C doesn't allow you to have code outside functions.
Re: Starting to make things final
Dan -- Thanks for mentioning Jako. It usually gets no respect. :) But, I think Jako is "working" for some definition of "working". But, it is clearly not an idiomatic compiler in that its using old conventions (not surprising, given its history). Did I miss the creation of the compiler-writer list? I need to figure out what needs to be done to convert Jako to a compiler worthy of regular mention, and I suspect the perception problem it has is due to its ageing world-view on how to compile a language down to IMC. Last time I wrote code for it, there were impedence mismatches between IMC and the natural way of thinking about Jako code. Maybe those are gone now, but I could sure use some guidance getting up to speed on The Right Ways as they currently are. Or, should I wait until some of the changes you contemplate in this message so I don't have to change calling convention stuff *again*? Regards, -- Gregor Dan Sugalski wrote: In what's seems a rather bizarre twist, Parrot's getting production ready. Yes, I find this really strange, and no, I'm not even talking about my work project, though I probably should. Python and PHP are both near-beta ready, and Span looks... well, it looks damn nice. As such, I think we're in a state where the things that have been in and implemented should be documented and fixed, and the things that are in flux should un-flux and get fixed. I'm tired of most of languages/ being broken as well -- I'd like to get forth, BASIC, Jako, Cola, and the rest all working again, and like to not break m4. So, here's what we're going to do. First, I'm digging into Leo's proposal for changing sub calls. It has user-visible issues in that when we're done hashing it out, it'll mean no need to do save/restores. Next we're going to put the return continuation, sub PMC, and object PMC into the interpreter structure. They can stay in the registers they're in now, I expect. That'd be convenient, and we're not really short of registers. Then we kick the python bytecode compiler around until it works. This will, I expect, involve finalizing exceptions, so we will. When we're done with that we're going to release 0.2.0. After that we're going to revisit, and then lock down, the embedding and extending APIs. When we're done with those, we're *done*. We'll put together source tests, which'll remain canonical unless the tests themselves have bugs. Then we release 0.2.1. After that I think we address the string internal issues, and dynamic string loading. We'll also tackle, I think, serializable continuations. Then we release 0.3.0. From there I don't want to speculate, but events/IO and threads are next on the hit list. Questions? This'd be a good time to suggest changes to the timeline...
Re: Python::Bytecode
Leo -- I had tinkered around with this stuff back in 2003, and ended up writing Python::Bytecode::SAX to help me visualize bytecode. IIRC, I ran into the same issue of only disassembling one code block. I'd be interested to know if P::B::S treats your example python bytecode any better than P::B. If so, maybe someone could take part of P::B::S and use it. http://www.gregorpurdy.com/gregor/sw/Python-Bytecode-SAX/ Regards, -- Gregor Leopold Toetsch wrote: ... is on CPAN (said Dan) and is broken. I'd be glad if people could fix it and send me a running version ;) * constants are messed up * it doesn't disassemble all code objects of a .pbc - just one $ cd languages/python $ perl pie-thon.pl -dD some.py shows more (and AFAIK correct) Python disassembly (it's using dis.py) - but e.g. lambda code objects are missing as well as class initializers and such stuff. $ perl pie-thon.pl xyz.py | ../../parrot - runs that stuff (if it's implemented ;) Thanks, leo
Re: The Pie-thon benchmark
So, where and when is the pie-throwing going to happen, precisely? IIRC, its at OSCON, but last time i googled for it, I didn't see mention of which OSCON session or BOF it would be at Regards, -- Gregor Dan Sugalski wrote: Since this is getting worked on now, I figured I'd post the benchmark URL for anyone who might be interested: ftp://python.org/pub/python/parrotbench/parrotbench.tgz It's pretty evil, and there's a chunk of "let's exercise python's builtins just because" code in there. Worth taking a look at, as we may well enlist the aid of the list to get some of those built-in functions working. (Which will be cool, since it'll mean a push to get a chunk of extra, useful functionality in) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Compatibility with perl 5
Brent --
I think I missed your point. I'll refer to your two code chunks as
(a) and (b). Maybe you are getting at a finer point, though...
What you've said in (a) is pretty much what I hinted about Inline::Perl6
in my message. If you pass it to a Perl 6 interpreter, then it will
probably use that hint to shift into Perl 5 mode (which, fortunately,
is a perfectly respectable thing for a Perl 6 interpreter to do) kind
of as if what you had sent it was really:
#!/usr/bin/perl6
use syntax 'perl5';
...
Any Perl 5 code above your 'use 5' statement that isn't also legal
Perl 6 code, though, would cause the compiler to complain.
I don't see how what you've said in (b) is different from what I've
said, outside the "use 6" which I think shouldn't exist, since
it means nothing to Perl 5 (there is no Perl 5, version 6) and
means nothing to Perl 6 (which has as its lowest version number...
6). So, the code you wrote is Perl 6 with a redundant "use 6"
in it, otherwise in the same vein as what I wrote. If you pass it
to a Perl 5 interpreter, it will choke. If you pass it to a Perl 6
interpreter, life is peachy keen. If you pass it to a Python
interpreter, you get what you deserve :) You have used "use syntax"
which falls under the category of "# or whatever" in my message.
Regards,
-- Gregor
On Wed, 2004-04-14 at 18:51, Brent 'Dax' Royal-Gordon wrote:
> Gregor N. Purdy wrote:
>
> > #!/usr/bin/perl6
> >
> > ... # Perl 6 stuff here
> >
> > use 5; # or, whatever
> >
> > # Perl 5 stuff here
> >
> > no 5; # or, whatever
> >
> > # More Perl 6 stuff here
> >
> > use python; # you get the idea
>
> Why conflate the two at all? Perl 5 has two separate syntaxes for
> forcing a version and embedding code in a different language:
>
> use 5;# forces Perl < 6
> perl_five_code();
> use Inline::Perl6 q{ # Ah, the wonders of ponie...
> perl_six_code();
> };
> use Inline::Python q{
> python_code()
> };
>
> So why not do the same (albeit in a much slicker way) for Perl 6?
>
> use 6;# forces Perl 6+
> perl_six_code();
>
> {
> use syntax 'perl5'; # switches to Perl 5 syntax
> perl_five_code();
> }
>
> {
> use syntax 'python';
> python_code()
> }#With the indentation, I think this closes both the Perl and
> # the Python block...
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Brent --
Clever points are relatively high here, but I find the idea of
doing the notionally simultaneous parse uncomfortable. I really
don't want my programs subject to a hidden double parse cost.
Regards,
-- Gregor
On Wed, 2004-04-14 at 15:30, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman wrote:
> > On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> >
> >>So, we are moving in a more verbose direction, which is a bummer for
> >>people who like to write one-liners and other tiny programs.
> >
> >
> > perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> > s:g/\b\.\.\.\b/IP ADDR/;' *
> >
> > No biggie.
>
> Curlies aren't used for that anymore. I'd also suggest using an
> assertion for a much shorter C rule:
>
> perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
> s:g/\b\.\.\.\b/IP ADDR/' *
>
> TMTOWTDI, though, and I'm being rather nitpicky.
>
> Personally, I would implement Perl 5 vs. Perl 6 switching as:
>
> 1. If argv[0] includes either '5' or '6', use the appropriate version.
> 2. Parse the program as *both* Perl 5 and Perl 6.
> 3. Figure out which parses succeeded:
> a. If Perl 5 succeeded...
>i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
> warning should be on by default, but that's open to
> negotiation.)
> ii. Execute the Perl 6 parse.
> b. Else if Perl 6 succeeded, execute the Perl 6 parse.
> c. Else...
>i. If exactly one of the parses died on an error that
> disambiguates between the Perls (e.g. a package statement, a
> 'use 6'), emit the other's error message.
> ii. Otherwise, emit an ambiguity warning and both error messages.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Lets try that again, since I think you parsed my email in a way I
didn't intend (and its at least 50% my fault)
--
In my opinion, starting a script with "#!/usr/bin/perl6" should force
the interpreter to treat it like Perl 6, and if it does anything else
that's just ugly. Similarly, starting a script with "#!/usr/bin/perl5"
should force the interpreter to treat it like Perl 5, and if it does
anything else that's just ugly, too. The only opportunity for
ambiguity is if the script starts with "#!/usr/bin/perl" or no shebang
line.
In that case, maximal backward compatibility dictates that the
interpreter expect Perl 5, although 20 years from now we may wish
Perl 6 was assumed (and maybe by Perl 7 we will assume Perl 6 unless
told otherwise... :)
Personally, I view Perl 6 as such a completely new language (although
still Perlish in spirit, it is very different in other respects), that
I would be perfectly happy to be required to start all my Perl 6
programs with "#!/usr/bin/perl6" instead of "#!/usr/bin/perl", just
the same as I'd start a Python program with "#!/usr/bin/python".
If it turns out that the /usr/bin/perl program is actually just a link
to the same executable as /usr/bin/perl6 but operating with a different
personality, I'm fine with that. Heck, I'd be fine with /usr/bin/python
being a symlink to the same executable, too, and I'd expect it to behave
like a Python interpreter.
I don't see any need to have a program start out as a potentially Perl 5
program and then determine that it should really be thought of as Perl 6
and switch personalities. That is, I don't see a need for this:
#!/usr/bin/perl
use 6;
Since there is no version 6 of the Perl (5) language. Inline::Perl6
aside, there ain't no Perl 6 in the Perl 5 world, even though there are
a few Perl6:: isms.
Now, I do think it would be perfectly fine for a program to start off
as a Perl 6 program and have an embedded chunk that is interpreted as
Perl 5, since that is a feature of Perl 6.
#!/usr/bin/perl6
... # Perl 6 stuff here
use 5; # or, whatever
# Perl 5 stuff here
no 5; # or, whatever
# More Perl 6 stuff here
use python; # you get the idea
...
Regards,
-- Gregor
On Wed, 2004-04-14 at 12:59, Aaron Sherman wrote:
> On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> > So, we are moving in a more verbose direction, which is a bummer for
> > people who like to write one-liners and other tiny programs.
>
> perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> s:g/\b\.\.\.\b/IP ADDR/;' *
>
> No biggie.
>
> > Assuming only Perl 6 is installed on your system, if your script
> > started with:
> >
> > #!/usr/bin/perl
> >
> > all the stuff about trying to figure out what version you are using
> > would have to apply I suppose. But, if you used this, are we saying
> > you still have to do something else to ensure its treated as Perl 6?
>
> Yes, because Perl 6 *is* Perl 5, when it wants to be.
>
> > #!/usr/bin/perl6
> >
> > And, if you did this, you might have to do something else to ensure
> > it is treated as Perl 5?
>
> Correct. If you *say* "perl6" and then want to *be* Perl 5, I'm not sure
> if a) you could not or b) you would have to throw in something like "use
> 5".
>
> > #!/usr/bin/perl5
> >
> > that seems wrong.
>
> Not sure why. That is just short-hand for:
>
> #!/usr/bin/perl
> use 5;
>
> I'm not sure, once again, what would happen if you said:
>
> use 5;
> use 6;
>
> Either it would give you an error (you really deserve it) or it would
> just switch back to Perl 6 mode... the problem arises when you ask,
> "what about anything that got parsed in between the two?" Yech.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
So, we are moving in a more verbose direction, which is a bummer for people who like to write one-liners and other tiny programs. Assuming only Perl 6 is installed on your system, if your script started with: #!/usr/bin/perl all the stuff about trying to figure out what version you are using would have to apply I suppose. But, if you used this, are we saying you still have to do something else to ensure its treated as Perl 6? #!/usr/bin/perl6 And, if you did this, you might have to do something else to ensure it is treated as Perl 5? #!/usr/bin/perl5 that seems wrong. Regards, -- Gregor On Tue, 2004-04-13 at 08:12, Luke Palmer wrote: > David Cantrell writes: > > A few days ago I briefly discussed with Nicholas Clark (current perl 5.8 > > pumpking) about making perl5 code forward-compatible with perl6. A > > quick look through the mailing list archives didn't turn up anything > > obvious, and I don't recall any mechanism being presented in any of the > > Apocalypses, so ... > > Well, there is one, as far as I understand it. Your "use perl5;" is > spelled "package". That is, perl will assume Perl 6 unless it sees > "package SomethingOrOther;" (since Perl 6 calls them "module"s). So, to > force Perl 5 interpretation, use: > > package main; > > Luke -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: new libraries
Sounds like a deep version of map... Regards, -- Gregor On Fri, 2004-04-09 at 06:02, Jens Rieks wrote: > Hi, > > On Thursday 08 April 2004 23:49, Tim Bunce wrote: > > On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote: > > > Data::Replace replaces every occurrence of one PMC in a nested data > > > structure with another PMC. > > > > I'm not sure what that means, but Data::Replace seems too vague. > > What is it? > if you have a data structure [A, B, [C, D, E], C, D, E], where each letter > represents a PMC. With Data::Replace, you can for example replace each D PMC > with another PMC value. > Do you have a better name for it? > > > > Data::Escape contains a function "String" that escapes the string. > > > > Wouldn't escape_string be better? > What would be redundant, the namespace already contains "Escape". > > > (And I wonder how different languages escape strings, > > and if there's a common subset that'll work for all/most of them.) > Its C and PIR like escaping, it relaces some ASCII code with \n, \t, \r and > replaces ' with \' in strings quoted with ', and " with \" in strings quoted > with ". > > > Tim [wearing a tired old namespace police hat] > :-) > > jens -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Continuations (again)
I don't know about the continuation stuff, but you can't assume that running imc --> pasm --> exec does the same thing as imc --> exec. I ran into that before, and I don't think its going to get fixed until the new imcc lands, at which point old-school pasm might even be gone (although I don't know that I'm remembering that part right). Regards, -- Gregor On Sun, 2004-03-21 at 08:53, Piers Cawley wrote: > So, I'm trying to get my head 'round parrot's continuations. It's my > understanding that, at creation time, a Continuation closes over the > current user stacks, control stack and lexical pad (and possibly some > other stuff but those'll do for now). > > So, it seems to me that the following code should print "Howdy, > world". > > .sub main > $P0 = new PerlUndef > $P0 = "Howdy, world\n" > save $P0 > $P1 = newcont after > #$P1 = new .Continuation > #set_addr $P1, after > invoker($P1) > sub_end: > .pcc_begin_return > .pcc_end_return > > after: > restore $P2 > print $P2 > branch sub_end > .end > > .sub invoker > .param pmc a_cont > invoke a_cont > .pcc_begin_return > .pcc_end_return > .end > > Except, what actually happens is: > > Parrot VM: PANIC: Illegal rethrow! > C file src/exceptions.c, line 356 > Parrot file (unknown file), line 0 > > Which isn't quite what I had in mind. Bizarrely, if I do: > > $ parrot -o howdy.pasm howdy.imc > $ parrot howdy.pasm > Howdy, world > $ > > everything's fine. > > Weird hunh? -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
Oh, and the form doesn't require you to do the :set digraph thing. Its always available. Regards, -- Gregor On Fri, 2004-03-19 at 06:16, Gregor N. Purdy wrote: > For me, (vim 6.2), that is > > < < to get « > > > to get » > > after doing > > :set digraph > > (list of available digraphs can be seen by :digraph) > > But, I find the above a bit unnerving because I've deleted > the character, and then if I type a certain character next > I haven't. > > Vim also allows > >< < to get « >> > to get » > > > Regards, > > -- Gregor > > On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: > > Andy Wardley wrote in perl.perl6.language : > > > I'm so happy! I just found out, totally by accident, that I can type > > > the « and » characters by pressing AltGr + Z and AltGr + X, > > > respectively. > > > > Of course this information is almost completely unusable without knowing > > your OS, your locale, and your keyboard flavour. But thanks anyway, and > > I'll share mine : with vim, and with the 'digraph' option set, just type > > < <to get « > > > >to get » > > This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
For me, (vim 6.2), that is < < to get « > > to get » after doing :set digraph (list of available digraphs can be seen by :digraph) But, I find the above a bit unnerving because I've deleted the character, and then if I type a certain character next I haven't. Vim also allows < < to get « > > to get » Regards, -- Gregor On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: > Andy Wardley wrote in perl.perl6.language : > > I'm so happy! I just found out, totally by accident, that I can type > > the « and » characters by pressing AltGr + Z and AltGr + X, > > respectively. > > Of course this information is almost completely unusable without knowing > your OS, your locale, and your keyboard flavour. But thanks anyway, and > I'll share mine : with vim, and with the 'digraph' option set, just type > < < to get « > > > to get » > This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Mutating methods
Larry --
So, will "mutatingness" be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the end result is going to clobber the
current object, we could avoid making an extra copy.
I suppose there is some danger here. What if I write a class
that I intend to have value semantics. That is, once an instance's
value is set at construction time, it never changes, although you
can get new instances by invoking its methods. BigInt would
work this way. I can imagine a Point class working this way - you
don't (necessarily) want two objects hanging on to a point, and one
of them to mutate it into a different value out from under the other
one. You wouldn't expect that behavior from other value objects such
as built-in strings.
This points at mutatingness being aimed at the reference (variable)
not the referrent (value), unless it can be different in the case
of value-objects and container-objects...
So, if we had a BigDataContainer class for which it *was* reasonable
to mutate it in place, and we wanted that behavior to trigger on .=
to do an in-place modification:
$bigData .=applyBlockCipher($cipher, $key);
would there be a way to do that without the extra copy implied in:
$bigData = $bigData.applyBlockCipher($cipher, $key);
while leaving
$foo .=someOtherMethod();
equivalent to
$foo = $foo.someOtherMethod();
when $foo's class or someOtherMethod() implementation doesn't do
anything special?
Regards,
-- Gregor
On Wed, 2004-03-10 at 21:29, Larry Wall wrote:
> On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
> : I was thinking along the lines of...
> :
> : String $foo = "hello";
> : $foo.scramble!
>
> That would be $foo.=scramble in the current scheme of things.
>
> : print "$foo\n";
> : $foo = "hello"
> : print $foo.scramble ~ "\n";
> : print $foo;
> :
> : OUTPUT (or close):
> : elhlo
> : hloel
> : hello
> :
> : Also, along these same things.. is there a way to apply a method to all
> : variables/objects of a certain type (e.g. String, Num, etc)? Taking the
> : above example.. being able to write a method called "Scramble" that can be
> : called as a method from any String type.
>
> Two ways, actually. You can 'reopen" the String class and add the method:
>
> class String is extended {
> method scramble () returns String {...}
> }
>
> or if you consider that underhanded, you can define a multi-sub:
>
> multi sub *scramble (String $s) returns String {...}
>
> If you call that as a method, and there is no ordinary scramble method,
> it will "fail soft" to looking for a scramble multimethod, and end up
> calling your definition. Or you can just call it directly as a function:
>
> scramble("hello")
>
> Larry
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Inconsistent Parrot / IMCC behavior
Leo -- Thanks for the pointer. I made the change, and now I get consistent results. I'll check that in. I am still not clear, though, on why we wouldn't have the same failure in all cases. I'd think these should be equivalent: * Running parrot on 'foo.imc' * Running parrot on 'foo.pasm' generated from 'foo.imc' * Running parrot on 'foo.pbc' generated from 'foo.pasm' since I'd think that the later cases would be mirroring what is going on inside parrot in the earlier ones. Where am I going wrong? Regards, -- Gregor On Sat, 2004-02-28 at 05:33, Leopold Toetsch wrote: > Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > > > I was running the various languages/jako/examples and I ran > > across this oddity (after doing a fresh 'make' of Parrot and > > in the languages/jako directory): > > > [EMAIL PROTECTED] jako]$ ./jako examples/fact.jako > > [EMAIL PROTECTED] jako]$ ../../parrot examples/fact.imc > > This segfaults because of illegal code. The "branch __IN_LINE_1" doesn't > get a proper fixup - branches are not supposed to go into different > compilation units. > > Changing the code to: > > .sub __INLINE_0 > .globalconst int N = 15 > bsr __INLINE_1 > ret > .end > > fixes this. > > When compiling the PASM, all is one compilation unit and the error > vanishes. > > leo -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Fill Justification
Damian -- Good. I don't remember where I first heard about doing it that way vs. from the left, but the results going from the right to left are typically better looking than from left to right, and I use that way exclusively now. Regards, -- Gregor On Sat, 2004-02-28 at 15:54, Damian Conway wrote: > Gregor N. Purdy wrote: > > > In the section "He doth fill fields..." we see an example of Fill > > Justification where two spaces fit between every word. This doesn't > > give us an idea of how spaces are distributed if the number of > > spaces needed does not divide evenly into the number of interstices. > > Currently extra spaces are fitted into the rightmost gaps (as this seems -- to > me at leats- to produce the least weird results). I've tried all sorts of > other schemes but none seem as satisfactory to me. > > Damian -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Overflow Fields
Smylers -- So, what I'm looking for is more explicit phrasing around "immediately above". In the example, the column range for the overflow field is exactly the same as that of the $method field in the prior "picture". But, what does it do if it doesn't match *exactly*? Is it an error, does it have some heuristics to guess? What are the edge cases? Regards, -- Gregor On Sat, 2004-02-28 at 07:39, Smylers wrote: > Gregor N. Purdy writes: > > > In "And now at length they overflow their banks." its not clear > > how an overflow field gets tied to its initial non-overflow field. > > In the recipe example given, how does it know to go with the > > $method field instead of the $prep_time field? > > The definition given is: > > An overflow field automagically duplicates the field specification > immediately above it. > > The method field is immediately above the overflow field; the > preparation time field isn't. > > Smylers -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Option Key Validity
Smylers -- I think the claim in E7 is stronger, that not only does the string match the identifier pattern, but that it is a 'valid' (known, declared) identifier. Else, what would be the point of saying both: * "contains a valid identifier", and * "check the validity before the program starts" But, since E7 doesn't come right out and say it, I'm asking for clarification. Still could be that you are right and there is nothing to see here, though... Regards, -- Gregor On Sat, 2004-02-28 at 07:46, Smylers wrote: > Gregor N. Purdy writes: > > > "...we're guaranteed that the key of the resulting pair is a string, > > that the string [...] contains a valid identifier, and that the > > compiler can check the validity before the program starts." > > > > We aren't told what validity checking the compiler is doing. I figure > > its looking for some in-scope declaration of that identifier, but what > > would such a declaration look like? > > I take "valid identifier" to mean something which is syntactically valid > as an identifier, rather than something that is in the finite set of > identifiers which C actually uses. > > Using the C<< => >> it's possible to construct pairs in which the key is > not a valid identifier: > > 'Hello there' => 'contains a space', > '2b' => 'starts with a digit', > '%^&@";' => 'only punctuation characters', > > None of those keys could result from using the C<:> option constructor. > > Smylers -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Perl6::Slurp
The Exegesis mentions the Perl6::Slurp module, but I don't see it on CPAN. Is it just a race condition? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Overflow Fields
In "And now at length they overflow their banks." its not clear how an overflow field gets tied to its initial non-overflow field. In the recipe example given, how does it know to go with the $method field instead of the $prep_time field? Is it basing off of matching the horizontal extent of the initial field? If so, are error messages generated if there is overlap? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Option Key Validity
In "Thou shalt have my best gown to make thee a pair...", we are given a reason to use the option syntax vs. the pair constructing fat comma C<< => >>: "...we're guaranteed that the key of the resulting pair is a string, that the string [...] contains a valid identifier, and that the compiler can check the validity before the program starts." (Do we need both "...a valid..." and "...check the validity..."?) We aren't told what validity checking the compiler is doing. I figure its looking for some in-scope declaration of that identifier, but what would such a declaration look like? Where exactly does the set of valid option identifiers *for C* come from, and are they tied *to C*, or floating in a global space, free to collide with other (option key) identifier declarations? It seems like there's more to this story... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Fill Justification
In the section "He doth fill fields..." we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. In the section "More particulars must justify my knowledge...", indicates the approach is to "...distribute any padding as evenly as possible into the existing whitespace gaps...", but still doesn't tell us what the rule really is. In the example, there are two spaces to be distributed and three interstices. The last two each get one space. That could be the "add one pad to each insterstice from right to left, repeat until exhausted" rule, which isn't really about even distribution. One other note about this example: The text says C will "...extract a maximal substring...", but in the example that string would be "A fellow of infinite j". The example output shows that the extracted string isn't quite maximal. It tries to keep words together (this rule is detailed elsewhere, but this example doesn't refer to that extraction rule). -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Dynamic Headers
In "From the crown of his head to the sole of his foot..." (clearly
a reference to a Gilligan's Island episode where Lovey said something
similar :), we have:
:header{ ..., odd => "Act, $act, Scene $scene...", ... }
and below, text indicating that it will
"prepend the act and scene information to the start of any odd page
(except, of course, the first or the last), ..."
I don't see how that can be. The string will be evaluated and
interpolated at the time the option pair is constructed, most likely
with C<$act> and C<$scene> undef. After that, the same static text
will appear in the header.
I suppose
... odd => sub { "Act, $act, Scene $scene ..." }, ...
would work, though.
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Some other tyops
First, thanks Damian for doing this, and good show!
Smylers already pointed out a few errors in the document, but
here are a few others I noticed:
* In "Why, how now, ho! From whence ariseth this?"
We have this near the top:
type FormArgs ::= Str|Array|Pair;
and this below:
type FormArgs ::= Str|Num|Array|Pair
which is it? (The former -- :) -- appears later in the document
too,
in "Therefore, put you in your best array...")
* In "What a block art thou..."
We have a format like this:
"...{<<<<<<<<<<<<<<<<<}...{>>>>>>>}...
printing something like this:
...By the pricking of ... A horse!...
That should be
...By the pricking of ...A horse!...
* In "Therefore, put you in your best array..."
"form doesn't losing track" should be "form doesn't lose track"
* In "Or else be impudently negative..."
"we simple put an" should be "we simply put an"
* In "Thou shalt have my best gown to make thee a pair..."
"that the string that contains a valid identifier" should be "that
the string contains a valid identifier"
* In "What you will command me will I do..."
"there's not reason" should be "there's no reason".
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: LANGUAGES.STATUS
Jako is in a mostly working state. I just checked in a couple of minor
cleanups:
* Disable languages/jako/examples/sub.jako, since Parrot / IMCC
don't support .global int x
* Change languages/jako/examples/pmc.jako to preallocate a nice
PerlString PMC before attempting to set to a string value.
* Fix Curses.jako library to not use the '.so' suffix when referring
to the curses library.
So, modulo the post I just made about languages/jako/examples/fact.jako
and Parrot / IMCC inconsistent behavior, things are basically working,
such as they are.
Regards,
-- Gregor
On Fri, 2004-02-27 at 22:12, Mitchell N Charity wrote:
> (1) LANGUAGES.STATUS is out of date.
>
> I found (on linux x86 [1]):
>
> These languages failed to build:
> BASIC/interpreter
> jako
> miniperl
> tcl
>
> And these languages were quite broken (bad make test failures):
> BASIC/compiler [2]
> m4
> ruby
> scheme
>
> LANGUAGES.STATUS says they all work.
>
> If my result is typical, adding a
> S: Not working as of 0.0.14 release.
> line to each of these entries seems appropriate.
>
>
> (2) Also, these languages' directories could really use README's:
> python
> plot
> README's saying just what their LANGUAGES.STATUS entries say
> ("elsewhere" and "broken and abandoned", respectively).
>
>
> (3) Finally, this suggests a serious need for expectation management.
> The version documentation should perhaps say, early and often,
> something very vaguely like
>
> Several of the languages targeting parrot were not working at release time.
> They were waiting for objects. Waiting for this release.
> While they waited, enough things changed to break them.
> The purpose of this release is to help them get unstuck and resynced.
> In the meantime, you might look at languages/perl6, forth, cola, and urm,
> which already work. [3]
>
>
> Mitchell
>
> [1] redhat 7.1 linux-x86-gcc2.96, perl 5.6.0, parrot_2004-02-26_08.
> [2] Actually, BASIC/compiler wasn't a "make test" failure (no Makefile).
> BASIC_README points to the wumpus2.bas example, which failed with
> error:imcc:parse error, unexpected LOCAL, expecting $end
> suggesting obsolete code is being generated.
> [3] I list these languages because they demonstrate "parrot is _real_"
> and being used "professionally". And cola draws a mandelbrot. :)
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Inconsistent Parrot / IMCC behavior
I saw the report that Jako wasn't working right with the latest Parrot, so I went to investigate. I was running the various languages/jako/examples and I ran across this oddity (after doing a fresh 'make' of Parrot and in the languages/jako directory): [EMAIL PROTECTED] jako]$ ./jako examples/fact.jako [EMAIL PROTECTED] jako]$ ../../parrot examples/fact.imc [EMAIL PROTECTED] jako]$ ../../parrot examples/fact.pasm Algorithm F1 (The factorial function) Calculating fact(15) = ... ... = 2004189184 [EMAIL PROTECTED] jako]$ ../../parrot examples/fact.pbc Algorithm F1 (The factorial function) Calculating fact(15) = ... ... = 2004189184 [EMAIL PROTECTED] jako]$ I find it odd that turning Parrot loose on the .imc file has a different outcome than turning it loose on the .pasm and .pbc files generated therefrom. The makeology responsible for those files prints output like this: [EMAIL PROTECTED] jako]$ make clean rm -f examples/*.imc examples/*.pasm examples/*.list examples/*.pbc [EMAIL PROTECTED] jako]$ make examples/fact.pbc /usr/bin/perl -I lib jakoc examples/fact.jako > examples/fact.imc || (rm -f examples/fact.imc && false) ../../parrot -o examples/fact.pasm examples/fact.imc || (rm -f examples/fact.pasm && false) ../../parrot -a --output-pbc -o examples/fact.pbc examples/fact.pasm [EMAIL PROTECTED] jako]$ Any thoughts on whether or not this would be my fault somehow? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: I could not resist
This made me think of one of my Gregor's Word of the Week entries, but when I went looking for it, I realized that it was in the list of potential future entries, not on the live site. So, I went ahead and used this occasion to select trichotillomania for Word of the Week for 2004-01-03: http://www.gregorpurdy.com/gregor/wow/000533.html Regards, -- Gregor David Pippenger wrote: On Mon, Dec 29, 2003 at 04:44:33PM -0500, Uri Guttman wrote: "HJ" == Harry Jackson <[EMAIL PROTECTED]> writes: HJ> I was searching on google for HJ> core.html parrot HJ> http://www.gurney.co.uk/parrots/dandan.html and if dan keeps leading parrot he will soon pluck out his own hairs (there is a name for this human neurotic disease). :) That would be trichotillomania http://psychcentral.com/library/hair_pulling.htm -- Dave
Re: The C Comma
Luke --
I guess it might be nice to just do that with a block...
my $n;
while { $n++; @accum } < $total {
...;
}
since we already have a nice do-this-then-do-this syntax.
Sure, it looks a little weird in a for loop:
for ($i = 0; $i < $X; { $i++; some_func() }) {
...;
}
but they are already weird anyway.
FWIW, In the (hypothetical) future Jako (see parrot's
languages/jako/docs/future.pod), I've toyed with a few different ways of
looking at these sorts of constructs, one of which is this (I've made it
look a *little* more Perlish than in future.pod):
You can still write for() like this:
for ($i = 0; $i < l;$ i++) { print $x[$i], "\n" }
but it is really shorthand for this (there's a nit here wrt mapping
"for (my $i ...)" to something reasonable):
for { $i = 0 } { $i < l } { $i++ } { print $x[$i], "\n" }
or, more verbosely:
for {
$i = 0;
} while {
$i < l
} continue {
$i++
} do {
print $x[$i], "\n"
}
That is, the construct:
( ...; ...; ...; )
is another way of saying
{ ... } { ... } { ... }
which, in the case of for(), is interpreted as
{ ... } while { ... } continue { ... }
when each of the "..." is a single statement. For any case where you
want to use more than one statement for one of the "...", you just use
the more verbose syntax.
Now, that won't map directly to Perl 6, since it will handle continue
differently inside the "do" part (right?), but it fits my mental model
nicely (this idea came from looking at looping constructs from Eiffel
as well as elsewhere and looking for the unifying stuff).
Regards,
-- Gregor
On Mon, 2003-11-24 at 16:00, Luke Palmer wrote:
> Honestly you guys, I'm not trolling. I'm just getting a lot of ideas
> recently. :-)
>
> The C comma has always bugged me, but its function is indeed useful
> (many times I use C in its place, if I know the left side will
> always be true). I don't know whether it's staying or not (I've heard
> rumors of both), but I'd suggest that it leave and allow itself to be
> replaced by a word, alongside C, C, and C.
>
> This word: C.
>
> So, from a recent script of mine:
>
> my $n;
> while $n++ then @accum < $total {
> ...
> }
>
> (Where I got in trouble for using C and never executing anything :-)
>
> To me, it's very clear what's going on, and eliminates the mystery of
> the comma in scalar context for a syntax error.
>
> Luke
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Some PIR "How do I?" questions
Umm.. Do you mean:
package Foo::Bar;
sub new {
my $class = shift;
return bless { jo => 42 }, $class;
}
sub prnJoe {
my $self = shift;
print $self->{jo}, "\n";
}
package main;
$f = Foo::Bar->new();
$f->prnJoe();
----
Regards,
-- Gregor
On Sat, 2003-11-22 at 04:36, Sterling Hughes wrote:
> Dan Sugalski wrote:
> > These could use some documenting (and yes, I know the answer to many) for
> > future use for folks generating PIR. (Hint, hint -- documentation is a
> > good thing)
> >
> > *) How do I declare an externally visible subroutine?
> >
> > *) How do I store a global variable
> >
> > *) How do I load a global variable
> >
> > *) How do I call an external function
> >
> > *) How do I get the sub pmc for a sub declared later (or earlier) in the
> > file?
> >
> > *) How do I (or even can I) have a file-scoped variable? (like .local,
> > only for all code in the file)
> >
>
>
> *) How do I do the following in PIR:
>
> package Foo::Bar;
>
> my $joe = 42;
>
> sub new {
> bless {};
> }
>
> sub prnJoe {
> my $self = shift;
> print $self->jo;
> }
>
> package main;
>
> $f = Foo::Bar->new();
> $f->prnJoe();
>
>
> Would also be *really* great (I'm trying to implement the IMC codegen in
> PHP for classes and objects right now :)
>
> -Sterling
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
New glossary entries
I just committed a few new glossary entries for folks reading the summaries: IMC, IMCC, Packfile, PBC, PIR. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Brass Parrot
Here's a suggestion for some upcoming release: Brass Parrot. http://www.avonpage.com/brassparrot.html http://usvi.diningguide.net/data/d100132.htm Maybe a deep-winter release, so us folks in the Northern hemisphere can think pleasant tropical thoughts about St. Croix... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Object freezing
> the xml header is only for the top level thing in the serialized
> tree. if it is nonstandard you have to mark the serialized string so you
> can call the matching thaw methods. each object in the serialized tree
> will have to support that method or some code has to be supplied to
> handle all the freeze/thaw calls made by the tree traverser code. so the
> xml header is just a way to mark which external class will be used for
> the freeze/thaw and it will always be called for each object in the
> tree. you can't mix/match different freeze/thaw techniques in one
> operation (yes, you could but then you do have to mark each node with
> its technique which is a lot of overhead and painful in other ways).
I find the notion of an "XML header" a bit confusing, given Dan's
statement to the effect that it was a throw to XML folks.
I think anything "XML folks" will be interested in will entail
*wrapping* stuff, not *prefixing* it.
Perhaps Dan meant "wrapper" or "envelope" when he said "header", but
its not clear to me without an example. So, I'll put some examples out
there for folks to throw stuff at:
Here's an example of a Parrot Magic Ice (PMI) header (no love here from
XML folks):
# Data of some sort determined by class foo
(This is the way I read Dan's original comment.)
Taken in its entirety, this chunk isn't XML. Sure, you could pull out
the first line and pass it to something that understands XML, and it
wouldn't choke. But, if there is value here, I'm missing it. It could
just as well have been SMTP style:
PMI-Class: foo
Some-Other-Header: ...
# Data of some sort
Here's an example of a wrapper:
That's a bit better, although bear in mind that if the intent is that
you could throw the entire chunk at an XML parser and have it not
complain, you are going to have to take some care in generating the
guts. Binary data is in general right out (where does it end? What if
it contains fragments that look like XML markup?). Sure, you could
slap it in a film, but you'd still have to watch
out for the possibility that the body might want the sequence "]]>"
in it somewhere...
.
OK. Now, I'll throw one crazy idea into the mix. Suppose for just a
moment that instead of using XML proper, or leaving things completely
open-ended, we adopted SAX events as our interchange. it would be
roughly equivalent to:
begin-element pmi { class => 'foo' }
# events for the guts
end-element pmi
Now, anyone who likes XML can hook up a DOM tree builder, or an XML
renderer to the stream of events and be happy as a clam. But, for
storing stuff on disk, we are free to invent a more compact
representation of the events. Thawing entails interpreting the events
as object allocations and state changes to the objects.
I can imagine some reasonably compact representations...
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: PCC and IMC
Luke -- Yeah. That falls into the "duh" category, I guess. But, I'm still having some trouble: .pcc_sub _consume_string prototyped .param str input .local int c .local int test .local Sub __char_is_white_space newsub __char_is_white_space, .Sub, _char_is_white_space .local Sub __char_is_digit newsub __char_is_digit, .Sub, _char_is_digit CONSUME: ord c, input substr input, input, 1 # error:imcc:op not found 'ord_i_p' (ord<2>) (Note that the complaint about ord_i_p is on the substr line, and its as if it thinks input is a PMC not a string. Regards, -- Gregor On Sun, 2003-10-12 at 12:15, Luke Palmer wrote: > Gregor N. Purdy writes: > > Leo -- > > > > The Jako compiler spits stuff out from Perl. > > > > I'm writing some new experimental stuff in PIR directly. > > > > I'm curious about other stuff, too. I don't see any > > of the languages/imcc/t/**/*.t files doing anything with > > the ord op, and when I try to use it as > > > > .local int c > > .local str s > > > > and then > > > > c = ord(s) > > > > or > > > > ord(c, s) > > > > in my .imc file, neither works. Do I need to do magic to > > use any old op I want? > > Uhh... I may be misunderstanding the question, but you should be able to > use assembler syntax, eg. > > ord c, s > > That works for me. > > Luke > > > > > Regards, > > > > -- Gregor > > > > On Sun, 2003-10-12 at 11:42, Leopold Toetsch wrote: > > > Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > > > > Is there any good reason why prototyped PCC subs > > > > shouldn't be callable with IMC syntax that looks like > > > > a macro call, without having to make a macro wrapper > > > > manually? > > > > > > Could be done, but for sure unlikely. PASM/PIR are still assembler > > > languages. You can stuff features and more into it, but this is not the > > > goal. The assembler syntax should be simple and easy to generate from > > > HLL compilers. It should of course have support for all the features of > > > the underlying CPU (parrot), but not much more. > > > You are AFAIK generating PIR files by perl, so just spit out > > > the function call, that's it. > > > > > > leo > > -- > > Gregor Purdy[EMAIL PROTECTED] > > Focus Research, Inc. http://www.focusresearch.com/ -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: PCC and IMC
Leo -- The Jako compiler spits stuff out from Perl. I'm writing some new experimental stuff in PIR directly. I'm curious about other stuff, too. I don't see any of the languages/imcc/t/**/*.t files doing anything with the ord op, and when I try to use it as .local int c .local str s and then c = ord(s) or ord(c, s) in my .imc file, neither works. Do I need to do magic to use any old op I want? Regards, -- Gregor On Sun, 2003-10-12 at 11:42, Leopold Toetsch wrote: > Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > > Is there any good reason why prototyped PCC subs > > shouldn't be callable with IMC syntax that looks like > > a macro call, without having to make a macro wrapper > > manually? > > Could be done, but for sure unlikely. PASM/PIR are still assembler > languages. You can stuff features and more into it, but this is not the > goal. The assembler syntax should be simple and easy to generate from > HLL compilers. It should of course have support for all the features of > the underlying CPU (parrot), but not much more. > You are AFAIK generating PIR files by perl, so just spit out > the function call, that's it. > > leo -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
PCC and IMC
Is there any good reason why prototyped PCC subs
shouldn't be callable with IMC syntax that looks like
a macro call, without having to make a macro wrapper
manually? (I know its not the way it works now, but
you can almost simulate it with a PCC sub def and a
macro, and it seems to me it would be nice if it was
free instead) It would make code more readable...
.pcc_sub _howdy prototyped
.param str who
print "Hello, "
print str
print "!\n"
.end
...
_howdy("partner")
It would be better still if it could handle at least
single return values, too. It would make the IMC stuff
I'm writing much more readable and easier to write, too...
If that wouldn't be considered a mis-feature, does
anyone have a good feeling for how hard it would be to
adjust the IMC syntax and update the compiler?
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Macros and PCC calls
I have a PCC sub: .pcc_sub _char_is_white_space prototyped .param int c # Character to test (as an integer representing its ASCII code) if c == ASCII_NULL goto TRUE if c == ASCII_HORIZONTAL_TABULATION goto TRUE if c == ASCII_LINE_FEED goto TRUE if c == ASCII_FORM_FEED goto TRUE if c == ASCII_CARRIAGE_RETURN goto TRUE L5: unless c == ASCII_SPACE goto L6 goto TRUE L6: FALSE: .pcc_begin_return .return 0 .pcc_end_return TRUE: .pcc_begin_return .return 1 .pcc_end_return .end And, I don't want my calls to it to have to include the entire PCC calling convention. So, I've defined a macro (BTW, why can't I define a macro at the file level? I had to put it inside .sub __main): .macro char_is_white_space(CHAR) .pcc_begin prototyped .arg .CHAR .pcc_call char_is_white_space ### "unexpected identifier"? .local $ret: .result test .pcc_end .endm So now, I can call it like this later ... .local int test .local int c ... .char_is_white_space(c) if test goto ... Except, the line marked in the macro def above shows that parrot doesn't like this arrangement. It seems confused about the .pcc_call line (which I've patterned after syn/pcc.t#1). I don't know what to make of this. Can anyone see where I'm going wrong? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: IMCC - calling convention syntax
The optimizer could hoist the construct out of the loop... Assuming it can realize its possible to do that. Regards, -- Gregor On Tue, 2003-10-07 at 01:14, Leopold Toetsch wrote: > Will Coleda <[EMAIL PROTECTED]> wrote: > > As I realize my example is incorrect. =-) > > > Is there any reason not to make the ".pcc_call _parse" work also, > > rather than having to construct a .Sub? > > We probably could construct a Sub PMC under the hood. The reason for 2 > stages is efficiency though: If you are generating and calling a Sub in > a loop, there is unneeded overhead. > So the rule is: Construct your Sub early. But there are of course > examples, where there isn't any loop. > > leo -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Predereferencing glossary.pod entry
I just put together an entry on predereferencing in the glossary, with pointers to info on various events in its history. I don't remember if it was a recent summary or what, but someone pointed out there was no such entry. Sorry I can't find the original email to notify you directly, but I hope you are watching... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Safe Mode for Parrot -- Need a volunteer
Leo -- Thanks for taking the time to review and comment. > > Here's a first version that works with the regular core. > > > You have to explicitly define PARANOID, or the added code > > won't get compiled. > > It IMHO should be a separate run core, which can be switched to, > whenever safe execution is desired. Then we want to turn off some > opcodes especially these, which would allow to escape from the safe > core. Generally we need a classification of opcodes, so that we can > disable e.g. all IO cops. The reason I wrapped the new code in an #ifdef PARANOID is precisely so that you could use cc -o to override the object file name and build two different .o files (one paranoid and one not) from a single source file. Of course, there are probably other things that need to be done, but I didn't want to make 2 * N new .c files to get paranoid versions of the N core .c files now. > WRT implementation: Putting the register range check in each opcode > function just blows the core size. Its much simpler to have one central > place to inspect the program code. > I'd use the switched core (or better a safe switched core derived from > it) as the base. Its a predereferenced core, so during safe prederef > some of these checks can be done in advance. I thought about prederef a bit right before submitting this, and I think the prederef code path is a great place to do the checks. In fact, I'm wondering if the prederef process shouldn't just do the paranoid checks always, since the point of its process is to make one slightly slower pass through things so that subsequent passes can get a speed boost. Maybe it won't be too much of a hit to leave PARANOID as a built-in part of it always. > While its seems legitimate to check P and S registers for > NULL, its suboptimal to generally disallow NULL registers. NULL PRegs > are in use e.g. for C and if the code allows execution of dlfunc > (probably not but ...) a NULL value for the dl-handle is valid. Only 'in' S and P registers are being checked for NULLness. I looked at dlfunc, and I think the right code is being generated for PARANOID. Maybe you could post a code snippet to point out where it is wrong... > And finally composite keys may have registers too. I have to admit I don't know much about the way the keyed stuff works. It appeared in Parrot after my big push of effort. I've been wanting to integrate it into Jako as a way of learning how it works, but alas my supply of tuits has been very low for some time. Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Safe Mode for Parrot -- Need a volunteer
Dan --
Here's a first version that works with the regular core.
You have to explicitly define PARANOID, or the added code
won't get compiled.
I imagine this will have to be adapted to work with the other
core types, but I wanted to throw this out as a starting point.
I'll leave it up to you whether its worth committing it or
starting over fresh thinking about all cores simultaneously.
Regards,
-- Gregor
On Fri, 2003-10-03 at 11:29, Dan Sugalski wrote:
> Okay, it's time to start in, at least a little, on safe mode for parrot.
>
> While there's a *lot* to ultimately do, the initial part, a paranoid set
> of ops and a runloop that understands it, is relatively simple. What we
> need is someone to thump the code that generates the core_ops.c files (and
> their kindred) to getnerate an alternate set of runloops and op functions.
> These functions, to start, are relatively simple. All that needs to be
> done is for there to be a preamble emitted for each op function that does
> simple validation of the parameters. That means the register number must
> be between 0 and 31, and that any P or S register that is an 'in'
> parameter must be non-NULL.
>
> Anyone care to take a shot?
>
> Dan
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Index: lib/Parrot/Op.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Op.pm,v
retrieving revision 1.11
diff -u -r1.11 Op.pm
--- lib/Parrot/Op.pm 20 May 2003 08:37:14 - 1.11
+++ lib/Parrot/Op.pm 4 Oct 2003 06:27:16 -
@@ -98,6 +98,17 @@
#
+# arg_count()
+#
+
+sub arg_count
+{
+ my $self = shift;
+ return scalar(@{$self->{ARGS}});
+}
+
+
+#
# arg_types()
#
@@ -176,7 +187,66 @@
{
my $self = shift;
- my $body = $self->body;
+ my $preamble = "";
+
+ if ($self->arg_count > 1) {
+$preamble .= <full_name;
+
+for(my $i = 1; $i < $self->arg_count; $i++) {
+ my $type = $self->arg_type($i);
+ my $dir = $self->arg_dir($i);
+
+ $preamble .= < '$type', DIR => '$dir' */
+END_C
+
+ if ($self->arg_type($i) =~ m/^(i|n|p|s)$/i ) {
+$preamble .= < 31) {
+PANIC("Register number out of range for arg $i of op '$full_name'!");
+ }
+END_C
+ }
+
+ if ($self->arg_type($i) =~ m/^(p|s)$/i and $self->arg_dir($i) =~ m/^i$/i) {
+$preamble .= <arg_type($i) =~ m/^([knps])c$/i) {
+my $const_type_tag;
+if(lc $1 eq 'k') { $const_type_tag = "PFC_KEY";}
+elsif (lc $1 eq 'n') { $const_type_tag = "PFC_NUMBER"; }
+elsif (lc $1 eq 'p') { $const_type_tag = "PFC_PMC";}
+elsif (lc $1 eq 's') { $const_type_tag = "PFC_STRING"; }
+
+$preamble .= <= interpreter->code->const_table->const_count) {
+PANIC("Constant number out of range for arg $i of op '$full_name'!");
+ }
+ if (interpreter->code->const_table->constants[cur_opcode[$i]]->type != $const_type_tag) {
+PANIC("Constant of wrong type for arg $i of op '$full_name'!");
+ }
+END_C
+ }
+
+}
+
+$preamble .= <body;
$body .= sprintf(" {{+=%d}};\n", $self->size)
if $self->type eq 'auto';
Re: Problem building jako (perl version dependency?)
Andy --
Thanks. That was a strange one. No complaint by my Perl, even with
"use warnings 'all';", but its definitely a typo (and now fixed, too).
Regards,
-- Gregor
On Mon, 2003-09-22 at 06:21, Andy Dougherty wrote:
> On Thu, 18 Sep 2003, Gregor N. Purdy wrote:
>
> > Andy --
> >
> > I didn't see anything wrong in the code, but I added some parens.
> >
> > Let me know if you still have trouble...
>
> Yup, still the same problem. Here's the line in question:
>
> > > Can't modify subroutine entry in scalar assignment at lib/Jako/Symbol.pm
> > > line 83, near "'arg';"
>
> sub is_variable { my $self = shift; return ($self->kind eq 'var') or
> ($self->kind = 'arg'); }
>
> It's the ($self->kind = 'arg') assignment that's illegal under 5.00503.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Trig functions for vtables
On a related note, I wonder how all this fits in with
methods and multimethods?
If we consider the current trig.ops as being equivalent
to, e.g. (expressed with approximate Perl 6 isms):
multi sub sin(Num $arg) : returns Num;
multi sub cos(Num $arg) : returns Num;
And, at some level I do think some of the more primitive
Perl 6 builtins should be expressed in a Perl syntax that
indicates "this is an op, go to it!" (like I implemented
in Jako. For example, the file 'string.jako' has guts
that look like this:
module string
{
sub concat :op (str dest, str s);
sub int index :op (str input, str pattern, int start);
sub int length :op (str dest);
sub str substr :op (str s, int i, int l);
}
(if
the sub name != the op name, then you can use :op='foo')
This ends up corresponding nicely to related syntax for
NCI. For example, here is Curses.jako:
module Curses
:fnlib = "libcurses.so"
{
sub int initscr :fn ();
sub int endwin :fn ();
sub int curs_set :fn (int x);
sub int addstr :fn (str s);
sub int refresh :fn ();
sub int move :fn (int x, int y);
sub int getch:fn ();
sub int box :fn (int screen, int v, int h);
sub int hline:fn (int ch, int n);
}
(if
the func name != the sub name, then you can use :fn='bar')
Now, along comes the Perl6Scalar PMC, which implements
multi sub sin(Perl6Scalar $arg) : returns Perl6Scalar;
multi sub cos(Perl6Scalar $arg) : returns Perl6Scalar;
In short, it would be nice if
PMC == Class with opaque implementation
(in our case its a C implementation, but I suppose as
soon as someone implements a class in Python and another
person uses it in Perl, its opaque in Perl). Hmm...
"Opaque" smells kind of like "closed", although maybe not
exactly.
Now, along comes some new class that doesn't implement its
own sin(), etc. What should happen? Well, if it is known to
be convertible without loss of information to something that
does have sin(), etc. then things should just work. If they
don't work fast enough, then someone can go to the trouble
to implement the appropriat multi sub in C. As long as we
never implicitly apply a lossy conversion, things should work
fine.
The deeper into the internals we can carry off the similarity
while still being Fast as All Get Out (TM), the better.
Regards,
-- Gregor
On Mon, 2003-09-22 at 15:08, Luke Palmer wrote:
> Brent Dax writes:
> > Dan Sugalski:
> > # Okay, since it seems reasonable to hang the trig functions off of
> > PMCs,
> > # we'd best get a list of the functions we want. I can think of:
> > #
> > # pow
> > # logarithm
> > # square root (yes, I know, it's for speed)
> > #
> > # Normal and hyperbolic versions of:
> > # sine
> > # cosine
> > # tangent
> > # cotangent
> > # arcsine
> > # arccosine
> > # arctangent
> > # arccotangent
> >
> > Okay, reality check. How often are we going to use acosh? Is it really
> > worth the space in the vtable for that few calls? And why can't we just
> > use find_method?
>
> And let's not forget our handy trig identities. We definitely don't
> need all those vtable. Technically, all we need are sine and arccosine.
> I think putting in cosine, arcsine, and [arc]?tangent would be nice,
> too. Cotangent is easy, and is so infrequently used that it's kind of
> silly to include. And hyperbolics are very infrequently used, and can
> be implemented in terms of exp, which in turn can be implemented in
> terms of pow, but shouldn't.
>
> > Basically, where do you draw the line between a vtable method and a
> > find_method method? Unless the line is "methods that everything should
> > support", I'd say it's been crossed when you add acosh to the vtable.
> > And if that *is* where the line is, don't be surprised when vtables
> > cross the megabyte line.
>
> But that's not even the line. There are a lot of methods in there which
> a lot of classes don't support. Now that we have find_method, it might
> be a good idea to define our critera for vtable functions, and then
> prune the vtable accordingly. Maybe.
>
> > I'm really starting to wonder: why do we have only one type of vtable?
> > Why are Closures, Pointers, and Scratchpads forced to implement acosh,
> > splice, pop, or even get_float? And why are PerlInts forced to
> > implement invoke and can_k
Re: string_to_cstring()
Nicholas -- I'd be happy with that... Regards, -- Gregor On Sun, 2003-09-21 at 09:12, Nicholas Clark wrote: > On Sun, Sep 21, 2003 at 08:48:55AM -0700, Gregor N. Purdy wrote: > > The next change is a change to the IO layer. In include/parrot/io.h > > we change struct _ParrotIOLayerAPI to have two versions of C string > > writing: > > > > INTVAL (*PutSc)(theINTERP, ParrotIOLayer * l, /* C-style string put > > */ > > ParrotIO * io, const char * s); > > INTVAL (*PutSl)(theINTERP, ParrotIOLayer * l, /* Explicit length > > string put */ > > ParrotIO * io, const char * s, INTVAL len); > > > > and chase down and fix all the things this breaks. The reason is we > > might need to output a buffer of stuff that contains an interior zero > > byte, which would throw off the old way of doing things. > > Instead could we just ditch the C-style put? (and make the layer table > one pointer smaller) > > Anyone who wants to put a \0 terminated string can do the strlen > themselves. (Or we could provide a helpful macro) > > Nicholas Clark -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: jako causing MANIFEST failures
Nick -- Looks like I'm the guilty party. I do tend to do this every now and again, even though I don't consider myself thoughtless or careless. I think sometimes I get focused on my local changes and as I'm testing and committing it just isn't natural to consider that a change in something that *depends on* the rest of Parrot will cause a build failure of Parrot. It may be that I'm the only one that feels that way, but perhaps not. A sure way to make the problem go away is to make the building of these other pieces of code fail when the problem exists. One way to accomplish that would be to have the various languages have their own MANIFEST files that are checked every time you do a 'make' there. That way, if I have a clean checkout of the entirety of Parrot, and it builds fine, and then I go off and make a change to Jako, I'll get the complaint right then and there instead of having to remember to go back and build/test Parrot again (which hasn't been changed after all). Regards, -- Gregor On Sun, 2003-09-21 at 10:43, Nicholas Clark wrote: > On Sun, Sep 21, 2003 at 05:49:41PM +0100, Nicholas Clark wrote: > > I'm seeing this failure on a clean checkout: > > > > t/src/manifest.NOK 4# Failed test (t/src/manifest.t at line 38) > > # Missing files in Manifest: > > # languages/jako/examples/python.jako > > # languages/jako/jako > > # Looks like you failed 1 tests of 4. > > t/src/manifest.dubious > > Test returned status 1 (wstat 256, 0x100) > > DIED. FAILED test 4 > > Failed 1/4 tests, 75.00% okay > > > > Did MANIFEST get committed without some files? > > As everyone on the commit list will have seen, Dan fixed this > (and I misunderstood the error - files were added without the MANIFEST > being updated) > > How come people don't do a clean build after checking things in to verify > that there's nothing unexpected gone wrong? :-( > > I suspect that dipsy knows the answer: > > 18:41 rule 2 > 18:41 rule 2 is people are lazy > > curiously, like Thermodynamics, a rule 0 has been added: > > 18:42 rule 0 > 18:42 rule 0 is even if you know the rules, you're still a person > > Nicholas Clark -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
string_to_cstring()
All -- I've got some diffs in my sandbox that I thought I had submitted at one point, but I can't find any evidence of them being submitted, so I'll open discussion here. The first change is that the prototype for string_to_cstring() becomes: char * string_to_cstring(struct Parrot_Interp * interpreter, STRING * s, INTVAL * len) The reason is that the caller *should* care about the length, since there is no guarantee that we didn't return a buffer that contained interior zero bytes (which would make calling strlen() on it return the wrong answer). There are of course a bunch of places this is used, so changes to all those places would be required. The next change is a change to the IO layer. In include/parrot/io.h we change struct _ParrotIOLayerAPI to have two versions of C string writing: INTVAL (*PutSc)(theINTERP, ParrotIOLayer * l, /* C-style string put */ ParrotIO * io, const char * s); INTVAL (*PutSl)(theINTERP, ParrotIOLayer * l, /* Explicit length string put */ ParrotIO * io, const char * s, INTVAL len); and chase down and fix all the things this breaks. The reason is we might need to output a buffer of stuff that contains an interior zero byte, which would throw off the old way of doing things. Regards, --Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Pondering argument passing
Luke -- Need it *actually* stick them in the array? Or, could it just provide an array-like interface to the underlying registers? Thats cheaper, especially if not all args are going to get accessed. Explaining how such a thing works to an optimizer that wants to know when registers are being accessed, on the other hand... IIRC the conventions are set up in such a way that the PMC would have to know the args prototype to know which registers to use for each element of the array, whether copying values from them or just providing an interface to them. Regards, -- Gregor On Sat, 2003-09-20 at 21:17, Luke Palmer wrote: > Steve Fink writes: > > The callee side would then need to have a way of saying "...and all > > the rest". So that would be > > > >.params PythonArray foo > > Or, perhaps we could have an ArgArray PMC, which, upon construction, > would examine the registers as per the calling conventions, and stick > all the arguments in the PMC. > > Luke -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: IMCC .globalconst?
Leo --
I'm going to chuck the idea of collecting stuff, and use
this:
.sub _INLINE_{N}
# a chunk of stuff
goto _INLINE_{N+1}
.end
to wrap each contiguous piece. I don't want symbols defined
at point X in the code to be visible to subs introduced at
points prior to X.
I think the collection path is A Bad Idea (TM) for a language with
scripting style (like Jako, Perl, Python, etc.). Whether its
good for other languages is open for discussion, although I
suspect most languages would choke on code analogous to this:
sub foo {
print $X;
}
global $X = 43;
and the collection approach you suggest would make it not choke
in IMCC. I want the visibility of my symbols in IMCC to match
their visibility in the source language. Of course, if I didn't
care about the extra visibility, then collection would be A Fine
Idea (TM).
Regards,
-- Gregor
On Sat, 2003-09-20 at 12:59, Leopold Toetsch wrote:
> Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> > All --
>
> > It used to emit the constants as .const right where the were found
> > lexically, but I've introduced code motion to collect all inline
> > code into the __MAIN sub at the end, which put the .const stuff
> > there (which I've changed to .globalconst in the case where it
> > is something from the top level File block).
>
> [ snip ]
>
> > So, where am I supposed to put these .globalconsts if they
> > have to be in a .sub?
>
> You could emit .globalconst here:
>
>.sub ___MAIN
>
> or just emit .const as they are seen. They get folded anyway, so it's no
> penalty.
>
> > Generally, making me move the code around like this is a bit
> > of a PITA, since technically lexical accessibility of variables
> > inside subroutines defined after them but not those defined
> > before them ends up being a problem.
>
> I think you should collect all code first and then emit "main" and subs
> in that order.
>
> > -- Gregor
>
> leo
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
IMCC .globalconst?
All -- I don't understand how .globalconst fits in with the IMCC policy of everything being in a .sub. The Jako compiler emits stuff like this right now (in my sandbox). It used to emit the constants as .const right where the were found lexically, but I've introduced code motion to collect all inline code into the __MAIN sub at the end, which put the .const stuff there (which I've changed to .globalconst in the case where it is something from the top level File block). .sub ___MAIN bsr __MAIN end .end .sub some_real_sub # calling conv args get print X # calling conv result put ret .end .sub __MAIN .globalconst int X = 43; # calling conv call set up and arg put call some_real_func # calling conv call tear down and result get ret .end This doesn't work. IMCC complains about the use of X in some_real_sub. So, where am I supposed to put these .globalconsts if they have to be in a .sub? Generally, making me move the code around like this is a bit of a PITA, since technically lexical accessibility of variables inside subroutines defined after them but not those defined before them ends up being a problem. I suppose I could collect every chunk of uninterrupted code into .sub __INLINE_N sections still interspersed, and have __MAIN call __INLINE_1 and __INLINE_1 goto __INLINE_2 and the last one ret to __MAIN, but I'd want some input before going to all that trouble. What is the right way to do this stuff??? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: examples/sub.pasm (and others) broken?
Steve -- I've made some progress in fixing the Jako compiler. Modules don't work yet, but the first few examples compile and run. My email was mainly to point out that the $PARROT/examples/ mentioned (not part of Jako) are b0rken. I've got my hands full trying to improve Jako, so I threw to the list in case someone has the tuits to fix the examples. I really don't think we should ship with broken examples. They should be fixed or removed if it isn't worth it... Regards, -- Gregor On Thu, 2003-09-18 at 21:04, Steve Fink wrote: > On Sep-18, Gregor N. Purdy wrote: > > I just got my setup working here in my new home town of Seattle, WA > > and I noticed we are about to release a new Parrot. I wanted to make > > sure Jako was working right, but there has aparently been some > > changes to imcc that make its output unacceptable now. > > > > In an attempt to get up to speed on what is required, I looked in > > examples/ and started running stuff. I noticed that sub.pasm > > outputs this: > > > > Hello subroutine > > No entries on ControlStack! > > > > Also, the following other examples appear broken, too: > > > > * io1.pasm (bad op seek_i_p_ic_ic) > > * uniq.pasm (segfault) > > * xml_parser.pasm (segfault) > > Run 'make' in languages/jako and you'll see more failures. Nothing is > allowed outside of subs, not even namespaces. And nested subs are not > allowed. I only made it that far in looking at this, then got > intimidated by the nested sub thing. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Problem building jako (perl version dependency?)
Andy -- I didn't see anything wrong in the code, but I added some parens. Let me know if you still have trouble... Regards, -- Gregor On Mon, 2003-09-15 at 08:51, Andy Dougherty wrote: > On Solaris 8, with Sun's supplied perl5.00503 and with Sun's cc, I get the > following error when trying to build jako: > > cd jako && make && cd .. > /usr/bin/perl -I lib jakoc examples/bench.jako > examples/bench.imc || > (rm -f examples/bench.imc && false) > Can't modify subroutine entry in scalar assignment at lib/Jako/Symbol.pm > line 83, near "'arg';" > BEGIN failed--compilation aborted at lib/Jako/Construct/Declaration/Sub.pm > line 20. > BEGIN failed--compilation aborted at lib/Jako/Parser.pm line 32. > BEGIN failed--compilation aborted at jakoc line 24. > > I suspect there's a perl5.6 feature being used somewhere, but > haven't looked more closely. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
examples/sub.pasm (and others) broken?
I just got my setup working here in my new home town of Seattle, WA and I noticed we are about to release a new Parrot. I wanted to make sure Jako was working right, but there has aparently been some changes to imcc that make its output unacceptable now. In an attempt to get up to speed on what is required, I looked in examples/ and started running stuff. I noticed that sub.pasm outputs this: Hello subroutine No entries on ControlStack! Also, the following other examples appear broken, too: * io1.pasm (bad op seek_i_p_ic_ic) * uniq.pasm (segfault) * xml_parser.pasm (segfault) Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: [RfC] Clean up of the ParrotIOLayerAPI
Juergen -- Juergen Boemmels wrote: Write PutS Why are there two diffrent calls to write data to an io, with only a slightly different prototype. This is code-duplication in every layer. I can't think of any use case where PutS won't be implemented as Write(..., data, strlen(data)). These two calls could be unified. As a side note: The primary memory structure is the buffer, maybe the unified call should take a buffer argument. -> unify these two We need to be careful here about the difference between C strings and Parrot strings. For your basic C string strlen(data) is the way to decide how many bytes to write. For Parrot strings, we can have internal zero bytes (or the lack of a trailing zero byte) that will throw off strlen and therefore screw things up. I have a patch on my workstation (currently in transit from Cincinnati to Seattle, so not accessible -- but, I've discussed a bit with Dan on IRC) that tries to deal with this issue by having a "*c" (for C-style) and a "*l" (for length-style) variant of a couple functions (including changes to vtables stuff, IIRC). But, that leaves out another important piece: If we have a Parrot string in some encoding, and we are going to Write/Put it to STDOUT, which is headed for someone's terminal, we might need to do more than just blast the buffer if we expect the user to do anything other than curse us and our mothers. Regards, -- Gregor
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
Benjamin -- The trick is to find the cheapest possible way to get conditional processing to occur if and only if there are events in the event queue. I'll only be considering the fast core here for simplicity. But, if you look at include/parrot/interp_guts.h, the only thing of interest there is the definition of the DO_OP() macro, which looks like this: #define DO_OP(PC,INTERP) \ (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP)) The easiest way to intercept this flow with minimal cost is to have the mechanism that wants to take over replace the interpreter's op_func_table with a block of pointers to some Parrot_hijack() function that conforms to the opfunc prototype. Enqueueing an event would set the appropriate interpreter's op_func_table to hijack_op_func_table. Of course, if threads are involved there are going to be locking issues, and I don't know how cheap the locking can be made... I'm aware that there are some very cheap locking approaches available, but I don't have a good feel for when you can and cannot use them, and how cheap they really are. The hijack op_func can do whatever it needs to do and then reset the interpreter's op_func_table to the saved pointer and return the same PC, so the interpreter will pick up where it left off. There might be some use for continuations in here, too. Perhaps the hijack function could save the current state as a continuation (presumably with the old opfunc table as part of the saved context), and then it could invoke the event handler with that continuation as the place to return to... If something like what I've described is workable, it would mean we wouldn't have to have an explicit event queue checking policy. Events would get delivered on the next op dispatch after they were enqueued. As we handle the last event, we notice the queue is empty and make sure the normal op_func_table is installed and normal execution is resumed. This approach does mean that events arriving quickly could DoS the main line of execution, which could require us to add a bit more logic to make sure that "thread" is not starved (if that is important). Regards, -- Gregor On Fri, 2003-07-11 at 16:07, Benjamin Goldberg wrote: > Leopold Toetsch wrote: > [snip] > > - When will we check, it there are events in the event queue? > > If we check too often (between each two ops), it will slow things down. > > If we don't check often enough, the code might manage to avoid checking > for events entirely. > > I would suggest that every flow control op check for events. Or maybe > just every control flow op that goes to earlier instructions. > > And of course ops which might block for IO. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: cmod op
Simon -- It used to be that the 'mod' op was the mathematically "correct" (in the Knuth sense) op, and the 'cmod' op was 'mod' per the C implementation used to compile Parrot (which are two very different things, it turns out). I wrote the Knuth-mod op originally, and proposed having both versions. It looks to me like core.ops still has the simple cmod (x % y) and the distinct mod (Knuth-style) ops when it comes to the non- PMC versions. Since it is likely that much numeric work will occur via PMC ints and nums, I'd rather see PMCs have the same mod / cmod distinction as exists with INTVALs and NUMVALS, which as you point out does not seem to be the case. In general, I'd expect that we want Parrot to support all INTVAL, NUMVAL and STRING op semantics with related PMC vtable methods, and you point out a lack in that regard that I think should be remedied by adding vtable methods. Note that the Knuth-style mod can be useful for things like calendrical calculations. Regards, -- Gregor On Thu, 2003-07-10 at 19:54, Simon Glover wrote: > The PMC version of this op (ie cmod_p_p_p) is identical in > implementation to the plain mod op (mod_p_p_p), which seems rather > pointless. Would anybody object if we just got rid of it? > > Simon > -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Copyrights
Robert --
I just ran a little script (pasted at the end), and here
is what we have, today:
Total regular files:2793
When this is determined is in: 108
Yet Another Society is in: 32
The Perl Foundation is in: 0
Regards,
-- Gregor
On Thu, 2003-07-10 at 14:56, Robert Spier wrote:
> s/Yet Another Society/The Perl Foundation/g
>
>
> Gregor N. Purdy wrote:
> > All --
> >
> > I noticed that there are many files with copyrights of
> > "when this is determined...", while some files have a
> > copyright of Yet Another Society. Seems like they should
> > all be Yet Another, or none should be...
>
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
#!/bin/bash
echo -n "Total regular files: "
find . -type f | wc -l
echo -n "When this is determined is in: "
find . -type f -exec grep -l -i 'when this is determined' {} ';' | wc -l
echo -n "Yet Another Society is in: "
find . -type f -exec grep -l -i 'Yet Another Society' {} ';' | wc -l
echo -n "The Perl Foundation is in: "
find . -type f -exec grep -l -i 'The Perl Foundation' {} ';' | wc -l
Using imcc instead of assemble.pl?
All --
I changed the Jako makefile to use imcc instead of assemble.pl,
but I noticed that the mandelzoom example no longer cleared
the screen between screen updates. So, I manually assembed its
languages/jako/examples/mandelzoom.pasm with assemble.pl with
the idea of comparing the results of dissassemble.pl on the
one assembled with imcc and the one assembled with assemble.pl.
However, disassemble.pl dies while looking at the immc assembled
version (the assemble.pl assembled version disassembles fine):
Unrecognized constant type code '0'! at
/home/gregor/src/parrot-cvs/lib/Parrot/PackFile/Constant.pm line 198,
line 7.
(I have applied the patch below to make the error message useful.)
I grubbed around in languages/imcc/pbc.c a bit to see if I could
tell if anything was obviously wrong, but didn't see anything.
Maybe disassemble.pl isn't meant to be used?
ASIDE:
I'm also wondering if our use of character constants (ord("x") in Perl,
'x' in C) to specify the constant types might present a character
set problem on some platforms? If we build a PBC on an ASCII
platform, won't the character value for 'n' be different than on
an EBCDIC platform?
I'd like to stick with imcc as my assembler, but I need to figure
out why the behavior of mandelzoom differs depending upon how it
was assembled. I'll need to figure out some other way if I can't
use disassemble.pl to do it.
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Index: lib/Parrot/PackFile/Constant.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/PackFile/Constant.pm,v
retrieving revision 1.11
diff -u -r1.11 Constant.pm
--- lib/Parrot/PackFile/Constant.pm 19 Aug 2002 23:17:26 -
1.11
+++ lib/Parrot/PackFile/Constant.pm 10 Jul 2003 12:33:02 -
@@ -195,7 +195,7 @@
} elsif ($type == $type_codes{'PFC_KEY'}) {
$value = shift_key($string);
} else {
-die;
+die "Unrecognized constant type code '$type'!";
}
$self->{TYPE} = $type;
imcc and integer constants
At line 679 of languages/imcc/pbc.c, we have:
case 'I':
if (r->name[0] == '0' && r->name[1] == 'x')
r->color = strtoul(r->name+2, 0, 16);
else if (r->name[0] == '0' && r->name[1] == 'b')
r->color = strtoul(r->name+2, 0, 2);
else
r->color = atoi(r->name);
break;
Shouldn't atoi() be atol()?
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: [PATCH] "fix" boolean.pmc and closure.pmc?
Leo --
Its looking like a Heisenbug. I deleted and got fresh copies
of boolean.pmc and closure.pmc and tried to build again so I
could copy the error messsages for you. But, now things
compile without complaint.
Go figure.
Regards,
-- Gregor
On Thu, 2003-07-10 at 02:51, Leopold Toetsch wrote:
> Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> > All --
>
> > I just did a CVS update, and I had to make the following changes
> > to get it to compile
>
> Why did it not compile? What error message?
>
> > ... (I also had to delete and update
> > languages/imcc/parser.[hc], which I think was expected).
>
> Not expected, but I have checked in a solution a minute ago.
>
> > I didn't check it in because I'm not sure if the stuff I commented
> > out is really supposed to go (although recent posts seem to imply
> > that).
>
> I'm waiting for Dan's famous last words WRT the _same vtables.
>
>
> > Regards,
>
> > -- Gregor
>
> > +/*
> > void set_integer_same (PMC * value) {
> > SELF->cache.int_val = value->cache.int_val;
> > }
> > +*/
>
> Strange ...
>
> leo
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Copyrights
All -- I noticed that there are many files with copyrights of "when this is determined...", while some files have a copyright of Yet Another Society. Seems like they should all be Yet Another, or none should be... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
[PATCH] "fix" boolean.pmc and closure.pmc?
All --
I just did a CVS update, and I had to make the following changes
to get it to compile (I also had to delete and update
languages/imcc/parser.[hc], which I think was expected).
I didn't check it in because I'm not sure if the stuff I commented
out is really supposed to go (although recent posts seem to imply
that).
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Index: classes/boolean.pmc
===
RCS file: /cvs/public/parrot/classes/boolean.pmc,v
retrieving revision 1.4
diff -u -r1.4 boolean.pmc
--- classes/boolean.pmc 6 Jun 2003 15:14:59 - 1.4
+++ classes/boolean.pmc 9 Jul 2003 22:10:53 -
@@ -29,9 +29,11 @@
SELF->cache.int_val = (value != 0);
}
+/*
void set_integer_same (PMC * value) {
SELF->cache.int_val = value->cache.int_val;
}
+*/
void set_number (PMC * value) {
SELF->cache.int_val = (value!=0);
@@ -41,9 +43,11 @@
SELF->cache.int_val = (value!=0);
}
+/*
void set_number_same (PMC * value) {
SELF->cache.int_val = value->cache.int_val;
}
+*/
void set_string (PMC* value) {
SELF->cache.int_val = string_bool(value->cache.string_val);
@@ -53,9 +57,11 @@
SELF->cache.int_val = string_bool(value);
}
+/*
void set_string_same (PMC* value) {
SELF->cache.int_val = string_bool(value->cache.string_val);
}
+*/
void neg (PMC* dest) {
Index: classes/closure.pmc
===
RCS file: /cvs/public/parrot/classes/closure.pmc,v
retrieving revision 1.3
diff -u -r1.3 closure.pmc
--- classes/closure.pmc 28 Jun 2003 14:04:44 - 1.3
+++ classes/closure.pmc 9 Jul 2003 22:10:53 -
@@ -48,10 +48,12 @@
stack_mark_cow(sub->ctx.pad_stack);
}
+/*
void set_same (PMC* value) {
PMC_data(SELF) = PMC_data(value);
SELF->cache.struct_val = value->cache.struct_val;
}
+*/
INTVAL is_equal (PMC* value) {
return (SELF->vtable == value->vtable &&
Re: Jako groks basic PMCs
Leo -- No problem. I saw the smiley, but SCNR was new to me. "we cool" :) Regards, -- Gregor On Wed, 2003-07-09 at 02:08, Leopold Toetsch wrote: > Gregor N. Purdy wrote: > > > IIRC, that has been the policy during previous freezes. > > > > However, I can stop tinkering if its getting in anyone's > > way or on anyone's nerves... > > Some smilies and a "SCNR" must have been lost. The change was small, > doesn't break anything and wouldn't be of any harm, *if* we had a > feature freeze. > Sorry for the confusion. > > > > -- Gregor > leo -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Jako groks basic PMCs
IIRC, that has been the policy during previous freezes. However, I can stop tinkering if its getting in anyone's way or on anyone's nerves... Regards, -- Gregor On Tue, 2003-07-08 at 18:01, Melvin Smith wrote: > At 11:50 PM 7/8/2003 +0200, Leopold Toetsch wrote: > >Gregor N. Purdy wrote: > > > >>All -- > >>I just checked in a small patch that allows Jako to start > >>grokking PMCs. For example: > > > >During feature freeze - > > I think languages/ (besides imcc) should probably be > exempt of freezes unless Parrot depends on said language > to build/function. > > Just my 2 cents. > > -Melvin > -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Jako groks basic PMCs
Melvin -- Thanks! Its of only limited utility until I get the key stuff working, but I was tired of having a null PMC story for Jako. Regards, -- Gregor On Tue, 2003-07-08 at 18:01, Melvin Smith wrote: > At 05:44 PM 7/8/2003 -0400, Gregor N. Purdy wrote: > >I just checked in a small patch that allows Jako to start > >grokking PMCs. For example: > > > > use sys; > > var pmc foo; > > foo = new PerlUndef; > > foo = "Hello, world!\n"; > > sys::print(foo); > > Neato, by the way. > > -Melvin -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Jako groks basic PMCs
All -- I just checked in a small patch that allows Jako to start grokking PMCs. For example: use sys; var pmc foo; foo = new PerlUndef; foo = "Hello, world!\n"; sys::print(foo); Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Jako has modules! (for real this time)
All -- I just checked in changes that add real (for some values of "real") modules to Jako. The lexer now handles #line directives, and intercepts 'use ', bringing in the lines from the appropriate file to be lexed. The Jako Standard Library (languages/jako/*.jako, including sys, string and Curses) is now used by the examples as a proof of concept. Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Jako gets modules (sort of)
All --
I just checked in some changes to Jako that bring rudimentary
module support. Its rudimentary because for now, modules are
not referenced from separate files, but simply form handy
named groups of symbols within the single source file being
compiled.
Of course, this really becomes useful once I handle reading
modules from separate source files, so stay tuned...
However, this minimal functionality does permit some fun with
the examples/nci.jako example, which uses curses. The "external
function" declarations within the module can inherit the library
specification from the module properties, which makes for a
handy shortcut notation.
You can see the :fn
property attached to the subroutine declarations -- the function
name in the library defaults to the function name in the .jako
file, although it can be overridden like this:
:fn="foo"
An external function (with :fn property) without a :fnlib
property still needs an fnlib property to work. If it is
declared within a module, it inherits the module's fnlib
attribute (if any), making for handy bundling.
It is intended (but not yet tested) that you can combine
subs with and without :fn within a :fnlib module and have
things work out fine. This will be useful in the Curses
library because (at least on my system) the notional
box() function is actually a macro in the C file, and in
order to present a complete Curses interface in the Jako
module, we'd need to implement box() with the equivalent
call to one of the other :fn subs.
Here's the code from examples/nci.jako:
module Curses
:fnlib = "libcurses.so"
{
sub int initscr :fn ();
sub int endwin :fn ();
sub int curs_set :fn (int x);
sub int addstr :fn (str s);
sub int refresh :fn ();
sub int move :fn (int x, int y);
sub int getch:fn ();
sub int box :fn (int screen, int v, int h);
sub int hline:fn (int ch, int n);
}
var int foo; # Store result from above functions here.
var int screen;
screen = Curses::initscr();
foo = Curses::curs_set(0);
foo = Curses::box(screen, 42, 42);
foo = Curses::move(10, 20);
foo = Curses::addstr("Hello, world!");
foo = Curses::move(12, 15);
foo = Curses::addstr("(Press any key to exit)");
foo = Curses::move(8, 10);
foo = Curses::hline(42, 33);
foo = Curses::move(14, 10);
foo = Curses::hline(42, 33);
foo = Curses::refresh();
foo = Curses::getch();
foo = Curses::curs_set(1);
foo = Curses::endwin();
The code I just checked in includes a few *.jako files in
the languages/jako directory that are intended to eventually
be real usable Jako modules, some of them for ops (:op property)
and some for external libraries (such as Curses.jako).
In any case, if you've been watching Jako (like watching corn
grow, I know) or toying with it, this new update should add
some fun to your day...
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Parrot doesn't compile: Parrot_end_jit() missing...
OK. Daniel and I drilled into it and we discovered that a small change to two regexps in jit2h.pl solved the problem. I have checked in the change. Regards, -- Gregor On Wed, 2003-07-02 at 18:02, Gregor N. Purdy wrote: > Leo -- > > Daniel and I are on the trail... > > On Wed, 2003-07-02 at 17:47, Leopold Toetsch wrote: > > Gregor N. Purdy wrote: > > > > > Leo -- > > > > > > My jit_cpu.c doesn't have a Parrot_jit_end() in it: > > > > > > $ grep end_jit jit_cpu.c > > > > Wasn't here recently (~weeks) a report about a broekn Perl and > > DeadRat^WRedHat? > > > > leo > > > > -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Parrot doesn't compile: Parrot_end_jit() missing...
Leo -- Daniel and I are on the trail... On Wed, 2003-07-02 at 17:47, Leopold Toetsch wrote: > Gregor N. Purdy wrote: > > > Leo -- > > > > My jit_cpu.c doesn't have a Parrot_jit_end() in it: > > > > $ grep end_jit jit_cpu.c > > Wasn't here recently (~weeks) a report about a broekn Perl and > DeadRat^WRedHat? > > leo > > -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Parrot doesn't compile: Parrot_end_jit() missing...
Leo --
My jit_cpu.c doesn't have a Parrot_jit_end() in it:
$ grep end_jit jit_cpu.c
My jit_cpu.c tells me where it came from (I'll attach the
whole file to the message):
$ head jit_cpu.c
/*
* !!! DO NOT EDIT THIS FILE !!!
*
* This file is generated automatically from 'jit/i386/core.jit'
* by jit2h.pl.
*
* Any changes made here will be lost!
*
*/
I can see a relevant entry in jit/i386/core.jit:
$ head -12 jit/i386/core.jit
;
; i386/core.jit
;
; $Id: core.jit,v 1.43 2003/03/08 15:44:37 leo Exp $
;
# TODO complete this
#define P_ARITH ((PREV_OP == dec_i) || (PREV_OP == inc_i) || (PREV_OP ==
sub_i_i_i))
Parrot_end {
jit_emit_end(NATIVECODE);
}
$
But its definitely not ending up in jit_cpu.c here...
Regards,
-- Gregor
On Wed, 2003-07-02 at 12:51, Leopold Toetsch wrote:
> Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
>
> > Which file do you think has the implementation of
> > this function?
>
> All Parrot_*_jit functions are *generated* out of jit/*/core.jit. They
> finally are in jit_cpu.c. This file includes then jit_emit.h, where the
> prototype of the file is too.
>
> Just Configure and make again, then have a look at jit_cpu.c:
>
> #v+
> static void Parrot_end_jit(Parrot_jit_info_t *jit_info, struct Parrot_Interp *
> interpreter){
> jit_emit_end(jit_info->native_ptr);
> }
>
> static void Parrot_noop_jit(Parrot_jit_info_t *jit_info, struct Parrot_Interp *
> interpreter){
> emit_nop(jit_info->native_ptr);
> }
>
> ...
> #v-
>
> > Regards,
>
> > -- Gregor
>
> leo
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
/*
* !!! DO NOT EDIT THIS FILE !!!
*
* This file is generated automatically from 'jit/i386/core.jit'
* by jit2h.pl.
*
* Any changes made here will be lost!
*
*/
#include
#include"parrot/jit.h"
#define JIT_EMIT 1
/*
*define default jit_funcs, if architecture doesn't have these optimizations
*/
#define Parrot_jit_vtable1_op Parrot_jit_normal_op
#define Parrot_jit_vtable1r_op Parrot_jit_normal_op
#define Parrot_jit_vtable2rk_op Parrot_jit_normal_op
#define Parrot_jit_vtable3k_op Parrot_jit_normal_op
/*
* the numbers corresspond to the registers
*/
#define Parrot_jit_vtable_112_op Parrot_jit_normal_op
#define Parrot_jit_vtable_221_op Parrot_jit_normal_op
#define Parrot_jit_vtable_1121_op Parrot_jit_normal_op
#define Parrot_jit_vtable_1123_op Parrot_jit_normal_op
#define Parrot_jit_vtable_2231_op Parrot_jit_normal_op
#define Parrot_jit_vtable_1r223_op Parrot_jit_normal_op
#define Parrot_jit_vtable_1r332_op Parrot_jit_normal_op
#define Parrot_jit_vtable_ifp_op Parrot_jit_cpcf_op
#define Parrot_jit_vtable_unlessp_op Parrot_jit_cpcf_op
#define Parrot_jit_vtable_newp_ic_op Parrot_jit_normal_op
#define Parrot_jit_restart_op Parrot_jit_cpcf_op
#include"parrot/jit_emit.h"
#undef CONST
#define IREG(i) interpreter->int_reg.registers[jit_info->cur_op[i]]
#define NREG(i) interpreter->num_reg.registers[jit_info->cur_op[i]]
#define PREG(i) interpreter->pmc_reg.registers[jit_info->cur_op[i]]
#define SREG(i) interpreter->string_reg.registers[jit_info->cur_op[i]]
#define CONST(i) interpreter->code->const_table->constants[jit_info->cur_op[i]]
#ifndef MAP
# define MAP(i) jit_info->optimizer->map_branch[jit_info->op_i + (i)]
#endif
#define P_ARITH (((jit_info->prev_op) && (*jit_info->prev_op == 300)) || ((jit_info->prev_op) && (*jit_info->prev_op == 330)) || ((jit_info->prev_op) && (*jit_info->prev_op == 406)))
Parrot_jit_fn_info_t op_jit[] = {
{ Parrot_jit_normal_op, 1 }, /* op 0: Parrot_end */
{ Parrot_jit_normal_op, 1 }, /* op 1: Parrot_noop */
{ Parrot_jit_normal_op, 1 }, /* op 2: Parrot_cpu_ret */
{ Parrot_jit_normal_op, 1 }, /* op 3: Parrot_err_i */
{ Parrot_jit_normal_op, 1 }, /* op 4: Parrot_err_s */
{ Parrot_jit_normal_op, 1 }, /* op 5: Parrot_read_i_i */
{ Parrot_jit_normal_op, 1 }, /* op 6: Parrot_read_i_ic */
{ Parrot_jit_normal_op, 1 }, /* op 7: Parrot_read_n_i */
{ Parrot_jit_normal_op, 1 }, /* op 8: Parrot_read_n_ic */
{ Parrot_jit_normal_op, 1 }, /* op 9: Parrot_read_s_i_i */
{ Parrot_jit_normal_op, 1 }, /* op 10: Parrot_read_s_ic_i */
{ Parrot_jit_normal_op, 1 }, /* op 11: Parrot_read_s_i_ic */
{ Parrot_jit_normal_op, 1 }, /* op 12: Parrot_read_s_ic_ic */
{ Parrot_jit_normal_op, 1 }, /* op 13: Parrot_time_i */
{ Parrot_jit_normal_op, 1 }, /* op 14: Parrot_time_n */
{ Parrot_jit_normal_op, 1 }, /* op 15: Parrot_write_i_i */
{ Parrot_jit_normal_op, 1 }, /* op 16: Parrot_write_ic_i */
{ Parrot_jit_normal_op, 1 }, /* op 17: Parrot_write_i_ic */
{ Parrot_jit_normal_op, 1 }, /* op 18: Parrot_write_ic_ic */
{ Parrot_jit_normal_op, 1 }, /* op 19: Parrot_write_i_n */
{ Parrot_j
Re: Parrot doesn't compile: Parrot_end_jit() missing...
Leo --
After doing a make realclean:
$ find . -type f -exec grep -l 'end_jit' {} ';'
./include/parrot/jit_emit.h
./jit/i386/jit_emit.h
./t/src/basic_2
./t/src/intlist_1
./t/src/exit_1
./t/src/intlist_2
./t/src/exit_2
./t/src/intlist_3
./t/src/intlist_4
./t/src/list_1
./t/src/sprintf_1
./t/src/sprintf_2
./t/src/list_2
./libparrot.a
In include/parrot/jit_emit.h and jit/i386/jit_emit.h:
static void Parrot_end_jit(Parrot_jit_info_t *, \
struct Parrot_Interp *);
So, here I only have two instances of prototypes for
this function, and no implementations. The lack of
implementation is causing the compile failure. And,
the existence of the prototype in two places seems
like a bad idea...
Which file do you think has the implementation of
this function?
Regards,
-- Gregor
On Wed, 2003-07-02 at 11:48, Leopold Toetsch wrote:
> Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> > Here's the failure stuff from the build process:
>
> > gcc -o parrot -L/usr/local/lib test_main.o blib/lib/libparrot.a -lnsl
> > -ldl -lm -lpthread -lcrypt -lutil
> > blib/lib/libparrot.a(jit_cpu.o)(.text+0x2ce0): In function
> > `Parrot_jit_restart_op':
> >: undefined reference to `Parrot_end_jit'
>
> Strange. Parrot_end_jit is the first opcode function in the file.
>
> leo
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Parrot doesn't compile: Parrot_end_jit() missing...
Here's the failure stuff from the build process: gcc -o parrot -L/usr/local/lib test_main.o blib/lib/libparrot.a -lnsl -ldl -lm -lpthread -lcrypt -lutil blib/lib/libparrot.a(jit_cpu.o)(.text+0x2ce0): In function `Parrot_jit_restart_op': : undefined reference to `Parrot_end_jit' collect2: ld returned 1 exit status make: *** [parrot] Error 1 -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/ 6216 Eddington Drive, Suite B Liberty Township, OH 45044
Re: Perl and *ML
Dan -- Dan++ (Dan -- this is going to look familiar to you from prior IRC conversions IIRC, but I thought it could stand repeating in public). A good set of tree/graph primitives/utilities would be a wonderful addition IMO. And since XML is so common, I'd like to see it treated as a quotelike construct for producing trees (we already have qq for strings and qw for lists, etc.): my $foo = Hi there! would be one way to point $foo at one of these magical graph representations. If we had such a thing, plus an eval variant that only accepted plain old data (safe to use on untrusted sources because nothing active will be respected), we could pull info in from XML (and other) files easily, too. The construct in the example above could be parsed at compile time. In memory you've got the tree. If you are compiling to bytecode, the constant section could contain the list of SAX events (or equivalent) required to reproduce it (allowing some lazy possibilities BTW). Regards, -- Gregor Purdy Dan Sugalski <[EMAIL PROTECTED]> 03/26/2003 10:25 AM To: [EMAIL PROTECTED] cc: Subject:Perl and *ML I think that the issue here isn't so much good perl support for XML as it is good support for attributed DAGs, something which would be of general good use for perl, since the ASTs the parser feeds to the compiler will ultimately be DAGs of a sort. So, rather than jumping on the "XML [insert verb here]!" bandwagon, perhaps we'd be better served figuring out what would be useful operations and support for/on DAGs and suchlike things? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A6: Complex Parameter Types
Nick --
I've been thinking of it like this:
class int isa intlike; # and isa value or whatever
class Int isa intlike; # and isa Object or whatever
class num isa numlike; # and isa value or whatever
class Num isa numlike; # and isa Object or whatever
...
class Scalar isa intlike, numlike, ...; # and isa Object or whatever
The *like classes are placeholder (interface) classes that capture
the ability to *treat as* (as opposed to *really is*). And (importantly
IMO) the *like classes capture the aspects of foo and Foo that
are the same, leaving the foo and Foo classes to capture the
differences.
- - - - - - - - - - - - - - - - - - - - - -
A different way to handle Scalar would be to have Perl 6 allow
mutating objects (type changes). Scalar could be a superclass
of Int and Num, but it could be abstract (no instances allowed).
Values would be only of concrete types (e.g. Int, Num, Str). That
isn't very tricky, until you try to do
my $x = "5";
$x += 37;
Is $x the same object as it was before, but with a different internal
state, or is it now a completely different object (since its type
presumably changed to Int from Str)?
I'm not as comfortable with this, I have to admit. I like a single Scalar
class that has magical internal state and presents various "facets"
to the outside world (Int, Num, Str, ...). The magical internal state
can do things like maintain Int and Str values in parallel if it wishes
(which would be a strange thing for Int to do by itself, IMO).
- - - - - - - - - - - - - - - - - - - - - - - -
FWIW, I think Circle is a predicate on the set of Ellipses, so I'd say
Circle isa Ellipse. If I were using Eiffel, I'd use renaming and
overriding so that you could query the semimajor and semiminor
axes and radius, and get the same number in all three cases.
And, if you are working with a value that isa Circle, you may not
*set* the semimajor and semiminor axes (you have to set the
radius). Of course, this makes things ugly when you have a Circle
in an Ellipse variable. You'd like to take the fact that something
is an Ellipse to mean that you *can* set the axes separately,
since that is an Ellipse kind of thing to do. This smacks of an
argument for Ellipse and Circle being peers -- subclasses of
some other abstract helper class.
Or, to truly simplify, don't have a Circle class at all. Have an isCircle
predicate on Ellipse, which matches the mathematical case nicely.
Being able to do C and get back an
appropriate ellipse would still be nice, though.
I think the trouble comes from the fact that there are two kinds of
Circle that come up: Ellipse-in-general-but-Circle-right-now (loose,
or behavioral) and Circle-we-want-to-treat-as-Ellipse-sometimes
(strict, classical). You could definitely make an Ellipse class that
had an isCircle method, a radius-based constructor, and
getRadius and setRadius methods, and the only time it would let
you down is if you didn't check isCircle before calling getRadius,
because it would throw an exception (since there is no single
radius for a not isCircle Ellipse). It means your class is really
EllipseOrCircle, I guess.
For the strict case above, you would have to have though
ahead enough to have the Ellipse-like 'get' methods in one
place and teh Ellipse-like 'set' methods elsewhere. Circle
could inherit from the EllipseGettable but not EllipseSettable
(since you can ask for, but not set the semi axes).
Regards,
-- Gregor Purdy
Nicholas Clark <[EMAIL PROTECTED]>
03/15/2003 06:48 PM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
cc:
Subject:Re: A6: Complex Parameter Types
There seems to be some confusion about which way up the world is.
On Tue, Mar 11, 2003 at 01:25:41PM +1100, Damian Conway wrote:
> Which in turn is because:
>
>not Scalar.isa(int)
On Thu, Mar 13, 2003 at 11:55:06AM -0800, Larry Wall wrote:
> On Thu, Mar 13, 2003 at 11:31:30AM -0800, Austin Hastings wrote:
> : "Everyone Knows" that an Int is a Scalar, and therefore a sub that has
> : a Scalar parameter can safely be passed an Int. This is normal.
> I don't see a problem. Scalar == Int|Num|Str|Ref, so Scalar.isa("Int").
>
> Larry
On Thu, Mar 13, 2003 at 12:00:54PM -0800, Paul wrote:
> > I don't see a problem. Scalar == Int|Num|Str|Ref, so
> > Scalar.isa("Int").
>
> Scalar.isa("Int") && Int.isa("Scalar")
This term "subtyping" I didn't know:
On Fri, Mar 14, 2003 at 10:46:31AM -0800, Larry Wall wrote:
> Well, I'm using the terms type and class pretty much interchangeably
> there, so don't put too much weight on that. But Perl 6 may well
> distinguish classes from types. Classical classes can only add
> capabilities when you derive (yes, you can rede
Re: Associations between classes [was: Re: Object spec]
Seems like you are thinking along the lines of making Parrot support
Prevayler-style
http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html
stuff naturally and with less coding at the top layer. Is that where you
are headed with
this?
Regards,
-- Gregor Purdy
Sam Vilain <[EMAIL PROTECTED]>
Sent by: Sam Vilain <[EMAIL PROTECTED]>
03/05/2003 11:11 AM
To: [EMAIL PROTECTED], Paul <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc:
Subject:Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
> > Leave them out to carry on with the status quo of a myriad of subtly
> > different, non-interchangable approaches to associating classes.
> TMTOWTDI?
> Still, though your point is valid if I understand it, it will always be
> possible to create "non-interchangable approaches", and we don't want
> to dictate methods if we can help it.
> I think I need an exampleunfortunately I'm at work and haven't the
> time to properly peruse the one you offered. Thus I must apologize, and
> wait for more input.
Consider this excerpt from the test script:
my $joe = new Person(name => "Joe Average");
my $car = new Object(description => "Red Car");
$car->set_owner($joe);
ok($joe->posessions->includes($car), "Joe owns car");
The `Object' class has an association which it calls `owner', to class
`Person' (note: not all associations will be restricted to a particular
class). This is a collection that can only have one element so it is
implemented with a reference.
The `Person' class has an association which it calls `posessions' to class
`Object'. This is an unordered collection that can hold many elements so
it is implemented with a Set::Object.
They are the same relationship, and so setting the relationship from one
direction affects the other direction.
So, it makes sense to allow the same methods to access and update the
collections.
is($joe->get_posessions(0), $car, "Joe's first posession is his car");
ok($joe->posessions->includes($car), "Joe's posessions are a set");
ok($joe->posessions_includes($car), "Joe's set of posessions is
encapsulated");
These tests perhaps illustrate the level to which I've made them similar;
is($car->get_owner(0), $joe, "Refs can look like arrays");
ok($car->owner_includes($joe), "Refs can look like encapsulated sets");
eval { $car->owner->includes($joe) };
ok($@, "Refs cannot behave like real Sets");
To make the last test work would need associations in the object core, I
think.
--
Sam Vilain, [EMAIL PROTECTED]
Whatever you do will be insignificant, but it is very important that
you do it.
-- Mahatma Gandhi
Re: Object spec
> Are you speaking in terms of limitation, or requirement?
> It would be nice to have a syntax solution. I've seen p5 interfaces
> with stubs that die so that you have to override them in a subclass. It
> works, but seems a little kludgy.
Back in 1988 programming Objective-C under NeXTSTEP you could have a
class that does these things (based on methods inherited from Object):
- iJustCantSeemToGetAnythingDone
{
[self notImplemented:_cmd]; // TODO: We'd better write this soon!
}
- imFeelingAbstract
{
[self subclassResponsibility:_cmd];
}
- bogus
{
[self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
}
Also, there was a doesNotRecognize: method that was called by the runtime
system when method lookup failed. I presume you could override it to do
nasty things, but I never did that myself.
Regards,
-- Gregor
Re: Status of PXS and some IMHO obsolete ops
Leo / Dan -- Have we allocated PASM or IMC directives to replace the setline, setfile, and setpackage ops? * .file * .line [] * .package Should we have an indicator of the name of a sub, too? Regards, -- Gregor Leopold Toetsch <[EMAIL PROTECTED]> 02/23/2003 04:35 AM To: P6I <[EMAIL PROTECTED]> cc: Dan Sugalski <[EMAIL PROTECTED]> Subject:Status of PXS and some IMHO obsolete ops As stated in the thread "pxs help", the QT example can be expressed in terms of NCI. So IMHO the following opsen are obsolete: - loadext (unused) - callnative (only in QtHelloWorld.pasm, unimplemented) And further: - setline - setfile - setpackage which are already/ought to be in the PBC metadata. Putting "setline"s into the PBC stream would also slow down execution. leo
Re: non-inline text in parrot assembly?
Tupshin -- Parrot Byte Code (.pbc) files (aka packfiles) have multiple sections, but Parrot Assembly (.pasm) files do not reference them explicitly. Literal constants are *implicitly* placed in the constant section of the .pbc file upon assembly. The .constant or .const directives allow you to name your constants, but the net result is equivalent. Regards, -- Gregor Tupshin Harper <[EMAIL PROTECTED]> 02/22/2003 02:31 PM To: Leopold Toetsch <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject:Re: non-inline text in parrot assembly? Leopold Toetsch wrote: > You can use the .constant (PASM) or .const (IMCC) syntax, to keep > strings visually together. > > > leo > Thanks. Apparently I'm being daft. I don't see any mention of pasm sections(constant or otherwise) in the pod docs, nor do any of the examples appear to use a constants section. What am I missing? -Tupshin
Re: This week's Perl 6 Summary
> ...but Leo seem to think that... I agree with the policy of referring to Leo in the plural. Regards, -- Gregor
Segfault in substr_s_ic_ic_sc op
I've been tinkering with the queens.jako example, trying to make it work with strings instead of bit fields. Along the way, I had a parrot segfault aparently due to substr and a (null) string register. Its probably my fault such a call was being made, but I was surprised to see the result was a segfault. Consider this program: substr S0, 0, 1, " " # S0 is (null) here in a fresh interpreter print S0 end Should it: (a) Silently do something, such as print " " (but what if it were substr S0, 5, 2, " ")? (b) Complain, but do something, such as print " " (same "what if" as above)? (c) Complain and die? (d) Be undefined behavior until we have exceptions, at which point it will (c)? (e) Something else? I think any time Parrot segfaults it represents a bug. If no external code has been loaded, it is a Parrot bug for sure. BTW, I added the above test to my local copy of t/op/string.t, but for whatever reason it doesn't segfault there. I would expect it to behave exactly as it does outside the harness, unless the harness is reusing an interpreter, which means its not testing what the code fragments would do in a fresh interpreter... Regards, -- Gregor
Re: Change to the calling convention, and other fallout from last week's perl 6 meeting
Dan --
> *) There's going to be a bunch of named argument stuff that we should
> (though don't have to) put support in for. Perl 6 is going to make
> heavy use of them.
I may be terminologically challenged here (if so, please forgive), but
this sounds like passing a single pad as *the* argument, so the pad
gets inserted into the lookup chain. Various optimizations seem
possible:
* Caller knows canonical order, and pad has a way to designate
both name and offset. Caller specifies by index, and callee can get
at them by their indexes rather than names.
* Caller doesn't know canonical order, so slaps names and values
into a pad and hands it off to callee. Callee probably does
an ordering of things so the indexes are where they need to be
and uses indexed pad access from there on out.
Speed makes us want the insides of the subs to be implemented as
by-register (or at least by-index) even when the call is constructed
by-name.
Of course, there are some by-name semantics that don't fit this model.
You have the exists/defined ambiguity for missing args if you do
anything other than pass a hash or equivalent. So, I think some subs
might want to specify that they do get their args this way so they
can test whether an arg was specified or not (its essentially this:
by-hash would allow you to detect omitted by-name args, and by-pad
would just have them undef or otherwise defaulted [???]).
But, it makes me wonder if we should have metadata on call-points
and have the interpreter do the tinkering in the middle. This way,
a sub could be compiled into an named-pad-access, indexed-pad-access
or register-access form, and annotated as such. The caller can
construct its call in whichever way is convenient and the interpreter
maps on call.
# By name call pseudo-imc
.call foo
.arg{bar} 1
.arg{splee} $S3
.go
# By index call pseudo-imc
.call foo
.arg[0] 1
.arg[1] $S3
.go
I guess the interpreter would assume basic by-reg calling unless it
was able to access metadata for the sub. If it does find metadata
and there are names for the args, then it is possible to do by-name
calling.
I'm not clear, though, on what the Parrot representation of
sub quux {
print "baz= ", shift, "\n";
print "ni= ", shift, "\n";
}
would be. It smells like another arg convention: by-array (meaning
all args get slurped into a single array passed to the sub), or
possibly by-pad (with the @_ entry pointing to the args).
IMO, it should be possible for compiler writers to spit out their
calls and defs as IMC in terms natural to what they are doing, and
imcc and the interpreter should conspire to make things as fast as
possible and complain when things aren't compatible.
If we have metadata with names, Parrot types and canonical order
of the args, then any of the caller styles can be mapped to any
of the callee styles.
Regards,
-- Gregor
Re: Random questions...
Dan -- > Who's for, C's or perl's? C's for doesn't need an opcode. Perl's > arguably might, but I think we'll be better off putting the count of > things into an I register and iterating through the list as an array. Four words: Lazy Lists. Regards, -- Gregor
Re: [CVS ci] CGP - CGoto Prederefed runloop
leo++ Leopold Toetsch <[EMAIL PROTECTED]> 02/06/2003 07:37 AM To: P6I <[EMAIL PROTECTED]> cc: Subject:[CVS ci] CGP - CGoto Prederefed runloop This is one thing I allways wanted to try ;-) fast_core MOps: 11 Prederef: 17.5 CGoto MOps: 19.4 CGP MOps: 27.5 CGP -O3 MOps: 65 !!!1 This runloop combines the faster dispatch of opcodes via computed goto and the clever register addressing due to predereferencing registers and constants. And it's compact due to the fact that all opcode variants with constants collapse to just one implementation of the functions body. It's so compact, that my ancient gcc 2.95.2 even can compile it -O3, which didn't succeed with core_ops_cg.c. -rw-r--r-- 1 ltusers 618496 Feb 6 12:33 core_ops.c -rw-r--r-- 1 ltusers 665012 Feb 6 13:10 core_ops.o -rw-r--r-- 1 ltusers 219169 Feb 6 12:33 core_ops_cg.c -rw-r--r-- 1 ltusers 339312 Feb 6 13:10 core_ops_cg.o -rw-r--r-- 1 ltusers 154457 Feb 6 13:05 core_ops_cgp.c -rw-r--r-- 1 ltusers 165520 Feb 6 13:27 core_ops_cgp.o -rw-r--r-- 1 ltusers 219446 Feb 6 12:33 core_ops_prederef.c -rw-r--r-- 1 ltusers 240592 Feb 6 13:10 core_ops_prederef.o This runloop is now enabled with the -P switch. If you want to run the "normal" prederefed runloop then use '-P -g'. Have fun, leo
Re: [RfC] a scheme for core.ops extending
Leo -- >>>- a opcode gets more or less or changed params => you are as out of luck >>> with the old PBC as my approach is: invalidate PBC file. >> Nope. The op 'name' includes the number and types of the args, foo_i_ic. >> A "change" involves a new op and marking the old one obsolete. As far as >> existing bytecode is concerned an op signature change is equivalent to an >> op deletion and an op addition, and therefore should not be treated as a >> separate case. > I see. So you would need to keep the implementation of 'foo_i_ic' for > old PBCs and you would have 'foo_x_y_z', your new variant of this > opcode. Seems not the best idea too me, in terms of maintanability and > code size. Yep. But I don't see how this is different from what you proposed for new and obsolete ops. It just combines those two policies in the case where the op is a replacement with a different signature. You are free to truly delete the op if you want to, with the "missing op" implications below. >> Removing an op instead of marking it obsolete will cause the oplookup to >> fail, and the interpreter would report and error, just as with finger- >> printing. However, you would actually have more information to report, >> such as which op is missing from which oplib, which can be helpful in >> tracking down the problem. So, IMO, the finer granularity is useful both >> for evolution and for failure diagnosis. > So, how would the PBC with extended ops look like? You can take a static or dynamic approach. The static approach has you tacking the optable onto the PBC as a segment (yes, its bigger than a fingerprint). Small code segments will have small op gamuts (gama? :), larger code segments will likely have larger op gamuts (and thus larger op tables), but it would not be linear. The extreme dynamic approach involves a new oplib (boot.ops) with a new op called useop_ic_sc_sc. This op is prewired (not necessarily *hard* wired) to optable slot zero at startup. C fills in optable slots: useop 1, "foo", "bar_i_ic" So, instead of a formal optable segment in the packfile, you modify your optable any time you please. You might even overwrite slot zero, disabling further useopping. I would expect that it would be common to put all the optable mucking up front, but it doesn't have to be that way. Exercise for the reader: Write 6502.ops and a program to convert a chunk of 6502 machine code into a PBC file with a preamble that sets up op slots 0-255 with these ops, and a body that is a recasting of the machine code into 32-bit ops and arguments. Beware of data handling. (Of course, you can imagine variants of this op where the arguments can be registers instead of constants, too. If you need these, you could pull them in from some oplib.) There are variants of this idea where the first N op slots are reserved for the core ops, in some canonical order, and with room for growth. Dynamic ops would appear in slots N and up. This common-case optimization trades in some of the flexibility of the approach for speed by not having to do the dynamic building. Its not my favorite approach, but as long as the set of "core" ops is kept tight, it wouldn't hurt. The idea would be to make the core set just large enough that real-world programs wouldn't need very many dynamic ops (beyond what might be expected for language support, which is unavoidable). One objection to this approach could be PBC bloat, but I'd challenge that one on these grounds: We use 32-bit bytecode slots to hold 5-bit register numbers and < 10 bit opcode numbers, "wasting" many of the bits (they were traded for simplicity and speed). But, thats a lot of bits in a large program. It certainly makes one ponder a .pbcz zipped format (which screws mmappability, alas). Another objection is that it makes disassembly harder. The answer: yup. > Still mmap()able? Or name/signature of extension ops? Yes, still mmap()able. Bytecode still consists of integer indexes into an optable followed by integer references to registers and constants. > Your proposal looks like moving the assembler to runtime. Not really. This is a separate but equally interesting issue. Having IMCC available (loadable, anyway) is a good idea. Parrot code should be able to generate a string or other representation of of an IMC code chunk and invoke IMCC to convert it to bytecode. It should be possible to create and populate new in-memory code chunks and then call them. I like languages with good introspection capabilities. The ability to do things like define new classes at run time is a bonus, too. I'm interested in seeing similar capabilities in the underlying virtual machine (I guess I want to turn it into a malleable machine). Not only would I like to see dynamic optables, but I'd like a program to be able to find out about its op table, too. Oh, and I'd like to have indirect addressing modes where the register numbers come from other registers. Regards, -- Gregor
Re: [RfC] a scheme for core.ops extending
Leo -- > > > ... Having major changes in opsfiles will invalidate PBCs, as > > > e.g. a change from gcc 2.x to 3.x invalidates C++ object files. > > > > I disagree that it is too expensive, but I expect it will require > > hard data to settle the matter. Since this is my pet issue, I > > expect you won't be surprised when I say invalidating PBC files > > isn't necessary, and therefore we shouldn't feel obligated to > > follow past practice in that regard. > > So lets have a closer look: > > - a new opcode emerges => put it into a new opsfile. Done.[1] > (in the next major release, it can go, where it belongs to) I suggest putting it in with the other similar ops. A new core op in core.ops, a new math op in math.ops, whatever. > - a opcode is obsoleted => you can't delete it anyway, so keep it, > update docs. Aside: Begs the question: Should op metadata include an 'obsolete' tag? It would allow you to report on obsolete op use. > - a opcode gets more or less or changed params => you are as out of luck > with the old PBC as my approach is: invalidate PBC file. Nope. The op 'name' includes the number and types of the args, foo_i_ic. A "change" involves a new op and marking the old one obsolete. As far as existing bytecode is concerned an op signature change is equivalent to an op deletion and an op addition, and therefore should not be treated as a separate case. Removing an op instead of marking it obsolete will cause the oplookup to fail, and the interpreter would report and error, just as with finger- printing. However, you would actually have more information to report, such as which op is missing from which oplib, which can be helpful in tracking down the problem. So, IMO, the finer granularity is useful both for evolution and for failure diagnosis. When I first introduced fingerprinting, it was a quick hack to keep me out of trouble. I didn't want to spend a bunch of time debugging a problem only to discover it was caused by having a stale PBC. When I introduced the dynamic optable stuff, it was due to my fondness for the dynamic aspects of Perl and Parrot. I'm interested in pushing to see how deep the dynamic stuff can go. In the end, it may turn out that this stuff is possible but impractical... I haven't been able to come up with a way to determine that without trying it (and, :(, I have not had the time to actually try it out on a private copy -- in large part because the supporting infrastructure for dynamic oplibs isn't there yet, and its a big task to build that *and* do the fully dynamic experiment). Regards, -- Gregor
Re: [RfC] a scheme for core.ops extending
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep
your favorite halide handy. ]]
> > You need to account for the possibility that the number of ops in an
oplib
> > could change over its versions,
>
> This does invalidate the PBC, as it's currently done via fingerprinting.
The per-op approach makes fingerprinting obsolete, which is another
reason I'm for it.
> > I think this needs to be done at the op level, not at the oplib level
(as
> > I've
> > detailed before). I believe op{info,func} lookup by name is fast
enough
> > that this can be done as a preamble without too much trouble.
>
> Not really necessary and too expensive IMHO. The language/ops will
> stabilize. Having major changes in opsfiles will invalidate PBCs, as
> e.g. a change from gcc 2.x to 3.x invalidates C++ object files.
I disagree that it is too expensive, but I expect it will require
hard data to settle the matter. Since this is my pet issue, I
expect you won't be surprised when I say invalidating PBC files
isn't necessary, and therefore we shouldn't feel obligated to
follow past practice in that regard.
[...]
Regards,
-- Gregor
Re: [RfC] a scheme for core.ops extending
Leo --
You need to account for the possibility that the number of ops in an oplib
could change over its versions, and so depending on it being stable is
a losing proposition. That is exactly what is going on in the scheme
below,
where you append oplibs en their entirety to the code segment's optable.
I think this needs to be done at the op level, not at the oplib level (as
I've
detailed before). I believe op{info,func} lookup by name is fast enough
that this can be done as a preamble without too much trouble.
Generally, I'm in favor of a greater number of smaller oplibs, with the
option
for static or dynamic linking.
The main objection I know of is the implications for the fast runops
cores.
They tend to dislike dynamic optables. Although I haven't had the time
to do the JIT tinkering to prove it, I think the JIT machinery might be
sufficient to build the equivalent of a computed goto core for a dynamic
optable on the fly. IMO, solving that opens the door to very dynamic
stuff. However, it might still be a non-starter if we need cgoto-like
cores
on architectures for which we are not going to have JIT. I don't know
what the long-term policy on non-JIT architectures is (going to have them?
does the cgoto core have to work on them?).
Regards,
-- Gregor
Leopold Toetsch <[EMAIL PROTECTED]>
02/05/2003 06:28 AM
To: P6I <[EMAIL PROTECTED]>
cc:
Subject:[RfC] a scheme for core.ops extending
The interpreter depends on the various ops files for actually executing
byte code.
Currently all ops files except obscure.ops get logically appended and
built into core_ops_*.c. This makes for huge core_ops files, with a lot
of unused operations, bad cache locality and so on. It will get worse,
when different HLs have more needs for special ops like dotgnu.ops, we
now already have.
So here is a scheme that allows for a small core.ops, easy extension and
no execution speed penalty for non core ops.
1) core.ops is really core (ev. minus the trigonometric ops, which could
go into math.ops)
2) There is one additional opcode
oplib "opsname" # e.g. opsfile "math"
3) Additional opsfiles are either compiled statically into the
interpreter, or get loaded dynamically via Parrot_{dlopen, dlsym}
4) Above B opcodes have to appear in the assembler (i.e. imcc) in
the same order as during runtime, simplest, just put them at the
beginning.
5) When imcc encounters such a B, imcc loads the op_info of the
opsfile and appends it to the cores op_info
6) imcc thus spits out consecutive opcode numbers, like if these
opsfiles were appended to core.ops in the order they are seen.
7) During runtime the op_func_tables get appended to core.ops'
op_func_table and all loaded oplibs get a pointer to this common
op_func_table. So due to 4) there again is a op_jump_table entry for the
opcode number.
That's it, modulo some additions for prederef and JIT, compiled C would
need more work.
I wrote a test program, showing what's on using the CGoto core:
core.ops (5 ops) : end, noop, oplib, "op 3", "op 4"
math.ops (2 ops): add5, sub5 (internally 0 and 1, real 5 and 6)
math2.ops (2 ops) : mul5, div5 (=> 7 and 8)
Here is a test run of:
opcode_t prog3[] = {3,20, 4,21, 2,0, 2,1, 5,10, 7,10, 3,30, 8,20, 0};
op 3: 20
op 4: 21
oplib: math
*** found static lib 'math'
oplib: math2
*** found dynamic lib 'math2'
add5 5+10=15
mul5 5*10=50
op 3: 30
div5 20/5=4
end
The "2, 0" and "2, 1" ops are oplib "math" (statically linked) and oplib
"math2" (dynamically linked), the 0/1 operands point into the
constant_table.
Appended is the test program, systems without dlopen/dlsym would need
some work like in platform.c.
Have fun,
leo
ext_oplib.tgz
Description: Binary data
Re: Language Discussion Summaries
Sounds like a job for a bot! (couldn't resist) -- Gregor Jonathan Scott Duff <[EMAIL PROTECTED]> 02/04/2003 11:38 AM Please respond to duff To: Buddha Buck <[EMAIL PROTECTED]> cc: "Miko O'Sullivan" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject:Re: Language Discussion Summaries On Tue, Feb 04, 2003 at 10:56:34AM -0500, Buddha Buck wrote: > Miko O'Sullivan wrote: > >>And how do these differ in concept to the RFC process Perl 6 has already > >>gone through? Wouldn't it make sense, assuming that clean, final > >>presentations of proposed ideas or features in Perl are useful, to > >>re-open the RFC process? > > > > > > RFC's are proposals before the comments. The summaries are, well, > > summaries of the comments. My main concern is that Larry, Damian, et al, > > are likely to have a hard time reading through all the comments in the > > language list (Damian isn't even in the list right now), so the summaries > > are a way of letting them cut to the chase on the discussion of each idea. > > You are aware the that RFCs went through a revision process, and the > "finalized" RFCs that the Design Team are looking at are supposed to > include the final form of the idea after discussion, and a summary of > what was thought of it? Many of the RFCs weren't written until after > the idea had been discussed. Buddha Buck's comments aside, I think thread-summaries would be a useful thing. But probably only if we continue to have these long seemingly endless threads. Better might be someone who's there to shout "LET'S WRAP IT UP PEOPLE!" every now and then. And maybe that someone is Miko :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Bytecode metadata
b. -- I agree that under normal circumstances the bytecode is primary. I was observing that as more and more metadata is considered, eventually its quantity (measured, say, in bytes) could approach or even exceed that of the raw bytecode. In cases where one would feel such a quantity of metadata is needed, it may not always be necessary to get greased-weasel speed-of-loading (but, see below). I understand the the mmap-and-go idea, although it doesn't always work out even when mmap is available (for example, prederef requires a side pointer-array to store its prederef results). Sometimes its mmap-mumble-go (but, see below). Certainly, there is nothing to prevent one from having the linearized bytecode pregenerated in the PBC file even when a metadata tree is also present (the tree could reference contiguous chunks of that bytecode by offset-size pairs). If you don't care about the tree, you don't process it. If you do process it, you probably produce an index data structure mapping byte code offsets to tree nodes for the debugger. I believe we retain high speed with this approach. We do need to consider how the metadata makes it from the compiler *through* IMCC to land in the PBC file. The compiler needs to be able to produce annotated input to IMCC, and IMCC needs to be able to retain the annotations while it makes its code improvements and rendering (register mapping, etc.). I'm thinking that, too, could possibly be a tree. IMCC can pick out the chunks of IMC, generate bytecode, and further annotate the tree with the offset and size of the generated PBC chunk. The tree can be retained as the metadata segment in the PBC file. Regards, -- Gregor Juergen Boemmels <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 02/04/2003 08:15 AM To: [EMAIL PROTECTED] cc: Perl6 Internals <[EMAIL PROTECTED]> Subject:Re: Bytecode metadata [EMAIL PROTECTED] writes: > Mike -- > > Thats a lot of metadata. Sounds like maybe the metadata is primary > and the bytecode is secondary, in which case perhaps what you > really want is a (metadata) tree decorated with bytecode rather than > a (bytecode) array decorated with metadata. The bytecode is primary. This is whats get executed, this is what needs too be fast (both in startup time and runtime). Some kind of data is necessary for the bytecode, such as the string constants. These need also be accessed fast (don't know if this is called metadata, this is more data). The metadata is only needed in rare cases e.g. debugging, so it doesn't need to be as fast (but even here speed is nice) > Of course, the most natural candidate for the metadata would be the > annotated (file & line, etc.) parse tree, or some approximation to it > after compilation-related transformations. > > I can imagine a process that loads the tree, and linearizes the > bytecode with the metadata consisting of backpointers to nodes of > the tree, either in band as escaped noop-equivalent bytecode or > out of band in an offset-pointer table. Bytecode reading must be fast. Ideally it is mmap and start. Treewalking for bytecodegeneration should be done by the compiler. > With a suitable amount of forethought on the tree representation, > you should be able to have good flexibility while still having enough > standardization on how tree-emitting compilers represent typical > debug-related metadata (file, line, etc.) that debuggers and other > tools could be generic. The tree metadata can sure be some kind of intermediate output of the compiler (the output of the compiler front end), but normaly this should be fed into a backend which generates fast running bytecode or even native code. bye b. -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Bytecode metadata
Mike -- Thats a lot of metadata. Sounds like maybe the metadata is primary and the bytecode is secondary, in which case perhaps what you really want is a (metadata) tree decorated with bytecode rather than a (bytecode) array decorated with metadata. Of course, the most natural candidate for the metadata would be the annotated (file & line, etc.) parse tree, or some approximation to it after compilation-related transformations. I can imagine a process that loads the tree, and linearizes the bytecode with the metadata consisting of backpointers to nodes of the tree, either in band as escaped noop-equivalent bytecode or out of band in an offset-pointer table. With a suitable amount of forethought on the tree representation, you should be able to have good flexibility while still having enough standardization on how tree-emitting compilers represent typical debug-related metadata (file, line, etc.) that debuggers and other tools could be generic. Regards, -- Gregor James Michael DuPont <[EMAIL PROTECTED]> 02/04/2003 04:06 AM To: James Mastros <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Leopold Toetsch <[EMAIL PROTECTED]> cc: Nicholas Clark <[EMAIL PROTECTED]>, Brent Dax <[EMAIL PROTECTED]>, Dan Sugalski <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James Michael DuPont <[EMAIL PROTECTED]>, Dave Beckett <[EMAIL PROTECTED]>, introspectors <[EMAIL PROTECTED]>, Juergen Boemmels <[EMAIL PROTECTED]>, Dave Mitchell <[EMAIL PROTECTED]> Subject:Re: Bytecode metadata Dear All, I just wanted to ask about a conclusion on the bytecode metadata. Here are the things I would like to know about a given bytecode : what line (maybe column) it comes from Possible comments about it. If it is a method call, what is the method name,signature,locatoin If it is a variable or constant, what is the variable name, type, size If it is a expression , what is the type of it, the size For a given type, the name, size would be great to store. Is it going to be possible to store this data in the meta-data, it does not have to be all there at once, but will the framework handle it? Hopefully you have answered this already, and you can just say, rtfm. Thanks for you patience, i am a bit slow today. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: XML output of parse tree for Jako
James -- I'm open to other ideas. I've toyed with learning DAML and RDF for some ontology stuff I'm interested in, but so far I haven't had the mental "click" that would make me feel comfortable working with them. I do have a good comfort level with XML in general. I am pondering the sorts of transforms I could implement against the XML I've generated (using XSLT)... Another twist would be: can the compiler be reasonably implemented as a handler for the SAX events generated by the parser? If so, then the XML I'm generating today is just a textual rendering of the actual data structure passed from the parser to the compiler. I'm thinking this might be possible since a good amount of the optimization will occur in IMCC. Failing the pure SAX approach (which kind of implies single-pass), the other possibility would be DOM (accept the SAX events, build a tree and use DOM to tinker with it). XML is not a religion for me, but I am interested in pushing on it to see where the boundaries of practicality are. XML occupies the following slot in my map: A common way to render (annotated) tree structures (with ordered children) as (mostly) plain text. (of course, you can substitute "graph" for "tree" if you consider internal links). Already, tinkering with the XML rendering of the Jako parse tree has made me think more deeply about a few of the language issues. For example, I need to treat strings with interpolations as expressions rather than as string literals (I'm making this transformation on-the-fly in the compilation and SAX rendering of string "literals" now, but it *should* happen during parsing, making the interpolated string C<"Howdy $what world!"> result in the same parse structure as C<'Howdy ' . $what . ' world!'> -- the former is just syntactic sugar). Regards, -- Gregor James Michael DuPont <[EMAIL PROTECTED]> 02/03/2003 08:37 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject:Re: XML output of parse tree for Jako --- [EMAIL PROTECTED] wrote: > I just committed some changes to the Jako compiler that add a '-x' > switch. Using jakoc -x will cause the compiler to emit the parse tree > as XML (via SAX events sent to XML::Handler::YAWriter). > Sounds interesting. I have to look into this, i have dropped xml in favor of RDF, maybe we can find a common base. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
XML output of parse tree for Jako
I just committed some changes to the Jako compiler that add a '-x' switch. Using jakoc -x will cause the compiler to emit the parse tree as XML (via SAX events sent to XML::Handler::YAWriter). It still has some worts, but it didn't die when I turned it loose on the Jako examples. There are a few places where the current Jako syntax is restrictive (comparisons for if statements, for example) but I've made the XML look more generic (the conditional test is just another block). Also, the current parse tree leaves "return if x < 0" as an instance of "return" (with special annotations about the statement modifier), but the XML conversion turns it into a "return" inside a conditional. Regards, -- Gregor
Re: Parrot developer world map
Greg -- Thats the centroid. You can see its dual South of Australia. Regards, -- Gregor Greg Woodhouse <[EMAIL PROTECTED]> 01/31/2003 03:52 PM To: [EMAIL PROTECTED] cc: Subject:Re: Parrot developer world map So, what's the yellow dot in the middle of the Atlantic? --- [EMAIL PROTECTED] wrote: > An interactive SVG version is (temporarily) available at: > > http://www.focusresearch.com/gregor/map.html > > > Regards, > > -- Gregor > > > > > > Leon Brocard <[EMAIL PROTECTED]> > 01/28/2003 05:24 PM > > > To: [EMAIL PROTECTED] > cc: > Subject:Parrot developer world map > > > Last week I collected your data. This week I bring you pretty > pictures: > > http://www.astray.com/parrot/worldmap/ > > So London would seem a good place for a Parrot developer day, as > would > California. I guess most people will be meeting up at Perl > conferences > anyway. > > What do people have in mind for such a thing? A room, at least one > computer, an internet connection and a Plan? Are you looking to learn > more about Parrot or do you have something more specific in mind? > > Leon > > ps feel free to send in your location if you've forgotten to: > > -- > Leon Brocard.http://www.astray.com/ > scribot.http://www.scribot.com/ > > ... Famous last words - Don't worry, I can handle it > > > = Greg Woodhouse [EMAIL PROTECTED] It is better to be complex than complicated.
Re: Parrot developer world map
An interactive SVG version is (temporarily) available at: http://www.focusresearch.com/gregor/map.html Regards, -- Gregor Leon Brocard <[EMAIL PROTECTED]> 01/28/2003 05:24 PM To: [EMAIL PROTECTED] cc: Subject:Parrot developer world map Last week I collected your data. This week I bring you pretty pictures: http://www.astray.com/parrot/worldmap/ So London would seem a good place for a Parrot developer day, as would California. I guess most people will be meeting up at Perl conferences anyway. What do people have in mind for such a thing? A room, at least one computer, an internet connection and a Plan? Are you looking to learn more about Parrot or do you have something more specific in mind? Leon ps feel free to send in your location if you've forgotten to: -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Famous last words - Don't worry, I can handle it
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
AAron --
I think the point is that C<$x{$foo}> says "Hey C<$x>, y'know that
unordered
mess of stuff you've been keeping track of? Get me the one tagged $foo,
woudja?" while C<$x[$n]> says "yo C<$x>! Grab me the C<$n>-th thingee
in line over there, hey!". And, nothing prevents you wanting to use a
number for a tag in the first instance (so type doesn't disambiguate).
And,
nothing prevents you having a single object that allows both types of
abuse (like the tree stuff I posted about earlier). Thus, we retain two
different
(but related) notations: one for unordered access, one for ordered access.
Any given object may support none, one or both.
Regards,
-- Gregor
Aaron Sherman <[EMAIL PROTECTED]>
01/30/2003 03:15 PM
To: Damian Conway <[EMAIL PROTECTED]>
cc: Perl6 Language List <[EMAIL PROTECTED]>
Subject:Re: arrays, hashes unified indexing syntax impact on future
varia tion s
on other collection types
On Thu, 2003-01-30 at 14:21, Damian Conway wrote:
> People, the whole argument that $a[key] should be a homonym for both
> array-like and hash-like look-ups is
... a really bad argument to have, and I would not presume. When Perl
has tried to unify syntax in that way, it has ultimately failed (as you
note) to be coherent.
My question was, are these two different semantic operations, or are
they one operation with some type-sensitivity? Do curlies actually
resolve some fundamental ambiguity? I think we've demonstrated that they
don't, other than that ambiguity which exists already in the language,
outside of indexing operations.
What was the semantic tie between select and select? Even the tie
between the various gotos was pretty tenuous, and that caused problems.
This is a case where the indexing operator on one container class is
different from the indexing operator on another. Why? Because we had so
much spare syntax lying around? No. It was because a) AWK introduced the
idea and b) Perl1..5 had a "sigle denotes access, not type" model.
Those things are not terribly relevant to Perl 6, and as such, I'm not
sure why you feel that there's an imperative to use the Perl 5 notation.
Please enlighten me, Damian. I respect your deep understanding of this
language, and I'm willing to accept that you're intuitively grasping
something that I don't. All I see now is:
namevalue
namevalue
Which would seem to be easier written as:
value
value
value
Perhaps casting it in non-Perl syntax will free us from the bonds of our
preconceptions
--
Aaron Sherman <[EMAIL PROTECTED]>
This message (c) 2003 by Aaron Sherman,
and granted to the Public Domain in 2023.
Fight the DMCA and copyright extension!
Re: Arrays: is computed
Shouldn't access to 'is computed' arrays be read-only?
If you want to be able to consume the elements by shifting,
you can always create a tied object that kees a cursor and
a reference to the underlying array and gives you that
access (and it could die for splicing, etc.)...
Regards,
-- Gregor
Michael Lazzaro <[EMAIL PROTECTED]>
01/30/2003 02:25 PM
To: [EMAIL PROTECTED]
cc:
Subject:Arrays: is computed
For C arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)
Now setting an element:
@a[4] = 0;# (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2];# 4
@a[3];# 9
@a[4];# 0
@a[5];# 25 (still doesn't exist, is computed)
@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant
it)
Again, note the dubious behavior of doing a C or other
manipulation on any C array. The autofilled portion would
shift, but the computed portion would not:
my int @a is computed { $^index ** 2 }
# at first, @a is entirely computed,
(0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a;# (1,4,9,0) + (16,25,...)
shift @a;# (4,9,0) + (9,16,25,...)
shift @a;# (9,0) + (4,9,16,25,...)
shift @a;# (0) + (1,4,9,16,25,...)
shift @a;# () + (0,1,4,9,16,25,...)
Not saying that's wrong. Just very, very wacky. And yes, it's fixable
if every array has an "offset" number that's always updated to mark how
far the array has been shifted/unshifted from it's starting point. But
I'm not suggesting that. Really.
MikeL
