Re: interp2 for Clojure

[Charles Harvey III]

These are both fantastic. It has been 25 years since I had a serious math 
class (no Stats either - Set Theory, Category Theory), so this has taken me 
a few afternoons to wrap my head around.

Spline? Cubic? Bicubic? RBF? Shephard? And that's just interpolation.

Its weird that the Commons Math doesn't seem to have anything that is 
Linear or Bilinear. Everything is Bicubic.

Fastmath is a nice wrapper over all of these things. The bilinear function 
wraps the BilinearInterpolation class from Smile. Incanter has an 
interpolate-grid function as well, but Incanter hasn't been touched for a 
while and Fastmath has a lot of updates.

More interesting is that I am not using this for image processing. It is 
for Computer Assisted Testing. If you get an question right or wrong, you 
get a different next question. But the next isn't just based off 
right/wrong, it has a lot of other input. They are essentially doing 
Nearest Neighbor but want it to be smoother. I wonder if doing Bicubic 
would give the same results as Bilinear.

Thanks so much for the pointers, I really appreciate it.



Charlie


On Tuesday, January 14, 2020 at 4:25:47 PM UTC-5, Tomasz Sulej wrote:
>
> Check out my fastmath library: 
> https://generateme.github.io/fastmath/fastmath.interpolation.html

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/8de99d4a-35c7-4961-9cc3-dc063fc3e8ef%40googlegroups.com.

interp2 for Clojure

[Charles Harvey III]

Greetings.
A current project I am working on needs to run a Bilinear Interpolation. R 
and Python (SciPy) have functions for this: interp2. I think this is just a 
fancy name for particular matrix multiplication. But I'm not really sure.
Can I cobble this together in core.matrix? Incanter? Neanderthal? I know 
the question is a little broad, I'm just at the beginning of this.

Thanks.

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

re-frame and material-ui

[Charles Harvey III]

Greetings,
I am pretty new to ClojureScript and re-frame but it all feels right. I am 
trying to replicate a small React project and show just how much more 
awesome it will be. But it is using material-ui. I'm sure this is a normal 
thing. There was even a library a few years ago integrating it into 
ClojureScript. Alas, it is many many versions behind - which is ok, these 
things happen, maintaining connectors is a tough business.

Is anyone else using material-ui in their re-frame (or any other cljs 
framework) project? Is it difficult to integrate the two? What is the 
general experience of adding some React-based widget into a cljs project?

Thanks.


Charlie


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/8bf23965-9341-4a12-a871-eab4f2a5bef5%40googlegroups.com.

Re: Am I being stupid regarding how much memory I use?

[Charles Harvey III]

Did you pull all 4 million at once? Are you doing a huge sorting operation 
over millions of records in memory? Then yes, you are going to use a lot of 
memory. There aren't many ways around it.

Eclipse Collections (and others) have smaller collections than java.util. 
Maybe they make a difference in your memory footprint.

Do like Gary said, use the database for that stuff. Why do "order by" and 
"group by" in java with lousy syntax when you can do it in the database? 
I'm not sure what your data set looks like though. Are these "documents" 
large blobs of text in a simple table? If so, then you are out of luck.

How to scale? Isn't that the question of our time?

Onyx or Storm could probably get you there. I think Spark can too, it just 
needs more homework. Spark goes the other direction from Hadoop because it 
assumes you will have a lot of RAM. 10GB is not that much really. A lot of 
problems go away if "your data fits in RAM". Can you get lots of RAM? You 
can get 4TB from AWS now.

https://www.awsforbusiness.com/aws-launches-biggest-instance-yet-4tb-ram/

Terabytes.

So all those in-memory thingies will work on a machine with 500GB or 1TB. 
Vertica! MemSQL! Spark! Apache Ignite! Hazelcast! All of these claim to be 
an "in memory data grid." You shove data in and run queries. Maybe you can 
get rid of MySQL? Maybe you can get rid of ES? If you can turn on the 
machine doing the work for a short amount of time maybe the cost will make 
sense. But keep in mind that RAM is getting pretty cheap and maybe you can 
scale up instead of scaling out. Scaling out gets hard pretty fast.





On Sunday, November 12, 2017 at 8:18:50 AM UTC-5, lawrence...@gmail.com 
wrote:
>
> I recently worked on a minor project that nevertheless needed to use 10 
> gigs of RAM. It ran on a reasonably powerful server, yet it taxed that 
> server. And I wondered, how are people scaling up such processes? If my 
> approach was naive, what does the less naive approach look like? 
>
> I wrote a simple app that pulled data from a MySQL database, denormalized 
> it, and then stored it in ElasticSearch. It pulled about 4 million 
> documents from MySQL. Parts of the data needed to be built up into complex 
> structures (maps, vectors) before being put into ElasticSearch. In the end, 
> the 4 million rows from MySQL became 1.5 million documents in ElasticSearch.
>
> I was wondering, what if, instead of 4 million documents, I needed to 
> process 400 million documents? I assume I would have to distribute the work 
> over several machines? I'm curious what are some of the most common routes 
> for doing so? Would this be the situation where people would start to use 
> something like Onyx or Storm or Hadoop? I looked at Spark but it seems to 
> be for a different use case, more about querying that denormalizing. 
> Likewise, dumping everything onto S3 and then using something like Athena 
> seems to be more for querying than denormalizing. 
>
> For unrelated reasons, I am moving toward the architecture where all data 
> is stored in Kafka. I suppose I could write a denormalizing app that reads 
> over Kafka and builds up the data and then inserts it to ElasticSearch, 
> though I suppose, on the narrow issue of memory usage, using Kafka is no 
> different than using using MySQL.
>
> So, I'm asking about common patterns here. When folks have an app that 
> needs more RAM than a typical server, what is the first and most common 
> steps they take? 
>
>
>
>
>
>
>
>

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

[JOB] clojure/cloud developer

[Charles Loomis]

SixSq is an SME based in Geneva, Switzerland that provides software for cloud 
application management.  We’re looking for a Clojure developer ideally with 
experience with cloud technologies to work on our core platform.  The full job 
announcement can be found here:

http://sixsq.com/jobs/clojure-and-cloud-developer

We prefer candidates that are in or can move to the Geneva region.  As such, 
the candidate must be a Swiss/EU national or have a Swiss working permit.

You can contact me directly by email for more information or use the email 
address in the job ad. 

--Cal

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

conditional support for spec in libraries

[Charles Loomis]

The only discussion I’ve seen about providing conditional support for spec in 
libraries is in the old thread started by Sean Corfield for the JDBC library: 

https://groups.google.com/d/msg/clojure-dev/4VAlKZxiN94/tNQo_4yABAAJ

Is the technique described there, the recommended best practice? Or should we 
expect to see a :spec feature expression added to Clojure 1.9+?  Do people have 
other ways of providing conditional spec support in libraries targeted at 
multiple clojure versions? 

Any feedback appreciated. 



-- 
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: Porting Clojure to Native Platforms

[Charles Harvey III]

You can watch Robert Virding's talk about creating Lisp Flavored Erlang 
(LFE).

https://www.youtube.com/watch?v=Br2KY12LB2w

It is really informative. It tells you a lot about Erlang and the BEAM. And 
it explains why LFE is not Clojure and why Clojure would not work.

Virding really likes his Erlang as you can see from his Github profile: 
https://github.com/rvirding?tab=repositories
He's ported Lisp, Lua and Prolog to the BEAM.



On Tuesday, April 26, 2016 at 5:55:26 PM UTC-4, Rangel Spasov wrote:
>
> tbc++ - given your experience, would you consider a Clojure port to Erlang 
> VM a viable idea for production workloads? I know Elixir comes pretty 
> close, but I still prefer Lisp : ) .
>
> On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote:
>>
>> As someone who has spent a fair amount of time playing around with such 
>> things, I'd have to say people vastly misjudge the raw speed you get from 
>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
>> general use, dynamic language that is not based on the JVM and comes even 
>> close to the speed of Clojure. 
>>
>> A LLVM/C++/RPython based version of Clojure would on a good day come in 
>> at about 1/10 the speed of Clojure on the JVM for general use cases. 
>>
>>
>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>
>>> > The main motivation would be performance gains.
>>>
>>> blah? so many impedance mismatches and layers of indirection that i
>>> don't think it will gain much? i mean, it would probably be better to
>>> spend time tuning gc parameters or something. just a rant / guess.
>>> e.g. robovm is for some use cases perfectly fine performance wise
>>> believe it or not.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>

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

Re: lein: managing versions of common deps / soliciting assistance on PR review

[Charles Loomis]

For many reasons, we’re currently looking at migrating the clojure part of our 
large, multi-language build from maven to leiningen or boot.  Because we’ve run 
into difficult dependency conflicts between modules in the past, maintaining 
central management of dependency versions is critical for us. 

We’re currently leaning more towards boot and in fact I was looking at creating 
a task/function to do essentially what Sean described.  If there’s interest in 
creating a general solution for this, I’d be willing to collaborate in or 
coordinate the development.

Cal 


