On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be preserved over a function call if either
of the
following is true:
1. The variable is referred to again (lexically) after the function has
On Nov 15, 2004, at 12:38 AM, Leopold Toetsch wrote:
Bill Coffman [EMAIL PROTECTED] wrote:
[ pdd03 ]
The way I read it, paragraph one implies that when you print P5 after
calling foo(), you are expecting to get the return value. You didn't
save and restore register P5, so you wanted foo() to do
On Nov 14, 2004, at 9:32 AM, Leopold Toetsch wrote:
Defining now that P5 has to be preserved in main, because it's a
possible return result of foo() and therefore may be clobbered by
foo() is meaning, that we have effectively just 16 registers per kind
available for allocation around a function
On Nov 15, 2004, at 10:29 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Picture this call stack:
main -- A -- B -- C -- D -- E
The call from D to E uses the RESUMEABLE label, and E stores the
resulting continuation in a global, and everything up to main returns.
Then, main
On Nov 16, 2004, at 10:03 AM, Matt Fowles wrote:
Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.
Here's a real example you can play with, if you have
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Yes, but in the case of the continuation resuming after foo, the
continuation should restore the frame to the point where it was taken.
Thus all of the registers will be exactly as they were when the
On Nov 15, 2004, at 3:27 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Yes, but Jeff's example wasn't really reflecting the problem.
How come?
Your code didn't reuse Ca after the call.
Oops.
It seems that, in term of cache
On Nov 14, 2004, at 1:53 PM, Dan Sugalski wrote:
Since, for example, it's completely reasonable (well, likely at least)
for a called sub to rebind lexicals in its parent
What does that mean, exactly? It seems like that directly contradicts
the meaning of lexical. For instance, see Larry's
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
2) Continuations (t/op/gc_13.imc [Hi Piers])
Again we have a hidden branch done by a Continuation, or better a
loop. The control flow of the main program is basically represented by
this conventional code fragment:
arr1=[...];
On Nov 13, 2004, at 11:16 AM, Matt Fowles wrote:
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites [EMAIL PROTECTED]
wrote:
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
We'd have just to force using lexicals for all vars
Having variable-size register sets would solve this, since you
On Nov 13, 2004, at 2:46 PM, Matt Fowles wrote:
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites [EMAIL PROTECTED]
wrote:
That's oversimplifying a bit, but I feel like those are the core
issues
(stemming from the observation of Leo's that continuations in effect
give all variables a lifetime
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
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
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
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
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
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
I was thinking: Implementing tail calls seems easy; the normal calling
sequence of do some setup, then jump just turns into don't bother
with (most of) the setup, just jump. That is, don't move a new
register base-pointer into place, etc.
But there's one wiggle: If you've created a
On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
But there's one wiggle: If you've created a continuation previously
(and it still exists), then any call has to preserve the frame
Well, that's what continuations are doing. They do preserve the frame,
which
On Nov 8, 2004, at 11:42 PM, Leopold Toetsch wrote:
Jeff Clites wrote:
new P16, 32 # .PerlInt
add P16, P18, P17
That's what worries me, and what prompted the question. You don't
know at compile-time that the return type should be a PerlInt.
Yes, I've already stated
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented...
On Nov 8, 2004, at 3:08 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
No. The binary operations in Python are opcodes, as well as in
Parrot.
And both provide the snytax to override the opcode doing a method
call,
that's it.
I guess we'll just have to disagree here. I don't see
From other threads:
Now we are placing arguments or return values in registers according
to PDD03 and the other end has immediately access to the placed
values, because the register file is in the interpreter.
With the indirect addressing of the register frame, this argument
passing is
On Nov 8, 2004, at 12:50 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
In Python, semantically you know that you'll end up doing a method
call
(or, behaving as though you had), so it's very roundabout to do a
method call
On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
OTOH it doesn't really matter, if the context structure is in the
frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as
valid as I0 or I4, as long as it's assured, that it's exactly
addressing
On Nov 8, 2004, at 2:47 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):
a = 7
b = 12
c = a + b
Run
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly).
I don't think so (and you can replace with add, sub
On Nov 5, 2004, at 10:03 AM, Sam Ruby wrote:
Jeff Clites wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
special, we don't need anything to support
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
[Referring to infix operators as an alternate syntax for a named method
call]
What's the downside of compiling this code in this way? If you are a
Python programmer and all the objects that you are dealing with were
created by Python code, then not
On Nov 7, 2004, at 2:25 AM, Jens Rieks wrote:
On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
* where exactly is the mismatch coming from?
Unix uses \n to indicate end-of-line, windows uses \r\n. The
problem is,
that the perlhist.txt file is checked in as a text file. I'll
recommit it
[missed cc-ing the list when I sent this originally]
On Nov 5, 2004, at 10:39 AM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
There are a
myriad of interesting mathematical types and operations, but they
don't
need dedicated ops to support them.
But we're not talking
On Nov 7, 2004, at 3:20 PM, Jack J. Woehr wrote:
Nicholas Clark wrote:
On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc
--cxx=gcc --icuplatform=sparc-sun-solaris2.9
The build bombs in:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):
a = 7
b = 12
c = a + b
Just a basic compilation question, brought to mind by a recent thread,
because the answer
On Nov 7, 2004, at 12:10 PM, Leopold Toetsch wrote:
Jack J. Woehr [EMAIL PROTECTED] wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
From a Python or Ruby language perspective, infix operators are not
fundamental operations associated with specific types, they are
syntactic sugar for method calls.
A the moment, I'm compiling x=y**z into:
x = y.__pow__(z)
There is nothing
On Nov 4, 2004, at 10:30 PM, Brent 'Dax' Royal-Gordon wrote:
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum
On Nov 3, 2004, at 8:09 AM, Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make
it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I know I'm going to regret
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I.e., PMCs don't inherently exponentiate--numbers do, and you can
exponentiate PMCs by numberizing them, exponentiating, and creating a
PMC with the result.
This is true. But how do you define
On Nov 2, 2004, at 12:41 AM, Leopold Toetsch wrote:
When we have objects with finalizers, we have to run the finalizers in
order from most derived down the parent chain.
Maybe, but not necessarily. The case of loops means that we cannot
always do this cleanly (no top of the chain), and the fact
On Nov 2, 2004, at 10:46 AM, Dan Sugalski wrote:
At 1:42 PM -0500 11/2/04, Sam Ruby wrote:
I don't care if Parrot uses ICU on any platform.
I do care that Parrot supports utf-8 on every platform.
Ah, OK. Yes, we will support all the unicode encodings, as well as the
unicode character set, on all
On Nov 2, 2004, at 7:10 PM, Matt Diephouse wrote:
Joshua Gatcomb and I have been working a little under a week to set up
an automated build system for parrot that tracks performance (with
help from Dan's box). We have collected benchmark data for regular and
optimized builds with and without JIT
On Nov 1, 2004, at 6:14 AM, Dan Sugalski wrote:
Because I need to get strings working right, so I'm going to be
implementing the encoding/charset library stuff, which is going to
cause some major disruptions.
Please tag cvs before checking this in.
Thanks,
JEff
On Oct 29, 2004, at 11:29 PM, Brent 'Dax' Royal-Gordon wrote:
I recently got my hands on money for an upgrade, and got an AMD64 and
motherboard and installed them. I'm still using 32-bit Windows, but
I've also installed a 64-bit Gentoo on some previously unpartitioned
space.
...
Failed Test
On Oct 30, 2004, at 12:58 AM, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote:
* The created C code could benefit from #line directives to track
where
C code came from the input .pmc file, so that compiler errors
I was getting a failure under JIT on PPC for t/pmc/threads_8.pasm, and
the problem turned out to be that emitting a restart op takes 26
instructions, or 104 bytes, and we were hitting the grow-the-arena
logic just shy of what would have triggered a resize, then running off
the end.
The below
Recently config/gen/platform/darwin/asm.s was added, containing
Parrot_ppc_jit_restore_nonvolatile_registers(). Corresponding code also
needs to be added to config/gen/platform/aix/asm.s -- Parrot should
fail to link on AIX currently, without this. I didn't try to update the
AIX asm.s myself,
On Oct 27, 2004, at 6:24 AM, Gisle Aas wrote:
How about the code JITed from the bytecodes. Will it be shared?
The JITed code can't be shared directly--in it's current form, it
(intentionally) includes absolute addresses which wouldn't be valid for
other processes.
But the exec core allows (or,
On Oct 22, 2004, at 3:57 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related,
and pointing out things
On Oct 23, 2004, at 4:20 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
See attached the patch, plus the new asm.s file.
Doesn't run, segfaults on even mops.pasm - please check.
I can't reproduce that here; parrot -j works for me with
examples/{benchmarks,assembly}/mops.pasm
On Oct 23, 2004, at 3:42 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Yep, that was the core of the issue. There's no free lunch--if we use
the nonvolatile registers, we need to preserve/restore them in
begin/end, but if we use the volatile registers, we need to preserve
them
On Oct 23, 2004, at 5:14 AM, Leopold Toetsch wrote:
First, if you don't have it yet done, install ccache.
Thanks for the tip--seems awesome.
HOW IT WORKS
The basic idea is to detect when you are compiling exactly the
same code a 2nd time and use the pre-
viously compiled output. You
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related, and
pointing out things which needed fixing anyway (float register
preservation issues). I'll
On Oct 20, 2004, at 12:09 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok,
On Oct 20, 2004, at 11:24 PM, Leopold Toetsch wrote:
Bill Coffman [EMAIL PROTECTED] wrote:
And of course, lexicals and globals already have a storage, you don't
need to spill them.
I'm not sure that's true. If there's no 'eval' in scope, lexicals don't
have to live in pads--they could purely
On Oct 21, 2004, at 4:13 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 20, 2004, at 11:24 PM, Leopold Toetsch wrote:
And of course, lexicals and globals already have a storage, you don't
need to spill them.
I'm not sure that's true.
It should read: if there are lexical
On Oct 21, 2004, at 8:34 AM, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like
to do with the interpreter, the register frame, and the register
backing stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date
On Oct 21, 2004, at 11:51 AM, Dan Sugalski wrote:
At 11:25 AM -0700 10/21/04, Bill Coffman wrote:
I read somewhere that the requirement for parrot code is that it
should be compliant with the ANSI C'89 standard. Can someone point me
to a description of the C89 spec, so I can make sure my
On Oct 19, 2004, at 12:42 AM, Leopold Toetsch wrote:
Will Coleda [EMAIL PROTECTED] wrote:
t/pmc/signal...Hangup
I saw that once too: looks like the test script got the signal.
That's what my patch from last week was supposed to fix--I'm surprised
it's still happening. We should
On Oct 19, 2004, at 1:56 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are done as soon
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 16, 2004, at 4:47 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are done as soon as they run (eval
On Oct 16, 2004, at 12:26 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
... But, we use this currently, because
there is one issue with threads: With a thread, you don't start from
the beginning of the JITted code segment,
This isn't a threading issue. We can always start
On Oct 14, 2004, at 12:10 PM, Leopold Toetsch wrote:
Proposal:
* we mandate that JIT code uses interpreter-relative addressing
- because almost all platforms do it
- because some platforms just can't do anything else
- and of course to avoid re-JITting for every new thread
FYI, the PPC JIT does
On Oct 13, 2004, at 6:36 PM, Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #31978]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31978
One of the recent changes
On Oct 8, 2004, at 7:54 AM, Andy Dougherty wrote:
On Thu, 7 Oct 2004, Steve Fink wrote:
So what I need is names for these. At the moment, I'm mostly using
$(SO)
for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
gneerally call $(LD_SHARED) or something with shared for shared
On Oct 8, 2004, at 9:03 AM, Steve Fink wrote:
If I just do
perl Configure.pl
make
right now, it builds the parrot executable ok but then fails when it
tries to compile the library .imc files. It's looking for the icu data
dir in $(prefix)/blib/lib/2.6.1. It works if I do
perl Configure.pl
On Oct 8, 2004, at 9:24 AM, Jeff Clites wrote:
On Oct 8, 2004, at 9:03 AM, Steve Fink wrote:
If I just do
perl Configure.pl
make
right now, it builds the parrot executable ok but then fails when it
tries to compile the library .imc files. It's looking for the icu data
dir in $(prefix)/blib/lib
On Oct 6, 2004, at 11:49 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
3) I won't mention the problem of languages which allow an object to
have instance variables and instance methods of the same name (so that
in Python, a.b would be ambiguous if a is an object from
On Oct 6, 2004, at 1:11 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
To put it another way, the expression foo.bar() in Python doesn't
really parse as invoke method bar on object foo, but rather as
lookup attribute bar on object foo
Well, there isn't much difference here. invoke
Python's method call semantics allows you to look up a method of an
object as an attribute, store it in a variable, and later invoke it
like a regular function. This works similarly if you do the lookup on
the class object, but when you invoke the function you need to pass
in an instance as an
On Oct 4, 2004, at 8:25 AM, Dan Sugalski wrote:
Okay, since we've got the *basic* semantics down (unified namespace,
namespace entries get a post-pended null character)
I'll ask again, what about subs? Do they get name-mangled too?
$Px = find_global [key; key; key], 'name'
As Leo pointed out
On Oct 4, 2004, at 9:58 PM, Brent 'Dax' Royal-Gordon wrote:
Tim Bunce [EMAIL PROTECTED] wrote:
Now, with that out of the way, let's talk about overlaid namespaces.
I don't think I ever read a description of what the purpose of this
was.
I get the what but not the why. Without the why it's hard to
Unless we've got this somewhere already, I think it would be useful to
have some examples of simple Perl6 code, and the bytecode we expect
this to compile down to. This would help to fix some ideas, and make
sure that everyone's on the same page. As an example, what bytecode
goes with the
On Sep 29, 2004, at 9:01 PM, Brent 'Dax' Royal-Gordon wrote:
[Argh...]
Chip Salzenberg [EMAIL PROTECTED] wrote:
parrot_alias(a, 'b', # dest: Python is unified, no
need for a category here
a, 'b', 'scalar') # src: Perl is not unified, so
source category is
On Oct 1, 2004, at 5:45 AM, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
On Friday 01 October 2004 08:42, Leopold Toetsch wrote:
sucks a lot less than making python programmers say
import Foo.ns.Bar.scalar.baz
But OTOH I can imagine that finally standard modules are present in
on this.
Further comments, some of which will be redundant with the above:
On Sep 30, 2004, at 1:00 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
First off, Perl5 doesn't describe itself that way. The Camel states,
Note that we can use the same name for $days, @days, and %days
without
On Sep 29, 2004, at 7:25 AM, Dan Sugalski wrote:
Okay, after seeing all the back and forth, here's what we're going to
do.
Namespaces are going to be *simple*. They do two things, and only two
things.
1) They provide a hierarchy for other namespaces
2) They bind names to PMCs
That's it. No
On Sep 29, 2004, at 2:53 AM, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, so we've got two points of dispute:
1) Jeff doesn't think the sigil should be part of the variable name
Which isn't practicable. We can't strip off the sigil for perl5. It's
part of the variable name,
On Sep 27, 2004, at 8:55 AM, Dan Sugalski wrote:
Okay, I've come to realize that it really helps if I'm clear about
what I want, which kinda requires being clear about what I want.
There are two things in the namespaces I'm concerned about.
First are the actual objects one grabs out. Variables,
On Sep 28, 2004, at 7:02 AM, Aaron Sherman wrote:
Rather than trying to shuffle through the keyboard and find that
special
character that can be used, why not have each language do it the way
that language is comfortable (e.g. place it in the regular namespace as
a variable like Python or place
On Sep 28, 2004, at 8:58 AM, Jeff Clites wrote:
And just to close the loop, you'd still express your $Foo::Bar::baz
lookup like:
lookupVariableInNamespace P1, [Foo; Bar], baz # the things in
the [...] are always namespace names
Here are more examples, just to be clear:
(and the actual op names
On Sep 28, 2004, at 9:54 AM, Chip Salzenberg wrote:
According to Jeff Clites:
Let's say that all you have around are $Foo and $Foo::Bar::baz ...
top-level namespace (say this is namespace #1):
{
variables = { Foo = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables = { Foo = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I think I get it. You're replacing
On Sep 28, 2004, at 12:28 PM, Chip Salzenberg wrote:
According to Dan Sugalski:
At 11:58 AM -0700 9/28/04, Jeff Clites wrote:
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables = { Foo = PerlScalar PMC
On Sep 25, 2004, at 10:27 PM, Larry Wall wrote:
On Sat, Sep 25, 2004 at 10:01:42PM -0700, Larry Wall wrote:
: We've also said that MY is a pseudopackage referring to the current
: lexical scope so that you can hand off your lexical scope to someone
: else to read (but not modify, unless you are
On Sep 25, 2004, at 10:14 AM, Dan Sugalski wrote:
At 7:43 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in P6
On Sep 25, 2004, at 11:15 AM, Dan Sugalski wrote:
At 2:10 PM -0400 9/25/04, Chip Salzenberg wrote:
According to Dan Sugalski:
Leaf subs and methods can know [their call paths], if we stipulate
that vtable methods are on their own, which is OK with me.
So, given this sub and tied $*var:
sub
On Sep 24, 2004, at 1:13 AM, Leopold Toetsch wrote:
Piers Cawley [EMAIL PROTECTED] wrote:
I could be wrong here, but it seems to me that having a special
'tailinvoke' operator which simply reuses the current return
continuation instead of creating a new one would make for rather
faster
tail calls
On Sep 23, 2004, at 9:53 AM, Dan Sugalski wrote:
At 12:06 AM -0700 9/23/04, Jeff Clites wrote:
On Sep 22, 2004, at 8:13 PM, Dan Sugalski wrote:
At 7:32 PM -0700 9/22/04, Jeff Clites wrote:
*) If a language wants different types of variables to have the
same name, it has to mangle the names. (So
On Sep 24, 2004, at 8:07 AM, Aaron Sherman wrote:
On Fri, 2004-09-24 at 10:03, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are
they
there)?
They are there so that variables can be found by name in a lexically
scoped way. One example, in Perl 5, of this need is:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
On Fri, 2004-09-24 at 12:36, Jeff Clites wrote:
Ha, you're example is actually wrong (but tricked me for a second).
Here's a simpler case to demonstrate that you can't look up lexicals
by
name (in Perl5):
You are, of course, correct. If I'd been
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in P6, as I
understand it.
Hmm, that's too bad--it could be quite an opportunity for
optimization
On Sep 22, 2004, at 8:13 PM, Dan Sugalski wrote:
At 7:32 PM -0700 9/22/04, Jeff Clites wrote:
One problem: Some languages (Scheme, for example, and arguably C)
have a unified namespace for subs and variables. What to do there?
The easiest thing would be to allow the languages to store
On Sep 22, 2004, at 5:06 PM, Edward Peschko wrote:
How do you do that? Generation and matching are two different things
algorithmically.
yes, but they are intimately linked. just like the transformation of a
string
into a number, and from a number to a string. Two algorithmically
different
On Sep 23, 2004, at 5:27 PM, Edward Peschko wrote:
On Thu, Sep 23, 2004 at 08:15:08AM -0700, Jeff Clites wrote:
just like the transformation of a string into a number, and from a
number to a string. Two algorithmically different things as well,
but they'd damn-well better
On Sep 22, 2004, at 10:58 AM, Dan Sugalski wrote:
*) There are three things that can be in a namespace: Another
namespace, a method or sub, and a variable.
*) The names of namespaces, methods subs, and variables do *not*
collide. You may have a namespace Foo, a sub Foo, and a variable Foo
at
On Sep 22, 2004, at 5:30 PM, Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #31682]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31682
...
$ make realclean
$
Hi Leo:
I was reading over you incremental GC posts from about a month ago, and
read the referenced paper--quite nice work you've done in implementing
the ideas there.
I have one question: What about finalizers? I may have just missed it,
but it would seem that calling finalizers would require
On Sep 18, 2004, at 2:09 AM, [EMAIL PROTECTED] wrote:
* Nicholas Clark [EMAIL PROTECTED] [2004-09-08 17:37:52 +0100]:
The probing is going to *have* to get written in something that
compiles
down to parrot bytecode to work on the autoconf-deprived systems, so
with
that as a given there's no need
On Sep 13, 2004, at 1:07 AM, Luke Palmer wrote:
Jeff Clites writes:
On Sep 12, 2004, at 8:43 PM, Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and
all
that. It'd map
On Sep 12, 2004, at 8:43 PM, Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and all
that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does
1 - 100 of 321 matches
Mail list logo
