Re: Clojure 1.4.0 released silently?
On Tue, Apr 17, 2012 at 18:14 +0530, Ravindra Jaju wrote: All are supposed to implement their own readers which can read this event from the repository's tags. Haha! But in earnest: clojure-1.4.0 tag: https://github.com/clojure/clojure/commit/0ba3ff1a059625704500445c2d8553811301520b Changelog: https://github.com/clojure/clojure/blob/master/changes.md It looks as if it has been released, but not advertised for reasons unbeknownst to me. Maybe the powers that be decided that they don't want us to use 1.4.0. -- Wolodja babi...@gmail.com 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
[ANN] Clojure 1.4 Released
We are pleased to announce the release of Clojure 1.4: http://clojure.org/downloads For maven/leiningen users, your settings are now: :dependencies [[org.clojure/clojure 1.4.0]] This release includes significant features and bug fixes, documented here: https://github.com/clojure/clojure/blob/master/changes.md The number of Clojure contributors continues to grow. Thanks to all the people whose code is included in this release: Aaron Bedra Aaron Cohen Achim Passen Alan Dipert Alexander Taggart Alex Miller Alex Osborne Alex Ott Alex Redington Allen Rohner Andy Fingerhut Baishampayan Ghose Benjamin Teuber Ben Smith-Mannschott Brian Hurt Chas Emerick Chris Houser Chris Perkins Christophe Grand Christopher Redinger Clinton R. Nixon Colin Jones Cosmin Stejerean Daniel Solano Gómez David Liebke David McNeil David Miller David Powell David Rupp Devender Gollapally Dimitry Gashinsky Drew Raines Eric Schoonover Michael Fogus Frantisek Sodomka George Jahad Jarkko Oranen Jason Wolfe James Reeves Juha Arpiainen Justin Balthrop Kevin Downey Konrad Hinsen Kurt Harriger Lauri Pesonen Luke VanderHart Matt Revelle Meikel Brandmeyer Micah Martin Michał Marczyk Mike Hinchey Nicolas Buduroi Paul Michael Bauer Paul Stadig Phil Hagelberg Rasmus Svensson Richard Newman Rich Hickey Robert Lachlan Sean Corfield Stephen C. Gilardi Steve Gilardi Steve Miner Stuart Halloway Stuart Sierra Tassilo Horn Tim Dysinger Timothy Pratley Tom Faulhaber Thanks to all involved! Alan Clojure/core -- 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 moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Inconsistent refs within an STM transaction.
Hi Neale,
I think refs #1 is fine as it stands. That said, perhaps this clarification
will help: Start means as of current try, not as of first try. If the
transaction has no way to see new things on retry, then the retry cannot
possibly succeed where the initial try failed.
Stu
Hi,
We're all agreed that the behaviour I'm seeing is because the READ
transaction is re-starting. It sounds like the community thinks that's the
right behaviour and I'm happy to be educated
I don't believe that the READ transaction should need to restart just because
the underlying refs changed after it started and in fact if the refs have
history then the READ transaction isn't restarted.
I guess my observations could be re-phrased...
Is it desirable that the semantics around transaction re-start where the
transaction is purely a read-only transaction differ based on whether the
refs have history or not.
If everyone's happy that that's the case then an update to that point #1 on
clojure.org/refs is probably in order, because that's not how it reads at the
moment at least in my understanding.
thanks for your time.
Neale
{t: @sw1nn, w: sw1nn.com }
On Tue, Apr 17, 2012 at 7:20 AM, dennis zhuang killme2...@gmail.com wrote:
Hi,
I know your meaning.But it is real that the read transaction is
restarted,you can observer it by stm-profile:
https://github.com/killme2008/stm-profiler
(.start (Thread.
#(do (Thread/sleep 1)
(prn (ref-stats r1)
(Thread/sleep 2000)
r1 statistics:
{:deref 2, :get-fault 1}
It meant that r1's dereference get fault once,because no version of r1 value
precedes the read point in the first transaction.
Clojure STM deference value from new to old,that the newest value will be in
ref history queue head,and it found that the newest value's point is great
than transaction read point,so the tx is restarted.I think that
in-transaction value means that you can change the value in the transaction
in an atomic way and is thread safe that you don't have to worry about
concurrency.It's consistent in the transaction,but it may be not consistent
with other transactions.
2012/4/17 Neale Swinnerton ne...@isismanor.com
Hi Stu,
The point is that there's no reason for the READ transaction to restart, it
has only made reads of refs and those reads should be consistent with each
other from the snapshot of the the ref world as per...
In practice, this means:
All reads of Refs will see a consistent snapshot of the 'Ref world' as of the
starting point of the transaction (its 'read point'). The transaction willsee
any changes it has made. This is called the in-transaction-value
from: http://clojure.org/refs
The fact that the behaviour changes in the presence of history is a problem
in my opinion.
Yes you can 'ensure' that the refs aren't modified, but that means writes are
blocked by reads - is that desired?
Neale
{t: @sw1nn, w: sw1nn.com }
On Tue, Apr 17, 2012 at 2:59 AM, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Hi,
[disclojure]: I've asked about this on SO, but figured out what was
happening myself[1] and that led to this enquiry.
It seems that the consistency of refs within an STM transaction (dosync)
depends on whether the ref has history.
So if you create 2 refs and then read them in a transaction they could be
inconsistent with each other. i.e they won't necessarily return the value
the ref had at the start of the transaction.
However, if you give the refs some history by updating them in a prior
transaction, then the two refs will be consistent with each other in
subsequent transactions.
This seems rather dangerous to me. Is there a rational for not creating at
least 1 history entry for a ref at ref creation time.
Neale
{t: @sw1nn, w: sw1nn.com }
[1]
http://stackoverflow.com/questions/10178639/are-refs-really-consistent-within-a-stm-transaction
Hi Neale,
Your example does not appear to match your conclusion. It shows that a
transaction restarts, and that the reads are all consistent as of the
restarted transaction.
Cheers,
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
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 moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: [ANN] Leiningen 2.0.0-preview3
Hi, I am also getting this error on Windows. I think I have tracked down the source of the problem in lein-newnew. c.j.io/resource expects a path separated by /, and (.getPath file)returns a path separated by the system dependent separator (i.e. leiningen\\new\\default\\project.clj). I have a fix that is working for me, and I'm happy to submit a pull request. Cheers, Tim On Sunday, April 15, 2012 1:05:08 PM UTC-7, Niels wrote: lein new error under Windows 7 x64: lein version Leiningen 2.0.0-preview3 on Java 1.6.0_31 Java HotSpot(TM) 64-Bit Server VM lein new quiltest Generating a project called quiltest based on the 'default' template. java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:495) at clojure.java.io$fn__7795$G__7790__7802.invoke(io.clj:63) at clojure.java.io$reader.doInvoke(io.clj:96) at clojure.lang.RestFn.invoke(RestFn.java:410) at leiningen.new.templates$slurp_resource.invoke(templates.clj:29) at leiningen.new.templates$renderer$fn__713.doInvoke(templates.clj:79) at clojure.lang.RestFn.invoke(RestFn.java:423) at leiningen.new.default$default.invoke(default.clj:15) at clojure.lang.Var.invoke(Var.java:401) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.Var.applyTo(Var.java:518) at clojure.core$apply.invoke(core.clj:602) at leiningen.new$create.doInvoke(new.clj:54) at clojure.lang.RestFn.invoke(RestFn.java:425) at leiningen.new$create.invoke(new.clj:47) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.RestFn.applyTo(RestFn.java:132) at clojure.core$apply.invoke(core.clj:600) at leiningen.new$new.doInvoke(new.clj:101) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:405) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:518) at clojure.core$apply.invoke(core.clj:602) at leiningen.core.main$resolve_task$fn__699.doInvoke(main.clj:66) at clojure.lang.RestFn.applyTo(RestFn.java:139) at clojure.lang.AFunction$1.doInvoke(AFunction.java:29) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:602) at leiningen.core.main$apply_task.invoke(main.clj:88) at leiningen.core.main$_main$fn__731.invoke(main.clj:140) at leiningen.core.main$_main.doInvoke(main.clj:140) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:405) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:518) at clojure.core$apply.invoke(core.clj:600) at clojure.main$main_opt.invoke(main.clj:323) at clojure.main$main.doInvoke(main.clj:426) at clojure.lang.RestFn.invoke(RestFn.java:457) at clojure.lang.Var.invoke(Var.java:413) at clojure.lang.AFn.applyToHelper(AFn.java:172) at clojure.lang.Var.applyTo(Var.java:518) at clojure.main.main(main.java:37) -- 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 moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
a convenience idea for test functions
Often times I find myself writing code like the following (if (map? foo) bar baz) would it make sense to make test functions variadic, so if only passed a single argument it would return true/false, but could also act as an if when passed 3 arguments, eg: (map? foo bar baz) would return bar if foo is a map and baz otherwise. -- 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 moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: a convenience idea for test functions
IMO this is fairly absurd for a language default, but you can easily
do this yourself in a number of ways. For example:
(defmacro define-preds [ preds]
(cons `do
(for [pred preds]
`(defmacro ~(symbol (str pred +)) ~'[obj then else]
(list '~'if (list '~pred ~'obj)
~'then ~'else)
(define-preds map? string?)
(map?+ {} 1 2) ;; 1
This would be quite a lot easier if we didn't care about the short-
circuiting behavior of 'if, since then a simple higher-order function
would do it, something like (defn as-switch [pred] (fn [obj then else]
(if (pred obj) then else))).
On Apr 17, 9:16 pm, Dmitri dmitri.sotni...@gmail.com wrote:
Often times I find myself writing code like the following
(if (map? foo) bar baz)
would it make sense to make test functions variadic, so if only passed
a single argument it would return true/false, but could also act as an
if when passed 3 arguments, eg:
(map? foo bar baz) would return bar if foo is a map and baz otherwise.
--
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 moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Leiningen plugin authors: compatibility with version 2
Hello folks.
As you may know, Leiningen 2 introduces some breaking changes that
affect plugins. I've already investigated most of the commonly-used
Leiningen plugins and helped fix many of them, but I haven't tried
them all. If you have a plugin of your own, it would be very helpful
if you could test it with Leiningen 2. In many cases it will work fine
with no changes, especially for simpler plugins. If this is the case,
it would be helpful if you could note the fact that your plugin is
compatible with Leiningen 2 in the readme and include instructions for
installing both under 1.x and 2.x, since the installation is
different. Something like this would do nicely:
# Installation
If you use Leiningen 2.x, add to your ~/.lein/profiles.clj file:
{:user {:plugins {lein-difftest 1.3.8}}}
Users of Leiningen 1.x can install via:
$ lein plugin install lein-difftest 1.3.7
It would also be great if you could mark your plugin as confirmed to
be compatible on the plugins wiki:
https://github.com/technomancy/leiningen/wiki/Plugins
If your plugin doesn't yet work with Leiningen 2, there are
instructions on upgrading it in the plugin guide under Upgrading
Existing Versions:
https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md If
you have any trouble upgrading it, please ask for help either in the
#leiningen channel on freenode or on the Leiningen mailing list. If
you are a user of a plugin that hasn't been upgraded, you might ask
the maintainer if he has plans to upgrade it or consider contributing
patches for compatibility.
thanks,
Phil
--
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 moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: a convenience idea for test functions
On Tue, Apr 17, 2012 at 9:16 PM, Dmitri dmitri.sotni...@gmail.com wrote: (map? foo bar baz) would return bar if foo is a map and baz otherwise. To elaborate on Alan's response, consider: (if (map? foo) (/ bar 0) baz) If map? were 'merely' a variadic function, (map? foo (/ bar 0) baz) would fail because (/ bar 0) would be evaluated and then passed as an argument, along with foo and baz. So, no, the simple answer is that you can't just make the test functions variadic and get the same behavior as an if form (hence Alan's suggestion of a macro-generating macro to create new macros for the forms you want). (Apologies if I'm laboring the point here) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
