Re: ANN: Clojure Libraries
I noticed it last when the new CSS theme wasn't applied - looks way better now. Well done, and looking forward to the features you mentioned. Regards, Shantanu On Feb 28, 4:56 am, Glen Stampoultzis wrote: > Hi everyone, > > I'd like to announce the availability of Clojure Libraries > (http://clojure-libraries.appspot.com/). Clojure Libraries is a > database for keeping track of Clojure libraries and tools. Clojure > Libraries can be edited by end users (by logging in with a Google > account). Edits are tracked somewhat like a wiki and bad edits can be > compared and rolled back. Comments can also be added to individual > libraries and extra details like the group and artifact name can be > added (which will link through to clojars automatically). > > Some of the features I plan on adding in the near future include: > > * Atom feeds for changes to the site > * Editing of categories and subcategories > * Ratings > * A search feature > > I planned on putting this on it's own domain however there were a few > technical issues when I attempted to do this so for now you can just > access it viahttp://clojure-libraries.appspot.com/. > > If you'd like to add or edit a library but don't have a Google account > (and would prefer not to create one) feel free to email me directly at > gst...@gmail.com and I'll add it for you. > > PS. This overlaps somewhat with Clojure Toolbox which, via an > unfortunate coincidence, came out about the same time. There are some > important differences however, so I thought it best to continue with > this release. > > Regards, > > Glen -- 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
Project/repo name change (Re: [ANN] Openar, a Clojure environment)
Hi again, Well, I made a mistake when I pushed the original repo on GitHub. There is already a well-known and respected project and my project/repo name is so close to it and confusing. So I fixed it; the new project/repo name is now Sevenri, https://github.com/ksuzuki/Sevenri. It's based on the name of a beach close to where I live. The code and docs were also updated due to the change. The google group with the old repo name was closed. I made my best to make Sevenri start up from a fresh clone. But not everybody's system is the same and Sevenri may not start on your Mac. Please report the issue to the GitHub issue tracker or the new mailing list, http://groups.google.com/group/sevenri. I really appreciate your help. Thanks a lot in advance! Sincerely, Kei Suzuki -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Libraries
Cool! I'd like to suggest a tagging feature rather-than/in-addition- to the categorization feature. On Feb 27, 5:56 pm, Glen Stampoultzis wrote: > Hi everyone, > > I'd like to announce the availability of Clojure Libraries > (http://clojure-libraries.appspot.com/). Clojure Libraries is a > database for keeping track of Clojure libraries and tools. Clojure > Libraries can be edited by end users (by logging in with a Google > account). Edits are tracked somewhat like a wiki and bad edits can be > compared and rolled back. Comments can also be added to individual > libraries and extra details like the group and artifact name can be > added (which will link through to clojars automatically). > > Some of the features I plan on adding in the near future include: > > * Atom feeds for changes to the site > * Editing of categories and subcategories > * Ratings > * A search feature > > I planned on putting this on it's own domain however there were a few > technical issues when I attempted to do this so for now you can just > access it viahttp://clojure-libraries.appspot.com/. > > If you'd like to add or edit a library but don't have a Google account > (and would prefer not to create one) feel free to email me directly at > gst...@gmail.com and I'll add it for you. > > PS. This overlaps somewhat with Clojure Toolbox which, via an > unfortunate coincidence, came out about the same time. There are some > important differences however, so I thought it best to continue with > this release. > > Regards, > > Glen -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Libraries
On 28 February 2011 12:01, James Reeves wrote: > On 27 February 2011 23:56, Glen Stampoultzis wrote: >> PS. This overlaps somewhat with Clojure Toolbox which, via an >> unfortunate coincidence, came out about the same time. There are some >> important differences however, so I thought it best to continue with >> this release. > > I'd definitely encourage you to continue :) > > I know of at least one other effort to categorize Clojure libraries, > and each has taken a different approach to this problem. I'm generally > of the opinion that a diverse ecosystem is usually better than a > monoculture. > > - James It is funny how these things happen. There were also a couple of Clojure API documentation sites that came out around the same time as well. Writing the site has been a fun exercise. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Libraries
On 27 February 2011 23:56, Glen Stampoultzis wrote: > PS. This overlaps somewhat with Clojure Toolbox which, via an > unfortunate coincidence, came out about the same time. There are some > important differences however, so I thought it best to continue with > this release. I'd definitely encourage you to continue :) I know of at least one other effort to categorize Clojure libraries, and each has taken a different approach to this problem. I'm generally of the opinion that a diverse ecosystem is usually better than a monoculture. - 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
ANN: Clojure Libraries
Hi everyone, I'd like to announce the availability of Clojure Libraries (http://clojure-libraries.appspot.com/). Clojure Libraries is a database for keeping track of Clojure libraries and tools. Clojure Libraries can be edited by end users (by logging in with a Google account). Edits are tracked somewhat like a wiki and bad edits can be compared and rolled back. Comments can also be added to individual libraries and extra details like the group and artifact name can be added (which will link through to clojars automatically). Some of the features I plan on adding in the near future include: * Atom feeds for changes to the site * Editing of categories and subcategories * Ratings * A search feature I planned on putting this on it's own domain however there were a few technical issues when I attempted to do this so for now you can just access it via http://clojure-libraries.appspot.com/. If you'd like to add or edit a library but don't have a Google account (and would prefer not to create one) feel free to email me directly at gst...@gmail.com and I'll add it for you. PS. This overlaps somewhat with Clojure Toolbox which, via an unfortunate coincidence, came out about the same time. There are some important differences however, so I thought it best to continue with this release. Regards, Glen -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: type hinting record types?
Maybe records shouldnt be redefined if their definition hasnt changed? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
With a fresh brain (and a fresh cup of coffee), I realized this
message is probably caused (somehow) by my misuse of the midje
library. No doubt it does fancy macro stuff under-the-hood.
At the core of this problem is that I'm a naive client of this macro
library and by an innocent misuse, I am stuck trying to debug my
syntax error by commenting out various pieces, adding printlns to see
how far the compiler gets in evaluating expressions, and guessing what
could be causing the problem. One could certainly argue that the
macro should do more to detect syntax errors and report them
gracefully and I would agree. I do not believe that relieves any
responsibility from the compiler to report as much information as it
can when it detects an error.
It would be nice if the compiler would report the macro form it was
trying to expand. I see it being an IDEs job to add niceties like a
macro expander tool which would let me expand the macro step-by-step.
None of this should be taken as a knock against midje. I'm just
starting to learn it and the style of programming it fosters and I
like it very much!
On Feb 27, 1:50 pm, Mark wrote:
> I wrote that up quickly without thinking much about it. Yes, the
> invocation is definitely a macro and not a function. Still, I think
> it would be helpful to see the symbol's value and, if possible, the
> macro's arity.
>
> On Feb 27, 1:13 pm, Ken Wesson wrote:
>
>
>
>
>
>
>
> > On Sun, Feb 27, 2011 at 2:10 PM, Ken Wesson wrote:
> > > On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote:
> > >> I get this:
> > >> # > >> of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main
> > >> \clojure:1)>
>
> > >> A few suggestions:
> > >> 1) An improved line number
> > >> 2) I'd like to see the value of the Symbol
> > >> 3) I'd like to see the three args applies to the symbol and, if the
> > >> symbol resolves to a function, I'd like to see the arity of the
> > >> function.
>
> > >> Something like:
> > >> Wrong number of args (3) passed to Symbol 'some-fn' which expects
> > >> arity 2
>
> > > This is interesting. I just checked with my copy of 1.2 and it seems
> > > you can indeed call a symbol as a function. It appears to try to look
> > > itself up in its first argument, the same as a keyword, and if not
> > > found or the first argument is not a map returns the (optional) second
> > > argument:
>
> > > user=> ('+ {'+ 3 '* 4} 42)
> > > 3
> > > user=> ('+ {'- 3 '* 4} 42)
> > > 42
>
> > > Of course this is rather icky to use because of the need to quote the
> > > symbols.
>
> > > So, the arity expected by a function like + ends up irrelevant. If you
> > > invoke something on '+ it wants either one or two arguments.
>
> > > If you're seeing this error you probably have a buggy macro that's not
> > > unquoting something as many times as it should be. Quoting-depth
> > > errors (other than forgetting to unquote something at all) seem to be
> > > most common when writing macros that emit other macros, and ending up
> > > with nested syntax-quoted expressions, doubled-up ~~@foo type
> > > unquotings, and things like `(quote ~foo) in helper functions.
>
> > > If the error points to a macro invocation I'd suggest inspecting the
> > > output of (macroexpand-1 '(the-problem-invocation)) and seeing what
> > > you get. If the output contains quoted symbols in operator position
> > > that clearly are meant to be just normal calls to functions then
> > > you've at least determined that the problem is caused by the macro.
> > > Though it could be the case that your arguments to the macro violate
> > > its preconditions. If it's not your own macro, check its
> > > documentation. If it is it has a bug since it's not doing what you
> > > want it to do and it's yours. If it's not it may or may not have a
> > > bug.
>
> > Addendum: the most likely macro *argument* error to cause this is
> > quoting a function name macro argument that you shouldn't be quoting,
> > e.g. (the-macro 'my-func ...) instead of (the-macro my-func ...). The
> > macro just plops (quote my-func) wherever it should put my-func and
> > boom!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
On 27 February 2011 20:50, Mark wrote: > I wrote that up quickly without thinking much about it. Yes, the > invocation is definitely a macro and not a function. Still, I think > it would be helpful to see the symbol's value and, if possible, the > macro's arity. Is calling symbols as a function actually used anywhere in Clojure or in the real world? If not, it might make sense to remove this (rather unexpected, IMHO) feature as a backwards-incompatible change. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Toolbox (Early Beta)
On 25 February 2011 21:06, Wilson MacGyver wrote: > I like to suggest > > clj-json https://github.com/mmcgrana/clj-json > a fast JSON encoder/decoder that uses jackson. > > clojuresque https://bitbucket.org/kotarak/clojuresque/src > clojure plugin for gradle (a very good build system) > > clj-time https://github.com/getwoven/clj-time > clojure binding for jodatime > > clothesline https://github.com/BankSimple/Clothesline > port of erlang webmachine to clojure > > work https://github.com/getwoven/work > a worker pool system Added. On 25 February 2011 20:56, Avram wrote: > Take a look at infer: > > https://github.com/getwoven/infer Added. - 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
Re: better error messages > smaller stack traces
I wrote that up quickly without thinking much about it. Yes, the
invocation is definitely a macro and not a function. Still, I think
it would be helpful to see the symbol's value and, if possible, the
macro's arity.
On Feb 27, 1:13 pm, Ken Wesson wrote:
> On Sun, Feb 27, 2011 at 2:10 PM, Ken Wesson wrote:
> > On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote:
> >> I get this:
> >> # >> of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main
> >> \clojure:1)>
>
> >> A few suggestions:
> >> 1) An improved line number
> >> 2) I'd like to see the value of the Symbol
> >> 3) I'd like to see the three args applies to the symbol and, if the
> >> symbol resolves to a function, I'd like to see the arity of the
> >> function.
>
> >> Something like:
> >> Wrong number of args (3) passed to Symbol 'some-fn' which expects
> >> arity 2
>
> > This is interesting. I just checked with my copy of 1.2 and it seems
> > you can indeed call a symbol as a function. It appears to try to look
> > itself up in its first argument, the same as a keyword, and if not
> > found or the first argument is not a map returns the (optional) second
> > argument:
>
> > user=> ('+ {'+ 3 '* 4} 42)
> > 3
> > user=> ('+ {'- 3 '* 4} 42)
> > 42
>
> > Of course this is rather icky to use because of the need to quote the
> > symbols.
>
> > So, the arity expected by a function like + ends up irrelevant. If you
> > invoke something on '+ it wants either one or two arguments.
>
> > If you're seeing this error you probably have a buggy macro that's not
> > unquoting something as many times as it should be. Quoting-depth
> > errors (other than forgetting to unquote something at all) seem to be
> > most common when writing macros that emit other macros, and ending up
> > with nested syntax-quoted expressions, doubled-up ~~@foo type
> > unquotings, and things like `(quote ~foo) in helper functions.
>
> > If the error points to a macro invocation I'd suggest inspecting the
> > output of (macroexpand-1 '(the-problem-invocation)) and seeing what
> > you get. If the output contains quoted symbols in operator position
> > that clearly are meant to be just normal calls to functions then
> > you've at least determined that the problem is caused by the macro.
> > Though it could be the case that your arguments to the macro violate
> > its preconditions. If it's not your own macro, check its
> > documentation. If it is it has a bug since it's not doing what you
> > want it to do and it's yours. If it's not it may or may not have a
> > bug.
>
> Addendum: the most likely macro *argument* error to cause this is
> quoting a function name macro argument that you shouldn't be quoting,
> e.g. (the-macro 'my-func ...) instead of (the-macro my-func ...). The
> macro just plops (quote my-func) wherever it should put my-func and
> boom!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problem establishing jdbc connection in la clojure REPL
According to MSDN: WSAEPROVIDERFAILEDINIT 10106 Service provider failed to initialize. The requested service provider could not be loaded or initialized. This error is returned if either a service provider's DLL could not be loaded (LoadLibrary failed) or the provider's WSPStartup or NSPStartup function failed. If these environments are launching distinct JVM installations then one may be failing to access a DLL another can see. This is definitely a weird one, though. The most obvious reason for networking to fail in one app and simultaneously succeed in another is a software firewall (such as ZoneAlarm) configured to allow, say, NetBeans and child processes to talk to the net but not told to let IDEA do so. But I'd expect that to manifest as connection refused or timeout errors rather than a failure to even initialize some DLL. Does attempting to access the DB from *Java* (not Clojure) in IDEA work? What is in the IDEA help files about databases and networking? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
On Sun, Feb 27, 2011 at 2:10 PM, Ken Wesson wrote:
> On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote:
>> I get this:
>> #> of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main
>> \clojure:1)>
>>
>> A few suggestions:
>> 1) An improved line number
>> 2) I'd like to see the value of the Symbol
>> 3) I'd like to see the three args applies to the symbol and, if the
>> symbol resolves to a function, I'd like to see the arity of the
>> function.
>>
>> Something like:
>> Wrong number of args (3) passed to Symbol 'some-fn' which expects
>> arity 2
>
> This is interesting. I just checked with my copy of 1.2 and it seems
> you can indeed call a symbol as a function. It appears to try to look
> itself up in its first argument, the same as a keyword, and if not
> found or the first argument is not a map returns the (optional) second
> argument:
>
> user=> ('+ {'+ 3 '* 4} 42)
> 3
> user=> ('+ {'- 3 '* 4} 42)
> 42
>
> Of course this is rather icky to use because of the need to quote the symbols.
>
> So, the arity expected by a function like + ends up irrelevant. If you
> invoke something on '+ it wants either one or two arguments.
>
> If you're seeing this error you probably have a buggy macro that's not
> unquoting something as many times as it should be. Quoting-depth
> errors (other than forgetting to unquote something at all) seem to be
> most common when writing macros that emit other macros, and ending up
> with nested syntax-quoted expressions, doubled-up ~~@foo type
> unquotings, and things like `(quote ~foo) in helper functions.
>
> If the error points to a macro invocation I'd suggest inspecting the
> output of (macroexpand-1 '(the-problem-invocation)) and seeing what
> you get. If the output contains quoted symbols in operator position
> that clearly are meant to be just normal calls to functions then
> you've at least determined that the problem is caused by the macro.
> Though it could be the case that your arguments to the macro violate
> its preconditions. If it's not your own macro, check its
> documentation. If it is it has a bug since it's not doing what you
> want it to do and it's yours. If it's not it may or may not have a
> bug.
Addendum: the most likely macro *argument* error to cause this is
quoting a function name macro argument that you shouldn't be quoting,
e.g. (the-macro 'my-func ...) instead of (the-macro my-func ...). The
macro just plops (quote my-func) wherever it should put my-func and
boom!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote:
> I get this:
> # of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main
> \clojure:1)>
>
> A few suggestions:
> 1) An improved line number
> 2) I'd like to see the value of the Symbol
> 3) I'd like to see the three args applies to the symbol and, if the
> symbol resolves to a function, I'd like to see the arity of the
> function.
>
> Something like:
> Wrong number of args (3) passed to Symbol 'some-fn' which expects
> arity 2
This is interesting. I just checked with my copy of 1.2 and it seems
you can indeed call a symbol as a function. It appears to try to look
itself up in its first argument, the same as a keyword, and if not
found or the first argument is not a map returns the (optional) second
argument:
user=> ('+ {'+ 3 '* 4} 42)
3
user=> ('+ {'- 3 '* 4} 42)
42
Of course this is rather icky to use because of the need to quote the symbols.
So, the arity expected by a function like + ends up irrelevant. If you
invoke something on '+ it wants either one or two arguments.
If you're seeing this error you probably have a buggy macro that's not
unquoting something as many times as it should be. Quoting-depth
errors (other than forgetting to unquote something at all) seem to be
most common when writing macros that emit other macros, and ending up
with nested syntax-quoted expressions, doubled-up ~~@foo type
unquotings, and things like `(quote ~foo) in helper functions.
If the error points to a macro invocation I'd suggest inspecting the
output of (macroexpand-1 '(the-problem-invocation)) and seeing what
you get. If the output contains quoted symbols in operator position
that clearly are meant to be just normal calls to functions then
you've at least determined that the problem is caused by the macro.
Though it could be the case that your arguments to the macro violate
its preconditions. If it's not your own macro, check its
documentation. If it is it has a bug since it's not doing what you
want it to do and it's yours. If it's not it may or may not have a
bug.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
I get this:
#
A few suggestions:
1) An improved line number
2) I'd like to see the value of the Symbol
3) I'd like to see the three args applies to the symbol and, if the
symbol resolves to a function, I'd like to see the arity of the
function.
Something like:
Wrong number of args (3) passed to Symbol 'some-fn' which expects
arity 2
On Feb 25, 3:15 pm, Stuart Halloway wrote:
> > Here's one:
>
> > user=> {:a 1 :b}
> > #
>
> > Instead how about a parse error exception that specifically says
> > something like, "Map literal requires an even number of forms."
>
> > Thanks,
> > Jeff
>
> Fixed in master today:http://dev.clojure.org/jira/browse/CLJ-742
>
> Thanks!
>
> Stu
--
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
Problem establishing jdbc connection in la clojure REPL
Hi!
I'm trying to run the code snippet (see at the end) from "la
clojure"'s (IntelliJ 10.0.2) REPL but it fails with the error:
"java.sql.SQLException: JZ006: Caught IOException:
java.net.SocketException: Unrecognized Windows Sockets error: 10106:
create (test.clj:3)."
The driver's library (jConn3.jar) is in the classpath.
To see if it works at all I checked the jdbc connection string using a
java program with netbeans and it works perfectly fine. I can do
select's and retrieve the rows.
I gave it another try and ran the code via the REPL and clojure
package that ships with Stuart's "Programming Clojure" and that was
success!
So I think there is a problem with my "la clojure" REPL. Looks like
it does not allow me to establish a tcp/ip connection?
Any ideas?
- finbeu
=
(use 'clojure.contrib.sql)
(def db {:classname "com.sybase.jdbc3.jdbc.SybDriver" ; must be in
classpath
:subprotocol "sybase:Tds"
:subname "sybsrv01:4100"
; Any additional keys are passed to the driver
; as driver-specific properties.
:user "test"
:password "test12"})
(with-connection db
(with-query-results rs ["select * from external_accounts"]
(dorun (map #(println (:portfolio_id %)) rs
==
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Anyone using the sdb library?
Forgot the link: https://gist.github.com/846363
> If you have time, I posted a gist containing a data access library I built
> on top of Rich's sdb library (data.clj), and the modifications I made to his
> sdb library (sdb.clj) for consistent reads, etc. This is some of the first
> real clojure code I wrote, so not the prettiest, but maybe you can see some
> of the pain points I had using the current sdb library.
>
> To summarize:
>
> - Whether or not to add asynchronous client support
> - Not a nice generic way of building up select dsl maps
> - I believe the select dsl 'where' clause only handles up to two
> predicates
> - How to account for nil / blank values
> - Automatically sync domains with a specified list
>
> Certainly some of this belongs above the level of the sdb library, but some
> of it should be handled there.
>
> - Mark
>
>
> On Sun, Feb 27, 2011 at 9:15 AM, Gijs S. wrote:
>
>> Yes, my suggestion without type indicators in SDB would look something
>> like this:
>>
>> (def config {:sdb-client (AmazonSimpleDBClient. ...)
>> :mapping {"Link" {"url" {:encode encode-string :decode
>> decode-string}
>> "points" sdb/integer-encoding
>> "date" {:encode encode-jodadate :decode
>> decode-jodadate}}
>> "AnotherDomain" {...}})
>>
>> sdb/integer-encoding would be a library provided encoding/decoding
>> map.
>>
>> In this approach each encoding/decoding pair is defined at the level
>> of an attribute in a domain.
>>
>> A (get-attr config "Link" "id") will go through the mapping in the
>> config to create a clojure datastructure with each attr properly
>> decoded.
>>
>> A mapping map would allow for a bit more composition then one big
>> encode fn in the config where a case construct needs to be extended
>> for each attribute. For instance the mapping could be constructed like
>> this: {:mapping (merge link-domain-map another-domain-map ...)}.
>> Perhaps a library could provide a macro that expands (defdomain Link
>> [url :string, point :int, date {:encode .. :decode ..}]) into such a
>> mapping map.
>>
>> Because this approach doesn't have any type indicators in SDB, every
>> attribute needs to have an encoding/decoding defined or there needs to
>> be a default encode/decoding, which for Clojure could be print-string/
>> read-string.
>>
>> -Gijs
>>
>> --
>> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Anyone using the sdb library?
If you have time, I posted a gist containing a data access library I built
on top of Rich's sdb library (data.clj), and the modifications I made to his
sdb library (sdb.clj) for consistent reads, etc. This is some of the first
real clojure code I wrote, so not the prettiest, but maybe you can see some
of the pain points I had using the current sdb library.
To summarize:
- Whether or not to add asynchronous client support
- Not a nice generic way of building up select dsl maps
- I believe the select dsl 'where' clause only handles up to two predicates
- How to account for nil / blank values
- Automatically sync domains with a specified list
Certainly some of this belongs above the level of the sdb library, but some
of it should be handled there.
- Mark
On Sun, Feb 27, 2011 at 9:15 AM, Gijs S. wrote:
> Yes, my suggestion without type indicators in SDB would look something
> like this:
>
> (def config {:sdb-client (AmazonSimpleDBClient. ...)
> :mapping {"Link" {"url" {:encode encode-string :decode
> decode-string}
> "points" sdb/integer-encoding
> "date" {:encode encode-jodadate :decode
> decode-jodadate}}
> "AnotherDomain" {...}})
>
> sdb/integer-encoding would be a library provided encoding/decoding
> map.
>
> In this approach each encoding/decoding pair is defined at the level
> of an attribute in a domain.
>
> A (get-attr config "Link" "id") will go through the mapping in the
> config to create a clojure datastructure with each attr properly
> decoded.
>
> A mapping map would allow for a bit more composition then one big
> encode fn in the config where a case construct needs to be extended
> for each attribute. For instance the mapping could be constructed like
> this: {:mapping (merge link-domain-map another-domain-map ...)}.
> Perhaps a library could provide a macro that expands (defdomain Link
> [url :string, point :int, date {:encode .. :decode ..}]) into such a
> mapping map.
>
> Because this approach doesn't have any type indicators in SDB, every
> attribute needs to have an encoding/decoding defined or there needs to
> be a default encode/decoding, which for Clojure could be print-string/
> read-string.
>
> -Gijs
>
> --
> 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 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
CLR classpath
Hi there, I want to use ClojureCLR in a C# project I am working on and need some guidance. 1) How do I correctly add ClojureCLR as a project reference in Visual Studio (2010)? I tried adding the Clojure.dll and that allowed my code to compile fine referencing a Clojure datastructure, but at run time I then got a TypeInitializationException with inner exception complaining about not finding clojure/core.clj.dll - I was able to work around this by manually copying the clojure binary directory into my target build location; but obviously that is just a temporary solution. I think I could set up a custom build step to copy clojure from a lib directory into the build target if necessary, is that the best way? 2) I still cannot instantiate the object: PersistentTreeMap _entities = new PersistentTreeMap(); Inner exception is: "Ambiguous match found." However PersistentList foo = new PersistentList(1); works just fine, so I'm thinking that the issue how I'm calling it. Any pointers appreciated! Regards, Timothy -- 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
unchecked-divide etc being replaced in 1.3 - no more support for longs?
Hi, I just noticed that in 1.3 alpha 4, unchecked-divide (which seemed to support longs as well as ints) has been replaced by unchecked-divide- int. But there's no unchecked-divide-long, as far as I can see. This also seems to apply to the other unchecked-* math functions. Given that one of the main themes of 1.3 seems to be speed/efficiency, I'm sort of surprised by this but I might have missed something. What's the plan for fast math on longs (and floats)? Cheers, Joost. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Anyone using the sdb library?
Yes, my suggestion without type indicators in SDB would look something
like this:
(def config {:sdb-client (AmazonSimpleDBClient. ...)
:mapping {"Link" {"url" {:encode encode-string :decode
decode-string}
"points" sdb/integer-encoding
"date" {:encode encode-jodadate :decode
decode-jodadate}}
"AnotherDomain" {...}})
sdb/integer-encoding would be a library provided encoding/decoding
map.
In this approach each encoding/decoding pair is defined at the level
of an attribute in a domain.
A (get-attr config "Link" "id") will go through the mapping in the
config to create a clojure datastructure with each attr properly
decoded.
A mapping map would allow for a bit more composition then one big
encode fn in the config where a case construct needs to be extended
for each attribute. For instance the mapping could be constructed like
this: {:mapping (merge link-domain-map another-domain-map ...)}.
Perhaps a library could provide a macro that expands (defdomain Link
[url :string, point :int, date {:encode .. :decode ..}]) into such a
mapping map.
Because this approach doesn't have any type indicators in SDB, every
attribute needs to have an encoding/decoding defined or there needs to
be a default encode/decoding, which for Clojure could be print-string/
read-string.
-Gijs
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Anyone using the sdb library?
Thanks very much for the feedback!
On Feb 27, 2011, at 5:59 AM, Gijs S. wrote:
> To talk in terms of entities is perhaps too much structure for the
> simpledb.
I would agree -- although if the data one is storing in SDB is regular enough,
you should be able to build ORM-esque functionality on top of the approach I'm
proposing.
> I would suggest a way to define serialization and
> deserialization per attribute per domain in code. This would mean that
> there is no encoding of the type of an attribute in its name or value
> in the storage. get-attr and put-attr take the domain as an argument,
> which can be used to lookup the proper serialization and
> deserialization function per attribute.
>
> This approach would do away with storing type information into
> simpledb. It is also possible to provide this functionality on top of
> the existing simpledb library or the library with the suggested
> improvements.
If I'm understanding you properly, you could build this on top of the
:encode/:decode functions in the configuration object as well. I've added this
example to the design notes:
Or, if you wanted to avoid storing any type indicators in SDB, you could
explicitly map formats to attribute names (which would then be used on a
per-domain basis):
(def config {:sdb-client (AmazonSimpleDBClient. …)
:encode (fn [[k v]]
[(str k)
(case k
(:mls :asking-price) (encode-integer v)
(:address :agent-name) (str v)
:listing-date (encode-date v)
(str v))])
:decode …})
If the above is common usage, a helper function that takes a simple map of
attribute names -> value types and returns a corresponding configuration object
would be nice.
Is that what you were describing?
- Chas
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Anyone using the sdb library?
Hi,
I have dabbled a bit with both AWS SimpleDB and the sdb library as
well as with the similar Google App Engine Datastore and related
Clojure libraries.
These two parts are indeed no-brainers:
- Support for consistent reads
- Support for literal string queries
Re: numeric formatting
I am not too familiar with the details of numeric types in SimpleDB
and Clojure 1.3. Congruence between the two through usage of longs and
integers sounds good.
Re: type indicators in attribute values
Indeed this gives some troubles when using literal string queries or
using different tools and languages. The suggested move to storing
type indicators in the attribute names instead of values would improve
the usability of
literal string queries and the "LIKE" construct. Below is another
suggestion.
Re: suggestion to be able to customize how the library should
serialize and deserialize values
I have used two clojure libraries with the Google App Engine Datastore
that provide such functionality. Both libraries need an explicit
definition of an entity. They also allow the specification of a
serialization and deserialization function per attribute, for instance
with appengine-clj:
(ds/defentity Link ()
((url :key identity)
(title)
(points)
(date :serialize joda->javadate
:deserialize java->jodadate)))
The two libraries are:
appengine-clj [https://github.com/r0man/appengine-clj/]
clj-gae-datastore [https://github.com/smartrevolution/clj-gae-
datastore]
(Note that the often mentioned appengine-magic has no support for
defining how values should be serialized and deserialized in the
datastore)
To talk in terms of entities is perhaps too much structure for the
simpledb. I would suggest a way to define serialization and
deserialization per attribute per domain in code. This would mean that
there is no encoding of the type of an attribute in its name or value
in the storage. get-attr and put-attr take the domain as an argument,
which can be used to lookup the proper serialization and
deserialization function per attribute.
This approach would do away with storing type information into
simpledb. It is also possible to provide this functionality on top of
the existing simpledb library or the library with the suggested
improvements.
Finally, a (get-attr "domain" "some-id") call returns a {:sdb/id "some-
id"} map when there is no item with that id in the domain. This means
that a get-attr result can always be used a base case to merge updates
in, but I have also found cases where I would have preferred a nil
result when the item doesn't exist. I would prefer the nil returning
case as this works nicely with if-let constructs.
-Gijs
--
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
