Awesome, thanks for the help and the clarification!
On Monday, April 6, 2015 at 1:59:21 AM UTC+3, Alex Miller wrote:
>
> Yes, each platform defines their own platform feature so it wouldn't be
> too hard to change the specified platform in the fork. However the key here
> is that the conditional
Yes, each platform defines their own platform feature so it wouldn't be too
hard to change the specified platform in the fork. However the key here is that
the conditional occurs at read time, so you need to ensure that compilation
happens with this platform if aot is involved. Maybe that's obvi
On the other hand, Clojure-Android runtime is largely similar to regular
Clojure except for some small differences; so in order to use feature
expressions there effectively it might make sense to wait until broader
capabilities (feature combinations, feature inheritance etc.) is introduced.
--
Well, I must say I'm even more ignorant in how the feature expansions are
implemented. Is the feature a thing that each implementation defines
separately? If so, then it will be easy to set our fork's feature as :clja,
or whatever else. My request to you would then be: can you please include
:c
The reader can be invoked programmatically with any feature set you like now.
We did not plan to allow custom features for 1.7.
I'm not sure what it would mean to "add" an android feature? I'll plead
ignorance in not knowing how the Clojure
Android stuff works or where a feature indicating Andr
Hello Alex,
As I've understood from the dev.clojure.org page, additional features and
feature combinations will become available later. Can we please get
:clj/android (or :clja) still in 1.7? If so, what has to be done by me or
Daniel to make it happen?
Thanks!
On Tuesday, March 31, 2015 at 7
Yes, I'll get that in the next release, I forgot to put it in there...
On Saturday, April 4, 2015 at 6:45:07 PM UTC-5, Andy Fingerhut wrote:
>
> I believe that change is due to this commit from early March 2015:
> https://github.com/clojure/clojure/commit/692645c73c86d12c93a97c858dc6e8b0f4280a0b
I believe that change is due to this commit from early March 2015:
https://github.com/clojure/clojure/commit/692645c73c86d12c93a97c858dc6e8b0f4280a0b
Nicola Mometto had opened a ticket CLJ-1593 for this issue:
http://dev.clojure.org/jira/browse/CLJ-1593
The commit did not reference the ticket, but
Hi Alex, All,
An observation really.
I've just noticed that a literal map e.g. (def m {:a 1 :b 2 :c 3}) in
alpha6 is an array map not hash map.
In 1.6.0 and 1.7.0-alpha5 its a hash map.
Couldn't find any obvious statement in the release notes but interested in
the background to the change.
If you want caching behavior, then use it as a sequence. If you want faster
iteration, use it via reduce. The whole point of this change is to open the
faster reduce path, which you won't get if you also cache.
I did some research a few months back via crossclj looking at how people
typically u
Alex:
I'd bet heavily on the "slower" ones being measurement noise (they only
differ by a few percent) - I typically see that much variation between
runs. I probably shouldn't have reported them as "slower" - 1-5% is (in my
experience) typically just noise, so don't think it's worth digging int
Actaully caching makes a difference even with inc and a sequence of just
1000 elements:
Clojure 1.7.0-alpha5
user=> (def a (iterate inc 0))
#'user/a
user=> (time (reduce (fn [_ x]) nil (take 1000 a)))
"Elapsed time: 4.170778 msecs"
nil
user=> (time (reduce (fn [_ x]) nil (take 1000 a)))
"Elapsed
The recent changes to iterate come with an interesting consequence:
reducing an iterate multiple times will cause the entire chain of x, (f
x), (f (f x)) .. to be recalculated every time.
I'd argue that this is not desiderable and a regression (even though
probably one considered by design), and
Yup. Fixed.
On Thursday, April 2, 2015 at 1:24:46 PM UTC-5, Leon Grapenthin wrote:
>
> http://dev.clojure.org/display/design/Reader+Conditionals
>
> First use-case "Platform-specific require/import":
>
> Shouldn't the reader conditional example be:
> (ns cemerick.pprng
> #?(:cljs (:require math.
http://dev.clojure.org/display/design/Reader+Conditionals
First use-case "Platform-specific require/import":
Shouldn't the reader conditional example be:
(ns cemerick.pprng
#?(:cljs (:require math.seedrandom
[cljs.core :as lang]))
#?@(:clj [
(:require [clojure
Not a bug imho, you're invoking reduce with no init arg so you're
forcing the realization of at least two elements in the coll, one for
init and one for step -- the step one causes the exception.
Ambrose Bonnaire-Sergeant writes:
> Here's some weird behaviour I found from 1.6.
>
> user=> (take 1
Great to hear feedback like this! I'd be particularly interested if you had any
suspicions about the characteristics of the ones that are slower.
> On Apr 2, 2015, at 3:22 AM, tcrayford wrote:
>
> Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark suite
> (using criterium
Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark
suite
(using criterium, with a heck of a lot of work put into getting real and
good
results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 -
it's
pretty comprehensive, and covers a wide range of things. Resul
Here's some weird behaviour I found from 1.6.
user=> (take 1 (iterate zero? true))
(true)
user=> (reduce (fn [l _] (reduced l)) (iterate zero? true))
ClassCastException java.lang.Boolean cannot be cast to java.lang.Number
clojure.lang.Numbers.isZero (Numbers.java:90)
Is this a bug, and should th
Thanks! If anyone wants to throw a patch, would love to have one. Must
include test ...
On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant
wrote:
>
> http://dev.clojure.org/jira/browse/CLJ-1692
>
> On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant <
> abonnair...@
http://dev.clojure.org/jira/browse/CLJ-1692
On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> Ok.
>
> On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller wrote:
>
>> I would love a jira for the iterate thIng.
>>
>> --
>> You received this message because y
Ok.
On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller wrote:
> I would love a jira for the iterate thIng.
>
> --
> 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 mem
I would love a jira for the iterate thIng.
--
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 unsub
Actually it seems the oddity is that "next" now does the computation
instead of "first" in Iterate.java.
On Wed, Apr 1, 2015 at 8:56 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> AFAICT there is consistently one extra call, which seems to suggest an
> off-by-one error in t
AFAICT there is consistently one extra call, which seems to suggest an
off-by-one error in the IReduce implementation of Iterate.
;; 1.6
user=> (take 11 (iterate (fn [a] (prn (str "PR" a)) (inc a)) 1))
"PR1"
"PR2"
"PR3"
"PR4"
"PR5"
"PR6"
"PR7"
"PR8"
"PR9"
"PR10"
(1 2 3 4 5 6 7 8 9 10 ...)
;; 1.7.
Ambrose, does that "iterate" result arise from chunking? "iterate" is
advertised as producing an infinite lazy sequence. While a suddenly
chunking "iterate" will no doubt smoke out some cases like this, doesn't it
seem that they are abuses? It's not quite spot-on to employ "take" or
"take-wh
Hi,
Iterate calls its function after it is finished iterating.
;; clojure 1.6
user=> (take 2 (iterate zero? 0))
(0 true)
;; clojure 1.7-alpha6
user=> (take 2 (iterate zero? 0))
ClassCastException java.lang.Boolean cannot be cast to java.lang.Number
clojure.lang.Numbers.isZero (Numbers.java:92)
@Alex Miller — Thanks! I appreciate it.
On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"
We'll consider it, thanks for the questions.
On Wednesday, April 1, 2015 at 2:32:58 PM UTC-5, Alexander Gunnarson wrote:
>
> @Sean Corfield — That's exactly my point. I use Sublime Text and I usually
> just copy-paste code from various buffers / open files into a REPL buffer
> on my workspace. M
@Sean Corfield — That's exactly my point. I use Sublime Text and I usually
just copy-paste code from various buffers / open files into a REPL buffer
on my workspace. Maybe that's not the most efficient way, and I want to
move to some sort of auto-reload plugin for leiningen a la figwheel for
Cl
@Alex Miller: Thanks for letting me know. I'll unfortunately have to change
my workflow accordingly.
On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1
REPLs are of course free to choose how they read and some of the other
changes coming out of the socket repl work may make those choices easier to
select. The clojure.main/repl function is already (perhaps excessively)
parameterized and can be given a custom read function for example. The read
and
On Apr 1, 2015, at 10:09 AM, Alex Miller wrote:
> There is no way to "turn on" read conditionals by default at the REPL - it is
> only on by default when loading a .cljc file.
This sounds like a useful feature to add to the REPL tho’ so that you can
copy’n’paste code as-is and have it behave "a
If you want to invoke the reader programmatically with reader conditionals
allowed, you can do that through the (new) options map available with both
read and read-string:
user=> (read-string {:read-cond :allow} "#?(:clj foo :cljs bar)")
foo
There is no way to "turn on" read conditionals by def
This patch is incredibly useful! Great job to everyone that contributed.
One question: how do I enable conditional reading by default in the REPL as
opposed to passing a properties map to /read-string/, etc.? Do I set
certain system properties in the command line like "cond_read=true"?
On Tuesd
If this is a use case that could be lifted out into an API level function,
that would be an ok enhancement jira request to consider (would need to
think about it more, but that seems like one option).
On Tuesday, March 31, 2015 at 6:12:09 PM UTC-5, puzzler wrote:
>
> The reason instaparse uses C
Ok, thanks - I was looking for a way to access the data, right, I'll try
tagged-literal for this.
On 1 April 2015 at 17:03, Alex Miller wrote:
> We do not expect to provide readers for the #object and #error forms
> (afaik). It's not possible to actual create a new Object or Throwable form
> tha
We do not expect to provide readers for the #object and #error forms
(afaik). It's not possible to actual create a new Object or Throwable form
that would be useful as an instance.
The new tagged-literal function could be used as a fallback reader function
for either though, which would then allow
One question - it appears that the new #object and #error forms aren't
readable at the moment. Is this something that's coming, or is the
intention just that people could provide reader functions for these if they
wanted to?
On 1 April 2015 at 14:01, Sean Corfield wrote:
> With instaparse 1.3.6
With instaparse 1.3.6 available, we’ve been able to upgrade our dev stack to
Clojure 1.7.0-alpha6 and all our automated tests pass (and our full build/test
script seems to be running a bit faster although we haven’t actually
benchmarked our application yet). We’ll push alpha6 into QA either late
This patch is great! It's much needed for my development workflow. One
question: how do I enable conditional reading by default in the REPL? Do I
set certain system properties in the command line like "cond_read=true" ?
--
You received this message because you are subscribed to the Google
Group
Included Michael Blume's pull request in version 1.3.6.
On Tue, Mar 31, 2015 at 4:11 PM, Mark Engelberg
wrote:
> The reason instaparse uses Clojure's string reader is to make sure that
> strings inside the context-free grammar DSL are handled consistently with
> Clojure's logic for interpreting
The reason instaparse uses Clojure's string reader is to make sure that
strings inside the context-free grammar DSL are handled consistently with
Clojure's logic for interpreting strings.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
On Mar 31, 2015, at 4:00 PM, Mark Engelberg wrote:
> I can push a new version of instaparse incorporating Michael Blume's pull
> request by the end of the day.
That would be great, Mark! Thank you!
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"Perfection is the e
On Mar 31, 2015, at 3:57 PM, Alex Miller wrote:
> From my perspective, Instaparse is reaching pretty far into the guts there.
> I'll talk to Rich about it though.
Thanks. I know we've had several discussions about what should be considered
"API" around some of the Java code that implements Cloj
I can push a new version of instaparse incorporating Michael Blume's pull
request by the end of the day.
On Tue, Mar 31, 2015 at 3:57 PM, Alex Miller wrote:
> From my perspective, Instaparse is reaching pretty far into the guts
> there. I'll talk to Rich about it though.
>
> --
> You received th
>From my perspective, Instaparse is reaching pretty far into the guts there.
>I'll talk to Rich about it though.
--
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 me
I've proposed a patch to instaparse to fix this, I realize it's not the
most elegant version check ever, but it should fix the problem
https://github.com/Engelberg/instaparse/pull/94
On Tue, Mar 31, 2015 at 3:21 PM Sean Corfield wrote:
> Looks like a great set of updates!
>
> Unfortunately, as s
Looks like a great set of updates!
Unfortunately, as several of us found out today, the change to the StringReader
invoke() signature breaks Instaparse so I’m blocked from testing the World
Singles code base with alpha6 (or master) at the moment. Is that just a hazard
of relying on the internal
As I mentioned in the change log, the current repl chooses to continue
printing exceptions with no change. But if you print an exception yourself
with, for example, (println *e), you should see it. Currently you'll see
that printed without any pretty-printing - there will likely still be some
c
This is exciting! Thanks Alex et al! Been using alpha5 w/o problems in
several projects (and w/ noticeable improvements when I started using
transducers) and will switch to alpha6 asap.
On 31 March 2015 at 18:29, Alex Miller wrote:
> In case anyone is curious about the path from here to a final r
Hi,
The fancy printing of exceptions is not working for me.
Ubuntu 14.04.2 LTS
java version "1.8.0_40"
plain clojure jar or lein 2.5.1
gnome terminal
Regards,
Geraldo
On Tuesday, March 31, 2015 at 1:51:13 PM UTC-3, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
>
In case anyone is curious about the path from here to a final release, the
remaining items on the 1.7 list can always be found here:
http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10519
The main "feature" things to be done before a beta are optimized range and
the so
53 matches
Mail list logo
