Re: REPL using Emacs Cider

Hi Timur, I've seen weird errors when not using lein2. What version of lein are you using? On Sun, Jun 1, 2014 at 11:52 AM, Timur wrote: > hi everyone, I have a question about using nREPL (cider) in Emacs. > > In my clojurescript project, I start the repl server using cider-jack-in > command.

Re: REPL

2014-04-08 14:34 GMT+02:00 Di Xu : > cursor movement requires readline > library > support, I assume you start clojure by > using > > > java -cp bin/clojure- > * > .jar clojure.main > > you can add readline library via > > rlwrap java -cp bin/clojure-*.jar clojure.main > Works like a charm. >

Re: REPL

cursor movement requires readline library support, I assume you start clojure by using java -cp bin/clojure- * .jar clojure.main you can add readline library via rlwrap java -cp bin/clojure-*.jar clojure.main or you can do this using lein , and start

Re: REPL

Leiningen is really the place to start, it bundles REPL-y, which includes these features. Follow the instructions to install: http://leiningen.org/ Then you can simply 'lein repl' in a project root (with the project's dependencies) or it'll just open up a basic repl. On Tue, Apr 8, 2014 at 8:01

Re: REPL Reloaded

BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new mem

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL: viewing data structures containing infinite lists

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.

Re: REPL: viewing data structures containing infinite lists

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

Re: REPL behavior different from running from a file

The "won't terminate" part is due to background threads being created by the call to pmap, and by default it will wait 60 seconds before exiting. If you don't wait that long, it definitely appears like it is hung. If you look on the ClojureDocs entry for pmap, the last example says to see the

Re: repl hanging sometimes in lein2?

On Fri, May 18, 2012 at 4:16 PM, Jim - FooBar(); wrote: > It seems that the known issue of lein1 (repl hanging sometimes after > printing), is still present on lein2... The only way to avoid this is to aot > compile at least one namespace and then do  "lein2 run", which is exactly > what I used to

Re: repl dodges ns :use :only ?

