Re: Offline Clojure docs

2013-11-23 Thread Lan Rogers 
Zeal  is a Dash clone for linux/windows, and is api 
compatible with Dash docsets, hence would include the clojure docset. It's 
a little rough around the edges UI-wise but it gets the job done. 

On Sunday, June 30, 2013 11:43:19 PM UTC-7, Erik Bakstad wrote:
>
> If you are a Mac user I highly recommend 
> Dash
>  it 
> has all kinds of documentation available for download, and the search is 
> very nice as well.
>
> -Erik
>
> kl. 07:31:40 UTC+2 mandag 1. juli 2013 skrev David Pollak følgende:
>>
>> Thanks everyone for the super helpful suggestions!
>>
>>
>> On Mon, Jul 1, 2013 at 9:04 AM, Mark Engelberg wrote:
>>
>>> Download here:
>>> https://github.com/clojure/clojure/tree/gh-pages
>>>
>>>  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>

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

[ANN] java.jdbc DSLs moved to jdbc-java/dsl

2013-11-23 Thread Sean Corfield 
Based on feedback from the community, and in preparation for java.jdbc
0.3.0-beta2, the DSLs, introduced in 0.3.0-alpha1, have been made
available in another project:

[java-jdbc/dsl "0.1.0"]

via the namespaces java-jdbc.sql java-jdbc.ddl

Anyone currently using the org.clojure/java.jdbc.sql or
org.clojure/java.jdbc.ddl namespaces, can add the dependency above and
update their ns declarations to require (or use) the alternative
namespaces.

This will clear the path to full removal of those namespaces from the
java.jdbc contrib library in 0.3.0-beta2.

The 0.3.0-beta2 release will also address the "dual API" issue, likely
by moving the deprecated API into a separate namespace, which will
force a change in code that uses it, but will make it clear what is
what in the API, as well as separating the documenting along natural
lines.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread Sean Corfield 
On Sat, Nov 23, 2013 at 8:27 PM, Keith Irwin  wrote:
> Personally, the DSL doesn’t bother me at all. (Just a data point.) I get 
> where you’re going with it, and support the idea, FWIW, but if it were gone, 
> I wouldn’t notice. My needs are 1) so simple, strings work, or 2) so 
> complicated, a (or any) DSL is just extra headache. (Reading them out of a 
> separately maintained data file, for instance, is one way to go.)

Thank you.

> The mixture of the old API and the new API is problematic, mainly because 
> it’s difficult for me (anyway) to look down the list of functions and figure 
> out which are old and which are new.

I agree.

> Might you be able to publish a parallel version of the API *documentation* 
> with all the deprecated stuff removed for those folks new to the library who 
> are uninterested in the old API? Even users of the old API might appreciate 
> it for the same reasons.

I think, given that I am retiring the DSL namespaces and making them
available in a separate project (that change is already committed,
although the docstrings have yet to catch up), the least confusing
thing to do at this point for 0.3.0-beta2 onward will be to create a
java.jdbc.deprecated namespace containing the entirety of the 0.2.3
API and remove all of the deprecated functions from java.jdbc itself?

That would clearly separate the API documentation into two namespaces:
one the modern API going forward, one the deprecated API provided for
backward compatibility.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Spit seems to use incorrect line terminator on Windoze

2013-11-23 Thread Cedric Greevey 
(spit "C:\\foo.txt" "test1\n")
(spit "C:\\foo.txt" "test2\n" :append true)

open file in notepad => "test1test2"

(spit "C:\\foo.txt" "test1\r\n")
(spit "C:\\foo.txt" "test2\r\n" :append true)

open file in notepad => "test1
 test2"

So a newline in the string passed to spit seems to be emitted as 0x10,
regardless of the platform, and you have to use \r\n in the string to get a
Windoze newline.

Since (AIUI) "spit" is designed to emit text files (who writes binary files
via a Writer?), shouldn't each "\n" in the input be getting coerced to
(System/getProperty "line.separator") somewhere along the way?

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread Paul Samways 
> Parallel (and conjoined) API docs would solve ALL my (admittedly shallow)
problems, actually, but I wonder if it would remove some confusion for
others new to the lib and Clojure?

Definitely. I have only just started using Clojure and the java.jdbc
library and have found this a (minor) pain point in an otherwise excellent
library.


On Sun, Nov 24, 2013 at 3:27 PM, Keith Irwin  wrote:

