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_stri
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
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=Per
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
> > # -- funct
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 a
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
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 e
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 rem
Well, still about getting callbacks to work on GTK, thaught that before
going for this:
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote:
> >Otherwise, already thaught of actually unrolling the gtk_main function
> >and have it handled/implemented within parrot directly (mainly gtk_
This patch adds tests for is 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
These two patches add jit support for is style ops (isgt, isge, isle,
islt, iseq, isne) on integers for the sun/sparc platform.
The jitted code follows this "pattern":
cmp %r2, %r3
b,a next
mov 1, %r1
mov 0, %r1
next: ..
defining th
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
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
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
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
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:
>
>
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
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
On Sat, Feb 14, 2004 at 06:19:42PM +0100, Leopold Toetsch wrote:
> If that runs and it works you get a stabs file (for parrot -d -j). This is
> compiled via an hardcoded line with "as". s. jit_debug.c
mh ok, I do get the stabs file, and apparently the reason no objfile gets
created is that "as" c
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
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 lo
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, 2693
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:[EM
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.
24 matches
Mail list logo
