There is a small but particularly nasty corner of the third circle of
Hell reserved for people who mandate environment variables. Don't go
there.
On Feb 25, 3:47 pm, "Stephen C. Gilardi" wrote:
> On Feb 25, 2009, at 1:27 PM, Mark Colburn wrote:
>
> > #!/bin/sh
> > DP="${0%/*}"
> > java -cp ~/s
Can't find the chapter and verse, but a bit of googling shows that
GCJ does this optimization
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02312.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
No, but the semantics of java.lang classes are fully specified in the
Java spec, and JVM implementers are allowed to rely on them. It's
entirely possible that there are special case optimizations for
java.lang.Math calls.
--~--~-~--~~~---~--~~
You received this mes
Note, however, that your JVM may very well know that java.lang.Math.log
(0.5) is a constant, and optimize the calculation out of the JIT
compiled code. This wouldn't show up in the bytecode, and is
extremely difficult to actually check. Whether or not any JVM
actually does this probably depends
It looks like the mutable locals use case is covered by the "with-
local-vars" binding form. That said, I'm not sure how useful this
would be. Even in Java 5, 95% of my local vars are immutable, i.e
annotated as final and never have any mutating methods called on
them. Most of the rest are simp
>
> Ah, I believe I finally understand the difference between send and
> send-off. To describe it in my own words, send-off creates a new
> thread each time, while send schedules to a thread in a thread pool.
>
Not quite true, but close. Send-off requests a thread from a
CachingThreadPool, but
> I'm actually trying to get a notification after a transaction
> successfully finished.
Well that's easy. Agent sends are buffered in a transaction, and only
sent upon successful commit. The coolness of this is hard to
overestimate.
Right now, you add listeners to agents, but not refs. IIRC, there
was talk of adding listeners to refs to enable just the sort of
reactive programming you describe, but I don't know the status.
--~--~-~--~~~---~--~~
You received this message because you are subsc
that a parser could theoretically have. On the
downside, you can't tell until runtime whether a given function call
has an acceptable arity, which pretty much any other popular language
can check at edit-time.
--Dave Griffith
--~--~-~--~~~---~--~~
You received
TED]> wrote:
> On Thursday 11 December 2008 06:33, Dave Griffith wrote:
>
> > On Dec 11, 9:21 am, bOR_ <[EMAIL PROTECTED]> wrote:
> > > Hi all,
>
> > > I thought I remembered there was a method in the api somewhere that
> > > would count the frequency
Excellent! This is a great way of making code fail-fast for a class of
bugs that would normally only occur under load (i.e. at the worst
possible time).
--Dave Griffith
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
(defn frequencies [coll]
(reduce (fn [map val] (assoc map val (if (contains map val)
(get map val) 1)) #{})
)
On Dec 11, 9:21 am, bOR_ <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I thought I remembered there was a method in the api somewhere that
> would count the frequency of each uniq
Since it requires changes to the Clojure runtime, it probably doesn't
make much sense to put it in contrib. I've posted it as an attachment
to the group.
--Dave Griffith
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
nd is perfectly fine, although it looks like
exposing a method in LockingTransaction would be more performant.
--Dave Griffith
On Dec 8, 6:07 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> Hi Dave,
>
> It looks like LockingTransaction.getRunning would need to be made
> publ
prohibitted in transactions, but questions were raised as
to whether there was any way to actually prevent it. Looking through
the API, I couldn't find any way of detecting when execution was
occuring in a transactional context or not.
--Dave Gri
used for
production purposes. Contents may have settled during shipping. All
models over 18.
Where should I send the patch?
--Dave Griffith
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" grou
> Maybe if the external commit
> can be delayed until the end of the transaction, when it is certain
> that the in-memory operations succeeded, it could work. I think this
> is the most promising way of implementing this.
This was my plan. As near as I can tell, the current STM
implementation co
ld be pretty easy to extend
the STM with features like timeouts and such.
Thoughts? Am I missing anything? Has this already been attempted in
some way I was unable to google for? My temptation is to try to
implement something as a quick spike and
elicensed as Apache 2.0.I don't know if that's
something you might be interested in eventually, but it's something to
think about. It's early days for Clojure, but who knows what the
future might bring.
Dave Griffith
--~--~-~--~~~---~--~~
You re
One big issue to note is that, because of Refs, Clojure agent
semantics can't simply be remoted the way Erlang processes can be.
This is because a message send could include a references to a Ref,
thus exposing mutable state remotely. This breaks, well, just about
everything.
If you restrict th
20 matches
Mail list logo