Clojure android activity?

[Mike Meyer]

Is there still any activity in the clojure-android space? The 
clojure-android mail list is largely inactive, seems like the developers of 
lein-droid haven't done anything in months (1.7.0-r4 is still used in the 
templates), and the numerous references If ind for an android-clojure web 
site are all dead.

That said, things do seem to mostly work for stock android. But accessing 
API's for android wear seems problematical 
(see https://github.com/clojure-android/lein-droid/issues/162 for my bug 
report).

-- 
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: error in nrepl

[Sean Corfield]

For several years I used Emacs on both Mac and Windows and I went through 
several configurations. I tried to build a config from scratch early on and 
gave up with that, so I switched to Emacs-Live from the Overtone folks, which 
worked well enough back in the day but had a strange view of packages and, 
ultimately, wasn’t being kept very up-to-date as CIDER was evolving so quickly… 
so I switched to Prelude, which is maintained by the same folks who are behind 
CIDER. That was the key to a slick, full-featured, up-to-date Emacs/CIDER setup 
for Clojure work, as far as I was concerned:

 

https://github.com/bbatsov/prelude

 

I was very happy with that setup.

 

That said, after seeing ProtoREPL demo’d at Conj 2017, I switched from Emacs to 
Atom/ProtoREPL and I’ve found that much nicer to work with overall (again, on 
Mac and Windows – I can’t speak to Atom on Linux). Initially, I had it 
configured with Emacs key-bindings to ease my transition, but I’ve recently 
(this week) uninstalled those packages.

 

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

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

 

On 6/23/17, 3:15 PM, "clojure@googlegroups.com on behalf of 
lawrence.krub...@gmail.com"  wrote:

 

 

Thank you. Maybe I can find some time to upgrade my whole Emacs setup next 
weekend. It is a bit out of date. 

 

I'm curious if folks think it is easier to work with Emacs on a Linux machine, 
or on a Mac? 

 



On Friday, June 23, 2017 at 5:39:42 PM UTC-4, Kevin Baldor wrote:

Have you tried following the instructions at 
http://www.braveclojure.com/basic-emacs/ ?

It's a bit heavy-handed (replacing your entire .emacs directory), but it might 
give you a starting point to figure out how to integrate it into your emacs 
setup.

 

On Fri, Jun 23, 2017 at 4:36 PM,  wrote:

 

Yes, sadly, I've never gotten Cider to work with Emacs. I keep thinking someday 
I'll take a weekend and work through all the errors and get it working, but I 
never seem to find the time. So I keep working with an old version of nrepl. 
But I take it, from your answer, you think this error would vanish if I 
upgraded to Cider? 





On Friday, June 23, 2017 at 5:15:09 PM UTC-4, James Reeves wrote:

nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a very 
old version of Cider.

 

On 23 June 2017 at 21:29,  wrote:

I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. I'm 
iterating over a dataset from mysql. My code is very simple, I'm just trying to 
count the words: 

 

