On Tue, Jul 7, 2009 at 9:30 AM, Stephen C. Gilardi wrote:
>
> On Jul 7, 2009, at 5:51 AM, John Harrop wrote:
>
> Somehow, code that is treated as valid when compiled a function at a time
>> is treated as invalid when compiled all at once. That pretty much proves
>> it's an implementation bug, si
On Jul 7, 2009, at 5:51 AM, John Harrop wrote:
Somehow, code that is treated as valid when compiled a function at a
time is treated as invalid when compiled all at once. That pretty
much proves it's an implementation bug, since the same code can't
both be buggy and be fine at the same time
On Mon, Jul 6, 2009 at 11:25 PM, John Harrop wrote:
> On Mon, Jul 6, 2009 at 7:50 PM, Richard Newman wrote:
>
>> Have you tried simpler things like splitting the offending function
>> into a separate namespace, or seeing what happens with (or without)
>> AOT compilation?
>
>
> I didn't get aroun
On Mon, Jul 6, 2009 at 7:50 PM, Richard Newman wrote:
>
> > Since it's not apparently a simple bug in my function above, but
> > something about a combination of that version of that function and
> > some other part of my code, I can't think of a way to track the
> > cause down short of the very
> Since it's not apparently a simple bug in my function above, but
> something about a combination of that version of that function and
> some other part of my code, I can't think of a way to track the
> cause down short of the very tedious method of commenting out
> functions or replacing
On Mon, Jul 6, 2009 at 3:58 PM, Emeka wrote:
> (defn- subexpressions-of-sum** [[n p] terms]
> (let-print [sum (cons '+ (map #(factor-term % n p) terms))
>prod (rest (make-product* n p))]
>(cons sum
> (map #(cons '* (cons sum (rest %)))
>(concat prod (subexpressions-of-p
(defn- subexpressions-of-sum** [[n p] terms]
(let-print [sum (cons '+ (map #(factor-term % n p) terms))
prod (rest (make-product* n p))]
(cons sum
(map #(cons '* (cons sum (rest %)))
(concat prod (subexpressions-of-product prod))
I look at the above, and something stupi
On Mon, Jul 6, 2009 at 8:53 AM, Chouser wrote:
>
> On Sun, Jul 5, 2009 at 3:51 PM, John Harrop wrote:
> >
> > This is frankly quite baffling. The changes to the function are
> > innocent from a large-literal or pretty much any other perspective.
>
> Both your functions load fine for me without th
On Sun, Jul 5, 2009 at 3:51 PM, John Harrop wrote:
>
> This is frankly quite baffling. The changes to the function are
> innocent from a large-literal or pretty much any other perspective.
Both your functions load fine for me without the rest of
your code. Are there type hints on the return valu
I'm not doing any funny things with load-string. The largest literal
at this time is
[2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79
83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163
167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251
257 263 269 271 277 2
On Jul 5, 2009, at 2:01 AM, John Harrop wrote:
and got:
#32 in class file com/mycompany/myfile$eval__14598 (NO_SOURCE_FILE:0)>
Are there large literals elsewhere in the same namespace?
Here's some info from a previous report of this error:
http://groups.google.com/group/clojure/browse_frm/t
I had this:
(defn- subexpressions-of-sum** [[n p] terms]
(let-print [sum (cons '+ (map #(factor-term % n p) terms))
prod (rest (make-product* n p))]
(concat [sum] (subexpressions-of-product (cons sum prod)
in a source file with other definitions. Load-file worked. I then
change
12 matches
Mail list logo
