Re: spec key aliasing or different specs for same keyword

[adrian . medina]

Avoiding global name collision is the reason why specs are named with 
namespace-qualified keywords. I am confused by your last sentence though. 
Do you mean Clojure namespaces or the namespace component of the keyword 
itself? There is no requirement in clojure.spec that the namespace of the 
specs you def be coupled to the Clojure namespace they happen to be defined 
in. If you are actually asking about how to write specs for unqualified 
keys in a map there is a built-in facility to do that as well: 
clojure.spec.alpha/keys has a :req-un and :opt-un argument.

On Thursday, December 28, 2017 at 11:28:18 AM UTC-5, Jonathon McKitrick 
wrote:
>
> I have one spec question covering two scenarios.
>
> 1. Suppose I want to spec a payload from a third-party API that has the 
> keyword ':resultCount' in it. Does that mean my specs for that item must 
> have the same name?
>
> 2. Supposed I have a few payloads from that API and each has a keyword 
> ':result' but the spec for each will be different. Other than using an 
> entirely different namespace, how can I map the :result keyword to 
> different specs?
>
> Thanks!
>

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

Re: Minor bug in clojure.zip/path

[adrian . medina]

clojure.core/seq?
([x])
  Return true if x implements ISeq

(seq? []) => false

because...

(instance? clojure.lang.ISeq []) => false

Vectors do not implement ISeq. That's all the seq? predicate cares about.

But vectors are `seqable?`:

clojure.core/seqable?
([x])
  Return true if the seq function is supported for x

(seqable? []) => true

Colloquially, it is normal to refer to any seqable collection as a "seq". 

On Tuesday, October 24, 2017 at 4:13:51 PM UTC-4, Maxim Bazhenov wrote:
>
> Hi,
>
> the documentation for clojure.zip/path states that it *"Returns a seq of 
> nodes leading to this loc". *But the following test will fail (seq? 
> returns false):
> (require '[clojure.zip :as z])
>
> (def v [[1]])
>
> (def vz (z/vector-zip v))
>
> (seq? (z/path (z/down (z/down vz
>
> The path actually returns a vector which is not a seq
>

-- 
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: CPU & platform for best compilation performance

[adrian . medina]

Shot in the dark, but dependent namespace compilation may be the source of 
your CLJS compiler slowdowns if you have tons of namespaces. Try seeing 
what happens when you set :recompile-dependents to false in the CLJS 
compiler options.

On Wednesday, August 23, 2017 at 11:54:44 AM UTC-4, Maarten Truyens wrote:
>
> Hi all, 
>
> My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of 
> code, and compilation times are starting to interfere with my workflow 
> happiness. In addition, Chrome Devtools is becoming somewhat sluggish due 
> to the high number of separate namespaces loaded through Figwheel. 
>
> My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For 
> quite a while I have been investigating whether a switch to another machine 
> and/or platform would be interesting from a workflow speed point of view. 
> However, aside from Timothy Pratley's article on the AMD Ryzen 1800x (
> http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html), 
> I have trouble finding information that is relevant for us Clojure 
> programmers. 
>
> I would summarize my research as follows:
> * single-core performance is most important, so that it is probably the 
> case that a 4-core CPU with a higher single-thread speed is preferable to 
> an 6/8/10-core CPU with a slower single-thread speed;
> * as from 4 cores, there are hardly any speedups to be expected for having 
> more cores in CLJ or even (parallel) CLJS builds;
> * the Ryzens are great value, but their single-core performance is usually 
> 10-20% below the top of the line Intels; 
> * according to the many Phoronix benchmarks, Linux and OSX have about the 
> same performance, although there are some interesting deviations for some 
> workflows (even up to 30 - 40%);
> * the single-core performance difference between my current CPU and the 
> single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be 
> between 20-40%
>
> While a 50% performance increase would be enough to warrant the time 
> investment & cost of switching, my fear is that the real-world speed-up 
> will probably be more like a meager 20%. 
>
> Ignoring cost considerations and performance outside CLJ development: what 
> CPU and platform would you recommend?  
>
> Many thanks!
>
> Maarten
>

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

Re: What kind of dependency is org.clojure/core.specs in a Leiningen project?

[adrian . medina]

Consider adding it as a dependency in your :dev profile. 

On Thursday, June 15, 2017 at 12:25:36 PM UTC-4, 676c...@gmail.com wrote:
>
> Hello,
>
> I have a question regarding the Clojure spec split.
>
> How would a diligent Clojure library author declare the core.specs
> dependency in a Leiningen project? The core specs need to be available
> during development, but they are not really a dependency if I never
> refer to them anywhere: so I don’t think it’s right to depend on them
> directly. Am I correct in thinking that the typical scope for core.specs
> is ‘provided’?
>
> I have a library that uses specs in the main namespace. Therefore,
> org.clojure/spec.alpha is an actual project dependency. But with
> org.clojure/core.specs.alpha I am not so sure.
>
> Thank you!
>
>
> --
> David
>
>

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

Re: Starting with Clojure

[adrian . medina]

https://clojure.org/community/companies

https://clojure.org/community/community_stories

Might be insightful for you. Clojure has plenty of commercial use. 

On Tuesday, May 9, 2017 at 3:59:33 AM UTC-4, Kristian Koci wrote:
>
> Hello community
>
> I'm getting started with Clojure, seems like an exciting language, I've 
> been into LISP many years ago, so I think is really cool to have such a 
> language running on top of the jvm.
>
> Anyways, I'll love to know in which industries is Clojure used the most?
>
> Is there any example/name?
>
> I'm just curious to know, if besides the exciting 
> functional/experimental/scientific side, is there any significant steps 
> forward in business :)
>
> Thanks in advance!
>

-- 
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: Sayid Pro - Transparency for Clojure Production Environments (kickstarter)

[adrian . medina]

Thanks for the clarifications and answers! Interested to see what Emacs 
integration looks like. I'm surprised most developers want web interfaces 
for this stuff but can't argue with the data if it means more licenses sold 
for you. 

On Monday, May 8, 2017 at 1:10:37 PM UTC-4, Bill Piel wrote:
>
> Thanks for the questions and feedback, Adrian.
>
> > Why is the Pro version acceptable for production use and the free 
> version is not? 
>
> I thought I addressed that well in the video, but maybe not. And I didn't 
> do much to address that in the text. The answer is that sayid stores all 
> the data that it captures in memory. It would be much too easy to take down 
> a production server by capturing too much. Sayid Pro immediately exports 
> everything it captures to a db, minimizing impact on a server. I hope that 
> makes sense.
>
> > Why then is a web interface for this necessary or even desirable?
>
> My focus with sayid has been on the emacs integration, because that's what 
> I use. For Sayid Pro, I wanted to build what the community wanted. I 
> conducted a survey and a web interface was *far* more requested than 
> anything else. If the market wants integrations with IDEs/editors, or 
> possibly other production monitoring services, I will build that. But for 
> the prototype, I wanted to show what I believed would be generally most 
> appealing.
>
> Additionally, you describe cider and cursive as being the most mature 
> *development* environments. Agreed. They are excellent. But, I wouldn't 
> describe sayid pro as a development tool.
>
> I hope that helps.
>
> thanks
>
>
>
>
>
>
> On Monday, May 8, 2017 at 12:54:23 PM UTC-4, adrian...@mail.yu.edu wrote:
>>
>> Why is the Pro version acceptable for production use and the free version 
>> is not? Is it just the UI/UX improvements? I looked for this in the 
>> Kickstarter since I assumed this would be a major selling point, but could 
>> not find the answer. Apologies if I missed something.  
>>
>> I guess I also have unrelated concerns. 
>>
>> TRACE is a facility which has been part of Lisp systems since time 
>> immemorial. Visualizing traces is common in the Common Lisp world. Like 
>> other Lisp tooling, progress on porting equivalent functionality to Clojure 
>> has been slow, but has progressed significantly. At this point CIDER and 
>> Cursive have progressed to the most mature development environments 
>> available for Clojure programming. Why then is a web interface for this 
>> necessary or even desirable? If you have a better solution than what is 
>> provided by the built in functionality of your preferred development 
>> environment, you extend it. This means plugins in the IDE world, Elisp 
>> packages in the Emacs world, etc. Why not take that approach, which will 
>> lead to a product that integrates well with a developers existing tooling. 
>>
>> On Monday, May 8, 2017 at 10:35:00 AM UTC-4, Bill Piel wrote:
>>>
>>> Today I launched a kickstarter for Sayid Pro.
>>>
>>>
>>> https://www.kickstarter.com/projects/1269641244/sayid-pro-transparency-for-clojure-production-envi
>>>
>>> Maybe you've heard of Sayid, a clojure debugger and profiler, that I wrote 
>>> and then presented at Conj 2016. After my talk, a lot of people asked 
>>> me if sayid could be used in a production environment. I strongly 
>>> discouraged that. A month later, I started working on a new tool that 
>>> brings the same transparency as Sayid, but is designed for use in a 
>>> production environment. Sayid Pro nows exists as a very rough, but 
>>> promising, prototype.
>>>
>>> If you would like to help me build a tool that will give you insight into 
>>> your production servers -- far beyond what logs or metrics could ever 
>>> deliver -- please consider supporting this kickstarter.
>>>
>>> thanks,
>>> Bill
>>>
>>

-- 
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: Sayid Pro - Transparency for Clojure Production Environments (kickstarter)

[adrian . medina]

Why is the Pro version acceptable for production use and the free version 
is not? Is it just the UI/UX improvements? I looked for this in the 
Kickstarter since I assumed this would be a major selling point, but could 
not find the answer. Apologies if I missed something.  

I guess I also have unrelated concerns. 

TRACE is a facility which has been part of Lisp systems since time 
immemorial. Visualizing traces is common in the Common Lisp world. Like 
other Lisp tooling, progress on porting equivalent functionality to Clojure 
has been slow, but has progressed significantly. At this point CIDER and 
Cursive have progressed to the most mature development environments 
available for Clojure programming. Why then is a web interface for this 
necessary or even desirable? If you have a better solution than what is 
provided by the built in functionality of your preferred development 
environment, you extend it. This means plugins in the IDE world, Elisp 
packages in the Emacs world, etc. Why not take that approach, which will 
lead to a product that integrates well with a developers existing tooling. 

On Monday, May 8, 2017 at 10:35:00 AM UTC-4, Bill Piel wrote:
>
> Today I launched a kickstarter for Sayid Pro.
>
>
> https://www.kickstarter.com/projects/1269641244/sayid-pro-transparency-for-clojure-production-envi
>
> Maybe you've heard of Sayid, a clojure debugger and profiler, that I wrote 
> and then presented at Conj 2016. After my talk, a lot of people asked me 
> if sayid could be used in a production environment. I strongly 
> discouraged that. A month later, I started working on a new tool that 
> brings the same transparency as Sayid, but is designed for use in a 
> production environment. Sayid Pro nows exists as a very rough, but 
> promising, prototype.
>
> If you would like to help me build a tool that will give you insight into 
> your production servers -- far beyond what logs or metrics could ever 
> deliver -- please consider supporting this kickstarter.
>
> thanks,
> Bill
>

-- 
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: Using transducers in a new transducing context

[adrian . medina]

What you said holds for reduction but not necessarily a parallel fold (see 
clojure.core.reducers/fold). 

On Monday, April 10, 2017 at 9:37:29 AM UTC-4, Léo Noel wrote:
>
> This topic is of high interest to me as it is at the core of my current 
> works. I had a similar questioning a while ago 
>  and I have 
> to say I'm even more confused with this :
>
> While transducing processes may provide locking to cover the visibility of 
>> state updates in a stateful transducer, transducers should still use 
>> stateful constructs that ensure visibility (by using volatile, atoms, etc).
>>
>
> I actually tried pretty hard to find a use case that would make 
> partition-all fail because of its unsynchronized local state, and did not 
> manage to find one that did not break any contract. I arrived at the 
> conclusion that it is always safe to use unsynchronized constructs in 
> stateful transducers. The reason is that you need to ensure that the result 
> of each step is given to the next, and doing so you will necessarily set a 
> memory barrier of some sort between each step. Each step happens-before the 
> next, and therefore mutations performed by the thread at step n are always 
> visible by the thread performing the step n+1. This is really brilliant : 
> when designing a transducer, you can be confident that calls to your 
> reducing function will be sequential and stop worrying about concurrency. 
> You just have to ensure that mutable state stays local. True encapsulation, 
> the broken promise of object-oriented programming.
>
> My point is that the transducer contract "always feed the result of step n 
> as the first argument of step n+1" is strong enough to safely use local 
> unsynchronized state. For this reason, switching partition-* transducers to 
> volatile constructs really sounds like a step backwards to me. However, 
> after re-reading the documentation on transducers, I found that this 
> contract is not explicitly stated. It is just *natural* to think this way, 
> because transducers are all about reducing processes. Is there a plan to 
> reconsider this principle ? I would be very interested to know what Rich 
> has in mind that could lead him to advise to overprotect local state of 
> transducers.
>
>
>
> On Monday, April 10, 2017 at 4:44:00 AM UTC+2, Alexander Gunnarson wrote:
>>
>> Thanks so much for your input Alex! It was a very helpful confirmation of 
>> the key conclusions arrived at in this thread, and I appreciate the 
>> additional elaborations you gave, especially the insight you passed on 
>> about the stateful transducers using `ArrayList`. I'm glad that I wasn't 
>> the only one wondering about the apparent lack of parity between its 
>> unsynchronized mutability and the volatile boxes used for e.g. 
>> `map-indexed` and others.
>>
>> As an aside about the stateful `take` transducer, Tesser uses the 
>> equivalent of one but skirts the issue by not guaranteeing that the first n 
>> items of the collection will be returned, but rather, n items of the 
>> collection in no particular order and starting at no particular index. This 
>> is achievable without Tesser by simply replacing the `volatile` in the 
>> `core/take` transducer with an `atom` and using it with `fold`. But yes, 
>> `take`'s contract is broken with this and so still follows the rule of 
>> thumb you established that `fold` can't use stateful transducers (at least, 
>> not without weird things like reordering of the indices in `map-indexed` 
>> and so on).
>>
>> That's interesting that `fold` can use transducers directly! I haven't 
>> tried that yet — I've just been wrapping them in an `r/folder`.
>>
>> On Sunday, April 9, 2017 at 10:22:13 PM UTC-4, Alex Miller wrote:
>>>
>>> Hey all, just catching up on this thread after the weekend. Rich and I 
>>> discussed the thread safety aspects of transducers last fall and the 
>>> intention is that transducers are expected to only be used in a single 
>>> thread at a time, but that thread can change throughout the life of the 
>>> transducing process (for example when a go block is passed over threads in 
>>> a pool in core.async). While transducing processes may provide locking to 
>>> cover the visibility of state updates in a stateful transducer, transducers 
>>> should still use stateful constructs that ensure visibility (by using 
>>> volatile, atoms, etc).
>>>
>>> The major transducing processes provided in core are transduce, into, 
>>> sequence, eduction, and core.async. All but core.async are single-threaded. 
>>> core.async channel transducers may occur on many threads due to interaction 
>>> with the go processing threads, but never happen on more than one thread at 
>>> a time. These operations are covered by the channel lock which should 
>>> guarantee visibility. Transducers used within a go block (via something 
>>> like transduce or into) occur eagerly and don't incur any switch in threads 

Re: [ANN] core.async 0.3.426

[adrian . medina]

Thanks for pointing this out. 

On Thursday, February 23, 2017 at 6:37:45 AM UTC-5, Max Penet wrote:
>
> There are new/related issues that crept up with this release fyi.
>
> I would personally wait the next one for an upgrade in production: 
>
> http://dev.clojure.org/jira/browse/ASYNC-187
> http://dev.clojure.org/jira/browse/ASYNC-186
>
> On Wednesday, February 22, 2017 at 7:58:27 PM UTC+1, Gary Trakhman wrote:
>>
>> Thank you so much for getting around to ASYNC-138+32, it was a usability 
>> issue between idiomatic clojure code and async code, would show up almost 
>> immediately in new projects, the workaround raised questions during 
>> code-reviews, etc.
>>
>> On Wed, Feb 22, 2017 at 1:47 PM Alex Miller  wrote:
>>
>>> core.async 0.3.426 is now available.
>>>
>>> Try it via:  [org.clojure/core.async "0.3.426"]
>>>
>>> 0.3.426 includes the following changes:
>>>
>>>- ASYNC-169  - 
>>>handling of catch and finally inside go blocks was broken, causing a 
>>> number 
>>>of issues
>>>   - Related: ASYNC-100 
>>>   , ASYNC-173 
>>>   , ASYNC-180 
>>>   , ASYNC-179 
>>>   , ASYNC-122 
>>>   , ASYNC-78 
>>>   , ASYNC-168 
>>>   
>>>- ASYNC-138  - go 
>>>blocks do not allow closed over locals to be cleared which can lead to a 
>>>memory leak
>>>   - Related: ASYNC-32 
>>>- ASYNC-155  - 
>>>preserve loop binding metadata when inside a go block
>>>- ASYNC-54  - fix bad 
>>>type hint on MAX-QUEUE-SIZE
>>>- ASYNC-177  - fix 
>>>docstring typo in Buffer protocol full? method
>>>- ASYNC-70  - docstring 
>>>change in thread, thread-call
>>>- ASYNC-143  - assert 
>>>that fixed buffers must have size > 0
>>>- Update tools.analyzer.jvm dependency
>>>
>>>
>>> Many thanks to Kevin Downey and Nicola Mometto for their help on the go 
>>> block issues.
>>>
>>> Additionally, I've done some work to make the core.async build less 
>>> weird and to match all the other contrib projects (other than how the 
>>> version is computed). This will make core.async easier to use and manage 
>>> for development and CI and also lets us use our automated CI matrix test 
>>> setup to give us more coverage going forward.
>>>
>>> -- 
>>> 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] permissions - role & permission based access control

[adrian . medina]

My suggestion of a bitmask was just a response to a suggestion of prime 
factorization for encoding roles in an integer. I think using a set is just 
fine. The space requirements for a small set of keywords is negligible in 
the larger scheme of things. It also permits more readable code (always a 
good thing) with bits of code that need to interact with it. 

On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote:
>
> It might be premature optimization, or you could view it as a different 
> approach, for a different usage scenario.
> I'm myself pretty content with the literal approach, we're using this in a 
> fairly large application and haven't experienced any problems with regards 
> of performance or amount of data attached to users so far.
>
> On the other hand I see these suggestions as a way to experiment with 
> alternative approaches, which might as well teach me something...
>
> Stefan Kamphausen  schrieb am Do., 13. 
> Okt. 2016 um 10:29 Uhr:
>
>> Hi,
>>
>> Doesn't that feel like premature optimization to you, too?  Bitmasks are 
>> much harder to read than sets with spelled out roles and I wonder if the 
>> performance gain is really worth that. And it poses a limit of 64 roles.  I 
>> have seen several enterprise applications that had far more than 64 roles 
>> and/or permissions.
>>
>> Or am I missing something here?
>>
>> Just my 2ct.
>>
>> Kind regards,
>> Stefan
>>
>> -- 
>> 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] permissions - role & permission based access control

[adrian . medina]

If you wanted to do something more efficient, why not just use a bitmask? 
That is far more efficient than prime factorization.

