Not quite:
ld: multiple definitions of symbol _PROXY_STRING
pyproxytype.o definition of _PROXY_STRING in section (__DATA,__common)
pyproxyclass.o definition of _PROXY_STRING in section (__DATA,__common)
Sam Ruby wrote:
cvsuser 04/12/13 19:12:07
Modified:dynclasses pyproxyclass.pmc pyproxy
# New Ticket Created by Will Coleda
# Please include the string: [perl #33036]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33036 >
Fresh cvs update, make realclean, configure, make:
c++ -L/usr/local/lib -flat_namesp
Thanks, (finally) applied.
FYI, I had to mangle one of the chunks by hand, but since this is from March,
I'm not
surprised.
> [bernhard - Tue Mar 02 14:02:42 2004]:
>
>
> The attached patch is another overhaul of debug.pod. The most notable change
> is that there
> is no 'imcc' binary any mor
Sending a copy of this message to the [EMAIL PROTECTED] list.
Hopefully someone there will have a clue about your question.
> [EMAIL PROTECTED] - Fri Nov 26 01:17:46 2004]:
>
> Hello, I am currently very dedicated into learning the Parrot
> programming language, and to do this, I have gathered f
At 3:31 PM +0100 12/14/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
Which does argue that it ought not be a sub, I suppose, but something
simpler. A plain bsr sort of thing.
A bsr doesn't change anything. It has to return
This no longer errors out, presumably due to the semi-recent changes regarding
.return()
> [EMAIL PROTECTED] - Mon Mar 22 01:18:45 2004]:
>
> -
> IMCC parser chokes on empty subs. Simple test case:
>
> .sub _main
> _foo()
>
At 8:48 AM -0500 12/14/04, Dan Sugalski wrote:
At 9:08 AM + 12/14/04, Leopold Toetsch via RT wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
IMCC's doing odd things when moving PMCs into the appropriate spot
when calling into functions with a large number of parameters. Here's
a snip from a t
here's a fun little app i cooked up yesterday -- an ASCII mandelbrot
browser written as a mod_parrot handler. it's pretty speedy (assuming
your connection isn't holding you back), and it's the first handler i've
written that parses form inputs.
for now, it's on my mod_parrot page at http://www.sm
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
> Which does argue that it ought not be a sub, I suppose, but something
> simpler. A plain bsr sort of thing.
A bsr doesn't change anything. It has to return to the caller. That
thing, where it's returnin
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi!
> I have found a problem with with mmd_dispatch_v_pnp.
> The function calls (for an Integer-PMC) Parrot_Integer_multiply_int, which
> expects an INTVAL, but a FLOATVAL is passed to it.
I can't reproduce that.
new P1, .Integer
set P1, 2
new P2, .U
Dan Sugalski (via RT) wrote:
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist t
At 9:08 AM + 12/14/04, Leopold Toetsch via RT wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
IMCC's doing odd things when moving PMCs into the appropriate spot
when calling into functions with a large number of parameters. Here's
a snip from a trace of one of the programs running. Note the l
Hi!
I have found a problem with with mmd_dispatch_v_pnp.
The function calls (for an Integer-PMC) Parrot_Integer_multiply_int, which
expects an INTVAL, but a FLOATVAL is passed to it.
jens
---
Breakpoint 1, mmd_dispatch_v_pnp (interpreter=0x8245048, left=0x8401328,
right=1, dest=0x8401328,
At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the relationship to the C opcode?
The one
Dan Sugalski (via RT) wrote:
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist t
chromatic wrote:
On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote:
A plain
./parrot foo.pbc
when foo.pbc doesn't exist triggers a core dump on OS X.
The problem is in embed.c not checking the results of
Parrot_locate_runtime_file(). Here's a naive patch.
[snip chromatic's fine patch, very
# New Ticket Created by Lambeck
# Please include the string: [perl #33029]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33029 >
I am missing some features for "make install". Right now there is no way to
make ONLY Par
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> subclass - To create a subclass of a class object
Is existing and used.
> add_parent - To add a parent to the class this is invoked on
> become_parent - Called on the class passed as a parameter to add_parent
What is the latter used for?
Sam's latest patch seems to have resolved this issue - dynclasses now build,
and:
perl t/harness t/dynclass/py*
skips 1 test, passes everything else.
Thanks.
Matthew Zimmerman <[EMAIL PROTECTED]> wrote:
> strlen() is puking on the NULL return from Parrot_locate_runtime_file()
> in Parrot_readbc. Attached patch fixes this behavior.
Thanks, applied.
leo
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33032]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33032 >
IMCC's doing odd things when moving PMCs into the appropriate spot
when calling into
Will Coleda via RT <[EMAIL PROTECTED]> wrote:
>> Loading platform and local hint files. Bad command or
Rerunning
perl Configure.pl --verbose=2
should reveal the failing program.
leo
On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote:
> A plain
>
> ./parrot foo.pbc
>
> when foo.pbc doesn't exist triggers a core dump on OS X.
The problem is in embed.c not checking the results of
Parrot_locate_runtime_file(). Here's a naive patch.
Is there a good place to put tests f
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33031 >
Currently parrot sets the current object for a method call *after*
calliing invoke o
Hey folks.
I'm really sorry that I've been missing of late -- been mugged by
work. (Which you might've figured, seeing the trickle of bug reports
:) I'm still a week or more behind in p6i mail, though if I'm lucky
I'll be able to mostly catch up in the next few days.
I don't think my time short
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... A scope exit
action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the r
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist triggers a core dump on OS
At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
Thinking more about that it seems that we don't have much chance to keep
the current scheme that the destination is passed in.
(This is probably out of order -- I've a lot of mail I'm backed up on
unfortunately, but since it was CC'd directly to me
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> The PerlHash is now an extension of Hash.
Great, thanks.
> The semantics should not have changed. For example, integer values are
> still stored as PerlInt PMCs in the Hash PMC.
I'd propose the following:
* instead of PerlInt an Integer PM
Hi,
I have responded to the ticket,
http://rt.perl.org/rt3/index.html?q=31859, but the response hasn't made
if to [EMAIL PROTECTED]
Is there a policy, which responses to RT tickets are posted to
[EMAIL PROTECTED] I know that it works fine for new tickets.
A patch for moving the implementation o
Justin DeVuyst <[EMAIL PROTECTED]> wrote:
> A few days ago I noticed that the vpm benchmark was failing. Then
> today, I saw that the majority of the OO benchmarks were failing.
Yeah. Fixed.
> I'd like to propose including testbench under fulltest so that the
> benchmarks can be more readily te
A few days ago I noticed that the vpm benchmark was failing. Then
today, I saw that the majority of the OO benchmarks were failing.
I'd like to propose including testbench under fulltest so that the
benchmarks can be more readily tested. Maybe that will help keep
the benchmarks from getting brok
32 matches
Mail list logo