> Sean—
>
> Personally, the DSL doesn’t bother me at all. (Just a data point.) I get
> where you’re going with it, and support the idea, FWIW, but if it were
> gone, I wouldn’t notice. My needs are 1) so simple, strings work, or 2) so
> complicated, a (or any) DSL is just extra headache. (Reading them out of a
> separately maintained data file, for instance, is one way to go.)
>
> BUT:
>
> The mixture of the old API and the new API is problematic, mainly because
> it’s difficult for me (anyway) to look down the list of functions and
> figure out which are old and which are new.
>
> I understand the need to maintain the old API, and I’m not arguing against
> that at all.
>
> Might you be able to publish a parallel version of the API *documentation*
> with all the deprecated stuff removed for those folks new to the library
> who are uninterested in the old API? Even users of the old API might
> appreciate it for the same reasons.
>
> Parallel (and conjoined) API docs would solve ALL my (admittedly shallow)
> problems, actually, but I wonder if it would remove some confusion for
> others new to the lib and Clojure?
>
> On Nov 20, 2013, at 2:25 PM, Sean Corfield  wrote:
>
> > Thank you both - that's excellent feedback!
> >
> > I certainly don't want the library to cause confusion so maybe
> > hiding/removing the DSLs would be the best path going forward.
> >
> > Right now, a handful of the DSL functions are used to generate the SQL
> > behind delete!, insert! and update! as well as the core implementation
> > of the naming strategy stuff. We're also using a few of them in
> > production code at World Singles but it would be easy enough to back
> > off that and switch to HoneySQL (which we use extensively elsewhere).
> >
> > I totally agree about the API being too broad. I'd like to just drop
> > the old API completely but experience with APIs changing in contrib
> > libraries has shown that backward compatibility needs to be maintained
> > for at least a version or two so folks can migrate off the old API. I
> > was planning to streamline the API - dropping the old API that relied
> > on the dynamic *db* variable - in 0.5.0 but maybe I'll make that the
> > focus of 0.4.0 instead.
> >
> > The feedback on the DSLs - ever since my first proposal to add them -
> > seems to be overwhelmingly negative so at this point I'm now
> > considering removing them from 0.3.0 rather than perpetuate the
> > confusion.
> >
> > Is anyone using the java.jdbc.sql namespace? (besides World Singles :)
> >
> > Sean
> >
> >
> >
> > On Wed, Nov 20, 2013 at 3:52 AM, Alice  wrote:
> >> I agree with Colin and had a similar experience.
> >>
> >> Even if you say it's completely optional, people will first try it
> because
> >> it's already included. I think honeysql is good and also not any harder
> to
> >> use than the included DSL. It's concept is very simple and clear.
> Actually,
> >> your DSL is magical because it's based on macro.
> >>
> >> For example, I asked about specifying the default name mapping functions
> >> before* and it was not the first time. I had to see the source code to
> >> understand why it's not possible. I was only the second but I bet you'll
> >> keep hearing this kind of questions over and over again. If you keep the
> >> jdbc and DSL in the same library, it becomes confusing to users why some
> >> things are not possible.
> >>
> >> And I don't see any problem with separating it into another library.
> It's
> >> just one additional line in project.clj.
> >>
> >> *
> >>
> https://groups.google.com/forum/#!searchin/clojure/jdbc/clojure/iOBs_VC09FM/8aUF2xzz7scJ
> >>
> >>
> >> On Wednesday, November 20, 2013 6:41:33 PM UTC+9, Colin Yates wrote:
> >>>
> >>> Hi Sean,
> >>>
> >>> First - I hugely appreciate the work you have done and use java.jdbc
> >>> daily.
> >>>
> >>> However, as a complete newbie I found the included DSL very unhelpful.
> >>> The java.jdbc API is very wide and navigating it was hard,
>  Particularly as
> >>> it was in a transition from using bound *db* to not, so effectively
> there
> >>> seemed two APIs.
> >>>
> >>> I started using the DSL and it didn't meet the expectation I think
> anybody
> >>> would have for a DSL in that it wasn't complete or expressive enough.
>  There
> >>> were moments where the combined experience was very very negative and
> not
> >>> representative of the quality of the work you have put in.
> >>>
> >>> It also made it unclear what the library was supposed to do
> (regardless of
> >>> what the documentation says :)).
> >>>
> >>> Treating java.jdbc without the DSL and the DSL as separa

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread Keith Irwin 
Sean—

Personally, the DSL doesn’t bother me at all. (Just a data point.) I get where 
you’re going with it, and support the idea, FWIW, but if it were gone, I 
wouldn’t notice. My needs are 1) so simple, strings work, or 2) so complicated, 
a (or any) DSL is just extra headache. (Reading them out of a separately 
maintained data file, for instance, is one way to go.)

BUT:

The mixture of the old API and the new API is problematic, mainly because it’s 
difficult for me (anyway) to look down the list of functions and figure out 
which are old and which are new.

I understand the need to maintain the old API, and I’m not arguing against that 
at all.

Might you be able to publish a parallel version of the API *documentation* with 
all the deprecated stuff removed for those folks new to the library who are 
uninterested in the old API? Even users of the old API might appreciate it for 
the same reasons.

Parallel (and conjoined) API docs would solve ALL my (admittedly shallow) 
problems, actually, but I wonder if it would remove some confusion for others 
new to the lib and Clojure?

On Nov 20, 2013, at 2:25 PM, Sean Corfield  wrote:

