At 03:26 PM 10/13/00 +, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > If there's no hit, I'd love to have all perl functions callable from
> > outside. I'm not sure that'll be the case, though I'm all for it...
>
>With the 334 infrastructure, the -o option to generate a linkable object
>fro
Dan Sugalski wrote:
> If there's no hit, I'd love to have all perl functions callable from
> outside. I'm not sure that'll be the case, though I'm all for it...
With the 334 infrastructure, the -o option to generate a linkable object
from a perl program/library (RFC 121) will be most do-able: "s
At 06:30 PM 10/10/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> >
> > Perl functions that are called from outside will have to have some sort of
> > interpreter attached to 'em. I can see either a default interpreter, or
> the
> > one they were compiled into being valid as a choice.
> >
> >
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 01:50 PM 10/10/00 -0400, Chaim Frenkel wrote:
>> There is an intermediate method, have our own execution and data stack.
>> Basically build a TIL interpreter. This might be intermediate in speed
>> between raw machine code and the perl
Dan Sugalski wrote:
>
> Perl functions that are called from outside will have to have some sort of
> interpreter attached to 'em. I can see either a default interpreter, or the
> one they were compiled into being valid as a choice.
>
> If there's no hit, I'd love to have all perl functions cal
At 01:50 PM 10/10/00 -0400, Chaim Frenkel wrote:
>There is an intermediate method, have our own execution and data stack.
>Basically build a TIL interpreter. This might be intermediate in speed
>between raw machine code and the perl vararg calls.
Perl functions that are called from outside will h
There is an intermediate method, have our own execution and data stack.
Basically build a TIL interpreter. This might be intermediate in speed
between raw machine code and the perl vararg calls.
If not intermediate in speed, I suspect it would involve cleaner
looking code. All functions would lo
At 08:50 PM 9/29/00 +0100, Nicholas Clark wrote:
>On Fri, Sep 29, 2000 at 12:37:15PM -0400, Dan Sugalski wrote:
> > At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote:
> > >Are you suggesting that the attributes use the same mapping system as
> > >the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils
On Fri, Sep 29, 2000 at 12:37:15PM -0400, Dan Sugalski wrote:
> At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote:
> >Are you suggesting that the attributes use the same mapping system as
> >the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils/typemap?
> >If so, will there be the "terse" column in
At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote:
>Are you suggesting that the attributes use the same mapping system as
>the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils/typemap?
>If so, will there be the "terse" column in the typemap file to associate
>"i" with "T_IV" ?
Hadn't considered it
On Thu, Sep 28, 2000 at 08:59:58PM -, Perl6 RFC Librarian wrote:
> =head1 DESCRIPTION
>
> Any sub that has the appropriate attribute can be called from C (or some other
> compiled language). Perl will automagically convert the input
> parameters (which is what the attributes tells us) to thin
11 matches
Mail list logo
