Maik Schünemann writes:
> There is real no sensible default value rather than the current.
I would say that there is no sensible default value *including* the
current. Certainly at REPL usage, the current value is probably the
least sensible.
My sensible default is 32.
Phil
--
You received
kovas boguta writes:
> Chalk this up as another cautionary tale about global singletons.
It's dynamic, so it can be bound for a repl thread!
> What we need is a parameterizable write-edn function, mirroring the
> already extant read-edn. The function should guarantee it will either
> write valid
Andy mentioned files, but yes, in a pipe this is true. Still, it's not
true on the REPL; I can't think of an obvious use case there, and if
there is one then having the programmer work around something like
*interactive-print-length* would be reasonable.
Note that we are talking about an infinite
If you're using cider (https://github.com/clojure-emacs/cider), there's a
convenience function for controlling the value of *print-length*, including
giving it a default value for new nrepl instances:
https://github.com/clojure-emacs/cider#limiting-printed-output-in-the-repl
/Ragnar
On Tuesday
Chalk this up as another cautionary tale about global singletons.
There can be only one print-method, yet we have two conflicting use
cases: repl interaction, and data transport.
What we need is a parameterizable write-edn function, mirroring the
already extant read-edn. The function should guara
There is real no sensible default value rather than the current.
But for me the current behaviour is no problem, just C-c C-c to interrupt
evaluation (at least in cider)
On Tue, Apr 1, 2014 at 7:02 PM, Gary Trakhman wrote:
> It's possible for an infinite print to be just fine, it's a streaming AP
It's possible for an infinite print to be just fine, it's a streaming API
after all, consider invoking a clojure program in the middle of some unix
pipes.
On Tue, Apr 1, 2014 at 12:58 PM, Phillip Lord
wrote:
>
> Of course, in this circumstances, infinitely long lists are not going to
> behave we
Of course, in this circumstances, infinitely long lists are not going to
behave well either.
But, it seems to me, that this is (or should be) independent of
interactive use in the REPL. The current behaviour is never nice.
Probably, there needs to be a *interactive-print-length* var or
equivalent
Yea, print is generalized to a java PrintWriter class, I think, the
requirements of repl usage are not the only ones.
On Tuesday, April 1, 2014, A. Webb wrote:
>
>
> On Tuesday, April 1, 2014 11:00:37 AM UTC-5, Andreas Liljeqvist wrote:
>>
>> Is there any good reason for not providing a default
On Tuesday, April 1, 2014 11:00:37 AM UTC-5, Andreas Liljeqvist wrote:
>
> Is there any good reason for not providing a default value for
> *print-length*?
> I think that if you *really* want to print a list containing 100K items,
> you would have to set *print-length*.
>
> Basically it seems l
One argument for default value of *print-length* being nil: Plenty of
people print Clojure data structures to files and later read them back in.
The data would be corrupted if *print-length* was a too-small numeric value
for your particular data. It might not be obvious until much later that
you h
I'd be interested in knowing this as well. Lots of tutorials have
things like
(take 10 (range))
followed by statements that range on it's own will break your REPL.
Seems to me a common gotcha for Clojure.
Phil
Andreas Liljeqvist writes:
> Is there any good reason for not providing a defaul
Is there any good reason for not providing a default value for
*print-length*?
I think that if you *really* want to print a list containing 100K items,
you would have to set *print-length*.
Basically it seems less harmful to set it to a nice value by default(42?)
than possible locking up the REPL.
http://clojuredocs.org/clojure_core/clojure.core/*print-length*
On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard wrote:
> Is there some kind of "safe" function for printing representations of
> lazy, infinite data structures? I'm finding I like using them inside
> other data structures here a
14 matches
Mail list logo
