At 8:27 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Yes, of course. Parrot built with the JIT throws a fatal exception
when loading up the postgres.imc library.
Should be fixed now.
Cool, thanks.
--
Dan
Chromatic <[EMAIL PROTECTED]> wrote:
> Would it be easier to require that all out parameters use PMCs instead
> that are converted to their low-level types? For example, for my
> signature of:
> int SDLCALL TTF_SizeText(TTF_Font *font, const char *text, int *w, int
> *h);
A PMC doesn't wo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Yes, of course. Parrot built with the JIT throws a fatal exception
> when loading up the postgres.imc library.
Should be fixed now.
leo
On Thu, 2004-04-29 at 10:25, Leopold Toetsch wrote:
> I'm still thinking that we should reduce the amount of signatures. Some
> special pointer types could be ok, though, *if* we can find something
> for/against the in/out problem.
Brainstorming again, I had a bit of insight.
The real problem is
At 7:25 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Nah, those work. And I'm using quite a number of them as part of the
postgres wrapper. (One of the reasons I have a non-jit build, since
they're not implemented in it)
If JIT can't build a signature like 'L
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Nah, those work. And I'm using quite a number of them as part of the
> postgres wrapper. (One of the reasons I have a non-jit build, since
> they're not implemented in it)
If JIT can't build a signature like 'L' or whatnot, it falls back to
hard-wired con
At 6:35 PM +0200 4/29/04, Leopold Toetsch wrote:
Chromatic <[EMAIL PROTECTED]> wrote:
Building structs to pass around is currently very verbose and my least
favorite part of NCI. (Again, it's not nearly as tricky as XS, for
which I'm very grateful.)
Building a struct is still the right thing.
Chromatic <[EMAIL PROTECTED]> wrote:
> Building structs to pass around is currently very verbose and my least
> favorite part of NCI. (Again, it's not nearly as tricky as XS, for
> which I'm very grateful.)
Building a struct is still the right thing. We currently already have
some more (unimplem
On Thu, 2004-04-29 at 03:05, Tim Bunce wrote:
> > Provided we pick a convention that makes sense (that is, out parameters
> > go in I5, I6, ... In, and then the actual returned value goes at the end
> > of the list in In+1) and stick with it, I like option A a little better.
>
> Is there a good r
On Thu, 2004-04-29 at 05:43, Dan Sugalski wrote:
> While it's much nicer to reorder the parameters, I left them in that
> way on purpose. Once you start reordering in and out parameters then
> you get into multiple joined parameters (buffer pointers and lengths)
> and then it starts (well, cont
At 10:36 PM -0700 4/28/04, chromatic wrote:
On Wed, 2004-04-28 at 03:23, Leopold Toetsch wrote:
> Well, that's ok for this one. Bu, what if we have:
int foo(int *i, int *j) {}
in I5 in I6
out I5
We could fake that as:
(i, j, retval) = foo(i, j)
and count each pointer typ
On Wed, Apr 28, 2004 at 10:36:00PM -0700, chromatic wrote:
> > Or, we forget about these special cased pointer to int and pass a
> > managed struct.
>
> That's cleaner from the C side, but it's enough of a pain to set up
> managed structs on the calling side that I'd rather do it only when it's
>
On Wed, 2004-04-28 at 03:23, Leopold Toetsch wrote:
> > I patched pcf_i_pt33()
>
> missing test?
That's an autogenerated file and my patch was only a local proof of
concept. I'm not sure exactly how the interface should look, so I
haven't written the test yet.
> Well, that's ok for this one. B
Chromatic <[EMAIL PROTECTED]> wrote:
> ... Still, there has to be some extra support for out
> parameters, or else NCI will walk all over the newly-updated contents of
> the registers with the return results.
Ah yep. That's a problem.
> I patched pcf_i_pt33()
missing test?
> ... manually to p
On Mon, 2004-04-26 at 23:15, Leopold Toetsch wrote:
> > Per my reading of the NCI PDD and the code, this isn't yet supported.
>
> Then the POD is missing some items:
>
> ,--[ src/call_list.txt ]
> | # 2 - pointer to short
> | # 3 - pointer to int
> | # 4 - pointer to long
> `
Chromatic <[EMAIL PROTECTED]> wrote:
> int SDLCALL TTF_SizeText(TTF_Font *font, const char *text, int *w, int
> *h);
> *w and *h are out parameters.
> Per my reading of the NCI PDD and the code, this isn't yet supported.
Then the POD is missing some items:
,--[ src/call_list.txt ]
| # 2 - point
# New Ticket Created by chromatic
# Please include the string: [perl #29200]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29200 >
I've just come across the following signature for which I want to write
NCI bindings:
/
17 matches
Mail list logo
