On Wed, 2008-08-20 at 22:20 +0200, Ron Blaschke wrote:
> I think we need a way to select the calling convention for a function,
> similar to, or maybe even part of, the signature. Also, it would be
> good to have a way to select a calling convention when loading a
> library, as a calling conventio
These statements are removed in r23981.
kjs
On Dec 16, 2007 4:16 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
> > Hi,
> >
> > At the top of the NCI PMC, there are these comments:
> >
> > --
> > Invoking an NCI function changes some registers according to PDD 3.
>
Jonathan Worthington wrote:
Hi,
At the top of the NCI PMC, there are these comments:
--
Invoking an NCI function changes some registers according to PDD 3.
The caller has to preserve registers if needed.
--
Am I right in thinking that's no longer true?
Yes, PDD 3 no longer uses specific reg
On Friday 21 July 2006 11:43, Leopold Toetsch wrote:
> Without futher looking - you have to replace a lot of 'p's (some structure)
> with 'J' (the Interpreter* interp structure). E.g.
>
> .store_nci_func( 'Parrot_readbc', 'ppt' )
>
> =>
>
> .store_nci_func( 'Parrot_readbc', 'pJt' )
I'm not co
Am Freitag, 21. Juli 2006 20:08 schrieb chromatic:
> On Friday 21 July 2006 00:57, Leopold Toetsch wrote:
> > (You could use 'pIt' and 'pIp' signatures too, then the STRING* result of
> > the 'const_string' would be wrapped into a ManagedStruct PMC).
>
> I don't see documentation for the S or I par
On Friday 21 July 2006 00:57, Leopold Toetsch wrote:
> This can't work for several reasons:
>
> 1) the NCI call signatures don't match the C functions' args:
>
> .store_nci_func( 'const_string', 'ppt' )
>
> should be: 'SIt' (return STRING*, interp & C-cstring args)
>
> .store_nci_func
Am Freitag, 21. Juli 2006 07:53 schrieb chromatic:
> Should this code work? I think so.
This can't work for several reasons:
1) the NCI call signatures don't match the C functions' args:
.store_nci_func( 'const_string', 'ppt' )
should be: 'SIt' (return STRING*, interp & C-cstring args
On Friday 03 March 2006 02:41, Tim Bunce wrote:
> Any news on this? Is it okay? Should I send it via parrotbug?
It looked good to me. I say check it in and see what the smokes do.
-- c
Any news on this? Is it okay? Should I send it via parrotbug?
Tim.
On Tue, Feb 28, 2006 at 03:36:20PM +, Tim Bunce wrote:
> On Tue, Feb 14, 2006 at 10:04:59PM +0100, Leopold Toetsch wrote:
> > On Feb 14, 2006, at 18:29, Tim Bunce wrote:
> >
> > >The runtime dlfunc code will need to be altere
On Tue, Feb 14, 2006 at 10:04:59PM +0100, Leopold Toetsch wrote:
> On Feb 14, 2006, at 18:29, Tim Bunce wrote:
>
> >The runtime dlfunc code will need to be altered to normalize away the
> >trailing v so old code won't break. Should it warn about that?
>
> Yes, a warning please.
Here's the patch.
On Feb 14, 2006, at 18:29, Tim Bunce wrote:
I'll aim to work up a patch this week.
Great, thanks.
The runtime dlfunc code will need to be altered to normalize away the
trailing v so old code won't break. Should it warn about that?
Yes, a warning please.
Tim.
leo
On Feb 14, 2006, at 21:45, chromatic wrote:
To avoid confusion, I suggest requiring that functions returning void
always
use 'v' and disallowing the signature ''.
Exactly my thoughts too.
leo
On Tuesday 14 February 2006 05:48, Leopold Toetsch wrote:
> I'd say, we should drop all the '?v' variants. The extra 'v' doesn't
> cover any information, it's just causing an init call to the argument
> passing code.
To avoid confusion, I suggest requiring that functions returning void always
us
On Tue, Feb 14, 2006 at 02:48:41PM +0100, Leopold Toetsch wrote:
> Tim Bunce wrote:
> >What's the difference between 'v' and '' for NCI function parameters?
>
> There isn't any, except the extra 'v' char.
>
> >I ask because both 'fv' and 'f' are in src/call_list.txt
>
> Yeah.
>
> >In fact there
Tim Bunce wrote:
What's the difference between 'v' and '' for NCI function parameters?
There isn't any, except the extra 'v' char.
I ask because both 'fv' and 'f' are in src/call_list.txt
Yeah.
In fact there are several 'duplicated' signatures:
[ ... ]
I'd say, we should drop all the '
On Aug 23, 2005, at 14:38, Klaas-Jan Stol wrote:
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
void print_pmc(void *PMC)
{
// how to access the string in P?
}
If it's a stringish PMC, then STRING *s = VTABLE_get_string(INTERP,
p); will do it.
The C code is just in a .c file, it's n
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
hi,
I'm currently trying to check out the NCI. As my Lua compiler only
uses PMCs (and not I/N/S registers), calling C functions will only be
done with PMCs.
I couldn't find info on this matter: suppose I have this string PMC,
how can I access
Klaas-Jan Stol wrote:
hi,
I'm currently trying to check out the NCI. As my Lua compiler only uses
PMCs (and not I/N/S registers), calling C functions will only be done
with PMCs.
I couldn't find info on this matter: suppose I have this string PMC, how
can I access the actual string in it?
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> I see. Does this morphing work as designed? Creating an array out of
>> an undef feels somewhat wrong.
> Yes and yes ;)
> A longer answer is: all operators currently need an existing LHS.
[snip]
Thanks for explaining things.
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> I see. Does this morphing work as designed? Creating an array out of
> an undef feels somewhat wrong.
Yes and yes ;)
A longer answer is: all operators currently need an existing LHS. The
canonical way is:
lhs = new Undef
lhs = a b
While we AFAIK
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> assign nci_dlvar_float, nci_dlvar_float_decl
> This calls Undef::assign, which morphs the Undef to the RHS type. So the
> Undef becomes an array and
>> N2 = nci_dlvar_float[0]
> this succeeds.
I see. Does this morphing
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> assign nci_dlvar_float, nci_dlvar_float_decl
This calls Undef::assign, which morphs the Undef to the RHS type. So the
Undef becomes an array and
> N2 = nci_dlvar_float[0]
this succeeds.
leo
[EMAIL PROTECTED] wrote:
| -- Original Message --
| From: Charles Lowell <[EMAIL PROTECTED]>
| The whole reason I'm fooling around with nci in the first place is to
| register callbacks as described in pdd16, and it was the function
| signature of 'vCYZ' that was failing.
The docs aren't yet up
On Wednesday 15 September 2004 23:58, Brent 'Dax' Royal-Gordon wrote:
> I'm not sure this is a panic-worthy error--panics are really meant for
> cases where something has gone horribly, unfixably wrong in the
> interpreter's guts, like a critical pointer in the ParrotInterp got
> nulled out, or som
| -- Original Message --
| From: Charles Lowell <[EMAIL PROTECTED]>
| The whole reason I'm fooling around with nci in the first place is to
| register callbacks as described in pdd16, and it was the function
| signature of 'vCYZ' that was failing.
The docs aren't yet updated, sorry. Have a loo
Brent 'Dax' Royal-Gordon wrote:
Jens Rieks <[EMAIL PROTECTED]> wrote:
It now prints an error message:
with nothing
with int 5
Parrot VM: PANIC: vt is an unknown signature type.
CAN_BUILD_CALL_FRAMES is disabled, add the signature to src/call_list.txt!
C file src/nci.c, line 4485
Parrot file (unk
Jens Rieks <[EMAIL PROTECTED]> wrote:
> It now prints an error message:
>
> with nothing
> with int 5
> Parrot VM: PANIC: vt is an unknown signature type.
> CAN_BUILD_CALL_FRAMES is disabled, add the signature to src/call_list.txt!
> C file src/nci.c, line 4485
> Parrot file (unknown file), line 0
Hi!
On Wednesday 15 September 2004, [EMAIL PROTECTED] wrote:
> Is there anyone who could help remove said bone from my head?
It now prints an error message:
with nothing
with int 5
Parrot VM: PANIC: vt is an unknown signature type.
CAN_BUILD_CALL_FRAMES is disabled, add the signature to src/call_
thanks leo -- it worked! i'm still going to keep my wrapper lib around
though, just in case there are platforms where this dlfunc trick doesn't
work. but that can easily be detected during configuration.
-jeff
On Fri, 10 Sep 2004, Leopold Toetsch wrote:
> Jeff Horwitz wrote:
>
> > 1. can you s
Jeff Horwitz wrote:
1. can you still dlopen the running image by passing a NULL string to loadlib?
No. Didn't work that way, IIRC
2. can you dlsym (via dlfunc) a statically linked function?
Yes. Pass NULL for the library PMC:
.sub main @MAIN
.local pmc nul
null nul
.local NCI f
.loc
i put my old code back in and got apache to segfault. here's a backtrace,
which confirms the offending code, but it doesn't offer much explanation.
btw, i'm working off a CVS update from last night.
#0 0xb713b11a in Parrot_dlfunc_p_p_sc_sc (cur_opcode=0xb52a80d0,
interpreter=0x815fc50) at co
> I think the problem here is that you need to pass a NULL into dlopen
> for the filename to get the main image, not a null string.
[snip]
> null $S0
> loadlib self_lib, $S0
that's exactly what i was doing -- i should have included more of the
actual code in my original mail (i admit, nu
At 11:02 AM -0400 9/9/04, Jeff Horwitz wrote:
okay, i'm bringing back a thread from a year ago. for mod_parrot, i'd
like to be able to loadlib the running process image (httpd) and dlfunc
the various apache API functions. however, while this works for libc
functions, and any other functions from
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> The only issue I see atm is if parrot wants to call the callback it-
> self while in the "waiting for callback loop", mean it would run into
> some race conditions if for some reasons parrot invokes the callback,
> and somebody triggers the callback via g
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_
On Tue, 31 Aug 2004 05:56:27 -0700 (PDT), Joshua Gatcomb
<[EMAIL PROTECTED]> wrote:
> Obviously the test is passing, but the expected result
> is different:
> loaded runtime/parrot/dynext/libnci.so
> vs
> loaded libnci.so
I'm getting the same thing on Solaris 8 using GCC 3.4.1 with solaris binutil
--- Bernhard Schmalhofer
<[EMAIL PROTECTED]> wrote:
> Printing a initialised ParrotLibrary currently gives
> you the '_filename'
> property. This is highly platform dependent, and
> therefore hard to test.
>
> I could rewrite the test and check only, that the
> stringified
> ParrotLibrary conta
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> # got: 'loaded libnci.so
> Before I started digging around I was wondering if
> someone might want to whack me with the clue stick.
rm libnci.so ?
> Cheers
> Joshua Gatcomb
leo
Joshua Gatcomb wrote:
just not sure how to fix it
t/pmc/nciok 1/35# Failed test (t/pmc/nci.t at
line 59)
# got: 'loaded libnci.so
# 8.00
# '
# expected: 'loaded
runtime/parrot/dynext/libnci.so
# 8.00
# 'mc/nciNOK 2
Obviously the test is passing, but the expected res
At 3:32 PM +0200 8/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I can trigger the problem locally, though not with the nci tests.
(And, indeed, it may not be the NCI tests ultimately at fault) The
core dump shows things dying in the dod run.
It's fixed. See answer to you
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can trigger the problem locally, though not with the nci tests.
> (And, indeed, it may not be the NCI tests ultimately at fault) The
> core dump shows things dying in the dod run.
It's fixed. See answer to your ticket.
leo
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can trigger the problem locally, though not with
> the nci tests.
> (And, indeed, it may not be the NCI tests ultimately
> at fault) The
> core dump shows things dying in the dod run. GDB's
> backtrace is:
>
> Dan
Ok, I tracked it down to a CVS
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb wrote:
> > This might help shed some light:
> >
> > $ cd t/pmc
> > $ parrot nci_1.pasm
>
> Not really. bash: parrot: command not found ;)
> You got an old parrot around somewhere in the path?
No - believe it or not I only ever ke
At 10:06 AM +0200 8/27/04, Leopold Toetsch wrote:
Joshua Gatcomb wrote:
$ parrot --gc-debug nci_1.pasm
Segmentation fault (core dumped)
Well, I just don't have these segfaults. Wait ... Oops, I've turned
on incremental GC here, which could make it succeed. Recompiling ...
another coffee ...
No.
Joshua Gatcomb wrote:
This might help shed some light:
$ cd t/pmc
$ parrot nci_1.pasm
Not really. bash: parrot: command not found ;)
You got an old parrot around somewhere in the path?
$ parrot --gc-debug nci_1.pasm
Segmentation fault (core dumped)
Well, I just don't have these segfaults. Wait ..
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
>
> > t/pmc/nci.t28 716835 28 80.00%
> 1-27
>
> strange.
>
> > t/pmc/perlhash.t1 256361 2.78% 20
>
> Only that one is supposed to fail.
>
> leo
This might help shed so
At 5:26 PM +0200 8/26/04, Leopold Toetsch wrote:
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
t/pmc/nci.t28 716835 28 80.00% 1-27
strange.
Yeah. I've got NCI stuff failing all over the place for me on Linux,
though not in the test suite, which is frustrating. It's GC related
so far
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> t/pmc/nci.t28 716835 28 80.00% 1-27
strange.
> t/pmc/perlhash.t1 256361 2.78% 20
Only that one is supposed to fail.
leo
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
Stephane Peiry wrote:
dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
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.
Parrot stuffs the interpreter and the Sub PMC into user_data and unpacks
that when th
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 runnin
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
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.
The whole idea behind callbacks is, that there is a userdata argument
that get's passed through tr
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.
I now tried calling g_cclosure_new_object() and
g_signal_connect_closure() directly. Doesn't segfault anymore (at least,
Stephane Peiry wrote:
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"?
gtk shouldn't make assumption on the user_data argument IMHO.
Whats the difference between the way parrot calls
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
Stephane Peiry 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?
I've beautified the example a bit, segfaults
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
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> 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,
>
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
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> 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
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
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> 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?
"gtk-signal-connect" or "g-signal-connect" isn't found here. I can't
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:19 PM +0100 1/4/04, Leopold Toetsch wrote:
>>Its a bit complicated and brain-mangling, the more in the absence of
>>any examples, but the current design in pdd16 seems to lack some
>>flexibility and is IMHO missing the proper handling of the
>>(library
On Mon, Jan 12, 2004 at 01:01:58PM -0600, Garrett Goebel wrote:
> Tim Bunce wrote:
> > > Tim Bunce wrote:
> > >
> > > I see Dan says in his blog "Yeah, I know, we should use libffi, and
> > > we may as a fallback, if we don't just give in and build up the
> > > function headers everywhere."
> > >
Tim Bunce wrote:
> > Tim Bunce wrote:
> >
> > I see Dan says in his blog "Yeah, I know, we should use libffi, and
> > we may as a fallback, if we don't just give in and build up the
> > function headers everywhere."
> >
> > I'm not familiar with libffi so this may be a dumb question,
> > but why
At 10:13 AM -0600 1/12/04, Garrett Goebel wrote:
Tim Bunce wrote:
I see Dan says in his blog "Yeah, I know, we should use libffi, and
we may as a fallback, if we don't just give in and build up the
function headers everywhere."
I'm not familiar with libffi so this may be a dumb question,
but w
On Sat, Jan 10, 2004 at 09:42:14PM +, Tim Bunce wrote:
> On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote:
> > Jeff Clites <[EMAIL PROTECTED]> wrote:
> >
> > > I assume the plan is to get on-the-fly building of NCI stubs working
> > > "everywhere". Platforms where that works don
Tim Bunce wrote:
>
> I see Dan says in his blog "Yeah, I know, we should use libffi, and
> we may as a fallback, if we don't just give in and build up the
> function headers everywhere."
>
> I'm not familiar with libffi so this may be a dumb question,
> but why the apparent reluctance to use it?
On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
>
> > I assume the plan is to get on-the-fly building of NCI stubs working
> > "everywhere". Platforms where that works don't need the functions
> > generated by build_nativecall.pl, but right
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I assume the plan is to get on-the-fly building of NCI stubs working
> "everywhere". Platforms where that works don't need the functions
> generated by build_nativecall.pl, but right now that's only i386; it's
> a JIT-like and pretty difficult piece of code
On Jan 10, 2004, at 6:50 AM, Harry Jackson wrote:
# New in libpq.so.3.1
t pt
p ptit33i
i ptit33i
i ptiit33i
c pi
I have jsut added the above signatures to my call_list due to an
upgrade to postgres and was wondering what plans are there for
managing the call_l
Harry Jackson wrote:
I have tested the patches below now. Could someone have a look at them
and see if they can get commited especially the patch to the
call_list.txt file.
# New in libpq.so.3.1
t pt
p ptit33i
i ptit33i
i ptiit33i
c pi
I have jsut added the a
I have tested the patches below now. Could someone have a look at them
and see if they can get commited especially the patch to the
call_list.txt file.
Harry
Harry Jackson wrote:
Some questions
Please note:
I have been unable to test these patches with "make test" due to the
problems I mentio
At 8:19 PM +0100 1/4/04, Leopold Toetsch wrote:
Its a bit complicated and brain-mangling, the more in the absence of
any examples, but the current design in pdd16 seems to lack some
flexibility and is IMHO missing the proper handling of the
(library-provided) external_data. The latter will be pa
Jared Rhine <[EMAIL PROTECTED]> wrote:
> [Leopold == [EMAIL PROTECTED] on Fri, 7 Nov 2003 08:43:04 +0100]
> Leopold> [ shared file extensions ]
> Leopold> Can we for now do it like:
> Leopold> * if there is a dot in the filepart[1] leave the name as is
> Leopold> * if not append PARROT_DLL_EXTENS
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
>> > src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
>> Did you recheck that recently, I had committed a change WRT this.
> I did, and I just did an update now to try it again. Same set of errors
> still appear. Again, it's bec
> Jonathan Worthington <[EMAIL PROTECTED]> wrote:
>
> > src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
>
> Did you recheck that recently, I had committed a change WRT this.
I did, and I just did an update now to try it again. Same set of errors
still appear. Again, it's beca
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
Did you recheck that recently, I had committed a change WRT this.
> NMAKE : warning U4006: special macro undefined : '$<'
> link -dll -def:libparrot.def -nologo -debug
> Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > Ah, that's changed, 'cus it used to work with me doing that. :-) So
now it
> > loads the library, but fails here:-
>
> > dlfunc P0, P1, "MessageBoxA", "llttl"
>
> > With:-
>
> > Parrot VM: PANIC: Unknown signature type!
>
> Your parrot seems t
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Ah, that's changed, 'cus it used to work with me doing that. :-) So now it
> loads the library, but fails here:-
> dlfunc P0, P1, "MessageBoxA", "llttl"
> With:-
> Parrot VM: PANIC: Unknown signature type!
Your parrot seems to lack JIT support
> > loadlib P1, "user32.dll"
>
> There are 2 errors in that, one is mine :)
> - I didn't use the configure define of PARROT_DLL_EXTENSION
> - Your's is: don't append ".dll" - parrot does it
Ah, that's changed, 'cus it used to work with me doing that. :-) So now it
loads the library, but fails her
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Hi,
> loadlib P1, "user32.dll"
There are 2 errors in that, one is mine :)
- I didn't use the configure define of PARROT_DLL_EXTENSION
- Your's is: don't append ".dll" - parrot does it
BTW - are the nci tests succeeding on Win32:
$ make libnci.dl
Michael Scott <[EMAIL PROTECTED]> wrote:
> On OS X 10.2.6 (gcc 3.3) make dies with:
> perl build_nativecall.pl call_list.txt
> nci.c
> nci.c: In function `pcf_i_42p':
> nci.c:454: error: invalid lvalue in unary `&'
I see. Thanks fixed.
leo
At 7:55 PM -0500 11/25/02, Dan Sugalski wrote:
Okay, I've finished the framework for the NCI stuff. The code to
make storing into PMCs, and using strings, needs finishing, but the
rest is in there. (Something went awry with the checkin, so it might
not have been noted properly)
Okay, fetches f
85 matches
Mail list logo
