Jason Switzer wrote:
On Thu, May 13, 2010 at 3:59 AM, wrote:
And at the core of that, is the need for preemptive (kernel) threading and
shared memory.
These can (and should!) be hidden from the application programmer, through
the use of language and/or library
level abstractions, of which th
Ruud (>):
> (Do Perl_6 hyper-operators need pthreads?)
No. The ability to thread over list elements in a hyper operator is
more of a possibility than a requirement, if I understand things
correctly.
// Carl
Author: colomon
Date: 2010-05-14 12:54:30 +0200 (Fri, 14 May 2010)
New Revision: 30622
Modified:
docs/Perl6/Spec/S32-setting-library/Numeric.pod
Log:
[spec] Switch atan2 to work on Real instead of Numeric. Add TrigBase argument
to it as well.
Modified: docs/Perl6/Spec/S32-setting-library/Num
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
<+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
The support of threading should be completely optional. The threading
support should not be active by default.
I'd like to understand why you
After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require, parallelism.
It is left for the implementors to resolve whether a single or mult
Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu:
> The less, or rather the more abstract, the specification in perl6, the
> less likely perl6 will 'age'.
I think the important thing to realize here is that the Perl 6 language
keeps its definitions mostly abstract. Junctions, Hyper O
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
:
: Parallelism and Concurrency could be considered to be two different things.
:
: The hyperoperators and junctions imply, but do not require,
: p
On Fri, 14 May 2010 15:05:44 +0100, B. Estrade wrote:
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
wrote:
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
rv...@isolution.nl
<+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
>
>The suppo
On Fri, 14 May 2010 15:58:00 +0100, Daniel Ruoso - dan...@ruoso.com
<+nntp+browseruk+d52dbf78bb.daniel#ruoso@spamgourmet.com> wrote:
Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu:
The less, or rather the more abstract, the specification in perl6, the
less likely perl6 wil
Em Sex, 2010-05-14 às 18:13 +0100, nigelsande...@btconnect.com escreveu:
> The point I(we)'ve been trying to make is that once you have a reentrant
> interpreter, and the ability to spawn one in an OS thread,
> all the other bits can be built on top. But unless you have that ability,
> whilst t
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
> After reading this thread and S17, I have lots of questions and some
> remarks.
>
> Parallelism and Concurrency could be considered to be two different things.
>
> The hyperoperators and junctions imply, but do not require, pa
On Fri, May 14, 2010 at 09:50:21AM -0700, Larry Wall wrote:
> On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
...
>
> But as you say, this is not a simple problem to solve; our response
> should not be to punt this to future generations, but to solve it
> as best as we can, a
On Fri, May 14, 2010 at 06:03:46PM +0100, nigelsande...@btconnect.com wrote:
> On Fri, 14 May 2010 15:05:44 +0100, B. Estrade wrote:
>
> >On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
> >wrote:
> >>On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
> >>rv...@isolu
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com wrote:
> On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
> <+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
>
>
> >
> >The support of threading should be completely optional. T
14 matches
Mail list logo
