Thus, you should override connect, as well as read and recv.

The other problem is that the program will still yield ONCE within each of those methods, and then continue on to perform the original blocking io operation.

The apparent solution to this is to make the socket be nonblocking, and only yield if the connect or read or recv fails due to ewouldblock or eagain. This, of course, results in polling (and much wasted cpu time) if all of the coroutines are waiting for connections or data.

The better solution, of course, is to make use of Parrot’s new threads, and perform each $lwp.get in a separate thread.

for @searches -> $s {
say $s;
}

and the result:
beer
masak

rakudo the indent tab before word

Is this a bug or …?

Farabi You can try recent versions of Rakudo, Niecza, STD and Perlito 6 (four distinct implementations of Perl 6) using the fledgling (first appeared at the end of 2012) Farabi, an online “Modern Perl Editor”.
#perl6 If you just want to do some one liners, and would find it helpful to have folk seeing and commenting on what you enter and what results you get, you can try recent versions of Rakudo, Rakudo Star, Niecza, STD, and Pugs using evalbots on IRC channel #perl6 on freenode.net.

If you do want to install something, and are a Windows user, and would be happy with the Rakudo Star bundle (which adds docs, jnthn’s awesome debugger, the Panda module installer, some basic modules, etc. to the compiler), you can just grab the latest .MSI from the Rakudo downloads link.

If you want to use Niecza, or stay close to C# (which is Niecza’s underlying “systems” language), or prefer targeting CLR/.NET/mono (Niecza’s current bytecode target), you would want the latest from sorear’s Niecza github repo.

These changes in Rakudo have led to comments such as “exceptionally helpful perl6 error message”.

(STD has had exceptionally helpful error handling for years, and Niecza has always used STD, so it too has had great error handling from the get go. But now Rakudo’s finally converging on STD’s approach, as has been the plan for many years.)

It’s about a year since I first encountered this usage of “quasi” and I still don’t like it. Bikeshed suggestion: rename “quasi” to “toast”. (Toast implies some simple cooking of the code. There’s more to do — add butter, eat it — but those come later.)

> {{{}}}
> It’s our way to mix template code in the quasi block with code coming in from other places. Doing say $message; would have been wrong, because $message is a syntax tree of the message to be logged.

Could you invert the marking logic? Anything coming in from outside the macro, eg an argument, is automatically unquoted if referenced in the body of the macro. If you DON’T want that, you use triples.

I take it that “ugly” here means “it stands out too much”. In that case, that’s part of the idea. Just like BEGIN blocks are spelled with all-capitals to signify “something unusual is going on here”, the triple blocks look like they do to signify “Warning, Will Robinson! this ain’t your ordinary kind of code, this is special code”.

So, if by “ugly”, you mean “stands out”, then the answer is “yes, we know. that’s the idea”. Perl has never shied away from using ugly syntax to make things stand out. ☺