can somebody convert an MS Project 97 file for me?
If you have MS Project 98 or Project 2000 installed, and can load-and-save a project file for me, please mail me. adTHANSKvance -- Chip Salzenberg [EMAIL PROTECTED]
Re: Hi, it's me / yet another student trying to write a compiler targetting Parrot ;-)
Sven Schubert [EMAIL PROTECTED] wrote: Et voila. I bought Perl 6 and Parrot Essentials and installed Parrot 0.1.1 You might consider to update to the CVS version. A lot of things are improved or changed already. Parrot provides a general-purpose parser built on top of Perl 6's grammar engine...provides some utility code to transform a yacc grammar into a Perl 6 grammar , so languages that already use yacc can be moved over the Parrot's parser with a minimum amount of fuss. Yeah. The book is slightly ahead in future with some statements (as well as with the mentioned asynchronous IO :) Anyway, in CVS we have PGE the Parrot Grammar Engine. It implements parts of Perl6 rules and Perl5 regexen. You might also have a look at Subject: Parrot Syntax Engine posted here recently. Both are work in progress. cheers, Sven. leo
Hi, it's me / yet another student trying to write a compiler targetting Parrot ;-)
Hi all, I've been reading the internals list for a while more or less regularly and as this is me first post, it is about time, that I introduce myself: My name is Sven Schubert, I am studying information systems and business in Germany and currently I'm on an exchange program (ERASMUS for fellow euro-zone readers) studying a year abroad in Ireland (I.T. Carlow). Now, being here only for the (final) year, I'm not only to improve my English big time, but I'll have to get into compilers in general and Parrot in particular, as my final year project is baptised A Pascal Compiler for Parrot. Et voila. I bought Perl 6 and Parrot Essentials and installed Parrot 0.1.1 on my 2.6.5 linux here at college. Well, what I read sounded good and especially the following gave me some hope that I might actually get around re-inventing the wheel: (on page 102 P6PE) Parrot provides a general-purpose parser built on top of Perl 6's grammar engine...provides some utility code to transform a yacc grammar into a Perl 6 grammar , so languages that already use yacc can be moved over the Parrot's parser with a minimum amount of fuss. Has this 'general-purpose parser' been implemented yet? Is there _any_ documentation on that? I've skimmed through some of the languages that come with parrot, but I couldn't really figure out, if any of them is using Perl 6 grammars already. And where can I find this utilities that convert yacc grammars into P6-grammars? Any suggestions would be highly welcome. I am kinda aware, that I might just as well build a compiler from scratch that simply produces PASM or rather PIR, but the book seems to promise an easier way, especially, as there certainly are a number of already yacc'ed standard-Pascal grammars... Did I get something wrong here? Thanks a million, cheers, Sven. ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Something broke for me
Michel Pelletier [EMAIL PROTECTED] wrote: ... It only segfaults when *not* tracing. I'm still looking for the right snippet. You might also make sure that you aren't running into a DOD/GC bug. These kind of bugs sometimes show this Heisenbug behavior. Try: $ parrot -G ... # turn of DOD/GC $ parrot -Gt# same with tracing $ parrot --gc-debug # do more DOD runs $ parrot --gc-debug -t # w. trace If the bug vanishes with -G, then its likely to be a DOD/GC bug. -Michel leo
Re: Something broke for me
On Sun, 15 Aug 2004 11:19:44 +0200 Leopold Toetsch [EMAIL PROTECTED] wrote: Michel Pelletier [EMAIL PROTECTED] wrote: ... It only segfaults when *not* tracing. I'm still looking for the right snippet. You might also make sure that you aren't running into a DOD/GC bug. These kind of bugs sometimes show this Heisenbug behavior. Try: $ parrot -G ... # turn of DOD/GC This one does not segfault. $ parrot --gc-debug # do more DOD runs This one segfaults. If the bug vanishes with -G, then its likely to be a DOD/GC bug. Hmmm, that appears to be the case. That also makes sense that it happens only with sufficiently complicated Parakeet scripts. I suppose none of this is very helpful though without PIR reproduction. I'm going to try and put an hour or two tonight on finding a small PIR script that fails. -Michel
Re: Something broke for me
On Sat, 14 Aug 2004 09:17:25 +0200 Leopold Toetsch [EMAIL PROTECTED] wrote: Michel Pelletier [EMAIL PROTECTED] wrote: The first is multi-inheritance stopped working, but that's not as big a deal as the new problem. I've changed a few bits in object code during Pie-thon hacking, which is likely the cause for the problem. A small code snippet that exposes the error would be fine. Good news and bad, small multi-inheritance test scripts work fine for me, only my large test script segfaults. I'm still trying to boil it down to the minimal case tonight. Bad news is it's *weird*, when I turn on opcode tracing to find out exactly where it is (and I have a strange feeling it's the 'compile' opcode) the large script works fine. It only segfaults when *not* tracing. I'm still looking for the right snippet. 3) turn off line buffering $P0 = getstdout# PIR syntax $P0.setbuf(0) That did it for me, thanks! -Michel
Something broke for me
I've been developing Parakeet on a month old Parrot build, so today I decided to update to a recent checkout, and Parakeet broke two ways. The first is multi-inheritance stopped working, but that's not as big a deal as the new problem. Consider: .sub _main @MAIN BeginInteraction: getstdin $P0 print readline $S0, $P0 print $S0 goto BeginInteraction .end Print a prompt, read a line, print the line, print the prompt, a simplification of Parakeet's interpreter loop. it works on a month old parrot checkout just fine, but on a checkout done this afternoon it prints the prompt *after* it reads the line. [EMAIL PROTECTED]:~/dev/parrot$ ./parrot languages/test/test.imc one two one two Did I miss something that changed, or should I file a bug report? -Michel
Re: Something broke for me
At 11:24 AM -0700 8/13/04, Michel Pelletier wrote: I've been developing Parakeet on a month old Parrot build, so today I decided to update to a recent checkout, and Parakeet broke two ways. The first is multi-inheritance stopped working, but that's not as big a deal as the new problem. Gack -- it's a very big deal, and the test suite should've picked that up. D'you have a code snippet that demonstrates it, so we can fix the problem and get a test to help keep it happening in the future? Print a prompt, read a line, print the line, print the prompt, a simplification of Parakeet's interpreter loop. it works on a month old parrot checkout just fine, but on a checkout done this afternoon it prints the prompt *after* it reads the line. This one looks like an autoflush problem. I don't think we've ever formally defined what happens when you don't set the autoflush properties of filehandles,and I think some of Leo's IO optimizations for the piethon are causing a problem here. Doesn't look like we've defined how to set autoflushing for filehandles, so we'd best go do that. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Something broke for me
On Fri, 13 Aug 2004 16:40:12 -0400 Dan Sugalski [EMAIL PROTECTED] wrote: At 11:24 AM -0700 8/13/04, Michel Pelletier wrote: I've been developing Parakeet on a month old Parrot build, so today I decided to update to a recent checkout, and Parakeet broke two ways. The first is multi-inheritance stopped working, but that's not as big a deal as the new problem. Gack -- it's a very big deal, and the test suite should've picked that up. D'you have a code snippet that demonstrates it, so we can fix the problem and get a test to help keep it happening in the future? I should have been more clear, *Parakeet* multi-inheritance breaks, I have no proof that Parrot's is broke, or it just changed out from under me the way I'm using it. I'll try to come up with a simple test case tonight. Here's where it breaks in Parakeet: class C extends A meth testMethod 2 end end C new var c c - testMethod println # prints 2 # another for multi-inheritance class X meth xciting exciting! end end # multi-inheritance class D extends C extends X end D new var d d - testMethod println d - xciting println # seg-faults here after printing exciting! I ran into a seg-fault in the same place a couple weeks ago on my old build, but fixed it because each of my compiled functions and methods included my macros.imc file, which I didn't realize was totally redundant (I figured every use of the compile opcode started with a fresh compiler state, but I guess that's not the case, thank God). So speaking of pathalogical test cases, un-comment the last two lines of the following example to seg-fault (note that my macros.imc file, which I attached, is, weird). .sub _main @MAIN .local pmc pir .local pmc mysub compreg pir, PIR newclass $P0, one compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\one\]\n newclass $P1, two compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\two\]\n newclass $P2, three compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\three\]\n newclass $P3, four compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\four\]\n newclass $P4, five compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\five\]\n newclass $P5, six compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\six\]\n # uncomment to seg-fault # newclass $P6, seven # compile mysub, pir, .include \cruft/macros.imc\\n.namespace[\seven\]\n .end Include my macros.imc file more than seven times and boom. Print a prompt, read a line, print the line, print the prompt, a simplification of Parakeet's interpreter loop. it works on a month old parrot checkout just fine, but on a checkout done this afternoon it prints the prompt *after* it reads the line. This one looks like an autoflush problem. That was my first guess too. I don't think we've ever formally defined what happens when you don't set the autoflush properties of filehandles,and I think some of Leo's IO optimizations for the piethon are causing a problem here. Doesn't look like we've defined how to set autoflushing for filehandles, so we'd best go do that. Hmm, I'm suprised this didn't break a lot more stuff since it's just a simple input to output loop one would find about anywhere. Well, I'll wait for the configurable autoflush features and step back to the old build for now. -Michel macros.imc Description: Binary data
Do my debugging for me? (memory corruption)
I'm staring at a crash, my eyes are glazing over, and I need sleep. So
I was wondering if anyone would be interested in taking a look at a
.imc file that is giving me a seg fault while marking a hash in a gc
run triggered by a hash PMC allocation. Or at least tell me whether
it's seg faulting on your machine too.
I'll attach the 5KB compressed .imc file (25KB uncompressed; PIR code
is redundant!) It's generated from the following Perl6 code, but you'd
need my local changes in order to regenerate it:
rule thing() {
[a-z]+
}
rule parens() {
{ print entering parens\n; }
\( [ thing | parens | \s ]* \)
{ print leaving parens\n; }
}
sub main() {
my $t = ()()(((blah blah () blah))(blah));
my $t2 = $t _ );
print ok 8\n if $t2 !~ /^ parens $/;
}
(the entering/leaving parens printouts have no effect on the bug;
they're just remnants of my flailing.)
If you run with --gc-debug, it dies a little earlier, but in what
appears to be the same op.
Hopefully,
Steve
hash_bug.imc.gz
Description: GNU Zip compressed data
Re: Do my debugging for me? (memory corruption)
Steve Fink [EMAIL PROTECTED] wrote: I'm staring at a crash I'll attach the 5KB compressed .imc file (25KB uncompressed; PIR code Its really good, to have such short code snippets, that clearly show, where a bug is coming from ;) Anyway, it was again me causing this bug - sorry. Fixed and updated the comment which I didn't understand when removing it. Hopefully, Steve Thanks for the failure report, leo
Re: I scare me.
On Sat, Aug 02, 2003 at 01:49:05AM -0400, David H. Adler wrote: I'm sure it needs a few tweaks, but I've managed to write a hq9+ interpreter in pasm. Any thoughts on this? + isn't a portable file name character is it? So although Unix (and CVS) will be quite happy, it would not be a great idea naming a subdirectory hq9+ ? What should we call it prn.Im_told_CPM_still_has_its_claws_in_windows ? :-) Nicholas Clark
Re: I scare me.
On Sat, Aug 02, 2003 at 10:35:56AM +0100, Nicholas Clark wrote: On Sat, Aug 02, 2003 at 01:49:05AM -0400, David H. Adler wrote: I'm sure it needs a few tweaks, but I've managed to write a hq9+ interpreter in pasm. Any thoughts on this? + isn't a portable file name character is it? So although Unix (and CVS) will be quite happy, it would not be a great idea naming a subdirectory hq9+ ? What should we call it hq9p, same as the .pasm file. PS I think READ needs s/S1/S5/ if I'm reading it correctly. Otherwise everything after the 1024th character will be ignored, and then you couldn't write Enterprise Level hq9+ programs! -- Quit looking, kids! It'll EAT YOUR MIND!! -- http://www.angryflower.com/fuck.gif
I scare me.
I'm sure it needs a few tweaks, but I've managed to write a hq9+ interpreter in pasm. [insert deity here] help us all. :-) Any thoughts on this? http://www.thetasigma.com/parrot/ dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ It's all eggs, bacon, beans and a fried slice. - Madness
Re: [perl #18762] nci.t hates me
Alex Gough (via RT) wrote: # New Ticket Created by Alex Gough # Please include the string: [perl #18762] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18762 ... so using math.so is probably not the way to test the nci, instead a set of dummy functions ought to be provided by a little library of our own, and built as part of the build process. Yep, you are right. I just wanted a quick test, and libm ought to be on most systems - but it's really not the way to go. We need a test library with common function signatures, at best generated out from build_nativecall.pl, which should generate the tests too. Build system/test gurus wanted. leo
[perl #18762] nci.t hates me
# New Ticket Created by Alex Gough
# Please include the string: [perl #18762]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18762
t/pmc/nci.t doesn't like me or, at least, it doesn't like the way I
don't have a lrint in my math.h. My KR claims that everything in
math.h ought to return a double (well, anything you can validly expect
to find in every math.h), so using math.so is probably not the way to
test the nci, instead a set of dummy functions ought to be provided by
a little library of our own, and built as part of the build process.
Oh, and the test dumps core when it doesn't find the symbol, this is
probably not a good thing either.
[12:30AM]percy/parrot% perl -Ilib t/pmc/nci.t
1..2
ok 1 - nic_d_d
not ok 2 - nic_i_d
# Failed test (t/pmc/nci.t at line 28)
# got: 'Undefined symbol lrint
# '
# expected: 'loaded
# dlfunced
# ok 1
# '
# Looks like you failed 1 tests of 2.
(((
output_is('CODE', 'OUTPUT', nic_i_d);
loadlib P1, libm.so
print loaded\n
dlfunc P0, P1, lrint, id
print dlfunced\n
set N5, 4.1
invoke
ne I5, 4, nok_1
print ok 1\n
end
nok_1: print nok 1\n
print I5
print \n
end
CODE
loaded
dlfunced
ok 1
OUTPUT
)))
Alex Gough
--
Why on earth was William of Orange? (Seriously, though.)
Re: [perl #18762] nci.t hates me
t/pmc/nci.t doesn't like me or, at least, it doesn't like the way I don't have a lrint in my math.h. My KR claims that everything in math.h ought to return a double (well, anything you can validly expect to find in every math.h), so using math.so is probably not the way to test the nci, instead a set of dummy functions ought to be provided by a little library of our own, and built as part of the build process. lrint() is new in C99, so older libraries may not have it. For testing nci with a long return, why don't we use something more univarsal, like labs()? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[netlabs #593] Call me 00247
# New Ticket Created by Wild Cats # Please include the string: [netlabs #593] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=593 Hello I am your hot lil horny toy. I am the one you dream About, I am a very open minded person, Love to talk about and any subject. Fantasy is my way of life, Ultimate in sex play. Umm I am Wet and ready for you. It is not your looks but your imagination that matters most, With My sexy voice I can make your dream come true... Hurry Up! call me let me Cum for you.. TOLL-FREE: 1-877-451-TEEN (1-877-451-8336) For phone billing: 1-900-993-2582 -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
[netlabs #591] Call me 87596
# New Ticket Created by Wild Cats # Please include the string: [netlabs #591] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=591 Hello I am your hot lil horny toy. I am the one you dream About, I am a very open minded person, Love to talk about and any subject. Fantasy is my way of life, Ultimate in sex play. Umm I am Wet and ready for you. It is not your looks but your imagination that matters most, With My sexy voice I can make your dream come true... Hurry Up! call me let me Cum for you.. TOLL-FREE: 1-877-451-TEEN (1-877-451-8336) For phone billing: 1-900-993-2582 -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
[PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
I think that I have perhaps discovered the solution to my inability to
compile parrot after 0.0.4.
It turns out that many (all?) things were compiling. I got a parrot.o,
for example. So none of the suspected problems with long long or cgoto
are now suspect. I was, for some reason, failing to link at the end,
but for some reason cc didn't return an error, so make didn't return an
error.
It turns out that the flags beign passed to my linker were
-flat_namespace -L/usr/local/lib -L/sw/lib -flat_namespace [sic]
Removing the second -flat_namespace worked.
The two questions:
1. Why don't other people run into this? Does this not show up if
you've built a perl later than 5.6.1 (which, IIRC, don't require
the explicit argument of -Dldflags=-flat_namespace upon Configure)?
2. Why didn't this cause a problem in parrot-0.0.4, where the option
was also duplicated (as I have later checked)?
Anyway, with the following patch I can just acccept all the defaults in
Configure.pl, then make; make test with no problems.
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 03:45:49 -
@@ -1,5 +1,6 @@
$c{ccflags} .= -I/sw/include;
$c{ccflags} =~ s/-flat_namespace\s*//;
+$c{ldflags} =~ s/-flat_namespace\s*//;
$c{ldflags} .= -L/sw/lib -flat_namespace ;
$c{libs} .= -ldl;
$c{cc_warn} = -Wno-shadow
--
David Cogent Hand
http://davidhand.com/ mailto:[EMAIL PROTECTED] icq:4321282
Re: [PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Mon, Apr 22, 2002 at 12:00:31AM -0400, David Hand wrote:
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 03:45:49 -
-1,5 +1,6
$c{ccflags} .= -I/sw/include;
$c{ccflags} =~ s/-flat_namespace\s*//;
+$c{ldflags} =~ s/-flat_namespace\s*//;
$c{ldflags} .= -L/sw/lib -flat_namespace ;
$c{libs} .= -ldl;
$c{cc_warn} = -Wno-shadow
You sure about that patch? Looks like you're removing it and adding it
the next line.
Re: [PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Sun, Apr 21, 2002 at 09:24:26PM -0700, Steve Fink wrote:
On Mon, Apr 22, 2002 at 12:00:31AM -0400, David Hand wrote:
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 03:45:49 -
@@ -1,5 +1,6 @@
$c{ccflags} .= -I/sw/include;
$c{ccflags} =~ s/-flat_namespace\s*//;
+$c{ldflags} =~ s/-flat_namespace\s*//;
$c{ldflags} .= -L/sw/lib -flat_namespace ;
$c{libs} .= -ldl;
$c{cc_warn} = -Wno-shadow
You sure about that patch? Looks like you're removing it and adding it
the next line.
Well, -flat_namespace needs to be there that once, but only once.
What was happening to me was that it was being added even though it was
there. It seems rather easier to remove it if it exists and then
unconditionally add it, rather than looking for it and adding it if it's
not there.
Either way, though, really. Perhaps this instead?
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 04:32:28 -
@@ -1,5 +1,6 @@
$c{ccflags} .= -I/sw/include;
$c{ccflags} =~ s/-flat_namespace\s*//;
-$c{ldflags} .= -L/sw/lib -flat_namespace ;
+$c{ldflags} .= -L/sw/lib ;
+$c{ldflags} .= -flat_namespace unless $c{ldflags} =~ /-flat_namespace\s*/;
$c{libs} .= -ldl;
$c{cc_warn} = -Wno-shadow
--
David Cogent Hand
http://davidhand.com/ mailto:[EMAIL PROTECTED] icq:4321282
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
David Hand: Mind you that this is Mac OS X 10.1.3, with a UFS root partition. Just as a data point, CVS Parrot makes test fine under the same circumstances. Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. Well, you saw a ton of warnings. Have you compiled your own Perl, or are you using Darwin's Perl? -- The primary difference between a teenage male and an adult man is that a man has learned to think of something else *while* he's thinking of sex. - Mark Atwood
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
Simon Cozens: Just as a data point, CVS Parrot makes test fine under the same circumstances. Guh, spoke too soon: t/pmc/array.t 1 256 11 100.00% 1 t/pmc/perlstrin 1 256 81 12.50% 7 t/pmc/pmc.t 5 1280565 8.93% 49-53 -- I am familiar with this particular stupid user; it lives inside one's head and takes control at unexpected moments. - Roger Burton West
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, becauseI rather like it.
On Wed, 17 Apr 2002, Andy Dougherty wrote: On Wed, 17 Apr 2002, David Hand wrote: Mind you that this is Mac OS X 10.1.3, with a UFS root partition. This was compiled on the UFS partition. Interestingly, parrot 0.0.4 compiled okay. I recently tried compiling CVS parrot, but got similar errors to the below. I didn't have time to check it more, and as I appeared to be the only one to have this problem, I figured it was me just being broken. I dunno. How big would you like integers to be? [long long] What is your native opcode type? [long long] Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. If I had to guess, I'd guess this was the problem. This is probably not as heavily-tested a Configuration as the plain 'long' version, and most of that has probably been on little-endian systems, while I'll guess that Mac OS X is big-endian. Hmm. You could try again with just 'long'. I'll also try with 'long long' on SPARC, which often uncovers such issues Nope, bad guess on my part. Parrot 0.0.5+ (checked out this morning) did just fine with 'long long' opcode_t and INTVAL on SPARC Solaris 8. -- Andy Dougherty [EMAIL PROTECTED]
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Wed, Apr 17, 2002 at 01:40:39PM -0400, Andy Dougherty wrote: On Wed, 17 Apr 2002, Andy Dougherty wrote: If I had to guess, I'd guess this was the problem. This is probably not as heavily-tested a Configuration as the plain 'long' version, and most of that has probably been on little-endian systems, while I'll guess that Mac OS X is big-endian. Hmm. You could try again with just 'long'. I'll also try with 'long long' on SPARC, which often uncovers such issues Nope, bad guess on my part. Parrot 0.0.5+ (checked out this morning) did just fine with 'long long' opcode_t and INTVAL on SPARC Solaris 8. Trying CVS parrot as of 1400 EDT (why not?), it still didn't work. Interestingly, typing long both times that Configure suggests long long doesn't work, either. (I get what appears to be the same problem: scads of compiler errors/warnings, and fail basically all of the first few tests but test one. I'm running late for something called work that might, ahm, be important for me to go to one of these days.) Now, I get a *lot* of errors/warnings. For example ---BEGIN--- core_ops_cg.c:811: illegal expression, found `' core_ops_cg.c:812: illegal expression, found `' core_ops_cg.c:816: illegal statement, missing `identifier' after `goto' core_ops_cg.c:816: syntax error, missing `;' after `*' core.ops:65: illegal statement, missing `identifier' after `goto' core.ops:65: syntax error, missing `;' after `*' core.ops:95: illegal statement, missing `identifier' after `goto' core.ops:95: syntax error, missing `;' after `*' core.ops:113: illegal statement, missing `identifier' after `goto' core.ops:113: syntax error, missing `;' after `*' END (Copied from the border between those two errors.) I get pages and pages of each of those errors, in addition to others. Is *this* related to long long, too? -- David Cogent Hand http://davidhand.com/ mailto:[EMAIL PROTECTED] icq:4321282
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
Okay, on a whim, I tried `perl Configure.pl` again in both my parrot-0.0.4 and parrot-0.0.5 directories, accepting all defaults. The difference appears to be in the checking for computed goto. Of course, Configure.pl *does* warn me that I may see some errors. I have no idea why any of this would fail on my machine and work for others. I *have* been frobbing this machine pretty hard to get it to compile certain other things; perhaps that's what's going on? Whatever; such was the whim. And the errors/warnings here *are* the same or similar to many of the error message in compilation. Here we go: ---BEGIN `cd /usr/local/src/parrot-0.0.4; perl Configure.pl`--- 14:12:47 [cogent@localhost] parrot-0.0.4$ cd /usr/local/src/parrot-0.0.4; perl Configure.pl Parrot Version 0.0.4 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking the MANIFEST to make sure you have a complete Parrot kit... Okay, we found everything. Next you'll need to answer a few questions about your system. Defaults are in square brackets, and you can hit enter to accept them. If you don't want the default, type a new value in. If that new value starts with a '+', it will be concatenated to the default value. What C compiler do you want to use? [cc] How about your linker? [cc] What flags would you like passed to your C compiler? [-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -I/sw/include] What flags would you like passed to your linker? [-flat_namespace -L/usr/local/lib -L/sw/lib -flat_namespace ] Which libraries would you like your C compiler to include? [-ldb -lm -lc -ldl] How big would you like integers to be? [long long] And your floats? [double] What is your native opcode type? [long long] Now I have to find out what opcode files you would like to compile into your Parrot. The following opcode files are available: core.ops io.ops obscure.ops rx.ops WARNING: Bad Things may happen if the first file on the list isn't core.ops. WARNING: These file names will not be checked for spelling, and typing them wrong will force you to run Configure again. WARNING: I worry way too much about Configure users. Which opcode files would you like? [core.ops io.ops rx.ops] Determining if your C compiler is actually gcc (this could take a while): Your C compiler reports itself as gcc, major version 2, minor version 95. What gcc warning flags do you want to use? [ -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wno-shadow] Probing Perl 5's configuration to determine which headers you have (this could take a while on slow machines)... Determining C data type sizes by compiling and running a small C program (this could take a while): Building ./test.c from test_c.in... Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. Figuring out the formats to pass to pack() for the various Parrot internal types... Figuring out what integer type we can mix with pointers... We'll use 'unsigned int'. Building a preliminary version of include/parrot/config.h, your Makefiles, and other files: Building include/parrot/config.hfrom config_h.in... Building ./Makefile from Makefile.in... Building ./classes/Makefile from classes/Makefile.in... Building ./docs/Makefilefrom docs/Makefile.in... Building ./languages/Makefile from languages/Makefile.in... Building ./languages/jako/Makefile from languages/jako/Makefile.in... Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in... Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in... Building lib/Parrot/Types.pmfrom Types_pm.in... Building lib/Parrot/Config.pm from Config_pm.in... Checking some things by compiling and running another small C program (this could take a while): Building ./testparrotsizes.cfrom testparrotsizes_c.in... Updating include/parrot/config.h: Building include/parrot/config.hfrom config_h.in... Okay, we're done! You can now use `make' (or your platform's equivalent to `make') to build your Parrot. After that, you can use `make test' to run the test suite. Happy Hacking, The Parrot Team 14:13:11 [cogent@localhost] parrot-0.0.4$ END `cd /usr/local/src/parrot-0.0.4; perl Configure.pl` ---BEGIN `cd /usr/local/src/parrot-0.0.5; perl Configure.pl`--- 14:13:11 [cogent@localhost] parrot-0.0.4$ cd /usr/local/src/parrot-0.0.5; perl Configure.pl Parrot Version 0.0.5 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really,because I rather like it.
At 2:10 PM -0400 4/17/02, David Hand wrote: On Wed, Apr 17, 2002 at 01:40:39PM -0400, Andy Dougherty wrote: On Wed, 17 Apr 2002, Andy Dougherty wrote: If I had to guess, I'd guess this was the problem. This is probably not as heavily-tested a Configuration as the plain 'long' version, and most of that has probably been on little-endian systems, while I'll guess that Mac OS X is big-endian. Hmm. You could try again with just 'long'. I'll also try with 'long long' on SPARC, which often uncovers such issues Nope, bad guess on my part. Parrot 0.0.5+ (checked out this morning) did just fine with 'long long' opcode_t and INTVAL on SPARC Solaris 8. Trying CVS parrot as of 1400 EDT (why not?), it still didn't work. Interestingly, typing long both times that Configure suggests long long doesn't work, either. (I get what appears to be the same problem: scads of compiler errors/warnings, and fail basically all of the first few tests but test one. I'm running late for something called work that might, ahm, be important for me to go to one of these days.) Okay, that's bizarre. I'm going to try and track this down and see what I can do about that.
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Wed, Apr 17, 2002 at 02:40:16PM -0400, Dan Sugalski wrote: At 2:10 PM -0400 4/17/02, David Hand wrote: Trying CVS parrot as of 1400 EDT (why not?), it still didn't work. Interestingly, typing long both times that Configure suggests long long doesn't work, either. (I get what appears to be the same problem: scads of compiler errors/warnings, and fail basically all of the first few tests but test one. I'm running late for something called work that might, ahm, be important for me to go to one of these days.) Okay, that's bizarre. I'm going to try and track this down and see what I can do about that. Yeah, and just so that I can be even later to work, I tried again with int. Same thing. And, for whatever it's worth, I'm doing `make distclean` between each of these. And, again: parrot-0.0.4 *works*. Configures, compiles, tests. (The warnings it spits out while it compiles are fairly numerous, but, hey, Configure.pl told me that would happen.) -- David Cogent Hand http://davidhand.com/ mailto:[EMAIL PROTECTED] icq:4321282
Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
Okay, that's bizarre. I'm going to try and track this down and see what I can do about that. Before you get too far deep in it, I think David identified the problem in a later email. Basically, he has gcc 2.95 for Mac OS X. Unfortunatel,y, it doesn't seem to support computed goto. The Configure.pl was supposed to check if they correctly support cgoto, and disable it if they don't. Given his Configure.pl output, his compiler is failing to compile testcomputedgoto.c, but yet it is still choosing to use the CGoto core when compiling Parrot. The fact that this didn't exist in 0.0.4 would explain why that version works for him. I must admit to not having a full understanding of the configure whole configure process, and how to detect compile failures of stuff like this. Hopefully someone else with more experience can figure out why the cgoto detection isn't working for David? Thanks, Mike Lambert
parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
Okay, I can't find any documentation on how to send problem reports, so I hope this is sufficient and useful. If not, let me know: I've included the scrollback from `perl Configure.pl`, and the first pageful or so from `make`. (`make test`, of course, bombs completely, even though `make` doesn't error out.) Mind you that this is Mac OS X 10.1.3, with a UFS root partition. This was compiled on the UFS partition. Interestingly, parrot 0.0.4 compiled okay. I recently tried compiling CVS parrot, but got similar errors to the below. I didn't have time to check it more, and as I appeared to be the only one to have this problem, I figured it was me just being broken. I dunno. ---BEGIN perl Configure.pl SCROLLBACK--- 01:18:39 [cogent@localhost] parrot-0.0.5$ perl Configure.pl Parrot Version 0.0.5 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking the MANIFEST to make sure you have a complete Parrot kit... Okay, we found everything. Next you'll need to answer a few questions about your system. Defaults are in square brackets, and you can hit enter to accept them. If you don't want the default, type a new value in. If that new value starts with a '+', it will be concatenated to the default value. What C compiler do you want to use? [cc] How about your linker? [cc] What flags would you like passed to your C compiler? [-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -I/sw/include] What flags would you like passed to your linker? [-flat_namespace -L/usr/local/lib -L/sw/lib -flat_namespace ] Which libraries would you like your C compiler to include? [-ldb -lm -lc -ldl] How big would you like integers to be? [long long] And your floats? [double] What is your native opcode type? [long long] Now I have to find out what opcode files you would like to compile into your Parrot. The following opcode files are available: core.ops io.ops obscure.ops rx.ops vtable.ops WARNING: Bad Things may happen if the first file on the list isn't core.ops. WARNING: These file names will not be checked for spelling, and typing them wrong will force you to run Configure again. WARNING: I worry way too much about Configure users. Which opcode files would you like? [core.ops io.ops rx.ops] Determining if your C compiler is actually gcc (this could take a while): Your C compiler reports itself as gcc, major version 2, minor version 95. What gcc warning flags do you want to use? [ -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wno-shadow] Probing Perl 5's configuration to determine which headers you have (this could take a while on slow machines)... Determining C data type sizes by compiling and running a small C program (this could take a while): Building ./test.c from test_c.in... Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. Figuring out the formats to pass to pack() for the various Parrot internal types... Figuring out what integer type we can mix with pointers... We'll use 'unsigned int'. Building a preliminary version of include/parrot/config.h, your Makefiles, and other files: Building include/parrot/config.hfrom config_h.in... Building ./Makefile from Makefile.in... Building ./classes/Makefile from classes/Makefile.in... Building ./docs/Makefilefrom docs/Makefile.in... Building ./languages/Makefile from languages/Makefile.in... Building ./languages/jako/Makefile from languages/jako/Makefile.in... Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in... Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in... Building lib/Parrot/Types.pmfrom Types_pm.in... Building lib/Parrot/Config.pm from Config_pm.in... Checking some things by compiling and running another small C program (this could take a while): Building ./testparrotsizes.cfrom testparrotsizes_c.in... Still everything ok, let's check if we can use computed goto, don't worry if you see some errors, it will be all right, This could take a bit... Building ./testcomputedgoto.c from testcomputedgoto_c.in... testcomputedgoto.c:9: illegal expression, found `' testcomputedgoto.c:12: illegal statement, missing `identifier' after `goto' testcomputedgoto.c:12: syntax error, missing `;' after `*' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode Building ./Makefile from Makefile.in... Updating include/parrot/config.h: Building include/parrot/config.hfrom config_h.in
RE: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
David Hand:
# Okay, I can't find any documentation on how to send problem
# reports, so I hope this is sufficient and useful. If not,
# let me know:
#
# I've included the scrollback from `perl Configure.pl`, and
# the first pageful or so from `make`. (`make test`, of
# course, bombs completely, even though `make` doesn't error out.)
#
# Mind you that this is Mac OS X 10.1.3, with a UFS root
# partition. This was compiled on the UFS partition.
# Interestingly, parrot 0.0.4 compiled okay. I recently tried
# compiling CVS parrot, but got similar errors to the below. I
# didn't have time to check it more, and as I appeared to be
# the only one to have this problem, I figured it was me just
# being broken. I dunno.
Can you send the output of `make test' and attach the file
$parrot_directory/lib/Parrot/Config.pm? Thanks.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
[PATCH] Ok this has bugged me long enough
test_main needed an overhaul on options handling, and if/then/else was
breeding like rabbits. This one is 41 lines shorter and easier to read.
Please test before I commit.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.36
diff -u -r1.36 test_main.c
--- test_main.c 22 Jan 2002 00:53:35 - 1.36
+++ test_main.c 23 Jan 2002 19:49:56 -
@@ -27,6 +27,7 @@
int from_stdin;
int from_file;
char *filename;
+char **argp;
struct Parrot_Interp *interpreter;
init_world();
@@ -40,10 +41,10 @@
** -p profiling
** -P predereferencing
** -t tracing
+** -f filename or stdin
**
-** We really should use getopt, but are we allowed?
*/
-
+argp = argv+1;
flags= 0;
bounds_checking = 0;
profiling= 0;
@@ -55,102 +56,60 @@
from_file= 0;
filename = NULL;
-while (argc 1 argv[1][0] == '-') {
-if (argv[1][1] == 'b' argv[1][2] == '\0') {
-bounds_checking = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'j' argv[1][2] == '\0') {
-jit = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'p' argv[1][2] == '\0') {
-profiling = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'P' argv[1][2] == '\0') {
-predereferencing = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 't' argv[1][2] == '\0') {
-tracing = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'd' argv[1][2] == '\0') {
-debugging = 1;
-for(i = 2; i argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'f') {
-if (strcmp(-, argv[2]) == 0) {
-from_stdin = 1;
-}
-else {
-filename = malloc(strlen(argv[2])+1);
-filename = strcpy(filename, argv[2]);
-}
-for (i = 3; i argc; i++) {
-argv[i-2] = argv[i];
-}
-argc -= 2;
+while (*argp (*argp)[0] == '-') {
+if((*argp)[2] != '\0')
+internal_exception(PARROT_USAGE_ERROR,
+%s: Invalid switch: %s\n, argv[0], (*argp));
+
+switch((*argp)[1]) {
+case 'd': debugging = 1;
+argp++; break;
+case 'b': bounds_checking = 1;
+argp++; break;
+case 'j': jit = 1;
+argp++; break;
+case 'p': profiling = 1;
+argp++; break;
+case 'P': predereferencing = 1;
+argp++; break;
+case 't': tracing = 1;
+argp++; break;
+case 'f': argp++;
+printf(-f flag\n);
+if(strcmp(-, (*argp)) == 0) {
+from_stdin = 1;
+} else {
+filename = malloc(strlen((*argp))+1);
+filename = strcpy(filename, (*argp));
+}
+argp++; break;
+default:
+internal_exception(PARROT_USAGE_ERROR,
+%s: Invalid switch: %s\n,
+argv[0], (*argp));
}
-else {
-internal_exception(PARROT_USAGE_ERROR, %s: Invalid switch:
%s\n, argv[0], argv[1]);
-}
}
+flags |= (debugging == 1 ? PARROT_DEBUG_FLAG : 0);
+flags |= (profiling == 1 ? PARROT_PROFILE_FLAG : 0);
+flags |= (bounds_checking == 1 ? PARROT_BOUNDS_FLAG : 0);
+flags |= (jit == 1 ? PARROT_JIT_FLAG : 0);
+flags |= (predereferencing == 1 ? PARROT_PREDEREF_FLAG : 0);
+flags |= (tracing == 1 ? PARROT_TRACE_FLAG : 0);
-if (debugging) {
+if(debugging)
fprintf(stderr, Parrot VM: Debugging enabled.\n);
-flags |= PARROT_DEBUG_FLAG;
-}
-if (bounds_checking) {
-flags |= PARROT_BOUNDS_FLAG;
-}
-
-if (jit) {
#if !JIT_CAPABLE
- internal_exception( JIT_UNAVAILABLE, %s: Cannot use the '-j'
JIT-enabling flag on this architecture: JIT_ARCHNAME \n, argv[0]);
-#else
-flags |=
Re: [PATCH] Ok this has bugged me long enough
Eek, don't apply that, I see a bug, I'll post a new one in a sec. -Melvin At 02:52 PM 1/23/2002 -0500, Melvin Smith wrote: test_main needed an overhaul on options handling, and if/then/else was breeding like rabbits. This one is 41 lines shorter and easier to read. Please test before I commit. -Melvin Index: test_main.c ===
Re: JIT me some speed!
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote: In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. It does seem to be quite impressively fast. Faster even than the compiled version of mops on my machine... It looks like it is going to need some work before it can work for other instruction sets though, at least for RISC systems where the operands are typically encoded with the opcode as part of a single word and the range of immediate constants is often restricted. I'm thinking it will need some way of indicating field widths and shifts for the operands and opcode so they can be merged into an instruction word and also some way of handling a constant pool so that arbitrary addresses can be loaded using PC relative loads. I've been thinking about this, and worrying somewhat if I'm in danger of trying to make a something run before it can walk, but in trying to think how to make an ARM jit. I don't know how typical ARM is of RISC CPUs, but it's probably enough food for thought. I may have made some minor technical errors in this: All our JIT code would be running in user mode on ARM, so we only get to play with the user mode bank of 16 general purpose registers, named r0-r15 general purpose in quotes because r15 is the program counter, one (now always r13) is the stack pointer and the ABI specifies uses for some others. I assume that we're not generating shared library code (if we are, the ABI claims r9 from us) The ABI needs 6 registers to call another function, a called function has the first 4 integer arguments passed in using r0-r3, and returns a result in r0. However in the body of a function we can arrange to use 2 of those reserved 6, so we have 12 registers for our use, of which r4-r9 will be preserved across function calls. Memory loads and stores have to be done relative to a base register (which can be r15, the PC), +- a constant (in the range 0-4095) or another register (optionally shifted by a constant). There is no direct way to load a register with an arbitrary 32 bit constant. Registers can be loaded with an immediate constant stored in 12 bits as 8 bit value rotate right 2 * 4 bit value (So you can load 0xFF in one instruction (4 bytes), for something like 0xFFF it's best to express it in 2 instructions (8 bytes) as load 0xFF, add 0xF00, and for complex values stuff it in a data word within 4092 bytes of the PC and load it PC relative, which is also 8 bytes, but possibly slower) The upshot of this is that loading integer register values by substituting addresses into template code is not an easy way to go. Much better would be to load up r4 to r7 with the base addresses of the integer, floating point, string and PMC registers and do a load integer register 16 into r0 as ldr r0, [r4, #60] @ parrot registers start at 1, don't they? [maybe I am already in danger of trying to run before I can walk, as I suspect that the address substitution can be shoe-horned as ldr r0, [pc, #-4] @ oops - may have got the pipeling wrong here b .L1 .word @ substitute your address here ..L1 ldr r0, [r0] but that's something like 5 CPU cycles rather than 2.] I'm in danger of wanting to run before I can walk. And maybe I should shut up for now as I'm describing a possible next generation JIT, rather than this one: The reason I'd feel I'd naturally want to define Parrot_set_i_i not as 1 code snippet, but as load parrot integer register (from memory) into CPU register n # do nothing here store CPU register n to parrot integer register (to memory) is because even with a more complex JIT syntax that lets me translate setI2, I4 as ldr r0, [r4, #12] str r0, [r4, #4] with r4-r7 loaded with those base addresses, I'm wasting most of the ARM CPU: I've got r1-r3, r8, r9, r12 and r14 that I'm not even using. I've got to be careful in what I'm suggesting here: I'm *not* suggesting that I (or anyone else) immediately writes a JIT that maps CPU registers to parrot registers and attempts to keep values in the CPU where possible. I *am* suggesting that if Parrot_set_i_i is defined as input: load parrot integer register (from memory) into CPU register n body: output: store CPU register n to parrot integer register (to memory) where the JIT provides that load and store code (rather than each op) then the work that goes into writing body code for the ops is still useful and usable with a second (third?) generation JIT that does know how to combine 2 or more adjacent Parrot ops. Possibly also useful thoughts: For things like generating constants for ARM, it would be useful to be able to specify alternative code generation snippets, with some
Re: .ops metadata [was: Re: JIT me some speed!]
On Mon, Dec 24, Gregor N. Purdy wrote:
Nicholas --
Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
Dan likes C-like syntax as much as possible in other parts of the ops
file. Thats why I chose 'inline' as the tag for 'trivial' ops (although
that's a C++-ism).
More than one C compiler uses 'inline' as an extension to hint
at inlining code under optimization. As we are effectively defining
our own compiler...
If we didn't mind the verbosity, a C-like syntax would be:
inline op set(register INTVAL, const register INTVAL) {
$1 = $2;
}
instead of
inline op set(i, i) {
$1 = $2;
}
The problem is, we lose the nice space/time/etc. saving capability of:
inline op set(i, i|ic) {
$1 = $2;
}
FWIW, I like the 'C-ish' version. It makes it accessible to folks
who know C, not a mongrel language which may or may not even exist.
Note that in the last version above, we are _not_ saying that
the second argument is the result of evaluating a bitwise OR
on 'i' and 'ic'.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED]printf %d, 0x2a;
-- deep thought
Re: .ops metadata [was: Re: JIT me some speed!]
Jason --
Making the distinction between the three cases enables a number of
optimizations of native code based on analysing data flow. 'in' would be good
as an implicit default, as many PMC opcodes will not overwrite any PMC
registers.
An optimizing native code generator (whether static or JIT) will also need to
be aware of operands that may implicitly clobber parrot register values or
modify control flow, so that it knows when it musth spill updated parrot
register values in hardware registers back to their memory locations and when
it must reload hardware registers from main memory.
I had considered something like this, using Apocolypse 2 properties, and
'sub' instead of 'op':
sub set(INTVAL $1 is written, INTVAL $2 is read) is inline {
$1 = $2;
goto NEXT();
}
# ...
sub branch(INTVAL $1 is read) is inline nonlinear {
goto OFFSET($1);
}
Heck, that's almost Perl. In fact, we *could* go all the way to named
args:
sub set(INTVAL $target is written, INTVAL $source is read) is inline {
$target = $source;
goto NEXT();
}
# ...
sub branch(INTVAL $dest is read) is inline nonlinear {
goto OFFSET($1);
}
We could even use adverbial-looking notation for gotos:
sub set(INTVAL $target is written, INTVAL $source is read) is inline {
$target = $source;
goto : next;
}
# ...
sub branch(INTVAL $dest is read) is inline nonlinear {
goto : offset $dest;
}
Finally, we could use the Perl 6 no-funny-business typenames:
sub set(int $target is written, int $source is read) is inline {
$target = $source;
goto : next;
}
# ...
sub branch(int $dest is read) is inline nonlinear {
goto : offset $dest;
}
We could take 'written' as implying 'register' and not 'constant'; and
'read' (without 'written') could imply 'constant' and not 'register'.
We could automatically treat those 'read' args as we do 'x|xc' today.
We could automatically treat those 'written' args as we do 'x' today.
This moves us in the direction of very-Perl-looking .ops code vs. semi-
C-looking .ops code, which wouldn't bother me. I can live with C-like
or Perl-like syntax here. Note, though that we *are* using Perl-style
comments and POD documenjtation, which means that Perl-like syntax would
be consistent.
One Perl thing we would be breaking is subroutine name overloading.
We'd have 'set' in there multiple times, once for each register type. To
get around this, we'd have to name them set_[inps] and make sure we've
got the C function name generation logic doing The Right Thing. Not
insurmountable.
The code that does the .ops file reading could be made to permit any
number of tags. Stashing them in the Parrot/opblib/*.pm file is easy.
Stashing them in *_ops.c won't be hard if we just treat them like an
array of strings with a NULL terminator, probably sorted. Harder to
use than flag bits, but extensible. Either way would work.
Regards
-- Gregor
/Inspiration Innovation Excellence (TM)\
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
From 85.83.77.67: Time to live exceeded
Re: JIT me some speed!
I think we should leave all that for an optimizer. Daniel Grunblatt. On Mon, 24 Dec 2001, Nicholas Clark wrote: On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote: It looks like it is going to need some work before it can work for other instruction sets though, at least for RISC systems where the operands are typically encoded with the opcode as part of a single word and the range of immediate constants is often restricted. I'm thinking it will need some way of indicating field widths and shifts for the operands and opcode so they can be merged into an instruction word and also some way of handling a constant pool so that arbitrary addresses can be loaded using PC relative loads. Another thing that struck me on reading it was: =item CBIRIn Place the address of the CINTVAL register specified in the Inth argument. RISC chips have lots of general purpose registers. It's likely that there will be enough spare that several can be used to map to parrot registers. Say 4 are available, it would be useful to be able to say that an op requires the value of rN and rM, and modifies rD. The JIT compiler would make a sandwich with the code to read in N and M into two of the real CPU registers, the op filling, and then some more code to write D back to memory. However, if the JIT can see that N is already in memory from the previous OP, or D is going to be used and modified by the next op, it can skip, defer or whatever some of the memory reads and writes. [And provided the descriptions are this helpful it doesn't have to do it immediately. It becomes possible to write a better optimising JIT that makes sandwiches with multiple fillings or even Scooby Snacks, while the initial JIT insists that the only recipe available is bread, 1 filling, bread] mops will be fast if REDO: subI4, I4, I3 if I4, REDO maps to REDO: load I4 from memory (which will be in the L1 cache) load I3 from memory I4 = I4 - I3 store I4 to memory load I4 from memory is it 0? goto REDO if true it will be slightly faster if it maps to REDO: load I4 from memory (which will be in the L1 cache) load I3 from memory I4 = I4 - I3 store I4 to memory # I4 still in a CPU register is it 0? goto REDO if so and faster still if the JIT can see how to push things out of the loop: load I4 from memory load I3 from memory REDO: I4 = I4 - I3 is it 0? goto REDO if so store I4 to memory (does threading mess this idea up?) Nicholas Clark
Re: JIT me some speed!
Oh, and by the BTW, I already tried you fastest example last week and got 50x speed up, but that's works only for mops, so ... Daniel Grunblatt. On Mon, 24 Dec 2001, Nicholas Clark wrote: On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote: It looks like it is going to need some work before it can work for other instruction sets though, at least for RISC systems where the operands are typically encoded with the opcode as part of a single word and the range of immediate constants is often restricted. I'm thinking it will need some way of indicating field widths and shifts for the operands and opcode so they can be merged into an instruction word and also some way of handling a constant pool so that arbitrary addresses can be loaded using PC relative loads. Another thing that struck me on reading it was: =item CBIRIn Place the address of the CINTVAL register specified in the Inth argument. RISC chips have lots of general purpose registers. It's likely that there will be enough spare that several can be used to map to parrot registers. Say 4 are available, it would be useful to be able to say that an op requires the value of rN and rM, and modifies rD. The JIT compiler would make a sandwich with the code to read in N and M into two of the real CPU registers, the op filling, and then some more code to write D back to memory. However, if the JIT can see that N is already in memory from the previous OP, or D is going to be used and modified by the next op, it can skip, defer or whatever some of the memory reads and writes. [And provided the descriptions are this helpful it doesn't have to do it immediately. It becomes possible to write a better optimising JIT that makes sandwiches with multiple fillings or even Scooby Snacks, while the initial JIT insists that the only recipe available is bread, 1 filling, bread] mops will be fast if REDO: subI4, I4, I3 if I4, REDO maps to REDO: load I4 from memory (which will be in the L1 cache) load I3 from memory I4 = I4 - I3 store I4 to memory load I4 from memory is it 0? goto REDO if true it will be slightly faster if it maps to REDO: load I4 from memory (which will be in the L1 cache) load I3 from memory I4 = I4 - I3 store I4 to memory # I4 still in a CPU register is it 0? goto REDO if so and faster still if the JIT can see how to push things out of the loop: load I4 from memory load I3 from memory REDO: I4 = I4 - I3 is it 0? goto REDO if so store I4 to memory (does threading mess this idea up?) Nicholas Clark
.ops metadata [was: Re: JIT me some speed!]
Nicholas --
Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
Dan likes C-like syntax as much as possible in other parts of the ops
file. Thats why I chose 'inline' as the tag for 'trivial' ops (although
that's a C++-ism).
If we didn't mind the verbosity, a C-like syntax would be:
inline op set(register INTVAL, const register INTVAL) {
$1 = $2;
}
instead of
inline op set(i, i) {
$1 = $2;
}
The problem is, we lose the nice space/time/etc. saving capability of:
inline op set(i, i|ic) {
$1 = $2;
}
But, we could still adopt the C-ism 'const' as meaning read-only, and
assume all non-const arguments are written:
inline op set(i, const i|ic) {
$1 = $2;
}
Or, do we really need to have the three-way in/out/inout tagset?
inline op set(out i, in i|ic) {
$1 = $2;
}
Regards,
-- Gregor
/Inspiration Innovation Excellence (TM)\
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
From 85.83.77.67: Time to live exceeded
RE: .ops metadata [was: Re: JIT me some speed!]
Gregor N. Purdy:
# Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
#
# I'm tempted to push the specification of this information all the way
# back to the syntax of .ops files, since the code that lives there
# should behave the same wrt read/write on args.
#
# Dan likes C-like syntax as much as possible in other parts of the ops
# file. Thats why I chose 'inline' as the tag for 'trivial' ops
# (although
# that's a C++-ism).
#
# If we didn't mind the verbosity, a C-like syntax would be:
#
# inline op set(register INTVAL, const register INTVAL) {
# $1 = $2;
# }
#
# instead of
#
# inline op set(i, i) {
# $1 = $2;
# }
#
# The problem is, we lose the nice space/time/etc. saving capability of:
#
# inline op set(i, i|ic) {
# $1 = $2;
# }
#
# But, we could still adopt the C-ism 'const' as meaning read-only, and
# assume all non-const arguments are written:
#
# inline op set(i, const i|ic) {
# $1 = $2;
# }
#
# Or, do we really need to have the three-way in/out/inout tagset?
#
# inline op set(out i, in i|ic) {
# $1 = $2;
# }
Or we could go with the Perl 6-ism:
inline op set(i is rw, i|ic) {
$1=$2;
}
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
Nothing important happened today.
--George III of England's diary entry for 4-Jul-1776
Re: JIT me some speed!
Dan and Michael -- $ ./test_parrot -j examples/assembly/mops.pbc Illegal instruction That's not supposed to happen is it? Its Linux/PowerPC, so maybe it is supposed to happen. It's sort of supposed to happen. It shouldn't work, at least--we need better error checking and such, so the -j is disabled on systems we don't support yet. Today's the day guards in interpreter.c / test_main.c go in so you get yelled at instead of barfed on in this case. Regards, -- Gregor /Inspiration Innovation Excellence (TM)\ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \/ [[EMAIL PROTECTED]]$ ping osama.taliban.af PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data. From 85.83.77.67: Time to live exceeded
Re: JIT me some speed!
All -- $ ./test_parrot -j examples/assembly/mops.pbc Illegal instruction That's not supposed to happen is it? Its Linux/PowerPC, so maybe it is supposed to happen. It's sort of supposed to happen. It shouldn't work, at least--we need better error checking and such, so the -j is disabled on systems we don't support yet. Today's the day guards in interpreter.c / test_main.c go in so you get yelled at instead of barfed on in this case. The code is in. Regards, -- Gregor /Inspiration Innovation Excellence (TM)\ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \/ [[EMAIL PROTECTED]]$ ping osama.taliban.af PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data. From 85.83.77.67: Time to live exceeded
Re: JIT me some speed!
On Fri, 21 Dec 2001, Tom Hughes wrote: In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. It does seem to be quite impressively fast. Faster even than the compiled version of mops on my machine... It looks like it is going to need some work before it can work for other instruction sets though, at least for RISC systems where the operands are typically encoded with the opcode as part of a single word and the range of immediate constants is often restricted. I'm thinking it will need some way of indicating field widths and shifts for the operands and opcode so they can be merged into an instruction word and also some way of handling a constant pool so that arbitrary addresses can be loaded using PC relative loads. I suspect it is also rather questionable to call system calls directly rather than going via their C library veneers - that is even more true when you come to things (like socket calls) which are system calls on some machines and functions on others. We are not always calling system calls directly, we can use the C library when ever we need it, check out the .jit syntax. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: JIT me some speed!
In message [EMAIL PROTECTED] Daniel Grunblatt [EMAIL PROTECTED] wrote: On Fri, 21 Dec 2001, Tom Hughes wrote: I suspect it is also rather questionable to call system calls directly rather than going via their C library veneers - that is even more true when you come to things (like socket calls) which are system calls on some machines and functions on others. We are not always calling system calls directly, we can use the C library when ever we need it, check out the .jit syntax. I did have a brief look last night but I must have missed that. No problem that front then. Incidentally the JIT times are definitely impressive... Times for a 1.33 GHz Athlon are like this: dutton [~/src/parrot] % ./test_parrot ./examples/assembly/mops.pbc Iterations:1 Estimated ops: 2 Elapsed time: 4.806858 M op/s:41.607220 dutton [~/src/parrot] % ./test_parrot -j ./examples/assembly/mops.pbc Iterations:1 Estimated ops: 2 Elapsed time: 0.300258 M op/s:666.093736 dutton [~/src/parrot] % ./examples/assembly/mops Iterations:1 Estimated ops: 2 Elapsed time: 0.324787 M op/s:615.788117 Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: JIT me some speed!
Don't forget that (if I'm missing somthing) by the time that pbc2c.pl work with all the ops it will be much slower than the jit. Daniel Grunblatt. On 21 Dec 2001, Tom Hughes wrote: In message [EMAIL PROTECTED] Daniel Grunblatt [EMAIL PROTECTED] wrote: On Fri, 21 Dec 2001, Tom Hughes wrote: I suspect it is also rather questionable to call system calls directly rather than going via their C library veneers - that is even more true when you come to things (like socket calls) which are system calls on some machines and functions on others. We are not always calling system calls directly, we can use the C library when ever we need it, check out the .jit syntax. I did have a brief look last night but I must have missed that. No problem that front then. Incidentally the JIT times are definitely impressive... Times for a 1.33 GHz Athlon are like this: dutton [~/src/parrot] % ./test_parrot ./examples/assembly/mops.pbc Iterations:1 Estimated ops: 2 Elapsed time: 4.806858 M op/s:41.607220 dutton [~/src/parrot] % ./test_parrot -j ./examples/assembly/mops.pbc Iterations:1 Estimated ops: 2 Elapsed time: 0.300258 M op/s:666.093736 dutton [~/src/parrot] % ./examples/assembly/mops Iterations:1 Estimated ops: 2 Elapsed time: 0.324787 M op/s:615.788117 Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: JIT me some speed!
In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. It does seem to be quite impressively fast. Faster even than the compiled version of mops on my machine... It looks like it is going to need some work before it can work for other instruction sets though, at least for RISC systems where the operands are typically encoded with the opcode as part of a single word and the range of immediate constants is often restricted. I'm thinking it will need some way of indicating field widths and shifts for the operands and opcode so they can be merged into an instruction word and also some way of handling a constant pool so that arbitrary addresses can be loaded using PC relative loads. I suspect it is also rather questionable to call system calls directly rather than going via their C library veneers - that is even more true when you come to things (like socket calls) which are system calls on some machines and functions on others. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: JIT me some speed!
Dan Sugalski [EMAIL PROTECTED] wrote: To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. $ ./test_parrot -j examples/assembly/mops.pbc Illegal instruction That's not supposed to happen is it? Its Linux/PowerPC, so maybe it is supposed to happen. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: JIT me some speed!
On Thu, 20 Dec 2001, Michael G Schwern wrote: Dan Sugalski [EMAIL PROTECTED] wrote: To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. $ ./test_parrot -j examples/assembly/mops.pbc Illegal instruction That's not supposed to happen is it? Its Linux/PowerPC, so maybe it is supposed to happen. It's sort of supposed to happen. It shouldn't work, at least--we need better error checking and such, so the -j is disabled on systems we don't support yet. dan
JIT me some speed!
Thanks to the work of Daniel Grunblatt, we now have JIT capabilities in parrot. It's in the latest CVS, ready for your use and abuse. To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of 35x) but it's a darned good place to start. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Licensing and source. READ ME, DAMMIT!
At 04:25 AM 12/5/2001 -0500, James Mastros wrote: On Tue, 4 Dec 2001, Dan Sugalski wrote: This also means no writing your own license terms for code you submit. (Licensed under the same terms as perl counts as writing your own...) Umm, AFACS (Though AINAL, and ISGCBAP (I should get caught by the acronym police) but Under the same terms as _parrot_ should be fine. If it's in the parrot distribution it ought not even *have* licensing terms attached to it. That's what the package license is for... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Licensing and source. READ ME, DAMMIT!
Folks, We're nailing down the license finally for Parrot, and should have things set. Until then... DO NOT SUBMIT CODE THAT ISN'T YOURS! This *includes* from perl 5. (Like, say, the code in utf8.[ch]) If you didn't write it, or did but don't want to abide by the bits about licensing in the README, then don't submit it. This also means no writing your own license terms for code you submit. (Licensed under the same terms as perl counts as writing your own...) Sorry, that's life. When we do have this sorted out, any code from other projects with compatible licensing *must* be attributed in both the checkin and comments in the source, unless you are owner of said code in the first place, in which case it's from you and not the project. Yes, licensing is a pain, and yes the hoops suck. 'Tis life. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Me
I will be on vacation in Disney World from now until Sunday night. Therefore, if you need me I won't be here :) Tanton
Re: Magic [Slightly Off-Topic... please point me to documentation]
On Tue, 6 Feb 2001 17:53:17 -0200, Branden wrote:
It appears you're blessing one reference and returning another... like
sub new {
my $key;
my $a = \$key;
my $b = \$key;
bless $a;
return $b;
}
I think the problem is not with the overloading magic, but with the code
snippet...
A recent thread on comp.lang.perl.misc discussed how bless() works with
the reference, but alledgedly, it's the underlying thing that gets
blessed, not the reference itself.
my $a = \$x;
my $b = \$x;
bless $a, 'FOO';
print $b;
--
FOO=SCALAR(0x8a652e4)
It sure looks that they're right. Oh, this is perl 5.6.0.
--
Bart.
Magic [Slightly Off-Topic... please point me to documentation]
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
No, you attach the magic to a value. Perl just doesn't copy
magic when it copies data. Whether this is a good thing or
not is up in the air. (Half the time I want it to, the other
half I don't...)
Is there a good discussion of magic, copying magic etc. in the core perl
documentation? Or elsewhere for that matter? Any documentation, pointers,
general tips, etc. would be greatly appreciated.
I was recently bit by overloading magic in the Class::Context generic
constructor which the following code illustrates. If you return "another"
reference to a scalar which was blessed, instead of the blessed reference,
then you loose your magic. I'm trying to keep Class::Contract (which I'm
maintaining for Damian) overload friendly... But Perl magic on my map is
labelled "there be dragons".
package foo;
use overload '""' = 'asString';
sub asString { 'Hello World' }
package bar;
@ISA = qw(foo);
sub new { bless \my $key; \$key }
package baz;
@ISA = qw(foo);
sub new { my $ref = \ my $key; bless $ref; $ref }
package main;
my ($bar, $baz);
$bar = bar::-new();
$baz = baz::-new();
print "bar $bar\n";
print "baz $baz\n";
Results In:
bar bar=SCALAR(0x1bbfc9c)
baz Hello World
Re: Magic [Slightly Off-Topic... please point me to documentation]
At 11:46 AM 2/6/2001 -0600, Garrett Goebel wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]] No, you attach the magic to a value. Perl just doesn't copy magic when it copies data. Whether this is a good thing or not is up in the air. (Half the time I want it to, the other half I don't...) Is there a good discussion of magic, copying magic etc. in the core perl documentation? Or elsewhere for that matter? Any documentation, pointers, general tips, etc. would be greatly appreciated. Nope. I was recently bit by overloading magic in the Class::Context generic constructor which the following code illustrates. If you return "another" reference to a scalar which was blessed, instead of the blessed reference, then you loose your magic. I'm trying to keep Class::Contract (which I'm maintaining for Damian) overload friendly... But Perl magic on my map is labelled "there be dragons". Dragons is right. It's a dicey area, and past that most extensions handle magic values flat-out wrong. (Including most of mine, so I've no room to talk...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Magic [Slightly Off-Topic... please point me to documentation]
Magic [Slightly Off-Topic... please point me to documentation]Garrett Goebel
wrote:
I was recently bit by overloading magic in the Class::Context
generic constructor which the following code illustrates. If
you return "another" reference to a scalar which was blessed,
instead of the blessed reference, then you loose your magic.
I'm trying to keep Class::Contract (which I'm maintaining for
Damian) overload friendly... But Perl magic on my map is
labelled "there be dragons".
Only blessed objects can be overloaded, not references. Only a class can
have overloading behaviour, and a plain reference belongs to no class, so it
should have no overloading behaviour. Contrast this use of \$key with having
[1,2,3]. Do you think this array reference should have any overloading
behaviour? Or else, try to define a method in package bar and try to call it
from $bar, like $bar-foo. Won't work either, you have to ${$bar}-foo.
Overloading should loose the magic in the same sense that the method should
not be called.
package bar;
@ISA = qw(foo);
sub new { bless \my $key; \$key }
You return a reference to the object...
package main;
my ($bar, $baz);
$bar = bar::-new();
$baz = baz::-new();
print "bar $bar\n";
print "baz $baz\n";
Try printing $$bar, it will work...
- Branden
RE: Magic [Slightly Off-Topic... please point me to documentation]
From: Branden [mailto:[EMAIL PROTECTED]]
try to define a method in package bar and try to call it
from $bar, like $bar-foo. Won't work either, you have
to ${$bar}-foo. Overloading should loose the magic
in the same sense that the method should not be called.
No, $bar-asString and $baz-asString both work. They produce:
Hello World
package bar;
@ISA = qw(foo);
sub new { bless \my $key; \$key }
You return a reference to the object...
No, it returns an object reference... Try it.
Try printing $$bar, it will work...
No, it doesn't. $$bar is an undefined scalar.
sub new { my $ref = \ my $key; bless $ref; $ref }
and
sub new { bless \ my $key; \$key; }
Both return an object reference. The former has magic, the latter does not.
I'm sorry... I didn't mean to start an off-topic thread. Unless someone can
find a way to shoe-horn in a discussion of language or internals magic
handling for Perl6? Is there really no substantial documentation anywhere
on magic? I suppose that is why it is called magic, eh?
package foo;
use overload '""' = 'asString';
sub asString { 'Hello World' }
package bar;
@ISA = qw(foo);
sub new { bless \my $key; \$key }
package baz;
@ISA = qw(foo);
sub new { my $ref = \ my $key; bless $ref; $ref }
package main;
my ($bar, $baz);
$bar = bar::-new();
$baz = baz::-new();
print "\$bar$bar\n";
print "\$baz$baz\n";
print "\$bar-asString ", $bar-asString, "\n";
print "\$baz-asString ", $baz-asString, "\n";
print "\$\$bar ", $$bar, "\n";
Results In:
$barbar=SCALAR(0x1bbfc9c)
$bazHello World
$bar-asString Hello World
$baz-asString Hello World
$$bar
Re: Magic [Slightly Off-Topic... please point me to documentation ]
On Tue, Feb 06, 2001 at 01:38:56PM -0600, Garrett Goebel wrote: I'm sorry... I didn't mean to start an off-topic thread. This is currently being discussed on p5p, so you might want to take it over there. Is there really no substantial documentation anywhere on magic? Not yet. This looks like something that we can fix. What I'll try and do, although I make no promises, is make sure that either Tim or I [1] finds out all about magic, writes up some documentation and pushes some of it back to perlguts.pod, since it looks like there is definitely a crying need for people to understand this. I suppose that is why it is called magic, eh? Yup! [1] Tim Jenness has written a section about magic in a book we're writing on Perl and C interaction. However, what we've got at the moment isn't much more than what's in perlguts. -- "Darkly hinting of head hitting desk" -- Megahal (trained on asr), 1998-11-05
Re: Magic [Slightly Off-Topic... please point me to documentation]
Garrett Goebel wrote:
package bar;
@ISA = qw(foo);
sub new { bless \my $key; \$key }
It appears you're blessing one reference and returning another... like
sub new {
my $key;
my $a = \$key;
my $b = \$key;
bless $a;
return $b;
}
I think the problem is not with the overloading magic, but with the code
snippet...
- Branden
[READ ME!]Perl 6's temporary code licensing[READ ME!]
(Ask, can we get the below added to the perl6-internals welcome message? Thanks) Folks, It's about time to start into the serious work on perl 6. Unfortunately we don't quite yet have the final license for perl 6, which makes any code submissions a touch dicey. Until we have a final license in place, all code should: 1) Have its copyright assigned to Larry Wall or 2) Be licensed under the current perl 5 license scheme with the explicit provision that it may be later re-licensed under whatever scheme is devised for perl 6. or 3) Be placed in the public domain If you're not comfortable with any of them and want to wait until we have a final license in place, that's fine. (And quite understandable) However... ALL CODE POSTED TO THE PERL6-INTERNALS LISTS (OR ANY OF ITS SUB-LISTS) FROM THIS POINT ON IS ASSUMED TO BE USING SCHEME #2 ABOVE UNLESS OTHERWISE NOTED! And *please* do *NOT* post any code to the lists that's not covered by one of the above schemes. I really, really do not want to be misusing anyone's code even by accident. When we have a final licensing scheme in place, all submissions to the lists will be assumed to be submitted to the perl 6 project and included under that final license. (And we'll make a general announcement when that's the case) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Summary...tell me where I'm worng...
Graham Barr writes:
Why would the fuzzy regex not be done this way ?
I have some small objections:
I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing. If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module that doesn't use =~ and qr//.
I also think that lexically scoped RE engines are useless.
You want the engine scoped to the pattern, so you can mix
and match fuzzy with traditional (e.g., search engine has
box for pattern and buttons for regular RE or fuzzy, and
all you need to do is say:)
$pattern = param("pattern");
if (param("fuzzy")) {
$re = qr/$pattern/f;
} else {
$re = qr/$pattern/;
}
# ...
while (FILE) {
print if /$re/;
}
My big objection to a dynamically loadable core is my
experience (admittedly limited) with GNOME and Mozilla.
They're big Big BIG ... fat Fat FAT ... pigs Pigs PIGS.
I see the plethora of componentized libraries as part of
the problem. I fear Perl becoming a big fat pig too.
Nat
Summary...tell me where I'm worng...
Just trying to catch up. This is where I understand the discussion stands: INTERNALS(?) modular language: Scanner/Symbol Table/Parser/Executor Standard Functions separate from core (moving to language?) Modules Separate from everything (definitely language) Strict(er) DataTypes: Automatic Type Conversion(?) (internal or language?) Native Size Allocation (Internal or language?) Items still under general discussion: Formats (probably language if it stays) Garbage Collection (internals?) RegEx (internals?) localtime() (arrays start at 0 or 1) (language) Backward compatibility in general (who knows) If someone could just tell me where these discussions go (as many aren't really defined yet) I would be grateful. Also, If I have missed anything let me know, Grant M. [EMAIL PROTECTED]
RE: Summary...tell me where I'm worng...
Perl's regex syntax in not poorly documented (IMHO, of couse). Some of the new stuff is. (Poorly documented, that is.) MRE made me feel like a ghod (after I read chapter 7 for the third time ;) Some of the new stuff's not in MRE, which is, I suppose, partly why Jeffrey Friedl's working on a new edition (and trawling up a rich haul of bugs in the process -- see the p5p list). Of course, documentation in MRE II would lay that particular complaint of mine to rest (six feet deep in a in a lead-lined casket). -- Dominic Dunlop
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 07:03:42AM -0400, Grant M. wrote: Just trying to catch up. This is where I understand the discussion stands: INTERNALS(?) modular language: Scanner/Symbol Table/Parser/Executor Internals. Standard Functions separate from core (moving to language?) Some of each. Modules Separate from everything (definitely language) Yes. Strict(er) DataTypes: Automatic Type Conversion(?) (internal or language?) Native Size Allocation (Internal or language?) Language for now. Items still under general discussion: Formats (probably language if it stays) Garbage Collection (internals?) RegEx (internals?) Yes, Yes, Yes. localtime() (arrays start at 0 or 1) (language) Yes. Backward compatibility in general (who knows) Script Backward compatibility = language. XS Backward compatibility = here (later) if someone volunteers to write the code to make old XS code work with the new APIs. If someone could just tell me where these discussions go (as many aren't really defined yet) I would be grateful. Also, I'd say "if in doubt then it's not for perl6-internals, at least not for now". I'd also say there's not much point at the moment in discussing details of implementing features that we're not pretty sure will be in the language. I think there's _lot's_ of valuable work we can do here we can do here prior to the language being firmed up. If we start getting into details of other things we won't make progress on the basics, like vtable interfaces for SV and libraries, analysis of GC implementations etc. We need to be pretty sure of most of those kind of issues by the time the language gets firmed up. Tim.
Re: Summary...tell me where I'm worng...
At 15:19 +0100 2000-08-01, Tim Bunce wrote: RegEx (internals?) Yes, Yes, Yes. I could argue for regex being language too: it's a little language, and it's got very crufty of late. Yes, it's sexy cruft which can be justified because it allows one to do neat things which were previously difficult or impossible (or merely verbose). But it's also more or less poorly documented, more or less poorly understood, more or less well-used, and more or less poorly tested. (Indeed, some of it's still marked as experimental.) If the language group is going to give each of perl's reserved words (and much else besides) the third degree so as to decide whether it should stay in the core, be cast into outer darkness, or end up somewhere in between, then I'd say that the same should be done for the language supported by the regex engine. Once the language group has decided what are the required and optional features of the regex language, then the internals folks can start working out how to make it fly (or tell the language folks it won't). Pluggable regex engines would make supporting (say) core and optional regex language features easier. Want me to write this up as an RFC? -- Dominic Dunlop
