* 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-checkedout the
* 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
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 =
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 they
=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
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 trying to
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
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.
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 interpreter
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
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
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 while
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 temp
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
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.
--
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
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 per
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 each
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
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 (so
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
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
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)
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, for the
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
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.
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
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) that are
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
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
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
-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
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 changed to
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,2,3) »+«
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
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
36 matches
Mail list logo