Re: Importing and using Enum types
Thanks. That did the trick. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Toolbox (Early Beta)
Looks fantastic, this is exactly what I was thinking about when I said Clojure libraries need more discoverability. Excellent work. David On Wednesday, 23 February 2011 at 10:12 pm, semperos wrote: > Thanks for taking the time and effort to put this together. > > -Daniel > -- > 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: ANN: Clojure Toolbox (Early Beta)
Thanks for taking the time and effort to put this together. -Daniel -- 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: Release.Next Version Number
On Wed, Feb 23, 2011 at 9:23 PM, Brian Marick wrote: > > On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: > >> Thanks for the suggestions. I should say that I was only giving you my >> impression of using Clojure re: it's version number. I'm not saying any of >> the things I listed are not doable, just that they feel very ad-hoc and not >> quite ready for a "2.0". > > I agree. My gut tells me "2.0" implies promises about the ecosystem and > ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise > and overdeliver, as they say. But "1.3" may overpromise and underdeliver backward compatibility. How do you suggest we resolve this dilemma? -- 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: Release.Next Version Number
On Feb 23, 2011, at 3:06 PM, David Jacobs wrote: > Thanks for the suggestions. I should say that I was only giving you my > impression of using Clojure re: it's version number. I'm not saying any of > the things I listed are not doable, just that they feel very ad-hoc and not > quite ready for a "2.0". I agree. My gut tells me "2.0" implies promises about the ecosystem and ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise and overdeliver, as they say. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- 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: Ordering of defn's?
On Wed, Feb 23, 2011 at 4:54 PM, Alessio Stalla wrote:
> On 23 Feb, 19:51, Ken Wesson wrote:
>> Java has a lack of this top-down processing,
>
> That's not true, what do you mean?
>
> class Foo {
> void bar() { baz(); }
> void baz() {}
> }
>
> compiles fine, as well as
>
> class Foo {
> void bar() { new Baz(); }
> }
>
> class Baz {}
That's *exactly* what I mean. Java allows forward references.
>> and it sometimes causes
>> problems because the order in which static initializers will execute
>> is not generally predictable.
>
> Static initializers are executed at runtime, so this has nothing to do
> with how the compiler processes declarations.
Clojure source files are more like giant static initializers than like
compile-time Java declarations. They actively do things -- usually,
construct things and intern symbols in namespaces to refer to them
(your defs and defns). In particular, they execute at run-time.
--
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: ignore-errors
Clojure itself does not use exceptions for control flow. Java libraries sometimes do. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Distributed atom :)
Tim Dysinger did it with Hazelcast: https://github.com/dysinger/apparatus -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Transforming map entries
Reduce!
(reduce (fn [new-map [key value]] (assoc new-map ...)) {} old-map)
This is nice because you can change both keys and values, even add or remove
keys.
For something simpler:
(into {} (fn [[key value]] ... ) old-map)
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Release.Next Version Number
I don't really understand why snapshots should be in Clojars at all, yeah. It seems to me like CPAN, RubyGems, etc., encourage versioned software and not "snapshots", because they're going for non-volatile, stable packages. I think Clojars should, too. You're right, that's neither here nor there re: 2.0, though, so I guess if we want to talk about that, we can take it to another thread. David On Wed, Feb 23, 2011 at 7:01 PM, Chas Emerick wrote: > > On Feb 23, 2011, at 4:06 PM, David Jacobs wrote: >> >> > - better discovery for existing, well-tested libraries. >> >> You can search on http://clojars.org/. This works well for me. >> However, the key to well tested libraries is having people give >> feedback if a library breaks or is badly documented or doesn't meet >> their needs. > > To me, Clojars is not the most discoverable interface in the world, though I > do appreciate that it exists. It doesn't have download counts or any other > sort of quality indicator. What's more, some entries are domain-qualified and > others aren't, and it's hard to know exactly what I'm getting when I install > any package from Clojars. > > I've never quite understood the criticism that it's difficult to find Clojure > libraries -- perhaps because I came primarily from the Java and Python > worlds, both of which share the same library-discovery mechanism (i.e. > Google). > That said, of course it'd be great to have a top-notch directory (and it > looks like various people are working on that). In any case, this isn't > relevant to the language's versioning. > > Side question (also relating to the ecosystem feeling rough), what's with all > the "SNAPSHOT"s on Clojars? > > Clojars provides only one repository, where both SNAPSHOTs and releases are > deployed. AFAICT, few people understand what SNAPSHOT implies, and the > importance of having sane releases (i.e. a non-SNAPSHOT version as well as > having no transitive SNAPSHOT-versioned dependencies). It's an unfortunate > state of affairs. > Cheers, > - Chas > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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: Release.Next Version Number
On Feb 23, 2011, at 4:06 PM, David Jacobs wrote: > > - better discovery for existing, well-tested libraries. > > You can search on http://clojars.org/. This works well for me. > However, the key to well tested libraries is having people give > feedback if a library breaks or is badly documented or doesn't meet > their needs. > > To me, Clojars is not the most discoverable interface in the world, though I > do appreciate that it exists. It doesn't have download counts or any other > sort of quality indicator. What's more, some entries are domain-qualified and > others aren't, and it's hard to know exactly what I'm getting when I install > any package from Clojars. I've never quite understood the criticism that it's difficult to find Clojure libraries -- perhaps because I came primarily from the Java and Python worlds, both of which share the same library-discovery mechanism (i.e. Google). That said, of course it'd be great to have a top-notch directory (and it looks like various people are working on that). In any case, this isn't relevant to the language's versioning. > Side question (also relating to the ecosystem feeling rough), what's with all > the "SNAPSHOT"s on Clojars? Clojars provides only one repository, where both SNAPSHOTs and releases are deployed. AFAICT, few people understand what SNAPSHOT implies, and the importance of having sane releases (i.e. a non-SNAPSHOT version as well as having no transitive SNAPSHOT-versioned dependencies). It's an unfortunate state of affairs. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Clojure Toolbox (Early Beta)
On 23 February 2011 23:37, Sam Aaron wrote: > How about a Music & Sound Synthesis section with a pointer to Overtone? 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: ANN: Clojure Toolbox (Early Beta)
James Reeves wrote: I'm sure I've covered only a very small proportion of Clojure libraries out there, so if you'd like to suggest a project that's not on there, please do so in this thread, or in an email to me. I'll try and update the site as quickly as possible. How about a Music & Sound Synthesis section with a pointer to Overtone? https://github.com/overtone/overtone/ Sam --- http://sam.aaron.name -- 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 Toolbox (Early Beta)
I've put together a small, static site inspired by The Ruby Toolbox (ruby-toolbox.com), called (of course) The Clojure Toolbox. It's currently just a series of categorized links to Clojure projects, but I'll be gradually adding more functionality to it over the coming weeks. If you've been to the Ruby Toolbox site you'll likely know what to expect (project descriptions, links to Clojars, GitHub watchers and forks, etc.) The URL to the site is: http://www.clojure-toolbox.com I'm sure I've covered only a very small proportion of Clojure libraries out there, so if you'd like to suggest a project that's not on there, please do so in this thread, or in an email to me. I'll try and update the site as quickly as possible. - 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: Release.Next Version Number
>> - better discovery for existing, well-tested libraries. > > You can search on http://clojars.org/. This works well for me. > However, the key to well tested libraries is having people give > feedback if a library breaks or is badly documented or doesn't meet > their needs. I'm currently working on something that might help fill this space. It's not yet complete and shouldn't be used except for testing at this stage. http://clojure-libraries.appspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Release.Next Version Number
I don't have a strong opinion about the version number but I want to say that David's critiques of the state of the ecosystem all ring true to me. FWIW (and I offer this only because Saul is "genuinely interested in how they don't meet your needs" :-) here are my own responses to David's suggestions/questions about Saul's critiques: On Feb 23, 2011, at 2:58 PM, Saul Hazledine wrote: > Below are suggestions to the shortcomings you mention. I'm genuinely > interested in how they don't meet your needs. > > On Feb 23, 8:42 pm, David Jacobs > wrote: >> - definitive, simple, integrated package management > Leiningen and Cake? Both seem great but neither plays nice with an editor/IDE/workflow that works well for me. Eclipse/CCW is my current favorite and while there are ways to use lein in conjunction with Eclipse projects they are seriously non-intuitive. I was initially very excited about TextMate/cake but some basic things failed to work and my posted issue on the textmate-clojure github site got no reply so I cooled on this and went back to Eclipse/CCW. I'm a long-time emacs user but the installation/configuration issues are infuriating, especially in a teaching context (which is important for me), as are some of the decades-old UI conventions. > >> - a better REPL experience out of the box (esp. Jline support) > Slime/Emacs? I only use the REPL in very rare cases and aren't > bothered by a lack of JLine. See above. I'm looking for a non-emacs solution (or maybe I'd be happy with a fail-proof simple Aquamacs-for-clojure single-click-download+installer). I use REPLs all the time and want them to have basic features like parentheses matching, language-aware indentation, and the ability to scroll through history. > >> - a simpler, more useful stack trace > Slime? See above. > >> - better commandline integration > > https://github.com/gar3thjon3s/clargon Not actually a concern of mine. > >> - abstracting away Java concepts like excessive hierarchies for package >> definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) > > You don't have to use this convention. Personally I keep things > shallow. Some tools force or strongly encourage such conventions (and they vary among tools). If I recall correctly NetBeans/Enclojure uses fairly deep hierarchies. Eclipse's are shallower, I think, and the default for new projects in cake is somewhere in between. I gather that keeping things completely flat is somehow impossible or bad in the Java ecosystem in general, but the variation among all of the popular tools is indeed bothersome. >> - better discovery for existing, well-tested libraries. > > You can search on http://clojars.org/. This works well for me. > However, the key to well tested libraries is having people give > feedback if a library breaks or is badly documented or doesn't meet > their needs. I'm still surprised sometimes even by things that are in core or contrib that I hadn't seen previously. Clojure.org doesn't help much with this, in my experience. I've found some of the newer documentation sites (like http://clojuredocs.org/) to be quite good but again this is sort of scattered, with a bunch of things of different levels of completeness and quality and not a lot of guidance to the newcomer about where to go to get oriented. If this situation could be firmed up for core+contrib, and then expanded to other libraries, then that would be fantastic. Just my e cents or so. -Lee -- 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: Release.Next Version Number
> > I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is > definitely colored. > It seems to me like (most) of the things you are talking about are not core language specific things. In particular for package management Ruby uses Rubygems which is a separate project, and just recently Bundler for dependency management. To me these things have no impact on the language and shouldn't keep the language from moving forward in a version numbering sense. I do agree that they should mature though. > Three problems with the REPL: > > 1. The standard way Clojure tells me to get a REPL is using the java > command. This makes Clojure not feel like a first-class language. > Agreed, there is a ticket for this in JIRA. > > 2. Once I do get a REPL, either through the java or lein or cljr commands, > it has no indentation or Jline support. It feels messy. > >From what I have seen most people aren't using the bare REPL or lein repl, but the experience could be better. > > 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I > don't want to have to use a specific editor in order to use the language of > my choice.) > Sorry if you are already aware of this, but there is a vim plugin for slime that I have heard good things about. > > >> > - better discovery for existing, well-tested libraries. >> > Well tested is completely a matter of opinion and is another one of those things that doesn't seem like a reason to hold back a "2.0". > As I say, I really enjoy coding in Clojure, but the process surrounding > coding is not always very polished. I see too much Java and not quite enough > integration to think of it as a "2.0" yet, though I do think we can get > there. > I can completely understand what you mean after coming from the Ruby world where there has been a ton of effort spent on making the development experience better. I think we can take a lot away from what Ruby has done. Two of the Clojure/core team members (Stuart Halloway and me) also came from Ruby and spent quite a bit of time helping make it better while we were there. I do want to make sure that the things we think about when calling a release 2.0 factor more into what has changed since the last release. This would be both how much has changed, and how many breaking changes have occurred. I don't want to dismiss what you have brought up though because I think they are all really important for the adoption of the language going forward. Cheers. Aaron -- Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Ordering of defn's?
On 23 Feb, 19:51, Ken Wesson wrote:
> Java has a lack of this top-down processing,
That's not true, what do you mean?
class Foo {
void bar() { baz(); }
void baz() {}
}
compiles fine, as well as
class Foo {
void bar() { new Baz(); }
}
class Baz {}
> and it sometimes causes
> problems because the order in which static initializers will execute
> is not generally predictable.
Static initializers are executed at runtime, so this has nothing to do
with how the compiler processes declarations.
--
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: Ordering of defn's?
On Wed, Feb 23, 2011 at 3:12 PM, Jonathan Mitchem wrote: > I know it sounds like a finicky, minor issue, but it is actually that > important to me. It's not rejection to change, inasmuch as > unwillingness to intentionally make my life harder. > Consider how macros immediately affect the compilation of later forms. Consider Clojure's take on macro hygiene. 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
Re: Release.Next Version Number
Hi Saul, Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a "2.0". I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is definitely colored. > - definitive, simple, integrated package management > Leiningen and Cake? I use leiningen and cljr for package management, depending on whether I'm working on a discrete project or on a script/quick hack/toy program. These tools are great, and I don't want to diminish the amount of effort that's gone into them. However, the whole process of getting package management working is a barrier to entry to Clojure. Getting package management up and running requires too many steps. I think that Clojure should come with a default executable that can take care of package management and start a REPL (loading all global packages into the classpath). Integrating leiningen into Clojure packages would give this definitive experience that new users are looking for when they try to get up and running. > > - a better REPL experience out of the box (esp. Jline support) > Slime/Emacs? I only use the REPL in very rare cases and aren't > bothered by a lack of JLine. > > - a simpler, more useful stack trace Slime? Three problems with the REPL: 1. The standard way Clojure tells me to get a REPL is using the java command. This makes Clojure not feel like a first-class language. 2. Once I do get a REPL, either through the java or lein or cljr commands, it has no indentation or Jline support. It feels messy. 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I don't want to have to use a specific editor in order to use the language of my choice.) > - better commandline integration > > https://github.com/gar3thjon3s/clargon I'll give this a look. In general, I think we need a way to write Clojure scripts so that they are directly executable (perhaps via a shebang directive at the top of our script). > > - abstracting away Java concepts like excessive hierarchies for package > > definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) > > You don't have to use this convention. Personally I keep things > shallow. > You're right, but a lot of people do (even clojure.contrib does), which makes browsing Clojure source code feel rough. > > - better discovery for existing, well-tested libraries. > > You can search on http://clojars.org/. This works well for me. > However, the key to well tested libraries is having people give > feedback if a library breaks or is badly documented or doesn't meet > their needs. > To me, Clojars is not the most discoverable interface in the world, though I do appreciate that it exists. It doesn't have download counts or any other sort of quality indicator. What's more, some entries are domain-qualified and others aren't, and it's hard to know exactly what I'm getting when I install any package from Clojars. Side question (also relating to the ecosystem feeling rough), what's with all the "SNAPSHOT"s on Clojars? As I say, I really enjoy coding in Clojure, but the process surrounding coding is not always very polished. I see too much Java and not quite enough integration to think of it as a "2.0" yet, though I do think we can get there. I'm open-minded about this take, though. Maybe I just don't have a solid enough setup on my machine yet. (But should it really take that much effort?) 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
Re: java.lang.Exception: transaction rolled back: java.lang.InterruptedException
On Feb 23, 9:54 pm, clj123 wrote: > I'm getting the following exception trying to insert large batch data > in the database. I'd try to write less data at one time to the database. Start with, say, 20 rows at a time. Saul -- 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: transaction rolled back: java.lang.InterruptedException
On Feb 23, 9:42 pm, clj123 wrote: > I have been getting this exception: > java.lang.Exception: transaction rolled back: > java.lang.InterruptedException > at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj: > 142) I can only take some wild guesses I'm afraid. The rollback occurs because clojure.contrib.sql tends to wrap operations in transactions. It appears that an InteruptedException occured during an operation and this called the rollback. Wild guesses: 1. The app is trying to write lots of data and a timeout has occured. 2. The database is busy and a timeout has occured. Saul -- 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
java.lang.Exception: transaction rolled back: java.lang.InterruptedException
I'm getting the following exception trying to insert large batch data in the database. Any ideas? java.lang.Exception: transaction rolled back: java.lang.InterruptedException at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj: 142) at clojure.contrib.sql.internal$transaction_STAR_.invoke(internal.clj: 169) at com.prototype.commonUtil$persist_data $fn__2297.invoke(commonUtil.clj:86) at clojure.contrib.sql.internal $with_connection_STAR_.invoke(internal.clj:105) at com.prototype.commonUtil$persist_data.invoke(commonUtil.clj:85) (defn insert-table-entry-multi [table-name col-names & values] (apply insert-values table-name col-names values)) (defn persist-data [rows table-name column-names] (clojure.contrib.sql/with-connection *db* ;commonUtil.clj: 85 (clojure.contrib.sql/transaction ;commonUtil.clj: 86 (try (apply insert-table-entry-multi table-name column-names rows) Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
transaction rolled back: java.lang.InterruptedException
I have been getting this exception: java.lang.Exception: transaction rolled back: java.lang.InterruptedException at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj: 142) at clojure.contrib.sql.internal$transaction_STAR_.invoke(internal.clj: 169) at com.prototype.commonUtil$persist_data $fn__2292.invoke(commonUtil.clj:76) at clojure.contrib.sql.internal $with_connection_STAR_.invoke(internal.clj:105) at com.prototype.commonUtil$persist_data.invoke(commonUtil.clj:76) -- 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
transaction rolled back: java.lang.InterruptedException
I have been getting this exception: java.lang.Exception: transaction rolled back: java.lang.InterruptedException at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj: 142) at clojure.contrib.sql.internal$transaction_STAR_.invoke(internal.clj: 169) at com.prototype.commonUtil$persist_data $fn__2292.invoke(commonUtil.clj:76) at clojure.contrib.sql.internal $with_connection_STAR_.invoke(internal.clj:105) at com.prototype.commonUtil$persist_data.invoke(commonUtil.clj:76) -- 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: Clojure namespace conventions
This discussion has been had multiple times on this list, not sure how much new information you will get. See the following for a couple examples: http://groups.google.com/group/clojure/browse_thread/thread/968e9066223c3a2b/fbce84869dbf4ce6?lnk=gst# http://groups.google.com/group/clojure/browse_thread/thread/78a32eeaacd659e/89304aeec4d00f7d?lnk=gst# On Wed, Feb 23, 2011 at 3:19 PM, Paul Richards wrote: > Hi, > Is there a guide to the conventions for naming and structuring > namespaces in a Clojure project? > > I see for example that the ".core" namespace is fairly common in > different projects. Is this also where the "-main" entry point should > live? > > Also is it typical to have code living in "someproject" as well as > "someproject.tools", or should the former be promoted to > "someproject.core"? > > > -- > Paul Richards > @pauldoo > > -- > 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
Clojure namespace conventions
Hi, Is there a guide to the conventions for naming and structuring namespaces in a Clojure project? I see for example that the ".core" namespace is fairly common in different projects. Is this also where the "-main" entry point should live? Also is it typical to have code living in "someproject" as well as "someproject.tools", or should the former be promoted to "someproject.core"? -- Paul Richards @pauldoo -- 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: Ordering of defn's?
On Wed, Feb 23, 2011 at 3:12 PM, Jonathan Mitchem wrote: >> Java has a lack of this top-down processing, and it sometimes causes >> problems because the order in which static initializers will execute >> is not generally predictable. > > If you're programming with a side-effect free functional approach, > that shouldn't be a problem right? No program is truly side-effect free, though, and initialization is precisely one of the areas likely to have a few side effects. -- 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: Ordering of defn's?
> Java has a lack of this top-down processing, and it sometimes causes > problems because the order in which static initializers will execute > is not generally predictable. If you're programming with a side-effect free functional approach, that shouldn't be a problem right? Or are you saying that you can have one static initializer be calculated off the value of another that hasn't been executed yet, and then blow up during compile? (I don't think C# lets you have any dependencies in static initializers; all those have to be expressed in a static constructor. I could be wrong.) > I prefer to define my terms (simpler functions) before I use > them (in more complex functions) anyway. It helps me organize my > thoughts and my design, too, as I need to think first about what > something will be built out of -- what are the basic data > representations and the fundamental operations on these? I tend to work from a different side. iteration 1: (display-winning-stocks) iteration 2: (display-stocks (pick-winning-stocks (analyze-stocks (download-stock-data And then I'll flesh out each of those functions, creating more helper functions as I progressively break down the problem. iteration 3 - just the download-stock-data function (aggregate-results (download-from-urls (get-stock-urls (get-list-of-stocks Having to "interrupt my flow" to add declares at the top, or just reorder the functions isn't quite what I'm looking for. It's entirely personal preference sure, but it's a significant obstacle hearing that, effectively "no, the language won't work the way you program best, and it's not going to change, so you might as well stick with what already works for you or look for something else." I know it sounds like a finicky, minor issue, but it is actually that important to me. It's not rejection to change, inasmuch as unwillingness to intentionally make my life harder. On Feb 23, 1:51 pm, Ken Wesson wrote: > Java has a lack of this top-down processing, and it sometimes causes > problems because the order in which static initializers will execute > is not generally predictable. > > I don't have any problems with Clojure files being processed from the > top down. I prefer to define my terms (simpler functions) before I use > them (in more complex functions) anyway. It helps me organize my > thoughts and my design, too, as I need to think first about what > something will be built out of -- what are the basic data > representations and the fundamental operations on these? If I think of > more later I can always scroll up and add them. -- 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: Release.Next Version Number
Below are suggestions to the shortcomings you mention. I'm genuinely interested in how they don't meet your needs. On Feb 23, 8:42 pm, David Jacobs wrote: > - definitive, simple, integrated package management Leiningen and Cake? > - a better REPL experience out of the box (esp. Jline support) Slime/Emacs? I only use the REPL in very rare cases and aren't bothered by a lack of JLine. > - a simpler, more useful stack trace Slime? > - better commandline integration https://github.com/gar3thjon3s/clargon > - abstracting away Java concepts like excessive hierarchies for package > definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) You don't have to use this convention. Personally I keep things shallow. > - better discovery for existing, well-tested libraries. You can search on http://clojars.org/. This works well for me. However, the key to well tested libraries is having people give feedback if a library breaks or is badly documented or doesn't meet their needs. Saul -- 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: Release.Next Version Number
If we want to practice semantic versioning[0] and the next iteration is introducing backwards-incompatible changes, we should go with 2.0. However, I have my reservations. Clojure itself feels solid to code with, but the *ecosystem* doesn't feel very 2.0. For that it would need: - definitive, simple, integrated package management - a better REPL experience out of the box (esp. Jline support) - a simpler, more useful stack trace - better commandline integration - abstracting away Java concepts like excessive hierarchies for package definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) - better discovery for existing, well-tested libraries. [0] http://semver.org/ Those, for me, are the rough edges of Clojure, the ones that aggravate me at times. They don't have as much to do with the language itself as with the ecosystem, so I'm okay calling a new version of the language "2.0". Just my $0.02. David Jacobs On Wed, Feb 23, 2011 at 11:18 AM, Lärry wrote: > Gang - > > I'm still in the "playing" stage with the language. I'm exploring > Clojure and > prototyping ideas for future directions. The language is very > expressive and > its community is quite supportive. > > One thing the environment lacks is a good, current book for > beginners. Oh, > there are a couple of good books out there. The problem is that the > books are > out-dated, because they are based on versions 1.0 or 1.1. This means > that the > language needs to be rich enough and we need to settle on a "standard" > platform > and stick with it long enough for the writers to catch up. (This > doesn't mean > stagnation. Please don't let Clojure 2.0 become the end of the line - > like > "Java 2".) > > Version 2.0 of any product usually signifies a "coming-of-age", where > it is > ready for prime-time, ready to become THE solution for a certain set > of > problems. If we believe that the next release of Clojure will be the > platform > for the next stage of growth, then I'm all for calling it 2.0. If > it's just a > stepping-stone, call it 1.3. > > The other thing the environment needs is a "killer app". But that's a > different > thread... > > > - Larry > > -- > 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: Ordering of defn's?
A related problem occurs when you separate your code into multiple namespaces. You can't create cyclic links with use or require. There's a case to be made for avoiding that situation, but the solution clojure provides when you need it is to import the vars using ns-resolve as in (def myfn (ns-resolve 'com.foo.bar.mylib 'myfn)) On Tue, Feb 22, 2011 at 1:05 AM, Jonathan Mitchem wrote: > I'm new to Lisps in general, and very new to Clojure. > > When I was trying out CL, I could put my "defun/defn"s in any order in > the file, and it would load and run fine in the REPL. However, in > Clojure, it seems to be much more C/C++-like and I have to define > things before I use them in other defns. > > Is this... correct? Or is it just a limitation of the IDEs I've been > trying out? > > > E.g., it seems like I have to define "sum" before I can define > "average". > > -- > 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: Release.Next Version Number
Gang - I'm still in the "playing" stage with the language. I'm exploring Clojure and prototyping ideas for future directions. The language is very expressive and its community is quite supportive. One thing the environment lacks is a good, current book for beginners. Oh, there are a couple of good books out there. The problem is that the books are out-dated, because they are based on versions 1.0 or 1.1. This means that the language needs to be rich enough and we need to settle on a "standard" platform and stick with it long enough for the writers to catch up. (This doesn't mean stagnation. Please don't let Clojure 2.0 become the end of the line - like "Java 2".) Version 2.0 of any product usually signifies a "coming-of-age", where it is ready for prime-time, ready to become THE solution for a certain set of problems. If we believe that the next release of Clojure will be the platform for the next stage of growth, then I'm all for calling it 2.0. If it's just a stepping-stone, call it 1.3. The other thing the environment needs is a "killer app". But that's a different thread... - Larry -- 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: Ordering of defn's?
Java has a lack of this top-down processing, and it sometimes causes problems because the order in which static initializers will execute is not generally predictable. I don't have any problems with Clojure files being processed from the top down. I prefer to define my terms (simpler functions) before I use them (in more complex functions) anyway. It helps me organize my thoughts and my design, too, as I need to think first about what something will be built out of -- what are the basic data representations and the fundamental operations on these? If I think of more later I can always scroll up and add them. -- 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: Ordering of defn's?
With C# inside of Visual Studio, I have very good IDE support for top-
down design. If I use an undeclared method, it is displayed in red,
with a tooltip saying "Cannot resolve symbol '[symbol name]'". A
context menu provides me "generate > method stub", which will do what
it says, and add parameter names based on how I use it, and use type
inference.
E.g., if what I typed was "string name = GetName( enumType, value );"
it can generate "private string GetName( Type enumType, MyEnum value)
{ throw NotImplementedException(); }"
It's an oft-used feature for me, but in particular, that's an IDE
feature, not a language feature.
More importantly, I haven't had to deal with declaration order being a
limitation in a language since C++. It feels... backwards to me, if
it's by design.
I'm aware that a lot of the problems can be reduced with IDE support,
indexing symbols and such, but I haven't seen it yet. Fortunately
parsing clojure seems very straightforward, so that may be a feasible
option.
Secondly, thanks to everyone for pointing out that you _can_ use
"declare". It's a solution for now.
On Feb 23, 1:20 pm, Alessio Stalla wrote:
> On 23 Feb, 01:28, Mark Engelberg wrote:
>
> > I'm not crazy about this behavior either, but my understanding is that
> > this is an intentional design decision that is a direct consequence of
> > two things:
> > 1. In Clojure IDEs, people want to be able to feed the compiler
> > single functions and expressions. You don't need to compile the
> > entire file all at once; this can be useful for making small
> > modifications to a running system. For consistency, compiling the
> > entire file is just like feeding the functions into the compiler one
> > by one. There's no special "lookahead" for compiling a file in its
> > entirety.
>
> That's the same for Common Lisp.
>
> > 2. Without lookahead, declarations are the only way to allow the
> > compiler to give an intelligent error message if you accidentally
> > refer to a function name that does not exist. People want good error
> > messages.
>
> Doesn't make sense. If the compiler can recognize that a function is
> not defined (and it can, since it signals an error), then it can
> signal a meaningful error or even better a warning (e.g., "call to
> unknown function FOO"). To have the function declaration beforehand is
> necessary only when you want to do some optimizations based on the
> type of the function or other properties (e.g. if the function is
> declared inline).
> I don't know why Clojure requires declare, but certainly it looks like
> an unnecessary limitation from someone coming from Common Lisp.
>
> Cheers,
> Alessio
--
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: Ordering of defn's?
On 23 Feb, 01:28, Mark Engelberg wrote: > I'm not crazy about this behavior either, but my understanding is that > this is an intentional design decision that is a direct consequence of > two things: > 1. In Clojure IDEs, people want to be able to feed the compiler > single functions and expressions. You don't need to compile the > entire file all at once; this can be useful for making small > modifications to a running system. For consistency, compiling the > entire file is just like feeding the functions into the compiler one > by one. There's no special "lookahead" for compiling a file in its > entirety. That's the same for Common Lisp. > 2. Without lookahead, declarations are the only way to allow the > compiler to give an intelligent error message if you accidentally > refer to a function name that does not exist. People want good error > messages. Doesn't make sense. If the compiler can recognize that a function is not defined (and it can, since it signals an error), then it can signal a meaningful error or even better a warning (e.g., "call to unknown function FOO"). To have the function declaration beforehand is necessary only when you want to do some optimizations based on the type of the function or other properties (e.g. if the function is declared inline). I don't know why Clojure requires declare, but certainly it looks like an unnecessary limitation from someone coming from Common Lisp. Cheers, Alessio -- 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: Ordering of defn's?
On Feb 22, 2011, at 6:28 PM, Jonathan Mitchem wrote: > It just seems to interrupt my flow when coding. Maybe that's not a > legitimate enough concern, but coming from first principles, that > seems to be one of the fundamental gains of Clojure. This annoys me as well. I made an Emacs macro that puts the symbol under the cursor in what amounts to a `declare` form. It's in here: https://github.com/marick/Midje/blob/master/emacs/midje-mode.el Look for midje-add-identifier-to-unfinished-list Also: I've gone to some trouble to support a top-down(ish) style of programming in Clojure. If that's a style you like, you may be interested in this: http://www.vimeo.com/19404746 - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- 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: Transforming map entries
That is true. Thank you for the reminder. On Feb 23, 10:18 am, Laurent PETIT wrote: > 2011/2/23 Benny Tsai > > > My guess is that Clojure's fmap behaves that way because it is modeled > > Note that it's not "Clojure's fmap". > fmap is a function in a clojure contrib namespace. > > The distinction may be important. -- 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: Transforming map entries
On Wed, Feb 23, 2011 at 11:55 AM, Benny Tsai wrote:
> My guess is that Clojure's fmap behaves that way because it is modeled
> after Haskell's fmap
Hmm, I thought it might be a Haskell thing.
> To pass both keys and values to your transforming function, I think
> Alan's idea of using 'walk' is the best:
>
> (use '[clojure.walk :only (walk)])
>
> (def my-map {:first "john" :last "smith" :age 25})
>
> (defn my-fn [[key value]]
> (if (string? value)
> [key (.toUpperCase value)]
> [key value]))
>
> user=> (walk my-fn identity my-map)
> {:first "JOHN", :last "SMITH", :age 25}
That looks pretty nice. I'll give that a shot, thanks.
>
> On Feb 23, 6:27 am, Chris Maier wrote:
>> Can anybody explain why fmap, when operating on an IPersistentMap,
>> only passes the function the value of the map entry, instead of the
>> entire map entry (i.e., the key and value pair)? It seems a bit odd
>> in that all the other implementations of fmap operate on the entire
>> item in the sequence. Also, I can imagine cases where you'd want to
>> do some map transformation that also depends on the key (do something
>> for entries A, B, and C, but something else for entries X, Y, and Z).
>>
>> I suppose I could use remove-method and then write my own fmap
>> implementation for IPersistentMap. I'm curious about the design,
>> though.
>>
>> Thanks,
>> Chris
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 22, 2011 at 6:56 PM, Benny Tsai wrote:
>> > There is fmap from clojure.contrib.generic.functor, which expects a
>> > function of arity 1, for just the value:
>>
>> > (use 'clojure.contrib.generic.functor)
>> > (require '[clojure.string :as str])
>>
>> > (def my-map {:first "john" :last "smith" :age 25})
>>
>> > (defn my-fn [value]
>> > (if (string? value)
>> > (str/upper-case value)
>> > value))
>>
>> > user=> (fmap my-fn my-map)
>> > {:first "JOHN", :last "SMITH", :age 25}
>>
>> > On Feb 22, 4:23 pm, rob levy wrote:
>> >> The usual intuitive options for this are reduce, zipmap, or into. You can
>> >> also write a lazily recursive solution. I wonder why there's no function
>> >> in
>> >> core that lazily re-constructs the map with the results of the function?
>> >> It
>> >> seems to have been discussed on the list at least once or twice. It seems
>> >> like there would have to be two versions of it, one expecting a function
>> >> with an arity of one (for just the value) and another expecting an arity
>> >> of
>> >> two (key and value).
>>
>> >> On Mon, Feb 21, 2011 at 10:08 PM, yair wrote:
>> >> > I'm hoping this is a dumb question and I've missed something obvious.
>> >> > I have a map with various key-value pairs and I want to transform some
>> >> > of the values, e.g.
>>
>> >> > (def mymap {:first "john" :last "smith" :age 25}) and say I want to
>> >> > change the strings to be upper case.
>> >> > Right now all I can think of doing is using reduce and passing in an
>> >> > empty map and the re-associating each key with the (possibly)
>> >> > transformed value. Is there something like the map function that
>> >> > takes two parameters, one a function that receives a pair and returns
>> >> > a new pair, and the other a map, and returns a map that's
>> >> > reconstituted from those pairs?
>>
>> >> > Thanks
>>
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Clojure" group.
>> >> > To post to this group, send email to clojure@googlegroups.com
>> >> > Note that posts from new members are moderated - please be patient with
>> >> > your first post.
>> >> > To unsubscribe from this group, send email to
>> >> > clojure+unsubscr...@googlegroups.com
>> >> > For more options, visit this group at
>> >> >http://groups.google.com/group/clojure?hl=en
>>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To 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
--
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, v
Re: Transforming map entries
2011/2/23 Benny Tsai > My guess is that Clojure's fmap behaves that way because it is modeled > Note that it's not "Clojure's fmap". fmap is a function in a clojure contrib namespace. The distinction may be important. -- 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: Bandalore, a Clojure client library for Amazon’s Simple Queue Service (SQS)
"I recently found myself wanting to work with Amazon’s Simple Queue Service (SQS), but I could find no reasonable Clojure library for accessing it. Of course, AWS’ own Java SDK is the canonical implementation of their APIs (at least in the JVM space), so putting together a Clojure wrapper that adds a few handy extras wasn’t particularly difficult." - http://cemerick.com/2011/02/18/bandalore-a-clojure-client-library-for-amazons-simple-queue-service-sqs/ The code is on github: https://github.com/cemerick/bandalore v0.0.1 is now in Maven central. See the README on the github page for Maven/lein/gradle coordinates. Questions and feedback are welcome. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Importing and using Enum types
> The name of the Enum Class is (Unfortunately) IContainer.Type that lives in > com.xuggle.xuggler package. > I believe it is the dot within the IContainer.Type class name that is giving > me headache. > > I'd appreciate any input or work around that I am not aware of. Try IContainer$Type/READ and IContainer$Type/WRITE Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Transforming map entries
My guess is that Clojure's fmap behaves that way because it is modeled
after Haskell's fmap, which only accepts functions that operate only
on the values due to the way fmap (and the Functor typeclass that fmap
belongs to) is modeled in Haskell's type system.
To pass both keys and values to your transforming function, I think
Alan's idea of using 'walk' is the best:
(use '[clojure.walk :only (walk)])
(def my-map {:first "john" :last "smith" :age 25})
(defn my-fn [[key value]]
(if (string? value)
[key (.toUpperCase value)]
[key value]))
user=> (walk my-fn identity my-map)
{:first "JOHN", :last "SMITH", :age 25}
On Feb 23, 6:27 am, Chris Maier wrote:
> Can anybody explain why fmap, when operating on an IPersistentMap,
> only passes the function the value of the map entry, instead of the
> entire map entry (i.e., the key and value pair)? It seems a bit odd
> in that all the other implementations of fmap operate on the entire
> item in the sequence. Also, I can imagine cases where you'd want to
> do some map transformation that also depends on the key (do something
> for entries A, B, and C, but something else for entries X, Y, and Z).
>
> I suppose I could use remove-method and then write my own fmap
> implementation for IPersistentMap. I'm curious about the design,
> though.
>
> Thanks,
> Chris
>
>
>
>
>
>
>
> On Tue, Feb 22, 2011 at 6:56 PM, Benny Tsai wrote:
> > There is fmap from clojure.contrib.generic.functor, which expects a
> > function of arity 1, for just the value:
>
> > (use 'clojure.contrib.generic.functor)
> > (require '[clojure.string :as str])
>
> > (def my-map {:first "john" :last "smith" :age 25})
>
> > (defn my-fn [value]
> > (if (string? value)
> > (str/upper-case value)
> > value))
>
> > user=> (fmap my-fn my-map)
> > {:first "JOHN", :last "SMITH", :age 25}
>
> > On Feb 22, 4:23 pm, rob levy wrote:
> >> The usual intuitive options for this are reduce, zipmap, or into. You can
> >> also write a lazily recursive solution. I wonder why there's no function
> >> in
> >> core that lazily re-constructs the map with the results of the function?
> >> It
> >> seems to have been discussed on the list at least once or twice. It seems
> >> like there would have to be two versions of it, one expecting a function
> >> with an arity of one (for just the value) and another expecting an arity of
> >> two (key and value).
>
> >> On Mon, Feb 21, 2011 at 10:08 PM, yair wrote:
> >> > I'm hoping this is a dumb question and I've missed something obvious.
> >> > I have a map with various key-value pairs and I want to transform some
> >> > of the values, e.g.
>
> >> > (def mymap {:first "john" :last "smith" :age 25}) and say I want to
> >> > change the strings to be upper case.
> >> > Right now all I can think of doing is using reduce and passing in an
> >> > empty map and the re-associating each key with the (possibly)
> >> > transformed value. Is there something like the map function that
> >> > takes two parameters, one a function that receives a pair and returns
> >> > a new pair, and the other a map, and returns a map that's
> >> > reconstituted from those pairs?
>
> >> > Thanks
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient with
> >> > your first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> >http://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To 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: Importing and using Enum types
Thanks Ken. I was able to use enums before as you have suggested but here is the specific issue: The name of the Enum Class is (Unfortunately) IContainer.Type that lives in com.xuggle.xuggler package. I believe it is the dot within the IContainer.Type class name that is giving me headache. I'd appreciate any input or work around that I am not aware of. -K -- 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: Transforming map entries
And at the underkill end of the spectrum :) (comp #(.toUpperCase %) mymap) (Seriously: might be feasible of you don't need the map properties afterwards...) Sincerely Meikel -- 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: Transforming map entries
Perhaps this is an overkill, but it comes to my mind :) (I'm new to clojure)
user=> (def mymap {:a (ref "foo") :b (ref "bar")})
#'user/mymap
user=> mymap
{:a #, :b #}
user=> (map #(dosync (ref-set %1 (repeat 2 (deref %1 (vals mymap))
(("foo" "foo") ("bar" "bar"))
user=> mymap
{:a #, :b #}
Stanislav Paskalev
On Wed, Feb 23, 2011 at 1:27 AM, Nurullah Akkaya wrote:
> You can use map to get your new sequence of pairs, the turn it into a
> hash-map using into,
>
> (->> {:first "john" :last "smith" :age 25}
> (map #(let [[k v] %]
> (if (string? v)
> [k (.toUpperCase v)] [k v])))
> (into {}))
>
> Best,
> --
> Nurullah Akkaya
> http://nakkaya.com
> On Tuesday, February 22, 2011 at 5:08 AM, yair wrote:
>> I'm hoping this is a dumb question and I've missed something obvious.
>> I have a map with various key-value pairs and I want to transform some
>> of the values, e.g.
>>
>> (def mymap {:first "john" :last "smith" :age 25}) and say I want to
>> change the strings to be upper case.
>> Right now all I can think of doing is using reduce and passing in an
>> empty map and the re-associating each key with the (possibly)
>> transformed value. Is there something like the map function that
>> takes two parameters, one a function that receives a pair and returns
>> a new pair, and the other a map, and returns a map that's
>> reconstituted from those pairs?
>>
>> Thanks
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To 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: Transforming map entries
Can anybody explain why fmap, when operating on an IPersistentMap,
only passes the function the value of the map entry, instead of the
entire map entry (i.e., the key and value pair)? It seems a bit odd
in that all the other implementations of fmap operate on the entire
item in the sequence. Also, I can imagine cases where you'd want to
do some map transformation that also depends on the key (do something
for entries A, B, and C, but something else for entries X, Y, and Z).
I suppose I could use remove-method and then write my own fmap
implementation for IPersistentMap. I'm curious about the design,
though.
Thanks,
Chris
On Tue, Feb 22, 2011 at 6:56 PM, Benny Tsai wrote:
> There is fmap from clojure.contrib.generic.functor, which expects a
> function of arity 1, for just the value:
>
> (use 'clojure.contrib.generic.functor)
> (require '[clojure.string :as str])
>
> (def my-map {:first "john" :last "smith" :age 25})
>
> (defn my-fn [value]
> (if (string? value)
> (str/upper-case value)
> value))
>
> user=> (fmap my-fn my-map)
> {:first "JOHN", :last "SMITH", :age 25}
>
> On Feb 22, 4:23 pm, rob levy wrote:
>> The usual intuitive options for this are reduce, zipmap, or into. You can
>> also write a lazily recursive solution. I wonder why there's no function in
>> core that lazily re-constructs the map with the results of the function? It
>> seems to have been discussed on the list at least once or twice. It seems
>> like there would have to be two versions of it, one expecting a function
>> with an arity of one (for just the value) and another expecting an arity of
>> two (key and value).
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 21, 2011 at 10:08 PM, yair wrote:
>> > I'm hoping this is a dumb question and I've missed something obvious.
>> > I have a map with various key-value pairs and I want to transform some
>> > of the values, e.g.
>>
>> > (def mymap {:first "john" :last "smith" :age 25}) and say I want to
>> > change the strings to be upper case.
>> > Right now all I can think of doing is using reduce and passing in an
>> > empty map and the re-associating each key with the (possibly)
>> > transformed value. Is there something like the map function that
>> > takes two parameters, one a function that receives a pair and returns
>> > a new pair, and the other a map, and returns a map that's
>> > reconstituted from those pairs?
>>
>> > Thanks
>>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> >http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To 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: Ordering of defn's?
There has been some debate about this over time in the clojure mailing list. I too regret from time to time the ability to organize my code "top-down" without having to resort to "tricks" (declare). I had suggested that unknown vars encountered during compilation could just be "automatically declared" by default. The debate has shown that there are at least 2 drawbacks to this approach: * you loose the ability to "catch up" problems at compile time: if you misspelled a var, instead of explicitly reference a yet-to-be-defined var, you're not helped by the compiler anymore. * in some areas, performant clojure code needs type hints to avoid compiling bytecode which uses reflection. "auto-declaration" of yet-to-be-defined vars associated with "seamless compilation" of code using these "auto-declared" vars would automatically lead to suboptimal code where the compiler cannot imply anything for the output ype of the auto-declared var. The generated code would in average use more reflective calls. 2011/2/23 Mikhail Kryshen > On Tue, 22 Feb 2011 16:12:50 -0800 (PST) > Jonathan Mitchem wrote: > > > Hm, I see now. Does Java work like that too? (C# doesn't.) > > No. > > > Are there any plans for this to change in the future? I can work with > > it now, but it makes me uncomfortable. It feels like a step > > backwards. > > > > I fully understand if it was just a feature put on hold, just to get > > the reader/compiler out there. If it was a design decision, then > > that's kind of different. > > This is probably by design. Loading or compiling clojure file implies > evaluating all the forms it contains in order. You can do anything at > compile/load time, not only define things. > > -- > Mikhail > > -- > 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: Implementing search algorithm for binary tree
HB writes: > I'm trying to implement searching algorithm for binary tree. > > (defrecord Node [data left-child right-child]) > > (defrecord Tree [root]) > > (defn find-node [tree data] > "Search for a node" > (let [root (:root tree)] > (loop [current root] > (if (= data (:data current)) > current > (cond > (< data (:data current)) > (> data (:data current))) > > I don't know to to set/assign a value for current inside cond form. > Thank you for help and time. loop should be paired with recur. So something like this (untested): (defn find-node [tree data] "Search for a node" (loop [current (:root tree)] (cond (nil? current) nil (< data (:data current)) (recur (:left-child current)) (> data (:data current)) (recur (:right-child current)) :else current))) -- 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: Java Agent Based Modeling Systems and Clojure
I've been programming agent-based models in clojure for the last 2 years, and I've found that having a vector full of refs works fine. If two individuals interact (in my case, form a relationship), I use dosync and alter in a parallel environment to ensure that noone is starting more relationships than they have capacity for). (def world (vec (map (fn [pos] (ref (create-host (- (rand-int (* timespan 365)) (* maximum-age 365)) pos))) (range fullpopsize) (defn pair-hosts [h1 h2] (dosync (let [keep-till (+ @day (exp-decay (table-relation reltype)))] (alter h1 assoc :relas (vec (conj (:relas @h1) (struct relation (:id @h2) reltype @day keep-till (alter h2 assoc :relas (vec (conj (:relas @h2) (struct relation (:id @h1) reltype @day keep-till (vector h1 h2)) -- 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: akka
On Feb 23, 1:17 am, Mark Engelberg wrote: > 3. What is Clojure's state-of-the-art for building distributed, > fault-tolerant systems with its existing feature set and/or leveraging > popular libraries? > I've not used it, but jobim is worth looking at since it brings together all the components required for fault tolerant distributed systems: https://github.com/antoniogarrote/jobim Although, like most people, I would love the convenience of a complete Java implementation of ZeroMQ. Saul -- 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: Transforming map entries
On Feb 22, 4:08 am, yair wrote:
> I'm hoping this is a dumb question and I've missed something obvious.
> I have a map with various key-value pairs and I want to transform some
> of the values, e.g.
>
> (def mymap {:first "john" :last "smith" :age 25}) and say I want to
> change the strings to be upper case.
> Right now all I can think of doing is using reduce and passing in an
> empty map and the re-associating each key with the (possibly)
> transformed value. Is there something like the map function that
> takes two parameters, one a function that receives a pair and returns
> a new pair, and the other a map, and returns a map that's
> reconstituted from those pairs?
since hash-maps aren't lazy, what's wrong with using hash-map?
(apply hash-map (mapcat (fn [[k v]] [(.toUpperCase k) v]) {"bla" 1
"bloop" 2}) )
=> {"BLOOP" 2, "BLA" 1}
or:
--
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
