Re: Do you recommend the book: "Web Development with Clojure"

[Adrian Mowat]

Hi Laurent

If you are making the switch from OO then I recommend https://leanpub.com/fp-oo

Cheers

Adrian

-- 
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/groups/opt_out.

Re: [ANN] Gorilla REPL initial release (0.1.2)

[Fabian Page]

What i found with saving and loading:
- If i try to save to a folder it will not be created and there is no error 
message.
- It will not load a file which is in the root folder.
- If i created the ws folder by hand i can load and save without problems.

Fabian

Am 20.02.2014 um 08:43 schrieb Fabian Page :

> Very nice project!
> 
> I can save but not load a worksheet on my machine. (OS X, Chrome) If somebody 
> else has the same problem i can open an issue on github.
> 
> Fabian
> 
> Am 19.02.2014 um 22:23 schrieb Jony Hudson :
> 
>> Hi All,
>> 
>>  I'm pleased to announce the first release of Gorilla REPL, a rich REPL in 
>> the notebook style:
>> 
>> https://github.com/JonyEpsilon/gorilla-repl
>> 
>> From the README:
>> 
>> "You can think of it like a pretty REPL that can plot graphs, or you can 
>> think of it as an editor for rich documents that can contain interactive 
>> Clojure code, graphs, table, notes, LaTeX formulae. Whatever works for you! 
>> One of the main aims is to make it lightweight enough that you can use it 
>> day-to-day instead of the command-line REPL, but also offer the power to 
>> perform and document complex data analysis and modelling tasks. Above all 
>> else, Gorilla tries not to dictate your workflow, but rather to fit in to 
>> the way you like to work, hopefully putting a bit more power to your elbow."
>> 
>> You might like to take a look at a video introduction that shows what it 
>> does better than my poor prose describes it:
>> 
>> https://vimeo.com/87118206
>> 
>> I hope you like it and find it useful. In particular I really hope it fits 
>> in to your workflow, and if not it would be great to know why. Bear in mind 
>> it is very new and hasn't had a lot of testing, so caveat evaluator. In 
>> particular:
>> 
>> * I've done very limited testing other than on Safari on Mac. I've checked 
>> that it works in most of the major browsers on Windows and Mac, but that's 
>> about it!
>> 
>> * At the moment you can only open one window otherwise it breaks 
>> (silently!). I'd love some help on the bug that's blocking this from someone 
>> who understands nREPL better than me. 
>> https://github.com/JonyEpsilon/gorilla-repl/issues/10
>> 
>> * It relies on an internet connection at the moment, at least until it 
>> caches various fonts. Need to get in touch with someone at clojars about 
>> size limitations.
>> 
>> 
>> I think there's a lot still to be done, and there are some areas that would 
>> really benefit from feedback from clojure developers more experienced than 
>> me. Directions I'd love to see explored:
>> 
>> * More work on plotting. Still very green, and much could be improved.
>> 
>> * Incanter integration. If I've understood correctly, Incanter can generate 
>> SVG, so shouldn't be too difficult.
>> 
>> * Content-types. Currently values are tagged to indicate they should be 
>> rendered specially by the front-end. Is this the right way to do it? What 
>> about tagged literals?
>> 
>> * UI as a value. There's a lot that could be done with custom rendering of 
>> values. Mathematica is particularly impressive in this regard, and it would 
>> be interesting to think where this could go with clojure. I know Kovas 
>> Boguta has thought about this a lot.
>> 
>> * Clojurescript! I think this is a _really_ interesting one. I'd love to see 
>> a pure-client-version that uses a clojurescript REPL server in a web-worker 
>> or similar. I came to write Gorilla through thinking about this angle 
>> originally, having previously messed around with javascript based data 
>> analysis in the browser (see http://monkeycruncher.org - cute idea, but 
>> no-one wants to use js to analyse their data!). In my opinion there's some 
>> really important work to be done on opening up analysis - I'd love to 
>> publish scientific papers not with a snapshot of my analysis, but with my 
>> real, living, breathing analysis in them. And I love to do it on an open, 
>> ubiquitous platform :-)
>> 
>> Anyway, let me know what you think. Comments, issues and pull requests all 
>> very, very welcome ;-)
>> 
>> 
>> 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/groups/opt_out.
> 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure

Re: [ANN] Gorilla REPL initial release (0.1.2)

[Max Kreminski]

This is really neat! For the last two or three weeks I've been 
experimenting with a handful of different implementations of a really 
similar idea – an interactive Clojure "notebook" using web technologies for 
the frontend. In the process I've encountered a lot of the same issues you 
described (I'm particularly amused that we independently came up with the 
same idea of tagging values to indicate that they should be rendered in a 
particular way).

One thing that I've been playing around with is implementing the whole 
thing directly in ClojureScript – that is, evaluating user-entered code 
directly in the browser environment instead of sending it off to a JVM 
Clojure REPL in the background – using cljs-in-cljs, a reimplementation of 
the ClojureScript compiler in ClojureScript. This area of experimentation 
is particularly interesting to me because it seems to have the greatest 
potential for realizing the "open, ubiquitous platform" part of the dream :)

Definitely looking forward to helping out with this in any way I can.

On Wednesday, February 19, 2014 1:23:02 PM UTC-8, Jony Hudson wrote:
>
> Hi All,
>
>  I'm pleased to announce the first release of Gorilla REPL, a rich REPL in 
> the notebook style:
>
> https://github.com/JonyEpsilon/gorilla-repl
>
> From the README:
>
> "You can think of it like a pretty REPL that can plot graphs, or you can 
> think of it as an editor for rich documents that can contain interactive 
> Clojure code, graphs, table, notes, LaTeX formulae. Whatever works for you! 
> One of the main aims is to make it lightweight enough that you can use it 
> day-to-day instead of the command-line REPL, but also offer the power to 
> perform and document complex data analysis and modelling tasks. Above all 
> else, Gorilla tries not to dictate your workflow, but rather to fit in to 
> the way you like to work, hopefully putting a bit more power to your elbow."
>
> You might like to take a look at a video introduction that shows what it 
> does better than my poor prose describes it:
>
> https://vimeo.com/87118206
>
> I hope you like it and find it useful. In particular I really hope it fits 
> in to your workflow, and if not it would be great to know why. Bear in mind 
> it is very new and hasn't had a lot of testing, so caveat evaluator. In 
> particular:
>
> * I've done very limited testing other than on Safari on Mac. I've checked 
> that it works in most of the major browsers on Windows and Mac, but that's 
> about it!
>
> * At the moment you can only open one window otherwise it breaks 
> (silently!). I'd love some help on the bug that's blocking this from 
> someone who understands nREPL better than me. 
> https://github.com/JonyEpsilon/gorilla-repl/issues/10
>
> * It relies on an internet connection at the moment, at least until it 
> caches various fonts. Need to get in touch with someone at clojars about 
> size limitations.
>
>
> I think there's a lot still to be done, and there are some areas that 
> would really benefit from feedback from clojure developers more experienced 
> than me. Directions I'd love to see explored:
>
> * More work on plotting. Still very green, and much could be improved.
>
> * Incanter integration. If I've understood correctly, Incanter can 
> generate SVG, so shouldn't be too difficult.
>
> * Content-types. Currently values are tagged to indicate they should be 
> rendered specially by the front-end. Is this the right way to do it? What 
> about tagged literals?
>
> * UI as a value. There's a lot that could be done with custom rendering of 
> values. Mathematica is particularly impressive in this regard, and it would 
> be interesting to think where this could go with clojure. I know Kovas 
> Boguta has thought about this a lot.
>
> * Clojurescript! I think this is a _really_ interesting one. I'd love to 
> see a pure-client-version that uses a clojurescript REPL server in a 
> web-worker or similar. I came to write Gorilla through thinking about this 
> angle originally, having previously messed around with javascript based 
> data analysis in the browser (see http://monkeycruncher.org - cute idea, 
> but no-one wants to use js to analyse their data!). In my opinion there's 
> some really important work to be done on opening up analysis - I'd love to 
> publish scientific papers not with a snapshot of my analysis, but with my 
> real, living, breathing analysis in them. And I love to do it on an open, 
> ubiquitous platform :-)
>
> Anyway, let me know what you think. Comments, issues and pull requests all 
> very, very welcome ;-)
>
>
> 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?

