On Tue, Mar 16, 2010 at 3:19 PM, Andrew Whitworth <[email protected]> wrote: > Putting arguments into a ResizablePMCArray or Hash and using :flat > (Signature "Pf") would similarly resolve the problem.
So we'd have to create a bunch of extra PMCs on every call to pass ints, floats, and strings? Ewwww! I know that marshaling between calling conventions is inevitably going to be more expensive, but why do we make it more expensive when it doesn't have to be? Also, what if I want to pass a parameter using :flat? Then I can't use this trick. > On Tue, Mar 16, 2010 at 3:03 PM, Jonathan Leto <[email protected]> wrote: >> Howdy, >> >> Recently on #parrot, eggyknap++ asked this question: >> >> <eggyknap> davidfetter and I are embedding parrot in postgresql, and >> are under the impression we should use Parrot_ext_call(). The problem >> is that requires us to know at compile time the functions arguments, >> which we can't do. >> <Coke> davidfetter: ... can't you just dynamically construct the >> signature string? >> <eggyknap> The signature string is easy. But the arguments themselves >> aren't. Parrot_ext_call() takes a signature string and a varargs list >> of arguments >> ... >> <Coke> eggyknap: I wonder if we could take a container PMC or >> something and let you use :flat. I've found somewhere else where I find the varargs interface on PCC obstructive: frame builders (I'm looking at libffi ATM). There's just no way to call Parrot_pcc_fill_params_from_c_args() in the ways required using standard C. Fortunately here, I can guarantee that some library is around to call into C with arbitrary args, so I can work around the issue by using the frame builder to call into parrot, but it doesn't have to be that complicated. >> After doing a little research, it seems that plobsing++'s work on the >> Parrot_ext_call_cb function in the tt1477 branch is what we need [0], >> but I would like to be sure and ask for additional comments about the >> best way to go about this. We want a solution that will work for >> stored procedures written in any language sitting on top of Parrot, >> not just PIR, but for the time being, we are more than happy to get >> just PIR working. I started the tt1477 branch intent on creating an interface that took a C<void *[]> (with assumptions about to what the elements point), which would work for all the cases I've encountered where the varargs interface is unsatisfactory (would this work for PL/Parrot?). But I realized quickly that callbacks would be the most general way, out of which an interface using C<void *[]> could easily be created. There are some small advantages to using callbacks over C<void *[]>, but I'd be content if PCC provided any general purpose interface to C (preferably something simple and C-ish, not something ladden unecessarily with PMCs). _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
