Austin Hastings wrote:
role Dog {must bark();}
role Tree {must bark();}
class crossPerson {
method bark() {speak_sharply;}
}
class Trog does Tree does Dog {
method bark() {bark_like_a_trog;}
}
multi sub purchase(Dog $mansBestFriend) {...}
multi sub purchase(Tree $shrubbe
Austin Hastings wrote:
> Larry Wall wrote:
> > On the other hand, it's possible that we should extend the visual
> > metaphor of »« and apply it asymmetrically when one of the arguments
> > is expected to be scalar. That would mean that your last three lines
> > would be written:
> >
> > (1,
i think this is on topic. :)
uri
F*** THE NAZIS, SAYS CHURCHILL'S PARROT
Jan 19 2004
EXCLUSIVE
By Bill Borrows
SHE WAS at Winston Churchill's side during Britain's darkest hour. And
now Charlie the parrot is 104 years old...and still cursing the Nazis.
[Picture]
Her favourite sayings we
Joe Gottman wrote:
>About a month ago, a thread here suggested that we change the meaning
> of the comma operator. Currently, in scalar context the expression
> foo(), bar()
> means "evaluate foo(), discard the result, then return the value of
> bar()".
> It was suggested that this be chan
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On the other hand, it's possible that we should extend the visual metaphor
> of »« and apply it asymmetrically when one of the arguments is expected to
> be scalar. That would mean that your last three lines would be wr
Larry Wall wrote:
> Note that if we do take this approach, we'll have to require the space
> after = in
>
> @list = «a b c d e»;
Perl 6 has already set the precedent of the presence or absence of
whitespace being syntactically important (as opposed to Python, where the
amount and type of whi
20/01/2004 13:29:35, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
>On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED]
>wrote:
>
>> Is there any likelyhood that memory allocation will be hidden behind
>> macros at two levels:
>> - ALLOCPOOL() for allocating large chunks of memory (ppols) t
About a month ago, a thread here suggested that we change the meaning of
the comma operator. Currently, in scalar context the expression
foo(), bar()
means "evaluate foo(), discard the result, then return the value of bar()".
It was suggested that this be changed to return the 2-element arr
On Tuesday, January 20, 2004, at 07:56 , [EMAIL PROTECTED]
wrote:
I believe that parrot already has the concept of memory pools in it's
memory management. The idea is that by allocating similarly sized
objects from separate (large) allocations, you can reduce the
fragmentation of chunks and re
Thank you! You make some of my cheesy code a bit more respectable :)
--Josh
At 23:35 on 01/20/2004 +0100, Michael Scott <[EMAIL PROTECTED]> wrote:
> I've committed updates to the documentation in the Perl scripts in
> build_tools, classes and tools/dev.
>
> http://homepage.mac.com/mich
On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote:
: A thought occurred to me. What should this return:
:
: [1,2,3] »+« [4,5,6]
:
: At first glance, one might say [5,7,9]. But is that really the best
: way to go? I'm beginning to think that it should be the same as
: whatever [1,
Here are a few that can be closed; I'm sure this is far from a complete
list.
Simon
> 15357: Read & write ops in core.ops are broken
Close - the broken ops no longer exist.
> 16114: [PATCH] faster assembler
Close - we don't use assemble.pl any more.
> 17974: make clean removes lib/Parr
> Thanks for taking this on.
No problemo.
> > 22558: Another Hack at constant propogation
> Aplied or Fixed and then applied (I forget which)
>
> > 24847: [patch] simplify register stacks (remove code duplication)
> Reject (resubmitted late as a different patch which was applied)
Noted.
(FYI,
Robert~
Thanks for taking this on.
Matt
22558: Another Hack at constant propogation
Aplied or Fixed and then applied (I forget which)
24847: [patch] simplify register stacks (remove code duplication)
Reject (resubmitted late as a different patch which was applied)
Here are 177 currently outstanding parrot issues in the RT system.
You can see more detail on them by going to:
http://rt.perl.org/
clicking on guest access, and then typing the number into the upper
right hand corner box.
what we're mostly looking for are issues that can already be marked a
Mike~
I just recently added a file src/generic_register.c. I think that I
simply copied the CVS $Id from the file register.c which I used as a
template.
Matt
Michael Scott wrote:
I've committed updates to the documentation in the Perl scripts in
build_tools, classes and tools/dev.
http:
I've committed updates to the documentation in the Perl scripts in
build_tools, classes and tools/dev.
http://homepage.mac.com/michael_scott/Parrot/docs/html
All scripts now run with -w (turned up a harmless bug in
Parrot::Vtables, which I fixed).
CVS $Id and copyright notices were also added
> In the mean time, if anyone else has todo list items, send them
> (*ONE* per e-mail!) to bugs-parrot at bugs6.perl.org to get 'em in
> the queue and we'll start sorting them out from there. If we're lucky
> and have sufficient web luck we might even get 'em into a
> web-accessible TODO list (
At 2:17 PM +0100 1/11/04, Leopold Toetsch wrote:
> One further note, while at Array/PerlArray: the class dependency is
suboptimal. PerlArray isa Array isa list. The underlying list is
auto-extending and does no bounds checking. Array does bounds-checking.
PerlArray doesn't bounds check. So for
At 6:49 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote:
1) PMC initialization (new_p_ic_p): The shared PMC needs
additionally the allocation of the synchronize structure and the
MUTEX_INIT.
This is a one-time cost.
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> (Overall timings aren't really comparable, the SharedRef also does a
>> LOCK for mark, which slows that down as well)
> ?? Why'd you do that?
I didn't do it :) Pmc2c.pm is too dumb, it just puts a LOCK/UNLOCK pair
around eac
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote:
>>1) PMC initialization (new_p_ic_p): The shared PMC needs
>>additionally the allocation of the synchronize structure and the
>>MUTEX_INIT.
> This is a one-time cost. If a PMC has one, it should stick around
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:16 PM +0100 1/20/04, Leopold Toetsch wrote:
>>What about temporary PMCs (or strings)?
> Those won't get marked as shared unless we're unconditionally marking
> things as shared. (Though we may just give 'em a mutex anyway)
This needs either one check
At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote:
To estimate the costs of shared PMCs I have run this program[1],
once with .Ref and once with .SharedRef.
There are 2 major issues:
1) PMC initialization (new_p_ic_p): The shared PMC needs
additionally the allocation of the synchronize structure a
Leopold Toetsch wrote:
> (Overall timings aren't really comparable, the SharedRef also does a
> LOCK for mark, which slows that down as well)
?? Why'd you do that? Competetive threads MUST be suspended (most likely
with their cooperation, not with an OS suspend call) during the mark
phase.
--
To estimate the costs of shared PMCs I have run this program[1], once
with .Ref and once with .SharedRef.
There are 2 major issues:
1) PMC initialization (new_p_ic_p): The shared PMC needs additionally
the allocation of the synchronize structure and the MUTEX_INIT.
2) PMC access (set_p_i): locki
At 5:16 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
=item Interpreter pools will share allocation pools
All the interpreters in an interpreter pool will share header and
memory allocation pools.
What about temporary PMCs (or strings)?
Those won't get marked
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>=item Interpreter pools will share allocation pools
> All the interpreters in an interpreter pool will share header and
> memory allocation pools.
What about temporary PMCs (or strings)? Evaluating a non-trivial
expression can have lot of these. Each new
At 4:24 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
The term "process id" is really misleading.
Nope. It's the process ID. Nothing misleading there, unless you've
done threading work under linux, since for a w
At 16:24 +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
The term "process id" is really misleading.
Nope. It's the process ID. Nothing misleading there, unless you've
done threading work under linux, since for a whi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
>>The term "process id" is really misleading.
> Nope. It's the process ID. Nothing misleading there, unless you've
> done threading work under linux, since for a while it gave each
> thread a separate PID.
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
=item SHARED THREAD
A thread that's part of a group of threads sharing a common
interpreter environment.
I presume that this "group of threads" is one thread pool or
interpreter pool. Could you expand the d
On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED]
wrote:
Is there any likelyhood that memory allocation will be hidden behind
macros at two levels:
- ALLOCPOOL() for allocating large chunks of memory (ppols) that are
later sub-allocated (and managed) by:
- SUBALLOC() for sub alloca
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>=item SHARED THREAD
> A thread that's part of a group of threads sharing a common
> interpreter environment.
I presume that this "group of threads" is one thread pool or
interpreter pool. Could you expand the definition to cover "pool".
>=item Each inter
Steve Fink <[EMAIL PROTECTED]> wrote:
> Here's another obnoxious test case.
[ ... ]
> So, in case anyone is curious (hi leo!), attached is a 56KB (<9KB
> gzipped) imc file.
> It crashes on a memcpy inside compact_pool
Some remarks what I could find out:
- the damaged Buffer is in a pool of obje
The Perl 6 Summary for the week ending 20040118
I hope you'll forgive the lack of banter before we start in on
perl6-internals.
Threads. Again.
Still more proposals about threads this week. Jeff Clites offered some
notes based on the Java Virtual Machine's threading model. Surpri
Will Coleda <[EMAIL PROTECTED]> wrote:
> bash-2.05a$ make exit
> ../../../parrot ../tcl.pbc exit.tcl
> branch_cs: illegal resume offsetmake: *** [exit] Error 1
This is very likely an undefined label. imcc tries to find that at
runtime (it could have come out from eval) and fails.
> So, I'm tryin
> =item MUTEX
>
> This is a low level, under the hood, not exposed to users, thing that
> can be locked. They're non-recursive, non-read/write, exclusive
> things. When a thread gets a mutex, any other attempt to get that
> mutex will block until the owning thread releases the mutex. The
> platfor
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> =head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to another will always be received
in the order th
A thought occurred to me. What should this return:
[1,2,3] Â+Â [4,5,6]
At first glance, one might say [5,7,9]. But is that really the best
way to go? I'm beginning to think that it should be the same as
whatever [1,2,3]+[4,5,6] is, hopefully an error.
Here's my reasoning. Substitute $a =
* Andrew Dougherty ([EMAIL PROTECTED]) [040120 02:19]:
>
> Wordsize errors are one common type of error that show up on PPC
> (and SPARC) more readily than on x86, due to byte-order issues.
>
> When reporting problems, it's often a good idea to include the ./myconfig
> file in the parrot build di
* Harry ([EMAIL PROTECTED]) [040118 05:06]:
>
> --- Paul Cochrane <[EMAIL PROTECTED]> wrote:
> > Yeah, I don't think you're going crazy. The funny thing is that
> > about a three
> > weeks ago my cvs checkout worked fine. I did a cvs update, and then
> > Configure.pl didn't work[1], so I re-chec
42 matches
Mail list logo
