Re: How to create a core.async channel that will drop messages if no consumer is currently reading from the channel?

[Jozef Wagner]

>From my understanding of how core.async is implemented, if channel has a 
buffer, every message goes through it, regardless of whether there are 
takes waiting or not. This is due to transducers that are applied only on 
buffer items. None messages would thus pass through with a 0 size dropping 
buffer.

Jozef

On Wednesday, January 7, 2015 6:39:47 AM UTC+1, Yehonathan Sharvit wrote:
>
> What is the reason for the dropping buffer not supporting size 0?
>
> Why the most trivial option of "no buffering" is not supported out of the 
> box by core.async?
>
>
>
> On Thu, Jan 1, 2015 at 11:31 AM, Jozef Wagner  > wrote:
>
>> Implement a custom buffer type, or use mult. With mult, use tap/untap to 
>> control reading. Items sent to mult are dropped if there are no taps.
>>
>> Jozef
>>  
>> On Mon, Dec 29, 2014 at 12:38 PM, Yehonathan Sharvit > > wrote:
>>
>>>  Hello,
>>>
>>>
>>> I would like to create a channel that will drop messages if no consumer 
>>> is currently reading from the channel.
>>>
>>> Something like a channel with a dropping-buffer of size 0.
>>> The problem is that the API doesn't allow to create a dropping-buffer of 
>>> size 0.
>>>
>>>
>>>  With the following code snippet, I would like the reader to read 
>>> nothing. 
>>>
>>> *(def c (create-unbuffered-chan)) *
>>>
>>>  *(put! c :ok)*
>>>
>>>  *(go (println (>>  
>>>
>>>
>>> Your help is appreciated.
>>> Thanks,
>>> Yehonathan.
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/6rYA9Ik7Aws/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: camelize-dasherize - reinventing the wheel?

[Noam Ben-Ari]

@Thomas

Unfortunately, clojure.walk is not StackOverflowError-safe. Same goes for 
tree-seq (uses walk). The only safe solution I found so far are zippers.

Regarding memoization, yes I agree it will help if converting the same maps 
frequently, however at scale, with many users hitting the same API, and 
each has a different user-id, it will not help (unless I'm missing 
something).

Thanks.

On Wednesday, January 7, 2015 1:36:53 AM UTC+2, Thomas Heller wrote:
>
> If you want to boost performance a bit just memoize the conversion 
> functions. Memoize makes you vurnable to exploits though, better use 
> something with WeakRefs if you convert anything from untrusted sources (eg. 
> guava CacheBuilder). But given your usecase this will probably be the 
> biggest gain, no matter what else you use to convert maps.
>
> https://gist.github.com/thheller/7ddc0371561deaf13e11
> "Elapsed time: 35.488 msecs"
>
> clojure.walk has keywordize-keys and stringify-keys, maybe a suitable 
> starting point for your implementation.
>
> HTH,
> /thomas
>
>
> On Tuesday, January 6, 2015 8:25:57 PM UTC+1, Noam Ben-Ari wrote:
>>
>> Hi,
>>
>> I've written a small library (1 ns, 100 lines) to transform nested maps 
>> from "dash-case" keys to "camelCase" keys and back.
>>
>> The original use case was taking MySQL records that use camelCase field 
>> names and convert them to dash-case so they don't stick out like a sore 
>> thumb in my code. Similarly, when writing new records into the DB, I wanted 
>> to camelize them back before passing to JDBC.
>>
>> It should work on an arbitrarily deep nested map without blowing the 
>> stack (using zipper).
>>
>> It is symmetric:
>>
>> (dasherize "clientOSVersion")
>> => "client-OS-version"
>> (camelize "client-OS-version")
>> => "clientOSVersion"
>>
>>
>> The library starts with defining functions that work on strings, then 
>> ones that work on keywords (internally calling the string ones) and later 
>> ones working on maps (that assume all keys are keywords and use the keyword 
>> functions). Lastly, the library defines protocols that will ease working 
>> with different types.
>>
>> I would love any feedback, but especially:
>> - is there any off-the-shelf library for this already?
>> - I found zipper and regex to be really hurting performance here, 
>> anything you would do differently to improve this?
>> - anything about style... I'm writing Clojure for a year and didn't get 
>> much code reviews.
>>
>> the gist is here:
>>
>> https://gist.github.com/NoamB/6e940775dfa63c73ee9c
>>
>> Thanks.
>>
>> PS - I took the string versions of the functions from cuerdas (
>> https://github.com/funcool/cuerdas) and modified a bit, mainly to get 
>> the symmetry working.
>>
>

-- 
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: camelize-dasherize - reinventing the wheel?

[Andrey Antukh]

Hello

2015-01-07 10:11 GMT+01:00 Noam Ben-Ari :

> @Thomas
>
> Unfortunately, clojure.walk is not StackOverflowError-safe. Same goes for
> tree-seq (uses walk). The only safe solution I found so far are zippers.
>
> Regarding memoization, yes I agree it will help if converting the same
> maps frequently, however at scale, with many users hitting the same API,
> and each has a different user-id, it will not help (unless I'm missing
> something).
>

As far as I understand, you are trying transform keys and not values. If
that supposition is correct, you have only a little subset of posible keys
memoized (the set of keys of your api). In case of user-id, you will
memoize the transformation of userId to user-id and for it you only need
one cache entry.

Obviously, if you transform arbitrary user input, memoize is not a good
solution.

My two cents!

Cheers.
Andrey

>
> Thanks.
>
> On Wednesday, January 7, 2015 1:36:53 AM UTC+2, Thomas Heller wrote:
>>
>> If you want to boost performance a bit just memoize the conversion
>> functions. Memoize makes you vurnable to exploits though, better use
>> something with WeakRefs if you convert anything from untrusted sources (eg.
>> guava CacheBuilder). But given your usecase this will probably be the
>> biggest gain, no matter what else you use to convert maps.
>>
>> https://gist.github.com/thheller/7ddc0371561deaf13e11
>> "Elapsed time: 35.488 msecs"
>>
>> clojure.walk has keywordize-keys and stringify-keys, maybe a suitable
>> starting point for your implementation.
>>
>> HTH,
>> /thomas
>>
>>
>> On Tuesday, January 6, 2015 8:25:57 PM UTC+1, Noam Ben-Ari wrote:
>>>
>>> Hi,
>>>
>>> I've written a small library (1 ns, 100 lines) to transform nested maps
>>> from "dash-case" keys to "camelCase" keys and back.
>>>
>>> The original use case was taking MySQL records that use camelCase field
>>> names and convert them to dash-case so they don't stick out like a sore
>>> thumb in my code. Similarly, when writing new records into the DB, I wanted
>>> to camelize them back before passing to JDBC.
>>>
>>> It should work on an arbitrarily deep nested map without blowing the
>>> stack (using zipper).
>>>
>>> It is symmetric:
>>>
>>> (dasherize "clientOSVersion")
>>> => "client-OS-version"
>>> (camelize "client-OS-version")
>>> => "clientOSVersion"
>>>
>>>
>>> The library starts with defining functions that work on strings, then
>>> ones that work on keywords (internally calling the string ones) and later
>>> ones working on maps (that assume all keys are keywords and use the keyword
>>> functions). Lastly, the library defines protocols that will ease working
>>> with different types.
>>>
>>> I would love any feedback, but especially:
>>> - is there any off-the-shelf library for this already?
>>> - I found zipper and regex to be really hurting performance here,
>>> anything you would do differently to improve this?
>>> - anything about style... I'm writing Clojure for a year and didn't get
>>> much code reviews.
>>>
>>> the gist is here:
>>>
>>> https://gist.github.com/NoamB/6e940775dfa63c73ee9c
>>>
>>> Thanks.
>>>
>>> PS - I took the string versions of the functions from cuerdas (
>>> https://github.com/funcool/cuerdas) and modified a bit, mainly to get
>>> the symmetry working.
>>>
>>  --
> 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
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: camelize-dasherize - reinventing the wheel?

[Noam Ben-Ari]

You are right. If it is only applied to keys, like in Thomas's example, it 
can be very helpful.

On Wednesday, January 7, 2015 11:21:39 AM UTC+2, Andrey Antukh wrote:
>
> Hello
>
> 2015-01-07 10:11 GMT+01:00 Noam Ben-Ari >:
>
>> @Thomas
>>
>> Unfortunately, clojure.walk is not StackOverflowError-safe. Same goes for 
>> tree-seq (uses walk). The only safe solution I found so far are zippers.
>>
>> Regarding memoization, yes I agree it will help if converting the same 
>> maps frequently, however at scale, with many users hitting the same API, 
>> and each has a different user-id, it will not help (unless I'm missing 
>> something).
>>
>
> As far as I understand, you are trying transform keys and not values. If 
> that supposition is correct, you have only a little subset of posible keys 
> memoized (the set of keys of your api). In case of user-id, you will 
> memoize the transformation of userId to user-id and for it you only need 
> one cache entry.
>
> Obviously, if you transform arbitrary user input, memoize is not a good 
> solution.
>
> My two cents!
>
> Cheers.
> Andrey
>
>>
>> Thanks.
>>
>> On Wednesday, January 7, 2015 1:36:53 AM UTC+2, Thomas Heller wrote:
>>>
>>> If you want to boost performance a bit just memoize the conversion 
>>> functions. Memoize makes you vurnable to exploits though, better use 
>>> something with WeakRefs if you convert anything from untrusted sources (eg. 
>>> guava CacheBuilder). But given your usecase this will probably be the 
>>> biggest gain, no matter what else you use to convert maps.
>>>
>>> https://gist.github.com/thheller/7ddc0371561deaf13e11
>>> "Elapsed time: 35.488 msecs"
>>>
>>> clojure.walk has keywordize-keys and stringify-keys, maybe a suitable 
>>> starting point for your implementation.
>>>
>>> HTH,
>>> /thomas
>>>
>>>
>>> On Tuesday, January 6, 2015 8:25:57 PM UTC+1, Noam Ben-Ari wrote:

 Hi,

 I've written a small library (1 ns, 100 lines) to transform nested maps 
 from "dash-case" keys to "camelCase" keys and back.

 The original use case was taking MySQL records that use camelCase field 
 names and convert them to dash-case so they don't stick out like a sore 
 thumb in my code. Similarly, when writing new records into the DB, I 
 wanted 
 to camelize them back before passing to JDBC.

 It should work on an arbitrarily deep nested map without blowing the 
 stack (using zipper).

 It is symmetric:

 (dasherize "clientOSVersion")
 => "client-OS-version"
 (camelize "client-OS-version")
 => "clientOSVersion"


 The library starts with defining functions that work on strings, then 
 ones that work on keywords (internally calling the string ones) and later 
 ones working on maps (that assume all keys are keywords and use the 
 keyword 
 functions). Lastly, the library defines protocols that will ease working 
 with different types.

 I would love any feedback, but especially:
 - is there any off-the-shelf library for this already?
 - I found zipper and regex to be really hurting performance here, 
 anything you would do differently to improve this?
 - anything about style... I'm writing Clojure for a year and didn't get 
 much code reviews.

 the gist is here:

 https://gist.github.com/NoamB/6e940775dfa63c73ee9c

 Thanks.

 PS - I took the string versions of the functions from cuerdas (
 https://github.com/funcool/cuerdas) and modified a bit, mainly to get 
 the symmetry working.

>>>  -- 
>> 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.
>>
>
>
>
> -- 
> Andrey Antukh - Андрей Антух - > / <
> ni...@niwi.be >
> http://www.niwi.be 
> 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 unsubscr

Re: camelize-dasherize - reinventing the wheel?

[Noam Ben-Ari]

Cool! I'm glad you found it useful :-)

On Wednesday, January 7, 2015 2:12:35 AM UTC+2, Andrey Antukh wrote:
>
> Hi!
>
> 2015-01-06 20:25 GMT+01:00 Noam Ben-Ari >:
>
>> Hi,
>>
>> I've written a small library (1 ns, 100 lines) to transform nested maps 
>> from "dash-case" keys to "camelCase" keys and back.
>>
>> The original use case was taking MySQL records that use camelCase field 
>> names and convert them to dash-case so they don't stick out like a sore 
>> thumb in my code. Similarly, when writing new records into the DB, I wanted 
>> to camelize them back before passing to JDBC.
>>
>> It should work on an arbitrarily deep nested map without blowing the 
>> stack (using zipper).
>>
>> It is symmetric:
>>
>> (dasherize "clientOSVersion")
>> => "client-OS-version"
>> (camelize "client-OS-version")
>> => "clientOSVersion"
>>
>>
>> The library starts with defining functions that work on strings, then 
>> ones that work on keywords (internally calling the string ones) and later 
>> ones working on maps (that assume all keys are keywords and use the keyword 
>> functions). Lastly, the library defines protocols that will ease working 
>> with different types.
>>
>> I would love any feedback, but especially:
>> - is there any off-the-shelf library for this already?
>> - I found zipper and regex to be really hurting performance here, 
>> anything you would do differently to improve this?
>> - anything about style... I'm writing Clojure for a year and didn't get 
>> much code reviews.
>>
>> the gist is here:
>>
>> https://gist.github.com/NoamB/6e940775dfa63c73ee9c
>>
>> Thanks.
>>
>> PS - I took the string versions of the functions from cuerdas (
>> https://github.com/funcool/cuerdas) and modified a bit, mainly to get 
>> the symmetry working.
>>
>
> I have ported some changes from your dasherize version to cuerdas. Thank 
> you very much for improved version.
>
> Cheers.
> Andrey
>  
>
>>  -- 
>> 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.
>>
>
>
>
> -- 
> Andrey Antukh - Андрей Антух - > / <
> ni...@niwi.be >
> http://www.niwi.be 
> 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: How to create a core.async channel that will drop messages if no consumer is currently reading from the channel?

[Yehonathan Sharvit]

Anyway, I was able to implement only one oof your suggested solutions. The 
tap/untsp one.




I was unable to implement a buffer of size 0.




I have tried, this:








(deftype NoBuffer [state]

  impl/UnblockingBuffer

  impl/Buffer

  (full? [this] false)

  (remove! [this])

  (add!* [this itm])

  clojure.lang.Counted

  (count [this] 0))









But it didn’t work at all!!




Please help.




Thanks.


—
Sent from Mailbox

On Wed, Jan 7, 2015 at 10:22 AM, Jozef Wagner 
wrote:

> From my understanding of how core.async is implemented, if channel has a 
> buffer, every message goes through it, regardless of whether there are 
> takes waiting or not. This is due to transducers that are applied only on 
> buffer items. None messages would thus pass through with a 0 size dropping 
> buffer.
> Jozef
> On Wednesday, January 7, 2015 6:39:47 AM UTC+1, Yehonathan Sharvit wrote:
>>
>> What is the reason for the dropping buffer not supporting size 0?
>>
>> Why the most trivial option of "no buffering" is not supported out of the 
>> box by core.async?
>>
>>
>>
>> On Thu, Jan 1, 2015 at 11:31 AM, Jozef Wagner > > wrote:
>>
>>> Implement a custom buffer type, or use mult. With mult, use tap/untap to 
>>> control reading. Items sent to mult are dropped if there are no taps.
>>>
>>> Jozef
>>>  
>>> On Mon, Dec 29, 2014 at 12:38 PM, Yehonathan Sharvit >> > wrote:
>>>
  Hello,


 I would like to create a channel that will drop messages if no consumer 
 is currently reading from the channel.

 Something like a channel with a dropping-buffer of size 0.
 The problem is that the API doesn't allow to create a dropping-buffer of 
 size 0.


  With the following code snippet, I would like the reader to read 
 nothing. 

 *(def c (create-unbuffered-chan)) *

  *(put! c :ok)*

  *(go (println (>>>  


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

>>>  
>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/6rYA9Ik7Aws/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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/6rYA9Ik7Aws/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Extend causes error in servlet container?

[peter . denhaan]

Those are some very comprehensive responses indeed; thanks Michael. It 
makes sense now. I'll keep an eye on lein-ring and clojure upgrades and in 
the mean time work around it.

Ghadi, you are of course right; thanks. I was playing around with extend so 
two types could share an implementation without adding glue. Direct 
implementation is probably more efficient, glue notwithstanding. And it 
doesn't run into CLJ-979 :)


On Tuesday, 6 January 2015 22:20:17 UTC, Michael Blume wrote:
>
> On further investigation, it looks like you're suffering from 
> http://dev.clojure.org/jira/browse/CLJ-979 -- if I apply the patch for 
> this bug to clojure and recompile your project everything works fine. It 
> looks like this patch *is* slated to make it into Clojure 1.7.0, so that 
> should also make your problem go away.
>
>>
  

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

[ANN] Sparkling, a Clojure-API to Apache Spark.

[chris_betz]

Hi,


we just released Sparkling (https://gorillalabs.github.io/sparkling/), our 
take on an API to Apache Spark.



With an eye on speed for very large amounts of data we improved clj-spark 
and flambo to get us the speed we need for our production environment.


See https://gorillalabs.github.io/sparkling/articles/getting_started.html 
for a quickstart or dive directly into our playground project by 
git clone https://github.com/gorillalabs/sparkling-getting-started.git



Happy hacking

Chris
(@gorillalabs_de )

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

[ANN] lentic 0.6: Multiple syntactic views over Emacs buffers

[Phillip Lord]

Lentic.el 0.6 is now available.

Lentic is an Emacs mode which supports multiple views over the same text. This
can be used for a form of literate programming. It has specific support for
Clojure which it can combine with either LaTeX, Asciidoc or Org-Mode.

Two lentic buffers, by default, the two share content but are otherwise
independent. Therefore, you can have two buffers open, each showing the
content in different modes; to switch modes, you simply switch buffers. The
content, location of point, and view are shared.

However, lentic also allows a bi-directional transformation between lentic
buffers -- the buffers can have different but related text. This allows, for
example, one buffer to contain an Emacs lisp file, while the other contains
the same text but with ";;" comment characters removed leaving the content in
org-mode, enabling a form of literate Emacs-Lisp programming with no change to
either org-mode or Emacs-Lisp. Ready made transformations are also available
for Clojure, latex and asciidoc.

Lentic is both configurable and extensible, using the EIEIO object system.

Lentic was previously known as Linked-Buffers.

The 0.6 release is heavily refactored from previous versions and includes an
incremental update feature which performs well, coping well with buffers of
3-4k lines in length.

Available on MELPA-stable, MELPA and Marmalade
https://github.com/phillord/lentic
http://www.russet.org.uk/blog/3035

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

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

Simplifying JS dependencies in ClojureScript

[David Nolen]

I believe the solution to this problem has been sitting right under our
noses for some time.

I've written up my thoughts here:
http://dev.clojure.org/jira/browse/CLJS-965

Feedback & patch welcome :)

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.

Potential bug in trampoline

[Hongseok Yang]

Hi,

While trying to use trampoline to optimise tail recursion in my Clojure 
project, I came across some strange behaviour of the trampoline function.

=> (defn f [g] (fn [k & args] #(k (apply g args
...
=> (trampoline (f list) println 1 2 3)
(# 1 2 3)
nil
=> (((f list) println 1 2 3))
(1 2 3)
nil

I think that (trampoline (f list) ...) and ((f list) ...) should give the 
same result.

In fact, I asked this question in Stackoverflow before. You can find some 
further discussion about this potential bug.

https://stackoverflow.com/questions/27819418/strange-behaviour-of-clojure-trampoline

Best wishes,
Hongseok

-- 
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: Potential bug in trampoline

[Nicola Mometto]

This looks like a serious bug in PersistentList, it has nothing to do
with trampoline.

Here's a minimal case:
user=> ((fn [& args] (apply (fn [a & b] (apply list b)) args)) 1 2 3)
(1 2 3)


Hongseok Yang writes:

> Hi,
>
> While trying to use trampoline to optimise tail recursion in my Clojure
> project, I came across some strange behaviour of the trampoline function.
>
> => (defn f [g] (fn [k & args] #(k (apply g args
> ...
> => (trampoline (f list) println 1 2 3)
> (# 1 2 3)
> nil
> => (((f list) println 1 2 3))
> (1 2 3)
> nil
>
> I think that (trampoline (f list) ...) and ((f list) ...) should give the
> same result.
>
> In fact, I asked this question in Stackoverflow before. You can find some
> further discussion about this potential bug.
>
> https://stackoverflow.com/questions/27819418/strange-behaviour-of-clojure-trampoline
>
> Best wishes,
> Hongseok

--

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

Prefer non-daemon threads in clojure.core.async/thread?

[Erik Price]

Howdy,

I see that the ThreadFactory used by clojure.core.async/thread‘s Executor
accepts a daemon parameter, to specify whether the threads are daemon or
not. But from reading the source, I don’t see any obvious way to specify
this for individual calls to clojure.core.async/thread. Is it possible?

Thanks!

e
​

-- 
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: Potential bug in trampoline

[Nicola Mometto]

I created http://dev.clojure.org/jira/browse/CLJ-1633 with a patch
implementing the proposed fix in the stackoverflow answer by the user "
d.j.sheldrick".

Hongseok Yang writes:

> Hi,
>
> While trying to use trampoline to optimise tail recursion in my Clojure
> project, I came across some strange behaviour of the trampoline function.
>
> => (defn f [g] (fn [k & args] #(k (apply g args
> ...
> => (trampoline (f list) println 1 2 3)
> (# 1 2 3)
> nil
> => (((f list) println 1 2 3))
> (1 2 3)
> nil
>
> I think that (trampoline (f list) ...) and ((f list) ...) should give the
> same result.
>
> In fact, I asked this question in Stackoverflow before. You can find some
> further discussion about this potential bug.
>
> https://stackoverflow.com/questions/27819418/strange-behaviour-of-clojure-trampoline
>
> Best wishes,
> Hongseok

--

-- 
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: A (foolish) plan to re-invent IO on top of core.async

[Paul deGrandis]

There was another discussion on this list regarding async IO and web 
servers.  It may be rather informative to you: 
https://groups.google.com/d/msg/clojure/rKqT13Ofy4k/H9xvkZA9Yy4J

To my knowledge, Pedestal is the only web library that let's you go async 
all the way down to the wire (potentially the latest Aleph also allows for 
this).  The benefit provided is that Pedestal manages the NIO integration 
directly with the container for you - optimized to the specific container.  
You may thumb through the implementation for some ideas.

You also have to be very mindful about back-pressure when using core.async 
in certain combinations.  Zach Tellman has covered the major points here: 
https://groups.google.com/d/msg/clojure/TVMQJwaij1U/dQxyBxxbIjQJ

Cheers,
Paul

-- 
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: Simplifying JS dependencies in ClojureScript

[Ivan L]

Sounds like this would work great for the majority where the lib is only js, 
but what about edge cases where a lib depends on a relative pathed resource 
like an image or css file?  Bootstrap comes to mind.

-- 
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 handle refactoring with TDD and mocking/stubbing

[Allen Rohner]

On Wednesday, December 31, 2014 8:48:27 AM UTC-6, Jonathon McKitrick wrote:
>
> I use TDD and mocking/stubbing (conjure) to test each layer of my code.  
> The problem is when I change the function signature and the tests do not 
> break, because the mocks/stubs do not know when their argument lists no 
> longer agree with the underlying function they are mocking.  Is there a way 
> to catch this?  Short of a test suite that eschews stubbing in favor of 
> full setup/teardown of DB data for each test?
>

I'll second the avoiding mocks, and avoiding midje votes.  

As for practical advice, I noticed that many times when I had 
mocking/stubbing problems in my tests, it was because my app was too 
tightly complected or stateful. I highly highly recommend using 
https://github.com/stuartsierra/component . Component strongly encourages 
you to program in a style where it's easy to e.g. replace your DB with an 
in-memory instance, and make it obvious which fns need DB access, 
encouraging you to split fns into pure and impure. Also, use core.async to 
communicate between separate components, where it makes sense. 

As a design rule, I prefer making I/O fns (things that hit the DB or a REST 
API), 'dumb', and perform all logic/processing in fns that just receive 
plain data, and return plain data. 

When you follow those two practices, your need for stubbing & mocking will 
drop significantly. As a bonus, your tests usually get faster!

Thanks,
Allen





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

maya - A DSL for math and numerical stuff

[Divyansh Prakash]

maya - A DSL for math and numerical stuff.

https://gist.github.com/divs1210/b4fcbd48d7697dfd8850#file-maya

-- 
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 handle refactoring with TDD and mocking/stubbing

[Sean Corfield]

On Jan 7, 2015, at 10:21 AM, Allen Rohner  wrote:
> As a design rule, I prefer making I/O fns (things that hit the DB or a REST 
> API), 'dumb', and perform all logic/processing in fns that just receive plain 
> data, and return plain data.

I’m curious: do you have wrapper functions for the DB reads/writes (i.e., a 
domain layer that just wraps the calls to your persistence library as well as 
managing the connections etc)?

Currently we primarily run Clojure as the embedded "Model" in a legacy MVC app 
so we can’t really use Stuart’s Component (at least, I don’t think we can, 
because we have a lot of entry points into the Clojure code) but we would like 
to figure out a cleaner way to separate DB access from our business logic on a 
per request basis...

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

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

maya - A DSL for math and numerical stuff

[Ivan L]

Lovely.  It also seems like a stones throw away to a succint let macro.

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