I accept that, and the note helps, but I just pulled the conditional
declarations out of the block and ran make headerizer again. It put
the
headers for the conditional functions back in the headerizer block.
Yeah, I understand. I don't have a solution yet. I'll ponder.
xoxo,
Andy
--
And
On Sunday 11 May 2008 18:43:57 Andy Lester wrote:
> The sections that the headerizer rewrites are not for human
> modification. Putting preprocessor directives between HEADERIZER
> BEGIN and HEADERIZER END is the same as modifying an auto-generated
> file. As the headerizer exists now, you
On Tuesday 06 May 2008 22:22:59 Geoffrey Broadwell wrote:
> The attached patch mainly cleans up the implementation of GLUT
> callbacks, simplifying code both internally and in the PIR-visible API.
>
> It also includes two other small cleanups in the OpenGL code:
> 1. a missing libglutcb build de
It's been about 5 days. Can someone please either:
1. Apply this patch,
2. Give me comments on what needs to change, or
3. Advise me that I should apply for a commitbit in order
to do my OpenGL work more efficiently?
Sorry if this is coming from a frustrated place. I am trying my best to
On May 11, 2008, at 9:08 PM, chromatic wrote:
Perhaps you missed the invisible tags I forgot to include.
I must have.
headerizer makes the silly double-declaration problem of C more
bearable.
Thank you for writing it.
You're welcome. I'm about to finish with a "DO NOT TOUCH" message.
On Sunday 11 May 2008 18:52:17 Andy Lester wrote:
> On May 11, 2008, at 8:48 PM, chromatic wrote:
> > I'm trying to decide which I hate more, headerizer, C, or #ifdefs
> > in .c files. Ah, who am I kidding? It's the latter.
> >
> > If you add a note to headerizer to this effect (or tell me "It'
On May 11, 2008, at 8:48 PM, chromatic wrote:
I'm trying to decide which I hate more, headerizer, C, or #ifdefs
in .c files.
Ah, who am I kidding? It's the latter.
If you add a note to headerizer to this effect (or tell me "It's
already
there, you dope!") I'll fix the .c files so this wo
On Sunday 11 May 2008 18:43:57 Andy Lester wrote:
> On May 11, 2008, at 4:09 PM, chromatic wrote:
> > headerizer should *not* delete preprocessor directives. What needs
> > changing so that it doesn't mangle this code in the future?
>
> A massive reworking of how headerizer handles header files,
On May 11, 2008, at 4:09 PM, chromatic wrote:
headerizer should *not* delete preprocessor directives. What needs
changing
so that it doesn't mangle this code in the future?
A massive reworking of how headerizer handles header files, because
what you expected here is not at all how the h
On May 11, 2008, at 4:07 PM, chromatic wrote:
Log:
putting back the struct on Parrot_Context for headerizer
I prefer that headerizer does the right thing, rather than
cluttering up
functional code. What goes kablooie in the headerizer here?
Actually, it's not headerizer, but the header
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #54000]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54000 >
The C, C, and C methods on
various capture-like objects are deprecated in favor of
On Saturday 10 May 2008 22:53:48 [EMAIL PROTECTED] wrote:
> Log:
> more headerizing, except for src/headers.c which needs Special Attention
> Modified: trunk/compilers/imcc/optimizer.c
> ===
>=== --- trunk/compilers/imcc/opti
On Saturday 10 May 2008 22:22:17 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/gc/register.c
>
> Log:
> putting back the struct on Parrot_Context for headerizer
I prefer that headerizer does the right thing, rather than cluttering up
functional code. What goes kablooie in the headerizer h
# New Ticket Created by NotFound
# Please include the string: [perl #53990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53990 >
Hello.
In recent revisions there are warning about unused static functions in
compilers/imc
On Mi. 02. Apr. 2008, 06:27:23, doughera wrote:
> This very minimal patch at leasts gives a brief warning about the
> issue.
>
> On a closely related topic, I thought about changing the default in
> this
> case to not build a shared libparrot, but dealing with the combination
> of
> undocumented
On May 10, 2008, at 7:38 PM, chromatic via RT wrote:
I tried this patch, and I'm getting warnings:
Generating runtime/parrot/include...Use of uninitialized value in hash
element at config/gen/parrot_include.pm line 105, <$fh> line 32.
Use of uninitialized value in pattern match (m//) at
config/g
On Fri, Feb 15, 2008 at 11:59 AM, via RT chromatic
<[EMAIL PROTECTED]> wrote:
> $ ./parrot -O t/compilers/imcc/syn/const_24.pir
> Null PMC access in get_string()
>
> $ ./parrot t/compilers/imcc/syn/const_24.pir
> Null PMC access in get_string()
> current instr.: 'main' pc 5 (t/compilers/imcc/syn/c
# New Ticket Created by Ivan B. Serezhkin
# Please include the string: [perl #53966]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53966 >
Hello.
.sub _ :main
load_bytecode 'Data/Dumper.pbc'
.local pmc Dumper, str
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #53978]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53978 >
19:13 <@pmichaud> so, set $PX[$PX], $PX is calling set_pmc_keyed even
when [$PX] is a
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #53954]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53954 >
Tried to build this morning using MSVC and the latest repo version.
svn update, make
20 matches
Mail list logo