(reduce 

 

(fn [map-of-word-count next-name] 

(let [

words (clojure.string/split next-name #"\s") 

map-of-names-words-with-count (frequencies words)

] 

(println map-of-names-words-with-count)

(merge-with + map-of-word-count map-of-names-words-with-count)

)

) 

{} 

names)

 

I keep getting this message:

 

 

error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1

error in process filter: Cannot decode object: 1

Error running timer `jit-lock-stealth-fontify': (error "Variable binding depth 
exceeds max-specpdl-size")

timer-relative-time: Variable binding depth exceeds max-specpdl-size

 

 

Does anyone know what this means? 

 

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



 

-- 

James Reeves

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

 

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

Re: Stubbornly eager results in clojure.java.jdbc

[Luke Burton]

> On Jun 23, 2017, at 2:26 PM, Sean Corfield  wrote:
> 
> This is excellent news as far as I’m concerned because it shows there’s no 
> specific bug in clojure.java.jdbc that is fundamentally causing the OOM 
> problem you’re seeing!

I'm relieved too, given that I use clojure.java.jdbc extensively :) 

> (that’s not to say there aren’t _other_ bugs in clojure.java.jdbc and the 
> idea of the reducible result set definitely has appeal, which is why there’s 
> a JIRA issue for it, but it doesn’t appear to be necessary in this instance).

I've been trying to find a use case for the reducible result set, other than 
avoiding the memory issues I was experiencing, and there aren't too many that 
spring to mind. Probably the main one is mentioned in the JIRA, which is 
cleaning up clojure.java.jdbc internals. You could drop the need for sprinkling 
 ^:once everywhere.

One idea: as we have the constraint that regular result sets cannot be passed 
around, and must be consumed entirely in the context of their JDBC connection, 
perhaps they could be wrapped somewhat like `eduction` and represent the 
'recipe' for a query. At the start of reduce/iterator it would attempt to 
execute the query it owns. That would be kind of handy. Such a thing could be 
passed around to reduce or transduce, and would implement IReduceInit and 
clojure.lang.Sequential (apropos post from Alex: 
http://insideclojure.org/2015/01/18/reducible-generators/)

Another option that achieves similar goals is simply feeding the results to a 
channel. I seem to code this up myself on every new project :) 
clojure.java.jdbc internals could handle the bookkeeping of keeping the 
ResultSet alive until fully consumed, at which point the channel is closed. I'm 
sure this isn't the first such request, and that there are probably good 
reasons for it not having happened as yet.

Luke.

-- 
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: error in nrepl

[Kevin Baldor]

It's much easier on Linux, I wish that I had taken notes when I set up my
Mac. But after a few false starts, it's working well for me. My mac is at
home, so I'll have to wait until I get there to see if I can figure out
what version I'm running and from where I downloaded it. There's a pretty
good chance that it's just the latest from *http://emacsformacosx.com
 *with the .emacs directory from
https://github.com/flyingmachine/emacs-for-clojure/archive/book1.zip.

On Fri, Jun 23, 2017 at 5:14 PM,  wrote:

>
> Thank you. Maybe I can find some time to upgrade my whole Emacs setup next
> weekend. It is a bit out of date.
>
> I'm curious if folks think it is easier to work with Emacs on a Linux
> machine, or on a Mac?
>
>
>
> On Friday, June 23, 2017 at 5:39:42 PM UTC-4, Kevin Baldor wrote:
>>
>> Have you tried following the instructions at
>> http://www.braveclojure.com/basic-emacs/ ?
>>
>> It's a bit heavy-handed (replacing your entire .emacs directory), but it
>> might give you a starting point to figure out how to integrate it into your
>> emacs setup.
>>
>> On Fri, Jun 23, 2017 at 4:36 PM,  wrote:
>>
>>>
>>> Yes, sadly, I've never gotten Cider to work with Emacs. I keep thinking
>>> someday I'll take a weekend and work through all the errors and get it
>>> working, but I never seem to find the time. So I keep working with an old
>>> version of nrepl. But I take it, from your answer, you think this error
>>> would vanish if I upgraded to Cider?
>>>
>>>
>>>
>>>
>>> On Friday, June 23, 2017 at 5:15:09 PM UTC-4, James Reeves wrote:

 nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a
 very old version of Cider.

 On 23 June 2017 at 21:29,  wrote:

> I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl.
> I'm iterating over a dataset from mysql. My code is very simple, I'm just
> trying to count the words:
>
> (reduce
>
> (fn [map-of-word-count next-name]
> (let [
> words (clojure.string/split next-name #"\s")
> map-of-names-words-with-count (frequencies words)
> ]
> (println map-of-names-words-with-count)
> (merge-with + map-of-word-count map-of-names-words-with-count)
> )
> )
> {}
> names)
>
> I keep getting this message:
>
>
> error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
> error in process filter: Cannot decode object: 1
> Error running timer `jit-lock-stealth-fontify': (error "Variable
> binding depth exceeds max-specpdl-size")
> timer-relative-time: Variable binding depth exceeds max-specpdl-size
>
>
> Does anyone know what this means?
>
> --
> 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.
>



 --
 James Reeves
 booleanknot.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.
>>>
>>
>> --
> 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 

Re: error in nrepl

[lawrence . krubner]

Thank you. Maybe I can find some time to upgrade my whole Emacs setup next 
weekend. It is a bit out of date. 

I'm curious if folks think it is easier to work with Emacs on a Linux 
machine, or on a Mac? 



On Friday, June 23, 2017 at 5:39:42 PM UTC-4, Kevin Baldor wrote:
>
> Have you tried following the instructions at 
> http://www.braveclojure.com/basic-emacs/ ?
>
> It's a bit heavy-handed (replacing your entire .emacs directory), but it 
> might give you a starting point to figure out how to integrate it into your 
> emacs setup.
>
> On Fri, Jun 23, 2017 at 4:36 PM,  
> wrote:
>
>>
>> Yes, sadly, I've never gotten Cider to work with Emacs. I keep thinking 
>> someday I'll take a weekend and work through all the errors and get it 
>> working, but I never seem to find the time. So I keep working with an old 
>> version of nrepl. But I take it, from your answer, you think this error 
>> would vanish if I upgraded to Cider? 
>>
>>
>>
>>
>> On Friday, June 23, 2017 at 5:15:09 PM UTC-4, James Reeves wrote:
>>>
>>> nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a 
>>> very old version of Cider.
>>>
>>> On 23 June 2017 at 21:29,  wrote:
>>>
 I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. 
 I'm iterating over a dataset from mysql. My code is very simple, I'm just 
 trying to count the words: 

 (reduce 

 (fn [map-of-word-count next-name] 
 (let [
 words (clojure.string/split next-name #"\s") 
 map-of-names-words-with-count (frequencies words)
 ] 
 (println map-of-names-words-with-count)
 (merge-with + map-of-word-count map-of-names-words-with-count)
 )
 ) 
 {} 
 names)

 I keep getting this message:


 error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
 error in process filter: Cannot decode object: 1
 Error running timer `jit-lock-stealth-fontify': (error "Variable 
 binding depth exceeds max-specpdl-size")
 timer-relative-time: Variable binding depth exceeds max-specpdl-size


 Does anyone know what this means? 

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

>>>
>>>
>>>
>>> -- 
>>> James Reeves
>>> booleanknot.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.
>>
>
>

-- 
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: error in nrepl

[Kevin Baldor]

Have you tried following the instructions at
http://www.braveclojure.com/basic-emacs/ ?

It's a bit heavy-handed (replacing your entire .emacs directory), but it
might give you a starting point to figure out how to integrate it into your
emacs setup.

On Fri, Jun 23, 2017 at 4:36 PM,  wrote:

>
> Yes, sadly, I've never gotten Cider to work with Emacs. I keep thinking
> someday I'll take a weekend and work through all the errors and get it
> working, but I never seem to find the time. So I keep working with an old
> version of nrepl. But I take it, from your answer, you think this error
> would vanish if I upgraded to Cider?
>
>
>
>
> On Friday, June 23, 2017 at 5:15:09 PM UTC-4, James Reeves wrote:
>>
>> nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a
>> very old version of Cider.
>>
>> On 23 June 2017 at 21:29,  wrote:
>>
>>> I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl.
>>> I'm iterating over a dataset from mysql. My code is very simple, I'm just
>>> trying to count the words:
>>>
>>> (reduce
>>>
>>> (fn [map-of-word-count next-name]
>>> (let [
>>> words (clojure.string/split next-name #"\s")
>>> map-of-names-words-with-count (frequencies words)
>>> ]
>>> (println map-of-names-words-with-count)
>>> (merge-with + map-of-word-count map-of-names-words-with-count)
>>> )
>>> )
>>> {}
>>> names)
>>>
>>> I keep getting this message:
>>>
>>>
>>> error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
>>> error in process filter: Cannot decode object: 1
>>> Error running timer `jit-lock-stealth-fontify': (error "Variable binding
>>> depth exceeds max-specpdl-size")
>>> timer-relative-time: Variable binding depth exceeds max-specpdl-size
>>>
>>>
>>> Does anyone know what this means?
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> James Reeves
>> booleanknot.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.
>

-- 
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: error in nrepl

[lawrence . krubner]

On Friday, June 23, 2017 at 4:29:24 PM UTC-4, lawrence...@gmail.com wrote:
>
> I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. I'm 
> iterating over a dataset from mysql. My code is very simple, I'm just 
> trying to count the words: 
>
> (reduce 
>
> (fn [map-of-word-count next-name] 
> (let [
> words (clojure.string/split next-name #"\s") 
> map-of-names-words-with-count (frequencies words)
> ] 
> (println map-of-names-words-with-count)
> (merge-with + map-of-word-count map-of-names-words-with-count)
> )
> ) 
> {} 
> names)
>
> I keep getting this message:
>
>
> error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
> error in process filter: Cannot decode object: 1
> Error running timer `jit-lock-stealth-fontify': (error "Variable binding 
> depth exceeds max-specpdl-size")
> timer-relative-time: Variable binding depth exceeds max-specpdl-size
>
>
> Does anyone know what this means? 
>
>

-- 
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: error in nrepl

[lawrence . krubner]

Yes, sadly, I've never gotten Cider to work with Emacs. I keep thinking 
someday I'll take a weekend and work through all the errors and get it 
working, but I never seem to find the time. So I keep working with an old 
version of nrepl. But I take it, from your answer, you think this error 
would vanish if I upgraded to Cider? 




On Friday, June 23, 2017 at 5:15:09 PM UTC-4, James Reeves wrote:
>
> nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a 
> very old version of Cider.
>
> On 23 June 2017 at 21:29,  wrote:
>
>> I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. I'm 
>> iterating over a dataset from mysql. My code is very simple, I'm just 
>> trying to count the words: 
>>
>> (reduce 
>>
>> (fn [map-of-word-count next-name] 
>> (let [
>> words (clojure.string/split next-name #"\s") 
>> map-of-names-words-with-count (frequencies words)
>> ] 
>> (println map-of-names-words-with-count)
>> (merge-with + map-of-word-count map-of-names-words-with-count)
>> )
>> ) 
>> {} 
>> names)
>>
>> I keep getting this message:
>>
>>
>> error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
>> error in process filter: Cannot decode object: 1
>> Error running timer `jit-lock-stealth-fontify': (error "Variable binding 
>> depth exceeds max-specpdl-size")
>> timer-relative-time: Variable binding depth exceeds max-specpdl-size
>>
>>
>> Does anyone know what this means? 
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> James Reeves
> booleanknot.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: Stubbornly eager results in clojure.java.jdbc

[Sean Corfield]

This is excellent news as far as I’m concerned because it shows there’s no 
specific bug in clojure.java.jdbc that is fundamentally causing the OOM problem 
you’re seeing!

 

(that’s not to say there aren’t _other_ bugs in clojure.java.jdbc and the idea 
of the reducible result set definitely has appeal, which is why there’s a JIRA 
issue for it, but it doesn’t appear to be necessary in this instance).

 

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

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

 

On 6/23/17, 2:03 PM, "Luke Burton"  wrote:

 

 

Well, shoot. I went back and revisited this because it was bugging me … I 
looked at the code generated with and without usage of ^:once fn* and that led 
me down the right path. TL;DR – the problem appears to be locals clearing 
always disabled in Cursive REPL. This is just my current hypothesis based on 
testing and not 100% certainty. I guess I'll put this in a blog post or 
something once I validate this hypothesis and get some feedback from Colin 
(1.6.0-eap1-2017.2 if you're watching, Colin ;)

 

For mailing list posterity, here's the difference, using Lubomir's examples and 
the decompiler in IntelliJ, between ^:once fn* and regular fn (or fn*)

 

Note the inner-bad function:

 

(defn bad []

  (let [x (for [n (range)] (make-array Object 1)), f (fn* inner-bad [] (nth 
x 1e6))] (f)))

 

The inner-bad class generated is:

 

public final class core$bad$inner_bad__431 extends AFunction {
  Object x;
  public static final Object const__1 = 100.0D;

  public core$bad$inner_bad__431(Object var1) {
this.x = var1;
  }

  public Object invoke() {
return RT.nth(this.x, RT.intCast((Number)const__1));
  }
}

 

Note the inner-good function:

 

(defn good []

  (let [x (for [n (range)] (make-array Object 1)), f (^:once fn* inner-good 
[] (nth x 1e6))] (f)))

 

The inner-good class generated is:

 

public final class core$good$inner_good__414 extends AFunction {

  Object x;

  public static final Object const__1 = 100.0D;

 

  public core$good$inner_good__414(Object var1) {

this.x = var1;

  }

 

  public Object invoke() {

Object var1 = this.x;

this.x = null;

return RT.nth(var1, RT.intCast((Number)const__1));

  }

}


You can see pretty clearly the difference is that each time the function is 
invoked in the "good" case, the local reference to this.x is cleared, meaning 
this function really is only good for one invocation. No wonder it's 
undocumented!

 

=> (let [z 1000

  f (^:once fn* one-shot [x] (println x))

  p (f z)]

  (p)

  (p))

 

1000

CompilerException java.lang.NullPointerException

 

Anyway, I saw this and jumped to the thought: "locals!! I have fallen victim to 
uncleared locals!!"

 

So I started some tests, going back to my previous code and trying the JDBC 
result set that wasn't being lazy before. I put the test1 invocation into -main 
and tried:

· lein run – no OOM.

· lein repl, then invoking (-main) – no OOM.

· lein repl :headless, then connecting via lein repl :connect 
"localhost:54321" and invoke (-main) – no OOM.

· Cursive nREPL via Leiningen (locals clearing, debug REPL) – OOM!!

· Cursive nREPL via Leiningen (no locals clearing, debug REPL) – OOM!!

· Cursive nREPL via Leiningen (no locals clearing, regular REPL) – OOM!!

· Cursive nREPL via Leiningen (no locals clearing, regular REPL) – OOM!!

· lein run, with -Dclojure.compiler.disable-locals-clearing=true – OOM!!

I feel slightly better for knowing I can point the finger of blame at disabled 
locals clearing. It would be great to have this fixed in Cursive, considering 
that I run quite memory intensive applications and I'm sure locals clearing 
being permanently disabled has caused me to engineer around some non-existent 
problems. I have not tested CIDER or any other REPL, YMMV.

 

Luke.

 

 

On Jun 20, 2017, at 11:26 AM, Lubomir Konstantinov  wrote:

 

^{:once true}


should deal with this. Try the following simplified test case with and without 
it:

 

(defn query [result-fn]

  (let [x (for [n (range 1e6)] (make-array Object 10)) 

f (^:once fn* [rs] (result-fn rs))] (f x)))

 

(defn testq []

  (let [myfn (fn [rs] (doseq [r rs] nil))]

(query myfn)))




On Tuesday, 20 June 2017 03:47:45 UTC+3, James Reeves wrote:

This might be a bug in java.jdbc. The code that passes the result set seq to 
the function is:

 

(^{:once true} fn* [rset]

  ((^{:once true} fn* [rs]

 (result-set-fn (if as-arrays?

  (cons (first rs)

(map row-fn (rest rs)))

  (map row-fn rs

   (result-set-seq rset opts)))

 

I'm wondering if this function holds onto the head of the seq, since it's bound 
to "rs".

 

Re: error in nrepl

[James Reeves]

nrepl-jack-in? Do you mean cider-jack-in? AFAIK nrepl-jack-in is from a
very old version of Cider.

On 23 June 2017 at 21:29,  wrote:

> I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. I'm
> iterating over a dataset from mysql. My code is very simple, I'm just
> trying to count the words:
>
> (reduce
>
> (fn [map-of-word-count next-name]
> (let [
> words (clojure.string/split next-name #"\s")
> map-of-names-words-with-count (frequencies words)
> ]
> (println map-of-names-words-with-count)
> (merge-with + map-of-word-count map-of-names-words-with-count)
> )
> )
> {}
> names)
>
> I keep getting this message:
>
>
> error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
> error in process filter: Cannot decode object: 1
> Error running timer `jit-lock-stealth-fontify': (error "Variable binding
> depth exceeds max-specpdl-size")
> timer-relative-time: Variable binding depth exceeds max-specpdl-size
>
>
> Does anyone know what this means?
>
> --
> 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.
>



-- 
James Reeves
booleanknot.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: Stubbornly eager results in clojure.java.jdbc

[Luke Burton]

Well, shoot. I went back and revisited this because it was bugging me … I 
looked at the code generated with and without usage of ^:once fn* and that led 
me down the right path. TL;DR – the problem appears to be locals clearing 
always disabled in Cursive REPL. This is just my current hypothesis based on 
testing and not 100% certainty. I guess I'll put this in a blog post or 
something once I validate this hypothesis and get some feedback from Colin 
(1.6.0-eap1-2017.2 if you're watching, Colin ;)

For mailing list posterity, here's the difference, using Lubomir's examples and 
the decompiler in IntelliJ, between ^:once fn* and regular fn (or fn*)

Note the inner-bad function:

(defn bad []
  (let [x (for [n (range)] (make-array Object 1)), f (fn* inner-bad [] (nth 
x 1e6))] (f)))

The inner-bad class generated is:

public final class core$bad$inner_bad__431 extends AFunction {
  Object x;
  public static final Object const__1 = 100.0D;

  public core$bad$inner_bad__431(Object var1) {
this.x = var1;
  }

  public Object invoke() {
return RT.nth(this.x, RT.intCast((Number)const__1));
  }
}

Note the inner-good function:

(defn good []
  (let [x (for [n (range)] (make-array Object 1)), f (^:once fn* inner-good 
[] (nth x 1e6))] (f)))

The inner-good class generated is:

public final class core$good$inner_good__414 extends AFunction {
  Object x;
  public static final Object const__1 = 100.0D;

  public core$good$inner_good__414(Object var1) {
this.x = var1;
  }

  public Object invoke() {
Object var1 = this.x;
this.x = null;
return RT.nth(var1, RT.intCast((Number)const__1));
  }
}

You can see pretty clearly the difference is that each time the function is 
invoked in the "good" case, the local reference to this.x is cleared, meaning 
this function really is only good for one invocation. No wonder it's 
undocumented!

=> (let [z 1000
  f (^:once fn* one-shot [x] (println x))
  p (f z)]
  (p)
  (p))

1000
CompilerException java.lang.NullPointerException

Anyway, I saw this and jumped to the thought: "locals!! I have fallen victim to 
uncleared locals!!"


So I started some tests, going back to my previous code 
 and trying 
the JDBC result set that wasn't being lazy before. I put the test1 invocation 
into -main and tried:
lein run – no OOM.
lein repl, then invoking (-main) – no OOM.
lein repl :headless, then connecting via lein repl :connect "localhost:54321" 
and invoke (-main) – no OOM.
Cursive nREPL via Leiningen (locals clearing, debug REPL) – OOM!!
Cursive nREPL via Leiningen (no locals clearing, debug REPL) – OOM!!
Cursive nREPL via Leiningen (no locals clearing, regular REPL) – OOM!!
Cursive nREPL via Leiningen (no locals clearing, regular REPL) – OOM!!
lein run, with -Dclojure.compiler.disable-locals-clearing=true – OOM!!
I feel slightly better for knowing I can point the finger of blame at disabled 
locals clearing. It would be great to have this fixed in Cursive, considering 
that I run quite memory intensive applications and I'm sure locals clearing 
being permanently disabled has caused me to engineer around some non-existent 
problems. I have not tested CIDER or any other REPL, YMMV.

Luke.


> On Jun 20, 2017, at 11:26 AM, Lubomir Konstantinov  wrote:
> 
> ^{:once true}
> 
> should deal with this. Try the following simplified test case with and 
> without it:
> 
> (defn query [result-fn]
>   (let [x (for [n (range 1e6)] (make-array Object 10)) 
> f (^:once fn* [rs] (result-fn rs))] (f x)))
> 
> (defn testq []
>   (let [myfn (fn [rs] (doseq [r rs] nil))]
> (query myfn)))
> 
> 
> 
> On Tuesday, 20 June 2017 03:47:45 UTC+3, James Reeves wrote:
> This might be a bug in java.jdbc. The code that passes the result set seq to 
> the function is:
> 
> (^{:once true} fn* [rset]
>   ((^{:once true} fn* [rs]
>  (result-set-fn (if as-arrays?
>   (cons (first rs)
> (map row-fn (rest rs)))
>   (map row-fn rs
>(result-set-seq rset opts)))
> 
> I'm wondering if this function holds onto the head of the seq, since it's 
> bound to "rs".
> 
> On 20 June 2017 at 00:20, Luke Burton > wrote:
> 
> Anyone have any insights here? Really the most important thing I'm trying to 
> learn is 2) how to identify when a lazy seq head is being retained, other 
> than waiting for it to become bad enough that your program OOMs.
> 
> 
>> On Jun 16, 2017, at 6:14 PM, Luke Burton > wrote:
>> 
>> 
>> Riddle me this:
>> 
>> https://gist.github.com/hagmonk/a75621b143501966c22f53ed1e2bc36e 
>> 
>> 
>> Wherein I synthesize a large table in Postgres, then attempt to lazily load 
>> the table, discarding each row as I receive it. I tried *many* permutations 
>> and experiments, but settled on these two 

error in nrepl

[lawrence . krubner]

I'm using Emacs on my Mac. I ran "nrepl-jack-in" to load up the repl. I'm 
iterating over a dataset from mysql. My code is very simple, I'm just 
trying to count the words: 

(reduce 

(fn [map-of-word-count next-name] 
(let [
words (clojure.string/split next-name #"\s") 
map-of-names-words-with-count (frequencies words)
] 
(println map-of-names-words-with-count)
(merge-with + map-of-word-count map-of-names-words-with-count)
)
) 
{} 
names)

I keep getting this message:


error in process filter: nrepl-bdecode-buffer: Cannot decode object: 1
error in process filter: Cannot decode object: 1
Error running timer `jit-lock-stealth-fontify': (error "Variable binding 
depth exceeds max-specpdl-size")
timer-relative-time: Variable binding depth exceeds max-specpdl-size


Does anyone know what this means? 

-- 
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: Stubbornly eager results in clojure.java.jdbc

[Luke Burton]

Postgres, as mentioned in the mail and the linked source code. The problem at 
this point doesn't appear to be options given to the driver, since I show two 
implementations using the same driver options. One processes the results 
lazily, one does not. 

Now, I'm calling two different methods in clojure.java.jdbc, so there's a 
chance the driver options aren't being propagated correctly to the 
implementation in one of the methods. It's already soaked up way too much of my 
time (and I like the elegance of the reducible-result-set alternative) so I 
haven't revisited the code to explore further.


> On Jun 23, 2017, at 7:38 AM, r0man  > wrote:
> 
> Hi Luke,
> 
> which database are you using? I had the same issue with MySQL recently. At 
> the end I got it working with clojure.java.jdbc.
> I don't have the code at hand, but according to the MySQL docs you have to 
> set the fetch size to Integer.MIN_VALUE.
> 
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html
>  
> 
> 
> r0man
> 
> On Saturday, June 17, 2017 at 3:15:13 AM UTC+2, Luke Burton wrote:
> 
> Riddle me this:
> 
> https://gist.github.com/hagmonk/a75621b143501966c22f53ed1e2bc36e 
> 
> 
> Wherein I synthesize a large table in Postgres, then attempt to lazily load 
> the table, discarding each row as I receive it. I tried *many* permutations 
> and experiments, but settled on these two tests to illustrate my point. Which 
> is that I simply can't get it to work with clojure.java.jdbc.
> 
> test1, according to all my research and reading of the source code involved, 
> should consume the query results lazily. It does not, and I can't for the 
> life of me figure out why. Traffic starts to stream in, and the heap is 
> overwhelmed almost immediately. I've deliberately set the heap to 1 GB.
> 
> test2 uses a technique I borrowed wholesale from Ghadi Shayban in JDBC-99 
> ,
>  which is to have ResultSet implement IReduceInit. It consumes a nominal 
> amount of memory. I've verified it's actually doing something by putting 
> counters in, and using YourKit to watch about 20 MB/s of traffic streaming 
> into the JVM. It's brilliant, it doesn't even break 200 MB total heap usage.
> 
> I used YourKit to track where the memory is being retained for test1. 
> Initially I made the mistake of not setting the fetchSize, so I saw an 
> ArrayList inside the driver holding the reference. The driver documentation 
>  confirms that 
> autoCommit must be disabled and the fetchSize set to some non-zero number.
> 
> After making that change, YourKit confirmed that the GC root holding all the 
> memory was the stack local variable "rs". At least I think it did, as a 
> non-expert in this domain. I tried disassembling the functions using 
> no.disassemble and the IntelliJ decompiler but I'm not really at the point 
> where I understand what to look for.
> 
> So my questions are:
> 
> 1) what am I doing wrong with clojure.java.jdbc?
> 
> Note some things I've already tried:
> 
> * using row-fn instead of result-set-fn
> * using prepared statements
> * explicitly setting auto-commit false on the connection
> * declaring my result-set-fn with (^{:once true} *fn […]) (I did not see a 
> change in the disassembly when using this)
> * probably other things I am forgetting
> 
> 2) in these situations where you suspect that the head of a lazy sequence is 
> being retained, how do you reason about it? I'm kind of lucky this one blew 
> the heap so quickly, who knows how much of my production code might burning 
> memory unnecessarily but not quite as fatally. Do you disassemble the 
> functions and observe some smoking gun? How do you peek under the covers to 
> see where the problem is? 
> 
> Luke.
> 
> -- 
> 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 
> 

Re: Stubbornly eager results in clojure.java.jdbc

[r0man]

Hi Luke,

which database are you using? I had the same issue with MySQL recently. At 
the end I got it working with clojure.java.jdbc.
I don't have the code at hand, but according to the MySQL docs you have to 
set the fetch size to Integer.MIN_VALUE.

https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html

r0man

On Saturday, June 17, 2017 at 3:15:13 AM UTC+2, Luke Burton wrote:
>
>
> Riddle me this:
>
> https://gist.github.com/hagmonk/a75621b143501966c22f53ed1e2bc36e
>
> Wherein I synthesize a large table in Postgres, then attempt to lazily 
> load the table, discarding each row as I receive it. I tried *many* 
> permutations and experiments, but settled on these two tests to illustrate 
> my point. Which is that I simply can't get it to work with 
> clojure.java.jdbc.
>
> test1, according to all my research and reading of the source code 
> involved, should consume the query results lazily. It does not, and I can't 
> for the life of me figure out why. Traffic starts to stream in, and the 
> heap is overwhelmed almost immediately. I've deliberately set the heap to 1 
> GB.
>
> test2 uses a technique I borrowed wholesale from Ghadi Shayban in JDBC-99 
> ,
>  
> which is to have ResultSet implement IReduceInit. It consumes a nominal 
> amount of memory. I've verified it's actually doing something by putting 
> counters in, and using YourKit to watch about 20 MB/s of traffic streaming 
> into the JVM. It's brilliant, it doesn't even break 200 MB total heap usage.
>
> I used YourKit to track where the memory is being retained for test1. 
> Initially I made the mistake of not setting the fetchSize, so I saw an 
> ArrayList inside the driver holding the reference. The driver 
> documentation  
> confirms 
> that autoCommit must be disabled and the fetchSize set to some non-zero 
> number.
>
> After making that change, YourKit confirmed that the GC root holding all 
> the memory was the stack local variable "rs". At least I think it did, as a 
> non-expert in this domain. I tried disassembling the functions using 
> no.disassemble and the IntelliJ decompiler but I'm not really at the point 
> where I understand what to look for.
>
> So my questions are:
>
> 1) what am I doing wrong with clojure.java.jdbc?
>
> Note some things I've already tried:
>
> * using row-fn instead of result-set-fn
> * using prepared statements
> * explicitly setting auto-commit false on the connection
> * declaring my result-set-fn with (^{:once true} *fn […]) (I did not see a 
> change in the disassembly when using this)
> * probably other things I am forgetting
>
> 2) in these situations where you suspect that the head of a lazy sequence 
> is being retained, how do you reason about it? I'm kind of lucky this one 
> blew the heap so quickly, who knows how much of my production code might 
> burning memory unnecessarily but not quite as fatally. Do you disassemble 
> the functions and observe some smoking gun? How do you peek under the 
> covers to see where the problem is? 
>
> Luke.
>

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