On Wed, May 28, 2003 at 06:35:31AM -0700, David Storrs wrote:
> On Wed, May 28, 2003 at 04:41:36AM -0600, Luke Palmer wrote:
> > I know it's compile-time binding, but... what's compile-time binding?
> > Luke
>
> Well, perhaps I'm mistaken, but I had understood it to mean simply
> [...]
>
> - Name
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
> > If we could think about "threads" not in terms of forkyness, but
> simply
> > in terms of coroutines that can be called in parallel, it should be
>
> > possible to create an implem
On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> On a single-CPU box, the OS level threads could easily be used to
> support blocking operations feeding back to async I/O, while all "real
> work" (execution of opcodes) was done in a single thread. Parrot could
> elect to implement
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> > On a single-CPU box, the OS level threads could easily be used to
> > support blocking operations feeding back to async I/O, while all
> "real
> > work" (execution of opcodes) was do
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > If we could think about "threads" not in terms of forkyness, but simply
> > in terms of coroutines that can be called in parallel, it should be
> > possible to create an implementation of "threading" that had to
On Tuesday, May 27, 2003, at 07:32 PM, Jonathan Scott Duff wrote:
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
If we could think about "threads" not in terms of forkyness, but
simply
in terms of coroutines that can be called in parallel, it should be
possible to create an imple
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> How, then, would you design an interface around (Concept 1) -- the
> listener/eventloop/subprocess model? Pseudocode for a top-level
> event
> loop might be something like:
>
> loop {
> sleep($fraction), next
>unless
"Austin Hastings" <[EMAIL PROTECTED]> wrote:
> 1. C always acts the same way -- stores args in CurThread.result
> and gives up control to [?something?].
I think you want a fifo on the output there -- at least conceptually.
"Stores args in .result" might overly block the producer thread.
"gives up
You may evaluate for yourself whether thse comments are actually worth
two cents, but:
I want to be able to tell whether my program is threading or using some
other useful-but-not-what-I'd-do-in-a-hurry tool.
I don't want to learn a thousand different details that are only there
to make sure I k
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > 1. C always acts the same way -- stores args in
> CurThread.result
> > and gives up control to [?something?].
>
> I think you want a fifo on the output there -- at least conceptually.
> "Stores args in .r
On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
Exampling:
sub traverse(Hash $tree) {
return unless $tree;
traverse $tree{left} if $tree{left};
yield $tree{node};
traverse $tree{right} if $tree{right};
}
my %hash is Tree;
my &cotrav := coro &traverse(%hash);
print $_ for ;
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
> > Exampling:
> >
> > sub traverse(Hash $tree) {
> > return unless $tree;
> >
> > traverse $tree{left} if $tree{left};
> > yield $tree{node};
> > traverse $tree{right} if $t
> But, as Luke pointed out, some of the other syntax required to make
> that work is isn't particularly friendly:
>
> coro pre_traverse(%data) {
> yield %data{ value };
> yield $_ for <&_.clone(%data{ left })>;
> yield $_ for <&_.clone(%data{ right })>;
> }
>
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >
> > On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
> > > Exampling:
> > >
> > > sub traverse(Hash $tree) {
> > > return unless $tree;
> > >
> > > traverse $tree{left} if $tree{left};
> > > yield $tree{node};
> > > traver
"Austin Hastings" <[EMAIL PROTECTED]> wrote
> --- Dave Whipp <[EMAIL PROTECTED]> wrote:
> > "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > > 1. C always acts the same way -- stores args in
> > CurThread.result
> > > and gives up control to [?something?].
> >
> > I think you want a fifo on the out
On Wednesday, May 28, 2003, at 02:56 PM, Austin Hastings wrote:
(s/coroutine/thread/g for the same rough arguments, e.g. "why should
the caller care if what they're doing invokes parallelization, so
long as it does the right thing?")
Global variables. Threads __never__ do the right thing.
Heh. Tha
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in
> for {...}
>
> It doesn't matter whether foo() is a closure or function returning a
> list, lazy list, or iterator, or is a coroutine returning it's .next
> value. Which is excellent, and, I'd argue, the whole point; I'm not
> sure that we can
On Tuesday 27 May 2003 21:25, Bill Atkins wrote:
> Am I correct in assuming that Parrot's JIT will eventually be able to
> produce directly-executable files, like .exe's?
Yes, you are.
>
> Bill
Daniel.
At 05:45 PM 5/27/2003 -0400, you wrote:
On Tue, 2003-05-27 at 08:01, Clinton A. Pierce wrote:
> At 11:57 PM 5/26/2003 -0400, Will Coleda wrote:
> >Perhaps "macros only work in assembler mode" is the issue?
> >
> >http://www.mail-archive.com/[EMAIL PROTECTED]/msg14107.html
> >
> >Regards.
>
> It was
At 11:13 AM 5/28/2003 -0400, Clinton A. Pierce wrote:
# These are vastly simplified, but give you the idea
And of course, by "vastly simplified" I meant "completely wrong" because
the sample shown won't work because of the saveall and restoreall before
and after the array creation in _DIMENSION.
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>>>... . We need some tests, from which size memory is
>>>cleard for malloc and memalign.
Here is a small program, which could be put into a test.
Are there systems out there, without memalign, where malloc.c can not be
linked with?
/*
* test clean me
Leopold Toetsch wrote:
> Mitchell N Charity <[EMAIL PROTECTED]> wrote:
>
> > Perhaps it is time to get "multiple gc regimes can coexist" working?
>
> Sounds good, but AFAIK doesn't work - or isn't practical. I can only
> imagine to have some #defines in place, to switch/test different
> schemes, as
Very possibly old and useless but in the grand tradition of piping up
with ideas which may or may not be useful -
http://home.pipeline.com/~hbaker1/CheneyMTA.html
being a paper on filling the C stack completely thus saving on some GC
amongst other things.
The paper explains it much better.
Si
Clinton A. Pierce <[EMAIL PROTECTED]> wrote:
> And actually, on further consideration, .const isn't what I want
> either.
You are looking vor .sym/.local:
.local PerlHash BASICARR
.sub _main
BASICARR = new PerlHash
.arg "value"
.arg "x"
call _DIMENSION
.ar
Daniel Grunblatt <[EMAIL PROTECTED]> wrote:
> On Tuesday 27 May 2003 21:25, Bill Atkins wrote:
>> Am I correct in assuming that Parrot's JIT will eventually be able to
>> produce directly-executable files, like .exe's?
> Yes, you are.
Anything, what I might have missed? JIT 2?
> Daniel.
leo
# New Ticket Created by Luke Palmer
# Please include the string: [perl #22352]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22352 >
I've been trying to run pbc2c.pl, and it's been dying. I traced the
problem down to Parr
Luke Palmer <[EMAIL PROTECTED]> wrote:
> I've been trying to run pbc2c.pl, and it's been dying. I traced the
> problem down to Parrot::Packfile thinking that the size of the
> bytecode segment is zero. However, it works fine when I use
> assemble.pl to compile; the problem only arises when I com
# New Ticket Created by Luke Palmer
# Please include the string: [perl #22353]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22353 >
It appears JIT is entirely broken. It broke recently, as it was
working well for me just
On Wed, 28 May 2003, Luke Palmer wrote:
> I get segfaults with both imcc -Oj and parrot -j (with assemble.pl) on
> mandel.pasm and a bunch of others.
I've noticed a number of these as well (linuxppc, gcc3.3), but then again
I've been tweaking my copy of the JIT. I get these failures:
Failed Tes
On Wed, 2003-05-28 at 19:03, Leopold Toetsch wrote:
> Our current problem is, that we have two assemblers and two PBC formats.
> Keeping all in sync till now ends obviously at test level.
The perl assembler was never intended to be the permanent solution.
Rather, in typical Perl fashion, to get s
On Wed, 2003-05-28 at 11:13, Clinton A. Pierce wrote:
> >
> >Is there is reason not to s/\.constant/.const/g for consistency's sake?
>
> And actually, on further consideration, .const isn't what I want
> either.
Which doesn't invalidate my question. :-)
--
Bryan C. Warnock
bwarnock@(gtemail
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [perl #22359]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22359 >
The IMCC optimizer run with these options:
..\..\imcc\imcc -Op1 -d60 err
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [perl #22360]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22360 >
(Low priority, more an annoyance than anything.)
When the message of the form:
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It appears JIT is entirely broken. It broke recently, as it was
> working well for me just a couple days ago.
> I'm running i686 (P3) Linux, gcc-3.2.2
> I get segfaults with both imcc -Oj and parrot -j (with assemble.pl) on
> mandel.pasm and a bunch of o
Clinton A. Pierce <[EMAIL PROTECTED]> wrote:
> ..\..\imcc\imcc -Op1 -d60 err.imc
Please note: -Op does optimize PASM code, that wouldn't get optimized
else. For .imc files just using -O1 suffices.
> Bug #1:
> Issues the error message (now a warning, but probably a problem nontheless):
>
Appended is a refined version of #22337 which it obsoletes.
Key features are:
1) DOD flags (live, on_free_list, ...) are kept in the arenas, 1 nibble
per object
2) arena memory is aquired per memalign() to be able to calculate arena
from object address
3) free_list is per arena now
4) PMC size i
At 5:43 PM +0200 5/28/03, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
... . We need some tests, from which size memory is
cleard for malloc and memalign.
Here is a small program, which could be put into a test.
Are there systems out there, without memalign, where malloc.c ca
At 9:31 PM -0700 5/27/03, Randal L. Schwartz wrote:
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
Dan> Now, this book is on a tight schedule and, as such, went through a
Dan> small tech edit phase. The more people you have the longer it takes,
Dan> and this was moving reasonably quickly
At 11:00 PM +0200 5/27/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 8:03 PM +0200 5/27/03, Leopold Toetsch wrote:
... . We need some tests, from which size memory is
cleard for malloc and memalign.
I tossed the memset for now and saved ~450.000 L2-misses or ~0.2 s.
Whi
I found this online: http://unixhelp.ed.ac.uk/CGI/man-cgi?posix_memalign.
Note in particular, "For all three routines, the memory is not zeroed."
Regarding the lack of "man memalign," have you tried texinfo instead?
(There isn't a linux machine handy right now so I can't check myself.)
--Andy
40 matches
Mail list logo
