comes out.
regards
14.08.2015, 19:09, "Timo Paulssen" :
> On 08/14/2015 12:04 PM, Matija Papec wrote:
>> Hi,
>>
>> I'm looking for single threaded coroutines in perl6. Will hyper/race make
>> them possible?
>> Will 2015 production Rakudo in
On Fri Jun 19 12:57:49 2015, barto...@gmx.de wrote:
> I tried the evaluation from this bug report and didn't get that
> internal error anymore. There is still a type check error, though
> (which looks plausible to me):
>
> $ perl6-m -e 'sub p(*@l) { gather { if @l == 1 { take @l } else {
> @l.shif
On 08/14/2015 12:04 PM, Matija Papec wrote:
> Hi,
>
> I'm looking for single threaded coroutines in perl6. Will hyper/race make
> them possible?
> Will 2015 production Rakudo include async IO?
>
> Right now I'm considering golang for scalable websocket service, bu
Hi,
I'm looking for single threaded coroutines in perl6. Will hyper/race make them
possible?
Will 2015 production Rakudo include async IO?
Right now I'm considering golang for scalable websocket service, but also
wonder if perl6 would
(and how) make such thing possible.
ps. I
I tried the evaluation from this bug report and didn't get that internal error
anymore. There is still a type check error, though (which looks plausible to
me):
$ perl6-m -e 'sub p(*@l) { gather { if @l == 1 { take @l } else { @l.shift; for
p(@l) -> @p {} } } }; say p 1..4'
Type check failed in
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #117763]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=117763 >
stuck anew with the same message; no return in the gather
though. https://gist.
Em Sex, 2009-01-02 às 08:34 -0300, Daniel Ruoso escreveu:
> token routine_def: {...}
Actually, I was just looking at STD, and the correct token would be
token routine_declarator:coro { }
I was also looking at the spec files, and I realized that DRAFT S17
mentions coroutines, but
Em Qui, 2009-01-01 às 12:34 -0800, Geoffrey Broadwell escreveu:
> In the below Perl 5 code, I refactored to pull the two halves of the PID
> file handling out of init_server(), but to do so, I had to return a sub
> from pid_file_handler() that acted as a "continuation". The syntax is a
> bit ugly,
HaloO,
Mark J. Reed wrote:
? Multiple-assignment second-class? I don't see how you get that out
of Larry's message...
Well, he explicitly says that loop is second-class because
it uses multi-assignment. Actually he says it "tends to
violate single-assignment". But I interpret that sort of
int
? Multiple-assignment second-class? I don't see how you get that out
of Larry's message...
On 4/21/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Larry Wall wrote:
> > That is, coro and loop tend to violate single-assignment semantics, and
> > single-assignment semantics are easier to map int
HaloO,
Larry Wall wrote:
That is, coro and loop tend to violate single-assignment semantics, and
single-assignment semantics are easier to map into functional semantics.
So if we do allow coro in Perl 6, it'll probably be a second-class
citizen like loop and goto and die (and anything else cons
On Fri, Apr 18, 2008 at 07:22:35PM +0200, TSa wrote:
> HaloO,
>
> I just wonder what has become of the coroutine feature.
> Was that dropped from the spec? And when yes, why?
Coroutines have never been in the official spec, except in the
form of gather/take. Pugs implements coro, and
HaloO,
I wrote:
sub foo () { my $x = 0; yield $x++; }
I meant:
sub foo () { my $x = 0; yield $x++ while 1;
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
HaloO,
I just wonder what has become of the coroutine feature.
Was that dropped from the spec? And when yes, why?
The trick is to design the yield statement nicely.
And also to define a syntax that allows to get a fresh
instance from a coro quasi-class.
sub foo () { my $x = 0; yield $x++; }
From: François PERRAD <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 13:39:30 +0200
Thank for your long response.
I included your code in languages/lua/lib/luacoroutine.pir (r14877).
I encountered 2 problems :
1) coroutine_yield needs a current coroutine (not surprising)
Yes, this
ficulty. I can't even get a
simple recursive coroutine to work in PIR. See the first attachment for
an attempt. I think this is a fundamental problem; I know nothing about
Lua, but I strongly suspect Parrot coroutines would have to be
redesigned to support what the Lua manual says about t
ree_node
again:
if i >= size goto done
## print "[coro recur: depth "
## print depth
## print ' elt '
## print i
## print "]\n"
$P1 = tree_node[i]
coro_enumerate_tree(coro, $P1, depth)
inc i
ive coroutine to work in PIR. See the first attachment for
an attempt. I think this is a fundamental problem; I know nothing about
Lua, but I strongly suspect Parrot coroutines would have to be
redesigned to support what the Lua manual says about them [1].
But that's not a show-stopper; co
g. See also Dan's blogs about couroutines,
I prefer the option of repassing arguments to coroutines. It is
slightly easier to emulate not repassing with repassing then vice
versa. That and it just feels more powerful to me.
Sounds reasonable.
Given the 3 operations of the paper
s blogs about couroutines,
I prefer the option of repassing arguments to coroutines. It is
slightly easier to emulate not repassing with repassing then vice
versa. That and it just feels more powerful to me.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Nice summary with examples:
ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf
and we still have to define semantics of parrot couroutines, e.g. WRT
argument passing. See also Dan's blogs about couroutines,
leo
Michael Walter <[EMAIL PROTECTED]> wrote:
> I sense confusion between "closure", "continuation" and "coroutine".
> http://c2.com/cgi/wiki?ContinuationsAndCoroutines
and that's even referencing Dan's blog ;)
leo
Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
[ nested coroutines ]
> Do you think the above code snippet could work? That is, without much
> special code, can this be done in PIR?
As said, coroutine's (argument passing and more) behavior isn't yet
layed out and there are sev
Klaas-Jan Stol writes:
> Hello,
>
> I spoke (through email) with Roberto Ierusalimschy, one of the creators of
> the Lua programming language, and I said that Parrot has good support for
> implementing coroutines and closures (heck, they are explicitly there).
>
> However
On Thu, Nov 04, 2004 at 10:11:07PM +0100, Klaas-Jan Stol wrote:
>
> I hadn't seen ".yield(x)"
> Is
>.yield(x)
>
> the same as:
>
>.pcc_begin_yield
>.return x
>.pcc_end_yield
> ?
>
Yes. This alternative syntax has been checked in yesterday
and is documented in the updated callin
Nov 2004 22:11:07 +0100, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
> >Well, I don't know how "true" coroutines are defined, but Parrot, as
> >it's CPS based, has no problems with coroutines and there are no
> >restrictions to coroutines, AFAIK.
Well, I don't know how "true" coroutines are defined, but Parrot, as
it's CPS based, has no problems with coroutines and there are no
restrictions to coroutines, AFAIK.
To be honest, I hadn't thought of this, either (this "true"-ness of
coroutines), but
Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Hello,
> "Are you sure Parrot support "true" coroutines? Does it integrate
> coroutines and closures correctly? (For instance, a single closure may
> refer to variables in several different coroutines.)"
Well,
Hello,
I spoke (through email) with Roberto Ierusalimschy, one of the creators of the Lua
programming language, and I said that Parrot has good support for implementing
coroutines and closures (heck, they are explicitly there).
However, in a reply, Roberto asked:
"Are you sure Parrot su
Dan Sugalski wrote:
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op with an
appropriate MMD table. :)
Yes, *but" we have to do t
Dan Sugalski wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op with an
appropriate MMD table. :)
Conceptually, "+" is not an op at all in Python, it is syntatic sugar
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MM
On Mon, 2004-10-11 at 14:03, Sam Ruby wrote:
> Here's a script that will run in both Python and Perl. It simply will
> return different results.
>
>print "1" + "2","\n",;
>print "45%s8" % "7","\n",;
>print 45 / 7 ,"\n",;
>print ['a','b','c'],"\n",;
>
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can
introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as a fallback mechanism,
On Sat, 9 Oct 2004, Sam Ruby wrote:
> Inheritance can reduce the combinatorial problem, but it can introduce a
> precendence question. The most interesting case still seems to be:
>
>mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as a fallback mechanism, the foreign
object were cast int
Dan Sugalski wrote:
Are Python specific PMCs the right way to go?
Mostly, yes.
What are the implications of having a PerlString and a PyString? I
guess ultimately we are going to need to decide what to do with things
like:
mmd_lookup(MMD_ADD, PerlString, PyString)
Will the combinatorics inv
on did EXCEPT for the generator stuff?
Probably not. We'll have a set of PMCs that do the right thing.
A better idea is just to fix coroutines. I don't care if pie-thon.pl
breaks.
> - Michal
leo
At 11:59 AM -0400 10/8/04, Sam Ruby wrote:
Leopold Toetsch wrote:
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's
On Fri, 8 Oct 2004, Leopold Toetsch wrote:
> Guido is to blame. Python generators/coroutines work like this:
>
>iter = coro() # first time calling
>for x = iter() ...# iterate
>
> And that's what Parrot is doing too with the --python switch. But there
>
Leopold Toetsch wrote:
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's what Parrot is doing too with the --p
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's what Parrot is doing too with the --python switch. But there
is
Hey all,
Here's a simple hand coded example that
(correctly, AFAIK) prints "ab" in vanilla
parrot, but goes off in an infinite
loop with the --python flag.
Why does --python mode modify the
behaviour of coroutines?
I thought perhaps they were used for
generators or "for.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Aug 2003, Leopold Toetsch wrote:
>> Or coroutines shouldn't swap the control stack - I don't know.
> They should, sort of.
> Coroutines are a pain, but what they have to do is keep track of both the
> top
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Aug 2003, Leopold Toetsch wrote:
>> Or coroutines shouldn't swap the control stack - I don't know.
> They should, sort of.
> Coroutines are a pain, but what they have to do is keep track of both the
> top
On Mon, 18 Aug 2003, Leopold Toetsch wrote:
> Or coroutines shouldn't swap the control stack - I don't know.
They should, sort of.
Coroutines are a pain, but what they have to do is keep track of both the
top *and* bottom of their saved stacks. When a coroutine with active state
i
the exception handler in its context. Calling the generator
therefor hasn't the eception handler, the exception isn't caught then.
I can't see a way to update the context of coroutines created before the
exception handler was there.
Or coroutines shouldn't swap the control stack - I don't know.
leo
It seems that exception handlers get tied to
subroutines when they're created, not when
they're actually used. For example:
## this works:
try:
f = make_function()
f.die() # raise some error
except:
pass
## this does not work:
f = make_function()
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
Quoting Michael Lazzaro <[EMAIL PROTECTED]>:
> Similarly, then, I would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread. C would temporarily suspend
> the thread, and C would end the thread. (Note that you could
Jonathan Scott Duff wrote:
I've read this post far more times than I care to admit and I still
see no merit to conflating "threads" and "coroutines".
To me, the salient feature of coroutines is the ability to start from
the beginning or from where we left off, while the s
d this post far more times than I care to admit and I still
see no merit to conflating "threads" and "coroutines".
To me, the salient feature of coroutines is the ability to start from
the beginning or from where we left off, while the salient feature of
threads is independent sim
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > Similarly, then, I
would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread.
Perhaps we should fall back on the old message passing abstraction, where
messages can be either
read. C would temporarily suspend
> the thread, and C would end the thread. (Note that you could
> use &_.yield to yield the current Code object, so you can have nested
> yields w/out confusion -- see C, from A6.)
The problem with unifying Coroutines with Threads is that Coro
e block being
parallelizable with the addition of a single word. Few languages do a
decent job of parallelization, and current thread syntax is often
overly burdensome.
Importantly, I hope that it _might_ be possible to, in the
multiprocessor-laden future, automagically parallelize some coroutine
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
So, in summary, its good to have a clean abstraction for all the HCCCT
things. But I think it is a mistake to push them too close. Each of
the HCCCT things might be implemented as facades over the underlying
othogonal concepts of data manag
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
What I'm getting at is that all these concepts are much more related
than they might at first seem, and that the differences between them
are largely of "scope". If we have some form of coroutines,
Jonathan Sillito wrote:
-Original Message-
From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
And from imcc's register allocations POV the whole coroutine stuff is a
PITA, no registers are preserved, AFAIK, so a coroutines and the caller
+ all edges out from both do share the same regi
t; possibility, that the coroutine states, "I'm finished now" - with
> possibly meaning "don't call me again".
That's correct.
> And from imcc's register allocations POV the whole coroutine stuff is a
> PITA, no registers are preserved, AFAIK, so a cor
t;don't call me again".
And from imcc's register allocations POV the whole coroutine stuff is a
PITA, no registers are preserved, AFAIK, so a coroutines and the caller
+ all edges out from both do share the same registers, don't they?
leo
Damian Conway writes:
>
> There's no second iterator. Just C walking through an array.
>
( questions in the form of answers :-)
so :
* "for" impose array context for first argument and doesnt care about
"nature" of the array which it was given eventually as an argument .
no multiple st
her than from the start of the subroutine
Continuation: a mechanism for capturing the "what-happens-next"
at any point in a program's execution
BTW, there's rather a nice discussion of these three at:
http://mail.python.org/pipermail/python-dev/1999-July/000467.html
}
2b2- Is that what C does in scalar context -- returns an
iterator?
my $iter = each qw(apple banana cherry);
my $junk = all qw(apple banana cherry);
my $itr2 = each $junk; # Whoops! Wrong thread...
3- What's the difference among an iterator, a coroutine, and a
continuation?
3a- Does imp
At 12:48 PM 7/5/2002 -0400, Dan Sugalski wrote:
>At 10:39 PM -0400 7/3/02, Melvin Smith wrote:
>>At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
>>>I know there was some talk about this extra "address" parameter recently,
>>>but i'm not sure what the upshot of it is. Right now, tcc is complaining
lly preallocate
> > at construction time, then resize later. For languages other than Perl
> > that might need a "struct" type, it makes sense to request the correct
> > allocation up front. The size could be bytes, elements, or kilometers.
> > It doesn't need to
On Fri, 5 Jul 2002, Josh Wilmes wrote:
> At 8:55 on 07/05/2002 CDT, "David M. Lloyd" <[EMAIL PROTECTED]> wrote:
>
> > It got removed because it wasn't in the spec... Dan directed that we
> > replace it with a version of init that accepts a PMC argument
> > (init_pmc_method_t) that can be used to
At 10:39 PM -0400 7/3/02, Melvin Smith wrote:
>At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
>>I know there was some talk about this extra "address" parameter recently,
>>but i'm not sure what the upshot of it is. Right now, tcc is complaining
>>loudly because the init functions for parrotsub an
At 8:55 on 07/05/2002 CDT, "David M. Lloyd" <[EMAIL PROTECTED]> wrote:
> It got removed because it wasn't in the spec... Dan directed that we
> replace it with a version of init that accepts a PMC argument
> (init_pmc_method_t) that can be used to send in initial size or whatever
> else you can d
ense to request the correct
> allocation up front. The size could be bytes, elements, or kilometers.
> It doesn't need to be just size, as in subs/coroutines.
>
> In any case, it wasn't doing any harm, so I'm not sure why it got
> removed.
It got removed because it w
location, aggregates
usually preallocate at construction time, then resize later. For languages
other than Perl that might need a "struct" type, it makes sense to
request the correct allocation up front. The size could be bytes, elements,
or kilometers. It doesn't need to be just size
I know there was some talk about this extra "address" parameter recently,
but i'm not sure what the upshot of it is. Right now, tcc is complaining
loudly because the init functions for parrotsub and parrotcoroutine don't
match the init_method_t type in the _vtable structure.
What's the deal
, but still do them. (I'm all
> up for doing them better in perl 6)
my currently accreting coroutines module, which will, if all goes
well, appear in TPJ #21, will implement its continuations by rewriting
all lexical variables and all controlled loop constructs containing
yield calls in
72 matches
Mail list logo
