Re: [ANN] Clojure 1.8.0-alpha4

[Dragan Djuric]

Clojure only supports long and double primitives as function hints. You are 
using int; it didn't work with pre-1.8.0 clojure.

-- 
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: ClojureScript Self-hosting Demo

[kinleyd]

Hi all,

I've looked at the Optional Self-hosting section on the ClojureScript Github 
wiki. Would it be possible to have a more step-by-step set of instructions for 
experimentig with self hosting OR could someone point me to a resource which 
provides one?

Thanks,

Kinley

-- 
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: ClojureScript Self-hosting Demo

[kinleyd]

Hi all,

I've looked at the Option Self-hosting section section on the ClojureScript 
Github wiki. Would it be possible to have a more step-by-step set of 
instructions for self hosting OR could someone point me to resource which 
provides one?

Thanks,

Kinley

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

Re: Using a dynamic var for my database connection for implicit connections+transactions

[Dmitri]

My understanding is that the problem is actually caused by the stateless 
nature of the functions. Since the function accepts the connection as a 
parameter it's up to the user of the function to ensure that it's passed 
the correct connection. Every functional solution presented in this thread 
suffers from this same fundamental problem that the function is not aware 
of the context it's being run in.

On Monday, August 3, 2015 at 10:16:28 PM UTC-4, Rob Lally wrote:
>
> Everything you say is true. And programming is always about picking the 
> right trade-offs at the right time, making this sort of conversation one 
> that can never come to a *right* answer.
>
> But… in this case Pablo was experiencing concrete problems: those problems 
> stemmed from how easy it was to make mistakes having both a global 
> connection pool and the option to pass around specific connections which 
> had transactions open. Having two conflicting ways of doing the same thing 
> was causing problems. Eliminating at least one of them is a solution. Pablo 
> felt that he might want to eliminate both and add a new mechanism. A number 
> of people (including me) felt that Pablo’s proposed solution would, 
> potentially, lead to new problems and that eliminating only one of the 
> original mechanisms would be sufficient to solve his problems.
>
> In a very real sense, the pragmatic solution and the most “pure” solution 
> seem - to me at least - to be the same.
>
>
> R.
>
>
> On 3 Aug 2015, at 18:19, Dmitri > 
> wrote:
>
> While I generally agree that purity is something to strive for, I think 
> it's also important to consider the problem that's being solved in each 
> particular scenario. While creating stateless database query functions and 
> passing the connection round explicitly achieves purity, it's not entirely 
> clear what practical problem that's addressing. However, the practical 
> disadvantages are that you end up with is additional variable being passed 
> around and more opportunities for user error as is the case with 
> transactions. While there is mental overhead in having to understand that 
> the functions use an implicit connection, there's conversely additional 
> mental overhead in having to remember what connection to use when with the 
> explicit approach.
>
> In some applications it might be valuable to pass the database around 
> explicitly. Yet, many of the applications in the wild tend to deal with a 
> single database instance where a connection is created when the application 
> is started and retained for the lifecycle of the application. Creating the 
> additional hoops for the user to jump through for purely theoretical 
> benefit seems unwarranted in this scenario. 
>
>
> On Monday, August 3, 2015 at 6:48:05 PM UTC-4, Rob Lally wrote:
>>
>> Hey Pablo,
>>
>> Sorry, you are completely correct: I accidentally typed transaction when 
>> I meant connection. My bad.
>>
>> I don’t understand what you mean by connections having to be global when 
>> dealing with an RDBMS. It is true that you normally want to pool them to 
>> conserve resources, and that pooling may be global in nature - but it also 
>> may not be. Quality of Service demands often necessitate multiple pools to 
>> the same data-source to be created and accessed independently. You also, 
>> sometimes, want to access different databases from the same application, 
>> that gets much harder - and your code becomes less general if you need to 
>> reference specific global connection-pools.
>>
>> I’m also a little confused by your suggestion that it would be impossible 
>> to enclose each test in a transaction. The article you point to shows one 
>> way. Another way I’ve used often is to declare a var holding a ref and in a 
>> fixture initialise/close a connection around the test. The test function 
>> then derefences the var holding the connection passing it into the function 
>> under test. This does make it impossible to run tests in parallel, but 
>> that’s not something I’ve ever tried. Creating tests that access shared 
>> resources is a little bit uglier than in a OO language where you could more 
>> easily reference an instance variable but it isn’t much worse, and a little 
>> macro-pixie dust can make it all go away.
>>
>> I will say that it has been my experience that you don’t find yourself 
>> passing database connection pools around everywhere. As your code grows you 
>> naturally extract components/protocols that wrap all that up. Your 
>> ring-handler doesn’t need a connection it needs some sort of data-access 
>> component. That component needs a connection/connection pool but that can 
>> be passed in at construction time. I have feared the creation of functions 
>> that need an ever increasing number of parameters that need to be passed 
>> on, but it isn’t something I find happens in practice. Of course, YMMV.
>>
>> I would respectfully suggest that the solutions are not the same. My way 
>> has no global state and functi

Re: Using a dynamic var for my database connection for implicit connections+transactions

[Rob Lally]

Everything you say is true. And programming is always about picking the right 
trade-offs at the right time, making this sort of conversation one that can 
never come to a *right* answer.

But… in this case Pablo was experiencing concrete problems: those problems 
stemmed from how easy it was to make mistakes having both a global connection 
pool and the option to pass around specific connections which had transactions 
open. Having two conflicting ways of doing the same thing was causing problems. 
Eliminating at least one of them is a solution. Pablo felt that he might want 
to eliminate both and add a new mechanism. A number of people (including me) 
felt that Pablo’s proposed solution would, potentially, lead to new problems 
and that eliminating only one of the original mechanisms would be sufficient to 
solve his problems.

In a very real sense, the pragmatic solution and the most “pure” solution seem 
- to me at least - to be the same.


R.


> On 3 Aug 2015, at 18:19, Dmitri  wrote:
> 
> While I generally agree that purity is something to strive for, I think it's 
> also important to consider the problem that's being solved in each particular 
> scenario. While creating stateless database query functions and passing the 
> connection round explicitly achieves purity, it's not entirely clear what 
> practical problem that's addressing. However, the practical disadvantages are 
> that you end up with is additional variable being passed around and more 
> opportunities for user error as is the case with transactions. While there is 
> mental overhead in having to understand that the functions use an implicit 
> connection, there's conversely additional mental overhead in having to 
> remember what connection to use when with the explicit approach.
> 
> In some applications it might be valuable to pass the database around 
> explicitly. Yet, many of the applications in the wild tend to deal with a 
> single database instance where a connection is created when the application 
> is started and retained for the lifecycle of the application. Creating the 
> additional hoops for the user to jump through for purely theoretical benefit 
> seems unwarranted in this scenario. 
> 
> 
> On Monday, August 3, 2015 at 6:48:05 PM UTC-4, Rob Lally wrote:
> Hey Pablo,
> 
> Sorry, you are completely correct: I accidentally typed transaction when I 
> meant connection. My bad.
> 
> I don’t understand what you mean by connections having to be global when 
> dealing with an RDBMS. It is true that you normally want to pool them to 
> conserve resources, and that pooling may be global in nature - but it also 
> may not be. Quality of Service demands often necessitate multiple pools to 
> the same data-source to be created and accessed independently. You also, 
> sometimes, want to access different databases from the same application, that 
> gets much harder - and your code becomes less general if you need to 
> reference specific global connection-pools.
> 
> I’m also a little confused by your suggestion that it would be impossible to 
> enclose each test in a transaction. The article you point to shows one way. 
> Another way I’ve used often is to declare a var holding a ref and in a 
> fixture initialise/close a connection around the test. The test function then 
> derefences the var holding the connection passing it into the function under 
> test. This does make it impossible to run tests in parallel, but that’s not 
> something I’ve ever tried. Creating tests that access shared resources is a 
> little bit uglier than in a OO language where you could more easily reference 
> an instance variable but it isn’t much worse, and a little macro-pixie dust 
> can make it all go away.
> 
> I will say that it has been my experience that you don’t find yourself 
> passing database connection pools around everywhere. As your code grows you 
> naturally extract components/protocols that wrap all that up. Your 
> ring-handler doesn’t need a connection it needs some sort of data-access 
> component. That component needs a connection/connection pool but that can be 
> passed in at construction time. I have feared the creation of functions that 
> need an ever increasing number of parameters that need to be passed on, but 
> it isn’t something I find happens in practice. Of course, YMMV.
> 
> I would respectfully suggest that the solutions are not the same. My way has 
> no global state and functional purity-lite (those connections are rarely 
> idempotent): which are obviously only theoretical benefits. But it does work 
> when I do it; I like my code, I don’t have problems working with it, and I 
> genuinely don’t face any of the challenges you’re struggling with.
> 
> 
> 
> R.
> 
> 
> 
>> On 3 Aug 2015, at 03:19, J. Pablo Fernández pupeno.com 
>> > wrote:
>> 
>> Rob,
>> 
>> The transactions are not global, the transactions are local. Connections are 
>> global and there's no way around it with the constraints o

Re: Using a dynamic var for my database connection for implicit connections+transactions

[Dmitri]

While I generally agree that purity is something to strive for, I think 
it's also important to consider the problem that's being solved in each 
particular scenario. While creating stateless database query functions and 
passing the connection round explicitly achieves purity, it's not entirely 
clear what practical problem that's addressing. However, the practical 
disadvantages are that you end up with is additional variable being passed 
around and more opportunities for user error as is the case with 
transactions. While there is mental overhead in having to understand that 
the functions use an implicit connection, there's conversely additional 
mental overhead in having to remember what connection to use when with the 
explicit approach.

In some applications it might be valuable to pass the database around 
explicitly. Yet, many of the applications in the wild tend to deal with a 
single database instance where a connection is created when the application 
is started and retained for the lifecycle of the application. Creating the 
additional hoops for the user to jump through for purely theoretical 
benefit seems unwarranted in this scenario. 


