The S16: chown, chmod thread seems to be too unix-focussed.
Perl6 is being born in a world dominated by the internet. Whilst perl
was the glue for the internet when the internet was born, it was a unix
child. I learned perl from a Windows perspective and I found the
discussion of ownership and
Richard Hainsworth wrote in perl.perl6.language :
> The S16: chown, chmod thread seems to be too unix-focussed.
I was more or less thinking that the syscall-related primitives,
like chown or chmod, could go in a POSIX namespace. Even in UNIX
land nowadays the situation can be much more complex tha
* Richard Hainsworth ([EMAIL PROTECTED]) [081126 08:21]:
> The S16: chown, chmod thread seems to be too unix-focussed.
>
> To be portable, the minimum assumptions need to be made about the
> environment in which a program operates. Alternatively, the software
> needs to be able to determine whet
On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer wrote:
> We should focus on OS abstraction.
> [...] the design of this needs to be free from historical mistakes.
And avoid making too many new ones. There must be useful prior art around.
Java, for example, has a FileSystem abstraction ja
On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer <[EMAIL PROTECTED]> wrote:
> Also, I get data from a CD which was written case-insensitive and then
> copied to my Linux box. It would be nice to be able to say: "treat this
> directory case insensitive" (even when the implementation is slow)
> Share
* Leon Timmermans ([EMAIL PROTECTED]) [081126 15:43]:
> On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer <[EMAIL PROTECTED]> wrote:
> That is a task for the operating system, not Perl. You're trying to
> solve the problem at the wrong end here IMHO.
In my (and your) case, the operating system is no
On Wed, Nov 26, 2008 at 11:21:58AM +0300, Richard Hainsworth wrote:
> The S16: chown, chmod thread seems to be too unix-focussed.
Indeed, what you are currently reading in S16 is mostly just lightly
edited copy-paste from P5 docs. But the S16 draft is out in the pugs
repo for a reason--anyone and
I agree with the idea of making Perl 6's filesystem/etc interface more abstract,
as previously discussed, and also that users should be able to choose between
different levels of abstraction where that makes sense, either picking a more
portable interface versus a more platform-specific one.
F
On Wed, 2008-11-26 at 11:34 -0800, Darren Duncan wrote:
> I agree with the idea of making Perl 6's filesystem/etc interface more
> abstract,
> as previously discussed, and also that users should be able to choose between
> different levels of abstraction where that makes sense, either picking a
* Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> [2008-11-25 07:25]:
> OTOH Perl has historically not said much about doing that kind
> of thing.
And I’m not in favour of it starting now. All I am saying is that
APIs should be designed to encourage correct designs; arguably
this is the spirit of Per
On Wed, Nov 26, 2008 at 5:15 PM, Mark Overmeer <[EMAIL PROTECTED]> wrote:
> Yes, you are right on this. ASCII does not suffer from UTF-8, so my
> example was flawed. The second 128 does cause problems. How can glob()
> sort filenames, for instance?
That's a matter of collation, not (just) chara
On Wed, Nov 26, 2008 at 11:18:01AM -0800, Larry Wall wrote:
> Anyway, feel free to coordinate this here and/or on #perl6. (Note
> that Patrick is in the process of moving all the Synopses to the pugs
> repo at some point soon, so the current S16 in pugs/docs/Perl6/Spec
> is likely to have its name
Patrick R. Michaud wrote:
> Currently Rakudo is treating [EMAIL PROTECTED] as though it's
> prefix:<^> on a List, which S03 says
>
> If [prefix:<^> is] applied to a list, it generates a
> multidimensional set of subscripts.
>
> for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,
Can I just remind everyone that (IMO) we shouldn't just be considering
filesystems here? I think it would be a pretty useful feature to have a
general tree manipulation interface, and then this could be applied to
filesystems, or XML, or LDAP, or SQL (although this doesn't map so well), or
wh
On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
:
:
: Patrick R. Michaud wrote:
: > Currently Rakudo is treating [EMAIL PROTECTED] as though it's
: > prefix:<^> on a List, which S03 says
: >
: > If [prefix:<^> is] applied to a list, it generates a
: > multidimensional set o
Tom Christiansen wrote:
I believe database folks have been doing the same with character data, but
I'm not up-to-date on the DB world, so maybe we have some metainfo about
the locale to draw on there. Tim?
AFAIK, modern databases are all strongly typed at least to the point that the
values yo
On Wed, Nov 26, 2008 at 06:21:22PM -0800, Larry Wall wrote:
> On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
> : Patrick R. Michaud wrote:
> : > Currently Rakudo is treating [EMAIL PROTECTED] as though it's
> : > prefix:<^> on a List, which S03 says
> : > for ^(3,3) { ... } # (0,
Author: lwall
Date: 2008-11-27 08:21:32 +0100 (Thu, 27 Nov 2008)
New Revision: 24080
Modified:
docs/Perl6/Spec/S03-operators.pod
src/perl6/STD.pm
Log:
[STD] not() etc. is a function call
[S03] prefix:<^> no longer tries to get fancy with lists
Modified: docs/Perl6/Spec/S03-operators.pod
==
* Tom Christiansen ([EMAIL PROTECTED]) [081126 23:55]:
> On "Wed, 26 Nov 2008 11:18:01 PST."--or, for backwards compatibility,
> at 7:18:01 p.m. hora Romae on a.d. VI Kal. Dec. MMDCCLXI AUC,
> Larry Wall <[EMAIL PROTECTED]> wrote:
>
> SUMMARY: I've been looking into this sort of thing lately (see
19 matches
Mail list logo
