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"
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
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
infinit
Strange parsing error:
sub x {
}
while 0 {
my $b = 1;
}
breaks: [[[ Statement not terminated properly at line 6, near "{\n
my $" ]]]
If I add a semicolon after to sub decl, then it's happy:
sub x {
}; ## <--- semicolon here!
while 0 {
my $b = 1;
}
The strange thing is that it's only
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 th
On Nov 23, 3:56 pm, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH)
wrote:
> I think you're seeing something other than what we are. Checking any
> external resource before operating on it introduces a race condition
> which can allow an attacker to swap resources on you, so the item you
> (in
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 h
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
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 b
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 look&feel to have methods on
functions?
The definition of C includes the statement that it's not
available on most system unless you're superuser
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.
chow
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 l
12 matches
Mail list logo
