William Coleda [EMAIL PROTECTED] wrote:
Is it sufficient to provide a mechanism for the compiler writers to indicate
that tail call should be used? For example, I have a few cases in tcl where I
have something like:
($I0,$P0) = interpret($P1)
.return($I0,$P0)
Where I'd be happy to
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
Hi,
I am trying to pass a string, containing YAML, from Parrot to the shared
library 'libsyck'.
void syck_parser_str( SyckParser *, char *, long, SyckIoStrRead ); (
v_ptip )
^^
SYMID syck_parse( SyckParser * );
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
But, in a tail-call-optimization case, we don't need to call
new_register_frame() and copy_regs()--ex hypothesi, we can re-use the
register frame already in-place. That's a big savings--that's the
Dan Sugalski wrote:
From strings.pod I gather that the op 'pin' is meant to
make strings fit for passing strings to external libraries.
Sort of. The point is to make the string not move. Generally for
external libraries, but not universally.
It shouldn't add the trailing null, because that
Larry Wall wrote:
On Sat, Nov 06, 2004 at 10:37:39PM +0100, Juerd wrote:
: Larry Wall skribis 2004-11-06 13:32 (-0800):
: Easy, just one of
: my $named := anonymous();
: my @named := anonymous();
: my %named := anonymous();
: my named := anonymous();
: my ::named :=
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
...it sounds like we have an easy way to tell if a real continuation
has a claim on the register frame, because creating such a real
continuation can mark the frame,
There is no such mark. If ctx-current_cont
Leopold Toetsch wrote:
This means that the string buffer has to stay around, until the
parsing is
done.
This is what the t signature char is doing anyway - Oops or better,
what it should to. While it's using string_to_cstring the created string
isn't freed (unless the library would free it,
What generates runtime/parrot/library/config.pbc ?
It seems that make clean can remove it, and then any subsequent make fails:
$ make all
Compiling with:
xx.c
cc -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I/usr/local/include -g
-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline
James Mastros skribis 2004-11-11 3:55 (+0100):
It would seem, then, that the answer is there's some property of
thingies that gives the name that error messages will use to refer to
them. (I want to thank the man who made thingy the proper technical
term, BTW.) So what's it called?
Well
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
This is what the t signature char is doing anyway - Oops or better,
what it should to. While it's using string_to_cstring the created string
isn't freed (unless the library would free it, which is unlikely).
Actually
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
[ refcounting continuations ]
That's really not needed. If you return from the function and you call
it next time, you've again a RetContinuation. If the continuation was
created somewhere deeper in
I believe that I've now fixed all the bugs and made pmc2c2.pl emit accurate
#line directives in the C source files it generates. This means that C errors
in PMC files under development will be reported by the C compiler as being at
the correct line in the source PMC file, rather than the
At 11:15 AM +0100 11/11/04, Bernhard Schmalhofer wrote:
Leopold Toetsch wrote:
This means that the string buffer has to stay around, until the parsing is
done.
This is what the t signature char is doing anyway - Oops or better,
what it should to. While it's using string_to_cstring the created
Nicholas Clark wrote:
What generates runtime/parrot/library/config.pbc ?
It's an extension rule .imc.pbc.
It seems that make clean can remove it, and then any subsequent make fails:
No problem here, jsut tried it.
Nicholas Clark
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
... You really want the
'b' type if it's a long-lived thing. That pulls the buffer pointer
out of the string structure and passes it in, so it's suitable for
mutable stuff. (That's what it's there for, actually)
Using bufstart in string code is almost
Nicholas Clark [EMAIL PROTECTED] wrote:
I believe that I've now fixed all the bugs and made pmc2c2.pl emit accurate
#line directives in the C source files it generates.
Great, thanks a lot.
Builds pass with the --no-lines option in Makefile removed. Should this
be removed from the template
On Thu, Nov 11, 2004 at 02:49:24PM +0100, Leopold Toetsch wrote:
Nicholas Clark wrote:
What generates runtime/parrot/library/config.pbc ?
It's an extension rule .imc.pbc.
It seems that make clean can remove it, and then any subsequent make fails:
No problem here, jsut tried it.
Aha.
At 3:49 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
... You really want the
'b' type if it's a long-lived thing. That pulls the buffer pointer
out of the string structure and passes it in, so it's suitable for
mutable stuff. (That's what it's there for,
Or something like that.
Anyway, I'm nailing down the last bits of functionality for the
changes to the string system. There's still going to be a fair amount
of cleanup (including the eradication of some globals) once this is
in and merged, but I wanted to give folks a heads up, and a refresher
Jeff Clites [EMAIL PROTECTED] wrote:
I was thinking: Implementing tail calls seems easy;
I thought that too. So I did it ;)
$ time parrot -j fact.imc 1 # [1]
maximum recursion depth exceeded
$ time parrot -Oc -j fact.imc 1 2# [2]
real0m0.635s
$ time
All in all, looks really good, especially the fact that it defaults
to a grapheme view rather than a codepoint view. I also like the
escape valve for drilling down to bytes if you really need it, but
it reminds me that we'll need something similar for drilling down
to codepoints for those
At 1:24 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
This OTOH is meaning that we can do the
check only at runtime. Thus the Ctailcall or Ctailcallmethod opcodes
have to do plain calls if they detect such a
At 9:19 AM -0800 11/11/04, Larry Wall wrote:
All in all, looks really good, especially the fact that it defaults
to a grapheme view rather than a codepoint view. I also like the
escape valve for drilling down to bytes if you really need it, but
it reminds me that we'll need something similar for
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things, and
I think that's just not worth the risk and hassle. Besides, it's a
lot easier in
On Nov 11, 2004, at 6:53 AM, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
Builds pass with the --no-lines option in Makefile removed. Should
this
be removed from the template Makefile so that all builds now use #line
directives?
Yep. Is there still that %ENV var around to turn
Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the former is currently created by imcc with parrot -Oc
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things
Nah, that's just the difference between
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED]
wrote:
Even further, it's necessary for some languages
(Scheme)/paradigms (loop
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Even further, it's necessary
Jeff Clites [EMAIL PROTECTED] wrote:
I'd really like a way to turn them off easily (for the ops as well,
actually). I find them to be counterproductive (for our stuff), since
what gets shown in the debugger isn't stuff you can actually get gdb to
evaluate.
It depends. While hacking PMC files
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
I only skimmed the earlier parts of this, but continuations
shouldn't affect tail calls at all.
You should read the thread then.
Joy. That means continuations
Dan Sugalski [EMAIL PROTECTED] wrote:
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Patch is probably ready tomorrow.
Cool. I think I'd like to skip having to specify the -Oc flag,
though, and add explicit syntax to PIR.
Do we really need it? Are there wicked cases, where we could
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things.
Nah, that's just the difference between running optimized and
unoptimized.
At 10:13 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Patch is probably ready tomorrow.
Cool. I think I'd like to skip having to specify the -Oc flag,
though, and add explicit syntax to PIR.
Do we really need
On Thu, 11 Nov 2004 21:59:06 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Above is *without* tail calls. The next one was with tail calls, and it
obviously did succeed, because tail calls do not contribute to any kind
of stack depth. So there is for sure no limit. It's the same as an
At 10:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
I only skimmed the earlier parts of this, but continuations
shouldn't affect tail calls at all.
You should
Hello,
I have addressed almost all the code issues from the last patch. That
broke some things, which I had to fix, but they're fixed. A couple
other improvements too. Here's the state of things:
* I have the below failed tests. I haven't looked into these. Can
someone tell me if the tests
On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I think that actually doesn't matter. Even in the case where we think
we can't do a full tail call optimization (because of a continuation
that's been taken), we can still actually remove the calling frame
Trying again...
-- Forwarded message --
From: Bill Coffman [EMAIL PROTECTED]
Date: Thu, 11 Nov 2004 14:05:29 -0800
Subject: register allocation
To: Perl 6 Internals [EMAIL PROTECTED]
Hello,
I have addressed almost all the code issues from the last patch. That
broke some
On Nov 11, 2004, at 11:12 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I'd really like a way to turn them off easily (for the ops as well,
actually). I find them to be counterproductive (for our stuff), since
what gets shown in the debugger isn't stuff you can actually get gdb
Bill Coffman [EMAIL PROTECTED] wrote:
Hello,
I have addressed almost all the code issues from the last patch.
* I have the below failed tests.
Failed TestStat Wstat Total Fail Failed List of Failed
---
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
As Dan already has outlined a Continuation doesn't have any impact on
tail calls (my argument WRT that was wrong)
I'm confused then. What from the previous discussion in this thread was
incorrect?
We
44 matches
Mail list logo
