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
{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 yourself.
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
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/progs.pl to
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().
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().
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_vars).
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 the
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
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 needed
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
unacceptable.
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
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
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.
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
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
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
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 of the
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
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 true if the hash
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
[ 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.
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 bar
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 to a
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
# New Ticket Created by Adam Thomason
# Please include the string: [perl #24829]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24829
-Original Message-
From: Jeff Clites [mailto:[EMAIL PROTECTED]
Sent:
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 the
embedding
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, I've got a pretty big
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
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
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.
Just
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 Wall wrote:
On Sat,
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.bark(); #
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
- 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 Palmer [EMAIL
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 methods).
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 treeBark() {
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.
The
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
50 matches
Mail list logo