On Monday, August 3, 2015 at 6:48:05 PM UTC-4, Rob Lally wrote:
>
> Hey Pablo,
>
> Sorry, you are completely correct: I accidentally typed transaction when I 
> meant connection. My bad.
>
> I don’t understand what you mean by connections having to be global when 
> dealing with an RDBMS. It is true that you normally want to pool them to 
> conserve resources, and that pooling may be global in nature - but it also 
> may not be. Quality of Service demands often necessitate multiple pools to 
> the same data-source to be created and accessed independently. You also, 
> sometimes, want to access different databases from the same application, 
> that gets much harder - and your code becomes less general if you need to 
> reference specific global connection-pools.
>
> I’m also a little confused by your suggestion that it would be impossible 
> to enclose each test in a transaction. The article you point to shows one 
> way. Another way I’ve used often is to declare a var holding a ref and in a 
> fixture initialise/close a connection around the test. The test function 
> then derefences the var holding the connection passing it into the function 
> under test. This does make it impossible to run tests in parallel, but 
> that’s not something I’ve ever tried. Creating tests that access shared 
> resources is a little bit uglier than in a OO language where you could more 
> easily reference an instance variable but it isn’t much worse, and a little 
> macro-pixie dust can make it all go away.
>
> I will say that it has been my experience that you don’t find yourself 
> passing database connection pools around everywhere. As your code grows you 
> naturally extract components/protocols that wrap all that up. Your 
> ring-handler doesn’t need a connection it needs some sort of data-access 
> component. That component needs a connection/connection pool but that can 
> be passed in at construction time. I have feared the creation of functions 
> that need an ever increasing number of parameters that need to be passed 
> on, but it isn’t something I find happens in practice. Of course, YMMV.
>
> I would respectfully suggest that the solutions are not the same. My way 
> has no global state and functional purity-lite (those connections are 
> rarely idempotent): which are obviously only theoretical benefits. But it 
> does work when I do it; I like my code, I don’t have problems working with 
> it, and I genuinely don’t face any of the challenges you’re struggling with.
>
>
>
> R.
>
>
>
> On 3 Aug 2015, at 03:19, J. Pablo Fernández  > wrote:
>
> Rob,
>
> The transactions are not global, the transactions are local. Connections 
> are global and there's no way around it with the constraints of a 
> traditional RDBMs. Your idea of making the global connection unavailable 
> for code that's in the context of a transaction would prevent the errors 
> I'm trying to prevent but you would still required to pass the connection 
> around, which in a webapp, means that the whole chain of function calls, 
> pretty much everything, would have a database connection. That is ugly in 
> some cases, impossible in others.
>
> A piece of code that would be impossible is to enclose each test in a 
> transaction using clojure.test: 
> http://stackoverflow.com/questions/31735423/how-to-pass-a-value-from-a-fixture-to-a-test-with-clojure-test
>
> Furthermore, I don't think this solution gains you any purity, you still 
> have a global estate and you are hiding it away when starting a 
> transaction. My proposal was to make it work instead of hiding it. They are 
> rather equivalent from the complexity point of view.
>
>
>

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

Re: [ANN] Clojure 1.8.0-alpha4

[Rangel Spasov]

Thanks for the new alpha everyone!

Getting a compiler error below.

I think it's because of:

https://github.com/hugoduncan/clj-ssh/blob/develop/src/clj_ssh/ssh.clj 

(defn ^int session-port
  "Return the port for a session"
  [^Session session]
  (.getPort session))

Is this by design?

Rangel

#error {

 :cause Only long and double primitives are supported

 :via

 [{:type clojure.lang.Compiler$CompilerException

   :message java.lang.IllegalArgumentException: Only long and double 
primitives are supported, compiling:(clj_ssh/ssh.clj:345:1)

   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6894]}

  {:type java.lang.IllegalArgumentException

   :message Only long and double primitives are supported

   :at [clojure.lang.Compiler$FnMethod parse Compiler.java 5312]}]

 :trace

 [[clojure.lang.Compiler$FnMethod parse Compiler.java 5312]

  [clojure.lang.Compiler$FnExpr parse Compiler.java 3975]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6885]

  [clojure.lang.Compiler analyze Compiler.java 6688]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6875]

  [clojure.lang.Compiler analyze Compiler.java 6688]

  [clojure.lang.Compiler access$300 Compiler.java 38]

  [clojure.lang.Compiler$DefExpr$Parser parse Compiler.java 593]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6887]

  [clojure.lang.Compiler analyze Compiler.java 6688]

  [clojure.lang.Compiler analyze Compiler.java 6649]

  [clojure.lang.Compiler eval Compiler.java 6950]

  [clojure.lang.Compiler load Compiler.java 7393]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5445 invoke core.clj 5871]

  [clojure.core$load invokeStatic core.clj 5870]

  [clojure.core$load_one invokeStatic core.clj 5671]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5394 invoke core.clj 5716]

  [clojure.core$load_lib invokeStatic core.clj 5715]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 635]

  [clojure.core$load_libs invokeStatic core.clj 5753]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 635]

  [clojure.core$require invokeStatic core.clj 5775]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 930]

  [cloud_monkey.ssh$eval21651$loading__5337__auto21652 invoke ssh.clj 1]

  [cloud_monkey.ssh$eval21651 invokeStatic ssh.clj 1]

  [cloud_monkey.ssh$eval21651 invoke ssh.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6946]

  [clojure.lang.Compiler eval Compiler.java 6935]

  [clojure.lang.Compiler load Compiler.java 7393]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5445 invoke core.clj 5871]

  [clojure.core$load invokeStatic core.clj 5870]

  [clojure.core$load_one invokeStatic core.clj 5671]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5394 invoke core.clj 5716]

  [clojure.core$load_lib invokeStatic core.clj 5715]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 635]

  [clojure.core$load_libs invokeStatic core.clj 5753]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 635]

  [clojure.core$require invokeStatic core.clj 5775]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 1289]

  [cloud_monkey.execution_pipeline$eval21645$loading__5337__auto21646 
invoke execution_pipeline.clj 1]

  [cloud_monkey.execution_pipeline$eval21645 invokeStatic 
execution_pipeline.clj 1]

  [cloud_monkey.execution_pipeline$eval21645 invoke execution_pipeline.clj 
-1]

  [clojure.lang.Compiler eval Compiler.java 6946]

  [clojure.lang.Compiler eval Compiler.java 6935]

  [clojure.lang.Compiler load Compiler.java 7393]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5445 invoke core.clj 5871]

  [clojure.core$load invokeStatic core.clj 5870]

  [clojure.core$load_one invokeStatic core.clj 5671]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5394 invoke core.clj 5716]

  [clojure.core$load_lib invokeStatic core.clj 5715]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 635]

  [clojure.core$load_libs invokeStatic core.clj 5753]

  [clojure.core$load_libs do

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

On Mon, Aug 3, 2015 at 1:25 PM, Mark Engelberg 
wrote:



> The main reason I mentioned Intellij was because I didn't know whether
> there was a satisfactory Python plugin for Eclipse and you said you wanted
> to do all three languages on one IDE.
>
>

Gotcha.  The answer is yes, it's called PyDev and even our older version
meets our needs.  Per the link to course content (we open source the
textbooks, just as one may browse in a college book store, to see what the
profs are using) our needs in the IDE department are modest.

A current weakness is our not using Eclipse's native ability to back end
into version control.  There's only so much one wants to cover when billing
the course as Python, plus we're meeting our students as solo coders, not
as dev teams.  ALE could take it all a lot further, in terms of course-ware
topology.

http://courses.oreillyschool.com/  (recap of our learning environments:
CodeRunner, Eclipse, and Visual Studio)

I'm really new to IntelliJ but a happy user of Pycharm, same JetBrains
behind both.

Even if we stick with Eclipse I could see advising students to check out
that platform.

To use a particular IDE is not to be mean or dismissive to all others.  On
the contrary, I admire vim while using it sparingly, just like I'm not
often in a jazz bar on the piano (after closing time maybe, if I know the
owner).

New Yorker says StarBucks is actually good for the local shops because it
schools people in the culture, via something known and mainstream (i.e.
safe) and that gives them the confidence to branch out and get off the
beaten track.

Likewise a glancing but not unpleasant experience with Eclipse could feed a
next generation of Emacs users.  It's more the whole idea of "dashboards
for developers" that we want to get across, and Eclipse is a good example,
both multi-language and free.



> In my role as a tutor to bright comp sci kids, I was using Clojure for
> personal use several years before I was willing to start teaching it to
> kids, mainly because when Clojure first came out, emacs was pretty much the
> only game in town, and I knew it wouldn't go well if I tried to teach new
> programming language concepts to kids while simultaneously inflicting upon
> them an alien editor that behaves completely differently from every other
> editor they've ever used.  So I waited until Counterclockwise reached
> sufficient maturity before incorporating Clojure into my tutoring.
>


