On Apr 15, 1:51 am, Kasim ktu...@gmail.com wrote:
Here are what you need to get started:
1. Download ClojureW.zip and Unzip to a folder
0. Try to find the link to download.
--
Zmitro Lapcionak
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Hi,
is there any nonblocking way I kind find out whether a promise has
been delivered?
Thanky you, alux
--
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
More oddness:
If I remove all unit tests *except* test-compex-numbers, all is well:
[INFO] [clojure:test {execution: test-clojure}]
Testing clojure.contrib.test-complex-numbers
Ran 8 tests containing 268 assertions.
0 failures, 0 errors.
If I remove only test-complex-numbers, leaving
Not currently. I added the capability to some code I posted last month
for fixing print-method for promises so they aren't auto-dereferenced
when undelivered:
(defn promise?
[p]
(isa? (type p) ::Promise))
(defn promise-delivered?
[p]
(zero? (.getCount (:d p
(defmethod print-method
On 17 April 2010 16:46, Per Vognsen per.vogn...@gmail.com wrote:
Not currently. I added the capability to some code I posted last month
for fixing print-method for promises so they aren't auto-dereferenced
when undelivered:
Personally, I would prefer them never to be dereferenced for
Many thanks to Meikel Brandmeyer, whose code (after a one-character typo
correction) worked the first time. As soon as I saw it, I understood every
line of it; the problem was, it wouldn't have occurred to me to put all
those elements (which, individually, I understood) together in just that
way.
On Sat, Apr 17, 2010 at 15:45, B Smith-Mannschott bsmith.o...@gmail.com wrote:
More oddness:
If I remove all unit tests *except* test-compex-numbers, all is well:
[INFO] [clojure:test {execution: test-clojure}]
Testing clojure.contrib.test-complex-numbers
Ran 8 tests containing 268
On 16 April 2010 16:25, Asim Jalis asimja...@gmail.com wrote:
Could you explain the rationale for this swapping? Intuitively it
seems to me that (let [{ :body x } { :body 42 }] x) should bind x
to 42 -- it seems intuitive because it is binding :body to :body
and 42 to x.
My personal take on
Hello Per,
thats very cool! Many thanks! Completely solves my problem. (As far as
I can see :-)
I'm not sure whether I completely understand the implications of the
nondeterminism you described; will think about it. You say When each
promise can only be written by a single writer.. - I assume
On Sat, Apr 17, 2010 at 11:07 PM, alux alu...@googlemail.com wrote:
Hello Per,
thats very cool! Many thanks! Completely solves my problem. (As far as
I can see :-)
I'm not sure whether I completely understand the implications of the
nondeterminism you described; will think about it. You say
I have an application that will read in a large number of structures
from a file. those structures will be used throughout the application
to produce additional data etc. since they are user configurable,
it would be nice to know where they come from should one of them start
misbehaving. the
Thank you all for the explanations. I see now that I wasn't paying
close enough attention, and needed to add another pair of brackets to
destructure my lambda's single argument.
On Apr 16, 11:51 am, Per Vognsen per.vogn...@gmail.com wrote:
Tangent:
On Fri, Apr 16, 2010 at 7:41 PM, Douglas
Does anyone know of a clojure library for handling (un)packing of
binary structures? I'm looking for something similar to perl/ruby/
python's pack(...) function or something like OCaml's bitstring
module. My initial google and clojure-contrib perusing hasn't turned
up anything obvious though
Found the link here:
http://bitbucket.org/kasim/clojurew/get/tip.zip
Kasim - thanks for the quick start. Worked fine. Maybe add a readme?
M.
On Apr 17, 5:35 am, Zmitro Lapcjonak idob...@gmail.com wrote:
On Apr 15, 1:51 am, Kasim ktu...@gmail.com wrote:
Here are what you need to get started:
On Sat, Apr 17, 2010 at 18:02, B Smith-Mannschott bsmith.o...@gmail.com wrote:
On Sat, Apr 17, 2010 at 15:45, B Smith-Mannschott bsmith.o...@gmail.com
wrote:
More oddness:
If I remove all unit tests *except* test-compex-numbers, all is well:
[INFO] [clojure:test {execution: test-clojure}]
On Sat, Apr 17, 2010 at 2:29 AM, Kevin Livingston
kevinlivingston.pub...@gmail.com wrote:
I have an application that will read in a large number of structures
from a file. those structures will be used throughout the application
to produce additional data etc. since they are user
I let Meheadable and George (my two macs) run clojure-contrib builds
while I was watching TV to get an idea of the probability of this
crash occurring was.
George, a 1 GHz PowerPC G4 (1 core) fails 37 of 59 builds (circa 63%)
Meheadable, a 2.2 GHz Core2Duo (2 cores) fails 48 of 132 builds (circa
It's almost certainly the commit that added the InternalReduce
protocol: 5b281880571573c5917781de932ce4789f18daec.
I am slowly pounding my skull against this and would welcome any help.
It appears that the internal-reduce function flakes out and stops
working, but only intermittently.
If
I am seeing compilation errors in my code with deftype. I just updated
my project dependencies and probably pulled in the latest clojure
package. Anyway, the following code from wiki doesn't work anymore.
Pointers to any late breaking changes much appreciated!
TIA
(deftype Bar [a b c d e])
(def
(deftype Bar [a b c d e])
(def b (new Bar 1 2 3 4 5))
There are a few other syntax changes too, defrecord replaces extending
IPersistenMap, and you need to include 'this' in protocol fun
implementations ...
http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/deftype
Based on the Embedding section of http://github.com/technomancy/swank-clojure,
I'm using the following to test it out. Is there a better way to do
this that doesn't use Compiler? Is there a way to programmatically
stop swank? It seems start-repl takes control of the thread. What
would be a
21 matches
Mail list logo
