pugs-comm...@feather.perl6.nl wrote:
Author: wayland
Date: 2009-02-19 04:46:06 +0100 (Thu, 19 Feb 2009)
New Revision: 25402
Added:
docs/Perl6/Spec/S32-setting-library/
docs/Perl6/Spec/S32-setting-library/Any.pod
docs/Perl6/Spec/S32-setting-library/Containers.pod
docs/Perl6/Spec/S32-s
Author: wayland
Date: 2009-02-19 08:47:26 +0100 (Thu, 19 Feb 2009)
New Revision: 25405
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Improved Temporal (previously DateTime) stuff a bit
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
Timothy (>), Moritz (>>):
>> Speaking of Tree, let me quote from IRC:
>>
>> 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
>> squatted by an internal class in Perl 6, which is not
>> general
>> enough to reprenest an arbitrary tree data structure.
On Wed, 18 Feb 2009, Dave Rolsky wrote:
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what DateTime
does, but:
1. Uses more variables, of which I expect the g
Author: wayland
Date: 2009-02-19 05:08:23 +0100 (Thu, 19 Feb 2009)
New Revision: 25403
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S29-functions.pod
docs/Perl6/Spec/S32-setting-library/Any.pod
docs/Perl6/Spec/S32-setting-library/Containers.pod
docs/Perl6/Spec/S32-setting-li
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what DateTime
does, but:
1. Uses more variables, of which I expect the getters and setters to be
overridde
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
> I'll try and design an API that does what DateTime does, but:
> 1. Uses more variables, of which I expect the getters and setters to be
> overridden.
Please let's NOT have setters on "time" objects. They're a source of subtle
bugs in such client co
TSa wrote:
> HaloO,
>
> Daniel Ruoso wrote:
>> Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu:
>>> multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {...}
>>
>> As masak++ and moritz++ pointed out, this should be written
>>
>> multi infix:<+> (int $i where 2, int $j where 2) {
o/~ We're leaving together,
but still its farewell o/~
o/~ And maybe we'll come back,
To earth, who can tell? o/~
o/~ I guess there is no one to blame
We're leaving ground
Will things ever be the same again? o/~
o/~ It's the Final Countdown...
The Final Cou
...and this was too.
On Wed, 18 Feb 2009, Moritz Lenz wrote:
Hi,
Timothy S. Nelson wrote:
I'm not suggesting here that we specify the interfaces to all the
modules listed in the Camel book, or anything like that. Instead, I'm
suggesting that the S32 space be used for documen
Sorry, this was supposed to go to the mailing list.
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
After looking through the Phlanx project (which lists 100 or so top
perl modules), and the list in the Camel book, I can only see one or two
other
things we might eventually need,
Hi,
Timothy S. Nelson wrote:
> I'm not suggesting here that we specify the interfaces to all the
> modules listed in the Camel book, or anything like that. Instead, I'm
> suggesting that the S32 space be used for documenting the objects that we
> don't seem to be able to get away from.
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
Yup, thanks.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
On Wed, 18 Feb 2009, Leon Timmermans wrote:
On Wed, Feb 18, 2009 at 12:16 PM, Timothy S. Nelson
wrote:
On Wed, 18 Feb 2009, Leon Timmermans wrote:
The only difference I could see was that shutdown allows changing the
readability and writeability. While I agree that this functionality
On Wed, 18 Feb 2009, Mark J. Reed wrote:
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth
wrote:
What needs to be abstracted so that a perl6 program can know that a
Writeable may not be able to accept data (eg., because the file system is
full)?
I don't understand the question. To be a W
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth
wrote:
> What needs to be abstracted so that a perl6 program can know that a
> Writeable may not be able to accept data (eg., because the file system is
> full)?
I don't understand the question. To be a Writable, an object must
have a mechanism
On Wed, Feb 18, 2009 at 12:16 PM, Timothy S. Nelson
wrote:
> On Wed, 18 Feb 2009, Leon Timmermans wrote:
>
>The only difference I could see was that shutdown allows changing the
> readability and writeability. While I agree that this functionality should
> be exposed, (see my next update)
Actually, it seems to me that we do agree fundamentally, although using
different terminology.
And like I said in an earlier email, I do like/agree with the way you
are taking the Spec.
Also, it seems to me a re-ordering of the material in the Specs would
make more sense.
On our disagreeme
Author: wayland
Date: 2009-02-18 12:16:00 +0100 (Wed, 18 Feb 2009)
New Revision: 25382
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Fixed some things people were complaining about.
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs
On Wed, 18 Feb 2009, Leon Timmermans wrote:
I'd like to note that FileDescriptors are not reserved unices. I know
Windows also has them (though they aren't commonly used), and quite
possibly others too.
Will be fixed in next update.
Also, IO::Socket.close() is not an alternative for
Em Ter, 2009-02-17 às 22:38 +1100, Timothy S. Nelson escreveu:
> My third thought is that it would be very useful also to have
> date/time objects that integrate well with eg. ctime, mtime, and the like;
> I'd
> start with Time::Piece as a model.
> http://search.cpan.org/dist/Time-Piece/Pi
I'd like to note that FileDescriptors are not reserved unices. I know
Windows also has them (though they aren't commonly used), and quite
possibly others too.
Also, IO::Socket.close() is not an alternative for a shutdown()
method. They do subtly different things. IO::Socket should support
both IMH
> +role Date {
> + has Calendar $.calendar;
> + has NumberName $.year;
> + has NumberName $.month;
> + has NumberName $.dayofmonth;
> + has NumberName $.dayofweek;
> + has NumberName $.dayofyear;
> + has NumberName $.dayofquarter;
> + has NumberName
Author: wayland
Date: 2009-02-18 11:04:41 +0100 (Wed, 18 Feb 2009)
New Revision: 25380
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Fixed .new() methods to have correct name (instead of .init(), like I had)
Modified: docs/Perl6/Spec/S16-io.pod
Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
be specifying our files; it's prettier than File::Spec :), and
unified.
Anyway, HTH,
I like all the default suggestions.
Not sure whether this means you completely agree with me, o
* Timothy S. Nelson (wayl...@wayland.id.au) [090218 03:08]:
> On Tue, 17 Feb 2009, Richard Hainsworth wrote:
> >Moreover, if perl6 distinguishes between a location and a file, then the
> >spec can distinguish between a .children() method that provides a list of
> >child locations (viz., sub-direc
26 matches
Mail list logo