> On Jan 25, 2016, at 01:03, Sean Corfield  wrote:
> 
> We have slowly been running into this more and more and as part of our 
> solution to the problem, we switched from Leiningen to Boot. There were many 
> reasons for the switch but easier management of dependencies was one aspect.
> 
> We created a centralized properties file with the dependencies we wanted 
> pinned across all our projects (this is just a small part of it):
> 
> mysql/mysql-connector-java=5.1.36
> org.clojure/clojure=1.8.0
> org.clojure/core.cache=0.6.4
> org.clojure/core.memoize=0.5.8
> 
> Then our various `build.boot` files read this file and use it to patch up the 
> dependencies in each project:
> 
> (defn load-versions
>   "Read in pinned dependency versions."
>   []
>   (into {} (doto (java.util.Properties.)
>  (.load (io/input-stream (str (ws-root) 
> "/clojure/version.properties"))
> 
> (def ^:private versions (delay (load-versions)))
> 
> We have switched to keeping dependencies (for each project) in an EDN file so 
> it’s separate from our actual build files and we read that in like this:
> 
> (defn update-deps
>   "Given a set of dependencies, automatically update ones that
>   we pin using external version properties file."
>   [deps]
>   (into [] (map (fn [[artifact version :as dep]]
>   (if-let [pinned (@versions (str artifact))]
> [artifact pinned]
> dep)) deps)))
> 
> (defn datamapper-deps
>   "Read dependencies from datamapper project."
>   []
>   (-> (edn/read-string (slurp (str (ws-root) "/clojure/datamapper/deps.edn")))
>   update-deps))
> 
> And then we have tasks to set up the "context" for each project, for example:
> 
> (deftask datamapper
>   "Provide data mapper context."
>   []
>   (merge-env! :source-paths #{"clojure/datamapper/src"}
>   :dependencies   (datamapper-deps))
>   (environment))
> 
> Where datamapper depends on the environment project. So the dependencies are 
> read from the EDN file and updated to the pinned version in the properties 
> file. Then we just compose the context tasks as needed into other tasks that 
> invoke code based on them (including building JARs etc).
> 
> Inside each EDN file, we indicate the fake versions like this:
> 
> [[org.clojure/clojure "x.y.z"]
>  [org.clojure/core.cache "x.y.z"]
>  [org.clojure/core.memoize "x.y.z"]
>  [org.clojure/data.codec "x.y.z"]
>  [org.clojure/java.jdbc "x.y.z"]
>  [org.clojure/tools.nrepl "x.y.z"]
> …
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> 
> 
> From: Clojure Mailing List  on behalf of Chris 
> Price 
> Reply-To: Clojure Mailing List 
> Date: Sunday, January 24, 2016 at 1:39 PM
> To: Clojure Mailing List 
> Subject: lein: managing versions of common deps / soliciting assistance on PR 
> review
> 
>> Hi,
>> 
>> As the number of Clojure projects at our company has increased, we've ended 
>> up running into more and more frequent issues where lein's "pedantic" is 
>> alerting us to conflicting versions of transitive dependencies.  Up until 
>> now we've been managing this by surgically updating the lists of 
>> dependencies / exclusions in each project until everything matches up, but 
>> that's kind of like a giant game of whack-a-mole and has left us vulnerable 
>> to situations where we're unwittingly running a bunch of our CI jobs against 
>> a different version of some of our dependencies than the versions that we 
>> end up including in our final builds.
>> 
>> I'm curious how often this has been coming up for others, and whether or not 
>> anyone has found a solution or workaround for it that they are really happy 
>> with.
>> 
>> I've seen a couple of cool things that people have put out there, e.g.:
>> 
>> https://github.com/achin/lein-parent
>> https://github.com/walmartlabs/shared-deps
>> 
>> Both of these seem to be taking an approach somewhat similar to Maven's own 
>> solution, which is the "parent pom" / project inheritance[1] approach (along 
>> with the "managedDependencies" section of a pom file).  Given that, and 
>> given that lein's dependency management is already built on top of Maven, 
>> I've been wondering if it would 

Re: [ANN] Clojure/west 2016 CFP - 1 week left!

[Charles Nutter]

Ok! Good! 

On Friday, January 22, 2016 at 4:45:35 PM UTC-6, Alex Miller wrote:
>
> Clojure/west 2016  will be Apr 15-16 in Seattle, 
> WA and is shaping up to be a great conference. Registration will open soon, 
> hopefully next week!
>
> The Clojure/west CFP  closes soon - Jan 29th! 
> We would love to see a submission from you about Clojure or ClojureScript!
>
> People have been suggesting talk topics on the wiki 
>  
> and that's a great place to get ideas before you submit a talk. There is 
> also now a #conf-proposals room on the Clojurians slack if you are looking 
> to discuss a topic or hone your abstract.
>
> If you have any questions, please contact us at eve...@cognitect.com 
> !
>
> Alex
>
>
>
>
>
>
>
>

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

Re: [ANN] Yesql 0.5.1 Released.

[Charles Harvey III]

Here's another crazy question...

How would I use this from Java? Seriously though. I might be forced to use 
Java on my next project but I really like Yesql over MyBatis (the closest 
thing in Java Land). Has anyone done it before and can show a small 
example? I don't want to give up my .sql files for xml!!


Thanks.


Charlie


On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>
> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>
> The API is much improved - especially if you're using queries with many 
> arguments - so see the migration guide if you're upgrading:
>
> My thanks to everyone who has contributed to this release, and for all the 
> users who've been patiently waiting for v0.5 to go official. :-)
>
> Kris
>

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

Re: [ANN] Yesql 0.5.1 Released.

[Charles Harvey III]

I have a question that I hope you can answer about using Yesql with 
Component.

Currently I pass the db-spec into my endpoint and then pass it into each 
call to a query. Now that I can call defqueries with the db-spec, how do I 
send that in from component? Sorry for asking, I am new to both libraries 
and am still learning.

Thanks.



On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>
> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>
> The API is much improved - especially if you're using queries with many 
> arguments - so see the migration guide if you're upgrading:
>
> My thanks to everyone who has contributed to this release, and for all the 
> users who've been patiently waiting for v0.5 to go official. :-)
>
> Kris
>

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

Re: [ANN] Yesql 0.5.1 Released.

[Charles Harvey III]

That's what I have now and I was wondering if it could/should change now 
that I can pass the connection into defqueries. It seems like it could 
change. But, component is just a place to keep state/global values. The 
connection being one of them. defqueries must be storing it somewhere (an 
atom?) but if component already has it than I do not need to give it to 
yesql to hold as well.

Does this all sound right?

Thanks.




On Thursday, October 8, 2015 at 3:48:33 PM UTC-4, Robin Heggelund Hansen 
wrote:
>
> For a component-based workflow, you wouldn't send in the db-spec with the 
> defqueries. You would do it when calling a query.
>
> (defqueries "somepath")
>
> (defn code [component]
>   (some-query {:name "Robin", :age 6} {:db (:db-spec component)}))
>
> torsdag 8. oktober 2015 15.34.09 UTC+2 skrev Charles Harvey III følgende:
>>
>> I have a question that I hope you can answer about using Yesql with 
>> Component.
>>
>> Currently I pass the db-spec into my endpoint and then pass it into each 
>> call to a query. Now that I can call defqueries with the db-spec, how do I 
>> send that in from component? Sorry for asking, I am new to both libraries 
>> and am still learning.
>>
>> Thanks.
>>
>>
>>
>> On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>>>
>>> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>>>
>>> The API is much improved - especially if you're using queries with many 
>>> arguments - so see the migration guide if you're upgrading:
>>>
>>> My thanks to everyone who has contributed to this release, and for all 
>>> the users who've been patiently waiting for v0.5 to go official. :-)
>>>
>>> Kris
>>>
>>

-- 
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: Trying to understand Clojure/Java concurrency performance?

[Charles Harvey III]

Have you had a look at Chronicle? They have built up an entire 
infrastructure that is off-heap so there is no GC.

http://chronicle.software/products/chronicle-engine/

https://github.com/OpenHFT/Chronicle-Engine

There is a free version and a paid for version. They have broken it into 
parts so you can use just the off-heap Map/Set/Logger/Queue.

There isn't a web server, just a processing engine, so you would be rolling 
a lot of it on your own. But it sure is fast.



On Wednesday, October 7, 2015 at 5:43:26 PM UTC-4, Nick Pavlica wrote:
>
> Hi Timothy & Moe,
>   Thanks for your feedback!  I realize that we are speaking very generally 
> on this thread, and know that there are many ways to solve the complex 
> problems we face as developers.  I'm trying to understand the current know 
> limitations of using great tools like Clojure to solve the problems I'm 
> facing.  Clojure is bound by the JVM  which wasn't directly designed to 
> address high concurrency needs in the same way that Erlang/Go/etc. are.  My 
> experience with Java/JVM in the past was that it was more focused on raw 
> throughput, and less about high levels of concurrency.  I was hoping that 
> there were some good high concurrency solutions in place.  That's what 
> prompted my original question about the only benchmarks that I could find. 
>  If you have any additonal benchmarks, papers, etc., to share on this 
> subject, it would be great! 
>
> Timothy Wrote:
> "I'd investigate other tools (Netty?) before discounting an entire 
> platform"
>  -  I'm open to any suggestions.  However, I believe that Aleph is 
> build on Netty.
>
>  "I question why anyone would need 200k connections on a single 
> box, use AWS auto scaling"
>  -  There are many reasons, but in my case I'm paying for each 
> server, and I have to maintain not only the ones that I need to get the 
> work done, but ones I need for redundancy etc.  There is a huge business 
> case for doing the same work on one server that  would otherwise take two 
> or three.  An AWS server equipped similarly to the one in the benchmark is 
> running about $1200/month, adding two more would obviously increase my 
> costs by $2400/month or $28,000/year.   
>
> Mo Wrote:
>  "The github webserver benchmarks also contain many numbers above 
> 200,000 qps, for a variety of other webservers - right?"
>  - Yes, they are really great at throughput, but that's not 
> necessarily the primary metric that I'm looking for.  I'm trying to 
> determine if they are reliable and perform reasonably well with many 
> connections.  I realize that http-kit made a claim of 600K connections in 
> 2013.  But I can't find any other supporting evidence that it can do that 
> reliably.  It also seems to have stagnated a bit as a project which is 
> unfortunate. 
>
> Thanks Again for your input and guidance!
> -- Nick
>
>
> 
>
>
>
>
> On Tuesday, October 6, 2015 at 9:57:45 PM UTC-6, Nick Pavlica wrote:
>>
>> Dear Clojure/Java Experts,
>>   Earlier today I posted a question to the Immutant google group asking 
>> them a question about large numbers of concurrent websocket connections and 
>> their server.  A member of the group kindly responded with a link (
>> https://github.com/ptaoussanis/clojure-web-server-benchmarks)  to some 
>> fairly recent benchmarks that included a number of Clojure/Java servers. 
>>  After looking at the numbers in the benchmark, I was a little disappointed 
>> to see that they were only serving 60K connections as compared to other 
>> solutions like Erlang which seem to be capable of 1-2+ million connections 
>> on similar hardware.  The difference on the surface seems dramatic, and I 
>> was wondering if someone could help clarify the numbers for me.  It makes 
>> me wounder if there is a JVM solution that can even meet these numbers half 
>> way, or if I'm missing something?   
>>   
>> Many Thanks!
>> --Nick
>>
>>
>> ### Discussion from the Immutant Google group ##
>>
>> All,
>>   I'm a new Clojure developer, and I'm looking for a webserver that can 
>> handle a large number of concurrent websocket connections.  I understand 
>> that this question is a little/very vague, and is dependent on many factors 
>> like the OS, it's Kernal, amount of RAM in the system, etc.  However, there 
>> are a number of generalized claims out there, and I was wondering if anyone 
>> has done any basic testing/benchmarking with Immutant/Undertow?
>>
>> Examples:
>>
>> - http://www.http-kit.org/600k-concurrent-connection-http-kit.html
>>
>> - 
>> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
>>
>> - https://en.wikipedia.org/wiki/C10k_problem
>>
>> - https://vimeo.com/44312354
>>
>> - And so on ...
>>
>> Thanks!
>> --Nick
>>
>>
>> --
>>
>> Hi Nick, 
>> Here are some 

Lazy Sequence Results in Stack Overflow

[Charles Reese]

I want to compute a lazy sequence of primes.

Here is the interface:

user=> (take 10 primes)
(2 3 5 7 11 13 17 19 23 29)

So far, so good.

However, when I take 500 primes, this results in a stack overflow.

  core.clj:  133  clojure.core/seq
  core.clj: 2595  clojure.core/filter/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 2626  clojure.core/take/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
 Cons.java:   39  clojure.lang.Cons/next
  LazySeq.java:   81  clojure.lang.LazySeq/next
   RT.java:  598  clojure.lang.RT/next
  core.clj:   64  clojure.core/next
  core.clj: 2856  clojure.core/dorun
  core.clj: 2871  clojure.core/doall
  core.clj: 2910  clojure.core/partition/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 2551  clojure.core/map/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 3973  clojure.core/interleave/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  
I'm wondering what is the problem here and, more generally, when working 
with lazy sequences, how should I approach this class of error?

Here is the code.

(defn assoc-nth
  "Returns a lazy seq of coll, replacing every nth element by val

  Ex:
  user=> (assoc-nth [3 4 5 6 7 8 9 10] 2 nil)
  (3 nil 5 nil 7 nil 9 nil)
  "
  [coll n val]
  (apply concat
 (interleave
  (map #(take (dec n) %) (partition n coll)) (repeat [val]

(defn sieve
  "Returns a lazy seq of primes by Eratosthenes' method

  Ex:
  user=> (take 4 (sieve (iterate inc 2)))
  (2 3 5 7)

  user=> (take 10 (sieve (iterate inc 2)))
  (2 3 5 7 11 13 17 19 23 29)
  "
  [s]
  (lazy-seq
   (if (seq s)
 (cons (first s) (sieve
  (drop-while nil? (assoc-nth (rest s) (first s) 
nil
 [])))

(def primes
  "Returns a lazy seq of primes

  Ex:
  user=> (take 10 primes)
  (2 3 5 7 11 13 17 19 23 29)
  "
  (concat [2] (sieve (filter odd? (iterate inc 3)

-- 
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: OT: Github Alternatives

[Charles Harvey III]

You could abandon Git and save yourself a lot of money and pain.

Start using Bazaar! http://bzrinit.com/  (http://bazaar.canonical.com/en/)

Hosting is seriously you setting up an ftp server (sftp, ssh, scp) - 
whatever. There is web viewer plugin: https://launchpad.net/loggerhead. it 
is basically an apache module.

Seriously, take a look at Bzr. All the features of Git with much nicer 
commands and it won't ever lose your history. And hosting it yourself is 
just so easy.




-- 
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: OT: Github Alternatives

[Charles Harvey III]

That is truly sad if Bzr dies out. I have had such horrible experiences 
with Git that I still can't understand what people like about it. Well, 
aside from the fact that it is not SVN and that there is github. 





On Tuesday, July 1, 2014 6:58:32 AM UTC-4, Thorsten Jolitz wrote:

 Charles Harvey III charles...@gmail.com javascript: writes: 

  You could abandon Git and save yourself a lot of money and pain. 
  
  Start using Bazaar! http://bzrinit.com/ 
  (http://bazaar.canonical.com/en/) 
  
  Hosting is seriously you setting up an ftp server (sftp, ssh, scp) - 
  whatever. There is web viewer plugin: 
  https://launchpad.net/loggerhead. it is basically an apache module. 
  
  Seriously, take a look at Bzr. All the features of Git with much nicer 
  commands and it won't ever lose your history. And hosting it yourself 
  is just so easy. 

 Too bad that even GNU Emacs development is moving (has already moved?) 
 from bzr to git. See 

 , 
 | From: e...@thyrsus.com javascript: (Eric S. Raymond) 
 | Subject: bzr is dying; Emacs needs to move 
 | Newsgroups: gmane.emacs.devel 
 | To: emacs...@gnu.org javascript: 
 | Date: Thu,  2 Jan 2014 04:53:47 -0500 (EST) (25 weeks, 5 days, 1 hour 
 ago) 
 | 
 | I am posting this because I think it is my duty as a topic expert in 
 | version-control systems and the surrounding tools to do so, not because 
 | I have any desire to be in the argument that is certain to ensue. 
 | 
 | The bzr version control system is dying; by most measures it is 
 | already moribund.  [...] 
 ` 

 and the following long thread on gmane.emacs.devel. 

 -- 
 cheers, 
 Thorsten 



-- 
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: OT: Github Alternatives

[Charles Harvey III]

I didn't mean to derail this post asking for hosting options. I certainly 
do not want it to go down a git-hole.

I have had a good amount of experience with CVS, SVN, Git and Bazaar. Years 
worth. Usually when you complain about Git the first thing you hear is that 
I wasn't doing it right or that its a flexible tool and I just have to 
learn it. The amount of Git vitriol out there must be somewhat justified.

I just found Bazaar to be really friendly. Commands work like they do in 
SVN so it is easy to make the move. And I don't see a lot of Bazaar hate 
out there. Then again, hardly anyone is using it. :)

Original poster, Adrian, you are using Git and you are happy with it. I 
don't actually have any private hosting options for you besides setting up 
an sftp server of your own.

But that is usually a great idea. You just need a browser/viewer ala 
viewcvs:

http://viewgit.fealdia.org/
https://github.com/toolmantim/bananajour
http://git.zx2c4.com/cgit/about/
https://git.wiki.kernel.org/index.php/Gitweb
https://github.com/chad/gitjour

Total control of your repository and essentially free - you just pay for 
hard drives/backups.



On Tuesday, July 1, 2014 5:37:57 PM UTC-4, Adrian Mowat wrote:

  What were the horrible experiences? I agree that git allows you to make 
 a mess if you want to but then again Unix has rm -Rf and we all learned 
 quickly enough to use it carefully


  
 Sent from Mailbox https://www.dropbox.com/mailbox 
  
 On Tue, Jul 1, 2014 at 02:24 PM, Charles Harvey IIIcharles...@gmail.com 
 javascript:, wrote:

 That is truly sad if Bzr dies out. I have had such horrible experiences 
 with Git that I still can't understand what people like about it. Well, 
 aside from the fact that it is not SVN and that there is github. 





 On Tuesday, July 1, 2014 6:58:32 AM UTC-4, Thorsten Jolitz wrote:

 Charles Harvey III charles...@gmail.com writes: 

  You could abandon Git and save yourself a lot of money and pain. 
  
  Start using Bazaar! http://bzrinit.com/ 
  (http://bazaar.canonical.com/en/) 
  
  Hosting is seriously you setting up an ftp server (sftp, ssh, scp) - 
  whatever. There is web viewer plugin: 
  https://launchpad.net/loggerhead. it is basically an apache module. 
  
  Seriously, take a look at Bzr. All the features of Git with much nicer 
  commands and it won't ever lose your history. And hosting it yourself 
  is just so easy. 

 Too bad that even GNU Emacs development is moving (has already moved?) 
 from bzr to git. See 

 , 
 | From: e...@thyrsus.com (Eric S. Raymond) 
 | Subject: bzr is dying; Emacs needs to move 
 | Newsgroups: gmane.emacs.devel 
 | To: emacs...@gnu.org 
 | Date: Thu,  2 Jan 2014 04:53:47 -0500 (EST) (25 weeks, 5 days, 1 hour 
 ago) 
 | 
 | I am posting this because I think it is my duty as a topic expert in 
 | version-control systems and the surrounding tools to do so, not 
 because 
 | I have any desire to be in the argument that is certain to ensue. 
 | 
 | The bzr version control system is dying; by most measures it is 
 | already moribund.  [...] 
 ` 

 and the following long thread on gmane.emacs.devel. 

 -- 
 cheers, 
 Thorsten 

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

  

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

Re: [ANN] New core.async release

[Charles Duffy]

The most interesting thing I've learned from this release is just how 
lenient old releases were in the face of erroneous code, of which I appear 
to have had rather a lot. :)

That said, I have found at least one behavior I'm not able to understand. 
This works perfectly with the new core.async:

(defn apply-prefix-to-txn [prefix in-txn]
  (vec (for [op in-txn] (assoc op 1 (vec (concat prefix (get op 1)))

(defn apply-prefix
  [in-chan prefix]
  (map (partial apply-prefix-to-txn prefix) in-chan))

...but the definition below (which is, certainly, much worse code) results 
in a compile-time error:

(defn apply-prefix
  [in-chan prefix]
  (let [out-chan (chan)]
(go
  (loop []
(when-let [in-txn (! in-chan)]
  (! out-chan (vec (for [op in-txn] (assoc op 1 (vec (concat 
prefix (get op 1)))
  (recur))

...that being:

CompilerException java.lang.IllegalArgumentException: No method in 
multimethod '-item-to-ssa' for dispatch value: :fn, 
compiling:(/private/var/folders/hm/50_gxm6n4k3dbcqddkw3_btwgn/T/form-init2129308341681179922.clj:4:5)
 

My expectation is that these should be equivalent. Is there something I'm 
missing here?



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

core.async: closing a mix only when all inputs have emptied

[Charles Duffy]

Howdy --

Trying to use core.async's mix facility, one difficulty I've run into is 
the lack of a means to close the output channel only after al inputs have 
been exhausted. In the interim, I've ended up using the below instead -- 
which lacks some of the facilities provided by the mix interface (muting, 
pausing, soloing, etc), but has the advantage of cleanly closing its output 
channel if and only if all inputs (including the channel from which other 
channels are read) have been flushed.

That said, looking at core.async's code, it certainly seems possible to 
extend the mix abstraction to handle this use case -- for instance, adding 
a (close-on-empty! [mix]) call which would set a flag causing the the 
output channel to close whenever all inputs are unmixed, whether by user 
interaction or end-of-input, would be another solution.

Thoughts? Should I publish the below (and related tooling -- such as an 
N-way split helper used to create such channels of channels) as a separate 
library? Submit patches to core.async adding appropriate functionality to 
the mix implementation? Or is there already a better way of achieving the 
desired effect?

Thanks!

(defn merge-channels
  Given a channel which yields other channels, combine output from all of 
these into a single output channel.

  Close output channel and exit when both the input channel and all 
channels read from that channel have closed.
  [in-chan]
  (let [out-chan (chan)]
(go
  (loop [open-channels #{}, in-chan-open? true]
(let [all-chans (if in-chan-open?
  (conj open-channels in-chan)
  open-channels)
  [v c] (when-not (empty? all-chans) (alts! (vec all-chans)))]
  (cond

   (empty? all-chans)
   nil

   (= c in-chan)
   (if v
 (recur (conj open-channels v) true)
 (recur open-channels false))

   (nil? v)
   (do
 (recur (disj open-channels c) in-chan-open?))

   :else
   (do
 (! out-chan v)
 (recur open-channels in-chan-open?))
out-chan))

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

What does Clojure get from Java 8?

[Charles Harvey III]

I had read that the Clojure team was prepping the build to work on the new 
JDK8 and it got me to thinking - what does Clojure get from Java 8? Will it 
be using some of the new features or does the compiler just need to be 
ready for changes in the JDK so compilation passes? Clojure already has 
much of what Java 8 is delivering, so will it switch its internals to using 
the Java internals or just leave it alone?

Again, just curious. Thanks.

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

What are effective ways to debug Clojure code?

[Jeffrey Charles]

I'm interested in hearing how people who use Clojure in production are 
debugging their code, particularly those who use Emacs.

I am having issues quickly locating problems in my Clojure code that are 
identified by automated integration test failures. As an example, I had a 
Midje test that would make an HTTP call into my application running 
Compojure and Liberator on Ring on Jetty and I'd get an error back in a 
stacktrace in my shell running the Ring process. I got to a somewhat useful 
error of not being able to find a terminator for a JSON object which I 
correctly divined was actually that the request body was empty. My usual 
approach to debugging these sorts of problems in C# and Visual Studio is to 
set the built-in debugger to break on CLR exceptions and then run the 
integration test with my debugger attached to the web server process and 
take a look at the exception and local variables starting at the bottom of 
the stack and going up the stack until I spot something funky. I'm 
completely lost in figuring out how to do something similar in Clojure and 
Emacs or a shell, that is to say, running something that will pause 
execution and let me examine the exception and in-scope variables on a 
stack frame by stack frame basis with source code context (bonus points if 
it's a REPL).

One thing I've taken a look at is ritz and ritz-nrepl but I seem to get 
errors when I try to use them. Specifically, Symbol's value as variable is 
void: nrepl-mode-map which seems to be an already reported issue. As well, 
the Github repositories don't appear to have been updated in several months 
which makes me pessimistic that these libraries will be meaningfully 
maintained and as a result, I feel uncomfortable relying on them.

Another thing I looked at was George Jahad's Clojure Debug Toolkit which 
also doesn't seem to have gotten any love in the last few years and has 
pretty minimal public documentation around using it..

While playing around with functions in the REPL usually does the job, 
sometimes the bugs and their locations are not obvious or they're at 
integration points where the input is a complicated object. I'd like to 
know what other developers who use Clojure do when they need to debug 
something and a REPL in a namespace with minimal execution context doesn't 
seem to do the trick.

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

Re: I could use some help getting nrepl-ritz working

[Charles Comstock]

So nrepl-mode was just renamed to nrepl-repl-mode, so nrepl-mode-map is 
likely now nrepl-repl-mode-map. My presumption is that this breaks 
compatability with nrepl-ritz. I don't understand why the rename happened 
either. But yea that should fix it.

https://github.com/clojure-emacs/nrepl.el/commit/1d92c44ed6e9a75ea60233b4afb638fa38e0bcf3

Charles Comstock

On Thursday, October 3, 2013 3:01:05 PM UTC-5, Stephen Cagle wrote:

 I can actually get ritz to load without error in emacs by using the 
 aforementioned website's instructions and then, after ritz is pulled, going 
 into  .emacs.d/elpa/nrepl-ritz-20130516.1339/nrepl-ritz.el and 
 M-x replace-string RET nrepl-mode-map RET nrepl-repl-mode-map

 Why? Not really sure.

 On Monday, September 30, 2013 11:07:56 PM UTC-7, Stephen Cagle wrote:

 Basically, I get a error when I try to follow the directions at 
 http://ianeslick.com/2013/05/17/clojure-debugging-13-emacs-nrepl-and-ritz/ . 
 In my init.el, I get a error when evaluating: 
 *(require 'nrepl-ritz) ;;after (require 'nrepl)*

 the error is:
 *Debugger entered--Lisp error: (void-variable nrepl-mode-map)*
 *  byte-code(\302 \303\304#\210\302 \305\304#\207 
 [nrepl-interaction-mode-map nrepl-mode-map define-key [3 134217844] 
 nrepl-ritz-threads [3 134217844]] 4)*
 *  require(nrepl-ritz)*
 *  eval((require (quote nrepl-ritz)) nil)*
 *  eval-last-sexp-1(nil)*
 *  eval-last-sexp(nil)*
 *  call-interactively(eval-last-sexp nil nil)*

 clearly, it has no idea what nrepl-mode-map is.  Why this is I do not 
 know.

 The rest of this message is just all the things I could think of that you 
 might ask, and the contents of my init.el and profiles.clj file. If you 
 know what problem I am having already, there is  no reason to read it. I am 
 just trying to preemptively guess what you will ask.

 This is the warning when I start up emacs:

 *Warning (initialization): An error occurred while loading 
 `/home/stephen/.emacs.d/init.el':*
 *
 *
 *Symbol's value as variable is void: nrepl-mode-map*
 *
 *
 *To ensure normal operation, you should investigate and remove the*
 *cause of the error in your initialization file.  Start Emacs with*
 *the `--debug-init' option to view a complete error backtrace.*

 My emacs version is:
 M-x emacs-version = *GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ 
 Version 3.6.4) of 2013-08-22 on menkib, modified by Debian*

 I have the following in my ~/.lein/profile.clj
 *{:user {:plugins [;; [lein-marginalia 0.7.1]*
 *  ;; [lein-try 0.3.1]*
 *  ;; [lein-pprint 1.1.1]*
 *  ;; [lein-ancient 0.4.4]*
 *  ;; [lein-bikeshed 0.1.3]*
 *  ;; [lein-cljsbuild 0.3.3]*
 *  ;; [lein-ring 0.8.7]*
 *  ;; [com.keminglabs/cljx 0.3.0]*
 *  [lein-ritz 0.7.0]]*
 *:dependencies [[nrepl-inspect 0.3.0]*
 *   [ritz/ritz-nrepl-middleware 0.7.0]]*
 *:repl-options {:nrepl-middleware*
 *   [inspector.middleware/wrap-inspect*
 *ritz.nrepl.middleware.javadoc/wrap-javadoc*
 *
 ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}}}*
 *
 *
 and the folowing ~/.emacs.d/init.el file:
 *
 *
 *;;;-*
 *; From http://clojure.roboloco.net/?tag=paredit*
 *
 *
 *(setq inhibit-startup-message t) ;; No splash screen*
 *;; (setq initial-scratch-message nil) ;; No scratch message*
 *;; (tool-bar-mode nil) ;; No toolbars*
 *;; Create backup files in .emacs-backup instead of everywhere*
 *(defvar user-temporary-file-directory ~/.emacs-backup)*
 *(make-directory user-temporary-file-directory t)*
 *(setq backup-by-copying t)*
 *(setq backup-directory-alist*
 *  `((. . ,user-temporary-file-directory)*
 * (,tramp-file-name-regexp nil)))*
 *(setq auto-save-list-file-prefix*
 *  (concat user-temporary-file-directory .auto-saves-))*
 *(setq auto-save-file-name-transforms*
 *  `((.* ,user-temporary-file-directory t)))*
 *
 *
 *(set-face-attribute 'default nil :height 110)*
 *; http://www.emacswiki.org/emacs/ShowParenMode*
 *(require 'paren)*
 *(set-face-background 'show-paren-match-face (face-background 'default))*
 *(set-face-foreground 'show-paren-match-face #0f0)*
 *(set-face-attribute 'show-paren-match-face nil :weight 'extra-bold)*
 *(show-paren-mode 1)*
 *
 *
 *;;;-*
 *
 *
 *(require 'package)*
 *(add-to-list 'package-archives*
 * '(marmalade . http://marmalade-repo.org/packages/;)*
 *  '(melpa . http://melpa.milkbox.net/packages/;))*
 *(package-initialize)*
 *
 *
 *(defvar my-packages '(;starter-kit*
 *  ;starter-kit-lisp*
 *  ;starter-kit-bindings*
 *  ;starter-kit-eshell*
 *   ac-nrepl*
 *  clojure-mode*
 *   clojure-test-mode

Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.

[Charles Harvey III]

If you haven't tried out Light Table, it shows you the values of local 
variables. It is a pretty nice feature.


On Monday, May 27, 2013 5:53:16 PM UTC-4, puzzler wrote:

 I would be a lot happier with the state of Clojure debugging if, in 
 addition to a stacktrace, I could easily explore the local variables in 
 play when an error was triggered.  It was possible to do this in earlier 
 Clojure environments, but the capability seems to have been lost in the 
 transition to nrepl.


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

Need some Advice for my Prolog Project

[Charles Hoskinson]

I'm starting an open sourced project to port Prolog to the JVM like you 
guys did with LISP and I'd like to get some advice on where to start, 
materials to review, pitfalls to avoid, and anything else you feel would be 
useful to know. Could you either post here or contact me at 
charles.hoskin...@gmail.com

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

Re: A Working nrepl-ritz Setup?

[Charles Comstock]

No, that wasn't the problem, early on when I tried to use nrepl and ritz I 
experimented with clojure 1.5, but as far as I know all of these issues I 
encountered after switching back to 1.4. In response to someone elses 
question, I also was definitely using fresh copies of nrepl, presuming all 
the autoloads execute require in the correct order after executing 
nrepl-ritz-jack-in, as I would encounter the problem with missing the 
complete library even after a fresh emacs reboot. 

I'm happy to help diagnose this issue locally so as to get a permanent fix 
for all of us who may have been afflicted with these errors. I discovered 
the need to load in clojure-complete after diagnosing that was what was 
supposed to provide that namespace, but wasn't quite sure how it was 
intended to be added to the dependency list in the first place. Wasn't sure 
if nrepl-ritz was overriding that, or if it was a problem with core nrepl.

Charlie

On Monday, December 10, 2012 3:59:27 AM UTC-6, Chas Emerick wrote:


 On Dec 8, 2012, at 6:37 PM, Charles Comstock wrote:

 I still encounter some sort of issue where it appears that the 
 documentation querying functions, find-doc, and doc and the like are not 
 being properly brought into the repl namespace, which breaks ctrl-d d until 
 I manually bring that into the namespace. I'm not quite certain what was 
 causing that problem and have yet to find a permanent fix.


 Are you using a recent Clojure 1.5.0 beta build?  A change went in 
 recently to fix some behaviour where nREPL would inadvertently refer all of 
 the REPL utilities (doc, find-doc, pp, etc.) into *every* namespace.  When 
 used with Clojure 1.5.0, nREPL now only refers those vars into the user ns, 
 matching the default Clojure REPL defaults.

 (I actually got used to the old behaviour myself, but it can cause serious 
 problems, e.g.: 
 http://code.google.com/p/counterclockwise/issues/detail?id=443)

 This all said, it's definitely the case that some piece of the toolchain 
 (probably clients like reply and nrepl.el, based on project.clj / profile 
 config) should instigate global namespace refers so that these vars, or 
 some subset, in addition to whatever vars you use most often in your 
 workflow/project/application are always available.  Meditation on this 
 topic continues. :-)

 Cheers,

 - Chas


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

Re: A Working nrepl-ritz Setup?

[Charles Comstock]

Perhaps this discussion should move to the nrepl-el mailing list or the 
like, but I just discovered a bit more trying to figure this out. I noted 
that the .lein/profiles.clj documentation had been updated in the 
ritz/nrepl documentation. Namely that :hooks is scoped to the :user block 
and not at the same level as :user. Unfortunately, now when I run lein deps 
I get the following error message:

Error: cannot resolve ritz.add-sources/activate hook

This is from a revised .lein/profiles.clj of:

{:user {:plugins [[lein-ritz 0.6.0]]
:dependencies [[ritz/ritz-nrepl-middleware 0.6.0]
   [clojure-complete 0.2.2]]
:repl-options {:nrepl-middleware
   [ritz.nrepl.middleware.javadoc/wrap-javadoc

ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}
:hooks [ritz.add-sources]}}

Am I running into some sort of issue by not using the snapshot version of 
lein-ritz? I am using leiningen 2.0.0-preview10, with clojure 1.4, and the 
rest of the dependencies are furnished by the  lein profile.clj. I did 
verify that without manually adding clojure-complete, I still get the error 
about missing complete's init. Note that the hooks error does not prevent 
nrepl-ritz-jack-in from bringing up an nrepl buffer. The same is true for 
missing clojure-complete, but the completion mechanism throws an 
exception every time I hit tab.

I also updated the corresponding portion of my init.el to require 
'nrepl-ritz on using an nrepl, but I presume that is happening anyway due 
to nrepl-ritz-jack-in triggering the nrepl-ritz autoload.

Let me know if any other information would help in diagnosing what's 
different about my environment?

Thanks,
  Charlie

On Monday, December 10, 2012 6:38:09 PM UTC-6, Charles Comstock wrote:

 No, that wasn't the problem, early on when I tried to use nrepl and ritz I 
 experimented with clojure 1.5, but as far as I know all of these issues I 
 encountered after switching back to 1.4. In response to someone elses 
 question, I also was definitely using fresh copies of nrepl, presuming all 
 the autoloads execute require in the correct order after executing 
 nrepl-ritz-jack-in, as I would encounter the problem with missing the 
 complete library even after a fresh emacs reboot. 

 I'm happy to help diagnose this issue locally so as to get a permanent fix 
 for all of us who may have been afflicted with these errors. I discovered 
 the need to load in clojure-complete after diagnosing that was what was 
 supposed to provide that namespace, but wasn't quite sure how it was 
 intended to be added to the dependency list in the first place. Wasn't sure 
 if nrepl-ritz was overriding that, or if it was a problem with core nrepl.

 Charlie

 On Monday, December 10, 2012 3:59:27 AM UTC-6, Chas Emerick wrote:


 On Dec 8, 2012, at 6:37 PM, Charles Comstock wrote:

 I still encounter some sort of issue where it appears that the 
 documentation querying functions, find-doc, and doc and the like are not 
 being properly brought into the repl namespace, which breaks ctrl-d d until 
 I manually bring that into the namespace. I'm not quite certain what was 
 causing that problem and have yet to find a permanent fix.


 Are you using a recent Clojure 1.5.0 beta build?  A change went in 
 recently to fix some behaviour where nREPL would inadvertently refer all of 
 the REPL utilities (doc, find-doc, pp, etc.) into *every* namespace.  When 
 used with Clojure 1.5.0, nREPL now only refers those vars into the user ns, 
 matching the default Clojure REPL defaults.

 (I actually got used to the old behaviour myself, but it can cause 
 serious problems, e.g.: 
 http://code.google.com/p/counterclockwise/issues/detail?id=443)

 This all said, it's definitely the case that some piece of the toolchain 
 (probably clients like reply and nrepl.el, based on project.clj / profile 
 config) should instigate global namespace refers so that these vars, or 
 some subset, in addition to whatever vars you use most often in your 
 workflow/project/application are always available.  Meditation on this 
 topic continues. :-)

 Cheers,

 - Chas



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

Re: A Working nrepl-ritz Setup?

[Charles Comstock]

I actually just encountered this error, and then intended to post how I 
fixed it as a reported issue and then forgot. So this is my current lein 
profile.clj

{:user {:plugins [[lein-vanity 0.1.0]
  [jonase/eastwood 0.0.2]
  [lein-ritz 0.6.0]]
:dependencies [[ritz/ritz-nrepl-middleware 0.6.0]
   [ritz/ritz-debugger 0.6.0]
   [ritz/ritz-repl-utils 0.6.0]
   [clojure-complete 0.2.2]]
:repl-options {:nrepl-middleware
   [ritz.nrepl.middleware.javadoc/wrap-javadoc

ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}}
 :hooks [ritz.add-sources]}

Note that unlike the docs listed at ritz/nrepl, I also needed to add an 
explicit dependency for clojure-complete 0.2.2. I also needed to use the 
MELPA version of nrepl, nrepl-ritz. I still encounter some sort of issue 
where it appears that the documentation querying functions, find-doc, and 
doc and the like are not being properly brought into the repl namespace, 
which breaks ctrl-d d until I manually bring that into the namespace. I'm 
not quite certain what was causing that problem and have yet to find 
a permanent fix.

The inclusion of clojure-complete should definitely fix the error you are 
getting, but I definitely found setting up the whole ritz setup to be error 
prone.

Charlie

On Wednesday, December 5, 2012 9:09:46 PM UTC-6, frye wrote:

 Ahh yes, `*lein ritz-nrepl*` wasn't working. I got it working by changing 
 the file name to profiles.clj . So Hugo, in the 
 ritz/nreplhttps://github.com/pallet/ritz/tree/develop/nrepl page, 
 you'll want to change the instruction text from *A)* to *B)*. 

 *A)* Add this to your ~/.lein/profiles file (requires lein version 2):
 *B)* Add this to your *~/.lein/profiles.clj* file (requires lein version 
 2):


 So with that, I get a little further. And running `*M-x nrepl-ritz-jack-in
 *` gets me an nrepl shell and server. But the result of the jack-in is an 
 error (see below). I'm not sure if that has to do with ritz, but I'll play 
 around with it: 

 java.io.FileNotFoundException: Could not locate complete/core__init.class 
 or complete/core.clj on classpath: 
 
 
 
  
  at clojure.lang.RT.load (RT.java:432) 
 
 
 
 

 clojure.lang.RT.load (RT.java:400) 
 
 
 
 

 clojure.core$load$fn__4890.invoke (core.clj:5415) 
 
 
 
 
 
 clojure.core$load.doInvoke (core.clj:5414) 
 
 
 
 

 clojure.lang.RestFn.invoke (RestFn.java:408) 



 Thanks very much 
 Tim 



 On Wed, Dec 5, 2012 at 12:27 PM, Hugo Duncan dunca...@gmail.comjavascript:
  wrote:

 Timothy Washington twas...@gmail.com javascript: writes:

  Yes, I updated *~/.emacs.d/init.el* and *~/.lein/profiles*, as 
 outlined
  on that page. But somehow nrepl server thinks *'ritz-nrepl' is not a 
 task*.

 Does running `lein ritz-nrepl` from a shell within your project
 directory work?

 Hugo



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

Re: Combining Complement and Not

[Charles Comstock]

I understand that, hence the example being to check if the value was a 
function, since returning false from not'ing a function didn't make sense 
to me. The change I was inquiring about applied to your example would be;

(filter (fnot even?) [1 2 3 4 5 6 7]) = (1 3 5 7)
(filter fnot [true false true]) = [false true false]

So I fully understand that one is operating on values, and one is operating 
on functions. What I was asking, is if it's ever useful to execute not on a 
function but treat it as a value, just as it doesn't make sense to execute 
complement on values instead of functions. Given that it seemed the vast 
majority of use cases are distinct dependent on if you are dealing with 
functions or values, I was questioning if the functions could be combined 
to do the right thing depending on if it was a value or a function. I was 
asking for arguments for and against that, but concluded it was probably 
was due to complecting and was asking for verification.

Thanks,

Charlie

On Tuesday, November 6, 2012 4:03:44 AM UTC-6, Stathis Sideris wrote:

 The difference between not and complement is that not takes a *value* and 
 produces a new *value* which is true if the original was false (and vice 
 versa) while complement takes a *function* and produces a new *function 
 *which 
 returns true in the cases where the original function would return false.

 Here is an example that shows how complement can result in more concise 
 code in comparison to not:

 user (filter (fn [x] (not (even? x))) [1 2 3 4 5 6 7])
 (1 3 5 7)
 user (filter (complement even?) [1 2 3 4 5 6 7])
 (1 3 5 7)

 (of course you could just use odd? in this case, but it's only an example).

 I hope that clears it up.

 Stathis

 On Monday, 5 November 2012 23:12:03 UTC, Charles Comstock wrote:

 Hi All,

 I quite like Clojure but have been confused from time to time on 
 particular design choices. I find understanding the root cause of these 
 decisions helps to understand the language better. As example, the fact 
 that complement and not are separate functions has been puzzling me for a 
 bit [1]. The implementation of not and complement is roughly;

 (defn not [x] (if x false true))
 (defn complement [f] 
   (fn 
  ([] (not (f)))
  ([x] (not (f x)))
  ([x y] (not (f x y)))
  ([x y  zs] (not (apply f x y zs)

 What I'm wondering is if it's purely for performance, historical or 
 idiomatic reasons that it's not;


 (defn fnot [arg]
   (if (ifn? arg)
 (fn
   ([] (fnot (arg)))
   ([x] (fnot (arg x)))
   ([x y] (fnot (arg x y)))
   ([x y  zs] (fnot (apply arg x y zs
 (if arg false true)))

 Perhaps a multi-method could also be appropriate here, though I'm not 
 exactly certain what the appropriate dispatch function would be. I follow 
 why bit-not is a separate function as the intended meaning is clearly 
 different, but the implied meaning of not seems to be the same as complement 
 which is why it seems odd that they are different methods. 

 After doing some experimentation with these, I finally realized that (not 
 identity) yields false, but I'm not quite following that use case. I'm 
 guessing the idiomatic argument against fnot is that it would complect not 
 and complement unnecessarily?

 While pouring through the clojure.core source, I also saw a few functions 
 like not-every? which use (comp not every?) instead of (complement every?). 
 This led me to question why complement is not implemented as;


 (defn complement [f] (comp not f))


 Is there a difference that I'm just not seeing? Or is that just a side 
 effect of either performance or dependency ordering in clojure.core [2].

 I think I may have answered my own question concerning fnot in a roundabout 
 manner, but I found the process of discovering this illuminating. Can anyone 
 else shed light on this, or am I correct in concluding that fnot would 
 complect not and complement?

 Thanks,
  Charlie

 1. I frequently misread comp as complement and not compose in point free 
 code, so perhaps that confusion is why complement is oddly jarring to me.

 2. not-every? and not-any? are implemented using def instead of defn and 
 manually set meta :arglist, despite defn already being defined, is this just 
 for historical reasons?




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

Combining Complement and Not

[Charles Comstock]

Hi All,

I quite like Clojure but have been confused from time to time on particular 
design choices. I find understanding the root cause of these decisions 
helps to understand the language better. As example, the fact that 
complement and not are separate functions has been puzzling me for a bit 
[1]. The implementation of not and complement is roughly;

(defn not [x] (if x false true))
(defn complement [f] 
  (fn 
 ([] (not (f)))
 ([x] (not (f x)))
 ([x y] (not (f x y)))
 ([x y  zs] (not (apply f x y zs)

What I'm wondering is if it's purely for performance, historical or idiomatic 
reasons that it's not;


(defn fnot [arg]
  (if (ifn? arg)
(fn
  ([] (fnot (arg)))
  ([x] (fnot (arg x)))
  ([x y] (fnot (arg x y)))
  ([x y  zs] (fnot (apply arg x y zs
(if arg false true)))

Perhaps a multi-method could also be appropriate here, though I'm not exactly 
certain what the appropriate dispatch function would be. I follow why bit-not 
is a separate function as the intended meaning is clearly different, but the 
implied meaning of not seems to be the same as complement which is why it seems 
odd that they are different methods. 

After doing some experimentation with these, I finally realized that (not 
identity) yields false, but I'm not quite following that use case. I'm guessing 
the idiomatic argument against fnot is that it would complect not and 
complement unnecessarily?

While pouring through the clojure.core source, I also saw a few functions like 
not-every? which use (comp not every?) instead of (complement every?). This led 
me to question why complement is not implemented as;


(defn complement [f] (comp not f))


Is there a difference that I'm just not seeing? Or is that just a side effect 
of either performance or dependency ordering in clojure.core [2].

I think I may have answered my own question concerning fnot in a roundabout 
manner, but I found the process of discovering this illuminating. Can anyone 
else shed light on this, or am I correct in concluding that fnot would complect 
not and complement?

Thanks,
 Charlie

1. I frequently misread comp as complement and not compose in point free code, 
so perhaps that confusion is why complement is oddly jarring to me.

2. not-every? and not-any? are implemented using def instead of defn and 
manually set meta :arglist, despite defn already being defined, is this just 
for historical reasons?


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

Layered DynamicClassLoader instances -- why?

[Charles Duffy]

Using Clojure 1.4.0, I'm inspecting the classloader stack my software
is running with... and have at times noticed numerous layered
DynamicClassLoader instances:

(defn classloader-parents [loader]
  (when loader
(lazy-seq (cons loader
(classloader-parents (.getParent loader))

= (pprint (classloader-parents (.getContextClassLoader (Thread/
currentThread
(#DynamicClassLoader clojure.lang.DynamicClassLoader@1b0c5fe9
 #DynamicClassLoader clojure.lang.DynamicClassLoader@78f92fba
 #ModuleClassLoader 94.0
 #WebappClassLoader WebappClassLoader
  delegate: false
  repositories:
/WEB-INF/classes/
-- Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@70eb7859

 #StandardClassLoader
org.apache.catalina.loader.StandardClassLoader@70eb7859
 #AppClassLoader sun.misc.Launcher$AppClassLoader@4aad3ba4
 #ExtClassLoader sun.misc.Launcher$ExtClassLoader@3326b249)

In this case it's only two DynamicClassLoader instances, but I've seen
it be much more, as eval unconditionally generates a new
DynamicClassLoader in all cases, since changeset
2c2ed386ed0f6f875342721bdaace908e298c7f3 (by rhickey in May 2010).
Unfortunately, this changeset doesn't include a ticket number or other
details on the bug it was intended to resolve.

Looking at the implementation, the immediate cause is obvious:
clojure.lang.RT.makeClassLoader() uses layers a new DynamicClassLoader
on top of baseLoader(), whatever that may be, and baseLoader() uses
clojure.lang.Compiler.LOADER, whenever that variable is bound, in
preference to anything else.

Does anyone know the issue that was behind this hotfix?

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

Re: JVM 7 support (invokedynamic)

[Charles Nutter]

This is the best summary of how Clojure *could* benefit from invokedynamic.

Clojure doesn't dispatch as dynamically as JRuby, but there is a dynamic 
component...specifically, you have to go get the fn. That repeated get 
would disappear with invokedynamic,

In fact, anywhere you're going after something that's immutable but requires 
a memory access, you could potentially use invokedynamic to eliminate repeat 
memory accesses. I assume that would help in many places.

Also, as Paul notes below, there's no need for multiple-arity interfaces to 
get full-speed perf if you use invokedynamic; JRuby's invokedynamic-based 
dispatch ends up going directly from call site to target code body, with no 
intervening interface at all.

Listen to Paul. He's right.

- Charlie

On Friday, August 26, 2011 5:37:53 AM UTC-5, Paul Stadig wrote:

 On Thu, Aug 25, 2011 at 5:41 PM, Tal Liron tal@gmail.com wrote:

 So, after setting up a JVM 7 environment to play with Clojure, and 
 enthusiastically rummaging through the codebase, I have good news and bad 
 news. :)

 So, when Clojure calls a function, it either already has the instance in 
 its entirety (a lambda) or it finds it by dereferencing a binding. Since all 
 functions are instances that implement IFn, the implementation can then call 
 invokeinterface, which is very efficient.

 [See clojure.lang.Compiler#InvokeExpr.emitArgsAndCall]


 What I said in another post was that with invokedynamic (assuming you could 
 just go whole hog into Java 7) you don't need the IFn interface. You just 
 need a MethodHandle. So yes, I agree that given all the existing Clojure 
 code, and the desire to stay compatible with Java 5 or 6 or whatever, 
 invokedynamic isn't very compelling. If you were going to do a green field 
 project, and didn't mind the Java 7 requirement, invokedynamic is very 
 compelling, because you can basically push a bunch of code down into the 
 JVM. This mean much less work, and it means you get to benefit from any 
 improvements and optimizations that get built into the JVM. Even for Clojure 
 having an optional Java 7 target may still be interesting in that it allows 
 you to hook into all the work that will be done on invokedynamic to support 
 the whole dynamic language ecosystem on the JVM.
  

 Clojure can get away with this especially easily because the only variant 
 for function signatures in Clojure is arity. So, all we need is a simple 
 switch to call the IFn method with the correct arity. (Interestingly, this 
 means that Clojure has a fixed set of such signatures, and thus a fixed 
 upper limit to arity: 20, in case you were wondering.)

 In a language like Ruby, methods are not so free floating, and have much 
 more complex invocation styles as well as flexible signatures. (Clojure has 
 only one style: function calls are simple forms.) So, in order to use 
 invokeinterface, JRuby implementors would have had to create special classes 
 *per* method *per* invocation style if they wanted to be efficient. But this 
 is impossible, because so many classes would exhaust the perm-gen. For those 
 languages, invokedynamic is a terrific solution, because it lets them 
 dynamically link the implementation to the caller via a flexible 
 bootstrapping mechanism, allowing them to do entirely without the extra 
 class definition. Since all Clojure functions share essentially the same 
 class as well as interface, none of these challenges exist.


 It's very possible that I'm missing something, but I'm not quite sure what 
 you're getting at here. In JRuby, for instance, the method overloading is 
 the same as in Clojure, it is based on arity. The slowdown is in dispatch 
 where you have to check a singleton class, your class, your ancestors, then 
 method_missing, etc. Once you've looked this all up you cache it to speed it 
 up later. Then you want to invalidate the cache when the world changes.

 Clojure has similar needs. For instance, Clojure has protocol dispatch and 
 multimethod dispatch as well as Var based dispatch. The multimethod dispatch 
 does a look up in the derivation hierarchy. All of this stuff can change at 
 runtime, just like in Ruby you can add methods to a class, change methods on 
 a class, etc. I don't see how Clojure's dispatch needs are much different 
 than what other dynamic languages are doing.
  

 Another aspect is the immutability of these IFn instances: you can't 
 refactor them at runtime, all you can do is change the bindings to refer to 
 new functions. So, Clojure achieves runtime dynamics by letting you simply 
 rebind new functions to existing Vars, Refs, Atoms, etc., and the same 
 invocation route continues as usual. In a language like Ruby, the 
 bootstrapping mechanism of invokedynamic lets implementors change the base 
 linkage to reflect a new signature for the method. Again, a terrific JVM 7 
 feature that Clojure simply does not need.


 The signature of a JRuby method is not much different than a Clojure 

Re: Funding Clojure 2010

[Charles Nutter]

You might find this interesting:

http://www.oreillynet.com/ruby/blog/2008/03/the_ruby_mendicant_project.html

Or this:

http://www.modrails.com/enterprise.html

There are only a handful of such efforts in the Ruby community, but
when buoyed by a reasonably large and active community, it is possible
to live off donations for some time. The Mendicant project lasted over
a summer, and the Phusion guys periodically run donation drives to
bring them up to a particular amount. I know lots of other sites run
similar drives, but they're always targeting a particular dollar
value. Perhaps that might be worth doing here, so people know whether
their $X have brought you closer to a specific goal? At any rate
contacting groups who have run similar drives might stir up some ideas
too.

Best of luck with the donation drive, either way, and after Christmas
perhaps my wife will let me near the bank account again so I can make
a donation myself :)

- Charlie

On Dec 14, 8:33 am, Rich Hickey richhic...@gmail.com wrote:
 Funding Clojure 2010

 Background
 --

 It is important when using open source software that you consider who
 is paying for it, because someone is. There is no such thing as free
 software.

 Sometimes open source software is developed under a license with
 undesirable properties (e.g. the GPL), such that people are willing to
 pay for a (proprietary) version of it that is not subject to that
 license. Both Monty Widenius [1] and Richard Stallman [2] have argued
 for the necessity of such a mechanism to fund open source software,
 lest there be insufficient resources for its development. Clojure
 doesn't use the GPL, thus conveying more freedom to its users, but
 precluding me from funding it via dual licensing.

 Some companies develop technology as a component of a proprietary
 product or service, absorbing it as a necessary expense, only to
 decide that it is not a core, unique, or advantage-bearing business
 function. They can reduce their costs in ongoing development by open
 sourcing it, deriving benefit from community contributions and letting
 them focus on their core business [3]. It is important to note that
 the bulk of the costs are often in the original development, and are
 paid for by the proprietary product or service. That is not the case
 for Clojure.

 Some open source is the product of academic research, and is funded by
 the academic institution and/or research grants [4]. That is not the
 case for Clojure.

 Some open source software is (partially) funded by proprietary
 support. It is important to note that often the support income does
 not in fact make it to the people who create the software. Such income
 models work best for support sold to conservative enterprises [5].
 That is not the case for Clojure.

 Some companies 'fund' open source software by dedicating some of their
 employees' time, or making investments, in its development. There must
 be some business value to the company for doing so (e.g. it helps them
 sell hardware [6]), and thus is ultimately paid for by their
 proprietary products/services. That is not the case for Clojure.

 There *are* companies that make software themselves, whose consumers
 see a value in it and willingly pay to obtain that value. The money
 produced by this process pays the salaries of the people who are
 dedicated to making it, and some profit besides. It's called
 proprietary software. People pay for proprietary software because
 they have to, but otherwise the scenario is very similar to open
 source - people make software, consumers get value from it. In fact,
 we often get a lot less with proprietary software - vendor lock-in, no
 source etc. Most alarmingly, this is the only model that associates
 value with software itself, and therefore with the people who make it.

 Why don't people pay for open source software? Primarily, because they
 don't *have to*. I think also, partially, it is because open source
 software often doesn't have a price tag. I think it should. I'd like
 to pay for open source, and know the money is going to those who
 create it. I'd like companies to *expect* to pay for it. I'd like to
 see people make a living (and even profit!) directly making open
 source, not as a side effect of some other proprietary process, to
 dedicate themselves to it, and not have it be hobby/side work.

 Unfortunately, there seems to be no way to convey the full benefits of
 open source software while *forcing* people to pay for it. Only in the
 proprietary (including dual-license) model is there a direct
 connection between the consumers of software and the funding of those
 that produce it. This is having the effect of driving open source
 software towards having zero apparent cost, becoming a free bounty of
 someone else's other profitable endeavors, and is severely
 compromising our profession.

 Foreground
 --

 As should be obvious, Clojure is a labor of love on my part. Started
 as a self-funded sabbatical 

Re: Funding Clojure 2010

[Charles Nutter]

On Dec 14, 12:19 pm, BerlinBrown berlin.br...@gmail.com wrote:
 Have you ever considered working with a larger company like Oracle/
 Sun, IBM or Google in some kind of research capacity and working on
 Clojure full time there?  For example, I believe the JRuby developers
 worked for Sun at one point while they developed JRuby.

Those were certainly happier times for our industry. Then someone
else's bubble burst (not our fault this time!) and things got tight
again.

Tom Enebo and I were hired by Sun in 2006, and we are very thankful to
Sun for all their sponsorship during the years until we had to make
our exit. It's a damn shame more companies aren't like Sun, willing to
fund promising open-source projects for both the tangible and
intangible benefits they may produce...but with a better strategy for
helping those projects fund their bottom-lines.

To be honest, I still feel like there's a company waiting to happen
that specializes in JVM languages, the frameworks around them, and
making the best use of available language and VM experts. You wouldn't
need that many developers to form the technology core and there would
be scads of support, consulting, and grant-driven research
possibilities as a result. And that's not even mentioning that on the
non-JVM side of the world, Microsoft *does* fund multiple languages,
all in-house, all sharing resources. The Bazaar is definitely stronger
in some areas, but collaboration across religious boundaries is not
one of them.

Unfortunately I think the whole world is still struggling to find the
right way to make funding open-sourced products profitable in the long
term, especially in lean times when people tragically take advantage
of unrestricted common resources. The sad situation is that a massive
number of companies derive tremendous benefits for free on the backs
of open-source devs. I don't know how to fix it.

- Charlie

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

Re: Krishnamurthi's Automata in Clojure (OutOfMemoryError)

[Charles Gordon]

Mark,

That did the trick, thanks! I'll definitely be testing my loops for
this sort of thing in the future. It's a little worrisome that it's
this easy to write a major memory leak in Clojure, but I guess this is
just one of the consequences of writing a functional language on top
of the JVM. Maybe it's time for all of us to switch to the CLR! (Rich
mentions that they don't have this problem in the other thread).

CG.

On Nov 27, 6:53 pm, Mark Triggs mark.h.tri...@gmail.com wrote:
 Hi Charles,

 I notice I can stop your version from running out of memory with a very
 small change.  Changing from:

   ;; the [f  args] form of trampoline
   (trampoline init start-stream)

 to:

   ;; the [f] form of trampoline
   (trampoline #(init start-stream))

 seems to work as expected.  I would hazard a guess that this might be
 the same issue as described in this thread:

  http://groups.google.com/group/clojure/msg/dfb1c1d68ac7e742

 Cheers,

 Mark



 Charles Gordon charles.gor...@gmail.com writes:
  The implementation listed there doesn't work, and is before Rich
  introduced letfn, so I decided to try my own implementation using
  letfn and trampoline:

  (defn machine [start-stream]
    (letfn [(init [stream]
                  #(cond (empty? stream) true
                          (= \c (first stream)) (more (rest stream))
                          :else false))
            (more [stream]
                  #(cond (empty? stream) true
                          (= \a (first stream)) (more (rest stream))
                          (= \d (first stream)) (more (rest stream))
                          (= \r (first stream)) (end (rest stream))
                          :else false))
            (end [stream]
                 #(cond (empty? stream) true
                         :else false))]
      (trampoline init start-stream)))

  This works, but if I try to run it on an infinite sequence, it
  eventually runs out of memory:

  (machine (iterate (fn [c] (if (= c \c) \a \d)) \c))

  Java heap space
    [Thrown class java.lang.OutOfMemoryError]

 --
 Mark Triggs
 mark.h.tri...@gmail.com

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

Krishnamurthi's Automata in Clojure (OutOfMemoryError)

[Charles Gordon]

I've been working on a problem that requires me to write a small state
machine for processing XML documents. Out of curiousity (I'm new to
functional programming) I hit Google to see how automata are written
in other functional languages. I found Shriram Krishnamurthi's paper:

http://lambda-the-ultimate.org/node/569

It is discussed further, along with a Clojure implementation,  here:

http://list.cs.brown.edu/pipermail/plt-scheme/2007-November/thread.html#21571

The implementation listed there doesn't work, and is before Rich
introduced letfn, so I decided to try my own implementation using
letfn and trampoline:

(defn machine [start-stream]
  (letfn [(init [stream]
#(cond (empty? stream) true
(= \c (first stream)) (more (rest stream))
:else false))
  (more [stream]
#(cond (empty? stream) true
(= \a (first stream)) (more (rest stream))
(= \d (first stream)) (more (rest stream))
(= \r (first stream)) (end (rest stream))
:else false))
  (end [stream]
   #(cond (empty? stream) true
   :else false))]
(trampoline init start-stream)))

This works, but if I try to run it on an infinite sequence, it
eventually runs out of memory:

(machine (iterate (fn [c] (if (= c \c) \a \d)) \c))

Java heap space
  [Thrown class java.lang.OutOfMemoryError]

I don't understand the underlying model of Clojure's runtime well
enough to understand why this is occurring. I'm not getting a stack
overflow error, so it seems likely that something is holding onto
memory (perhaps the entire stream?). Does anyone have any insight into
this?

Thanks!
Charles Gordon

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

Re: Troll in our midst - please ignore them

[Charles]

It's unfortunate when a troll has a brain and uses it for evildoing.

Thank you Rich for the language, and your efforts at moderation.

On Jun 29, 12:56 am, Alex Combas alex.com...@gmail.com wrote:
 On Sun, Jun 28, 2009 at 10:21 PM, CuppoJava patrickli_2...@hotmail.comwrote:



  Thank you Denfer,
  That's a very interesting trick. I'm sure it'll be handy to me in the
  future. I really never considered trolls a possibility on this forum.
  It seems if that sort of thing interests you, there's much easier and
  satisfying prey elsewhere.

 heh, well if trolls had brains they wouldn't be trolls now would they?

 Best regards,
 agc

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