Re: ANN: deep-freeze serialization library
Hi,
Am 31.12.2011 um 05:36 schrieb Peter Taoussanis:
>> I guess what I'd like a mode where I can say "act like read/pr" and> for
>> deep-freeze to ignore metadata, refs and atoms.
>
> I'm still not sure I'm getting this argument though. In its current
> form, deep-freeze makes an attempt to preserve as much information as
> it can. In the specific case of STM/metadata it happens to preserve a
> little more information than read/pr.
I think, what James wants to say is: serialising reference types is
non-trivial. Reference types are identities. So the instance itself (as in
identical?) carries information. When you have references to a ref you have to
make sure that they all refer to the same ref again after thawing. Let's say
you have a data structure like this:
(let [left-and-right (ref :state)]
{:left left-and-right :right left-and-right})
What is the state of this map after thawing? Does it refer to the same ref? Or
different ones? If it's different ones, your program is broken now. If
left-and-right was a value, the program would now need more memory, but it
would be still ok.
Looking at the source of deep-freeze your program will be broken after a round
trip. You'll need to add a marker for the identity and kind of memoize the thaw
function for refs on this marker, so that it returns the same ref again.
Ironically pr provides this information already. So I would rather say that pr
preserves more information than deep-freeze in this situation.
BTW: Do you wrap everything in a dosync when freezing a data structure? If not,
you cannot guarantee that refs are frozen in a consistent state.
Many, many pitfalls. Freezing and thawing of reference types play in a
different league than freezing and thawing of values. There needs more thought
to go into that. (And the fact that read/pr doesn't support reference types
(yet), should be a hint that this is not a simple puzzle for an afternoon.)
Just my 0.02€.
Sincerely
Meikel
--
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
Re: ANN: deep-freeze serialization library
> I think, what James wants to say is: serialising reference types is > non-trivial. Reference types are identities. So the instance itself (as in > identical?) carries information. When you have references to a ref you have > to make sure that they all refer to the same ref again after thawing. Okay, gotcha! Actually your example was perfect: yes, this is clearly a problem. Indeed I hadn't put much thought into it since I personally have no use for de/serialization of STM objects. I think the identity issue should be solvable but before opening that door: is this something anyone _wants_ solved? Is there a good use- case for trying to freeze STM objects? What do you think, Timothy? Maybe best to disable the STM stuff for now to avoid possible confusion? -- Peter -- 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
Colliding hashes
Saw this in a scala mailing list thread: http://www.youtube.com/watch?v=R2Cq3CLI6H8 Should the clojure hash be fixed? -- 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
Re: Colliding hashes
Should we watch the whole video to see what you mean? At what time is it important? Cheers, Hubert On Sat, Dec 31, 2011 at 1:39 PM, Brian Mosley wrote: > Saw this in a scala mailing list thread: > > http://www.youtube.com/watch?v=R2Cq3CLI6H8 > > Should the clojure hash be fixed? > > -- > 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 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
Re: Really loving Clooj but..
I use a modified version of tools.trace (or rather the old version called clojure.contrib.trace, but works with 1.3), you might be interested in some of the additions (sorry not well doc'd at the moment): 1) Don't blow up if a function throws an exception (return value shown in the trace will be the exception object). 2) option to trace a multi-threaded app - output is to a separate file for each thread 3) Trace entire namespaces, multiple namespaces, exclude fn's from traced namespaces. 4) ability to pretty print the trace to html with syntax highlighter. 1 &3 are probably the only ones useful at the repl. Jeff https://github.com/weissjeffm/fn.trace/ On Dec 30, 11:52 am, Erlis Vidal wrote: > Hi Jonas, > > That's what I was looking for. Thanks for your reply > > > > > > > > On Fri, Dec 30, 2011 at 8:16 AM, Jonas wrote: > > You should take a look at tools.trace [1]. A minimal example: > > > (ns trc.core > > (:use [clojure.tools.trace :only [deftrace]])) > > > (deftrace fib [n] > > (if (or (= n 0) (= n 1)) > > 1 > > (+ (fib (- n 1)) (fib (- n 2) > > > the following is printed when (fib 4) is evaluated: > > > TRACE t2302: (fib 4) > > TRACE t2303: | (fib 3) > > TRACE t2304: | | (fib 2) > > TRACE t2305: | | | (fib 1) > > TRACE t2305: | | | => 1 > > TRACE t2306: | | | (fib 0) > > TRACE t2306: | | | => 1 > > TRACE t2304: | | => 2 > > TRACE t2307: | | (fib 1) > > TRACE t2307: | | => 1 > > TRACE t2303: | => 3 > > TRACE t2308: | (fib 2) > > TRACE t2309: | | (fib 1) > > TRACE t2309: | | => 1 > > TRACE t2310: | | (fib 0) > > TRACE t2310: | | => 1 > > TRACE t2308: | => 2 > > TRACE t2302: => 5 > > > [1]:https://github.com/clojure/tools.trace > > > -- > > 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 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
Re: ANN: deep-freeze serialization library
On 31 December 2011 08:08, Meikel Brandmeyer wrote:
> I think, what James wants to say is: serialising reference types is
> non-trivial. Reference types are identities. So the instance itself (as in
> identical?) carries information. When you have references to a ref you have
> to make sure that they all refer to the same ref again after thawing. Let's
> say you have a data structure like this:
>
> (let [left-and-right (ref :state)]
> {:left left-and-right :right left-and-right})
>
> What is the state of this map after thawing? Does it refer to the same ref?
> Or different ones? If it's different ones, your program is broken now. If
> left-and-right was a value, the program would now need more memory, but it
> would be still ok.
This is pretty much what I was trying to say, but Meikel puts it far
more clearly than I managed to.
Serializing refs just seems such a briar patch that I'd prefer an
exception be raised so I know something is wrong.
- James
--
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
Distributed transactions
Is there any attempt to make distributed transactions? The usage scenario is the same like in JEE apps. I mean, there is a web service call, the transaction is started, there are some changes to db, some jms sends and when there is no failure all is commited. Maybe someone is already using glassfish or spring from clojure? Some reference to github? -- 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
Re: Distributed transactions
maybe avout is what you're looking for? https://github.com/liebke/avout 2011/12/31 Michael Jaaka > Is there any attempt to make distributed transactions? > The usage scenario is the same like in JEE apps. > I mean, there is a web service call, the transaction is started, there > are some changes to db, some jms sends and when there is no failure > all is commited. > Maybe someone is already using glassfish or spring from clojure? Some > reference to github? > > -- > 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 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
Re: Bug in extend-protocol macro? (Clojure 1.3.0)
Alan Malloy writes: > Stuff like this always worries me. It may happen to work now, but I > doubt if that's a guarantee. extend-protocol's contract is that you > give it a Symbol, which it resolves into a Class. It surely isn't > expecting a Class as an argument, because you can't enter that as a > source-code literal. If you give it a Class, it could conceivably do > something dreadful like try to call (resolve s) on it to figure out > what Class you mean, and that will fail when passed a Class. I'm not entirely happy with it either, but I don't think the situation is quite that dire. The docstring for `extend-protocol' doesn't say anything about *how* it divides up the stanzas for extended types, and as pointed out elsewhere in this thread the implementation uses seq vs not-seq, not symbol? vs not-symbol?. The docstrings for `extend-type' and `extend' explicitly say that they take a "type/class" -- I'd interpret that to mean that they can be called with anything which resolves to a type/class via normal resolution methods, including a literal value generated via #=. > For that matter, trying out your example, it doesn't seem to work for > me. The first fix is to use java.lang.Class instead of just Class, > since reader evaluation happens in a no-frills environment. Apologies -- I just modified the OP's original example without thinking it all the way through or running the code. One does need to specify java.lang.Class/forName, which is what I've been doing in my own source. > But after that, it seems the extend-protocol just silently does > nothing: (Addressed by another poster.) -Marshall -- 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
Re: Colliding hashes
http://www.kb.cert.org/vuls/id/903934 should give you pointers to understand the problems, and http://www.ocert.org/advisories/ocert-2011-003.html has details about what is vulnerable from an HTTP request processing point of view. Fixing the underlying map / hash tools would be awesome, of course, because it makes the fundamental attack inaccessible. I have no knowledge of either the Java or Clojure hash maps that would allow me to know if this actually applies here. Daniel On Sat, Dec 31, 2011 at 05:06, Hubert Iwaniuk wrote: > Should we watch the whole video to see what you mean? > At what time is it important? > > Cheers, > Hubert > > > > On Sat, Dec 31, 2011 at 1:39 PM, Brian Mosley > wrote: >> Saw this in a scala mailing list thread: >> >> http://www.youtube.com/watch?v=R2Cq3CLI6H8 >> >> Should the clojure hash be fixed? >> >> -- >> 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 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 -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Distributed transactions
Distributed transactions slow u down Why the hell would you want that? I'm yet to see a valid use case! They require sticky sessions *whi*ch suck for scalability! Keep in mind it's 4am on the 31st of December :-) Leonardo Borges www.leonardoborges.com Sent from my Galaxy Nexus(IceCreamSandwhich) On Jan 1, 2012 3:42 AM, "Bronsa" wrote: > maybe avout is what you're looking for? > https://github.com/liebke/avout > > 2011/12/31 Michael Jaaka > >> Is there any attempt to make distributed transactions? >> The usage scenario is the same like in JEE apps. >> I mean, there is a web service call, the transaction is started, there >> are some changes to db, some jms sends and when there is no failure >> all is commited. >> Maybe someone is already using glassfish or spring from clojure? Some >> reference to github? >> >> -- >> 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 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 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
Re: Distributed transactions
Well, I can't speak for Michael, but we want them because we need to update the database *and* send events notifying other parts of the distributed system about the change. We really don't want to do only one *or* the other, because that requires that we get into the fun world where distributed tools in multiple languages can't trust the events we send, or need to implement client polling to notice change. Distributed database transactions? Not much fun. Transactions that cover more than just one technology? More useful. Daniel On Sat, Dec 31, 2011 at 09:39, Leonardo Borges wrote: > Distributed transactions slow u down Why the hell would you want that? > I'm yet to see a valid use case! They require sticky sessions which suck for > scalability! Keep in mind it's 4am on the 31st of December :-) > > Leonardo Borges > www.leonardoborges.com > Sent from my Galaxy Nexus(IceCreamSandwhich) > > On Jan 1, 2012 3:42 AM, "Bronsa" wrote: >> >> maybe avout is what you're looking for? >> https://github.com/liebke/avout >> >> 2011/12/31 Michael Jaaka >>> >>> Is there any attempt to make distributed transactions? >>> The usage scenario is the same like in JEE apps. >>> I mean, there is a web service call, the transaction is started, there >>> are some changes to db, some jms sends and when there is no failure >>> all is commited. >>> Maybe someone is already using glassfish or spring from clojure? Some >>> reference to github? >>> >>> -- >>> 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 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 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 -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: ANN: deep-freeze serialization library
First of all, I've updated the README.md to show the license. It's a BSD 3 clause license. Yeah, I hadn't thought of the issue of the refs, but I don't think it's a exceptionally hard problem to solve. What we are discussing is basically the same thing that mutable languages deal with every day. At work I'm forced to work with a business object library known as CSLA.NET and although most of the library is the best example of complected code I've ever seen, the serialization isn't all that bad. Basically you follow this method: Serialize the tree putting each ref into a list. Then you write the indexed id of that ref instead of the contents of that ref. When you are done serializing the object, you loop through every object in the ref list and serialize the contents of the refs. The same pattern is followed each time. If the ref is in the list, you write the id (index in the list) of the ref. If it's not in the list, you add it to the list and write the id. This sort of serialization is needed in mutable languages such as C# because it's fairly easy to create loops in the data that would cause a simpler serializer to enter a infinite loop. Does anyone see any issues with this method? Timothy -- 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
Any built-in way to print to stream besides *out*?
I know I can bind *out* to another stream like *err*, but is that the only way built-in to Clojure? (binding [*out* *err*] (println "This will go to *err*, not *out*")) If it is the only way, is there some library perhaps where someone has implemented a function that lets you specify the output stream as an argument, e.g. (printf+ *err* "This will go to *err*") (printf+ "This will go to *out* as the default output stream") Thanks, Andy -- 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
Re: Distributed transactions
Immutant is going to have distributed (XA) transactions. The're "furiously" working on it 8) http://immutant.org/ On Dec 31, 11:26 am, Michael Jaaka wrote: > Is there any attempt to make distributed transactions? > The usage scenario is the same like in JEE apps. > I mean, there is a web service call, the transaction is started, there > are some changes to db, some jms sends and when there is no failure > all is commited. > Maybe someone is already using glassfish or spring from clojure? Some > reference to github? -- 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
Re: Any built-in way to print to stream besides *out*?
Like this? (defn printf+ [& [writer & more :as xs]] (if (instance? java.io.PrintWriter writer) (binding [*out* writer] (apply println more)) (apply println xs))) On Sat, Dec 31, 2011 at 10:01 AM, Andy Fingerhut wrote: > I know I can bind *out* to another stream like *err*, but is that the only > way built-in to Clojure? > > (binding [*out* *err*] (println "This will go to *err*, not *out*")) > > If it is the only way, is there some library perhaps where someone has > implemented a function that lets you specify the output stream as an > argument, e.g. > > (printf+ *err* "This will go to *err*") > (printf+ "This will go to *out* as the default output stream") > > Thanks, > Andy > > -- > 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 -- Sam Ritchie, Twitter Inc 703.662.1337 @sritchie09 (Too brief? Here's why! http://emailcharter.org) -- 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
Re: Colliding hashes
String hashing uses the default java hashCode method which contains the vulnerability. user=> (= (hash "Ey") (hash "FZ")) true user=> (apply = (map hash ["EyEy" "FZEy" "EyFZ" "FZFZ"])) true -- 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
distincto
I am trying to learn how to use core.logic. Here is a toy problem that I am thinking about. (run* [q] (fresh [a b c] (membero a [1 2 3]) (membero c [1 2 3]) (== b 2) (!= a b) (!= a c) (!= b c) (== q [a b c]))) I would like to create a function that replaces the three != lines, something like, (distincto [a b c]) such that I could rewrite the above problem as (run* [q] (fresh [a b c] (membero a [1 2 3]) (membero c [1 2 3]) (== b 2) (distincto [a b c]) (== q [a b c]))) I tried to write several functions but they are all end up inside some variant of a col, [(!= a b)(!= a c)(!= b c)]. Thus, I either need someone to help me figure out how do write the distincto function, or what to call on [(!= a b)(!= a c)(!= b c)] to get it to work. -- 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
Re: Any built-in way to print to stream besides *out*?
Yep. I should have mentioned that I know it isn't difficult to write one, but in something I'm writing up I wanted to avoid reinventing an already-existing wheel if it was already in a well-used library. Thanks, Andy On Sat, Dec 31, 2011 at 10:36 AM, Sam Ritchie wrote: > Like this? > > (defn printf+ [& [writer & more :as xs]] > (if (instance? java.io.PrintWriter writer) > (binding [*out* writer] > (apply println more)) > (apply println xs))) > > On Sat, Dec 31, 2011 at 10:01 AM, Andy Fingerhut > wrote: > >> I know I can bind *out* to another stream like *err*, but is that the >> only way built-in to Clojure? >> >> (binding [*out* *err*] (println "This will go to *err*, not *out*")) >> >> If it is the only way, is there some library perhaps where someone has >> implemented a function that lets you specify the output stream as an >> argument, e.g. >> >> (printf+ *err* "This will go to *err*") >> (printf+ "This will go to *out* as the default output stream") >> >> Thanks, >> Andy >> >> >> -- >> 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 > > > > > -- > Sam Ritchie, Twitter Inc > 703.662.1337 > @sritchie09 > > (Too brief? Here's why! http://emailcharter.org) > > -- > 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 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
Re: Distributed transactions
On Dec 31 2011, 9:26 pm, Michael Jaaka wrote: > Is there any attempt to make distributed transactions? > The usage scenario is the same like in JEE apps. > I mean, there is a web service call, the transaction is started, there > are some changes to db, some jms sends and when there is no failure > all is commited. Did you look at JOTM? http://jotm.ow2.org/xwiki/bin/view/Main/WebHome You can wrap the Java calls with Clojure. Regards, Shantanu -- 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
Re: Distributed transactions
On Dec 31, 1:16 pm, Jeff Heon wrote: > Immutant is going to have distributed (XA) transactions. > The're "furiously" working on it 8) > > http://immutant.org/ "Furiously" is probably not the right word, but XA is definitely on the roadmap. It's just a matter of wiring up the TransactionManager provided by JBoss AS7. We've done this already for Ruby with TorqueBox, so it should be straightforward. With any luck, we'll have it wired up by Februrary, certainly in time for Clojure/West. Jim > > On Dec 31, 11:26 am, Michael Jaaka > wrote: > > > Is there any attempt to make distributed transactions? > > The usage scenario is the same like in JEE apps. > > I mean, there is a web service call, the transaction is started, there > > are some changes to db, some jms sends and when there is no failure > > all is commited. > > Maybe someone is already using glassfish or spring from clojure? Some > > reference to github? > > -- 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
Re: Distributed transactions
On Dec 31, 12:39 pm, Leonardo Borges wrote: > Distributed transactions slow u down Why the hell would you want that? > I'm yet to see a valid use case! They require sticky sessions *whi*ch suck > for scalability! Keep in mind it's 4am on the 31st of December :-) It's a surprisingly common request, Leonardo, especially when it's necessary to include both messaging and persistence in the same tx. Without XA, you have to implement your own middleware to account for failed sends or writes, e.g. the "idempotent receiver" pattern. This adds "accidental complexity" to your codebase, and it's hard to get right, adding tests for all possible failure scenarios. With a good TransactionManager, the performance hit is negligible, and your codebase becomes *MUCH* simpler. XA is certainly not for every app, but it can be a very attractive solution for many. And fwiw, you can certainly make good use of XA without sticky sessions, so I'm not totally clear on why you say they're required. Regardless, have a happy (and SAFE!) new year! Jim > > Leonardo Borgeswww.leonardoborges.com > Sent from my Galaxy Nexus(IceCreamSandwhich) > On Jan 1, 2012 3:42 AM, "Bronsa" wrote: > > > maybe avout is what you're looking for? > >https://github.com/liebke/avout > > > 2011/12/31 Michael Jaaka > > >> Is there any attempt to make distributed transactions? > >> The usage scenario is the same like in JEE apps. > >> I mean, there is a web service call, the transaction is started, there > >> are some changes to db, some jms sends and when there is no failure > >> all is commited. > >> Maybe someone is already using glassfish or spring from clojure? Some > >> reference to github? > > >> -- > >> 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 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 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
Re: Really loving Clooj but..
On Sat, Dec 31, 2011 at 6:43 AM, jweiss wrote: > I use a modified version of tools.trace (or rather the old version > called clojure.contrib.trace, but works with 1.3), you might be > interested in some of the additions (sorry not well doc'd at the > moment): Those look like nice additions. Perhaps you could open tickets http://dev.clojure.org/jira/browse/TTRACE with details so those features might get added to clojure.tools.trace? -- 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
Re: Distributed transactions
> On Dec 31, 1:16 pm, Jeff Heon wrote: >> Immutant is going to have distributed (XA) transactions. >> The're "furiously" working on it 8) >> >> http://immutant.org/ > > "Furiously" is probably not the right word, but XA is definitely on > the roadmap. It's just a matter of wiring up the TransactionManager > provided by JBoss AS7. We've done this already for Ruby with > TorqueBox, so it should be straightforward. With any luck, we'll have > it wired up by Februrary, certainly in time for Clojure/West. > > Jim What wiring is needed, beyond knowing how to call a Java API from Clojure? Stu Stuart Halloway Clojure/core http://clojure.com -- 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
Re: Distributed transactions
On Dec 31, 7:33 pm, Stuart Halloway wrote: > > On Dec 31, 1:16 pm, Jeff Heon wrote: > >> Immutant is going to have distributed (XA) transactions. > >> The're "furiously" working on it 8) > > >>http://immutant.org/ > > > "Furiously" is probably not the right word, but XA is definitely on > > the roadmap. It's just a matter of wiring up the TransactionManager > > provided by JBoss AS7. We've done this already for Ruby with > > TorqueBox, so it should be straightforward. With any luck, we'll have > > it wired up by Februrary, certainly in time for Clojure/West. > > > Jim > > What wiring is needed, beyond knowing how to call a Java API from Clojure? At a minimum, we need to obtain a TransactionManager (easy) and define XAResource implementations for each resource participating in the transaction (easy for messaging, not as easy for db). In ruby, the activerecord jdbc adapter helps us with the latter, allowing us to automatically create XAResource's for each key listed in the Rails database.yml file, using standard ruby conventions to provide XA "for free" when a rails app is deployed under TorqueBox. We need to figure out what those conventions are for clojure. Or help define them. Also, the Java API's for XA are kinda awkward. I hope we can wrap them a bit to make the common usage patterns simple. Now, back to drinking. :) Jim > > Stu > > Stuart Halloway > Clojure/corehttp://clojure.com -- 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
Re: distincto
I had a peek on the cKanren branch, distincto is basically all-diffo in cKanren. https://github.com/clojure/core.logic/blob/cKanren/src/main/clojure/clojure/core/logic.clj#L2229 Here's the port to core.logic. (change !=c to !=) (defn distincto [l] (conde [(== l ())] [(fresh [a] (== l [a]))] [(fresh [a ad dd] (== l (llist a ad dd)) (!= a ad) (distincto (llist a dd)) (distincto (llist ad dd)))])) (run* [q] (fresh [a b c] (membero a [1 2 3]) (membero c [1 2 3]) (== b 2) (distincto [a b c]) (== q [a b c]))) ;=> ([1 2 3] [3 2 1]) Pretty cool! Thanks, Ambrose On Sun, Jan 1, 2012 at 4:31 AM, cej38 wrote: > I am trying to learn how to use core.logic. Here is a toy problem > that I am thinking about. > > (run* [q] > (fresh [a b c] >(membero a [1 2 3]) >(membero c [1 2 3]) >(== b 2) >(!= a b) >(!= a c) >(!= b c) >(== q [a b c]))) > > I would like to create a function that replaces the three != lines, > something like, (distincto [a b c]) such that I could rewrite the > above problem as > > (run* [q] > (fresh [a b c] >(membero a [1 2 3]) >(membero c [1 2 3]) >(== b 2) >(distincto [a b c]) >(== q [a b c]))) > > I tried to write several functions but they are all end up inside some > variant of a col, [(!= a b)(!= a c)(!= b c)]. Thus, I either need > someone to help me figure out how do write the distincto function, or > what to call on [(!= a b)(!= a c)(!= b c)] to get it to work. > > > -- > 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 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
Re: distincto
Ambrose, Thanks for pointing me to the cKanren branch. Happy New Year. On Dec 31, 9:18 pm, Ambrose Bonnaire-Sergeant wrote: > I had a peek on the cKanren branch, distincto is basically all-diffo in > cKanren. > > https://github.com/clojure/core.logic/blob/cKanren/src/main/clojure/c... > > Here's the port to core.logic. (change !=c to !=) > > (defn distincto [l] > (conde > [(== l ())] > [(fresh [a] (== l [a]))] > [(fresh [a ad dd] > (== l (llist a ad dd)) > (!= a ad) > (distincto (llist a dd)) > (distincto (llist ad dd)))])) > > (run* [q] > (fresh [a b c] > (membero a [1 2 3]) > (membero c [1 2 3]) > (== b 2) > (distincto [a b c]) > (== q [a b c]))) > ;=> ([1 2 3] [3 2 1]) > > Pretty cool! > > Thanks, > Ambrose > > > > > > > > On Sun, Jan 1, 2012 at 4:31 AM, cej38 wrote: > > I am trying to learn how to use core.logic. Here is a toy problem > > that I am thinking about. > > > (run* [q] > > (fresh [a b c] > > (membero a [1 2 3]) > > (membero c [1 2 3]) > > (== b 2) > > (!= a b) > > (!= a c) > > (!= b c) > > (== q [a b c]))) > > > I would like to create a function that replaces the three != lines, > > something like, (distincto [a b c]) such that I could rewrite the > > above problem as > > > (run* [q] > > (fresh [a b c] > > (membero a [1 2 3]) > > (membero c [1 2 3]) > > (== b 2) > > (distincto [a b c]) > > (== q [a b c]))) > > > I tried to write several functions but they are all end up inside some > > variant of a col, [(!= a b)(!= a c)(!= b c)]. Thus, I either need > > someone to help me figure out how do write the distincto function, or > > what to call on [(!= a b)(!= a c)(!= b c)] to get it to work. > > > -- > > 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 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
