Status of PXS and some IMHO obsolete ops
As stated in the thread pxs help, the QT example can be expressed in terms of NCI. So IMHO the following opsen are obsolete: - loadext (unused) - callnative (only in QtHelloWorld.pasm, unimplemented) And further: - setline - setfile - setpackage which are already/ought to be in the PBC metadata. Putting setlines into the PBC stream would also slow down execution. leo
Re: invoke
Steve Fink wrote: On Feb-22, Leopold Toetsch wrote: Yep. At least add Binvoke Px. Ok, done. Good. One minor note - and it is my fault to haven't documented that in the first place - I did revert all the other changes, they are necessary for pbc2c compiled code. Of course, it would be better, to have another set of macros, that state: This offset ought to be a real PBC offset. leo
Re: access to partial registers?
Tupshin Harper wrote: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? We have a very limited subset in dotgnu.ops. -Tupshin leo
Re: [RFC] imcc calling conventions
Benjamin Goldberg wrote:
Dan Sugalski wrote:
Yeah, 32 is a bunch. I've considered going with 16 on and off, and
still might.
16 is not enough for non trivial subroutines. E.g. the _Generate sub in
life.p6 consumes 25 P regs.
Given that registers are allocated with the lower numbers being the ones
used more often, how about having 32 registers, as we now have, but two
different ops for saving -- one of which saves registers 0 .. 15, the
other saves all 0 .. 31. Or is this just a dumb idea?
I think, this is a good idea. For caller-save subroutines we could have:
saveall 10,0,1,2 # save I0..I9, no S, P0, N0..N1
...
restoreall 10,0,1,2
ret
accompanied with push{i,s,p,n}_i and pop{i,s,p,n}_i, for
saving/restoring just a certain amount of one kind of registers.
leo
Re: Status of PXS and some IMHO obsolete ops
Leo / Dan -- Have we allocated PASM or IMC directives to replace the setline, setfile, and setpackage ops? * .file name * .line [filename] line * .package name Should we have an indicator of the name of a sub, too? Regards, -- Gregor Leopold Toetsch [EMAIL PROTECTED] 02/23/2003 04:35 AM To: P6I [EMAIL PROTECTED] cc: Dan Sugalski [EMAIL PROTECTED] Subject:Status of PXS and some IMHO obsolete ops As stated in the thread pxs help, the QT example can be expressed in terms of NCI. So IMHO the following opsen are obsolete: - loadext (unused) - callnative (only in QtHelloWorld.pasm, unimplemented) And further: - setline - setfile - setpackage which are already/ought to be in the PBC metadata. Putting setlines into the PBC stream would also slow down execution. leo
Re: Configure.pl --cgoto=0 doesn't work
On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote: Nicholas Clark wrote: On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote: Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c But surely we'd also like a flag to disable core_ops_cgp.c but leave core_ops_cg.c? IMHO no. Why disable the faster and much smaller core, and keep the big and slow core? It might just be that on someone's machine the faster and smaller core triggers a compiler bug. And Here is a summary in terms of speed: JIT CGP (obsoletes CGoto Prederef) Switched Prederef (obsoletes Prederef) Switched Normal When PBC code size matters we could have: CGoto you've already found a reason why someone might want the obsoleted CGoto core. I'm not saying that we recommend using, or even default to building any obsolete cores that we ship source for. Merely that we ensure that the configure system is flexible enough to let anyone build any arbitrary combination of cores they ask for. (Providing they answer yes enough times to do you really want to do that?). It strikes me that having rules in the configure system to explicitly forbid compiling certain combinations of cores is actually more complex than not having such rules. I forget who I'm misquoting, but good tools can be used in ways their makers never even thought of. Nicholas Clark
Re: Arrays, lists, referencing
On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote: I would like to argue in favour of pass by value to be the default in the absence of some explicit prototype, because it allows greater type-safety, and because the opposite default interacts badly with out-of-order execution such as parallelism, and bars some optimisations that can be applied to closures. (We do want Perl to run fast on parallel hardware, don't we?) Based on what I remember of reading apocalpyses 1 to 5 and messages on this list, perl6 intends to pass by value by default. PS: sorry for the long post... No need to apologise. Thanks for the informative, well thought out and well reasoned post. Nicholas Clark
Re: Arrays, lists, referencing
On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote:
I would like to argue in favour of pass by value to be the
default in the absence of some explicit prototype, because it
allows greater type-safety, and because the opposite default
interacts badly with out-of-order execution such as parallelism,
and bars some optimisations that can be applied to closures. (We
do want Perl to run fast on parallel hardware, don't we?)
Based on what I remember of reading apocalpyses 1 to 5 and messages
on this list, perl6 intends to pass by value by default.
No, default is constant reference, from Apocalypse 4, under RFC 89.
Well, it's constant reference for Ideclared parameters. When you
don't give a parameter list, _ is bound to the argument list with
mutable reference elements, to make it as much like Perl 5 as
possible. But you shouldn't use that form anyway, because it's
archaic and ugly.
And I don't see how making parameters passed by constant reference is
slow. If you're writing very close to pure functional like you say,
you shouldn't be modifying your parameters anyway. And constant
reference may have a few consequences with threading that are absent
with by-value if you're not aware of the semantics, but it is a much,
much better default for single threaded programs. I suspect 90% of
Perl 6 programs will be single threaded.
If you want to modify a parameter in place, you declare with Cis rw.
If you want to pass by-value, there might be a property for that, but
I think this was recommended:
sub foo($bar_) {
my $bar = $bar_; # Copy, not bind
# ... with $bar
}
Luke
Re: Configure.pl --cgoto=0 doesn't work
Nicholas Clark wrote: On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote: It might just be that on someone's machine the faster and smaller core triggers a compiler bug. And When PBC code size matters we could have: CGoto you've already found a reason why someone might want the obsoleted CGoto core. [...] I forget who I'm misquoting, but good tools can be used in ways their makers never even thought of. Ok, ok, you have convinced me. Let's just select a default core set build according to the mentioned hierarchies and the possibility to build every combination, if the user wants to. Nicholas Clark leo
Re: Using imcc as JIT optimizer
Dan Sugalski wrote: At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment: - do register allocation for JIT in imcc - use the first N registers as MAPped processor registers This sounds pretty interesting, and I bet it could make things faster. I have now checked in a first version for testing: - the define JIT_IMCC_OJ in jit.c is disabled - so no impact - jit2h.pl defines now a MAP macro, which makes jit_cpu.c more readable Restrictions: - no vtable ops - no saving of non preserved registers (%edx on I386) So not much will run, when experimenting with it. But I think, the numbers are promising, so it's worth a further try. To enable the whole fun, recompile with JIT_IMCC_OJ enabled, build imcc and use the -Oj switch (primes.pasm is from examples/benchmarks): $ time imcc -j -Oj primes.pasm N primes up to 5 is: 5133 last is: 4 Elapsed time: 3.523477 real0m3.548s $ ./primes # primes.c -O3 gcc 2.95.2 N primes up to 5 is: 5133 last is: 4 Elapsed time: 3.647063 $ time imcc -j -O1 primes.pasm # normal JIT N primes up to 5 is: 5133 last is: 4 Elapsed time: 4.039121 real0m4.065s imcc/parrot was built without optimization, but this doesn't matter, no external code is called for jit/i386 in the primes.pasm. The timings for imcc obviously include compiling too. leo
Re: Status of PXS and some IMHO obsolete ops
[EMAIL PROTECTED] wrote: Leo / Dan -- Have we allocated PASM or IMC directives to replace the setline, setfile, and setpackage ops? * .file name * .line [filename] line * .package name Should we have an indicator of the name of a sub, too? We don't need .file/.line, imcc knows these, and passes the information in the PBC metadata already to jit_debug. The parrot debugger still needs work. For HL file/line information I'd rather use (the already in perl6/P6C implemented) comment syntax, like: #line 13 mops.p6 $ imcc -d -o p.pbc primes.pasm $ pdump -t p.pbc ... BYTECODE_DB = [ # offs 0xa0(160) = op_count 40, itype 0, id 0, size 32, ... 00a4: 0005 0007 0008 0009 00a8: 000a 000b 000c 000f 0010 0012 0013 0017 00b0: 0018 0019 001b 001c 0020 0021 0022 0023 00b8: 0024 0025 0026 0027 0028 0029 002a 002b 00c0: 6d697270 702e7365 006d7361 ] In the last bytes you can decipher the filename. Regards, -- Gregor leo
Re: access to partial registers?
If memory serves me right, Leopold Toetsch wrote: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? I always thought bitwise and and or were the things to use to modify partial content ?. Though I can't say if that makes sense because INTVAL is not fixed and neither is the endianess of registers (IIRC they are not fixed ?). We have a very limited subset in dotgnu.ops. Those were written to support the fixed size integers and longs that C# needs (Int32 Friends). I think you could convert from/to sized integer values with those opcodes (conv_u4,conv_i4...). Parrot codegen for C# still awaits the second coming of the prophet Zarquon.. (to be accurate -- Object instructions ;) Gopal -- The difference between insanity and genius is measured by success
Re: Configure.pl --cgoto=0 doesn't work
At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote: I forget who I'm misquoting, but good tools can be used in ways their makers never even thought of. Ok, ok, you have convinced me. Let's just select a default core set build according to the mentioned hierarchies and the possibility to build every combination, if the user wants to. Cool. When we do that I'd like to look at revamping the tinderbox system to run tests on all the core types. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: access to partial registers?
At 6:54 PM -0800 2/22/03, Tupshin Harper wrote: Sorry for all the questions...these are the trials and tribulations of dealing with a newbie trying to get up to speed with the current state of parrot. So here's another question: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? At the moment no, and they'd only really be useful for the integer registers. Having said that, which ones would you want? I don't mind us thinking about an intreg.ops set. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Configure.pl --cgoto=0 doesn't work
Dan Sugalski wrote:
At 2:33 PM +0100 2/23/03, Leopold Toetsch wrote:
Ok, ok, you have convinced me. Let's just select a default core set
build according to the mentioned hierarchies and the possibility to
build every combination, if the user wants to.
Cool. When we do that I'd like to look at revamping the tinderbox system
to run tests on all the core types.
s. 4) below - that's easy
While you say it tinderbox, currently the reports are really
suboptimal. Some are red (stating not even parrot was built), but only
have failing tests, sometimes the error reason is not show in the brief
log, making it a PITA to read the full log (on my 64Kbit ISDN line).
So to make tinderboxen really more useful, they would need some improvement:
1) sync with CVS
Currently tinderboxen seem to delete the whole tree and start from
scratch. This generates a lot of traffic (albeit - thanks - not mine),
but this is IMHO not necessary:
$ cvs -z3 update [-d...] -dP parrot $FULL_LOG 21
perl Configure.pl [--options] $FULL_LOG 21
make distclean ...
With appropriate error checking should do it.
Make normal entry in brief log is something like
echo Parrot sync src ok $BRIEF_LOG
2) building parrot
$ perl Configure.pl [--options] $FULL_LOG 21
make -s $BUILD_LOG 21
- [/me dreaming:] Filter $BUILDLOG to contain the first warning of some
type and then only a repeat count and may be maximal 1 line per
occurance of this warning, by deleting the line number and run the
output through some kind of sort|uniq. The error parser of your
$EDITOR should contain the necessary regexen to get the real
warning/error message even from the normally multiline mess{,age}.
- show all errors
- append status to $BRIEF_LOG and $FULL_LOG
If this fails stop here.
3) building imcc
$ cd languages/imcc
$ make -s ...
$ cd -
Same procedure as above - but *don't stop* if this fails, only generate
report.
4) run parrot tests (if 2) succeeded)
$ make quickfulltest
This runs normal, -j, -P, and -g i.e. all major cores.
In case of test failure show enough lines in the brief log, to really
get the start of the problem. This is one line after the last running
test. The output of the test (expected/got) is normally not of much
value, but could be included e.g. as a diff.
5) if imcc did build ok:
$ cd languages/imcc
$ make test
Summary:
The brief log should really contain all kinds of problems but reall be
*brief* and the full log would be just a check, that brief log is ok.
my 2¢ TIA,
leo
Re: Configure.pl --cgoto=0 doesn't work
On Sun, Feb 23, 2003 at 11:13:30AM -0500, Dan Sugalski wrote: Cool. When we do that I'd like to look at revamping the tinderbox system to run tests on all the core types. I know I'm asking a needless question (because I should be able to work it out from the source and the list archive) but what remains to be done before we can use imcc rather than assemble.pl as the default assembler for the regression tests? imcc is a lot (20 times) faster. Nicholas Clark
Re: Configure.pl --cgoto=0 doesn't work
On 2/23/03 10:25 AM, Leopold Toetsch [EMAIL PROTECTED] wrote:
[SNIP]
While you say it tinderbox, currently the reports are really
suboptimal. Some are red (stating not even parrot was built), but only
have failing tests, sometimes the error reason is not show in the brief
log, making it a PITA to read the full log (on my 64Kbit ISDN line).
I'll try to improve the brief log. The problem is that the client does not
generate this log, it's automatically generated by the server, but I can
hack around this. As for redness that should really be yellow, that's an
error in the regexp's client config file. I'll try to make them a little
more robust by default.
So to make tinderboxen really more useful, they would need some improvement:
1) sync with CVS
Currently tinderboxen seem to delete the whole tree and start from
scratch. This generates a lot of traffic (albeit - thanks - not mine),
but this is IMHO not necessary:
$ cvs -z3 update [-d...] -dP parrot $FULL_LOG 21
perl Configure.pl [--options] $FULL_LOG 21
make distclean ...
With appropriate error checking should do it.
Make normal entry in brief log is something like
echo Parrot sync src ok $BRIEF_LOG
This was something that original versions of tinderclient did, but I added
the unlink because it was causing trees to become corrupted. I'll probably
add this as an option in the next version defaulting to not unlink the tree.
2) building parrot
$ perl Configure.pl [--options] $FULL_LOG 21
make -s $BUILD_LOG 21
- [/me dreaming:] Filter $BUILDLOG to contain the first warning of some
type and then only a repeat count and may be maximal 1 line per
occurance of this warning, by deleting the line number and run the
output through some kind of sort|uniq. The error parser of your
$EDITOR should contain the necessary regexen to get the real
warning/error message even from the normally multiline mess{,age}.
- show all errors
- append status to $BRIEF_LOG and $FULL_LOG
This would be good to have, but again, the client only generates the full
log and sends it to the server, but I'll see.
If this fails stop here.
3) building imcc
$ cd languages/imcc
$ make -s ...
$ cd -
Same procedure as above - but *don't stop* if this fails, only generate
report.
This is doable, I could have it give a yellow test failed condition if it
fails.
4) run parrot tests (if 2) succeeded)
$ make quickfulltest
This runs normal, -j, -P, and -g i.e. all major cores.
I'll change this in the default config.
In case of test failure show enough lines in the brief log, to really
get the start of the problem. This is one line after the last running
test. The output of the test (expected/got) is normally not of much
value, but could be included e.g. as a diff.
This would also be fixed by fixing the server's brief log generation code.
5) if imcc did build ok:
$ cd languages/imcc
$ make test
Summary:
The brief log should really contain all kinds of problems but reall be
*brief* and the full log would be just a check, that brief log is ok.
Thanks for your feedback. I'm pretty busy now, but I'll try to get the
client side of this done at least, the server side will bit a bit harder.
Zach
my 2¢ TIA,
leo
Re: invoke
On Feb-23, Leopold Toetsch wrote:
Good.
One minor note - and it is my fault to haven't documented that in the
first place - I did revert all the other changes, they are necessary for
pbc2c compiled code.
Of course, it would be better, to have another set of macros, that
state: This offset ought to be a real PBC offset.
Oops, sorry, I didn't mean to commit that part until I figured out
what was going on.
I think I kind of have a grasp on what's going on, now. So I've
attached two possible patches. The first just implements a new macro
OP_SIZE that can be used to calculate relative offsets. The second
goes further, and replaces expr_offset() for the pbc2c version so that
it computes start_code-relative offsets. Nothing appears to be using
the current version, which would only work for constant offsets
anyway. (The second also includes the OP_SIZE macro, but doesn't use
it -- so apply one or the other.)
I feel that my grasp of the situation is tenuous enough that I don't
want to commit the second without someone checking it over, and the
first isn't needed if the second is applied.
I also noticed that rx.ops doesn't look like it'll work with pbc2c
because it uses 'goto OFFSET' in a macro, and
Parrot::OpTrans::Compiled needs to know the relative PC of the current
instruction.
And finally, jsr seems to be broken with pbc2c (and maybe other cores,
I don't know.)
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.260
diff -p -u -b -r1.260 core.ops
--- core.ops23 Feb 2003 09:58:29 - 1.260
+++ core.ops23 Feb 2003 18:59:36 -
@@ -19,10 +19,10 @@ Parrot's core library of ops.
=head1 NOTE
Some branching ops use BCUR_OPCODE + size as branch destination and
-not Bexpr NEXT(). This is done, to get a branch destination in terms
+not Bexpr NEXT(). This is done to get a branch destination in terms
of offsets in the normal core, and not in terms of the running core.
-This is needed, for all branching ops, that might leave the actual
+This is needed for all branching ops that might leave the actual
core, so that the branch offset can be recalculated to the other core,
Currently used in the native run core generated by Bpbc2c.pl.
@@ -3799,7 +3799,7 @@ stack for later returning.
=cut
inline op bsr (in INT) {
- stack_push(interpreter, interpreter-ctx.control_stack, CUR_OPCODE + 2,
STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+ stack_push(interpreter, interpreter-ctx.control_stack, CUR_OPCODE + OP_SIZE,
STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
goto OFFSET($1);
}
@@ -3815,7 +3815,7 @@ location onto the call stack for later r
inline op jsr(in INT) {
opcode_t * loc;
- stack_push(interpreter, interpreter-ctx.control_stack, CUR_OPCODE + 2,
STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+ stack_push(interpreter, interpreter-ctx.control_stack, CUR_OPCODE + OP_SIZE,
STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
loc = INTVAL2PTR(opcode_t *, $1);
goto ADDRESS(loc);
}
@@ -4592,7 +4592,7 @@ inline op invoke() {
opcode_t *dest;
PMC * p = interpreter-ctx.pmc_reg.registers[0];
- dest = (opcode_t *)p-vtable-invoke(interpreter, p, CUR_OPCODE + 1);
+ dest = (opcode_t *)p-vtable-invoke(interpreter, p, CUR_OPCODE + OP_SIZE);
goto ADDRESS(dest);
}
@@ -4601,7 +4601,7 @@ inline op invoke(in PMC) {
opcode_t *dest;
PMC * p = $1;
- dest = (opcode_t *)p-vtable-invoke(interpreter, p, CUR_OPCODE + 2);
+ dest = (opcode_t *)p-vtable-invoke(interpreter, p, CUR_OPCODE + OP_SIZE);
goto ADDRESS(dest);
}
Index: lib/Parrot/Op.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Op.pm,v
retrieving revision 1.9
diff -p -u -b -r1.9 Op.pm
--- lib/Parrot/Op.pm22 Apr 2002 02:40:59 - 1.9
+++ lib/Parrot/Op.pm23 Feb 2003 18:59:37 -
@@ -202,6 +202,7 @@ sub _substitute {
s/{{-=([^{]*?)}}/ $trans-goto_offset(-$1); /me;
s/{{=([^*][^{]*?)}}/ $trans-goto_address($1); /me;
+ s/{{\^(-?\d+)}}/ $1/me;
s/{{\^\+([^{]*?)}}/ $trans-expr_offset($1); /me;
s/{{\^-([^{]*?)}}/$trans-expr_offset(-$1); /me;
s/{{\^([^{]*?)}}/ $trans-expr_address($1); /me;
Index: lib/Parrot/OpsFile.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/OpsFile.pm,v
retrieving revision 1.31
diff -p -u -b -r1.31 OpsFile.pm
--- lib/Parrot/OpsFile.pm 22 Jan 2003 15:57:24 - 1.31
+++ lib/Parrot/OpsFile.pm 23 Feb 2003 18:59:37 -
@@ -232,7 +232,7 @@ sub read_ops
}
#
-# Accummulate the code into the op's body:
+# Accumulate the code into the op's body:
#
if ($seen_op) {
@@ -301,6 +301,7 @@ sub make_op
# expr OFFSET(X) {{^+X}} PC + XRelative address
# expr NEXT(){{^+S}} PC + SWhere S is op size
# expr
Re: access to partial registers?
Dan Sugalski wrote: At 6:54 PM -0800 2/22/03, Tupshin Harper wrote: Sorry for all the questions...these are the trials and tribulations of dealing with a newbie trying to get up to speed with the current state of parrot. So here's another question: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? At the moment no, and they'd only really be useful for the integer registers. Having said that, which ones would you want? I don't mind us thinking about an intreg.ops set. I actually *don't* necessarily want to. The question only came up becasue virtually all real CPUs allow you to do this to conserve registers, and I'm just trying to understand how and why a VM like parrot diverges from the concepts/semantics of a real CPU. If this kind of optimization is to take place, it sems like it would have to take place on the fly (JIT level) once the system knew what kind of target CPU it was running on, and that it wouldn't be meaningful to do so at the pasm or pbc generation levels(except possibly as a hinting mechanism). Does this make sense, or am I smoking crack? -Tupshin
Re: invoke
On Feb-22, Dan Sugalski wrote: At 10:20 AM -0800 2/20/03, Steve Fink wrote: The invoke op is bothering me -- namely, it disturbs me that it implicitly operates on P0. I know that P0 is the correct register to use according to pdd03, but I dislike having it be implicit. The user is required to set the rest of the pdd03 conventions up manually, so I don't see any need for invoke to be different. It isn't, though. You have to set up P0 just like all the other registers you're using. It's not like invoke makes you specify them either. (Though I could certainly see a case for a version that takes counts as parameters and sets up the I registers appropriately, for speed reasons) I suppose that's true, if you really are doing full externally-visible (pdd03-compliant) invoke() calls. But if you're doing internal stuff, then it starts to matter what things are part of the invoke() interface, and what things are purely (calling) convention. At the moment, Sub.pmc's invoke() really only looks at P0. Will it eventually use all of pdd03's registers, or will some of that always be handled by the callee? I don't really know the fundamental motivation underlying 'invoke', so I can't guess the answer to this. I suppose if invoke is going to be used for multiple dispatch, then it really will use everything -- register counts, return type, the actual parameters, etc. I'm OK with a one-arg version, as long as it's made explicit in the docs that code that uses it makes no guarantees about the state of any of the registers. -- I'll need the answer to the previous question before I can write those docs.
Re: Arrays, lists, referencing
Luke wrote:
If you want to modify a parameter in place, you declare with Cis rw.
If you want to pass by-value, there might be a property for that, but
I think this was recommended:
sub foo($bar_) {
my $bar = $bar_; # Copy, not bind
# ... with $bar
}
In the design meetings early this month we added Cis copy for true
pass-by-value.
sub foo($bar is copy) {
...
}
There's a nice explanation of it in A6, which will be coming out fairly
soon now.
Allison
Re: Arrays, lists, referencing
[EMAIL PROTECTED] (Allison Randal) writes: In the design meetings early this month we added Cis copy for true pass-by-value. Can someone please compile a list of all the is foo properties that have been suggested/accepted as being pre-defined by the language? I can't keep track of them all. -- So what if I have a fertile brain? Fertilizer happens. -- Larry Wall in [EMAIL PROTECTED]
