Hi Nehal,
You can use "scroll-other-window" and "scroll-other-window-up", which are
bound to "C-M-v" and "C-M-S-v" respectively. These will scroll the next
window (i.e. the window that "C-x o" would switch to) up or down by a page.
Check out the help page for "scroll-other-window" for more info
Thanks all :)
@A. Webb: I knew it must be something dopey, thanks for the advice!
@Lee That is indeed exactly what I'm trying to do, and that method is much
more elegant and straightforward. In fact, precisely what I'm trying to do
is write some notes on symbolic regression for some students, w
2014-03-29 3:40 GMT+01:00 Christopher Howard :
>
> Is that "webnf" package the thing I am supposed to put in my
> "dependencies" list? Version 0.0.1 doesn't sound right. Or am I
> supposed to download something myself and throw it in my lib
> directory?
>
For clarification: webnf.deps packages are
ANother step further
Thanks for the help..
I set up the diretory struc and can import the class.
Now to get the call working.
On Friday, March 28, 2014 10:12:08 AM UTC-5, bww00...@yahoo.com wrote:
>
> I have read so much i cant see the tree for the forest.
> and need some help calling the ocfLZW
On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote:
>
> I know this is a silly example but I am curious to know what is happening
> with the proxy method.
>
> I have set up two calls to proxy:
>
> 1.
> (def cp
> (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] []))
>
> 2.
>
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.
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
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
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
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
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
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
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
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
I'm having trouble using a custom :store with multipart-params. I thought
I did exactly what the documentation indicates, but I'm getting the default
behavior.
http://ring-clojure.github.io/ring/ring.middleware.multipart-params.html
:store- a function that stores a file upload. The functi
Sorry, I just realized there's a ring-specific mailing list - apologies for
the clutter.
Moved:
https://groups.google.com/d/topic/ring-clojure/O5HoT-UIWfk/discussion
On Tuesday, April 1, 2014 12:02:26 PM UTC-6, K Livingston wrote:
>
> I'm having trouble using a custom :store with multipart-params
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-2199
Leiningen dependency information:
[org.clojure/clojurescript "0.0-2199"]
The only difference is the removal of spurious warn
It's because you apply wrap-multipart-params twice. First with the default
arguments, then with your custom store. The first application of the
function is via compojure.handler/site. If you remove that, or use
handler/api instead, or apply the parameter middleware yourself, your code
should work a
I am just a newbie who has been hanging around and it is rather late in
the day to bring this up but...
should we remove lazy sequences and lazy evaluation from Clojure? Back
of the envelope calculations show that we can get 2x performance
improvements.
Thanks,
Pradip
--
You received this
Back of the envelope meaning that you thought about the implementation and
are estimating, or you have measurements?
Either way, I agree that there are definitely use cases where non-lazy
processing can give performance improvements. Probably even relatively
common use cases.
Cases where lazy se
The question is "replace them with what"? I remember with not so fond
memories the days of using IEnumerable in C#, there was no immutability and
no caching. So if you created a massive chain of data and iterated over it
twice you would have to execute the entire chain of functions twice. With
Lazy
Thanks. This is indeed what was going on. I even went checking for that
middle ware being referenced somewhere else, but didn't realize that
handler function was adding so much middle ware (didn't even bother looking
in it).
I removed the double calls and things are performing exactly as I ex
Reducers should be given IMO a more attention, support and importance and
I'm actually experimenting on a hypothesis that reducers can replace lazy
seqs in most cases (excluding simple stuff, e.g. destructuring). Imagine a
core API where functions like map, filter, rseq, range etc. are working
And Happy April Fools' everyone. Nicely done Pradip.
On Tuesday, April 1, 2014 3:58:34 PM UTC-4, Jozef Wagner wrote:
>
> Reducers should be given IMO a more attention, support and importance and
> I'm actually experimenting on a hypothesis that reducers can replace lazy
> seqs in most cases (e
So close!!
i have a question about the called java class and access to the byte array
from clojure upon return of the call to java
the call to the method in the class has 2 args buffer in and buffer out. i
confirmed that the data is in buf and nnnx contains the correct
size of the uncompresse
Ah no wonder!
I was looking at the wrong documentation for asm.
On 02/04/2014, at 1:41, "A. Webb" wrote:
>
>
> On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote:
>>
>> I know this is a silly example but I am curious to know what is happening
>> with the proxy method.
>>
>> I have
Hi David,
On Tue, Apr 1, 2014 at 2:38 PM, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> New release version: 0.0-2199
>
> The only difference is the removal of spurious warnings about
> required/imported Google Closure libraries.
As always, thank
I really want legitimate paredit in the browser.
Looking through the source for parsley & paredit.clj, I'm halfway
convinced that maybe its not so hard to port these to clojurescript.
Anyone have input in either direction?
Most of the Java interop seems to be
1. ArrayList (in parsley)
2. Various
I can't speak to the implementation of any of this, but I have to link to a
favorite demo [1] of structural editing. The animations are really slick,
but the way he's designed moving up and down the abstraction hierarchy is
brilliant. Cue an Emacs user telling me it's already possible with som
29 matches
Mail list logo
