Re: Threads: Time to get the terminology straight
05/01/04 04:51:20, Sam Vilain [EMAIL PROTECTED] wrote: On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote; I accept that it may not be possible on all platforms, and it may be too expensive on some others. It may even be undesirable in the context of Parrot, but I have seen no argument that goes to invalidate the underlying premise. I think you missed this: LT Different VMs can run on different CPUs. Why should we make atomic LT instructions out if these? We have a JIT runtime performing at 1 LT Parrot instruction per CPU instruction for native integers. Why LT should we slow down that by a magnitude of many tenths? LT We have to lock shared data, then you have to pay the penalty, but LT not for each piece of code. . So far, I have only suggested using the mechanism in conjuction with PMCs and PMC registers. You can't add an in-use flag to a native integer. But then, native integers are not a part of the VHLLs (perl/Python/Ruby). The are a consituent part of scalars, but they use different register set and opcodes. Copying the integer value of a scalar into an I register would require locking the scalars PMC. Once the value is in the I register, operations performed on it would not need to be synchronised. Once the resultant is calculated, it need to be moved back to the PMC and lock is cleared. There should be no need to interlock on most opcodes dealing with the I and R register sets. The S registers are a different kettle of fish, and I haven't worked through the implications for these. My gut feels is that the C-style strings pointed at by S registers would be protected by the in-use flag set on the PMCs for the scalars from which they are derived. This means that when a single PMC opcode results in a sequence of non-PMC operations, then other shared threads would be blocked from operations until the sequence of non-PMC ops in the first shared thread where complete. But ONLY if they attempt access to the same PMC. If they are processing PMC or non-PMC operations that do not involve the in-use PMC, then they will not be blocked and will be scheduled for their timeslices in the normal way. and this: LT I think, that you are missing multiprocessor systems totally. If the mutex mechanism that is use to block the shared threads is SMP, NUMA, AMP etc. safe, then the mechanism I describe is also safe in these envirnments. You are effectively excluding true parallellism by blocking other processors from executing Parrot ops while one has the lock. . The block only occurs *IF* concurrent operations on the same data are attempted. You may as well skip the thread libraries altogether and multi-thread the ops in a runloop like Ruby does. But let's carry the argument through, restricting it to UP systems, with hyperthreading switched off, and running Win32. Is it even true that masking interrupts is enough on these systems? . No masking of interupts is involved anywhere! I don't know where the idea arises, but it wasn't from me. Win32 `Critical Sections' must be giving the scheduler hints not to run other pending threads whilst a critical section is running. Maybe it uses the CPU sti/cli flags for that, to avoid the overhead of setting a memory word somewhere (bad enough) or calling the system (crippling). In that case, setting STI/CLI might only incur a ~50% performance penalty for integer operations. . I don't have access to the sources, but I do know that when one thread has entered a critical section, all other threads and processes continue to be scheduled in the normal way except those that also try to enter the critical section. Scheduling is only disabled for those threads that *ask* to be so, and no others. Either within the process or other processes. How the mechanism works I can only speculate, but no CLI/STI instructions are involved. total speculation When the first thread enters the critsec, a flag is set in the critsec memory. When a second thread attempts to enter the critsec, a flag is set in the corresponding scheduler table to indicate that it should not be scheduled again until the flag is cleared. When the first thread leaves the critsec, the flag in the critsec memory is cleared and the flag(s) in the scheduler tables for any thread(s) blocking on the critsec are also cleared. Which ever of the blocked threads is next scheduled, it aquires the critsec, sets the flag in the critsec memory and the process repeats. /total speculation No masking of interupts is involved. but then there's this: NS Other internal housekeeping operations, memory allocation, garbage NS collection etc. are performed as sysopcodes, performed by the VMI NS within the auspices of the critical section, and thus secured. UG there may be times when a GC run needs to be initiated DURING a VM UG operation. if the op requires an immediate lare chunk of ram it UG can trigger a GC pass or allocation request. you can't force those UG things to only
newclass bug, or something
The following program segfaults after 510 iterations: .sub _main $I0 = 0 again: $S1 = anon $S0 = $I0 inc $I0 concat $S1, $S0 newclass $P0, $S1 find_type $I2, $S1 print $I2 print \n if $I0 1000 goto again end .end It runs fine if I Csweepoff at the beginning, and indeed, it dies during DOD, since bucket points to an invalid memory location. I haven't the slightest clue what's wrong beyond that. Here's the gdb backtrace: #0 0x080809d2 in mark_hash (interpreter=0x826f9b0, hash=0x8dfb38) at src/hash.c:297 297 (hash-mark_key)(interpreter, (PObj *)bucket-key); (gdb) bt #0 0x080809d2 in mark_hash (interpreter=0x826f9b0, hash=0x8dfb38) at src/hash.c:297 #1 0x081cfabb in Parrot_PerlHash_mark (interpreter=0x826f9b0, pmc=0x8dfb50) at perlhash.c:62 #2 0x081fefcf in Parrot_OrderedHash_mark (interpreter=0x826f9b0, pmc=0x8dfb50) at orderedhash.c:57 #3 0x080b764c in trace_children (interpreter=0x826f9b0, current=0x8dfb50) at src/dod.c:251 #4 0x080b74ea in trace_active_PMCs (interpreter=0x826f9b0, trace_stack=1) at src/dod.c:201 #5 0x080b7cad in Parrot_do_dod_run (interpreter=0x826f9b0, trace_stack=1) at src/dod.c:744 #6 0x081f0ba7 in more_traceable_objects (interpreter=0x826f9b0, pool=0x8277170) at src/smallobject.c:71 #7 0x081f0cbc in get_free_object (interpreter=0x826f9b0, pool=0x8277170) at src/smallobject.c:134 #8 0x080b66a7 in get_free_buffer (interpreter=0x826f9b0, pool=0x8277170) at src/headers.c:55 #9 0x080b6be6 in new_bufferlike_header (interpreter=0x826f9b0, size=60) at src/headers.c:250 #10 0x08080f46 in new_hash_x (interpreter=0x826f9b0, hptr=0x8dfb50, val_type=enum_type_PMC, val_size=0, hkey_type=Hash_key_type_ascii, compare=0x8080565 STRING_compare, keyhash=0x8080518 key_hash_STRING, mark=0x80b71d8 pobject_lives) at src/hash.c:516 #11 0x08080f05 in new_hash (interpreter=0x826f9b0, hptr=0x8dfb50) at src/hash.c:477 #12 0x081cfa92 in Parrot_PerlHash_init (interpreter=0x826f9b0, pmc=0x8dfb50) at perlhash.c:55 #13 0x081fefa5 in Parrot_OrderedHash_init (interpreter=0x826f9b0, pmc=0x8dfb50) at orderedhash.c:50 #14 0x0807ed8a in pmc_new (interpreter=0x826f9b0, base_type=23) at src/pmc.c:51 #15 0x081ecfd0 in Parrot_new_class (interpreter=0x826f9b0, class=0x8dfbb0, class_name=0x9a7e70) at src/objects.c:131 #16 0x080cefda in Parrot_newclass_p_s (cur_opcode=0x8291608, interpreter=0x826f9b0) at object.ops:123 #17 0x0807e1c5 in runops_slow_core (interpreter=0x826f9b0, pc=0x8291608) at src/runops_cores.c:115 #18 0x080753b3 in runops_int (interpreter=0x826f9b0, offset=0) at src/interpreter.c:628 #19 0x08075455 in runops_ex (interpreter=0x826f9b0, offset=0) at src/interpreter.c:650 #20 0x08075606 in runops (interpreter=0x826f9b0, offset=0) at src/interpreter.c:701 #21 0x080b0ad5 in Parrot_runcode (interpreter=0x826f9b0, argc=1, argv=0xb8dcf16c) at src/embed.c:513 #22 0x08074611 in main (argc=1, argv=0xb8dcf16c) at imcc/main.c:548 #23 0x00232ba7 in __libc_start_main () from /lib/libc.so.6 gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice) Luke
Crash when joining multiple threads
If I run this code, which should just be a loop which creates-then-joins a thread (looping twice), I get a crash at the end: set I16, 0 again: inc I16 new P5, .ParrotThread find_global P6, _foo find_method P0, P5, thread3 invoke set I5, P5 getinterp P2 find_method P0, P2, join invoke lt I16, 2, again print done\n end .pcc_sub _foo: invoke P1 The problem is that when joining the _second_ time, in pt_thread_join() you get a return value from joining the thread--which happens to contain a thread-interpreter PMC: (gdb) p (char*)((PMC*)retval)-vtable-isa_str-strstart $2 = 0x1dc40c ParrotThread ParrotInterpreter This then gets cloned, which ultimately ends up messing up the interpreter_array[] (things end up in the wrong slot), and pt_join_threads() ends up trying to join a bogus thread, and you get a crash. So, the bug seems to be that the second time through, you get a return value from the thread. I don't know why this is happening--haven't tried digging yet. JEff
[perl #24808] [PATCH] Fix for remaining PPC JIT failures
# New Ticket Created by Jeff Clites # Please include the string: [perl #24808] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24808 Attached are patches to fix the remaining make testj failures on Mac OS X (i.e., ppc jit). These fixes are relative to my previously submitted patch with other ppc jit fixes, [perl #24789]. Notes: 1) ppc/jit_emit.h -- Augmented Parrot_jit_begin to handle the restart case (to forward branch to the correct initial op), fixed Parrot_jit_cpcf_op to update the appropriate registers in the case of an inter-segment branch, and implemented Parrot_jit_restart_op. This fixes all of the remaining testj failures on Mac OS X (except for the arithmetics.t failure, fixed below). 2) t/op/interp.t -- Enabled threading tests on darwin. 3) src/spf_render.c -- Added one line to prevent -0.0 on platforms which get this from negating zero. (This fix is in the sprintf-ish code because the sign bit on zero only makes a difference when printing, not in mathematical operations.) This fixes the failure of test 7 of t/op/arithmetics.t on platforms on which it was failing for this reason. After applying these fixes (and those from [perl #24789]), all JIT tests pass on Mac OS X: All tests successful, 28 subtests skipped. Files=61, Tests=1021, 79 wallclock secs (25.51 cusr + 20.62 csys = 46.13 CPU) JEff interp_t.patch Description: Binary data ppc-jit_emit_h.patch Description: Binary data spf_render_c.patch Description: Binary data
Re: newclass bug, or something
Luke Palmer [EMAIL PROTECTED] wrote: The following program segfaults after 510 iterations: .sub _main $I0 = 0 again: $S1 = anon $S0 = $I0 inc $I0 concat $S1, $S0 newclass $P0, $S1 find_type $I2, $S1 print $I2 print \n if $I0 1000 goto again end .end Yep. Tricky. The init code of OrderedHash didn't clear the ptr, where the hash isn't yet constructed. Now during DOD this pointer was marked as a PerlHash which caused the segfault. It runs fine if I Csweepoff at the beginning, and indeed, $ parrot -G x.imc # turn off DOD Thanks for reporting, leo
[PATCH] The Return of the Priority DOD
After many months of lying dormant, I figured I'd get my act together
and adapt this patch to the few recent modifications. And this time,
I'm posting a benchmark!
My results get about 5% slowdown in the eager case, and the usual
10,000% speedup in the lazy case.
Luke
First, the benchmark (examples/benchmarks/dod_priority.imc):
#! /usr/bin/env parrot
# Call this program with an argument of 0 (or no arguments at all)
# to see the priority dod behavior. Call with an argument of 1 to
# see the full sweep.
.pcc_sub _main non_prototyped
.param pmc argv
.const int ntimes = 1
.const int nestlevel = 1000
.sym int sweep_arg
$I0 = argv
if $I0 = 1 goto set_zero
$P0 = argv[1]
sweep_arg = $P0
goto continue
set_zero:
sweep_arg = 0
continue:
$I0 = nestlevel
$P0 = new PerlString
$P0 = Foo!
needs_destroy $P0
makenest:
unless $I0 goto last
dec $I0
$P1 = new PerlArray
$P1[0] = $P0
$P0 = $P1
goto makenest
last:
# That concludes making the data structure, now let's run
# DOD a bunch of times (we're still in the root set in $P0)
$I0 = ntimes
again:
unless $I0 goto last2
dec $I0
if sweep_arg goto sweep_one
sweep 0
goto again
sweep_one:
sweep 1
goto again
last2:
end
.end
---
And the patch:
? vtable.dump
? examples/benchmarks/dod_priority.imc
Index: classes/timer.pmc
===
RCS file: /cvs/public/parrot/classes/timer.pmc,v
retrieving revision 1.7
diff -u -r1.7 timer.pmc
--- classes/timer.pmc 25 Aug 2003 09:46:23 - 1.7
+++ classes/timer.pmc 5 Jan 2004 13:30:45 -
@@ -253,7 +253,7 @@
t-self = SELF;
SELF-cache.struct_val = t;
PObj_active_destroy_SET(SELF);
- interpreter-has_early_DOD_PMCs = 1;
+ ++interpreter-num_early_DOD_PMCs;
}
void init_pmc(PMC *init) {
Index: include/parrot/dod.h
===
RCS file: /cvs/public/parrot/include/parrot/dod.h,v
retrieving revision 1.11
diff -u -r1.11 dod.h
--- include/parrot/dod.h28 Jul 2003 13:38:00 - 1.11
+++ include/parrot/dod.h5 Jan 2004 13:30:46 -
@@ -40,7 +40,12 @@
#define Parrot_is_blocked_GC(interpreter) \
((interpreter)-GC_block_level)
-void Parrot_do_dod_run(struct Parrot_Interp *, int trace_stack);
+enum {
+DOD_trace_stack_FLAG = 1 0,
+DOD_lazy_FLAG= 1 1
+};
+
+void Parrot_do_dod_run(struct Parrot_Interp *, UINTVAL flags);
void trace_system_areas(struct Parrot_Interp *);
void trace_mem_block(struct Parrot_Interp *, size_t, size_t);
Index: include/parrot/interpreter.h
===
RCS file: /cvs/public/parrot/include/parrot/interpreter.h,v
retrieving revision 1.114
diff -u -r1.114 interpreter.h
--- include/parrot/interpreter.h2 Jan 2004 14:09:32 - 1.114
+++ include/parrot/interpreter.h5 Jan 2004 13:30:46 -
@@ -247,7 +247,6 @@
/* per interpreter global vars */
INTVAL world_inited;/* Parrot_init is done */
-PMC *mark_ptr; /* last PMC marked used in DOD runs */
PMC *iglobals; /* SArray of PMCs, containing: */
/* 0: PMC *Parrot_base_classname_hash; hash containing name-base_type */
/* 1: PMC *Parrot_compreg_hash;hash containing assembler/compilers */
@@ -255,7 +254,12 @@
/* 3: PMC *Env;hash_like Env PMC */
/* 4: PMC *ParrotInterpreter that's me */
/* 5: PMC *Dyn_libs Array of dynamically loaded ParrotLibrary */
-int has_early_DOD_PMCs; /* Flag that some want immediate destruction */
+UINTVAL num_early_DOD_PMCs; /* how many PMCs want immediate destruction */
+UINTVAL num_early_PMCs_seen;/* how many such PMCs has DOD seen */
+PMC* dod_mark_ptr; /* last PMC marked during a DOD run */
+PMC* dod_trace_ptr; /* last PMC trace_children was called on */
+int lazy_dod; /* flag that indicates whether we should stop
+ when we've seen all impatient PMCs */
PMC* DOD_registry; /* registered PMCs added to the root set */
struct MMD_table *binop_mmd_funcs; /* Table of MMD function pointers */
PMC** nci_method_table; /* Method table PMC for NCI stubs per class */
Index: include/parrot/pobj.h
===
RCS file: /cvs/public/parrot/include/parrot/pobj.h,v
retrieving revision 1.31
diff -u -r1.31 pobj.h
--- include/parrot/pobj.h 24 Dec 2003 10:43:08 - 1.31
+++ include/parrot/pobj.h 5 Jan 2004 13:30:46 -
@@ -224,12 +224,14 @@
*/
b_PObj_is_special_PMC_FLAG = 1 26,
-b_PObj_needs_early_DOD_FLAG = 1 27,
+/* true if this is connected by some route to a
Re: [perl #24796] [PATCH] build errors on solaris
Lars Balker Rasmussen [EMAIL PROTECTED] wrote: Adding a hints file for solaris solves two thread-related link issues. Applied - thanks, leo
Re: [perl #24808] [PATCH] Fix for remaining PPC JIT failures
Jeff Clites [EMAIL PROTECTED] wrote: Attached are patches to fix the remaining make testj failures on Mac OS X (i.e., ppc jit). These fixes are relative to my previously submitted patch with other ppc jit fixes, [perl #24789]. ... which still seems to be missing. Could you rediff all against current please. leo
Re: Crash when joining multiple threads
Jeff Clites [EMAIL PROTECTED] wrote: If I run this code, which should just be a loop which creates-then-joins a thread (looping twice), I get a crash at the end: The problem is that when joining the _second_ time, in pt_thread_join() you get a return value from joining the thread The return value is only returned, when I3 != 0. For your example that shouldn't be the case (I3 is unused aka zero). So there isn't any return value passed back. Are you running the latest source? It doesn't crash here. JEff leo
Re: [perl #24797] [PATCH] libnci build problem on FreeBSD
Lars Balker Rasmussen [EMAIL PROTECTED] wrote: nci_test.c included malloc.h which is deprecated on FreeBSD Applied, as well as #24802. Thanks, leo
Re: [PATCH] The Return of the Priority DOD
Luke Palmer [EMAIL PROTECTED] wrote:
After many months of lying dormant, I figured I'd get my act together
and adapt this patch to the few recent modifications. And this time,
I'm posting a benchmark!
Wow, thanks.
Some comments:
-b_PObj_needs_early_DOD_FLAG = 1 27,
+/* true if this is connected by some route to a needs_early_DOD object */
+PObj_high_priority_DOD_FLAG = 1 27,
+PObj_needs_early_DOD_FLAG = (1 27 | 1 28),
Moving the needs_early_DOD_FLAG out of the arena_flags is suboptimal
(and probably the reason for the 5% slowdown for the eager case). Now the
relevant flags is the high_priority_DOD_FLAG. If I get the patch right,
it gets set on the PMC itself and all its parents.
So it would be fine, if the high_priority_DOD_FLAG would be in the
arena_flags nibble. The tests in the fast path of pobject_lives can then
go away - PMCs that can contain other PMCs can't be the parent of PMCs
that need timely destruction, so that should work. And all PMCs, that
can contain other PMCs must have a PMC_EXT attached with the next_for_GC
pointer.
And if that helps, we can just say: If an object needs timely
destruction it must have the PMC_EXT struct attached, so that marking
is out of the fast path.
@@ -45,21 +45,45 @@
UINTVAL *dod_flags = arena-dod_flags + ns;
if (*dod_flags ((PObj_on_free_list_FLAG | PObj_live_FLAG) nm))
return;
+if (*dod_flags PObj_on_free_list_FLAG nm)
+return;
This seems bogus, if the flag is set, the first test has succeeded.
+if (PObj_high_priority_DOD_TEST(obj) interpreter-dod_trace_ptr)
+/* set obj's parent to high priority */
+PObj_high_priority_DOD_SET(interpreter-dod_trace_ptr);
That could go probably below, if the special_PMC_FLAG is set.
@@ -84,23 +108,38 @@
-if (PObj_is_special_PMC_TEST(obj)) {
+if (*dod_flags (PObj_is_special_PMC_FLAG nm)) {
This seems to be the non-ARENA_DOD_FLAGS case, so above doesn't work.
leo
Re: [PATCH] The Return of the Priority DOD
Luke Palmer [EMAIL PROTECTED] wrote: One more remark: +if (PObj_needs_early_DOD_TEST(obj)) +++interpreter-num_early_PMCs_seen; When is this counter reset? leo
Re: [PATCH] The Return of the Priority DOD
On Jan 5, 2004, at 5:47 AM, Luke Palmer wrote: After many months of lying dormant, I figured I'd get my act together and adapt this patch to the few recent modifications. And this time, I'm posting a benchmark! My results get about 5% slowdown in the eager case, and the usual 10,000% speedup in the lazy case. Sounds cool; do you have a quick high-level description of what it's all about? (I had seen that needs_early_DOD flag in the source, and didn't know what it was intended to do.) Thanks! JEff
Re: Crash when joining multiple threads
On Jan 5, 2004, at 5:32 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
If I run this code, which should just be a loop which
creates-then-joins a thread (looping twice), I get a crash at the end:
The problem is that when joining the _second_ time, in
pt_thread_join()
you get a return value from joining the thread
The return value is only returned, when I3 != 0. For your example that
shouldn't be the case (I3 is unused aka zero). So there isn't any
return
value passed back.
Yep, the second time through I find REG_INT(3) (that is,
interpreter-int_reg.registers[3]) set to 1 in thread_func().
Are you running the latest source? It doesn't crash here.
Yep, I just verified, using a clean checkout and build:
% gdb parrot
...
(gdb) b src/thread.c:238
Breakpoint 1 at 0xf890c: file src/thread.c, line 238.
(gdb) r thrspeed.pasm
Starting program:
/Users/jac/Projects/parrot/parrot-thread-join-crash/parrot
thrspeed.pasm
Reading symbols for shared libraries . done
Breakpoint 1, pt_thread_join (parent=0x1000200, tid=1) at
src/thread.c:238
238 if (retval) {
(gdb) p retval
$1 = (void *) 0x0
(gdb) c
Continuing.
Breakpoint 1, pt_thread_join (parent=0x1000200, tid=1) at
src/thread.c:238
238 if (retval) {
(gdb) p retval
$2 = (void *) 0x10163d0
(gdb) p (char*)((PMC*)retval)-vtable-isa_str-strstart
$3 = 0x1da410 ParrotThread ParrotInterpreter
(gdb) c
Continuing.
done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90039138 in pthread_join ()
(gdb) bt
#0 0x90039138 in pthread_join ()
#1 0x000f8b78 in pt_join_threads (interpreter=0x1000200) at
src/thread.c:309
#2 0xaba0 in Parrot_really_destroy (exit_code=0,
vinterp=0x1000200) at src/interpreter.c:1123
#3 0xc120 in Parrot_exit (status=0) at src/exit.c:48
#4 0x3544 in main (argc=1, argv=0xbbd4) at imcc/main.c:555
(gdb) f 1
#1 0x000f8b78 in pt_join_threads (interpreter=0x1000200) at
src/thread.c:309
309 JOIN(thread_interp-thread_data-thread, retval);
(gdb) p thread_interp-thread_data
$4 = (struct _Thread_data *) 0x903520
(gdb) p thread_interp-thread_data-thread
$5 = 0x0
And here's myconfig:
Summary of my parrot 0.0.13 configuration:
configdate='Mon Jan 5 08:33:02 2004'
Platform:
osname=darwin, archname=darwin
jitcapable=1, jitarchname=ppc-darwin,
jitosname=DARWIN, jitcpuarch=ppc
execcapable=1
perl=perl
Compiler:
cc='cc', ccflags='-g -pipe -pipe -fno-common -no-cpp-precomp
-DHAS_TELLDIR_PROTOTYPE -pipe -fno-common -Wno-long-double ',
Linker and Libraries:
ld='cc', ldflags=' -flat_namespace ',
cc_ldflags='',
libs='-lm'
Dynamic Linking:
so='.dylib', ld_shared=' -flat_namespace -bundle -undefined
suppress',
ld_shared_flags=''
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=4 byteorder=4321,
nv=double, numvalsize=8, doublesize=8
JEff
Re: [PATCH?] Error in t/src/list.t on FreeBSD
Lars Balker Rasmussen [EMAIL PROTECTED] wrote: I was seeing an error in the second test in t/src/list.t on FreeBSD: set_integer_keyed() not implemented in class 'PerlInt' I tracked it down to two consecutive calls to pmc_new() returning the same pointer, which is generally not what you want. All these (non-trivial) source tests, that create some resources should use the scheme of t/src/basic_3. leo
Generating optimized PIR?
Optimized for speed, at least. I'm finding that large subs seem to give imcc headaches. I'm not sure if it's O(n^2) or O(2^n) headaches, but definitely issues. At the moment I've got parrot churning on some pir code and it's taking quite a while. Final time tally: real41m46.978s user21m24.300s sys 0m41.080s Ended with a missing symbol error, of course, just to rub it in a bit. vm_stat reports a lot of zero-fill page allocation (about 1600 4K pages/sec) though the memory footprint isn't growing to match, so that might indicate at least something of the problem. (For all I know there's some sort of degenerate GC issue somewhere, depending on how imcc does its memory allocation and management) I know IMCC's being redone, and we're nowhere near close to optimized, but I think it'd be worth it to get a handle on what sorts of things are likely to trigger off exponential time compiles when fed to IMCC. I'm assuming that it's due to a combination of sub size (about 61K of source in one sub) and locals needing coloring (132) but it'd be nice to know for sure. For me, reducing the size of the sub's untenable, but I can switch from using locals to using pad or global variables that get fetched as need be if that means less compile time. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Threads: Time to get the terminology straight
At 2:43 AM + 1/5/04, Nigel Sandever wrote: 05/01/04 01:22:32, Sam Vilain [EMAIL PROTECTED] wrote: [STUFF] :) In another post you mentions intel hyperthreading. Essentially, duplicate sets of registers within a single CPU. Do these need to apply lock on every machine level entity that they access? No. Why not? Because they can only modify an entity if it is loaded into a register and the logic behind hyperthreading won't allow both register sets to load the same entity concurrently. This seems generally common for SMT core CPUs (though some of them may allow multiple references in different threads on-chip and just keeps the data sync'd up--I've not looked), unfortunately, is untenable for Parrot. The hardware gets to throw massive amounts of parallelism at the problem, a luxury we, alas, don't have. (I'm pretty sure they also play some serious register remapping games and deferred speculative execution tricks to not deadlock) To do this would require that every time a PMC register was loaded that all the PMC registers of any other active interpreter in the interpreter group be scanned. Kind of a pricey operation. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Threads Design. A Win32 perspective.
At 4:03 PM -0800 1/4/04, Damien Neil wrote: It's my understanding that Parrot has chosen to take the path of using many mutable data structures at the VM level; unfortunately, this is pretty much incompatible with a fast or elegant threading model. Yep, generally true. The choice was made on purpose, and I was aware of most of the ramifications of it, both good and ill. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH?] Error in t/src/list.t on FreeBSD
Leopold Toetsch [EMAIL PROTECTED] writes:
All these (non-trivial) source tests, that create some resources should
use the scheme of t/src/basic_3.
I've rewritten list.t and hash.t to use this scheme, generalizing the
layout a bit in the process. I'm not sure about the reasoning for one
of the interpreter setups in the old hash.t (marked with XXX), and
whether it's needed now - seems to work fine without, but that may not
be the point.
I'll do the rest of them later, but I really should work on other
stuff now :-)
Cheers,
--
Lars Balker Rasmussen Consult::Perl
Index: t/src/exit.t
===
RCS file: /cvs/public/parrot/t/src/exit.t,v
retrieving revision 1.5
diff -u -a -r1.5 exit.t
--- t/src/exit.t 13 Dec 2003 15:01:19 - 1.5
+++ t/src/exit.t 5 Jan 2004 18:16:30 -
@@ -10,6 +10,7 @@
printf(pre-exit\n);
Parrot_exit(0);
printf(post-exit\n);
+return 0;
}
CODE
pre-exit
Index: t/src/hash.t
===
RCS file: /cvs/public/parrot/t/src/hash.t,v
retrieving revision 1.10
diff -u -a -r1.10 hash.t
--- t/src/hash.t 13 Dec 2003 15:01:19 - 1.10
+++ t/src/hash.t 5 Jan 2004 18:16:30 -
@@ -3,63 +3,79 @@
use Parrot::Test tests = 10;
-c_output_is('CODE', 'OUTPUT', new_hash);
+my $main = 'CODE';
+#include parrot/parrot.h
+#include parrot/embed.h
-#include stdio.h
-#include parrot/parrot.h
-#include parrot/embed.h
+static opcode_t *the_test(Parrot_Interp, opcode_t *, opcode_t *);
-int main(int argc, char* argv[]) {
-Interp* interpreter;
+int exit_value = 0;
+
+int main(int argc, char* argv[])
+{
+Parrot_Interp interpreter = Parrot_new(NULL);
+if (!interpreter) {
+return 1;
+}
+Parrot_init(interpreter);
+
+Parrot_run_native(interpreter, the_test);
+
+Parrot_exit(exit_value);
+return exit_value;
+}
+
+CODE
+
+c_output_is($main . 'CODE', 'OUTPUT', new_hash);
+
+static opcode_t*
+the_test(struct Parrot_Interp *interpreter,
+ opcode_t *cur_op, opcode_t *start)
+{
Hash *hash;
STRING *key;
HashEntry value;
-interpreter = Parrot_new(NULL);
-
-if ( interpreter == NULL ) return 1;
-
-Parrot_init(interpreter);
+UNUSED(cur_op);
+UNUSED(start);
new_hash(interpreter, hash);
if ( hash == NULL ) {
- printf(hash creation failed\n);
- return 1;
+ PIO_eprintf(interpreter, hash creation failed\n);
+ exit_value = 1;
+ return NULL;
}
-printf(ok\n);
+PIO_eprintf(interpreter, ok\n);
-return 0;
+return NULL;
}
CODE
ok
OUTPUT
-c_output_is('CODE', 'OUTPUT', hash_put);
-
-#include stdio.h
-#include parrot/parrot.h
-#include parrot/embed.h
+c_output_is($main . 'CODE', 'OUTPUT', hash_put);
-int main(int argc, char* argv[]) {
-Interp* interpreter;
+static opcode_t*
+the_test(struct Parrot_Interp *interpreter,
+ opcode_t *cur_op, opcode_t *start)
+{
Hash *hash;
STRING *key;
HashEntry value;
-interpreter = Parrot_new(NULL);
-
-if ( interpreter == NULL ) return 1;
-
-Parrot_init(interpreter);
+UNUSED(cur_op);
+UNUSED(start);
new_hash(interpreter, hash);
if ( hash == NULL ) {
- printf(hash creation failed\n);
- return 1;
+ PIO_eprintf(interpreter, hash creation failed\n);
+ exit_value = 1;
+ return NULL;
}
key = string_from_cstring(interpreter, fortytwo, 0);
@@ -67,39 +83,35 @@
value.val.int_val = 42;
hash_put(interpreter, hash, key, value);
-printf(ok\n);
+PIO_eprintf(interpreter, ok\n);
-return 0;
+return NULL;
}
CODE
ok
OUTPUT
-c_output_is('CODE', 'OUTPUT', hash_get);
+c_output_is($main . 'CODE', 'OUTPUT', hash_get);
-#include stdio.h
-#include parrot/parrot.h
-#include parrot/embed.h
-
-int main(int argc, char* argv[]) {
-Interp* interpreter;
+static opcode_t*
+the_test(struct Parrot_Interp *interpreter,
+ opcode_t *cur_op, opcode_t *start)
+{
Hash *hash;
STRING *key;
HashEntry _value;
HashEntry *value = _value;
-interpreter = Parrot_new(NULL);
-
-if ( interpreter == NULL ) return 1;
-
-Parrot_init(interpreter);
+UNUSED(cur_op);
+UNUSED(start);
new_hash(interpreter, hash);
if ( hash == NULL ) {
- printf(hash creation failed\n);
- return 1;
+ PIO_eprintf(interpreter, hash creation failed\n);
+ exit_value = 1;
+ return NULL;
}
key = string_from_cstring(interpreter, fortytwo, 0);
@@ -108,39 +120,35 @@
hash_put(interpreter, hash, key, value);
value = hash_get(interpreter, hash, key);
-printf(%i\n, (int)value-val.int_val);
+PIO_eprintf(interpreter, %i\n, (int)value-val.int_val);
-return 0;
+return NULL;
}
CODE
42
OUTPUT
-c_output_is('CODE', 'OUTPUT', hash_get with NULL key);
-
-#include stdio.h
-#include parrot/parrot.h
-#include parrot/embed.h
+c_output_is($main . 'CODE', 'OUTPUT',
Re: Generating optimized PIR?
On Mon, 5 Jan 2004 10:59:18 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: I know IMCC's being redone, and we're nowhere near close to optimized, That was my guess but I think it'd be worth it to get a handle on what sorts of things are likely to trigger off exponential time compiles when fed to IMCC. I'm assuming that it's due to a combination of sub size (about 61K of source in one sub) and locals needing coloring (132) but it'd be nice to know for sure. My experience was as follows (don't take these times too literally since this is a very old, very slow box; the relative times are what count). This was creating a single .sub: compile source and write a 2,500 line imc file: 0.2 seconds The first line of the imc file included a hand-crafted 1000 line file. parrot -o t.pasm t.imc: 7 seconds load the final pasm file (now 3,500 lines) and run it: 0.3 seconds Editing the hand-crafted 1000-line include file to replace symbolic registers (ie $I1 etc) with real registers (I1) cut imc time down to 3.5 seconds. Changing the code emitter to re-use symbolic registers no longer in use (ie not local variables, and not still on the parse stack) cut the time down to 1.39 seconds. Just letting you know what I found, I shall let you draw your own conclusions. Lastly, while I know that -O2 is not complete, I don't know by how much it is incomplete. You may want to check the times on that too. Regards, Pete
Re: [PATCH] The Return of the Priority DOD
Jeff Clites writes:
On Jan 5, 2004, at 5:47 AM, Luke Palmer wrote:
After many months of lying dormant, I figured I'd get my act together
and adapt this patch to the few recent modifications. And this time,
I'm posting a benchmark!
My results get about 5% slowdown in the eager case, and the usual
10,000% speedup in the lazy case.
Sounds cool; do you have a quick high-level description of what it's
all about? (I had seen that needs_early_DOD flag in the source, and
didn't know what it was intended to do.)
Thanks!
Okay, here I go, just before I get some sleep and then wake up to tie up
the rather insidious bugs in the patch.
We have a problem with several common constructs that Perl will likely
require of us. For instance, this one:
{
my $fh = open ' foo';
print $fh: Hello!\n;
}
{
my $fh = open ' foo';
print $fh;
}
In Perl 5, this prints Hello! without the blink of an eye (well, if it
were valid Perl 5 syntax ;-). But now on Parrot with a opportunistic
DOD, this guarantee doesn't hold. If $fh isn't closed before it's
opened, the results here are undefined.
Performing a full sweep at every scope exit is not practical: there's
enough sub-call overhead as it is. So a new variant of Csweep was
added: Csweep 0 would only sweep if there were no PMCs that had been
marked as neededing early (or impatient for) DOD.
I and several others quickly saw this as a makeshift solution. There
will commonly be at least one such object that will last the entire
lifetime of a program. So Csweep 0, in practice, was exactly
equivalent to Csweep 1.
Enter the scheme that this patch implements. It was batted around and
refined several times before I implemented it a few months ago. Here's
how it goes:
The common case is that none of the impatient objects go out of program
view, and moreover that the various paths to find them remain the same.
The algorithm takes heavy advantage of this, keeping state across
multiple DOD runs.
Each PMC has associated with it a high priority flag. First, only the
impatient objects have this flag set. But on each DOD run, it's
possible to efficiently tell all objects that hold a reference to this
high priority object. Those objects also get their high priority flag
set. And so on down the chain.
Then during the DOD main loop, if such a high priority object comes
along, it is prepended to the queue, temporarily switching the DOD to
depth first. This allows it to quickly navigate its way to the
impatient objects, and once they are all found, the lazy DOD is
terminated. And the more the lazy DOD is run, the faster it becomes.
When one of the impatient objects can't be found, the run is equivalent
to a Csweep 1, but that happens rarely. Also in this case, all high
priority flags are cleared, so that a wide-spreading circular data
structure doesn't end up making Ieverything high priority, thereby
nullifying the algorithm. This is one of those things I forgot to
implement ;-)
Hope this clarified things.
Luke
JEff
Re: Generating optimized PIR?
At 10:59 AM 1/5/2004 -0500, Dan Sugalski wrote: Optimized for speed, at least. I'm finding that large subs seem to give imcc headaches. I'm not sure if it's O(n^2) or O(2^n) headaches, but definitely issues. At the moment I've got parrot churning on some pir code and it's taking quite a while. Final time tally: real41m46.978s user21m24.300s sys 0m41.080s Ack. I expected this would happen. Most probably it is register-coloring/spilling. I'm a little rusty on the register colorer; I do know the first version I wrote was not very fast for large numbers of registers, but I believe Leo had improved on it a bit. I'd really like to see the piece of code so I can do some profiling. Ended with a missing symbol error, of course, just to rub it in a bit. vm_stat reports a lot of zero-fill page allocation (about 1600 4K pages/sec) though the memory footprint isn't growing to match, so that might indicate at least something of the problem. (For all I know there's some sort of degenerate GC issue somewhere, depending on how imcc does its memory allocation and management) That could be IMCC repeatedly allocating/freeing its interference graphs for each basic block, but I'm not positive. I know IMCC's being redone, and we're nowhere near close to optimized, but I think it'd be worth it to get a handle on what sorts of things are likely to trigger off exponential time compiles when fed to IMCC. I'm assuming that it's due to a combination of sub size (about 61K of source in one sub) and locals needing coloring (132) but it'd be nice to know for sure. There are several tests I can think of that we should include in IMCC. 1) A large number of locals with a very long code segment, without branches or labels. This would tests large graph coloring without lots of basic blocks. 2) A large number of locals _with_ the normal amount of branches and labels. This would test the life analysis on a large number of basic blocks. 3) A small number of locals with variants of 1 2 above for branching/labels. Any chance of getting the code sample? -Melvin
Re: Roles and Mix-ins?
On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote: On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote: : For one, one role's methods don't silently override another's. Instead, : you get, er, role conflict and you have to disambiguate yourself. How do you disambiguate? : For : two, you can attach new roles to an object at runtime (I don't know if : you can do this with mixins, actually). Yes, you can. The mixin creates a new singleton class every time you do it, derived from the previous class. My current thinking is that run-time roles work a little differently. You get a singleton class for the object the first time you apply a property, so that each object's properties remain distinct. However, subsequent properties re-use the existing singleton class, and do the same role-conflict checks at run time that does would do in the class definition at compile time. Furthermore, the singleton class is not really derived from the original class, but just presents a different view of the same class, so that, from the viewpoint of the object, every role has the same standing, and run-time roles aren't privileged above compile-time roles, as they would be if the singleton class were really derived from the original class. In a sense, the object thinks it's recomposing the original class, but it's slightly wrong. After reading this several times, I _think_ I understand. Let me check: imagine that the original class is a text buffer going from 0-99. We have two roles (A and B), each of length 100. Objects of various types can then see different segments of the buffer (i.e., different methods/properties/whatever), as follows: TypeCan see --- Class 1-100 A 101-199 B 200-299 Class+A 1-100,101-199 Class+B 1-100,200-299 Class+A+B 1-100,101-199,200-299 Is that right? Dave
Re: This week's summary
On 1/5/04 1:55 PM, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? I'm not not licking toads... (Hey, the list needs traffic ;) -John
Re: This week's summary
* Lars Balker Rasmussen [EMAIL PROTECTED] [2004-01-05 20:42]: I'm confused, are you optimistic or pessimistic in that last sentence? Sounds carefully optimistic to me. At least it certainly doesn't sound pessimistic per se, no? -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Roles and Mix-ins?
David Storrs wrote: On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote: On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote: : For one, one role's methods don't silently override another's. : Instead, you get, er, role conflict and you have to disambiguate : yourself. How do you disambiguate? For most cases, you either alias or exclude one or the other of the offending methods from the final class, rendering the ambiguity moot. However, role conflict not disambiguiated in either of the above manners throws an exception (presumably with a list of the ambiguous methods), letting you write code to disambiguate in whatever manner you like on a case-by-case basis. The only question I have about such an exception is what sort of information your ambiguity handler code receives. = Jonathan Dataweaver Lang __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Re: This week's summary
chromatic [EMAIL PROTECTED] writes: On Mon, 2004-01-05 at 10:55, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Mostly just British. There's no 'just' about it. Bloody colonials. That sentence did rather get away from me didn't it? s/wouldn't/would/ for the right sense.
RE: This week's summary
The Perl 6 Summarizer [EMAIL PROTECTED] writes: I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. Obviously you've been reading the proposed EU constitution. But DAMN, did you help write it, too? =Austin PS: While I'm somewhat sympathetic to the fact that eu guys are trying to spin up 200 years worth of amendments and supreme court decisions at the same time, it's still a ratf*ck. Eu need to get eurselves a Larry. I wonder if there's a precedent for that?
Yet another DOD bug
Looks like we've a bug in the DOD tracing. As far as I can tell (and it's somewhat tough, as my program's rather large) there's a bug where metadata on loadlib-loaded libraries doesn't get properly marked as live. The symptoms are straightforward -- the getprop call inside dynext.c during library loading fails with a get_pmc_keyed() not implemented in class NCI message. Littering the source with debugging messages, the property PMC on the entries in the library hash changes type. Throwing a sweepoff/sweepon pair around the library loading code makes the problem go away, so it seems like the PMC is getting collected and reused. I don't have a test case at the moment, though I'll try and work one up. (I'm running on 2 hours sleep and far too much caffeine, so I'm not at my best. Sorry) I don't know if this affects all property hashes, or only those on loaded libraries. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Crash when joining multiple threads
Jeff Clites [EMAIL PROTECTED] wrote: On Jan 5, 2004, at 5:32 AM, Leopold Toetsch wrote: The return value is only returned, when I3 != 0. For your example that shouldn't be the case (I3 is unused aka zero). So there isn't any return value passed back. Yep, the second time through I find REG_INT(3) (that is, interpreter-int_reg.registers[3]) set to 1 in thread_func(). Wherever that comes from, just insert a line set I3, 0 before you invoke the return continutation. That's the official way, to inidicate a void return value. leo
[perl #24819] [PATCH] Linkage problem
# New Ticket Created by Adam Thomason # Please include the string: [perl #24819] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24819 A pedantic fix courtesy of VisualAge: src/events.c attempts to call peek_entry(), which is defined in src/tsq.c. Currently, peek_entry is declared and defined as PARROT_INLINE, which expands to __inline under xlc. This in turn implies internal linkage for peek_entry (at least it does here), resulting in events.c: Static function peek_entry is undefined. IRC consensus was that PARROT_INLINE was not required on peek_entry, so attached patch removes it from header and implementation (tested on AIX and Linux). -- Adam Thomason [EMAIL PROTECTED] pedantic.patch Description: Binary data
[perl #24817] [PATCH] various extending interface changes
# New Ticket Created by Mattia Barbon # Please include the string: [perl #24817] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24817 Hello, this patch * renames Parrot_INTERP and Parrot_STRING to Parrot_Interp and Parrot_String, which matches the rest of Parrot types, as well as the embedding interface * Adds Parrot_PMC_get/set_vtable * makes the extending interface compilable with a C++ compiler (removed typedef struct Parrot_Interp* Parrot_Interp) (note: only *compiles*, it probably does not link yet) * changes typedefs in extend.h from typedef void* type to typedef struct type_* type which allows for slightly better type safety Regards Mattia Index: include/parrot/dynext.h === RCS file: /cvs/public/parrot/include/parrot/dynext.h,v retrieving revision 1.4 diff -u -2 -r1.4 dynext.h --- include/parrot/dynext.h 30 Sep 2003 09:29:41 - 1.4 +++ include/parrot/dynext.h 5 Jan 2004 20:52:34 - @@ -11,5 +11,5 @@ /* dynamic lib/oplib/PMC loading */ -PMC *Parrot_load_lib(Interp *interpreter, STRING *lib, PMC *initializer); +Parrot_PMC Parrot_load_lib(Parrot_Interp interpreter, Parrot_String lib, Parrot_PMC initializer); #endif Index: include/parrot/extend.h === RCS file: /cvs/public/parrot/include/parrot/extend.h,v retrieving revision 1.12 diff -u -2 -r1.12 extend.h --- include/parrot/extend.h 31 Dec 2003 11:54:32 - 1.12 +++ include/parrot/extend.h 5 Jan 2004 20:52:35 - @@ -16,4 +16,6 @@ #define PARROT_EXTEND_H_GUARD +#include stddef.h /* size_t */ + #include parrot/config.h /* PARROT_VERSION, PARROT_JIT_CAPABLE... */ #include parrot/interpreter.h /* give us the interpreter flags */ @@ -24,67 +26,67 @@ we'll split this into two pieces and not install the core version, but that would be really annoying */ -#if defined(PARROT_IN_CORE) +#if !defined(PARROT_IN_CORE) -#define Parrot_INTERP struct Parrot_Interp * -#define Parrot_STRING STRING * -#define Parrot_PMC PMC * -#define Parrot_Language Parrot_Int - -#else - -typedef void * Parrot_INTERP; -typedef void * Parrot_STRING; -typedef void * Parrot_PMC; +typedef struct Parrot_String_* Parrot_String; +typedef struct Parrot_PMC_* Parrot_PMC; typedef Parrot_Int Parrot_Language; -typedef void * Parrot_Encoding; -typedef void * Parrot_CharType; -typedef const void * Parrot_Const_Encoding; -typedef const void * Parrot_Const_CharType; +typedef struct Parrot_Encoding_* Parrot_Encoding; +typedef struct Parrot_Chartype_* Parrot_CharType; +typedef const struct Parrot_Encoding_* Parrot_Const_Encoding; +typedef const struct Parrot_Chartype_* Parrot_Const_CharType; +typedef struct _vtable* Parrot_Vtable; +/* XXX for vtables */ +typedef void BIGNUM; +typedef void visit_info; #endif -Parrot_STRING Parrot_PMC_get_string(Parrot_INTERP, Parrot_PMC); -void *Parrot_PMC_get_pointer(Parrot_INTERP, Parrot_PMC); -Parrot_Int Parrot_PMC_get_intval(Parrot_INTERP, Parrot_PMC); -Parrot_Int Parrot_PMC_get_intval_intkey(Parrot_INTERP, Parrot_PMC, Parrot_Int); -Parrot_Float Parrot_PMC_get_numval(Parrot_INTERP, Parrot_PMC); -char *Parrot_PMC_get_cstring(Parrot_INTERP, Parrot_PMC); -char *Parrot_PMC_get_cstringn(Parrot_INTERP, Parrot_PMC, Parrot_Int *); - -void Parrot_PMC_set_string(Parrot_INTERP, Parrot_PMC, Parrot_STRING); -void Parrot_PMC_set_pointer(Parrot_INTERP, Parrot_PMC, void *); -void Parrot_PMC_set_cstring(Parrot_INTERP, Parrot_PMC, const char *); -void Parrot_PMC_set_cstringn(Parrot_INTERP, Parrot_PMC, const char *, Parrot_Int); -void Parrot_PMC_set_intval(Parrot_INTERP, Parrot_PMC, Parrot_Int); -void Parrot_PMC_set_intval_intkey(Parrot_INTERP, Parrot_PMC, Parrot_Int, Parrot_Int); -void Parrot_PMC_set_numval(Parrot_INTERP, Parrot_PMC, Parrot_Float); +#include parrot/vtable.h /* Parrot_Vtable */ + +Parrot_String Parrot_PMC_get_string(Parrot_Interp, Parrot_PMC); +void *Parrot_PMC_get_pointer(Parrot_Interp, Parrot_PMC); +Parrot_Int Parrot_PMC_get_intval(Parrot_Interp, Parrot_PMC); +Parrot_Int Parrot_PMC_get_intval_intkey(Parrot_Interp, Parrot_PMC, Parrot_Int); +Parrot_Float Parrot_PMC_get_numval(Parrot_Interp, Parrot_PMC); +char *Parrot_PMC_get_cstring(Parrot_Interp, Parrot_PMC); +char *Parrot_PMC_get_cstringn(Parrot_Interp, Parrot_PMC, Parrot_Int *); +Parrot_Vtable Parrot_PMC_get_vtable(Parrot_Interp, Parrot_PMC); + +void Parrot_PMC_set_string(Parrot_Interp, Parrot_PMC, Parrot_String); +void Parrot_PMC_set_pointer(Parrot_Interp, Parrot_PMC, void *); +void Parrot_PMC_set_cstring(Parrot_Interp, Parrot_PMC, const char *); +void Parrot_PMC_set_cstringn(Parrot_Interp, Parrot_PMC, const char *, Parrot_Int); +void Parrot_PMC_set_intval(Parrot_Interp, Parrot_PMC, Parrot_Int); +void Parrot_PMC_set_intval_intkey(Parrot_Interp, Parrot_PMC, Parrot_Int, Parrot_Int); +void
RE: This week's summary
-Original Message- From: Uri Guttman [mailto:[EMAIL PROTECTED] AH == Austin Hastings [EMAIL PROTECTED] writes: AH PS: While I'm somewhat sympathetic to the fact that eu guys are AH trying to spin up 200 years worth of amendments and supreme court AH decisions at the same time, it's still a ratf*ck. Eu need to get AH eurselves a Larry. I wonder if there's a precedent for that? but he if worked on that at the rate he is churning out apocalypses, it would be another 200 years. this is not a knock on larry but a comment on how large and complex that eu constitution probably is. Au contraire. His job would not be to write, per se, but to eliminate. Consider all the RFC's and then consider the synthesis he did to produce, e.g., Grammars. Or the new block constructs (loop, etc.). Occam is dead. Larry's still got a very sharp razor. i say we just sell them a license to use the US constitution. say a royalty on EU coinage? When you consider some of the issues, it's sort of obvious that they're trying *real* hard not to say, Look the Americans solved this problem already. Honestly, voting weights? What a pack of maroons. You're right about the IP licensing. Bill Gates is probably frothing at the mouth for not having a Constitution Template in the Euroversion of MS Word. =Austin
Reminder: The EU constitution's off-topic
And should stay off-list, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: This week's summary
According to Austin Hastings: When you consider some of the issues, it's sort of obvious that they're trying *real* hard not to say, Look the Americans solved this problem already. Three words: Second System Effect. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early. // MST3K
Re: This week's summary
AH == Austin Hastings [EMAIL PROTECTED] writes: reminds me of the great line: in EU they consider a 100 miles a long distance, in the US we consider 100 years a long time. :) AH That's very good. I'm going to recycle it. Do you know the author? dunno. i have heard it from several sources and i toss it out at the proper moments. most people get it too. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
This week's summary
The Perl 6 Summary for the week ending 20040104 What a surprise, a scant week after the last Perl 6 Summary of 2003, it's the first Perl 6 Summary of 2004. Will wonders never cease? Without further ado, we'll start with perl6-internals as usual. Garbage Collection Tasks Dan noted that a copying garbage collector doesn't play that well with threads so he proposed a twofold task to fix things. 1 The GC and memory allocation APIs need to be formalized and abstracted in order to allow for changing the GC mechanism when threads come into play. 2 Someone needs to implement a more traditional, non-moving GC as an alternative to the copying collector. Plugging Parrot into Mozilla Stephane Peiry posted a set of patches to allow a parrot plugin for Mozilla. Not satisfied with this (but pretty darned impressed all the same) Sam Vilain noted that it would be nice if someone wrote an ECMAscript front-end to Parrot. Patches welcome Sam. http://tinyurl.com/2lgy8 Problems with make test Harry Jackson couldn't get his build of parrot to finish running make test. After a certain amount of thrashing about by the team, Dan narrowed it down to issues with the mutant '2.96' version of GCC that some versions of Red Hat used for a while. This is currently the list's best guess as to the root of the problem, but it's not absolutely certain. If it does turn out to be the compiler, the config suite will have to be rejigged to detect and warn. http://tinyurl.com/2lzsb Threading threads They're everywhere! And I despair of summarizing them. So I won't. Here's the root messages for anyone interested enough. Once things have died down and we know how threading is going to work in Parrot I'll summarize that. Dan opened the floodgates and asked anyone who was serious about their particular Right Way To Do Threading to write things up as a proper proposal. He outlined the constraints that Parrot's threading will be working under and encouraged everyone to speak now or forever hold their peace. http://tinyurl.com/3359s http://tinyurl.com/2e94j http://tinyurl.com/ytyb6 -- Dan says put up or shut up http://tinyurl.com/2p777 http://tinyurl.com/2akpn http://tinyurl.com/36qlo http://tinyurl.com/23byv http://tinyurl.com/2hugf -- Dan offers up common terminology Don't use IMCC macros Bernhard Schmalhofer found what looked like a bug in IMCC's macro support. This prompted Melvin Smith to expedite the removal of IMCC macro support as threatened some weeks ago. However, it turned out that that wasn't actually the seat of the bug. But if you like IMCC macros now is the time to make a *very* good case to Melvin, I doubt you'll convince him though; macros belong in a preprocessor. http://tinyurl.com/3e3cg wxWindows support? David Cuny wondered if Parrot's objects were not at the point where it's possible to interface wxWindows to Parrot. So far he's been Warnocked. Just try implementing it David. http://tinyurl.com/yr758 Win32 Core Dumps Dan's a fan of core dumps (when appropriate) and wondered if there was a way of getting windows to either produce a core dump or attach a debugger to a crashed process. Vladimir Lipsky and Nigel Sandever gave good answers. http://tinyurl.com/2ndy9 The Piemark is ready Dan forwarded the announcement that the Pie-thon Parrot Benchmark (which I've unilaterally decided to call the Piemark) code is ready. Let's make sure it's Guido not Dan who gets Pie eyed in Portland this year. http://tinyurl.com/28qjp ftp://ftp.python.org/pub/python/parrotbench/parrotbench.tgz Object System? Luke Palmer wondered what work was needed to finish up Parrot's object system. Judging by Leo's response there are name mangling issues that need deciding on, and we're not quite sure who's supposed to be making the decision. Dan? http://tinyurl.com/34wfq Enhancements for the debugger Whilst wearing his employee implementing a large project targetting Parrot hat, Dan has been using IMCC's debugging facilities. This led to a bunch of suggestions/decisions about how these could be improved. http://tinyurl.com/2g3ah NCI callback functions Leo isn't enamoured of the current PDD16 design of callbacks in NCI, so he proposed a new design. Dan seemed to think that this proposal smacked of getting a little to sophisticated to early, arguing that the best thing to do was to flesh out what's there (and get it working) before using it as a base on which to build. This means that, once his work deadline is out of the way, we should be expecting some better examples in PDD16. And we'll be reminding Dan of this in a couple of weeks' time. http://tinyurl.com/3c96z Meanwhile in
Re: This week's summary
At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) -Melvin
Re: This week's summary
Lars Balker Rasmussen [EMAIL PROTECTED] writes: The Perl 6 Summarizer [EMAIL PROTECTED] writes: Me? I think Perl 6's design 'in the large' will be pretty much done once Apocalypse 12 and its corresponding Exegesis are finished. Of course, the devil is in the details, but I don't doubt that the hoped for existence of a working Perl6::Rules by the end of April is going to provide us with a great deal of the leverage we need to get a working Perl 6 alpha ready for OSCON with something rather more solid ready by the end of the year. Parrot continues to amaze and delight with its progress; Dan tells me that he's about ready to roll out a large parrot based application for his employers, so it's approaching the point where people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Optimistic. Parrot being used for other languages too is a good thing. We're not going to see a full Perl 6 inside a year 'cos the design won't be finished (well, not at the detailed level it needs to be for a full implementation) and Ponie probably won't be finished because of the complexities of getting the backwards compatilibility with XS that's Ponie's raison d'etre. But there are other languages out there that don't have such stringent requirements. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Melvin Smith [EMAIL PROTECTED] writes: At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
At 09:30 PM 1/5/2004 +, Piers Cawley wrote: Melvin Smith [EMAIL PROTECTED] writes: At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. Unless you count our chats on IRC, no. I can deduce that much from IRC and summaries. We do read them, you know. :) -Melvin
Re: This week's summary
The Perl 6 Summarizer wrote: Problems with make test Harry Jackson couldn't get his build of parrot to finish running make test. After a certain amount of thrashing about by the team, Dan narrowed it down to issues with the mutant '2.96' version of GCC that some versions of Red Hat used for a while. This is currently the list's best guess as to the root of the problem, but it's not absolutely certain. If it does turn out to be the compiler, the config suite will have to be rejigged to detect and warn. I got fed up beating around the bush so I took some drastic action. I installed apt-get for redhat and did a massive upgrade and that sorted out the parrot problems but introduced several others that I wont go into (not parrot related). Now knowing I have not got dodgy hardware I decided to bite the bullet and install Debain, I have been missing apt-get for some time now. I now have debain running and am just about to test parrot and try and get postgres and a few other things back to normal. Don't use IMCC macros Bernhard Schmalhofer found what looked like a bug in IMCC's macro support. This prompted Melvin Smith to expedite the removal of IMCC macro support as threatened some weeks ago. However, it turned out that that wasn't actually the seat of the bug. But if you like IMCC macros now is the time to make a *very* good case to Melvin, I doubt you'll convince him though; macros belong in a preprocessor. http://tinyurl.com/3e3cg I was unaware of this. I must have missed a thread somewhere. I have been using macros quite a bit in the postgres lib but I am pretty sure if my parrot will start to squak properly I can do without them, if it dosn't I'll ring its neck. I was using macros for all the global function calls. I originally tried to get them all into an array/hash but was having some fun doing this (I am pretty sure this is nothing to do with imcc, rather my dodgy parrot ;-) The Piemark is ready Dan forwarded the announcement that the Pie-thon Parrot Benchmark (which I've unilaterally decided to call the Piemark) code is ready. Let's make sure it's Guido not Dan who gets Pie eyed in Portland this year. I really need to read more of the archives to find out what the crack is here. 1 Dan will win his bet with Guido, and that the Python.Net people will be so embarrassed by the piemark that they won't publish numbers. I am not 100% sure what this involves yet but its a bet and in a manner of speaking I'm gunning for the parrot. Harry
Re: This week's summary
On Mon, Jan 05, 2004 at 05:48:04PM -0500, Austin Hastings wrote: From: Uri Guttman [mailto:[EMAIL PROTECTED] AH == Austin Hastings [EMAIL PROTECTED] writes: AH PS: While I'm somewhat sympathetic to the fact that eu guys are AH trying to spin up 200 years worth of amendments and supreme court AH decisions at the same time, it's still a ratf*ck. Eu need to get AH eurselves a Larry. I wonder if there's a precedent for that? but he if worked on that at the rate he is churning out apocalypses, it would be another 200 years. this is not a knock on larry but a comment on how large and complex that eu constitution probably is. Au contraire. His job would not be to write, per se, but to eliminate. Consider all the RFC's and then consider the synthesis he did to produce, e.g., Grammars. Or the new block constructs (loop, etc.). Occam is dead. Larry's still got a very sharp razor. The RFC's were generated in just a few months and the elimination and synthesis has taken quite a bit longer.
