On 8/6/07, chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 06 August 2007 20:43:23 Mark Glines wrote:
>
> > Shouldn't that be a typedef? In other words:
> >
> > typedef enum {...} HLL_enum_t;
> >
> >
> > I think that'll fix Coke's build failure.
>
> Probably. I just hoisted it out of src/hll.c i
On Monday 06 August 2007 20:43:23 Mark Glines wrote:
> Shouldn't that be a typedef? In other words:
>
> typedef enum {...} HLL_enum_t;
>
>
> I think that'll fix Coke's build failure.
Probably. I just hoisted it out of src/hll.c into include/parrot/hll.h
verbatim.
-- c
On Sun, 5 Aug 2007 23:44:16 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> +enum {
> +e_HLL_name,
> +e_HLL_lib,
> +e_HLL_typemap,
> +e_HLL_MAX
> +} HLL_enum_t;
> +
Shouldn't that be a typedef? In other words:
typedef enum {...} HLL_enum_t;
I think that'll fix Coke's build failur
I tried this patch on OSX/Intel, build failed with a ton of errors,
similar to and ending with:
compilers/imcc/parser_util.o private external definition of
_HLL_enum_t in section (__DATA,__common)
compilers/imcc/pcc.o private external definition of _HLL_enum_t in
section (__DATA,__common)
On Sunday 05 August 2007 21:59:11 chromatic wrote:
> Actually, use this patch instead.
Unless you like bugs, use THIS patch. I mean it.
-- c
=== include/parrot/hll.h
==
--- include/parrot/hll.h (revision 5224)
+++ include/parrot/h
On Sunday 05 August 2007 21:57:05 chromatic wrote:
> Here's a patch which cleans up the issue somewhat, but doesn't fix up the
> typemaps.
Actually, use this patch instead.
-- c
=== src/pmc/parrotinterpreter.pmc
==
--- src/pmc/parr
I spent more time tracking down the segfaults in Tcl (specifically the one
with an invalid string passed to string_equals()). The problem appears to be
in thawing bytecode, specifically in the ParrotInterpreter PMC and its
thawfinish().
The code there attempts to reconstruct specific bytecode
