Joe Gottman wrote:
>On the other hand, this being Perl, I do believe it should be easy to
> specify the concurrent case. I think that a keyword (and a
> keyword corresponding to ) would be a good idea.
> These would not be quite parallel to and because there
> would be some subtle differen
# New Ticket Created by Andrew Sweger
# Please include the string: [perl #49368]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49368 >
The config/gen/makefiles/root.in perl6 target makes reference to
($EXE) when $(EXE) is
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #49358]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49358 >
Add math support to lolcode.
math ops are in src/builtins/math.pir
Index: MANIFEST
===
# New Ticket Created by Zev Benjamin
# Please include the string: [perl #49354]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49354 >
Attached are some tests from the NQP TODO file. I attempted to make
reasonable guesses
On Jan 4, 2008 9:18 AM, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Joe Gottman wrote:
> >On the other hand, this being Perl, I do believe it should be easy to
> > specify the concurrent case. I think that a keyword (and a
> > keyword corresponding to ) would be a good idea.
> > These would n
James Keenan via RT wrote:
The test file itself has not been substantively changed in several
months, so it's not the test itself that's causing the problem.
It's been doing this off and on for months. It's intermittent. If you
kill the test, and run it again, it'll pass.
(That said, I'm abo
On Jan 3, 2008 8:40 PM, via RT Andrew Sweger
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Andrew Sweger
> # Please include the string: [perl #49368]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=49368 >
>
>
> The c
On Jan 4, 2008, at 8:09 AM, Allison Randal wrote:
Andy, the headerizer dies with an error when src/atomic/gcc_x86.c
has two functions that are marked with both PARROT_API and
PARROT_INLINE. Am I correct in understanding that these two markings
should never occur on the same function at the
François and I have been writing over each other's commits on
src/atomic/gcc_x86.c, so before I edit again, let's figure out the right
way to edit.
Andy, the headerizer dies with an error when src/atomic/gcc_x86.c has
two functions that are marked with both PARROT_API and PARROT_INLINE. Am
I
Luke Palmer wrote:
forall was about concurrency, not order of evaluation. There is a difference
between running in an arbitrary order serially and running in parallel.
for %bag {
.say;
}
If the bag had elements "hello", "world", I think printing:
helworld
lo
Would defi
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential in nature.
Where the s
On Jan 3, 2008 4:58 PM, via RT Zev Benjamin
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Zev Benjamin
> # Please include the string: [perl #49354]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=49354 >
>
>
> Attache
On Fri, Jan 04, 2008 at 12:55:19AM -0600, Andy Lester wrote:
> http://use.perl.org/~pmichaud/journal/35272
> http://perlbuzz.com/2008/01/flurry-of-perl-6-activity-picks-up-new-contributor.html
>
> Lots of cool stuff is going on, and I'm so so glad to see it. I'm
> thinking of making a Perl 6-sp
Mark J. Reed wrote:
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential i
> I disagree with the idea that humans don't think concurrently (though
> more often they think in terms of data dependencies).
I think this is more analogous to event based programming rather than parallel
programming. Event based and parallel based have some similarities but the
are fundament
I (impersonally) believe that hyper context is the right solution to
this because context can propagate to where it needs to dynamically.
As for the fact that it's not the default list context for "for",
that could easily be changed with a pragma. Maybe that could even
be the default someday, but
On Fri Jan 04 05:46:48 2008, [EMAIL PROTECTED] wrote:
>
> It's been doing this off and on for months. It's intermittent.
??? I've got dozens of 'make test' reports going back months, and I've
never seen it.
> If you kill the test, and run it again, it'll pass.
Nope.
[li11-226:parrot] 503 $ p
On Friday 04 January 2008 06:09:40 Allison Randal wrote:
> And François, from your commits it looks like parrot_i386_cmpxchg and
> parrot_i386_xadd need PARROT_API for linking on MinGW32. Can you delete
> PARROT_INLINE and have it still work?
I'm confused as to why MinGW32 needs PARROT_API for th
Joe Gottman schreef:
> if code that should be processed concurrently
> is instead processed sequentially, the results will be correct
Not if parallel sampling of happening stuffs is involved. All of your
thousands of temperature sensors in your nuclear factory, all running
the same code, should n
James Keenan via RT wrote:
What is very puzzling to me is that after 'make realclean;svn update',
it's continuing to fail on my Debian server, but it's passing on an
Ubuntu box. I've never had a test results discrepancy between the two.
What version of Debian? I can set up a chroot instance a
On Friday 04 January 2008 12:53:55 Allison Randal wrote:
> James Keenan via RT wrote:
> > What is very puzzling to me is that after 'make realclean;svn update',
> > it's continuing to fail on my Debian server, but it's passing on an
> > Ubuntu box. I've never had a test results discrepancy betwe
chromatic wrote:
Conjecture: the number of cores/processors/available threads between in the
various machines differs.
That does play a part in this particular bug. Though, I'm getting
intermittent hangs on a dual core Mac and a single core Ubuntu box.
Allison
Larry Wall wrote:
It's really, really easy to misdesign a computer language by
overemphasizing one particular design dimension to the detriment
of others.
I agree that adding a parallel "forall" (and similar statements) via a
pragma will be easy if the appropriate underlying machinery is ther
On Fri Jan 04 12:54:33 2008, [EMAIL PROTECTED] wrote:
>
> What version of Debian?
4.0
>
> (Though, I'm surprised you're not getting hangs in t/stm/ on Ubuntu. I'm
> getting them intermittently there.)
>
I've only tested a few times on Ubuntu, so I probably don't have a large
enough sample.
On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote:
> From that
> perspective, it's unfortunate a C loop always iterates arrays in the
> order of their indices.
But it doesn't, in hyper context. In Perl 6, C and C are
really the same thing, and both respond to hyper context.
> As I see
Larry Wall wrote:
> I (impersonally) believe that hyper context is the right solution to
> this because context can propagate to where it needs to dynamically.
> As for the fact that it's not the default list context for "for",
> that could easily be changed with a pragma. Maybe that could even
>
Dave Whipp wrote:
> No, you're not the only person thinking Occam ... though I should point
> out that none of my suggestions are "par" blocks -- a par block made
> every statement within the block execute in parallel with the other
> statements in that block (much like a Verilog fork/join pair).
Larry Wall wrote:
my hope is that we can delegate locking entirely to the innards of
the implementation and never mention it at all on the language level.
Hmm, sounds to me analogous to hoping that type inference will avoid the
need to expose type-annotations at the language level (synchroniz
Perl scripts have had the extension *.pl
To distinguish the scripts I started writing in perl6 from those in the
same directory written for perl5, I started naming perl6 scripts with
extension *.p6 .
Trivial question, I suppose, but any reason not to use p6? What will the
perl6 compiler look
To be brief, file extensions for both programs and modules should
remain exactly the same, .pl and .pm, between Perl 5 and Perl 6.
Perl 5 and Perl 6 code are differentiated by what the files contain,
not by their file name extensions. For example, what their internal
'use 6' vs 'use 5' lines s
I just ran a little experiment. I patched Parrot::HLLCompiler to transcode
the source code it reads to UCS-2 before parsing and compiling it, then I
profiled building perl6.pbc.
Without this hack, the build takes around 20 seconds, mostly running NQP over
languages/perl6/src/parser/actions.pm.
On Thu Jan 03 17:27:03 2008, [EMAIL PROTECTED] wrote:
> [li11-226:parrot] 502 $ prove -v t/stm/basic_mt.t
> t/stm/basic_mt1..4
> ok 1 - wait (simple)
>
>
> ... and it waits forever. Caused make test to fail to complete on
> Linux: first time I've ever seen that.
>
> kid51
FWIW: This te
On Fri, Jan 04, 2008 at 07:43:18PM -0800, chromatic wrote:
> I just ran a little experiment. I patched Parrot::HLLCompiler to transcode
> the source code it reads to UCS-2 before parsing and compiling it, then I
> profiled building perl6.pbc.
>
> Without this hack, the build takes around 20 sec
On Sat, Jan 05, 2008 at 12:29:40AM -0600, Patrick R. Michaud wrote:
> On Fri, Jan 04, 2008 at 07:43:18PM -0800, chromatic wrote:
> > (Callgrind suggests that about 45% of the running time of
> > the NQP part of the build comes from utf8_set_position
> > and utf8_skip_forward.)
>
> Even better mi
34 matches
Mail list logo
