I've published the first releases of dynamic-object to Maven.
dynamic-object (https://github.com/rschmitt/dynamic-object) is an effort to
bring the flexibility and power of Clojure data and the Edn data language
to Java developers in the most direct way possible. This library is
intended to
See points 2, 3 and 8 at http://clojure.org/refs
It is just a way to obtain the change lock of the ref in the dosync
transaction, without rewriting it. The alternative would be to
explicitly modify it to the same value as it was before, which is
potentially wasteful.
One possible case where this
It sounds like you're building an API to provide documentation, but instead
why not just document the data structure directly?
Once you have your data structure design, add functions for non-trivial
tasks. So something like red? seems a little too trivial and specific.
The raw s-expression, (=
I think this is a great idea and I certainly support this effort.
One thought that springs to mind is that it would be nice to be able to use
the Clojure interfaces and data structures in Java *without* pulling in
the whole of Clojure as a dependency. Clojure is a bit of a heavyweight
Hi,
I'm observing an incredibly weird bug in my program where this happens on
the REPL
(use 'myapp.some.stuff)
(def x (-Record 1))
(type x) ; = myapp.some.stuff.Record
(instance? myapp.some.stuff.Record x) ; = false
(instance? (type x) x) ; = true
Somewhere the namespace gets reloaded, and
I was hoping to use sente https://github.com/ptaoussanis/sente
to provide access to a server endpoint from clients in arbitrary domains,
but the sente client explicity prepends its own host to the user-provided
endpoint:
Clojure Contrib libraries are all deprecated and very out of date.
For clojure.contrib.sql, you'll want to use clojure.java.jdbc instead. Complete
(community-maintained) documentation can be found here:
http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html
Reference documentation can
er, should the various pages be updated to say that they are all super
deprecated now?
e.g. things that turn up in google:
http://dev.clojure.org/display/doc/Clojure+Contrib+Libraries
On Thu, Jun 26, 2014 at 3:58 PM, Sean Corfield s...@corfield.org wrote:
Clojure Contrib libraries are all
On Jun 26, 2014, at 4:03 PM, Raoul Duke rao...@gmail.com wrote:
e.g. things that turn up in google:
http://dev.clojure.org/display/doc/Clojure+Contrib+Libraries
Which says:
If you currently depend on the Monolithic Contrib, you are encouraged to
look at the new modular contrib projects to see
Thanks Ryan and James - that gives me a few more ideas on how to think
about things. Hopefully some of the links Ryan posted will clarify things
for me also.
Ryan - yes my question about namespaces was to do with understanding the
ideal granularity of namespaces. And more specifically,
Most Clojure libraries I've seen only give you a handful of namespaces. I
would expect a moderately large Clojure library to expose, say, half a
dozen at most. Remember that Clojure has no concept of star imports, even
for Java classes, and imports will generally be qualified somehow (e.g.
This answer says everything I would want to say better than I would say it.
Second!
Alex
On Wednesday, June 25, 2014 9:12:01 PM UTC-5, Ryan Schmitt wrote:
In object-oriented programming, encapsulation is always and everywhere
regarded as a highly significant design virtue, but the Clojure
I am aware of edn-java; it has a very different scope than this library.
edn-java is basically a pure Java implementation of an Edn parser, and it
exposes the parsed data as mutable, untyped Java collections (e.g. an Edn
map becomes a java.util.HashMap?, ?). I wanted to bring Clojure's entire
Hi,
I am planning to play with implementing some giant in-memory index that is
basically tree-like structure containing counters on certain tree nodes,
and can aggregate billion data points and will probably consume tens of GBs
of RAM.
Since space (memory)-efficiency is crucial here, I was
14 matches
Mail list logo
