Re: clojure.java.jdbc - jdbc metadata support?

Cool. I'll take a look at that and email you (hopefully tomorrow, depending on workload!). Sean On Wed, Jul 24, 2013 at 10:15 PM, Mark wrote: > Thanks, Sean. Not sure through what channel you want to communicate. > > I have pushed some changes that significantly clean up the code: > > Use reg e

Re: clojure.java.jdbc - jdbc metadata support?

Thanks, Sean. Not sure through what channel you want to communicate. I have pushed some changes that significantly clean up the code: - Use reg ex as you suggest - Eliminated reflection warnings - Learned me a zipmap for great success On Wednesday, July 24, 2013 7:09:27 PM UTC-7,

[ANN] Dominoes front-end validation library

dominoes A ClojureScript front-end validation library => https://github.com/runexec/dominoesClick here to try it live or watch the animated GIF preview (loading)Usage Example(use '[dominoes.core :only [document-ready? validate! valid-submit! *error-s

Re: clojure.java.jdbc - jdbc metadata support?

I'll reply off-list. There's a lot of stuff in that code to digest. I'll say straight off that I think a regex replace would make the clojurize-java-accessor code much simpler. I suspect there are reflection warnings in several places that will need to be addressed and definitely some refactoring t

[ANN] byte-transforms: methods for hashing, compressing, and encoding bytes

https://github.com/ztellman/byte-transforms This is just a thin wrapper over byte-streams [1] and some best-in-class hashing and compression algorithms, but I figure there are at least a few people who, like me, have put off using Snappy or MurmurHash because they didn't feel like crawling thro

Re: Confused again by core.async

I have removed the problem.clj file referenced in the original post, and I have incorporated Timothy's corrections into the Hoare CSP examples: https://github.com/nodename/async-plgd/blob/master/src/hoare/subroutines.clj On Wednesday, July 24, 2013 12:17:01 PM UTC-7, nodename wrote: > > Well that

ANN: core.match 0.2.0-rc5

More bug fixes - this time around locals matching in ClojureScript as well as general bugs around vector patterns with rest patterns. http://github.com/clojure/core.match Feedback welcome! David -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: clojure.java.jdbc - jdbc metadata support?

re Signing the CA: Definitely. I'll get that sent in ASAP. In the meantime, can you take a look at https://github.com/markaddleman/java.jdbc/commit/27a246dee7c0a06c888d827e0699bc6966725b58 ? I'm still a Clojure noob so I'm not sure if the approach is correct. All feedback welcome. On We

Re: Evaluation of metadata by reader

I wrote a blog post about this last year: http://spencertipping.com/posts/2012.0819.clojure-metadata.html On Wednesday, July 24, 2013 3:09:11 PM UTC-7, Jozef Wagner wrote: > > I have a hard time understanding the rules for the evaluation of the > metadata in the reader. Following example illustr

Re: clojure.java.jdbc - jdbc metadata support?

That's great and would be a worthwhile addition but don't forget to get your CA signed and sent in, otherwise your contributions cannot be accepted. See http://clojure.org/contributing for more details. Sean On Wed, Jul 24, 2013 at 4:03 PM, Mark wrote: > I'm pretty interested in getting at least

clojure.java.jdbc - jdbc metadata support?

I'm pretty interested in getting at least a subset of jdbc metadata support into clojure.java.jdbc. I've forked the repo and will start crafting the API if there is no else has a similar effort going on. I'm mostly interested in result set metadata. My first thought is to extend the query fu

Re: How do I setup a Clojurescript REPL with emacs?

The lein-cljsbuild plugin even with the repl-listen task option does not seem to me to use an nrepl middleware. The best interactive experience is obtainable by using pieggieback middleware. Chas (I did not scrupulously read the README - sorry about that) remembered me that piggieback 0.0.5 r

Evaluation of metadata by reader

I have a hard time understanding the rules for the evaluation of the metadata in the reader. Following example illustrates this: (let [x :foo v1 (quote ^{x 4} [1 2 3]) v2 ^{x 4} [1 2 3]] (println (meta v1) v1) (println (meta v2) v2)) prints {x 4} [1 2 3] {:foo 4} [1 2 3].

