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.
...
The
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.
It would be nice instead to get a more specific error message indicating that
you
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 here
This patch (not quite for application) builds on yesterday's free list
de-sucking patch. It sets the Hey, I'm free! flag on all objects on the
free list, then adds assertions to the PMC_IS_NULL() and saneify_string()
macros to make sure that neither use free PMCs.
Parrot's test suite passes
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.
Minor Changes
-
* libparrot_(static|shared) now contains the path to the library
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.
snip reasoning
this looks fabulous. thank you
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.
snip reasoning
this looks fabulous
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 section and this
Currently compilation fails on OS X with gcc/g++, because -bundle as the
first argument gets interpreted as a request to run the undle version of
the compiler. It works fine as a later argument, so there's no need to
break compatibility with the Apple compiler:
Index:
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++,
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
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
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
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
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
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 Cdiff -u? i don't see the
familiar Index: filename headers.
It's a standard svk diff. That's really weird. Is this any better?
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 Cdiff -u? i don't see the
familiar Index: filename headers.
It's a standard svk
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
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 don't have any particular attachment to any approach here, only that this
get
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 is
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
Hi all,
Here's a patch for discussion. It adds a new test module that uses a Parrot
embedded in Perl 5 to run pir_output_*() tests. It's a bit fragile and
depends on Embed::Parrot (which I haven't checked in yet). I'm just posting
it here to document that it exists and works in some cases,
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 think
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
Hi there,
Here's a proposed patch (for review, not application) to generate
src/extend.c from vtable.tbl. It has some limitations:
- I'm not sure if the Makefile magic is perfect
- it doesn't pick up all of the C types used in vtable.tbl
- it makes everything it understands in that file
On Mon, Oct 03, 2005 at 06:24:30PM -0700, chromatic wrote:
Nothing uses it yet; it's just there to test against in whatever
generates the file for embedders. Someone'll have to enable it
manually with some Makefile magic.
Would you like to propose such magic, at least a model?
(It's only a
On Mon, 2005-09-26 at 22:04 +0200, Leopold Toetsch wrote:
vtable_extend.patch
Well, besides a nitpick regarding:
+=item Cvtbl_extend($vtable)
+
+ [ snipped ]
+
+sub vtbl_embed
... I'm fine with that patch.
Okay, I checked it in.
But the ultimate word should speak actual
users
On Sep 19, 2005, at 20:26, chromatic wrote:
vtable_extend.patch
Well, besides a nitpick regarding:
+=item Cvtbl_extend($vtable)
+
+ [ 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
Hi all,
Here is a patch I promised Nicholas a while ago to generate
src/extends.c automatically. It's not complete and it's not perfect,
but it's a good first step that someone (including potentially myself)
can refine as we see where and how it fails.
-- c
Index: lib/Parrot/Vtable.pm
# New Ticket Created by chromatic
# Please include the string: [perl #29385]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29385
The attached patch allows you to fetch nested structs from their
enclosing structs.
Chromatic [EMAIL PROTECTED] wrote:
The attached patch allows you to fetch nested structs from their
enclosing structs.
Hehe, where's that I'm not a C programer? Great.
- it reuses the PMC from the struct initializer, so there's a
possibility of yanking the rug out from someone else
# New Ticket Created by chromatic
# Please include the string: [perl #28849]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28849
Hi there,
After playing with vim syntax highlighting for a few minutes, I hacked
Chromatic [EMAIL PROTECTED] wrote:
After playing with vim syntax highlighting for a few minutes, I hacked
up syntax highlighting for POD comments. This works on my box, but I'm
not quite sure it's portable. Are there any other vim hackers willing
to try it out?
Works great here.
It does
Chromatic [EMAIL PROTECTED] wrote:
After playing with vim syntax highlighting for a few minutes, I hacked
up syntax highlighting for POD comments.
Thanks, applied.
leo
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
I think the current platform/linux.[ch] files do more harm than good. They
may eventually be necessary, but nearly everything that's currently in
linux.[ch] also would belong in a hypothetical freebsd.[ch], openbsd.[ch],
netbsd.[ch], solaris.[ch], ncr.[ch], unixware.[ch], smes.[ch],
unisys.[ch],
36 matches
Mail list logo