My trajectory is similar in that I've used Python with middle through high
school aged, most recently with Saturday Academy, piloting what I call
Martian Math in my four-aspect Digital Math (the others being Supermarket,
Casino, and Neolithic.

I know that sounds weird but the Neolithic-to-Martian axis gives like a
timeline (math meets history) with a science fiction view of the future.
The other axis, with Supermarket the persistence layer (inventory,
bookkeeping) and Casino representing risk, investment, probabilities.
Makes a nice package in that you can fit anything in.

http://wikieducator.org/Digital_Math  FYI.

Anyway, just saying, like you I've not ventured to teach any LISP-family
language and in my post to edu-...@python.org recently (another listserv)
it was all about { Python -> Java -> Clojure } sequence with the former in
high school and the latter not expected until college unless you want an
accelerated experience.

Here's that post:
https://mail.python.org/pipermail/edu-sig/2015-August/011290.html

In other words, just to sketch a possibility (one among many):

(A) use what Phillips-Andover uses, Mathematics for the Digital Age and
Programming in Python, with that high schoolish age group, then

(B) move to Java,

(C) then cap with Clojure, which coming from Java means you'll appreciate
about interop, i.e. you know your heritage.

Not saying that's the best or only trajectory, just that's a good example
of what I imagine the ALE (Asynchronous Learning Machine) --  with some
Open Source license -- could provide the bare bones for.

In favor of the { Python -> Java -> Clojure } track is that it gives the
full dose of OO on the way to FP, and it's in climbing out to that level
that you feel more control over heritage in OO.  I don't think OO is over,
but that the discipline of FP will keep OO from decaying as quickly. :-D

With Clojure, the Java stack is still yours (I understand about the .NET
version) -- and not just the JVM but the libraries.

Plus (maybe not everyone knows this here):  Python likewise comes in a
flavor that targets the JVM as well:  Jython, open source from Oracle.

Seems a promising ecosystem all round!  Thanks for engaging (both here and
on edu-sig).

Kirby

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

Re: Using a dynamic var for my database connection for implicit connections+transactions

[Rob Lally]

Hey Pablo,

Sorry, you are completely correct: I accidentally typed transaction when I 
meant connection. My bad.

I don’t understand what you mean by connections having to be global when 
dealing with an RDBMS. It is true that you normally want to pool them to 
conserve resources, and that pooling may be global in nature - but it also may 
not be. Quality of Service demands often necessitate multiple pools to the same 
data-source to be created and accessed independently. You also, sometimes, want 
to access different databases from the same application, that gets much harder 
- and your code becomes less general if you need to reference specific global 
connection-pools.

I’m also a little confused by your suggestion that it would be impossible to 
enclose each test in a transaction. The article you point to shows one way. 
Another way I’ve used often is to declare a var holding a ref and in a fixture 
initialise/close a connection around the test. The test function then 
derefences the var holding the connection passing it into the function under 
test. This does make it impossible to run tests in parallel, but that’s not 
something I’ve ever tried. Creating tests that access shared resources is a 
little bit uglier than in a OO language where you could more easily reference 
an instance variable but it isn’t much worse, and a little macro-pixie dust can 
make it all go away.

I will say that it has been my experience that you don’t find yourself passing 
database connection pools around everywhere. As your code grows you naturally 
extract components/protocols that wrap all that up. Your ring-handler doesn’t 
need a connection it needs some sort of data-access component. That component 
needs a connection/connection pool but that can be passed in at construction 
time. I have feared the creation of functions that need an ever increasing 
number of parameters that need to be passed on, but it isn’t something I find 
happens in practice. Of course, YMMV.

I would respectfully suggest that the solutions are not the same. My way has no 
global state and functional purity-lite (those connections are rarely 
idempotent): which are obviously only theoretical benefits. But it does work 
when I do it; I like my code, I don’t have problems working with it, and I 
genuinely don’t face any of the challenges you’re struggling with.



R.



> On 3 Aug 2015, at 03:19, J. Pablo Fernández  wrote:
> 
> Rob,
> 
> The transactions are not global, the transactions are local. Connections are 
> global and there's no way around it with the constraints of a traditional 
> RDBMs. Your idea of making the global connection unavailable for code that's 
> in the context of a transaction would prevent the errors I'm trying to 
> prevent but you would still required to pass the connection around, which in 
> a webapp, means that the whole chain of function calls, pretty much 
> everything, would have a database connection. That is ugly in some cases, 
> impossible in others.
> 
> A piece of code that would be impossible is to enclose each test in a 
> transaction using clojure.test: 
> http://stackoverflow.com/questions/31735423/how-to-pass-a-value-from-a-fixture-to-a-test-with-clojure-test
>  
> 
> 
> Furthermore, I don't think this solution gains you any purity, you still have 
> a global estate and you are hiding it away when starting a transaction. My 
> proposal was to make it work instead of hiding it. They are rather equivalent 
> from the complexity point of view.

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

Re: core.async: implementing pi.go

[Divyansh Prakash]

>
> does maya automatically handle operator precedence?
>

maya always evals from left to right. 

(maya 1 + 5 :as six, six * 2 :as twelve, twelve / 3 * 2) ;=> 8
>
>
- Divyansh 

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Mark Engelberg]

I currently use Eclipse Counterclockwise and have me eye on Cursive (will
evaluate it more seriously when it is officially released).  Eclipse is
reasonably well suited for beginners working in Clojure, I think.
Certainly it has the simplest install process of any of the platforms right
now.  When I go out and do Clojure training, I start everyone on
Counterclockwise for the first few sessions, and then allow them to move to
whatever platform they want.  It is a fine choice.

The main reason I mentioned Intellij was because I didn't know whether
there was a satisfactory Python plugin for Eclipse and you said you wanted
to do all three languages on one IDE.

In my role as a tutor to bright comp sci kids, I was using Clojure for
personal use several years before I was willing to start teaching it to
kids, mainly because when Clojure first came out, emacs was pretty much the
only game in town, and I knew it wouldn't go well if I tried to teach new
programming language concepts to kids while simultaneously inflicting upon
them an alien editor that behaves completely differently from every other
editor they've ever used.  So I waited until Counterclockwise reached
sufficient maturity before incorporating Clojure into my tutoring.

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

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Senior Clojure Software Engineer at Guaranteed Rate

http://functionaljobs.com/jobs/8853-senior-clojure-software-engineer-at-guaranteed-rate



Server Engineer at ActionX

http://functionaljobs.com/jobs/8850-server-engineer-at-actionx



DevOps Engineer at ActionX

http://functionaljobs.com/jobs/8849-devops-engineer-at-actionx



Cheers,

Sean Murphy

FunctionalJobs.com


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

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

On Mon, Aug 3, 2015 at 8:18 AM, Fluid Dynamics  wrote:

> On Monday, August 3, 2015 at 10:26:34 AM UTC-4, kirby urner wrote:
>>
>>
>> (A) when a student hacks on a Python or Java project and want's mentor
>> feedback, it's *not* a matter of the mentor remoting in to the student
>> instance or accessing the students V: drive.  Rather, we have software
>> infrastructure by the talented Michael Long that zips up the entire Eclipse
>> project and sends it to the mentor's computer, where it unzips.  The mentor
>> can run the code, find bugs, make changes, without touching the student's
>> original.  The mentor can send the whole project back, though usually
>> quotes and comments are sufficient.
>>
>
> Oh, dear God. You *do* know what used to happen to any unix box where
> "Help! I'm a newb, please help me, why won't my script work" was reliably
> synonymous with "sudo root" except for not needing the root password, right?
> Better that it be the virtual box in the cloud than the mentor's computer
> if that should ever happen.
>

Good points!

Yeah we don't do that.  The provisioning of an Ubuntu instance in the cloud
(or a Windows instance in today's version of the ALE) is all about not
helping students with complicated configuration / installing; all platform
specific -- and they don't need sudo rights on the instance we give them,
which instance vanishes without a trace when coursework is done.

There's no huge tech support staff necessary to this picture, since the
only umbilical cord to the learning environment is RDP (remote desktop),
which is platform specific.  But is also the only piece we have to help
with, many free and easy solutions available (I use CoRD from a Mac OSX
(where I'm root if I wanna be -- but this is not part of ALE).

As a mentor I'm on this very same setup in the cloud (running ALE, in-house
version -- we call it Nano). I'm doing my job in a cloud instance via
remote desktop to a rack space somewhere.

In role of  "mentor" I've never been root and don't need to be; Eclipse
fills my entire desktop, no need to touch Windows guts at all -- Terminal
takes me to my Linux sandbox (where I'm just another user, like the
students are)).

We do, on the other hand, encourage students to SFTP their own work back to
local platforms where they take responsibility for setting up their own
setup, mirroring ours if they like (Eclipse + MySQL... basically LAMP) or
going their own way.

It's not for us to tell them what to do when home alone.



>
> PS:  another thing ALE does not do in my world is give mentors a way to
>> assign letter grades or compute grading curves or whatever.
>>
>
> On the other hand, if a mentor grades on a curve, he deserves anything
> that happens to his computer from running students' code there. :)
>
>
We let mentors pick their own pronoun. :-D

I'm trying to stay open minded about curve grading.  I was a classroom
teacher in the brick and mortar sense, both full and part time, and I know
there's such a thing as healthy competition.

I also know a lot of our students really like a tough coach who takes no
nonsense, but on the other hand there's no comparison, no standing out as
better or worse.

Sometimes I'll say "good job, most students average three attempts to get
this -- par for the course -- you got a hole in one" (no I'm not a golfer
in real life) but there's no public scoreboard, no "grades" one has to live
with (or live up to, as the case may be).

Everyone gets the same certificate.

Good grades helped get me into Princeton though (from the Philippines),
i.e. those of us at the high end of the curve have always liked the curve,
or benefited.  But I see no reason to bake it into ALE at a primitive
level.  Could be an add on:  curve-grade.clj  :-D

Kirby

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Fluid Dynamics]

On Monday, August 3, 2015 at 10:26:34 AM UTC-4, kirby urner wrote:
>
>
> (A) when a student hacks on a Python or Java project and want's mentor 
> feedback, it's *not* a matter of the mentor remoting in to the student 
> instance or accessing the students V: drive.  Rather, we have software 
> infrastructure by the talented Michael Long that zips up the entire Eclipse 
> project and sends it to the mentor's computer, where it unzips.  The mentor 
> can run the code, find bugs, make changes, without touching the student's 
> original.  The mentor can send the whole project back, though usually 
> quotes and comments are sufficient.
>