On Tuesday, October 11, 2016 at 12:06:19 AM UTC-4, larry google groups 
wrote:
>
> A minor pet peeve of mine, but is it possible to attach prime numbers to 
> the roles, and to then decipher the roles from the factors of the total? 
> Using strings or keywords for permissions often strikes me as inefficient. 
> Assuming:
>
> create -- 2
>
> read -- 3
>
> update  -- 5
>
> delete -- 7
>
> bulk-erase -- 11
>
> delete-others -- 13
>
> So given a permissions value of 330, we can factor 330 and find 2, 3, 5 
> and 11. And it seems more efficient (though less readable) to carry around 
> "330" rather than [:create :read :update :bulk-erase]
>
> I would very much like to see a small library that does this for me, 
> rather than always writing this code for myself. 
>
>
>
>
>
>
>
>
>
> On Monday, October 10, 2016 at 6:51:14 AM UTC-4, Torsten Uhlmann wrote:
>>
>> I'd like to announce the first preview of "permissions"- a small library 
>> to handle role and permission based access control in web applications.
>>
>> Github: https://github.com/tuhlmann/permissions
>> Clojars: https://clojars.org/agynamix/permissions
>>
>> Permissions is heavily inspired and modeled after Apache Shiro's 
>> WildcardPermission: http://shiro.apache.org/permissions.html.
>>
>> In a nutshell, you can define permissions based on a 
>>
>> - domain: "users", "company", "admin", whatever the main areas of your 
>> application might be, 
>> - actions: "read", "edit", "delete", "upload" or however you like to name 
>> them,
>> - entities: "abcd1234", to limit access only to a resource with this 
>> specific ID
>>
>> And you have the wildcard. You can grant access to all domains, all 
>> actions, all entities by applying the wildcard in the appropriate field.
>>
>> Examples:
>>
>> "*" would grant access to everything (internally this would be 
>> represented as "*:*:*", a wildcard for each
>> "users:*" would grant the user that holds the permission to everything 
>> that asks for a "users" permission
>> "users:read" would grant the user read access
>> "users:write:abcd1234" would grant write access to that specific resource
>>
>> Roles:
>>
>> The library also holds an implementation for roles and an easy to use API 
>> to check if a given user holds a permission or does not.
>>
>> Roles are really just a container for a set of permissions. In order for 
>> the library to know which roles exist it has to be initialized with a map 
>> of roles.
>> The key is the name of the role, the value is a set of permissions. Such 
>> a definition could look like:
>>
>> (def roles {:user/admin "user/*"
>> :user/all   #{"user/read" "user/write"}
>> :admin/all  "*"
>> :company/super #{"company/read" "company/write" "company/edit" 
>> "company/delete"}
>> }
>>
>>
>> In order to let the library check if a user "has-permission?" or 
>> "lacks-permission?" it expects a key ":roles" and/ or a key ":permissions" 
>> (you can override that default) inside the user map.
>>
>> (def user {:roles #{:user/all :company/super}
>>:permissions #{"library/read" "company/gibberish"}
>>... lots of other keys
>>}
>>
>>
>> It would take the roles, flatten them to a list of permissions (through 
>> that mapping you initialized it with, remember?) and add the individual 
>> permissions to them.
>> It would then check if the permission required by the resource the user 
>> is trying to access is covered by one of the permissions of the user. How 
>> you handle granted or denied access is totally up to you.
>>
>> I have used this role based access management in a number of different 
>> Scala projects (https://github.com/liftmodules/mapperauth, 
>> https://github.com/eltimn/lift-mongoauth) and found it quiet versatile. 
>> I'm using it now in a ClojureScript project and thought that might 
>> actually be a good candidate for a standalone library. Now here it is.
>>
>> If you're interested in it please have a look at the tests and the code- 
>> I'm sure there is much room for improvement and interesting ideas I haven't 
>> thought about.
>> One thing that especially bugs me is the need to initialize the map of 
>> existing roles prior to using the library. If you come up with a better way 
>> I'm eager to hear it.
>>
>> Please keep in mind that the code is merely a preview at the moment. 
>> Changes to the API should comes as no surprise.
>>
>> Thanks,
>> Torsten.
>>
>>

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

Re: definterface odd error

[adrian . medina]

Hey Jeff,

The problem is that the code in that blog post is not amenable to 
copy/paste. The ellipses are standing in for other parts of the code they 
are leaving out. The exception you're seeing is basically saying that the 
symbol "..." cannot be treated like an indexed collection. The syntax for 
definterface expects a body of lists that spell out the method prototypes 
for that interface.

On Friday, September 23, 2016 at 3:54:44 PM UTC-4, Jeff Murphy wrote:
>
> Hi, I'm working with Clojure for the first time and am following a post to 
> implement a binary tree. However, the code results in an error that I've 
> been unable to figure out. 
>
> Post is here  
> http://macromancy.com/2014/04/09/data-structures-clojure-trees.html
>
> Error is 
>
>
> Exception in thread "main" java.lang.UnsupportedOperationException: nth 
> not supported on this type: Symbol
>
>
>
> The piece of code (if I paste into REPL) that causes the error is:
>
>
> (definterface INode
>   ...
>   (insert [k v]))
>
>
>
> If anyone can help me out with a hint/explanation, that would be awesome!
>
>
> thanks!
> jeff
>
>
>

-- 
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[adrian . medina]

Colin,

FWIW, I think you're doing a great job of articulating your points (which I 
largely agree with) and are providing great feedback for the core team and 
community to think about. This conversation is supposed to happen as the 
alpha versions are being iterated on. 

But I think continually resurfacing meta issues one has with Clojure's 
management (and I'm not saying you're doing this, but others are) instead 
of engaging thoughtfully with a team who is engaging you thoughtfully is 
both disrespectful and unproductive. Actually, it's counter productive 
because it can unfortunately make people think twice before taking you 
seriously in the future.

Like you, I think friendly error messages is an important issue for 
Clojure. We have an amazing source of heavily annotated information we can 
use to generate best-in-class error messages thanks to clojure.spec. We 
should refocus this in thread. 

But I'm not a moderator, so I guess take whatever I say with a grain of 
salt. :) 

On Thursday, August 25, 2016 at 7:12:04 PM UTC-4, Colin Fleming wrote:
>
> I really don't understand how you expect anyone to take your criticism 
>> seriously if you keep implying you're happily abandoning the language for 
>> greener pastures. 
>> Why would anyone developing Clojure look at anything you have to say at 
>> this point as anything less than trolling? 
>
>
> Because if we're genuinely interested in improving the language and the 
> community around it, the people who are deliberately choosing to leave it 
> have the answers to what we need to do that.
>
> I develop Cursive, and I'm always very interested in feedback from users, 
> and I'm really *more* interested in feedback about what they don't like 
> because my opportunities for improvement are there. It's always nice to 
> hear that people love Cursive and those messages are an important part of 
> maintaining my motivation to continue working on it. But in terms of 
> feedback that I can directly action, problems are where it's at.
>
> Of course, sometimes that feedback is not useful, actionable or valuable. 
> "IDEs suck" gets ignored, in much the same way that "Clojure sucks because 
> it's dynamically typed" should. "I don't use it because I find IDE's too 
> heavy" (like "I don't use Clojure because I prefer strong types") is fine, 
> there are lots of people out there with different preferences and I can't 
> cater to everyone. Being based on IntelliJ is what Cursive *is*, and I 
> can't change that. But if someone uses Cursive a lot, likes it, talks 
> publicly about how much they like it, participates in the issue tracker and 
> on the mailing list etc etc but then says "I'm taking up Emacs because I 
> can't stand how Cursive does x, y, and z" then I will absolutely try to 
> make those things better. 
>
> Criticisms about how the community works are perhaps the hardest to hear 
> since they seem very personal - if we're active in the community, in some 
> way they're directly criticising the ways we behave. Similarly, they're 
> much harder to fix. But they are essential, since no-one uses a programming 
> language purely because of the language itself these days.
>
> FWIW, I share many of Brian's concerns.
>
> On 26 August 2016 at 03:46,  wrote:
>
>> I really don't understand how you expect anyone to take your criticism 
>> seriously if you keep implying you're happily abandoning the language for 
>> greener pastures. 
>>
>> Why would anyone developing Clojure look at anything you have to say at 
>> this point as anything less than trolling? 
>>
>> Back on topic, I find Colin's suggestions about implementing an error 
>> reporting heuristic intriguing. What he has laid out could form the basis 
>> for a solution to this problem which can satisfy everyone's requirements 
>> when integrated well with spec's explain-data. I am curious to hear what 
>> Alex and others think about it. 
>>
>> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>>
>>>
>>> On Aug 24, 2016, at 9:28 PM, adrian...@mail.yu.edu wrote:
>>>
>>> I do not think your tone and lack of constructive feedback to Alex's 
>>> (and others) thoughtful responses is helping your case. 
>>>
>>>
>>> Probably not(*), though I would characterize the responses differently. 
>>> They are polite, and they are intended to be helpful to someone who already 
>>> agrees with axioms like “good error-handling is a nail for which core.spec 
>>> is the hammer” and “it is wise to push the responsibility for error 
>>> understanding to third-party libraries or diligent study”. They do a 
>>> service in that they lay out the rules under which Clojure users should 
>>> expect to live. But they are largely reiterations rather than engagement. I 
>>> find that rather frustrating.
>>>
>>>
>>> Let me point to an essential book on business/community management, 
>>> Hirschman’s /Exit, Voice, and Loyalty/. 
>>> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[adrian . medina]

I really don't understand how you expect anyone to take your criticism 
seriously if you keep implying you're happily abandoning the language for 
greener pastures. 

Why would anyone developing Clojure look at anything you have to say at 
this point as anything less than trolling? 

Back on topic, I find Colin's suggestions about implementing an error 
reporting heuristic intriguing. What he has laid out could form the basis 
for a solution to this problem which can satisfy everyone's requirements 
when integrated well with spec's explain-data. I am curious to hear what 
Alex and others think about it. 

On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>
>
> On Aug 24, 2016, at 9:28 PM, adrian...@mail.yu.edu  wrote:
>
> I do not think your tone and lack of constructive feedback to Alex's (and 
> others) thoughtful responses is helping your case. 
>
>
> Probably not(*), though I would characterize the responses differently. 
> They are polite, and they are intended to be helpful to someone who already 
> agrees with axioms like “good error-handling is a nail for which core.spec 
> is the hammer” and “it is wise to push the responsibility for error 
> understanding to third-party libraries or diligent study”. They do a 
> service in that they lay out the rules under which Clojure users should 
> expect to live. But they are largely reiterations rather than engagement. I 
> find that rather frustrating.
>
>
> Let me point to an essential book on business/community management, 
> Hirschman’s /Exit, Voice, and Loyalty/. 
> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever 
> take on group behavior, “Evaporative Cooling of Group Beliefs”, 
> http://lesswrong.com/lw/lr/evaporative_cooling_of_group_beliefs/. I think 
> there is much to learn from reflecting on those and the direction of 
> Clojure design and the Clojure community over the past few years. (I’m not 
> a huge fan of the application of Satir’s family counseling theory to 
> software management - Gerald Weinberg and the like - but it’s hard not to 
> read books like the /Quality Software Management/ series and see people in 
> the Clojure community - including me! - playing out stereotypical 
> dysfunctional roles.) 
>
> Read me as someone who’s publicly and self-destructively giving up on 
> Voice and is on the way to Exit. As someone who tends to Loyalty (though 
> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s 
> rather agonizing. That is, I still think Clojure is the best raw language 
> out there for broad-spectrum work. However, its design has been doubling 
> down on long-unfortunate tendencies, and - I’d argue - new languages like 
> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community 
> management and “peripheral” concerns like documentation and error handling. 
> In the meantime, the Clojure ideology - reinforced by memes like 
> “complecting” - has been getting more rigid. 
>
> The result is that what seem to me bizarre decisions are treated as 
> normal. We have an `any?` in clojure.core that always returns `true`. This 
> deviance from probably every other programming language is justified as 
> obvious for a feature - clojure.spec - that is largely unproven, certainly 
> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and 
> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is 
> completely dismissed, with the justification that people complain about 
> every new name. (Think about what that decision criterion entails, broadly 
> applied.)
>
> Also bizarre: the idea that error messages that amount to essentially 
> dumping a parse tree + BNF-ish grammar clause (possibly twice with a 
> vomitous stack trace between) is a *good* thing. Not a “we wish we could do 
> better, but software development is about constraints and tradeoffs” thing. 
> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing. 
>
> (I was honestly flummoxed that, although clojure.spec is supposed to be 
> the answer for error handling, there’s been no attempt to work through what 
> good error messages would be like and how the current infrastructure would 
> support the translation from raw data to such error messages.)
>
> I cannot help but think of this as groupthink. And - to be grandiose - 
> having people like me Exit will increase that, per evaporative cooling. 
>
>
> I also note that my library, Midje, is typically insulted on this mailing 
> list whenever a newbie brings it up. One of the contributors to this thread 
> has called it “an abomination”. There was no similar concern about *his* 
> tone. Because, I suspect, he's on the inside, punching out.
>
> ---
>
> (*) Might that not be my fiendish plan? Perhaps I’m being abrasive on this 
> list exactly to associate ideas like “error messages are the responsibility 
> of the compiler” as being from a hated Other, thus hardening a position 
> that I 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[adrian . medina]

I do not think your tone and lack of constructive feedback to Alex's (and 
others) thoughtful responses is helping your case. 

On Wednesday, August 24, 2016 at 8:46:47 PM UTC-4, Brian Marick wrote:
>
>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway  > wrote:
>
> 3. "Follow the inverted pyramid so people see what is most important." 
>  This kind of thing is easily done in a layer above spec, e.g. a custom 
> REPL printer for spec macro errors. Worth working on but not critical to 
> getting spec right.
>
>
> So why not do it in the bottom layer? Is there some deep reason why only 
> an unserious programmer would want information in anything other than the 
> current clojure.spec order? (We’re talking here about reordering a list.)
>
> There has been a notable lack of “yeah, we might have made a sub-optimal 
> decision” in this discussion. It looks bad, in my opinion. Has looked bad 
> for a long time. 
>
>
>

-- 
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: ref strange behavior

[adrian . medina]

The lazy sequence works with the code I provided as well. 