On Sat, 2011-11-19 at 08:15 -0800, Andrew wrote: > (Import only function bar from > library foo - renaming foo to f - requiring my own code to say f/bar and > ensuring that foo/baz and f/baz and baz don't work since baz is not > imported?) You can't do this within the confines of an ns form; it

Re: repl dodges ns :use :only ?

And how can I get what I originally wanted? (Import only function bar from library foo - renaming foo to f - requiring my own code to say f/bar and ensuring that foo/baz and f/baz and baz don't work since baz is not imported?) -- You received this message because you are subscribed to the Goog

Re: repl dodges ns :use :only ?

Sure, just remove the :as argument: (ns example.ns (:use [clojure.string :only (join)]) On Friday, November 18, 2011, Andrew wrote: > Oh, thanks. Is there a way to "import" some functions and not others such that the others cannot be used at all? > > -- > You received this message because you

Re: repl dodges ns :use :only ?

Oh, thanks. Is there a way to "import" some functions and not others such that the others cannot be used at all? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new m

Re: repl dodges ns :use :only ?

The :as clause establishes an alias for the entire clj-webdriver.core namespace. The value of :only lists the vars from that namespace that are referred into my-proj.core, which you can use without qualification e.g. `(attribute …)` will work, but `(start …)` won't. Both `(cw/attribute …)` and

Re: REPL magic: get the previous expression?

My particular use-case was to be able to write tests for things entered at the REPL. I'm almost done with a basic version of it and will post it to the list when done. It would be much easier if the expressions were there anyway. I guess the issue is that people may not always be using Lein or R

Re: REPL magic: get the previous expression?

The up-arrow key can recall the expressions you send thanks to either readline or Leiningen. You might be able to hook the appropriate var in leiningen.repl in order to slip your own function into the options passed to the Clojure REPL it starts. You need to be able to intercept the form being

Re: REPL magic: get the previous expression?

I mean I want to write a utility that has access to the previous expression entered at the REPL no matter where this utility is called. Since the up-arrow key has this access, it must be possible On Nov 9, 12:57 pm, Michael Beattie wrote: > What do you mean?  If it's programatically then why

Re: REPL magic: get the previous expression?

What do you mean? If it's programatically then why not use a loop or something? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be

Re: repl output for list seems inconsistent and a holdover from yesteryear

One clarification that might help is that traditionally the list has been the only structure in lisps, and other data representations were faked with lists. Clojure added other modern data structures to that traditional model (those are what are generally used for "data" purposes) and left the lis

Re: repl output for list seems inconsistent and a holdover from yesteryear

I think I understand more now though, everyone. Thanks. clojure chose lists for the data structure for code so lists sort of have a special place in the language. Thanks again. On Fri, Oct 28, 2011 at 1:13 AM, e wrote: > > > On Thu, Oct 27, 2011 at 8:26 PM, Mark Rathwell wrote: > >> > Maybe i

Re: repl output for list seems inconsistent and a holdover from yesteryear

On Thu, Oct 27, 2011 at 8:26 PM, Mark Rathwell wrote: > > Maybe it would be clearer if I proposed some other, lesser-used chars, > like > > "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this > > needs to be treated as data and not eval'd" as I am simply saying, "this > is >

Re: repl output for list seems inconsistent and a holdover from yesteryear

On Thu, Oct 27, 2011 at 7:42 PM, Stephen C. Gilardi wrote: > > On Oct 26, 2011, at 7:08 PM, e wrote: > > > [1 2 3] is a vector that is not evaluated. Since there is no overload > with things that are, there's no need for a special mark. > > If you type [1 2 3] into the REPL it is evaluated. The E

Re: repl output for list seems inconsistent and a holdover from yesteryear

> Maybe it would be clearer if I proposed some other, lesser-used chars, like > "%(1 2 3 4)" or even "<1 2 3 4>".  That is, I'm not so much saying, "this > needs to be treated as data and not eval'd" as I am simply saying, "this is > the 'list' data structure as opposed to some other". A list data

Re: repl output for list seems inconsistent and a holdover from yesteryear

On Oct 26, 2011, at 7:08 PM, e wrote: > [1 2 3] is a vector that is not evaluated. Since there is no overload with > things that are, there's no need for a special mark. If you type [1 2 3] into the REPL it is evaluated. The E part of the REPL always runs. Some expressions evaluate to themsel

Re: repl output for list seems inconsistent and a holdover from yesteryear

You can also use the list function if you don't care about syntactic sugar, and it seems. Like it should look like this: => (list 1 2 3 4) '(1 2 3 4) or <1 2 3 4> <-- although i'd use that for vectors and use [] for lists. Wouldn't that be cool? I imagine (set 1 2 3 4) prints as #{1 2 3 4} On Oc

Re: repl output for list seems inconsistent and a holdover from yesteryear

On Oct 26, 2011 7:15 PM, "Stuart Halloway" wrote: >> >> checking out the "Try Clojure": >> >> if you type the following, you get output that matches what you typed >> in every case except for lists. >> >> Vectors: --> [1 2 3 4] >> [1 2 3 4] >> >> Maps: --> {:foo "bar" 3 4} >> {:foo "bar" 3 4} >> >

Re: repl output for list seems inconsistent and a holdover from yesteryear

Hi! Well [1 2 3] is just a syntaxic sugar for (vector 1 2 3): =>(vector 1 2 3) [1 2 3] When you enter a vector in the repl, it is evaluted to itself. Here an example that show it: =>[1 2 (+ 1 2)] [1 2 3] And you can use the vector function for the same result: =>(vector 1 2 (+ 1 2)) [1 2 3] The

Re: repl output for list seems inconsistent and a holdover from yesteryear

More reasonable.. On Oct 27, 7:15 am, Stuart Halloway wrote: > > checking out the "Try Clojure": > > > if you type the following, you get output that matches what you typed > > in every case except for lists. > > > Vectors: --> [1 2 3 4] > > [1 2 3 4] > > > Maps: --> {:foo "bar" 3 4} > > {:foo "b

Re: repl output for list seems inconsistent and a holdover from yesteryear

> '(1 2 3) is a list that is not evaluated.  No loss of generality.  it's a > special type of list.  One that's not evaluated.  as opposed to a special > indicator to the repl. That would essentially be a new data structure, filling a role mostly already filled by vectors. And you would still nee

Re: repl output for list seems inconsistent and a holdover from yesteryear

> checking out the "Try Clojure": > > if you type the following, you get output that matches what you typed > in every case except for lists. > > Vectors: --> [1 2 3 4] > [1 2 3 4] > > Maps: --> {:foo "bar" 3 4} > {:foo "bar" 3 4} > > Lists: --> '(1 2 3 4) > (1 2 3 4) <- *INCONSISTENT* why

Re: repl output for list seems inconsistent and a holdover from yesteryear

not necessarily. [1 2 3] is a vector that is not evaluated. Since there is no overload with things that are, there's no need for a special mark. '(1 2 3) is currently a way of say, "don't evaluate this list", but it could have been: '(1 2 3) is a list that is not evaluated. No loss of generali

Re: repl output for list seems inconsistent and a holdover from yesteryear

The point to think about here is that functions are also lists, the same as your list of integers. The difference is that one is evaluated, the other is not. That is what the quote is saying: "don't evaluate me". The quote is not actually a part of the list. It's just the way you tell the reader

Re: REPL and Leiningen checkouts

A Maven project, yes. Just "mounting" a directory as a project and editing resources tells IntelliJ nothing about the projects in question. See: http://wiki.jetbrains.net/intellij/Creating_and_importing_Maven_projects#Importing_an_existing_Maven_project_into_an_IntelliJ_IDEA_project What I saw

Re: REPL and Leiningen checkouts

Thanks for the reply Chas. Does that mean that I have to create a Java project inside IntelliJ, instead of just opening the directory containing a Clojure/Lein project? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send emai

Re: REPL and Leiningen checkouts

FWIW, IntelliJ (like Eclipse) has excellent Maven support, which includes (IIRC, haven't touched IDEA in a long time) the equivalent of Eclipse's workspace dependency resolution. So, if you have project A that depends on vX of project B and vY of project C, then the IDE will add the compilation

Re: REPL and Leiningen checkouts

I'm currently using La Clojure. Not sure if I can directly hook it to lein. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patien

Re: REPL and Leiningen checkouts

2011/8/16 J. Pablo Fernández : > I want to play around with a library I'm using so I started using the > Leiningen checkouts feature and if I do lein repl it works. But when I'm > running the REPL inside my editor I'm not running it through lein. Any ideas > how to get my REPL to pick up checkouts

Re: REPL bug: premature submission hitting enter with unmatched [

On Sat, Apr 2, 2011 at 7:01 PM, Alan wrote: > Works fine for me in slime, came repl, and java -jar clojure.jar. The > indentation isn't so hot for the raw repl, but what can you expect? > The repl is fine; perhaps you should tell us how you're launching your > repl, since that seems to be the sour

Re: REPL bug: premature submission hitting enter with unmatched [

Works fine for me in slime, came repl, and java -jar clojure.jar. The indentation isn't so hot for the raw repl, but what can you expect? The repl is fine; perhaps you should tell us how you're launching your repl, since that seems to be the source of the problem. ;; TABs added by me - the repl pu

Re: REPL+Laziness: the worst combination ever!

On Sat, Jan 8, 2011 at 5:15 PM, Stuart Halloway wrote: > Scopes will not make dynamic bindings linger in lazy seqs. Agreed that is a > terrible idea. In other words scopes would have only half-solved the problem anyway? Ack. -- You received this message because you are subscribed to the Google

Re: REPL+Laziness: the worst combination ever!

> On Sat, Jan 8, 2011 at 3:11 PM, Laurent PETIT wrote: >> 2011/1/8 Ken Wesson >>> >>> On Sat, Jan 8, 2011 at 2:09 PM, Laurent PETIT >>> wrote: 2011/1/8 Ken Wesson > > On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway > wrote: >> One goal of resource scopes [1] is to help

Re: REPL+Laziness: the worst combination ever!

2011/1/8 Ken Wesson > On Sat, Jan 8, 2011 at 3:11 PM, Laurent PETIT > wrote: > > 2011/1/8 Ken Wesson > >> > >> On Sat, Jan 8, 2011 at 2:09 PM, Laurent PETIT > >> wrote: > >> > 2011/1/8 Ken Wesson > >> >> > >> >> On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway > >> >> wrote: > >> >> > One go

Re: REPL+Laziness: the worst combination ever!

On Sat, Jan 8, 2011 at 3:11 PM, Laurent PETIT wrote: > 2011/1/8 Ken Wesson >> >> On Sat, Jan 8, 2011 at 2:09 PM, Laurent PETIT >> wrote: >> > 2011/1/8 Ken Wesson >> >> >> >> On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway >> >> wrote: >> >> > One goal of resource scopes [1] is to help with sc

Re: REPL+Laziness: the worst combination ever!

2011/1/8 Ken Wesson > On Sat, Jan 8, 2011 at 2:09 PM, Laurent PETIT > wrote: > > 2011/1/8 Ken Wesson > >> > >> On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway > >> wrote: > >> > One goal of resource scopes [1] is to help with scoping activities at > >> > the REPL. That said, I think this is a

Re: REPL+Laziness: the worst combination ever!

On Sat, Jan 8, 2011 at 2:09 PM, Laurent PETIT wrote: > 2011/1/8 Ken Wesson >> >> On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway >> wrote: >> > One goal of resource scopes [1] is to help with scoping activities at >> > the REPL. That said, I think this is a "ramping up" problem -- I rarely if >

Re: REPL+Laziness: the worst combination ever!

On Jan 8, 12:25 pm, Brian Goslinga wrote: > I find that if your code is functional, laziness works quite well > (except for the rare expensive function + chunking problem). > > Perhaps your code isn't very functional? (your mention of binding > suggests that) That's a valid observation, most of t

Re: REPL+Laziness: the worst combination ever!

Didn't knew about scope, it looks like an interesting feature. Still as you point this is pretty much a problem BKAC! On Jan 8, 12:33 pm, Stuart Halloway wrote: > One goal of resource scopes [1] is to help with scoping activities at the > REPL. That said, I think this is a "ramping up" problem -

Re: REPL+Laziness: the worst combination ever!

2011/1/8 Ken Wesson > On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway > wrote: > > One goal of resource scopes [1] is to help with scoping activities at the > REPL. That said, I think this is a "ramping up" problem -- I rarely if ever > hit it anymore. > > > > Stu > > > > [1] http://dev.clojure

Re: REPL+Laziness: the worst combination ever!

On Sat, Jan 8, 2011 at 12:33 PM, Stuart Halloway wrote: > One goal of resource scopes [1] is to help with scoping activities at the > REPL. That said, I think this is a "ramping up" problem -- I rarely if ever > hit it anymore. > > Stu > > [1] http://dev.clojure.org/display/design/Resource+Scope

Re: REPL+Laziness: the worst combination ever!

One goal of resource scopes [1] is to help with scoping activities at the REPL. That said, I think this is a "ramping up" problem -- I rarely if ever hit it anymore. Stu [1] http://dev.clojure.org/display/design/Resource+Scopes > I've been doing a lot of Clojure lately and, of all thing, > col

Re: REPL+Laziness: the worst combination ever!

On Jan 7, 7:03 pm, Nicolas Buduroi wrote: > I've been doing a lot of Clojure lately and, of all thing, > collection's laziness coupled with a REPL is what makes me loose the > most time. I really love having laziness built-in by default and I'm a > REPL-driven development addict, but sometimes I j

Re: REPL+Laziness: the worst combination ever!

I do this too on occasion, and my opinion is: better to chase them in the REPL than in deployed code, because the same problem would usually come up there. On Jan 7, 5:03 pm, Nicolas Buduroi wrote: > I've been doing a lot of Clojure lately and, of all thing, > collection's laziness coupled with a

Re: REPL

This. And to clarify, in case it's unclear: every function in Clojure must return a value - there are no "void" functions as in Java. print and println, therefore, in addition to printing their data, must return something (they choose nil), and the REPL always prints out the return value of whateve

Re: REPL

On Wed, 8 Sep 2010 11:26:38 -0700 (PDT) Sean wrote: > Hi, > > I'm new to Clojure. This is also my first time posting here. > When I use REPL and print something out, I always get a nil printed. > For example, (print "Clojure"), I got: clojurenil. Where does the nil > come from? REPL stands for

Re: REPL

On Wed, Sep 8, 2010 at 2:26 PM, Sean wrote: > Hi, > > I'm new to Clojure. This is also my first time posting here. > When I use REPL and print something out, I always get a nil printed. > For example, (print "Clojure"), I got: clojurenil. Where does the nil > come from? > > Thanks a lot! > Try

Re: REPL

Hi, On 19 Aug., 23:43, Alan wrote: > Ctrl-C works too, and is what I would try first on Windows. Ctrl-C is a rather hard way to shutdown things. Compare to turning off the computer without flushing the disk caches. With JLine Ctrl-D also works on Windows. Sincerely Meikel -- You received thi

Re: REPL

I use Ctrl-D on linux, but Ctrl-C works too, and is what I would try first on Windows. (System/exit 0) won't work if you're using leiningen to get your repl, because it passes I/O through JLine and System.exit terminates the clojure process without notifying the JLine process: $ lein repl user=>

Re: REPL

I use Ctrl+D. But I am on Linux. On Thu, Aug 19, 2010 at 4:28 PM, Abraham Varghese wrote: > How to exit from REPL? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that post

Re: REPL

Control-D on Unix, Control-Z Enter on Windows, (System/exit 0) On 19 Aug., 17:28, Abraham Varghese wrote: > How to exit from REPL? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note tha

Re: repl, Linux, up-arrow to repeat

On 5 June 2010 12:23, Ramakrishnan Muthukrishnan wrote: > On Sat, Jun 5, 2010 at 4:48 PM, Dave Pawson wrote: >> On many interactive shells I use up-arrow to repeat >> the last command. >> >> Is that possible with the clojure repl, Linux? > > You can use rlwrap or jline with the repl invocation co

Re: repl, Linux, up-arrow to repeat

On Sat, Jun 5, 2010 at 4:48 PM, Dave Pawson wrote: > On many interactive shells I use up-arrow to repeat > the last command. > > Is that possible with the clojure repl, Linux? You can use rlwrap or jline with the repl invocation command. $ rlwrap java -cp /usr/share/java/clojure.jar clojure.main

Re: REPL and its command prompt

Well, while I don't like it much, there are in fact REPLs that work the way he expects, e.g. SBCL's: This is SBCL 1.0.24, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty.

Re: REPL and its command prompt

It's clear that a REPL used interactively must respond as it does, otherwise it's appear hanged. Do you have a particular scenario for your code? I thought about recreating or documenting a session, but you can't see the input, only the REPL's output. On Apr 2, 12:23 am, Michael Jaaka wrote: > Hi

Re: REPL and its command prompt

In most character-buffered REPLs the enter key serves two purposes: quoting a new line character and submitting input to the REPL. Some systems like Mathematica require a special key combination like shift-enter or control-enter to submit input. That is a clean separation of concerns but it is awfu

Re: REPL behaviour / time / lazyness

Ah, brilliant, many thanks Laurent! Interesteresting stuff under the hood .. Kind regards, alux Laurent PETIT schrieb: > hi, follow links from here: > http://www.infoq.com/news/2009/12/clojure-11-rc1-transients > > chunked sequences have their first elements realized in advanced by > packets of

Re: REPL behaviour / time / lazyness

hi, follow links from here: http://www.infoq.com/news/2009/12/clojure-11-rc1-transients chunked sequences have their first elements realized in advanced by packets of 32 Under the hoods, it seems that range uses chunked sequences ( http://github.com/richhickey/clojure/blob/master/src/clj/clojure/

Re: REPL behaviour / time / lazyness

Yes, chunked sequences explain the behaviour, look: 1:1 user=> (set! *print-length* 10) 10 1:2 user=> (defn fib0 [n] (let [fib (fn fib [n] (if (< n 1) 1 (+ (fib (- n 1)) (fib (- n 2)] (println (str "fib0[" n "]")) (fib n))) #'user/fib0 1:7 user=> (time (map fib0 (iterate inc 0))) "

Re: REPL behaviour / time / lazyness

Laurent, > Could chunked seqs explain something here ? sounds possible. If I only knew what this is ;-) Regards, alux Laurent PETIT schrieb: > 2010/3/19 alux : > > ;-) > > > > Still, I dont believe. > > > > I get the same difference with > > > > user=> (time (map fib0 (range 100))) > > "Elapsed

Re: REPL behaviour / time / lazyness

Meikel, you are right, I changed horses, uh, definitions inbetween. So the REPL interaction of my last response should read Clojure 1.1.0 user=> (set! *print-length* 10) 10 user=> (defn fib0 [n] (if (< n 1) 1 (+ (fib0 (- n 1)) (fib0 (- n 2) #'user/fib0 user=> (time (map fib0 (range 100))) "El

Re: REPL behaviour / time / lazyness

Hi, On Mar 19, 1:39 pm, alux wrote: > Still, I dont believe. You should... > > I get the same difference with > > user=> (time (map fib0 (range 100))) > "Elapsed time: 1.916445 msecs" > > more than 5 seconds > > (0 1 1 2 3 5 8 13 21 34 ...) > > user=> (time (map fib0 (iterate inc 0))) > "Elaps

Re: REPL behaviour / time / lazyness

2010/3/19 alux : > ;-) > > Still, I dont believe. > > I get the same difference with > > user=> (time (map fib0 (range 100))) > "Elapsed time: 1.916445 msecs" > > more than 5 seconds > > (0 1 1 2 3 5 8 13 21 34 ...) > > user=> (time (map fib0 (iterate inc 0))) > "Elapsed time: 0.104203 msecs" > (0

Re: REPL behaviour / time / lazyness

;-) Still, I dont believe. I get the same difference with user=> (time (map fib0 (range 100))) "Elapsed time: 1.916445 msecs" more than 5 seconds (0 1 1 2 3 5 8 13 21 34 ...) user=> (time (map fib0 (iterate inc 0))) "Elapsed time: 0.104203 msecs" (0 1 1 2 3 5 8 13 21 34 ...) Hm. Regards, al

Re: REPL behaviour / time / lazyness

Hi, On Mar 19, 12:34 pm, alux wrote: > You didnt try this, as I can judge, because you responded in finite > time ;-) Ah, yes. Intersperse with (take 10 ...) at will. :) > My main irritation is still: Why do my range and my iterate version > differer in their print beheavior? Because with ran

Re: REPL behaviour / time / lazyness

You didnt try this, as I can judge, because you responded in finite time ;-) (fib0 35) takes 20 seconds already. So your suggestion (time (doall (map fib0 (range 100))) will do all up to 100, time it, and print the first ten, in that order. (fib0 100) takes a good while (I just estimaded 15 mill

Re: REPL behaviour / time / lazyness

Hi, On Mar 19, 11:27 am, alux wrote: > user=> (time (fib0 35)) > "Elapsed time: 20874.18345 msecs" > 24157817 > > user=> (time (map fib0 (iterate inc 1))) > "Elapsed time: 0.913524 msecs" > (2 3 5 8 13 21 34 55 89 144 ...) > > Everything fine. > Now what puzzles me: > > user=> (time (map fib0 (r

Re: REPL, refs and casting

Hi Mike, On 10 March 2010 21:03, Mike Erickson wrote: > I am writing a simple blackjack game in Clojure I've written up a little commentary as to how I'd approach this problem differently: http://gist.github.com/328929 which hopefully will give you some ideas. The general thrust being to keep yo

Re: REPL, refs and casting

On 11 March 2010 17:15, Timothy Pratley wrote: > You probably want to use conj instead of concat! Actually ignore that! I was being confused by the deck-building. Can you try running this code: http://gist.github.com/328912 It is exactly the same as yours but uses known starting conditions... and

Re: REPL, refs and casting

On 11 March 2010 17:10, Timothy Pratley wrote: > I tried running your code and it worked fine for me... Ah excuse me it only 'worked' because I used vectors instead of lists: > [5 \S]]] [:player []]), :house ([:house []]), :deck nil} <--- should give you the clue you need, You probably want to

Re: REPL, refs and casting

On 10 March 2010 21:03, Mike Erickson wrote: > but calling (deal 2 :house) bombs out with the following stacktrace: Hi Mike, I tried running your code and it worked fine for me... so I think something else is playing tricks on you here like maybe you changed the function in your text buffer but

Re: REPL in a browser

You mean Clojurescript? http://github.com/richhickey/clojure-contrib/tree/master/clojurescript/ It would be great to have more people working on it... On Mar 9, 12:12 pm, Jozef Wagner wrote: > Thank you. > > They seem to use java to generate (with GWT) both client-side html and > javascript, an

Re: REPL in a browser

Thank you. They seem to use java to generate (with GWT) both client-side html and javascript, and server-side REPL. Nice approach. I'm looking forward to the day when one will be able to do all that only with clojure :) We already have a nice clojrue web frameworks, so the only thing that is miss

Re: REPL in a browser

There is a Clojure REPL in a browser implementation I know: http://lotrepls.appspot.com/ Project home http://code.google.com/p/lotrepls/ They support - beanshell * - clojure - groovy * - javascript * - python * - ruby * - scala * - scheme using Google App Engine as back

Re: REPL vs Script + Regex Problem!

On 3 February 2010 08:58, Meikel Brandmeyer wrote: > condp was specifically designed to be a scheme-like cond with :>> > support and such. Well, I like condp a lot (really, condp FTW! -- definately worth a define-syntax in Scheme :-)), but it's nothing like Scheme's cond (which is a good thing, a

Re: REPL vs Script + Regex Problem!

Hi, On Feb 3, 1:54 am, Michał Marczyk wrote: > Something I wanted to mention is that this could provide a use case > for an Scheme style cond macro, especially if the processing logic got > more involved -- have a look at my scond if you'd like: > > http://gist.github.com/293212 > > Basically th

Re: REPL vs Script + Regex Problem!

Something I wanted to mention is that this could provide a use case for an Scheme style cond macro, especially if the processing logic got more involved -- have a look at my scond if you'd like: http://gist.github.com/293212 Basically this would allow you to write things like (scond [(re-matches

Re: REPL vs Script + Regex Problem!

(some) definitely seems like the way to go. Now I've got to move onto my next problem, which is totally the number of duplicate files and the bytes they take up. I'm guessing at this point that something like (reduce) will be the way to go. Thanks for all your help. This won't be the last time you

Re: REPL vs Script + Regex Problem!

On 3 February 2010 00:50, ataggart wrote: > It occurs to me you could use 'some instead of nested if-lets: > > (some identity >  [(first (re-matches #"([0-9]+) byte\(null\)each:" line)) >   (first (re-matches #".*(\.[0-9a-zA-Z]+)" line))]) A simplified version: (some #(first (re-matches % line))

Re: REPL vs Script + Regex Problem!

It occurs to me you could use 'some instead of nested if-lets: (some identity [(first (re-matches #"([0-9]+) byte\(null\)each:" line)) (first (re-matches #".*(\.[0-9a-zA-Z]+)" line))]) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to t

  1   2   >