Oh, dear God. You *do* know what used to happen to any unix box where 
"Help! I'm a newb, please help me, why won't my script work" was reliably 
synonymous with "sudo root" except for not needing the root password, right?
Better that it be the virtual box in the cloud than the mentor's computer 
if that should ever happen.

PS:  another thing ALE does not do in my world is give mentors a way to 
> assign letter grades or compute grading curves or whatever.
>

On the other hand, if a mentor grades on a curve, he deserves anything that 
happens to his computer from running students' code there. :)

-- 
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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Thanks, Alex, I will give this a try the next time I run into this. Given a 
little distance from the problem, and the insights that you and Mars0i have 
been sharing, I have a clearer picture of what was going on at compile 
time. I suspect the problem is something along these lines: Leiningen 
invokes the compiler on the file that is supposed to create my class, and 
it fails because of my incorrect ordering of function invocation and 
definition. For reasons unknown, but which if I can pin down better I will 
open as an issue with Leiningen, the output from this failed compilation is 
lost. Then when something tries tor refer to the class which was supposed 
to have been compiled and fails, the linkage error happens.

But now that you have pointed me at a way to just invoke the compiler 
directly on my problem source file, I bet I will be able to see the 
compilation errors when I do that, which will enable me to fix them without 
trial and error. 

Indeed, I just tested that by commenting out one of the functions in my 
source, confirming that Leiningen gives me the cryptic linkage error, and 
tried a manual compile from the REPL, and was given this completely helpful 
compilation error:
 

