On Sun, Aug 28, 2011 at 9:22 PM, Kevin Lynagh klyn...@gmail.com wrote:
I am having trouble using ClojureScript to call JavaScript functions
that exploit prototype injection.
If I'm reading `defmethod :emit invoke` correctly,
Hi,
the commute case can be understood:
user= (send thread (fn [agt aref] (dosync (commute aref + 100)
(Thread/sleep 8000) agt)) account)
#Agent@1950e0a: Thread
user= (time (dosync (ref-set account 2000)))
Elapsed time: 0.369415 msecs
2000
user= @account
2000
;; wait a few seconds
user=
Hi,
alter obviously has a similar effect as ensure. Exchanging the sleep and the
alter will allow the repl thread to do its ref-set and the background thread
will retry.
Don't ask me for the details of why and how...
Sincerely
Meikel
--
You received this message because you are subscribed
@Bob -- recovery group, stop now, -- hehehe. It certainly is a
great website for when I get bored with the daily grind of enterprise-
Java coding. I guess I was lucky to get stuck on one problem.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Clojure 1.3 Beta 2 is now available at
http://clojure.org/downloads
The list of changes:
* clojure.test/*/*-report vars made dynamic for use with external
tools.
* Calls favor arg vectors :tag over var :tag (CLJ-811)
* BigInt ops made faster when values are small enough to be treated
Chouser,
Yes, that does it---I didn't even think about my use of (apply js/f
args), thanks!
Is there a way to use the interop form with variable-arity JavaScript
functions without using `apply`?
This issue came up with my ClojureScript wrapper for D3; I'm using
this macro
(defmacro shim
Hello,
I wanted to give a try to ClojureScript but from Windows XP.
Now I was doing all what is written on github but had to remove -server to
obey missing jvm.dll problem (even after coping server path there was
still a problem about loading some routine) and had to add to ENV Variables
The call to alter already wrote to the Ref, this requires a write-lock on
the ref (see LockingTransaction.java/doSet). After that it sleeps a while
and gets to its commit phase. The other transactions retries in the
meantime. Consider the following code, which introduces some atoms for
Hi,
Assuming I have:
(defrecord myrecord [:a :b :c])
is there a way to get the list of keys from the record definition?
Thanks,
Razvan
--
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
user= (defrecord MyRecord [a b c])
user.MyRecord
user= (def rec (user.MyRecord. one two three))
#'user/rec
user= (keys rec)
(:a :b :c)
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 08/29/2011 12:54 PM, Razvan Rotaru wrote:
Hi,
Assuming I have:
(defrecord myrecord [:a :b :c])
Thanks a lot for this detailed analysis and the pointers to the Java
implementation, Stefan! That's excellent and very helpful.
I still wonder, why the first transaction blocks write access. My
overall understanding of the transaction system is that changes to
referenced values remain
Aaron Bedra aaron.be...@gmail.com writes:
user= (defrecord MyRecord [a b c])
user.MyRecord
user= (def rec (user.MyRecord. one two three))
#'user/rec
user= (keys rec)
(:a :b :c)
I guess the problem with that is that you need to have an instance of
the record before you can use `keys'. And
Hm,
while I was just reading the source of the STM implementation in Ref.java
and LockingTransaction.java two new questions came up for me.
1. Is there any use of the msecs field in the inner TVal in Ref? I don't see
any and if it's not used anymore, at least two calls to
Progress... is slow.
I encouraged other people to try, so the least I can do now is to point you
at some of the serious challenges.
Right now I have what I think is a nice semi-generic mechanism for
invokedynamic. It's called the Linker: it handles finding the target
method handle,
Hi! I wonder if someone might tell me what I'm doing wrong here.
(ns hello (:require [goog.fx :as fx] [goog.dom :as dom]))
(defn ^:export main []
(let [kurdt (dom/getElement kurdt)]
(dom/appendChild (.body (dom/getDocument)) (dom/createDom h1 0
(dom/getOuterHtml kurdt)))
(fx/Dragger.
Congratulations, you've found a bug in clojure 1.3 beta2, see:
look with my clojure 1.2.0 version :
;; Clojure 1.2.0
= (def thread (agent Thread))
(def account (ref 1000))
(send thread
(fn [agt aref] (dosync (alter aref + 100) (Thread/sleep 8000) agt))
account)
(time
The version of ASM that is bundled in Clojure is very old. This will
likely cause problems. You are correct in looking to ASM 4 since it has
started supported the JSR-292 stuff and other Java 7 changes. I am
planning on doing an extraction, update, and re-packaging of ASM in
Clojure as soon as
ok so now i'm totally confused, since I cannot see why the behaviour is so
different between beta1 and beta 2 ...
2011/8/30 Laurent PETIT laurent.pe...@gmail.com
Congratulations, you've found a bug in clojure 1.3 beta2, see:
look with my clojure 1.2.0 version :
;; Clojure 1.2.0
= (def
On 08/29/2011 06:01 PM, Aaron Bedra wrote:
The version of ASM that is bundled in Clojure is very old. This will
likely cause problems. You are correct in looking to ASM 4 since it has
started supported the JSR-292 stuff and other Java 7 changes. I am
planning on doing an
There is no good way to do this in 1.2 other than using the instance
mechanism that Aaron suggests. I have had this need myself for
several meta-programming type use cases (building specialized record
serializers, universal record constructors, etc). We wrap defrecord
in our own macros that
On Aug 29, 2011, at 2:57 PM, Tassilo Horn wrote:
I guess the problem with that is that you need to have an instance of
the record before you can use `keys'. And to create an instance, at
least you have to know the number of keys.
However, you can inspect the record's constructor using
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L424
is definitely the line that causes the write lock to be acquired.
I get the same behavior on master(1.3) and 1.2.1:
the first time I run the code on a particular ref it locks for writing
while the
weird, it actually ping-pongs, every other run of the (time …) the
transaction in the future locks the ref writing so you get
Elapsed time: 10006.505 msecs
Elapsed time: 0.358 msecs
Elapsed time: 9038.18 msecs
Elapsed time: 0.348 msecs
Elapsed time: 26250.854 msecs
On Mon, Aug 29, 2011 at 6:13
On Aug 29, 2011, at 8:20 PM, Alex Miller wrote:
I'm not sure if there are any enhancements in the 1.3 record support
for this feature.
In 1.3beta2, the record class has a static method getBasis that will give you
the fields. I remember Fogus mentioning this on the mailing list. The design
Firebug says goog.fx.Dragger is not a constructor.
Firebug's error message doesn't match my understanding of the
goog.fx.Dragger documentation, but yes, that line did stop the script.
http://closure-library.googlecode.com/svn/docs/class_goog_fx_Dragger.html
On Mon, Aug 29, 2011 at 6:50
https://github.com/hiredman/clojure/compare/master...apocrypha-stm#L0L296
I've been playing around with the stm, and I think this change gives
you the behavior that is intuitively expected, someone else will have
to speak for correctness. ant test runs successfully but I don't know
how extensive
The change to beta2 isn't working for me:
dependency
groupIdorg.clojure/groupId
artifactIdclojure/artifactId
version1.3.0-beta2/version
/dependency
1.3.0-beta1 works fine.
On Aug 29, 7:28 am, Christopher Redinger redin...@gmail.com wrote:
Clojure 1.3 Beta 2 is now
I came across the following behavior today, and wanted to make sure
it's expected (on 1.2 and 1.3-beta2).
Each time a reify form is executed, two fresh objects seem to be
created; one is immediately thrown away, and the other is returned
from the form:
user= (defn foo [] (let [x (reify Object
On Wed, Aug 10, 2011 at 7:39 AM, Rich Hickey richhic...@gmail.com wrote:
:use … :only doesn't have the problems of full :use.
Enhancement ticket and patch for :use … :only welcome. Note it must support
:use … :only only, i.e. :only is required.
Rich
False alarm. Some trouble with the VPN line.
On Aug 29, 9:06 pm, Armando Blancas armando_blan...@yahoo.com wrote:
The change to beta2 isn't working for me:
dependency
groupIdorg.clojure/groupId
artifactIdclojure/artifactId
version1.3.0-beta2/version
/dependency
Not surprisingly, some of the benchmarks game programs written for
Clojure 1.2 have problems with 1.3 Beta 2.
My guess is that small changes to the programs will be required to
catch up with the new version, but occasionally program failures have
indicated a bug in new versions of other
31 matches
Mail list logo
