In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I was under the impression that ANSI C required that a void * be large
> enough to store any pointer type in it. Whether that's true or not's
> irrelevant at the moment, though we can work something out at some poi
At 02:36 PM 12/13/00 +, Nicholas Clark wrote:
>Ah. Digest system tells me some messages for me bounced.
>
> > From: Damien Neil <[EMAIL PROTECTED]>
> > On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
> > >int perl6_parse(PerlInterp *interp,
> > >void *sour
Ah. Digest system tells me some messages for me bounced.
> From: Damien Neil <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: The external interface for the parser piece
> Message-ID: <[EMAIL PROTECTED]>
> Mime-Version: 1.0
> Content-Type: text/plain; cha
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On a related note: a wrapper not completely unlike
JH> union sv_any_aligned_s {
JH> IV iv;
JH> NV iv;
JH> PV pv;
JH> void *vp;
JH> int (*dummy)(void) *fp;
JH> /* any others? */
JH> };
JH> should be used aroun
On Thu, Nov 30, 2000 at 04:15:24PM +, Nick Ing-Simmons wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> >
> >We're trying to make this an easy embedding API.
>
> Yes, and we are in danger of "premature optimization" of the _interface_.
Amen.
Tim.
> > > Huh? You're not talking about using this union around, say, the IV slot in
> > > a scalar, I hope...
> >
> >You hope in vain :-) If we still want to in perl6 to do (disgusting)
> >things like (we do in perl5)
> >
> > - "intercast" pointers and integers
> > - "intercast" integ
At 10:54 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> > At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > > On a related note: a wrapper not completely u
On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > On a related note: a wrapper not completely unlike
> > >
> > > union sv_any_aligned_s {
> > > IV iv
At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > On a related note: a wrapper not completely unlike
> >
> > union sv_any_aligned_s {
> > IV iv;
> > NV iv;
> > PV pv;
> > void *vp;
> > int (*du
On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> On a related note: a wrapper not completely unlike
>
> union sv_any_aligned_s {
> IV iv;
> NV iv;
> PV pv;
> void *vp;
> int (*dummy)(void) *fp;
> /* any others? */
> };
>
> should be used ar
Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>We're trying to make this an easy embedding API.
Yes, and we are in danger of "premature optimization" of the _interface_.
What we need to start with is a list of "what we need to know" - they may
as well be separate parameters at this point - the
Nicholas Clark <[EMAIL PROTECTED]> writes:
>> Counted strings should probably just have either a platform-native int in
>> front, or a 32-bit int in network format, both of which should be doable on
>> any platform that perl deals with.
>
>I agree it's do-able.
>What seems to me a good idea not
On a related note: a wrapper not completely unlike
union sv_any_aligned_s {
IV iv;
NV iv;
PV pv;
void *vp;
int (*dummy)(void) *fp;
/* any others? */
};
should be used around SVs to ascertain that everything fits everywhere.
--
$jhi++; # http://ww
On Tue, Nov 28, 2000 at 04:47:42PM -0500, Dan Sugalski wrote:
> At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
Not sure:
Dan:
> is treated as if it points to a stream of bytes, where the first four are
> the length o
At 07:29 AM 11/30/00 -0800, Dave Storrs wrote:
>On Wed, 29 Nov 2000, Dan Sugalski wrote:
>
> > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> > >I have a feeling this is a stupid question, but I have to ask anyway.
> > >
> > >Do we really need to pass in a PerlInterp pointer? Or can perl6_par
On Wed, 29 Nov 2000, Dan Sugalski wrote:
> At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> >I have a feeling this is a stupid question, but I have to ask anyway.
> >
> >Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
> >just create one for itself if/when it needs one? I
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Count me in with the people who prefer:
int perl6_parse(PerlInterp *interp, Perl
At 02:49 PM 11/29/00 +, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski wrote:
> > At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> > >FILE * is not a good idea. PerlIO * is fine.
> >
> > The problem with that is we're potentially getting the filehandle fro
On Wed, Nov 29, 2000 at 09:51:07AM -0800, Dave Storrs wrote:
> I have a feeling this is a stupid question, but I have to ask anyway.
> Do we really need to pass in a PerlInterp pointer?
Yes. Threads. There's a reason for all the PERL_EXPLICIT_CONTEXT anxiety.
--
Old Japanese proverb:
T
At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
>I have a feeling this is a stupid question, but I have to ask anyway.
>
>Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
>just create one for itself if/when it needs one? If created, it could of
>course be kept around so that
I have a feeling this is a stupid question, but I have to ask anyway.
Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
just create one for itself if/when it needs one? If created, it could of
course be kept around so that it didn't need to be re-created later.
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> But on the other hand I also liked Simon Cozen's argument that it should
NC> be easy to embed somewhere else, in which case why do we want to make
NC> the parser have a dependency on the IO library?
I can't see anyway that the dependen
Tom Hughes <[EMAIL PROTECTED]> writes:
>In message <[EMAIL PROTECTED]>
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>>
>> >FILE * is not a good idea. PerlIO * is fine.
>>
>> The problem with that is we're potentially getting the filehan
On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski wrote:
> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
> >FILE * is not a good idea. PerlIO * is fine.
>
> The problem with that is we're potentially getting the filehandle from
> something that isn't perl. Or so my thinking went at t
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> >FILE * is not a good idea. PerlIO * is fine.
>
> The problem with that is we're potentially getting the filehandle from
> something that isn't perl. Or so my
At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 07:03 PM 11/28/00 +, Tom Hughes wrote:
> >>In message <[EMAIL PROTECTED]>
> >> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>
> >> > The third parameter is the flags parameter, and it's
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>>In message <[EMAIL PROTECTED]>
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>> > The third parameter is the flags parameter, and it's optional. If omitted
>> > or set to PERL_CHAR_SOURCE, the secon
On Tue, 28 Nov 2000, Dan Sugalski wrote:
> >I also like the suggestion that rather than supply flags, we should
> >follow the lead and supply a Perl* something that would return an
> >appropriate bunch of text to the parser.
>
> I'd really rather not, since that would place the burden of knowing
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, and I called my abstract stream "void *source". :)
It isn't really abstract though as it only understand types of streams
that the parser author had thought of. An abstract stream would have a
vtable or som
Dan Sugalski wrote:
>
> Sure. Suggestions?
int perl6_parse(PerlInterp* interp, PerlIO* input);
PerlIO* make_memory_stream(char* buf, ssize_t length); // length=-1 for
nul-terminated
int close_stream(PerlIO* stream);
then if you read further, you'll eventually see:
PerlIO* make_callback_stream(
At 04:23 PM 11/28/00 -0500, Chaim Frenkel wrote:
>Err, this seems a little too Swiss Army Knife.
>
>This reads like a utility function. (i.e. A function that handles the
>most common scenerio.)
What it's supposed to be is the highest-level interface to the parser, and
so it's supposed to handle
At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > > is treated as if it points to a stream of bytes, where the first
> four are
>
>
>I spy magic number.
At 03:15 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software design problem
On Tue, Nov 28, 2000 at 03:15:35PM -0600, Jarkko Hietaniemi wrote:
> On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software
Err, this seems a little too Swiss Army Knife.
This reads like a utility function. (i.e. A function that handles the
most common scenerio.)
Shouldn't a set of lower level visible API be visible? One that seems
to pop out at me is some way of actually parsing a piece of code and
ending up with a
On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > Applying the maxim that any software design problem can be solved
> > > with sufficient levels of abstraction I'
On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > is treated as if it points to a stream of bytes, where the first four are
I spy magic number.
> > > the length of the source to be read followed by the
At 09:10 AM 11/28/00 -1000, Tim Jenness wrote:
>On Mon, 27 Nov 2000, Dan Sugalski wrote:
>
> > ---
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
> >
>
> > The third para
At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > Applying the maxim that any software design problem can be solved
> > with sufficient levels of abstraction I'd suggest that passing some
>
>A related warning sign is trying to cra
At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> > null-t
On Mon, 27 Nov 2000, Dan Sugalski wrote:
> ---
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
>
> The third parameter is the flags parameter, and it's optional. If omitted
> o
On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a sta
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The third parameter is the flags parameter, and it's optional. If omitted
> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> null-terminated string. If set to PERL_COUNTED_SOURCE, the sec
--- Steve Fink <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
>
> Given that other things may want to be streamable in
> similar f
At 09:48 AM 11/28/00 -0800, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
>
>Given that other things may want to be streamable in similar fash
Dan Sugalski wrote:
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Given that other things may want to be streamable in similar fashion (eg
the regular expression engine), why not have a Per
While I'm not sure of the structure of the internals of the parsing piece
of perl at the moment (and, unfortunately, language parsers aren't one of
my strong points), I am reasonably certain of the interface we'll present
to the rest of the world and the other pieces of perl. So... comments?
-
47 matches
Mail list logo
