[PATCH] Re: [CVS ci] indirect register frame 9 - go
On Thu, Oct 28, 2004 at 10:06:05AM +0200, Leopold Toetsch wrote:
* all JIT platforms except ppc and i386 are broken
Takers wanted for JIT fixes. See jit/ppc/* for necessary changes.
This patch fixes JIT for the sparc platform (make testj passes
except for the streams and gc_10.pasm where it hangs - where
apparently ppc has the issues).
leo
Thanks,
Stéphane
Index: jit/sun4/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/sun4/jit_emit.h,v
retrieving revision 1.30
diff -u -r1.30 jit_emit.h
--- jit/sun4/jit_emit.h 10 Oct 2004 17:27:45 - 1.30
+++ jit/sun4/jit_emit.h 28 Oct 2004 21:24:47 -
@@ -355,7 +355,7 @@
/* This register can be used only in jit_emit.h calculations */
#define XSR1 emitm_l(0)
-#define Parrot_jit_regbase_ptr(i) ((i)-int_reg.registers[0])
+#define Parrot_jit_regbase_ptr(interpreter) REG_INT(0)
/* The offset of a Parrot register from the base register */
#define Parrot_jit_regoff(a, i) (unsigned)(a) - (unsigned)(Parrot_jit_regbase_ptr(i))
@@ -469,25 +469,25 @@
break;
case PARROT_ARG_I:
-val = (int)interpreter-int_reg.registers[val];
+val = (int)REG_INT(val);
emitm_ld_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
case PARROT_ARG_P:
-val = (int)interpreter-pmc_reg.registers[val];
+val = (int)REG_PMC(val);
emitm_ld_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
case PARROT_ARG_S:
-val = (int)interpreter-string_reg.registers[val];
+val = (int)REG_STR(val);
emitm_ld_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
case PARROT_ARG_N:
-val = (int)interpreter-num_reg.registers[val];
+val = (int)REG_NUM(val);
emitm_ldd_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
@@ -512,25 +512,25 @@
switch(op_type){
case PARROT_ARG_I:
-val = (int)interpreter-int_reg.registers[val];
+val = (int)REG_INT(val);
emitm_st_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
case PARROT_ARG_P:
-val = (int)interpreter-pmc_reg.registers[val];
+val = (int)REG_PMC(val);
emitm_st_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
case PARROT_ARG_S:
-val = (int)interpreter-string_reg.registers[val];
+val = (int)REG_STR(val);
emitm_st_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
case PARROT_ARG_N:
-val = (int)interpreter-num_reg.registers[val];
+val = (int)REG_NUM(val);
emitm_std_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
@@ -572,13 +572,13 @@
break;
case PARROT_ARG_I:
-val = (int)interpreter-int_reg.registers[val];
+val = (int)REG_INT(val);
emitm_ldf_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
case PARROT_ARG_N:
-val = (int)interpreter-num_reg.registers[val];
+val = (int)REG_NUM(val);
emitm_lddf_i(jit_info-native_ptr, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter), hwreg);
break;
@@ -602,13 +602,13 @@
switch(op_type){
case PARROT_ARG_I:
-val = (int)interpreter-int_reg.registers[val];
+val = (int)REG_INT(val);
emitm_stf_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
case PARROT_ARG_N:
-val = (int)interpreter-num_reg.registers[val];
+val = (int)REG_NUM(val);
emitm_stdf_i(jit_info-native_ptr, hwreg, Parrot_jit_regbase,
Parrot_jit_regoff(val, interpreter));
break;
@@ -664,23 +664,27 @@
* i1 is reusable once past the jump. interpreter is preserved in i0
*/
int ireg0_offset;
+int ireg0_address;
/* Standard Prolog */
emitm_save_i(jit_info-native_ptr, emitm_SP, -104, emitm_SP);
/* Calculate the offset of I0 in the interpreter struct */
-ireg0_offset =
Re: [perl #31725] [PATCH] non-branching compare opcodes - tests
This patch adds tests for iscompare style ops (isgt, isge, isle, islt,
iseq, isne) on integers, numbers and strings, in t/op/comp.t.
Thanks,
Stéphane
PS.: maybe t/op/*.t could be reorganized so that test filenames match
what is under ops/*.ops? and t/op would test only I, N, and S stuff,
leaving any P (pmc) tests to t/pmc.
On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote:
I've moved these opcodes to ops.num and added some missing variants.
These opcodes need tests.
Index: t/op/comp.t
===
RCS file: /cvs/public/parrot/t/op/comp.t,v
retrieving revision 1.7
diff -u -r1.7 comp.t
--- t/op/comp.t 1 Oct 2004 21:16:49 - 1.7
+++ t/op/comp.t 2 Oct 2004 10:50:50 -
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 8;
+use Parrot::Test tests = 80;
# some of these were failing with JIT/i386
@@ -195,6 +195,1120 @@
ok
OUTPUT
-1;
+output_is('CODE', OUTPUT, isgt_i_i_i);
+set I1, 111
+set I2, 222
+set I3, 333
+isgt I1, I2, I3
+print I1
+set I2, I3
+isgt I1, I2, I3
+print I1
+inc I2
+isgt I1, I2, I3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_ic_i);
+set I1, 111
+set I3, 333
+isgt I1, 222, I3
+print I1
+isgt I1, 333, I3
+print I1
+isgt I1, 334, I3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_i_ic);
+set I1, 111
+set I2, 222
+isgt I1, I2, 223
+print I1
+isgt I1, I2, 222
+print I1
+isgt I1, I2, 221
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_ic_ic);
+set I1, 111
+isgt I1, 222, 223
+print I1
+isgt I1, 222, 222
+print I1
+isgt I1, 222, 221
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_n_n);
+set I1, 111
+set N2, 2.22
+set N3, 3.33
+isgt I1, N2, N3
+print I1
+set N2, N3
+isgt I1, N2, N3
+print I1
+inc N2
+isgt I1, N2, N3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_nc_n);
+set I1, 111
+set N3, 3.33
+isgt I1, 2.22, N3
+print I1
+isgt I1, 3.33, N3
+print I1
+isgt I1, 3.34, N3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_n_nc);
+set I1, 111
+set N2, 2.22
+isgt I1, N2, 2.23
+print I1
+isgt I1, N2, 2.22
+print I1
+isgt I1, N2, 2.21
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_nc_nc);
+set I1, 111
+isgt I1, 2.22, 2.23
+print I1
+isgt I1, 2.22, 2.22
+print I1
+isgt I1, 2.22, 2.21
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_s_s);
+set I1, 111
+set S2, Aaa
+set S3, Bbb
+isgt I1, S2, S3
+print I1
+set S2, S3
+isgt I1, S2, S3
+print I1
+set S2, Ccc
+isgt I1, S2, S3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_sc_s);
+set I1, 111
+set S3, Bbb
+isgt I1, Aaa, S3
+print I1
+isgt I1, Bbb, S3
+print I1
+isgt I1, Ccc, S3
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_s_sc);
+set I1, 111
+set S2, Bbb
+isgt I1, S2, Ccc
+print I1
+isgt I1, S2, Bbb
+print I1
+isgt I1, S2, Aaa
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isgt_i_sc_sc);
+set I1, 111
+isgt I1, Bbb, Ccc
+print I1
+isgt I1, Bbb, Bbb
+print I1
+isgt I1, Bbb, Aaa
+print I1
+print \n
+end
+CODE
+001
+OUTPUT
+
+output_is('CODE', OUTPUT, isge_i_i_i);
+set I1, 111
+set I2, 222
+set I3, 333
+isge I1, I2, I3
+print I1
+set I2, I3
+isge I1, I2, I3
+print I1
+inc I2
+isge I1, I2, I3
+print I1
+print \n
+end
+CODE
+011
+OUTPUT
+
+output_is('CODE', OUTPUT, isge_i_ic_i);
+set I1, 111
+set I3, 333
+isge I1, 222, I3
+print I1
+isge I1, 333, I3
+print I1
+isge I1, 334, I3
+print I1
+print \n
+end
+CODE
+011
+OUTPUT
+
+output_is('CODE', OUTPUT, isge_i_i_ic);
+set I1, 111
+set I2, 222
+isge I1, I2, 223
+print I1
+isge
Re: [perl #31726] [PATCH] non-branching compare opcodes - JIT
These two patches add jit support for iscompare style ops (isgt, isge, isle,
islt, iseq, isne) on integers for the sun/sparc platform.
The jitted code follows this pattern:
cmp %r2, %r3
bc,a next
mov 1, %r1
mov 0, %r1
next: ..
c defining the branch condition.
Thanks,
Stéphane
On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote:
The integer and number variants of these opcodes could need JIT support.
Index: jit/sun4/core.jit
===
RCS file: /cvs/public/parrot/jit/sun4/core.jit,v
retrieving revision 1.7
diff -u -r1.7 core.jit
--- jit/sun4/core.jit 25 Sep 2004 14:44:22 - 1.7
+++ jit/sun4/core.jit 2 Oct 2004 10:53:54 -
@@ -197,11 +197,11 @@
jit_emit_store_i(jit_info, interpreter, 1, arg1);
}
}
-
+
Parrot_inc_i {
Parrot_incdec_i s/op/add/
}
-
+
Parrot_dec_i {
Parrot_incdec_i s/op/sub/
}
@@ -701,6 +701,132 @@
Parrot_cmp_ix_ix_ic s/a/bge/
}
+TEMPLATE Parrot_iscmp_ix_ix_ix {
+if(MAP[2] MAP[3]){
+emitm_subcc_r(NATIVECODE, MAP[2], MAP[3], emitm_g(0));
+}
+else if (MAP[2]) {
+jit_emit_load_i(jit_info, interpreter, 3, ISR2);
+emitm_subcc_r(NATIVECODE, MAP[2], ISR2, emitm_g(0));
+}
+else if (MAP[3]) {
+jit_emit_load_i(jit_info, interpreter, 2, ISR1);
+emitm_subcc_r(NATIVECODE, ISR1, MAP[3], emitm_g(0));
+}
+else {
+jit_emit_load_i(jit_info, interpreter, 2, ISR1);
+jit_emit_load_i(jit_info, interpreter, 3, ISR2);
+emitm_subcc_r(NATIVECODE, ISR1, ISR2, emitm_g(0));
+}
+
+emitm_bicc(NATIVECODE, 1, emitm_a, 3);
+
+if(MAP[1]){
+emitm_mov_i(NATIVECODE, 1, MAP[1]);
+emitm_or_r(NATIVECODE, emitm_g(0), emitm_g(0), MAP[1]);
+} else {
+emitm_bicc(NATIVECODE, 1, emitm_a, 3);
+jit_emit_store_i(jit_info, interpreter, 1, 1);
+jit_emit_store_i(jit_info, interpreter, 1, 0);
+}
+}
+
+Parrot_isgt_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isge_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isle_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_islt_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_iseq_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_isne_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
/*
* Local variables:
* c-indentation-style: bsd
Index: jit/sun4/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/sun4/jit_emit.h,v
retrieving revision 1.28
diff -u -r1.28 jit_emit.h
--- jit/sun4/jit_emit.h 25 Sep 2004 14:44:22 - 1.28
+++ jit/sun4/jit_emit.h 2 Oct 2004 10:54:20 -
@@ -77,7 +77,7 @@
emitm_rs1(rs1) | (low14); \
pc +=4 ; }
-/* format 3b */
+/* format 3a */
#define emitm_3a(pc, op, rd, op3, rs1, asi, rs2) \
emitm_fmt3(pc, op, rd, op3, rs1, ((asi) 5) | (rs2))
@@ -107,7 +107,8 @@
#define emitm_restore_i(pc, rs1, i, rd) emitm_3b(pc, 2, rd, 075, rs1, i)
/* MOV */
-#define emitm_mov(pc, rs, rd) emitm_or_r(pc, emitm_g(0), rs, rd)
+#define emitm_mov_r(pc, rs, rd) emitm_or_r(pc, emitm_g(0), rs, rd)
+#define emitm_mov_i(pc, i, rd) emitm_or_i(pc, emitm_g(0), i, rd)
/* Integer Register Loads */
@@ -283,7 +284,7 @@
/* Branch */
#define emitm_bicc(pc, a, cond, disp22) emitm_2b(pc, a, cond, 02, disp22)
-#define jit_emit_mov_rr_i(pc, dst, src) emitm_mov(pc, src, dst)
+#define jit_emit_mov_rr_i(pc, dst, src) emitm_mov_r(pc, src, dst)
#define jit_emit_mov_rr_n(pc, dst, src) { \
Re: [perl #31726] [PATCH] non-branching compare opcodes - JIT
Sorry the previous core.jit patch for sun contained a typo. The correct
patch file is attached here again.
Thanks!
Stephane
On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote:
The integer and number variants of these opcodes could need JIT support.
Index: jit/sun4/core.jit
===
RCS file: /cvs/public/parrot/jit/sun4/core.jit,v
retrieving revision 1.7
diff -u -r1.7 core.jit
--- jit/sun4/core.jit 25 Sep 2004 14:44:22 - 1.7
+++ jit/sun4/core.jit 2 Oct 2004 11:50:59 -
@@ -197,11 +197,11 @@
jit_emit_store_i(jit_info, interpreter, 1, arg1);
}
}
-
+
Parrot_inc_i {
Parrot_incdec_i s/op/add/
}
-
+
Parrot_dec_i {
Parrot_incdec_i s/op/sub/
}
@@ -701,6 +701,131 @@
Parrot_cmp_ix_ix_ic s/a/bge/
}
+TEMPLATE Parrot_iscmp_ix_ix_ix {
+if(MAP[2] MAP[3]){
+emitm_subcc_r(NATIVECODE, MAP[2], MAP[3], emitm_g(0));
+}
+else if (MAP[2]) {
+jit_emit_load_i(jit_info, interpreter, 3, ISR2);
+emitm_subcc_r(NATIVECODE, MAP[2], ISR2, emitm_g(0));
+}
+else if (MAP[3]) {
+jit_emit_load_i(jit_info, interpreter, 2, ISR1);
+emitm_subcc_r(NATIVECODE, ISR1, MAP[3], emitm_g(0));
+}
+else {
+jit_emit_load_i(jit_info, interpreter, 2, ISR1);
+jit_emit_load_i(jit_info, interpreter, 3, ISR2);
+emitm_subcc_r(NATIVECODE, ISR1, ISR2, emitm_g(0));
+}
+
+emitm_bicc(NATIVECODE, 1, emitm_a, 3);
+
+if(MAP[1]){
+emitm_mov_i(NATIVECODE, 1, MAP[1]);
+emitm_or_r(NATIVECODE, emitm_g(0), emitm_g(0), MAP[1]);
+} else {
+jit_emit_store_i(jit_info, interpreter, 1, 1);
+jit_emit_store_i(jit_info, interpreter, 1, 0);
+}
+}
+
+Parrot_isgt_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isgt_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bg/
+}
+
+Parrot_isge_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isge_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bge/
+}
+
+Parrot_isle_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_isle_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/ble/
+}
+
+Parrot_islt_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_islt_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bl/
+}
+
+Parrot_iseq_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_iseq_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/be/
+}
+
+Parrot_isne_i_i_i {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_ic_i {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_i_ic {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
+Parrot_isne_i_ic_ic {
+Parrot_iscmp_ix_ix_ix s/a/bne/
+}
+
/*
* Local variables:
* c-indentation-style: bsd
Re: NCI and callback functions
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote: Whatever you'll try the current scheme is not compatible with this GTK callback. Parrot needs a PMC as user_data. GTK awaits a GObject. Yes. But draining the event queue still needs a running Parrot runloop. This made me remember that Ive tried sometime ago another of those gtk callback installer function that is g_signal_connect_data (wich is what the #defined g_signal_connect uses actually. That didn't broke, or even freeze the app, or else.. but it was say actually working.. o well.. Mainly Ive traced it to be sure and indeed, parrot is properly called each time the button pressed. Just that, as you say, parrot piles it up in its event queue.. and never takes it, since its busy doing gtk_main. Well at least I know for sure how the whole callback scheme works now in parrot and can go try this: Otherwise, already thaught of actually unrolling the gtk_main function and have it handled/implemented within parrot directly (mainly gtk_main simply loops and waits on the gtk event queue). That's the way to go. ! :) Thanks, Stephane # -- Gtk Button Example. .sub _gtkcallback print Hello\n .end .sub _main @MAIN .include glib.pasm .include gtk.pasm .local pmc window .local pmc button .local pmc callback .local pmc userdata .local NCI init init = global Gtk::gtk_init init(0) # -- create the window .local NCI w_new w_new = global Gtk::gtk_window_new window = w_new(0) # -- create the button .local NCI b_new b_new = global Gtk::gtk_button_new_with_label button = b_new(Parrot) # -- install callback? .local pmc cb_sub cb_sub = global _gtkcallback userdata = new Integer userdata = 42 callback = new_callback cb_sub, userdata, pU # -- function sig is 'lptppi', then we have: #P5 is the button #P6 the callback #P7 data we may to pass through. #S5 clicked #I5 is 0 # -- Uncomment this section to actually install the callback # -- (this segfaulst on my system) .local NCI sig_conn sig_conn = global Glib::g_signal_connect_data sig_conn(button, clicked, callback, userdata, 0, 0) # -- Set the container. .local NCI cont_add cont_add = global Gtk::gtk_container_add cont_add(window, button) # -- show button .local NCI w_show w_show = global Gtk::gtk_widget_show w_show(button) # -- show window w_show(window) .local NCI g_main g_main = global Gtk::gtk_main g_main() end .end saveall loadlib P1, 'libgtk-x11-2.0' dlfunc P2, P1, 'gtk_init', 'vii' store_global 'Gtk::gtk_init', P2 dlfunc P2, P1, 'gtk_main', 'vv' store_global 'Gtk::gtk_main', P2 dlfunc P2, P1, 'gtk_widget_show', 'vp' store_global 'Gtk::gtk_widget_show', P2 dlfunc P2, P1, 'gtk_container_add', 'vpp' store_global 'Gtk::gtk_container_add', P2 dlfunc P2, P1, 'gtk_button_new_with_label', 'pt' store_global 'Gtk::gtk_button_new_with_label', P2 dlfunc P2, P1, 'gtk_window_new', 'pi' store_global 'Gtk::gtk_window_new', P2 restoreall saveall loadlib P1, 'libgobject-2.0' dlfunc P2, P1, 'g_signal_connect_data', 'lptpPii' store_global 'Glib::g_signal_connect_data', P2 restoreall
Re: NCI and callback functions
On Mon, Aug 23, 2004 at 12:14:51PM +0200, Leopold Toetsch wrote: Leopold Toetsch wrote: Stephane Peiry wrote: g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here gtk shouldn't make assumption on the user_data argument IMHO. [...] call is NULL, because of the same check, G_IS_OBJECT(gobject). mh.. ok, this whole thing made me try the following, and that is actually sticking to what I do really understand about nci and function signatures for parrot. Currently the signature is 'lptpPi' dlfunc P2, P1, 'g_signal_connect_object', 'lptpPi' and Ive placed P in there for the user data mainly because of the example taken from the t/pmc/nct.t tests and I thaught that well.. that would do the right thing :) Now I would have otherwise written the function sig as 'lptppi' dlfunc P2, P1, 'g_signal_connect_object', 'lptppi' as thats what gtk really wants, a pointer to the user data, and for sure p will give it exactly that. Doing so, gtk doesnt complain anymore, it goes onto creating the window, the button, installing the callback (by calling this g_signal..) without problems and shows the window and button. So now gtk is happy but parrot isnt: if I hit the button, it goes onto calling callback in parrot, and he breaks with: Parrot VM: PANIC: callback_info doesn't look like a pointer! C file src/inter_cb.c, line 132 (as I understand it, by having p on the signature for the user data, gtk gets what it wants, a pointer to the user data, but parrot doesnt like it because once it gets it, it doesnt get it wrapped into a PMC? otoh, if P is used then its gtk not happy because it wants a pointer rather than a - pmc - struct?.. how wrong is this view?) *If* that is solved then the next problem is of course that by calling gtk_main() the GTK event loop is running. That means, while Parrot_callback_C() would get called, the callback fuction itself wouldn't get run because Parrot isn't executing any code at that point. Parrot is stuck in the NCI call to gtk_main(). mh.. thats was not the way I understood callbacks were implemented. I mean understood from this thread (*): [1] pdd16 states: Hand over control to the external library. IT IS IMPORTANT THAT THE INTERPRETER YOU ARE CALLING BACK INTO IS NOT ACTIVE WHEN THE CALLBACK IS MADE! As we don't know, when the callback is invoked, my scheme uses an event so that its safe to run the PASM code. that callbacks were indeed installed through an event (that is on its own thread) so that it wouldnt block nomatter what parrot would be doing at a given point (say it invoked some long running function in a lib :) unless there would be a lock on the user data itself. Otherwise, already thaught of actually unrolling the gtk_main function and have it handled/implemented within parrot directly (mainly gtk_main simply loops and waits on the gtk event queue). Or maybe run it in its own thread if the event threads are not enought? Thanks, Stephane (*) Subject: [CVS ci] approaching pdd16 callbacks http://groups.google.com/groups?q=callback+group:perl.perl6.internalshl=enlr=ie=UTF-8group=perl.perl6.internalsselm=4024E112.5030809%40toetsch.atrnum=3 PS.: attached the same test files, just using the new signature. # -- Gtk Button Example. .sub _gtkcallback print Hello\n .end .sub _main @MAIN .include glib.pasm .include gtk.pasm .local pmc window .local pmc button .local pmc callback .local pmc userdata .local NCI init init = global Gtk::gtk_init init(0) # -- create the window .local NCI w_new w_new = global Gtk::gtk_window_new window = w_new(0) # -- create the button .local NCI b_new b_new = global Gtk::gtk_button_new_with_label button = b_new(Parrot) # -- install callback? .local pmc cb_sub cb_sub = global _gtkcallback userdata = new Integer userdata = 42 callback = new_callback cb_sub, userdata, pU # -- function sig is 'lptppi', then we have: #P5 is the button #P6 the callback #P7 data we may to pass through. #S5 clicked #I5 is 0 # -- Uncomment this section to actually install the callback # -- (this segfaulst on my system) .local NCI sig_conn sig_conn = global Glib::g_signal_connect_object sig_conn(button, clicked, callback, userdata, 0) # -- Set the container. .local NCI cont_add cont_add = global Gtk::gtk_container_add cont_add(window, button) # -- show button .local NCI w_show w_show = global Gtk::gtk_widget_show w_show(button) # -- show window w_show(window) .local NCI g_main g_main = global Gtk::gtk_main g_main() end .end saveall loadlib P1, 'libgtk-x11-2.0' dlfunc P2, P1, 'gtk_init', 'vii' store_global 'Gtk::gtk_init', P2 dlfunc P2, P1, 'gtk_main', 'vv' store_global 'Gtk::gtk_main', P2 dlfunc P2, P1, 'gtk_widget_show', 'vp' store_global 'Gtk::gtk_widget_show', P2 dlfunc P2, P1, 'gtk_container_add', 'vpp' store_global 'Gtk::gtk_container_add', P2 dlfunc P2, P1
Re: NCI and callback functions
mh.. guess P is an actuall pointer to PMC, in that case forget that part.. :) Stephane On Mon, Aug 23, 2004 at 11:15:03PM +0200, Stephane Peiry wrote: [signatures question gone] *If* that is solved then the next problem is of course that by calling gtk_main() the GTK event loop is running. That means, while Parrot_callback_C() would get called, the callback fuction itself wouldn't get run because Parrot isn't executing any code at that point. Parrot is stuck in the NCI call to gtk_main(). mh.. thats was not the way I understood callbacks were implemented. I mean understood from this thread (*): [1] pdd16 states: Hand over control to the external library. IT IS IMPORTANT THAT THE INTERPRETER YOU ARE CALLING BACK INTO IS NOT ACTIVE WHEN THE CALLBACK IS MADE! As we don't know, when the callback is invoked, my scheme uses an event so that its safe to run the PASM code. that callbacks were indeed installed through an event (that is on its own thread) so that it wouldnt block nomatter what parrot would be doing at a given point (say it invoked some long running function in a lib :) unless there would be a lock on the user data itself. Otherwise, already thaught of actually unrolling the gtk_main function and have it handled/implemented within parrot directly (mainly gtk_main simply loops and waits on the gtk event queue). Or maybe run it in its own thread if the event threads are not enought? Thanks, Stephane
Re: NCI and callback functions
On Thu, Aug 19, 2004 at 01:21:33PM +0200, Leopold Toetsch wrote:
[ segfaulting example ]
g_signal_connect_object (G_OBJECT (button), clicked,
G_CALLBACK (hello), NULL, 0);
Are you sure, that these two G_foo() aren't doing something with the
function arguments?
These are just typecasts/checks actually, so you can remove them and it
will still work (youll receive a warning though when compiling it but
otherwise it will work without problems - have tried it).
I've beautified the example a bit, segfaults much nicer now ;)
Cool, thanks for that :), Ill go through the sdl examples as
well to get on more pir.
Dunno, what's wrong.
Just built a debugable version of gtk, so as to see whats going on
when it enters this function. Mainly its button param, as well as
its user_data are not set (or at least ddd doesnt know how to give
me any info about it), but it breaks because of its user data..
g_signal_connect_object (gpointer instance,
const gchar *detailed_signal,
GCallback c_handler,
gpointer gobject,
GConnectFlags connect_flags)
{
g_return_val_if_fail (G_TYPE_CHECK_INSTANCE (instance), 0);
g_return_val_if_fail (detailed_signal != NULL, 0);
g_return_val_if_fail (c_handler != NULL, 0);
if (gobject)
{
GClosure *closure;
g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
anyway I just dont see what could be wrong with the way parrot could be
passing the user_data?
Whats the difference between the way parrot calls this, and the way
the C example is doing it? As the parrot example follows exactly the
same steps as the C one.
What ddd can tell me is:
[instance] ? disableb
[detailed_signal] = clicked
[c_handler]= Parrot_callback_C
[gobject] ? disabled
[connect_flags]= 0
leo
Thanks,
Stephane
gobject.c.gz
Description: GNU Zip compressed data
Re: NCI and callback functions
On Wed, Aug 18, 2004 at 09:11:17AM +0200, Leopold Toetsch wrote:
You've mixed up the function parameters.
P0 = global Gtk::gtk_window_new
null I5
invoke
P15 = P5
I presume that's instance ...
actually shouldnt the callback is for the button
# -- function sig is 'lptpPi', then we have:
#P5 is the button
#P6 the callback
#P7 data we may to pass through.
#S5 clicked
#I5 is 0
... and the button is the gobject. I did:
set P6, P5# the callback
set P5, P15 # instance
set S5, clicked
set P7, P11 # button = object
And got a clickable button labeled Parrot.
do you mean the callback worked? as I dont get it to on my system
(ie if I activate the callback the it seg faults).
You might start using PIR code and named variables so that it gets
simpler to call such functions.
Ok I have changed this a bit and should be more readable.
Mainly attached is the C version of this small example, and the parrot
version is just about a conversion to it line be line.
(its simply a slightly modified of the Gtk tutorial hello world,
where instead of using the #defined g_signal_connect it uses the
g_signal_connect_object function)
Unless Im overlooking something the parrot version mimics exactly
whats the C version does. Just still cant get it to work out the
callback.
leo
Thanks always,
Stephane
/*
* Compile this with:
*
* gcc hello.c -o hello `pkg-config --cflags --libs gtk+-2.0`
*/
#include gtk/gtk.h
static void hello( GtkWidget *widget,
gpointer data )
{
g_print (Hello\n);
}
int main( int argc,
char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
button = gtk_button_new_with_label (Parrot);
g_signal_connect_object (G_OBJECT (button), clicked,
G_CALLBACK (hello), NULL, 0);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
# -- Gtk Button Example.
.sub _gtkcallback
print Hello\n
.end
.sub _main @MAIN
.include gtk.pasm
.local pmc window
.local pmc button
.local pmc callback
.local pmc userdata
P0 = global Gtk::gtk_init
I5 = 0
invoke
# -- create the window
P0 = global Gtk::gtk_window_new
null I5
invoke
window = P5
# -- create the button
P0 = global Gtk::gtk_button_new_with_label
S5 = Parrot
invoke
button = P5
# -- install callback?
newsub P6, .Sub, _gtkcallback
new P7, .Integer # -- just give it something even if dont care
set P7, 42
userdata = P7
new_callback P5, P6, P7, Ut
callback = P5
# -- function sig is 'lptpPi', then we have:
#P5 is the button
#P6 the callback
#P7 data we may to pass through.
#S5 clicked
#I5 is 0
# -- Uncomment this section to actually install the callback
# -- (this segfaulst on my system)
# P0 = global Gtk::g_signal_connect_object
# P5 = button
# S5 = clicked
# P6 = callback
# P7 = userdata
# I5 = 0
# invoke
# -- .
# -- Set the container.
P5 = window
P6 = button
P0 = global Gtk::gtk_container_add
invoke
# -- show button
P5 = button
P0 = global Gtk::gtk_widget_show
invoke
# -- show window
P5 = window
P0 = global Gtk::gtk_widget_show
invoke
P0 = global Gtk::gtk_main
invoke
end
.end
saveall
loadlib P1, 'libgtk-x11-2.0'
dlfunc P2, P1, 'gtk_init', 'vii'
store_global 'Gtk::gtk_init', P2
dlfunc P2, P1, 'gtk_main', 'vv'
store_global 'Gtk::gtk_main', P2
dlfunc P2, P1, 'gtk_widget_show', 'vp'
store_global 'Gtk::gtk_widget_show', P2
dlfunc P2, P1, 'gtk_container_add', 'vpp'
store_global 'Gtk::gtk_container_add', P2
dlfunc P2, P1, 'gtk_button_new_with_label', 'pt'
store_global 'Gtk::gtk_button_new_with_label', P2
dlfunc P2, P1, 'gtk_window_new', 'pi'
store_global 'Gtk::gtk_window_new', P2
dlfunc P2, P1, 'g_signal_connect_object', 'lptpPi'
store_global 'Gtk::g_signal_connect_object', P2
restoreall
Re: NCI and callback functions
On Tue, Aug 17, 2004 at 09:01:39AM +0200, Leopold Toetsch wrote: It returns a PerlUndef. 60 dlfunc P2, P1, g_signal_connect, lptpP - \ P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), , 65 store_global Gtk::g_signal_connec, P2 - , \ P2=PerlUndef=PMC(0x8363fb8 Num:0 Int:0) ^ The symbol g_signal_connect isn't found in that lib. ow.. ok, this one is actaully a macro.. the actual function is gulong g_signal_connect_object (gpointer instance, const gchar *detailed_signal, GCallback c_handler, gpointer gobject, GConnectFlags connect_flags); so I've changed this and now it does find it. And it does seem to callback as well, but there must something else wrong (or I'm missing something) as it dies anyway. Attached are again the test files, plus two dumps of my tries to run it. In one of them (run.null) I simply null the user data to be passed through. In that case it displays the button but dies as soon as it is clicked on (in this case it dies because the user data is null actually, but at least it let me now it does actually callback :) Parrot_callback_D then verify_CD). On other one (run), there is an actual (not null) user data. Know it goes somewhere into the g_signal function and (guess) also someway back.. but I'm really blind as to what is really happening there..? leo Thanks Stephane 8 saveall 9 loadlib P1, libgtk-x11-2.0 - P1=NULL, 12 dlfunc P2, P1, gtk_init, vii - P2=NULL, P1=ParrotLibrary=PMC(0x8364108), , 17 store_global Gtk::gtk_init, P2 - , P2=NCI=PMC(0x8364048) 20 dlfunc P2, P1, gtk_main, vv - P2=NCI=PMC(0x8364048), P1=ParrotLibrary=PMC(0x8364108), , GC 25 store_global Gtk::gtk_main, P2 - , P2=NCI=PMC(0x8364030) 28 dlfunc P2, P1, gtk_widget_show, vp - P2=NCI=PMC(0x8364030), P1=ParrotLibrary=PMC(0x8364108), , 33 store_global Gtk::gtk_widget_show, P2 - , P2=NCI=PMC(0x8364018) 36 dlfunc P2, P1, gtk_container_add, vpp- P2=NCI=PMC(0x8364018), P1=ParrotLibrary=PMC(0x8364108), , 41 store_global Gtk::gtk_container_a, P2 - , P2=NCI=PMC(0x8364000) GC 44 dlfunc P2, P1, gtk_button_new_with_, pt - P2=NCI=PMC(0x8364000), P1=ParrotLibrary=PMC(0x8364108), , 49 store_global Gtk::gtk_button_new_, P2 - , P2=NCI=PMC(0x8363fe8) 52 dlfunc P2, P1, gtk_window_new, pi- P2=NCI=PMC(0x8363fe8), P1=ParrotLibrary=PMC(0x8364108), , 57 store_global Gtk::gtk_window_new, P2 - , P2=NCI=PMC(0x8363fd0) GC 60 dlfunc P2, P1, g_signal_connect_obj, lptpPi - P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), , 65 store_global Gtk::g_signal_connec, P2 - , P2=NCI=PMC(0x8363fb8) 68 restoreall 69 find_global P0, Gtk::gtk_init - P0=NULL, 72 set I5, 0- I5=0, 75 invoke 76 find_global P0, Gtk::gtk_window_new- P0=NCI=PMC(0x8364048), GC 79 null I5 - I5=0 81 invoke 82 set P15, P5 - P15=NULL, P5=UnManagedStruct=PMC(0x8363fa0) 85 find_global P0, Gtk::gtk_button_new_ - P0=NCI=PMC(0x8363fd0), 88 set S5, Parrot - , 91 invoke 92 set P6, P5 - P6=NULL, P5=UnManagedStruct=PMC(0x8363f88) GC 95 set P11, P5 - P11=NULL, P5=UnManagedStruct=PMC(0x8363f88) 98 newsub P6, 22, -98 - P6=UnManagedStruct=PMC(0x8363f88), , 102 new P7, 31 - P7=NULL, 105 set P7, 42 - P7=Integer=PMC(0x8363f58), 108 new_callback P5, P6, P7, Ut- P5=UnManagedStruct=PMC(0x8363f88), P6=Sub=PMC(0x8363f70 Adr:0x84e6628), P7=Integer=PMC(0x8363f58), GC 113 find_global P0, Gtk::g_signal_connec - P0=NCI=PMC(0x8363fe8), 116 set S5, clicked- S5=Parrot, 119 set I5, 0- I5=0, 122 set P6, P5 - P6=Sub=PMC(0x8363f70 Adr:0x84e6628), P5=UnManagedStruct=PMC(0x8363ef8) 125 set P5, P11 - P5=UnManagedStruct=PMC(0x8363ef8), P11=UnManagedStruct=PMC(0x8363f88) GC 128 invoke Segmentation fault 8 saveall 9 loadlib P1, libgtk-x11-2.0 - P1=NULL, 12 dlfunc P2, P1, gtk_init, vii - P2=NULL, P1=ParrotLibrary=PMC(0x8364108), , 17 store_global Gtk::gtk_init, P2 - , P2=NCI=PMC(0x8364048) 20 dlfunc P2, P1, gtk_main, vv - P2=NCI=PMC(0x8364048), P1=ParrotLibrary=PMC(0x8364108), , GC 25 store_global Gtk::gtk_main, P2 - , P2=NCI=PMC(0x8364030) 28 dlfunc P2, P1, gtk_widget_show, vp - P2=NCI=PMC(0x8364030), P1=ParrotLibrary=PMC(0x8364108), , 33 store_global Gtk::gtk_widget_show, P2 - , P2=NCI=PMC(0x8364018) 36 dlfunc P2, P1, gtk_container_add, vpp- P2=NCI=PMC(0x8364018), P1=ParrotLibrary=PMC(0x8364108), , 41 store_global Gtk::gtk_container_a, P2 - ,
Re: NCI and callback functions
On Mon, Aug 16, 2004 at 10:20:46AM +0200, Leopold Toetsch wrote: gtk-signal-connect or g-signal-connect isn't found here. I can't check the symbols of the lib, this dam** OS has symbols stripped. The other box has only gtk-1.2. actually it should run as well against gtk-1.2 if g_signal_connect is renamed gtk_signal_connect. Attached here are the files with that small change, but I've never been able to run any parrot code against gtk v1.2 as parrot dies complaining: /usr/lib/libgtk.so: undefined symbol: gdk_root_window actually its simply dlopen dumping this. (btw there parrot displays a misleading .. No such file or dir.. caused by the way loadlib lookups for the lib, note for a patch if I find a nice way to clean it :) It returns a PerlUndef. Run it with -t. Attached is the trace output. leo Thanks, Stephane # -- Gtk Button Example. .sub _gtkcallback print Hello\n .end .sub main @MAIN .include gtk.pasm P0 = global Gtk::gtk_init I5 = 0 invoke P0 = global Gtk::gtk_window_new null I5 invoke P15 = P5 P0 = global Gtk::gtk_button_new_with_label S5 = Parrot invoke # -- Save it. P6 = P5 P11 = P5 # -- install callback? newsub P6, .Sub, _gtkcallback new P7, .Integer # -- just give it something even if dont care set P7, 42 new_callback P5, P6, P7, U P0 = global Gtk::gtk_signal_connect S5 = clicked P6 = P5 P5 = P11 invoke # -- . P5 = P11 P6 = P11 P0 = global Gtk::gtk_widget_show invoke # -- Set the container. P5 = P15 P0 = global Gtk::gtk_container_add invoke P0 = global Gtk::gtk_widget_show invoke P0 = global Gtk::gtk_main invoke end .end saveall loadlib P1, 'libgtk' dlfunc P2, P1, 'gtk_init', 'vii' store_global 'Gtk::gtk_init', P2 dlfunc P2, P1, 'gtk_main', 'vv' store_global 'Gtk::gtk_main', P2 dlfunc P2, P1, 'gtk_widget_show', 'vp' store_global 'Gtk::gtk_widget_show', P2 dlfunc P2, P1, 'gtk_container_add', 'vpp' store_global 'Gtk::gtk_container_add', P2 dlfunc P2, P1, 'gtk_button_new_with_label', 'pt' store_global 'Gtk::gtk_button_new_with_label', P2 dlfunc P2, P1, 'gtk_window_new', 'pi' store_global 'Gtk::gtk_window_new', P2 dlfunc P2, P1, 'gtk_signal_connect', 'lptpP' store_global 'Gtk::gtk_signal_connect', P2 restoreall $ ./parrot -t gtk.toplevel.button.imc 8 saveall 9 loadlib P1, libgtk-x11-2.0 - P1=NULL, 12 dlfunc P2, P1, gtk_init, vii - P2=NULL, P1=ParrotLibrary=PMC(0x8364108), , 17 store_global Gtk::gtk_init, P2 - , P2=NCI=PMC(0x8364048) 20 dlfunc P2, P1, gtk_main, vv - P2=NCI=PMC(0x8364048), P1=ParrotLibrary=PMC(0x8364108), , GC 25 store_global Gtk::gtk_main, P2 - , P2=NCI=PMC(0x8364030) 28 dlfunc P2, P1, gtk_widget_show, vp - P2=NCI=PMC(0x8364030), P1=ParrotLibrary=PMC(0x8364108), , 33 store_global Gtk::gtk_widget_show, P2 - , P2=NCI=PMC(0x8364018) 36 dlfunc P2, P1, gtk_container_add, vpp- P2=NCI=PMC(0x8364018), P1=ParrotLibrary=PMC(0x8364108), , 41 store_global Gtk::gtk_container_a, P2 - , P2=NCI=PMC(0x8364000) GC 44 dlfunc P2, P1, gtk_button_new_with_, pt - P2=NCI=PMC(0x8364000), P1=ParrotLibrary=PMC(0x8364108), , 49 store_global Gtk::gtk_button_new_, P2 - , P2=NCI=PMC(0x8363fe8) 52 dlfunc P2, P1, gtk_window_new, pi- P2=NCI=PMC(0x8363fe8), P1=ParrotLibrary=PMC(0x8364108), , 57 store_global Gtk::gtk_window_new, P2 - , P2=NCI=PMC(0x8363fd0) GC 60 dlfunc P2, P1, g_signal_connect, lptpP - P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), , 65 store_global Gtk::g_signal_connec, P2 - , P2=PerlUndef=PMC(0x8363fb8 Num:0 Int:0) 68 restoreall 69 find_global P0, Gtk::gtk_init - P0=NULL, 72 set I5, 0- I5=0, 75 invoke 76 find_global P0, Gtk::gtk_window_new- P0=NCI=PMC(0x8364048), GC 79 null I5 - I5=0 81 invoke 82 set P15, P5 - P15=NULL, P5=UnManagedStruct=PMC(0x8363fa0) 85 find_global P0, Gtk::gtk_button_new_ - P0=NCI=PMC(0x8363fd0), 88 set S5, Parrot - , 91 invoke 92 set P6, P5 - P6=NULL, P5=UnManagedStruct=PMC(0x8363f88) GC 95 set P11, P5 - P11=NULL, P5=UnManagedStruct=PMC(0x8363f88) 98 newsub P6, 22, -98 - P6=UnManagedStruct=PMC(0x8363f88), , 102 new P7, 31 - P7=NULL, 105 set P7, 42 - P7=Integer=PMC(0x8363f58), 108 new_callback P5, P6, P7, U - P5=UnManagedStruct=PMC(0x8363f88), P6=Sub=PMC(0x8363f70 Adr:0x84e6548), P7=Integer=PMC(0x8363f58), GC 113 find_global P0, Gtk::g_signal_connec - P0=NCI=PMC(0x8363fe8), 116 set S5, clicked- S5=Parrot, 119 set P5, P11 - P5=UnManagedStruct=PMC(0x8363ef8), P11=UnManagedStruct=PMC(0x8363f88) 122 invoke get_string() not implemented in class 'UnManagedStruct'\n
NCI and callback functions
Hi All, Ive been trying to get the (NCI) callbacks working with GTK but somehow cant. Mainly the attached file implements a (very) small test app where it simply displays a button within a window. The problem is that as soon as it goes onto installing the callback parrot returns with a get_string() not implemented in class 'UnManagedStruct'. So what is happening there? Either the small test program attached is correct and therefore only need to implement that get_string for the UnManagedStruct PMC.. or theres something wrong with the code? Somehow I believe that the message (get_string not implemeted) is somewhat missleading? mean at least I dont understand why it enters this get_string function, as it dumps this message nomatther what signature I could make parrot beleive the callback function has. Also when trying to trace this with gdb, get_string gets called from a PerlInt PMC, even thaught I'm not using any PerlInt PMC. In GTK (using version 2) the calling function is: gulong g_signal_connect( gpointer *object, const gchar *name, GCallback func, gpointer func_data ); and the called: void callback_func( GtkWidget *widget, gpointer callback_data ); Any hints/help greatly appreciated :) Thanks, Stephane PS.: the attached file load libgtk-x11-2.0 as this the GTK version 2 lib name on my RedHat.. please change that to libgtk or whatever GTKv2 libname on your system is to try it out. # -- Gtk Button Example. .sub _gtkcallback print Hello\n .end .sub main @MAIN .include gtk.pasm P0 = global Gtk::gtk_init I5 = 0 invoke P0 = global Gtk::gtk_window_new null I5 invoke P15 = P5 P0 = global Gtk::gtk_button_new_with_label S5 = Parrot invoke # -- Save it. P6 = P5 P11 = P5 # -- install callback? newsub P6, .Sub, _gtkcallback new P7, .Integer # -- just give it something even if dont care set P7, 42 new_callback P5, P6, P7, U P0 = global Gtk::g_signal_connect S5 = clicked P6 = P7 P5 = P11 invoke # -- . P5 = P11 P6 = P11 P0 = global Gtk::gtk_widget_show invoke # -- Set the container. P5 = P15 P0 = global Gtk::gtk_container_add invoke P0 = global Gtk::gtk_widget_show invoke P0 = global Gtk::gtk_main invoke end .end saveall loadlib P1, 'libgtk-x11-2.0' dlfunc P2, P1, 'gtk_init', 'vii' store_global 'Gtk::gtk_init', P2 dlfunc P2, P1, 'gtk_main', 'vv' store_global 'Gtk::gtk_main', P2 dlfunc P2, P1, 'gtk_widget_show', 'vp' store_global 'Gtk::gtk_widget_show', P2 dlfunc P2, P1, 'gtk_container_add', 'vpp' store_global 'Gtk::gtk_container_add', P2 dlfunc P2, P1, 'gtk_button_new_with_label', 'pt' store_global 'Gtk::gtk_button_new_with_label', P2 dlfunc P2, P1, 'gtk_window_new', 'pi' store_global 'Gtk::gtk_window_new', P2 dlfunc P2, P1, 'g_signal_connect', 'lptpP' store_global 'Gtk::g_signal_connect', P2 restoreall Summary of my parrot 0.1.0 configuration: configdate='Fri Aug 13 22:56:58 2004' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lpthread -lcrypt -lutil -lrt -lgmp' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib -fPIC', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8
Re: [perl #27246] [PATCH] Correct ommision inconfig/gen/makefiles /befun ge.in
Done thanks,
Stéphane
On Mon, Mar 01, 2004 at 11:48:08AM -0500, Gay, Jerry wrote:
if this is accepted, please close [perl #27083], as it addresses this bug,
but i haven't yet seen it posted to the list.
--jerry
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 2:20 AM
To: [EMAIL PROTECTED]
Subject: [perl #27246] [PATCH] Correct ommision
inconfig/gen/makefiles/befun ge.in
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27246]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27246
There was no
PERL = ${perl}
definition in this file (which does exist in jako.in and
others), hence when the
clean target was called, the RM_F expansion omitted the
perl resulting in
nmake befunge clean
and all the dependancies
nmake languages-clean
nmake clean
nmake realclean
failing with invalid command or filename.
Lokking around, I think that BF.in is similarly wrong, but I
am not currently
building that, and could be mistaken .
**
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.
Re: More closeable tickets in RT
On Fri, Feb 27, 2004 at 03:40:20PM -0500, Simon Glover wrote: 20707 -- fixed (and also irrelevant now we no longer use assemble.pl) 21665 -- fixed 21759 -- patch accepted and applied 22321 -- patch accepted and applied ok these are now closed (resolved). 26898, 26904, 26927, 26939, 26941, 26945, 26953, 26956, 26964, 26976, 27097, 27098, 27143, 27150 -- spam already reported these and they are to be cleaned out soon ;) (there have been a few spam slippages lately) Thanks! Stéphane
Re: JIT branches under the Sun
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote: Yep. That's a bit complicated. The jit code tries to avoid loading/storing the same register from/to memory. Actually on this, while looking at what jit on i386 would give for this particular loop, just noticed it does quite a lot of these store/loads to memory who are, afaik, useless? (althaugh as I understand they are needed for the general case) 0x0829c5ed jit_func+53: mov$0x2,%ebx 0x0829c5f2 jit_func+58: mov%esi,%esi 0x0829c5f4 jit_func+60: mov%ebx,0x8278c74 0x0829c5fa jit_func+66: mov0x8278c74,%ebx 0x0829c600 jit_func+72: sub$0x1,%ebx 0x0829c606 jit_func+78: test %ebx,%ebx 0x0829c608 jit_func+80: jne0x829c600 jit_func+72 (up here we could just skeep 58 to 66) jit/i386/jit_emit.h implements all the necessary bits. s. jit_emit_jcc, fixup-skip and load_size. Thanks.. was going round in loops ;) I'll go on it as time permits. leo Stéphane
Re: JIT branches under the Sun
On Mon, Feb 16, 2004 at 09:08:55AM +0100, Leopold Toetsch wrote: I see. Your libc's sprintf seems to be missing the 0x prefix for the %p format. Ok you were right, that fixed it immediatly, and I'm now able to see within jit :). Attached are the dumps for this loop, with and without the print in between. Looking at it makes it pretty clear why it loops forever (mainly it jumps back to a load, loading always the same value). Somehow it relates to the way these jit sections are built afaik, but still do have to dig more and understand better its works. (if there are any hints/pointers, they are greatly appreciated ;) Thanks again for the help, Stephane PS.: apoligize for the delay in answering back. Also concerning fixing the debug part, I kind of prefer your second option (using Parrot_sprintf) since as I understand it its meant to avoid platform specific quirks? 0x00266570 jit_func+0:save %sp, -104, %sp 0x00266574 jit_func+4:add %i0, 0, %i2 0x00266578 jit_func+8:sethi %hi(0x266400), %i3 0x0026657c jit_func+12: or %i3, 0x130, %i3 ! 0x266530 0x00266580 jit_func+16: sethi %hi(0xfee7), %l0 0x00266584 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00266588 jit_func+24: sub %i1, %l0, %l0 0x0026658c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00266590 jit_func+32: jmpl %l0, %l0 0x00266594 jit_func+36: nop 0x00266598 jit_func+40: mov 2, %l1 ! 0x2 0x0026659c jit_func+44: st %l1, [ %i2 + 4 ] 0x002665a0 jit_func+48: ld [ %i2 + 4 ], %l1 0x002665a4 jit_func+52: dec %l1 0x002665a8 jit_func+56: nop 0x002665ac jit_func+60: cmp %l1, 0 0x002665b0 jit_func+64: nop 0x002665b4 jit_func+68: bne,a 0x2665a0 jit_func+48 0x002665b8 jit_func+72: nop 0x002665bc jit_func+76: st %l1, [ %i2 + 4 ] 0x002665c0 jit_func+80: sethi %hi(0xfee7), %o0 0x002665c4 jit_func+84: or %o0, 0xc4, %o0 ! 0xfee700c4 0x002665c8 jit_func+88: call 0x8a43c Parrot_print_sc 0x002665cc jit_func+92: mov %i0, %o1 0x002665d0 jit_func+96: ret 0x002665d4 jit_func+100: restore # -- pasm used: set I1, 2 LOOP: sub I1, 1 ifI1, LOOP print end\n end 0x00266f10 jit_func+0:save %sp, -104, %sp 0x00266f14 jit_func+4:add %i0, 0, %i2 0x00266f18 jit_func+8:sethi %hi(0x266c00), %i3 0x00266f1c jit_func+12: or %i3, 0x2c8, %i3 ! 0x266ec8 0x00266f20 jit_func+16: sethi %hi(0xfee7), %l0 0x00266f24 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00266f28 jit_func+24: sub %i1, %l0, %l0 0x00266f2c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00266f30 jit_func+32: jmpl %l0, %l0 0x00266f34 jit_func+36: nop 0x00266f38 jit_func+40: mov 2, %l1 ! 0x2 0x00266f3c jit_func+44: st %l1, [ %i2 + 4 ] 0x00266f40 jit_func+48: ld [ %i2 + 4 ], %l1 0x00266f44 jit_func+52: dec %l1 0x00266f48 jit_func+56: st %l1, [ %i2 + 4 ] 0x00266f4c jit_func+60: sethi %hi(0xfee7), %o0 0x00266f50 jit_func+64: or %o0, 0xb8, %o0 ! 0xfee700b8 0x00266f54 jit_func+68: call 0x8a254 Parrot_print_i 0x00266f58 jit_func+72: mov %i0, %o1 0x00266f5c jit_func+76: ld [ %i2 + 4 ], %l1 0x00266f60 jit_func+80: nop 0x00266f64 jit_func+84: cmp %l1, 0 0x00266f68 jit_func+88: nop 0x00266f6c jit_func+92: bne,a 0x266f40 jit_func+48 0x00266f70 jit_func+96: nop 0x00266f74 jit_func+100: sethi %hi(0xfee7), %o0 0x00266f78 jit_func+104: or %o0, 0xcc, %o0 ! 0xfee700cc 0x00266f7c jit_func+108: call 0x8a43c Parrot_print_sc 0x00266f80 jit_func+112: mov %i0, %o1 0x00266f84 jit_func+116: ret 0x00266f88 jit_func+120: restore # -- pasm used: set I1, 2 LOOP: sub I1, 1 print I1 ifI1, LOOP print end\n end 0x00263660 jit_func+0:save %sp, -104, %sp 0x00263664 jit_func+4:add %i0, 0, %i2 0x00263668 jit_func+8:sethi %hi(0x243c00), %i3 0x0026366c jit_func+12: or %i3, 0x2c8, %i3 ! 0x243ec8 0x00263670 jit_func+16: sethi %hi(0xfee7), %l0 0x00263674 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00263678 jit_func+24: sub %i1, %l0, %l0 0x0026367c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00263680 jit_func+32: jmpl %l0, %l0 0x00263684 jit_func+36: nop 0x00263688 jit_func+40: mov 0x14d, %l1 ! 0x14d 0x0026368c jit_func+44: st %l1, [ %i2 + 4 ] 0x00263690 jit_func+48: ret 0x00263694 jit_func+52: restore 0x00263698 jit_func+56: st %l1, [ %i2 + 4 ] # -- pasm used: set I1, 333 end
Re: JIT branches under the Sun
On Fri, Feb 13, 2004 at 10:48:09AM +0100, Leopold Toetsch wrote: I don't know suns JIT code nor the assembler syntax, but it seems that the two subcc lines are broken: emitm_subcc_r(NATIVECODE, MAP[1], emitm_g(0), emitm_g(0)); If I understand that correctly it should read: emitm_subcc_r(NATIVECODE, MAP[1], MAP[1], emitm_g(0)); This would actually compare, say I1, to itself, and would then always be equal. So as I understand it, the line is ok: the subcc_r lines build these synthetic instructions where a compare is cmp reg, reg_or_imm -- subcc reg, reg_or_imm, %g0 Since if compares reg to 0 (as the not jitted core does), it uses register %g0 (for reg_or_imm) which contains 0 (%g0 is actually a special register in sparc always containing 0 no matter how - its just constant 0). Hence we have subcc reg, %g0, %g0 and in parrot(jit) terms: emitm_subcc_r(NATIVECODE, MAP[1], emitm_g(0), emitm_g(0)); Somehow I thaught that the problem could lie in the optimize section? Is there any simple way to disable that for jit? (it seems quite hardwired atm). Also, whats a good way to debug jit? meanning, I'm able to step through and see what is going on with gdb while still in parrot itself so to speak, but as soon as it jumps in jit.. its just a sort of blackbox. PS.: placing a 'print I1' within the loop resolves the problem, That could clear g(0) ... As said %g0 is just always 0, the only thing is that this one kind of jumps out of jit? leo Thanks, Stephane
Re: JIT branches under the Sun
On Sat, Feb 14, 2004 at 02:35:02PM +0100, Leopold Toetsch wrote: docs/debug.pod /jit saw that one, but jit doesn't generate a .o file under sparc? Stéphane
JIT branches under the Sun
Hi All, While playing with JIT on Suns, I've found out that the following pasm code: set I1, 2 LOOP: sub I1, 1 ifI1, LOOP print end\n end never finishes.. that is: parrot -j loop.pasm hangs forever (never printing 'end') while the non-jitted parrot loop.pasm prints 'end' and finishes there as expected. Can anybody give me some hints as to what is going on there? :) Thanks, Stephane PS.: placing a 'print I1' within the loop resolves the problem, both jitted and non jitted finishing properly in that case. Instead 'noop', 'set some' or else within the loop dont help the jitted case and hangs again.. set I1, 2 LOOP: sub I1, 1 ifI1, LOOP print end\n end # -- Sun/SPARC-V9 - Solaris 9 Summary of my parrot 0.0.13 configuration: configdate='Sun Feb 8 15:33:49 2004' Platform: osname=solaris, archname=sun4-solaris jitcapable=1, jitarchname=sun4-solaris, jitosname=SOLARIS, jitcpuarch=sun4 execcapable=0 perl=perl Compiler: cc='gcc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib ', cc_ldflags='', libs='-lsocket -lnsl -ldl -lm -lpthread -lrt' Dynamic Linking: so='.so', ld_shared='-G -L/usr/local/lib', 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
Re: RT Cleanup
Hi All, Attached here is a list with old entries in RT where you can see the requestor (email address), ticket number, description. If your email address is in there, please give an update or I'll go flagging these as obsolete (unless they are obviously resolved, patch applied or else ;) Thanks Stphane On Sun, 2004-01-25 at 05:25, Will Coleda wrote: Sorry for the singletons in the previous messages, didn't expect to find more than the first. This isn't meant to be a canonical list of close-able things, just those I found poking around for several minutes. In the open queue, there are 5 calls that range from 10 months to two years old that may be crufty. These are all from the new queue for parrot. 22183 is a [PATCH] (though it doesn't claim to be) that's been Applied. 22521 is a bug that leo fixed but didn't close. 22360 is a bug that someone fixed, but didn't take credit for or close. 22328 is a [PATCH] that's been Applied. 22617 is a bug leo fixed but didn't close. 22645 is fixed, as nested subs won't even compile at this point. 22718 is an applied [PATCH] (though it doesn't claim to be a patch.) 22995 is an applied [PATCH] 23346 is an applied [PATCH] 23064 is an applied [PATCH] 23039 was marked applied, Nicholas Clark asked if it should be closed, and then it was unmarked applied. Leo? Can this be closed? 24662 was a [PATCH], applied. 24701 is a [PATCH]. Dan and Leo both said to apply it, and peering at my fairly recent checkout, it appears to have been applied. 25144 should be assigned to Melvin, as he said he was working on a fix. 25252 is spam. -- Will Coke Coledawill at coleda dot com 19192 JIT fails 3 tests on AMD K5 1 years [EMAIL PROTECTED]17159 imcc / Mac OS X problem 1 years [EMAIL PROTECTED]24865 Parrot and Gentoo 3 weeks [EMAIL PROTECTED]24682 [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch? 5 weeks [EMAIL PROTECTED] 16842 Solaris8/gcc warnings/errors 1 years [EMAIL PROTECTED] 22173 test t/native_pbc/number.t fails on powerpc linux9 months [EMAIL PROTECTED]19834 [PATCH] sub, add, mul, div with combinations of INT, NUM, PMC2 months [EMAIL PROTECTED]20298 Operators neg and abs in core.ops 2 months [EMAIL PROTECTED]22548 [PATCH] Numbers with a '+' sign in the exponent 2 months [EMAIL PROTECTED]22765 [PATCH] Unary '+' is not symmetric to unary '-' in languages/perl6 7 months [EMAIL PROTECTED]24553 [PATCH] missing documentation files in imcc.pod 2 months [EMAIL PROTECTED] 18097 [PATCH] allow NULL interpreter in sprintf like functions 1 years [EMAIL PROTECTED] 21600 [PATCH] Enable buffer io in PIO 9 months [EMAIL PROTECTED] 24224 [PATCH] IMCC: Macros are handled via hash 3 months [EMAIL PROTECTED] 24701 [PATCH] Build core_ops.c etc in ops dir instead of src 5 weeks [EMAIL PROTECTED] 16258 [PATCH] The Great Renaming 1 years [EMAIL PROTECTED] 16622 RE: [PATCH PDD07] Document struct naming conventions 1 years [EMAIL PROTECTED] 17646 [PATCH] Add stone-age exception handling 1 years [EMAIL PROTECTED] 17817 [PATCH] Parrot_sprintf-related stuff, part 2 1 years [EMAIL PROTECTED] 19467 [PATCH] win32.h - MinGW #pragma warnings 1 years [EMAIL PROTECTED] 22174 [PATCH] snprintf link errors on Win32 9 months [EMAIL PROTECTED] 22175 [PATCH] Static libparrot should built by target 'all'9 months [EMAIL PROTECTED] 22319 [PATCH] extra-large is too big for varargs 8 months [EMAIL PROTECTED] 22321 [PATCH] debug tests when debugging 8 months [EMAIL PROTECTED] 22324 [PATCH] fixed test and
a Parrot plugin for Mozilla
Hi All,
For some reason.. always wanted to be able to write (and get) perl
applets on web browsers, so attached here is my go at a parrot plugin
for Mozilla :)
The files attached are:
The plugin.tar is the one containing it mainly with some instructions
on how to build it (and test it).
Since I need to pass onto parrot the pointer to the boxing window
(container) for the plugin in Mozilla, I have done this by pointing an
UnManagedStruct to it, hence the set_pointer patch attached for the
UnManagedStruct PMC:
As well, Gtk2 was used to test the plugin, so attached is a file with
required gtk.declarations plus a call_list.txt.patch if the signatures
for it are not built on the fly.
The examples merely display widgets in the Mozilla window as callbacks
to Parrot still need some work (but thats the Parrot side, so applets
will get better as soon as we have these ;)
Have fun :)
Stphane
PS.: I noticed that somehow recently events where added to Parrot, and
somehow this breaks the plugin when hitting reload on Mozilla. Comenting
out Parrot_init_events(interpreter) in interpreter.c resolves the
problem: is the event queue properly cleaned up on Parrot_destroy?
plugin.tar.gz
Description: GNU Zip compressed data
Index: unmanagedstruct.pmc
===
RCS file: /cvs/public/parrot/classes/unmanagedstruct.pmc,v
retrieving revision 1.22
diff -u -r1.22 unmanagedstruct.pmc
--- unmanagedstruct.pmc 4 Nov 2003 18:35:05 - 1.22
+++ unmanagedstruct.pmc 29 Dec 2003 18:34:08 -
@@ -246,6 +246,10 @@
return PMC_data(SELF);
}
+void set_pointer (void* value) {
+PMC_data(SELF) = value;
+}
+
void set_integer_native(INTVAL value) {
*(INTVAL *)PMC_data(SELF) = value;
}
[package]
Gtk
[lib]
libgtk-x11-2.0
[defs]
v gtk_init ii
v gtk_main v
p gtk_calendar_new v
# -- Gtk Widget
#p gtk_widget_new it# -- Check this (ellipsis)
p gtk_widget_ref p
v gtk_widget_unrefp
v gtk_widget_destroy p
#v gtk_widget_destroyedpp# -- Check this.
#v gtk_widget_set pt# -- Check this (ellipsis)
v gtk_widget_unparent p
v gtk_widget_show p
v gtk_widget_show_now p
v gtk_widget_hide p
v gtk_widget_show_all p
v gtk_widget_hide_all p
v gtk_widget_map p
v gtk_widget_unmapp
v gtk_widget_realize p
v gtk_widget_unrealizep
v gtk_widget_queue_draw p
v gtk_widget_queue_resize p
v gtk_widget_draw pp
v gtk_widget_size_request pp
v gtk_widget_get_child_requisitionpp
v gtk_widget_size_allocatepp
v gtk_widget_add_accelerator ptpiii
i gtk_widget_remove_accelerator ppii
v gtk_widget_set_accel_path ptp
p gtk_widget_list_accel_closures p
i gtk_widget_eventpp
i gtk_widget_activate p
v gtk_widget_reparent pp
i gtk_widget_intersectppp
i gtk_widget_is_focus p
v gtk_widget_grab_focus p
v gtk_widget_grab_default p
v gtk_widget_set_name pt
t gtk_widget_get_name p
v gtk_widget_set_statepi
v gtk_widget_set_sensitivepi
v gtk_widget_set_parent pp
v gtk_widget_set_parent_windowpp
p gtk_widget_get_parent_windowp
v gtk_widget_set_upositionpii
v gtk_widget_set_usizepii
v gtk_widget_set_events pi
v gtk_widget_add_events pi
v gtk_widget_set_extension_events pi
i gtk_widget_get_extension_events p
p gtk_widget_get_toplevel p
p gtk_widget_get_ancestor pi
p gtk_widget_get_colormap p
v gtk_widget_set_colormap pp
p gtk_widget_get_visual p
i gtk_widget_get_events p
v gtk_widget_get_pointer pii
i gtk_widget_is_ancestor pp
i gtk_widget_translate_coordinatespp
i gtk_widget_hide_on_delete p
v gtk_widget_set_stylepp
Re: pdump must die
Well I posted a very simple patch for it (maybe a bit too simplistic since it didnt end up being applied! ;-) Also noticied that I was the second trying apply a patch so that at least it does not core dump any more... Maybe its just hanging there for beginners to easy patch something ,-) Le 09.03.2002 à 13:54:45, Simon Cozens [EMAIL PROTECTED] a écrit: pdump takes over 43,000 lines of code and doesn't even work. Anyone fancy replacing it with something a mite simpler? -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
