I've heard a lot that Google App Engine's use of many JVMs makes
Clojure refs, etc. less useful than they are on one JVM. I'm curious—
what are the consequences of using a ref normally in Google App
Engine? How would it be broken? Would each JVM, invisibly, each store
a different value for the ref
Should be fixed in the latest commit.
Any of the following will work.
(System.Reflection.Assembly/Load "WindowsBase, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35")
(import '(System.Windows.Media Matrix))
(defn b [m] (doto m (.Scale 2.0 3.0)))
(defn a1 [] (b (Matrix.)))
(defn
>From what I've observed in the community, it seems that java library
dependencies are not discouraged. Lot of good things have been written
in java that perhaps don't need rewriting from ground up. It's one of
Clojure's big pluses.
I personally would go the "from ground up" route only if the exi
Hey, you're one up on IronRuby, which had a bug where one couldn't create an
instance of a CLR struct!
http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=1788
On Wed, Sep 30, 2009 at 3:45 AM, David Miller wrote:
>
> Short answer: It's a bug.
> Longer answer: It's a problem with type pro
I have no doubt spy is easy to use and fairly straightforward to
encapsulate. But doesn't this strategy somewhat complicates the use
and deployment from Clojure? I would think a user would prefer a
"pure" Clojure solution that hides the Java hooks and does not depend
on third part jars.
Paulo
On
On Wed, Sep 30, 2009 at 1:39 PM, John Harrop wrote:
> On Tue, Sep 29, 2009 at 7:21 PM, David Miller wrote:
>
>> Mono:
>> - One BigDecimal implementation away from getting serious about
>> this.
>
>
> Why doesn't Mono have a BigDecimal analogue? It shouldn't, in principle, be
> difficult to crea
I've personally found using the spymemcached through java introp extremely easy,
(def mc (MemcachedClient. (list (InetSocketAddress. "127.0.0.1" 1211
(.. mc (set "topic:1" 3600 topic))
(.. mc (get "topic:1"))
(.. mc (getBulk coll))
etc.
Perhaps a simple macro wrappers to encapsulate some co
Thanks! This is just what I wanted. The latest version is at:
http://paste.lisp.org/display/71652
Best,
Mike
On Sep 30, 12:33 am, Meikel Brandmeyer wrote:
> Hi,
>
> maybe the following comes close?
>
> http://groups.google.com/group/clojure/browse_thread/thread/3ea877788...
>
> Sincerely
>
Hi,
On Wed, Sep 30, 2009 at 7:18 PM, Matt Brown wrote:
> Using a million iterations, I got:
> (myavgtime (+ 1 2 3) 1e6 mytime1) -> 0.00027 - 0.00029 msec (over a
> dozen repeats)
> (myavgtime (+ 1 2 3) 1e6 mytime2) -> 0.00068 msec (single run,
> printing 10^6 lines takes a long time, I was too i
On Tue, Sep 29, 2009 at 7:21 PM, David Miller wrote:
> Mono:
> - One BigDecimal implementation away from getting serious about
> this.
Why doesn't Mono have a BigDecimal analogue? It shouldn't, in principle, be
difficult to create an open-source-friendly implementation backed by GMP.
--~--~-
Hi,
I am just learning Clojure (and Lisp) and I was thinking about
developing a Clojure memcached client as an exercise. I am in doubt
about the best way to do it. I could just write a thin wrapper around
some existing Java memcached library (like Dustin Sallings'
spymemcached or Greg Whalin's me
Hi.
Thanks all, for your comments.
> You need to use a bigger number than 1000 for these results to be meaningful.
Out of curiousity, why is this?
Does the JIT do something different after 1000 iterations?
Or is the concern simply that the variance of the mean estimate is too
high with 1000 vs.
Well, after removing all jars except clojure and clojure-contrib, I
still get the exact same error. Apparently, it doesn't like the import
statement in java_utils.clj in clojure-contrib. Very weird.
I think I'll revert back to clojure 1.0 for now, and try again at a
later date.
-Matt Courtney
--
Sorry, that was TOO easy. Too many years as a Java programmer have
rotted my brain!.
--~--~-~--~~~---~--~~
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
You need to use a bigger number than 1000 for these results to be
meaningful.
FWIW, I've run both on my Toshiba dual core laptop with ubuntu, and
they return approximately the same values.
(and there is some JIT trickery going on, as I got:
user=> (myavgtime (+ 1 2 3) 1000 mytime1)
(myavgtime (+
Hi Meikel !,
2009/9/30 Meikel Brandmeyer
>
> Hi Laurent,
>
> On Sep 30, 9:46 am, Laurent PETIT wrote:
>
> > Where should the responsability be placed ? Should the user of the
> library,
> > in doubt, place everywhere in his code bind-fn calls to protect it ?
> Should
> > the library author use
Hi Laurent,
On Sep 30, 9:46 am, Laurent PETIT wrote:
> Where should the responsability be placed ? Should the user of the library,
> in doubt, place everywhere in his code bind-fn calls to protect it ? Should
> the library author use bind-fn before dispatching to other threads (with the
> probl
Hello Rich,
It's been a long time since I've not hijacked a thread, so let's get back to
this bad habit exceptionally :)
While the example provided by jon may not be the best ones, as you pointed
out below, I feel there still is a problem: dynamic scopes and threads.
I don't know how it can be c
Short answer: It's a bug.
Longer answer: It's a problem with type propagation in let. It'll
take me a day or so to fix it.
The handling of non-primitive value types by the compiler still has
some problems. Any place where the JVM compiler is discriminating
between primitive types and reference
Hi,
maybe the following comes close?
http://groups.google.com/group/clojure/browse_thread/thread/3ea8777880231e18/6fd1b352ac1a6744?lnk=gst&q=trace#6fd1b352ac1a6744
Sincerely
Meikel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On Tue, 2009-09-29 at 22:54 -0700, Meikel Brandmeyer wrote:
> Hi,
>
> On Sep 30, 12:19 am, Cliff Wells wrote:
>
> > In short, you've taken something that was originally CPU-bound and made it
> > I/O-bound.
>
> I don't think so. The measured times do not include the println. The
> loop with th
21 matches
Mail list logo