Re: A concept for Exceptions
Luke Palmer [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tue, 15 Oct 2002 14:33:28 -0400
I like the idea of this. The finer details, like returning what to
do, could be more elegant. But the extensibility idea is golden.
To change how certain exceptions behave, a block simply changes the methods
of the existing ExceptionCreator to point to other subroutines. This
approach allows for an ala carte style of exception configuration. Blocks
can (through a module that makes this sort of thing easy), clone the
ExceptionCreator object, then change just the methods that are desired. A
reference to that new object is passed down the line to child blocks.
I think a clone should be implicit (and lazy). Exception handlers
should be lexically (or dynamically?) scoped. Dynamically could be
useful in that if a module generated some known exception, you could
tell it what to do---on it's level. I worry that this could break
things too easily, though.
I definitely like this idea in that it eliminates a lot of
redundancy. Instead of 10 CATCH blocks doing the same thing with
different names, you just have one handler that does it all.
Exceptions are always something that seemed tedious to me (though I
have had some fun with them), and this might possibly relieve that.
If you have 10 different exceptions that you want to handle in the
same way then you should probably look at subclassing them. Then all
you have to do is
try {
...
CATCH MyExceptionParent { ... }
}
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Character Properties
-- On Mon, 21 Oct 2002 16:49:57 Dan Sugalski wrote: Almost. At least perl 5's macros look like C. Emacs' macro horrors make C look like Lisp... This is because C is _clearly_ a dialect of Lisp . . . -Erik -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Character Properties
On Tue, 22 Oct 2002, Erik Steven Harrison wrote: : On Mon, 21 Oct 2002 16:49:57 : Dan Sugalski wrote: : : Almost. At least perl 5's macros look like C. Emacs' macro horrors : make C look like Lisp... : : This is because C is _clearly_ a dialect of Lisp . . . Yeah, look at all the extra parentheses around things like conditionals and argument lists... Larry
Re: Help! Bugs! Crawling all over!
On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote: Steve Fink wrote: I currently get three test failures when running with GC_DEBUG on, but not always the same three (depending on how I muck with unrelated parts of the code.) On my system I get failures with op/string.t tests 96 and 97 and pmc/pmc.t test 76 (aka 75) The first two can be fixed by the patch below. The last one looks like a fundamental problem in MultiArray. The line b-cell_buffer = new_buffer_header(interpreter); in function new_marray is creating a new buffer header, overwriting the new_bufferlike_header created earlier. Yes!! Thank you! I am now getting just the one error you're seeing too. Earlier I also saw an error in sprintf.t. In fact, I still have a patch in my tree for it. The error was only triggered by gc, but seemed to be wrong regardless. I'll have to look at it again; I could have been fooling myself. Patch applied, with much rejoicing.
[PATCH] multiarray memory management
On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote:
The last one looks like a fundamental problem in MultiArray.
The line
b-cell_buffer = new_buffer_header(interpreter);
in function new_marray is creating a new buffer header, overwriting
the new_bufferlike_header created earlier.
I didn't really read enough of the code to know whether this is doing
at all the right thing or not, but here's a trial patch that makes the
test failure go away on my machine, at least. Josef, can you take a
look? Apply with patch -p0 multiarray.patch in the parrot directory.
Index: classes/multiarray.pmc
===
RCS file: /cvs/public/parrot/classes/multiarray.pmc,v
retrieving revision 1.5
diff -p -u -r1.5 multiarray.pmc
--- classes/multiarray.pmc 7 Sep 2002 02:29:09 - 1.5
+++ classes/multiarray.pmc 22 Oct 2002 07:00:30 -
-56,7 +56,7 typedef struct _cell_buffer CELL_B;
* cell buffer representation
*/
struct _cell_buffer {
-Buffer *cell_buffer;
+Buffer buffer;
INTVAL size;
INTVAL free_cell;
PMC *dimension;
-102,7 +102,7 static INTVAL calc_offset_multi(struct P
dim_key = cell_data-dimension;
my_key = k;
-if(cell_data-cell_buffer != NULL dim_key != NULL my_key != NULL ) {
+if(cell_data-buffer.bufstart != NULL dim_key != NULL my_key != NULL ) {
/* first part of alg.
* (i + (j-1)*Ni
-155,7 +155,7 static void expand_cell_buffer( struct P
{
CELL_B *b = data;
if(new_size b-size) {
- Parrot_reallocate(interpreter, b-cell_buffer, new_size * sizeof(CELL));
+ Parrot_reallocate(interpreter, b-buffer, new_size * sizeof(CELL));
b-free_cell += (new_size - b-size);
b-size = new_size;
}
-171,7 +171,7 static CELL *new_cell( struct Parrot_Int
CELL *ret_cell;
INTVAL new_size = 0;
CELL_B *cell_b = data;
-ret_cell = (CELL *)cell_b-cell_buffer-bufstart;
+ret_cell = (CELL *)cell_b-buffer.bufstart;
if((cell_b-free_cell-1) 0) {
cell_b-free_cell -= 1;
-179,7 +179,7 static CELL *new_cell( struct Parrot_Int
new_size = cell_b-size*2;
expand_cell_buffer( interpreter, cell_b, new_size);
cell_b-free_cell -= 1;
- ret_cell = (CELL *)cell_b-cell_buffer-bufstart;
+ ret_cell = (CELL *)cell_b-buffer.bufstart;
}
return ret_cell[cell_b-size - cell_b-free_cell-1]; /* notice -1 we start at 0
*/
}
-188,13 +188,11 static CELL *new_cell( struct Parrot_Int
static CELL_B *new_marray( Interp *interpreter )
{
CELL_B *b = (CELL_B *)new_bufferlike_header(interpreter, sizeof(*b));
-/* CELL_B *b = (CELL_B *)new_tracked_header(interpreter, sizeof(*b)); */
b-size = CELL_POOL_SIZE;
b-free_cell = CELL_POOL_SIZE;
-b-cell_buffer = new_buffer_header(interpreter);
b-dimension = NULL;
-Parrot_allocate(interpreter, b-cell_buffer , CELL_POOL_SIZE*sizeof(CELL));
-memset( b-cell_buffer-bufstart, 0, CELL_POOL_SIZE*sizeof(CELL));
+Parrot_allocate(interpreter, b-buffer, CELL_POOL_SIZE*sizeof(CELL));
+memset( b-cell_buffer.bufstart, 0, CELL_POOL_SIZE*sizeof(CELL));
return b;
}
-208,8 +206,8 static void init_marray( Interp *interpr
PMC *oldkey;
marray = new_marray(interpreter);
-marray-cell_buffer-flags |= PMC_is_buffer_ptr_FLAG;
-marray-cell_buffer-flags |= PMC_is_PMC_ptr_FLAG;
+marray-buffer.flags |= PMC_is_buffer_ptr_FLAG;
+marray-buffer.flags |= PMC_is_PMC_ptr_FLAG;
self-data = (CELL_B *)marray;
self-cache.int_val = 0;
-225,8 +223,8 static void init_marray( Interp *interpr
marray-size = size;
marray-free_cell = size;
-Parrot_reallocate(interpreter, marray-cell_buffer, marray-size * sizeof(CELL));
-memset(marray-cell_buffer-bufstart, 0, marray-size * sizeof(CELL));
+Parrot_reallocate(interpreter, marray-buffer, marray-size * sizeof(CELL));
+memset(marray-buffer.bufstart, 0, marray-size * sizeof(CELL));
marray-dimension = oldkey;
}
-249,7 +247,7 static INTVAL get_marray_keyed( Interp *
offs = calc_offset_multi(interpreter, mg_marray, key);
-base = (CELL *)mg_marray-cell_buffer-bufstart;
+base = (CELL *)mg_marray-buffer.bufstart;
buffer_ptr = base[offs];
buffer_ptr_virt = buffer_ptr;
-319,7 +317,7 static void set_marray_keyed( Interp *in
CELL *base;
INTVAL offs = 0;
offs = calc_offset_multi(interpreter, sik_marray, key);
- base = (CELL *)sik_marray-cell_buffer-bufstart;
+ base = (CELL *)sik_marray-buffer.bufstart;
my_cell = base[offs];
my_cell-virtual_addr = offs;
my_cell-data.int_val = src_value;
-827,7 +825,7 pmclass MultiArray {
INTVAL stalker;
marray = SELF-data;
- base = (CELL *)marray-cell_buffer-bufstart;
+ base = (CELL *)marray-buffer.bufstart;
size = stalker = marray-size;
while(stalker = 0) {
ptr =
Re: [RFC] 2. Proposal for _keyed opcodes
Juergen Boemmels wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
What happens if you try to use it on an object which has no real
components like a bitvector or a packed structure?
The substituted code for an aggregate is:
set Py, P1[k1]
and for a non keyed operand:
set Py, {N,S,I}1
There will always
be a pack-unpack cycle. On the other hand, is there any case where
this pack-unpack cycle can be avoided?
Yes, if the 3rd operand is an integer, we have some opcodes like
add_p_p_i
The newly created PMC is of type PerlUndef. Is this the correct
behavior or shouldn't it be the same type as the old element in the
Component? Something like this.
As in my example, the LHS might and does not exist yet, so you can't get
the type of it. And The PerlUndef convert's itself to the result of the
operation automagically, so it's IMHO the correct way to do it.
With an approach like this, we could cut down the VTABLE to roughly
1/3 of it's current size. The _keyed entrys would only consist of the
set_.._keyed{,_int} variants plus exists_keyed and defined_keyed. And,
we would never have the opcode explosion to 64 times of current size.
Instead of 1 opcode and 1 vtable-lookup with a quite complex
vtable-function you have 6 opcodes and 5 vtable lookups with simple
vtable-functions.
Take the new px, .PerlUndef out of the calculation, it can be done
only once. The vtable lookup's are there, either hidden in a complex
opcode, or explictely like in my solution.
So the difference are +4 opcodes worst case. But opcode dispatch is
really fast. A better cache locality will bring us back this speed
difference.
... Also no vtable function has to
decide wether its called with 1, 2 or 3 keyed elements.
Yes, another advantage, I didn't think of. Currently all _keyed vtable
calls have to check, it the key is really there. This could be tossed.
bye
b.
leo
Re: Another vtable update
Dan Sugalski wrote: Copying is the right thing to do here. If the compiler wants to put copies of things into an aggregate, it can make copies first. Ok, fine. I'll update comments WRT clone. leo
Re: [RFC] 2. Proposal for _keyed opcodes
Dan Sugalski wrote:
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
With an approach like this, we could cut down the VTABLE to roughly
1/3 of it's current size. The _keyed entrys would only consist of the
set_.._keyed{,_int} variants plus exists_keyed and defined_keyed. And,
we would never have the opcode explosion to 64 times of current size.
The big disadvantage here is speed. It means that specialized aggregates
will have to create temporary PMCs for things that don't already have
them, which is potentially slow and wasteful, something I'd rather
avoid.
No, take the new px, .PerlUndef out of the opcode, it must only be
done once. This temporary Px can be reused by _all_ _keyed ops.
If the LHS doesn't exist, like in my example, a new PMC has to be
created anyway. If the LHS exists, the set_value methods assigns a new
value.
The only difference of my solution is +4 opcode dispatches worst case
minus some checks, we now have, that a key exists. These checks in each
_keyed method could be tossed then.
And for my demonstration I did use current existing set_ ops. I could
imagine, thats - as in my proposal - special key_ ops could be used,
which have the variable/value split built in, i.e. they could prepare
pointers to the PMC values directly.
Encouraging the use of specialized aggregates is one of the
reasons for the typing system coming in with perl 6, and given the size
of aggregates in perl 5 I think it's something that will see some heavy
use.
The HL language can and will use multi_keyed operations. Sean already
stated, that probably every (local) variable usage will be a multi_keyed
operation, where the aggregates are the lexical scope pads.
I just hide these operations in the assembler (or imcc currently).
I don't mind the opcode explosion, honestly. It's automatically
generated, and that's not a big deal. There are other ways to cut down
on it as well, if we find the need.
I do mind. We currently have ~900 opcodes. We would have ~6 opcodes.
I can't imagine, that the CPU cache will be happy with that many
opcodes. You could multiply this by 4 (normal, CGoto, CPderef, JIT) for
an estimation of a final full fledged parrot executable size.
For the moment, I'd rather things stay the way they are. If we can
produce demonstrable speed wins, then I'll change my mind.
It's hard to demonstrate speed wins against a system we don't have. But
I'll have a closer look, how to simulate this.
... For now,
though, things stay generally the way they are. We can do some mild
reworking to get things manageable if they're currently really
unmanageable.
As I already demonstrated wtih my op_stat, currently 1/3 opcodes is
unused, neither parrot tests, nor any perl6 program produces this ops.
With the final ~6 opcodes, we would probably have 1000 used ops,
scattered over a huge program - this is unmanagable IMHO.
leo
Re: Two problems groping around in PerlHashes
Dan Sugalski wrote: For plain PerlHash PMCs, yes, they should be PMCs only. The union went into them in a fit of enthusiasm and generality. :) More specialized aggregates can hold more specialized things, but I'm not sure we're going to have a need for something that really efficiently holds multiple fundamental data types. All-ints, floats, strings, or PMCs, sure, and certainly ones with tighter restrictions on what types of PMCs can be stored, but I doubt we'll see a general need to store, say, PMCs and ints. Hash and arrays are diffent here, IMHO. An array either stores a PMC or is an array of e.g. packed ints. Hash creation doesn't have a notation, what will be stored in the hash finally. If a lot of plain int's are stored in the hash, the current approach is faster, because there is no need to generate a PMC for holding the value - though not so space efficient. So I'm not too sure, if we need two hashes, one for PMCs and a general one. leo
Re: [RFC] 2. Proposal for _keyed opcodes
Dan Sugalski wrote:
For the moment, I'd rather things stay the way they are. If we can
produce demonstrable speed wins, then I'll change my mind.
I have some preliminary numbers:
- changed core.ops to include add_keyed [1]
- did implement add_keyed_int in array
- hacked set_pmc_keyed_int() to resemble the set_value approach [2]
- changed test program to do 10^5 add_keyed (+100 checks for ok)
$ time parrot a.pbc # 3 keyed emulation
ok
real0m0.563s
$ time parrot k.pbc # 3 keyed opcode
ok
real0m0.503s
So the direct add_keyed_int is ~10% faster then my proposal.
[1] This adds 9 opcodes. We still don't have the _kc variants.
[2] this breaks perl6's t/compiler/1_4, where proably a clone would help
(it's a postincrement z[0]++).
So, when looking at the size of just one method (~60 lines for just
add_keyed_int) I can't imagine that implementing all these _keyed
methods is the way to go.
leo
--- parrot/classes/array.pmcMon Oct 21 15:23:30 2002
+++ parrot-leo/classes/array.pmcTue Oct 22 13:05:56 2002
-306,14 +306,23
}
void set_pmc_keyed_int (INTVAL* dest_key, PMC* src, INTVAL* src_key) {
-
+ PMC* ptr;
if (!dest_key) {
return;
}
- Parrot_Array_set_pmc_ptr(INTERP, (List *) SELF-data, *dest_key);
+ ptr = Parrot_Array_set_pmc_ptr(INTERP, (List *) SELF-data, *dest_key);
if (src_key)
src = src-vtable-get_pmc_keyed_int(INTERP, src, src_key);
+ /* we have a valid value at this point, if src is a scalar,
+* jus move the data over */
+ if (!src-data) {
+ mem_sys_memcopy(ptr-cache.int_val, src-cache.int_val,
+ sizeof(UnionVal));
+ ptr-vtable = src-vtable;
+ ptr-flags = src-flags;
+ }
+ else
list_assign(INTERP, (List *) SELF-data, *dest_key,
(void*)src, enum_type_PMC);
}
-494,6 +503,71
INTVAL is_equal_keyed_int (INTVAL* key, PMC* value, INTVAL* value_key) {
/* XXX */
return 0;
+}
+
+void add_keyed_int (INTVAL* key, PMC* value, INTVAL* value_key, PMC* dest,
+INTVAL* dest_key) {
+ INTVAL i1, i2, i3;
+ FLOATVAL f1, f2, f3;
+ int type = enum_class_PerlInt;
+
+ if(value-vtable == Parrot_base_vtables[enum_class_PerlNum]) {
+ type = enum_class_PerlNum;
+ }
+ else if(value-vtable == Parrot_base_vtables[enum_class_PerlString]) {
+ f2 = value-vtable-get_number(INTERP, value);
+ i2 = value-vtable-get_integer(INTERP, value);
+ if(f2 != i2)
+ type = enum_class_PerlNum;
+ }
+ if (type == enum_class_PerlInt) {
+ if(SELF-vtable == Parrot_base_vtables[enum_class_PerlNum]) {
+ type = enum_class_PerlNum;
+ }
+ else if(SELF-vtable == Parrot_base_vtables[enum_class_PerlString]) {
+ f2 = SELF-vtable-get_number(INTERP, SELF);
+ i2 = SELF-vtable-get_integer(INTERP, SELF);
+ if(f2 != i2)
+ type = enum_class_PerlNum;
+ }
+ }
+ if (value_key) {
+ if (type == enum_class_PerlInt)
+ i3 = value-vtable-get_integer_keyed_int(INTERP, value, value_key);
+ else
+ f3 = value-vtable-get_number_keyed_int(INTERP, value, value_key);
+ }
+ else {
+ if (type == enum_class_PerlInt)
+ i3 = value-vtable-get_integer(INTERP, value);
+ else
+ f3 = value-vtable-get_number(INTERP, value);
+ }
+ if (key) {
+ if (type == enum_class_PerlInt)
+ i2 = SELF-vtable-get_integer_keyed_int(INTERP, SELF, key);
+ else
+ f2 = SELF-vtable-get_number_keyed_int(INTERP, SELF, key);
+ }
+ else {
+ if (type == enum_class_PerlInt)
+ i2 = SELF-vtable-get_integer(INTERP, SELF);
+ else
+ f2 = SELF-vtable-get_number(INTERP, SELF);
+ }
+ if (type == enum_class_PerlInt) {
+ i1 = i2 + i3;
+ if (key)
+ dest-vtable-set_integer_keyed_int(INTERP, dest, dest_key, i1);
+ else
+ dest-vtable-set_integer_native(INTERP, dest, i1);
+ }
+ else {
+ f1 = f2 + f3;
+ if (key)
+ dest-vtable-set_number_keyed_int(INTERP, dest, dest_key, i1);
+ else
+ dest-vtable-set_number_native(INTERP, dest, i1);
+ }
}
}
--- parrot/k.pasm Tue Oct 22 13:09:59 2002
+++ parrot-leo/k.pasm Tue Oct 22 10:58:12 2002
-0,0 +1,31
+_main:
+ new P0, 10 # .PerlArray
+ new P1, 10 # .PerlArray
+ new P2, 10 # .PerlArray
+ set I0, 0
+ set I1, 10
+loop:
+ set P1[I0], I0
+ set P2[I0], I0
+ add P0[I0], P1[I0], P2[I0]
+ inc I0
+ le I0, I1, loop
+ set I0, 0
+lp2:
+ set I2, P0[I0]
+ shr
Re: 64-bit ints and non-capable hardware
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, I'm about ready to just bite the bullet and declare that INTVALs have to be 64 bit integers. Does anyone know of a platform that has neither native nor emulated 64 bit integers? (One we're likely to run on, rather) I'm fairly new to Parrot, but I've spent a while following standards tracks for languages such as C and C++, and also using Perl, so hopefully I'm not too far off the mark here... I was wondering if anyone else followed the discussion in comp.std.c about integer types, prior to the adoption of the C99 standard? There was a substantial paper put out by Frank Farance, entitled specification based extended integer range or SBEIR for short; see http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/. It wasn't adopted at the time, mostly because it was too big a lump to swallow, too late in the standardisation process, but it looks like it might be timely for Parrot to consider the concepts involved. The basic idea is to express the requirements that a program has for its integers, and let the compiler choose the best option; minimum size trap-on-overflow, take-modulus-on-overflow, exactness of size (for modulus operation), compactness speed There were objections that this was too complex, and that some combinations didn't make sense. To address the complexity, I proposed that integers should be subcategorised as classical versus logical. Classical integers included all the existing C integer types, while logical integers were those based on usage specification rather than storage specification. In practice a logical specification would be something like an exact range of values with trap-on-overflow, whereas a classical or low level specification would be something like the range held by a CPU register, with host-specific handling of overflows. The relevance to Parrot is that, rather than opting for a short-list of integer sizes like [8, 16, 32 and 64 bit], we should if possible allow an extensible type system, possibly including optional automatic promotion to a library-implemented integer type (BigNum, Complex, or whatever). -Martin (I find it quiet disappointing that modern languages like Java and C# rely entirely on storage-based integer specifications 64 bit, when languages like Pascal and Algol had range-specified integers 20 years ago.) -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
Re: [perl #18044] Assembler doesn't return a useful exit status
On Mon, 21 Oct 2002, Clinton Pierce wrote: * With bad arguments, the assembler returns 1 to the OS. Peachy. Please can we have... #include sysexits.h exit(EX_USAGE); // 64 on most platforms * Upon failure, the assembler returns the status 0 to the OS and writes some bytecode. No telling how healthy that bytecode is. exit(EXIT_FAILURE); // 1 on most platforms -Martin -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
Re: [RFC] 2. Proposal for _keyed opcodes
Leopold Toetsch [EMAIL PROTECTED] writes:
Dan Sugalski wrote:
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
With an approach like this, we could cut down the VTABLE to roughly
1/3 of it's current size. The _keyed entrys would only consist of
the set_.._keyed{,_int} variants plus exists_keyed and
defined_keyed. And, we would never have the opcode explosion to 64
times of current size.
The big disadvantage here is speed. It means that specialized
aggregates will have to create temporary PMCs for things that don't
already have them, which is potentially slow and wasteful, something
I'd rather avoid.
No, take the new px, .PerlUndef out of the opcode, it must only be
done once. This temporary Px can be reused by _all_ _keyed ops.
Im not sure about this. This really depends on the fact if the
op does something depending on the type of LHS. If it doesn't need any
information about this type then even the new px, .PerlUndef is not
really needed (This is just an artefact of the fact that the
vtable-functions are called with value of the register instead of the
register). But if the context-information is needed then the right
context must be provided. If this context evalutation is done in the
vtable function then its up to the PMC-implementation to decide if
its needed. OTOH the compiler has no chance to decide if this context
is necessary or not.
If the LHS doesn't exist, like in my example, a new PMC has to be
created anyway. If the LHS exists, the set_value methods assigns a new
value.
If we would change the signature of the vtable function to
add (PMC *, PMC *, PMC **lhs) and the call in the op to
$2-vtable-add($2,$3,$1), then the new is not need. The signature of
the add op could also be changed to add (out PMC, in PMC, in PMC)
The only difference of my solution is +4 opcode dispatches worst case
minus some checks, we now have, that a key exists. These checks in
each _keyed method could be tossed then.
[...]
b.
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Perl 6 Summary for last week (JVM-PBC)
If memory serves me right, Piers Cawley wrote: /me is a newcomer from DotGNU ... and has missed the mails quoted, hence here's what I have .. Regarding JVM - Parrot Compatibility Newcomer Karthik Kumar is interested in writing a tool to convert java .class files to parrot .pbc files and asked for information on what had been done in this area. I had a run-in with JILC (http://savannah.gnu.org/projects/jilc/), in which the entire JVM loading and disassembly was hijacked from my curriculum project work The ILC part is still lacking (the reasons for /me giving up is simple, those people started jilc.sf.net :-) But KK should be able to make use of the code atleast partially ... it's very easy to get the basics working because of the low number of JVM bytecodes. Don't fall into that trap /me has made that mistake once ... In JVM a localvariable can contain any data type , viz ints,floats, or objects.. It takes a lot of flow analysis to figure out what type is in a particular localvar.. iconst_0 istore_0 goto jmp1 fconst_0 fstore_0 goto jmp2 jmp1: iload_0 pop // or maybe a toString() which clears the stack ? jmp2: fload_0 pop // or a println(); is a valid bytecode formation ... viz, I need to split this into 2 localvars and track with type information for IL ... (no, it's not an undecidability problem , but still it's difficult which is yet another reason why JILC got left in the wayside) I'm assuming that parrot will need a similar mapping to store to the 'I' and 'F' type registers ? Gopal -- The difference between insanity and genius is measured by success
Re: [RFC] 2. Proposal for _keyed opcodes
Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: No, take the new px, .PerlUndef out of the opcode, it must only be done once. This temporary Px can be reused by _all_ _keyed ops. Im not sure about this. This really depends on the fact if the op does something depending on the type of LHS. My timing test was done with the new px, .PerlUndef out of the loop, and worked after some tweaking of the array_set_pmc_keyed_int. ... If it doesn't need any information about this type then even the new px, .PerlUndef is not really needed (This is just an artefact of the fact that the vtable-functions are called with value of the register instead of the register). We will see, what Dan's plans WRT variable/value vtable's will look like. ... But if the context-information is needed then the right context must be provided. If this context evalutation is done in the vtable function then its up to the PMC-implementation to decide if its needed. The LHS of an add_keyed may exist or not. Extending a PerlArray creates a PerlUndef anyway. So the LHS is not concerned. The questions is already, how to set the value of the LHS. If we would change the signature of the vtable function to add (PMC *, PMC *, PMC **lhs) and the call in the op to $2-vtable-add($2,$3,$1), then the new is not need. Yes, that's similar to my current hack. ... The signature of the add op could also be changed to add (out PMC, in PMC, in PMC) If the add creates a new PMC holding the value (or the value is changed directly), yes. I think this is similar to set vs assign. b. leo
RE: 64-bit ints and non-capable hardware
At 3:59 PM -0700 10/21/02, Brent Dax wrote: Dan Sugalski: # Okay, I'm about ready to just bite the bullet and declare that # INTVALs have to be 64 bit integers. # # Does anyone know of a platform that has neither native nor emulated # 64 bit integers? (One we're likely to run on, rather) Mac Classic processors and Palm DragonBalls? While the 68K doesn't do 64-bit natively, neither does the x86, but gcc provides emulation, so that's not a problem. Dunno about the DragonBall, but I'd bet we're out of luck generally for 64 bit stuff there. By the way, it looks like Palm OS now supports stdio emulation. Well, cool. That's darned good news. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #18054] [PATCH] changes to fix tools/dev/manicheck.pl output
# New Ticket Created by Matthew Zimmerman # Please include the string: [perl #18054] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18054 These changes to the root .cvsignore and to the MANIFEST fix two file accounting issues. 1) The executable test in the root directory is automatically generated by Configure.pl but is not ignored by (my) CVS, resulting in incorrect output from tools/dev/manicheck.pl (it was listed as 'Extra' instead of 'Ignored'). 2) As discovered by Nicholas Clark, the files in icu/source were never entered into the MANIFEST, and are thus deleted whenever a make distclean or make cvsclean is done. Part 1 obsoletes issue #17989. -- Matt -- Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/ -- attachment 1 -- url: http://rt.perl.org/rt2/attach/40318/32601/2915f8/manicheck.patch diff -ubBr parrot/.cvsignore parrot-matt/.cvsignore --- parrot/.cvsignore Wed Oct 16 17:37:22 2002 +++ parrot-matt/.cvsignore Tue Oct 22 13:18:52 2002 -19,3 +19,4 jit_cpu.c core_pmcs.c *.tmp +test diff -ubBr parrot/MANIFEST parrot-matt/MANIFEST --- parrot/MANIFEST Tue Oct 22 13:16:36 2002 +++ parrot-matt/MANIFESTTue Oct 22 12:54:12 2002 -201,6 +201,1003 global_setup.c hash.c headers.c +icu/source/common/Makefile.in +icu/source/common/bidi.cpp +icu/source/common/brkdict.cpp +icu/source/common/brkdict.h +icu/source/common/brkiter.cpp +icu/source/common/chariter.cpp +icu/source/common/charstr.h +icu/source/common/cmemory.c +icu/source/common/cmemory.h +icu/source/common/common.dsp +icu/source/common/common.rc +icu/source/common/convert.cpp +icu/source/common/cpputils.h +icu/source/common/cstring.c +icu/source/common/cstring.h +icu/source/common/cwchar.c +icu/source/common/cwchar.h +icu/source/common/dbbi.cpp +icu/source/common/dbbi_tbl.cpp +icu/source/common/dbbi_tbl.h +icu/source/common/digitlst.cpp +icu/source/common/digitlst.h +icu/source/common/filestrm.c +icu/source/common/filestrm.h +icu/source/common/hash.h +icu/source/common/icucfg.h.in +icu/source/common/locid.cpp +icu/source/common/locmap.c +icu/source/common/locmap.h +icu/source/common/mutex.cpp +icu/source/common/mutex.h +icu/source/common/normlzr.cpp +icu/source/common/putil.c +icu/source/common/rbbi.cpp +icu/source/common/rbbicst.pl +icu/source/common/rbbidata.cpp +icu/source/common/rbbidata.h +icu/source/common/rbbinode.cpp +icu/source/common/rbbinode.h +icu/source/common/rbbirb.cpp +icu/source/common/rbbirb.h +icu/source/common/rbbirpt.h +icu/source/common/rbbirpt.txt +icu/source/common/rbbiscan.cpp +icu/source/common/rbbiscan.h +icu/source/common/rbbisetb.cpp +icu/source/common/rbbisetb.h +icu/source/common/rbbistbl.cpp +icu/source/common/rbbitblb.cpp +icu/source/common/rbbitblb.h +icu/source/common/resbund.cpp +icu/source/common/schriter.cpp +icu/source/common/symtable.h +icu/source/common/uassert.h +icu/source/common/ubidi.c +icu/source/common/ubidiimp.h +icu/source/common/ubidiln.c +icu/source/common/ubidiwrt.c +icu/source/common/ubrk.cpp +icu/source/common/uchar.c +icu/source/common/uchriter.cpp +icu/source/common/ucln.h +icu/source/common/ucln_cmn.c +icu/source/common/ucln_cmn.h +icu/source/common/ucmndata.c +icu/source/common/ucmndata.h +icu/source/common/ucmp8.c +icu/source/common/ucmp8.h +icu/source/common/ucnv.c +icu/source/common/ucnv2022.c +icu/source/common/ucnv_bld.c +icu/source/common/ucnv_bld.h +icu/source/common/ucnv_cb.c +icu/source/common/ucnv_cnv.c +icu/source/common/ucnv_cnv.h +icu/source/common/ucnv_err.c +icu/source/common/ucnv_imp.h +icu/source/common/ucnv_io.c +icu/source/common/ucnv_io.h +icu/source/common/ucnv_lmb.c +icu/source/common/ucnv_u16.c +icu/source/common/ucnv_u32.c +icu/source/common/ucnv_u7.c +icu/source/common/ucnv_u8.c +icu/source/common/ucnvbocu.c +icu/source/common/ucnvhz.c +icu/source/common/ucnvisci.c +icu/source/common/ucnvlat1.c +icu/source/common/ucnvmbcs.c +icu/source/common/ucnvmbcs.h +icu/source/common/ucnvscsu.c +icu/source/common/udata.c +icu/source/common/udatamem.c +icu/source/common/udatamem.h +icu/source/common/uenum.c +icu/source/common/uenumimp.h +icu/source/common/uhash.c +icu/source/common/uhash.h +icu/source/common/uhash_us.cpp +icu/source/common/uiter.cpp +icu/source/common/uloc.c +icu/source/common/umapfile.c +icu/source/common/umapfile.h +icu/source/common/umemstrm.c +icu/source/common/umemstrm.h +icu/source/common/umutex.c +icu/source/common/umutex.h +icu/source/common/unames.c +icu/source/common/unicode.cpp +icu/source/common/unicode/bidi.h +icu/source/common/unicode/brkiter.h +icu/source/common/unicode/chariter.h +icu/source/common/unicode/convert.h +icu/source/common/unicode/dbbi.h +icu/source/common/unicode/docmain.h +icu/source/common/unicode/locid.h +icu/source/common/unicode/normlzr.h
Re: 64-bit ints and non-capable hardware
At 6:25 PM -0400 10/21/02, Bryan C. Warnock wrote: On Mon, 2002-10-21 at 15:11, Dan Sugalski wrote: Okay, I'm about ready to just bite the bullet and declare that INTVALs have to be 64 bit integers. Which INTVALs? I registers. INTVAL, IMHAOSBRPO[1], is overused internally. I see little relative performance and size damage if INTVAL is made 64 bits and relegated only to user-space math as long as the internals (pointer-tracking, sizes, offsets, etc) are left as native. You can check and cast when numbers cross over. OTOH, converting all of the internals to 64-bit is probably not such a good idea. Of course, I registers are probably being used for both uses completely independent of each other. Yeah, and they don't need to be. Most of the internals can leave native integers to be whatever's most convenient and fastest Or did I miss the point on wherefore 64-bit? Nope, that's pretty much it. At this point, I think I've given up on requiring 64 bit ints. If they're rare enough, then they can just be in PMCs and be done with it. We can always revisit that decision later if it's really important. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #18056] [PATCH] Extending the Packfile (Part 1.)
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18056]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18056
This patch is the beginning of an effort to make PackFile format
extendible. At the moment its combatible with the old bytecode
format.
Ok, to the details:
It appends a 4th segment behind the 3 already defined segments (FIXUP,
CONSTANT and BYTECODE) name DIRECTORY. After this directory one ore
more uniquely named segments may follow.
The directory segments start with the number of segments in the
PackFile, followed by a list of directory items. Each item constists
of a '\0' terminated c-string (padded to opcode_t-alignment), a
flag-word, the size of the corresponding segment and the position of
the segment in the packfile. The 4 first segments are nothing special,
expect that their name and order is fixed.
The implementation uses a glib style inheritance aproach. The
base-class of all Segments is struct PackFile_Segment which consists
of data-members for name, packfile, fileoffset, size and flags and
furter the member-functions destroy, packed_size, and pack. The
derived classes struct PackFile_Directory, PackFile_ConstTable
PackFile_FixupTable and PackFile_ByteCode (the later two are ATM just
dummy implementations) embed a PackFile_Segment as first elment so the
base-class can be get by a pointer cast.
Next steps might be:
- seperate the packfile.c in diffrent files (maybe move them to a
directory/subsystem on its own as suggest by PDD07) one for each
segment-type.
- document the extension in parrotbyte.pod
- lower the restriction on the ordering of the first 4 segments
- write an objdump-like tool for manipulating packfiles. (I tried to
extend pdump for that, but it segfaults in unmake_COW, a
NULL-interpreter from PIO_eprintf)
- Teach the assembler to output the new format. (imcc uses AFAIK
packout.c and should already work)
bye
b.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40325/32605/06f52f/packfile.diff
Index: packfile.c
===
RCS file: /cvs/public/parrot/packfile.c,v
retrieving revision 1.57
diff -u -r1.57 packfile.c
--- packfile.c 11 Oct 2002 01:46:31 - 1.57
+++ packfile.c 22 Oct 2002 00:26:35 -
-19,6 +19,46
#define TRACE_PACKFILE 0
+/*
+** Static functions
+*/
+static void segment_init (struct PackFile_Segment *self,
+ struct PackFile *pf,
+ const char* name,
+ PackFile_Segment_destroy_func_t destroy,
+ PackFile_Segment_packed_size_func_t packed_size,
+ PackFile_Segment_pack_func_t size);
+
+static void default_destroy (struct PackFile_Segment *self);
+static size_t default_packed_size (struct PackFile_Segment *self);
+static size_t default_pack (struct PackFile_Segment *self,
+opcode_t *dest, size_t offset, size_t size);
+
+static struct PackFile_Directory *directory_new (struct PackFile *pf);
+static size_t directory_unpack (struct PackFile *pf, opcode_t *cursor);
+static void directory_destroy (struct PackFile_Segment *self);
+static size_t directory_packed_size (struct PackFile_Segment *self);
+static size_t directory_pack (struct PackFile_Segment *self,
+ opcode_t *dest, size_t offset, size_t size);
+
+static struct PackFile_FixupTable *fixup_new (struct PackFile *pf);
+static size_t fixup_packed_size (struct PackFile_Segment *self);
+static size_t fixup_pack (struct PackFile_Segment * self,
+ opcode_t *dest, size_t offset, size_t size);
+
+static struct PackFile_ConstTable *const_new (struct PackFile *pf);
+static void const_destroy (struct PackFile_Segment *self);
+static size_t const_pack (struct PackFile_Segment *self,
+ opcode_t *dest, size_t offset, size_t size);
+
+static struct PackFile_ByteCode *byte_code_new (struct PackFile *pf);
+static size_t byte_code_packed_size (struct PackFile_Segment *self);
+static size_t byte_code_pack (struct PackFile_Segment *self,
+ opcode_t *dest, size_t offset, size_t size);
+
+/* internal definitions */
+#define ROUND_UP(val,size) ((val) + (size) - (val)%(size))
+
/**
=head1 PackFile Manipulation Functions
-61,8 +101,7
}
/* Create fixup table */
-pf-fixup_table =
-mem_sys_allocate(sizeof(struct PackFile_FixupTable));
+pf-fixup_table = fixup_new(pf);
if (!pf-fixup_table) {
PIO_eprintf(NULL, PackFile_new: Unable to allocate fixup table!\n);
-72,21 +111,22
pf-fixup_table-dummy = 0;
/* Create constant table */
-pf-const_table =
-mem_sys_allocate(sizeof(struct PackFile_ConstTable));
Re: 64-bit ints and non-capable hardware
Martin D Kealey wrote: I was wondering if anyone else followed the discussion in comp.std.c about integer types, prior to the adoption of the C99 standard? There was a substantial paper put out by Frank Farance, entitled specification based extended integer range or SBEIR for short; see http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/. Very interesting proposal. I wish they had adopted it. Would have saved me a lot of hassle with typedefs over the years. :-) This kind of system works well in a statically compiled language like C because the compiler can look at signed int exact:32 and say Oh! That's just int on this platform! and then compile away the distinction. I'm not sure how well it would work in a dynamic environment like Parrot, where the compiler doesn't necessarily know the final actual type. It is up to the runtime engine. e.g. how would the engine rearrange the code to do signed int exact:64 with PMC's on 32-bit platforms and I registers on 64-bit? That way lies polymorphic instruction sets and other CLI madness ... Having said that, it might be nice to have a variant on BIGINT that can be dynamically range-limited using dynamically-specified rules. Then 64-bit ints can be created as instances of RANGEBIGINT. Cheers, Rhys. P.S. I suspect one reason why it was rejected was because some programmer would ask for signed int exact:23517 and expect it to work on every compiler. Implementing the intrinsics for something like that is *hard*.
Re: [perl #18054] [PATCH] changes to fix tools/dev/manicheck.pl output
On Tue, Oct 22, 2002 at 05:34:18PM +, Matthew Zimmerman wrote: # New Ticket Created by Matthew Zimmerman # Please include the string: [perl #18054] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18054 These changes to the root .cvsignore and to the MANIFEST fix two file accounting issues. 1) The executable test in the root directory is automatically generated by Configure.pl but is not ignored by (my) CVS, resulting in incorrect output from tools/dev/manicheck.pl (it was listed as 'Extra' instead of 'Ignored'). 2) As discovered by Nicholas Clark, the files in icu/source were never entered into the MANIFEST, and are thus deleted whenever a make distclean or make cvsclean is done. Part 1 obsoletes issue #17989. Thanks, applied.
Re: [perl #17903] [PATCH] sprintf test
On Thu, Oct 17, 2002 at 02:51:24PM +0200, Leopold Toetsch wrote: Steve Fink wrote: I don't know exactly who has the permissions to do these things, but I'm pretty sure that if you have commit access then you also have RT futzing access. I tried to set the status of my patches to resolved after committing and got something like forbidden. Hm. Sorry. I assumed that if it worked for me, it would work for anyone. Robert has fixed one permission problem recently; can you give it another try? Thanks.
Re: [perl #17936] [PATCH] MANIFEST
On Mon, Oct 14, 2002 at 11:06:05PM +, J?rgen B?mmels wrote: # New Ticket Created by J?rgen B?mmels # Please include the string: [perl #17936] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17936 There are again some files missing in MANIFEST. HINT: I have still [perl #16839] in my tree, so errors like this are really easy to recognize. Thanks, I just applied #16839. Sorry for the delay; I've meant to apply that patch for quite a while.
Re: [perl #17502] [PATCH] config/gen/makefiles/classes.in - compiler flag bug
On Sep-22, Bruce Gray wrote:
# New Ticket Created by Bruce Gray
# Please include the string: [perl #17502]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17502
To specify a rule to build object files from C files,
root.in correctly says:
.c$(O) :
$(CC) $(CFLAGS) ${cc_o_out}$ -c $
but classes.in gets it wrong:
.c$(O):
$(CC) $(CFLAGS) ${cc_exe_out}$ -c $
The bug does not show up under platforms (like Unix) where the two
flags are the same. It bit me on Win32, with the free Borland
compiler.
This patch corrects the problem.
Thanks, applied.
Re: [perl #17506] [PATCH] lib/Parrot/Configure/Step.pm - litterbug
On Sep-22, Bruce Gray wrote: # New Ticket Created by Bruce Gray # Please include the string: [perl #17506] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17506 lib/Parrot/Configure/Step.pm, in sub cc_clean, is trying to clean up its test compiles by 'unlink glob test.*'. This fails to remove 'test', the executable name under Unixes, because it has no extension. Also, the unlink is unnecessarily aggressive; it might remove 'test.o.i_saved_for_a_reason. Step.pm created all the test files, and it should know how to enumerate them during cleanup. This patch teaches it how. Thanks, applied.
Re: [PATCH] String literals (was Re: Return of RE match)
On Oct-08, Dakkar wrote: I discovered the problem: print Yes r\n if 0 =~ /0/; print Yes s\n if 0 =~ 0; printed only Yes s The problem is NOT in the RE engine, but in the string literal code in P6C/Tree/String.pm I replaced some if ($stuff) with if (defined $stuff) and now it works. The problem was that a string 0 is false, but it's not the same as (which would get used instead). Proof: print 0;print \n; prints an empty line. I attach a small patch: it's quite possible that by adding 'defined' in several places I broke something else. People familiar with the code will undoubtedly correct my patch. Looks good as far as I can tell. Applied, thanks.
Re: [PATCH] multiarray memory management
On Oct-22, Steve Fink wrote: On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote: The last one looks like a fundamental problem in MultiArray. The line b-cell_buffer = new_buffer_header(interpreter); in function new_marray is creating a new buffer header, overwriting the new_bufferlike_header created earlier. I didn't really read enough of the code to know whether this is doing at all the right thing or not, but here's a trial patch that makes the test failure go away on my machine, at least. Josef, can you take a look? Apply with patch -p0 multiarray.patch in the parrot directory. Oops. That patch is missing one s/cell_buffer/buffer/. But the patch is big enough that I won't spam the list with it again; if you apply it, you'll need to fix the compile error first. But really, I just like replying to myself.
Perl 6 Summary for last week
The Perl 6 Summary for the week ending 20021020
I'm sorry to have to inform you that I've returned from my holiday (no,
base jumping and paragliding were *not* involved) and that this week's
summary will not be written by the estimable Leon Brocard. Sorry about
that. Leon is currently taking a rest cure.
So, with the customary mention of Mister Brocard out of the way good and
early this week, it's time to take a look at what's been discussed on
the internals list:
Regarding JVM - Parrot Compatibility
Newcomer Karthik Kumar is interested in writing a tool to convert java
.class files to parrot .pbc files and asked for information on what
had been done in this area. Leon Brocard says it's very easy to get the
basics working because of the low number of JVM bytecodes. But getting
the fundamentals (classes, objects) right is hard. Ramesh
Ananthakrishnan commented that it might be a little early for anything
more than proofs of concept at the moment as Parrot is a rapidly moving
target. Ramesh also came up with the idea of compiling `real machine'
assembly language to `virtual machine' parrot assembler.
Karthik commented that the real issue seems to be one of what level of
support Parrot will offer for objects, and until that is known the
class-parrot problem is almost pointless to solve.
http://makeashorterlink.com/?S18F26432
http://makeashorterlink.com/?C19F22432 -- Ramesh clarifies his `Linux
in Parrot' idea.
The Getting Started Guide
Erik Lechak is still not loving POD but, despite his distaste he posted
version 0.4 of his getting started guide in POD format. Thanks a lot
Erik. Marty Pauley suggested that Erik take a look at the Simple
Document Format which may meet his needs better than POD
http://makeashorterlink.com/?F2AF11432
http://makeashorterlink.com/?Z5BF34432
C# and Parrot
Rhys Weatherly, author of Portable.NET, part of the DotGNU project made
a welcome appearance on the list. Apparently the DotGNU people are
looking into compiling C# down to parrot bytecode and hoped that there
might be parrot people who were interested in trying to complete their
compiler and system library.
Rhys wanted to know how to make a user-defined class in Parrot; what the
convention is for which registers must be saved across a call; the size
of int and whether there was a way to store and access auxiliary data
in a Parrot bytecode file.
Answers were provided. Sadly, the answer to Rhys's question about
user-defined classes was You don't, yet. Other answers were more
immediately useful.
The DotGNU weekly IRC meeting discussed Parrot this week, Leon and Dan
managed to cover both sessions between them, and there's a log
available.
http://makeashorterlink.com/?M2CF21432
http://makeashorterlink.com/?J1DF11432 -- Condensed summary of the
meeting
http://ajmitch.dhis.org/dotgnu/ -- unedited logs available here
Variable/Value Split Prelims
Leopold Toetsch rather confused me when he replied to a two week old
message (I thought I'd completely screwed up setting the `limit by date'
values in my summary buffer) about the conceptual split between
variables and values. Leo wanted some clarification which Dan provided.
http://makeashorterlink.com/?M4EF21432 -- Dan's old message
http://makeashorterlink.com/?C3FF22432 -- Leo's questions
PMC Initializers
Leon Brocard attempted to kick start discussion of Jonathan Sillito's
patch to pass more information when creating new PMCs. Leopold Toetsch
and Josef Höök both said they thought that something along those lines
was a good idea, but the discussion seemed to die there. Later in the
week, Dan introduced the new init_pmc function to PDD02, which works
along the lines suggested.
http://makeashorterlink.com/?V20023532
http://makeashorterlink.com/?I11021532
PerlHash questions
Clinton A. Pierce wondered about how to do the equivalent of exists
$hash{$key} in Parrot when one doesn't necessarily know the types of
the things in the hash. Leo Toetsch pointed to exists_keyed and
type_keyed. Jason Gloudon pointed out that the docs for type_keyed
referred only to PMCs, with no mention of 'primitive' types. He wondered
if PerlHash shouldn't just dictate that its contents were all PMCs.
http://makeashorterlink.com/?M62042532
Meanwhile in Perl6-language
The language group is trying to catch up with internals in number of
posts. They managed 89 posts this week compared to internals' 96. If you
discount attachments, language probably won on volume (and it certainly
wins hands down on the `difficulty of summarization' metric).
Draft Proposal: Declaring Classwide Attributes
The discussion of how to declare classwide attributes rumbled on from
last week; I'll just pick out a few
