[ANN] Onyx 0.5.3: Flow Conditions
Onyx is a distributed, masterless, fault tolerant data processing system for Clojure. Version 0.5.3 is out with a new feature called Flow Conditions. Flow Conditions isolate logic for message routing within your cluster, offering extraordinary flexibility for runtime specification. Blog post: http://michaeldrogalis.github.io/jekyll/update/2015/03/04/Onyx-0.5.3:-Flow-Conditions.html GitHub: https://github.com/MichaelDrogalis/onyx Gitter: https://gitter.im/MichaelDrogalis/onyx Thanks to everyone who helped with this release! -- 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID
Thanks for the extra analysis. My feeling was that it would be possible, but I wasn't sure. Luckily my current use cases don't depend on keeping UUIDs secret, but I was still wondering if there was a trade off. A mention in the docs seems worthwhile. Cheers On 4 Mar 2015, at 21:40, danle...@gmail.com danle...@gmail.com wrote: Also, if someone were given another time based UUID to use as a basis of comparison, they could eliminate 47 more bits of randomness to guess at. So, I think you make a good point that I think will be worthwhile to mention in my documentation. Thank you. -- 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: [ClojureScript] Re: IMPORTANT: ClojureScript Firefox Nightly ES6 Issue
I just cut 0.0-2985. This is only for people who need to and can upgrade to address the FireFox Nightly issue. No release information for this. There's a proper release coming this week or next which will enumerate the changes since 0.0-2913. David On Wed, Mar 4, 2015 at 3:38 AM, Mitchel Kuijpers mitchelkuijp...@gmail.com wrote: On Tuesday, March 3, 2015 at 11:12:03 PM UTC+1, David Nolen wrote: If you have a ClojureScript based product and your customers use FireFox Nightly you will encounter trouble due to a RegExp detection bug in prior ClojureScript releases interacting with recent Firefox ES6 related changes. Here's the ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1138325 We've already landed a fix in master, but if this is a show-stopping problem for you *today* I would express your concerns on the linked ticket. Also more than happy to cut a quick ClojureScript release if that helps people as well. David Aha this was why my app stopped working yesterday in firefox developer edition.. I wouldn't mind a quick clojurescript release :) -- 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.
Re: [ANN] Understanding the Persistent Vector
Hi Frank, On Wednesday, March 4, 2015 at 12:24:42 PM UTC+1, Frank Castellucci wrote: Will you be doing this for other data types? I will have a small break first, but I intend to do the same kind of series for persistent hash maps/sets. Maybe even RRB-trees if people are interested (I found them to be pretty hard to grasp by the paper alone). Again, Great Work! Thanks! =) -- Jean Niklas Frank On Saturday, February 28, 2015 at 11:14:17 AM UTC-5, Jean Niklas L'orange wrote: Hello fellow Clojurians, I am happy to announce that I have finished my blogpost series on the persistent vector. It consists of five parts: 1. The basic algorithms http://hypirion.com/musings/understanding-persistent-vector-pt-1 2. Indexing http://hypirion.com/musings/understanding-persistent-vector-pt-2 3. The tail optimisation http://hypirion.com/musings/understanding-persistent-vector-pt-3 4. Transients http://hypirion.com/musings/understanding-clojure-transients 5. Performance http://hypirion.com/musings/persistent-vector-performance-summarised (which is a summary of this detailed blogpost http://hypirion.com/musings/persistent-vector-performance) I hope this will help you to get a good understanding of how the algorithms on the data structure work, how the optimisations work, and how efficient it is on the JVM. Constructive criticism, both positive and negative, is appreciated. Enjoy! (NB: I haven't gotten around to fix the illustrations in part 3, so unfortunately it will be a bit hard to read if you print it out in grayscale. It's on my todo-list.) -- Jean Niklas L'orange -- 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] EuroClojure 2015
EuroClojure has been a great conference for Clojure for several years - big thanks to Marco Abis and the community for all of their hard work. To ensure the continued excellence and growth of the conference, we are excited that EuroClojure has joined the Cognitect ecosystem. Marco has been helping us and will continue to help make this conference awesome and importantly to preserve the unique style of EuroClojure. We want to thank him for creating the vibrant community event it has already become. EuroClojure now joins Clojure/conj (in the fall) and Clojure/West (April 20-22, Portland, OR) in our lineup. We’re working on an exact date and location for EuroClojure 2015, and should be able to announce that within the week so stay tuned. Marco and the Cognitect folks are all excited about this and looking forward to seeing you all this summer. Contact us at eve...@cognitect.com for questions or to learn more about this. -- 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID
Yep. I can't overstate how useful feedback from this group has been to find new ways to optimize the code and to try to make the documentation more clear and useful. On Wednesday, March 4, 2015 at 11:17:30 AM UTC-5, Lucas Bradstreet wrote: Thanks for the extra analysis. My feeling was that it would be possible, but I wasn't sure. Luckily my current use cases don't depend on keeping UUIDs secret, but I was still wondering if there was a trade off. A mention in the docs seems worthwhile. Cheers On 4 Mar 2015, at 21:40, danl...@gmail.com javascript: danl...@gmail.com javascript: wrote: Also, if someone were given another time based UUID to use as a basis of comparison, they could eliminate 47 more bits of randomness to guess at. So, I think you make a good point that I think will be worthwhile to mention in my documentation. Thank you. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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.
Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which resolves
to a thread local database connection. In addition, one might itself have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething and
an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the first
argument to the protocol but this isn't appropriate in this case as there
are validly multiple implementations. I could abstract a 'unit-of-work' and
pass that as the first argument to the protocols but that seems a bit
painful.
Also, these protocols may be used quite far away from where the database
code lives and passing a parameter all the way through the call stack is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and
that I have something upside down.
What do you all do?
--
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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
And just to be clear - I get _why_ explicit parameter passing is a good
idea, or rather why dynamic binding is frowned upon, I am asking for
practical help with the consequences of that decision.
I also get the argument that a transaction changes at runtime state and so
shouldn't be part of the (Stuart Sierra's) component lifecycle, but I can't
be the only one to run into this; func-a calls func-b calls func-c which
needs some state - the answer can't be for func-a to pass it to func-b
particularly when neither of them know anything about the internals of
func-c.
On Wednesday, 4 March 2015 17:58:58 UTC, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which resolves
to a thread local database connection. In addition, one might itself have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols but
that seems a bit painful.
Also, these protocols may be used quite far away from where the database
code lives and passing a parameter all the way through the call stack is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and
that I have something upside down.
What do you all do?
--
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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
Having never used Spring (or anything else resembling the style of code you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do this
for Datomic all of the time, and the boilerplate looks something like this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure exactly
how this would fit into JDBC, but I'm sure you can figure it out if you
think it would be worthwhile.
I then pass the database component to any other component in my system that
I know will make use of it. If used in a middleware-like scenario (where an
arbitrary function is passed to the component, possibly composed with other
functions, and invoked elsewhere), I usually have a convention where I pass
a map of options as an argument to the handler, and make the database a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which resolves
to a thread local database connection. In addition, one might itself have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols but
that seems a bit painful.
Also, these protocols may be used quite far away from where the database
code lives and passing a parameter all the way through the call stack is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and
that I have something upside down.
What do you all do?
--
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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
Ah I think I understand now! Is it possible to dereference the connection
and hold on to the thread local state? If so, then dynamically binding
the transactional connection and doing all of your work within that context
might be a good solution. You can also write a macro to do this,
closing/doing cleanup of the connection before exiting the dynamic scope of
your transaction.
On Wednesday, March 4, 2015 at 1:15:02 PM UTC-5, Colin Yates wrote:
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection to a thread local and
then passes a connection proxy around - accessing that proxy magically
(through the use of the lovely AOP) resolves to the current
thread-local transactional connection.
I don't see any option other than to re-implement that in Clojure or
pass an explicit 'unit-of-work' around but it all feels wrong in
Clojure.
The problem at the moment is that the implementation of each protocol
will execute in separate transactions.
On 4 March 2015 at 18:06, adrian...@mail.yu.edu javascript: wrote:
Having never used Spring (or anything else resembling the style of code
you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do
this
for Datomic all of the time, and the boilerplate looks something like
this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure
exactly
how this would fit into JDBC, but I'm sure you can figure it out if you
think it would be worthwhile.
I then pass the database component to any other component in my system
that
I know will make use of it. If used in a middleware-like scenario (where
an
arbitrary function is passed to the component, possibly composed with
other
functions, and invoked elsewhere), I usually have a convention where I
pass
a map of options as an argument to the handler, and make the database a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which
resolves
to a thread local database connection. In addition, one might itself
have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a
JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will
have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case
as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols but
that
seems a bit painful.
Also, these protocols may be used quite far away from where the
database
code lives and passing a parameter all the way through the call stack
is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and
that
I have something upside down.
What do you all do?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
javascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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
Re: Any Lispers in South Devon, UK?
Only if you promise to move up to Leicester :). On 4 March 2015 at 13:14, John Kane j...@kanej.me wrote: Hello Stephen, There is a small group of us based around Exeter and we are trying to get a group off the ground, is that close enough to be of interest? John On Tuesday, 3 March 2015 21:53:57 UTC, Stephen Wakely wrote: Hi, Are there any other Lispers in South Devon who would be interested in meeting up and talking code? Clojure, Common Lisp, Scheme, anything as long as there are loads of parentheses! Please get in touch. Cheers Stephen -- 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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
In my previous project we were using high order functions to wrap
everything in a transaction.
So we would have stuff like this:
(require [clojure.java.jdbc :as db])
(defn create-foo-entity [entity]
[(fn [conn] (db/insert! ...))])
(defn create-bar-entity [entity]
[(fn [conn] (db/insert! ...)) (fn [conn] (db/update! ...))])
(defn execute-sql [sql-fns]
(db/with-db-transaction ... (dorun (map #(statement conn) sql-fns
(execute-sql (concat (create-foo-entity entity1) (create-bar-entity entity2))
*--*
*Eduardo Aquiles Radanovitsck*
ThoughtWorks Brasil
On Wed, Mar 4, 2015 at 3:14 PM, Colin Yates colin.ya...@gmail.com wrote:
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection to a thread local and
then passes a connection proxy around - accessing that proxy magically
(through the use of the lovely AOP) resolves to the current
thread-local transactional connection.
I don't see any option other than to re-implement that in Clojure or
pass an explicit 'unit-of-work' around but it all feels wrong in
Clojure.
The problem at the moment is that the implementation of each protocol
will execute in separate transactions.
On 4 March 2015 at 18:06, adrian.med...@mail.yu.edu wrote:
Having never used Spring (or anything else resembling the style of code
you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do
this
for Datomic all of the time, and the boilerplate looks something like
this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure
exactly
how this would fit into JDBC, but I'm sure you can figure it out if you
think it would be worthwhile.
I then pass the database component to any other component in my system
that
I know will make use of it. If used in a middleware-like scenario (where
an
arbitrary function is passed to the component, possibly composed with
other
functions, and invoked elsewhere), I usually have a convention where I
pass
a map of options as an argument to the handler, and make the database a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which
resolves
to a thread local database connection. In addition, one might itself
have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a
JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will
have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case
as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols but
that
seems a bit painful.
Also, these protocols may be used quite far away from where the database
code lives and passing a parameter all the way through the call stack is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and
that
I have something upside down.
What do you all do?
--
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.
Re: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection to a thread local and
then passes a connection proxy around - accessing that proxy magically
(through the use of the lovely AOP) resolves to the current
thread-local transactional connection.
I don't see any option other than to re-implement that in Clojure or
pass an explicit 'unit-of-work' around but it all feels wrong in
Clojure.
The problem at the moment is that the implementation of each protocol
will execute in separate transactions.
On 4 March 2015 at 18:06, adrian.med...@mail.yu.edu wrote:
Having never used Spring (or anything else resembling the style of code you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do this
for Datomic all of the time, and the boilerplate looks something like this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure exactly
how this would fit into JDBC, but I'm sure you can figure it out if you
think it would be worthwhile.
I then pass the database component to any other component in my system that
I know will make use of it. If used in a middleware-like scenario (where an
arbitrary function is passed to the component, possibly composed with other
functions, and invoked elsewhere), I usually have a convention where I pass
a map of options as an argument to the handler, and make the database a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which resolves
to a thread local database connection. In addition, one might itself have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols but that
seems a bit painful.
Also, these protocols may be used quite far away from where the database
code lives and passing a parameter all the way through the call stack is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is surprisingly
unhelpful which makes me think I have missed something fundamental, and that
I have something upside down.
What do you all do?
--
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
Re: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
(if it's just a regular ThreadLocal, you should be able to get its value
through (.get tx))
To elucidate briefly, I mean something like this:
(def ^:dynamic *tx*)
;; elsewhere
(binding [*tx* (.get tx)]
...do stuff
...cleanup)
a with-tx macro would make this pattern reusable throughout your code.
On Wednesday, March 4, 2015 at 1:43:36 PM UTC-5, adrian...@mail.yu.edu
wrote:
Ah I think I understand now! Is it possible to dereference the connection
and hold on to the thread local state? If so, then dynamically binding
the transactional connection and doing all of your work within that context
might be a good solution. You can also write a macro to do this,
closing/doing cleanup of the connection before exiting the dynamic scope of
your transaction.
On Wednesday, March 4, 2015 at 1:15:02 PM UTC-5, Colin Yates wrote:
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection to a thread local and
then passes a connection proxy around - accessing that proxy magically
(through the use of the lovely AOP) resolves to the current
thread-local transactional connection.
I don't see any option other than to re-implement that in Clojure or
pass an explicit 'unit-of-work' around but it all feels wrong in
Clojure.
The problem at the moment is that the implementation of each protocol
will execute in separate transactions.
On 4 March 2015 at 18:06, adrian...@mail.yu.edu wrote:
Having never used Spring (or anything else resembling the style of code
you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do
this
for Datomic all of the time, and the boilerplate looks something like
this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure
exactly
how this would fit into JDBC, but I'm sure you can figure it out if you
think it would be worthwhile.
I then pass the database component to any other component in my system
that
I know will make use of it. If used in a middleware-like scenario
(where an
arbitrary function is passed to the component, possibly composed with
other
functions, and invoked elsewhere), I usually have a convention where I
pass
a map of options as an argument to the handler, and make the database a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which
resolves
to a thread local database connection. In addition, one might itself
have a
collaborator which itself has a collaborator which needs a datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a
JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an
IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they will
have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this case
as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols
but that
seems a bit painful.
Also, these protocols may be used quite far away from where the
database
code lives and passing a parameter all the way through the call stack
is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is
surprisingly
unhelpful which makes me think I have missed something fundamental,
and that
I have something upside down.
What do you all do?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are
Re: How to persist a value while doing do-seq
Probably a reduce is more appropriate. (reduce (fn [x a] (your-compare-expression x a) ; the result of this expr is the result of the fn and will be 'x' for the next iteration ) 0 b) BTW, a let to bind an atom outside your do-seq, while _not recommended_, should work. We would have to see your code to know why it didn't for you. Show you code if you're curious, but please don't actually do it this way. On Tue, Mar 3, 2015 at 10:26 PM, noobcoder kely...@gmail.com wrote: Hi, I have the following code structure (do-seq [a b] . . . ) For each a in b, I want to check a particular value in a, store it and compare it with the same value in next a. If it is same I want to clear it before next a. I tried to define an x (atom 0) by having a let outside of the do-seq. I can successfully compare the value of the atom and reset it, but when I get the second a the atom value is again 0. How do I go about this? -- 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: Idiomatic way to co-ordinate 'disconnected' services into a single transaction (ala Spring's @Transactional functionality)?
Yeah, that is the conclusion I came to, dynamic binding for the win, I
think :).
On 4 Mar 2015 18:47, adrian.med...@mail.yu.edu wrote:
(if it's just a regular ThreadLocal, you should be able to get its value
through (.get tx))
To elucidate briefly, I mean something like this:
(def ^:dynamic *tx*)
;; elsewhere
(binding [*tx* (.get tx)]
...do stuff
...cleanup)
a with-tx macro would make this pattern reusable throughout your code.
On Wednesday, March 4, 2015 at 1:43:36 PM UTC-5, adrian...@mail.yu.edu
wrote:
Ah I think I understand now! Is it possible to dereference the connection
and hold on to the thread local state? If so, then dynamically binding
the transactional connection and doing all of your work within that context
might be a good solution. You can also write a macro to do this,
closing/doing cleanup of the connection before exiting the dynamic scope of
your transaction.
On Wednesday, March 4, 2015 at 1:15:02 PM UTC-5, Colin Yates wrote:
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection to a thread local and
then passes a connection proxy around - accessing that proxy magically
(through the use of the lovely AOP) resolves to the current
thread-local transactional connection.
I don't see any option other than to re-implement that in Clojure or
pass an explicit 'unit-of-work' around but it all feels wrong in
Clojure.
The problem at the moment is that the implementation of each protocol
will execute in separate transactions.
On 4 March 2015 at 18:06, adrian...@mail.yu.edu wrote:
Having never used Spring (or anything else resembling the style of
code you
presented) I don't really know if I'm understanding what you're
asking.
However, it might be useful to wrap your database in a component. I do
this
for Datomic all of the time, and the boilerplate looks something like
this:
https://gist.github.com/aamedina/a1ca5e97c1a5d73fe141. I'm not sure
exactly
how this would fit into JDBC, but I'm sure you can figure it out if
you
think it would be worthwhile.
I then pass the database component to any other component in my system
that
I know will make use of it. If used in a middleware-like scenario
(where an
arbitrary function is passed to the component, possibly composed with
other
functions, and invoked elsewhere), I usually have a convention where I
pass
a map of options as an argument to the handler, and make the database
a
value in that map.
On Wednesday, March 4, 2015 at 12:58:58 PM UTC-5, Colin Yates wrote:
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which
resolves
to a thread local database connection. In addition, one might itself
have a
collaborator which itself has a collaborator which needs a
datasource.
So far I have two protocols:
(defprotocol IDoSomething
(do-something [this ...])
(defprotocol IDoSomethingElse
(do-something [this ...])
Each protocol may have a number of implementations, one of which is a
JDBC
implementation:
(defrecord JdbcIDoSomething [db]
(do-something [this ...] ...))
The problem is that the calling code only gets provided an
IDoSomething
and an IDoSomethingElse and it wants to do something like:
(let [one (-JdbcDoSomething db) two (-JdbcDoSomethingElse db)]
(with-transaction [tx db]
(do-something one)
(do-something-else two)))
The problem here is that the implementations of do-something and
do-something-else won't have access to the local bound 'tx', they
will have
their own 'db'.
I realise the general argument is to be explicit and pass a db as the
first argument to the protocol but this isn't appropriate in this
case as
there are validly multiple implementations. I could abstract a
'unit-of-work' and pass that as the first argument to the protocols
but that
seems a bit painful.
Also, these protocols may be used quite far away from where the
database
code lives and passing a parameter all the way through the call stack
is
painful.
I am using Stuart Sierra's components if that makes any difference.
I can't be the first person to run into this but google is
surprisingly
unhelpful which makes me think I have missed something fundamental,
and that
I have something upside down.
What do you all do?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from
Re: How to persist a value while doing do-seq
For examining adjacent items in a sequence, there are a few functional
(i.e., no mutable state) approaches.
When the output is a sequence with an element for each adjacent pair:
(map (fn [a b] ...) s (next s))
When the output is a sequence with an element for each adjacent pair that
meets some criterion:
(remove #{::removeme}
(map
(fn [a b]
(if (criterion a b)
(foo a b)
::removeme))
s (next s)))
OR
(for [[a b] (map vector s (next s))
:when criterion]
foo a b)
When the output is a single accumulated value:
(reduce foo (map vector s (next s)))
OR
(reduce foo (partition 2 1 s))
When the output is an accumulated value, with short-circuit when some pair
meets some criterion:
(reduce foo (take-while not-criterion (map vector s (next s
(criterion in that case takes a single parameter to destructure into two,
e.g. (fn [[a b]] ...) rather than (fn [a b] ...).)
When the output is a seq that should short-circuit when some pair meets
some criterion:
(map foo
(take-while not-criterion
(map vector s (next s)))
OR
(for [[a b] (map vector s (next s))
:while not-criterion]
(foo a b))
--
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: How to persist a value while doing do-seq
Consider using for, and returning the new set of values (for [[a b] (partition 2 1 coll)] (if (= (:foo a) (:foo b)) (dissoc a :foo) a)) Here I use partition so that each item can be compared to the one that follows it. You would likely want a final step that tacks on the last item in the input coll (since it is not processed by this code). On Wednesday, March 4, 2015 at 11:36:34 AM UTC-8, mlimotte wrote: Probably a reduce is more appropriate. (reduce (fn [x a] (your-compare-expression x a) ; the result of this expr is the result of the fn and will be 'x' for the next iteration ) 0 b) BTW, a let to bind an atom outside your do-seq, while _not recommended_, should work. We would have to see your code to know why it didn't for you. Show you code if you're curious, but please don't actually do it this way. On Tue, Mar 3, 2015 at 10:26 PM, noobcoder kel...@gmail.com javascript: wrote: Hi, I have the following code structure (do-seq [a b] . . . ) For each a in b, I want to check a particular value in a, store it and compare it with the same value in next a. If it is same I want to clear it before next a. I tried to define an x (atom 0) by having a let outside of the do-seq. I can successfully compare the value of the atom and reset it, but when I get the second a the atom value is again 0. How do I go about this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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: Any Lispers in South Devon, UK?
Hello Stephen, There is a small group of us based around Exeter and we are trying to get a group off the ground, is that close enough to be of interest? John On Tuesday, 3 March 2015 21:53:57 UTC, Stephen Wakely wrote: Hi, Are there any other Lispers in South Devon who would be interested in meeting up and talking code? Clojure, Common Lisp, Scheme, anything as long as there are loads of parentheses! Please get in touch. Cheers Stephen -- 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 to persist a value while doing do-seq
Hi, I have the following code structure (do-seq [a b] . . . ) For each a in b, I want to check a particular value in a, store it and compare it with the same value in next a. If it is same I want to clear it before next a. I tried to define an x (atom 0) by having a let outside of the do-seq. I can successfully compare the value of the atom and reset it, but when I get the second a the atom value is again 0. How do I go about this? -- 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: Any Lispers in South Devon, UK?
Awesome! I work in the middle of Exeter so that's definitely close enough. I would love to get involved. Do you guys have anything planned for a meet up? On 4 Mar 2015 19:13, John Kane j...@kanej.me wrote: Hello Stephen, There is a small group of us based around Exeter and we are trying to get a group off the ground, is that close enough to be of interest? John On Tuesday, 3 March 2015 21:53:57 UTC, Stephen Wakely wrote: Hi, Are there any other Lispers in South Devon who would be interested in meeting up and talking code? Clojure, Common Lisp, Scheme, anything as long as there are loads of parentheses! Please get in touch. Cheers Stephen -- 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: partition-when
I went though almost the exact same exercise and my code is almost identical to yours. I called it partition-every and I use it a lot. A more determined individual might submit this for inclusion into core! On Tuesday, March 3, 2015 at 2:46:29 PM UTC-5, Frank wrote: Hi all, for some tests I need a function which starts a new partition each time a predicate returns true, for instance: (partition-when (fn [s] (.startsWith s )) [ 1 2 3 4 5 6]) := [[ 1 2 3] [ 4 5 6]] Since I haven't found a built-in function, I copied, pasted, and modified the core function partition-by: (defn partition-when [f coll] (lazy-seq (when-let [s (seq coll)] (let [fst (first s) run (cons fst (take-while #(not (f %)) (next s)))] (cons run (partition-when f (seq (drop (count run) s Is there a better (more idiomatic) way to achieve the same result? Thank you in advance. Frank -- 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.
clojure map to java instance of pojo class
hi all,
is there some library or simple way to do it like the function
map-to-pojo in the following code ?
java code
class A{
public int a;
public String b;
}
clojure code
(def a {:a 1 :b 2})
(def b (map-to-pojo a A))
(instance? b A)
any solution is good.
Joe
--
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] Understanding the Persistent Vector
Hi Bost, Thanks for the input! Yeah, I agree it might be a bit confusing right now. I'll definitely change it to something that's a bit easier to grok, probably with some inspiration from your suggestion. On Tuesday, March 3, 2015 at 11:58:00 AM UTC+1, Bost wrote: Hi Jean The tail optimisation http://hypirion.com/musings/understanding-clojure-transients It took me a second to find out how the graphs for the vector-trie and tail correspond to each other. Please consider slightly deeper explanation or add some visual clues. Something like: http://picpaste.com/pics/tails-colored.1425379672.png -- 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] Understanding the Persistent Vector
Jean It's been added to the must reads list. Will you be doing this for other data types? Again, Great Work! Frank On Saturday, February 28, 2015 at 11:14:17 AM UTC-5, Jean Niklas L'orange wrote: Hello fellow Clojurians, I am happy to announce that I have finished my blogpost series on the persistent vector. It consists of five parts: 1. The basic algorithms http://hypirion.com/musings/understanding-persistent-vector-pt-1 2. Indexing http://hypirion.com/musings/understanding-persistent-vector-pt-2 3. The tail optimisation http://hypirion.com/musings/understanding-persistent-vector-pt-3 4. Transients http://hypirion.com/musings/understanding-clojure-transients 5. Performance http://hypirion.com/musings/persistent-vector-performance-summarised (which is a summary of this detailed blogpost http://hypirion.com/musings/persistent-vector-performance) I hope this will help you to get a good understanding of how the algorithms on the data structure work, how the optimisations work, and how efficient it is on the JVM. Constructive criticism, both positive and negative, is appreciated. Enjoy! (NB: I haven't gotten around to fix the illustrations in part 3, so unfortunately it will be a bit hard to read if you print it out in grayscale. It's on my todo-list.) -- Jean Niklas L'orange -- 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID
My pleasure! Just to be clear, clj-uuid does NOT use the hardware MAC address and does NOT pose any security concern. -- 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID
Also, if someone were given another time based UUID to use as a basis of comparison, they could eliminate 47 more bits of randomness to guess at. So, I think you make a good point that I think will be worthwhile to mention in my documentation. Thank you. -- 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID
It is a fair point about guessability, though, in the sense that you might be able to mount a brute force attack to guess a time based UUID, but it would not be easy. You would need to guess an effectively random 59 bit number (the low order bits) and then step through all possible time stamps millisecond by millisecond (the high order bits). If you had some means to know the specific range of time to search (and a very fast test to determine when you had guessed correctly) you would certainly improve your odds vs guessing a purely random UUID. Best, Dan On Wednesday, March 4, 2015, danle...@gmail.com danle...@gmail.com wrote: My pleasure! Just to be clear, clj-uuid does NOT use the hardware MAC address and does NOT pose any security concern. -- 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 javascript:; 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 javascript:; For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/D8l-qRqCyOw/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com javascript:;. 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.
