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...
>
> He
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 [
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
> 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 Transact
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. Perha
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 req
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
pr
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
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 p
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 thr
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
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
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
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 s
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.
A
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 to
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(IceCreamSandwhic
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,
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
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
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 glassfis
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 tha
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 t
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 r
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
> 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.
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 pre
27 matches
Mail list logo
