At 3:16 PM -0700 5/18/02, Brent Dax wrote:
>Dan Sugalski:
># At 1:14 PM -0700 5/15/02, Brent Dax wrote:
># >Dan Sugalski:
># ># At 12:51 AM -0700 5/15/02, Brent Dax wrote:
># ># >-Parrot becomes Parrot_Interp
># ># >-Parrot_String is gone and the string_funcs.h functions are # no
># >longer # >externally visible. -A few structures have been renamed.
># ># >-config.h has been rearranged so that INTVAL, etc. are now
># ># aliases for
># ># >Parrot_Int, etc.
># ># >-A few things that were accidentally made external no longer are.
># >#
># ># This isn't a problem with config.h. config.h should *never* be used
># ># by anyone embedding Parrot, either directly or indirectly.
># >
># >Why not? Some parts of Parrot's embedding system have to be
># set up by
># >Configure.
>#
># And those parts should go in embed.h. The bare minimum amount of
># stuff should go in there--the definitions of INTVAL, NUMVAL, Buffer,
># STRING (maybe), and the exported functions. A later phase of the
># build could probably set this up as well, as it'd have access to more
># information.
>
>I'm trying to keep the number of dynamically-generated files to a
>minimum.
Why?
>We don't lose anything by defining a small part of config.h
>that's external, and we gain a static embed.h.
There's too much risk of leakage. Once things leak, they can't easily
be retracted. I'd rather not have them leak in the first place.
># Stuff like PMC definitions shouldn't go in it. PMC * should be
># typedef'd to void * in the embedding header.
>
>What I do is declare things like
>
> struct parrot_pmc_t;
> typedef struct parrot_pmc_t* Parrot_PMC;
>
>So we don't get warnings about type mismatches when we compile embed.c.
That works.
>Actually, Parrot_PMC won't be in embed.h directly--it'll be in extern.h,
>which defines the interface between the outside world and PMCs and
>STRINGs. (I'm planning for extenders to use the same interface, which
>is why it's in a separate header. embed.h will probably include
>extern.h, so it'll be transparent to the user.)
Keeping the interfaces separate is good, and keeping them compatible
is also good. Works for me.
># ># >I first noticed the problems with computed-goto when I
># found the #
># >>following line in test_main.c: # >
># ># > #ifdef HAVE_COMPUTED_GOTO
># ># >
># ># >See the problem?
># >#
># ># Yes. test_main.c should never have to know about computed
># goto cores
># ># or whatnot. The define's likely something generally passed on the
># ># command line to all the parrot core bits,
># >
># >True. Still, the idea of a define like this not being fixed
># somewhere
># >scares me a bit. If someone tries to send us a copy of
># their config.h
># >so we can debug a problem, we can't tell if they have cgoto enabled.
>#
># That's definitely a problem. That #define should be in config.h, and
># *is* a problem.
>
>Actually, the JIT does the same thing, so it's not *entirely* his fault.
I'm not looking to place blame--I don't really care that much, and
blame doesn't really buy us anything. I'd just rather it not happen,
and get fixed when it does.
># >Actually, it should know that Parrot may support a
># computed-goto core
># >and the flag to enable it is X. It shouldn't have to know if this
># >particular copy of Parrot is built with that capability.
># (It probably
># >should be able to detect it, however, so that it can handle
># cases like
># >the one in test_main's -h handler.)
>#
># Flag handling, or at least feature enabling, should probably be done
># by core code. We should provide a set_feature() function
>
>Right now we have something like this:
>
> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL);
>
>I'm not sure how Parrot reacts to that if computed goto isn't available
>on this platform, though.
It should pitch a warning and then ignore the computed goto choice.
It's not a fatal error, after all.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
