Re: a junction or not
On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote: The problem that Richard just identified is that Junctions don't fully manage to hide themselves when it comes to their method calls. [...] I'm thinking that maybe Junction shouldn't be a type. Instead, it should be a meta-type, in (very rough) analogy to the concept of the meta-operator. In particular, Junction bears a certain resemblance to the hyper-operator. A couple of months ago I started a thread rfc: The values of a junction where I suggested that a solution tot he problem was to add a grep meta-operator that would enable an operator-based collapse of junctions. My suggested syntax from that thread was: my @values = 0..21 |==| $junc_value; Or my @values = Int |==| $junc_value; The idea was to match the range against the (possibly) junctional value, but return the set of matching values rather than just a True/ False comparison (Any binary operator that returns something boolean- like would be usable in the |op| meta chars. Given changes to meta- ops since then, perhaps my @values = 0..21 G== $junc_value would be more consistent. The advantage of using an operator over the existing grep method is that it could reasonable be expected to handle infinite ranges (and infinite junctions) analytically (in finite time). The advantage of using the operator over the eigenstates method is that it doesn't assume any knowledge pf the nature of the junction: all, any, one, none -- the operator would do the right thing without any additional user-introspection.
Re: RFD: Built-in testing
On Jan 23, 8:59 pm, jswit...@gmail.com (Jason Switzer) wrote: That sounds useful on the surface but often turns out to be more difficult to do than you might think. There are many cases where tests are performed from within loops. Something like S09.237 may or may not be in a loop, may be difficult to identify in files with many tests. There are at least two reasons to identify a test (or check): to control it from afar, and to track it's results. If the reason for wanting identity is to control it (e.g. Foo::Bar::TestS09.237.disable()), then the fact that it's in a loop isn't necessarily important: if you want to disable it, then you probably want to disable all iterations. If we do want finer grain control, then it is probably possible to do something with resumable exceptions that are thrown each time the test is potentially skipped. If the reason to identifying a check is to track its result, then the obvious solution is to not assume that it's result is pass/fail, but is instead a pair of pass/fail counts (or pass/total -- same thing). A good testing approach is directed-random, where the same test is run multiple times with different random seeds so as to use different test data. IMO, it is reasonable to think of a one-shot test as an aberration.
Re: rfc: The values of a junction
On Jan 5, 2:24 pm, d...@dave.whipp.name (Dave Whipp) wrote: Handling all the variations around this (including compound junctions) will be quite tricky to implement, even if we did have introspection for junctions. Incidentally, we'd also need introspection of arrays, to extract the infinite ranges without iterating over them.
Re: S16: chown, chmod
On Nov 23, 4:55 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote:
I don’t see any examples in S16 concerning error handling anyway,
but even so I don’t see how relying on exceptions would could
possibly be more complex than guard clauses.
Neither do I. Catching Failure objects is better than explicit checks
(except where performance implications exist and are relevant to the
application -- which isn't the case here).
Dave.
PS. From S16, q{ ... On POSIX systems, you can detect this condition
this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
}
From this I inferred that the purpose of this assignment was to do a
check -- I apologize if I misinterpreted it -- and would suggest that
we should either get rid of that text, or else reword to suggest not
using it in bad ways.
Re: S16: chown, chmod
On Nov 23, 2:33 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote: The API you propose does not seem to me to shorten code at all and is likely to lead to problematic code, so it seems like a bad idea. Interfaces should be designed to encourage people to do things correctly and to make it hard to even think about the nearly certainly wrong way. I'm going to both agree and disagree. I agree that the specific example of chown.is_restricted is a bad idea, but only because the POSIX API I was wrapping is itself flawed. In general I would continue to pursue the approach of adding precondition-checks as methods on functions, a concept that is orthogonal to the specific example you are arguing against: I disagree that the code I showed is not simpler that the original S16 approach.
Re: S16: chown, chmod
On Nov 22, 12:46 am, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH) wrote: On 2008 Nov 21, at 14:13, Dave Whipp wrote: The restriction of chown to the superuser is a property of the OS, not the files. The example from the pod is: man pathconf Ah, thanks for that. It's probably an unproductive rats nest to attempt to add abstractions for all these APIs, so I assume we'll have a use IO::pathconf pragma that adds a global pathconf function, plus an IO.pathconf method, to access these properties.
S16: chown, chmod
Reading S16, I was struck by the lack of abstraction over the
underlying Unix API for chown and chmod. Nothing wrong with having the
existing functions lying about in a module that people can use Unix
for; but I do feel that the variants in the global namespace should be
more user-friendly.
chown, for example, accepts uid and gid only as integers, -1 meaning
don't change. To my mind, perl6 should have a variant of chown
strings for uid and gid (and lookup the integers automatically). And
it should accept undef as a synonym for -1.
BTW, the Synopsis fails to define the return value of chown (except
that it's an integer). The underlying Unix API returns success/error
status: The p6 wrapper should be defined to return the appropriate
Failure object (so that { use fatal } will work).
A similar situation exists for chmod, except it is harder to fix.
The fact that it needs a discussion of don't say 0644 has a pungent
aroma. A list of integers might solve that. Or perhaps something with
named args: { chmod :u(6), :g(4), :o(4) == @files }.
But this still isn't as flexible (nor readable) as a Unix command
line. The command line allows you to say add execute permission
without specifying any of the other bits. A bunch of methods might the
the right approach, but that would fall foul of the same issue that
filetest operators have: Do we really want to add all these methods to
the Str class?
The return value of chmod is defined, in the synopsis, as the number
of files modified. The underlying Unix API returns success/fail. As
with chown, I feel that we should return a Failure object to represent
failures.
One final point is that not all systems use the Unix security model.
The primary P6 abstraction should probably reflect that fact. The
synopsis does make brief mention of use filetest from P5 for
interacting with ACLs, but then punts to the P5 definition/
implementation.
Re: S16: chown, chmod
On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
Please feel free to whack on the spec
OK, working on it.
Question: is it appropriate to P6 lookfeel to have methods on
functions?
The definition of Cchown includes the statement that it's not
available on most system unless you're superuser; and this can be
checked using a POSIX incantation. I was wondering if it would be
reasonable to provide this as a method on the chown function, so that
a user could say:
if chown.is_restricted {
...
}
else {
chown $user, $group == @files
}
Re: S16: chown, chmod
before I attempt to change the POD, would this wording be appropriate?
=item chown
our multi chown (Int $uid, Int $gid, Str|IO [EMAIL PROTECTED])
our multi chown (Str $user, Str $group, Str|IO [EMAIL PROTECTED])
Changes the owner (and/or group) of a list of files. The new
ownership can be specified either as integers or as strings.
If an argument is either a negative integer or undefined then
the ownership (or group membership) of the files will be
unchanged.
A True value will be returned if the operation succeeds,
otherwise the function will Cfail.
The list of files may contain strings and/or filehandles.
Strings are interpretted as filenames. On systems that don't
support Cfchown the use of file handles will result in
failure
When $user or $group are passed as strings, the implementation
will convert this name to the underlying uid/gid using a
function such as getpwnam.
On most systems, you are not allowed to change the ownership of
the file unless you?re the superuser, although you should be
able to change the group to any of your secondary groups. On
insecure systems, these restrictions may be relaxed, but this
is not a portable assumption. On POSIX systems, you can detect
this condition this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
=item chmod
our multi chmod( Int $mode, Str|IO [EMAIL PROTECTED] );
our multi chmod( PermissionModifier :$user?, PermissionModifier :
$group?, PermissionModifier :$other?, Str|IO [EMAIL PROTECTED] );
class PermissionModifier {
submethod BUILD ( Bool :$r, Bool :$w, Bool :$x );
...
};
Changes the permissions of a list of files. Returns a true value if
the operation is sucessful on all the files, otherwise Cfail.
The files to modify can be given either as Strings, or FileHandles.
The permissions can be provided as either a single integer,
corresponding
to the underlying Unix permissions mode value, or as named options
using PermissionModifier objects.
A PermissionModifier object is constructed using options similar
to filetest operators. :r, :w and :x (and their inverted forms).
If a given option is not included in the object that the corresponding
permission mode of the file(s) will not be changed.
Examples:
chmod 0o755, @executables;
$mode = '0644'; chmod $mode, 'foo';# !!! sets mode to --
wr-T
$mode = '0o644'; chmod $mode, 'foo'; # this is better
$mode = 0o644; chmod $mode, 'foo'; # this is best
@executables == chmod :user( :x ),# users can execute
these
:group( :x ), # as can group members
:other( :!x :!r :!w ); # but non-group members
cannot
Re: how much detail can I get from caller.want?
On Aug 30, 8:47 am, [EMAIL PROTECTED] (John M. Dlugosz) wrote: Have the sort function simply return a lazy list object. When the [4] is called on that object, it knows to do as much work as needed, and can leave the rest as lazy. That may be half the answer, but simply making the decision lazily is insufficient, because the guarantee that only exactly one item is needed is lost. An algorithm that singles out exactly one ordered element may be in retrospect inefficient if the list is later accessed for other indices.
