On Jan 5, 2004, at 9:37 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Jan 5, 2004, at 5:32 AM, Leopold Toetsch wrote:
The return value is only returned, when I3 != 0. For your example
that
shouldn't be the case (I3 is unused aka zero). So there isn't any
return
value pass
{This is a re-send of my submission [perl #24789] from 12/31, which has
not been forwarded from RT. I wanted to keep this separate from my
subsequent [perl #24808] in order to preserve the change history.}
Attached is a patch which fixes most of the "make testj" failures on
Mac OS X (ie, ppc
Uri Guttman wrote:
> i say we just sell them a license to use the US constitution.
Bill Gates wrote:
> What is it with these Linux guys?
> i say we just sell them a license to use Windoze.
:-)
A
David Storrs writes:
>
> On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
> > On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote:
>
> > : For one, one role's methods don't silently override another's. Instead,
> > : you get, er, role conflict and you have to disambiguate your
All~
I just got a brand new checkout tonite and have the following problem:
$ perl Configure.pl
Parrot Version 0.0.13 Configure 2.0
Copyright (C) 2001-2003 The Perl Foundation. All Rights Reserved.
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot.
Matt Fowles <[EMAIL PROTECTED]> writes:
> $ cat test.ldo
> /usr/bin/ld: cannot find -lgdbm_compat
> collect2: ld returned 1 exit status
>
>
> Hope someone know more about this gdbm_compat thing then I do...
>
> I am running a relatively stock Debian testing box.
Changing line 27 of config/inter/pr
On Sunday, January 4, 2004, at 03:17 , Jeff Clites wrote:
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
C
On Sunday, January 4, 2004, at 01:43 , Dan Sugalski wrote:
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Com
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Looks like we've a bug in the DOD tracing. As far as I can tell (and
> it's somewhat tough, as my program's rather large) there's a bug
> where metadata on loadlib-loaded libraries doesn't get properly
> marked as live.
Yep. Good catch. The library PMC was
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Optimized for speed, at least.
> I'm finding that large subs seem to give imcc headaches. I'm not sure
> if it's O(n^2) or O(2^n) headaches, but definitely issues.
Live analysis and register allocation are the main problems. The former
is O(n_lines * n_va
Looks like when I run parrot -v, the statistics report on each sub, but
it calls all the subs the same thing, in particular, the last sub
compiled.
Luke
Aren't continuations supposed to close over the register stacks? In
this code:
.sub _main
I17 = 42
savetop
newsub P0, .Continuation, second
restoretop
invoke P0
second:
restoretop
print I17
print "\n"
end
.end
I
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
I should hope to get 42, but instead I get "no more I frames to pop."
They're not very good continuations if you have to treat them just like
an address stack!
Currently th
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> Hello,
> this patch
> * renames Parrot_INTERP and Parrot_STRING to Parrot_Interp and Parrot_String,
> which matches the rest of Parrot types, as well as the embedding interface
AFAIK are the types in extend.c opaque types which are different to the
i
Adam Thomason <[EMAIL PROTECTED]> wrote:
> A pedantic fix courtesy of VisualAge:
> src/events.c attempts to call peek_entry(), which is defined in
> src/tsq.c. Currently, peek_entry is declared and defined as
> PARROT_INLINE,
Thsnks, applied
leo
Lars Balker Rasmussen <[EMAIL PROTECTED]> wrote:
> I've rewritten list.t and hash.t to use this scheme, generalizing the
> layout a bit in the process.
Thanks, applied.
> I'm not sure about the reasoning for one
> of the interpreter setups in the old hash.t (marked with XXX), and
> whether it's
At 12:30 PM +0100 1/6/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure
if it's O(n^2) or O(2^n) headaches, but definitely issues.
Live analysis and register allocation are the
Gordon Henriksen wrote:
> Dan Sugalski wrote:
> >
> > An interpreter *must* lock any shared data structure,
> > including PMCs, when accessing them. Otherwise they may
> > be in an inconsistent state when being accessed, which will
> > lead to data corruption or process crashing, which is
> > una
Melvin Smith wrote:
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
Currently the Copy-On-Write bit isn't being honored on the register pad
stacks,
No. Register backing stacks are no more in the interpreter context an
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I tracked down how I3 was getting set, even though from the pasm it
> looks like nothing should be changing it. It turns out to be a side
> effect of the use of NCI in the threading implementation; the problem
> wasn't showing up for you since you have CAN_B
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is right.
$foo = \$hash{key};
$$foo = "bar";
$has{key} is now "bar"
I don't see how the current vtable setup will allow for this in a tied
situation, or will
Dan Sugalski wrote:
Oh, yeah, lots of spilling. In a hacked up version of the PIR I see 50
spills in the main routine.
Brrr. It would definitely help, if you can use lexicals or gloabals, so
that you don't have that much long-ranged variables - and of course
splitting the beast if possible.
l
Jeff Clites <[EMAIL PROTECTED]> wrote:
> {This is a re-send of my submission [perl #24789] from 12/31, which has
> not been forwarded from RT. I wanted to keep this separate from my
> subsequent [perl #24808] in order to preserve the change history.}
Thanks, applied.
leo
Arthur Bergman:
> I am wondering how the references to hash elements are planned to be
> done? The call to set_ must somehow be delayed until the time is right.
I would have thought that a hash element would itself be a PMC rather
than an immediate value, so a reference to that should be treated
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> Hi,
> I am wondering how the references to hash elements are planned to be
> done? The call to set_ must somehow be delayed until the time is right.
> $foo = \$hash{key};
> $$foo = "bar";
> $has{key} is now "bar"
There was some discussion WRT that is
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Attached are patches to fix the remaining "make testj" failures on Mac
> OS X (i.e., ppc jit). These fixes are relative to my previously
> submitted patch with other ppc jit fixes, [perl #24789].
Thanks, applied,
leo
For those of you who like perusing gobs of autogenerated info, take a
look at
http://homepage.mac.com/michael_scott/Parrot/pod_report.html
where I've put up a list of Parrot POD errors as seen by podchecker.
I've started to put together a bunch Perl modules which will allow us
autogenerate HT
Pragmatic nonblocking synchronization for real-time systems
USENIX '01: http://os.inf.tu-dresden.de/~hohmuth/prj/usenix2001.html
Phd Thesis: http://os.inf.tu-dresden.de/~hohmuth/prj/phd.pdf
Summary: pragmatic methodology for developing systems using nonblocking
synchronization with following prope
On Jan 6, 2004, at 9:05 AM, Simon Cozens wrote:
Arthur Bergman:
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
I would have thought that a hash element would itself be a PMC rather
than an immediate valu
Jeff Clites:
> But there's a semantic difference between a "reference to a hash
> element" and a "reference to something which happens to have come out
> of a hash".
True, but irrelevant. :)
> $a = $hash{bar};
Here you used the copy constructor before taking the reference. It might look
like a
Simon Cozens writes:
> > $a = $hash{bar};
>
> Here you used the copy constructor before taking the reference. It might look
> like an assignment operator, but it isn't. You're better off thinking that
> assignment doesn't exist. It's a copy constructor. It makes the PMC referred
> to by $a a copy
On 6 Jan 2004, at 17:05, Simon Cozens wrote:
I would have thought that a hash element would itself be a PMC rather
than an immediate value, so a reference to that should be treated just
like any other reference to a PMC.
But this does not hold true if the hash element is in fact conjured up
by
Arthur Bergman writes:
>
> On 6 Jan 2004, at 17:05, Simon Cozens wrote:
>
> >
> >I would have thought that a hash element would itself be a PMC rather
> >than an immediate value, so a reference to that should be treated just
> >like any other reference to a PMC.
> >
>
> But this does not hold tru
At 4:53 PM + 1/6/04, Arthur Bergman wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
Nope, actually they don't have to be. Simon was correct here.
Accessing an element of an aggregate retu
[ apologies for the duplicate email message from my last post--mail
client problems... ]
On Jan 6, 2004, at 11:50 AM, Simon Cozens wrote:
Jeff Clites:
$a = $hash{bar};
Here you used the copy constructor before taking the reference. It
might look
like an assignment operator, but it isn't. You're
On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote:
Arthur Bergman <[EMAIL PROTECTED]> wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
$foo = \$hash{key};
$$foo = "bar";
$has{key} is now "ba
Jeff Clites:
> But here what I'm copying is the _contents_ of the hash slot.
True, but irrelevant. :)
> And here I'm not making a copy, but also the thing I'm taking a
> reference to is not the same thing I copied above. Here, it's a
> reference to a hash slot.
No, it isn't. It's a reference t
On Jan 6, 2004, at 1:31 PM, Simon Cozens wrote:
Jeff Clites:
But here what I'm copying is the _contents_ of the hash slot.
True, but irrelevant. :)
And here I'm not making a copy, but also the thing I'm taking a
reference to is not the same thing I copied above. Here, it's a
reference to a hash s
There's a rule of thumb that goes along the lines of "bugs lurk where
many changes are made to the source code", because it's a sign of "we're
just not getting this area right."
Has anyone tried to use checkin/diff info to find areas to focus on for
testing? Anyone tied it to a coverage tool?
On Wed, 07 Jan 2004 08:12, Garrett Goebel wrote;
> It currently runs on arm, ia32, ia64, and the Linux system-call
> interface. A microkernel running atop an OS' system-call
> interface, is perhaps not so dissimilar from a common language
> interpreter like parrot that these papers may hop
# New Ticket Created by Adam Thomason
# Please include the string: [perl #24829]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24829 >
> -Original Message-
> From: Jeff Clites [mailto:[EMAIL PROTECTED]
> Sent: Wedn
Il Tue, 6 Jan 2004 16:43:42 +0100 Leopold Toetsch <[EMAIL PROTECTED]> ha scritto:
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
> > Hello,
> > this patch
>
> > * renames Parrot_INTERP and Parrot_STRING to Parrot_Interp and
> Parrot_String,
> > which matches the rest of Parrot types, as well as t
Leopold Toetsch writes:
> Melvin Smith wrote:
>
> >At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
> >
> >>Aren't continuations supposed to close over the register stacks? In
> >>this code:
> >
> >Currently the Copy-On-Write bit isn't being honored on the register pad
> >stacks,
>
> No. Register
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
Leopold Toetsch writes:
Good. Pass it over to me :) COW copy of stacks and of other
buffer-based
items is still broken. These need distinct headers so that they work
like COWed strings.
Alright, I've got a pretty big incomplete patch here (see, when
Jeff Clites writes:
> On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
>
> >Leopold Toetsch writes:
> >>
> >>Good. Pass it over to me :) COW copy of stacks and of other
> >>buffer-based
> >>items is still broken. These need distinct headers so that they work
> >>like COWed strings.
> >
> >Alright,
At 04:41 PM 1/6/2004 -0700, Luke Palmer wrote:
I want these things to be garbage collected, but DOD doesn't trace the
buffer. I can't seem to find a way to mark the frames without making
the chunks into PMCs (yuck). Is there a way to do this?
I was about to answer your question when I saw your f
On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:
Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
To do that properly, I think you need a pobj_t as the
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Austin Hastings) writes:
>PS: While I'm somewhat sympathetic to the fact that eu guys are trying to
>spin up 200 years worth of amendments and supreme court decisions at the
>same time, it's still a ratf*ck. Eu need to get eurselves a Larry.
Jus
- Original Message -
From: "Luke Palmer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 06, 2004 4:51 AM
Subject: [perl] Re: Roles and Mix-ins?
> David Storrs writes:
> >
> > On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
> > > On Sat, Dec 13, 2003 at 04
Joe Gottman writes:
>
> - Original Message -
> From: "Luke Palmer" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 06, 2004 4:51 AM
> Subject: [perl] Re: Roles and Mix-ins?
>
>
> > David Storrs writes:
> > >
> > > On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wa
Joe Gottman wrote:
>How about something like
> class Trog
>does Dog {bark=>dogBark} does Tree {bark=>treeBark}
>{...}
>
> Then we could have code like
> my Trog $foo = Trog.new();
> my Dog $spot := $foo;
> my Tree $willow := $foo;
> $spot.ba
Luke Palmer wrote:
> Renaming methods defeats the purpose of roles. Roles are like
> interfaces inside-out. They guarantee a set of methods -- an interface
> -- except they provide the implementation to (in terms of other,
> required methods). Renaming the method destroys the interface
> compati
- Original Message -
From: "Luke Palmer" <[EMAIL PROTECTED]>
To: "Joe Gottman" <[EMAIL PROTECTED]>
Cc: "Perl6" <[EMAIL PROTECTED]>
Sent: Tuesday, January 06, 2004 9:34 PM
Subject: [perl] Re: Roles and Mix-ins?
> Joe Gottman writes:
> >
> > - Original Message -
> > From: "Luke P
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> Luke Palmer wrote:
> > Renaming methods defeats the purpose of roles. Roles are like
> > interfaces inside-out. They guarantee a set of methods -- an interface
> > -- except they provide the implementation to (in terms of other,
> > required metho
Joe Gottman wrote:
> Luke Palmer wrote:
> > Your renaming can be done easily enough, and more clearly (IMO) with:
> >
> > class Trog
> > does Dog does Tree {
> > method bark() { ... } # Explicitly remove the provided method
> > method dogBark() { .Dog::bark() }
> > method
Austin Hastings wrote:
> There's two ways to look at that. One way is to say: "I'm going to
> define an interface as being this OTHER thing minus a method." That
> seems like a positive construction, and supporting it might be
> desirable.
>
> The other way is to say: "Nobody knows what methods
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> Austin Hastings wrote:
> > There's two ways to look at that. One way is to say: "I'm going to
> > define an interface as being this OTHER thing minus a method." That
> > seems like a positive construction, and supporting it might be
> > desirable.
>
Larry, chromatic, Allison, Damian, et al:
What's the big fascination with traits?
I read the paper, and at the end where they talked about refactoring the
Smalltalk class library, they managed to claim 12% fewer lines of code:
> In total, these classes use 46 different traits and implement 509
On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
> So on the grand balance of utility, what are the metrics that traits are
> supposed to help improve?
Two big ones:
- naming collections of behavior that are too fine-grained to fit into
classes cleanly
- enabling finer-grained
59 matches
Mail list logo
