Cory Spencer [EMAIL PROTECTED] wrote:
I've been hard pressed to find any examples of proper exception-raising
with Parrot
t/pmc/exception.t
... has this
been at least semi-completed?
Yes.
leo
Andy Dougherty [EMAIL PROTECTED] wrote:
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and run the build there.
Thus they can create all the
Vladimir Lipsky [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
Sent: Monday, December 01, 2003 5:47 PM
Which child interpreter? Parrot_destroy_vtable() is called after
free_unused_pobjects().
Well you know test 61 in t/pmc/pmc.t causes a segfault.
Its pmc_62 labeled PMC
Leopold Toetsch [EMAIL PROTECTED] wrote:
OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables.
We are already constructing too much temporary key PMCs from a string
just to pass a string to an hash lookup. Object ops and functions do
this all over the place repeatedly.
And
On Dec 1, 2003, at 9:01 PM, Melvin Smith wrote:
At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote:
As outlined some time ago, when ops.num made it into the core, we
need fix assigned PMC class enums too. (Changed class enums
invalidate existing PBC files).
1) lib/Parrot/PMC.pm is the
At 2:05 AM +0300 12/2/03, Vladimir Lipsky wrote:
From: Dan Sugalski [EMAIL PROTECTED]
Sent: Monday, December 01, 2003 9:53 PM
*) I've made the Parrot_base_vtable array movable again, as it needs
to be resized. This is a temporary hack, since there are horrible
threading issues here. (Not to
At 8:10 PM -0700 12/1/03, Cory Spencer wrote:
However, if giving up IMCC's register allocator is worth gaining
the extra control of PASM, by all means do it, however I'm all ears
on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to allow
At 10:28 PM -0500 12/1/03, Melvin Smith wrote:
2) printf/sprintf - we do need it (and implemented in C) since it is
a staple and is the
reasonable hook for HLL implementors to do interpolation without having
to write a special native method or PMC for each language.
Okay, once I get the object
At 12:01 AM -0500 12/2/03, Melvin Smith wrote:
At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote:
As outlined some time ago, when ops.num made it into the core, we
need fix assigned PMC class enums too. (Changed class enums
invalidate existing PBC files).
1) lib/Parrot/PMC.pm is the canonical
At 1:52 AM +0300 12/2/03, Vladimir Lipsky wrote:
I'm done with it for now and I'm not the dan to say which way is the parrot
way to fix this bug
Well, bah. I'll disable the table freeing for now and that should
take care of the bug at the moment, though it certainly won't cure
the underlying
At 10:32 AM +0100 12/2/03, Leopold Toetsch wrote:
Andy Dougherty [EMAIL PROTECTED] wrote:
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and
At 12:14 PM +0100 12/2/03, Leopold Toetsch wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables.
We are already constructing too much temporary key PMCs from a string
just to pass a string to an hash lookup. Object ops and
Well, objects-ish, at least.
Single-inheritance objects seem to be done. The code can use a lot of
abuse and cleanup, and we need actual tests to make sure that it
functions as it should, but they're in.
Here's the technical scoop.
When you create a ParrotClass-based class (which is to say,
Leopold Toetsch [EMAIL PROTECTED] writes:
Andy Dougherty [EMAIL PROTECTED] wrote:
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and run
Bernhard Schmalhofer (via RT) [EMAIL PROTECTED] writes:
languages.in:
- add $(MAKE_C) befunge clean in target 'clean'
root.in:
- add target 'help': This should give a basic overview of what can be done
with the Makefile
- add target 'languages-clean': I needed that for testing
- add
I've been hard pressed to find any examples of proper exception-raising
with Parrot
t/pmc/exception.t
Excellent, thank you.
Now that objects at least limp along a bit (albeit in a crashy,
hackish way) it's time to look forward a bit.
The code definitely needs some looking at and cleanup. It's not
perfect and I expect it's flawed in a number of places. I'm just
happy to get the damn stuff into the repository so the
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #24584]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24584
This patch concers a few error messages generated in 'imclexer.c'.
When
On 02 Dec 2003 18:37:15 +0100, Juergen Boemmels
[EMAIL PROTECTED] wrote:
Pete Lomax [EMAIL PROTECTED] writes:
Command line used was:
$ perl -e open STDERR,'STDOUT'; exec qq{$^X Configure.pl --cc=gcc
--cgoto=0 --jitcapable=0 --verbose} conf.out
Output file is attached
[...]
Ok, I looked
In an effort to improve its error reporting ability and internal
maintainability,
I'm considering the following changes; well number (1) is already decided,
but I need feedback from compiler maintainers before doing so.
1) Currently typenames are not checked except with 'new classname'
At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote:
Single-inheritance objects seem to be done. The code can use a lot of
abuse and cleanup, and we need actual tests to make sure that it functions
as it should, but they're in.
Let me start the abuse.
*(cough)* examples would be nice ;)
Ok, abuse
At 10:09 PM -0500 12/2/03, Melvin Smith wrote:
At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote:
Single-inheritance objects seem to be done. The code can use a lot
of abuse and cleanup, and we need actual tests to make sure that it
functions as it should, but they're in.
Let me start the abuse.
On Dec-02, Melvin Smith wrote:
1) Currently typenames are not checked except with 'new classname'
I would vote for no aliases at all. I propagated the existing uses of
.local object in the Perl6 compiler and introduced several more
uses, but that was only because I wasn't sure at the time
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
On Dec-02, Melvin Smith wrote:
1) Currently typenames are not checked except with 'new classname'
I would vote for no aliases at all. I propagated the existing uses of
.local object in the Perl6 compiler and introduced several more
uses, but that
The Perl 6 summary for the week ending 20031130
Welcome back to the weekly Perl 6 Summary, which I'm hoping to keep on a
weekly cycle for the foreseeable future.
It's been a relatively low volume week this week, I'm assuming that
Thanksgiving had something to do with it (I hope
25 matches
Mail list logo
