Clojure

(take-nth 0 coll) redux...

Details

  • Type: Enhancement Enhancement
  • Status: In Progress In Progress
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Backlog
  • Component/s: None
  • Labels:
    None
  • Approval:
    Vetted

Description

I dont seem to be able make the old ticket uninvalid so here goes
(take-nth 0 coll) causes (at least on Solaris) infinite space and time consumption
It's not a printout error as the following code causes the problem too

(let [j 0
firstprod (apply * (doall (map #(- 1 %) (take-nth j (:props mix)))))]) ; from my parameter update function

I used jvisualvm and the jvm is doing some RNI call - no clojure code is running at all
If left alone it will crash the jvm with all heap space consumed
0 is an InvalidArgument for take-nth
I wouldnt mind if it produced an infinite lazy sequence of nils even though thats wrong
It doesnt do this though it actively destroys the JVM
Its a bug nasty destructive and it took me half a day to figure out what was going on
please let someone fix it!

Activity

Hide
Assembla Importer added a comment -

bhurt said: Before this bug gets marked as invalid as well, let me point out that the problem here is that (take-nth 0 any-list) is a meaningless construction- the only question is what to do when this happens. IMHO, the correct behavior is to throw an exception.

Show
Assembla Importer added a comment - bhurt said: Before this bug gets marked as invalid as well, let me point out that the problem here is that (take-nth 0 any-list) is a meaningless construction- the only question is what to do when this happens. IMHO, the correct behavior is to throw an exception.
Hide
Assembla Importer added a comment -

ataggart said: [file:dfNhoS2Cir3543eJe5cbLA]: throws IllegalArgumentException on negative step size

Show
Assembla Importer added a comment - ataggart said: [file:dfNhoS2Cir3543eJe5cbLA]: throws IllegalArgumentException on negative step size
Hide
Stuart Halloway added a comment -

Does calling (take-nth 0 ...) cause the problem, or only realizing the result?

Show
Stuart Halloway added a comment - Does calling (take-nth 0 ...) cause the problem, or only realizing the result?
Hide
Chouser added a comment -

I'm not seeing a problem. Calling take-nth and even partially consuming the seq it returns works fine for me:

(take 5 (take-nth 0 [1 2 3]))
;=> (1 1 1 1 1)

Note however that it is returning an infinite lazy seq. The example in the issue description seems to include essentially (doall <infinite-lazy-seq>) which does blow the heap:

(doall (range))

This issue still strikes me as invalid.

Show
Chouser added a comment - I'm not seeing a problem. Calling take-nth and even partially consuming the seq it returns works fine for me: (take 5 (take-nth 0 [1 2 3])) ;=> (1 1 1 1 1) Note however that it is returning an infinite lazy seq. The example in the issue description seems to include essentially (doall <infinite-lazy-seq>) which does blow the heap: (doall (range)) This issue still strikes me as invalid.
Hide
Rich Hickey added a comment -

(take-nth 0 ...) returns an infinite sequence of the first item:

(take 12 (take-nth 0 [1 2 3]))
=> (1 1 1 1 1 1 1 1 1 1 1 1)

Is something other than this happening on Solaris?

Show
Rich Hickey added a comment - (take-nth 0 ...) returns an infinite sequence of the first item: (take 12 (take-nth 0 [1 2 3])) => (1 1 1 1 1 1 1 1 1 1 1 1) Is something other than this happening on Solaris?

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: