Possible bug in LockingTransaction

[Brandon Ibach]

I have found what appears to be a bug in LockingTransaction, albeit one 
that probably wouldn't occur often.  But, I suppose that's a given for a 
previously undiscovered problem in oft-used code that hasn't changed for 
some while. :)

I'm using the Clojure 1.4 library strictly from Java code and I have a 
fairly simple transaction which dispatches an action to an agent (send, not 
send-off).  When called from a JUnit test, such that we jump right in to 
things, skipping some of the initialization we normally do in our app, I 
get a ConcurrentModificationException from inside Locktransaction.run() 
while it is iterating through the "actions" list, dispatching the actions 
after committing the transaction.

Based on some debugging, here's what seems to be happening:

1. My transaction is run, dispatching an action to an agent.
2. The transaction completes and is successfully committed.
3. LockingTransaction does post-commit cleanup, freeing locks and putting a 
stop() to the transaction, which nulls the transaction's Info object 
reference.
4. Notifications are sent and we start iterating the list of actions to be 
dispatched.
5. The run() method calls Agent.dispatchAction().  Because the thread's 
transaction is no longer "running" (due to the Info object being null) and 
no action is being processed on the thread (so its "nested" vector is 
null), the action is enqueue()d with the agent.
6. As part of the enqueue process, the action is consed onto the agent's 
ActionQueue.  Here's where the unique circumstances come into play.
   a. At this point, we haven't really interacted with the Clojure runtime, 
specifically the RT class, so its initiation machinery kicks in.
   b. Down in the depths, it executes a transaction to add a library to its 
list of loaded libraries.
   c. The still-existing-but-not-running thread-local transaction, with its 
existing action list intact, fires up, runs and commits.
   d. The post-commit stuff runs, including a nested attempt to dispatch 
that same action, again, which apparently succeeds.
   e. The action list is cleared before exiting the run() method.
7. Upon returning way back up the stack to our 
not-quite-finished-post-processing transaction, we continue iterating the 
now-cleared action list, which promptly throws the 
ConcurrentModificationException.

A quick perusal of the LockingTransaction code shows that the only 
interaction with the action list is adding an item to it in the enqueue() 
method, iterating it in the post-processing section of run() and clearing 
it in the "finally" clause of that section, so it's easy to see how a 
transaction started by any of the action-dispatching machinery would cause 
problems.  Any such activity in the actions themselves would not be an 
issue, since they'd occur on other threads, but the dispatch stuff all runs 
on the same thread.  The few moving parts that occur in this code seem 
fairly safe, as long as the runtime is already initialized, but if that 
occurs during this phase, I think all bets are off.

Does this analysis seem sound?  If so, is there a more formal process for 
filing this as a bug?  I can probably create a nice, compact example to 
reproduce it.

Thanks!

-Brandon :)

-- 
-- 
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: new ClojureDocs experiment

[Steven Degutis]

All very good points.

One of my assumptions was that people don't use wikis simply because
it's Yet Another Account to sign up for, so this being hosted on
github would be a much lower barrier-to-entry for contributing
examples. But I'm not sure that's a valid assumption for anyone
besides just me.

And I wasn't suggesting that the structure be edited. I was imagining
an unwritten rule where only examples would be edited/added, and the
rest of the structure of each page remain the same. That would make
parsing the wiki partially manageable. But I'm not sure how realistic
that is in practice.

Thanks for your feedback.

-Steven