> Thank you both - that's excellent feedback!
> 
> I certainly don't want the library to cause confusion so maybe
> hiding/removing the DSLs would be the best path going forward.
> 
> Right now, a handful of the DSL functions are used to generate the SQL
> behind delete!, insert! and update! as well as the core implementation
> of the naming strategy stuff. We're also using a few of them in
> production code at World Singles but it would be easy enough to back
> off that and switch to HoneySQL (which we use extensively elsewhere).
> 
> I totally agree about the API being too broad. I'd like to just drop
> the old API completely but experience with APIs changing in contrib
> libraries has shown that backward compatibility needs to be maintained
> for at least a version or two so folks can migrate off the old API. I
> was planning to streamline the API - dropping the old API that relied
> on the dynamic *db* variable - in 0.5.0 but maybe I'll make that the
> focus of 0.4.0 instead.
> 
> The feedback on the DSLs - ever since my first proposal to add them -
> seems to be overwhelmingly negative so at this point I'm now
> considering removing them from 0.3.0 rather than perpetuate the
> confusion.
> 
> Is anyone using the java.jdbc.sql namespace? (besides World Singles :)
> 
> Sean
> 
> 
> 
> On Wed, Nov 20, 2013 at 3:52 AM, Alice  wrote:
>> I agree with Colin and had a similar experience.
>> 
>> Even if you say it's completely optional, people will first try it because
>> it's already included. I think honeysql is good and also not any harder to
>> use than the included DSL. It's concept is very simple and clear. Actually,
>> your DSL is magical because it's based on macro.
>> 
>> For example, I asked about specifying the default name mapping functions
>> before* and it was not the first time. I had to see the source code to
>> understand why it's not possible. I was only the second but I bet you'll
>> keep hearing this kind of questions over and over again. If you keep the
>> jdbc and DSL in the same library, it becomes confusing to users why some
>> things are not possible.
>> 
>> And I don't see any problem with separating it into another library. It's
>> just one additional line in project.clj.
>> 
>> *
>> https://groups.google.com/forum/#!searchin/clojure/jdbc/clojure/iOBs_VC09FM/8aUF2xzz7scJ
>> 
>> 
>> On Wednesday, November 20, 2013 6:41:33 PM UTC+9, Colin Yates wrote:
>>> 
>>> Hi Sean,
>>> 
>>> First - I hugely appreciate the work you have done and use java.jdbc
>>> daily.
>>> 
>>> However, as a complete newbie I found the included DSL very unhelpful.
>>> The java.jdbc API is very wide and navigating it was hard,  Particularly as
>>> it was in a transition from using bound *db* to not, so effectively there
>>> seemed two APIs.
>>> 
>>> I started using the DSL and it didn't meet the expectation I think anybody
>>> would have for a DSL in that it wasn't complete or expressive enough.  There
>>> were moments where the combined experience was very very negative and not
>>> representative of the quality of the work you have put in.
>>> 
>>> It also made it unclear what the library was supposed to do (regardless of
>>> what the documentation says :)).
>>> 
>>> Treating java.jdbc without the DSL and the DSL as separate projects (I
>>> realise they are separate namespaces already) would be a much stronger
>>> statement of intent I think.
>>> 
>>> To put it another way, at the moment the risk is to interpret java.jdbc as
>>> a DSL on top of JDBC with some low level utilities around managing
>>> connections.  That clearly isn't true and the project comes off looking very
>>> poor.
>>> 
>>> Please hear me - I write this only because I think my experience will be
>>> very similar to a lot of other people's experiences when they start adopting
>>> the library whilst picking up Clojure a

Re: [ANN] Reaction

2013-11-23 Thread Kelker Ryan 
Thanks. I just added some documentation and two more macros.API Docs user> (use '[reaction.core])
nil
reaction.core> (def-reactive! my-int 1)
#'reaction.core/my-int
reaction.core> (push! my-int inc inc)
nil
reaction.core> @my-int
3
reaction.core> (pop! my-int)
nil
reaction.core> @my-int
2
reaction.core> (pop! my-int)
nil
reaction.core> @my-int
1
reaction.core> (push! my-int inc (partial + 5) dec)
nil
reaction.core> @my-int
6
reaction.core> (pop! my-int 3)
nil
reaction.core> @my-int
1  22.11.2013, 22:52, "Marc Limotte" :Very clever.  Thanks for the contribution.On Fri, Nov 22, 2013 at 1:20 AM, Kelker Ryan  wrote:Reaction  - https://github.com/runexec/reaction A small reactive programming library for ClojureUsageuser> (use '[reaction.core])niluser> (def-reactive! my-int 123)#'user/my-intuser> @my-int 123user> (rapply! my-int inc)niluser> @my-int124user> (original-value my-int)123user> @my-int124user> (rapply! my-int #(+ 5 %))niluser> @my-int129user> (defn reactive-minus-2 [] (- @my-int 2)) #'user/reactive-minus-2user> (reactive-minus-2)127user> (rapply! my-int #(- % 20))niluser> @my-int109user> (reactive-minus-2)107user> (rset! my-int 1)niluser> (remove-actions! my-int) niluser> @my-int1user> (rapply! my-int inc)niluser> @my-int2user> (remove-actions! my-int)niluser> @my-int1user>  --  --  You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en ---  You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. --  --  You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en ---  You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.



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

Re: Clojure CLR versioning and binary downloads

2013-11-23 Thread dmiller 
1.5.0 of Clojure CLR includes the one fix in 1.5.1.  I got excited and went 
one too far. Normally, the version numbers match exactly.

I tagged 1.5.0 a little prematurely.  We had some troubles on the NuGet 
release and on the mono build.  I wasn't really ready for an official 1.5.0 
release, so I hadn't done the SourceForge binary distributions.

That's all been fixed as of earlier today (11/23/2013 relative to Central 
Standard).

ClojureCLR 1.5.0 is officially out.

This version has a NuGet package, with binaries for .Net 3.5 and .Net 4.0. 
 All the binaries to run ClojureCLR itself are in one file, Clojure.dll, 
due to the magic of ILMerge and a lot of new internal plumbing to allow 
embedded DLL resources and merged DLLs.  Also, this version is signed so 
that it can be referenced in signed projects or GAC'd.  

There are Debug and Release binaries  (not ILMerged) for .Net 3.5 and 4.0 
on the SourceForge site.

