Re: [ANN] clj-memory meter – measure the memory used by arbitrary objects

[Juraj Martinka]

Works great for me. Thank you very much for publishing this!
Previously, I tried to use jol-cli  
but it was much more 
cumbersome.

On Monday, 5 March 2018 11:56:20 UTC+1, Alexander Yakushev wrote:
>
> I'm happy to release the first version of clj-memory-meter 
> . It's a thin 
> wrapper around jamm  which allows 
> measuring how much space an arbitrary object occupies. clj-memory-meter is 
> usable from the REPL, can be loaded on-demand, and doesn't require to 
> launch JVM with special parameters.
>
> Blog post with a little more detail and usage examples: 
> http://clojure-goes-fast.com/blog/introspection-tool-object-memory-meter/
>
> To start, using add [com.clojure-goes-fast/clj-memory-meter "0.1.0"], or 
> run the following with clj:
>
> $ clj -Sdeps "{:deps {com.clojure-goes-fast/clj-memory-meter 
> {:mvn/version \"0.1.0\"}}}"
> Clojure 1.9.0
>
> ;; Nevermind the warning, it doesn't break the library.
> user=> (require '[clj-memory-meter.core :as mm])
> objc[59881]: Class JavaLaunchHelper is implemented in both 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/bin/java 
> (0x1089814c0) and 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/jre/lib/libinstrument.dylib
>  
> (0x10d9dc4e0). One of the two will be used. Which one is undefined.
> nil
>
> user=> (mm/measure (vec (range 10)))
> "2.8 MB"
>
> user=> (mm/measure (list 1 2 3 4 5) :debug true)
>
> root [clojure.lang.PersistentList] 320 bytes (40 bytes)
>   |
>   +--_first [java.lang.Long] 24 bytes (24 bytes)
>   |
>   +--_rest [clojure.lang.PersistentList] 256 bytes (40 bytes)
> |
> +--_first [java.lang.Long] 24 bytes (24 bytes)
> |
> +--_rest [clojure.lang.PersistentList] 192 bytes (40 bytes)
>   |
>   +--_first [java.lang.Long] 24 bytes (24 bytes)
>   |
>   +--_rest [clojure.lang.PersistentList] 128 bytes (40 bytes)
> |
> +--_first [java.lang.Long] 24 bytes (24 bytes)
> |
> +--_rest [clojure.lang.PersistentList] 64 bytes (40 bytes)
>   |
>   +--_first [java.lang.Long] 24 bytes (24 bytes)
>
> "320 B"
>
> I hope this library will be useful for you. Enjoy!
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [ANN] clj-memory meter – measure the memory used by arbitrary objects

[Sean Corfield]

Could you try that again and immediately after getting the exception from the 
require, type in:

  *e

(instead of trying the mm/measure call)

In the exception that prints out, look for the Caused by portion of the 
exception. That’s going to be the underlying exception that will help us help 
you debug this.

Also, what version of Java are you using? (java -version)

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of 
numbch...@gmail.com 
Sent: Tuesday, March 6, 2018 8:38:34 PM
To: clojure@googlegroups.com
Subject: Re: [ANN] clj-memory meter – measure the memory used by arbitrary 
objects

Got error when requiring:

clj -Sdeps "{:deps {com.clojure-goes-fast/clj-memory-meter {:mvn/version 
\"0.1.0\"}}}"
Clojure 1.9.0
user=> (require '[clj-memory-meter.core :as mm])
CompilerException java.lang.reflect.InvocationTargetException, 
compiling:(clj_memory_meter/core.clj:50:1)
user=> (mm/measure (vec (range 10)))
CompilerException java.lang.RuntimeException: No such namespace: mm, 
compiling:(NO_SOURCE_PATH:2:1)
user=>


[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Tue, Mar 6, 2018 at 7:44 PM, Alexander Yakushev 
mailto:unlo...@bytopia.org>> wrote:
user=> (count nn)
25000

user=> (mm/measure nn)
"940.3 KB"

;; Still shared though!
user=>(mm/measure [mm nn])
"1.8 MB"

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 
clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clj-memory meter – measure the memory used by arbitrary objects

[numbch...@gmail.com]

Got error when requiring:

clj -Sdeps "{:deps {com.clojure-goes-fast/clj-memory-meter {:mvn/version
\"0.1.0\"}}}"
Clojure 1.9.0
user=> (require '[clj-memory-meter.core :as mm])
CompilerException java.lang.reflect.InvocationTargetException,
compiling:(clj_memory_meter/core.clj:50:1)
user=> (mm/measure (vec (range 10)))
CompilerException java.lang.RuntimeException: No such namespace: mm,
compiling:(NO_SOURCE_PATH:2:1)
user=>


[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Tue, Mar 6, 2018 at 7:44 PM, Alexander Yakushev 
wrote:

> user=> (count nn)
> 25000
>
> user=> (mm/measure nn)
> "940.3 KB"
>
> ;; Still shared though!
> user=>(mm/measure [mm nn])
> "1.8 MB"
>
> --
> 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: clojure.spec gen-testing VS NaN

[Wes Morgan]

Yes it did: https://dev.clojure.org/jira/browse/CLJ-2054

On Tuesday, March 6, 2018 at 12:15:26 PM UTC-7, Wes Morgan wrote:
>
> Did this ticket get created?
>
> On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote:
>>
>> Alright cool, I'll do that tomorrow :) 
>>
>> Thanks,
>>
>> Dimitris
>>
>> On 07/11/16 22:07, Alex Miller wrote:
>>
>> I think it would be reasonable to log a jira enhancement request for the 
>> spec any? generator to avoid generating double NaNs. 
>>
>>
>> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: 
>>>
>>> Hi Alex,
>>>
>>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help 
>>> me if I want to :ret spec a function with similar semantics as remove (a fn 
>>> that transforms a seq given a predicate), which I find a very common 
>>> indeed.  I'm only starting playing with clojure.spec (in fact i've only 
>>> spec'ed 2 fns so far) and I've not yet had to spec specifically a 
>>> double-precision number. I have had however the need to spec :any? as 
>>> ::anything-but-NaN, in both my first 2 specs, so according to my experience 
>>> this is by no means a rare issue. In fact, looking at clojure.core, most 
>>> fns operate on seqs, and a good proportion of them processes/transforms a 
>>> coll according to a predicate/fn. This has nothing to do with doubles or in 
>>> fact numbers. We can only spec the contents of the collection as `any?` 
>>> right? anything more specific, and the gen-surface area is reduced. So yeah 
>>> it's great that we have `s/double-in`, but ideally I'd also like a reliable 
>>> way to say that the output coll from a fn is equal to the input coll, while 
>>> having specified the contents of that coll with `any?`, and without having 
>>> to jump through hoops in the :ret spec. My workaround is actually working 
>>> nicely for me, and i can certainly live without NaNs in the tests, but it 
>>> still feels a bit hacky.
>>>
>>> Thanks,
>>>
>>> Dimitris
>>>
>>> On 07/11/16 18:14, Alex Miller wrote:
>>>
>>> Please also take a look at s/double-in, which allows you to exclude NaN 
>>> (and Infinity/-Infinity) as valid values. 
>>>
>>> (I realize this does not address the any? question, but that seems like 
>>> a rarer issue to me than cases where I'm explicitly spec'ing a double but 
>>> don't want to allow NaN.)
>>>
>>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: 

 Hi all, 

 clojure.spec helped me realise that NaNs totally break [1] equality 
 (per 
 `clojure.core/=`). Even though in real production code this might not 
 be 
 an issue due to how infrequently one deals with NaNs, but during 
 gen-testing I've found them extremely annoying, and I've essentially 
 worked around this by spec-ing things I'd normally specify via `any?`, 
 via `(s/and any? (complement double-NaN?))` instead. I have to do this 
 for any spec, where in the :ret spec i need to be able to confirm that 
 the input coll is equal to the output coll (e.g. `clojure.core/remove` 
 returns the same coll it was passed in when nothing has been removed), 
 which is a possibility in a lot of functions. Have other people 
 encountered this as well, and if yes, how are you guys dealing with it? 
 Thanks in advance... 

 Kind regards, 

 Dimitris 

 [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 



 -- 
>>> 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, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
G

Re: clojure.spec gen-testing VS NaN

[Wes Morgan]

Did this ticket get created?

On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote:
>
> Alright cool, I'll do that tomorrow :) 
>
> Thanks,
>
> Dimitris
>
> On 07/11/16 22:07, Alex Miller wrote:
>
> I think it would be reasonable to log a jira enhancement request for the 
> spec any? generator to avoid generating double NaNs. 
>
>
> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: 
>>
>> Hi Alex,
>>
>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help me 
>> if I want to :ret spec a function with similar semantics as remove (a fn 
>> that transforms a seq given a predicate), which I find a very common 
>> indeed.  I'm only starting playing with clojure.spec (in fact i've only 
>> spec'ed 2 fns so far) and I've not yet had to spec specifically a 
>> double-precision number. I have had however the need to spec :any? as 
>> ::anything-but-NaN, in both my first 2 specs, so according to my experience 
>> this is by no means a rare issue. In fact, looking at clojure.core, most 
>> fns operate on seqs, and a good proportion of them processes/transforms a 
>> coll according to a predicate/fn. This has nothing to do with doubles or in 
>> fact numbers. We can only spec the contents of the collection as `any?` 
>> right? anything more specific, and the gen-surface area is reduced. So yeah 
>> it's great that we have `s/double-in`, but ideally I'd also like a reliable 
>> way to say that the output coll from a fn is equal to the input coll, while 
>> having specified the contents of that coll with `any?`, and without having 
>> to jump through hoops in the :ret spec. My workaround is actually working 
>> nicely for me, and i can certainly live without NaNs in the tests, but it 
>> still feels a bit hacky.
>>
>> Thanks,
>>
>> Dimitris
>>
>> On 07/11/16 18:14, Alex Miller wrote:
>>
>> Please also take a look at s/double-in, which allows you to exclude NaN 
>> (and Infinity/-Infinity) as valid values. 
>>
>> (I realize this does not address the any? question, but that seems like a 
>> rarer issue to me than cases where I'm explicitly spec'ing a double but 
>> don't want to allow NaN.)
>>
>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: 
>>>
>>> Hi all, 
>>>
>>> clojure.spec helped me realise that NaNs totally break [1] equality (per 
>>> `clojure.core/=`). Even though in real production code this might not be 
>>> an issue due to how infrequently one deals with NaNs, but during 
>>> gen-testing I've found them extremely annoying, and I've essentially 
>>> worked around this by spec-ing things I'd normally specify via `any?`, 
>>> via `(s/and any? (complement double-NaN?))` instead. I have to do this 
>>> for any spec, where in the :ret spec i need to be able to confirm that 
>>> the input coll is equal to the output coll (e.g. `clojure.core/remove` 
>>> returns the same coll it was passed in when nothing has been removed), 
>>> which is a possibility in a lot of functions. Have other people 
>>> encountered this as well, and if yes, how are you guys dealing with it? 
>>> Thanks in advance... 
>>>
>>> Kind regards, 
>>>
>>> Dimitris 
>>>
>>> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 
>>>
>>>
>>>
>>> -- 
>> 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, 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...@goo

Re: clojure.zip: skip a node

[Marco Rucci]

Hi all, thank for the helpful discussion.
I've stumbled upon the same issue of needing to skip a subtree during a 
traversal and solved it with the following skip function that is a slight 
modification of one in the original message:

(defn skip-subtree
  "Fast-forward a zipper to skip the subtree at `loc`."
  [loc]
  (cond
(zip/end? loc) loc
(some? (zip/right loc)) (zip/right loc)
(some? (zip/up loc)) (recur (zip/up loc))
:else (assoc loc 1 :end)))

In short, we traverse to the right if there's a right, otherwise we 
recursively go up and check again if there's a right.  If we never find a 
right, then we'll navigate back up to the root.  In this case, mark the 
zipper as consumed (with `:end`) and return.
Seems to be working well, so hopefully it can help somebody else. 

Cheers.

--
Marco


On Tuesday, May 6, 2014 at 5:24:53 PM UTC+2, Pascal Germroth wrote:
>
>
> On Tuesday, May 6, 2014 4:07:11 PM UTC+1, Alex Miller wrote:
>>
>> I wrote this article long ago which hints about this at the end:
>> https://www.ibm.com/developerworks/library/j-treevisit/
>>
>
> I started from that actually, very helpful article.
>
> I have since noticed a bug in my previous skip function where it would 
> loop infinitely when skipping from the rightmost location.
> The fix includes an end function, so I can no just iterate backwards using 
> that as you suggested.
>
> Leaving this here for future reference, in case anybody comes across the 
> same problem:
>
> (defn end
>   "returns the location loc where (end? (next loc)) is true."
>   [loc]
>   (loop [loc loc]
> (let [loc (z/rightmost loc)]
>   (if (z/branch? loc)
> (recur (z/down loc))
> loc
>
> (defn skip
>   "returns the next location that is not a child of this one"
>   [start-loc]
>   (loop [loc start-loc]
> (cond
>   ; can't skip, jump to end
>   (nil? loc) (z/next (end start-loc))
>   ; at end
>   (z/end? loc) loc
>   ; go to right/up
>   true (or (z/right loc)
>(recur (z/up loc))
>  
>
>>
>> The approach I have taken for editing trees with zippers is to do a 
>> post-walk from end to beginning - that way you're always done transforming 
>> and will not walk into your edited subtrees. The article does talk a little 
>> about how to separate navigation from transformation; it's not particularly 
>> hard. You want to start from your rightmost node, which you can get from a 
>> repeated application of zip/rightmost or last of zip/rights. Then 
>> repeatedly call prev till you reach a node without a parent at that point 
>> convert the loc to a node in the termination.
>>
>> I can dig up actual code for this later if you're interested.
>>
>> Alex
>>
>>
>> On Monday, May 5, 2014 6:01:04 PM UTC-5, Pascal Germroth wrote:
>>>
>>> Hi,
>>>
>>> I'm using clojure.zip to edit a tree by visiting each location using 
>>> zip/next, possibly using zip/replace to alter the tree.
>>> There are cases where I replace a part of the tree with another tree 
>>> that will/must not be visited, but I couldn't find a good way to skip 
>>> nodes, since
>>> (zip/next (zip/replace loc new-subtree)) will walk right into my new 
>>> tree, and I can't use (zip/right (zip/replace loc new-subtree)) as the 
>>> replaced location might already be the rightmost.
>>>
>>> Is there a built-in function I missed, or a zip enhancement library I 
>>> could use?
>>>
>>> (defn skip
>>>   "returns the next location that is not a child of this one"
>>>   [loc]
>>>   (if (or (z/end? loc) (nil? loc))
>>> loc
>>> (loop [loc loc]
>>>   (or (z/right loc)
>>>   (recur (z/up loc))
>>>
>>> I came up with this replacement, does that seem like a good idea, or am 
>>> I using zip completely wrong (because what I really would like to do is 
>>> iterate backwards through the tree, starting at the end, using zip/prev; 
>>> but there's also no function to just jump to the end as far as I can tell)
>>>
>>>
>>> Cheers,
>>>
>>> -- 
>>> pascal
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clj-memory meter – measure the memory used by arbitrary objects

[Alexander Yakushev]

user=> (count nn)
25000

user=> (mm/measure nn)
"940.3 KB"

;; Still shared though!
user=>(mm/measure [mm nn])
"1.8 MB"

-- 
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: Why does the `def-` not exist?

[Léo Noel]

That's what I do !
However I have the gut feeling that the :private metadata was designed for 
exactly this purpose, and many people (including me) don't use it because 
they don't want to rely on dirty hacks to access implementation from the 
outside. That's why I half-jokingly suggested the compiler could just 
ignore it. This would foster its use so we could fully leverage tools 
designed for it such as those Alex cited. We could still rely on linters to 
make sure we don't accidentally call implementation directly in production 
code. Or maybe a compiler warning is a good compromise.
Of course this is just random thoughts, I started learning clojure around 
1.6 and I may be missing something obvious, so please correct me if this 
has already been discussed before.

On Monday, March 5, 2018 at 9:26:09 AM UTC+1, Chris Ford wrote:
>
> This isn't foolproof Léo, but sometimes folks use docstrings to make that 
> distinction i.e. if it's got a docstring it's part of the public API. 
> Codox, for example, takes this approach when deciding what to include in 
> generated API documentation.
>
> On 4 March 2018 at 12:50, Léo Noel > 
> wrote:
>
>> Or maybe people are confused because the :private metadata *complects* 
>> two separate concerns : *API commitment* and *visibility*.
>> If there was a way to programmatically make the distinction between 
>> implementation and API without impacting visibility, it would be 
>> tremendously valuable for tooling and I would definitely use it.
>>
>>
>> On Saturday, March 3, 2018 at 6:02:00 PM UTC+1, Alex Miller wrote:
>>>
>>> > ^:private is the stale and sleazy co-conspirator of another blunt 
>>> instrument, the whole-ns :use. 
>>>
>>> It’s also useful for anything that uses the var meta to show you only 
>>> public vars in an ns, such as dir, ns-publics, etc. those are all useful 
>>> and would affect your repl experience even if you never :use or :refer 
>>> :all. 
>>>
>>> I find people have different relationships with :private depending on 
>>> what kind of work they do. It’s very useful in in libs for delineating 
>>> public apis, much less important in an app context.
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] clj-memory meter – measure the memory used by arbitrary objects

[Matching Socks]

Unrealized lazy sequence...

user=> (def mm (filter even? (range 10)))
#'user/mm
user=> (mm/measure mm)
"160 B"


Realized...

user=> (count mm)
5
user=> (mm/measure mm)
"1.8 MB"


Structural sharing?

user=> (def nn (drop 25000 mm))
#'user/nn
user=> (mm/measure nn)
"1.8 MB"
user=> (mm/measure [mm nn])
"1.8 MB"


Can we free some of that memory?

user=> (def mm nil)
#'user/mm
user=> (mm/measure nn)
"1.8 MB"
user=> (System/gc)
nil
user=> (mm/measure nn)
"1.8 MB"


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