Re: use :only in ns

2014-06-04 Thread Leonardo Borges
>
> This will make available the whole seesaw.chooser namespace available via
> prefixed notation, with the bonus that choose-file which will be accessible
> without a namespace prefix. If just a couple vars are needed, then the :use
> :only is a preferable solution.
>

Ah good point. I tend to forget about ':only' as I use :require/:refer most
of the time. Though as Linus points out, you can also use :only with
:require so that's quite convenient.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: use :only in ns

2014-06-04 Thread Linus Ericsson
Either :use with [seesaw.chooser :only [choose-file]] like

(ns ...
(:gen-class)
(:use [seesaw.chooser :only [choose-file]])

or the beefed up refer functionality:

http://clojuredocs.org/clojure_core/clojure.core/refer

which can have :only, :exclude and :rename to avoid collisions, which is
more powerful.

More info here:
http://clojure.org/libs

and yes, the seemingly random wrapping of things in lists/vectors that
sometimes should be quoted and sometimes not is confusing and has been up
to discussion several times.

in practice it works quite well, though.

/Linus

On Thursday, June 5, 2014, Glen Rubin  wrote:

> In my ns i am using a couple of libraries, e.g.
>
> (ns providence.core
>   (:gen-class)
>   (:use seesaw.chooser))
>
>
> However, I only want to use 1 or 2 commands from these libraries, for
> example (choose-file) from the above seesaw.chooser.  How do I specify only
> a single library?  thanks
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: use :only in ns

2014-06-04 Thread François Rey

On 05/06/14 08:29, Leonardo Borges wrote:

I believe you want:

(ns providence.core
  (:gen-class)
  (:require [seesaw.chooser :refer [choose-file]]))

This will make available the whole seesaw.chooser namespace available 
via prefixed notation, with the bonus that choose-file which will be 
accessible without a namespace prefix. If just a couple vars are needed, 
then the :use :only is a preferable solution.


(ns providence.core
  (:gen-class)
  (:use [seesaw.chooser :only [choose-file fn2 fn3 ...]]))

--
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: use :only in ns

2014-06-04 Thread Leonardo Borges
I believe you want:

(ns providence.core
  (:gen-class)
  (:require [seesaw.chooser :refer [choose-file]]))


Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Jun 5, 2014 at 4:08 PM, Glen Rubin  wrote:

> In my ns i am using a couple of libraries, e.g.
>
> (ns providence.core
>   (:gen-class)
>   (:use seesaw.chooser))
>
>
> However, I only want to use 1 or 2 commands from these libraries, for
> example (choose-file) from the above seesaw.chooser.  How do I specify only
> a single library?  thanks
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: use :only in ns

2014-06-04 Thread François Rey

This may help:
https://groups.google.com/forum/#!msg/clojure/cFmCkdq9tQk/I23-uiqsEwEJ 



--
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


use :only in ns

2014-06-04 Thread Glen Rubin
In my ns i am using a couple of libraries, e.g. 

(ns providence.core
  (:gen-class)
  (:use seesaw.chooser))


However, I only want to use 1 or 2 commands from these libraries, for 
example (choose-file) from the above seesaw.chooser.  How do I specify only 
a single library?  thanks

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Past and future of data.generators

2014-06-04 Thread Mars0i
clojure.core provides a minimal set of functions for random effects: rand, 
rand-int, and rand-nth, currently with no simple ability to base these on a 
resettable random number generator or on different RNGs in different 
threads.  (But see this ticket  
pointed out by Andy Fingerhut in another thread.)

data.generators includes additional useful general-purpose functions 
involving random numbers and random choices, but this is entirely not 
obvious when you read the docstrings.  (Some of the docstrings are pretty 
mysterious.)  It's also not necessarily what one would guess from the name 
of the library.  (None of this is a criticism of anyone or anything about 
the project.  Data.generators is at an 0.n.m release stage.  I'm very 
grateful for the work that people have put in on it.)

As I understand it, data.generators was split off from test.generative, 
which sounds like a good idea.So data.generators was intended to provide 
functions that generate random data for testing.  (I imagine that the 
existing documentation makes more sense in the context of test.generative, 
too.)

However, what's in data.generator has more general applications, for people 
who want random numbers, samples, etc. outside of software testing.  (In my 
case, that would be for random effects in scientific simulations.)  Off the 
top of my head, it seems to me that these other applications might have 
slightly different needs from the use of data.generators by 
test.generative.  

For one thing, efficiency might matter a lot in some simulations, but not 
in software testing.  (At least, *I* wouldn't care if my test functions 
were slow.)  I'm not saying that functions in data.generator are slow, but 
I don't think there's a good reason to worry about making them efficient if 
they're only intended for software testing.

Further, there are other needs than are currently provided by 
test.generators.  See the sampling functions in bigml/sampling 
 or Incanter , 
for example, and lots of other random functions that Incanter provides.  
Some of those should remain in Incanter, of course, but I wonder whether 
Clojure would benefit from a contributed library that satisfied a set of 
core needs for random effects.  (Incanter partly builds on clojure.core's 
rand at this point.)

Maybe data.generators is/will be that library.  Or maybe parts of 
data.generators would make more sense as part of a separate library 
(math.random? data.random? math.probability?) that could be split out of 
data.generators.  (If it doesn't make sense to split data.generators, then 
would a new name for the library be more appropriate?)

Just some things I was wondering about.  Curious to see what others say.

(Fun tip: Check out data.generators' anything function, which is like 
Emacs' Zippy the Pinhead functions for people who prefer industrial atonal 
music composed by randomly filtered Jackson Pollock paintings, to speech.  
Or: People who want to thoroughly test their functions by throwing random 
randomly-typed data at them.)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Is it the right Clojure group for a newbie

2014-06-04 Thread Mars0i


On Tuesday, June 3, 2014 8:41:33 AM UTC-5, Gregg Reynolds wrote:
>
> I know you've asked for online resources, but I can't resist a plug for The 
> Little Schemer .  It's 
> short, very clear, starts at the very beginning, and you don't even need a 
> computer to read it.  (It's also annoyingly cute, but you can overlook that 
> with a little effort.)  It's far and away the best introduction I've ever 
> come across to the kind of thinking one needs to master in order to program 
> in lispy languages like Clojure.  It uses scheme, but everything translates 
> more or less directly to Clojure.
>

I'll second Gregg's recommendation, especially given your comment that 
you're coming from a non-technical background.  This book will get you into 
a good mindset for Clojure programming. 

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: What's clojure killer app? I don't see any.

2014-06-04 Thread douglas smith
Jony, Hey thanks 

Just finish watching and reading about Gorilla-Repl (will be digging 
deeper) and WOW really clean and simple UI -Nice. 
Much Much easier to install than IPython notebook was and its Clojure!
Couldn't follow much of your coding as I said I am just starting out.
I like the keystrokes and no buttons - I do need to remap chrome-browser 
ctrl-g to something else -don't use it anyway.
I like how you can show the underling 'value' of things.

Couldn't this type of application run remotely and potentially provide a 
'live work space' for dislocated groups of students?
Maybe a keystroke that toggles screen control.  
- a 'kitchen table coders' thing but virtual.
 -just a thought.

I really am convinced that clojure is a great first language to learn-  and 
I'm determined to learn it.

Thanks -Doug

 
 



 


 

On Tuesday, June 3, 2014 6:54:31 AM UTC-4, Jony Hudson wrote:
>
>
>
> On Monday, 2 June 2014 18:42:32 UTC+1, douglas smith wrote:
>  
>
>> A killer app for me and I think MANY others like me would be very similar 
>> to a Kovas' 'Session' 'pretty like Light Table'  and beefy like IPythons 
>> Notebooks. 
>>
>
> Hope you'll excuse a shameless plug, but have you seen Gorilla REPL (
> http://gorilla-repl.org) ? It may or may not have some of the things 
> you're looking for :-)
>
>
> Jony 
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Effective Clojure book?

2014-06-04 Thread dennis zhuang
《The joy of clojure》 ?


2014-06-05 9:30 GMT+08:00 Mike Fikes :

> Are there any books yet that prescribe best practices for Clojure, à la
> Meyers or Bloch?
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Effective Clojure book?

2014-06-04 Thread Mike Fikes
Are there any books yet that prescribe best practices for Clojure, à la 
Meyers or Bloch?

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Eval-ing a map expression in Emacs Live doesn't seem to work

2014-06-04 Thread J Irving
Your cursor was probably on the closing paren at the end - you eval'd the
previous expression, which was the vector.

Check out the key bindings here:

https://github.com/clojure-emacs/cider#cider-mode

If your cursor is anywhere on that expression, you probably want C-c C-c.



On Wed, Jun 4, 2014 at 7:32 PM, gvim  wrote:

> I opened a core.clj file in my Emacs Live and, to make sure everything is
> working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used
> cider-jack-in to get a repl connection. For practice I entered this:
>
> (map #(+ % 5) [1 2 3 4 5])
>
> ... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e
>
> The output was:
>
> => [1 2 3 4 5]
>
> ... instead of the expected [6 7 8 9 10]
>
> ??
>
> gvim
>
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Eval-ing a map expression in Emacs Live doesn't seem to work

2014-06-04 Thread Alex Miller
Maybe you evaluated the inner vector instead of the outer expression? Might 
depend whether your cursor is on or after the last paren.

On Wednesday, June 4, 2014 6:32:18 PM UTC-5, g vim wrote:
>
> I opened a core.clj file in my Emacs Live and, to make sure everything 
> is working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used 
> cider-jack-in to get a repl connection. For practice I entered this: 
>
> (map #(+ % 5) [1 2 3 4 5]) 
>
> ... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e 
>
> The output was: 
>
> => [1 2 3 4 5] 
>
> ... instead of the expected [6 7 8 9 10] 
>
> ?? 
>
> gvim 
>
>
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Eval-ing a map expression in Emacs Live doesn't seem to work

2014-06-04 Thread gvim
I opened a core.clj file in my Emacs Live and, to make sure everything 
is working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used 
cider-jack-in to get a repl connection. For practice I entered this:


(map #(+ % 5) [1 2 3 4 5])

... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e

The output was:

=> [1 2 3 4 5]

... instead of the expected [6 7 8 9 10]

??

gvim


--
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Lee Spector

On Jun 4, 2014, at 1:29 PM, Timothy Baldridge  wrote:

> Although your original complaint was about clojure seqs being lazy. It should 
> be noted that reducers are also lazy down to the point of a fold or reduce, 
> so I'm not sure what you're really getting there. It wouldn't be hard at all 
> to write map, filter, remove, etc. in terms of list operations. Perhaps 
> that's what you're looking for? If I understand your original complaint, you 
> want map, filter, etc, to be eager.
> 

True, my original concern was (and my main concern still is) to avoid crashes 
(in this case, stack overflow errors) that stem from unexpected (to me) 
consequences of laziness.

Those problems could indeed be solved by rewriting map and filter etc, or 
(easier) by "wringing out the laziness" wherever it arises, e.g. by forcing 
everything to be a vector (or a list, as you suggest). It's a little cumbersome 
to do this everywhere, though, and I was wondering if there was an existing 
library or approach for this issue.

Then, however, it was suggested that I could have my cake and another kind of 
cake too, by using reducers. The suggestion was that this could banish the 
laziness-related issues while also providing significant performance 
improvements. Sounds good to me! I'm still working on getting my current 
project to behave well using reducers, but it seems promising.

> 
> On the other hand, time spent learning how lazy seqs work, and the caveats 
> involved will make it easier for you to understand the code produced by the 
> rest of the community. So perhaps that's the better option. 

I agree that it's important to understand lazy sequences, and I do think I 
understand the core concepts reasonably well (and I've implemented lazy 
evaluation in other languages, etc.). But I've also traced some really annoying 
and hard to find bugs to unexpected (and sometimes never fully explained) 
consequences of laziness, so I'd like to find the best ways to avoid it when I 
don't really want it. If that best way turns out to make things run faster too 
then that'd be fantastic.

 -Lee

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Lee Spector

On Jun 4, 2014, at 1:20 PM, Gary Johnson  wrote:

> - If I operate on a vector with a sequence of r/map and r/filter operations 
> and finally with "into []" to get back a vector, then I think that fold will 
> be called within the call to into, and that parallelism should happen 
> there... right? But if that's right, how do I control the group size that the 
> call to fold uses in this case? I see how to specify the group size for a 
> direct call to fold, but not for other function in the library. 
> 
> 
> No, fold will not be called in into. The definition of into uses reduce, 
> which is single-threaded. What you want is one of the following two 
> formulations:
> 
>   (fold group-size cat append! foldable-collection)   ;; if you want to 
> specify the group size
> 
>   (foldcat foldable-collection)  ;; if you are happy with the default 512 
> group size
> 
> In both cases, the foldable-collection is just one of your (r/map f (r/filter 
> p? initial-collection)) forms. For it to be foldable though, 
> initial-collection needs to be a vector, map, or set (i.e., a tree-like 
> collection).
> 
> I hope that helps.

Definitely helpful. With the fold version, and messing with the group size, I'm 
seeing much higher multicore utilization and I think I'm seeing speedups too 
(although it's a little hard to measure because of randomness). I'm also having 
new problems (pauses that get worse over time... GC?) but I'll experiment more 
before I bother anyone else with those.

Thanks so much Gary,

 -Lee

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Allow reseeding/rebinding RNG behind rand?

2014-06-04 Thread Linus Ericsson
Sorry, of course i meant the clojure.data.generators library

https://github.com/clojure/data.generators

esp. the *rnd* that can be bound around many of the functions in the
library.

/Linus

On Wednesday, June 4, 2014, Linus Ericsson 
wrote:

> Data.generative already has this function and many more, I realized.
>
> /Linus
>
> On Wednesday, June 4, 2014, Mars0i  > wrote:
>
>>
>>
>> On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote:
>>>
>>> Once you notice that you usually need a fast solution.
>>>
>>
>> Yes!
>>
>>
>>> The easiest solution is to just pass around an instance of
>>> java.util.Random which you create with the desired seed. Another options is
>>> to have a constructor function returning a "rand" function.
>>>
>>> (defn prng [seed]
>>>   (let [rnd (java.util.Random. (long seed))]
>>> (fn rand [] (.nextDouble rnd
>>>
>>
>> Thanks.  This is very helpful.  I have not been thoroughly immersed in
>> the Java world for many years, so I have to spend a bit of time studying in
>> order to figure out this sort of thing on my own.  (I like Clojure because
>> I usually only need to deal with Java when I want to, but there are times
>> when it's necessary.)
>>
>>
>>> But having a built-in rebindable (thread-local) "rand" is preferable in
>>> the long run.
>>>
>>
>> Yes, especially since rolling one's own version means coding up any
>> higher-level functions that use randomness, when others who have thought
>> more about relevant algorithms have already done that work.  Then again,
>> their source code is usually available, so one can copy it.  For my present
>> purposes, data.generators or bigml/sampling might do what I need.
>>
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Allow reseeding/rebinding RNG behind rand?

2014-06-04 Thread Linus Ericsson
Data.generative already has this function and many more, I realized.

/Linus

On Wednesday, June 4, 2014, Mars0i  wrote:

>
>
> On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote:
>>
>> Once you notice that you usually need a fast solution.
>>
>
> Yes!
>
>
>> The easiest solution is to just pass around an instance of
>> java.util.Random which you create with the desired seed. Another options is
>> to have a constructor function returning a "rand" function.
>>
>> (defn prng [seed]
>>   (let [rnd (java.util.Random. (long seed))]
>> (fn rand [] (.nextDouble rnd
>>
>
> Thanks.  This is very helpful.  I have not been thoroughly immersed in the
> Java world for many years, so I have to spend a bit of time studying in
> order to figure out this sort of thing on my own.  (I like Clojure because
> I usually only need to deal with Java when I want to, but there are times
> when it's necessary.)
>
>
>> But having a built-in rebindable (thread-local) "rand" is preferable in
>> the long run.
>>
>
> Yes, especially since rolling one's own version means coding up any
> higher-level functions that use randomness, when others who have thought
> more about relevant algorithms have already done that work.  Then again,
> their source code is usually available, so one can copy it.  For my present
> purposes, data.generators or bigml/sampling might do what I need.
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Allow reseeding/rebinding RNG behind rand?

2014-06-04 Thread Mars0i


On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote:
>
> Once you notice that you usually need a fast solution. 
>

Yes!
 

> The easiest solution is to just pass around an instance of 
> java.util.Random which you create with the desired seed. Another options is 
> to have a constructor function returning a "rand" function.
>
> (defn prng [seed]
>   (let [rnd (java.util.Random. (long seed))]
> (fn rand [] (.nextDouble rnd
>

Thanks.  This is very helpful.  I have not been thoroughly immersed in the 
Java world for many years, so I have to spend a bit of time studying in 
order to figure out this sort of thing on my own.  (I like Clojure because 
I usually only need to deal with Java when I want to, but there are times 
when it's necessary.)
 

> But having a built-in rebindable (thread-local) "rand" is preferable in 
> the long run.
>

Yes, especially since rolling one's own version means coding up any 
higher-level functions that use randomness, when others who have thought 
more about relevant algorithms have already done that work.  Then again, 
their source code is usually available, so one can copy it.  For my present 
purposes, data.generators or bigml/sampling might do what I need. 

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Allow reseeding/rebinding RNG behind rand?

2014-06-04 Thread Mars0i
On Tuesday, June 3, 2014 4:56:26 PM UTC-5, Andy Fingerhut wrote:
>
> This ticket seems to be at least somewhat related to your questions:
>
> http://dev.clojure.org/jira/browse/CLJ-1420
>
> Andy
>

Yes, thanks for finding that, Andy.  It looks like it would address the 
problem about accessing an RNG from distinct threads, and the discussion 
raises the issue of ability to reset the seed in order to replay 
experiments.

(Incidentally, I realized that comparing (map rand ...) and (pmap rand ...) 
might be a poor test, because rand might be too inexpensive to overcome the 
cost of thread setup by pmap.  I reported a better test in a post here 
.)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: gemacl: Scientific computing application written in Clojure

2014-06-04 Thread Mars0i


On Tuesday, June 3, 2014 12:46:55 PM UTC-5, Mars0i wrote:
>
> (def ones (doall (repeat 1000 1)))
> (bench (def _ (doall (map rand ones   ; 189 microseconds average time
> (bench (def _ (doall (pmap rand ones  ; 948 microseconds average time
>

For the record, I worried later that rand was too inexpensive, and that 
those results were being driven only by the cost of setting up threads in 
pmap.  This seems like a better test:

(bench (def _ (doall (map #(nth (iterate rand %) 1) (repeat 256 1)
; 185 milliseconds average time

(bench (def _ (doall (pmap #(nth (iterate rand %) 1) (repeat 256 1)
; 793 milliseconds average time

I have been having success getting a speedup simply by changing certain map 
calls to pmap in my main project.  I'm sure that many of us will be 
interested in a report whenever you get to it, but I can easily imagine 
that finding the time to summarize what you've learned is difficult. 

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Ambrose Bonnaire-Sergeant
Does Swift have any static types to harvest? :)


On Thu, Jun 5, 2014 at 1:50 AM, David Nolen  wrote:

> I wouldn't pass judgement on Swift too soon. Eval works just fine in the
> REPL and it appears the language supports hot code loads out of the box.
> Swift also has real support for final fields via 'let'. I personally think
> a ClojureSwift could be quite interesting :)
>
> On Wednesday, June 4, 2014, Timothy Baldridge 
> wrote:
>
>> I'm starting to feel like a broken record, but here we go.
>>
>> Some things to think about:
>>
>> 1) Why do you want this? The JVM GC and JIT are some of the fastest (if
>> not the fastest) on the planet, so performance will never be a good reason
>> to do this.
>> 2) Do you want something like eval? As far as I can tell Swift is
>> statically compiled. Only XCode has the ability to modify a program on the
>> fly.
>> 3) Clojure is highly polymorphic and dynamically typed. Walk the source
>> code for first  and next and you'll find something like 3-4 polymorphic
>> calls involved in something as simple as (doseq [x (range 100)]), per item.
>> 4) I have yet to see performance numbers for Swifthow fast/slow is it
>> compared to other languages?
>>
>> To put this all into perspective, I once translated LazySeq to C++ and
>> ran some code (with a GC) that performed something like (doall (range
>> 10)). The result was about 10x slower than Clojure on the JVM. So
>> simply running something in C++/LLVM doesn't mean that you'll even get
>> close to the performance of the JVM.
>>
>> Memory constrained systems might benefit from a LLVM Clojure. In addition
>> there's room for improvement with the JVM's horrible warmup times. Python
>> will boot instantly on most systems while the Clojure REPL takes about a
>> minute to boot on the RPi. But aside form that, I can't see much of a
>> point.
>>
>> If you want something like this there's always (
>> https://github.com/galdolber/clojure-objc)
>>
>> Timothy
>>
>>
>>
>>
>> On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp 
>> wrote:
>>
>>> The recent release of Swift made me revisit Clojure on LLVM. This post
>>> from 2010
>>> 
>>> suggests it's a very difficult task.
>>>
>>> Swift would make this job easier? As with ClojureScript, generate Swift
>>> code / provide interop and Clojurian's can produce native iOS apps?
>>>
>>> Perhaps the biggest hole to be filled would be tooling (Xcode is not
>>> Clojure/Lisp friendly? i.e. no playground support)
>>>
>>> --
>>> 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 patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to

Re: Clojure on iOS devices - Swift as a host?

2014-06-04 Thread David Nolen
I wouldn't pass judgement on Swift too soon. Eval works just fine in the
REPL and it appears the language supports hot code loads out of the box.
Swift also has real support for final fields via 'let'. I personally think
a ClojureSwift could be quite interesting :)

On Wednesday, June 4, 2014, Timothy Baldridge  wrote:

> I'm starting to feel like a broken record, but here we go.
>
> Some things to think about:
>
> 1) Why do you want this? The JVM GC and JIT are some of the fastest (if
> not the fastest) on the planet, so performance will never be a good reason
> to do this.
> 2) Do you want something like eval? As far as I can tell Swift is
> statically compiled. Only XCode has the ability to modify a program on the
> fly.
> 3) Clojure is highly polymorphic and dynamically typed. Walk the source
> code for first  and next and you'll find something like 3-4 polymorphic
> calls involved in something as simple as (doseq [x (range 100)]), per item.
> 4) I have yet to see performance numbers for Swifthow fast/slow is it
> compared to other languages?
>
> To put this all into perspective, I once translated LazySeq to C++ and ran
> some code (with a GC) that performed something like (doall (range 10)).
> The result was about 10x slower than Clojure on the JVM. So simply running
> something in C++/LLVM doesn't mean that you'll even get close to the
> performance of the JVM.
>
> Memory constrained systems might benefit from a LLVM Clojure. In addition
> there's room for improvement with the JVM's horrible warmup times. Python
> will boot instantly on most systems while the Clojure REPL takes about a
> minute to boot on the RPi. But aside form that, I can't see much of a
> point.
>
> If you want something like this there's always (
> https://github.com/galdolber/clojure-objc)
>
> Timothy
>
>
>
>
> On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp  > wrote:
>
>> The recent release of Swift made me revisit Clojure on LLVM. This post
>> from 2010
>> 
>> suggests it's a very difficult task.
>>
>> Swift would make this job easier? As with ClojureScript, generate Swift
>> code / provide interop and Clojurian's can produce native iOS apps?
>>
>> Perhaps the biggest hole to be filled would be tooling (Xcode is not
>> Clojure/Lisp friendly? i.e. no playground support)
>>
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Timothy Baldridge
Although your original complaint was about clojure seqs being lazy. It
should be noted that reducers are also lazy down to the point of a fold or
reduce, so I'm not sure what you're really getting there. It wouldn't be
hard at all to write map, filter, remove, etc. in terms of list operations.
Perhaps that's what you're looking for? If I understand your original
complaint, you want map, filter, etc, to be eager.

On the other hand, time spent learning how lazy seqs work, and the caveats
involved will make it easier for you to understand the code produced by the
rest of the community. So perhaps that's the better option.

Timothy


On Wed, Jun 4, 2014 at 11:20 AM, Gary Johnson  wrote:

> Hey Lee, answers below. Also make sure to read my other post at 12:59pm
> today regarding the behavior of vec vs. into for reducible collections.
>
>
> On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote:
>>
>> Some quick notes and a question from my first look into this:
>>
>> - I watched a Rich Hickey reducers video, was riveted, and see that they
>> are beautiful. I particularly appreciated his brief aside about how lazy
>> seqs have independent utility.
>>
>> - In practice, for the little program I posted about previously,
>> switching to reducers involved a couple of initially unexpected
>> complications, some of now make sense to me but others of which don't
>> fully: results of reducers sometimes have to be explicitly converted, e.g.
>> with "into []"; r/map doesn't take multiple collections; I don't
>> immediately see elegant reducer-based approaches to uses of "for" or
>> "repeat", etc.
>>
>>
> It's true that the library does have these limitations. You could, of
> course, just implement a for-like macro that uses the reducing operations
> under the hood. Easier (but less readable) is to just convert your for into
> the equivalent r/map and r/filter operations. When using repeat, make sure
> the result sequence will be finite and call vec on it directly. Then you
> can apply the reducing functions to it and still have a foldable collection.
>
>
>> - My initial swapping of clojure.core.reducers functions for lazy seq
>> (and agent-based parallel computing) functions seems to make my performance
>> worse rather than better. I realize that there are several possible
>> explanations for this and I have to look at my usage more carefully. It's
>> definitely possible that I'm doing more than one thing wrong, but one
>> question that this leads to is:
>>
>>
> Hard to say why this would be without seeing your code, but the first
> thing that comes to mind is that if you aren't calling fold or foldcat
> anywhere, then you won't be getting any parallelization from using
> reducers. So maybe your performance decrease is because you're now running
> single-threaded.
>
>
>> - If I operate on a vector with a sequence of r/map and r/filter
>> operations and finally with "into []" to get back a vector, then I think
>> that fold will be called within the call to into, and that parallelism
>> should happen there... right? But if that's right, how do I control the
>> group size that the call to fold uses in this case? I see how to specify
>> the group size for a direct call to fold, but not for other function in the
>> library.
>>
>>
> No, fold will not be called in into. The definition of into uses reduce,
> which is single-threaded. What you want is one of the following two
> formulations:
>
>   (fold group-size cat append! foldable-collection)   ;; if you want to
> specify the group size
>
>   (foldcat foldable-collection)  ;; if you are happy with the default 512
> group size
>
> In both cases, the foldable-collection is just one of your (r/map f
> (r/filter p? initial-collection)) forms. For it to be foldable though,
> initial-collection needs to be a vector, map, or set (i.e., a tree-like
> collection).
>
> I hope that helps.
>
>   ~Gary
>
>> Thanks,
>>
>>  -Lee
>
>  --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 me

Re: non-lazy clojure?

2014-06-04 Thread Gary Johnson
Hey Lee, answers below. Also make sure to read my other post at 12:59pm 
today regarding the behavior of vec vs. into for reducible collections.

On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote:
>
> Some quick notes and a question from my first look into this: 
>
> - I watched a Rich Hickey reducers video, was riveted, and see that they 
> are beautiful. I particularly appreciated his brief aside about how lazy 
> seqs have independent utility. 
>
> - In practice, for the little program I posted about previously, switching 
> to reducers involved a couple of initially unexpected complications, some 
> of now make sense to me but others of which don't fully: results of 
> reducers sometimes have to be explicitly converted, e.g. with "into []"; 
> r/map doesn't take multiple collections; I don't immediately see elegant 
> reducer-based approaches to uses of "for" or "repeat", etc. 
>
>
It's true that the library does have these limitations. You could, of 
course, just implement a for-like macro that uses the reducing operations 
under the hood. Easier (but less readable) is to just convert your for into 
the equivalent r/map and r/filter operations. When using repeat, make sure 
the result sequence will be finite and call vec on it directly. Then you 
can apply the reducing functions to it and still have a foldable collection.
 

> - My initial swapping of clojure.core.reducers functions for lazy seq (and 
> agent-based parallel computing) functions seems to make my performance 
> worse rather than better. I realize that there are several possible 
> explanations for this and I have to look at my usage more carefully. It's 
> definitely possible that I'm doing more than one thing wrong, but one 
> question that this leads to is: 
>
>
Hard to say why this would be without seeing your code, but the first thing 
that comes to mind is that if you aren't calling fold or foldcat anywhere, 
then you won't be getting any parallelization from using reducers. So maybe 
your performance decrease is because you're now running single-threaded.
 

> - If I operate on a vector with a sequence of r/map and r/filter 
> operations and finally with "into []" to get back a vector, then I think 
> that fold will be called within the call to into, and that parallelism 
> should happen there... right? But if that's right, how do I control the 
> group size that the call to fold uses in this case? I see how to specify 
> the group size for a direct call to fold, but not for other function in the 
> library. 
>
>
No, fold will not be called in into. The definition of into uses reduce, 
which is single-threaded. What you want is one of the following two 
formulations:

  (fold group-size cat append! foldable-collection)   ;; if you want to 
specify the group size

  (foldcat foldable-collection)  ;; if you are happy with the default 512 
group size

In both cases, the foldable-collection is just one of your (r/map f 
(r/filter p? initial-collection)) forms. For it to be foldable though, 
initial-collection needs to be a vector, map, or set (i.e., a tree-like 
collection).

I hope that helps.

  ~Gary 

> Thanks, 
>
>  -Lee

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Lee Spector

On Jun 4, 2014, at 12:59 PM, Gary Johnson  wrote:

> Hey Lee,
> 
>   (vec ...) is NOT the same as (into [] ...) in this case.
[etc]

Thanks Gary -- very clear and helpful.

 -Lee

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Greg Knapp
I wasn't really pointing at performance with my post. More about native app 
development, for OSX we have Clojure on the JVM which is fine. I don't see 
Apple allowing Java on iOS anytime though.

Thanks for the replies so far, this was purely food for thought.

On Wednesday, 4 June 2014 16:11:56 UTC+1, Aaron France wrote:
>
> @Timothy, you mention speed a lot, but I'm not sure where in the OP it 
> mentioned wanting to do this for speed at all. I think the intention is to 
> be able to Clojure on a different platform, is all.
>
>
> On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes > 
> wrote:
>
>> I have been experimenting writing an iOS app using ClojureScript embedded 
>> in JavaScriptCore, where the ClojureScript essentially implements the logic 
>> of my view controllers which drive native UI.
>>
>> So far, this approach seems like a reasonable one to “writing iOS apps 
>> using Clojure.”
>>
>> You essentially trade off direct tooling support and gain the ease of 
>> developing using ClojureScript (this is important to me, as my server is in 
>> Clojure and I can effectively master one language.)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Gary Johnson
Hey Lee,

  (vec ...) is NOT the same as (into [] ...) in this case.

  Whenever you use a reducing function, like r/map, r/filter, r/mapcat, and 
so on, you are not, in fact, performing any computations on the collection 
to which you apply it. These functions simply wrap the collection with a 
kind of delayed operation that will later be triggered by applying reduce 
to it.

  So, if I have a collection called samples, and I run (r/map inc samples), 
I just get a reducible object back. Same thing with a chain of these 
functions as in (r/filter odd? (r/map inc samples)). I just get back a 
reducible object (which itself is wrapping another reducible object). When 
you run reduce on this whole thing, each of the delayed operations are 
combined together into one giant reduce function, as if you had written 
something like this:

  (reduce + (r/filter odd? (r/map inc samples)))
   => (reduce (fn [sum sample] (let [sample' (inc sample)] (if (odd? 
sample') (+ sample' sum) sum))) 0 samples)

  This is the reason that you need to use (into [] ...) rather than (vec 
...). Running vec on a reducible object will just throw a RuntimeException. 
When you use into, you will be applying reduce (since that's how it is 
implemented), and as long as you use into with a vector, map, or set, it 
will be run using transients for efficiency.

  Uses transients:

  (into [] (r/map inc (range 10)))
  (into {} (r/map #(vector % 0) (range 10)))
  (into #{}| (r/map inc (range 10)))

  Doesn't use transients (but still works). Note that the list will have 
been reversed because of the nature of list consing:
  (into () (r/map inc (range 10)))

Alright, hopefully that's enough from me for now. Good luck with your 
program.

  ~Gary

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: non-lazy clojure?

2014-06-04 Thread Lee Spector
> On Jun 2, 2014, at 7:14 PM, Gary Johnson  wrote:
> 
>> Hey Lee,
>> 
>>  I would second Jozef's suggestion that you look into using the reducers 
>> library when you need non-lazy sequence operations. [etc]

On Jun 2, 2014, at 10:38 PM, Lee Spector  wrote:

> 
> Gary: That's compelling indeed, and I will look into it more!


Some quick notes and a question from my first look into this:

- I watched a Rich Hickey reducers video, was riveted, and see that they are 
beautiful. I particularly appreciated his brief aside about how lazy seqs have 
independent utility.

- In practice, for the little program I posted about previously, switching to 
reducers involved a couple of initially unexpected complications, some of now 
make sense to me but others of which don't fully: results of reducers sometimes 
have to be explicitly converted, e.g. with "into []"; r/map doesn't take 
multiple collections; I don't immediately see elegant reducer-based approaches 
to uses of "for" or "repeat", etc.

- My initial swapping of clojure.core.reducers functions for lazy seq (and 
agent-based parallel computing) functions seems to make my performance worse 
rather than better. I realize that there are several possible explanations for 
this and I have to look at my usage more carefully. It's definitely possible 
that I'm doing more than one thing wrong, but one question that this leads to 
is:

- If I operate on a vector with a sequence of r/map and r/filter operations and 
finally with "into []" to get back a vector, then I think that fold will be 
called within the call to into, and that parallelism should happen there... 
right? But if that's right, how do I control the group size that the call to 
fold uses in this case? I see how to specify the group size for a direct call 
to fold, but not for other function in the library.

Thanks,

 -Lee

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread u1204
> Hi everyone, I'm looking to get some opinions on code style.
>
> Specifically, I like to write my code in a top-down.
>
> What I mean by that is that within a file the highest-level functions sit
> at the top, and are implemented in terms of lower-level functions further
> down.

You could write a "(defn-defer ..." macro that asserts the signature
and caches the code body. The final function in your file would be
(do-defer ...) which does the actual (defn ... forms.

Tim Daly

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Luc Prefontaine
I maintain that the average human
being looking at sed commands
would rather end up standing on his 
head for a significant amount of
time to avoid it :)))

BTWY, I have been scripting under u*x 
for a few decades by now.
I resort to it when nothing and I 
mean nothing (think about Daffy Duck's
voice  here) else can do it :))

Luc P.


Luc P.


> 
> 
> On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote:
> >
> > ... Then I add the new functions to the declare statement by hand, or I 
> > periodically do something like:
> >
> > grep defn mysourcefile.clj >> mysourcefile.clj
> > (Be careful to use two ">"s!)
> >
> > and then I edit the junk at the end of the file into a declare statement 
> > at the top of the file.  And maybe if f I were ... lazier, I'd code a 
> > script that would update the declare in one pass.
> >
> 
> OK, I couldn't resist my own implicit challenge. 
> 
> #!/bin/sh
> sourcefile="$1"
> newsourcefile="new.$sourcefile"
> 
> newdeclare=$(echo '(declare' \
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \
> | sed 's/ )/)/')
> 
> sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile"
> 
> This writes a new version of the file named new.. Or if you 
> either trust your script or trust your backups, and are on a system that 
> includes the mighty ed  editor, 
> you can replace the last line with:
> 
> echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile"
> 
> which edits the file in place, assuming that the previous version of the 
> declaration was on one line.  You may want to use a different scriptable 
> editor.
> 
> The messy part is the sed and tr line:
> 
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '`
> 
> The sed part finds all of the lines with "defn" in them, then substitutes 
> the empty string for "(defn" or "(defn-".   'tr' then removes the newlines 
> between the function names, replacing the newlines with spaces.  You'll 
> need something a little more complicated if you put the parameter vector or 
> anything else on the same line as the function name.  The 'echo' on the 
> previous line, along with the final ')' adds "(declare" and its closing 
> parenthesis.  Those two lines can be used by themselves to generate a 
> declare statement from the command line. The 'sed' command after these 
> lines isn't necessary; it just removes an unnecessary space before the 
> closing parenthesis. 
> 
> Obviously, there will be source files on which this won't work.  It's not 
> worth making it foolproof.
> 
> It's a certainty that others would code this more elegantly or more 
> succinctly.  It could be written in Clojure, obviously, but still wouldn't 
> be foolproof unless someone hacks it from the Clojure parser.
> 
> -- 
> 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 patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Phillip Lord

Then integrate the whole lot into the Clojure compiler pipeline so that
it just works in the first place.

Reid McKenzie  writes:

> Clearly the solution is to use tools.analyzer and write a big def emitter
>
> /s
> Reid
> On 06/04/2014 10:27 AM, Mars0i wrote:
>>
>>
>> On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote:
>>
>> ... Then I add the new functions to the declarestatement by hand,
>> or I periodically do something like:
>>
>> grep defn mysourcefile.clj >> mysourcefile.clj
>> (Be careful to use two ">"s!)
>>
>> and then I edit the junk at the end of the file into a
>> declarestatement at the top of the file.  And maybe if f I were
>> ... lazier, I'd code a script that would update the declarein one
>> pass.
>>
>>
>> OK, I couldn't resist my own implicit challenge.
>>
>> #!/bin/sh
>> sourcefile="$1"
>> newsourcefile="new.$sourcefile"
>>
>> newdeclare=$(echo '(declare' \
>> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \
>> | sed 's/ )/)/')
>>
>> sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile"
>>
>> This writes a new version of the file named new.. Or if
>> you either trust your script or trust your backups, and are on a
>> system that includes the mighty ed
>>  editor, you can replace the
>> last line with:
>>
>> echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile"
>>
>> which edits the file in place, assuming that the previous version of
>> the declaration was on one line.  You may want to use a different
>> scriptable editor.
>>
>> The messy part is the sed and tr line:
>>
>> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '`
>>
>> The sed part finds all of the lines with "defn" in them, then
>> substitutes the empty string for "(defn" or "(defn-".   'tr' then
>> removes the newlines between the function names, replacing the
>> newlines with spaces.  You'll need something a little more complicated
>> if you put the parameter vector or anything else on the same line as
>> the function name.  The 'echo' on the previous line, along with the
>> final ')' adds "(declare" and its closing parenthesis.  Those two
>> lines can be used by themselves to generate a declare statement from
>> the command line. The 'sed' command after these lines isn't necessary;
>> it just removes an unnecessary space before the closing parenthesis.
>>
>> Obviously, there will be source files on which this won't work.  It's
>> not worth making it foolproof.
>>
>> It's a certainty that others would code this more elegantly or more
>> succinctly.  It could be written in Clojure, obviously, but still
>> wouldn't be foolproof unless someone hacks it from the Clojure parser.
>> -- 
>> 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 patient
>> with your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] clj-generators - generator magic inspired by Python

2014-06-04 Thread Timothy Baldridge
A little known fact is that the guts of the go macro are quite flexible. We
use this in the test framework:

https://github.com/clojure/core.async/blob/master/src/test/clojure/clojure/core/async/ioc_macros_test.clj#L17

I also spent some time once and created a yield like macro:

https://github.com/halgari/async-bench/blob/master/src/async_bench/core.clj#L64

WARNING: this uses unpublished APIs from core.async, use at your own risk.

Timothy


On Wed, Jun 4, 2014 at 9:43 AM, Gary Johnson  wrote:

> What new features does this syntax provide over the existing infinite
> sequence generators?
>
> - lazy-seq
> - iterate
> - repeat
> - repeatedly
> - range
>
> I realize you provided a simple example for clarity, but perhaps you could
> illustrate something more complex that couldn't be done with the above
> functions easily. For example, the case you provided could be written as
> follows:
>
> (take 5 (iterate inc 1))
>
>   Thanks,
> ~Gary
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Colin Fleming
I actually have an open issue for Cursive to do this automatically: #200
. I'm starting to
think a namespace sorter that automatically manages the declares might not
be such a crazy idea.


On 5 June 2014 03:37, Reid McKenzie  wrote:

>  Clearly the solution is to use tools.analyzer and write a big def emitter
>
> /s
> Reid
>
> On 06/04/2014 10:27 AM, Mars0i wrote:
>
>
>
> On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote:
>>
>> ... Then I add the new functions to the declare statement by hand, or I
>> periodically do something like:
>>
>> grep defn mysourcefile.clj >> mysourcefile.clj
>> (Be careful to use two ">"s!)
>>
>> and then I edit the junk at the end of the file into a declare statement
>> at the top of the file.  And maybe if f I were ... lazier, I'd code a
>> script that would update the declare in one pass.
>>
>
> OK, I couldn't resist my own implicit challenge.
>
> #!/bin/sh
> sourcefile="$1"
> newsourcefile="new.$sourcefile"
>
> newdeclare=$(echo '(declare' \
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \
> | sed 's/ )/)/')
>
> sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile"
>
> This writes a new version of the file named new.. Or if you
> either trust your script or trust your backups, and are on a system that
> includes the mighty ed  editor,
> you can replace the last line with:
>
> echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile"
>
> which edits the file in place, assuming that the previous version of the
> declaration was on one line.  You may want to use a different scriptable
> editor.
>
> The messy part is the sed and tr line:
>
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '`
>
> The sed part finds all of the lines with "defn" in them, then substitutes
> the empty string for "(defn" or "(defn-".   'tr' then removes the newlines
> between the function names, replacing the newlines with spaces.  You'll
> need something a little more complicated if you put the parameter vector or
> anything else on the same line as the function name.  The 'echo' on the
> previous line, along with the final ')' adds "(declare" and its closing
> parenthesis.  Those two lines can be used by themselves to generate a
> declare statement from the command line. The 'sed' command after these
> lines isn't necessary; it just removes an unnecessary space before the
> closing parenthesis.
>
> Obviously, there will be source files on which this won't work.  It's not
> worth making it foolproof.
>
> It's a certainty that others would code this more elegantly or more
> succinctly.  It could be written in Clojure, obviously, but still wouldn't
> be foolproof unless someone hacks it from the Clojure parser.
>  --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] clj-generators - generator magic inspired by Python

2014-06-04 Thread Gary Johnson
What new features does this syntax provide over the existing infinite 
sequence generators?

- lazy-seq
- iterate
- repeat
- repeatedly
- range

I realize you provided a simple example for clarity, but perhaps you could 
illustrate something more complex that couldn't be done with the above 
functions easily. For example, the case you provided could be written as 
follows:

(take 5 (iterate inc 1))

  Thanks,
~Gary

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Reid McKenzie
Clearly the solution is to use tools.analyzer and write a big def emitter

/s
Reid
On 06/04/2014 10:27 AM, Mars0i wrote:
>
>
> On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote:
>
> ... Then I add the new functions to the declarestatement by hand,
> or I periodically do something like:
>
> grep defn mysourcefile.clj >> mysourcefile.clj
> (Be careful to use two ">"s!)
>
> and then I edit the junk at the end of the file into a
> declarestatement at the top of the file.  And maybe if f I were
> ... lazier, I'd code a script that would update the declarein one
> pass.
>
>
> OK, I couldn't resist my own implicit challenge.
>
> #!/bin/sh
> sourcefile="$1"
> newsourcefile="new.$sourcefile"
>
> newdeclare=$(echo '(declare' \
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \
> | sed 's/ )/)/')
>
> sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile"
>
> This writes a new version of the file named new.. Or if
> you either trust your script or trust your backups, and are on a
> system that includes the mighty ed
>  editor, you can replace the
> last line with:
>
> echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile"
>
> which edits the file in place, assuming that the previous version of
> the declaration was on one line.  You may want to use a different
> scriptable editor.
>
> The messy part is the sed and tr line:
>
> `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '`
>
> The sed part finds all of the lines with "defn" in them, then
> substitutes the empty string for "(defn" or "(defn-".   'tr' then
> removes the newlines between the function names, replacing the
> newlines with spaces.  You'll need something a little more complicated
> if you put the parameter vector or anything else on the same line as
> the function name.  The 'echo' on the previous line, along with the
> final ')' adds "(declare" and its closing parenthesis.  Those two
> lines can be used by themselves to generate a declare statement from
> the command line. The 'sed' command after these lines isn't necessary;
> it just removes an unnecessary space before the closing parenthesis.
>
> Obviously, there will be source files on which this won't work.  It's
> not worth making it foolproof.
>
> It's a certainty that others would code this more elegantly or more
> succinctly.  It could be written in Clojure, obviously, but still
> wouldn't be foolproof unless someone hacks it from the Clojure parser.
> -- 
> 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 patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


trouble using local jars in project

2014-06-04 Thread Wei Hsu
I'm having trouble using local jars in my project. I've built the jars and 
installed them with localrepo.

wei:clj-opencv wei$ lein localrepo install opencv-249.jar opencv/opencv 
2.4.9
wei:clj-opencv wei$ lein localrepo install opencv-native-249.jar 
opencv/opencv-native 2.4.9

The jars show up in the local repo list.

wei:pv wei$ lein localrepo list | grep opencv
opencv/opencv-native (2.4.9)
opencv (2.4.9)

I then included opencv in my project.clj with [opencv/opencv "2.4.9"]. But 
leiningen can't find the jar when I run the project:

wei:pv wei$ lein run
Could not find artifact opencv:opencv:jar:2.4.9 in central 
(http://repo1.maven.org/maven2/)
Could not find artifact opencv:opencv:jar:2.4.9 in clojars 
(https://clojars.org/repo/)
Could not find artifact opencv:opencv:jar:2.4.9 in project (file:repo)
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment 
variable.

I wonder if the problem is specific to opencv since I've used localrepo 
successfully for other jars. Any pointers would be appreciated.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Mars0i


On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote:
>
> ... Then I add the new functions to the declare statement by hand, or I 
> periodically do something like:
>
> grep defn mysourcefile.clj >> mysourcefile.clj
> (Be careful to use two ">"s!)
>
> and then I edit the junk at the end of the file into a declare statement 
> at the top of the file.  And maybe if f I were ... lazier, I'd code a 
> script that would update the declare in one pass.
>

OK, I couldn't resist my own implicit challenge. 

#!/bin/sh
sourcefile="$1"
newsourcefile="new.$sourcefile"

newdeclare=$(echo '(declare' \
`sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \
| sed 's/ )/)/')

sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile"

This writes a new version of the file named new.. Or if you 
either trust your script or trust your backups, and are on a system that 
includes the mighty ed  editor, 
you can replace the last line with:

echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile"

which edits the file in place, assuming that the previous version of the 
declaration was on one line.  You may want to use a different scriptable 
editor.

The messy part is the sed and tr line:

`sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '`

The sed part finds all of the lines with "defn" in them, then substitutes 
the empty string for "(defn" or "(defn-".   'tr' then removes the newlines 
between the function names, replacing the newlines with spaces.  You'll 
need something a little more complicated if you put the parameter vector or 
anything else on the same line as the function name.  The 'echo' on the 
previous line, along with the final ')' adds "(declare" and its closing 
parenthesis.  Those two lines can be used by themselves to generate a 
declare statement from the command line. The 'sed' command after these 
lines isn't necessary; it just removes an unnecessary space before the 
closing parenthesis. 

Obviously, there will be source files on which this won't work.  It's not 
worth making it foolproof.

It's a certainty that others would code this more elegantly or more 
succinctly.  It could be written in Clojure, obviously, but still wouldn't 
be foolproof unless someone hacks it from the Clojure parser.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Aaron France
@Timothy, you mention speed a lot, but I'm not sure where in the OP it
mentioned wanting to do this for speed at all. I think the intention is to
be able to Clojure on a different platform, is all.


On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes  wrote:

> I have been experimenting writing an iOS app using ClojureScript embedded
> in JavaScriptCore, where the ClojureScript essentially implements the logic
> of my view controllers which drive native UI.
>
> So far, this approach seems like a reasonable one to “writing iOS apps
> using Clojure.”
>
> You essentially trade off direct tooling support and gain the ease of
> developing using ClojureScript (this is important to me, as my server is in
> Clojure and I can effectively master one language.)
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Mike Fikes
I have been experimenting writing an iOS app using ClojureScript embedded in 
JavaScriptCore, where the ClojureScript essentially implements the logic of my 
view controllers which drive native UI.

So far, this approach seems like a reasonable one to “writing iOS apps using 
Clojure.”

You essentially trade off direct tooling support and gain the ease of 
developing using ClojureScript (this is important to me, as my server is in 
Clojure and I can effectively master one language.)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Mars0i


On Sunday, June 1, 2014 9:36:55 AM UTC-5, Glen Mailer wrote:
>
> Hi everyone, I'm looking to get some opinions on code style.
>
> Specifically, I like to write my code in a top-down.
>
> What I mean by that is that within a file the highest-level functions sit 
> at the top, and are implemented in terms of lower-level functions further 
> down.
> ...
> There's a few approaches i've seen from reading other's code:
> ...
> Some other options I considered include making really heavy use of 
> (declare), ...
>

I'm puzzled by the complexity of the solutions proposed.  (Although I like 
Luc's, since my computer doesn't have an auto-rotate function.)  I don't 
see this as a big deal at all. I just put a big declare statement at the 
top of the file.

More specifically, when initially coding related functions, I'll put the 
dependent ones below the ones they call.  After that chunk of code is done, 
I might move the higher-level functions up in the file.  Then I add the new 
functions to the declare statement by hand, or I periodically do something 
like:

grep defn mysourcefile.clj >> mysourcefile.clj
(Be careful to use two ">"s!)

and then I edit the junk at the end of the file into a declare statement at 
the top of the file.  And maybe if f I were ... lazier, I'd code a script 
that would update the declare in one pass.

That works for defn and defn-, and you might want to shorten the search 
term to 'def'.  It's more difficult if you use Clojure protocols.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: store a value in a PersistentVector and PersistentHashMap

2014-06-04 Thread Timothy Baldridge
If you've read those sites, then read the source. It's not that hard to
understand once you understand that Vectors are trees:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentVector.java


On Wed, Jun 4, 2014 at 7:46 AM, sorin cristea  wrote:

>
>
> On Wednesday, June 4, 2014 4:32:00 PM UTC+3, François Rey wrote:
>>
>> On 04/06/14 14:59, sorin cristea wrote:
>> >  do you know how is store a 'value' in a PersistentVector or in a
>> > PersistentHashMap ?
>> Hi Sorin,
>> Your question is difficult to understand without more context.
>> Are you trying to use Clojure data structures from Java?
>> http://www.lispcast.com/3-things-java-can-steal-from-clojure
>> Are you trying to understand how to use clojure data structures?
>> http://pleac.sourceforge.net/pleac_clojure/arrays.html
>> http://pleac.sourceforge.net/pleac_clojure/hashes.html
>> Are you trying to understand how clojure data structure work internally?
>> http://hypirion.com/musings/understanding-persistent-vector-pt-1
>> http://hypirion.com/musings/understanding-persistent-vector-pt-2
>> http://hypirion.com/musings/understanding-persistent-vector-pt-3
>>
>
>
>
> Hi Francois,
>
> I'm trying to understand how clojure persistence data structure, specially
> PersistentVector and PersistentHashMap, work internally
>
> Thanks.
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Timothy Baldridge
I'm starting to feel like a broken record, but here we go.

Some things to think about:

1) Why do you want this? The JVM GC and JIT are some of the fastest (if not
the fastest) on the planet, so performance will never be a good reason to
do this.
2) Do you want something like eval? As far as I can tell Swift is
statically compiled. Only XCode has the ability to modify a program on the
fly.
3) Clojure is highly polymorphic and dynamically typed. Walk the source
code for first  and next and you'll find something like 3-4 polymorphic
calls involved in something as simple as (doseq [x (range 100)]), per item.
4) I have yet to see performance numbers for Swifthow fast/slow is it
compared to other languages?

To put this all into perspective, I once translated LazySeq to C++ and ran
some code (with a GC) that performed something like (doall (range 10)).
The result was about 10x slower than Clojure on the JVM. So simply running
something in C++/LLVM doesn't mean that you'll even get close to the
performance of the JVM.

Memory constrained systems might benefit from a LLVM Clojure. In addition
there's room for improvement with the JVM's horrible warmup times. Python
will boot instantly on most systems while the Clojure REPL takes about a
minute to boot on the RPi. But aside form that, I can't see much of a
point.

If you want something like this there's always (
https://github.com/galdolber/clojure-objc)

Timothy




On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp  wrote:

> The recent release of Swift made me revisit Clojure on LLVM. This post
> from 2010
> 
> suggests it's a very difficult task.
>
> Swift would make this job easier? As with ClojureScript, generate Swift
> code / provide interop and Clojurian's can produce native iOS apps?
>
> Perhaps the biggest hole to be filled would be tooling (Xcode is not
> Clojure/Lisp friendly? i.e. no playground support)
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: store a value in a PersistentVector and PersistentHashMap

2014-06-04 Thread sorin cristea


On Wednesday, June 4, 2014 4:32:00 PM UTC+3, François Rey wrote:
>
> On 04/06/14 14:59, sorin cristea wrote: 
> >  do you know how is store a 'value' in a PersistentVector or in a 
> > PersistentHashMap ? 
> Hi Sorin, 
> Your question is difficult to understand without more context. 
> Are you trying to use Clojure data structures from Java? 
> http://www.lispcast.com/3-things-java-can-steal-from-clojure 
> Are you trying to understand how to use clojure data structures? 
> http://pleac.sourceforge.net/pleac_clojure/arrays.html 
> http://pleac.sourceforge.net/pleac_clojure/hashes.html 
> Are you trying to understand how clojure data structure work internally? 
> http://hypirion.com/musings/understanding-persistent-vector-pt-1 
> http://hypirion.com/musings/understanding-persistent-vector-pt-2 
> http://hypirion.com/musings/understanding-persistent-vector-pt-3 
>



Hi Francois, 

I'm trying to understand how clojure persistence data structure, specially 
PersistentVector and PersistentHashMap, work internally 

Thanks.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Are zippers the right choice for "sequence-like" trees?

2014-06-04 Thread Jason Felice
In general, I've found that zippers make complicated edits super-easy,
while a recursive phrasing of the same algorithm - if it exists and isn't
super complicated to write - performs better and gives more control over
structural sharing.  I might prove out an algorithm with zippers, but when
the pedal hits the road for performance, I'll try to rephrase it.

If you can phrase things in terms of (catvec (subvec ...) (subvec ...)),
then I'll bet (but you should check) that rrb-vector will perform better
and do more structural sharing.



On Wed, Jun 4, 2014 at 8:29 AM, Paul Butcher  wrote:

> I am working with “sequence like” trees - by which I mean that they’re
> very broad (typically the root node will have several thousand children)
> and shallow (no more than 2 levels deep). I’m often dealing with a
> degenerate tree that’s really just a sequence (all the nodes in the tree
> are children of the root).
>
> A typical edit is either changing the value of a single element, inserting
> a single element, or deleting a small set of contiguous elements.
>
> I’m currently using clojure.zip to edit the tree, and it’s working just
> fine. But I’m concerned that it won’t be giving me much value in terms of
> structure sharing for this type of tree and this type of edit.
>
> So I have two questions:
>
> 1) What would be a good way for me to instrument my code to determine what
> level of structure sharing I am achieving?
>
> 2) Should I consider switching to something based on (say?) rrb-vector?
>
> --
> paul.butcher->msgCount++
>
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
>
> Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel
> http://pragprog.com/book/pb7con
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Bastien
Hi Alex,

Alex Ott  writes:

> res - the map consisting of:
>  - :text -> extracted text
>  - all other fields - metadata from document

Works like a charm, thanks a bunch!

-- 
 Bastien

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: store a value in a PersistentVector and PersistentHashMap

2014-06-04 Thread François Rey

On 04/06/14 14:59, sorin cristea wrote:
 do you know how is store a 'value' in a PersistentVector or in a 
PersistentHashMap ?

Hi Sorin,
Your question is difficult to understand without more context.
Are you trying to use Clojure data structures from Java?
http://www.lispcast.com/3-things-java-can-steal-from-clojure
Are you trying to understand how to use clojure data structures?
http://pleac.sourceforge.net/pleac_clojure/arrays.html
http://pleac.sourceforge.net/pleac_clojure/hashes.html
Are you trying to understand how clojure data structure work internally?
http://hypirion.com/musings/understanding-persistent-vector-pt-1
http://hypirion.com/musings/understanding-persistent-vector-pt-2
http://hypirion.com/musings/understanding-persistent-vector-pt-3

--
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Clojure on iOS devices - Swift as a host?

2014-06-04 Thread Greg Knapp
The recent release of Swift made me revisit Clojure on LLVM. This post from 
2010  
suggests it's a very difficult task.

Swift would make this job easier? As with ClojureScript, generate Swift 
code / provide interop and Clojurian's can produce native iOS apps?

Perhaps the biggest hole to be filled would be tooling (Xcode is not 
Clojure/Lisp friendly? i.e. no playground support)

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Alex Ott
>lein try clj-tika "1.2.0"

user=> (use 'tika)
user=> (def res (parse "
https://www.oasis-open.org/committees/download.php/25054/07-08-22-MetaData-Examples.odt
"))
#'user/res

res - the map consisting of:
 - :text -> extracted text
 - all other fields - metadata from document





On Wed, Jun 4, 2014 at 2:33 PM, Bastien  wrote:

> Hi Alex,
>
> Alex Ott  writes:
>
> > Pantomime right now doesn't support the text extraction, but you can
> > take the https://github.com/alexott/clj-tika (outdate although) - it
> > uses the Apache Tika for text extraction
>
> thanks -- I stumbled upon clj-tika but didn't understand how to use
> it.  Would you have a minima example?  The README is pretty terse.
>
> Thanks in advance,
>
> --
>  Bastien
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


store a value in a PersistentVector and PersistentHashMap

2014-06-04 Thread sorin cristea
 
  Hi all,

do you know how is store a 'value' in a PersistentVector or in a 
PersistentHashMap ?

Thanks
Sorin.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Your chance to employ an experienced clojure team!

2014-06-04 Thread Dave Jarvis
Hey Florian - 

I'm a developer over at CircleCI and we're definitely interested in seeing 
if there might be a fit here. Would someone one your team mind shooting me 
an e-mail at j...@circleci.com? I read everything that goes into that 
address so I can promise you won't be lost in any bureaucracy :)

Cheers!

 - Dave

On Tuesday, June 3, 2014 4:22:17 AM UTC-7, Florian Over wrote:
>
> Hey,
> you know how hard it is to find good clojure developers?
> This is your chance to hire a battle-proven team. :)
> Our startup shutdown the core product right and our whole clojure team is 
> available from July.
> We would love to work together in this team in the future.
> Relocation is not really an option but contact us either way!
> (We are based in Cologne area, Germany)
>
> We developed a cloud-based document management solution for end-users 
> and small/medium businesses. (Event-driven, CQRS architecture)
>
> We did the whole enchilada from architecture, concept, research & 
> development to hosting and operations.
>
> Some of the technologies we used:
> * ring, compojure, clojure-script, http-kit
> * prismatic-schema
> * ... dozen of other clojure libraries :)
> * pallet
> * riemann
> * zookeeper
> * postgres
> * AWS (ec2, s3, dynamoDB, SQS, Cloudfront, EMR, Cloudwatch, ...)
>
> Right now we are not allowed to show or open-source the code we developed. 
> :(
>
> * Islon Scherer - https://github.com/stackoverflow
> * Emil Yessenamanov - https://github.com/mobyte
>  * Gerrit Hentschel - https://github.com/gerrit-hntschl
> * Florian Over - https://github.com/FlorianO
>
> Feel free to contact me directly for more information.
> Best regards Florian
>  

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure Pretty Printing with Blogger

2014-06-04 Thread Ashish Negi
Hi i am trying to pretty a clojure code :
my emacs version is 24.3.1
my org file is :

#+BEGIN_SRC clojure
  (defn foo [x]
(reverse (let [A (reduce 
(fn [x y] 
  (if (= (:L x) y)
(assoc x :T (conj (:T x) y))
 (assoc (assoc  
(if (:L x)
(assoc x :V 
   (conj (:V x) (cons (:L x) (:T x))) 
   )
x)
 :T nil)
 :L y )
   ))
   {}  x)] 
(conj (:V A) (cons (:L A) (:T A)))
  )))

#+END_SRC

when i do C-c C-e h o, it open a file which shows code in a block but it is 
not pretty. 
On Friday, 25 May 2012 15:37:24 UTC+5:30, Jake Johnson wrote:
>
> Hi, guys. Has anyone had any luck with using google-code-prettify 
>  and 
> http://google-code-prettify.googlecode.com/svn/trunk/src/lang-clj.js 
> together on blogger? I followed 
> http://www.tkglaser.net/2012/03/syntax-highlighting-in-blogger.html 
>  
> , but I can't get Clojure to display correctly, at least yet.
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Bastien
Hi Alex,

Alex Ott  writes:

> Pantomime right now doesn't support the text extraction, but you can
> take the https://github.com/alexott/clj-tika (outdate although) - it
> uses the Apache Tika for text extraction

thanks -- I stumbled upon clj-tika but didn't understand how to use
it.  Would you have a minima example?  The README is pretty terse.

Thanks in advance,

-- 
 Bastien

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Are zippers the right choice for "sequence-like" trees?

2014-06-04 Thread Paul Butcher
I am working with “sequence like” trees - by which I mean that they’re very 
broad (typically the root node will have several thousand children) and shallow 
(no more than 2 levels deep). I’m often dealing with a degenerate tree that’s 
really just a sequence (all the nodes in the tree are children of the root).

A typical edit is either changing the value of a single element, inserting a 
single element, or deleting a small set of contiguous elements.

I’m currently using clojure.zip to edit the tree, and it’s working just fine. 
But I’m concerned that it won’t be giving me much value in terms of structure 
sharing for this type of tree and this type of edit.

So I have two questions:

1) What would be a good way for me to instrument my code to determine what 
level of structure sharing I am achieving?

2) Should I consider switching to something based on (say?) rrb-vector?

--
paul.butcher->msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher

Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel
http://pragprog.com/book/pb7con

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Phillip Lord
Gregg Reynolds  writes:

>> This is not side-effect free (sorry for pun). I did this for my code,
>> and now slamhound doesn't work on it. Other tools too? I don't know.
>>
>> https://github.com/technomancy/slamhound/issues/61
>
>
> (load "foo") is legal Clojure; if a tool can't handle it, that's either a
> bug or a deliberate limitation in the tool. 


If you read the bug report, you will see that I agree. The slamhound
developers don't and argue that (load "foo") is bad style. Who is right
is not so relevant; that there is such an argument is.


> So I wouldn't say that using "load" has side-effects that break tools,
> but that some tools may make assumptions and have side-effects that do
> nasty things to legal code (or "encourage" a particular style). I
> would not be surprised if other tools make similar assumptions about
> the structure of clojure source files. Then it's a question of whether
> one wants to allow the limitations of tools to constrain one's use of
> the language.


Or whether one's use of the language limits the ability to use tools. I
just make the statement that it good to know about these choices rather
than to make them by chance.

Phil

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Top-down code in namspaces

2014-06-04 Thread Phillip Lord
Gary Trakhman  writes:
> Knowing with certainty that some called method is defined above in the
> compilation strategy simplifies code-reading and comprehension by
> minimizing where you have to look, and it also makes it easier to move
> stuff around with a text editor than what I imagine the alternative
> would provide.

I never really care about backward or forward when jumping about code.
The editors take care of it for me.

> I haven't used a late-binding lisp in a large code-base, so I'm contrasting
> against my experience with Java.


It's a total pain in the ass. You write some lisp, start to debug it
carefully, and half way through hit a mispelt symbol.

(defun thing[fred x]
   (funcall frd x))


In Clojure, the closest equivalent (hitting a symbol you have declared,
but not defined) is rare:

(declare frd)
(defun thing[fred x]
   (frd x))


Although, pre-declaration doesn't prevent a related bug which is using a
symbol that you *think* is local but is actually global as in:

(defn blah [mp]
   (do-stuff-to map))


Having said this this, having to declare things first and being forced
to write bottom up is also a pain. Win some, lose some.

Phil

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Simbase: A vector similarity database

2014-06-04 Thread Mingli Yuan
Hi,folks,

Simbase v0.1.0-beta1 just release! We had fix many bugs,and the system are
very stable for almost half a year in our cases。

In the docs, we add simple scenario for your references

Setup

> bmk b2048 t1 t2 t3 ... t2047 t2048
> vmk b2048 article
> vmk b2048 userprofile
> rmk userprofile article cosinesq

Fill data

> vadd article 1 0.11 0.112 0.1123...
> vadd article 2 0.21 0.212 0.2123...
...

> vadd userprofile 1 0.11 0.112 0.1123...
> vadd userprofile 2 0.21 0.212 0.2123...
...

Query

> rrec userprofile 2 article




On Sun, Jan 26, 2014 at 9:21 AM, Mingli Yuan  wrote:

> Hi, folks,
>
> This week we released v0.1.0-alpha3
>
> * Remove constrains on vectors, Simbase support arbitrary vectors now
> * Fix various bugs on memory structure to keep scale ratio linearly
> * Almost 7 times improvement on performance, right now it can handle 100k
> dimensional dense vectors in under 0.14 sec on a i7-cup mac laptop.
>
> From now on, it enter the beta phase. If it is relevant to your work,  we
> encourage you to have a try, and help us to find more bugs.
>
> Regards,
> Mingli
>
>
> On Mon, Jan 13, 2014 at 5:55 PM, Mingli Yuan 
> wrote:
>
>> Hi, folks,
>>
>> We just release an alpha version of Simbase, a vector similarity database
>> that talks redis protocol. Since it is the first version of all its
>> releases, we decided to keep it in alpha right now, for we want to hear
>> from the community for any comments and improvements.
>>
>> Github page
>> --
>>
>> https://github.com/guokr/simbase
>>
>> We introduce the basic idea, limitations, build process and commands
>> there.
>>
>> Background
>> --
>>
>> Simbase is a tool we developed during the process we revise our content
>> recommendation engine.
>>
>> Our document set have 300k docs, and we use LDA to change them into
>> vectors. But how to compare the 300k vectors was a problem for us then. We
>> had tried different method, but the performance is not very good.
>>
>> Since the comparison logic is quit simple, we decided to write a new data
>> store to do the tricks.
>>
>> So far, we are satisfied by its performance. Under the setting of an i7
>> MacBook and 120k 1k-dimensional vector set:
>>
>>- write: about 1 ops per second
>>- read: up to 1k ops per second
>>
>> The real read performance may be higher than the current result, because
>> our testing method is limited.
>>
>> Regards,
>>
>> Mingli
>>
>>
>>
>>
>>
>

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Alex Ott
Hi

Pantomime right now doesn't support the text extraction, but you can take
the https://github.com/alexott/clj-tika (outdate although) - it uses the
Apache Tika for text extraction


On Wed, Jun 4, 2014 at 1:27 AM, Bastien  wrote:

> Hi all,
>
> I'm trying to get the content of an ODT file as plain text.
>
> I've found Pantomime, but don't understand how to use it?
>
> Can anyone put me on the right tracks with a minimal working
> example?
>
> Thanks in advance!
>
> --
>  Bastien
>
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Bastien
Hi Denis,

Denis Fuenzalida  writes:

> I've created a small gist which shows how to use the ODFDOM API which
> is much simpler to use:
>
> https://gist.github.com/dfuenzalida/a1e9755e9b2e7f638620

Thanks a lot for this!  I tested it and I can get the human readable
text from an arbitrary .odt file.

My next purpose is to get what getTextContent gives me, but with new
lines preserved -- I used "getContentDom" so that I can get the full
DOM and find new lines by replacing ... ... but
this feel dirty.  Do you know if I can get paragraphs easily?  Or
should I manipulate the DOM with some other XML parsing tool?

Thanks for your time,

-- 
 Bastien

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Parsing ODT files (with Pantomime?)

2014-06-04 Thread Bastien
Hi Jeffrey,

"'Jeffrey Cummings' via Clojure"  writes:

> You may want to look at Docjure https://github.com/mjul/docjure
>
>
> It parses .xlsx files it may be able to parse .odt files.

Thanks, but I don't see anything in docjure about parsing .odt files.
Or am I missing something?

-- 
 Bastien

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Allow reseeding/rebinding RNG behind rand?

2014-06-04 Thread Gunnar Völkel
Once you notice that you usually need a fast solution. The easiest solution 
is to just pass around an instance of java.util.Random which you create 
with the desired seed. Another options is to have a constructor function 
returning a "rand" function.

(defn prng [seed]
  (let [rnd (java.util.Random. (long seed))]
(fn rand [] (.nextDouble rnd

You can specify different arities as you need them. But obviously this is 
more limited than just passing around the Random object since you can't 
choose between the next* methods.

But having a built-in rebindable (thread-local) "rand" is preferable in the 
long run.

-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.