Re: [GSoC] Mentors contact information

[Christopher Medrela]

Alex, Ambrose, thank you for quick answer. I'll contact you soon. I'm sorry 
for
overlooking your mail, Ambrose.

By the way, I can read at student application guidelines in "project
information" section [1]:

 GSoC officially runs from 19 May–22 Aug, a period of 14 weeks.  

while the official GSoC website says [2]:

25 May: Students begin coding for their Google Summer of Code projects;
17 August: Suggested 'pencils down' date
21 August 19:00 UTC: Firm 'pencils down' date.

[1] http://dev.clojure.org/display/community/Student+application+guidelines
[2] https://www.google-melange.com/gsoc/events/google/gsoc2015

-- 
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: [OT?] Best DB/architecture for n-gram corpus?

[John Wiseman]

OK, I see.  Well, on non-trivially sized corpora, I think storage
requirements can become an issue, and in a situation where you're handling
user queries one might wonder how often someone will query a 10-gram.  But
if you can make it work, go nuts!

For a lot of statistical language modeling there seems to be a sweet spot
at the 3-gram point.  I feel like I even saw a paper recently that compared
different human languages and concluded something about the importance of
trigrams, but I can't find it now.


On Tue, Mar 10, 2015 at 10:58 AM, Sam Raker  wrote:

