On Sep 10, 10:32 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> On Sep 10, 2008, at 7:43 AM, Rich Hickey wrote:
>
> > If you don't want to wait, submit a patch (and a CA if you haven't
> > already), and I'll look at it. I will say that the "silent ignore"
> > path is not an option - cycli
On Sep 10, 4:32 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> The enclosed patch modifies "load" to detect and prevent loading a
> resource while another load of the same resource is pending in the
> same thread. It works at the "load" level using paths so the
> protection is compreh
On Sep 10, 2008, at 7:43 AM, Rich Hickey wrote:
> If you don't want to wait, submit a patch (and a CA if you haven't
> already), and I'll look at it. I will say that the "silent ignore"
> path is not an option - cyclic dependencies are an error you can't
> leave in place. There will be other tool
On Sep 10, 1:38 am, ntupel <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-09-09 at 23:57 +1000, Brett Morgan wrote:
> > On Tue, Sep 9, 2008 at 10:31 PM, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
>
> > > On Sep 9, 11:26 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> > >> For C, protection agai
On Tue, 2008-09-09 at 07:26 -0700, Rich Hickey wrote:
> Certainly there are areas where there could be more explicit messages,
> but the detection and reporting of errors has a cost (in time,
> sometimes runtime, effort, code size and complexity) and I don't want
> to incur that cost unless it is
On Wed, 2008-09-10 at 16:47 +1100, Brett Morgan wrote:
> On Wed, Sep 10, 2008 at 4:38 PM, ntupel <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2008-09-09 at 23:57 +1000, Brett Morgan wrote:
> >> On Tue, Sep 9, 2008 at 10:31 PM, [EMAIL PROTECTED]
> >> <[EMAIL PROTECTED]> wrote:
> >> >
> >> > On Sep 9,
On Wed, Sep 10, 2008 at 4:38 PM, ntupel <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-09-09 at 23:57 +1000, Brett Morgan wrote:
>> On Tue, Sep 9, 2008 at 10:31 PM, [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > On Sep 9, 11:26 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
>> >> For C, pro
On Tue, 2008-09-09 at 23:57 +1000, Brett Morgan wrote:
> On Tue, Sep 9, 2008 at 10:31 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >
> > On Sep 9, 11:26 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> >> For C, protection against circular dependencies is on the head of the
> >> programmer,
On Sep 9, 4:26 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> My point is, having encountered this error (which is not the kind of
> thing that is going to lurk around to bite you deep at runtime), was
> it not obvious what the problem was? Did Clojure, and the work you
> were doing, vanish? It may
Whatever you do, don't kill Clojure while trying to save us from
ourselves.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscrib
On Sep 9, 2:36 am, ntupel <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-08 at 13:15 -0700, Rich Hickey wrote:
> > Hmm, don't do that?
>
> > Seriously, how is this a bug in Clojure, and not a bug in your
> > program, which resulted in an exception which easily leads you to your
> > problem?
>
> We
On Tuesday 09 September 2008 07:00, Brett Morgan wrote:
> On Tue, Sep 9, 2008 at 11:58 PM, Randall R Schulz wrote:
> > On Tuesday 09 September 2008 01:51, Brett Morgan wrote:
> >> ...
> >>
> >> Would you kindly educate me in how you believe that Clojure would
> >> go about trapping your error and
On Tue, Sep 9, 2008 at 11:58 PM, Randall R Schulz <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 09 September 2008 01:51, Brett Morgan wrote:
>> ...
>>
>> Would you kindly educate me in how you believe that Clojure would go
>> about trapping your error and giving you an error message instead of
>> runn
On Tuesday 09 September 2008 01:51, Brett Morgan wrote:
> ...
>
> Would you kindly educate me in how you believe that Clojure would go
> about trapping your error and giving you an error message instead of
> running out of stack space, given that you had given it a
> non-terminating dependency lis
On Tue, Sep 9, 2008 at 10:31 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On Sep 9, 11:26 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
>> For C, protection against circular dependencies is on the head of the
>> programmer, in the form of #ifdef guards.
>
> There is #import as a GCC extens
On Tue, Sep 9, 2008 at 10:20 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On Sep 9, 11:28 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 9, 2008 at 8:20 PM, Mike Hinchey <[EMAIL PROTECTED]> wrote:
>>
>> > It doesn't seem *impossible* for require and use to keep a var set of
>
On Sep 9, 11:26 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> For C, protection against circular dependencies is on the head of the
> programmer, in the form of #ifdef guards.
There is #import as a GCC extension (also used in Objective-C).
--~--~-~--~~~---~--~~
On Sep 9, 11:28 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 8:20 PM, Mike Hinchey <[EMAIL PROTECTED]> wrote:
>
> > It doesn't seem *impossible* for require and use to keep a var set of
> > namespaces it's loading and check if the current is already in the set
> > then gi
On Tue, Sep 9, 2008 at 8:20 PM, Mike Hinchey <[EMAIL PROTECTED]> wrote:
>
> It doesn't seem *impossible* for require and use to keep a var set of
> namespaces it's loading and check if the current is already in the set
> then give an error.
And that technique is itself open to stack overflow atta
On Tue, Sep 9, 2008 at 8:12 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On Sep 9, 10:51 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
>> Would you kindly educate me in how you believe that Clojure would go
>> about trapping your error and giving you an error message instead of
>> running
It doesn't seem *impossible* for require and use to keep a var set of
namespaces it's loading and check if the current is already in the set
then give an error.
However, I don't think clojure supports circular dependency since
loading is sequential. I know there's a trick for functions to be
cir
On Sep 9, 10:51 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> Would you kindly educate me in how you believe that Clojure would go
> about trapping your error and giving you an error message instead of
> running out of stack space, given that you had given it a
> non-terminating dependency list?
On Tue, Sep 9, 2008 at 7:29 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On Sep 9, 8:48 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
>> You seem to be asking for the
>> compiler to be able to prove that your computation finishes, and if it
>> doesn't then give you a sane response.
>
> No.
On Sep 9, 8:48 am, "Brett Morgan" <[EMAIL PROTECTED]> wrote:
> You seem to be asking for the
> compiler to be able to prove that your computation finishes, and if it
> doesn't then give you a sane response.
No.
--~--~-~--~~~---~--~~
You received this message becau
On Tue, Sep 9, 2008 at 5:36 PM, ntupel <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-09-08 at 13:15 -0700, Rich Hickey wrote:
> > Hmm, don't do that?
> >
> > Seriously, how is this a bug in Clojure, and not a bug in your
> > program, which resulted in an exception which easily leads you to your
> > p
On Mon, 2008-09-08 at 13:15 -0700, Rich Hickey wrote:
> Hmm, don't do that?
>
> Seriously, how is this a bug in Clojure, and not a bug in your
> program, which resulted in an exception which easily leads you to your
> problem?
Well, first of all this bug in a users program results in undefined
b
On Sep 8, 4:08 pm, ntupel <[EMAIL PROTECTED]> wrote:
> (ns test
> (:require test))
>
> results in:
>
> clojure.lang.Compiler$CompilerException: test.clj:0: null
...
> Caused by: java.lang.StackOverflowError
Hmm, don't do that?
Seriously, how is this a bug in Clojure, and not a bug in you
(ns test
(:require test))
results in:
clojure.lang.Compiler$CompilerException: test.clj:0: null
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3824)
at clojure.lang.Compiler.analyze(Compiler.java:3657)
at clojure.lang.Compiler.eval(Compiler.java:3848)
at cloj
28 matches
Mail list logo