On Wed, Sep 11, 2013 at 12:39 AM, John Gabriele  wrote:
> On Sunday, September 8, 2013 4:07:33 AM UTC-4, Steven Degutis wrote:
>>
>>
>> https://github.com/sdegutis/clojuredocs/wiki
>>
>> {snip}
>>
>> Thoughts?
>>
> Hi Steven,
>
> This is a nice piece of work. Thank you.
>
> Some thoughts:
>
>   * Wikis are difficult to keep nice. And, seemingly contradictory to that,
> it's difficult to find contributors.
>
>   * There is already a Clojure wiki,
> , but it does not see many
> updates.
>
>   * I really like clojuredocs.org's clean (and enforced) separation of
> examples, see-also, and comments.
>
>   * Although github's wiki feature is handy, for a pure wiki there are
> better solutions, IMO (for example, my favorite is
> [gitit](http://www.gitit.net/)).
>
>   * I think some of the work necessary to replace/rewrite clojuredocs.org
> has already been done by dakrone. Dunno the status of it though.
>
>   * I think it's worthwhile to pull docstrings directly from Clojure itself.
> Fixing docstring typos in a wiki is nice, but I'd rather see fixed the
> actual source docstrings themselves...
>
> -- John
>
> --
> --
> 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: new ClojureDocs experiment

[John Gabriele]

On Sunday, September 8, 2013 4:07:33 AM UTC-4, Steven Degutis wrote:

>
> https://github.com/sdegutis/clojuredocs/wiki 
>
> {snip}
>
> Thoughts? 
>
> Hi Steven,

This is a nice piece of work. Thank you.

Some thoughts:

  * Wikis are difficult to keep nice. And, seemingly contradictory to that, 
it's difficult to find contributors.

  * There is already a Clojure wiki, 
, but it does not see 
many updates.

  * I really like clojuredocs.org's clean (and enforced) separation of 
examples, see-also, and comments.

  * Although github's wiki feature is handy, for a pure wiki there are 
better solutions, IMO (for example, my favorite is 
[gitit](http://www.gitit.net/)).

  * I think some of the work necessary to replace/rewrite clojuredocs.org 
has already been done by dakrone. Dunno the status of it though.

  * I think it's worthwhile to pull docstrings directly from Clojure 
itself. Fixing docstring typos in a wiki is nice, but I'd rather see fixed 
the actual source docstrings themselves...

-- John

-- 
-- 
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: finding retained head

[Armando Blancas]

>
> I also suspected the closure over the matrix argument as being the 
> root cause but was puzzled when using doseq instead made the problem 
> go away... 
>
>
Right, it doesn't seem to be a hold in the closure, unless the compiler 
could tell when to release it, which is the case when the code is macro 
expanded (doseq) or placed inline, but not when you call a function like 
dorun. That's really kind of puzzling.

-- 
-- 
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: finding retained head

[Brian Craft]

(defmacro transaction
  [& body]
  `(transaction* (fn [] ~@body)))

I'm not sure how to avoid that. The anonymous function created here doesn't 
take parameters.

On Tuesday, September 10, 2013 8:55:42 PM UTC-7, Brian Craft wrote:
>
> Ah. So the root of my problem is that the jdbc/transaction macro creates a 
> closure in my function..
> (defmacro transaction
>
>
> On Tuesday, September 10, 2013 7:34:32 PM UTC-7, Armando Blancas wrote:
>>
>> Can anyone explain to me what's happening here? Something about creating 
>>> a anonymous function?
>>>
>>
>> The problem is not creating the anonymous function but that it closes 
>> over the matrix argument. The closure passed on to blah will keep a 
>> reference to matrix until blah returns. This won't happen if the anonymous 
>> function takes the matrix as a parameter:
>>
>> (defn blah [func v] (func v))
>> (defn load-exp [matrix]
>>   (blah
>> (fn [m] (dorun (map identity m))) matrix))
>>  
>>
>

-- 
-- 
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: finding retained head

[Brian Craft]

Ah. So the root of my problem is that the jdbc/transaction macro creates a 
closure in my function..
(defmacro transaction


On Tuesday, September 10, 2013 7:34:32 PM UTC-7, Armando Blancas wrote:
>
> Can anyone explain to me what's happening here? Something about creating a 
>> anonymous function?
>>
>
> The problem is not creating the anonymous function but that it closes over 
> the matrix argument. The closure passed on to blah will keep a reference to 
> matrix until blah returns. This won't happen if the anonymous function 
> takes the matrix as a parameter:
>
> (defn blah [func v] (func v))
> (defn load-exp [matrix]
>   (blah
> (fn [m] (dorun (map identity m))) matrix))
>  
>

-- 
-- 
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: finding retained head

[Sean Corfield]

FWIW, Brian and I were looking at this off-list and we changed (dorun
(map identity matrix)) to (doseq [x matrix] (identity x)) and that
seemed to work just fine - even in Brian's more complicated case.
Given that dorun specifically says it doesn't hold on to the head, I
would have expected the two to behave identically.

I also suspected the closure over the matrix argument as being the
root cause but was puzzled when using doseq instead made the problem
go away...

Sean

On Tue, Sep 10, 2013 at 7:34 PM, Armando Blancas  wrote:
>> Can anyone explain to me what's happening here? Something about creating a
>> anonymous function?
>
>
> The problem is not creating the anonymous function but that it closes over
> the matrix argument. The closure passed on to blah will keep a reference to
> matrix until blah returns. This won't happen if the anonymous function takes
> the matrix as a parameter:
>
> (defn blah [func v] (func v))
> (defn load-exp [matrix]
>   (blah
> (fn [m] (dorun (map identity m))) matrix))
>
>
> --
> --
> 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.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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: Clojure & Jruby (Ruby on Rails) Interop

[Ron Toland]

Rodrigo,

We went with RabbitMQ over ZeroMQ mostly because we were more familiar with 
it. As I understand it, ZeroMQ is less of a message-queueing system and 
more "sockets on steroids." Which one is best will depend pretty strongly 
on your particular usecase.

In our case, our messages are pretty simple: they're just mongodb docIds 
plus some extra data. We use the queue the message goes into as the 
"meta-data" for the message. If a docId appears in the "word-count" queue, 
for example, the Clojure workers know to calculate the avg word count stats 
for the given document.

For us, security comes in the form of username/password authentication for 
RabbitMQ, plus blocking the ports to everyone save the Ruby and Clojure 
servers that need to communicate with it. If we were firing off messages 
with more sensitive data (e.g., passwords), we'd look at encryption then.

The performance of the pipeline so far has been great. Ruby can offload the 
heavy processing to Clojure, so the user can continue working on the site 
without interruption. Clojure gets to focus on just the processing side, so 
we can optimize and scale it separately.

As for portability, we started with everything on Heroku, but we've been 
slowly migrating to aws as our needs scale up. Our configuration makes this 
really easy: we can move the rabbitmq piece over one week, then the clojure 
the next, without changing anything but a few lines in a config file.

Ron

On Monday, September 9, 2013 7:47:54 AM UTC-7, rdelcueto wrote:
>
> Hey Ron,
> Thanks for your response. Digging deeper into my question...
>
> When I read about the Torquebox Immutant duet, I thought it was 
> particularly interesting solution, because it was fairly easy to deploy and 
> both processes would live inside a JVM environment. I was impressed by how 
> Clojure data structures mapped to Ruby structures and vice-versa, it seemed 
> to provide a very clean and idiomatic messaging platform. Plus it would 
> provide tools for caching, clustering, and what not. Still I wasn't very 
> keen on the JRuby subject, since It's known to have compatibility issues 
> with certain gems.
>
> Yesterday while researching on the subject I found about ZeroMQ. Do you 
> have any particular reason to use RabbitMQ over other messaging libraries? 
> Are there any caveats to your interop model?
> How portable is deploying a site using a messaging solution such as 
> RabbitMQ?
>
> I also found out about Google's Protocol Buffers, they seemed like a 
> lightweight solution to pass language agnostic data structures through the 
> messaging infrastructure.
> Do messages need to be encapsulated somehow, or is this actually 
> unnecessary? How it's done in your case?
>
> Regarding security and sensible information interop; Should messages be 
> encrypted? Should they be encrypted as a whole message or partially (only 
> sensible data)?
> What are the performance implications of this pipeline? Is the overhead 
> and footprint of such setup (Ruby + Messaging Broker + ClojureJVM) big 
> enough, for it to be worth thinking on writing everything in Clojure (using 
> the Luminus framework)?
>
> On Monday, September 9, 2013 8:10:41 AM UTC-5, Ron Toland wrote:
>>
>> At Rewryte, we use Rails for the web frontend and Clojure for the data 
>> processing backend for exactly the reasons you described.
>>
>> We use RabbitMQ to communicate between the two. This maintains separation 
>> between the two apps (no JRuby required), and lets us scale them both 
>> independently, while taking advantage of each language/framework's 
>> strengths.
>>
>

-- 
-- 
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: finding retained head

[Armando Blancas]

>
> Can anyone explain to me what's happening here? Something about creating a 
> anonymous function?
>

The problem is not creating the anonymous function but that it closes over 
the matrix argument. The closure passed on to blah will keep a reference to 
matrix until blah returns. This won't happen if the anonymous function 
takes the matrix as a parameter:

(defn blah [func v] (func v))
(defn load-exp [matrix]
  (blah
(fn [m] (dorun (map identity m))) matrix))
 

-- 
-- 
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] Introducing VDD Core - Visualization Driven Development in Clojure

[Mark Mandel]

Thanks for posting this - at first glance it looks very cool :)

See you at Strangeloop - I've been looking forward to this talk :)

Mark


On Wed, Sep 11, 2013 at 10:13 AM, Jason Gilman wrote:

> I've just released a new open source tool, VDD Core, to help enable
> Visualization Driven Development in Clojure. Visualization Driven
> Development and VDD Core are the subject of my Strange Loop talk (
> https://thestrangeloop.com/sessions/visualization-driven-development)
> next week. VDD Core's goal is to make it easy to capture and send data to
> be visualized in a web browser. This is an early alpha release. I hoping to
> get others interested and testing it out.
>
> You can read more about VDD Core and Visualization Driven Development at
> the following places:
>
>   * Blog Announcement: http://www.element84.com/announcing-vdd-core.html
>   * Github Page: https://github.com/Element84/vdd-core
>   * Wiki: https://github.com/Element84/vdd-core/wiki
>   * Example Project: https://github.com/Element84/vdd-core-examples
>
>
> Thanks,
> Jason Gilman
>
> --
> --
> 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.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

-- 
-- 
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: finding retained head

[Brian Craft]

Copying the pattern of jdbc/transaction*, I tried this:

(defn blah [func] (func))
(defn load-exp [file timestamp filehash matrix]
  (blah
(fn [] (dorun (map identity matrix)


which also consumes the heap.

Can anyone explain to me what's happening here? Something about creating a 
anonymous function?

On Tuesday, September 10, 2013 5:24:44 PM UTC-7, Brian Craft wrote:
>
> It seems to be something about the jdbc/transaction macro. If I rewrite 
> load_exp so it does nothing but walk the seq, it still consumes the heap:
>
> (defn load-exp [file timestamp filehash matrix]
>   (jdbc/transaction
> (dorun (map identity matrix
>
>
> If I remove the jdbc/transaction call, it's fine.
>
> (defn load-exp [file timestamp filehash matrix]
>   (dorun (map identity matrix)))
>
>
>
> On Tuesday, September 10, 2013 3:24:29 PM UTC-7, Brian Craft wrote:
>>
>> Trying jhat now, reference chain here:
>>
>> --> cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:)
>> --> clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:)
>> --> clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:)
>> --> clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:)
>> --> clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:)
>>
>> This looks to me like the head is being retained as a parameter to a 
>> function. load_exp signature is like so:
>>
>> defn load-exp [file timestamp filehash matrix]
>>
>> But surely passing a seq to a function doesn't retain the head?
>>
>> Here's the body of the function:
>>
>> (defn load-exp [file timestamp filehash matrix]
>>   (kdb/transaction
>> (let [cid (merge-cohort file)
>>   exp (merge-exp file (format-timestamp timestamp) filehash cid)
>>   sids (load-samples cid (:samples (meta matrix)))]
>>   (load-exp-samples exp sids)
>>   (load-exp-matrix exp matrix
>>
>>
>> load-exp-matrix calls (dorun (map)) on matrix. There's one other 
>> reference here, where we pull the metadata. Does any of this retain the 
>> head?
>>
>> On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote:
>>>
>>> From jmap output it's pretty clear I'm retaining the head of a seq 
>>> somehow, but I have no idea how, or where. Is there any way to find the 
>>> reference, besides staring at code waiting for enlightenment?
>>>
>>

-- 
-- 
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: finding retained head

[Brian Craft]

It seems to be something about the jdbc/transaction macro. If I rewrite 
load_exp so it does nothing but walk the seq, it still consumes the heap:

(defn load-exp [file timestamp filehash matrix]
  (jdbc/transaction
(dorun (map identity matrix


If I remove the jdbc/transaction call, it's fine.

(defn load-exp [file timestamp filehash matrix]
  (dorun (map identity matrix)))



On Tuesday, September 10, 2013 3:24:29 PM UTC-7, Brian Craft wrote:
>
> Trying jhat now, reference chain here:
>
> --> cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:)
> --> clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:)
> --> clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:)
> --> clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:)
> --> clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:)
>
> This looks to me like the head is being retained as a parameter to a 
> function. load_exp signature is like so:
>
> defn load-exp [file timestamp filehash matrix]
>
> But surely passing a seq to a function doesn't retain the head?
>
> Here's the body of the function:
>
> (defn load-exp [file timestamp filehash matrix]
>   (kdb/transaction
> (let [cid (merge-cohort file)
>   exp (merge-exp file (format-timestamp timestamp) filehash cid)
>   sids (load-samples cid (:samples (meta matrix)))]
>   (load-exp-samples exp sids)
>   (load-exp-matrix exp matrix
>
>
> load-exp-matrix calls (dorun (map)) on matrix. There's one other reference 
> here, where we pull the metadata. Does any of this retain the head?
>
> On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote:
>>
>> From jmap output it's pretty clear I'm retaining the head of a seq 
>> somehow, but I have no idea how, or where. Is there any way to find the 
>> reference, besides staring at code waiting for enlightenment?
>>
>

-- 
-- 
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: Clojure newbie code review

[Igor Demura]

Thank you Philipp, this is really helpful!

Marshall's guess where *read-eval* from is right. I didn't googled what 
does it mean, just left as-is from the Leiningen template.

Talking on replacement to join. For this function I'll link additional 
library. My question how this works: in C++ world, linker will eliminate 
all unused symbols (classes in this case?) from output binary. Is the same 
true for JVM/Clojure world? Will it bloat binary?
Why do you recommend update-in instead of assoc? First time I did this, 
than I saw using assoc in similar situation on ClojureDocs and  changed my 
mind.

I see your point about architecture. You suggest to make it more sequential 
(composition like: (f (g x))), instead of injecting actions like this:
(defn action [subaction]  ;; subaction is a function to pass control to
  (do ... (subaction ...)))

Thank you again.

On Monday, September 9, 2013 4:24:10 PM UTC-7, Igor Demura wrote:
>
> Hi Clojure community,
>
> (I tried codereview.stackaxchange.com before, but no responses where) I'm 
> Clojure newbie, and feel very excited about it and functional programming 
> in general. I wrote tiny app (59 lines of code) which renders a directory 
> tree to the terminal, filtering with a regex. I'm sure that my code is not 
> perfect and something could be done much better. I'll appreciate if you 
> could spent sometime to review it: 
> https://github.com/idemura/incub/tree/master/tree. Don't know where to 
> get help with this.
>
> Igor.
>
>

-- 
-- 
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: Clojure newbie code review

[Andy Fingerhut]

Regarding your question about join: The clojure.string namespace contains
the join function recommended to you.  All functions in the clojure.string
namespace, and several other namespaces (see below for a complete list) are
part of the Clojure JAR file, and in that sense come at "no additional
charge" over and above that Clojure JAR file size.  Whether you regard that
Clojure JAR file bloated or not is your judgement call (Clojure 1.5.1 is
~3.5 Mbytes).

$ java -cp $HOME/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
clojure.main
user=> (use 'clojure.pprint)
nil
user=> (clojure.pprint/pprint (sort (map str (all-ns
("clojure.core"
 "clojure.core.protocols"
 "clojure.instant"
 "clojure.java.browse"
 "clojure.java.io"
 "clojure.java.javadoc"
 "clojure.java.shell"
 "clojure.main"
 "clojure.pprint"
 "clojure.repl"
 "clojure.string"
 "clojure.uuid"
 "clojure.walk"
 "user")
nil

If you add other libraries with their own separate JAR files, you can look
at each one to decide whether you think its size is worth it.  Many that
are written purely in Clojure tend to be source-code only, and thus quite
small.  For example, Ring + Compojure + Hiccup JAR files total about 40
Kbytes.

Andy



On Tue, Sep 10, 2013 at 10:46 AM, Igor Demura  wrote:

> Thank you Philipp, this is really helpful!
>
> Marshall's guess where *read-eval* from is right. I didn't googled what
> does it mean, just left as-is from the Leiningen template.
>
> Talking on replacement to join. For this function I'll link additional
> library. My question how this works: in C++ world, linker will eliminate
> all unused symbols (classes in this case?) from output binary. Is the same
> true for JVM/Clojure world? Will it bloat binary?
> Why do you recommend update-in instead of assoc? First time I did this,
> than I saw using assoc in similar situation on ClojureDocs and  changed
> my mind.
>
> I see your point about architecture. You suggest to make it more
> sequential (composition like: (f (g x))), instead of injecting actions
> like this:
> (defn action [subaction]  ;; subaction is a function to pass control to
>   (do ... (subaction ...)))
>
> Thank you again.
>
> On Monday, September 9, 2013 4:24:10 PM UTC-7, Igor Demura wrote:
>>
>> Hi Clojure community,
>>
>> (I tried codereview.stackaxchange.com before, but no responses where)
>> I'm Clojure newbie, and feel very excited about it and functional
>> programming in general. I wrote tiny app (59 lines of code) which renders a
>> directory tree to the terminal, filtering with a regex. I'm sure that my
>> code is not perfect and something could be done much better. I'll
>> appreciate if you could spent sometime to review it: https://github.com/*
>> *idemura/incub/tree/master/tree
>> **. Don't know where to get help with this.
>>
>> Igor.
>>
>>  --
> --
> 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.

[ANN] Introducing VDD Core - Visualization Driven Development in Clojure

[Jason Gilman]

I've just released a new open source tool, VDD Core, to help enable 
Visualization Driven Development in Clojure. Visualization Driven 
Development and VDD Core are the subject of my Strange Loop talk (
https://thestrangeloop.com/sessions/visualization-driven-development) next 
week. VDD Core's goal is to make it easy to capture and send data to be 
visualized in a web browser. This is an early alpha release. I hoping to 
get others interested and testing it out. 

You can read more about VDD Core and Visualization Driven Development at 
the following places:

  * Blog Announcement: http://www.element84.com/announcing-vdd-core.html
  * Github Page: https://github.com/Element84/vdd-core
  * Wiki: https://github.com/Element84/vdd-core/wiki
  * Example Project: https://github.com/Element84/vdd-core-examples


Thanks,
Jason Gilman

-- 
-- 
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] Blackwater 0.0.8

[Christopher Allen]

https://github.com/bitemyapp/blackwater

Single-line SQL query formatting, separate Korma and c.j.j namespaces, 
ability to use a custom fn with set-logger! now as well.

Any additional feature requests/changes should continue to hit the Github 
issues.

Cheers all.

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

Re: finding retained head

[Brian Craft]

Trying jhat now, reference chain here:

--> cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:)
--> clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:)
--> clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:)
--> clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:)
--> clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:)

This looks to me like the head is being retained as a parameter to a 
function. load_exp signature is like so:

defn load-exp [file timestamp filehash matrix]

But surely passing a seq to a function doesn't retain the head?

Here's the body of the function:

(defn load-exp [file timestamp filehash matrix]
  (kdb/transaction
(let [cid (merge-cohort file)
  exp (merge-exp file (format-timestamp timestamp) filehash cid)
  sids (load-samples cid (:samples (meta matrix)))]
  (load-exp-samples exp sids)
  (load-exp-matrix exp matrix


load-exp-matrix calls (dorun (map)) on matrix. There's one other reference 
here, where we pull the metadata. Does any of this retain the head?

On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote:
>
> From jmap output it's pretty clear I'm retaining the head of a seq 
> somehow, but I have no idea how, or where. Is there any way to find the 
> reference, besides staring at code waiting for enlightenment?
>

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

finding retained head

[Brian Craft]

>From jmap output it's pretty clear I'm retaining the head of a seq somehow, 
but I have no idea how, or where. Is there any way to find the reference, 
besides staring at code waiting for enlightenment?

-- 
-- 
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: new ClojureDocs experiment

[Steven Degutis]

Thanks :)

By the way, it's probably *not* a good idea to use this github-wiki
version of clojuredocs. Everyone's still using clojuredocs.org, and we
don't want to scatter data (examples, etc) between two websites.

My reason for posting this was to hear the community's thoughts on
this alternate implementation and its viability.

-Steven

On Mon, Sep 9, 2013 at 5:39 AM, Alex Fowler  wrote:
> That's really cool! Was always wondering if there's gone be something like
> that ever.. Gonna be visiting often! Wish also that it'd be near clojuredocs
> in search results if you google like "clojure parse", but that'a a different
> effort, I suppose.. keep up!
>
> воскресенье, 8 сентября 2013 г., 12:07:33 UTC+4 пользователь Steven Degutis
> написал:
>>
>> ClojureDocs.org is pretty awesome, I think I use it nearly every day,
>> especially for the Examples and See Also sections. But sometimes I've
>> been wishing it had Clojure 1.5.1 support. For example, I think as->
>> and cond-> would have been easier for me to pick up had there been
>> entries for these with community-driven Examples.
>>
>> A while back, someone told me "complaining is laziness". So I worked
>> on an experiment that I'd like to propose to you all. It's a github
>> wiki that's been seeded with data scraped from in-process docs and
>> clojuredocs.org's API. Here it is:
>>
>> https://github.com/sdegutis/clojuredocs/wiki
>>
>> Pros:
>> - Docs are for Clojure 1.5.1
>> - Anyone logged into github can edit it
>> - Any part of it can be edited (to fix typos in docstring, etc)
>> - All namespaces are shown on the Home page for easy searching
>> - Free hosting, free database storage :)
>>
>> Cons:
>> - Doesn't have dynamic relevance-based search field
>> - Doesn't have an API (but an external one could be built)
>> - Doesn't have Quick Ref tables (yet)
>> - A few URLs are kind of ugly
>> - The namespace-navigation bar is gone, you'd have to click Home
>> - Doesn't store nearly as much data as clojuredocs.org does
>>
>> (But as usual, pros/cons are totally subjective to individual needs.
>> This is just how I saw it. These tables may be reversed for you, who
>> knows.)
>>
>> Right now, it only has core namespaces. But I've made it easy to add
>> data from new namespaces, so long as the right dependencies are added
>> to project.clj.
>>
>> Thoughts?
>>
>> -Steven
>
> --
> --
> 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: Functional purity and "globals" in Clojure

[Christopher Allen]

I do a hybrid in Bulwark.

github.com/bitemyapp/bulwark/

Defaults to accepting a closure of a config map for nice testing and 
hygiene, with a fallback to a global atom map for configuration for muggles.

Works well for me.

On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote:
>
> I'm trying to determine how to best deal with the concept of globals in 
> Clojure. Say I have a map of configuration values for my Ring app, populate 
> at app startup from disk or env, and I need to reference the contents of 
> this map from all over the project. Assuming MVC, models and controllers 
> all would be interested in its contents. I just want to clarify that the 
> question is not so much about "configuration" as it is about dealing with 
> state that many different components in an application might be all 
> interested in. This is an issue that seems to arise very often.
>
> I'm seeing a couple of options here:
>
>- Pass the configs map along with each Ring request with some 
>middleware, and then down every subsequent function call that might 
>eventually need it. It's a bit of a hassle since now you're passing more 
>data, potentially increasing the # of parameters, or forcing you to use a 
>parameter map everywhere where you might have passed along just 1 
>primitive. Nonetheless, this is as pure as it gets.
>- Def the configs map in a namespace somewhere and refer to it from 
>wherever, just like global state. The trick is now that now you're no 
>longer certain what e.g. your model functions are expecting there to be in 
>the system and testing becomes trickier. Now you have to either lein test 
>with a separate set of configurations (which doesn't actually give you 
> much 
>per-test granularity) or use with-redefs everywhere to make sure the right 
>test config state is being used.
>- Something in the middle where perhaps you agree to never directly 
>reference the configs map from your models (again, thinking MVC here) and 
>instead only ever access it from controllers, and pass the necessary 
>options along down to the model functions. This way you can test both 
>controllers and models in isolation in purity.
>
> Ultimately I want to contain the chaos of having to know internal 
> implementation details of my functions at different layers and want them to 
> be easily testable in isolation. It does seem like the first option is the 
> most straightforward, but I'd be curious to find out what those of you who 
> have deal with the problem for a while would recommend. Purity all the way, 
> or are there patterns that can give you the best of both worlds? Or what 
> else?
>
>
>

-- 
-- 
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: Clojure newbie code review

[Marshall Bockrath-Vandegrift]

Philipp Meier  writes:

> (alter-var-root #'*read-eval* (constantly false))
> => why do you think this is necessary?

Some versions of the Leiningen `app` template put this in the skeleton
initial source file.  I assume that’s where this came from.

-Marshall

-- 
-- 
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: Functional purity and "globals" in Clojure

[Softaddicts]

This presentation is funny from Stuart is interesting and funny to watch as 
usual :)

The "mud ball" issue is not new and you can face it in other languages than Lisp
that lack a single straight jacket with which anything needs to be defined
(like classes).

Freedom comes with a price, you cannot always rely on some fixed rail guards to 
tell
you how to do things.

I guess that a decade of OOP frenzy took its toll and now some folks suffer
from vertigo when they switch to a "muddy" language :)

Luc P

> This Clojure/West talk deals with many of these concepts.
> > http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques
> > Timothy
> > > On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier  wrote:
> > >
> >
> > Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
> >
> >> I agree more or less, I hate having my configuration data spread
> >> everywhere.
> >> I prefer to dedicate a name space to maintain/access configuration data.
> >> I usually split access to resources using bundles.
> >> A bundle can reflect anything you want in your design, including a
> >> controller...
> >>
> >
> > You can always use a global config system and pass through the
> > configuration information into the sub systems.
> >
> > --
> > --
> > 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.
> >
> > > > -- > “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/groups/opt_out.
> --
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Functional purity and "globals" in Clojure

[Timothy Baldridge]

This Clojure/West talk deals with many of these concepts.

http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques

Timothy


On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier  wrote:

>
>
> Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
>
>> I agree more or less, I hate having my configuration data spread
>> everywhere.
>> I prefer to dedicate a name space to maintain/access configuration data.
>> I usually split access to resources using bundles.
>> A bundle can reflect anything you want in your design, including a
>> controller...
>>
>
> You can always use a global config system and pass through the
> configuration information into the sub systems.
>
> --
> --
> 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.
>



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

Re: Functional purity and "globals" in Clojure

[Philipp Meier]

Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
>
> I agree more or less, I hate having my configuration data spread 
> everywhere. 
> I prefer to dedicate a name space to maintain/access configuration data. 
> I usually split access to resources using bundles. 
> A bundle can reflect anything you want in your design, including a 
> controller... 
>
 
You can always use a global config system and pass through the 
configuration information into the sub systems.

-- 
-- 
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] core.typed 0.2.5, News

[Leonardo Borges]

Thanks for all your work ambrose! Core.typed is quite a feat.

And I can confirm ambrose is amazingly responsive on freenode. Every time I
bug him, it works :)
On 10/09/2013 9:57 PM, "Ambrose Bonnaire-Sergeant" <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> Pushing another release of core.typed,
> mostly bug/documentation fixes.
>
> We now push a "slim" jar which does not include AOT file. See the README
> for dependency information.
>
> See the CHANGELOG for specific changes.
>
> I'm also starting to provide functions that will help integrate core.typed
> with IDE's. eg. 
> check-form-info
>  returns
> a map of data summarising the results of type checking, including type
> errors. This is towards Counterclockwise 
> support
> .
>
> I'm planning to fix a bunch of things that have proven problematic with
> the type syntax. I'll be adding to this design 
> wikiif you 
> want to follow along, or contribute. These may end up being breaking
> changes.
>
> Also, recursive deftype and protocols have proven to be tricky. 
> Hereare my 
> thoughts.
>
> Finally, I wrote a blog 
> postexplaining
>  how core.typed understands assertions.
>
> Enjoy!
> Ambrose
>
> PS. If you have questions, try #typed-clojure on Freenode!
>

-- 
-- 
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] core.typed 0.2.5, News

[Ambrose Bonnaire-Sergeant]

Hi,

Pushing another release of core.typed,
mostly bug/documentation fixes.

We now push a "slim" jar which does not include AOT file. See the README
for dependency information.

See the CHANGELOG for specific changes.

I'm also starting to provide functions that will help integrate core.typed
with IDE's. eg.
check-form-info
returns
a map of data summarising the results of type checking, including type
errors. This is towards Counterclockwise
support
.

I'm planning to fix a bunch of things that have proven problematic with the
type syntax. I'll be adding to this design
wikiif
you want to follow along, or contribute. These may end up being
breaking
changes.

Also, recursive deftype and protocols have proven to be tricky.
Hereare
my thoughts.

Finally, I wrote a blog
postexplaining
how core.typed understands assertions.

Enjoy!
Ambrose

PS. If you have questions, try #typed-clojure on Freenode!

-- 
-- 
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: Functional purity and "globals" in Clojure

[Softaddicts]

I agree more or less, I hate having my configuration data spread everywhere.
I prefer to dedicate a name space to maintain/access configuration data.
I usually split access to resources using bundles.
A bundle can reflect anything you want in your design, including a controller...

This allows you to later change where you store and how you manage 
your configuration underneath, calls to the configuration are traceable in your 
code
(conf/...) and you can easily stub it for testing purposes.

Yes you need some discipline to avoid accessing it from everywhere (it could be 
tempting) but in general I refer to it at the top level and pass bits of the
configuration data downward.

Downward in your code you refer to semantics that have little to do with what 
the 
configuration data may represent as a whole. E.g. when trying to create a 
socket,
you do not matter where the host/port came from in your configuration,
you just need the values as args.

It helps keeping your functions as pure a possible or at least with a clearly 
delimited 
side effect scope and still allows tests to be written.

Attaining 100% purity is in my view a nice but rarely reachable objective.

I would say that 80 to 90% is more realistic :)

Luc P.

> Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin:
> 
> >
> >- Something in the middle where perhaps you agree to never directly 
> >reference the configs map from your models (again, thinking MVC here) 
> > and 
> >instead only ever access it from controllers, and pass the necessary 
> >options along down to the model functions. This way you can test both 
> >controllers and models in isolation in purity.
> >
> >
> I'd do the following: for every layout of your application (persistence, 
> datamodel, web) define one or more vars that hold the configuration 
> specific for that layer. Testing a layer is easy and documentation of the 
> layer gives you the necessary information about the configuration vars. 
> 
> -billy.
> 
> -- 
> -- 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Clojure newbie code review

[Philipp Meier]

Am Dienstag, 10. September 2013 01:24:10 UTC+2 schrieb Igor Demura:
>
> Hi Clojure community,
>
> (I tried codereview.stackaxchange.com before, but no responses where) I'm 
> Clojure newbie, and feel very excited about it and functional programming 
> in general. I wrote tiny app (59 lines of code) which renders a directory 
> tree to the terminal, filtering with a regex. I'm sure that my code is not 
> perfect and something could be done much better. I'll appreciate if you 
> could spent sometime to review it: 
> https://github.com/idemura/incub/tree/master/tree. Don't know where to 
> get help with this.
>
> (str (reduce #(str %1 " " %2) coll)

can be replaced with clojure.string/join 

(iterate inc 1) 
=> (rest (range)) may be more clear

(alter-var-root #'*read-eval* (constantly false))
=> why do you think this is necessary?

You can convert the regex string into a pattern once in line 51:
(when regex (re-pattern regex))

(assoc m p (conj (m p []) f))
=> (update-in m [p] (fnil conj []) f)) 

In general I would separate the different task:

* directory tree walking -> tree representation
* render tree into line definitions
* render tree lines into string
* print string

-billy



 

-- 
-- 
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: Functional purity and "globals" in Clojure

[Philipp Meier]

Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin:

>
>- Something in the middle where perhaps you agree to never directly 
>reference the configs map from your models (again, thinking MVC here) and 
>instead only ever access it from controllers, and pass the necessary 
>options along down to the model functions. This way you can test both 
>controllers and models in isolation in purity.
>
>
I'd do the following: for every layout of your application (persistence, 
datamodel, web) define one or more vars that hold the configuration 
specific for that layer. Testing a layer is easy and documentation of the 
layer gives you the necessary information about the configuration vars. 

-billy.

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

Functional purity and "globals" in Clojure

[Alexandr Kurilin]

I'm trying to determine how to best deal with the concept of globals in 
Clojure. Say I have a map of configuration values for my Ring app, populate 
at app startup from disk or env, and I need to reference the contents of 
this map from all over the project. Assuming MVC, models and controllers 
all would be interested in its contents. I just want to clarify that the 
question is not so much about "configuration" as it is about dealing with 
state that many different components in an application might be all 
interested in. This is an issue that seems to arise very often.

I'm seeing a couple of options here:

   - Pass the configs map along with each Ring request with some 
   middleware, and then down every subsequent function call that might 
   eventually need it. It's a bit of a hassle since now you're passing more 
   data, potentially increasing the # of parameters, or forcing you to use a 
   parameter map everywhere where you might have passed along just 1 
   primitive. Nonetheless, this is as pure as it gets.
   - Def the configs map in a namespace somewhere and refer to it from 
   wherever, just like global state. The trick is now that now you're no 
   longer certain what e.g. your model functions are expecting there to be in 
   the system and testing becomes trickier. Now you have to either lein test 
   with a separate set of configurations (which doesn't actually give you much 
   per-test granularity) or use with-redefs everywhere to make sure the right 
   test config state is being used.
   - Something in the middle where perhaps you agree to never directly 
   reference the configs map from your models (again, thinking MVC here) and 
   instead only ever access it from controllers, and pass the necessary 
   options along down to the model functions. This way you can test both 
   controllers and models in isolation in purity.

Ultimately I want to contain the chaos of having to know internal 
implementation details of my functions at different layers and want them to 
be easily testable in isolation. It does seem like the first option is the 
most straightforward, but I'd be curious to find out what those of you who 
have deal with the problem for a while would recommend. Purity all the way, 
or are there patterns that can give you the best of both worlds? Or what 
else?


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