should edn recognise defrecord?
I am sending instances of defrecords from clojurescript via transmit/edn
and getting:
2015-Feb-24 19:23:52 + dev-os-mbp.local DEBUG [taoensso.sente] - Bad
package: [[:client/message #health.shared.domain.PingCommand{}]]
(clojure.lang.ExceptionInfo: No reader function for tag
health.shared.domain.PingCommand {:type :reader-exception})
The defrecord is defined using cljx and is definitely there on the server.
Do I need to write a reader function to recognise instances of defrecord -
my assumption was that this should just work?
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can someone offer refactoring suggestions for my protocol example?
There's one important case where (coll n) is not the same as (get coll n) -
when coll is nil. In that case (get coll n) will return nil and (coll n)
will barf. I tend to use get in those cases because of this.
On 24 February 2015 at 08:50, Colin Yates colin.ya...@gmail.com wrote:
A minor point (get col n) is the same as (col n).
It's more of a stylistic thing, but your use of protocols and
implementation is quite 'stateful'. I would have done the same with
vanilla maps:
(def employee [first-name last-name level]
{:first-name .})
(defn promote [{:keys [level] :as employee]
(assoc employee :level (next-item levels level)))
but that is just me - maybe I ran too far from the OO world
On 23 February 2015 at 18:44, Daniel Hinojosa
dh.evolutionn...@gmail.com wrote:
This is for my language matrix project that has samples for 10 different
languages. My clojure knowledge is ok, but not really as great where I
would like it to be, therefore looking towards the community for help.
This example works, but it still has the feel of a lot of duplication,
are
there any refactorings that I can do to this to make it more concise?
https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj
Thank you in advance,
Danno
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: New scientific article out on plague and climate, using clojure, quil and incanter for data analysis, and lighttable as IDE.
This is awesome. I had just opened the BBC news summary article, and then scrolled down my Clojure Group digest to see your post. Nice work. Always good to see other scientists using Clojure in their work. On Tuesday, February 24, 2015 at 2:59:41 AM UTC-8, Boris V. Schmid wrote: Hi all, Published a new paper, using clojure, quil, and incanter to do some custom statistics (permutation testing) and data exploration, and lighttable as IDE Aim was to discover the wildlife reservoirs of plague in medieval Europe, but we ended up finding evidence for repeated reintroductions of the bacterium into Europe from Asia, over the course of 4 centuries. I continue to use clojure today, although I am switching from incanter/charts to https://github.com/JonyEpsilon/gg4clj to have access to ggplot2. ggplot2 is just more powerful than the JfreeChart-based charting of Incanter. Thanks all for making the tools I use every day :-). @BorisVSchmid Background on the article: https://theconversation.com/plague-outbreaks-that-ravaged-europe-for-centuries-were-driven-by-climate-change-in-asia-37933 Article is open access, and available from PNAS http://www.pnas.org/content/early/2015/02/20/1412887112 Source code and datasets available here: https://zenodo.org/record/14973#.VOxH5vnF9vo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Advice on core.async and (JDBC) transactions
Hi Andrey - thanks for responding. Asciidoctor looks great! I think I understand the sucriata approach which serialises access to the connection (via the agent). But this doesn't ensure that all operations using the connection are done in the same thread does it (I didn't think agents were thread-locked)?. In not then it looks like a no go. To be clear, my understanding (which is from a while ago admittedly) is that JDBC transaction implementations tend to use thread locals to store a bunch of stuff so it isn't so much the concurrent access which is a problem (nicely solved by the agent approach) it is ensuring it is ensuring the same thread is used. On 23 February 2015 at 23:41, Andrey Antukh n...@niwi.be wrote: Hi Colin. You are talking about suricatta documentation? Is build with asciidoctor. And, about core.async and transactions, suricatta comes with an async abstraction that internally uses a clojure agent for serialize all access to one connection from different threads (managed by core.async internal thread pool). Nothing special is used from jooq for handle it. A suricatta context encapsulates the standard jdbc connection and additional state. As far as I know, JDBC connection is not fully thread safe (http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe), and the general opinion is avoid use the same connection instance from different threads concurrently. But the suricata approach is share a connection instance between threads but ensuring that only one thread can use it at same time (as I said previously) using serialization semantics of clojure agents. I hope it has been helpful. Cheers Andrey 2015-02-23 22:26 GMT+01:00 Colin Yates colin.ya...@gmail.com: Thanks Christian, that looks interesting. By the way, any idea what tool was used to generate the documentation? On 23 February 2015 at 21:22, Christian Weilbach whitesp...@polyc0l0r.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.02.2015 18:20, Colin Yates wrote: Currently each request gets serviced in its own thread (web container) and I am thinking of integrating core.async and I wonder how core.async and a JDBC transactional unit of work get on. Conceptually, this model (thread-per-request) is trivial however the problems are well known. Replacing this with core.async right at the front is trivial but I can see the benefit of sprinkling asynchronous behaviour throughout the (still very trivial) pipeline. Or rather I can see the beauty of decomposed components communicating via channels. My question is about transactionality. I am used to JDBC transactions being thread local and I understand core.async utilises a thread-pool, so how does one implement a unit of work that spans multiple channels? I want to do something like: - request comes in - the appropriate handler/service consumes it (either through request mapping, defmethod whatever) - TX starts - in parallel some logging happens (and DB is updated) - the message is handled (and DB is updated) - performance metrics are stored (and DB is updated) - all work on all channels gets finished - TX commits The point is that channels are used only to communicate between disconnected components but they should all participate in the same TX. Is anyone else using channels like this? I have done it in IndexedDB in JavaScript and had to use the proper callback API (1), because otherwise transactions break. I guess you cannot do channel operations inside a JDBC operation since they are executed in the threadpool (by the state-machine) while each JDBC connection seems to be pinned to a thread, so you cannot participate in the same transaction from another thread of the threadpool. But if you can wrap your blocking JDBC stuff in a singular thread call, you might be able to use async/thread (probably less than you want). There is also https://github.com/niwibe/suricatta, but I have no experience with it. jooq seems to solve the the thread per request problem decoupling into async operations you have in mind. Cheers, Christian (1) https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+ xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7 dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw= =Wi7E -END PGP SIGNATURE- -- 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
[ANN] semantic-csv 0.1.0-alpha2 released
Semantic CSV is a library for taking you the extra mile with CSV parsing - https://github.com/metasoarous/semantic-csv This release will hopefully be the last 0.1.0-alpha release, as long as no major issues come up in the next week or two. Till then, please take it for a spin and leave any feedback you might have on the github issues page. Some (abridged) notes from the changelog: * simplified casting functionality to just a single function * smarter casting error handling options * except-first macro for leaving header columns unaltered in threading macro forms * can specify :header to mappify, so it doesn't consume the first column * mappify now supports using structs instead of array- or hash-maps, for a nice performance boost (with thanks to @MichaelBlume) * greatly improved testing coverage (thanks in part to @ballPointPenguin) * some more flexible numerics casting helpers (thanks in part to @JonyEpsilon) For updated documentation and examples, see http://metasoarous.github.io/semantic-csv/ With gratitude, Christopher Small -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing pulley.cps
Hi, Nathan Would you like to describe shortly, why one would need such transformation. What are the benefits and what prevents to write code in CPS style by hand? p.s. sorry, I'm far from being expert in this field :) четверг, 19 февраля 2015 г., 23:45:10 UTC+6 пользователь Nathan Davis написал: Dear Fellow Clojurians, I'm pleased to annouce release 0.1.0 of pulley.cps, a tool for transforming Clojure code into Continuation-Passing-Style. You can find it at http://github.com/positronic-solutions/pulley.cps. While this is not the first attempt at such a tool, to the best of my knowledge it is the most complete to date. The rather lengthy Readme (which for now also doubles as User Guide, API Documentation, and design document) goes into more detail, but here's a quick run-down of features: - Two macros, cps and cps-fn, serve as primary entry points for transforming code. - Transformed code can call native code (non-transformed functions and Java methods) and vice versa. - Due to the nature of CPS, we get tail-call optimization for free (i.e., all tail-calls within transformed code are naturally TCO'd). Of course, calls from CPS to native code still consume Java stack space, and non-tail calls within transformed code will consume *heap* space. - Dynamic bindings are fully supported, and do not interfere with TCO ( binding is fully tail-call optimizable). set! is not currently implement for dynamic vars, but due to some recent changes to the way dynamic environments are implemented should be trivial to support. - Since with CPS we explicitly pass the continuation around, it is easy to expose the current continuation to the user. This is accomplished via the function call-cc and its macro analog let-cc. - Exceptions are not currently implemented. However, they are actively being worked on. The expectation here is that exceptions will work pretty much seamlessly with native exceptions, and you will be able to use the same forms (throw, try, catch, finally) as you would in regular Clojure code. - The ability to override native functions with a CPS implementation, in order to provide an optimal experience. For example, clojure.core/apply is overridden to provide an optimized implementation when invoked from CPS code. So if you call apply with a CPS function, continuations, TCO, etc. will still work. Overall, the goal is to be able to automatically transform as much regular clojure code into CPS while maintaining seamless interoperation with native Clojure code. The one area I don't think we'll manage to do a satisfactory job on are forms that create Java types (reify, deftype, genclass, etc.). These forms are currently completely unsupported, and any potential future support will most likely consist of simply escaping the transformation process when these forms are encountered. Other than that, once exception support is completed, I think this goal will be within reach. Near-term development goals are first to implement exceptions. Then I'd like to explore expanding platform support beyond the JVM, namely ClojureCLR and ClojureScript. Anyway, feel free to give things a try. I greatly treasure your feedback, including bug reports and if you have trouble navigating the documentation. Have fun, Nathan Davis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support
On Saturday, February 21, 2015 at 7:01:39 PM UTC+1, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2913 Leiningen dependency information: [org.clojure/clojurescript 0.0-2913] This release comes with two very big enhancements. The first is support for Google Closure Modules via the :modules build option. Google Closure Modules permits splitting advanced compiled builds into optimal smaller pieces for faster page loads. ClojureScript's Google Closure Module support is fully :foreign-libs aware. Source mapping for modules is also fully supported. The feature is described in more detail here: https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules The second big change is a fundamental rearchitecting of ClojureScript REPLs. ClojureScript REPLs now support a set of options similar to those taken by `clojure.main/repl` with small changes to account for different JavaScript evaluation environments. Many third party REPLs like Figwheel, Weasel, and Ambly are either unaffected or have already accounted for these changes. However current tooling leveraging Piggieback will likely present an inferior experience as Piggieback was designed to work around the previous limitations of ClojureScript REPLs. Now that ClojureScript REPLs are more like the standard Clojure REPL it should be far simpler to add proper interruptible-eval and load-file nREPL middleware so that existing tooling around nREPL can more easily integrate ClojureScript REPLs as first class citizens. Feedback on both of these enhancements is very welcome! There are also many smaller fixes around REPL command line behavior, the Nashorn REPL, :foreign-libs resource finding issues, the full list follows: ## 0.0-2913 * Support custom :output-to for :cljs-base module ## 0.0-2911 ### Enhancements * CLJS-1042: Google Closure Modules :source-map support * CLJS-1041: Google Closure Modules :foreign-libs support * Google Closure Modules support via :modules * CLJS-1040: Source-mapped script stack frames for the Nashorn repl ### Changes * CLJS-960: On carriage return REPLs should always show new REPL prompt * CLJS-941: Warn when a symbol is defined multiple times in a file * REPLs now support parameterization a la clojure.main/repl * all REPLs analyze cljs.core before entering loop * can emit :closure-source-map option for preserving JS-JS map * REPLs can now merge new REPL/compiler options via -setup ### Fixes * CLJS-998: Nashorn REPL does not support require special fn * CLJS-1052: Cannot require ns from within the ns at the REPL for reloading purposes * CLJS-975: preserve :reload :reload-all in ns macro sugar * CLJS-1039: Under Emacs source directory watching triggers spurious recompilation * CLJS-1046: static vars do not respect user compile time metadata * CLJS-989: ClojureScript REPL loops on EOF signal * fix DCE regression for trivial programs * CLJS-1036: use getResources not findResources in get-upstream-deps* Nice! I played a bit with modules support. Good stuff! It is still not very clear for me where should I put my preamble stuff in that case. Will it be stored in cljs-base or in main output file? Can I have per module preamble? (probably per module preamble does not make any sense, right?) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Advice on core.async and (JDBC) transactions
2015-02-24 10:15 GMT+01:00 Colin Yates colin.ya...@gmail.com: Hi Andrey - thanks for responding. Asciidoctor looks great! I think I understand the sucriata approach which serialises access to the connection (via the agent). But this doesn't ensure that all operations using the connection are done in the same thread does it (I didn't think agents were thread-locked)?. In not then it looks like a no go. Yes, the agent does not ensures that all operations using a connection are done in the same thread. Using agent only ensures that all actions are done in serialized way and only one thread uses the connection at time. To be clear, my understanding (which is from a while ago admittedly) is that JDBC transaction implementations tend to use thread locals to store a bunch of stuff so it isn't so much the concurrent access which is a problem (nicely solved by the agent approach) it is ensuring it is ensuring the same thread is used. I'm not expert in jdbc, but I have see the source of postgresql jdbc, and the transaction state is bind to the connection, nothing related to thread locals. Thread locals are often used for transaction mangers like spring tx, maybe hibernate (I'm not sure because I have never used it), and other lightweight implementations like that https://github.com/witoldsz/ultm ... But in case of plain jdbc transactions, as far as I know, no thread local state is involved. Cheers. Andrey On 23 February 2015 at 23:41, Andrey Antukh n...@niwi.be wrote: Hi Colin. You are talking about suricatta documentation? Is build with asciidoctor. And, about core.async and transactions, suricatta comes with an async abstraction that internally uses a clojure agent for serialize all access to one connection from different threads (managed by core.async internal thread pool). Nothing special is used from jooq for handle it. A suricatta context encapsulates the standard jdbc connection and additional state. As far as I know, JDBC connection is not fully thread safe ( http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe ), and the general opinion is avoid use the same connection instance from different threads concurrently. But the suricata approach is share a connection instance between threads but ensuring that only one thread can use it at same time (as I said previously) using serialization semantics of clojure agents. I hope it has been helpful. Cheers Andrey 2015-02-23 22:26 GMT+01:00 Colin Yates colin.ya...@gmail.com: Thanks Christian, that looks interesting. By the way, any idea what tool was used to generate the documentation? On 23 February 2015 at 21:22, Christian Weilbach whitesp...@polyc0l0r.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.02.2015 18:20, Colin Yates wrote: Currently each request gets serviced in its own thread (web container) and I am thinking of integrating core.async and I wonder how core.async and a JDBC transactional unit of work get on. Conceptually, this model (thread-per-request) is trivial however the problems are well known. Replacing this with core.async right at the front is trivial but I can see the benefit of sprinkling asynchronous behaviour throughout the (still very trivial) pipeline. Or rather I can see the beauty of decomposed components communicating via channels. My question is about transactionality. I am used to JDBC transactions being thread local and I understand core.async utilises a thread-pool, so how does one implement a unit of work that spans multiple channels? I want to do something like: - request comes in - the appropriate handler/service consumes it (either through request mapping, defmethod whatever) - TX starts - in parallel some logging happens (and DB is updated) - the message is handled (and DB is updated) - performance metrics are stored (and DB is updated) - all work on all channels gets finished - TX commits The point is that channels are used only to communicate between disconnected components but they should all participate in the same TX. Is anyone else using channels like this? I have done it in IndexedDB in JavaScript and had to use the proper callback API (1), because otherwise transactions break. I guess you cannot do channel operations inside a JDBC operation since they are executed in the threadpool (by the state-machine) while each JDBC connection seems to be pinned to a thread, so you cannot participate in the same transaction from another thread of the threadpool. But if you can wrap your blocking JDBC stuff in a singular thread call, you might be able to use async/thread (probably less than you want). There is also https://github.com/niwibe/suricatta, but I have no experience with it. jooq seems to solve the the thread per request problem decoupling into async
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support
:preamble will only be applied to the base module. When using :modules there is not such thing as a main output file. You cannot currently have a per module :preamble. David On Tue, Feb 24, 2015 at 6:25 AM, Max Gonzih gon...@gmail.com wrote: On Saturday, February 21, 2015 at 7:01:39 PM UTC+1, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2913 Leiningen dependency information: [org.clojure/clojurescript 0.0-2913] This release comes with two very big enhancements. The first is support for Google Closure Modules via the :modules build option. Google Closure Modules permits splitting advanced compiled builds into optimal smaller pieces for faster page loads. ClojureScript's Google Closure Module support is fully :foreign-libs aware. Source mapping for modules is also fully supported. The feature is described in more detail here: https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules The second big change is a fundamental rearchitecting of ClojureScript REPLs. ClojureScript REPLs now support a set of options similar to those taken by `clojure.main/repl` with small changes to account for different JavaScript evaluation environments. Many third party REPLs like Figwheel, Weasel, and Ambly are either unaffected or have already accounted for these changes. However current tooling leveraging Piggieback will likely present an inferior experience as Piggieback was designed to work around the previous limitations of ClojureScript REPLs. Now that ClojureScript REPLs are more like the standard Clojure REPL it should be far simpler to add proper interruptible-eval and load-file nREPL middleware so that existing tooling around nREPL can more easily integrate ClojureScript REPLs as first class citizens. Feedback on both of these enhancements is very welcome! There are also many smaller fixes around REPL command line behavior, the Nashorn REPL, :foreign-libs resource finding issues, the full list follows: ## 0.0-2913 * Support custom :output-to for :cljs-base module ## 0.0-2911 ### Enhancements * CLJS-1042: Google Closure Modules :source-map support * CLJS-1041: Google Closure Modules :foreign-libs support * Google Closure Modules support via :modules * CLJS-1040: Source-mapped script stack frames for the Nashorn repl ### Changes * CLJS-960: On carriage return REPLs should always show new REPL prompt * CLJS-941: Warn when a symbol is defined multiple times in a file * REPLs now support parameterization a la clojure.main/repl * all REPLs analyze cljs.core before entering loop * can emit :closure-source-map option for preserving JS-JS map * REPLs can now merge new REPL/compiler options via -setup ### Fixes * CLJS-998: Nashorn REPL does not support require special fn * CLJS-1052: Cannot require ns from within the ns at the REPL for reloading purposes * CLJS-975: preserve :reload :reload-all in ns macro sugar * CLJS-1039: Under Emacs source directory watching triggers spurious recompilation * CLJS-1046: static vars do not respect user compile time metadata * CLJS-989: ClojureScript REPL loops on EOF signal * fix DCE regression for trivial programs * CLJS-1036: use getResources not findResources in get-upstream-deps* Nice! I played a bit with modules support. Good stuff! It is still not very clear for me where should I put my preamble stuff in that case. Will it be stored in cljs-base or in main output file? Can I have per module preamble? (probably per module preamble does not make any sense, right?) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
New scientific article out on plague and climate, using clojure, quil and incanter for data analysis, and lighttable as IDE.
Hi all, Published a new paper, using clojure, quil, and incanter to do some custom statistics (permutation testing) and data exploration, and lighttable as IDE Aim was to discover the wildlife reservoirs of plague in medieval Europe, but we ended up finding evidence for repeated reintroductions of the bacterium into Europe from Asia, over the course of 4 centuries. I continue to use clojure today, although I am switching from incanter/charts to https://github.com/JonyEpsilon/gg4clj to have access to ggplot2. ggplot2 is just more powerful than the JfreeChart-based charting of Incanter. Thanks all for making the tools I use every day :-). @BorisVSchmid Background on the article: https://theconversation.com/plague-outbreaks-that-ravaged-europe-for-centuries-were-driven-by-climate-change-in-asia-37933 Article is open access, and available from PNAS http://www.pnas.org/content/early/2015/02/20/1412887112 Source code and datasets available here: https://zenodo.org/record/14973#.VOxH5vnF9vo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: can binary arithmetic guru help improve these bitmasking ops?
Lief you have a really valid point here. I was definitely aware that there are only about a dozen actual masks that get used, so I had been looking for a good way to unroll that computation. So, you definitely have showed me something useful with your macro approach. I think doing that though is something I will want to revisit a little bit down the line -- ldb and dpb Have proven themselves useful enough to try to first look at ways to optimize them for the general use case. The .countTrailingZeros code seems to take a much more efficient approach to mask-offset and IIRC may completely eliminate mask-width. I'm going to play with it today and I'll report back any interesting results. This group is really a fantastic resource. You guys are awesome. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Advice on core.async and (JDBC) transactions
It seems like it is worthwhile to brush up my knowledge then, this looks quite hopeful - thanks! On 24 February 2015 at 10:39, Andrey Antukh n...@niwi.be wrote: 2015-02-24 10:15 GMT+01:00 Colin Yates colin.ya...@gmail.com: Hi Andrey - thanks for responding. Asciidoctor looks great! I think I understand the sucriata approach which serialises access to the connection (via the agent). But this doesn't ensure that all operations using the connection are done in the same thread does it (I didn't think agents were thread-locked)?. In not then it looks like a no go. Yes, the agent does not ensures that all operations using a connection are done in the same thread. Using agent only ensures that all actions are done in serialized way and only one thread uses the connection at time. To be clear, my understanding (which is from a while ago admittedly) is that JDBC transaction implementations tend to use thread locals to store a bunch of stuff so it isn't so much the concurrent access which is a problem (nicely solved by the agent approach) it is ensuring it is ensuring the same thread is used. I'm not expert in jdbc, but I have see the source of postgresql jdbc, and the transaction state is bind to the connection, nothing related to thread locals. Thread locals are often used for transaction mangers like spring tx, maybe hibernate (I'm not sure because I have never used it), and other lightweight implementations like that https://github.com/witoldsz/ultm ... But in case of plain jdbc transactions, as far as I know, no thread local state is involved. Cheers. Andrey On 23 February 2015 at 23:41, Andrey Antukh n...@niwi.be wrote: Hi Colin. You are talking about suricatta documentation? Is build with asciidoctor. And, about core.async and transactions, suricatta comes with an async abstraction that internally uses a clojure agent for serialize all access to one connection from different threads (managed by core.async internal thread pool). Nothing special is used from jooq for handle it. A suricatta context encapsulates the standard jdbc connection and additional state. As far as I know, JDBC connection is not fully thread safe (http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe), and the general opinion is avoid use the same connection instance from different threads concurrently. But the suricata approach is share a connection instance between threads but ensuring that only one thread can use it at same time (as I said previously) using serialization semantics of clojure agents. I hope it has been helpful. Cheers Andrey 2015-02-23 22:26 GMT+01:00 Colin Yates colin.ya...@gmail.com: Thanks Christian, that looks interesting. By the way, any idea what tool was used to generate the documentation? On 23 February 2015 at 21:22, Christian Weilbach whitesp...@polyc0l0r.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.02.2015 18:20, Colin Yates wrote: Currently each request gets serviced in its own thread (web container) and I am thinking of integrating core.async and I wonder how core.async and a JDBC transactional unit of work get on. Conceptually, this model (thread-per-request) is trivial however the problems are well known. Replacing this with core.async right at the front is trivial but I can see the benefit of sprinkling asynchronous behaviour throughout the (still very trivial) pipeline. Or rather I can see the beauty of decomposed components communicating via channels. My question is about transactionality. I am used to JDBC transactions being thread local and I understand core.async utilises a thread-pool, so how does one implement a unit of work that spans multiple channels? I want to do something like: - request comes in - the appropriate handler/service consumes it (either through request mapping, defmethod whatever) - TX starts - in parallel some logging happens (and DB is updated) - the message is handled (and DB is updated) - performance metrics are stored (and DB is updated) - all work on all channels gets finished - TX commits The point is that channels are used only to communicate between disconnected components but they should all participate in the same TX. Is anyone else using channels like this? I have done it in IndexedDB in JavaScript and had to use the proper callback API (1), because otherwise transactions break. I guess you cannot do channel operations inside a JDBC operation since they are executed in the threadpool (by the state-machine) while each JDBC connection seems to be pinned to a thread, so you cannot participate in the same transaction from another thread of the threadpool. But if you can wrap your blocking JDBC stuff in a singular thread call, you might be able to use async/thread (probably less than you
Re: Current best-of-breed JDBC libraries?
We tried Korma but found it too limiting for our needs. Later, I saw this tweet: https://twitter.com/ibdknox/status/557236505639665664 We are currently using HoneySQL to generate SQL which then gets passed to clojure.java.jdbc. e On Tue, Feb 24, 2015 at 9:04 AM, Colin Yates colin.ya...@gmail.com wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing pulley.cps
Sure, you can write code in CPS style by hand. Javascript developers do it all the time. But it's a very tedius, mechanical transformation. And tedius, mechanical transformations are what Lisps excel at ;-) We could also ask why we would want (reified) continuations? From a theoretical point of view, continuations are the fundamental basis for control flow. If continuations are reified as a first-class construct, then we have a basis for implementing all sorts control-flow constructs. For example, cooperative multitasking (green threads) is almost trivial to implement with continuations. Mitchell Wand's Continuation-Based Multiprocessing ftp://ftp.ccs.neu.edu/pub/people/wand/papers/hosc-99.ps is a good read for this application. Finally, the combination of CPS with thunking and trampolining gives us tail call optimization for free. This allows us to express many complex iterative processes in a recursive, functional, manner while retaining space efficiency. Some people find this more natural than iterative alternatives, such as state machines. Again, this can be done by hand, but is very tedious. Nathan Davis On Tue, Feb 24, 2015 at 3:03 AM, Vladimir Bokov bokov.v...@gmail.com wrote: Hi, Nathan Would you like to describe shortly, why one would need such transformation. What are the benefits and what prevents to write code in CPS style by hand? p.s. sorry, I'm far from being expert in this field :) четверг, 19 февраля 2015 г., 23:45:10 UTC+6 пользователь Nathan Davis написал: Dear Fellow Clojurians, I'm pleased to annouce release 0.1.0 of pulley.cps, a tool for transforming Clojure code into Continuation-Passing-Style. You can find it at http://github.com/positronic-solutions/pulley.cps. While this is not the first attempt at such a tool, to the best of my knowledge it is the most complete to date. The rather lengthy Readme (which for now also doubles as User Guide, API Documentation, and design document) goes into more detail, but here's a quick run-down of features: - Two macros, cps and cps-fn, serve as primary entry points for transforming code. - Transformed code can call native code (non-transformed functions and Java methods) and vice versa. - Due to the nature of CPS, we get tail-call optimization for free (i.e., all tail-calls within transformed code are naturally TCO'd). Of course, calls from CPS to native code still consume Java stack space, and non-tail calls within transformed code will consume *heap* space. - Dynamic bindings are fully supported, and do not interfere with TCO (binding is fully tail-call optimizable). set! is not currently implement for dynamic vars, but due to some recent changes to the way dynamic environments are implemented should be trivial to support. - Since with CPS we explicitly pass the continuation around, it is easy to expose the current continuation to the user. This is accomplished via the function call-cc and its macro analog let-cc. - Exceptions are not currently implemented. However, they are actively being worked on. The expectation here is that exceptions will work pretty much seamlessly with native exceptions, and you will be able to use the same forms (throw, try, catch, finally) as you would in regular Clojure code. - The ability to override native functions with a CPS implementation, in order to provide an optimal experience. For example, clojure.core/apply is overridden to provide an optimized implementation when invoked from CPS code. So if you call apply with a CPS function, continuations, TCO, etc. will still work. Overall, the goal is to be able to automatically transform as much regular clojure code into CPS while maintaining seamless interoperation with native Clojure code. The one area I don't think we'll manage to do a satisfactory job on are forms that create Java types (reify, deftype, genclass, etc.). These forms are currently completely unsupported, and any potential future support will most likely consist of simply escaping the transformation process when these forms are encountered. Other than that, once exception support is completed, I think this goal will be within reach. Near-term development goals are first to implement exceptions. Then I'd like to explore expanding platform support beyond the JVM, namely ClojureCLR and ClojureScript. Anyway, feel free to give things a try. I greatly treasure your feedback, including bug reports and if you have trouble navigating the documentation. Have fun, Nathan Davis -- 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
Re: Current best-of-breed JDBC libraries?
I've done a fair bit of complex SQL with honeysql, and must say it rocks. It could use a bit more documentation where extending it with new clauses is concerned, though. For my latest project being able to manipulate the datastructures that are rendered to SQL was crucial, and honeysql was the only one that fitted that bill. Basically, it generates SQL scripts to relink foreign key references to clean up duplicates in a database. It takes a honeysql select query with (at least) a from table, a group-by and an order-by clause as a base definition what are to be considered doubles, and in which order records should be preserved. In combination with JDBC metadata that query effectively gets rewritten to generate: A temporary replacement table Queries to unify unique indexes, to prevent clashes when foreign key references are updated Queries to update all foreign key references Delete statements to remove all duplicates To create the best performing, but still database independent SQL, I had to extend honeysql with extra clauses like OVER and PARTITION BY. I wouldn't say it was a breeze, but seemed to work very well. Compared to the previous version I wrote in Ruby (without these clauses), the SQL now only scales with the amount of unique / foreign key constraints, instead of the amount of doubled sets. That cut down SQL to (sometimes) GB's of script to around a few 100 lines of SQL, and on one occasion, a runtime from 19 hours to 1.5 minutes. All in all, pretty impressed with Clojure and HoneySQL. On Tuesday, February 24, 2015 at 3:04:36 PM UTC+1, Colin Yates wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
+1 to all of that. We are using honeysql to serve our ad-hoc reporting engine. Composing data structures for the win. On 24 February 2015 at 15:12, Niels van Klaveren niels.vanklave...@gmail.com wrote: I've done a fair bit of complex SQL with honeysql, and must say it rocks. It could use a bit more documentation where extending it with new clauses is concerned, though. For my latest project being able to manipulate the datastructures that are rendered to SQL was crucial, and honeysql was the only one that fitted that bill. Basically, it generates SQL scripts to relink foreign key references to clean up duplicates in a database. It takes a honeysql select query with (at least) a from table, a group-by and an order-by clause as a base definition what are to be considered doubles, and in which order records should be preserved. In combination with JDBC metadata that query effectively gets rewritten to generate: A temporary replacement table Queries to unify unique indexes, to prevent clashes when foreign key references are updated Queries to update all foreign key references Delete statements to remove all duplicates To create the best performing, but still database independent SQL, I had to extend honeysql with extra clauses like OVER and PARTITION BY. I wouldn't say it was a breeze, but seemed to work very well. Compared to the previous version I wrote in Ruby (without these clauses), the SQL now only scales with the amount of unique / foreign key constraints, instead of the amount of doubled sets. That cut down SQL to (sometimes) GB's of script to around a few 100 lines of SQL, and on one occasion, a runtime from 19 hours to 1.5 minutes. All in all, pretty impressed with Clojure and HoneySQL. On Tuesday, February 24, 2015 at 3:04:36 PM UTC+1, Colin Yates wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
I'm currently using and maintaining this two: https://github.com/niwibe/clojure.jdbc - A clojure.java.jdbc alternative. https://github.com/niwibe/suricatta - High level Sql toolkit (slightly higher level abstraction over plain jdbc and includes sql dsl) Cheers. Andrey 2015-02-24 15:11 GMT+01:00 Colin Yates colin.ya...@gmail.com: Actually, https://github.com/krisajenkins/yesql, now that it supports named parameters is probably just the ticket... On Tuesday, 24 February 2015 14:04:36 UTC, Colin Yates wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Andrey Antukh - Андрей Антух - andrei.anto...@kaleidos.net / n...@niwi.be http://www.niwi.be http://www.niwi.be/page/about/ https://github.com/niwibe -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Current best-of-breed JDBC libraries?
Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
Actually, https://github.com/krisajenkins/yesql, now that it supports named parameters is probably just the ticket... On Tuesday, 24 February 2015 14:04:36 UTC, Colin Yates wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Buddy 0.4.0: Security library for clojure.
Hi, What I like about buddy is that I can define access rules like this: https://funcool.github.io/buddy-auth/latest/#access-rules It gives me the ability to have the rules in one place and adjust them with patterns as I wish, it reminds me of shiro and I really like that approach. Best Regards, Sven Am Montag, 23. Februar 2015 02:25:43 UTC+1 schrieb Dave Sann: buddy-auth vs friend? What is the difference/motivation? On Monday, 23 February 2015 06:32:22 UTC+11, g vim wrote: On 22/02/2015 11:36, Andrey Antukh wrote: Documentation: https://funcool.github.io/buddy-core/latest/ https://funcool.github.io/buddy-auth/latest/ https://funcool.github.io/buddy-hashers/latest/ https://funcool.github.io/buddy-sign/latest/ Great addition to Clojure web development security. For new users might I suggest adding a namespace table to -core, -hashers and -sign as with -auth? gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
On Feb 24, 2015, at 6:04 AM, Colin Yates colin.ya...@gmail.com wrote: What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? At World Singles, all our MySQL interaction is done through clojure.java.jdbc (which I maintain), and HoneySQL for our more complex reporting queries. We like the composability of HoneySQL for complex stuff. We have a small wrapper around clojure.java.jdbc for basic CRUD stuff (get-by-id, delete-by-id, find-by-keys) that encapsulates the identifier/entity mappings and the DB connections we use, but we’re slowly moving away from that toward raw clojure.java.jdbc and leveraging the :row-fn and :result-set-fn keys more. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
I haven't used it but I remember building up pages of SQL in Clojure wasn't fun. The idea of putting that SQL into a .sql file, accessible by non-Clojure DB developer is very appealing. On 24 February 2015 at 18:24, Niels van Klaveren niels.vanklave...@gmail.com wrote: Perhaps I'm missing something, but I don't really see the advantages of yesql over standard parametrized clojure.java.jdbc queries ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
OK - thanks all. I am surprised that yesql isn't more adopted, particularly now named parameters is there - has anyone run into roadblocks with it? On 24 February 2015 at 16:50, Sean Corfield s...@corfield.org wrote: On Feb 24, 2015, at 6:04 AM, Colin Yates colin.ya...@gmail.com wrote: What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? At World Singles, all our MySQL interaction is done through clojure.java.jdbc (which I maintain), and HoneySQL for our more complex reporting queries. We like the composability of HoneySQL for complex stuff. We have a small wrapper around clojure.java.jdbc for basic CRUD stuff (get-by-id, delete-by-id, find-by-keys) that encapsulates the identifier/entity mappings and the DB connections we use, but we’re slowly moving away from that toward raw clojure.java.jdbc and leveraging the :row-fn and :result-set-fn keys more. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
Perhaps I'm missing something, but I don't really see the advantages of yesql over standard parametrized clojure.java.jdbc queries ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
On Feb 24, 2015, at 9:16 AM, Colin Yates colin.ya...@gmail.com wrote: I am surprised that yesql isn't more adopted, particularly now named parameters is there - has anyone run into roadblocks with it? Most of our SQL is dynamically created -- data-driven -- so YeSQL isn't really a good fit, as I understand it. We're either building SQL from a map of key/value pairs or from composable pieces using HoneySQL (for our complex reports that are all driven by data as well). Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
Honeysql has to be one of the best examples of data transformation
where Clojure really shines. {domain-data} - {honey-sql data} - SQL.
Love it.
I understand YeSQL's sweet spot is where the SQL is static except for
parameters so yeah, not applicable for building up queries at runtime.
Still, if SQL is known up front then it seems very nice.
On 24 February 2015 at 18:10, Sean Corfield s...@corfield.org wrote:
On Feb 24, 2015, at 9:16 AM, Colin Yates colin.ya...@gmail.com wrote:
I am surprised that yesql isn't more adopted, particularly now named
parameters is there - has anyone run into roadblocks with it?
Most of our SQL is dynamically created -- data-driven -- so YeSQL isn't
really a good fit, as I understand it. We're either building SQL from a map
of key/value pairs or from composable pieces using HoneySQL (for our complex
reports that are all driven by data as well).
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
I ran through all of the above and found it easier just to build my queries straight and call with clojure.java.jdbc. But my needs were light. On Tue, Feb 24, 2015 at 10:40 AM, Colin Yates colin.ya...@gmail.com wrote: I haven't used it but I remember building up pages of SQL in Clojure wasn't fun. The idea of putting that SQL into a .sql file, accessible by non-Clojure DB developer is very appealing. On 24 February 2015 at 18:24, Niels van Klaveren niels.vanklave...@gmail.com wrote: Perhaps I'm missing something, but I don't really see the advantages of yesql over standard parametrized clojure.java.jdbc queries ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Current best-of-breed JDBC libraries?
I actually prefer yesql for most of my Clojure-SQL interaction. Since a significant portion of my job involves me writing and optimizing SQL queries, I like being able to seamlessly switch between psql, org-babel's sql mode, and yesql with a simple cut and paste operation. For extra emacs sexiness, check out the yesql-ghosts package in MELPA. This automatically inserts all of the imported function signatures (as defns) as a text overlay below any (defqueries ...) form when a clojure buffer is in cider-mode. Keep on hackin' in the free world, ~Gary On Tuesday, February 24, 2015 at 9:04:36 AM UTC-5, Colin Yates wrote: Hi all, What are you all using for interacting with an RDBMS? In the past I looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just rocks). I have lost touch a bit - any recommendations? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How not to drop core.async publication items?
My test case would be something like this:
;; I have a channel that I want to wrap in a publication
(def publisher (async/chan))
(def publication (async/pub publisher :topic))
;; then I put data into the publisher channel
(async/put! publisher {:topic :foo :payload first message})
;; then I create a channel to read data from that publication
(def reader (async/chan))
(async/sub publication :foo reader)
(async/go (println value is: (async/! reader)))
;; nothing happens since the publication already read the value and dropped
it
;; if I send another message, this time it will be read by the ! above
(async/put! c1 {:topic :foo :msg second message})
== value is {:topic :foo :msg second message}
Is there a way not to lose that first item?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: should edn recognise defrecord?
The edn format does not include records. The transit README gives an example
of how to write a transit handler for a record. See the section on
extensibility.
https://github.com/cognitect/transit-format#extensibility
https://github.com/cognitect/transit-format#extensibility
Before transit existed, there was a little library that I used to encode a
Clojure record as a tagged literal (for edn compatibility). It’s only for the
Clojure side at the moment, but I imagine it wouldn’t be hard to port to CLJS.
However, I suggest that you use transit.
https://github.com/miner/tagged https://github.com/miner/tagged
On Feb 24, 2015, at 4:40 PM, Colin Yates colin.ya...@gmail.com wrote:
I am sending instances of defrecords from clojurescript via transmit/edn and
getting:
2015-Feb-24 19:23:52 + dev-os-mbp.local DEBUG [taoensso.sente] - Bad
package: [[:client/message #health.shared.domain.PingCommand{}]]
(clojure.lang.ExceptionInfo: No reader function for tag
health.shared.domain.PingCommand {:type :reader-exception})
The defrecord is defined using cljx and is definitely there on the server.
Do I need to write a reader function to recognise instances of defrecord - my
assumption was that this should just work?
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can someone offer refactoring suggestions for my protocol example?
It’s probably fine to do a linear search with .indexOf for small vectors, but I’ll just say as a matter of style I prefer to use a couple of maps to hold previous and next items. The maps are callable like functions, which I think reads very nicely. Using your example data for ranks: ;; helper functions (defn prev-map [coll] (zipmap (rest coll) coll)) (defn next-map [coll] (zipmap coll (rest coll))) (def ranks [:private :corporal :sergeant :lieutenant :captain :major :colonel :general]) (def previous-rank (prev-map ranks)) (def next-rank (next-map ranks)) (next-rank :corporal) ;= :sergeant Perhaps, in your example with promotions you'd want the end items to stick rather than return nil for the overflow cases. (In other situations, you might want to wrap around.) (defn bounded-prev-map [coll] (assoc (zipmap (rest coll) coll) (first coll) (first coll))) (defn bounded-next-map [coll] (let [lst (if (vector? coll) (peek coll) (last coll))] (assoc (zipmap coll (rest coll)) lst lst))) Just a suggestion. On Feb 23, 2015, at 1:44 PM, Daniel Hinojosa dh.evolutionn...@gmail.com wrote: This example works, but it still has the feel of a lot of duplication, are there any refactorings that I can do to this to make it more concise? https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] thi.ng collection update (CLJ/CLJS)
Hi guys, thi.ng is a collection of over a dozen largely x-platform Clojure Clojurescript libs for computational/generative design data visualization tasks. I just wanted to give a little heads up that this project has recently seen a number of releases and, as a whole, by now is generally quite stable and usable (*is used*) for realworld projects (although most libs remain in constant parallel development to make them more feature complete). I've collated a number of images of projects and links to the most important libs here: http://thi.ng/ Most notably of those: http://thi.ng/geom By far the largest sub-project and backbone for most others: A 2D/3D geometry package w/ comprehensive vector algebra, swizzling, intersections, matrix types helpers, quaternions, pure shape primitives with ~50 protocols for polymorphic enquiry manipulation, meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics engine (only particles, springs, behaviors)... Most of this lib is pure geometry w/ no rendering specifics, although there're separate modules for SVG rendering w/ shader support decorators [1], WebGL wrapper and converters from shapes/meshes to VBOs and various shader presets/utils. http://thi.ng/shadergraph GLSL (WebGL) pure function library dependency graph (based on com.stuartsierra/dependency), GLSL minification during CLJS compile time http://thi.ng/color RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes) http://thi.ng/luxor Complete scene compiler DSL for http://luxrender.net, based around thi.ng/geom http://thi.ng/morphogen Declarative 3D form evolution through tree-based transformations, basically an AST generator of geometric operations to transform a single seed node into complex 3D objects http://thi.ng/tweeny Interpolation of nested (presumably animation related) data structures. Allows tweening of deeply nested maps/vectors with completely flexible tween fns/targets and hence easy definition of complex timelines http://thi.ng/validate Purely functional, composable data validation optional corrections for nested data. Supports both maps vectors, wildcards, comes with many predefined validators, but extensible... http://thi.ng/trio A generic, non-RDF specific triple store API and feature rich SPARQL-like query engine (and my prime example of using the literate programming approach with org-mode[2][3]) Last but not least: Super special thanks are due to the following people: Rich, Alex + rest of clojure.core David (+everyone else involved) for the immense effort on making CLJS proper useful, Chas, Kevin and anyone else working on CLJX... none of this would have been possible without these amazing tools! Best, K. Ps. There're a number of other libs in this collection which are in dire need of updating (last touched spring 2013) - these are related to general OpenCL functionality and voxel rendering. Some of the example images on the above site were created with these... [1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org [2] https://github.com/thi-ng/trio/blob/master/src/query.org [3] http://orgmode.org/ -- Karsten Schmidt http://postspectacular.com | http://thi.ng/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
