Re: [ANN] Jig

[Timothy Washington]

This is great. I tried digging into the code and saw the repo changing. So
I'm glad I didn't get too far down a path. I'll definitely have a look in
the next few days and have feedback for you.


Tim Washington
Interruptsoftware.ca / Bkeeping.com


On Thu, Oct 24, 2013 at 8:54 PM, Malcolm Sparks  wrote:

> Hi Tim,
>
> I've just pushed Jig 1.2.0 to https://github.com/juxt/jig.
>
> This release adds support for Ring and Compojure, which many people have
> asked for, including proper examples of using both Ring/Compojure and
> Pedestal services. There are numerous other components included (Git pull,
> JMX, nginx) to support an automated continuous deployment process.
>
> As you pointed out, there were missing details in my own work branches, so
> the packaged examples should hopefully make things clearer.
>
> Thanks for the feedback on using Jig, it is much appreciated, and please
> let me know if you still need some help with the specifics.
>
> Regards,
>
> Malcolm
>
>
>
>
>
>
> On Monday, 21 October 2013 21:14:32 UTC+1, frye wrote:
>
>> Hey Malcolm,
>>
>>
>> So since you guys just have Pedestal set up at the moment, I've started
>> there.
>>
>>
>> *My Repos *
>>
>> You can see my project jig 
>> here.
>> It connects to 
>> common
>> , 
>> compojure
>>  (not
>> yet configured), and 
>> pedestal-service
>>  **component. I'm trying to get the Pedestal portions working. Now, I
>> haven't yet been able to stitch together routes using the Pedestal "
>> :juxtweb/service" component you have. The ":server" component runs fine,
>> when executing (go). But the handlers don't seem to be attached. Do I
>> need a separate ":jig/projects" entry in my config?
>>
>> {
>>
>>  :jig/components
>>
>>
>>  {
>>
>>   ;; ===>
>>
>>   :server {:jig/component jig.web.server/Component
>>
>>
>>
>>
>>:io.pedestal.**service.http/port 8000
>>
>>:io.pedestal.**service.http/type :jetty}
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   :juxtweb/web {:jig/component jig.web.app/Component
>>
>>
>>
>> :jig/**dependencies [:server]
>>
>> :jig/scheme :http
>>
>> :jig/hostname "localhost"
>>
>> :jig.web/**server :server}
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   ;; ===>
>>
>>   :stefon-webui-common {:jig/component stefon-webui-common.core/**Component
>>
>>
>>
>>
>> :jig/**project 
>> "../stefon-webui-common/**project.clj"}
>>
>>
>>
>>
>>
>>   :stefon-compojure {:jig/component stefon-compojure.core/**Component
>>
>>
>>
>>  :jig/**project "../stefon-compojure/project.**clj"
>>
>>  :jig/**dependencies [:server
>>
>>
>>
>>   **  :stefon-webui-common**]}
>>
>>
>>   :stefon-pedestal {:jig/component 
>> stefon-pedestal-service.**service/Component
>>
>>
>>
>>
>> :jig/**project "../stefon-pedestal-service/**project.clj"
>>
>> :jig/**dependencies [:juxtweb/web
>>
>>
>>
>>   ** :stefon-webui-common]
>>
>> :jig.web/**app-name :juxtweb/web}
>>
>>
>>
>>   }}
>>
>>
>>
>>
>> *Juxt's Cloned Repos *
>>
>> So I tried cloning your example repos to see working example code. But
>> there's a few things that went awry.
>>
>>
>> *A)* I had to rename the cloned repo for the referencing in
>>  "jig/config/config.clj" to work (:jig/project
>> "../accounting/project.clj").
>>
>> ~/Projects/trial/*JIG*$ ls -la
>>accounting/   *;; had to `mv juxt-accounting accounting` *
>>jig/
>>juxtweb/
>>
>>
>> *B)* Also, you've hard-coded an accounts db file to your hard drive
>>
>> *java.io.FileNotFoundException: /home/malcolm/Dropbox.private/
>> JUXT/accounts.edn*
>>
>>
>>
>>
>> Tim Washington
>> Interruptsoftware.ca / Bkeeping.com
>>
>>
>> On Mon, Oct 21, 2013 at 3:57 AM, Malcolm Sparks  wrote:
>>
>>> Hi Tim,
>>>
>>> Good to hear you're finding Jig useful.
>>>
>>> There isn't any explicit support for Ring in Jig yet, it's just Pedestal
>>> services right now. The separation of jig.web.server and jig.web.app into 2
>>> components is to allow multiple 'virtual hosts' to share the same Jetty
>>> server, if necessary.
>>>
>>> It's a third component, usually your own, that actually adds routes to a
>>> virtual host. See the ReadmeComponent in examples/docsite/src/examples/*
>>> *docsite/core.clj 
>>> here.
>>> It adds routes in its init phase.
>>>
>>> The idea is that other components can be contribute routes in the same
>>> way, so you have the option of breaking up a

How to use core.cache to store the results of expensive computations?

[dgrnbrg]

I've been looking through examples of usages of core.cache, and I have not 
been able to understand how to make a ref or atom backed cache that offers 
a simple API to the application programmer: I want to provide a key and a 
thunk, and have the cache either return me the cached value (if it's in the 
cache), or invoke the thunk and store it in the cache, returning the 
thunk's value.

How can I do this?

Thanks,
David

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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/groups/opt_out.

Re: Request for help optimising a Clojure program

[Mark Engelberg]

On Fri, Oct 25, 2013 at 9:11 AM, Stuart Halloway
wrote:

> To save others from having to read this whole thread, is the following
> summary correct?
>
> 1. We believe that the performance issue Paul first encountered is
> substantially / entirely caused by hash collisions.
>

Yes.


>
> 2. The hash collisions could be improved by spreading the hashes of
> numbers (and not needing to mess with hashes of collections).
>

Yes.  Increasing the spread of the number hashes wouldn't solve all the
types of hash collisions we've discussed, but it would definitely help.
However, as David pointed out, there's a tradeoff between increasing the
complexity of the hashing function and the time saved by improving hash
collisions.  My intuition from playing around with this is that increasing
the complexity of hashing numbers from the current, dead-simple scheme
would be an overhead that would really be felt.  Two advantages of messing
with hashes at the collection level is that:
a. Collections are already doing reasonably complex things during hashing,
like traversing their elements.
b. The hash, once computed, can be cached.
Those two factors mean that adding a tiny amount of complexity to the hash
function of a collection is more likely to help than to hurt performance.



>
> If the above summary is correct, then I have the following questions:
>
> a. Is the approach Scala took substantially #2 above, or something
> different / more?
>

I don't believe that Scala altered the hashing of numbers, but I am not
certain.  All I know about Scala's hashing is what I've seen from following
some of the links that David Nolen has posted here.  It appears to me that
they made a variety of small improvements for different kinds of hashing.
For example, choosing different magic primes for strings versus collections
(Clojure mimics Java and uses 31 everywhere) helped with certain kinds of
collisions.  The link David posted is specifically about how they improved
case classes, which are similar to Clojure's records.  It looks like they
generate a custom hash function at compile time using knowledge of the
types of the element and an algorithm that munges together the individual
bytes of the items.  So I'd say that it looks like they did something in
the different / more category.


> b. Is changing the hash codes of numbers going to break expectations on
> the Java side of things?
>

I don't know.

-- 
-- 
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/groups/opt_out.

Re: Request for help optimising a Clojure program

[Cedric Greevey]

I don't see a general solution for idiomatic Clojure data (so, often not
records) other than making the hashes of small integers a spread-out,
nonlinear function of them.


On Fri, Oct 25, 2013 at 2:11 PM, Mark Engelberg wrote:

> On Fri, Oct 25, 2013 at 9:56 AM, David Nolen wrote:
>
>> What I suggested is far, far more conservative than anything else
>> proposed on this or on the dev thread.
>>
>
> I understand your point that records are a separate "island" unique to
> Clojure-land, whereas the other Clojure types need to align with Java, and
> therefore, are riskier to mess around with.  But I find it hard to get
> excited about a records-only solution, mainly because I hardly ever use
> records.  Using straight maps, sets, and vectors to represent data is
> perfectly ordinary and idiomatic in Clojure, e.g., Paul's initial code
> didn't use records to represent his objects.  So solving the problem just
> for records doesn't feel to me like much of a solution.
>
>
>
>>  I suspect we can duplicate the approach already taken by Scala for case
>> classes.
>>
>>
>>
> There are two things that jump out to me as things that might make it hard
> to mimic Scala's approach for case classes in Clojure's records:
> 1. Clojure records function like maps, and you can assoc more things into
> them after construction.  Scala is working with a fixed number of fields at
> compile time.
> 2. Scala knows the type of each of the fields at compile time, and so (if
> I understand their approach correctly), they can compile a custom hashing
> function for the case class that leverages the types of all its components
> for maximum speed.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Request for help optimising a Clojure program

[Mark Engelberg]

On Fri, Oct 25, 2013 at 9:56 AM, David Nolen  wrote:

> What I suggested is far, far more conservative than anything else proposed
> on this or on the dev thread.
>

I understand your point that records are a separate "island" unique to
Clojure-land, whereas the other Clojure types need to align with Java, and
therefore, are riskier to mess around with.  But I find it hard to get
excited about a records-only solution, mainly because I hardly ever use
records.  Using straight maps, sets, and vectors to represent data is
perfectly ordinary and idiomatic in Clojure, e.g., Paul's initial code
didn't use records to represent his objects.  So solving the problem just
for records doesn't feel to me like much of a solution.



>  I suspect we can duplicate the approach already taken by Scala for case
> classes.
>
>
>
There are two things that jump out to me as things that might make it hard
to mimic Scala's approach for case classes in Clojure's records:
1. Clojure records function like maps, and you can assoc more things into
them after construction.  Scala is working with a fixed number of fields at
compile time.
2. Scala knows the type of each of the fields at compile time, and so (if I
understand their approach correctly), they can compile a custom hashing
function for the case class that leverages the types of all its components
for maximum speed.

-- 
-- 
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/groups/opt_out.

Re: Request for help optimising a Clojure program

[David Nolen]

What I suggested is far, far more conservative than anything else proposed
on this or on the dev thread.

Changing the hash implementation of sets and vectors etc. is likely to have
unintended consequences for performance -
http://www.scala-lang.org/old/node/8510.html

The original Scala code used case classes - like defrecord they provide a
lot of functionality out of the box and don't require defining hash /
equals methods. In the past Scala case classes had bad hash code
distribution, this is no longer the case.

What I'm suggesting is to leave everything else alone, but only make the
sensible change so that the Scala code can be reasonably ported to Clojure.
This simply requires giving defrecord a better hashing strategy. I suspect
we can duplicate the approach already taken by Scala for case classes.

David

On Fri, Oct 25, 2013 at 12:11 PM, Stuart Halloway  wrote:

> To save others from having to read this whole thread, is the following
> summary correct?
>
> 1. We believe that the performance issue Paul first encountered is
> substantially / entirely caused by hash collisions.
>
> 2. The hash collisions could be improved by spreading the hashes of
> numbers (and not needing to mess with hashes of collections).
>
> If the above summary is correct, then I have the following questions:
>
> a. Is the approach Scala took substantially #2 above, or something
> different / more?
>
> b. Is changing the hash codes of numbers going to break expectations on
> the Java side of things?
>
>
> On Thu, Oct 24, 2013 at 8:37 PM, Evan Gamble  wrote:
>
>> As Andy Fingerhut pointed out, since (hash [a b]) is 31*(a + 30) + (b +
>> 31) when a and b are ints, summing the hashes of 2-tuples when the values
>> are small ints, as happens when hashing sets of such 2-tuples, is quite
>> likely to lead to collisions. This particular problem could be avoided by
>> spreading the hashes of ints out to large numbers with a non-linear
>> function, not just multiplying them all by some N.
>>
>>
>> On Wednesday, October 23, 2013 5:41:15 PM UTC-7, puzzler wrote:
>>
>>> Perhaps I don't understand your point, but vector hashing is not
>>> currently the sum of hashes.  It's a more complex computation.
>>>
>>> => (hash [0 2])
>>> 963
>>> => (hash [2 0])
>>> 1023
>>> => (hash [2])
>>> 33
>>>
>>> The fact that numbers hash to themselves means that the resulting hashes
>>> are not hugely spread apart, but collisions don't seem to be as common as
>>> with sets and maps.  I'm sure it could be improved, but vector/sequence
>>> hashing doesn't strike me as a huge issue.
>>>
>>>
>>> On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey wrote:
>>>
 There's still a problem with collisions among *vectors* though.

 I'd say the real underlying problem is that small integers hash to
 themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
 widely separated ones, while inducing a permutation on nonzero integers --
 the hash space wouldn't be any smaller. That alone won't help much with the
 vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
 avoid collisions with small integers in small hash maps when the hash is
 being used modulo a small hash-table length. What might help with vectors,
 sets, and other small data structures containing integers (but would shrink
 the hash space by about half) is to additionally square the result (all
 operations being 2s-complement 32-bit integer operations with wrapping --
 Java "int" arithmetic). Now 1 and 4 won't give the same summed hashes as 3
 and 2, and 0 and 5 will be different again. You might also want to add some
 constant to avoid 0 hashing to 0.

  --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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 rec

Re: Request for help optimising a Clojure program

[Andy Fingerhut]

Two partial answers in-line below, but as it says there, Mark Engelberg has
more experimental data than I do right now on proposed changes.


On Fri, Oct 25, 2013 at 9:11 AM, Stuart Halloway
wrote:

> To save others from having to read this whole thread, is the following
> summary correct?
>
> 1. We believe that the performance issue Paul first encountered is
> substantially / entirely caused by hash collisions.
>

There are definitely many hash collisions with Paul's program.  I believe
Mark Engelberg has already run experiments to show that most/all of these
collisions go away with one proposed change to the hash functions.


> 2. The hash collisions could be improved by spreading the hashes of
> numbers (and not needing to mess with hashes of collections).
>

If the only change made were to spread out the hashes of numbers using a
linear function, e.g. something of the form const1 * number + const2, then
the same hash collisions would remain, due to the current hash functions
for vectors/sequences and sets and the nature of Paul's data (which were
definitely not created with an eye towards breaking the hash functions --
they are quite reasonable things a programmer would hope to work
efficiently without needing to know any special tricks).

If the only change made were to spread out the hashes of numbers using a
non-linear function, e.g. something like the number*number suggested by
Mark Engelberg, then it needs more verification than I personally have done
so far, but I believe that would help avoid many of the collisions.  I
think Mark Engelberg could make comments based on more collected data than
I have.

I do not know the answers to questions a or b below.

Andy


>
> If the above summary is correct, then I have the following questions:
>
> a. Is the approach Scala took substantially #2 above, or something
> different / more?
>
> b. Is changing the hash codes of numbers going to break expectations on
> the Java side of things?
>
>
> On Thu, Oct 24, 2013 at 8:37 PM, Evan Gamble  wrote:
>
>> As Andy Fingerhut pointed out, since (hash [a b]) is 31*(a + 30) + (b +
>> 31) when a and b are ints, summing the hashes of 2-tuples when the values
>> are small ints, as happens when hashing sets of such 2-tuples, is quite
>> likely to lead to collisions. This particular problem could be avoided by
>> spreading the hashes of ints out to large numbers with a non-linear
>> function, not just multiplying them all by some N.
>>
>>
>> On Wednesday, October 23, 2013 5:41:15 PM UTC-7, puzzler wrote:
>>
>>> Perhaps I don't understand your point, but vector hashing is not
>>> currently the sum of hashes.  It's a more complex computation.
>>>
>>> => (hash [0 2])
>>> 963
>>> => (hash [2 0])
>>> 1023
>>> => (hash [2])
>>> 33
>>>
>>> The fact that numbers hash to themselves means that the resulting hashes
>>> are not hugely spread apart, but collisions don't seem to be as common as
>>> with sets and maps.  I'm sure it could be improved, but vector/sequence
>>> hashing doesn't strike me as a huge issue.
>>>
>>>
>>> On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey wrote:
>>>
 There's still a problem with collisions among *vectors* though.

 I'd say the real underlying problem is that small integers hash to
 themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
 widely separated ones, while inducing a permutation on nonzero integers --
 the hash space wouldn't be any smaller. That alone won't help much with the
 vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
 avoid collisions with small integers in small hash maps when the hash is
 being used modulo a small hash-table length. What might help with vectors,
 sets, and other small data structures containing integers (but would shrink
 the hash space by about half) is to additionally square the result (all
 operations being 2s-complement 32-bit integer operations with wrapping --
 Java "int" arithmetic). Now 1 and 4 won't give the same summed hashes as 3
 and 2, and 0 and 5 will be different again. You might also want to add some
 constant to avoid 0 hashing to 0.

  --
>> --
>> 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/groups/op

Re: Request for help optimising a Clojure program

[Ben Mabey]

On 10/24/13 5:46 AM, Paul Butcher wrote:
On 24 Oct 2013, at 11:34, Phillip Lord > wrote:



What does Scala do? I mean, given that it doesn't have the same problem,
perhaps it has a solution?


By default, Scala uses a tree-based set, not a hash-based set. So the 
fact that it doesn't run into hashing issues isn't surprising (and is 
yet another example of how this isn't a perfect apples-to-apples 
comparison).


However, I've just tried rerunning the Scala using a hash-based set 
implementation, and that takes the runtime down from around 2.5 
minutes to just over 2.


Which hash-based set implementation did you use for that comparison?  It 
would be nice to look at the hashing fn it is using.


-Ben

--
--
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/groups/opt_out.

Re: Request for help optimising a Clojure program

[Stuart Halloway]

To save others from having to read this whole thread, is the following
summary correct?

1. We believe that the performance issue Paul first encountered is
substantially / entirely caused by hash collisions.

2. The hash collisions could be improved by spreading the hashes of numbers
(and not needing to mess with hashes of collections).

If the above summary is correct, then I have the following questions:

a. Is the approach Scala took substantially #2 above, or something
different / more?

b. Is changing the hash codes of numbers going to break expectations on the
Java side of things?


On Thu, Oct 24, 2013 at 8:37 PM, Evan Gamble  wrote:

> As Andy Fingerhut pointed out, since (hash [a b]) is 31*(a + 30) + (b +
> 31) when a and b are ints, summing the hashes of 2-tuples when the values
> are small ints, as happens when hashing sets of such 2-tuples, is quite
> likely to lead to collisions. This particular problem could be avoided by
> spreading the hashes of ints out to large numbers with a non-linear
> function, not just multiplying them all by some N.
>
>
> On Wednesday, October 23, 2013 5:41:15 PM UTC-7, puzzler wrote:
>
>> Perhaps I don't understand your point, but vector hashing is not
>> currently the sum of hashes.  It's a more complex computation.
>>
>> => (hash [0 2])
>> 963
>> => (hash [2 0])
>> 1023
>> => (hash [2])
>> 33
>>
>> The fact that numbers hash to themselves means that the resulting hashes
>> are not hugely spread apart, but collisions don't seem to be as common as
>> with sets and maps.  I'm sure it could be improved, but vector/sequence
>> hashing doesn't strike me as a huge issue.
>>
>>
>> On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey wrote:
>>
>>> There's still a problem with collisions among *vectors* though.
>>>
>>> I'd say the real underlying problem is that small integers hash to
>>> themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
>>> 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
>>> widely separated ones, while inducing a permutation on nonzero integers --
>>> the hash space wouldn't be any smaller. That alone won't help much with the
>>> vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
>>> avoid collisions with small integers in small hash maps when the hash is
>>> being used modulo a small hash-table length. What might help with vectors,
>>> sets, and other small data structures containing integers (but would shrink
>>> the hash space by about half) is to additionally square the result (all
>>> operations being 2s-complement 32-bit integer operations with wrapping --
>>> Java "int" arithmetic). Now 1 and 4 won't give the same summed hashes as 3
>>> and 2, and 0 and 5 will be different again. You might also want to add some
>>> constant to avoid 0 hashing to 0.
>>>
>>>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Rolling back transactions with clojure.java.jdbc

[Mark Tomko]

Looks like that was a success. Thanks for the help!


On Fri, Oct 25, 2013 at 11:26 AM, Mark Tomko  wrote:

> Thanks Sean. I'll give it a try!
>
>
>
>
> On Fri, Oct 25, 2013 at 11:21 AM, Sean Corfield wrote:
>
>> Second bug in your code: (delete-scores-for-column db cid)
>>
>> Should be: (delete-scores-for-column t cid)
>>
>> Sorry I didn't see that (additional) bug first time around when I
>> suggested removing :transaction? from delete!
>>
>> execute! does not call with-open if it can find an active connection
>> in the passed in db-spec. Inside a transaction, there is an active
>> connection. But if you pass the original db-spec instead of the
>> transaction-aware one, it will do what you ask (create a new
>> connection) instead of what you want (use the same connection).
>>
>> Most of the bugs I see in java.jdbc usage code are the result of
>> overthinking and not just letting the library do its thing :)
>>
>> Sean
>>
>> On Fri, Oct 25, 2013 at 6:33 AM, Mark  wrote:
>> > Scratch that aside, I think I have that part working. It was a little
>> gnarly
>> > because the datasource provider was written in Scala and posed a few
>> > potentially confusing interop problems, and I must have gotten it wrong
>> on
>> > at least one account.
>> >
>> > However, I'm still seeming to commit automatically.
>> >
>> >
>> > On Friday, October 25, 2013 9:17:03 AM UTC-4, Mark wrote:
>> >>
>> >> That doesn't seem to work. Neither does explicitly setting
>> :transaction?
>> >> to false.
>> >>
>> >> Looking at the source of execute!, it looks like the statement is
>> running
>> >> within a "with-open" on the java.sql.Connection, which is where a
>> commit or
>> >> rollback would occur. I presume that the with-open is closing the
>> >> connection, which is resulting in a commit. Is there some way I can set
>> >> autocommit to false on the connection through the db-spec?
>> >>
>> >> Unrelated to this, I had earlier been trying to use a DataSource
>> provider
>> >> that we have and wrap it with {:datasource ds}, which worked fine for
>> >> executing queries, but db-set-rollback-only! would throw a
>> >> NullPointerException (from reset!) if I created the data source that
>> way. I
>> >> dug around in the source code a bit more, but didn't see immediately
>> what
>> >> was going on - that being said, I'm not terribly familiar with how
>> atoms
>> >> work in Clojure.
>> >>
>> >> Thanks for your help!
>> >>
>> >> Mark
>> >>
>> >> On Friday, October 25, 2013 2:10:18 AM UTC-4, Sean Corfield wrote:
>> >>>
>> >>> Remove :transaction? true from the delete! call.
>> >>>
>> >>> You're telling delete! to run inside its own transaction - you don't
>> >>> want that: that's why your deletes do not rollback.
>> >>>
>> >>> Sean
>> >>>
>> >>> On Thu, Oct 24, 2013 at 2:03 PM, Mark  wrote:
>> >>> > I've been working on a small utility script to clean up a very large
>> >>> > table
>> >>> > (~1 billion rows). Because the table is so large, I want to go
>> through
>> >>> > and
>> >>> > delete it chunk at a time. I've written a simple script that does
>> this,
>> >>> > but
>> >>> > when I was testing it against our dev instance, I found that it
>> wasn't
>> >>> > rolling back, as I'd hoped it would.
>> >>> >
>> >>> > You can see a simplified version of the script here:
>> >>> >
>> >>> > https://gist.github.com/anonymous/14ed57085709a2772ee0
>> >>> >
>> >>> > It's using an Oracle database (11GR1, I think) and clojure.java.jdbc
>> >>> > version
>> >>> > 0.3.0-alpha5. I've dug through the clojure.java.jdbc docs and code,
>> but
>> >>> > I
>> >>> > don't see an obvious problem with what I'm doing, although I presume
>> >>> > that to
>> >>> > someone who knows this library better, my problem is quite simple.
>> >>> >
>> >>> > Does anyone have any idea what I'm doing wrong? Can you point to an
>> >>> > example
>> >>> > that issues deletes (or inserts, or updates) that rollback?
>> >>> >
>> >>> > Thanks!
>> >>> > Mark
>> >>> >
>> >>> > --
>> >>> > --
>> >>> > 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 moderated - please be patient
>> with
>> >>> > your
>> >>> > first post.
>> >>> > To unsubscribe from this group, send email to
>> >>> > clojure+u...@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+u...@googlegroups.com.
>> >>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Sean A Corfield -- (904) 302-SEAN
>> >>> An Architect's View -- http://corfield.org/
>> >>> World Singles, LLC. -- http://worldsingles.com/
>> >>

Re: Rolling back transactions with clojure.java.jdbc

[Mark Tomko]

Thanks Sean. I'll give it a try!




On Fri, Oct 25, 2013 at 11:21 AM, Sean Corfield wrote:

> Second bug in your code: (delete-scores-for-column db cid)
>
> Should be: (delete-scores-for-column t cid)
>
> Sorry I didn't see that (additional) bug first time around when I
> suggested removing :transaction? from delete!
>
> execute! does not call with-open if it can find an active connection
> in the passed in db-spec. Inside a transaction, there is an active
> connection. But if you pass the original db-spec instead of the
> transaction-aware one, it will do what you ask (create a new
> connection) instead of what you want (use the same connection).
>
> Most of the bugs I see in java.jdbc usage code are the result of
> overthinking and not just letting the library do its thing :)
>
> Sean
>
> On Fri, Oct 25, 2013 at 6:33 AM, Mark  wrote:
> > Scratch that aside, I think I have that part working. It was a little
> gnarly
> > because the datasource provider was written in Scala and posed a few
> > potentially confusing interop problems, and I must have gotten it wrong
> on
> > at least one account.
> >
> > However, I'm still seeming to commit automatically.
> >
> >
> > On Friday, October 25, 2013 9:17:03 AM UTC-4, Mark wrote:
> >>
> >> That doesn't seem to work. Neither does explicitly setting :transaction?
> >> to false.
> >>
> >> Looking at the source of execute!, it looks like the statement is
> running
> >> within a "with-open" on the java.sql.Connection, which is where a
> commit or
> >> rollback would occur. I presume that the with-open is closing the
> >> connection, which is resulting in a commit. Is there some way I can set
> >> autocommit to false on the connection through the db-spec?
> >>
> >> Unrelated to this, I had earlier been trying to use a DataSource
> provider
> >> that we have and wrap it with {:datasource ds}, which worked fine for
> >> executing queries, but db-set-rollback-only! would throw a
> >> NullPointerException (from reset!) if I created the data source that
> way. I
> >> dug around in the source code a bit more, but didn't see immediately
> what
> >> was going on - that being said, I'm not terribly familiar with how atoms
> >> work in Clojure.
> >>
> >> Thanks for your help!
> >>
> >> Mark
> >>
> >> On Friday, October 25, 2013 2:10:18 AM UTC-4, Sean Corfield wrote:
> >>>
> >>> Remove :transaction? true from the delete! call.
> >>>
> >>> You're telling delete! to run inside its own transaction - you don't
> >>> want that: that's why your deletes do not rollback.
> >>>
> >>> Sean
> >>>
> >>> On Thu, Oct 24, 2013 at 2:03 PM, Mark  wrote:
> >>> > I've been working on a small utility script to clean up a very large
> >>> > table
> >>> > (~1 billion rows). Because the table is so large, I want to go
> through
> >>> > and
> >>> > delete it chunk at a time. I've written a simple script that does
> this,
> >>> > but
> >>> > when I was testing it against our dev instance, I found that it
> wasn't
> >>> > rolling back, as I'd hoped it would.
> >>> >
> >>> > You can see a simplified version of the script here:
> >>> >
> >>> > https://gist.github.com/anonymous/14ed57085709a2772ee0
> >>> >
> >>> > It's using an Oracle database (11GR1, I think) and clojure.java.jdbc
> >>> > version
> >>> > 0.3.0-alpha5. I've dug through the clojure.java.jdbc docs and code,
> but
> >>> > I
> >>> > don't see an obvious problem with what I'm doing, although I presume
> >>> > that to
> >>> > someone who knows this library better, my problem is quite simple.
> >>> >
> >>> > Does anyone have any idea what I'm doing wrong? Can you point to an
> >>> > example
> >>> > that issues deletes (or inserts, or updates) that rollback?
> >>> >
> >>> > Thanks!
> >>> > Mark
> >>> >
> >>> > --
> >>> > --
> >>> > 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 moderated - please be patient
> with
> >>> > your
> >>> > first post.
> >>> > To unsubscribe from this group, send email to
> >>> > clojure+u...@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+u...@googlegroups.com.
> >>> > For more options, visit https://groups.google.com/groups/opt_out.
> >>>
> >>>
> >>>
> >>> --
> >>> Sean A Corfield -- (904) 302-SEAN
> >>> An Architect's View -- http://corfield.org/
> >>> World Singles, LLC. -- http://worldsingles.com/
> >>>
> >>> "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

Re: Rolling back transactions with clojure.java.jdbc

[Sean Corfield]

Second bug in your code: (delete-scores-for-column db cid)

Should be: (delete-scores-for-column t cid)

Sorry I didn't see that (additional) bug first time around when I
suggested removing :transaction? from delete!

execute! does not call with-open if it can find an active connection
in the passed in db-spec. Inside a transaction, there is an active
connection. But if you pass the original db-spec instead of the
transaction-aware one, it will do what you ask (create a new
connection) instead of what you want (use the same connection).

Most of the bugs I see in java.jdbc usage code are the result of
overthinking and not just letting the library do its thing :)

Sean

On Fri, Oct 25, 2013 at 6:33 AM, Mark  wrote:
> Scratch that aside, I think I have that part working. It was a little gnarly
> because the datasource provider was written in Scala and posed a few
> potentially confusing interop problems, and I must have gotten it wrong on
> at least one account.
>
> However, I'm still seeming to commit automatically.
>
>
> On Friday, October 25, 2013 9:17:03 AM UTC-4, Mark wrote:
>>
>> That doesn't seem to work. Neither does explicitly setting :transaction?
>> to false.
>>
>> Looking at the source of execute!, it looks like the statement is running
>> within a "with-open" on the java.sql.Connection, which is where a commit or
>> rollback would occur. I presume that the with-open is closing the
>> connection, which is resulting in a commit. Is there some way I can set
>> autocommit to false on the connection through the db-spec?
>>
>> Unrelated to this, I had earlier been trying to use a DataSource provider
>> that we have and wrap it with {:datasource ds}, which worked fine for
>> executing queries, but db-set-rollback-only! would throw a
>> NullPointerException (from reset!) if I created the data source that way. I
>> dug around in the source code a bit more, but didn't see immediately what
>> was going on - that being said, I'm not terribly familiar with how atoms
>> work in Clojure.
>>
>> Thanks for your help!
>>
>> Mark
>>
>> On Friday, October 25, 2013 2:10:18 AM UTC-4, Sean Corfield wrote:
>>>
>>> Remove :transaction? true from the delete! call.
>>>
>>> You're telling delete! to run inside its own transaction - you don't
>>> want that: that's why your deletes do not rollback.
>>>
>>> Sean
>>>
>>> On Thu, Oct 24, 2013 at 2:03 PM, Mark  wrote:
>>> > I've been working on a small utility script to clean up a very large
>>> > table
>>> > (~1 billion rows). Because the table is so large, I want to go through
>>> > and
>>> > delete it chunk at a time. I've written a simple script that does this,
>>> > but
>>> > when I was testing it against our dev instance, I found that it wasn't
>>> > rolling back, as I'd hoped it would.
>>> >
>>> > You can see a simplified version of the script here:
>>> >
>>> > https://gist.github.com/anonymous/14ed57085709a2772ee0
>>> >
>>> > It's using an Oracle database (11GR1, I think) and clojure.java.jdbc
>>> > version
>>> > 0.3.0-alpha5. I've dug through the clojure.java.jdbc docs and code, but
>>> > I
>>> > don't see an obvious problem with what I'm doing, although I presume
>>> > that to
>>> > someone who knows this library better, my problem is quite simple.
>>> >
>>> > Does anyone have any idea what I'm doing wrong? Can you point to an
>>> > example
>>> > that issues deletes (or inserts, or updates) that rollback?
>>> >
>>> > Thanks!
>>> > Mark
>>> >
>>> > --
>>> > --
>>> > 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 moderated - please be patient with
>>> > your
>>> > first post.
>>> > To unsubscribe from this group, send email to
>>> > clojure+u...@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+u...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>> --
>>> Sean A Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>> World Singles, LLC. -- http://worldsingles.com/
>>>
>>> "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 sub

Re: Overwrite equals in defrecord

[Andrii V. Mishkovskyi]

On Fri, Oct 25, 2013 at 4:41 PM, Marc Dzaebel  wrote:

> However, if you need the multiple features of records, you would need to
> have the generated code of defrecord in order to reimplement records with
> deftype. Is there something available?


Hey Marc,

I've recently been using this little library potemkin which has a few
useful deftype-like macros that would save a lot of typing (albeit I had a
different use case from yours), maybe deftype+ will work for you:
https://github.com/ztellman/potemkin#def-abstract-type-and-deftype

Cheers.


-- 
Wbr, Andrii V. Mishkovskyi.

He's got a heart of a little child, and he keeps it in a jar on his desk.

-- 
-- 
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/groups/opt_out.

Re: Overwrite equals in defrecord

[Marc Dzaebel]

>> use deftype which is more low-level and I think doesn't define equals or 
put y in meta data that don't participate in equality...:)

Hi Jim,

this works! However, if you need the multiple features of records, you 
would need to have the generated code of defrecord in order to reimplement 
records with deftype. Is there something available?

Thanks, Marc

-- 
-- 
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/groups/opt_out.

Re: Rolling back transactions with clojure.java.jdbc

[Mark]

Scratch that aside, I think I have that part working. It was a little 
gnarly because the datasource provider was written in Scala and posed a few 
potentially confusing interop problems, and I must have gotten it wrong on 
at least one account.

However, I'm still seeming to commit automatically.

On Friday, October 25, 2013 9:17:03 AM UTC-4, Mark wrote:
>
> That doesn't seem to work. Neither does explicitly setting :transaction? 
> to false. 
>
> Looking at the source of execute!, it looks like the statement is running 
> within a "with-open" on the java.sql.Connection, which is where a commit or 
> rollback would occur. I presume that the with-open is closing the 
> connection, which is resulting in a commit. Is there some way I can set 
> autocommit to false on the connection through the db-spec?
>
> Unrelated to this, I had earlier been trying to use a DataSource provider 
> that we have and wrap it with {:datasource ds}, which worked fine for 
> executing queries, but db-set-rollback-only! would throw a 
> NullPointerException (from reset!) if I created the data source that way. I 
> dug around in the source code a bit more, but didn't see immediately what 
> was going on - that being said, I'm not terribly familiar with how atoms 
> work in Clojure.
>
> Thanks for your help!
>
> Mark
>
> On Friday, October 25, 2013 2:10:18 AM UTC-4, Sean Corfield wrote:
>>
>> Remove :transaction? true from the delete! call. 
>>
>> You're telling delete! to run inside its own transaction - you don't 
>> want that: that's why your deletes do not rollback. 
>>
>> Sean 
>>
>> On Thu, Oct 24, 2013 at 2:03 PM, Mark  wrote: 
>> > I've been working on a small utility script to clean up a very large 
>> table 
>> > (~1 billion rows). Because the table is so large, I want to go through 
>> and 
>> > delete it chunk at a time. I've written a simple script that does this, 
>> but 
>> > when I was testing it against our dev instance, I found that it wasn't 
>> > rolling back, as I'd hoped it would. 
>> > 
>> > You can see a simplified version of the script here: 
>> > 
>> > https://gist.github.com/anonymous/14ed57085709a2772ee0 
>> > 
>> > It's using an Oracle database (11GR1, I think) and clojure.java.jdbc 
>> version 
>> > 0.3.0-alpha5. I've dug through the clojure.java.jdbc docs and code, but 
>> I 
>> > don't see an obvious problem with what I'm doing, although I presume 
>> that to 
>> > someone who knows this library better, my problem is quite simple. 
>> > 
>> > Does anyone have any idea what I'm doing wrong? Can you point to an 
>> example 
>> > that issues deletes (or inserts, or updates) that rollback? 
>> > 
>> > Thanks! 
>> > Mark 
>> > 
>> > -- 
>> > -- 
>> > 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 moderated - please be patient with 
>> your 
>> > first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@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+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/groups/opt_out. 
>>
>>
>>
>> -- 
>> Sean A Corfield -- (904) 302-SEAN 
>> An Architect's View -- http://corfield.org/ 
>> World Singles, LLC. -- http://worldsingles.com/ 
>>
>> "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/groups/opt_out.

Re: Rolling back transactions with clojure.java.jdbc

[Mark]

That doesn't seem to work. Neither does explicitly setting :transaction? to 
false. 

Looking at the source of execute!, it looks like the statement is running 
within a "with-open" on the java.sql.Connection, which is where a commit or 
rollback would occur. I presume that the with-open is closing the 
connection, which is resulting in a commit. Is there some way I can set 
autocommit to false on the connection through the db-spec?

Unrelated to this, I had earlier been trying to use a DataSource provider 
that we have and wrap it with {:datasource ds}, which worked fine for 
executing queries, but db-set-rollback-only! would throw a 
NullPointerException (from reset!) if I created the data source that way. I 
dug around in the source code a bit more, but didn't see immediately what 
was going on - that being said, I'm not terribly familiar with how atoms 
work in Clojure.

Thanks for your help!

Mark

On Friday, October 25, 2013 2:10:18 AM UTC-4, Sean Corfield wrote:
>
> Remove :transaction? true from the delete! call. 
>
> You're telling delete! to run inside its own transaction - you don't 
> want that: that's why your deletes do not rollback. 
>
> Sean 
>
> On Thu, Oct 24, 2013 at 2:03 PM, Mark > 
> wrote: 
> > I've been working on a small utility script to clean up a very large 
> table 
> > (~1 billion rows). Because the table is so large, I want to go through 
> and 
> > delete it chunk at a time. I've written a simple script that does this, 
> but 
> > when I was testing it against our dev instance, I found that it wasn't 
> > rolling back, as I'd hoped it would. 
> > 
> > You can see a simplified version of the script here: 
> > 
> > https://gist.github.com/anonymous/14ed57085709a2772ee0 
> > 
> > It's using an Oracle database (11GR1, I think) and clojure.java.jdbc 
> version 
> > 0.3.0-alpha5. I've dug through the clojure.java.jdbc docs and code, but 
> I 
> > don't see an obvious problem with what I'm doing, although I presume 
> that to 
> > someone who knows this library better, my problem is quite simple. 
> > 
> > Does anyone have any idea what I'm doing wrong? Can you point to an 
> example 
> > that issues deletes (or inserts, or updates) that rollback? 
> > 
> > Thanks! 
> > Mark 
> > 
> > -- 
> > -- 
> > 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 moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@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+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "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/groups/opt_out.

[ANN] - Major update of Tutorial 21 Learning by Collaborating of the modern-cljs series

[Mimmo Cosenza]

Hi all,
I made a major update of the Tutorial-21. It now brings the reader to brepl 
with the enfocus project. 

https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-21.md

HIH

Mimmo

-- 
-- 
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/groups/opt_out.

Re: Clojure(script) countdown like the one on clojurecup.com?

[Bastien]

Hi Cedric,

Cedric Greevey  writes:

> Why the hell did this message just mark itself as unread in my gmail
> inbox? I read it hours ago and I'm quite certain I didn't
> subsequently take any action to unmark it as read...yet here it is,
> suddenly showing as new again.

My bad -- I wasn't sure my first email made it through the list
(couldn't find it sent in my gmail sent box), so I resent it.

Sorry for the noise,

-- 
 Bastien

-- 
-- 
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/groups/opt_out.

Re: Clojure(script) countdown like the one on clojurecup.com?

[Cedric Greevey]

Why the hell did this message just mark itself as unread in my gmail inbox?
I read it hours ago and I'm quite certain I didn't subsequently take any
action to unmark it as read...yet here it is, suddenly showing as new again.


On Fri, Oct 25, 2013 at 4:30 AM, Bastien  wrote:

> I'm trying to implement a countdown like the one there was on
> clojurecup.com: is there a way to access to the website code,
> or is there any pointer where I could learn how to do this?
>
> Thanks in advance for your help!
>
> --
>  Bastien
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Clojure(script) countdown like the one on clojurecup.com?

[Bastien]

I'm trying to implement a countdown like the one there was on
clojurecup.com: is there a way to access to the website code,
or is there any pointer where I could learn how to do this?

Thanks in advance for your help!

-- 
 Bastien

-- 
-- 
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/groups/opt_out.