On Tue, Oct 18, 2005 at 11:06:22AM +0100, Nicholas Clark wrote:
> Likewise. A certain reputable OS vendor's NFS implementation went
> multithreaded, with the result that close() was now where the over quota
> error was reported, rather than the individual writes.
>
> Said reputable OS vendor's own
On Wed, Sep 28, 2005 at 11:46:37AM -0500, Adam D. Lopresto wrote:
> [2] I've actually seen data lost due to this. When drive space is very
> limited
> (due to, for instance, a user quota) it's often possible to open a new file
> (since
> there's some space left), but the close fails since too m
On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:
> Internally, it may be the same. But with exceptions, it's implemented by
> someone other than the victim, and leveraged by all. That's the kind of
> abstraction I'm looking for. My problem with the whole notion of "Either
> errorMess
TSa wrote:
>
> The view I believe Yuval is harboring is the one examplified
> in movies like The Matrix or The 13th Floor and that underlies
> the holodeck of the Enterprise: you can leave the intrinsic
> causality of the running program and inspect it. Usually that
> is called debugging. But this
Yuval Kogman wrote:
>On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
>
>
[Bunches of stuff elided.]
>>A million years ago, $Larry pointed out that when we were able to use
>>'is just a' classifications on P6 concepts, it indicated that we were
>>making good forward progress. In t
On Fri, Sep 30, 2005 at 17:09:23 +0200, TSa wrote:
> And it is the type system that guaranties the availability
> of the required information e.g. in $!.
$! is polymorphic.
Since CATCH is a topcializer, and you use when blocks to case over
$!, you can check to see if it has the metadata you want
HaloO,
Yuval Kogman wrote:
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
maint
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
> You already know that "err" is the low-precedence version of //, right?
> What replaces that? I like "default" or "defaults" myself,
Yes, he proposed 'dor'.
As I see it err is like this:
sub infix: ($lhs is delayed, $rhs i
TSa wrote:
> HaloO,
>
> Yuval Kogman wrote:
>
>> On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
>>
>>> The recent thread on Expectuations brought back to mind something
>>> I've been
>>> thinking for a while. In short, I propose that "use fatal" be on by
>>> default, and
>>> that
On 29/09/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> * "try { foo() } err next" will next even if foo() did not throw
> an exception, but returned undef. But I don't think that's a problem
> in most cases. One can always do:
> try { foo(); 1 }
I think that's a flag that it's not
Hi,
TSa wrote:
> Yuval Kogman wrote:
>> On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
>>>thinking for a while. In short, I propose that "use fatal" be on by
>>>default, and that "err" be turned into syntactic sugar for a very
>>>small try/CATCH block.
>>
>> I like it a lot. It
On Thu, Sep 29, 2005 at 12:53:51 +0200, TSa wrote:
> I don't like it at all. I fear, that we mix two orthogonal concepts
> just because it is convenient.
"just because it is convenient" is precicely why I like it =)
> To me the statement
>
>return 42; # 1
>
> has to orthogonal meanings:
>
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
and
that "err" be turned into syntactic sugar fo
At 11:46 AM -0500 9/28/05, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
I totally, TOTALLY, agree with this.
EVERY built-in function and operator that talks to p
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
> The recent thread on Expectuations brought back to mind something I've been
> thinking for a while. In short, I propose that "use fatal" be on by default,
> and
> that "err" be turned into syntactic sugar for a very small try/CATCH
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
and
that "err" be turned into syntactic sugar for a very small try/CATCH block.
Basically, my observation is that no-one consistently checks t
16 matches
Mail list logo