On Tuesday, August 23, 2016 at 9:29:08 AM UTC-4, Sergei Koledov wrote:
>
> Yes, you are absolutely right. After i modify the code as you advised, it 
> worked correctly. Thank you very much!
> Does it mean that is necessary to avoid the use of lazy data structures 
> within the STM?
>
> вторник, 23 августа 2016 г., 19:57:58 UTC+7 пользователь hitesh написал:
>>
>> Taking a quick look at this, I *think* the problem crops up in your tasks 
>> being a lazy sequence.
>>
>> Modify this
>>
>> (def tasks (ref (range 1 1000)))
>>
>> to this
>>
>> (def tasks (ref (doall (range 1 1000
>>
>> Running that with your large endpoint was taking a lot of time, so I'd 
>> suggest running it with 1e5 as that will finish much quicker.
>>
>>
>>
>> On Tuesday, August 23, 2016 at 8:22:00 AM UTC-4, Sergei Koledov wrote:
>>>
>>> Hello,
>>>
>>> I had a problem when I run the following code:
>>>
>>> (defn get-task [tasks]
>>>   (dosync
>>> (let [task (first @tasks)]
>>>   (alter tasks rest)
>>>   task)))
>>>
>>> (defn worker [& {:keys [tasks]}]
>>>   (agent {:tasks tasks}))
>>>
>>> (defn worker-loop [{:keys [tasks] :as state}]
>>>   (loop [last-task nil]
>>> (if-let [task (get-task tasks)]
>>>   (recur task)
>>>   (locking :out (println "Last task: " last-task
>>>   state)
>>>
>>> (defn create-workers [count & options]
>>>   (->> (range 0 count)
>>>(map (fn [_] (apply worker options)))
>>>(into [])))
>>>
>>> (defn start-workers [workers]
>>>   (doseq [worker workers] (send-off worker worker-loop)))
>>>
>>> (def tasks (ref (range 1 1000)))
>>>
>>> (def workers (create-workers 100 :tasks tasks))
>>>
>>> (start-workers workers)
>>> (apply await workers)
>>>
>>> Description: I have several agents (100 in my case). Each agent running 
>>> in a separate thread. All agents share the one ref with the collection of 
>>> tasks (range of longs in my case). Each agent get tasks from the collection 
>>> (in transaction) one by one until the collection becomes empty and then 
>>> prints the last task which it handle. However, when I run this code it 
>>> looks like the collection of tasks suddenly becomes empty and workers 
>>> handle only portion of all tasks (average 25-40% of all number).
>>>
>>> This code behave as I expected, when I create only one agent or use 
>>> explicit locking in get-task function:
>>>
>>> (defn get-task [tasks]
>>>   (locking :lock
>>> (dosync
>>> (let [task (first @tasks)]
>>>   (alter tasks rest)
>>>   task
>>>
>>> I run this code on the Clojure 1.8.0
>>> java version "1.8.0_91"
>>> Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
>>>
>>> Can anyone tell me, what am I doing wrong, or it really looks like a bug 
>>> in the clojure STM?
>>> I already asked this question on stackoverflow.com (
>>> http://stackoverflow.com/questions/39054911/strange-behavior-of-clojure-ref),
>>>  
>>> but so far nobody has been able to help me.
>>>
>>> P.S. Sorry for my english skill.
>>>
>>

-- 
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: ref strange behavior

[adrian . medina]

Here is working example code demonstrating how you might do this without 
agents:

(in-ns 'user)

(def tasks (ref (into clojure.lang.PersistentQueue/EMPTY (range 1 1000

(defn get-task
  [tasks]
  (dosync
(let [task (first @tasks)]
  (alter tasks pop)
  task)))

(defn worker-loop
  []
  (loop [completed-tasks []]
(if-let [task (get-task tasks)]
  (recur (conj completed-tasks task))
  completed-tasks)))

(defn create-workers
  [n & options]
  (vec (repeatedly n (fn []
   (future
 (worker-loop))

(def workers
  (create-workers 100))

(defn worker-test
  [xs]
  (= (set (mapcat deref workers))
 (set xs)))

(worker-test (range 1 1000))

On Tuesday, August 23, 2016 at 9:09:31 AM UTC-4, adrian...@mail.yu.edu 
wrote:
>
> I haven't run your code yet, but it's bad form to use Clojure's reference 
> types inside other reference types. They should store persistent data 
> structures to really make any sense in a concurrent context. 
>
> On Tuesday, August 23, 2016 at 8:22:00 AM UTC-4, Sergei Koledov wrote:
>>
>> Hello,
>>
>> I had a problem when I run the following code:
>>
>> (defn get-task [tasks]
>>   (dosync
>> (let [task (first @tasks)]
>>   (alter tasks rest)
>>   task)))
>>
>> (defn worker [& {:keys [tasks]}]
>>   (agent {:tasks tasks}))
>>
>> (defn worker-loop [{:keys [tasks] :as state}]
>>   (loop [last-task nil]
>> (if-let [task (get-task tasks)]
>>   (recur task)
>>   (locking :out (println "Last task: " last-task
>>   state)
>>
>> (defn create-workers [count & options]
>>   (->> (range 0 count)
>>(map (fn [_] (apply worker options)))
>>(into [])))
>>
>> (defn start-workers [workers]
>>   (doseq [worker workers] (send-off worker worker-loop)))
>>
>> (def tasks (ref (range 1 1000)))
>>
>> (def workers (create-workers 100 :tasks tasks))
>>
>> (start-workers workers)
>> (apply await workers)
>>
>> Description: I have several agents (100 in my case). Each agent running 
>> in a separate thread. All agents share the one ref with the collection of 
>> tasks (range of longs in my case). Each agent get tasks from the collection 
>> (in transaction) one by one until the collection becomes empty and then 
>> prints the last task which it handle. However, when I run this code it 
>> looks like the collection of tasks suddenly becomes empty and workers 
>> handle only portion of all tasks (average 25-40% of all number).
>>
>> This code behave as I expected, when I create only one agent or use 
>> explicit locking in get-task function:
>>
>> (defn get-task [tasks]
>>   (locking :lock
>> (dosync
>> (let [task (first @tasks)]
>>   (alter tasks rest)
>>   task
>>
>> I run this code on the Clojure 1.8.0
>> java version "1.8.0_91"
>> Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
>>
>> Can anyone tell me, what am I doing wrong, or it really looks like a bug 
>> in the clojure STM?
>> I already asked this question on stackoverflow.com (
>> http://stackoverflow.com/questions/39054911/strange-behavior-of-clojure-ref),
>>  
>> but so far nobody has been able to help me.
>>
>> P.S. Sorry for my english skill.
>>
>

-- 
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: ref strange behavior

[adrian . medina]

I haven't run your code yet, but it's bad form to use Clojure's reference 
types inside other reference types. They should store persistent data 
structures to really make any sense in a concurrent context. 

On Tuesday, August 23, 2016 at 8:22:00 AM UTC-4, Sergei Koledov wrote:
>
> Hello,
>
> I had a problem when I run the following code:
>
> (defn get-task [tasks]
>   (dosync
> (let [task (first @tasks)]
>   (alter tasks rest)
>   task)))
>
> (defn worker [& {:keys [tasks]}]
>   (agent {:tasks tasks}))
>
> (defn worker-loop [{:keys [tasks] :as state}]
>   (loop [last-task nil]
> (if-let [task (get-task tasks)]
>   (recur task)
>   (locking :out (println "Last task: " last-task
>   state)
>
> (defn create-workers [count & options]
>   (->> (range 0 count)
>(map (fn [_] (apply worker options)))
>(into [])))
>
> (defn start-workers [workers]
>   (doseq [worker workers] (send-off worker worker-loop)))
>
> (def tasks (ref (range 1 1000)))
>
> (def workers (create-workers 100 :tasks tasks))
>
> (start-workers workers)
> (apply await workers)
>
> Description: I have several agents (100 in my case). Each agent running in 
> a separate thread. All agents share the one ref with the collection of 
> tasks (range of longs in my case). Each agent get tasks from the collection 
> (in transaction) one by one until the collection becomes empty and then 
> prints the last task which it handle. However, when I run this code it 
> looks like the collection of tasks suddenly becomes empty and workers 
> handle only portion of all tasks (average 25-40% of all number).
>
> This code behave as I expected, when I create only one agent or use 
> explicit locking in get-task function:
>
> (defn get-task [tasks]
>   (locking :lock
> (dosync
> (let [task (first @tasks)]
>   (alter tasks rest)
>   task
>
> I run this code on the Clojure 1.8.0
> java version "1.8.0_91"
> Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
>
> Can anyone tell me, what am I doing wrong, or it really looks like a bug 
> in the clojure STM?
> I already asked this question on stackoverflow.com (
> http://stackoverflow.com/questions/39054911/strange-behavior-of-clojure-ref), 
> but so far nobody has been able to help me.
>
> P.S. Sorry for my english skill.
>

-- 
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: taking my clojure game to a higher level

[adrian . medina]

I think you just need a project to motivate you to go deeper into the 
language. Take on a project that you've been wanting to work on for some 
time and write it in Clojure.

On Saturday, August 20, 2016 at 11:59:42 PM UTC-4, chia kang ren wrote:
>
> I started programming with Racket 2 years ago and i decided i want to use 
> a Lisp with more libraries at my disposal. So i have made some headway into 
> Clojure and am familiar with core functions like map, reduce, filter, loop, 
> for, doseq, some, every?, apply. I make use of macros like ->, ->>, .. 
>  sometimes. I'm somewhat familiar with destructuring and the clojure data 
> structures.
>
> I have never seen the need to learn transients, macros, protocols, 
> transducers, multimethods, have struggled with string and file I/O 
> operations on the rare occasions i need to use them. I have a vague idea of 
> things like "parallelism", "concurrency", probably because the applications 
> i build never have had a need of such things. I have a vague idea of how 
> expensive calls to this or that function would be.
>
> Most of my explorations have been with Clojurescript using Om or solving 
> puzzles, so i have been limited to mostly small scripts, or projects that 
> never go beyond a few files.
>
> I would like to step up my game. I like working in Clojure enough and i 
> think i have had enough of scripts, i want to write Clojure *programs.* I 
> want to understand how to make the most of this language, and I would 
> appreciate very much anecdotes/guidance from the community on how to do so 
>

-- 
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: Using a function to def other functions?

[adrian . medina]

def isn't a good example actually because it's a special form. But the same 
principle applies when using it as a non-top level form. 

On Monday, August 8, 2016 at 5:30:12 PM UTC-4, adrian...@mail.yu.edu wrote:
>
> defn, def, etc are what I mean by "defining macros". 
>
> On Monday, August 8, 2016 at 5:19:04 PM UTC-4, fah...@gmail.com wrote:
>>
>> Oh...   'bar' and 'make-step' count as macros? My intent was that they're 
>> ordinary functions that return functions. Am I mistaken? Or does the issue 
>> you referred to apply to using defining *functions and macros *as 
>> non-top-level forms?
>>
>> (defn bar [] (fn ([x] (inc x
>>
>> (defn make-step [some-args]
>>   (fn ([other-args]
>>(some-body using-both-args
>>
>>
>>

-- 
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: Using a function to def other functions?

[adrian . medina]

defn, def, etc are what I mean by "defining macros". 

On Monday, August 8, 2016 at 5:19:04 PM UTC-4, fah...@gmail.com wrote:
>
> Oh...   'bar' and 'make-step' count as macros? My intent was that they're 
> ordinary functions that return functions. Am I mistaken? Or does the issue 
> you referred to apply to using defining *functions and macros *as 
> non-top-level forms?
>
> (defn bar [] (fn ([x] (inc x
>
> (defn make-step [some-args]
>   (fn ([other-args]
>(some-body using-both-args
>
>
>

-- 
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: Using a function to def other functions?

[adrian . medina]

Using defining macros as non top-level forms may not be forbidden by the 
language but its use is generally discouraged. 
See http://clhs.lisp.se/Issues/iss104_w.htm for a discussion about this 
issue in Common Lisp for some background context. In short, compile time 
effects may not be captured whenever you use defining macros as non 
top-level forms. I think you're seeing something like this manifest here. 
In this case, since you referenced a var which was not installed when the 
compiler reaches the calling code, the compiler will throw this error 
message. I would suggest rethinking this because the solution is ugly, but 
you should use something like clojure.core/resolve or 
clojure.core/ns-resolve to resolve the var dynamically and then funcall it. 

On Monday, August 8, 2016 at 2:52:37 PM UTC-4, fah...@gmail.com wrote:
>
> user> (macroexpand-1 '(defn foo [x] (inc x)))
> (def foo (clojure.core/fn ([x] (inc x
>
> If defn is just a macro, then it seems I can do this:
>
> user> (defn bar [] (fn ([x] (inc x
> #'user/bar
>
> user> (def foo (bar))
> #'user/foo
>
> user> foo
> #function[user/bar/fn--10778]
>
> But the result is a little different than doing it directly with defn:
>
> user> (defn foo [x] (inc x))
> #'user/foo
>
> We had #'user/*bar/fn--10778* vs #'user/foo. But either way, foo is bound 
> to something.
>
> Is the difference significant? It seems like it is because I tried 
> something similar in my project and got the following:
>
> IllegalStateException Attempting to call unbound fn: #'p.core/default-step 
>  clojure.lang.Var$Unbound.throwArity (Var.java:43)
> p.core> default-step
> #function[p.core/make-step/fn--10747]
>
> Function default-step was def'd using make-step which returned a function 
> and default-step is bound, so why does the repl say it is not?
>
> (defn make-step [some-args]
>   (fn ([other-args]
>(some-body using-both-args
>
> Basically I need to define a bunch of similar functions and am trying to 
> use another function to help define them (instead of using a macro). But it 
> seems I'm doing something wrong...
>

-- 
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: meaning of spec/and ?

[adrian . medina]

Just for future reference this is a mailing list and not a traditional 
forum, so after you post something here it will email everyone subscribed. 

On Thursday, July 21, 2016 at 6:24:28 PM UTC-4, Mars0i wrote:
>
> Ahh...  I realized my mistake very soon after I posted the question, and 
> deleted it.  You must have caught it before it went away.  Your explanation 
> is helpful, though.  Thanks.
>
> On Thursday, July 21, 2016 at 1:30:56 PM UTC-5, miner wrote:
>>
>> It looks like you’ve got your #s misplaced.  I think you want something 
>> like this:
>>
>> (s/and #(> % 0.0) #(< % 1.0))
>>
>> Of course, the first predicate expression could be replaced by `pos?`.
>>
>> The `s/and` returns a single spec that combines multiple specs.  Of 
>> course, `clojure.core/and` is basically the logical AND of “truthy” values.
>>
>> The #(…) form is creating an anonymous function.  In your first case, 
>> that creates a reasonable predicate, which works correctly as a spec.
>>
>> Your second form isn’t doing what you wanted because the anonymous 
>> function notation is wrapping the whole `s/and` combining form, and in that 
>> context the tests aren't syntactically the appropriate predicates.  You’re 
>> getting an extra level of nesting and bad tests.
>>
>> I suspect that the confusion comes from the similarity between a 
>> predicate and a spec.  In a sense, a predicate function is the simplest 
>> form of a spec.  However, you need a special way of combining multiple 
>> specs, not just the plain logical `and` combination.  So we have `s/and` to 
>> do the job.
>>
>>
>>
>> On Jul 21, 2016, at 1:23 PM, Mars0i  wrote:
>>
>> With Clojure 1.9.0-alpha10:
>>
>>
>>
>>
>>
>>
>>
>>
>> *user=> (s/def ::interval-with-cloj-and #(and   (> % 0.0) (< % 
>> 1.0)))user=> (s/def ::interval-with-spec-and #(s/and (> % 0.0) (< % 
>> 1.0)))user=> (s/valid? ::interval-with-cloj-and 1.0)false*That's what I 
>> expected.
>>
>>
>> *user=> (s/valid? ::interval-with-spec-and 1.0)true*
>>
>> That's not what I expected.
>>
>> In fact, as far as I can tell, (valid? ::interval-with-spec-and x) will 
>> return true for any number x.  What does spec/and mean, then?  I thought 
>> that in this context it would mean the same as Clojure's normal 'and'.  
>> That's what the first example of its use in the Clojure.spec Guide seems to 
>> show.  I must be misunderstanding something basic and perhaps obvious.
>>
>>
>>
>>

-- 
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: Sneaky ways to get people to learn Clojure

[adrian . medina]

This is awesome. 

On Sunday, July 3, 2016 at 1:45:11 AM UTC-4, James Elliott wrote:
>
> As a spinoff from Afterglow 
> , my Clojure-based 
> live-coding environment for light shows, I’ve created a library 
>  that facilitates 
> synchronizing things with Pioneer’s professional DJ equipment. And then I 
> was talked into creating an example application 
>  
> showing how to use it. With the help of seesaw and inspector-jay, among 
> other great Clojure and Java libraries, I was able to quickly create 
> something far more useful than I expected, and people are starting to find 
> it.
>
> Of course, I provide an embedded editor for you to use Clojure expressions 
> to customize and extend it, so I have DJs and show producers around the 
> world learning a little Clojure as an unexpected outcome. Thankfully our 
> community has great learning resources I can point them towards as well! 
> Thus it is being used successfully at events like this one 
> 
> :
>
>
> 
>
>
> If anyone is curious to see how Afterglow itself has come along since I 
> first announced it here last year, the recording of the presentation I gave 
> to the Madison Clojure Meetup, Afterglow: Live Coding for Light Shows 
> , turned out halfway decent, especially 
> once I added captions.
>
>
> Thanks again to everyone who helped me in my own learning and coding 
> journey in this wonderful environment!
>

-- 
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] Clojure 1.9.0-alpha6

[adrian . medina]

Thanks for the link Alex. I understand what changed, but I still don't 
understand why. Could you elaborate on the thought that went into this? 
Thank you. 

On Wednesday, June 15, 2016 at 7:37:52 PM UTC-4, Alex Miller wrote:
>
> Check out the thread at 
> https://groups.google.com/forum/m/#!topic/clojure/RLQBFJ0vGG4
>
> On Jun 15, 2016, at 5:22 PM, adrian...@mail.yu.edu  wrote:
>
> I was wondering if you could shed some light on why instrument was changed 
> to not automatically check the :ret and :fn specs. I miss that feature 
> already, hehe, although I understand that these are alpha versions and 
> things evolve. :) I just want to understand the context behind this 
> decision. If I missed relevant discussion already explaining this, I 
> apologize. 
>
> On Tuesday, June 14, 2016 at 1:31:25 PM UTC-4, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha6 is now available.
>>
>> Try it via
>>
>> - Download: 
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha6
>> - Leiningen: [org.clojure/clojure "1.9.0-alpha6"]
>>
>> 1.9.0-alpha6 includes the following changes since 1.9.0-alpha5:
>>
>> - & regex op now fails fast when regex passes but preds do not
>> - returns from alt/or are now map entries (supporting key/val) rather 
>> than 2-element vector
>> - [BREAKING] fn-specs was renamed to fn-spec and returns either the 
>> registered fspec or nil
>> - fspec now accepts ifn?, not fn?
>> - fspec impl supports keyword lookup of its :args, :ret, and :fn specs
>> - fix fspec describe which was missing keys and improve describe of 
>> :args/ret/fn specs
>> - instrument now checks *only* the :args spec of a var - use the 
>> clojure.spec.test functions to test :ret and :fn specs
>> - Added generator support for bytes? and uri? which were accidentally 
>> left out in alpha5
>>
>> -- 
> 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 a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/JIgmEFhAlq8/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Clojure 1.9.0-alpha6

[adrian . medina]

I was wondering if you could shed some light on why instrument was changed 
to not automatically check the :ret and :fn specs. I miss that feature 
already, hehe, although I understand that these are alpha versions and 
things evolve. :) I just want to understand the context behind this 
decision. If I missed relevant discussion already explaining this, I 
apologize. 

On Tuesday, June 14, 2016 at 1:31:25 PM UTC-4, Alex Miller wrote:
>
> Clojure 1.9.0-alpha6 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha6
> - Leiningen: [org.clojure/clojure "1.9.0-alpha6"]
>
> 1.9.0-alpha6 includes the following changes since 1.9.0-alpha5:
>
> - & regex op now fails fast when regex passes but preds do not
> - returns from alt/or are now map entries (supporting key/val) rather than 
> 2-element vector
> - [BREAKING] fn-specs was renamed to fn-spec and returns either the 
> registered fspec or nil
> - fspec now accepts ifn?, not fn?
> - fspec impl supports keyword lookup of its :args, :ret, and :fn specs
> - fix fspec describe which was missing keys and improve describe of 
> :args/ret/fn specs
> - instrument now checks *only* the :args spec of a var - use the 
> clojure.spec.test functions to test :ret and :fn specs
> - Added generator support for bytes? and uri? which were accidentally left 
> out in alpha5
>
>

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

[adrian . medina]

This looks incredible and it sounds like something which could immediately 
be put to good use in both hobby and production projects. Excited to test 
it out when the alpha is available. Thank you!

On Monday, May 23, 2016 at 10:12:29 AM UTC-4, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

-- 
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 do "key" and "val" not work on 2-element vectors?

[adrian . medina]

I may be misremembering here, but I think this was briefly implemented for 
an alpha release of 1.8.0. I think the entire feature in question is being 
reworked for the future, but I'm uncertain of the details. Perhaps others 
can chime in with the background motivating those changes and reversions? 

On Wednesday, May 4, 2016 at 12:44:19 PM UTC-4, JvJ wrote:
>
>
> I've noticed that, in Clojure, there is a MapEntry type that supports the 
> operations "key" and "val", but in Clojurescript, MapEntry is replaced by 
> simple 2-element vectors.
>
> Furthermore, 2-element vectors can be used in almost all other cases where 
> a MapEntry is expected, and MapEntries support all vector operations,but 
> "key" and "val" are
> not supported on these vectors.
>
> Is there a particular design reason for this?  It doesn't seem like much 
> more than an inconvenience
>

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

Re: Are strings vectors? Should 'get' docstring be changed?

[adrian . medina]

That's a good point, but it should be noted that all collections for which 
clojure.core/counted? returns true (they implement clojure.lang.Counted) 
should implement count in constant time. So the design of the Counted 
interface was clearly intended to provide consumers a soft guarantee of 
performance invariability across data structures when required. 

On Thursday, April 21, 2016 at 1:26:26 PM UTC-4, Michael Gardner wrote:
>
> On Apr 21, 2016, at 10:04, James Reeves  > wrote: 
> > 
> > Clojure seems to avoid having functions that have variable performance 
> depending on the data structure they're applied to. 
>
> But not always! (e.g. count)

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

Re: Are strings vectors? Should 'get' docstring be changed?

[adrian . medina]

That's a good point, but it should be noted that all collections for which 
clojure.core/counted? returns true (they implement clojure.lang.Counted) 
should implement count in constant time. So the design of the Counted 
interface was clearly intended to provide consumers a soft guarantee of 
performance invariability across data structures when necessary.. 

On Thursday, April 21, 2016 at 1:26:26 PM UTC-4, Michael Gardner wrote:
>
> On Apr 21, 2016, at 10:04, James Reeves  > wrote: 
> > 
> > Clojure seems to avoid having functions that have variable performance 
> depending on the data structure they're applied to. 
>
> But not always! (e.g. count)

-- 
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: Recur in an overloaded function does not work?

[adrian . medina]

I don't think you're missing anything James. It does not look like this 
example uses trampoline with the intended effect. 

On Wednesday, April 20, 2016 at 2:45:05 PM UTC-4, James Elliott wrote:
>
> Does trampoline really help in this case? I don’t see where we are ever 
> returning a new function for trampoline to call, avoiding a new stack 
> frame. It seems to me no different than simply calling the other arities 
> directly in this example. What am I missing?
>
> On Wednesday, April 20, 2016 at 12:00:35 PM UTC-5, J.-F. Rompre wrote:
>>
>> You can prevent stack consumption by using trampoline for tail-recursive 
>> calls to a different arity, and recur for same arity, something like:
>>
>> (defn find-comment-in-line
>>
>> ([s] (when (pos? (count s))
>>   (if-let [cs (seq (comment-s? s))]
>>  ;; yes, a comment symbol found,
>>  ;; just return the remainder of a string
>>   (subs s (count (first cs)))
>>
>>  ;; no, lets check for an opening quote
>>
>>   (if-let [qs (seq (quote-s? s))]
>>
>>   ;; yes, an opening quote found,
>>   ;; now go look for an end quote
>>   (trampoline find-comment-in-line (subs s 1) qs)
>>
>>   ;; no, just some other symbol found,
>>   ;; check for the rest
>>   (recur (subs s 1))
>>
>>  ([s q] (when (pos? (count s))
>>  ;; lets check if it is a quote
>>  (if-let [qs (seq (quote-s? s))]
>>
>>  ;; is it a closing quote?
>>  (if (= qs q)
>>;; yes, lets check for the rest
>>(trampoline find-comment-in-line (subs s 1))
>>
>>;; no, just ignore the symbol,
>>;;continue looking for a closing quote
>>(recur (subs s 1) q))
>>
>>
>>
>> On Tuesday, April 19, 2016 at 11:18:40 AM UTC-4, andmed wrote:
>>>
>>> Thank you. That the point. If "recur" binds to fn, why it can not know 
>>> the binding point as the function method based on the number of arguments 
>>> passed to it? I mean it is clear that Clojure can't do that, but I can see 
>>> no reason why it could or should not if we choose to implement such 
>>> syntactic nicety as recur in a function
>>>
>>

-- 
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: Recur in an overloaded function does not work?

[adrian . medina]

Each arity defined for a particular Clojure function is actually a separate 
"method" under the hood for that particular functional instance. `recur` in 
Clojure should be thought of as more like a primitive looping construct 
than a recursive call to some named function.

The documentation for the recur special form explains this in more 
detail: http://clojure.org/reference/special_forms#recur. 

On Monday, April 18, 2016 at 4:16:30 PM UTC-4, andmed wrote:
>
> Hello
>
> I am just a beginner Clojure programmer and I am unhappy with the way 
> recur behaves in Clojure
>
> I have implemented kata from here 
> https://github.com/alvarogarcia7/kata-formulation-find-comments/pull/3
> What it does: it outputs 'comments' (sequences starting with "#" or "//") 
> and ignores 'comments' in quotes
>
> Here is the code:
>
> (def comment-s '("#" "//"))
> (def quote-s '("'" "\""))
>
> (defn comment-s? [s]
>   (filter #(.startsWith s %) comment-s))
>
> (defn quote-s? [s]
>(filter #(.startsWith s %) quote-s))
>
> (defn find-comment-in-line
>   "We implement a FSM via an overloaded function -- when inside a quote, 
> pass two arguments, including opening quote symb, otherwise just one 
> (string itself). Don't know yet hot to recur in an 
> ([s] (when (pos? (count s))
>   (if-let [cs (seq (comment-s? s))]
>   (subs s (count (first cs))) ; yes, a comment symbol found, just 
> return the remainder of a string
>   (if-let [qs (seq (quote-s? s))] ; no, lets check for an opening 
> quote
>   (find-comment-in-line (subs s 1) qs) ; yes, an opening quote 
> found, now go look for an end quote
>   (find-comment-in-line (subs s 1)) ; no, just some other 
> symbol found, check for the rest
>  ([s q] (when (pos? (count s))
>(if-let [qs (seq (quote-s? s))] ; lets check if it is a quote
>  (if (= qs q) ; is it a closing quote?
>(find-comment-in-line (subs s 1)) ; yes, lets check for the rest
>(find-comment-in-line (subs s 1) q)) ; no, just ignore the 
> symbol, continue looking for a closing quote
>
>  My idea was to make it via recur: it does not work however because recur 
> apparently binds to an implementation with particular number of arguments, 
> not to a function call, and I can not see any reason why it would not.
>
> With recur I was getting 
> Caused by: java.lang.IllegalArgumentException: Mismatched argument count 
> to recur, expected: 1 args, got: 2
>
>
> I guess the code is a bit "imperative" and imperative programmer I am. 
> Also, I can make recur work with a nullable argument and a helper function, 
> still... is there any reason Clojure can not bind recur to a function call 
> in accordance with the number of arguments passed?
>
>

-- 
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: Pmap on hash maps

[adrian . medina]

It depends on your specific use case. Sometimes the overhead of parallelism 
overshadows the performance gains. The rule of thumb for any language is to 
first identify bottlenecks in your code through profiling and optimize 
accordingly. 

For a concrete example, a while ago I was created a program with Clojure 
which interprets 3D game assets in one format and re-exports them to 
another format. I needed to run this on thousands of files. After 
profiling, I found that parallelizing the conversion process for one asset 
was a red herring as I could barely saturate one thread before it finished. 
So instead of parallelizing the internals of the conversion process, I 
found it was much more efficient (and less complex) to just run the 
conversion process in parallel on many assets at the same time. This meant 
I could scale the import/export procedure linearly with CPUs, and it was 
incredibly simple to do with Clojure out of the box without increasing the 
complexity of the program at all. 

I know this is a relatively obvious use of parallelism, but my point is 
that while sometimes it's tempting to try to parallelize things all the way 
down my experience has taught me that parallelism is often more important 
at the I/O boundaries of your program, whatever that may be. 

On Sunday, April 17, 2016 at 5:23:32 PM UTC-4, JvJ wrote:
>
> Orders of magnitude?  Is it even worth running things in parallel in this 
> case?
>
> On Sunday, 17 April 2016 07:20:30 UTC-7, tbc++ wrote:
>>
>> The cost of creating that extra collection will be vastly overshadowed by 
>> the cost of running pmap. pmap involves the use of several locks, and 
>> thread co-ordination primitives, these will most likely be orders of 
>> magnitude more expensive than an extra allocation. 
>>
>> Timothy
>>
>> On Sun, Apr 17, 2016 at 12:38 AM, JvJ  wrote:
>>
>>> Perhaps I should have rephrased.  I meant calling it in such a way that 
>>> the result is a hash map.
>>>
>>> I know I could do something like:
>>>
>>> (into a (pmap f a))
>>>
>>> This will give the same result, but there's an extra collection in there 
>>> that I'm not sure is necessary.
>>>
>>>
>>> On Saturday, 16 April 2016 20:15:51 UTC-7, Alex Miller wrote:

 You can call pmap on hash maps!
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post 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] Aleph 0.4.1

[adrian . medina]

Awesome! At Vital Labs we use Aleph in production for our HTTP and (soon to 
be) websocket services. I have nothing but good things to say about it. It 
makes using Netty a breeze in Clojure. 

For an unrelated side project, I have been using Aleph to communicate over 
UDP with an old MMORPG called Star Wars Galaxies. Since UDP is not stream 
oriented, some of the architecture which make Aleph easy to reason about 
through Manifold for HTTP/TCP do not seem to carry over as cleanly when 
dealing with UDP services. 

Would you be open to writing a comprehensive UDP example for Aleph so that 
potential users could see how the author intends such services to be 
written in tandem with your other libraries, namely Manifold, Gloss, and 
byte-streams? 

In particular, SWG uses a convoluted protocol which involves optional XOR 
decryption of the body using an integer exchanged in the first packet you 
see from the game client (and saved for all future communication with the 
client until they go link dead), followed by optional decompression with 
DEFLATE of the body (not the header nor footer) depending on a value in the 
decrypted first byte of the footer, followed by variable-length (opcode 
driven) body decoding. To deal with the problem of unreliable transmission, 
you also need to ack sequenced packets before responding to a specific kind 
of message. Sometimes this needs to be repeated due to loss, etc. To 
respond you also need to invert the decoding process, so compress -> 
encrypt -> etc. 

Here's an overview of the protocol if you're interested in seeing the 
potential complexities that come up with protocols like 
these: http://wiki.swganh.org/index.php/Packet_Guides

Since many of these requirements break the more functional, streaming 
nature of Manifold's design I have found that the code quickly devolves 
into madness. I imagine it would be very enlightening to see how you would 
solve these or similar problems with Aleph. 

Thanks for the great library,
Adrian

On Sunday, April 3, 2016 at 2:44:53 AM UTC-4, Zach Tellman wrote:
>
> This release represents a number of incremental improvements to 0.4.0, 
> which has been handling billions of daily requests for close to a year.  
>
> * Documentation can be found at http://aleph.io/
> * Literate examples of usage can be found at 
> http://aleph.io/aleph/literate.html
> * Comparative benchmarks can be found at 
> https://www.techempower.com/benchmarks/#section=data-r12=peak=plaintext=4,
>  
> which may or may not be relevant to your particular use case
>
> If anyone has questions, I'm happy to answer them.
>

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

Re: [ANN] Predicat 0.2.2

[adrian . medina]

This looks really interesting and useful. Thanks for sharing. Thinking out 
loud, it would be interesting to see these failures integrated with 
something like Probe (https://github.com/VitalLabs/probe), which could not 
only record the failures but also potentially feed them into a monitoring 
system. Also, in tandem with Manifold 
(https://github.com/ztellman/manifold), I could see this greatly aiding 
asynchronous error tracing. 

On Sunday, March 27, 2016 at 8:03:46 PM UTC-4, Sébastien Bocq wrote:
>
> Hi all,
>
> I'm pleased to announce Predicat , a 
> new validation library that permits to create and compose predicate 
> functions whose failures always carry the expression and the input of the 
> predicate that fails.
>
> See readme on github for the motivation examples:
> https://github.com/sbocq/predicat
>
> I hope you find it useful!
>
> Sébastien
>

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

Re: Similar lisps and emacs reimplementations?

[adrian . medina]

Common Lisp is timeless in my opinion. :)

STMX is a high performance STM implementation for Common Lisp. 

https://github.com/cosmos72/stmx

On SBCL it even compiled down as an optimization to Intel TSX assembly 
instructions (which incidentally were disabled by the manufacturer 
unfortunately a couple of years ago due to a major bug; I am not sure if 
they fixed the bug in newer chips yet). In any event, it's still a great 
implementation. 

On Wednesday, March 9, 2016 at 1:43:38 PM UTC-5, Sam Halliday wrote:
>
> Hi all, 
>
> I have been learning clojure as holiday reading (I'm a scala dev and am 
> one of the main authors of ENSIME.org, which brings IDE like support to 
> text editors for Java and Scala). 
>
> Clojure is amazing! I'm really loving learning it. There is so much good 
> stuff in here, plus it's a lisp which is just incredible for me because 
> I've been an Emacs hacker for nearly two decades. 
>
> I've done enough research to know that the clojure licence is off topic 
> and discussions about it make people feel "nauseous", so I'll skip over 
> begging you to change it to MPL or Apache 2.0 and tell you that I cannot 
> use EPL at work. It is blacklisted by many of my customers and the patent 
> retaliation clause gives my legal advisors enough to construct terrifying 
> scenarios that all ended up in the end of my career. Also, I can't add 
> clojure support or use clojure in ENSIME because of the well known GPL / 
> EPL incompatibility. 
>
> So... skipping over that. It seems I can't actually use this beautiful 
> language. But I do a fair bit of emacs-lisp so naturally I'd like to know 
> to what extent the features have been reimplemented? 
>
> I've seen that Emacs 25 is going to have something that looks a bit like 
> destructuring, I've used dash (but there is an idiomatic replacement coming 
> too) and I've seen some "ports" of the threading (I love this macro so 
> much). However direct ports are still subject to the original licence, so 
> it needs to be a clean room implementation (or Rich/the author to release 
> those macros user GPL as an emacs package). 
>
> Is there anything else that is making its way back into Emacs lisp as a 
> result of what has been learnt in Clojure? 
>
> And are there any other lisps which use STM? Emacs is still single 
> threaded so STM is almost useless there. I'd be really interested in a 
> modern lisp with STM and a licence that I could use at work. 
>
> Best regards, 
> Sam

-- 
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: Question concerning eval

[adrian . medina]

You need to quote the entire vector `avec`, because otherwise the function 
you want to bind to `foo` will be evaluated before being evaluated by the 
`let` special operator, which expects only standard readable object 
literals to be embedded.  

Try changing:

(def avec
  ['p   true
  'foo (fn [x] (+ 2 x))])


to:


(def avec
  '[p   true
foo (fn [x] (+ 2 x))])


On Thursday, January 14, 2016 at 5:05:55 AM UTC-5, Burt wrote:
>
> Hi, 
>
> I got an exception using eval and I do not understand why!
> Can anybody explain what happens?
>
> Here is a small piece of code showing the problem:
>
> (defn eval-phi [avec phi]
>   (eval `(let ~avec ~phi)))
>
> ; The idea of eval-phi is the evaluation of
> ; arbitrary lists where the symbols are
> ; defined in avec
>
> ; example:
> ; in avec the symbol p is defined as true
> ; and the symbol foo as a function adding 2
>
> (def avec
>   ['p   true
>   'foo (fn [x] (+ 2 x))])
>
> ; here are two lists
> (def phi '(and p (= 7 (foo 5
> (def psi '(and (not p) (= 7 (foo 5
>
> ; and here their evaluation
> (eval-phi avec phi)
> ; => true
> (eval-phi avec psi)
> ; => false
>
> ; second approach:
> ; the attempt to give the definition of a
> ; function in avec by a function which
> ; returns a function leads to an exception:
>
> (defn make-adder [n]
>   (fn [x] (+ n x)))
>
> ((make-adder 2) 5)
> ; => 7
>
> ; here the second definition of a binding vector:
> (def avec'
>   ['p true
>'foo (make-adder 2)])
>
> (eval-phi avec' phi)
> ; CompilerException java.lang.ExceptionInInitializerError
>
> ; in my mental model of the substitution of symbols by 
> ; their value there should be no difference between the
> ; first approach and the second.
>
> ; Actually avec' contains the function returned by make-adder
> ((nth avec' 3) 5)
> ; => 7
>
> ; Why does avec' leads to an exception?
>
>
> *Kind regards,*
>
> *Burkhardt Renz*
>
>

-- 
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: Primitive pseudocode parser in Clojure

[adrian . medina]

I recommend Instaparse (https://github.com/Engelberg/instaparse) for all of 
your parsing needs. 

On Monday, September 21, 2015 at 12:29:16 PM UTC-4, Vitaliy Vlasov wrote:
>
> Hi all,
>
> I'm happy to write my first post here:) I am writing a mathematical 
> formula parser in Clojure. The formulas need to be written in infix 
> notation and also support some primitive conditional statements (e.g. 
> if-else and case), so that for instance this string would be parsed into a 
> valid Clojure function definition:
>
> if cond-value1
>   v1 * v2 - v3
> else
>   v4 ** 2
>
> The infix part turned out to be very easy thanks to Incanter's infix 
> module (i use eval and Incanters' $=). So right now the system supports 
> formulas without conditionals.
>
> But I'm not sure on how to proceed with the conditional statements parser. 
> Does a generalised approach/library exist on how to approach these kinds of 
> problems? If not, i will implement my own of course.
>
> Thank you!
>

-- 
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 (defn- ...) but (def ^:private? ...)

[adrian . medina]

Reader macros are evaluated at read time, not macroexpansion time. Read 
time happens during reading - the process in which the characters in a file 
are read into the Lisp forms Clojure supports. Therefore ^:private is not 
syntax which can be manipulated in a macro, because by the point the macro 
is evaluated that form is no longer present. 

Check out the source for defn- (you can find it in a REPL by calling 
(clojure.repl/source defn-)

(defmacro defn-
  same as defn, yielding non-public def
  {:added 1.0}
  [name  decls]
  (list* `defn (with-meta name (assoc (meta name) :private true)) decls))

(defmacro def-
  same as def, yielding non-public def
  ([name] `(def- ~name nil))
  ([name expr]
   (list `def (with-meta name (assoc (meta name) :private true)) expr)))
  

On Thursday, May 7, 2015 at 10:12:39 AM UTC-4, Stig Brautaset wrote:

 Is it because the def form can also be ^:dynamic?

 At any rate, I did an attempt at my first macro to create a (def- ...) 
 form, but it doesn't seem to work. Can you not attach metadata in a macro?

 (defmacro def-
   Why (defn- private-fn ...) but (def ^:private var ...)?
   [sym  body]
   `(def ^:private ~sym ~@body))

 ;; = #'user/def-
 user (macroexpand '(def- blah foo bar quux))
 ;; = (def blah foo bar quux)

 Stig


-- 
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: moving from core.async/reduce to transducers

[adrian . medina]

It will act exactly like transduce if you put a transducer on the input 
channel. 

On Wednesday, May 6, 2015 at 12:26:55 PM UTC-4, Pierre-Yves Ritschard wrote:

 Hi clojure,

 There's a thing I find myself doing often in some of my projects where 
 I reduce over a core.async channel this way:

 (core.async/reduce update-fn init-state input-channel)

 By doing this on a stream of inbound events.
 When looking at doing this with transducers, it's a bit unclear how to fit
 the fact that I'm not doing any modification on the input-channel, do you 
 usually just use identity there ?

 (transduce update-fn identity init-state input)

 Moving to a transducer based approach is tempting, especially since it 
 would allow for a simpler REPL-based workflow, but I want to make sure I 
 get this right.

 Cheers!



-- 
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: Metadata loss. What am I doing wrong?

[adrian . medina]

Because ' is a reader macro which expands to the list (quote some-symbol), 
so the metadata is applied to the list, and not the symbol. You can verify 
this in the REPL - (meta (quote ^:abc 'some-symbol))

On Tuesday, May 5, 2015 at 5:43:19 PM UTC-4, Andy- wrote:

 Frankly, I would've (meta ^:abc 'some-symbol) expected to work. Maybe 
 somebody else can weigh in on why this one is a no-go.

 On Tuesday, May 5, 2015 at 5:01:19 PM UTC-4, Andrey Antukh wrote:

 Thanks to both for the responses, but I stil not clearly understand.

 The documentation says very clearly that:

 In addition to with-meta, there are a number of reader macros (The 
 Reader: Macro Characters) for applying metadata to the expression following 
 it:
 ^{:doc How obj works!} obj - Sets the metadata of obj to the provided 
 map.
 Equivalent to (with-meta obj {:doc How obj works!})


 (def foo ^:abc [1 2 3]) - (meta foo) - {:abc true}
 (def foo ^:abc some-func) - (meta foo) - nil
 (def foo ^:abc 'some-symbol) - (meta foo) - nil (In clojure 
 programming book uses example attaching metadata using the reader to the 
 symbol, but seems it not works as expected)

 Is a little bit confusing. The metadata documentation says clearly that 
 are equivalent, but are not equivalent.


 Thank you very much again.

 Regards.
 Andrey

 2015-05-05 21:49 GMT+02:00 Andy- andre...@gmail.com:

 In addition to James comment: IMO clojure.org/metadata should be 
 clearer about this. It's mentioned more clearly on the reader page:
 http://clojure.org/reader#The%20Reader--Macro%20characters
 The metadata reader macro first reads the metadata and attaches it to 
 the next form read (see with-meta 
 http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/with-meta
  to 
 attach meta to an object):

 Stress on *next form read*.

 On Tuesday, May 5, 2015 at 2:31:40 PM UTC-4, Andrey Antukh wrote:

 Hi!

 I have some trouble with clojure metadata / reader and I do not know if 
 I'm doing something wrong.

 I have this code:

 (defn some-func [])

 (def func ^:abc some-func)

 (assert (= (meta func) {:abc true}))

 (def data [[:bar (with-meta some-func {:abc true})]
[:baz ^:abc some-func]])

 (assert (= (meta (get-in data [0 1])) {:abc true}))
 (assert (= (meta (get-in data [1 1])) {:abc true}))

 It fails in the first assert and in the last (if I comment the first 
 one obviously). I do not understand why that form of metadata does not 
 works
 as I expect (http://clojure.org/metadata)

 Thank you very much.

 Regards.
 Andrey

 -- 
 Andrey Antukh - Андрей Антух - andrei@kaleidos.net / 
 ni...@niwi.be
 http://www.niwi.be http://www.niwi.be/page/about/
 https://github.com/niwibe
  



 -- 
 Andrey Antukh - Андрей Антух - andrei@kaleidos.net / ni...@niwi.be
 
 http://www.niwi.be http://www.niwi.be/page/about/
 https://github.com/niwibe
  


-- 
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} Aleph 0.4.0 released, plus Manifold, Dirigiste, and a whole host of other libraries

[adrian . medina]

You really hit the ball out of the park with Aleph 0.4.0's API. You have 
set the standard for simplicity and power in a Clojure API with this 
release as far as I'm concerned. Thank for your your contribution! 

On Friday, April 17, 2015 at 5:06:30 PM UTC-4, Zach Tellman wrote:

 Hey all,

 In preparation for Clojure/West, I'm formally releasing the latest Aleph 
 and the libraries that surround it.  Aleph 0.4.0 has been running in 
 production at Factual for half a year now, and across a variety of services 
 is handling at peak 600k HTTP requests/sec (spread across 15-20 machines).  

 Since the landscape of Clojure HTTP servers is pretty crowded these days, 
 it's worth taking some time to explain how Aleph differs.  To be clear, 
 most Clojure deployments likely use Jetty, and should continue to do so. 
  However, Aleph has some unique properties:

 * It uses the Netty library, which is a high-performance and very 
 battle-tested network layer for the JVM
 * It is the only HTTP server that has *ubiquitous* asynchronous streams 
 wherever data can be received or sent (all other libraries can only 
 represent streaming requests using InputStreams, or like http-kit don't 
 support streaming HTTP requests at all)
 * It is the only server that has a WebSocket implementation with any 
 support for per-connection backpressure.  I won't make this post even 
 longer by going into why this is important, but this will be a central 
 theme of my talk at Clojure/West next week if you're interested in hearing 
 more.
 * It uses consistent abstractions to represent network connections over a 
 variety of protocols, which makes it straightforward to use the same 
 application logic for all of them.

 Again, none of these points mean you should immediately drop whatever 
 you're using and move over to Aleph instead.  However, I do feel it 
 represents the only (current) good option for using core.async or a similar 
 stream abstraction to represent network data, which is an idea a number of 
 people seem to be playing with lately.  Some examples of this can be found 
 at http://ideolalia.com/aleph/literate.html.

 A full list of the libraries:

 aleph - https://github.com/ztellman/aleph - uses the excellent Netty 
 library to expose HTTP, TCP, and UDP using a consistent asynchronous stream 
 representation.

 manifold - https://github.com/ztellman/manifold - an unopinionated stream 
 representation designed to cleanly interoperate with other stream 
 representations (Clojure's seqs, core.async channels, Java's 
 BlockingQueues, and others).  This is the base stream representation for 
 all network sources and sinks in Aleph.

 dirigiste -  https://github.com/ztellman/dirigiste - a pure-Java library 
 that provides instrumented, dynamically sized thread and object pools. 
  This is used for thread pools in Aleph's HTTP server, and for connection 
 pools in Aleph's HTTP client.

 byte-streams -  https://github.com/ztellman/byte-streams - a means of 
 translating any byte representation into another.  Want to turn a 
 core.async channel that emits byte-arrays into an InputStream, or maybe the 
 other way around?  Look no further.  The library's conversion mechanism is 
 extensible, which is used in Aleph to make Netty's custom byte 
 representations interoperable with more familiar representations.

 byte-transforms -  https://github.com/ztellman/byte-transforms - a 
 curated collection of byte compression, hashing, and encoding mechanisms, 
 which can work on anything byte-streams can convert.

 While all these libraries are used in concert to create Aleph, I've been 
 very careful to make sure any of them can be used by themselves.  If anyone 
 has questions about them, the best place to get my attention is the Aleph 
 mailing list: https://groups.google.com/forum/#!forum/aleph-lib.

 I will be mentioning some of these libraries at my upcoming Clojure/West 
 talk (http://clojurewest.org/speakers#ztellman), but I've also set aside 
 an Unsession for specifically discussing these libraries: 
 https://github.com/clojurewest/clojurewest2015/wiki/Unsessions.  If 
 you're interested, please add your name to the list.

 Zach


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

Re: Composing Stuart Sierra's components

[adrian . medina]

I believe I misunderstood your question; I didn't realize it was system (as 
opposed to any general component) specific. I think systems can be merged 
together (via 'merge'). Would that help? 

On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:

 Hi Adrian - I don't follow how that helps integrate two different 
 systems - I wonder if my question was unclear or I am missing 
 something in your answer. Would you mind posting some pseudo code to 
 clarify please? 

 On 11 March 2015 at 18:32,  adrian...@mail.yu.edu javascript: wrote: 
  You can specify component dependencies using the 'using' function as you 
  know. As long as you know the key of the component in the system you can 
  specify this dependency wherever you construct the component. If you 
 want to 
  parameterize dependencies, write a constructor function which takes the 
  external dependency as a value. 
  
  On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote: 
  
  I have a non-trivial component which requires a bunch of internal and 
  external collaborators to work. This component is itself re-usable. 
  
  What I really want to do is have ReusableComponent be a component in a 
  system so it can pull its external collaborators. However, 
 ReusableComponent 
  constructs its own services etc. so it really want to be (or at least 
 have 
  access to) a system. 
  
  For example, let's say I have the following: 
  
  (defrecord InternalToReusableComponent [bus] 
(component/Lifecycle 
  (start [this]...)) 
  
  (defrecord ReusableComponent [bus logger] 
(component/Lifecycle 
  (start [this] 
  
this) 
  )) 
  
  (defn reusable-component-system [external-collaborator] 
(component/system-map 
  :bus () 
  :logger () 
  :reusable-component (component/using (map-ReusableComponent {}) 
 [:bus 
  :logger external-collaborator])) 
  
  Fine - I now have a system from which I can pull the reusable 
 component. 
  However, where does 'external-collaborator' come from? Obviously there 
 is a 
  larger system which I want this component to be part of so I can do: 
  
  (defn larger-system [] 
(component/system-map 
   :external-collaborator (...) 
   :reusable-component (component/using (some-magic-glue) 
  [:external-collaborator]))) 
  
  I am struggling to see what (some-magic-glue) should be. I imagine it 
  needs to be something like: 
  
  (defrecord SystemAdaptor [external-collaborator internal-system] 
component/Lifecycle 
(start [this] 
  (let [internal-system (or internal-system 
 (reusable-component-system 
  external-collaborator)) 
 internal-system (component/start internal-system)] 
   (assoc this :internal-system internal-system))) 
(stop [this] 
  (let [internal-system (:internal-system this) 
 internal-system (component/stop internal-system] 
   (assoc this :internal-system internal-system))) 
  
  but it all feels a bit yuck. 
  
  I can't merge the two systems because the reusable component is chocka 
  full of very fine grained command handlers and both the internal and 
  external systems will have their own 'bus' for example. I could 
 namespace 
  the keys but that again feels painful... 
  
  Hope that is clear - and I look forward to your thoughts :). 
  
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.com 
 javascript: 
  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 javascript: 
  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 javascript:. 
  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: Composing Stuart Sierra's components

[adrian . medina]

You can specify component dependencies using the 'using' function as you 
know. As long as you know the key of the component in the system you can 
specify this dependency wherever you construct the component. If you want 
to parameterize dependencies, write a constructor function which takes the 
external dependency as a value. 

On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:

 I have a non-trivial component which requires a bunch of internal and 
 external collaborators to work. This component is itself re-usable. 

 What I really want to do is have ReusableComponent be a component in a 
 system so it can pull its external collaborators. However, 
 ReusableComponent constructs its own services etc. so it really want to be 
 (or at least have access to) a system.

 For example, let's say I have the following:

 (defrecord InternalToReusableComponent [bus]
   (component/Lifecycle
 (start [this]...))

 (defrecord ReusableComponent [bus logger]
   (component/Lifecycle
 (start [this]
   
   this)
 ))

 (defn reusable-component-system [external-collaborator]
   (component/system-map
 :bus ()
 :logger ()
 :reusable-component (component/using (map-ReusableComponent {}) [:bus 
 :logger external-collaborator]))

 Fine - I now have a system from which I can pull the reusable component. 
 However, where does 'external-collaborator' come from? Obviously there is a 
 larger system which I want this component to be part of so I can do:

 (defn larger-system []
   (component/system-map
  :external-collaborator (...)
  :reusable-component (component/using (some-magic-glue) 
 [:external-collaborator])))

 I am struggling to see what (some-magic-glue) should be. I imagine it 
 needs to be something like:

 (defrecord SystemAdaptor [external-collaborator internal-system]
   component/Lifecycle
   (start [this]
 (let [internal-system (or internal-system (reusable-component-system 
 external-collaborator))
internal-system (component/start internal-system)]
  (assoc this :internal-system internal-system)))
   (stop [this]
 (let [internal-system (:internal-system this)
internal-system (component/stop internal-system]
  (assoc this :internal-system internal-system)))

 but it all feels a bit yuck.

 I can't merge the two systems because the reusable component is chocka 
 full of very fine grained command handlers and both the internal and 
 external systems will have their own 'bus' for example. I could namespace 
 the keys but that again feels painful...

 Hope that is clear - and I look forward to your thoughts :).


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

Re: [ANN] Dunaj project, an alternative core API for Clojure

[adrian . medina]

Not sure exactly how to properly express my impression here, but it strikes 
me as odd that this project would not come out of direct collaboration with 
Clojure's core contributors. Proposed features should probably go through 
the official channels if you are serious about getting them included in the 
language. 

On Thursday, March 5, 2015 at 4:33:53 PM UTC-5, Jozef Wagner wrote:

 I'm happy to announce a project called Dunaj [1], which provides an 
 alternative core API for Clojure. Its main aim is to experimentally test 
 major additions to the language. 

 Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve 
 Clojure language and its core API. It deals with language features that 
 require changes across different parts of Clojure and which cannot be 
 evaluated in isolation. Dunaj aims to bring Clojure even more towards 
 simplicity, consistency and performance. 
 It is intended to be used by regular Clojure developers, either for 
 application or library development.

 Dunaj was created to test 10 experiments that bring significant changes to 
 the Clojure language. As there is a substantial number of additions and 
 changes, I want to try a bit unconventional approach here. Before I'll 
 release the actual library, I will introduce Dunaj's experiments in a 
 series of individual posts. Every part states the motivation behind the 
 experiment, introduces changes and additions to the language and 
 demonstrates its intended use. If you do not want to miss any of this, you 
 may want to register for a mailing list at [1] or follow @dunajproject at 
 Twitter.

 -- Jozef Wagner

 [1] http://www.dunaj.org/ 



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

Re: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?

[adrian . medina]

Having never used Spring (or anything else resembling the style of code you 
presented) I don't really know if I'm understanding what you're asking. 

However, it might be useful to wrap your database in a component. I do this 
for Datomic all of the time, and the boilerplate looks something like this: 
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure exactly 
how this would fit into JDBC, but I'm sure you can figure it out if you 
think it would be worthwhile. 

I then pass the database component to any other component in my system that 
I know will make use of it. If used in a middleware-like scenario (where an 
arbitrary function is passed to the component, possibly composed with other 
functions, and invoked elsewhere), I usually have a convention where I pass 
a map of options as an argument to the handler, and make the database a 
value in that map.

On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:

 Hi,

 I am looking for the Clojure equivalent of:

 class Whatever {
 @Transactional
 void doSomething(IDoSomething one, IDoSomethingElse two) {
   one.doSomething()
   two.doSomething()
 }
 }

 where both one and two are dependency injected with a proxy which resolves 
 to a thread local database connection. In addition, one might itself have a 
 collaborator which itself has a collaborator which needs a datasource.

 So far I have two protocols:

 (defprotocol IDoSomething
  (do-something [this ...])

 (defprotocol IDoSomethingElse
  (do-something [this ...])

 Each protocol may have a number of implementations, one of which is a JDBC 
 implementation:

 (defrecord JdbcIDoSomething [db]
   (do-something [this ...] ...))

 The problem is that the calling code only gets provided an IDoSomething 
 and an IDoSomethingElse and it wants to do something like:

 (let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
   (with-transaction [tx db]
 (do-something one)
 (do-something-else two)))

 The problem here is that the implementations of do-something and 
 do-something-else won't have access to the local bound 'tx', they will have 
 their own 'db'.

 I realise the general argument is to be explicit and pass a db as the 
 first argument to the protocol but this isn't appropriate in this case as 
 there are validly multiple implementations. I could abstract a 
 'unit-of-work' and pass that as the first argument to the protocols but 
 that seems a bit painful.

 Also, these protocols may be used quite far away from where the database 
 code lives and passing a parameter all the way through the call stack is 
 painful.

 I am using Stuart Sierra's components if that makes any difference.

 I can't be the first person to run into this but google is surprisingly 
 unhelpful which makes me think I have missed something fundamental, and 
 that I have something upside down.

 What do you all do?




-- 
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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?

[adrian . medina]

Ah I think I understand now! Is it possible to dereference the connection 
and hold on to the thread local state? If so, then dynamically binding 
the transactional connection and doing all of your work within that context 
might be a good solution. You can also write a macro to do this, 
closing/doing cleanup of the connection before exiting the dynamic scope of 
your transaction. 

On Wednesday, March 4, 2015 at 1:15:02 PM UTC-5, Colin Yates wrote:

 Hi Adrian, and thanks for replying. 

 I understand your point, but the subtlety is that a transactional 
 connection is per function invocation where as the database component 
 is per Component lifecycle - passing the db around isn't sufficient 
 here. 

 Spring plumbing binds a transactional connection to a thread local and 
 then passes a connection proxy around - accessing that proxy magically 
 (through the use of the lovely AOP) resolves to the current 
 thread-local transactional connection. 

 I don't see any option other than to re-implement that in Clojure or 
 pass an explicit 'unit-of-work' around but it all feels wrong in 
 Clojure. 

 The problem at the moment is that the implementation of each protocol 
 will execute in separate transactions. 




 On 4 March 2015 at 18:06,  adrian...@mail.yu.edu javascript: wrote: 
  Having never used Spring (or anything else resembling the style of code 
 you 
  presented) I don't really know if I'm understanding what you're asking. 
  
  However, it might be useful to wrap your database in a component. I do 
 this 
  for Datomic all of the time, and the boilerplate looks something like 
 this: 
  https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure 
 exactly 
  how this would fit into JDBC, but I'm sure you can figure it out if you 
  think it would be worthwhile. 
  
  I then pass the database component to any other component in my system 
 that 
  I know will make use of it. If used in a middleware-like scenario (where 
 an 
  arbitrary function is passed to the component, possibly composed with 
 other 
  functions, and invoked elsewhere), I usually have a convention where I 
 pass 
  a map of options as an argument to the handler, and make the database a 
  value in that map. 
  
  
  On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote: 
  
  Hi, 
  
  I am looking for the Clojure equivalent of: 
  
  class Whatever { 
  @Transactional 
  void doSomething(IDoSomething one, IDoSomethingElse two) { 
one.doSomething() 
two.doSomething() 
  } 
  } 
  
  where both one and two are dependency injected with a proxy which 
 resolves 
  to a thread local database connection. In addition, one might itself 
 have a 
  collaborator which itself has a collaborator which needs a datasource. 
  
  So far I have two protocols: 
  
  (defprotocol IDoSomething 
   (do-something [this ...]) 
  
  (defprotocol IDoSomethingElse 
   (do-something [this ...]) 
  
  Each protocol may have a number of implementations, one of which is a 
 JDBC 
  implementation: 
  
  (defrecord JdbcIDoSomething [db] 
(do-something [this ...] ...)) 
  
  The problem is that the calling code only gets provided an IDoSomething 
  and an IDoSomethingElse and it wants to do something like: 
  
  (let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)] 
(with-transaction [tx db] 
  (do-something one) 
  (do-something-else two))) 
  
  The problem here is that the implementations of do-something and 
  do-something-else won't have access to the local bound 'tx', they will 
 have 
  their own 'db'. 
  
  I realise the general argument is to be explicit and pass a db as the 
  first argument to the protocol but this isn't appropriate in this case 
 as 
  there are validly multiple implementations. I could abstract a 
  'unit-of-work' and pass that as the first argument to the protocols but 
 that 
  seems a bit painful. 
  
  Also, these protocols may be used quite far away from where the 
 database 
  code lives and passing a parameter all the way through the call stack 
 is 
  painful. 
  
  I am using Stuart Sierra's components if that makes any difference. 
  
  I can't be the first person to run into this but google is surprisingly 
  unhelpful which makes me think I have missed something fundamental, and 
 that 
  I have something upside down. 
  
  What do you all do? 
  
  
  -- 
  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 
 javascript: 
  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 javascript: 
  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 

Re: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?

[adrian . medina]

(if it's just a regular ThreadLocal, you should be able to get its value 
through (.get tx))

To elucidate briefly, I mean something like this: 

(def ^:dynamic *tx*)

;; elsewhere
(binding [*tx* (.get tx)]
   ...do stuff
   ...cleanup)

a with-tx macro would make this pattern reusable throughout your code. 

On Wednesday, March 4, 2015 at 1:43:36 PM UTC-5, adrian...@mail.yu.edu 
wrote:

 Ah I think I understand now! Is it possible to dereference the connection 
 and hold on to the thread local state? If so, then dynamically binding 
 the transactional connection and doing all of your work within that context 
 might be a good solution. You can also write a macro to do this, 
 closing/doing cleanup of the connection before exiting the dynamic scope of 
 your transaction. 

 On Wednesday, March 4, 2015 at 1:15:02 PM UTC-5, Colin Yates wrote:

 Hi Adrian, and thanks for replying. 

 I understand your point, but the subtlety is that a transactional 
 connection is per function invocation where as the database component 
 is per Component lifecycle - passing the db around isn't sufficient 
 here. 

 Spring plumbing binds a transactional connection to a thread local and 
 then passes a connection proxy around - accessing that proxy magically 
 (through the use of the lovely AOP) resolves to the current 
 thread-local transactional connection. 

 I don't see any option other than to re-implement that in Clojure or 
 pass an explicit 'unit-of-work' around but it all feels wrong in 
 Clojure. 

 The problem at the moment is that the implementation of each protocol 
 will execute in separate transactions. 




 On 4 March 2015 at 18:06,  adrian...@mail.yu.edu wrote: 
  Having never used Spring (or anything else resembling the style of code 
 you 
  presented) I don't really know if I'm understanding what you're asking. 
  
  However, it might be useful to wrap your database in a component. I do 
 this 
  for Datomic all of the time, and the boilerplate looks something like 
 this: 
  https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure 
 exactly 
  how this would fit into JDBC, but I'm sure you can figure it out if you 
  think it would be worthwhile. 
  
  I then pass the database component to any other component in my system 
 that 
  I know will make use of it. If used in a middleware-like scenario 
 (where an 
  arbitrary function is passed to the component, possibly composed with 
 other 
  functions, and invoked elsewhere), I usually have a convention where I 
 pass 
  a map of options as an argument to the handler, and make the database a 
  value in that map. 
  
  
  On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote: 
  
  Hi, 
  
  I am looking for the Clojure equivalent of: 
  
  class Whatever { 
  @Transactional 
  void doSomething(IDoSomething one, IDoSomethingElse two) { 
one.doSomething() 
two.doSomething() 
  } 
  } 
  
  where both one and two are dependency injected with a proxy which 
 resolves 
  to a thread local database connection. In addition, one might itself 
 have a 
  collaborator which itself has a collaborator which needs a datasource. 
  
  So far I have two protocols: 
  
  (defprotocol IDoSomething 
   (do-something [this ...]) 
  
  (defprotocol IDoSomethingElse 
   (do-something [this ...]) 
  
  Each protocol may have a number of implementations, one of which is a 
 JDBC 
  implementation: 
  
  (defrecord JdbcIDoSomething [db] 
(do-something [this ...] ...)) 
  
  The problem is that the calling code only gets provided an 
 IDoSomething 
  and an IDoSomethingElse and it wants to do something like: 
  
  (let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)] 
(with-transaction [tx db] 
  (do-something one) 
  (do-something-else two))) 
  
  The problem here is that the implementations of do-something and 
  do-something-else won't have access to the local bound 'tx', they will 
 have 
  their own 'db'. 
  
  I realise the general argument is to be explicit and pass a db as the 
  first argument to the protocol but this isn't appropriate in this case 
 as 
  there are validly multiple implementations. I could abstract a 
  'unit-of-work' and pass that as the first argument to the protocols 
 but that 
  seems a bit painful. 
  
  Also, these protocols may be used quite far away from where the 
 database 
  code lives and passing a parameter all the way through the call stack 
 is 
  painful. 
  
  I am using Stuart Sierra's components if that makes any difference. 
  
  I can't be the first person to run into this but google is 
 surprisingly 
  unhelpful which makes me think I have missed something fundamental, 
 and that 
  I have something upside down. 
  
  What do you all do? 
  
  
  -- 
  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 

Re: Comparison with atom values

[adrian . medina]

You must deref (https://clojuredocs.org/clojure.core/deref) reference 
values to get the data inside of it.

(= @a 0) 

is the same as saying

(= (deref a) 0)

Hope this helps!

On Thursday, February 12, 2015 at 2:27:39 PM UTC-5, Newbie wrote:

 I am trying to compare atom values with numbers. For e.g. - 

 (def a (atom 0))
 (print a) gives -- #Atom@2bcca11e: 0
 (= a 0) gives -- false

 How do I make this work? How do I compare 0 with the atom value? I want to 
 do the same for a string to?
 I cannot use compare-and-set! for my situation.

 Thanks!


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

Re: Architectural doubts

[adrian . medina]

If you're interested in efficient binary decoding/encoding with a more 
pleasant API than standard NIO ByteBuffers, check out Netty's buffer 
package, io.netty.buffer (http://netty.io/5.0/api/index.html). 

On Sunday, February 1, 2015 at 7:31:37 AM UTC-5, Milton Silva wrote:

 For now I'm hand coding a big loop with transients and a bytebuffer. It is 
 an incredibly ugly imperative mess but, it is fast enough and so far it 
 fits nicely into ram.
 It takes 2s (at this point gloss was taking upwards of 5 minutes) to 
 decode 200MB all the way to tcp and uses 500MB of heap. This is faster than 
 wireshark(10s) but a bit more memory hungry. Will see how it responds when 
 decoding diameter, so far that part is stored as byte-arrays.

 Thank you for the pointers with datomic. Are the indexes created 
 automatically or do I need to specify them on the schema?

  

-- 
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: When to use metadata

[adrian . medina]

To be clear, I actually agree with Stuart. I would really like to dig into 
this topic and hear everyones thoughts on this; it's such a large piece of 
Clojure's private and public API. 

On Friday, January 30, 2015 at 1:53:37 PM UTC-5, adrian...@mail.yu.edu 
wrote:

 Metadata fields proliferate throughout the standard Clojure value and 
 reference types. It seems odd that one would suggest that this seemingly 
 well supported feature should not be taken advantage of except in very 
 narrow circumstances. What is the rationale for such robust support for 
 runtime metadata if their usage should be restricted primarily to 
 compile-time or metaprogramming tasks? If that was the primary purpose, 
 certainly a Common Lisp proclaim/declaim/declare-esque expression would be 
 preferable since then the compiler and macros can take advantage of this 
 information when reading forms without having to extract data out of 
 symbols on an ad-hoc basis. It makes me think maybe we're missing the point 
 here. Rich Hickey clearly carefully designed Clojure to support varied uses 
 of runtime metadata on Clojure objects. 

 On Friday, January 30, 2015 at 1:28:04 PM UTC-5, Stuart Sierra wrote:

 Almost never.

 Seriously, anything important enough to be included in your program's 
 input or output is almost certainly important enough to be *data*, not 
 metadata. And the non-equality-checking semantics of metadata are confusing.

 About the only place I've found metadata to be worthwhile is 
 meta-programming namespaces and Vars, e.g. what clojure.test does.

 My personal rule of thumb is: if you strip all the metadata from your 
 program it should still work, thought maybe less efficiently.

 –S


 On Thursday, January 29, 2015 at 10:10:34 AM UTC-5, Jonathon McKitrick 
 wrote:

 Is there a rule of thumb or set of use cases when metadata is a more 
 elegant solution than simply adding more entries to a map or record?



-- 
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: When to use metadata

[adrian . medina]

Metadata fields proliferate throughout the standard Clojure value and 
reference types. It seems odd that one would suggest that this seemingly 
well supported feature should not be taken advantage of except in very 
narrow circumstances. What is the rationale for such robust support for 
runtime metadata if their usage should be restricted primarily to 
compile-time or metaprogramming tasks? If that was the primary purpose, 
certainly a Common Lisp proclaim/declaim/declare-esque expression would be 
preferable since then the compiler and macros can take advantage of this 
information when reading forms without having to extract data out of 
symbols on an ad-hoc basis. It makes me think maybe we're missing the point 
here. Rich Hickey clearly carefully designed Clojure to support varied uses 
of runtime metadata on Clojure objects. 

On Friday, January 30, 2015 at 1:28:04 PM UTC-5, Stuart Sierra wrote:

 Almost never.

 Seriously, anything important enough to be included in your program's 
 input or output is almost certainly important enough to be *data*, not 
 metadata. And the non-equality-checking semantics of metadata are confusing.

 About the only place I've found metadata to be worthwhile is 
 meta-programming namespaces and Vars, e.g. what clojure.test does.

 My personal rule of thumb is: if you strip all the metadata from your 
 program it should still work, thought maybe less efficiently.

 –S


 On Thursday, January 29, 2015 at 10:10:34 AM UTC-5, Jonathon McKitrick 
 wrote:

 Is there a rule of thumb or set of use cases when metadata is a more 
 elegant solution than simply adding more entries to a map or record?



-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[adrian . medina]

Ditto to the others. This looks great, and I have a lot of core.matrix 
compatible code I'd love to test it out against! Thanks for releasing this! 

On Tuesday, January 13, 2015 at 5:07:51 PM UTC-5, Sam Raker wrote:

 I'd like to politely add to the calls for this to become a pluggable 
 core.matrix backend.

 On Tuesday, January 13, 2015 at 4:38:22 PM UTC-5, Dragan Djuric wrote:

 It would be nice if that would be that easy. However, I am sceptical...

 On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.



-- 
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] dformat 0.1.0

[adrian . medina]

It seems so obvious in retrospect... :) Good job. 

On Monday, January 12, 2015 at 4:43:08 PM UTC-5, zirkonit wrote:

 A tiny library, my first open-source Clojure release. Removes some 
 head-scratching when formatting dates (is it  or ? or YYY?) by 
 building date format strings automatically based on a sample. For example:

 (dformat date March 1, 1999)   ;; June 9, 2011
 (dformat date Jan 1, 1999) ;; Jun 9, 2011
 (dformat date Jan 01)  ;; Jun 09
 (dformat date Sunday, May 1, 2000) ;; Thursday, June 9, 2011
 (dformat date Sun Aug 5)   ;; Thu Jun 9
 (dformat date 12/31/99);; 06/09/11
 (dformat date DOB: 12/31/2000) ;; DOB: 06/09/2011
 (dformat date March 15, 1999)  ;; June 09, 2011


 https://github.com/zirkonit/dformat

 All comments are welcome!


-- 
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] Clojure 1.7.0-alpha5 now available

[adrian . medina]

For my projects swapping 1.7.0-alpha4 - alpha5 has not culminated in any 
abnormalities. So... looking good thus far on my end. 

On Sunday, January 11, 2015 at 11:45:50 AM UTC-5, Plinio Balduino wrote:

 Hi there, Alex and Clojure team

 Is there a planned date for the stable version release?

 Regards

 Plínio

 On Sun, Jan 11, 2015 at 12:34 PM, Alex Miller al...@puredanger.com 
 javascript: wrote:

 I would greatly appreciate hearing any feedback about this (or any other) 
 alpha, even if it's just: everything looks ok.

 We've had a couple of regressions reported and that is hugely helpful as 
 we can quickly turn around fixes for the next one.

 Interested particularly in: regressions, performance +/-, and for this 
 alpha, AOT.

 --
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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: how do you name your protocols?

[adrian . medina]

You're overlooking the fact that a service provider interface is simply 
enterprise design pattern jargon for a subset of public APIs that expose 
the underlying interfaces of the library to consumers. Saying that Rich is 
saying protocols should never ever be part of the public API is both 
misleading and false. 

On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote:

 Protocols should never ever be part of public API. Protocols can be part 
 of the SPI, if custom extensions are to be supported. Otherwise they are an 
 implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968

 Jozef

 On Sun, Dec 28, 2014 at 8:11 AM, Mikera mike.r.an...@gmail.com 
 javascript: wrote:

 That depends if the protocols are part of your user-facing API or not - a 
 lot of the time I find that protocols are best hidden as implementation 
 details rather than exposed to users.

 In core.matrix, for example, users never see the protocols directly: only 
 implementers of new matrix libraries need to care

 On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:

 Changing old protocol names should trigger a major revision change in 
 the minimum because it breaks backwards compatibility. 

 --Ashton 

 Sent from my iPhone 

  On Dec 27, 2014, at 11:18 AM, Michael Klishin michael@gmail.com 
 wrote: 
  
  On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) 
 wrote: 
  clj-time seems to be naming protocols inconsistently. It uses   
  ISomething, Something and SomethingProtocol naming. 
  
  I suspect it is because it has 60 contributors and most users never 
 have to 
  extend the protocols. 
  
  Feel free to submit a PR that standardises all names on Something. 
  --   
  @michaelklishin, github.com/michaelklishin 
  
  -- 
  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: :keys and :or destructuring where defaults refer to one another

[adrian . medina]

Whenever you want to get insight in how a macro is rewriting your code, try 
evaluating your form quoted with macroexpand. 

Here's a gist with the macroexpansion each form. 

https://gist.github.com/aamedina/542b084d31d4e0c9a7a8

Hopefully the expansion makes things clear! 

On Thursday, December 11, 2014 6:11:59 PM UTC-5, Michael Blume wrote:

 If I make my defaults on a :keys :or destructuring depend on the values of 
 other keys, I *can* get a compile-time error, depending on what order I 
 give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727

 Is this on-spec behavior? Should the former be allowed but not the latter? 
 Should both be allowed? Should neither?


-- 
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: :keys and :or destructuring where defaults refer to one another

[adrian . medina]

Common Lisp has a really well thought approach to parameter lambda lists. 
If you feel strongly about resolving this ambiguity and enforcing 
consistency around sequential binding in the destructuring syntax, perhaps 
that would be a good place to root a design you can flesh out in Jira. 
Here's a resource you might find interesting as a starting 
point: http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm

On Thursday, December 11, 2014 11:55:36 PM UTC-5, Michael Blume wrote:

 Yep, I spent some time playing with the macro and the macroexpand. It 
 looks like

 a) it only works if the dependent keys come *before* the keys they depend 
 on (ie the opposite of how you'd order, say, defs)

 b) this ordering arises entirely from the seq ordering of 
 PersistentArrayMap (keys are stuck into the map here 
 https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4083
  
 and taken out again here 
 https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4090
 )

 The latter makes it pretty clear that this is accidental behavior and, as 
 you say, shouldn't be relied on -- in particular, if you have more than 
 about 8 keys, you spill over to a PersistentHashMap and get everything in a 
 random order and it almost certainly fails.

 The trouble is this behavior is already used by ring-middleware-format, 
 which then fails to compile if clojure uses a different implementation for 
 small maps.

 I'm wondering if given the brittleness of this behavior we should make 
 sure it can't be used in future versions of clojure.

 On Thu Dec 11 2014 at 6:56:22 PM adrian...@mail.yu.edu javascript: 
 wrote:

 Whenever you want to get insight in how a macro is rewriting your code, 
 try evaluating your form quoted with macroexpand. 

 Here's a gist with the macroexpansion each form. 

 https://gist.github.com/aamedina/542b084d31d4e0c9a7a8

 Hopefully the expansion makes things clear! 

 On Thursday, December 11, 2014 6:11:59 PM UTC-5, Michael Blume wrote:

 If I make my defaults on a :keys :or destructuring depend on the values 
 of other keys, I *can* get a compile-time error, depending on what order I 
 give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727

 Is this on-spec behavior? Should the former be allowed but not the 
 latter? Should both be allowed? Should neither?

  -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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] async-sockets - work with sockets using core.async channels

[adrian . medina]

Check out https://github.com/halgari/com.tbaldridge.hermod for an 
interesting take on this. 

On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:

  BTW, is there any network based core.async channel available now?

 On 10/08/2014 04:36 AM, adrian...@mail.yu.edu javascript: wrote:
  
  It's not about 'safety' (depending on what that means in this context), 
 but as Zach pointed out, if you aren't careful about backpressure you can 
 run into performance bottlenecks with unrestrained async IO operations 
 because although they let you code as if you could handle an unlimited 
 amount of connections, obviously that isn't true. There is only a finite 
 amount of data that can be buffered in and out of any network according to 
 its hardware. When you don't regulate that, your system will end up 
 spending an inordinate amount of time compensating for this. You don't need 
 to worry about this with regular io because the thread per connection 
 abstraction effectively bounds your activity within the acceptable physical 
 constraints of the server. 

 On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote: 

  
 On Mon, Oct 6, 2014 at 12:10 AM, adrian...@mail.yu.edu wrote:

 Zach makes an excellent point; I've used AsyncSocketChannels and its irk 
 (
 http://docs.oracle.com/javase/8/docs/api/java/nio/channels/AsynchronousServerSocketChannel.html),
  
 with core.async in the past. Perhaps replacing your direct java.net.Sockets 
 with nio classes that can be given CompletionHandlers (
 http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
  
 would be a better fit. 

  
 Once I do some performance instrumentation I'll give that a shot. I admit 
 that I'm not familiar with all the implications of using the nio classes; 
 were I to switch, is it safe to continue using go blocks, or is it worth 
 explicitly allocating a single thread per socket?

  Brian
  
  -- 
 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 javascript:
 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 javascript:
 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 javascript:.
 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] async-sockets - work with sockets using core.async channels

[adrian . medina]

It's not about 'safety' (depending on what that means in this context), but 
as Zach pointed out, if you aren't careful about backpressure you can run 
into performance bottlenecks with unrestrained async IO operations because 
although they let you code as if you could handle an unlimited amount of 
connections, obviously that isn't true. There is only a finite amount of 
data that can be buffered in and out of any network according to its 
hardware. When you don't regulate that, your system will end up spending an 
inordinate amount of time compensating for this. You don't need to worry 
about this with regular io because the thread per connection 
abstraction effectively bounds your activity within the acceptable physical 
constraints of the server. 

On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:


 On Mon, Oct 6, 2014 at 12:10 AM, adrian...@mail.yu.edu javascript: 
 wrote:

 Zach makes an excellent point; I've used AsyncSocketChannels and its irk (
 http://docs.oracle.com/javase/8/docs/api/java/nio/channels/AsynchronousServerSocketChannel.html),
  
 with core.async in the past. Perhaps replacing your direct java.net.Sockets 
 with nio classes that can be given CompletionHandlers (
 http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
  
 would be a better fit. 


 Once I do some performance instrumentation I'll give that a shot. I admit 
 that I'm not familiar with all the implications of using the nio classes; 
 were I to switch, is it safe to continue using go blocks, or is it worth 
 explicitly allocating a single thread per socket?

 Brian


-- 
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: Evaluation order

[adrian . medina]

*output

On Tuesday, October 7, 2014 8:17:34 PM UTC-4, adrian...@mail.yu.edu wrote:

 You need to flush the input stream after printing. Call 
 (clojure.core/flush) to do so.

 On Tuesday, October 7, 2014 4:51:05 PM UTC-4, Johannes Langøy wrote:

 Hi, I can't figure this out.  I have these two functions:

 (defn get-number []
   (try (let [input (read-string (read-line))]
  (if (number? input)
input
(get-number)))
(catch Exception e (get-number

 (defn selection-handler [tests]
   (dotimes [i (count tests)]
 (printf (%s) %s: %s\n
 (inc i)
 (first (nth tests i))
 (or (second (nth tests i))
 --)))
   (loop [input (dec (get-number))]
 (if ((set (range (count tests))) input)
   (nth tests input)
   (recur (dec (get-number))

 Now, the problem is that when I run selection-handler, the dotimes output 
 isn't printed until (get-number) has returned. Why is this?



-- 
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: Evaluation order

[adrian . medina]

You need to flush the input stream after printing. Call 
(clojure.core/flush) to do so.

On Tuesday, October 7, 2014 4:51:05 PM UTC-4, Johannes Langøy wrote:

 Hi, I can't figure this out.  I have these two functions:

 (defn get-number []
   (try (let [input (read-string (read-line))]
  (if (number? input)
input
(get-number)))
(catch Exception e (get-number

 (defn selection-handler [tests]
   (dotimes [i (count tests)]
 (printf (%s) %s: %s\n
 (inc i)
 (first (nth tests i))
 (or (second (nth tests i))
 --)))
   (loop [input (dec (get-number))]
 (if ((set (range (count tests))) input)
   (nth tests input)
   (recur (dec (get-number))

 Now, the problem is that when I run selection-handler, the dotimes output 
 isn't printed until (get-number) has returned. Why is this?


-- 
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: Do this or that

[adrian . medina]

I agree with James. The first can be tempting when you're doing side effect 
heavy code (which should probably cause you to take a double take on how 
you got to this point anyhow) but the most glaring issue that is all too 
easy to overlook is that they aren't actually equivalent expressions. Even 
with side effecting expressions, using an if here reinforces the notion 
that you are conditionally returning one of two values, not conditionally 
executing two different blocks of statements. 

On Monday, October 6, 2014 9:49:33 PM UTC-4, James Reeves wrote:

 The latter is what I'd consider to be the correct approach.

 If the do blocks become unwieldy, you can factor them out into functions.

 - James

 On 7 October 2014 02:16, Mike Fikes mikef...@gmail.com javascript: 
 wrote:

 Here's a style question: If you have to conditionally do one set of side 
 effects or another set, is your preference to use when and when-not, or 
 an if containing do blocks? Or perhaps some other construct?

 In terms of a concrete example:

 (let [boolean-value (some-predicate?)]
   (when boolean-value
 (do-alpha)
 (do-beta))
   (when-not boolean-value
 (do-gamma)
 (do-delta)))

 or:

 (if (some-predicate?)
   (do
 (do-alpha)
 (do-beta))
   (do
 (do-gamma)
 (do-delta)))

 -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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: core.async: peek the next value from a channel without consuming it

[adrian . medina]

I think you can achieve an effect similar to what you want by using a pub 
with an appropriate topic function that classifies the input in some way, 
and then subscribing to the topic whose value you want to see. This also 
has the benefit of automatically 'mult'ing the channel input, so you can 
have multiple consumers looking for the same value. 

On Sunday, October 5, 2014 11:33:16 AM UTC-4, Nahuel Greco wrote:

 Picture the following:

 producer --- go-loop --- external service

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop consumes the value with a take operation, **unblocking** 
 the producer
 3- The go-loop contacts the external-service but the external service 
 answers it can't process the value yet
 4- The go-loop waits some timeout to retry the request to the external 
 service

 After step 2 the producer continues to compute (suppose an expensive 
 computing) a new value but the previous one wasn't effectively consumed by 
 the external service. 
 I don't want that, I want to enforce an end-to-end flow-control setup 
 where the producer blocks on (! c v) (the step 1) until the value is 
 consumed by all parties, 

 Sure, this flow control can be solved adding an ack channel and sending an 
 ack from the go-loop to the producer when the external service effectively 
 consumes the value, previously blocking the producer after step 1 waiting 
 that ack. 
 But I think a peek operation in step 2 will be more elegant. Also, I was 
 curious if the implementation of core.async channels limits in some way 
 adding a peek operation.

 A take-if with a pure predicate can't solve this, because you need to 
 contact the external service to decide to consume the value or not. 


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics a209...@trbvm.com 
 javascript: wrote:

 On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote:

 I was thinking in a single-consumer scenario with a buffered chan, in 
 which you want to check if you can consume the value before effectively 
 consuming it. As you said, a peek operation has no sense if the channel has 
 multiple consumers.


 And if you can't consume the value, then what? Nothing ever does, and 
 that channel becomes useless?

 Actually the only peek operation that to me makes much sense would be a 
 (take-if pred chan) or something similar, which atomically tests the next 
 value with pred and consumes it or not, so, it can't be consumed elsewhere 
 between the pred test and optional consumption here. And if not consumed, 
 two behaviors both occur to me as possible -- return nil or some other 
 sentinel value for do not want or block until the unwanted object is 
 consumed by someone else and then test the next item, etc.; at which point 
 you've got four versions of take-if you'd want, the inside-go and 
 outside-go versions cross product with the two when-not-wanted behaviors.

 At that point, you'd probably be better off just writing a consumer that 
 splits off the pred-matching items into one out channel and feeds 
 everything else into a second channel, with your original consumer taking 
 from the first of these and the others taking from the second. That gets 
 you the block until version of the behavior. The other version can be had 
 by making the pred-using consumer the sole consumer of the in channel, 
 which takes a value, applies pred, and branches, on the want branch doing 
 whatever and on the do not want branch putting the value onto an out 
 channel that feeds the other consumers before taking its own do not want 
 actions.

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

Re: core.async: peek the next value from a channel without consuming it

[adrian . medina]

Then how would peeking at the value help? 

On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote:

 Adrian: I don't see how a pub can help here, in the previous example to 
 consume or not the value was decided not on some property intrinsic to the 
 value (one you can create a topic from), but on the result of sending it to 
 an external service.


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 12:59 PM, adrian...@mail.yu.edu javascript: 
 wrote:

 I think you can achieve an effect similar to what you want by using a pub 
 with an appropriate topic function that classifies the input in some way, 
 and then subscribing to the topic whose value you want to see. This also 
 has the benefit of automatically 'mult'ing the channel input, so you can 
 have multiple consumers looking for the same value. 

 On Sunday, October 5, 2014 11:33:16 AM UTC-4, Nahuel Greco wrote:

 Picture the following:

 producer --- go-loop --- external service

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop consumes the value with a take operation, **unblocking** 
 the producer
 3- The go-loop contacts the external-service but the external service 
 answers it can't process the value yet
 4- The go-loop waits some timeout to retry the request to the external 
 service

 After step 2 the producer continues to compute (suppose an expensive 
 computing) a new value but the previous one wasn't effectively consumed by 
 the external service. 
 I don't want that, I want to enforce an end-to-end flow-control setup 
 where the producer blocks on (! c v) (the step 1) until the value is 
 consumed by all parties, 

 Sure, this flow control can be solved adding an ack channel and sending 
 an ack from the go-loop to the producer when the external service 
 effectively consumes the value, previously blocking the producer after step 
 1 waiting that ack. 
 But I think a peek operation in step 2 will be more elegant. Also, I was 
 curious if the implementation of core.async channels limits in some way 
 adding a peek operation.

 A take-if with a pure predicate can't solve this, because you need to 
 contact the external service to decide to consume the value or not. 


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics a209...@trbvm.com 
 wrote:

 On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote:

 I was thinking in a single-consumer scenario with a buffered chan, in 
 which you want to check if you can consume the value before effectively 
 consuming it. As you said, a peek operation has no sense if the channel 
 has 
 multiple consumers.


 And if you can't consume the value, then what? Nothing ever does, and 
 that channel becomes useless?

 Actually the only peek operation that to me makes much sense would be 
 a (take-if pred chan) or something similar, which atomically tests the 
 next 
 value with pred and consumes it or not, so, it can't be consumed elsewhere 
 between the pred test and optional consumption here. And if not consumed, 
 two behaviors both occur to me as possible -- return nil or some other 
 sentinel value for do not want or block until the unwanted object is 
 consumed by someone else and then test the next item, etc.; at which point 
 you've got four versions of take-if you'd want, the inside-go and 
 outside-go versions cross product with the two when-not-wanted behaviors.

 At that point, you'd probably be better off just writing a consumer 
 that splits off the pred-matching items into one out channel and feeds 
 everything else into a second channel, with your original consumer taking 
 from the first of these and the others taking from the second. That gets 
 you the block until version of the behavior. The other version can be had 
 by making the pred-using consumer the sole consumer of the in channel, 
 which takes a value, applies pred, and branches, on the want branch 
 doing 
 whatever and on the do not want branch putting the value onto an out 
 channel that feeds the other consumers before taking its own do not want 
 actions.

 -- 
 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 
 javascript:
 Note that posts from new members are 

Re: core.async: peek the next value from a channel without consuming it

[adrian . medina]

Ah, I think we're on the same page now. I've come across the need for this 
recently in some code for a UDP based protocol between a multiplayer game 
client and server. 

I still think a pub fits in here nicely. You can consume the value from the 
channel in question and park until you get an acknowledgment from the 
external service (or timeout). The producer would subscribe to another 
topic on your pub that will get a value put onto it when acknowledgment or 
time out occurs in the consumer. Be sure to close the subs after you've 
gotten the ack or timed out. 

On Sunday, October 5, 2014 12:40:25 PM UTC-4, Nahuel Greco wrote:

 previous example with the peek operation:

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop unparks from (peek! c) without consuming the value, the 
 producer keeps parked
 3- The go-loop contacts the external-service
 4-A If the external-service answer is ok, the go-loop consume (and 
 discard) the value by doing a normal (! c), and the producer unparks
 4-B If the external-service answers it cannot process the value, the 
 go-loop waits until a timeout to retry step 3

 The producer only unparks when the value is effectively consumed by the 
 external service. That's my objective. 

 I think your pub proposal replaces the take-if proposal given before, but 
 I think take-if (and pub) doesn't work for this scenario.


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 1:20 PM, adrian...@mail.yu.edu javascript: 
 wrote:

 Then how would peeking at the value help? 

 On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote:

 Adrian: I don't see how a pub can help here, in the previous example to 
 consume or not the value was decided not on some property intrinsic to the 
 value (one you can create a topic from), but on the result of sending it to 
 an external service.


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 12:59 PM, adrian...@mail.yu.edu wrote:

 I think you can achieve an effect similar to what you want by using a 
 pub with an appropriate topic function that classifies the input in some 
 way, and then subscribing to the topic whose value you want to see. This 
 also has the benefit of automatically 'mult'ing the channel input, so you 
 can have multiple consumers looking for the same value. 

 On Sunday, October 5, 2014 11:33:16 AM UTC-4, Nahuel Greco wrote:

 Picture the following:

 producer --- go-loop --- external service

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop consumes the value with a take operation, 
 **unblocking** the producer
 3- The go-loop contacts the external-service but the external service 
 answers it can't process the value yet
 4- The go-loop waits some timeout to retry the request to the external 
 service

 After step 2 the producer continues to compute (suppose an expensive 
 computing) a new value but the previous one wasn't effectively consumed 
 by 
 the external service. 
 I don't want that, I want to enforce an end-to-end flow-control setup 
 where the producer blocks on (! c v) (the step 1) until the value is 
 consumed by all parties, 

 Sure, this flow control can be solved adding an ack channel and 
 sending an ack from the go-loop to the producer when the external service 
 effectively consumes the value, previously blocking the producer after 
 step 
 1 waiting that ack. 
 But I think a peek operation in step 2 will be more elegant. Also, I 
 was curious if the implementation of core.async channels limits in some 
 way 
 adding a peek operation.

 A take-if with a pure predicate can't solve this, because you need to 
 contact the external service to decide to consume the value or not. 


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics a209...@trbvm.com 
 wrote:

 On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote:

 I was thinking in a single-consumer scenario with a buffered chan, 
 in which you want to check if you can consume the value before 
 effectively 
 consuming it. As you said, a peek operation has no sense if the channel 
 has 
 multiple consumers.


 And if you can't consume the value, then what? Nothing ever does, and 
 that channel becomes useless?

 Actually the only peek operation that to me makes much sense would 
 be a (take-if pred chan) or something similar, which atomically tests 
 the 
 next value with pred and consumes it or not, so, it can't be consumed 
 elsewhere between the pred test and optional consumption here. And if 
 not 
 consumed, two behaviors both occur to me as possible -- return nil or 
 some 
 other sentinel value for do not want or block until the unwanted 
 object 
 is consumed by someone else and then test the next item, etc.; at which 
 point you've got four versions of take-if you'd want, the inside-go and 
 outside-go versions cross product with the two when-not-wanted behaviors.

 At that point, you'd probably be better off just writing a consumer 
 

Re: core.async: peek the next value from a channel without consuming it

[adrian . medina]

Yes, but the advantage of using a pub is that it's simpler to have one 
input channel than to continually spawning new ones. But that's just my 
opinion. Anyway, sorry I couldn't be more help. 

On Sunday, October 5, 2014 1:04:58 PM UTC-4, Nahuel Greco wrote:

 You can do that without a pub, the producer can send a new (chan) inside 
 the request to the go-loop and the go-loop will ack on that chan when 
 getting a good response from the external service.
 That schema solves this scenario, I mentioned it in the previous mail, but 
 I think a peek operation maybe could be better and can simplify the 
 producer code.

 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 1:57 PM, adrian...@mail.yu.edu javascript: 
 wrote:

 Ah, I think we're on the same page now. I've come across the need for 
 this recently in some code for a UDP based protocol between a multiplayer 
 game client and server. 

 I still think a pub fits in here nicely. You can consume the value from 
 the channel in question and park until you get an acknowledgment from the 
 external service (or timeout). The producer would subscribe to another 
 topic on your pub that will get a value put onto it when acknowledgment or 
 time out occurs in the consumer. Be sure to close the subs after you've 
 gotten the ack or timed out. 

 On Sunday, October 5, 2014 12:40:25 PM UTC-4, Nahuel Greco wrote:

 previous example with the peek operation:

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop unparks from (peek! c) without consuming the value, the 
 producer keeps parked
 3- The go-loop contacts the external-service
 4-A If the external-service answer is ok, the go-loop consume (and 
 discard) the value by doing a normal (! c), and the producer unparks
 4-B If the external-service answers it cannot process the value, the 
 go-loop waits until a timeout to retry step 3

 The producer only unparks when the value is effectively consumed by the 
 external service. That's my objective. 

 I think your pub proposal replaces the take-if proposal given before, 
 but I think take-if (and pub) doesn't work for this scenario.


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 1:20 PM, adrian...@mail.yu.edu wrote:

 Then how would peeking at the value help? 

 On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote:

 Adrian: I don't see how a pub can help here, in the previous example 
 to consume or not the value was decided not on some property intrinsic to 
 the value (one you can create a topic from), but on the result of sending 
 it to an external service.


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 12:59 PM, adrian...@mail.yu.edu wrote:

 I think you can achieve an effect similar to what you want by using a 
 pub with an appropriate topic function that classifies the input in some 
 way, and then subscribing to the topic whose value you want to see. This 
 also has the benefit of automatically 'mult'ing the channel input, so 
 you 
 can have multiple consumers looking for the same value. 

 On Sunday, October 5, 2014 11:33:16 AM UTC-4, Nahuel Greco wrote:

 Picture the following:

 producer --- go-loop --- external service

 1- The producer puts a value to a unbuffered (chan) by doing (! c v)
 2- The go-loop consumes the value with a take operation, 
 **unblocking** the producer
 3- The go-loop contacts the external-service but the external 
 service answers it can't process the value yet
 4- The go-loop waits some timeout to retry the request to the 
 external service

 After step 2 the producer continues to compute (suppose an expensive 
 computing) a new value but the previous one wasn't effectively consumed 
 by 
 the external service. 
 I don't want that, I want to enforce an end-to-end flow-control 
 setup where the producer blocks on (! c v) (the step 1) until the 
 value is 
 consumed by all parties, 

 Sure, this flow control can be solved adding an ack channel and 
 sending an ack from the go-loop to the producer when the external 
 service 
 effectively consumes the value, previously blocking the producer after 
 step 
 1 waiting that ack. 
 But I think a peek operation in step 2 will be more elegant. Also, I 
 was curious if the implementation of core.async channels limits in some 
 way 
 adding a peek operation.

 A take-if with a pure predicate can't solve this, because you need 
 to contact the external service to decide to consume the value or not. 


 Saludos,
 Nahuel Greco.

 On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics a209...@trbvm.com 
 wrote:

 On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote:

 I was thinking in a single-consumer scenario with a buffered chan, 
 in which you want to check if you can consume the value before 
 effectively 
 consuming it. As you said, a peek operation has no sense if the 
 channel has 
 multiple consumers.


 And if you can't consume the value, then what? Nothing ever does, 
 and that channel becomes useless?

 Actually the only 

Re: [ANN] async-sockets - work with sockets using core.async channels

[adrian . medina]

Zach makes an excellent point; I've used AsyncSocketChannels and its irk 
(http://docs.oracle.com/javase/8/docs/api/java/nio/channels/AsynchronousServerSocketChannel.html),
 
with core.async in the past. Perhaps replacing your direct java.net.Sockets 
with nio classes that can be given CompletionHandlers 
(http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
 
would be a better fit. 

On Sunday, October 5, 2014 11:57:18 PM UTC-4, Zach Tellman wrote:

 If I'm reading this correctly, you're using non-blocking thread pools for 
 blocking operations on the sockets.  Given more than N connections (last 
 time I looked the thread pool's size was 42), you risk deadlock or at the 
 very least poor average throughput.

 On Sunday, October 5, 2014 7:06:56 PM UTC-7, Brian Guthrie wrote:

 Hi all,

 I'm releasing a little library for working with sockets. Feedback and 
 pull requests gratefully appreciated.

 The skinny
 ---

 This library allows you to create socket servers and socket clients and 
 interact with them asynchronously using channels. Servers return a record 
 with a :connections field, a channel which yields one socket per incoming 
 connection. Clients return the same socket record. Socket records each have 
 an :in and :out channel each which allow you to receive and send data 
 respectively on a line-by-line basis. The raw java.net.Socket is also 
 available (as :socket).

 Servers and clients are defined using the Component framework and must be 
 explicitly started using (component/start server-or-client), though 
 sockets will clean up after themselves if they are terminated for some 
 reason.

 Further information is available on Github here: 
 https://github.com/bguthrie/async-sockets

 Releases
 --

 This is the first release, which I've tagged for now as 0.0.1-SNAPSHOT. 
 Leiningen dependency: [com.gearswithingears/async-sockets 0.0.1-SNAPSHOT].

 If this is useful to you, please let me know, but any and all feedback is 
 great.

 Happy hacking,

 Brian
 @bguthrie
 btgu...@gmail.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/d/optout.

Re: Re: Handling java streams..

[adrian . medina]

It's use cases like these that make me wish clojure.lang.Seqable and the 
like were protocols. Ah, one can dream... 

On Sunday, October 5, 2014 11:59:15 PM UTC-4, Zach Tellman wrote:

 Calling (- stream .iterator iterator-seq) should give the desired result.

 On Wednesday, October 1, 2014 6:39:11 AM UTC-7, José Ricardo wrote:

 By nicer I meant something like being able to use, for example, map and 
 filter, just like I can do on a java.util.ArrayList (in clojure) and on a 
 Stream (in java).

 On Saturday, September 27, 2014 1:47:38 AM UTC-4, Sean Corfield wrote:

 On Fri, Sep 26, 2014 at 11:51 AM, José Ricardo zehz...@gmail.com 
 wrote: 
  Hi, I'm not sure if resurrecting this thread is the right approach, 
 but what 
  about Java 8 Streams (java.util.stream)? 
  
  Are there any libraries out there for making java 8 streams handling 
 nicer? 
  :) 

 Well, this thread is certainly a blast from the past :) 

 Can you be a bit more specific about what you'd like to see nicer 
 with Java 8 streams, and what you'd like to see in a Clojure wrapper? 

 I ask because Java 8 is the first version that I've been interested in 
 since I felt it went off the rails with Java 5 - and streams are part 
 of what makes Java 8 attractive again :) 
 -- 
 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/d/optout.

Re: Getting rid of boxing and reflection when working with characters

[adrian . medina]

charAt returns a char, not a primitive int, which is why you are getting 
the ClassCastException java.lang.Character cannot be cast to 
java.lang.Number exception.

The long coercion function will inline to `(. clojure.lang.RT (longCast ~x)), 
and since that that is a static method which lacks a primitive signature 
for char, that explains your first exception.

Clojure primitive function support is limited to longs and doubles, which 
is fairly reasonable given that the places where this might actually matter 
(in terms of performance) would be tight numerical loops where the cost of 
repeated function invocation would degrade performance to an unreasonable 
degree. I don't think that's the case with this function, but you can 
decide based on your use case since only you know your program best. 

In any event, to solve the reflection warning here you should add a 
non-primitive type hint to the character returned by charAt so that it will 
match the Object method of longCast. ^Character will suffice. 

On Friday, October 3, 2014 11:41:48 AM UTC-4, Fluid Dynamics wrote:

 OK, can someone tell me what the hell is going on here?

 (defn alphanumeric?
   Given a character, returns true iff the character is alphanumeric.
Accented letters and other things that pass Character/isAlphabetic are
all counted as alphanumeric.
   [^long c]
   (or (Character/isDigit c) (Character/isAlphabetic c)))

 ...

 (let [^String s foo]
   (alphanumeric? (long (.charAt s i

 Reflection warning, blah blah blah - call to longCast can't be resolved.


 How do I get rid of reflection here? If I drop the (long ... ) around the 
 charAt call, it doesn't even compile:

 ClassCastException java.lang.Character cannot be cast to java.lang.Number

 which is even weirder, as it suggests that the return value from .charAt 
 is being boxed, which it shouldn't be if it's going to go directly into 
 interop or a primitive-taking function.

 None of the apparent fixes strike me as very attractive here:

 1. Get rid of alphanumeric? and just put the or expression everywhere.

 So much for code readability, DRY, and the vaunted code size efficiency of 
 Lisps.

 2. Turn the function into a macro, to avoid the repetition in 1.

 But now it won't work in (every? alphanumeric? some-string) and wrapping 
 it as #(alphanumeric? %) bloats things, though not as badly as before.

 3. definline seems to offer the best of both worlds

 But still bloats generated bytecode...


 Even supposing a nicer solution presented itself, the implication that 
 .charAt's return is being boxed is troubling. Is there no way (aside from 
 turning these parts of the code into a Java class full of utility methods) 
 to use char values without boxing, short of (or even) directly passing to 
 interop?

 Also: is there any way to make something as elegant as (every? 
 alphanumeric? s) that's efficient? Something involving the new reducers, 
 perhaps? It smells like a species of reduction to me...

 Also: How does one profile in Counterclockwise? Googling for 
 counterclockwise profile clojure didn't bear fruit, and googling for 
 eclipse profile java turned up that there's apparently supposed to be a 
 Profiling and Logging perspective which is missing, at least in the Open 
 Perspective dialog in the standalone CCW install 
 (Counterclockwise-0.28.1.STABLE001-win32.win32.x86_64.zip, current as of a 
 few days ago).



-- 
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: Getting rid of boxing and reflection when working with characters

[adrian . medina]

You can also call (.getNumericValue (.charAt foo 0)) to get the int the 
static Character isX methods expect. 

On Friday, October 3, 2014 2:38:58 PM UTC-4, adrian...@mail.yu.edu wrote:

 charAt returns a char, not a primitive int, which is why you are getting 
 the ClassCastException java.lang.Character cannot be cast to 
 java.lang.Number exception.

 The long coercion function will inline to `(. clojure.lang.RT (longCast ~x)), 
 and since that that is a static method which lacks a primitive signature 
 for char, that explains your first exception.

 Clojure primitive function support is limited to longs and doubles, which 
 is fairly reasonable given that the places where this might actually matter 
 (in terms of performance) would be tight numerical loops where the cost of 
 repeated function invocation would degrade performance to an unreasonable 
 degree. I don't think that's the case with this function, but you can 
 decide based on your use case since only you know your program best. 

 In any event, to solve the reflection warning here you should add a 
 non-primitive type hint to the character returned by charAt so that it will 
 match the Object method of longCast. ^Character will suffice. 

 On Friday, October 3, 2014 11:41:48 AM UTC-4, Fluid Dynamics wrote:

 OK, can someone tell me what the hell is going on here?

 (defn alphanumeric?
   Given a character, returns true iff the character is alphanumeric.
Accented letters and other things that pass Character/isAlphabetic are
all counted as alphanumeric.
   [^long c]
   (or (Character/isDigit c) (Character/isAlphabetic c)))

 ...

 (let [^String s foo]
   (alphanumeric? (long (.charAt s i

 Reflection warning, blah blah blah - call to longCast can't be resolved.


 How do I get rid of reflection here? If I drop the (long ... ) around the 
 charAt call, it doesn't even compile:

 ClassCastException java.lang.Character cannot be cast to java.lang.Number

 which is even weirder, as it suggests that the return value from .charAt 
 is being boxed, which it shouldn't be if it's going to go directly into 
 interop or a primitive-taking function.

 None of the apparent fixes strike me as very attractive here:

 1. Get rid of alphanumeric? and just put the or expression everywhere.

 So much for code readability, DRY, and the vaunted code size efficiency 
 of Lisps.

 2. Turn the function into a macro, to avoid the repetition in 1.

 But now it won't work in (every? alphanumeric? some-string) and wrapping 
 it as #(alphanumeric? %) bloats things, though not as badly as before.

 3. definline seems to offer the best of both worlds

 But still bloats generated bytecode...


 Even supposing a nicer solution presented itself, the implication that 
 .charAt's return is being boxed is troubling. Is there no way (aside from 
 turning these parts of the code into a Java class full of utility methods) 
 to use char values without boxing, short of (or even) directly passing to 
 interop?

 Also: is there any way to make something as elegant as (every? 
 alphanumeric? s) that's efficient? Something involving the new reducers, 
 perhaps? It smells like a species of reduction to me...

 Also: How does one profile in Counterclockwise? Googling for 
 counterclockwise profile clojure didn't bear fruit, and googling for 
 eclipse profile java turned up that there's apparently supposed to be a 
 Profiling and Logging perspective which is missing, at least in the Open 
 Perspective dialog in the standalone CCW install 
 (Counterclockwise-0.28.1.STABLE001-win32.win32.x86_64.zip, current as of a 
 few days ago).



-- 
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: keywords

[adrian . medina]

There is no hard limit beyond available memory and JVM class size 
limitations (which is really only relevant if your creating a ton of 
keywords statically I think). 

On Monday, September 15, 2014 3:32:40 PM UTC-4, Paweł Sabat wrote:

 Hi. 

 How many :keywords can I create in Clojure? Is there any limited 
 number of them? I know of such limitation of Erlang's atoms, which are 
 just like Clojure's keywords. 


 noniwoo 


-- 
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: keywords

[adrian . medina]

*you're

On Monday, September 15, 2014 4:23:46 PM UTC-4, adrian...@mail.yu.edu wrote:

 There is no hard limit beyond available memory and JVM class size 
 limitations (which is really only relevant if your creating a ton of 
 keywords statically I think). 

 On Monday, September 15, 2014 3:32:40 PM UTC-4, Paweł Sabat wrote:

 Hi. 

 How many :keywords can I create in Clojure? Is there any limited 
 number of them? I know of such limitation of Erlang's atoms, which are 
 just like Clojure's keywords. 


 noniwoo 



-- 
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} defun: A beautiful macro to define clojure functions with pattern match.

[adrian . medina]

Friendly advice: when you describe anything you create with adjectives like 
beautiful, it comes off as unnecessarily arrogant to native English 
speakers.

Adrian

On Sunday, September 14, 2014 2:47:28 AM UTC-4, dennis wrote:


 Hi , i am pleased to introduce defun https://github.com/killme2008/defun: 
 a beautiful macro to define clojure functions with pattern match.

 Some examples:


 (defun say-hi

   ([:dennis] Hi,good morning, dennis.)

   ([:catty] Hi, catty, what time is it?)

   ([:green] Hi,green, what a good day!)

   ([other] (str Say hi to  other)))


 (say-hi :dennis)

 ;;  Hi,good morning, dennis.

 (say-hi :catty)

 ;;  Hi, catty, what time is it?

 (say-hi :green)

 ;;  Hi,green, what a good day!

 (say-hi someone)

 ;;  Say hi to someone


 Recursive function? It's all right:

 (defun count-down

   ([0] (println Reach zero!))

   ([n] (println n)

  (recur (dec n

 (defun fib

 ([0] 0)

 ([1] 1)

 ([n] (+ (fib (- n 1)) (fib (- n 2)



 Guard functions? it's all right:

 (defun valid-geopoint?

 ([(_ :guard #(and ( % -180) ( % 180)))

   (_ :guard #(and ( % -90) ( % 90)))] true)

 ([_ _] false))


 (valid-geopoint? 30 30)

 ;; true

 (valid-geopoint? -181 30)

 ;; false


 It's really cool,all the magic are from core.match, much more details 
 please see 
 https://github.com/killme2008/defun


 -- 
 庄晓丹 
 Email:killm...@gmail.com javascript: xzh...@avos.com 
 javascript:
 Site:   http://fnil.net
 Twitter:  @killme2008


 

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

Re: {ANN} defun: A beautiful macro to define clojure functions with pattern match.

[adrian . medina]

Criticism accepted Herwig. I apologize for not doing so initially. 

On Sunday, September 14, 2014 12:15:36 PM UTC-4, Herwig Hochleitner wrote:

 Hi Dennis,

 marrying core.match to defn is a pretty neat idea. Thanks for releasing it!

 I see that you actually extended defn in that you made it possible to 
 recur between different arities.
 Can you give a quick rundown on how you made that work? Are the arities 
 still separate IFn arities? Does it still run in constant stack space?

 kind regards

 PS @adrian: If you feel like Friendly advice ing someone, why not do so 
 in a private email?


-- 
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: How to use Java library from sources

[adrian . medina]

If you can't figure out how to build the JAR, you can try copying the Java 
source code directly into your Clojure project. Leiningen allows you to 
specify :java-source-paths in your project.clj, as seen here 
(https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L276). 
Then you can (:import (org.boris.pecoff4j SectionHeader .. other classes )) 
in your Clojure namespace declarations. 

On Tuesday, September 2, 2014 11:07:32 AM UTC-4, Wilker wrote:

 Hello,

 I'm trying to use this Java library on my project: 
 https://github.com/kichik/pecoff4j

 But I'm still very new to the whole ecosystem, I was looking for some way 
 to first convert this to a jar, and then to load this jar into my Leiningen 
 project, I found a few posts on internet like this one:


 http://www.elangocheran.com/blog/2013/03/installing-jar-files-locally-for-leiningen-2/

 But they don't cover how to build the jar from the sources in first place, 
 and those seem a bit old.

 How is a good way for me to get the pecoff4j in my project? Another detail 
 is that my project is a Leiningen plugin, so I need to have this dependency 
 shared with the plugin users.

 Thanks.
 ---
 Wilker Lúcio
 http://about.me/wilkerlucio/bio
 Woboinc Consultant
 +55 81 82556600
  

-- 
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: How can I add meta to an object that doesn't implement IObj?

[adrian . medina]

Sorry, I overlooked that you already ruled out all IDeref instances. 

On Sunday, August 31, 2014 10:21:39 PM UTC-4, Atamert Ölçgen wrote:



 On Mon, Sep 1, 2014 at 1:52 AM, adrian...@mail.yu.edu javascript: 
 wrote:

 If you don't want to wrap the object in an atom, you can also reify an 
 object that supports IDeref which returns your object. All reified objects 
 support IObj out of the box. 


 As I said earlier:

 ... can't deref it since I can't change the functions that will use it 
 later.

  
 And again, later:

 I can't really pass a list since the first function is expecting the 
 object I am passing,


 That was why I was asking how to attach metadata.

  


 On Sunday, August 31, 2014 4:55:58 AM UTC-4, Atamert Ölçgen wrote:

 Hi Francis,


 On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila fran...@gmail.com 
 wrote:

 It would probably help if you said more about the source of this 
 atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it 
 final?


 It's not an atom-holding object. The only guarantee is that this object 
 extends one (or two) of these protocols: http://clecs.muhuk.
 com/api/0.2.1/clecs.world.html

 Other than that, it can be anything. A Java class, or a type or a 
 record...

  



 If you can control the construction of this object and its class is not 
 final, you can subclass it and add an IObj implementation. (Note that 
 most, 
 maybe all clojure ways of creating classes create final classes, so this 
 technique won't work.) The easiest way to subclass is with `proxy`:

 (defn meta-AtomHolder [atom-value metadata]
   (proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new 
 interfaces]
  [atom-value] ;; constructor args
 (meta [] metadata) ;; subclass method
 (withMeta [newmeta] (meta-AtomHolder newmeta
 = (var user/meta-AtomHolder)
 (meta-AtomHolder (atom x) {})
 = #AtomHolderClass$IObj$40298964 user.proxy$AtomHolderClass$
 IObj$40298964@302c28cc
 (meta (meta-AtomHolder (atom x) {}))
 = {}
 (meta (with-meta (meta-AtomHolder (atom x) {}) {:a 1}))
 = {:a 1}  


 This is really cool. So I can do (deref (meta-AtomHolder (atom x) {})) 
 and it would return x, right?

 I have actually managed to solve it using vars, had to move things 
 around a bit: https://github.com/muhuk/clecs/blob/master/src/clecs/
 world/check.clj#L73

  

  
 If the parent class is final or you can't construct the object 
 yourself, you need to delegate method calls from one instance to this 
 object instance. I think this is hard-but-not-impossible in java, but I'm 
 not sure.

 (Clojurescript has `specify`, which does exactly what you want, but 
 only exists because delegation between instances in javascript is trivial.)

 On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:

 Obviously I can't.

 But I need to add this capability to an object. During testing I 
 attach meta to this object that contains an atom. Then I pass this object 
 to other functions, known in runtime. I can't use a dynamic var because 
 all 
 this happens within a mock function that may be retried and run in 
 different threads.

 I have seen this: http://stackoverflow.com/questions/20724219/
 simplest-possible-clojure-object-that-can-accept-a-primitive-and-
 metadata but can't deref it since I can't change the functions that 
 will use it later. If I wrap this object I need to be able to delegate 
 all 
 of its functionality to the original object.

 I hope this all is not too vague. The code I'm working on is not 
 online yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm 
 adding quickcheck to compare different world implementations.


 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  
  -- 
 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.




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  
  -- 
 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 
 javascript:
 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 javascript:
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to 

Re: How can I add meta to an object that doesn't implement IObj?

[adrian . medina]

If you don't want to wrap the object in an atom, you can also reify an 
object that supports IDeref which returns your object. All reified objects 
support IObj out of the box. 

On Sunday, August 31, 2014 4:55:58 AM UTC-4, Atamert Ölçgen wrote:

 Hi Francis,


 On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila fran...@gmail.com 
 javascript: wrote:

 It would probably help if you said more about the source of this 
 atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it 
 final?


 It's not an atom-holding object. The only guarantee is that this object 
 extends one (or two) of these protocols: 
 http://clecs.muhuk.com/api/0.2.1/clecs.world.html

 Other than that, it can be anything. A Java class, or a type or a record...

  



 If you can control the construction of this object and its class is not 
 final, you can subclass it and add an IObj implementation. (Note that most, 
 maybe all clojure ways of creating classes create final classes, so this 
 technique won't work.) The easiest way to subclass is with `proxy`:

 (defn meta-AtomHolder [atom-value metadata]
   (proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new 
 interfaces]
  [atom-value] ;; constructor args
 (meta [] metadata) ;; subclass method
 (withMeta [newmeta] (meta-AtomHolder newmeta
 = (var user/meta-AtomHolder)
 (meta-AtomHolder (atom x) {})
 = #AtomHolderClass$IObj$40298964 
 user.proxy$AtomHolderClass$IObj$40298964@302c28cc
 (meta (meta-AtomHolder (atom x) {}))
 = {}
 (meta (with-meta (meta-AtomHolder (atom x) {}) {:a 1}))
 = {:a 1}  


 This is really cool. So I can do (deref (meta-AtomHolder (atom x) {})) 
 and it would return x, right?

 I have actually managed to solve it using vars, had to move things around 
 a bit: 
 https://github.com/muhuk/clecs/blob/master/src/clecs/world/check.clj#L73

  


 If the parent class is final or you can't construct the object yourself, 
 you need to delegate method calls from one instance to this object 
 instance. I think this is hard-but-not-impossible in java, but I'm not sure.

 (Clojurescript has `specify`, which does exactly what you want, but only 
 exists because delegation between instances in javascript is trivial.)

 On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:

 Obviously I can't.

 But I need to add this capability to an object. During testing I attach 
 meta to this object that contains an atom. Then I pass this object to other 
 functions, known in runtime. I can't use a dynamic var because all this 
 happens within a mock function that may be retried and run in different 
 threads.

 I have seen this: http://stackoverflow.com/questions/20724219/
 simplest-possible-clojure-object-that-can-accept-a-
 primitive-and-metadata but can't deref it since I can't change the 
 functions that will use it later. If I wrap this object I need to be able 
 to delegate all of its functionality to the original object.

 I hope this all is not too vague. The code I'm working on is not online 
 yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding 
 quickcheck to compare different world implementations.


 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  
  -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.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/d/optout.

Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report

[adrian . medina]

You rule Nicola! I really appreciate all of the work you've put into this. 
Your code has forever influenced the way I write lexical analyzers with 
Clojure. :)

On Wednesday, August 13, 2014 12:54:54 PM UTC-4, Nicola Mometto wrote:


 As some of you might know, I've been working contiuously on my various 
 tools.* contrib libraries for the past months and I've recently added 
 tools.analyzer.js to the list of contrib libraries I maintain. 

 Since I don't blog/tweet much about those libraries, I thought I'd write 
 a report to let the community aware of the status of those libraries. 

 ## tools.analyzer https://github.com/clojure/tools.analyzer 

 tools.analyzer is a host-agnostic pluggable analyzer and collection of 
 passes producing an AST in clojure data structures for clojure and 
 other languages in the clojure language family, like clojurescript. 

 The current release is 0.5.1, here's a list of notable changes that have 
 made in in the last few months: 

 * The analyzer now uses different environments for lexical state (like 
   the locals map) and for global state (like namespaces mappings); the 
   former is just a regular map passed to an analyze call, the latter is 
   a dynamic var holding an atom and lives in the tools.analyzer.env 
   namespace along with functions to setup/manipulate it. 

 * The metadata elision mechanism has been vastly improved, allowing to 
   specify different keys to elide based on the node :op, aswell as based 
   on a predicate rather than simple key matching. 

 * The env context now partecipates in a keyword hierarchy, the default 
   contexts are :ctx/statement, :ctx/return and :ctx/expr and other 
   contexts can be derived from those, as an example tools.analyzer 
   utilizes :ctx.invoke/target and :ctx.invoke/params for nodes in invoke 
   position. 

 * Dispatch on clojure expressions types has been opened with the 
   -analyze-form multimethod, allowing to provide custom evaluation 
   strategies for custom types (this was needed for tools.analyzer.js 
   because of clojurescript's #js syntax) 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer/blob/master/README.md 

 ## tools.analyzer.jvm https://github.com/clojure/tools.analyzer.jvm 

 tools.analyzer.jvm is a jvm-specific tools.analyzer extension, 
 collection of passes and useful functions to deal with analysis of 
 clojure on the JVM code. 

 The current release is 0.5.2, here's a list of notable changes that have 
 made in the last few months: 

 * Added an analyze-ns function that returns a vector of AST nodes for 
   every top-level form in that namespace; evaluates each form. 

 * Added a configurable handler for wrong tags: while Clojure is 
   permissive of type hints that don't resolve to a Class which it 
   simply ignores in most cases, tools.analyzer.jvm's default behaviour 
   has always been to throw an exception in those cases. This has been a 
   longstanding issue for tools like eastwood that want to simply emit a 
   warning on those cases rather than stopping analysis and error out. 
   With the addition of this handlers, users can now control what happens 
   when t.a.jvm hits a tag that can't be resolved to a Class. 

 * Added optional Var-level tag inference 

 * Improved analyze+eval to attach the result of the evaluation of the 
   node to the AST, wrapping potential exceptions at evaluation time in 
   an ExceptionThrown record. 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer.jvm/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/README.md 

 ## tools.analyzer.js https://github.com/clojure/tools.analyzer.js 

 tools.analyzer.js is a js-specific tools.analyzer extension, collection 
 of passes and useful functions to deal with analysis of clojurescript 
 code. 

 The current release is 0.1.0-beta4. 

 The produced AST is not compatible with the one produced by 
 cljs.analyzer even though they are similar as the cljs analyzer heavily 
 influenced the AST format of tools.analyzer. 
 tools.analyzer.js has several advantages over cljs.analyzer: 

 * Heavily modular implementation, thanks to the :children-walking based 
   multi-pass design. 

 * Unified AST format and analyzer interface between clj and cljs code 
   analyzers, this will allow 

Re: Is this behavior with recur and pre/post a bug?

[adrian . medina]

I do not believe this should be considered a bug. Recur is a special form 
that rebinds the bindings at the point of recursion with new values. It 
does not return a value. It does not get evaluated in the normal sense of 
the word. You cannot type check a value on a valueless expression. Just 
think about the implications of what a post condition on a recur form 
means. Even if you wanted to give value semantics to the evaluation of a 
recur form, there would be no single value it could check against. If you 
wanted the post condition to only be evaluated on the termination of the 
loop, or when the recur form is not conditionally present in the 
expression, then you are essentially asking the impossible for the 
compiler: it cannot know your intentions better than you do. 

On Friday, July 25, 2014 10:12:14 AM UTC-4, Michael O'Keefe wrote:

 Thanks Bob, Steve, and Andy. I was trying to get logged into JIRA to file 
 the bug report but I seem to be having a heck of a time -- I have a CA and 
 am signed up at dev.clojure.org but when I try to log into JIRA, it gives 
 me a nice System Error saying  user should not be null!. I've run out 
 of time to deal with this right now but, Steve, if you get to it before me, 
 feel free to submit the bug report.

 Thanks all for the helpful discussions!

 Michael

 On Friday, July 25, 2014 7:58:51 AM UTC-6, miner wrote:

 I will call it a bug.  It's definitely surprising to the user, and 
 therefore worthy of a ticket.  On first glance, it seems that the fix isn't 
 too hard. In core.clj where the macro fn is redefined, we just need to wrap 
 the section that handles the post condition either with a loop* or a fn* so 
 that the body has the proper recur target.  I'll try to make a patch and a 
 test.  If it works, I'll file a bug with the patch.



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

Re: Is this behavior with recur and pre/post a bug?

[adrian . medina]

I hear what you're saying. Given that recur is a special form, there exists 
a closed set of exceptions to be worked around like this even 
theoretically, so I could see the argument for having this patch accepted 
and not opening pandora's box. 

On Friday, July 25, 2014 11:36:36 AM UTC-4, Michael O'Keefe wrote:

 Adrian, thanks for your input on whether this is a bug or not. Your 
 viewpoint may yet prove to be the accepted one but I still felt like the 
 original way I wrote the function should have meant: check pre-conditions 
 function runs check final return to caller. In that sense, it feels 
 like my original function g should have been semantically equivalent to 
 g2... but we'll see.

 Thanks for the ticket and patch, Steve! Also, I seem to now be able to 
 finally log into JIRA -- I'll sign up to watch the ticket.

 Anyhow, thanks everyone! We'll see what happens.

 Michael

 On Friday, July 25, 2014 8:41:47 AM UTC-6, Ambrose Bonnaire-Sergeant wrote:

 Now that Steve mentions it, I have fixed this kind of issue in my own 
 defn macros. IIRC adding an inner loop form did the trick.

 Thanks,
 Ambrose


 On Fri, Jul 25, 2014 at 10:35 PM, adrian...@mail.yu.edu wrote:

 I do not believe this should be considered a bug. Recur is a special 
 form that rebinds the bindings at the point of recursion with new values. 
 It does not return a value. It does not get evaluated in the normal sense 
 of the word. You cannot type check a value on a valueless expression. Just 
 think about the implications of what a post condition on a recur form 
 means. Even if you wanted to give value semantics to the evaluation of a 
 recur form, there would be no single value it could check against. If you 
 wanted the post condition to only be evaluated on the termination of the 
 loop, or when the recur form is not conditionally present in the 
 expression, then you are essentially asking the impossible for the 
 compiler: it cannot know your intentions better than you do. 


 On Friday, July 25, 2014 10:12:14 AM UTC-4, Michael O'Keefe wrote:

 Thanks Bob, Steve, and Andy. I was trying to get logged into JIRA to 
 file the bug report but I seem to be having a heck of a time -- I have a 
 CA 
 and am signed up at dev.clojure.org but when I try to log into JIRA, 
 it gives me a nice System Error saying  user should not be null!. I've 
 run out of time to deal with this right now but, Steve, if you get to it 
 before me, feel free to submit the bug report.

 Thanks all for the helpful discussions!

 Michael

 On Friday, July 25, 2014 7:58:51 AM UTC-6, miner wrote:

 I will call it a bug.  It's definitely surprising to the user, and 
 therefore worthy of a ticket.  On first glance, it seems that the fix 
 isn't 
 too hard. In core.clj where the macro fn is redefined, we just need to 
 wrap 
 the section that handles the post condition either with a loop* or a fn* 
 so 
 that the body has the proper recur target.  I'll try to make a patch and 
 a 
 test.  If it works, I'll file a bug with the patch.

  -- 
 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: Is this behavior with recur and pre/post a bug?

[adrian . medina]

Indeed this is the case and no; I would not consider it a bug. Because you 
have specified a post condition on the return value, the clojure.core/fn 
macro is macroexpanding properly to support that post condition. By 
recursively macroexpanding the form, you can see the what the form will 
eventually look like to the 
compiler: https://gist.github.com/aamedina/49b4f8caf28c8b78c26b 

If you're using CIDER with Emacs, you can do this on any form by invoking 
M-x cider-macroexpand-all. 

Special forms, like recur, are handled by the compiler as special cases. 
The semantics of Clojure's recur special form forbid it from being used 
anywhere but the tail position of the body of either a fn* or loop*. As you 
can see from the gist, the return value is validated by the number? 
predicate before returning, or else it throws an error.

On Thursday, July 24, 2014 6:56:22 PM UTC-4, Michael O'Keefe wrote:

 Hello All,

 I encountered the following behavior in Clojure 1.6 and wanted to check if 
 it should be considered a bug or not. I would say yes but wanted to double 
 check on the list first.

 Here's a minimal test case that elicited the error:

 (defn f

   [xs acc]
   (if (nil? xs)
 acc
 (recur (next xs) (+ (first xs) acc

 (f [1 2 3 4] 0) = 10


 Now, if I want to add pre/post conditions, the following happens: 

 (defn g 

   [xs acc]
   {:pre [(or (nil? xs) (sequential? xs)) (number? acc)]
:post [number?]}
   (if (nil? xs)
 acc
 (recur (next xs) (+ (first xs) acc


 = this fails to compile with CompilerException 
 java.lang.UnsupportedOperationException: Can only recur from tail position


 In fact, it is only the post-condition that triggers the issue.

 My guess would be that the recur statement is being knocked out of tail 
 position by the mechanism for handling the post-condition assertion. It can 
 be fixed in the code by adding an explicit loop:

 (defn g2 [xs acc]
   {:pre [(or (nil? xs) (sequential? xs)) (number? acc)]
:post [number?]}
   (loop [xs xs
  acc acc]
 (if (nil? xs)
   acc
   (recur (next xs) (+ (first xs) acc)

  
 Thanks,

 Michael O'Keefe


-- 
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 unquote clone values?

[adrian . medina]

You're going down a rabbit hole here. Evaluating forms at runtime will 
always result in a slower execution time than a function that doesn't 
evaluate a form at runtime. 

On Thursday, July 3, 2014 11:55:02 AM UTC-4, Pascal Germroth wrote:

 Hi Atamert,

 Here's a gist with the example code: 
 https://gist.github.com/neapel/4e502a14e3738b709672

 I tried replacing a closure with a dynamically built and evaluated 
 metafunction but discovered that it was actually slower.


 If evaluating code during run is slower than AOT compiling it, it 
 wouldn't surprise me.


 I didn't actually try AOT compiling it, just using the REPL. As far as I 
 understand there shouldn't be a difference in speed, since (eval) runs the 
 same compiler as AOT does, and even writes out a .class file.

 (possibly unrelated, maybe due to eval, when trying to AOT compile the 
 example project by adding `:aot :all` and running `lein jar`, it appears to 
 fall into an infinite loop. The JAR file grew to 8GB, but I couldn't list 
 its contents.)
  

 I guess f2 runs this much slower than f1 because it doesn't actually pass 
 a reference to x when unquoting, but clones the value, which means it needs 
 to compare the lists element-wise.


 This is interesting. Were you able to confirm it or are you just 
 guessing? (I'm just curious.) 


  The code in the Gist produces a nice table now, here's my result (I 
 couldn't reproduce the case where f3 runs as fast as f1 for vectors; but 
 it's actually less weird this way)
 I think it's quite obvious that f1 compares always references, as does the 
 nil case, while the vec and map cases compare by value:

 |map |vec |  nil | name |
 |++--+--|
 |   5 ns |   5 ns | 5 ns |   f1 |
 | 558 ns | 134 ns | 6 ns |   f2 |
 | 567 ns | 130 ns | 7 ns |   f3 |
 | 561 ns | 117 ns | 7 ns |   f4 |

 It also dumps the disassembly, we can see that:

 f1-map == f1-vec == f1-nil (makes sense, as the reference to the value is 
 passed in the constructor of the closure)
 f2-map = f3-map, f2-vec = f3-vec, f2-nil = f3-nil (with renaming)
 f4-map = f1, f4-vec = f1, f4-nil = f1 (with renaming)
 f2-map = f2-vec, except for calling clojure.lang.RT.map / vector.

 So there are only three versions of the actual bytecode:
 - the closure f1/f4;
 - f2 building a new object in its static constructor
 - f2-nil using a null constant instead of a field containing null.

 importantly, f1/f4 are identical:
 public final class F extends clojure.lang.AFunction {
   /* ... static constructor getting clojure.core/= ... */
   Object x;
   public F(Object o) { x = o }
   public Object invoke( Object y ) {
 /*basically*/ return (bool (= x y))
   }
 }

 So why does f4 behave almost like f2/f3?!


 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: syntax tree manipulation

[adrian . medina]

If I understand your question correctly, you want to manipulate a deeply 
nested tree-like data structure, right? If that's correct, then perhaps a 
combination of clojure.zip and multimethods will suit your needs. Zippers 
provide a facility to transform (possibly) deeply nested immutable data 
structures in a way that feels like you are editing the data structure in 
place when you are actually not. To only manipulate the nodes that match a 
certain pattern, I would suggest writing a multimethod that allows you to 
identify a certain class of nodes that necessitate a type of 
modification. That way as you learn more about how your code needs to be 
structured to fit the needs of your data you can add new multimethod 
implementations to fit your needs. The default implementation should 
probably just move to the next loc in the zipper without modifying 
anything. 

On Thursday, July 3, 2014 12:12:35 PM UTC-4, Brian Craft wrote:

 What clojure tools should I be considering for doing syntax tree 
 manipulations? In general, I'm recursively matching patterns in subtrees 
 and rewriting them. The patterns are usually more complex than, say, 
 core.match patterns (e.g. match subtree having vector that contains term, 
 and split the term out of the vector and put in its own subtree).



-- 
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 unquote clone values?

[adrian . medina]

I'm not sure I understand what you're saying here. :( Your example is 
simply benchmarking the same bit of code in each form. Why would evaluating 
one explicitly affect that benchmark? Your original example called eval in 
the body of the functions that you're benchmarking. That is where the 
overhead comes from. 

On Thursday, July 3, 2014 1:05:12 PM UTC-4, Pascal Germroth wrote:



 On Thursday, July 3, 2014 5:19:56 PM UTC+1, adrian...@mail.yu.edu wrote:

 You're going down a rabbit hole here. Evaluating forms at runtime will 
 always result in a slower execution time than a function that doesn't 
 evaluate a form at runtime. 


 I thought that was the whole point of Clojure?

 The REPL is just parsing a string or file and running (eval) on it, I 
 can't detect any difference in speed when doing it manually:

 (quick-bench ((fn fac [x] (if (zero? x) 1 (* x (fac (dec x) 10)) ; = 
 263 ± 9 ns
 (eval `(quick-bench ((fn fac# [x#] (if (zero? x#) 1 (* x# (fac# (dec 
 x#) 10))) ; 269 ± 8 ns

 I'm very sure that the differences I measured are only because the lists 
 are being copied instead of passed by reference, which I can understand in 
 the case where the disassembly actually shows a copy being constructed. But 
 not in the case where the bytecode is exactly the same --- and criterium 
 takes a lot of time to warm up etc, all of the same optimisations should 
 have been applied (and the dynamic part of the code is not a lot anyway, 
 it's just calling AOT-compiled java code anyway. The only difference in 
 timing must stem from the element-wise comparison)


-- 
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 unquote clone values?

[adrian . medina]

No I'm benchmarking the functions returned by f1-4. 

Where did I say different? 

In any event, I'm trying to help you understand why your benchmarking 
results are not aligning with your expectations and assumptions about the 
code you wrote. 

I would really like to help you gain a greater understanding here, but I 
must admit you are coming off as fairly confrontational, so I am hesitant 
to continue this conversation. Good luck. 

On Thursday, July 3, 2014 2:14:51 PM UTC-4, Pascal Germroth wrote:

 On Thursday, July 3, 2014 6:15:32 PM UTC+1, adrian...@mail.yu.edu wrote:

 I'm not sure I understand what you're saying here. :( Your example is 
 simply benchmarking the same bit of code in each form. Why would evaluating 
 one explicitly affect that benchmark? Your original example called eval in 
 the body of the functions that you're benchmarking. That is where the 
 overhead comes from. 


 No I'm benchmarking the functions returned by f1-4.
 They use different ways of generating their return function, i.e. by 
 eval'ing the function constructor (fn [] ...) once before the benchmark -- 
 the `let [f (f1 v)]` part.
 Of course the call to (eval) takes time, but my point is that a function 
 that was generated using (eval) is exactly the same as one generated 
 statically.

 Except somehow when unquoting the x-parameter to create the eval'ed form 
 things are being cloned that shouldn't. That's what I'm measuring.

 Actually I just found a better example that doesn't need timing etc:

 (def x (Object.))
 (str x) ; java.lang.Object@...
 `(str ~x) ; (clojure.core/str #Object java.lang.Object@...)
 (eval `(str ~x)) ; RuntimeException: Can't embed object in code, maybe 
 print-dup not defined: java.lang.Object@...
 (eval `(str x)) ; java.lang.Object@... -- works through resolving user/x

 So it's not actually a problem with quoting, that returns a list with str 
 and the object as expected.
 But eval'ing that list fails because it can't print-dup'ed?! I can't tell 
 where that's happening, because it looks like clojure.lang.Parser.eval is 
 actually processing the elements of the list as I expected…



-- 
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: When to prefer keywords as functions?

[adrian . medina]

I believe you might have seen :when in the binding vector of either a for 
or deseq form. Their special usage is documented 
here: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/for

In any event, James explained the distinction quite well. Macros are often 
used to create special syntax for domain specific functionality. In the ns 
macro, this is to simplify the specification for required libraries, 
classes, etc. in a given namespace. You noticed the similarity to the 
standalone 'require', 'use', and 'import' macros for a reason. The ns macro 
was designed to make adding those options to the ns form look and feel like 
the standalone forms.

In the case of the 'for' macro, it is to allow for powerfully expressive 
list comprehensions. This is tangential but I think you might enjoy seeing 
how far you can go with list comprehensions in 
Clojure: 
http://programming-puzzler.blogspot.com/2013/03/logic-programming-is-overrated.html

On Thursday, July 3, 2014 2:24:51 PM UTC-4, g vim wrote:

 On 03/07/2014 18:36, James Reeves wrote: 
  
  The reason for this is to make it clear that you're not executing the 
  require function directly, but instead passing options to the ns form. 
  

 I don't understand not executing the require function directly. 

 I've also seen the when function called as :when in the body of a let 
 statement so could you elaborate on this non-macro example? I need to be 
 clear on when it is preferable to use a keyword function rather than a 
 normal function call. 

 gvim 


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

Re: Quil for ClojureScript

[adrian . medina]

I wrote a small wrapper over processing.js over the week a few weeks ago, 
here are some examples with 
code: http://aamedina.github.io/processing.cljs. 

It was a lot of fun. =) Good luck with the port!

On Tuesday, March 11, 2014 8:26:18 AM UTC-4, Divyansh Prakash wrote:

 Hello!

 I am a Java developer, and the author of 
 3Coffeehttps://github.com/divs1210/3Coffee, 
 a 2D Game Engine (with custom inbuilt physics) that I wrote some 2 years 
 back.
 I stumbled across Clojure while trying to solve one of the *many* 
 threading issues I seemed to have with swing.

 I have been Lisping ever since. Check 
 thishttp://pizzaforthought.blogspot.in/2014/02/on-art-of-programming.htmlout.

 The point is: I like designing high-level APIs, and have a fairly good 
 understanding of Clojure (and working on it). I have worked with 
 graphics-processing before, and would like to work on the ClojureScript 
 port for Quil as a project for GSoC 2014.

 I have been busy with college all this while, but I'll start working on it 
 ASAP.
 Will keep you posted.


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