On Fri, May 02, 2008 at 02:16:01AM -0500, Patrick R. Michaud wrote:
> > When you try to invoke a sub that doesn't exist, Parrot currently gives the
> > unhelpful error message "Null PMC access in invoke()". Sometimes you can
> > figure out what's wrong given the backtrace. Often you can't.
> >
On Thu, May 01, 2008 at 11:40:43PM -0700, chromatic wrote:
> When you try to invoke a sub that doesn't exist, Parrot currently gives the
> unhelpful error message "Null PMC access in invoke()". Sometimes you can
> figure out what's wrong given the backtrace. Often you can't.
Just a quick note
On 4/12/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> -# If we are building shared, need to include dynamic
>> libparrot.lib, otherwise
>> +
>> +# If we are building shared, need to include dynamic
>> parrot.lib, otherwise
>> # the static libparrot.lib.
> this code secti
jerry gay wrote:
On 4/12/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
Attached is a proposed patch to change the libparrot names and locations
for Windows. I have tested the changes for "core" Parrot on Win32
Visual C++, Cygwin GCC, MinGW GCC and Ubuntu GCC.
this looks fabulous. thank you f
On 4/12/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
Attached is a proposed patch to change the libparrot names and locations
for Windows. I have tested the changes for "core" Parrot on Win32
Visual C++, Cygwin GCC, MinGW GCC and Ubuntu GCC.
this looks fabulous. thank you for providing your
Whups, sorry, I meant to say "OS X 10.3", with its gcc (3.3). I agree that
it seems to build fine on Tiger.
On 8/30/06, Will Coleda <[EMAIL PROTECTED]> wrote:
What version of OSX and gcc are you using? I haven't seen this
problem on 10.4.7 PPC with gcc 4.0.1.
Did it just break recently??
Not
What version of OSX and gcc are you using? I haven't seen this
problem on 10.4.7 PPC with gcc 4.0.1.
Did it just break recently??
Not that I see any problem applying this patch, regardless.
On Aug 30, 2006, at 4:55 PM, Mark J. Reed wrote:
Currently compilation fails on OS X with gcc/g++, bec
At 12:58 16/08/2006 -0700, jerry gay wrote:
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
w
On Thursday 17 August 2006 00:28, Francois PERRAD wrote:
> I try it on Win2000 with MinGW.
> 1) ExtUtils::PkgConfig is a wrapper over pkg-config, and pkg-config is not
> available on Windows
Okay, that's a problem. It's actually a big problem, for two reasons.
First, linking against libparrot r
At 15:48 15/08/2006 -0700, chromatic wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
I try it on Win2000 with MinGW.
1) ExtUtils::PkgCo
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
windows indeed complains. not only about miss
On 8/16/06, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 16 August 2006 08:57, jerry gay wrote:
> i'll happily test, but i can't apply it, as it seems not to be in the
> format my patch util expects. did you use C? i don't see the
> familiar "Index: " headers.
It's a standard svk diff. Th
On Wednesday 16 August 2006 08:57, jerry gay wrote:
> i'll happily test, but i can't apply it, as it seems not to be in the
> format my patch util expects. did you use C? i don't see the
> familiar "Index: " headers.
It's a standard svk diff. That's really weird. Is this any better?
-- c
--- M
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
i'll happily test, but i can't apply it, as i
On Tuesday 01 August 2006 02:52, Leopold Toetsch wrote:
> Two things come to my mind:
> 1) why is it creating 2 interpreters?
Per my experiments, this worked out the best. That is, if there's an error in
the compiled code, reusing an interpreter gave weird answers. I haven't
tracked this down
Am Dienstag, 1. August 2006 07:20 schrieb chromatic:
> Hi all,
>
> Here's a patch for discussion.
Two things come to my mind:
1) why is it creating 2 interpreters? What is the $parent used for?
And related: is $interp ever cleaned up by calling Parrot_exit()?
2) This looks a bit bogus (there
On Wed, Oct 19, 2005 at 09:59:15PM +0100, Nicholas Clark wrote:
> I think the better solution is going to be to keep them in src/extend.c,
> and auto-generate a second file for the vtable calls. So the version attached
> generates src/extend_vtable.c
I like that separation.
> chromatic:
> > I thi
On Mon, Oct 17, 2005 at 11:30:35AM -0700, chromatic wrote:
> Hi there,
>
> Here's a proposed patch (for review, not application) to generate
> src/extend.c from vtable.tbl. It has some limitations:
Problem is that src/extend.c has some functions that aren't vtable methods.
I think the better sol
On Mon, 2005-09-26 at 22:04 +0200, Leopold Toetsch wrote:
> >
> Well, besides a nitpick regarding:
>
> +=item C
> +
> + [ snipped ]
> +
> +sub vtbl_embed
>
> ... I'm fine with that patch.
Okay, I checked it in.
> But the ultimate word should speak actual
> users of Parrot extend/embed, an
On Sep 19, 2005, at 20:26, chromatic wrote:
Well, besides a nitpick regarding:
+=item C
+
+ [ snipped ]
+
+sub vtbl_embed
... I'm fine with that patch. But the ultimate word should speak actual
users of Parrot extend/embed, and of course, if it should be included
in the upcoming release
At 09:32 AM 11/7/2001 -0500, Andy Dougherty wrote:
>I think a generic platform.c with a few sprinkled #ifdef's is more
>appropriate. That's what the patch below does.
Applied. Thanks.
Dan
--"it's like this"
21 matches
Mail list logo
