# 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
# 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 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
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
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 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
# 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 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
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
# 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 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
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 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 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: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 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.
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 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
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
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
20 matches
Mail list logo
