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
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
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 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
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
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):
>
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
# 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:
# 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
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
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, 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
# 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
"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 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
"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
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
> --- 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
> 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};
> > traverse $tree{right} if $t
# 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
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 ;
--- 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
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
"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
--- 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
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
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
"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
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
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
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
--- 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
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
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.
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
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.
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 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 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
40 matches
Mail list logo