The wiki pages on the github site have been updated.

Mono is now supported.  You can run it under Mono.  You can compile it 
directly using xbuild with mono.  Details on the wiki.

Regarding the Clojure.Main and Clojure.Compile binaries in the NuGet 
package:  Yes, you have to move them to run them.  Clojure.dll has to be in 
the lib\ folder in order for the package to work properly when included in 
a project.  Ancillary files such as Clojure.Main and Clojure.Compile are 
standalones and are not needed for other projects.  They are properly 
contained in the tools\  folder.  I was asked to include them in the NuGet 
package for ClojureCLR.  I'm not happy with the current arrangement, in a 
nitpicky way.  I'm open to suggestions.

-David



On Friday, November 22, 2013 8:41:58 PM UTC-6, Frank Hale wrote:
>
> As far as I can tell the Clojure CLR version number does not track the JVM 
> version number at least for some builds. The latest build 1.5.0 as far as I 
> can tell is at the same patch level as 1.5.1 on the JVM. This numbering 
> seems confusing to me. Are there any plans to streamline the version 
> numbers between the two platforms?
>
> Additionally I don't understand why on the Clojure CLR SourceForge page 
> there are only debug versions available for download and 1.5.0 is not 
> represented there. If you want 1.5.0 you have to use nuget to get it. I was 
> also a bit dumbfounded that the nuget version was broken out of the box and 
> what I mean by that is that once you have downloaded it you cannot run the 
> compiler or the REPL from it's current directory without first dumping the 
> exe's into the lib folder since they are segregated in the package. Running 
> the compiler or REPL from their directory will result in them complaining 
> that they cannot find the required Clojure CLR DLL's that they need.
>
> These are kind of nit-picky issues but they've been bugging me for a 
> while. 
>

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

Re: [ANN] Clojure 1.6.0-alpha3

2013-11-23 Thread Sean Corfield 
On Sat, Nov 23, 2013 at 12:47 PM, Colin Fleming
 wrote:
> BTW (and I may be a little late here) - is there a plan to add keyword
> creation to the API? Keywords are a pretty common part of many Clojure APIs,
> it would be good to allow their creation without forcing people to use
> Keyword.intern().

IFn kw = API.var("clojure.core", "keyword");
... kw.invoke("str") ... // produces :str

That's what I do in cfmljure, just wrapped up in my own utility function.

> On November 23, 2013 at 8:16:48 PM, a...@puredanger.com
> (a...@puredanger.com) wrote:
> Please be aware that we expect to make changes to the API package and class
> name in the next alpha based on a discussion today so you may want to wait
> for RC for that!

NP. I wasn't planning to rewrite cfmljure until 1.6 goes gold and we
switch from 1.5.1 to 1.6 :)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread Sean Corfield 
On Sat, Nov 23, 2013 at 3:06 PM, Alexander Hudek  wrote:
> As Dave said, we can move to honeysql without too much trouble. However, it
> would be extremely useful to move the sql namespace to a separate library as
> an interim solution.

OK, I'll get that done soon.

> Out of curiosity, what exactly does entities do? It isn't immediately
> obvious from the document string.

entities (and identifiers) walk the contained expression and insert
the :entities (or :identifiers) argument into forms that support it so
that naming strategies are applied as expected. In other words:

