G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
> Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a "major issue". I think of it as a constraint.
The ma
G'day all.
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> Welcome to my world. They're all bad ideas in some way or, rather,
> they're all equally as good.
That's definitely true. :-)
I should also point out that for Perl, all this is moot. Current Perl
semantics require tha
Piers Cawley
<[EMAIL PROTEC
> On Mon, 29 Apr 2002 18:58:18 -0400, Jeff <[EMAIL PROTECTED]> said:
J> Ilya Martynov wrote:
>>
>> Index: core.ops
>> [..snip..]
J> Applied, thanks.
I've just found other POD bugs in core.ops
Index: core.ops
===
RCS file: /cv
Ilya Martynov wrote:
>
> Index: core.ops
> ===
> RCS file: /cvs/public/parrot/core.ops,v
> retrieving revision 1.130
> diff -u -d -u -r1.130 core.ops
> --- core.ops24 Apr 2002 20:31:39 - 1.130
> +++ core.ops29 Apr 20
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
> >G'day all.
> >
> >On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> >
> >> We're going
>>OO code is full of subs which a) are called very often and b) look
>>like this:
>>
>> sub code
>> {
>> my $self = shift;
>> return $self->{CODE};
>> }
>>
>> sub body
>> {
>> my $self = shift;
>> if (@_) {
>> $self->{BODY} =
On Mon, Apr 29, 2002 at 09:42:46PM +0100, Piers Cawley wrote:
> Steve Fink <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> >> - Make an array of buffer data, in order of insertion into the hashtable.
> >> set pmc_pointer and buffer_ptr and let the
Steve Fink <[EMAIL PROTECTED]> writes:
> On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
>> - Make an array of buffer data, in order of insertion into the hashtable.
>> set pmc_pointer and buffer_ptr and let the GC rip through it.
>> - The hashtable itself just uses indices into thi
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> - Make an array of buffer data, in order of insertion into the hashtable.
> set pmc_pointer and buffer_ptr and let the GC rip through it.
> - The hashtable itself just uses indices into this array. Each
> linked-list node would be a P
On Mon, Apr 29, 2002 at 07:34:22PM +0100, Simon Cozens wrote:
> Steve Fink:
> > The assembler needs to be taught about the PMC constants:
>
> I disagree. Once you start adding assembler functions to make it easier
> for humans to use, you won't stop. I consider the assembler a tool for
> machine
Steve Fink:
> The assembler needs to be taught about the PMC constants:
I disagree. Once you start adding assembler functions to make it easier
for humans to use, you won't stop. I consider the assembler a tool for
machines to use. But if you want to do it, here's a patch.
--- newasm~ Mon A
> > > Btw, this is only a weak guess about what's going on, because the
> > > corruption I'm seeing isn't even in the linked list nodes. It only
> > > happens with GC_DEBUG, but it's not an infant mortality bug.
> >
> > GC_DEBUG adds extra calls to do_dod_run (infant mortality), and
> > do_collec
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> > I suspect the "bug" may be in my understanding of the memory
> > management API, though. If I want to maintain a linked-list of my own
> > objects, how do I do it? If I carve out my objects (hash buckets) from
> > a Buffer, then GC
> I suspect the "bug" may be in my understanding of the memory
> management API, though. If I want to maintain a linked-list of my own
> objects, how do I do it? If I carve out my objects (hash buckets) from
> a Buffer, then GC would keep moving them around and breaking the
> ->next link pointers.
On Sun, Apr 28, 2002 at 10:08:01PM -0400, Jeff wrote:
> And a long time coming...
>
> An assembler supporting keyed aggregates. Because of the current lack of
> macro support (that will be added in a few days), it's not built by
> default and isn't invoked in the test suite.
Yay! Thank you.
> S
Sounds like this stuff will collide violently with my local changes.
I'm trying to track down a nasty memory corruption bug. It sounds like
it would probably be easier to find with your new version, though.
The only real changes of interest I have so far are to finish the
implementation of new_tr
Dan Sugalski wrote:
> 1) Has the external interface changed, and are you planning on having
> it change?
So far, no. mem_allocate will shortly need to be told what pool to allocate
from; but I hope to remove this function from the external interface
entirely. Other than that, it should just be the
At 11:05 AM -0400 4/29/02, Melvin Smith wrote:
> >Just for chuckles, I went and benchmarked things, as meaningless
>>numbers are useful to have. With my current GCC3/-O3 build of parrot,
>>the cost to do 10,000,000 sets of saves is as follows:
>>
>>save all: 5.3 sec usertime
>>save 1: 2.6 sec
I just started playing with Parrot assembly and it looks like I have
found a bug with entrytype OP.
This test case causes segfault:
save I1
entrytype I2, 0
Another test case
save I1
entrytype I2, -1
This one causes 'Stack Depth wrong' error instead of getting
At 4:44 PM +0200 4/29/02, Peter Gibbs wrote:
>
>Herewith the first set of patches to the memory allocation routines.
>
>There is no new functionality here yet; basically I have been working on
>trying to remove some of the code that is duplicated between the various
>pools, before even more copies
Dan Sugalski
<[EMAIL PROTEC
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
>
>> We're going caller-save. I think I made this declaration before, but
>> now it's backed up with pure PDD goodness. :)
>
>The first thing to realise is that this vi
Herewith the first set of patches to the memory allocation routines.
There is no new functionality here yet; basically I have been working on
trying to remove some of the code that is duplicated between the various
pools, before even more copies get made for the new stuff.
The result is some fai
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.130
diff -u -d -u -r1.130 core.ops
--- core.ops24 Apr 2002 20:31:39 - 1.130
+++ core.ops29 Apr 2002 14:00:28 -
@@ -2823,7 +2823,7
Hi, again!
Sorry but I didn't have the time to read all I should about parrot, but
this question can be usefull to know if I should continue looking at it,
or not... is parrot ready (or will be, soon) to use external libraries?
And another simple... can parrot be used as a filter? assembler x.p
G'day all.
On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will already have been saved. If the callee saves then it's
> going to be d
> > Actually, I _was_ saying we shouldn't do caller-save (except
> > possibly for a small number of registers designated for the
> > purpose).
>
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will
So, I was thinking about how symbol tables are going to work, and I
remembered that Dan had said that he wanted hashes to preserve their
insertion order on print out.
Which led me to think that it'd be really nice if there was some way
of addressing hashes with integers to get the 'nth thing'
ins
Andrew J Bromage <[EMAIL PROTECTED]> writes:
> G'day all.
>
> On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
>
>> I don't think I and Andrew were saying we shouldn't do caller-save,
>> we were just discussing that the calling convention (read
>> activation record of a subroutine) s
30 matches
Mail list logo