afterglow.max.core=> (compile 'afterglow.max.Metro)

CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
set-bar in this context, compiling:(afterglow/max/Metro.clj:121:7) 


So the next time I screw up, I will be able to figure out how.

Thanks, everyone! Perhaps I should open a Leiningen issue about this now.

Cheers,

  -James

On Monday, August 3, 2015 at 9:59:57 AM UTC-5, Alex Miller wrote:
>
> You can just use the clojure.core/compile function to compile. There is a 
> simple example at http://clojure.org/compilation.  
>
> I have not seen or experienced a linkage error like this before and I'm 
> not aware of any ticket like this. Generally a linkage error indicates you 
> are seeing the wrong version of a class loaded by a different classloader.
>
>
> On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:
>>
>> Wow, that is a challenge, Alex! I would have no idea how to even compile 
>> a project without Leiningen. If I ever am not using 200% of my free time 
>> working on these projects, I may try to research that. I am afraid it may 
>> be some time, though. I was just hoping this was a known issue with know 
>> solutions.
>>
>> Thanks,
>>
>>   -James
>>
>> On Aug 3, 2015, at 09:41, Alex Miller  wrote:
>>
>> If you can create a small, reproducible test case (that does not require 
>> Leiningen), please file a ticket.
>>
>> On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
>>>
>>> Indeed, I visited the page you cite while trying to pin down this 
>>> problem. However, I am fairly certain that in my case it is a weird side 
>>> effect, not a root cause: I get that message when compiling my Clojure file 
>>> if I try to call a function which is defined later in the file. If I move 
>>> the function definition up before the point where I was calling it, 
>>> everything compiles fine, and no linkage error. No library changes in 
>>> between the two tests. And this only happens when my Clojure file is 
>>> subclassing a Java object. Very, very strange...
>>>
>>> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 
  
 is consistent with that hypothesis.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.

Re: Complete lack of helpful compilation errors with :gen-class

[Alex Miller]

You can just use the clojure.core/compile function to compile. There is a 
simple example at http://clojure.org/compilation.  

I have not seen or experienced a linkage error like this before and I'm not 
aware of any ticket like this. Generally a linkage error indicates you are 
seeing the wrong version of a class loaded by a different classloader.


On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:
>
> Wow, that is a challenge, Alex! I would have no idea how to even compile a 
> project without Leiningen. If I ever am not using 200% of my free time 
> working on these projects, I may try to research that. I am afraid it may 
> be some time, though. I was just hoping this was a known issue with know 
> solutions.
>
> Thanks,
>
>   -James
>
> On Aug 3, 2015, at 09:41, Alex Miller > 
> wrote:
>
> If you can create a small, reproducible test case (that does not require 
> Leiningen), please file a ticket.
>
> On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
>>
>> Indeed, I visited the page you cite while trying to pin down this 
>> problem. However, I am fairly certain that in my case it is a weird side 
>> effect, not a root cause: I get that message when compiling my Clojure file 
>> if I try to call a function which is defined later in the file. If I move 
>> the function definition up before the point where I was calling it, 
>> everything compiles fine, and no linkage error. No library changes in 
>> between the two tests. And this only happens when my Clojure file is 
>> subclassing a Java object. Very, very strange...
>>
>> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
>>>
>>> I don't have anything helpful to say, but:  I've often gotten a useful 
>>> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
>>> Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
>>> I think that whatever's happening is not just an issue with compilation of 
>>> gen-class.  Maybe an issue involving libraries?  This page 
>>> 
>>>  
>>> is consistent with that hypothesis.
>>>
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Yay, this is the kind of insight I was hoping for! ^_^

On Monday, August 3, 2015 at 9:49:17 AM UTC-5, Mars0i wrote:
>
> Ah--if that's the problem, it sounds familiar.  Try doing 'lein clean' 
> before 'lein compile' and see whether you get the same error.  That's 
> assuming you have namespaces/classes listed after :aot in project.clj.  (If 
> not, then I don't think that 'lein compile' is actually doing anything.)
>

Excellent point, I completely forgot about that (something about spending 
fifty or so hours in the previous three days cranking out code). The only 
time compilation would actually happen, given my project configuration, 
would be in creating the überjar, because that is the only profile which 
has :aot turned on. So I should have not been surprised that my "lein 
compile" did nothing.
 

> You probably know this, but: When using Java classes, whether defined by 
> gen-class or one of the other four ways to define classes (defrecord, 
> deftype, proxy, reify), Clojure is very persnickety about compilation 
> order.   A class has to be compiled before you can compile something that 
> explicitly references it.  (No cyclic dependencies between explicit 
> references to classes.)
>

I had not thought in precisely those terms before, but I am definitely used 
to struggling with cyclic dependencies and the Clojure compiler, so I am 
fairly confident that I did not have this issue.

I think, though, that between what you just reminded me about when 
compilation (doesn't) happen, and what Alex is suggesting about running the 
compiler directly, I likely have a workaround. When I get in this state, I 
will try running the compiler directly on just the suspect Clojure file and 
see what it says.

I now strongly suspect the problem is that somewhere in the bowels of 
Leiningen, this output is being discarded.

Thanks,

  -James

-- 
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: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:
>
> Wow, that is a challenge, Alex! I would have no idea how to even compile a 
> project without Leiningen. If I ever am not using 200% 
>

I think you can do this with compile 
 and then java -cp ... .  
I've never tried it.
 

> of my free time working on these projects, I may try to research that. I 
> am afraid it may be some time, though. I was just hoping this was a known 
> issue with know solutions.
>
> Thanks,
>
>   -James
>
> On Aug 3, 2015, at 09:41, Alex Miller > 
> wrote:
>
> If you can create a small, reproducible test case (that does not require 
> Leiningen), please file a ticket.
>
> On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
>>
>> Indeed, I visited the page you cite while trying to pin down this 
>> problem. However, I am fairly certain that in my case it is a weird side 
>> effect, not a root cause: I get that message when compiling my Clojure file 
>> if I try to call a function which is defined later in the file. If I move 
>> the function definition up before the point where I was calling it, 
>> everything compiles fine, and no linkage error. No library changes in 
>> between the two tests. And this only happens when my Clojure file is 
>> subclassing a Java object. Very, very strange...
>>
>> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
>>>
>>> I don't have anything helpful to say, but:  I've often gotten a useful 
>>> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
>>> Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
>>> I think that whatever's happening is not just an issue with compilation of 
>>> gen-class.  Maybe an issue involving libraries?  This page 
>>> 
>>>  
>>> is consistent with that hypothesis.
>>>
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
>
> Indeed, I visited the page you cite while trying to pin down this problem. 
> However, I am fairly certain that in my case it is a weird side effect, not 
> a root cause: I get that message when compiling my Clojure file if I try to 
> call a function which is defined later in the file. If I move the function 
> definition up before the point where I was calling it, everything compiles 
> fine, and no linkage error. No library 
>

Ah--if that's the problem, it sounds familiar.  Try doing 'lein clean' 
before 'lein compile' and see whether you get the same error.  That's 
assuming you have namespaces/classes listed after :aot in project.clj.  (If 
not, then I don't think that 'lein compile' is actually doing anything.)

You probably know this, but: When using Java classes, whether defined by 
gen-class or one of the other four ways to define classes (defrecord, 
deftype, proxy, reify), Clojure is very persnickety about compilation 
order.   A class has to be compiled before you can compile something that 
explicitly references it.  (No cyclic dependencies between explicit 
references to classes.)
 

> changes in between the two tests. And this only happens when my Clojure 
> file is subclassing a Java object. Very, very strange...
>
> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
>>
>> I don't have anything helpful to say, but:  I've often gotten a useful 
>> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
>> Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
>> I think that whatever's happening is not just an issue with compilation of 
>> gen-class.  Maybe an issue involving libraries?  This page 
>> 
>>  
>> is consistent with that hypothesis.
>>
>

-- 
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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Wow, that is a challenge, Alex! I would have no idea how to even compile a 
project without Leiningen. If I ever am not using 200% of my free time working 
on these projects, I may try to research that. I am afraid it may be some time, 
though. I was just hoping this was a known issue with know solutions.

Thanks,

  -James

> On Aug 3, 2015, at 09:41, Alex Miller  wrote:
> 
> If you can create a small, reproducible test case (that does not require 
> Leiningen), please file a ticket.
> 
> On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
> Indeed, I visited the page you cite while trying to pin down this problem. 
> However, I am fairly certain that in my case it is a weird side effect, not a 
> root cause: I get that message when compiling my Clojure file if I try to 
> call a function which is defined later in the file. If I move the function 
> definition up before the point where I was calling it, everything compiles 
> fine, and no linkage error. No library changes in between the two tests. And 
> this only happens when my Clojure file is subclassing a Java object. Very, 
> very strange...
> 
> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
> I don't have anything helpful to say, but:  I've often gotten a useful 
> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
> Not always.  Sometimes I have to use the guess-and-comment-out method.  So I 
> think that whatever's happening is not just an issue with compilation of 
> gen-class.  Maybe an issue involving libraries?  This page 
> 
>  is consistent with that hypothesis.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: [ANN] Clojure 1.8.0-alpha4

[Alex Miller]

No, there are no plans to integrate this work.

On Monday, August 3, 2015 at 9:18:26 AM UTC-5, Solomon wrote:
>
> Congratulations. Maybe the performance optimization based on new JVM 
> Graal/Truffle is the correct way. For instance:  
> http://ssw.jku.at/Teaching/MasterTheses/Graal/TruffleClojure.pdf
> Do the Clojure core team have the plan ?
>
> 2015-08-03 20:32 GMT+08:00 Alex Miller 
> >:
>
>> Clojure 1.8.0-alpha4 is now available.
>>
>> Try it via
>> - Download: 
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha4
>> - Leiningen: [org.clojure/clojure "1.8.0-alpha4"]
>>
>> Below is a list of the tickets included in this release (about half were 
>> added in alpha2, the rest in alpha4). Also see the full change log here: 
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>>- CLJ-1060  'list*' 
>>returns not a list
>>- CLJ-1722  Typo in the 
>>docstring of 'with-bindings'
>>- CLJ-1769  Docstrings 
>>for *' and +' refer to * and +
>>- CLJ-703  Improve 
>>writeClassFile performance
>>- CLJ-1208  Optionally 
>>require namespace on defrecord class init
>>- CLJ-130  Namespace 
>>metadata lost in AOT compile
>>- CLJ-1134  star-directive 
>>in clojure.pprint/cl-format with at-prefix ("~n@*") does not obey its 
>>specification
>>- CLJ-1137  Metadata on 
>>a def gets evaluated twice
>>- CLJ-1157  Classes 
>>generated by gen-class aren't loadable from remote codebase
>>- CLJ-1225  quot 
>>overflow issues around Long/MIN_VALUE for BigInt
>>- CLJ-1250  Reducer (and 
>>folder) instances hold onto the head of seqs
>>- CLJ-1313  Correct a 
>>few unit tests
>>- CLJ-1319  array-map 
>>fails lazily if passed an odd number of arguments
>>- CLJ-1361  pprint with 
>>code-dispatch incorrectly prints a simple ns macro call
>>- CLJ-1390  pprint a 
>>GregorianCalendar results in Arity exception
>>- CLJ-1399  field name 
>>unmunged when recreating deftypes serialized into bytecode
>>- CLJ-1485  
>> clojure.test.junit/with-junit-output 
>>doesn't handle multiple expressions
>>- CLJ-1528  
>> clojure.test/inc-report-counter 
>>is not thread-safe
>>- CLJ-1533  invokePrim 
>>path does not take into account var or form meta
>>- CLJ-1562  
>> some->,some->>,cond->,cond->> 
>>and as-> doesn't work with (recur)
>>- CLJ-1565  pprint 
>>produces infinite output for a protocol
>>- CLJ-1588  StackOverflow 
>>in clojure.test macroexpand with are and anon fn
>>- CLJ-1644  into-array 
>>fails for sequences starting with nil
>>- CLJ-1645  protocol 
>>class does not set the source file
>>- CLJ-1657  proxy 
>>bytecode calls super methods of abstract classes
>>- CLJ-1659  compile 
>>leaks files
>>- CLJ-1761  
>> clojure.core/run! 
>>does not always return nil per docstring
>>- CLJ-1782  Spelling 
>>mistake in clojure.test/use-fixtures
>>- CLJ-1785  Reader 
>>conditionals throw when returning nil
>>
>> -- 
>> 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 

Re: Complete lack of helpful compilation errors with :gen-class

[Alex Miller]

If you can create a small, reproducible test case (that does not require 
Leiningen), please file a ticket.

On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
>
> Indeed, I visited the page you cite while trying to pin down this problem. 
> However, I am fairly certain that in my case it is a weird side effect, not 
> a root cause: I get that message when compiling my Clojure file if I try to 
> call a function which is defined later in the file. If I move the function 
> definition up before the point where I was calling it, everything compiles 
> fine, and no linkage error. No library changes in between the two tests. 
> And this only happens when my Clojure file is subclassing a Java object. 
> Very, very strange...
>
> On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
>>
>> I don't have anything helpful to say, but:  I've often gotten a useful 
>> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
>> Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
>> I think that whatever's happening is not just an issue with compilation of 
>> gen-class.  Maybe an issue involving libraries?  This page 
>> 
>>  
>> is consistent with that hypothesis.
>>
>

-- 
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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Indeed, I visited the page you cite while trying to pin down this problem. 
However, I am fairly certain that in my case it is a weird side effect, not 
a root cause: I get that message when compiling my Clojure file if I try to 
call a function which is defined later in the file. If I move the function 
definition up before the point where I was calling it, everything compiles 
fine, and no linkage error. No library changes in between the two tests. 
And this only happens when my Clojure file is subclassing a Java object. 
Very, very strange...

On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
>
> I don't have anything helpful to say, but:  I've often gotten a useful 
> stacktrace from compile-time errors using 'lein compile' with :gen-class.  
> Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
> I think that whatever's happening is not just an issue with compilation of 
> gen-class.  Maybe an issue involving libraries?  This page 
> 
>  
> is consistent with that hypothesis.
>

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

On Mon, Aug 3, 2015 at 3:02 AM, Colin Fleming 
wrote:

> For Clojure nothing beats emacs + CIDER
>>
>
> As a clearly biased participant here (I develop Cursive) I'd like to
> politely disagree with this. Lots of people are switching to Cursive from
> Emacs, including many that you've heard of. Obviously different strokes for
> different folks etc, but a lot of experienced Emacs users are finding
> enough additional value in Cursive (and potentially other environments, but
> I can't really speak to them) that they're willing to go through the pain
> of switching editing environments to get it. A lot of people also switch
> from one to the other depending on what they're doing - lein and boot
> provide enough of a layer that this is not painful and allows you to use
> the strengths of one or the other.
>
> Obviously I'm delighted if people are happy with the tools that they're
> using, whatever they may be, but I do think it's time to lay to rest the
> myth that Emacs is the only (or unequivocally the best) environment for
> Clojure. That hasn't been true for a long time - there are lots of good
> options.
>
>
CURRENT USE CASE:

I appreciate all this feedback re choice of editor.  My situation is I've
spent the last few years a working school that teaches Java, Python, Ruby
etc. using either:

(1) browser plugins for code editing and bash shell access (beginner level)
or

(2) Eclipse IDE. [1]

We provision each student using Eclipse with a Windows machine in the
cloud, back ended into a Linux file system (mapping a Windows V:-drive --
for Virtual -- to the student's sandbox).

So they're using Eclipse on client Windows (we pay license fees for that)
back ending into Linux.

One reason we do that is "realism" i.e. we're simulating / emulating a
plain vanilla US corporate cubicle (one could argue), but the main reason
is Visual Studio.  We want to use that too and that's Windows-only.

HYPOTHETICAL FUTURE:

In the hypothetical model I'm working on, based on all of the above, we
replace Windows with Ubuntu in the cloud, on an EC2 instance.

Then for Python do something with I-Py Notebooks and VPython for 2D + 3D
graphics, but then it's starting to look like maybe staying with Eclipse
for Java and Clojure, Ruby and Rails...  not Atom, as I was originally
considering. [2]

However, provisioning students with tools they'll use for a few months then
move on, is quite different from making a personal choice as to one's
favorite IDE.

So even now my comments to students involve mentioning other IDEs they
might want to try, i.e. there's no evangelism for any specific IDE, though
there is evangelism for Open Source, this being O'Reilly of OSCON fame. [3]

REQUIREMENTS BASED ON CURRENT DESIGN:

Two other pieces of this puzzle:

(A) when a student hacks on a Python or Java project and want's mentor
feedback, it's *not* a matter of the mentor remoting in to the student
instance or accessing the students V: drive.  Rather, we have software
infrastructure by the talented Michael Long that zips up the entire Eclipse
project and sends it to the mentor's computer, where it unzips.  The mentor
can run the code, find bugs, make changes, without touching the student's
original.  The mentor can send the whole project back, though usually
quotes and comments are sufficient.

(B) when a student submits work to the mentor, notification goes to a queue
with a time stamp.  The mentor pulls student work off the queue, which is
what triggers the zip / unzip transfer, making the whole process quite
decoupled and asynchronous.  In other words, each mentor is presented with
a "dashboard" of queued submissions per course.  I currently teach four
courses whereas other mentors have taught many more.

So I spend hours every day in Eclipse, looking at one student project after
another, either passing the project or sending it back with feedback for
more revision.

OPEN SOURCE ANGLE:

What I'm brainstorming is a similar workflow migrated from Windows clients
to Ubuntu instances on EC2, meaning a rewritten workflow.  The parent
company has neither the in-house skills nor the funds to accomplish this
overhaul and indeed all the aforementioned capability was intact prior to
our school's purchase.

A typical move in such situations is to wonder if there's a nucleus here
that could help a lot of similar enterprises i.e. what if we package up the
workflow engine as some Open Source product (I'm calling it Asynchronous
Learning Engine or ALE) such that any school or corporate training division
could do the same:  provision training studios in the cloud pre-wired to
facilitate student-mentor workflows as described above? [4]

My motivation for sharing these details here is precisely to start gauging
the interest level around such an Open Source project, which I think could
be of help to colleges and universities as well.   There'd be room for lots
of value added, i.e. the curriculum itself, the actual leaning materials,
are not specified by the ALE.

SUM

Re: [ANN] Clojure 1.8.0-alpha4

[Qihui Sun]

Congratulations. Maybe the performance optimization based on new JVM
Graal/Truffle is the correct way. For instance:
http://ssw.jku.at/Teaching/MasterTheses/Graal/TruffleClojure.pdf
Do the Clojure core team have the plan ?

2015-08-03 20:32 GMT+08:00 Alex Miller :

> Clojure 1.8.0-alpha4 is now available.
>
> Try it via
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha4
> - Leiningen: [org.clojure/clojure "1.8.0-alpha4"]
>
> Below is a list of the tickets included in this release (about half were
> added in alpha2, the rest in alpha4). Also see the full change log here:
> https://github.com/clojure/clojure/blob/master/changes.md
>
>- CLJ-1060  'list*'
>returns not a list
>- CLJ-1722  Typo in the
>docstring of 'with-bindings'
>- CLJ-1769  Docstrings
>for *' and +' refer to * and +
>- CLJ-703  Improve
>writeClassFile performance
>- CLJ-1208  Optionally
>require namespace on defrecord class init
>- CLJ-130  Namespace
>metadata lost in AOT compile
>- CLJ-1134  star-directive
>in clojure.pprint/cl-format with at-prefix ("~n@*") does not obey its
>specification
>- CLJ-1137  Metadata on a
>def gets evaluated twice
>- CLJ-1157  Classes
>generated by gen-class aren't loadable from remote codebase
>- CLJ-1225  quot overflow
>issues around Long/MIN_VALUE for BigInt
>- CLJ-1250  Reducer (and
>folder) instances hold onto the head of seqs
>- CLJ-1313  Correct a few
>unit tests
>- CLJ-1319  array-map
>fails lazily if passed an odd number of arguments
>- CLJ-1361  pprint with
>code-dispatch incorrectly prints a simple ns macro call
>- CLJ-1390  pprint a
>GregorianCalendar results in Arity exception
>- CLJ-1399  field name
>unmunged when recreating deftypes serialized into bytecode
>- CLJ-1485  
> clojure.test.junit/with-junit-output
>doesn't handle multiple expressions
>- CLJ-1528  
> clojure.test/inc-report-counter
>is not thread-safe
>- CLJ-1533  invokePrim
>path does not take into account var or form meta
>- CLJ-1562  
> some->,some->>,cond->,cond->>
>and as-> doesn't work with (recur)
>- CLJ-1565  pprint
>produces infinite output for a protocol
>- CLJ-1588  StackOverflow
>in clojure.test macroexpand with are and anon fn
>- CLJ-1644  into-array
>fails for sequences starting with nil
>- CLJ-1645  protocol
>class does not set the source file
>- CLJ-1657  proxy
>bytecode calls super methods of abstract classes
>- CLJ-1659  compile leaks
>files
>- CLJ-1761  clojure.core/run!
>does not always return nil per docstring
>- CLJ-1782  Spelling
>mistake in clojure.test/use-fixtures
>- CLJ-1785  Reader
>conditionals throw when returning nil
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure

Re: [ANN] Clojure 1.8.0-alpha4

[Qihui Sun]

Could we study from JRuby 9.0.0.0
http://jruby.org/2015/07/22/jruby-9-0-0-0.html
https://github.com/jruby/jruby/wiki/Truffle

2015-08-03 22:17 GMT+08:00 Qihui Sun :

> Congratulations. Maybe the performance optimization based on new JVM
> Graal/Truffle is the correct way. For instance:
> http://ssw.jku.at/Teaching/MasterTheses/Graal/TruffleClojure.pdf
> Do the Clojure core team have the plan ?
>
> 2015-08-03 20:32 GMT+08:00 Alex Miller :
>
>> Clojure 1.8.0-alpha4 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha4
>> - Leiningen: [org.clojure/clojure "1.8.0-alpha4"]
>>
>> Below is a list of the tickets included in this release (about half were
>> added in alpha2, the rest in alpha4). Also see the full change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>>- CLJ-1060  'list*'
>>returns not a list
>>- CLJ-1722  Typo in the
>>docstring of 'with-bindings'
>>- CLJ-1769  Docstrings
>>for *' and +' refer to * and +
>>- CLJ-703  Improve
>>writeClassFile performance
>>- CLJ-1208  Optionally
>>require namespace on defrecord class init
>>- CLJ-130  Namespace
>>metadata lost in AOT compile
>>- CLJ-1134  star-directive
>>in clojure.pprint/cl-format with at-prefix ("~n@*") does not obey its
>>specification
>>- CLJ-1137  Metadata on
>>a def gets evaluated twice
>>- CLJ-1157  Classes
>>generated by gen-class aren't loadable from remote codebase
>>- CLJ-1225  quot
>>overflow issues around Long/MIN_VALUE for BigInt
>>- CLJ-1250  Reducer (and
>>folder) instances hold onto the head of seqs
>>- CLJ-1313  Correct a
>>few unit tests
>>- CLJ-1319  array-map
>>fails lazily if passed an odd number of arguments
>>- CLJ-1361  pprint with
>>code-dispatch incorrectly prints a simple ns macro call
>>- CLJ-1390  pprint a
>>GregorianCalendar results in Arity exception
>>- CLJ-1399  field name
>>unmunged when recreating deftypes serialized into bytecode
>>- CLJ-1485  
>> clojure.test.junit/with-junit-output
>>doesn't handle multiple expressions
>>- CLJ-1528  
>> clojure.test/inc-report-counter
>>is not thread-safe
>>- CLJ-1533  invokePrim
>>path does not take into account var or form meta
>>- CLJ-1562  
>> some->,some->>,cond->,cond->>
>>and as-> doesn't work with (recur)
>>- CLJ-1565  pprint
>>produces infinite output for a protocol
>>- CLJ-1588  StackOverflow
>>in clojure.test macroexpand with are and anon fn
>>- CLJ-1644  into-array
>>fails for sequences starting with nil
>>- CLJ-1645  protocol
>>class does not set the source file
>>- CLJ-1657  proxy
>>bytecode calls super methods of abstract classes
>>- CLJ-1659  compile
>>leaks files
>>- CLJ-1761  clojure.core/run!
>>does not always return nil per docstring
>>- CLJ-1782  Spelling
>>mistake in clojure.test/use-fixtures
>>- CLJ-1785  Reader
>>conditionals throw when returning nil
>>
>> --
>> 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, s

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Joe R. Smith]

I’ll come out as an Emacs -> Cursive convert. I had been using emacs for 
Clojure development for 6+ years before I switched. Originally I had no 
intention of actually switching, but, as Colin suggested, I found enough 
additional value in Cursive to make my experimentation with Cursive permanent.


> On Aug 3, 2015, at 5:02 AM, Colin Fleming  wrote:
> 
> For Clojure nothing beats emacs + CIDER
> 
> As a clearly biased participant here (I develop Cursive) I'd like to politely 
> disagree with this. Lots of people are switching to Cursive from Emacs, 
> including many that you've heard of. Obviously different strokes for 
> different folks etc, but a lot of experienced Emacs users are finding enough 
> additional value in Cursive (and potentially other environments, but I can't 
> really speak to them) that they're willing to go through the pain of 
> switching editing environments to get it. A lot of people also switch from 
> one to the other depending on what they're doing - lein and boot provide 
> enough of a layer that this is not painful and allows you to use the 
> strengths of one or the other.
> 
> Obviously I'm delighted if people are happy with the tools that they're 
> using, whatever they may be, but I do think it's time to lay to rest the myth 
> that Emacs is the only (or unequivocally the best) environment for Clojure. 
> That hasn't been true for a long time - there are lots of good options.
> 
> On 3 August 2015 at 04:05, Jason Lewis  > wrote:
> IntelliJ CE (the free version) has served me well for Java and (playing with) 
> Cursive for Clojure. I can't speak to Python.
> 
> For Clojure nothing beats emacs + CIDER, and emacs is a fine choice for 
> Python. I generally stick to IntelliJ for Java, but I do know a few people 
> who use emacs for Java and then do a run through an IDE for static analysis 
> and automated refactoring as a second step. 
> 
> FWIW, I think it's worth learning the tradeoffs between editors and IDEs; I 
> wish I'd learned the difference earlier on. Maybe Python/emacs -> 
> Java/IntelliJ -> Clojure/emacs? Learning emacs and IntelliJ might be a bit of 
> cognitive overhead, but (insert some old saw about a good craftsmen knowing 
> his tools). 
> 
> I can't imagine using Atom for Java, and using it for Clojure seems like a 
> terrible idea; no inline eval, no integrated REPL, no jump-to-fn-definition, 
> no jump-to-docstring... I used it briefly when I was still doing Ruby, it was 
> acceptable on the days when the latest update didn't cause it to crash every 
> 15 minutes.
> 
> 
> 
> On Sun, Aug 2, 2015 at 8:51 PM Mark Engelberg  > wrote:
> Intellij might be your best option for a unified development platform for 
> Java, Clojure, and Python.  It won't be free though.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first po

Re: [ANN] Clojure 1.8.0-alpha4

[Alex Miller]

Few bugs corrected below.

On Monday, August 3, 2015 at 7:32:37 AM UTC-5, Alex Miller wrote:
>
> Clojure 1.8.0-alpha4 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha4
> - Leiningen: [org.clojure/clojure "1.8.0-alpha4"]
>
> Below is a list of the tickets included in this release (about half were 
> added in alpha2, the rest in alpha4). Also see the full change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
>- CLJ-1060  'list*' 
>returns not a list
>- CLJ-1722  Typo in the 
>docstring of 'with-bindings'
>- CLJ-1769  Docstrings 
>for *' and +' refer to * and +
>- CLJ-703  Improve 
>writeClassFile performance
>- CLJ-1208  Optionally 
>require namespace on defrecord class init
>- CLJ-130  Namespace 
>metadata lost in AOT compile
>- CLJ-1134  star-directive 
>in clojure.pprint/cl-format with at-prefix ("~n@*") does not obey its 
>specification
>- CLJ-1137  Metadata on a 
>def gets evaluated twice
>- CLJ-1157  Classes 
>generated by gen-class aren't loadable from remote codebase
>- CLJ-1225  quot overflow 
>issues around Long/MIN_VALUE for BigInt
>- CLJ-1250  Reducer (and 
>folder) instances hold onto the head of seqs
>- CLJ-1313  Correct a few 
>unit tests
>- CLJ-1319  array-map 
>fails lazily if passed an odd number of arguments
>
> CLJ-1319 Was ok'ed but not yet applied.
 

>
>- CLJ-1361  pprint with 
>code-dispatch incorrectly prints a simple ns macro call
>- CLJ-1390  pprint a 
>GregorianCalendar results in Arity exception
>- CLJ-1399  field name 
>unmunged when recreating deftypes serialized into bytecode
>- CLJ-1485  
> clojure.test.junit/with-junit-output 
>doesn't handle multiple expressions
>- CLJ-1528  
> clojure.test/inc-report-counter 
>is not thread-safe
>- CLJ-1533  invokePrim 
>path does not take into account var or form meta
>- CLJ-1562  
> some->,some->>,cond->,cond->> 
>and as-> doesn't work with (recur)
>- CLJ-1565  pprint 
>produces infinite output for a protocol
>- CLJ-1588  StackOverflow 
>in clojure.test macroexpand with are and anon fn
>- CLJ-1644  into-array 
>fails for sequences starting with nil
>- CLJ-1645  protocol 
>class does not set the source file
>- CLJ-1657  proxy 
>bytecode calls super methods of abstract classes
>- CLJ-1659  compile leaks 
>files
>- CLJ-1761  clojure.core/run! 
>does not always return nil per docstring
>- CLJ-1782  Spelling 
>mistake in clojure.test/use-fixtures
>
> Typo - should have been CLJ-1772 

>
>- CLJ-1785  Reader 
>conditionals throw when returning nil
>
>

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

[ANN] Clojure 1.8.0-alpha4

[Alex Miller]

Clojure 1.8.0-alpha4 is now available.

Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha4
- Leiningen: [org.clojure/clojure "1.8.0-alpha4"]

Below is a list of the tickets included in this release (about half were 
added in alpha2, the rest in alpha4). Also see the full change log here: 
https://github.com/clojure/clojure/blob/master/changes.md

   - CLJ-1060  'list*' returns 
   not a list
   - CLJ-1722  Typo in the 
   docstring of 'with-bindings'
   - CLJ-1769  Docstrings for 
   *' and +' refer to * and +
   - CLJ-703  Improve 
   writeClassFile performance
   - CLJ-1208  Optionally 
   require namespace on defrecord class init
   - CLJ-130  Namespace 
   metadata lost in AOT compile
   - CLJ-1134  star-directive 
   in clojure.pprint/cl-format with at-prefix ("~n@*") does not obey its 
   specification
   - CLJ-1137  Metadata on a 
   def gets evaluated twice
   - CLJ-1157  Classes 
   generated by gen-class aren't loadable from remote codebase
   - CLJ-1225  quot overflow 
   issues around Long/MIN_VALUE for BigInt
   - CLJ-1250  Reducer (and 
   folder) instances hold onto the head of seqs
   - CLJ-1313  Correct a few 
   unit tests
   - CLJ-1319  array-map fails 
   lazily if passed an odd number of arguments
   - CLJ-1361  pprint with 
   code-dispatch incorrectly prints a simple ns macro call
   - CLJ-1390  pprint a 
   GregorianCalendar results in Arity exception
   - CLJ-1399  field name 
   unmunged when recreating deftypes serialized into bytecode
   - CLJ-1485  
clojure.test.junit/with-junit-output 
   doesn't handle multiple expressions
   - CLJ-1528  
clojure.test/inc-report-counter 
   is not thread-safe
   - CLJ-1533  invokePrim path 
   does not take into account var or form meta
   - CLJ-1562  
some->,some->>,cond->,cond->> 
   and as-> doesn't work with (recur)
   - CLJ-1565  pprint produces 
   infinite output for a protocol
   - CLJ-1588  StackOverflow 
   in clojure.test macroexpand with are and anon fn
   - CLJ-1644  into-array 
   fails for sequences starting with nil
   - CLJ-1645  protocol class 
   does not set the source file
   - CLJ-1657  proxy bytecode 
   calls super methods of abstract classes
   - CLJ-1659  compile leaks 
   files
   - CLJ-1761  clojure.core/run! 
   does not always return nil per docstring
   - CLJ-1782  Spelling 
   mistake in clojure.test/use-fixtures
   - CLJ-1785  Reader 
   conditionals throw when returning nil

-- 
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] Initial release of Glow, a tiny library for syntax highlighting Clojure source code

[W. David Jarvis]

Unfortunately, since Glow doesn't use a lisp reader as it's underlying
syntax engine, locals highlighting isn't something that the project can
easily support. Allen Rohner pointed me in the direction of a few other
underlying lisp/clojure readers that might open up avenues for that sort of
feature, and I'd definitely be interested in exploring it, but barring
outside contributions at the moment I think the project will probably stick
with its regex implementation for the immediate future.

Even so - someone else also opened an issue on the project page asking for
HTML output and it wouldn't be that hard to generalize the actual
highlighting process to target multiple output types. I'll noodle on it
some more.

On Mon, Aug 3, 2015 at 1:30 AM, Reid McKenzie  wrote:

> On the contrary, I would argue that there is some interesting stuff
> like locals highlighting that existing highlighting solutions don't or
> can't offer. However as you say pygments fulfills my requirements.
>
> Reid
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ntz-YPxwryA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

venanti.us
203.918.2328


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

Re: Using a dynamic var for my database connection for implicit connections+transactions

[J . Pablo Fernández]

Other than the fact that this approach doesn't reach the level of
functional purity that some people want, after playing with it for a while,
we found it very productive and leads to clean/readable code and tests, so
we decided to turn it into a library:

https://clojars.org/conman

https://github.com/luminus-framework/conman

You are still in control of the connection so you can do other things with
it and have more than one if necessary.

On 31 July 2015 at 01:44, J. Pablo Fernández  wrote:

> Hello Clojurians,
>
> I found passing around the database connection to each function that uses
> it very error prone when you are using transactions as passing the wrong
> one could mean a query runs outside the transaction when in the source code
> it is inside the with-db-transaction function. So I ended up defining the
> db namespace like this:
>
> (ns db)
>
> (defonce ^:dynamic conn (atom nil))
>
> (defn connect!
>   (reset conn (generate-new-connection)))
>
> (defn run-query
>   [query] (run-query query @conn)
>   [query conn] (run-the-query-in-connection query conn))
>
>
> This is pseudo-code of course, simplified to highlight the part that I'm
> most unfamiliar with:
>
> (defonce ^:dynamic conn (atom nil))
>
> The reason why it's an atom is so that connect! can *set* it and the
> reason why it's a dynamic var is so I can do this:
>
> (jdbc/with-db-transaction
> [db-connection-with-transaction @db/conn]
> (binding [db/conn (atom db-connection-with-transaction)]
>   (db/run-query "SELECT *"))
>
> and the query will be implicitly run inside the transaction. Does it make
> sense? Is this wrong? will it fail in unexpected ways? Is there a better
> way?
>
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/fRi554wbPSk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
J. Pablo Fernández  (http://pupeno.com)

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

Re: Using a dynamic var for my database connection for implicit connections+transactions

[J . Pablo Fernández]

Rob,

The transactions are not global, the transactions are local. Connections
are global and there's no way around it with the constraints of a
traditional RDBMs. Your idea of making the global connection unavailable
for code that's in the context of a transaction would prevent the errors
I'm trying to prevent but you would still required to pass the connection
around, which in a webapp, means that the whole chain of function calls,
pretty much everything, would have a database connection. That is ugly in
some cases, impossible in others.

A piece of code that would be impossible is to enclose each test in a
transaction using clojure.test:
http://stackoverflow.com/questions/31735423/how-to-pass-a-value-from-a-fixture-to-a-test-with-clojure-test

Furthermore, I don't think this solution gains you any purity, you still
have a global estate and you are hiding it away when starting a
transaction. My proposal was to make it work instead of hiding it. They are
rather equivalent from the complexity point of view.

On 1 August 2015 at 18:29, Rob Lally  wrote:

> Hey Pablo,
>
> I could be wrong, but it seems that the key problem here is the existence
> of the global transaction. If the global transaction didn’t exist then any
> time you failed to pass in a transaction the code would fail: immediately
> and loudly.
>
> I appreciate what you’re trying to do but it seems like you’re on a path
> to solve the problems caused by one shared, implicit, global variable by
> creating more shared, implicit, slightly less global, variables and that
> doesn’t seem like it is going to end well. Implicit connections in a
> binding will fail in, perhaps mysterious ways if you ever include any sort
> of concurrency: even things as simple as asynchronous logging can start
> logging wrong values or missing values.
>
> Can you somehow render the global connection inoperable in some way?
> Perhaps redefine it, point it at a data source that doesn’t exist or… by
> some other hook-or-crook have it fail in a loud, grotesque manner if it is
> touched?
>
>
> R.
>
>
>
>
> On 31 Jul 2015, at 01:54, J. Pablo Fernández  wrote:
>
> Hello James,
>
> Thanks for your answer. I do understand your point. Pure functions are
> easier to reason about and my use of dynamic here breaks that purity. I'm
> not doing it lightly. It already happened to me, that one of those
> functions that was running inside the transaction, was not passed the
> transaction connection and instead got the global one and the failure was
> silent and very hard to debug, and this was with a project that has less
> than 200 lines of code. I'm trying to find patterns that will work when
> this project has 200k lines of code.
>
> For me, the thing is, I have a traditional relational database here, this
> is already far from pure. For example, calling (db/create-user "
> pup...@pupeno.com") twice will not only not return the same thing the
> second time, it'll actually raise an exception the second time. Also, the
> database connection is *global state* unless each function creates its own
> connection, which would be terrible. So, this global state also breaks
> functional purity.
>
> The problem with the second aspect of breaking purity as far as I can see
> is this: at some point, this global state has to be picked up and used, so
> at some point a function will *not* get a database connection passed to it
> but *will* access the database by using this global connection. I haven't
> advanced this project enough to say this with 100% certainty, but, I think
> there's going to be more than one function like that and at some point I'll
> need to have one inside the other so I need them to be composable. Let me
> show you a naive example:
>
> db/create-user is the low level database function that creates a record in
> the user table
> user/create is the function used to create a user, it takes care of, for
> example, encrypting the password.
> account/register is the function to register a new user, it takes care of
> creating a user but also validation, sending a welcome email and so on.
>
> So each function calls the predecessor there and would pass the database
> connection, account/register, being the entry point, would grab it from the
> global state so it doesn't get a connection passed to it. So far, a lot of
> it looks like pure functions (let's ignore the fact that a database breaks
> that purity). The problem arises when I get another function,
> account/invite, that is used to register a bunch of people one after the
> other, so that account/invite would call account/register many times. The
> problem is that account/invite *can't* start a transaction and have
> account/register and all its inner functions use that transaction when that
> makes a lot of sense.
>
> To make account/register composable it needs to accept an optional
> database connection and use that one if it's present, or the global one if
> it's not. Every time a function does that there's a high risk of 

Re: Using a dynamic var for my database connection for implicit connections+transactions

[Colin Yates]

I have heard this approach before, but I have never seen how it works in
real life. For example, what about 'selects' - where do they happen?
What about if my updates are not independent (e.g. if the first
update works then do the second update otherwise do this completely
different thing?).

For simple workflows I can see the elegance. For non-trivial workflows
the problem is that _accessing_ the DB and _switching_ on the DB logic
tends to be all through the workflow.

I am genuinely interested in the answers to this as yes, the described
approach has some great benefits.

James Gatannah writes:

> On Thursday, July 30, 2015 at 7:44:31 PM UTC-5, J. Pablo Fernández wrote:
>>
>> Hello Clojurians,
>>
>> I found passing around the database connection to each function that uses
>> it very error prone when you are using transactions as passing the wrong
>> one could mean a query runs outside the transaction when in the source code
>> it is inside the with-db-transaction function.
>>
>
> I'll go ahead and make the point that it's error-prone for different
> reasons.
>
> Pretty much by definition, that database connection is a system boundary.
> It's all about something that's *way* more complex than random global state
> changes inside your program. This is a thing that interacts with the
> outside world, with all the nastiness that implies.
>
> Everything that everyone else has already written about this approach is
> true, but I don't think they've gone far enough.
>
> Even if you pass that database connection around as a parameter everywhere,
> you're talking about throwing away a huge part of the benefit of using a
> functional language.
>
> Isolate your side-effects.
>
> Think of a castle. You have a moat surrounding it, and a few gates that you
> use to allow your peasants to enter/exit. This particular gate opens up to
> a swamp full of alligators.
>
> Your approach amounts to letting the gators wander around loose.
>
> Passing the connection around to each function in the call chain is like
> tying a ribbon around the gator's neck and hoping you can use that as a
> leash.
>
> You can use either approach to great effect. If you're really, really good.
> And so is everyone else on your team (you did mention a 200 KLOC project).
>
> One of the main benefits to functional programming is that admitting you
> aren't really, really good is incredibly liberating. I don't have the
> time/energy to dedicate to trying to maintain this sort of code. (Yes, I
> spent lots of time recently thinking about how java was designed for very
> average programmers, but it really takes much better programmers than a
> functional language to actually write correct programs). Even if I were
> that good...I'd rather be focused on the problems that make my customers
> happy.
>
> I'm going to appeal to authority here for the right
> answer: http://prog21.dadgum.com/23.html (in my defense, it's a great
> blog). Have your web response handler (which is another system
> boundary...this one is next to an active volcano populated by
> fire-breathing dragons) build up a list of all the nasty side-effects that
> will eventually have to happen.
>
> Don't just isolate your side-effects. Quarantine those suckers as if each
> and every one means you're dealing with the most diabolical hacker you can
> imagine.

--
Sent with my mu4e

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

Re: Using a dynamic var for my database connection for implicit connections+transactions

[J . Pablo Fernández]

James,

I'm not new to functional programming and I understand the principles and
why they are good. I worked in Haskell, Erlang and other Lisps before. Even
if only a tiny portion of my codebase deals with the database, I still need
a pattern for that part of the codebase.

It is very easy to say "this is dirty, you should not do this" without
offering an alternative solution and by alternative solution I mean one
that applies to the pattern of making web applications that are database
heavy. Think of your traditional CRUD application, you can say "quarentine
the code that deals with the database" and yes, you can do that, but it
still is 90% of the code.





On 3 August 2015 at 06:00, James Gatannah  wrote:

>
>
> On Thursday, July 30, 2015 at 7:44:31 PM UTC-5, J. Pablo Fernández wrote:
>>
>> Hello Clojurians,
>>
>> I found passing around the database connection to each function that uses
>> it very error prone when you are using transactions as passing the wrong
>> one could mean a query runs outside the transaction when in the source code
>> it is inside the with-db-transaction function.
>>
>
> I'll go ahead and make the point that it's error-prone for different
> reasons.
>
> Pretty much by definition, that database connection is a system boundary.
> It's all about something that's *way* more complex than random global state
> changes inside your program. This is a thing that interacts with the
> outside world, with all the nastiness that implies.
>
> Everything that everyone else has already written about this approach is
> true, but I don't think they've gone far enough.
>
> Even if you pass that database connection around as a parameter
> everywhere, you're talking about throwing away a huge part of the benefit
> of using a functional language.
>
> Isolate your side-effects.
>
> Think of a castle. You have a moat surrounding it, and a few gates that
> you use to allow your peasants to enter/exit. This particular gate opens up
> to a swamp full of alligators.
>
> Your approach amounts to letting the gators wander around loose.
>
> Passing the connection around to each function in the call chain is like
> tying a ribbon around the gator's neck and hoping you can use that as a
> leash.
>
> You can use either approach to great effect. If you're really, really
> good. And so is everyone else on your team (you did mention a 200 KLOC
> project).
>
> One of the main benefits to functional programming is that admitting you
> aren't really, really good is incredibly liberating. I don't have the
> time/energy to dedicate to trying to maintain this sort of code. (Yes, I
> spent lots of time recently thinking about how java was designed for very
> average programmers, but it really takes much better programmers than a
> functional language to actually write correct programs). Even if I were
> that good...I'd rather be focused on the problems that make my customers
> happy.
>
> I'm going to appeal to authority here for the right answer:
> http://prog21.dadgum.com/23.html (in my defense, it's a great blog). Have
> your web response handler (which is another system boundary...this one is
> next to an active volcano populated by fire-breathing dragons) build up a
> list of all the nasty side-effects that will eventually have to happen.
>
> Don't just isolate your side-effects. Quarantine those suckers as if each
> and every one means you're dealing with the most diabolical hacker you can
> imagine.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/fRi554wbPSk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
J. Pablo Fernández  (http://pupeno.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://group

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Colin Fleming]

>
> For Clojure nothing beats emacs + CIDER
>

As a clearly biased participant here (I develop Cursive) I'd like to
politely disagree with this. Lots of people are switching to Cursive from
Emacs, including many that you've heard of. Obviously different strokes for
different folks etc, but a lot of experienced Emacs users are finding
enough additional value in Cursive (and potentially other environments, but
I can't really speak to them) that they're willing to go through the pain
of switching editing environments to get it. A lot of people also switch
from one to the other depending on what they're doing - lein and boot
provide enough of a layer that this is not painful and allows you to use
the strengths of one or the other.

Obviously I'm delighted if people are happy with the tools that they're
using, whatever they may be, but I do think it's time to lay to rest the
myth that Emacs is the only (or unequivocally the best) environment for
Clojure. That hasn't been true for a long time - there are lots of good
options.

On 3 August 2015 at 04:05, Jason Lewis  wrote:

> IntelliJ CE (the free version) has served me well for Java and (playing
> with) Cursive for Clojure. I can't speak to Python.
>
> For Clojure nothing beats emacs + CIDER, and emacs is a fine choice for
> Python. I generally stick to IntelliJ for Java, but I do know a few people
> who use emacs for Java and then do a run through an IDE for static analysis
> and automated refactoring as a second step.
>
> FWIW, I think it's worth learning the tradeoffs between editors and IDEs;
> I wish I'd learned the difference earlier on. Maybe Python/emacs ->
> Java/IntelliJ -> Clojure/emacs? Learning emacs and IntelliJ might be a bit
> of cognitive overhead, but (insert some old saw about a good craftsmen
> knowing his tools).
>
> I can't imagine using Atom for Java, and using it for Clojure seems like a
> terrible idea; no inline eval, no integrated REPL, no
> jump-to-fn-definition, no jump-to-docstring... I used it briefly when I was
> still doing Ruby, it was acceptable on the days when the latest update
> didn't cause it to crash every 15 minutes.
>
>
>
> On Sun, Aug 2, 2015 at 8:51 PM Mark Engelberg 
> wrote:
>
>> Intellij might be your best option for a unified development platform for
>> Java, Clojure, and Python.  It won't be free though.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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