(entities (quoted \`)
  (query (my-db)
(select [:id {:title :name}] :thing
  (where {:status "active"}

is shorthand for:

  (query (my-db)
(select [:id {:title :name}] :thing
  (where {:status "active"} :entities (quoted \`))
  :entities (quoted \`

So this generates:

  (query (my-db)
["select `id`, `title` as `name` from `thing` where `status` = ?" "active"])

-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread Alexander Hudek 
As Dave said, we can move to honeysql without too much trouble. However, it 
would be extremely useful to move the sql namespace to a separate library 
as an interim solution.

Out of curiosity, what exactly does entities do? It isn't immediately 
obvious from the document string.

On Friday, November 22, 2013 1:12:05 AM UTC-5, Sean Corfield wrote:
>
>  I spent this afternoon removing use of java.jdbc.sql from World Singles’ 
> code base to see how much work it would be. The worst part for us was how 
> much we relied on the naming strategy convenience macros (especially 
> entities, since it flows :entities through all the DSL constructs).
>
> How much impact would it have on you, Alexander, if the java.jdbc.sql 
> namespace went away? 
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- 
> http://corfield.org
>
> *From:* Alexander Hudek 
> *Sent:* Thursday, November 21, 2013 7:37 PM
> *To:* clo...@googlegroups.com 
>
>
>> Is anyone using the java.jdbc.sql namespace? (besides World Singles :) 
>>
>>
> We are using it but not the DDL. We also use honeysql in places where 
> jdbc.sql cannot express the query.
>
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>  

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

Re: [ANN] Clojure 1.6.0-alpha3

2013-11-23 Thread Colin Fleming 
BTW (and I may be a little late here) - is there a plan to add keyword creation 
to the API? Keywords are a pretty common part of many Clojure APIs, it would be 
good to allow their creation without forcing people to use Keyword.intern().

On November 23, 2013 at 8:16:48 PM, a...@puredanger.com (a...@puredanger.com) 
wrote:

Please be aware that we expect to make changes to the API package and class 
name in the next alpha based on a discussion today so you may want to wait for 
RC for that!



On Nov 22, 2013, at 11:06 PM,  wrote:

Thank you.

I’d like to take this opportunity to thank the Clojure/core team for the slow, 
measured pace of development and stability of Clojure. 1.6 looks like a safe, 
gentle upgrade from 1.5.1.

Ironically the biggest change for me in 1.6 is the new API stuff - I look 
forward to rewriting my cfmljure library to leverage the new API once it goes 
gold! 😊

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

From: Alex Miller
Sent: ‎Friday‎, ‎November‎ ‎22‎, ‎2013 ‎7‎:‎26‎ ‎PM
To: clojure@googlegroups.com

Clojure 1.6.0-alpha3 is now available. 
 
Try it via 
- Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha3/
- Leiningen: [org.clojure/clojure "1.6.0-alpha3"]

Clojure 1.6.0-alpha3 has the following changes from 1.6.0-alpha2:

1) Reverted: CLJ-1125 (fix for permgen leak) based on the regression reported 
in CLJ-1299. A fix for this regression is in development and I expect it to be 
re-applied in a future alpha.
- http://dev.clojure.org/jira/browse/CLJ-1125
- http://dev.clojure.org/jira/browse/CLJ-1299

2) The following features are no longer marked "Alpha" in Clojure (woohoo!):

* Watches - add-watch, remove-watch
* Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
* Exception data - ex-info, ex-data
* Promises - promise, deliver
* Records - defrecord
* Types - deftype
* Pretty-print tables - print-table

3) Applied patches for:

* [CLJ-827](http://dev.clojure.org/jira/browse/CLJ-827) - New function: 
clojure.core/unsigned-bit-shift-right
* [CLJ-866](http://dev.clojure.org/jira/browse/CLJ-866) - New function: 
clojure.test/test-vars
* [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102) - Better handling of 
exceptions with empty stack traces.
* [CLJ-939](http://dev.clojure.org/jira/browse/CLJ-939) - Exceptions thrown in 
the top level ns form are reported without file or line number.
* [CLJ-858](http://dev.clojure.org/jira/browse/CLJ-858) - Improve speed of STM 
by removing System.currentTimeMillis.
* [CLJ-669](http://dev.clojure.org/jira/browse/CLJ-669) - 
clojure.java.io/do-copy: use java.nio for Files
* [CLJ-1105](http://dev.clojure.org/jira/browse/CLJ-1105) - clojure.walk now 
supports records.
* [CLJ-949](http://dev.clojure.org/jira/browse/CLJ-949) - Removed all 
unnecessary cases of sneakyThrow.
* [CLJ-1238](http://dev.clojure.org/jira/browse/CLJ-1238) - Allow EdnReader to 
read foo// (matches LispReader behavior).
* [CLJ-1264](http://dev.clojure.org/jira/browse/CLJ-1264) - Remove uses of _ as 
a var in the Java code (causes warning in Java 8).
* [CLJ-1222](http://dev.clojure.org/jira/browse/CLJ-1222) - Multiplication 
overflow issues around Long/MIN_VALUE
* [CLJ-1118](http://dev.clojure.org/jira/browse/CLJ-1118) - Inconsistent 
numeric comparison semantics between BigDecimals and other numerics

3) Full change log is updated as well:
https://github.com/clojure/clojure/blob/master/changes.md

Still on the plate are 16 tickets (I expect many but not all of those to make 
it in) and the hashing performance work 
(http://dev.clojure.org/display/design/Better+hashing). Once we reach 
"completion" we'll release an RC for final testing.

Alex Miller

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

Re: Feedback on destructuring code walkthrough? (could not nest :keys inside :keys)

2013-11-23 Thread Karsten Schmidt 
No prob, you might also want to check Jay Fields' blog post (one of
the most often cited resources) for more destructuring options:

http://blog.jayfields.com/2010/07/clojure-destructuring.html

On 23 November 2013 18:19, David James  wrote:
> Thanks Karsten! I updated the Github example based on your recommendation.
>
>
> On Friday, November 22, 2013 4:30:19 PM UTC-5, Karsten Schmidt wrote:
>>
>> The nested `:keys` form for `b1`/`b2` must be moved out from the
>> vector containing `a`...
>>
>> (defn foo [{:keys [a] {:keys [b1 b2] :as b} :b}] [a b1 b2 b])
>>
>> (foo {:a 1 :b {:b1 2 :b2 3}})
>> ; => [1 2 3 {:b2 3, :b1 2}]
>>
>> On 22 November 2013 19:06, David James  wrote:
>> > I made a quick destructuring code walkthrough at
>> > https://github.com/xpe/clj-destruct/blob/master/src/destruct/core.clj
>> >
>> > I was hoping to show how to nest :keys inside of :keys but failed. Did I
>> > overlook something?



-- 
Karsten Schmidt
http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk

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

Re: gemacl: Scientific computing application written in Clojure

2013-11-23 Thread Jose M. Perez Sanchez 
Yes, the step extract function encodes the total number of steps and any 
intermediate steps whose values are to be saved.

I did the following changes to the code:

1 - Store results locally in the threads and return them when the thread 
function exits, instead of using global vector. This does not impact 
performance directly (tested), but allows to use a transient vector to 
store the results locally, which is faster.
2 - Use loop/recur to loop over the particles, the steps and the valid 
displacement generation (instead of lazy sequences with extract function). 
Also in a few other small loops that are executed many times.
3 - Use transients in any vector to which a lot of data is going to be 
conjoined during the calculation.

These changes brought the following results. There is some improvement, 
both in computing time and scaling. See graphs attached: The master branch 
is the old code I posted already and the perftest branch contains the 
changes. I'm sure there is still room for improvement, and I'll focus on 
that as soon as some important missing features get implemented and I can 
finish some calculations that we need urgently.

kovasb: Could you elaborate the last part of "I think you should try making 
the core iteration purely functional, meaning no agents, atoms, *or side 
effecting functions like the random generator*"? I did remove the atom and 
agent (I keep a global integer ref though since I need to track the 
progress of the calculation). Regarding the random displacements, if it 
means generating them first and then consuming them in a side effect free 
fashion, it would take a lot of RAM to store all those numbers...

Thanks a lot for the help, I'll keep you posted about any other tests that 
might be interesting and will let you know when the code gets released.

Best,

Jose.

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


benchmark.pdf
Description: Adobe PDF document


scaling.pdf
Description: Adobe PDF document

Re: Feedback on destructuring code walkthrough? (could not nest :keys inside :keys)

2013-11-23 Thread David James 
Thanks Karsten! I updated the Github example based on your recommendation.

On Friday, November 22, 2013 4:30:19 PM UTC-5, Karsten Schmidt wrote:
>
> The nested `:keys` form for `b1`/`b2` must be moved out from the 
> vector containing `a`... 
>
> (defn foo [{:keys [a] {:keys [b1 b2] :as b} :b}] [a b1 b2 b]) 
>
> (foo {:a 1 :b {:b1 2 :b2 3}}) 
> ; => [1 2 3 {:b2 3, :b1 2}] 
>
> On 22 November 2013 19:06, David James > 
> wrote: 
> > I made a quick destructuring code walkthrough at 
> > https://github.com/xpe/clj-destruct/blob/master/src/destruct/core.clj
> >  
> > 
> > I was hoping to show how to nest :keys inside of :keys but failed. Did I 
> > overlook something? 
>

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

Re: preferred way to dereference a ref: outside or inside dosync?

2013-11-23 Thread Stefan Kamphausen 


On Saturday, November 23, 2013 3:17:07 PM UTC+1, Justin Smith wrote:
>
> Of course in a real app the key should be serialized to a persistent, 
> consistent, and shared data store.
>
>
Which of course depends on the app in question. The code above was taken 
from a 'real app', if 'an app that is used productively' counts as one of 
those. :-)

Cheers,
stefan

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

Re: [ClojureScript] ANN: ClojureScript 0.0-2075

2013-11-23 Thread Mimmo Cosenza 
unrestrainable :-)
thanks!

On Nov 23, 2013, at 4:04 PM, David Nolen  wrote:

> Just pushed out 0.0-2080, fixes a regression around inference and adds 
> unsigned-bit-shift-right to keep in sync with the Clojure 1.6 alphas.
> 
> David
> 
> 
> On Fri, Nov 22, 2013 at 7:44 PM, David Nolen  wrote:
> Following the last announcement, the only significant changes are CLJS-681 
> which is Windows source map support and improved numeric checks.
> 
> David
> 
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN: ClojureScript 0.0-2075

2013-11-23 Thread David Nolen 
Just pushed out 0.0-2080, fixes a regression around inference and adds
unsigned-bit-shift-right to keep in sync with the Clojure 1.6 alphas.

David


On Fri, Nov 22, 2013 at 7:44 PM, David Nolen  wrote:

> Following the last announcement, the only significant changes are CLJS-681
> which is Windows source map support and improved numeric checks.
>
> David
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-23 Thread Justin Smith 
I have successfully run a fresh caribou site on Windows 8, with the latest 
default 64 bit jdk from sun. You may need to explicitly supply a -Xmx 
argument to your jvm (I don't know how predictable the default maximums 
are).

You are welcome to post issues on our github pages.

If we made a forum site, we would likely prefer eating our own dog food, 
I've got a commenting plugin for caribou on my TODO list.

On Saturday, November 23, 2013 1:09:22 AM UTC-8, Roman Yakovlev wrote:
>
> Great stuff
>
> Some suggestions and questions
> - forum is needed to disquss features and bugs. Something like 
> http://www.discourse.org/
>  would 
> be super awesome ( no google groups plz ! ) 
> - documentation with user comments, Disquss would be enough for now but it 
> would be great if it can be users driven ( if i want to add some examples 
> or some additional stuff for example) at gihub for example with users pull 
> requests.
>
> There is a problem running Caribou at windows 
>
> -> Running migrations on resources/config/development.clj
> Error occurred during initialization of VM
> Could not reserve enough space for object heap
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Subprocess failed
>
> I have enough memory and space here something else 
> On linux box(ubuntu) it runs ok..
>
> среда, 13 ноября 2013 г., 3:52:10 UTC+4 пользователь Ryan Spangler написал:
>>
>> Hello Clojure,
>>
>> Excited to announce today the release of Caribou!  
>> http://let-caribou.in/
>>
>> We have been building web sites and web applications with it for over two 
>> years now and improving it every day.  Currently we have four people 
>> working on it and another ten using it to build things, so it is getting a 
>> lot of real world testing.
>>
>> It has been designed as a collection of independent libraries that could 
>> each be useful on their own, but which come together as a meaningful whole.
>>
>> We have been spending the last couple months getting it ready for a full 
>> open source release, and I am happy to say it is finally ready.  Funded and 
>> supported by Instrument in Portland, OR:  
>> http://weareinstrument.com/
>>  We have four projects using it in production, and several more about to be 
>> launched (as well as over a dozen internal things).
>>
>> Documentation is here:  
>> http://caribou.github.io/caribou/docs/outline.html
>>
>> Source is here:  
>> http://github.com/caribou/caribou(use
>>  this for issues, you don't actually need the source as it is installed 
>> through a lein template).
>>
>> Some of the independently useful libraries Caribou is built on are:
>>
>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>> https://github.com/caribou/polaris
>> * Lichen -- Image resizing to and from s3 or on disk: 
>> https://github.com/caribou/lichen
>> * Schmetterling -- Debugging Clojure processes from the browser:  
>> https://github.com/prismofeverything/schmetterling
>> * Antlers -- Useful extensions to mustache templating (helpers and 
>> blocks, among other things):  
>> https://github.com/caribou/antlers
>> * Groundhog -- Replay http requests: 
>> https://github.com/noisesmith/groundhog
>>
>> And many others.
>>
>> Basically this is an Alpha release, and I am announcing it here first in 
>> order to get as much feedback from the community as possible.  We have made 
>> it as useful as we can for our purposes and recognize that for it to 
>> improve from here, we really need as many people using it and building 
>> things with it as possible.  The documentation also needs to be put through 
>> its paces:  we need to see how well people are able to use it who know 
>> nothing about it, b

Re: preferred way to dereference a ref: outside or inside dosync?

2013-11-23 Thread Justin Smith 
you may want to make that (defonce generate-keys (get-key-generator))

and even better, add a "start" argument to get-key-generator so you can 
persist across restarts of the vm.

Of course in a real app the key should be serialized to a persistent, 
consistent, and shared data store.

On Friday, November 22, 2013 3:05:06 AM UTC-8, Jim foo.bar wrote:
>
>  On 22/11/13 08:18, Stefan Kamphausen wrote:
>  
> How about
>
> (defn get-key-generator []
>   (let [i (atom 0)]
> (fn [] (swap! i inc
>  
> (def generate-keys (get-key-generator))
>
>
> nice one, much better than mine :) 
>
> thanks Stefan...
>
> Jim
>  

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

Re: [ANN] optparse-clj: Functional GNU-style command line options parsing

2013-11-23 Thread John Szakmeister 
On Fri, Nov 22, 2013 at 8:30 PM, guns  wrote:
> On Fri 22 Nov 2013 at 07:22:20PM -0500, John Szakmeister wrote:
>
>> This looks very nice.  Have you considered something along the lines
>> of Python's argparse?
>>
>> http://docs.python.org/dev/library/argparse.html
>
> Thank you. I am not familiar with Python's argparse. My experience with
> option parsers are primarily the C functions getopt and getopt_long, the
> getopts builtin in bash, and Ruby's OptionParser.
>
> On first scan, argparse and OptionParser appear to be very similar,
> both in capability and programming interface. I know OptionParser
> particularly well, and while I enjoy its flexibility and power, the
> actual implemention and scope of what it tries to accomplish are quite
> un-Clojuresque.

Sorry, I didn't mean to suggest you should model the inteface after
argparse.  That said, I think there's much about it that's declarative
and would fit well.

> The beautiful thing about tools.cli is that it is conceptually very
> simple: it reduces an option specification and a list of arguments into
> a map of configuration options.

Yep, and I think that's good as well.

> IMHO, printing elaborate usage banners, associating subcommands with
> methods, managing options of subcommands, and invoking behaviour should
> be handled separately from option parsing. The guiding principle of
> optparse-clj and the next version of tools.cli is to provide data and
> let the user take it from there.

The one thing that makes argparse interesting from everything else is
that it gives all the nice handling to arguments as well.  I can see
from the examples you've got things like :parse-fn for parsing the
argument and turning it into something else.  It's nice to have those
features for arguments as well, and that's where I think argparse is
really shines.  It treats both options and arguments as first-class
citizens. :-)

I think that would be useful for your library as well.

>> It's nice to see you thought about subcommand support as well. Thank
>> you for your contribution!
>
> The gist I linked to earlier¹ contains a detailed proposal for how I'd
> like to advance tools.cli. If you are interested, comments on that are
> much appreciated.

I'll take a look at it over the weekend.  Thanks!

-John

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

2013-11-23 Thread John D. Hume 
On Nov 22, 2013 4:09 PM, "Sean Corfield"  wrote:
>
> Perhaps a solution here is for me to
> put it in a library, on Clojars, under a different name and let folks
> migrate to that as an interim solution (i.e., identical API so folks
> would just update project.clj and update some ns declarations)?

That sounds like a good move.

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

[ANN] Amazon Kinesis support in Amazonica

2013-11-23 Thread Michael Cohen 
We're starting to play around with Kinesis[1] to get a sense of
performance, reliability, and cost. The Clojure api provides access to all
functionality[2] and handles most of the plumbing details[3] associated
with the client lib. Note: You will need the client library to test drive
it.

https://github.com/mcohen01/amazonica/tree/kinesis#kinesis

[1] https://docs.aws.amazon.com/kinesis/latest/dev/introduction.html
[2]
https://docs.aws.amazon.com/kinesis/latest/dev/kinesis-using-api-java.html
[3]
https://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record-processor-app.html


- Michael

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-23 Thread Roman Yakovlev 
Great stuff

Some suggestions and questions
- forum is needed to disquss features and bugs. Something like 
http://www.discourse.org/ would be super awesome ( no google groups plz ! ) 
- documentation with user comments, Disquss would be enough for now but it 
would be great if it can be users driven ( if i want to add some examples 
or some additional stuff for example) at gihub for example with users pull 
requests.

There is a problem running Caribou at windows 

-> Running migrations on resources/config/development.clj
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Subprocess failed

I have enough memory and space here something else 
On linux box(ubuntu) it runs ok..

среда, 13 ноября 2013 г., 3:52:10 UTC+4 пользователь Ryan Spangler написал:
>
> Hello Clojure,
>
> Excited to announce today the release of Caribou!  
> http://let-caribou.in/
>
> We have been building web sites and web applications with it for over two 
> years now and improving it every day.  Currently we have four people 
> working on it and another ten using it to build things, so it is getting a 
> lot of real world testing.
>
> It has been designed as a collection of independent libraries that could 
> each be useful on their own, but which come together as a meaningful whole.
>
> We have been spending the last couple months getting it ready for a full 
> open source release, and I am happy to say it is finally ready.  Funded and 
> supported by Instrument in Portland, OR:  
> http://weareinstrument.com/
>  We have four projects using it in production, and several more about to be 
> launched (as well as over a dozen internal things).
>
> Documentation is here:  
> http://caribou.github.io/caribou/docs/outline.html
>
> Source is here:  
> http://github.com/caribou/caribou(use
>  this for issues, you don't actually need the source as it is installed 
> through a lein template).
>
> Some of the independently useful libraries Caribou is built on are:
>
> * Polaris -- Routing with data (not macros) and reverse routing! :  
> https://github.com/caribou/polaris
> * Lichen -- Image resizing to and from s3 or on disk: 
> https://github.com/caribou/lichen
> * Schmetterling -- Debugging Clojure processes from the browser:  
> https://github.com/prismofeverything/schmetterling
> * Antlers -- Useful extensions to mustache templating (helpers and blocks, 
> among other things):  
> https://github.com/caribou/antlers
> * Groundhog -- Replay http requests: 
> https://github.com/noisesmith/groundhog
>
> And many others.
>
> Basically this is an Alpha release, and I am announcing it here first in 
> order to get as much feedback from the community as possible.  We have made 
> it as useful as we can for our purposes and recognize that for it to 
> improve from here, we really need as many people using it and building 
> things with it as possible.  The documentation also needs to be put through 
> its paces:  we need to see how well people are able to use it who know 
> nothing about it, based only on the existing docs.
>
> All feedback welcome!  
>
> Thanks for reading!  I hope you find it useful.
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-23 Thread Roman Yakovlev 
Great stuff

Some suggestions and questions
- forum is needed to disquss features and bugs. Something like 
http://www.discourse.org/ would be super awesome ( no google groups plz ! ) 
- documentation with user comments, Disquss would be enough for now but it 
would be great if it can be users driven ( if i want to add some examples 
or some additional stuff for example) at gihub for example with users pull 
requests.

There is a problem running Caribou at windows 

-> Running migrations on resources/config/development.clj
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Subprocess failed

I have enough memory and space here something else 
On linux box(ubuntu) it runs ok..

среда, 13 ноября 2013 г., 3:52:10 UTC+4 пользователь Ryan Spangler написал:
>
> Hello Clojure,
>
> Excited to announce today the release of Caribou!  
> http://let-caribou.in/
>
> We have been building web sites and web applications with it for over two 
> years now and improving it every day.  Currently we have four people 
> working on it and another ten using it to build things, so it is getting a 
> lot of real world testing.
>
> It has been designed as a collection of independent libraries that could 
> each be useful on their own, but which come together as a meaningful whole.
>
> We have been spending the last couple months getting it ready for a full 
> open source release, and I am happy to say it is finally ready.  Funded and 
> supported by Instrument in Portland, OR:  
> http://weareinstrument.com/
>  We have four projects using it in production, and several more about to be 
> launched (as well as over a dozen internal things).
>
> Documentation is here:  
> http://caribou.github.io/caribou/docs/outline.html
>
> Source is here:  
> http://github.com/caribou/caribou(use
>  this for issues, you don't actually need the source as it is installed 
> through a lein template).
>
> Some of the independently useful libraries Caribou is built on are:
>
> * Polaris -- Routing with data (not macros) and reverse routing! :  
> https://github.com/caribou/polaris
> * Lichen -- Image resizing to and from s3 or on disk: 
> https://github.com/caribou/lichen
> * Schmetterling -- Debugging Clojure processes from the browser:  
> https://github.com/prismofeverything/schmetterling
> * Antlers -- Useful extensions to mustache templating (helpers and blocks, 
> among other things):  
> https://github.com/caribou/antlers
> * Groundhog -- Replay http requests: 
> https://github.com/noisesmith/groundhog
>
> And many others.
>
> Basically this is an Alpha release, and I am announcing it here first in 
> order to get as much feedback from the community as possible.  We have made 
> it as useful as we can for our purposes and recognize that for it to 
> improve from here, we really need as many people using it and building 
> things with it as possible.  The documentation also needs to be put through 
> its paces:  we need to see how well people are able to use it who know 
> nothing about it, based only on the existing docs.
>
> All feedback welcome!  
>
> Thanks for reading!  I hope you find it useful.
>

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