Small line-seq regression?

[Mark Triggs]

Hi all,

I recently pulled down the latest Clojure master branch and have noticed
a small change in line-seq's behaviour which breaks some of my code.
The code in question uses line-seq like this:

(use 'clojure.contrib.duck-streams)
(with-open [ss (java.net.ServerSocket. 4141)]
(println (first (line-seq (reader (.accept ss))))))

If I run this then telnet to the listen port and send a single line:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hi

The above code prints nothing until the *second* line arrives from the
socket, even though that line isn't required to fulfil my (first ...)
request. It appears this behaviour changed in patch 284ee8aa in an
effort to make line-seq return nil (instead of ()) for an empty lazy
seq. The line-seq definition currently reads:

(defn line-seq
"Returns the lines of text from rdr as a lazy sequence of strings.
rdr must implement java.io.BufferedReader."
[#^java.io.BufferedReader rdr]
(let [line (. rdr (readLine))]
(when line
(lazy-seq (cons line (line-seq rdr))))))

and when my code above is blocked, it's because my call to 'first' has
caused the first recursive call to be made, which immediately blocks on
the now-eagerly-performed readLine for the second line of input. Taking
the line to be returned out of the lazy-seq seems to fix things for me:

(defn line-seq
"Returns the lines of text from rdr as a lazy sequence of strings.
rdr must implement java.io.BufferedReader."
[#^java.io.BufferedReader rdr]
(let [line (. rdr (readLine))]
(when line
(cons line (lazy-seq (line-seq-new rdr))))))

and, I think, still preserves the intention of the original change.
Does that seem reasonable?

Thanks,

Mark

--
Mark Triggs
<mark.h...@gmail.com>

[Chouser]

Your analysis and solution seem right to me. Rich, would you
accept a ticket for this?

--Chouser

[Rich Hickey]

Yes, and could someone please check the other functions that were
patched similarly?

Thanks,

Rich

[Meikel Brandmeyer]

Hi,

Am 14.12.2009 um 01:07 schrieb Mark Triggs:

> (defn line-seq
> "Returns the lines of text from rdr as a lazy sequence of strings.
> rdr must implement java.io.BufferedReader."
> [#^java.io.BufferedReader rdr]
> (let [line (. rdr (readLine))]
> (when line
> (lazy-seq (cons line (line-seq rdr))))))

Huh? Is there a reason, why it doesn't look like this:

(defn line-seq
"Returns the lines of text from rdr as a lazy sequence of strings.
rdr must implement java.io.BufferedReader."
[#^java.io.BufferedReader rdr]

(lazy-seq
(when-let [line (.readLine rdr)]
(cons line (line-seq rdr)))))

Is there some benefit treating a line-seq different to any other seq?

Sincerely
Meikel

[Rich Hickey]

The objective is to treat it like any (seq x) call, i.e. returning
nil if nothing there. line-seq et al are not sequence processing
functions like map/filter. They are seq obtainers. It's more like (seq
[])

Rich

[Sean Devlin]

Is this a 1.1 or 1.2 fix?

[Rich Hickey]

On Dec 14, 4:14 pm, Sean Devlin <francoisdev...@gmail.com> wrote:
> Is this a 1.1 or 1.2 fix?
>

1.1, thanks

Rich

[Drew Raines]

Rich Hickey wrote:

> On Mon, Dec 14, 2009 at 8:48 AM, Chouser <cho...@gmail.com> wrote:

[...]

>> Your analysis and solution seem right to me.  Rich, would you
>> accept a ticket for this?
>>
>
> Yes, and could someone please check the other functions that were
> patched similarly?

I'll do it since I created the original patch.

https://www.assembla.com/spaces/clojure/tickets/222

-Drew

[Mark Triggs]

Many thanks everyone.

Cheers,