Re: 'Reduced' and logic functions

[Niels van Klaveren]

>
>
> The definitions of alt-or and alt-and are swapped:
>
> (alt-or false true) and (alt-or true false) both return false, (but (and) 
> is true, and both (alt-and) and (alt-or) are false).
>
> (alt-and true false) and (alt-and false true) both return true.
>

That's some serious C&P errors there indeed, thanks Ben. For completeness 
sake, here's what they should be:

(defn alt-or
  ([] nil)
  ([& args] (reduce (fn [_ s] (if s (reduced s) s)) (alt-or) args)))

(defn alt-and
  ([] true)
  ([& args] (reduce (fn [_ s] (if s s (reduced s))) (alt-and) args)))

(defn alt-every?
  [pred coll]
  (reduce (fn [_ s] (let [t (boolean (pred s))] (if t t (reduced t true 
coll))

(defn alt-some
  [pred coll]
  (reduce (fn [_ s] (let [t (pred s)] (if t (reduced t) t))) nil coll))

 

>  
>
>>
>> Another idea was that this way I could also make core.reducers based 
>> versions. Of course this would mean that sometimes you would evaluate too 
>> much tests, but since this would happen in parallel, in general the result 
>> would return faster. *Am I right in presuming that, or am I overlooking 
>> some very basic argument against them (I'm pretty good at that) ?*
>>
>
> The result wouldn't return faster if the input is an infinite list.
>

I don't think normal *every?* and *some *would do that better, would they ? 
In any case, reducers don't work on lazy sequences, so that shouldn't be a 
problem.

-- 
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/groups/opt_out.

Re: [ANN] Gorilla REPL initial release (0.1.2)

[Jony Hudson]

Thanks all for the kind comments. I'll be back to follow up later once I 
have some free time.

I made another short video - this one slightly incoherent as I was getting 
tired it would seem - about how plotting works, that might be of interest:

https://vimeo.com/87139900

Thanks again,


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/groups/opt_out.

[ANN] Lucuma 0.2.0

[Julien Eluard]

Hi,

I am pleased to announce release 0.2.0 of lucuma [1][2] - a Web Components
library for ClojureScript.

Lucuma helps with creating custom HTML elements encapsulating document,
style and logic. You can think of it as Google polymer in ClojureScript
world.

This release [3] introduces element definition reusability, greatly
improves properties support and rationalizes the syntax. I consider its API
fairly stable at this stage.

Next release [4] will focus on introducing a new syntax to unify document
definition with dynamic document changes. [5]

Feedback welcomed!

Thanks,
Julien

[1] http://jeluard.github.io/lucuma/
[2] https://github.com/jeluard/lucuma/
[3] https://github.com/jeluard/lucuma/blob/master/CHANGELOG.md
[4] https://github.com/jeluard/lucuma/issues?milestone=2&page=1&state=open
[5] https://github.com/jeluard/lucuma/issues/8

-- 
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/groups/opt_out.

Re: 'Reduced' and logic functions

[Niels van Klaveren]

>
>
> The result wouldn't return faster if the input is an infinite list.
>
> Ah, I see the gotcha now. If you don't implement *or *as a macro, all 
arguments will be evaluated before *or *is invoked. Macro-expansion won't 
evaluate later arguments if a former one short-circuits, of course.
I'd only tested this with lazy-sequences, not functions over them..

(or true (apply + (range)))=> true

(alt-or true (apply + (range)))

-- 
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/groups/opt_out.

Re: Do you recommend the book: "Web Development with Clojure"

[m0nastic]

I just wanted to share my experience, I don't know if it's relatable to
your current situation.



I picked it up last weekend because I needed to put together a very
quick web application for work, and I'd previously considered doing it
in Clojure, but was dissuaded because it looked like there wasn't a
good, prescribed, easy way to make a dead-simple CRUD business app.
Basically I just needed to make a web interface to a database, because
the larger system I'm working on is mostly dealing with databases and I
couldn't convince my boss to use the existing interface (running psql
in the terminal).



I haven't written any Clojure before.  I had earmarked some future
parts of the project to try it out (there's some data modeling that
seems like it will be a good fit for core.logic, and I'm testing out
using Datomic as a datastore), but so far the rest of my project is
implemented in Haskell and Racket, and I wasn't keen on using either of
those for putting together a web application.



I figured that if I read it over the weekend and built all the sample
applications, I should be able to piece together enough of an
understanding of how Clojure worked to get my site up. The book was
perfectly acceptable in that regard. I went through all the examples
and yesterday got a working version of the web app up and deployed
(again, it's really a very very simple view on the database, with some
light form entry). Now I'll spend the next couple days making it look
better and hooking it into the larger system.



So, even as someone who was totally new to Clojure, I was able to get a
very simple web application up that did real work in a couple of hours.



I will say that I think the author's decision to use LightTable for the
first project caused a lot of avoidable problems. I think LightTable
looks great, and I am starting to enjoy using it, but it's still being
updated fairly frequently, and even though the author references some
other editors/ide's in an appendix, all the interactions with the REPL
are explained using LightTable.



There's already a bunch of errata on the book page of people running
into issues with LightTable and the code examples (which are easy
enough to fix, but I think people just starting out would do themselves
a favor and just run a REPL from Leiningen and use whatever text editor
they want.



After a couple of days, I'm starting to get the hang of it, but I don't
know if it's a great "out of the box" experience for folks who are new
to all of this.



Also, for what it's worth, I'm really liking Clojure so far. I'm not
quite ready to order the special Nike's, but it seems like a very
thoughtful language.



-Chris





On Wed, Feb 19, 2014, at 10:54 AM, Erlis Vidal wrote:

Hi all,

Have any of you read the book Web Development with Clojure?

[1]http://www.amazon.com/Web-Development-Clojure-Build-Bulletproof/dp/1
937785645

There's only one review on amazon, and it's a fantastic review but I'm
wondering if this is the book I should read if I wanted to start using
Clojure for web programming.

Any advice will be greatly appreciated.

Thanks,
Erlis

--

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

[2]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 [3]https://groups.google.com/groups/opt_out.

References

1. http://www.amazon.com/Web-Development-Clojure-Build-Bulletproof/dp/1937785645
2. http://groups.google.com/group/clojure?hl=en
3. https://groups.google.com/groups/opt_out

-- 
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/groups/opt_out.

Re: [ANN] Gorilla REPL initial release (0.1.2)

[Matt Mower]

Jony this thing is totally cool. Forget the plotting as a REPL for 
exploring stuff (with the ability to restore sessions) it's very nice.

m/

On Wednesday, 19 February 2014 21:23:02 UTC, Jony Hudson wrote:
>
>
>  I'm pleased to announce the first release of Gorilla REPL, a rich REPL in 
> the notebook style:
>
>

-- 
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/groups/opt_out.

Re: [ANN] Gorilla REPL initial release (0.1.2)

[Matt Mower]

Couple of feature requests:

move segment up/down

and

MathML support (it's been 20 years since I did any Latex although its 
undoubtedbly cool!)

m/

On Wednesday, 19 February 2014 21:23:02 UTC, Jony Hudson wrote:
>
> Hi All,
>
>  I'm pleased to announce the first release of Gorilla REPL, a rich REPL in 
> the notebook style:
>
> https://github.com/JonyEpsilon/gorilla-repl
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that 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/groups/opt_out.

ANN: Om 0.5.0

[David Nolen]

The only change is that we now depend on the just released React 0.9.0.

Feedback welcome!

https://github.com/swannodette/om

David

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new 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/groups/opt_out.

Re: ANN: Om 0.5.0

[Henrik Eneroth]

Great stuff! Thanks!


On Thursday, February 20, 2014 8:07:36 PM UTC+1, David Nolen wrote:
>
> The only change is that we now depend on the just released React 0.9.0.
>
> Feedback welcome!
>
> https://github.com/swannodette/om
>
> David
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new 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/groups/opt_out.

Re: ANN: om-sync

[Alexander Hudek]

 (Dave and I work together).

I suspect it will be easy to come to a reasonable license. My own 
preferences would be EPL or MIT, and EPL only because it's common in the 
community.

Beyond that, something like chord isn't actually the big problem in a 
scheme like this. The real issue is ensuring that data replication is 
reliable. Here are the main pain points we've identified so far:

1. Updating a view on the client should update the source data.

This is called the "view update problem" and is fantastically difficult to 
solve. There are lots of publications on this (e.g. 
http://www.ijcte.org/papers/278-D038.pdf). I would recommend that we punt 
on the problem for the near term and settle for explicit 
update/insert/delete actions.

2. SQL, keystore (nosql), datalog (datomic).
We are approaching this from the SQL perspective. You would define and name 
a view on the server along with it's sql. Clients would then be able to 
register to have a view be mapped to an atom and kept up-to-date. 
Presumably a keystore  can be treated conceptually as a single table. I 
haven't thought about what a view would mean for datomic, nor how to keep 
one up-to-date.

3. Keeping the views up-to-date.
This is the hardest part. Here we want all the client views to be 
automatically updated, and to be consistent with the source data. There can 
be some amount of time lag between when the source data is updated and when 
the view is updated. We've worked out some ways to do this for a subset of 
SQL queries (including joins). It does require that queries are given in 
something like honeysql though. To compute update deltas for views you need 
to do some manipulation of the original query.

The other part of this is making sure that view delta updates arrive in the 
right order. This becomes especially important when you have a multi-server 
setup (e.g. high availability or load balancing). It's the same problem 
that all the distributed databases need to solve. The only reasonable 
solution we've thought of is to linearize the updates via a single write 
transactor mechanism. This would likely also need to be pluggable: some 
people will want something simple such as a thread in a single server, 
others will need something heavier such as a service sitting on an internal 
node with a traditional tcp/ip interface.

This doesn't seem ideal, but I don't know of any better way at the moment. 
I'm not sure that things like vector clocks would work for all data sources.

3.5 Pluggable communications layer. This is where chord fits. But it could 
also be handled by amqp, browserchannel, or other things. It's reasonable 
to use core.async as part of the pluggable interface.

4. Error handling, recovery, security. The security aspect definitely needs 
to be a pluggable component.


On Thursday, February 20, 2014 1:52:19 AM UTC-5, Mikera wrote:
>
>
>
> On Thursday, 20 February 2014 13:56:29 UTC+8, David Della Costa wrote:
>>
>> > It's not clear to me that the server side should be tied to Om 
>> > specifically. It seems like the requirement is more to have a server 
>> > component that can pass messages / state changes in a generic way to 
>> > clients (probably using core.async channels, with the ability to use 
>> > websockets etc. as the underlying transport). This server component 
>> > would be useful for all kinds of clients (not just Om, not just 
>> > Clojurescript, maybe even other server systems). 
>> > 
>> > I've hacked some stuff together that does this kind of thing for 
>> > specific projects, but it would be nice to get a solid standard 
>> > library in the ecosystem for this. 
>>
>> We have a concrete need for a system like this and in fact already have 
>> a prototype in production (which uses browserchannel as opposed to 
>> websockets, but these should be interchangeable) with ampq messaging and 
>> http wrapped in core.async and Om on the front-end, but we are working 
>> through some issues relating to scaling while providing eventual 
>> consistency across a number of web front-ends.  The end goal is 
>> essentially materialized views in the client. 
>>
>> We would also be very interested in working with other folks to provide 
>> something with general applicability to the whole community.  Please let 
>> us know if you'd want to contribute! 
>>
>
> I'd be happy to contribute to a library that met the following 
> requirements:
> - A sensible open source license (LGPL or EPL are fine) 
> - As simple as possible (minimal dependencies and API surface area)
> - Designed for plug+play with the related libraries in the ecosystem 
> (core.async, http-kit, ring etc.)
> - Reasonable community consensus that it is a good design
>
> BTW chord looks pretty promising as a foundation / model for some of this 
> kind of work
> https://github.com/james-henderson/chord
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.

[ANN] seqspert - demystify the internals of Clojure Sequences

[Jules]

I've been teaching myself a bit about the internals of various Clojure seqs 
over the last week or so... maps, sets, vectors etc..

I started with a little Clojure to help me drill into the Seq POJOS - this 
quickly grew into Seqspert :-)

I think that if you want to write performant code, you need to understand a 
bit about your hardware (mechanical sympathy), the JVM  and the Clojure 
runtime. The Seqs are a large part of this and Seqspert will help you 
quickly understand how they work.

Please take a look:

https://github.com/JulesGosnell/seqspert.git

regards,


Jules



-- 
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/groups/opt_out.

How to compose a java function

[Steffen Panning]

Hi all,

I want to compose a java function call out of a string in a macro:

I tried something like this simplified example, but it doesn't work.
creating a symbol out of a string is not enough.
Note: I know that uppercase variable names are bad, but it simplifies the 
example.

So how I do it right?

TIA Steffen

repl:

user> (defmacro set-example [obj feature]
  (let [meth-name# (symbol (str ".set" (name feature)))]
`(~meth-name# ~obj  ~feature)))

#'user/set-example
user> (let [o (javax.swing.JCheckBox . "foo")
Label "xxx"]  
(set-example o Label))
CompilerException java.lang.RuntimeException: Unable to resolve symbol: . 
in this context, compiling:(/tmp/form-init6247570319423795481.clj:1:9) 

-- 
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/groups/opt_out.

Re: Namespace Problems org-mode/org-babel

[Maik Schünemann]

Sorry for the short answer I am writing this on my phone.
I am also using org mode and the following works fine for me:
1 evaluate the first block.
Now cider should already be in the right namespace.
2. The next source block can be evaluated in the current ns.
You basically have to make sure that the cider session is in the right
state after evaluating the first source block.
If that doesn't work for you, try adding an (in-ns ...) To the beginning of
the second source block.

Also make sure that you are using the most recent org mode version to get
proper support for clojure

Hope that helps

> I should mention, that I use cider and followd the instructions on this
> page for the setup:
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html
>
 --
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/groups/opt_out.

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jules]

So, having broken the back of fast re-combination of hash sets and maps, I 
wanted to take a look at doing a similar sort of thing for vectors - 
another type of seq that I use very heavily in this sort of situation.

Let's see the cake first:

seqspert.vector=> (def a (into [] (range 1000)))
#'seqspert.vector/a
seqspert.vector=> (time (def b (into a a)))
"Elapsed time: 3695.682654 msecs"
#'seqspert.vector/b
seqspert.vector=> (time (def c (supervec a a)))
"Elapsed time: 0.253922 msecs"
#'seqspert.vector/c
seqspert.vector=> (= b c)
true

As you can see, the usual method of combining two vectors into a third 
takes 3-4 secs to combine two 10M entry vectors.

Using 'supervec' it takes MUCH less time.

How ?

I looked at vector's impl and quickly realised that I would not be able to 
use the same trick that I had used for hash set/map. Then I looked at 
subvec and realised that I could do a very similar trick to create supervec.

Subvec provides a view on a subseq of a vector that behaves like a full 
vector. Supervec provides a similar view that makes two vectors behave like 
a single one:

seqspert.vector=> (supervec [1 2 3] [4 5 6])
[1 2 3 4 5 6]
seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
clojure.lang.APersistentVector$SuperVector

We can use seqspert (see my other posting this evening) to look inside a 
SuperVector:

seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
#seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, :shift 
5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil 
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
nil nil nil nil nil nil]}, :tail [1 2 3]}, :right 
#seqspert.vector.Vector{:cnt 3, :shift 5, :root 
#seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil nil 
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
nil nil nil]}, :tail [4 5 6]}, :middle 3, :count 6}
seqspert.vector=> (p/pprint (decloak (supervec [1 2 3] [4 5 6])))
{:left
 {:cnt 3,
  :shift 5,
  :root
  {:array
   [nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil]},
  :tail [1 2 3]},
 :right
 {:cnt 3,
  :shift 5,
  :root
  {:array
   [nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil]},
  :tail [4 5 6]},
 :middle 3,
 :count 6}
nil
seqspert.vector=> 

It looks very complicated - that is the two clojurer vectors held inside ! 
A SuperVector has fields left, right (the two vectors that we are 
combining), middle (the length of the left vector), and count (the sum of 
the counts of left and right).

With just this info and very little code, I  found myself with a working 
impl (except 'pop' but who 'pop's a vector?).

OK - there is a tiny extra runtime overhead associated with using a 
supervec - but, when you look at what is involved in dereffing into a 
vector, this quickly appears insignificant. It's about the same a using a 
subvec.

The SuperVector code is checked into my clojure fork on github - see 
beginning of this thread. Seqspert is also at github - see the announcement 
I posted this evening.

Finally 'supervec' is currently defined as:

(defn supervec [l r] (APersistentVector$SuperVector. {} l r))

I am thinking or renaming 'splice' from my earlier posting to 'combine' and 
creating a Combinable interface, to be implemented by any seq type that is 
able to do a fast re-combination with another seq of the same type. This 
could be leveraged by e.g. 'into' to deliver significant performance 
benefits and footprint reduction.

more as and when,


Jules





On Saturday, 15 February 2014 23:06:24 UTC, Jules wrote:
>
> Guys,
>
> I've been playing with reducers on and off for a while but have been 
> frustrated because they don't seem to fit a particular usecase that I have 
> in mind... specifically: getting as many associations into a hash-map as as 
> I can in as short a time as possible.
>
> My understanding of the reason for this is that reducers practice a divide 
> and conquer strategy. The incoming sequence is divided up. Each 
> sub-sequence is reduced into a sub-result (possibly in parallel) and then 
> the sub-results are combined into the the final outgoing result.
>
> Unfortunately, there does not seem to be a better way of combining two 
> hash-maps other than to read each entry from one and create a new 
> corresponding association in the other. This means that each recombination 
> in the above process essentially repeats most of the work already performed 
> in the previous reduction stage.
>
> Hash-sets are implemented via hash-maps, and simpler with which to 
> demonstrate this

Re: fast parallel reduction into hash-set/map

[Andy Fingerhut]

Have you looked at core.rrb-vector, which implements Relaxed Radix Trees
for vectors that implement subvec and concatenating two arbitrary vectors
in O(log n) time?

https://github.com/clojure/core.rrb-vector

Unless I am missing something, the fast concatenation is what you are
trying to achieve?

Andy


On Thu, Feb 20, 2014 at 2:59 PM, Jules  wrote:

>
> So, having broken the back of fast re-combination of hash sets and maps, I
> wanted to take a look at doing a similar sort of thing for vectors -
> another type of seq that I use very heavily in this sort of situation.
>
> Let's see the cake first:
>
> seqspert.vector=> (def a (into [] (range 1000)))
> #'seqspert.vector/a
> seqspert.vector=> (time (def b (into a a)))
> "Elapsed time: 3695.682654 msecs"
> #'seqspert.vector/b
> seqspert.vector=> (time (def c (supervec a a)))
> "Elapsed time: 0.253922 msecs"
> #'seqspert.vector/c
> seqspert.vector=> (= b c)
> true
>
> As you can see, the usual method of combining two vectors into a third
> takes 3-4 secs to combine two 10M entry vectors.
>
> Using 'supervec' it takes MUCH less time.
>
> How ?
>
> I looked at vector's impl and quickly realised that I would not be able to
> use the same trick that I had used for hash set/map. Then I looked at
> subvec and realised that I could do a very similar trick to create supervec.
>
> Subvec provides a view on a subseq of a vector that behaves like a full
> vector. Supervec provides a similar view that makes two vectors behave like
> a single one:
>
> seqspert.vector=> (supervec [1 2 3] [4 5 6])
> [1 2 3 4 5 6]
> seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
> clojure.lang.APersistentVector$SuperVector
>
> We can use seqspert (see my other posting this evening) to look inside a
> SuperVector:
>
> seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
> #seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, :shift
> 5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
> nil nil nil nil nil nil]}, :tail [1 2 3]}, :right
> #seqspert.vector.Vector{:cnt 3, :shift 5, :root
> #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil nil
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
> nil nil nil]}, :tail [4 5 6]}, :middle 3, :count 6}
> seqspert.vector=> (p/pprint (decloak (supervec [1 2 3] [4 5 6])))
> {:left
>  {:cnt 3,
>   :shift 5,
>   :root
>   {:array
>[nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil]},
>   :tail [1 2 3]},
>  :right
>  {:cnt 3,
>   :shift 5,
>   :root
>   {:array
>[nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil]},
>   :tail [4 5 6]},
>  :middle 3,
>  :count 6}
> nil
> seqspert.vector=>
>
> It looks very complicated - that is the two clojurer vectors held inside !
> A SuperVector has fields left, right (the two vectors that we are
> combining), middle (the length of the left vector), and count (the sum of
> the counts of left and right).
>
> With just this info and very little code, I  found myself with a working
> impl (except 'pop' but who 'pop's a vector?).
>
> OK - there is a tiny extra runtime overhead associated with using a
> supervec - but, when you look at what is involved in dereffing into a
> vector, this quickly appears insignificant. It's about the same a using a
> subvec.
>
> The SuperVector code is checked into my clojure fork on github - see
> beginning of this thread. Seqspert is also at github - see the announcement
> I posted this evening.
>
> Finally 'supervec' is currently defined as:
>
> (defn supervec [l r] (APersistentVector$SuperVector. {} l r))
>
> I am thinking or renaming 'splice' from my earlier posting to 'combine'
> and creating a Combinable interface, to be implemented by any seq type that
> is able to do a fast re-combination with another seq of the same type. This
> could be leveraged by e.g. 'into' to deliver significant performance
> benefits and footprint reduction.
>
> more as and when,
>
>
> Jules
>
>
>
>
>
> On Saturday, 15 February 2014 23:06:24 UTC, Jules wrote:
>
>> Guys,
>>
>> I've been playing with reducers on and off for a while but have been
>> frustrated because they don't seem to fit a particular usecase that I have
>> in mind... specifically: getting as many associations into a hash-map as as
>> I can in as short a time as possible.
>>
>> My understanding of the reason for this is that reducers practice a

Re: fast parallel reduction into hash-set/map

[Jules]

Hi, Andy.

No I haven't - Thanks for the pointer - I'll take a look.

I have a very specific usecase - the speeding up of the re-combination of 
the results of parallel reductions.

I've found that the cost of this recombination often impacts badly on the 
overall timing of such a reduction, but with a little thought we can speed 
it up because we know that both seqs involved in the recombination are of 
the same type...

Given the proliferation of cores and FP's promise of simple and elegant 
parallel code, I think that it is critical that Clojure really delivers on 
this promise and this issue is the last blocker for me for a couple of 
usecases that I have :-)

I hope that explains where I am coming from - does it seem reasonable ? am 
I missing anything ?

thanks again,


Jules
  

On Thursday, 20 February 2014 23:25:29 UTC, Andy Fingerhut wrote:
>
> Have you looked at core.rrb-vector, which implements Relaxed Radix Trees 
> for vectors that implement subvec and concatenating two arbitrary vectors 
> in O(log n) time?
>
> https://github.com/clojure/core.rrb-vector
>
> Unless I am missing something, the fast concatenation is what you are 
> trying to achieve?
>
> Andy
>
>
> On Thu, Feb 20, 2014 at 2:59 PM, Jules  >wrote:
>
>>
>> So, having broken the back of fast re-combination of hash sets and maps, 
>> I wanted to take a look at doing a similar sort of thing for vectors - 
>> another type of seq that I use very heavily in this sort of situation.
>>
>> Let's see the cake first:
>>
>> seqspert.vector=> (def a (into [] (range 1000)))
>> #'seqspert.vector/a
>> seqspert.vector=> (time (def b (into a a)))
>> "Elapsed time: 3695.682654 msecs"
>> #'seqspert.vector/b
>> seqspert.vector=> (time (def c (supervec a a)))
>> "Elapsed time: 0.253922 msecs"
>> #'seqspert.vector/c
>> seqspert.vector=> (= b c)
>> true
>>
>> As you can see, the usual method of combining two vectors into a third 
>> takes 3-4 secs to combine two 10M entry vectors.
>>
>> Using 'supervec' it takes MUCH less time.
>>
>> How ?
>>
>> I looked at vector's impl and quickly realised that I would not be able 
>> to use the same trick that I had used for hash set/map. Then I looked at 
>> subvec and realised that I could do a very similar trick to create supervec.
>>
>> Subvec provides a view on a subseq of a vector that behaves like a full 
>> vector. Supervec provides a similar view that makes two vectors behave like 
>> a single one:
>>
>> seqspert.vector=> (supervec [1 2 3] [4 5 6])
>> [1 2 3 4 5 6]
>> seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
>> clojure.lang.APersistentVector$SuperVector
>>
>> We can use seqspert (see my other posting this evening) to look inside a 
>> SuperVector:
>>
>> seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
>> #seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, :shift 
>> 5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil 
>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>> nil nil nil nil nil nil]}, :tail [1 2 3]}, :right 
>> #seqspert.vector.Vector{:cnt 3, :shift 5, :root 
>> #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil nil 
>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>> nil nil nil]}, :tail [4 5 6]}, :middle 3, :count 6}
>> seqspert.vector=> (p/pprint (decloak (supervec [1 2 3] [4 5 6])))
>> {:left
>>  {:cnt 3,
>>   :shift 5,
>>   :root
>>   {:array
>>[nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil]},
>>   :tail [1 2 3]},
>>  :right
>>  {:cnt 3,
>>   :shift 5,
>>   :root
>>   {:array
>>[nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil
>> nil]},
>>   :tail [4 5 6]},
>>  :middle 3,
>>  :count 6}
>> nil
>> seqspert.vector=> 
>>
>> It looks very complicated - that is the two clojurer vectors held inside 
>> ! A SuperVector has fields left, right (the two vectors that we are 
>> combining), middle (the length of the left vector), and count (the sum of 
>> the counts of left and right).
>>
>> With just this info and very little code, I  found myself with a working 
>> impl (except 'pop' but who 'pop's a vector?).
>>
>> OK - there is a tiny extra runtime overhead associated with using a 
>> supervec - but, when you look at what is involved in dereffing into a 
>> vector, this quickly appears insignificant. It's about the same a using a 
>> subvec.
>>
>> The SuperVector code is c

Re: fast parallel reduction into hash-set/map

[shlomivaknin]

Hey Jules, 

Really nice stuff your making!
One note about your SuperVecs idea though, it seems that using that 
approach we could get a deeply nested tree to represent our a vector, and I 
think this is the exact thing vectors are trying to avoid.. 


On Friday, February 21, 2014 1:39:56 AM UTC+2, Jules wrote:
>
> Hi, Andy.
>
> No I haven't - Thanks for the pointer - I'll take a look.
>
> I have a very specific usecase - the speeding up of the re-combination of 
> the results of parallel reductions.
>
> I've found that the cost of this recombination often impacts badly on the 
> overall timing of such a reduction, but with a little thought we can speed 
> it up because we know that both seqs involved in the recombination are of 
> the same type...
>
> Given the proliferation of cores and FP's promise of simple and elegant 
> parallel code, I think that it is critical that Clojure really delivers on 
> this promise and this issue is the last blocker for me for a couple of 
> usecases that I have :-)
>
> I hope that explains where I am coming from - does it seem reasonable ? am 
> I missing anything ?
>
> thanks again,
>
>
> Jules
>   
>
> On Thursday, 20 February 2014 23:25:29 UTC, Andy Fingerhut wrote:
>>
>> Have you looked at core.rrb-vector, which implements Relaxed Radix Trees 
>> for vectors that implement subvec and concatenating two arbitrary vectors 
>> in O(log n) time?
>>
>> https://github.com/clojure/core.rrb-vector
>>
>> Unless I am missing something, the fast concatenation is what you are 
>> trying to achieve?
>>
>> Andy
>>
>>
>> On Thu, Feb 20, 2014 at 2:59 PM, Jules  wrote:
>>
>>>
>>> So, having broken the back of fast re-combination of hash sets and maps, 
>>> I wanted to take a look at doing a similar sort of thing for vectors - 
>>> another type of seq that I use very heavily in this sort of situation.
>>>
>>> Let's see the cake first:
>>>
>>> seqspert.vector=> (def a (into [] (range 1000)))
>>> #'seqspert.vector/a
>>> seqspert.vector=> (time (def b (into a a)))
>>> "Elapsed time: 3695.682654 msecs"
>>> #'seqspert.vector/b
>>> seqspert.vector=> (time (def c (supervec a a)))
>>> "Elapsed time: 0.253922 msecs"
>>> #'seqspert.vector/c
>>> seqspert.vector=> (= b c)
>>> true
>>>
>>> As you can see, the usual method of combining two vectors into a third 
>>> takes 3-4 secs to combine two 10M entry vectors.
>>>
>>> Using 'supervec' it takes MUCH less time.
>>>
>>> How ?
>>>
>>> I looked at vector's impl and quickly realised that I would not be able 
>>> to use the same trick that I had used for hash set/map. Then I looked at 
>>> subvec and realised that I could do a very similar trick to create supervec.
>>>
>>> Subvec provides a view on a subseq of a vector that behaves like a full 
>>> vector. Supervec provides a similar view that makes two vectors behave like 
>>> a single one:
>>>
>>> seqspert.vector=> (supervec [1 2 3] [4 5 6])
>>> [1 2 3 4 5 6]
>>> seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
>>> clojure.lang.APersistentVector$SuperVector
>>>
>>> We can use seqspert (see my other posting this evening) to look inside a 
>>> SuperVector:
>>>
>>> seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
>>> #seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, 
>>> :shift 5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil]}, :tail [1 2 3]}, :right 
>>> #seqspert.vector.Vector{:cnt 3, :shift 5, :root 
>>> #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil]}, :tail [4 5 6]}, :middle 3, :count 6}
>>> seqspert.vector=> (p/pprint (decloak (supervec [1 2 3] [4 5 6])))
>>> {:left
>>>  {:cnt 3,
>>>   :shift 5,
>>>   :root
>>>   {:array
>>>[nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil]},
>>>   :tail [1 2 3]},
>>>  :right
>>>  {:cnt 3,
>>>   :shift 5,
>>>   :root
>>>   {:array
>>>[nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil]},
>>>   :tail [4 5 6]},
>>>  :middle 3,
>>>  :count 6}
>>> nil
>>> seqspert.vector=> 
>>>
>>> It looks very complicated - that is the two clojurer vectors held inside 
>>> ! A SuperVector has fields left, right (the two vectors that we are 
>>

Re: fast parallel reduction into hash-set/map

[Jules]

I did give this some thought :-)

Reading the code for subvec, it looks like if you try to take a subvec of a 
subvec the top subvec cuts the intermediate subvec out of the process by 
recalculating a new projection on the underlying vector, relevant to the 
offsets imposed by the intermediate subvec. i.e. you will only ever travel 
through a single subvec before hitting the underlying vector.

I thought about doing something like this for supervec, but unlike subvec 
where you would only ever have to deal with a single underlying vector, 
with supervec i would have to manage an array of underlying vectors. I 
decided for the first cut, to just go with a binary impl.

In future I could try something like subvec, but I am also considering 
multivec :-) - both a subvec and a supervec. This would be able to collapse 
subvecs and supervecs into a single layer / set of offset calcs...

The jury is still out, but I thought I should put my ideas out onto the 
forum to kick off useful discussions just like this one ...

thanks for your interest,


Jules

On Thursday, 20 February 2014 23:51:46 UTC, shlomi...@gmail.com wrote:
>
> Hey Jules, 
>
> Really nice stuff your making!
> One note about your SuperVecs idea though, it seems that using that 
> approach we could get a deeply nested tree to represent our a vector, and I 
> think this is the exact thing vectors are trying to avoid.. 
>
>
> On Friday, February 21, 2014 1:39:56 AM UTC+2, Jules wrote:
>>
>> Hi, Andy.
>>
>> No I haven't - Thanks for the pointer - I'll take a look.
>>
>> I have a very specific usecase - the speeding up of the re-combination of 
>> the results of parallel reductions.
>>
>> I've found that the cost of this recombination often impacts badly on the 
>> overall timing of such a reduction, but with a little thought we can speed 
>> it up because we know that both seqs involved in the recombination are of 
>> the same type...
>>
>> Given the proliferation of cores and FP's promise of simple and elegant 
>> parallel code, I think that it is critical that Clojure really delivers on 
>> this promise and this issue is the last blocker for me for a couple of 
>> usecases that I have :-)
>>
>> I hope that explains where I am coming from - does it seem reasonable ? 
>> am I missing anything ?
>>
>> thanks again,
>>
>>
>> Jules
>>   
>>
>> On Thursday, 20 February 2014 23:25:29 UTC, Andy Fingerhut wrote:
>>>
>>> Have you looked at core.rrb-vector, which implements Relaxed Radix Trees 
>>> for vectors that implement subvec and concatenating two arbitrary vectors 
>>> in O(log n) time?
>>>
>>> https://github.com/clojure/core.rrb-vector
>>>
>>> Unless I am missing something, the fast concatenation is what you are 
>>> trying to achieve?
>>>
>>> Andy
>>>
>>>
>>> On Thu, Feb 20, 2014 at 2:59 PM, Jules  wrote:
>>>

 So, having broken the back of fast re-combination of hash sets and 
 maps, I wanted to take a look at doing a similar sort of thing for vectors 
 - another type of seq that I use very heavily in this sort of situation.

 Let's see the cake first:

 seqspert.vector=> (def a (into [] (range 1000)))
 #'seqspert.vector/a
 seqspert.vector=> (time (def b (into a a)))
 "Elapsed time: 3695.682654 msecs"
 #'seqspert.vector/b
 seqspert.vector=> (time (def c (supervec a a)))
 "Elapsed time: 0.253922 msecs"
 #'seqspert.vector/c
 seqspert.vector=> (= b c)
 true

 As you can see, the usual method of combining two vectors into a third 
 takes 3-4 secs to combine two 10M entry vectors.

 Using 'supervec' it takes MUCH less time.

 How ?

 I looked at vector's impl and quickly realised that I would not be able 
 to use the same trick that I had used for hash set/map. Then I looked at 
 subvec and realised that I could do a very similar trick to create 
 supervec.

 Subvec provides a view on a subseq of a vector that behaves like a full 
 vector. Supervec provides a similar view that makes two vectors behave 
 like 
 a single one:

 seqspert.vector=> (supervec [1 2 3] [4 5 6])
 [1 2 3 4 5 6]
 seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
 clojure.lang.APersistentVector$SuperVector

 We can use seqspert (see my other posting this evening) to look inside 
 a SuperVector:

 seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
 #seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, 
 :shift 5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil 
 nil 
 nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
 nil 
 nil nil nil nil nil nil nil]}, :tail [1 2 3]}, :right 
 #seqspert.vector.Vector{:cnt 3, :shift 5, :root 
 #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil 
 nil 
 nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
 nil 
 nil nil nil]}

Re: fast parallel reduction into hash-set/map

[Alan Busby]

On Fri, Feb 21, 2014 at 8:51 AM,  wrote:

> One note about your SuperVecs idea though, it seems that using that
> approach we could get a deeply nested tree to represent our a vector, and I
> think this is the exact thing vectors are trying to avoid..


In general I think this is true for vectors, but in this covers one
particular use-case where I've often found generation time to be more
important that a faster lookup.
If you favor a faster lookup then a normal vector can be used instead of
course.

-- 
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/groups/opt_out.

Re: [ANN] seqspert - demystify the internals of Clojure Sequences

[Ambrose Bonnaire-Sergeant]

Nice, thanks for releasing!

Ambrose


On Fri, Feb 21, 2014 at 5:47 AM, Jules  wrote:

> I've been teaching myself a bit about the internals of various Clojure
> seqs over the last week or so... maps, sets, vectors etc..
>
> I started with a little Clojure to help me drill into the Seq POJOS - this
> quickly grew into Seqspert :-)
>
> I think that if you want to write performant code, you need to understand
> a bit about your hardware (mechanical sympathy), the JVM  and the Clojure
> runtime. The Seqs are a large part of this and Seqspert will help you
> quickly understand how they work.
>
> Please take a look:
>
> https://github.com/JulesGosnell/seqspert.git
>
> regards,
>
>
> Jules
>
>
>
>  --
> 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jules]

all true.

Also, if you look at the internal structure of PersistentVector (perhaps 
using me seqspert lib - announced this evening), you would see that 
PersistentVector is actually implemented as a tree. Recombination through 
several levels of supervec could simply be thought of as extending this 
tree up above the combined nodes, but with a smaller branching factor.

Jules


On Friday, 21 February 2014 00:10:19 UTC, TheBusby wrote:
>
> On Fri, Feb 21, 2014 at 8:51 AM, >
>  wrote:
>
>> One note about your SuperVecs idea though, it seems that using that 
>> approach we could get a deeply nested tree to represent our a vector, and I 
>> think this is the exact thing vectors are trying to avoid.. 
>
>
> In general I think this is true for vectors, but in this covers one 
> particular use-case where I've often found generation time to be more 
> important that a faster lookup. 
> If you favor a faster lookup then a normal vector can be used instead of 
> course.
>  

-- 
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/groups/opt_out.

Re: [ANN] seqspert - demystify the internals of Clojure Sequences

[Jules]

welcome :-)

Jules


On Friday, 21 February 2014 00:16:11 UTC, Ambrose Bonnaire-Sergeant wrote:
>
> Nice, thanks for releasing!
>
> Ambrose
>
>
> On Fri, Feb 21, 2014 at 5:47 AM, Jules  >wrote:
>
>> I've been teaching myself a bit about the internals of various Clojure 
>> seqs over the last week or so... maps, sets, vectors etc..
>>
>> I started with a little Clojure to help me drill into the Seq POJOS - 
>> this quickly grew into Seqspert :-)
>>
>> I think that if you want to write performant code, you need to understand 
>> a bit about your hardware (mechanical sympathy), the JVM  and the Clojure 
>> runtime. The Seqs are a large part of this and Seqspert will help you 
>> quickly understand how they work.
>>
>> Please take a look:
>>
>> https://github.com/JulesGosnell/seqspert.git
>>
>> regards,
>>
>>
>> Jules
>>
>>
>>
>>  -- 
>> 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/groups/opt_out.
>>
>
>

-- 
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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Jean Niklas L'orange]

Hi Jules,

On Thursday, February 20, 2014 11:59:03 PM UTC+1, Jules wrote:
>
> Subvec provides a view on a subseq of a vector that behaves like a full 
> vector. Supervec provides a similar view that makes two vectors behave like 
> a single one
>

This data structure ("supervec") is usually known as a rope, and your 
implementation degrades the *~O(1)* to worst case *O(k)* time for lookups, 
assoc, conj and pop, where *k* is the amount of concatenations performed. A 
good rope implementation can reduce that factor down to *O(log k)* through 
balancing, but it will still break the performance guarantees a persistent 
vector is supposed to have. If you try to use this in the reducers library, 
the amount of concatenations fork/join performs might actually show notable 
performance degradation for those operations. Further, passing it around to 
code which might perform more concatenations will lead to even worse 
performance, which may be hard to debug for people not knowing Clojure 
internals.

However, it is a very nice solution if you know there will be limited 
concatenations, that the concatenations result in a balanced tree, and you 
don't pass this vector around to other people. :)

For a small discussion on this vs. RRB-trees, see Section 1.1 in 
http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf.

Hopefully I'm not destroying your fun playing around with these things—that 
is not the intent at all. I'm just saying that these things are (sadly?) 
harder than it first looks like.

-- JN

-- 
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/groups/opt_out.

Re: Namespace Problems org-mode/org-babel

[Volker Strobel]

Thanks Maik! I just re-installed the most recent org-mode version (although 
I was 99.9 % sure, I did the same steps two days ago...) and now everything 
works fine! Quite simple, as I was looking for the error many, many hours 
(and several times stumbled across your 2012 blog post "Literate 
Programming in Clojure";) )
Bye for now,
Volker


Am Donnerstag, 20. Februar 2014 23:12:27 UTC+1 schrieb Maik Schünemann:
>
> Sorry for the short answer I am writing this on my phone.
> I am also using org mode and the following works fine for me:
> 1 evaluate the first block.
> Now cider should already be in the right namespace. 
> 2. The next source block can be evaluated in the current ns.
> You basically have to make sure that the cider session is in the right 
> state after evaluating the first source block.
> If that doesn't work for you, try adding an (in-ns ...) To the beginning 
> of the second source block.
>
> Also make sure that you are using the most recent org mode version to get 
> proper support for clojure
>
> Hope that helps
>
>> I should mention, that I use cider and followd the instructions on this 
>> page for the setup: 
>> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html
>>
>  -- 
> 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/groups/opt_out.
>  

-- 
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/groups/opt_out.

Re: Is ^{:once true} still necessary for lazy-seqs?

[Alan Malloy]

^:once is absolutely needed for lazy seqs, because it allows the 
closed-over variables to get cleared while the lambda is *still running*, 
rather than waiting for it to finish. You can see the difference in this 
repl session:

user> (let [x (for [n (range)] (make-array Object 1)), f (^:once fn* [] 
(nth x 1e6))] (f))
#
user> (let [x (for [n (range)] (make-array Object 1)), f (fn* [] (nth x 
1e6))] (f))
; Evaluation aborted.

Of course you may need to tune the numbers to make sure it runs out of 
space on your machine, but the point is that without ^:once, the lambda f 
holds onto the head of x, in case f is called again. ^:once constitutes a 
promise to only ever call it once, and so the sequence is cleaned up as 
soon as possible. My example doesn't use LazySeq, but I hope you can see 
how the same considerations apply there.

On Tuesday, February 18, 2014 9:39:06 AM UTC-8, pron wrote:
>
> lazy-seq marks it's supplied lambdata with ^{:once true} to prevent the 
> memory leak described at the bottom of this page 
> .
> However, while going over the code for clojure.lang.LazySeq, I noticed 
> that ever since this commit by 
> Rich,
>  
> LazySeq doesn't extend AFn, but rather contains a reference to the lambda, 
> fn, which it nullifies immediately after the first use, supposedly 
> preventing any leaks caused by closed locals.
> So my question is, is ^{:once true} still necessary for lazy-seqs, or does 
> this (pretty old) change to LazySeq make it redundant?
>
> Ron
>
>

-- 
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/groups/opt_out.

Re: core.async over websocket + cljs + clojure

[tonihe]

Anyone come up with anything? 

I'm also wondering ways to abstract this problem. Here's my current 
impl https://gist.github.com/whodidthis/9126971, you can imagine chord 
instead of the input and output channels. Any ideas and suggestions would 
be cool as im new to clojure.

On Thursday, January 23, 2014 8:39:06 AM UTC+1, t x wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the 
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via 
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects / 
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels 
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable 
> design is fine.
>
> 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/groups/opt_out.

Re: fast parallel reduction into hash-set/map

[Ghadi Shayban]

Jules,
For recombination of parallel reductions into a vector, have you looked at 
foldcat?
  
It works really well, and it's one of those wonderful gems in clojure.core 
waiting to be noticed.  It gives you back a structure that is counted, 
seqable, and re-foldable - which covers probably 99% of use cases.  The 
returned structure is not indexed, that is intentional.

It's definitely conceivable to have the equivalent of a 'transient merge' 
op for maps, and a design doc on clojure 
wikiis definitely warranted.

I echo the recommendation for RRB-trees when you need efficient combination 
that returns an indexed structure.  If you don't, foldcat = delicious.  
Jean is right about the many ways a superstructure can degrade.

Ghadi

On Thursday, February 20, 2014 8:09:26 PM UTC-5, Jean Niklas L'orange wrote:
>
> Hi Jules,
>
> On Thursday, February 20, 2014 11:59:03 PM UTC+1, Jules wrote:
>>
>> Subvec provides a view on a subseq of a vector that behaves like a full 
>> vector. Supervec provides a similar view that makes two vectors behave like 
>> a single one
>>
>
> This data structure ("supervec") is usually known as a rope, and your 
> implementation degrades the *~O(1)* to worst case *O(k)* time for 
> lookups, assoc, conj and pop, where *k* is the amount of concatenations 
> performed. A good rope implementation can reduce that factor down to *O(log 
> k)* through balancing, but it will still break the performance guarantees 
> a persistent vector is supposed to have. If you try to use this in the 
> reducers library, the amount of concatenations fork/join performs might 
> actually show notable performance degradation for those operations. 
> Further, passing it around to code which might perform more concatenations 
> will lead to even worse performance, which may be hard to debug for people 
> not knowing Clojure internals.
>
> However, it is a very nice solution if you know there will be limited 
> concatenations, that the concatenations result in a balanced tree, and you 
> don't pass this vector around to other people. :)
>
> For a small discussion on this vs. RRB-trees, see Section 1.1 in 
> http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf.
>
> Hopefully I'm not destroying your fun playing around with these 
> things—that is not the intent at all. I'm just saying that these things are 
> (sadly?) harder than it first looks like.
>
> -- JN
>

-- 
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/groups/opt_out.

Re: How to compose a java function

[Mikera]

On Friday, 21 February 2014 06:02:51 UTC+8, Steffen Panning wrote:
>
> Hi all,
>
> I want to compose a java function call out of a string in a macro:
>
> I tried something like this simplified example, but it doesn't work.
> creating a symbol out of a string is not enough.
> Note: I know that uppercase variable names are bad, but it simplifies the 
> example.
>
> So how I do it right?
>
> TIA Steffen
>
> repl:
>
> user> (defmacro set-example [obj feature]
>   (let [meth-name# (symbol (str ".set" (name feature)))]
> `(~meth-name# ~obj  ~feature)))
>
> #'user/set-example
> user> (let [o (javax.swing.JCheckBox . "foo")
>
Looks like you have an extra space here.

Constructor syntax is (ClassName. "foo"), without a space between the class 
name and the "."
 

> Label "xxx"]  
> (set-example o Label))
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: . 
> in this context, compiling:(/tmp/form-init6247570319423795481.clj:1:9) 
>
>

-- 
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/groups/opt_out.

Re: How to compose a java function

[Steffen Panning]

Thanks.

Note to self: Don't post when you are dead tired.

greetings Steffen


On Thursday, February 20, 2014 11:02:51 PM UTC+1, Steffen Panning wrote:
>
> Hi all,
>
> I want to compose a java function call out of a string in a macro:
>
> I tried something like this simplified example, but it doesn't work.
> creating a symbol out of a string is not enough.
> Note: I know that uppercase variable names are bad, but it simplifies the 
> example.
>
> So how I do it right?
>
> TIA Steffen
>
> repl:
>
> user> (defmacro set-example [obj feature]
>   (let [meth-name# (symbol (str ".set" (name feature)))]
> `(~meth-name# ~obj  ~feature)))
>
> #'user/set-example
> user> (let [o (javax.swing.JCheckBox . "foo")
> Label "xxx"]  
> (set-example o Label))
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: . 
> in this context, compiling:(/tmp/form-init6247570319423795481.clj:1:9) 
>
>

-- 
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/groups/opt_out.

Re: Namespace Problems org-mode/org-babel

[Volker Strobel]

Now I have the same problem again... Everything worked fine for a few 
hours, until now.
Again, I tried to re-install/rebuild org-mode (development version from 
git) etc.
I don't know what suddenly went wrong (I moved my .org file from the src/ 
folder to the leiningen project folder, but I undid that again).
I also created a new leiningen project in order to start from scratch. If I 
include (in-ns ...) in every code block it'll work fine, but I really would 
try to avoid that.
Here is an example again:

#+BEGIN_SRC clojure :tangle core.clj
(ns org-works.core
  (:gen-class))
#+END_SRC

#+RESULTS:
: nil

#+BEGIN_SRC clojure :tangle core.clj
(in-ns 'org-works.core)
(def a 5)

#+END_SRC

#+RESULTS:
: #'org-works.core/a

#+BEGIN_SRC clojure :tangle core.clj
(def b 5)

#+END_SRC

#+RESULTS:
: #'user/b

Currently this file is located in the src folder of the leiningen project. 
How can I make org-mode to use the correct namespace again?
Thanks, again!
Volker

-- 
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/groups/opt_out.