Leon (>):
> It seems S03 and S16 disagree on the meaning of $filename ~~ :e
> though. According to S16 it means $filename.:e, according to S03 it
> means $filename.e. I think it was discussed some time ago and S16 is
> correct.
No, $filename.e is the newer one; S16 is out-of-date on that point.
/
On Tue, Feb 3, 2009 at 8:34 AM, Richard Hainsworth wrote:
> I strongly believe the current S16 needs rewriting from scratch. This
> approach seems far more more perl6-ish. I tried to draft a new S16, but
> realised I simply dont have the knowledge (or the time to acquire the
> knowledge) necessary
Em Ter, 2009-02-03 às 10:34 +0300, Richard Hainsworth escreveu:
> f) radical suggestion:
> if the syntax '=$filehandle' lazily takes something from the file
> handle, then
> $filehandle = ;
> should send something to it.
Problem is that this meeses up with assignment, which is an operation in
the
Daniel Ruoso wrote:
Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
It's also not clear how this should interact with buffering systems
like stdio. But in any case, speaking directly to the IO stack is
likelier to give consistent results than playing mix-n-match with
various calls on
Em Seg, 2009-02-02 às 15:12 -0800, Larry Wall escreveu:
> Roles are good, but what is this Char thing of which you speak? It
> seems good neither for Unicode characters nor for keystroke sequences. :)
I meant exactly in the sense of providing one of those abstractions, let
me rephrase it:
role
On Mon, Feb 02, 2009 at 07:47:33PM -0300, Daniel Ruoso wrote:
: Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
: > It's also not clear how this should interact with buffering systems
: > like stdio. But in any case, speaking directly to the IO stack is
: > likelier to give consistent resu
Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
> It's also not clear how this should interact with buffering systems
> like stdio. But in any case, speaking directly to the IO stack is
> likelier to give consistent results than playing mix-n-match with
> various calls on the IO stack that
On Mon, Feb 02, 2009 at 11:00:28AM -0300, Daniel Ruoso wrote:
: Em Seg, 2009-02-02 às 13:51 +0100, Leon Timmermans escreveu:
: > On Mon, Feb 2, 2009 at 1:05 PM, wrote:
: > > -the latter case C<$!> is set).
: > > +the latter case C<$!> is set). The C<:async> flag lets the call
: > > +return an und
HaloO,
pugs-comm...@feather.perl6.nl wrote:
-our Bool method getc (IO $self: *...@list)
+our Bool method getc (IO $self: Bool :async)
Shouldn't there be a sigiled :$async?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not prece
Em Seg, 2009-02-02 às 13:51 +0100, Leon Timmermans escreveu:
> On Mon, Feb 2, 2009 at 1:05 PM, wrote:
> > -the latter case C<$!> is set).
> > +the latter case C<$!> is set). The C<:async> flag lets the call
> > +return an undefined value if no character is immediately available.
> IMHO it would b
On Mon, Feb 2, 2009 at 1:05 PM, wrote:
>
> =item getc
>
> -our Bool method getc (IO $self: *...@list)
> +our Bool method getc (IO $self: Bool :async)
getc returning a Bool???
> -the latter case C<$!> is set).
> +the latter case C<$!> is set). The C<:async> flag lets the call
> +return
11 matches
Mail list logo