> I more meant deciding on a maximum size and storing them qua ngrams--it
> seems limiting. On the other hand, after a certain size, they stop being
> ngrams and start being something else--"texts," possibly.
>
> On Tuesday, March 10, 2015 at 1:29:44 PM UTC-4, John Wiseman wrote:
>>
>> By "hard coding" n-grams, do you mean using the simple string
>> representation, e.g. "aunt rhodie" as the key in your database?  If so,
>> then maybe it helps to think of it from the perspective that it's not
>> really just text, it's a string that encodes an n-gram just like
>> "[\"aunt\", \"rhodie\"]" is another way to encode an n-gram--the
>> encoding/decoding uses clojure.string/join and clojure.string/split instead
>> of json/write and json/read, and escaping tokens that contain spaces is on
>> your TODO list at a low priority :)
>>
>> (And I think the Google n-gram corpus
>>  uses the same format.)
>>
>>
>> John
>>
>>
>> On Mon, Mar 9, 2015 at 7:09 PM, Sam Raker  wrote:
>>
>>> That's interesting. I've been really reluctant to "hard code" n-grams,
>>> but it's probably the best way to go.
>>>
>>> On Monday, March 9, 2015 at 6:12:43 PM UTC-4, John Wiseman wrote:

 One thing you can do is index 1, 2, 3...n-grams and use a simple & fast
 key-value store (like leveldb etc.)  e.g., you could have entries like

 "aunt rhodie" -> song-9, song-44
 "woman" -> song-12, song-65, song-96


 That's basically how I made the Metafilter N-gram Viewer
 , a clone of Google Books Ngram Viewer
 .

 Another possibility is using Lucene.  Just be aware that Lucene calls
 n-grams of characters ("au", "un", "nt") n-grams but it calls n-grams of
 words ("that the", "the old", "old gray") shingles.  So you would end up
 using (I think, I haven't done this) the ShingleFilter
 
 .

 You might also find this article by Russ Cox interesting, where he
 describes building and using an inverted trigram index:
 http://swtch.com/~rsc/regexp/regexp4.html


 John





 Three things that you might find interesting:

 Russ Cox' explanation of doing indexing and retrieval with an inverted
 trigram index: http://swtch.com/~rsc/regexp/regexp4.html


 On Sat, Mar 7, 2015 at 3:22 AM, Matching Socks 
 wrote:

> A lot of guys would use Lucene.  Lucene calls n-grams of words
> "shingles". [1]
>
> As for "architecture", here is a suggestion to use Lucene to find keys
> to records in your "real" database. [2]
>
> [1] https://lucidworks.com/blog/whats-a-shingle-in-lucene-parlance/
>
> [2] https://groups.google.com/d/msg/datomic/8yrCYxcQq34/GIomGaarX5QJ
>
>
>  --
> 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 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, visi

Re: [OT?] Best DB/architecture for n-gram corpus?

[Sam Raker]

That's honestly closer to what I was originally envisioning--I've never 
really looked into graph dbs before, but I'll check out Neo4j tonight. Do 
you know whether you can model multiple edges between the same nodes? I'd 
love to be able to have POS-based wildcarding as a feature, so you could 
search for e.g. "the ADJ goose", but that's a whole other layer of stuff, 
so it might go in the "eventually, maybe" pile.



On Tuesday, March 10, 2015 at 3:47:37 PM UTC-4, Ray Miller wrote:
>
> On 10 March 2015 at 17:58, Sam Raker > 
> wrote: 
> > I more meant deciding on a maximum size and storing them qua ngrams--it 
> > seems limiting. On the other hand, after a certain size, they stop being 
> > ngrams and start being something else--"texts," possibly. 
>
> Exactly. When I first read your post, I almost suggested you model 
> this in a graph database like Neo4j or Titan. Each word would be a 
> node in the graph with an edge linking it to the next word in the 
> sentence. You could define an index on the words (so retrieving all 
> nodes for a given word would be fast), then follow edges to find and 
> count particular n-grams. This is more complicated than the relational 
> model I proposed, and will be a bit slower to query. But if you don't 
> want to put an upper-bound on the length of the n-gram when you index 
> the data, it might be the way to go. 
>
> Ray. 
>

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

Adding directory to classpath in leiningen

[Cecil Westerhof]

I have some files in:
~/Clojure
that I want to use in a project I start with:
lein repl

But I do not see how to do this. How can I acomplish this?

-- 
Cecil Westerhof

-- 
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: [OT?] Best DB/architecture for n-gram corpus?

[Sam Raker]

POS tagging is a solved-enough problem, at least in most domains. Clojure 
still doesn't have its own NLTK (HINT HINT, GSOC kids!), but I'm sure I can 
find a Java lib or 2 that should do the job well enough.

On Tuesday, March 10, 2015 at 4:27:17 PM UTC-4, Ray Miller wrote:
>
> On 10 March 2015 at 20:03, Sam Raker > 
> wrote: 
> > That's honestly closer to what I was originally envisioning--I've never 
> > really looked into graph dbs before, but I'll check out Neo4j tonight. 
> Do 
> > you know whether you can model multiple edges between the same nodes? 
>
> Yes, certainly possible. 
>
> If you go for Neo4j you have two options for Clojure: embedded (with 
> the borneo library and reading Javadoc, or plain Java interop) or 
> stand-alone server with REST API (with the well-documented Neocons 
> library from Clojurewerkz). You'll also have to think about how to 
> model which text (song) each phrase came from - likely another node 
> type in the graph with a linking edge to the start of the phrase. 
>
> Great book on Neo4j available for free download, also covers data 
> modelling: http://neo4j.com/books/ 
>
> > I'd love to be able to have POS-based wildcarding as a feature, so you 
> could 
> > search for e.g. "the ADJ goose", but that's a whole other layer of 
> stuff, so 
> > it might go in the "eventually, maybe" pile. 
>
> Sounds like fun, but means doing some natural language processing on 
> the input texts, which is a much more difficult problem than simply 
> tokenizing. 
>
> Ray. 
>

-- 
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: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

[Peter West]

On Wednesday, 11 March 2015 23:38:40 UTC+10, Peter West  wrote:
> On Tuesday, 10 March 2015 09:41:45 UTC+10, David Nolen  wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> > 
> > New release version: 0.0-3058
> > 
> > The new Quick Start is essential reading even if you are a relatively
> > experienced ClojureScript developer.
> 
> 
> I did this, and worked through the example.  When I got to
> 
> Require your namespace by evaluating (require '[hello-world.core :as hello])
> 
> the REPL hung.  Any suggestions?

OS X 10.10.2  java version "1.8.0_31" tried with both Safari and Opera browsers.

-- 
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: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

[Peter West]

On Tuesday, 10 March 2015 09:41:45 UTC+10, David Nolen  wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> New release version: 0.0-3058
> 
> The new Quick Start is essential reading even if you are a relatively
> experienced ClojureScript developer.


I did this, and worked through the example.  When I got to

Require your namespace by evaluating (require '[hello-world.core :as hello])

the REPL hung.  Any suggestions?

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

volatile vs java.util.concurrent.atomic.* vs atom

[Brent Millare]

Doing some simple microbenchmarks, I found something unexpected:

(time
 (let [v (volatile! 1)]
   (dotimes [x 1]
 (vreset! v @v
"Elapsed time: 1016.992146 msecs"

(time
 (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
   (dotimes [x 1]
 (.set v (.get v)
"Elapsed time: 672.869727 msecs"

(time
 (let [v (java.util.concurrent.atomic.AtomicReference. {})]
   (dotimes [x 1]
 (.set v (.get v)
"Elapsed time: 678.143133 msecs"

(time
 (let [v (atom 1)]
   (dotimes [x 1]
 (reset! v @v
"Elapsed time: 1100.689493 msecs"

I expected volatile's to be faster. Maybe I'm not understanding the correct 
use case for volatiles but java.util.concurrent.atomic.Atomic* seems to be 
clearly the most performant. Given the downsides of using volatiles, is 
their existence justified when safer and faster alternatives exist?

-- 
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: Composing Stuart Sierra's components

[Colin Yates]

Hi Jonah,

This is quite comparable to micro-services - each service is an abstraction 
or at least a facade and wants to play in a bigger system, but each 
micro-service may itself have its own stateful graph to maintain.

I think I will explore my original direction of having a 
AComponentWhichDrivesAnEntireSystem and see how far I get with that.

On Wednesday, 11 March 2015 20:53:45 UTC, jonah wrote:
>
> Hey Colin, it sounds like:
>
> * if the 2 systems really can't function without each other, and their 
> start/stop lifecycles are tightly bound, then somehow they have to be 
> merged into a single system
>
> or
>
> * if the 2 systems can't be merged into a single system because of true 
> functional or lifecycle independence and non-overlapping dependencies, then 
> semantics for what it means for each system to not have the other available 
> at lifecycle event times have to be established
>
> It smells like the latter may be the way to go. So in pseudocode, the 
> reusable-component-system that "owns" the reusable-component would not 
> receive an instance of the external-collaborator at creation time. Instead, 
> the reusable-component would have a somewhat weaker definition of its start 
> semantics, and perhaps would have a way to refer to the 
> external-collaborator only by name. 
>
> That is, perhaps the external-collaborator provided to the 
> reusable-component is really an external-collaborator-client that is 
> configured to know the name of the external-collaborator- which is owned by 
> larger-system- and shields the reusable-component in cases where the larger 
> system has not been started or the collaborator isn't available.
>
> And perhaps similarly the larger-system has a reusable-component-client or 
> reusable-client-proxy that is able to bridge appropriately from 
> larger-system to the reusable-component. 
>
> And maybe both client components are configured with the same :bus for 
> cross-system communication (and perhaps the cross-system bus is owned by a 
> bridge system). Just riffing, as it's not precisely clear what the 
> semantics of the systems are. 
>
> Stuart's comment that he hasn't run into a need for systems of systems is 
> coming to mind. Perhaps it makes sense to break these apart more explicitly 
> in accordance with guidelines around managing micro-services. Easy to say, 
> of course. :)
>
> Not sure if that's helpful
>
> Jonah
>
>
>
> On Wed, Mar 11, 2015 at 3:01 PM, Colin Yates  > wrote:
>
>> merge won't help as there will be name space clashes.
>>
>> I wonder if a more elegant approach would be to construct the 'inner'
>> system and then assoc onto it the external dependencies it needs
>> before calling start.
>>
>> On 11 March 2015 at 18:49,  > wrote:
>> > I believe I misunderstood your question; I didn't realize it was system 
>> (as
>> > opposed to any general component) specific. I think systems can be 
>> merged
>> > together (via 'merge'). Would that help?
>> >
>> > On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:
>> >>
>> >> Hi Adrian - I don't follow how that helps integrate two different
>> >> systems - I wonder if my question was unclear or I am missing
>> >> something in your answer. Would you mind posting some pseudo code to
>> >> clarify please?
>> >>
>> >> On 11 March 2015 at 18:32,   wrote:
>> >> > You can specify component dependencies using the 'using' function as 
>> you
>> >> > know. As long as you know the key of the component in the system you 
>> can
>> >> > specify this dependency wherever you construct the component. If you
>> >> > want to
>> >> > parameterize dependencies, write a constructor function which takes 
>> the
>> >> > external dependency as a value.
>> >> >
>> >> > On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
>> >> >>
>> >> >> I have a non-trivial component which requires a bunch of internal 
>> and
>> >> >> external collaborators to work. This component is itself re-usable.
>> >> >>
>> >> >> What I really want to do is have ReusableComponent be a component 
>> in a
>> >> >> system so it can pull its external collaborators. However,
>> >> >> ReusableComponent
>> >> >> constructs its own services etc. so it really want to be (or at 
>> least
>> >> >> have
>> >> >> access to) a system.
>> >> >>
>> >> >> For example, let's say I have the following:
>> >> >>
>> >> >> (defrecord InternalToReusableComponent [bus]
>> >> >>   (component/Lifecycle
>> >> >> (start [this]...))
>> >> >>
>> >> >> (defrecord ReusableComponent [bus logger]
>> >> >>   (component/Lifecycle
>> >> >> (start [this]
>> >> >>
>> >> >>   this)
>> >> >> ))
>> >> >>
>> >> >> (defn reusable-component-system [external-collaborator]
>> >> >>   (component/system-map
>> >> >> :bus ()
>> >> >> :logger ()
>> >> >> :reusable-component (component/using (map->ReusableComponent {})
>> >> >> [:bus
>> >> >> :logger external-collaborator]))
>> >> >>
>> >> >> Fine - I now have a system from w

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Timothy Baldridge]

Actaully I think it comes down to the use of the rather generic Deref. I
fired up a repl and ran the following

(let [v (clojure.lang.Volatile. {})]
  (dotimes [x ...]
(.reset v (.deref v

I'm seeing very similar times to the one for the AtomicReference.

Timothy

On Wed, Mar 11, 2015 at 11:08 AM, Brent Millare 
wrote:

> I find it hard to believe GC would be a factor since there is very little
> being generated here. Also, while the outside loop is only 10 iterations of
> timings, in the inside loops the code is called for 100 million iterations.
> Anyways, running it with criterium didn't change the ranking.
>
> Here is the output:
> volatile: WARNING: Final GC required 1.149417308725186 % of runtime
> Evaluation count : 4156079100 in 60 samples of 69267985 calls.
>  Execution time mean : 12.975339 ns
> Execution time std-deviation : 0.188921 ns
>Execution time lower quantile : 12.823222 ns ( 2.5%)
>Execution time upper quantile : 13.272950 ns (97.5%)
>Overhead used : 1.613416 ns
> AtomicLong: Evaluation count : 6921767160 in 60 samples of 115362786 calls.
>  Execution time mean : 7.155989 ns
> Execution time std-deviation : 0.124147 ns
>Execution time lower quantile : 7.048738 ns ( 2.5%)
>Execution time upper quantile : 7.330448 ns (97.5%)
>Overhead used : 1.613416 ns
> AtomicReference: Evaluation count : 5814704460 in 60 samples of 96911741
> calls.
>  Execution time mean : 8.791224 ns
> Execution time std-deviation : 0.185229 ns
>Execution time lower quantile : 8.564921 ns ( 2.5%)
>Execution time upper quantile : 9.340265 ns (97.5%)
>Overhead used : 1.613416 ns
>
> Found 4 outliers in 60 samples (6.6667 %)
> low-severe 2 (3. %)
> low-mild 2 (3. %)
>  Variance from outliers : 9.4134 % Variance is slightly inflated by
> outliers
> atom: Evaluation count : 4038207840 in 60 samples of 67303464 calls.
>  Execution time mean : 13.007604 ns
> Execution time std-deviation : 0.202285 ns
>Execution time lower quantile : 12.819268 ns ( 2.5%)
>Execution time upper quantile : 13.275983 ns (97.5%)
>Overhead used : 1.613416 ns
>
> Note: I bench the get/set expression, not the creation of the
> volatile/atomic*/atom
>
> eg.
> (let [v (volatile! 1)]
>   (c/bench (vreset! v @v)))
>
> On Wednesday, March 11, 2015 at 12:30:06 PM UTC-4, tbc++ wrote:
>>
>> There's many other factors involved here though, GC, JIT warmup, etc.
>> That's kindof what criterium helps out with, removing all the variables and
>> running something until the JIT has warmed up enough (10 iterations
>> probably isn't enough).
>>
>> Timothy
>>
>>
>>   --
> 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: volatile vs java.util.concurrent.atomic.* vs atom

[Brent Millare]

Good catch. With criterium, I can detect the small performance improvement.

volatile: Evaluation count : 7550019420 in 60 samples of 125833657 calls.
 Execution time mean : 6.345042 ns
Execution time std-deviation : 0.126086 ns
   Execution time lower quantile : 6.223058 ns ( 2.5%)
   Execution time upper quantile : 6.525868 ns (97.5%)
   Overhead used : 1.651549 ns
AtomicLong: Evaluation count : 6925392540 in 60 samples of 115423209 calls.
 Execution time mean : 7.156855 ns
Execution time std-deviation : 0.136142 ns
   Execution time lower quantile : 7.010743 ns ( 2.5%)
   Execution time upper quantile : 7.362120 ns (97.5%)
   Overhead used : 1.651549 ns
AtomicReference: Evaluation count : 6014401080 in 60 samples of 100240018 
calls.
 Execution time mean : 8.342217 ns
Execution time std-deviation : 0.126856 ns
   Execution time lower quantile : 8.129171 ns ( 2.5%)
   Execution time upper quantile : 8.511877 ns (97.5%)
   Overhead used : 1.651549 ns


On Wednesday, March 11, 2015 at 1:50:37 PM UTC-4, tbc++ wrote:
>
> Actaully I think it comes down to the use of the rather generic Deref. I 
> fired up a repl and ran the following 
>
> (let [v (clojure.lang.Volatile. {})]
>   (dotimes [x ...]
> (.reset v (.deref v
>
> I'm seeing very similar times to the one for the AtomicReference.
>
> Timothy
>
> On Wed, Mar 11, 2015 at 11:08 AM, Brent Millare  > wrote:
>
>> I find it hard to believe GC would be a factor since there is very little 
>> being generated here. Also, while the outside loop is only 10 iterations of 
>> timings, in the inside loops the code is called for 100 million iterations. 
>> Anyways, running it with criterium didn't change the ranking.
>>
>> Here is the output:
>> volatile: WARNING: Final GC required 1.149417308725186 % of runtime
>> Evaluation count : 4156079100 in 60 samples of 69267985 calls.
>>  Execution time mean : 12.975339 ns
>> Execution time std-deviation : 0.188921 ns
>>Execution time lower quantile : 12.823222 ns ( 2.5%)
>>Execution time upper quantile : 13.272950 ns (97.5%)
>>Overhead used : 1.613416 ns
>> AtomicLong: Evaluation count : 6921767160 in 60 samples of 115362786 
>> calls.
>>  Execution time mean : 7.155989 ns
>> Execution time std-deviation : 0.124147 ns
>>Execution time lower quantile : 7.048738 ns ( 2.5%)
>>Execution time upper quantile : 7.330448 ns (97.5%)
>>Overhead used : 1.613416 ns
>> AtomicReference: Evaluation count : 5814704460 in 60 samples of 96911741 
>> calls.
>>  Execution time mean : 8.791224 ns
>> Execution time std-deviation : 0.185229 ns
>>Execution time lower quantile : 8.564921 ns ( 2.5%)
>>Execution time upper quantile : 9.340265 ns (97.5%)
>>Overhead used : 1.613416 ns
>>
>> Found 4 outliers in 60 samples (6.6667 %)
>> low-severe 2 (3. %)
>> low-mild 2 (3. %)
>>  Variance from outliers : 9.4134 % Variance is slightly inflated by 
>> outliers
>> atom: Evaluation count : 4038207840 in 60 samples of 67303464 calls.
>>  Execution time mean : 13.007604 ns
>> Execution time std-deviation : 0.202285 ns
>>Execution time lower quantile : 12.819268 ns ( 2.5%)
>>Execution time upper quantile : 13.275983 ns (97.5%)
>>Overhead used : 1.613416 ns
>>
>> Note: I bench the get/set expression, not the creation of the 
>> volatile/atomic*/atom
>>
>> eg.
>> (let [v (volatile! 1)]
>>   (c/bench (vreset! v @v)))
>>
>> On Wednesday, March 11, 2015 at 12:30:06 PM UTC-4, tbc++ wrote:
>>>
>>> There's many other factors involved here though, GC, JIT warmup, etc. 
>>> That's kindof what criterium helps out with, removing all the variables and 
>>> running something until the JIT has warmed up enough (10 iterations 
>>> probably isn't enough). 
>>>
>>> Timothy
>>>
>>>
>>>   -- 
>> 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.
>>
>
>
>
> -- 
> “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 t

Re: Composing Stuart Sierra's components

[Colin Yates]

merge won't help as there will be name space clashes.

I wonder if a more elegant approach would be to construct the 'inner'
system and then assoc onto it the external dependencies it needs
before calling start.

On 11 March 2015 at 18:49,   wrote:
> I believe I misunderstood your question; I didn't realize it was system (as
> opposed to any general component) specific. I think systems can be merged
> together (via 'merge'). Would that help?
>
> On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:
>>
>> Hi Adrian - I don't follow how that helps integrate two different
>> systems - I wonder if my question was unclear or I am missing
>> something in your answer. Would you mind posting some pseudo code to
>> clarify please?
>>
>> On 11 March 2015 at 18:32,   wrote:
>> > You can specify component dependencies using the 'using' function as you
>> > know. As long as you know the key of the component in the system you can
>> > specify this dependency wherever you construct the component. If you
>> > want to
>> > parameterize dependencies, write a constructor function which takes the
>> > external dependency as a value.
>> >
>> > On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
>> >>
>> >> I have a non-trivial component which requires a bunch of internal and
>> >> external collaborators to work. This component is itself re-usable.
>> >>
>> >> What I really want to do is have ReusableComponent be a component in a
>> >> system so it can pull its external collaborators. However,
>> >> ReusableComponent
>> >> constructs its own services etc. so it really want to be (or at least
>> >> have
>> >> access to) a system.
>> >>
>> >> For example, let's say I have the following:
>> >>
>> >> (defrecord InternalToReusableComponent [bus]
>> >>   (component/Lifecycle
>> >> (start [this]...))
>> >>
>> >> (defrecord ReusableComponent [bus logger]
>> >>   (component/Lifecycle
>> >> (start [this]
>> >>
>> >>   this)
>> >> ))
>> >>
>> >> (defn reusable-component-system [external-collaborator]
>> >>   (component/system-map
>> >> :bus ()
>> >> :logger ()
>> >> :reusable-component (component/using (map->ReusableComponent {})
>> >> [:bus
>> >> :logger external-collaborator]))
>> >>
>> >> Fine - I now have a system from which I can pull the reusable
>> >> component.
>> >> However, where does 'external-collaborator' come from? Obviously there
>> >> is a
>> >> larger system which I want this component to be part of so I can do:
>> >>
>> >> (defn larger-system []
>> >>   (component/system-map
>> >>  :external-collaborator (...)
>> >>  :reusable-component (component/using (some-magic-glue)
>> >> [:external-collaborator])))
>> >>
>> >> I am struggling to see what (some-magic-glue) should be. I imagine it
>> >> needs to be something like:
>> >>
>> >> (defrecord SystemAdaptor [external-collaborator internal-system]
>> >>   component/Lifecycle
>> >>   (start [this]
>> >> (let [internal-system (or internal-system
>> >> (reusable-component-system
>> >> external-collaborator))
>> >>internal-system (component/start internal-system)]
>> >>  (assoc this :internal-system internal-system)))
>> >>   (stop [this]
>> >> (let [internal-system (:internal-system this)
>> >>internal-system (component/stop internal-system]
>> >>  (assoc this :internal-system internal-system)))
>> >>
>> >> but it all feels a bit yuck.
>> >>
>> >> I can't merge the two systems because the reusable component is chocka
>> >> full of very fine grained command handlers and both the internal and
>> >> external systems will have their own 'bus' for example. I could
>> >> namespace
>> >> the keys but that again feels painful...
>> >>
>> >> Hope that is clear - and I look forward to your thoughts :).
>> >
>> > --
>> > 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

Re: Adding directory to classpath in leiningen

[Hildeberto Mendonça]

$ cd ~/Clojure
$ lein repl

Your code in the repl will see the path ~/Clojure as working directory, so
any file there will be accessible to your code by simply using the name of
the file. If you have sub-directories then add the relative path:
"path/to/the/file/the-file.txt"

On Thu, Mar 12, 2015 at 9:10 AM, Cecil Westerhof 
wrote:

> I have some files in:
> ~/Clojure
> that I want to use in a project I start with:
> lein repl
>
> But I do not see how to do this. How can I acomplish this?
>
> --
> Cecil Westerhof
>
> --
> 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.
>



-- 
Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Community: http://www.cejug.net
Twitter: https://twitter.com/htmfilho

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

Better outputs produced by the REPL

[Hildeberto Mendonça]

Hello,

Running the following code in the repl:

(str "a line and then \n another line")

returns:

"a line and then \n another line"

Is there a way to ask the repl to interpret that \n char in the string? I
just want to produce a better output without using print/println.

Thanks in advance.

-- 
Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Community: http://www.cejug.net
Twitter: https://twitter.com/htmfilho

-- 
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] Dunaj project, an alternative core API for Clojure

[Jozef Wagner]

With today's experiment, we are going to be halfway through Dunaj. I hope 
you are finding these write-ups interesting and
that eventually, they will enable us to write even more powerful and 
performant Clojure programs. Thanks for all the response so far.

If you haven't read the previous write-ups yet, please do it now. The order 
was not chosen randomly and following experiment relies on the existence of 
previous ones.

Experiment #5: Reducers First

Reducers were introduced in Clojure 1.5 and in version 1.7, transducers 
will be added to the language. Reducers are however a completely optional 
feature and collection related functions still return (mostly lazy) seqs by 
default. Dunaj makes reducers a new default and deemphasizes the role of 
seqs by making them an optional feature for most of the core API.

Dunaj’s initial and the main vision is to create API that uses reducers by 
default and to provide additional reducible data sources and consumers of 
reducible collections. The overhaul of reducers and collection related API 
is Dunaj’s biggest experiment. Goals of this fifth described experiment are 
as follows:

- Transform collection related API into one that uses reducers by default
- Enhance reducers to support straightforward conversion to lazy sequences
- Provide full API support for transducers

You can read more about this experiment at http://www.dunaj.org 

Best,
Jozef


On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote:
>
> I'm happy to announce a project called Dunaj [1], which provides an 
> alternative core API for Clojure. Its main aim is to experimentally test 
> major additions to the language. 
>
> Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve 
> Clojure language and its core API. It deals with language features that 
> require changes across different parts of Clojure and which cannot be 
> evaluated in isolation. Dunaj aims to bring Clojure even more towards 
> simplicity, consistency and performance. 
> It is intended to be used by regular Clojure developers, either for 
> application or library development.
>
> Dunaj was created to test 10 experiments that bring significant changes to 
> the Clojure language. As there is a substantial number of additions and 
> changes, I want to try a bit unconventional approach here. Before I'll 
> release the actual library, I will introduce Dunaj's experiments in a 
> series of individual posts. Every part states the motivation behind the 
> experiment, introduces changes and additions to the language and 
> demonstrates its intended use. If you do not want to miss any of this, you 
> may want to register for a mailing list at [1] or follow @dunajproject at 
> Twitter.
>
> -- Jozef Wagner
>
> [1] http://www.dunaj.org/ 
>
>

-- 
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: Adding directory to classpath in leiningen

[Cecil Westerhof]

2015-03-12 12:00 GMT+01:00 Hildeberto Mendonça :

> $ cd ~/Clojure
> $ lein repl
>
> Your code in the repl will see the path ~/Clojure as working directory, so
> any file there will be accessible to your code by simply using the name of
> the file. If you have sub-directories then add the relative path:
> "path/to/the/file/the-file.txt"
>

​That is not going to work, because I want to use the files in the project
that resides in:
~/Clojure/quotes

I could move the files to there, but there is a big change that I want to
use them in other projects also.
I could use (soft) links, but I was just wondering if it would be possible
to extend the classpath.

By the way: I moved them to:
~/Clojure/repl
that is a better place I think.



> On Thu, Mar 12, 2015 at 9:10 AM, Cecil Westerhof 
> wrote:
>
>> I have some files in:
>> ~/Clojure
>> that I want to use in a project I start with:
>> lein repl
>>
>> But I do not see how to do this. How can I acomplish this?
>>
>
-- 
Cecil Westerhof

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

Better outputs produced by the REPL

[Alex Miller]

Try print-str and println-str.

Also see http://clojure.org/cheatsheet for a handy reference.

-- 
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: Better outputs produced by the REPL

[Cecil Westerhof]

2015-03-12 13:51 GMT+01:00 Alex Miller :

> Try print-str and println-str.
>

​I am not the OP, but I tried that and it does not work. At the moment the
only thing that I got working is:
(printf "a line and then \n another line")

But the OP does not want to use that. (Do not ask me why.)

-- 
Cecil Westerhof

-- 
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] munge-tout 0.1.2

[ronen]

How this compares to clojure.java.data?

Thanks

On Thursday, March 12, 2015 at 12:47:59 AM UTC+2, Edward Kimber wrote:
>
> Munge Tout is a Java-Clojure interop library that helps convert Java 
> Objects into Clojure data structures.  It supports conversion of Java 
> primitives, Lists, Sets, Maps and Enums and can be configured to perform 
> custom conversions on a per-property basis, or generally for a type by 
> extending the Mungeable protocol. 
>
> We use this to construct Java classes to feed into legacy Java libraries. 
>  Some of our classes have a complex structure with properties being lists 
> of other classes and so on and this tool makes interop with our legacy code 
> significantly simpler.  Hopefully it may also be of use to others. 
>  Feedback welcomed.
>
> https://github.com/flybe-dev/munge-tout
> https://clojars.org/munge-tout
>
> Edward
>

-- 
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: Adding directory to classpath in leiningen

[Jony Hudson]

Putting them in the working directory does not add them to the classpath. 
Leiningen used to have an 'escape hatch' to allow local libraries to be 
added to the classpath, but that was removed. The right way to do it now is 
to make the artefacts you want on the classpath available to Maven. The 
easiest way to do this is to install them into your local repo. I've found

https://github.com/kumarshantanu/lein-localrepo

is really very helpful for adding arbitrary jars to my local repo in the 
past.


Jony

On Thursday, 12 March 2015 08:10:27 UTC, Cecil Westerhof wrote:
>
> I have some files in:
> ~/Clojure
> that I want to use in a project I start with:
> lein repl
>
> But I do not see how to do this. How can I acomplish this?
>
> -- 
> Cecil Westerhof
>  

-- 
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: Composing Stuart Sierra's components

[Stuart Sierra]

On Wednesday, March 11, 2015, Colin Yates wrote:
> I can't merge the two systems because the reusable
> component is chocka full of very fine grained command
> handlers and both the internal and external systems will
> have their own 'bus' for example. I could namespace the
> keys but that again feels painful...

That's exactly how I would do it.

Nested systems don't really work.

But one system can contain implicit "groups" of components.

Create each group as a map, then `merge` them into the
system.

Use namespaced keys to prevent clashes.

The constructor functions for each component (or component
group) can take an argument which tells them the names of their
dependencies in the system.

Pseudo example:

(defn reusable-component [collaborator-key]
  (component/using (map->ReusableComponent {})
[:my/logger :my/bus collaborator-key]))

(defn reusable-group [collaborator-key]
  {:my/logger ...
   :my/bus ...
   :my/reusable-component
 (reusable-component collaborator-key)})

(defn new-system []
  (merge (system-map :main/logger ...
 :main/bus ...
 :main/collaborator ...)
 (reusable-group :main/collaborator)))


-S

-- 
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: Better outputs produced by the REPL

[Akiva Schoen]

(println) does the trick for me.
On Thu, Mar 12, 2015 at 8:30 AM Cecil Westerhof 
wrote:

> 2015-03-12 13:51 GMT+01:00 Alex Miller :
>
>> Try print-str and println-str.
>>
>
> ​I am not the OP, but I tried that and it does not work. At the moment the
> only thing that I got working is:
> (printf "a line and then \n another line")
>
> But the OP does not want to use that. (Do not ask me why.)
>
> --
> Cecil Westerhof
>
> --
> 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: Better outputs produced by the REPL

[Akiva Schoen]

Oops. Missed the bit about not using println. Ignore my last email.
On Thu, Mar 12, 2015 at 10:19 AM Akiva Schoen 
wrote:

> (println) does the trick for me.
> On Thu, Mar 12, 2015 at 8:30 AM Cecil Westerhof 
> wrote:
>
>> 2015-03-12 13:51 GMT+01:00 Alex Miller :
>>
>>> Try print-str and println-str.
>>>
>>
>> ​I am not the OP, but I tried that and it does not work. At the moment
>> the only thing that I got working is:
>> (printf "a line and then \n another line")
>>
>> But the OP does not want to use that. (Do not ask me why.)
>>
>> --
>> Cecil Westerhof
>>
>> --
>> 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: Adding directory to classpath in leiningen

[John Gabriele]

Hi Cecil,

I think what you want to do is create a library project to house your 
common code, install the library to your local repository, then use it from 
your project:

~~~
cd ~/dev
lein new my-stuff/my-lib
cd my-lib
# edit src/my_stuff/my_lib.clj , adding your common code here
lein install

# Ok, that library is now ready to use from your project.
cd ~/dev
lein new app my-proj
cd my-proj
# edit project.clj to have `[my-stuff/my-lib "0.1.0-SNAPSHOT"]` in 
:dependencies
# edit src/my_proj/core.clj to have `(:require [my-stuff.my-lib :as my)` in
#   the ns macro at the top
# do something like `(my/foo 3)` from inside `-main`.
lein run
~~~

-- John



On Thursday, March 12, 2015 at 4:10:27 AM UTC-4, Cecil Westerhof wrote:
>
> I have some files in:
> ~/Clojure
> that I want to use in a project I start with:
> lein repl
>
> But I do not see how to do this. How can I acomplish this?
>
> -- 
> Cecil Westerhof
>  

-- 
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: Composing Stuart Sierra's components

[Colin Yates]

I like the idea of passing in the *key* of the external collaborator -
that's nice. Thanks Stuart.

I am surprised there isn't more call for nested systems - maybe there
is and this solution is sufficient-enough...

Again - thanks Stuart!

On 12 March 2015 at 15:16, Stuart Sierra  wrote:
> On Wednesday, March 11, 2015, Colin Yates wrote:
>> I can't merge the two systems because the reusable
>> component is chocka full of very fine grained command
>> handlers and both the internal and external systems will
>> have their own 'bus' for example. I could namespace the
>> keys but that again feels painful...
>
> That's exactly how I would do it.
>
> Nested systems don't really work.
>
> But one system can contain implicit "groups" of components.
>
> Create each group as a map, then `merge` them into the
> system.
>
> Use namespaced keys to prevent clashes.
>
> The constructor functions for each component (or component
> group) can take an argument which tells them the names of their
> dependencies in the system.
>
> Pseudo example:
>
> (defn reusable-component [collaborator-key]
>   (component/using (map->ReusableComponent {})
> [:my/logger :my/bus collaborator-key]))
>
> (defn reusable-group [collaborator-key]
>   {:my/logger ...
>:my/bus ...
>:my/reusable-component
>  (reusable-component collaborator-key)})
>
> (defn new-system []
>   (merge (system-map :main/logger ...
>  :main/bus ...
>  :main/collaborator ...)
>  (reusable-group :main/collaborator)))
>
>
> -S
>
> --
> 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: Adding directory to classpath in leiningen

[John Gabriele]

Forgot to add, you can then run `lein repl` from my-proj as usual, and have 
easy access to your library code:

~~~
$ cd ~/dev/my-proj
$ lein repl
> my-proj.core=> (my/foo 4)
4 Hello, World!
nil
~~~


On Thursday, March 12, 2015 at 11:58:53 AM UTC-4, John Gabriele wrote:
>
> Hi Cecil,
>
> I think what you want to do is create a library project to house your 
> common code, install the library to your local repository, then use it from 
> your project:
>
> ~~~
> cd ~/dev
> lein new my-stuff/my-lib
> cd my-lib
> # edit src/my_stuff/my_lib.clj , adding your common code here
> lein install
>
> # Ok, that library is now ready to use from your project.
> cd ~/dev
> lein new app my-proj
> cd my-proj
> # edit project.clj to have `[my-stuff/my-lib "0.1.0-SNAPSHOT"]` in 
> :dependencies
> # edit src/my_proj/core.clj to have `(:require [my-stuff.my-lib :as my)` in
> #   the ns macro at the top
> # do something like `(my/foo 3)` from inside `-main`.
> lein run
> ~~~
>
> -- John
>
>
>
> On Thursday, March 12, 2015 at 4:10:27 AM UTC-4, Cecil Westerhof wrote:
>>
>> I have some files in:
>> ~/Clojure
>> that I want to use in a project I start with:
>> lein repl
>>
>> But I do not see how to do this. How can I acomplish this?
>>
>> -- 
>> Cecil Westerhof
>>  
>

-- 
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: Immutant survey

[Ravindra Jaju]

Very curious to know - how's the response been?

A happy user,
jaju

On Fri, Mar 6, 2015 at 8:01 PM, Jim Crossley  wrote:

> Hi friends,
>
> If you have any opinion about Immutant [1], would you please take a few
> moments to fill out this short survey?
>
>   http://goo.gl/forms/syYnYtpM4v
>
> We're trying to get a sense of how Immutant is being used.
>
> Thanks so much!
> Jim
>
> [1] http://immutant.org
>
>  --
> 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: Immutant survey

[Jim Crossley]

As of this moment, we've received 46 responses, mostly positive, some
with very thoughtful feedback, for which we're very grateful.

We plan to post the results on immutant.org in a couple weeks.

Thanks,
Jim

On Thu, Mar 12, 2015 at 12:10 PM, Ravindra Jaju  wrote:
> Very curious to know - how's the response been?
>
> A happy user,
> jaju
>
> On Fri, Mar 6, 2015 at 8:01 PM, Jim Crossley  wrote:
>>
>> Hi friends,
>>
>> If you have any opinion about Immutant [1], would you please take a few
>> moments to fill out this short survey?
>>
>>   http://goo.gl/forms/syYnYtpM4v
>>
>> We're trying to get a sense of how Immutant is being used.
>>
>> Thanks so much!
>> Jim
>>
>> [1] http://immutant.org
>>
>> --
>> 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] munge-tout 0.1.2

[Edward Kimber]

Hi Ronen,

It's essentially the same idea as clojure.java.data but it can do quite a 
bit more, including:
- generic parameters - so if you have List in your class that's no 
problem, nor is Map> etc.
- creation of n-dimensional ragged arrays of any type
- setting fields if property accessors are not present
- camel-case to dash-separated keyword conversion
- custom constructors by property name as well as type
- breaking encapsulation and setting private fields (well, sometimes you 
really do need to do it!)

Edward

On Thursday, 12 March 2015 13:59:10 UTC, ronen wrote:
>
> How this compares to clojure.java.data?
>
> Thanks
>
> On Thursday, March 12, 2015 at 12:47:59 AM UTC+2, Edward Kimber wrote:
>>
>> Munge Tout is a Java-Clojure interop library that helps convert Java 
>> Objects into Clojure data structures.  It supports conversion of Java 
>> primitives, Lists, Sets, Maps and Enums and can be configured to perform 
>> custom conversions on a per-property basis, or generally for a type by 
>> extending the Mungeable protocol. 
>>
>> We use this to construct Java classes to feed into legacy Java libraries. 
>>  Some of our classes have a complex structure with properties being lists 
>> of other classes and so on and this tool makes interop with our legacy code 
>> significantly simpler.  Hopefully it may also be of use to others. 
>>  Feedback welcomed.
>>
>> https://github.com/flybe-dev/munge-tout
>> https://clojars.org/munge-tout
>>
>> Edward
>>
>

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

[ANN] trapperkeeper-jetty9 v1.2.0

[Chris Price]

Hi!  Just wanted to let everyone know that we recently released a new
version of trapperkeeper-webserver-jetty9 to clojars.  The new version is
v1.2.0.

https://clojars.org/puppetlabs/trapperkeeper-webserver-jetty9

It's a feature release; there are a few new config options, but the most
significant change is that it bumps us up from a build of Jetty 9.1.x that
was about a year and a half old, to a much newer version (9.2.8).

The motivation for this was that we had a customer reporting a really
nasty, low-level Jetty race condition that could cause the server to end up
in a hung / deadlocked / unresponsive state after experiencing sustained
high load.  We were eventually able to reproduce the behavior in a test
environment and confirm that the newer version of Jetty fixes the issue.

We've also seen a marked improvement in startup time, which is a fairly big
deal for us since we spin up and shut down Jetty dozens and dozens of times
during the tests for our various trapperkeeper applications.  We have some
more targeted performance testing scheduled, but no results yet... but so
far, it seems quite a bit faster.

If you're interested in the gory details, see the CHANGELOG:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/blob/master/CHANGELOG.md#120

Thanks!
Chris

-- 
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: Better outputs produced by the REPL

[Edward Kimber]

You could use println instead of prn as the REPL printer.

(clojure.main/repl :print println)

This seems to break the REPL a bit though, so you may want to figure out 
how to put it in the startup,

On Thursday, 12 March 2015 11:08:28 UTC, Hildeberto Mendonça wrote:
>
> Hello,
>
> Running the following code in the repl:
>
> (str "a line and then \n another line")
>
> returns:
>
> "a line and then \n another line"
>
> Is there a way to ask the repl to interpret that \n char in the string? I 
> just want to produce a better output without using print/println.
>
> Thanks in advance.
>
> -- 
> Hildeberto Mendonça, Ph.D
> Blog: http://www.hildeberto.com
> Community: http://www.cejug.net
> Twitter: https://twitter.com/htmfilho
>  

-- 
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: Better outputs produced by the REPL

[Hildeberto Mendonça]

Yeah :-) I want to format a string returned by a function, instead of the
side effects produced by print/ln. I've checked the source code of the
function (pst) to see what it uses to print the stack trace and it's using
println. So, I guess this is the only option I have for the moment.

Now, I just have to hide that nil at the end.

On Thu, Mar 12, 2015 at 4:20 PM, Akiva Schoen 
wrote:

> Oops. Missed the bit about not using println. Ignore my last email.
>
> On Thu, Mar 12, 2015 at 10:19 AM Akiva Schoen 
> wrote:
>
>> (println) does the trick for me.
>> On Thu, Mar 12, 2015 at 8:30 AM Cecil Westerhof 
>> wrote:
>>
>>> 2015-03-12 13:51 GMT+01:00 Alex Miller :
>>>
 Try print-str and println-str.

>>>
>>> ​I am not the OP, but I tried that and it does not work. At the moment
>>> the only thing that I got working is:
>>> (printf "a line and then \n another line")
>>>
>>> But the OP does not want to use that. (Do not ask me why.)
>>>
>>> --
>>> Cecil Westerhof
>>>
>>> --
>>> 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.
>



-- 
Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Community: http://www.cejug.net
Twitter: https://twitter.com/htmfilho

-- 
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: Better outputs produced by the REPL

[Hildeberto Mendonça]

On Thu, Mar 12, 2015 at 8:29 PM, Edward Kimber 
wrote:

> You could use println instead of prn as the REPL printer.
>
> (clojure.main/repl :print println)
>

Interesting. It works, but the instance of the REPL it creates doesn't have
all features of lein repl :-( If there was a way to pass this behavior to
lein repl, it would be great.

Thanks anyway.

-- 
Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Community: http://www.cejug.net
Twitter: https://twitter.com/htmfilho

-- 
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: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[kovas boguta]

Hi Karsten,

Technical usage question.

I want to associate a color to each face of a cuboid, tesselate the cuboid,
and end up with an array of vertices and an array of matching colors.

My problem is associating the colors of the cuboid faces to their
tessellated versions. AFAICT tessellation simply produces new faces and
does not have facilities for propagating annotations from the old face to
the new faces. Furthermore, because the faces are stored in an unordered
set, it is not possible to somehow match the new faces to the old ones
based on ordering, at least in this simple case.

I tried to work around this by supplying the face set as an empty vector to
the mesh constructor. Unfortunately this doesn't work because the creation
of the new mesh simply calls the default constructor function, so the new
faces end up getting poured into a set anyway.

If instead, it called (empty) on the faces of the supplied mesh, this
workaround could work. However it is brittle, requiring to one know ahead
of time how many new faces will be generated for each input face.

Is there a better way to do this?

Thanks!


















On Wed, Feb 25, 2015 at 6:13 PM, Karsten Schmidt  wrote:

> That's a good point, Bruce! To be honest, I don't know anymore, but it
> makes complete sense to change it. Consider it done! :)
>
> As for your mapping question, yes, of course! I've done a few of them.
> E.g. the first pic on the website [1] was a project for The ODI in
> 2013 and is a map of different council/borough stats of London (here
> knife crime). The shape files were first retrieved & processed with
> the thi.ng/trio lib directly from the UK statistics office's SPARQL
> endpoint [2], then projected to Mercator, converted to 2d polygons,
> smoothed them and then extruded as 3D walled meshes and exported as
> STL files using geom. To create that rendered image, another function
> then combined all borough meshes into a complete render scene for
> Luxrender (using the luxor lib). Since this all was for a 60sec
> animation, I also wrote the tweeny lib for that project to allow me to
> define the timeline for the various camera, mesh, light & shader
> changes. The whole bundle was then sent to EC2 and rendered on 340+
> CPUs... basically, spawned a private render farm.
>
> Alternatively with < 30 lines of code you could query any UK
> constituency (or use similar endpoints for other countries), do those
> initial shape transformations and send the resulting STL mesh file
> straight to a 3D printer... For online use, of course the SVG or WebGL
> modules would be more interesting, but these really would just deal
> with that last transformation/visualization step, i.e. turning a
> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
> stuff it into WebGL buffer to display...
>
> For more flexible mapping, it'd be great to port some/all of the
> projections from [3] in its own clj lib for easier (and non-JS
> related) access...
>
> [1] http://thi.ng/img/04.jpg
> [2] http://statistics.data.gov.uk/doc/statistical-geography
> [3] https://github.com/d3/d3-geo-projection/
>
> Hth!
>
> On 25 February 2015 at 22:34, Bruce Durling  wrote:
> > Karsten,
> >
> > Is there a reason why you went with a README.md and then an index.org
> > rather than a plain README.org?
> >
> > (love all the rest of it and loved your use of it at The Barbican. I
> > need to get my head around it all. I'm wondering if I can use it for
> > some of the geographic and other charting things I do a lot of).
> >
> > cheers,
> > Bruce
> >
> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
> wrote:
> >> Hi guys,
> >>
> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
> >> Clojurescript libs for computational/generative design & data
> >> visualization tasks.
> >>
> >> I just wanted to give a little heads up that this project has recently
> >> seen a number of releases and, as a whole, by now is generally quite
> >> stable and usable (*is used*) for realworld projects (although most
> >> libs remain in constant parallel development to make them more feature
> >> complete). I've collated a number of images of projects and links to
> >> the most important libs here:
> >>
> >> http://thi.ng/
> >>
> >> Most notably of those:
> >>
> >> http://thi.ng/geom
> >> By far the largest sub-project and backbone for most others: A 2D/3D
> >> geometry package w/ comprehensive vector algebra, swizzling,
> >> intersections, matrix types & helpers, quaternions, pure shape
> >> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> >> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> >> engine (only particles, springs, behaviors)... Most of this lib is
> >> pure geometry w/ no rendering specifics, although there're separate
> >> modules for SVG rendering w/ shader support & decorators [1], WebGL
> >> wrapper and converters from shapes/meshes to VBOs and various shader
> >> presets/utils.
> >>
> >> http://thi.ng/shadergraph

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[kovas boguta]

On Thu, Mar 12, 2015 at 8:18 PM, kovas boguta 
wrote:

>
> I want to associate a color to each face of a cuboid, tesselate the
> cuboid, and end up with an array of vertices and an array of matching
> colors.
>

To clarify, I want to turn the cuboid into a mesh, and then do the
tessellation of the mesh. Tessellating the cuboid directly gives me the
faces in an obvious predictable order. However I want the mesh b/c theres
other computations I want to perform with it.

-- 
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] munge-tout 0.1.2

[ronen]

Nice work! ill check it out thanks

On Thursday, March 12, 2015 at 7:19:42 PM UTC+2, Edward Kimber wrote:
>
> Hi Ronen,
>
> It's essentially the same idea as clojure.java.data but it can do quite a 
> bit more, including:
> - generic parameters - so if you have List in your class that's no 
> problem, nor is Map> etc.
> - creation of n-dimensional ragged arrays of any type
> - setting fields if property accessors are not present
> - camel-case to dash-separated keyword conversion
> - custom constructors by property name as well as type
> - breaking encapsulation and setting private fields (well, sometimes you 
> really do need to do it!)
>
> Edward
>
> On Thursday, 12 March 2015 13:59:10 UTC, ronen wrote:
>>
>> How this compares to clojure.java.data?
>>
>> Thanks
>>
>> On Thursday, March 12, 2015 at 12:47:59 AM UTC+2, Edward Kimber wrote:
>>>
>>> Munge Tout is a Java-Clojure interop library that helps convert Java 
>>> Objects into Clojure data structures.  It supports conversion of Java 
>>> primitives, Lists, Sets, Maps and Enums and can be configured to perform 
>>> custom conversions on a per-property basis, or generally for a type by 
>>> extending the Mungeable protocol. 
>>>
>>> We use this to construct Java classes to feed into legacy Java 
>>> libraries.  Some of our classes have a complex structure with properties 
>>> being lists of other classes and so on and this tool makes interop with our 
>>> legacy code significantly simpler.  Hopefully it may also be of use to 
>>> others.  Feedback welcomed.
>>>
>>> https://github.com/flybe-dev/munge-tout
>>> https://clojars.org/munge-tout
>>>
>>> Edward
>>>
>>

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