Thank you Mr. Alex Miller!
Fancy printing of exceptions is working :)
Geraldo
On Friday, April 10, 2015 at 4:26:30 PM UTC-3, Alex Miller wrote:
>
> Clojure 1.7.0-beta1 is now available.
>
> Try it via
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta1/
> - Leiningen:
I logged it with a patch here - thanks very much for that report. It's
tricky because you have to start realizing a chunk before you can see this,
so the existing serialization tests for range (which didn't do this) were
working!
http://dev.clojure.org/jira/browse/CLJ-1713
On Monday, April 20
The serializable thing is not intentional - would definitely like to fix it!
--
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 pati
Just tried the beta on our test suite. Aside from warnings from new
Clojure functions now shadowed by existing functions and obvious cases of
hash sensitivity, there are a couple less clear-cut cases (which likely
fall into the above hash case but will require further investigation), and
we al
This looks like the minimal case:
;; beta1
user=> (let [x 1] (let [{:keys [a b] :or {a b}} {}] a))
CompilerException java.lang.RuntimeException: Unable to resolve symbol: b
in this context, compiling:(/tmp/form-init3618156055290903409.clj:1:12)
This returns nil in at least alpha1, could someone
Possible issue with doseq in 1.7.0-beta1? Was working in 1.7.0-alpha5.
(Found with clj-jgit)
Leiningen 2.5.1 on Java 1.8.0_31 Java HotSpot(TM) 64-Bit Server VM
Error:
#error{:cause Unable to resolve symbol: private-key in this context, :via
[{:type clojure.lang.Compiler$CompilerException, :me
I've been running beta1 in production since about 1 day after it was
announced. Everything's been smooth so far :D
On Friday, 17 April 2015 06:51:53 UTC+12, Sean Corfield wrote:
>
> We deployed beta1 to production this morning. I’ll report back if we
> encounter any problems (generally we’ve fou
We deployed beta1 to production this morning. I’ll report back if we encounter
any problems (generally we’ve found Clojure pre-release builds to be very
stable). We were previously running alpha5 in production.
Sean
On Apr 10, 2015, at 12:25 PM, Alex Miller wrote:
> Clojure 1.7.0-beta1 is now
Thank you ! We live inside our heads but we expend much time inside repl.
This is very much appreciated!
Geraldo
On Tuesday, April 14, 2015 at 2:56:44 PM UTC-3, Alex Miller wrote:
>
> Well, we never added "fancy printing", just data printing of Throwables.
> :)
>
> But we were working on this
Well, we never added "fancy printing", just data printing of Throwables. :)
But we were working on this in the context of another thing that got moved
out and I have pulled that back as a separate ticket:
http://dev.clojure.org/jira/browse/CLJ-1703
Haven't talked to Rich about it yet, but we'
Hi,
>
> Fancy printing is not working.
Geraldo
--
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.
Why not just change the `?' to `_'? ?
So:
#?(:cljs (def unrelated-1 nil))
then
#_(:cljs (def unrelated-1 nil))
Even saved a character :)
On Monday, April 13, 2015 at 3:38:01 PM UTC-4, whodidthis wrote:
>
>
>
> On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote:
>>
>> I think what y
Your particular example is equivalent to #?(:clj) which is illegal, for the
reason given in the error message you saw.
Normal Clojure comments are far less surprising in their behavior than #_ is
I understand there can be convenience in using #_ when it works.
Andy
Sent from my iPhone
> On Ap
Just noticed that I sent my previous email to clojure-dev only – reposting
to all groups involved:
On 13 April 2015 at 16:25, Michał Marczyk wrote:
> On 13 April 2015 at 15:48, Alex Miller wrote:
> To get the effect you want in this, using #_ *inside* the reader
conditional would work:
>
> #?(:c
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote:
>
> I think what you're seeing here makes sense.
>
> On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote:
>>
>> Are there any thoughts on code like this:
>>
>> #_
>>
>
> This says to ignore the next read form
>
>
Sounds like you guys have it figured out; conditional reading forms cannot
be ignored, only their results.
Just wanted to make sure, had some bad times with it heh
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote:
>
> I think what you're seeing here makes sense.
>
> On Sunday, Ap
Ouch! But that actually makes a lot of sense.
On Mon, 13 Apr 2015 14:58 Alex Miller wrote:
> There is a ticket to consider a portable solution to this issue:
>
> http://dev.clojure.org/jira/browse/CLJ-1293
>
>
> On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote:
>
>> The only reas
There is a ticket to consider a portable solution to this issue:
http://dev.clojure.org/jira/browse/CLJ-1293
On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote:
>
> The only reason :default exists is because *anything* in JavaScript can be
> thrown and there needs to be some way to
I think what you're seeing here makes sense.
On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote:
>
> Are there any thoughts on code like this:
>
> #_
>
This says to ignore the next read form
> #?(:cljs (def unrelated-1 nil))
>
This evaluates to *nothing*, ie nothing is read,
Ahh ok, makes sense.
mandag 13. april 2015 12.45.35 UTC+2 skrev David Nolen følgende:
>
> The only reason :default exists is because *anything* in JavaScript can be
> thrown and there needs to be some way to catch non-Error derived values.
> This is not the case for Java of course. :default coul
The only reason :default exists is because *anything* in JavaScript can be
thrown and there needs to be some way to catch non-Error derived values.
This is not the case for Java of course. :default could probably be aliased
to Throwable, but in the meantime differences like this are now handleable
Hmm... In Clojurescript you can do the following
(try
;; throw something
(catch :default e
e))
When I try the same thing in Clojure, it seems to not be supported. Is
there any plans to support this syntax in Clojure 1.7?
--
You received this message because you are subscribed to the G
Why would that be fine?
On Sunday, April 12, 2015 at 10:39:17 PM UTC+2, whodidthis wrote:
> Are there any thoughts on code like this:
>
>
> #_#?(:cljs (def unrelated-1 nil))
>
>
> #?(:cljs (def unrelated-2 nil))
>
>
> #?(:cljs (def unrelated-3 nil))
>
>
> #?(:clj (def n 10))
>
>
> #?(:cl
23 matches
Mail list logo