Re: querying a clojure data structure

Like Tim, I was thinking about the Datomic query language. Before you do that though, remember that there's some basic relational algebra functions in clojure.set . Stuart Halloway demonstrates this in an interesting gist

Re: Interest in a Full Featured Clojure Blog Engine

Oh nice. I like the look of devs . So I've put together some rudimentary work for Stefon. Just some basic CRUD + find + list. I had a think about how to tie together the different domain entities. And internally, I think relation

Re: querying a clojure data structure

On Wed, Jul 24, 2013 at 5:16 AM, Phillip Lord wrote: > > > So, with this case, say I want the Italian label, in the set which is the > value of the annotation key, find any list with the first element 'label, > and > third element "it", and return the second element. Of course, this can be > done

Re: querying a clojure data structure

Eh...use the right tool for the job... On Wed, Jul 24, 2013 at 2:00 PM, Cedric Greevey wrote: > On Wed, Jul 24, 2013 at 3:27 PM, Timothy Baldridge > wrote: > >> However, to be honest, this is where I reach for Datomic. It has a wicked >> fast query engine (datalog), you can run it in-memory (n

Re: querying a clojure data structure

On Wed, Jul 24, 2013 at 3:27 PM, Timothy Baldridge wrote: > However, to be honest, this is where I reach for Datomic. It has a wicked > fast query engine (datalog), you can run it in-memory (no disk access > required), it has an excellent Clojure interface, the free version should > do everything

Re: querying a clojure data structure

I think the first hint to an answer is found in your question. You are dealing with complex data, simplify the data, and querying the data is much simpler. For instance, if you have a tree, you could flatten the tree into a hash map like this: {parent-id {:children [child-id1 child-id2]} child-i

Re: Can we please deprecate the :use directive ?

On Wed, Jul 24, 2013 at 12:50 PM, Phil Hagelberg wrote: > My assumption from our discussion would be that a warning would be added > in a near release when :use was detected in the ns macro, and that it would > be removed for Clojure 2.0 when backwards-incompatible changes are OK. > You mean, th

Re: Confused again by core.async

Well that makes sense and you've proved that you're right https://gist.github.com/halgari/6073419 so I am having a paradigm shift. Thanks! -A On Wednesday, July 24, 2013 11:47:29 AM UTC-7, tbc++ wrote: > > Take a look at your code again, service is reading a value from a, > modifying it, and

Re: querying a clojure data structure

Don't quote me on this, but it might be the sort of problem for which core.logic is well suited. Though really it seems like what's wanted is a variation on the theme of core.match but which does destructuring assignments rather than flow control. On Wed, Jul 24, 2013 at 8:16 AM, Phillip Lord wro

Re: Confused again by core.async

Take a look at your code again, service is reading a value from a, modifying it, and sticking it back into a. You also have a "put" process putting values into a, and fan-in taking values from a. So what is keeping values from flowing from your "put" process directly to fan-in, skipping service com

Re: Confused again by core.async

I do not think that is the problem. In fact I believe that reading a request from a channel and writing the response to the same channel is the canonical service pattern in Go. I have added a test-service function that works as expected, and a test-fan-in-2 function that fails in a slightly diff

Re: Can we please deprecate the :use directive ?

Too much is the same as not enough. People can choose to which extend they want to hang themselves, how thick the rope they "use" should be and the height from which they will throw themselves to insure a fast and painless deliverance, hopefully by breaking their neck as fast as possible :) T

Re: Can we please deprecate the :use directive ?

Imo, as soon as you have to maintain other peoples' code that heavily uses naked use, require starts to look a whole lot nicer. On Wed, Jul 24, 2013 at 10:14 AM, Lee Spector wrote: > > On Jul 24, 2013, at 12:45 PM, dennis zhuang wrote: > > I am using ':use' for my own namespaces.I know it's disco

Re: Can we please deprecate the :use directive ?

On Jul 24, 2013, at 12:45 PM, dennis zhuang wrote: > I am using ':use' for my own namespaces.I know it's discouraged, but if i can > control my own code,why not? Compiler can give me warnings and i process all > warnings carefully. I agree. But I do now see that it's really just about as good,

Re: Can we please deprecate the :use directive ?

This is quite decent. Luc > I can confirm that the point of adding :refer support to :require was to > deprecate :use; I suggested this to Rich at the 2011 Conj when he mentioned > the ns macro is too complicated, and he agreed it would be a good idea to > enhance :require so that it would ma

Re: Can we please deprecate the :use directive ?

I can confirm that the point of adding :refer support to :require was to deprecate :use; I suggested this to Rich at the 2011 Conj when he mentioned the ns macro is too complicated, and he agreed it would be a good idea to enhance :require so that it would make :use unnecessary in order to reduc

Re: Can we please deprecate the :use directive ?

I am using ':use' for my own namespaces.I know it's discouraged, but if i can control my own code,why not? Compiler can give me warnings and i process all warnings carefully. 2013/7/25 Steven Degutis > If our votes count for anything, then I'd like to add +1 for getting rid > of :use, and stro

Re: Can we please deprecate the :use directive ?

If our votes count for anything, then I'd like to add +1 for getting rid of :use, and strongly discouraging :refer :all. On Wed, Jul 24, 2013 at 11:16 AM, Alex Baranosky < alexander.barano...@gmail.com> wrote: > +1 for scary compiler deprecation warning for 1.6.0, then removing :use in > the 1.7

Re: Can we please deprecate the :use directive ?

If anyone needs help removing all their uses, Slamhound ( https://github.com/technomancy/slamhound) does a decent, though not perfect, job of automating this. On Wed, Jul 24, 2013 at 9:16 AM, Alex Baranosky < alexander.barano...@gmail.com> wrote: > +1 for scary compiler deprecation warning for 1.

Re: Can we please deprecate the :use directive ?

+1 for scary compiler deprecation warning for 1.6.0, then removing :use in the 1.7.0 release. On Wed, Jul 24, 2013 at 8:49 AM, Softaddicts wrote: > I disagree, when I use tracing fns and other useful REPL tools, > I like to have them included without having to prefix them with an alias. > > It's

Re: Can we please deprecate the :use directive ?

I disagree, when I use tracing fns and other useful REPL tools, I like to have them included without having to prefix them with an alias. It's not a hack it's a feature and you are free to use it or not. If code writers do not care about code readers it's a choice, maybe bad but that decision is

Re: [ANN] verily, non-magic testing lib

Also, I came up with a solution for simple around-each fixtures. It would use a declarative style just like (defn ^:test ...), but it would be (defn ^:around-each ...). And its metadata would contain a matcher-fn that matches against a test-fn's metadata. This way you could define a bunch of tests

Re: [ANN] verily, non-magic testing lib

The vast majority of my tests look like: do some setup, do some action, make a half-dozen assertions. Almost always in that order. The only reason I can think of that I would need to have assertions in the middle is if I plan to do more setup and action and assertions afterwards. And in that case

Re: [ANN] verily, non-magic testing lib

I've never tried it, but I like the idea of test fns returning their results. On Jul 24, 2013 8:30 AM, "Steven Degutis" wrote: > > Also, I've been considering having a non-side-effecty way of returning test results. What do people think? It would get rid of the last bit of magic in the lib. > > >

ANN: ClojureScript 0.0-1847

ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-1847 Leiningen dependency information: [org.clojure/clojurescript "0.0-1847"] *Changes: *The only changes since the last release

Re: Can we please deprecate the :use directive ?

On Jul 24, 2013, at 9:35 AM, Laurent PETIT wrote: > You (and to some extent me) can easily play with both forms. > But why both forms ? That's curse of knowledge in action, because this > will make no sense at all for newcomers, and there's no good reason > for having both, except historical ones.

Re: Can we please deprecate the :use directive ?

> I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) Agree. Code is read much more often than it is written, so omitting a few character is not effective time-saving. I also don't like :refer :all. I think it

Re: Can we please deprecate the :use directive ?

2013/7/24 Lee Spector : > I don't really see why it's helpful to anyone to make me and other :use users > do this. Lee, you were in the past really brilliant at showing me whre I couldn't see, anymore, how difficult to grasp some Counterclockwise features were. This is what is called "curse of k

Re: [ANN] verily, non-magic testing lib

I think I may have been the one on IRC that provoked you to this decision Steven, so I'm happy that you've put the project back up. I certainly never intended that you not build something to suit your own purposes, and I absolutely didn't intend to suggest you shouldn't put software out there for

Re: [ANN] verily, non-magic testing lib

Also, I've been considering having a non-side-effecty way of returning test results. What do people think? It would get rid of the last bit of magic in the lib. ;; current style (side-effecty) (defn test-1 [] (let [foo (get-foo)] (expect empty? foo) (expect awesome? foo))) ;; proposed

Re: [ANN] verily, non-magic testing lib

First, the goal of Verily was not the same as Test2. It wasn't intended to unify any existing test libs. It was really just meant to succeed clojure.test in spirit. That's all. Second, nobody "bullied" me into this decision. Some people asked how Verily improved upon the alternatives, and, try as

Re: Confused again by core.async

I think the problem is in your service function, notice how you are reading data from a channel then writing data to that same channel, within the same process? Try fixing that and see where it gets you. Timothy On Tue, Jul 23, 2013 at 11:25 PM, Alan Shaw wrote: > Hi, > I hope I can get a ligh

querying a clojure data structure

I have a relatively complex data structure, a simple example of which looks likes like this. This is the print representation -- the bits like "" are java classes. {:annotation #{(annotation #http://www.purl.org/ontolink/tawny/name>> "PizzaTopping" "en") (annotation #http://www.n

Re: Can we please deprecate the :use directive ?

I use 'use' yes. Take, for instance, this code. It uses my own library to generate a series of logical statements (about pizza's -- there is a reason, daft though it sounds). https://github.com/phillord/tawny-pizza/blob/master/src/pizza/pizza.clj It isn't until around the 300th line that I fir

Re: Can we please deprecate the :use directive ?

On Jul 24, 2013, at 2:40 AM, Baishampayan Ghose wrote: > > For that use-case, you can always use something like (:require the-ns > :refer :all). Thanks for the clarity BG. I guess if/when it becomes necessary I'll convert all of my (:use the-ns) to (:require the-ns :use :all), although I don't

Re: [ANN] verily, non-magic testing lib

I've never spoken to Steven in anything that wasn't a public email to this list, so it wasn't me. I'm not sure who the self-proclaimed project guardians are, but I just wanted to make sure no one thought I was trying to "protect" https://github.com/jaycfields/expectations in anyway. I don't actual

Re: [ANN] verily, non-magic testing lib

Am Mittwoch, 24. Juli 2013 08:14:15 UTC+2 schrieb Steven Degutis: > > It's been brought to my attention that this project is an utter waste of > time, brings no real improvement over the existing solutions, and was > wrought in complete arrogance. So I've deleted the project. Sorry for > wastin

Re: anaphoric macro?

Hi Alex, That works perfect! I've another (possibly stupid) question. If I want this to work with your macro: (def abc ["a" "b" "c"]) (def-name abc a) How could I get that to work? Thanks, --anders Den tisdagen den 23:e juli 2013 kl. 09:48:18 UTC+2 skrev Alex Baranosky: > > Hi Anders, > > (defm

Re: Can we please deprecate the :use directive ?

I usually :use clojure.pprint and clojure.repl. Nobody was hurt. For everything else, I use :require/as. -- Dave On Tue, Jul 23, 2013 at 7:27 PM, Gary Trakhman wrote: > We should scour clojuresphere for uses of 'use' and automatically post > github issues to the projects of interest, and re

[ANN] ClojureScript Benchmarks

I have some performance sensitive code in my ClojureScript program, so I've done some benchmarks to determine the best approach. I've streamlined the benchmarking process and made it public. You can find it at http://wagjo.github.io/benchmark-cljs/ May it help you make more performant ClojureSc