Re: is this a bug? tools.nrepl 0.2.13 in Alpine linux

I just opened NREPL-87 for this... On Thursday, September 21, 2017 at 4:07:17 PM UTC-7, Neil Okamoto wrote: > > > Copying this over from a discussion in the clojurians slack: > > The description in the ticket NREPL-83 suggests "start-server" will try > “::” first and then fall back to “localhost”

is this a bug? tools.nrepl 0.2.13 in Alpine linux

Copying this over from a discussion in the clojurians slack: The description in the ticket NREPL-83 suggests "start-server" will try “::” first and then fall back to “localhost”. However, running in Alpine Linux, the attempt to bind “::” throws an exception and the fallback to "localhost" nev

Re: is it a bug in clojure? unchecked-multiply

Note that using the auto-promoting ops will automatically overflow into an arbitrary precision type: user=> (*' 3037000500 3037000500) 922337203700025N user=> (*' 1000 1000) 100N The trailing N indicates the arbitrary precision integer. On Friday, March 3

Re: is it a bug in clojure? unchecked-multiply

On 03/03/2017 12:14 AM, BongHyeon. Jo wrote: > (unchecked-multiply 1000 1000) The default type clojure uses for integers is the jvm's long (or the boxed variant Long) type. Longs are signed 64bit numbers. 100 is outside the range of longs. `(* 1000 1

is it a bug in clojure? unchecked-multiply

500) -9223372036709301616 user=> (unchecked-multiply 1000 1000) 1864712049423024128 is it a bug in clojure? -- 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 tha

Re: Is this a bug that is already fixed?

Upgraded clojure too and now it works. Phew! -- 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 u

Re: Is this a bug that is already fixed?

Now it gets complicated. I upgraded to the latest clojurescript. and switched to reader version 1.0.0-beta3 which holds the/a fix. No change. The bug is still present. Here's my build boot: https://github.com/rolonicArk/simpleArk/blob/master/build.boot :-( -- You received this message becau

Re: Is this a bug that is already fixed?

Thanks Timothy! I found a similar issue with the same answer here: https://github.com/ptaoussanis/sente/issues/241 Closed! -- 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

Re: Is this a bug that is already fixed?

That's a pretty old version of ClojureScript. Try upgrading to the latest. Timothy On Sun, Feb 19, 2017 at 2:17 PM, William la Forge wrote: > I'll note that when I add a second entry to the map, everything is fine: >> >> > {:fix nil :local/contacts-capability contacts-capability} > > -- > You

Re: Is this a bug that is already fixed?

> > I'll note that when I add a second entry to the map, everything is fine: > > {:fix nil :local/contacts-capability contacts-capability} -- 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

Is this a bug that is already fixed?

Here's my clojure data: {:local/contacts-capability contacts-capability} pr-str gives me this: #:local{:contacts-capability #uuid "--4000-8000-0003"} I pass this over to clojurescript and when I read it I get... Uncaught Error: Could not find tag parser for :local in ("sim

Re: spec and à la carte conformance of map vals (and maybe a bug)

Sean, Thank you for sharing your input and code! Although I am interested by what you shared about your team’s usage of spec, I don’t believe it addresses my original problem of wanting to omit conformers when registering specs, yet later opt in to use a conformer when *consuming* the specs.

Re: spec and à la carte conformance of map vals (and maybe a bug)

At World Singles, we use clojure.spec for that scenario: conforming / validating string input data and producing non-string conformed values. For each string-to-non-string type, we write a conformer that accepts the string and either produces the valid, parsed non-string valid or produces ::

Re: spec and à la carte conformance of map vals (and maybe a bug)

Alex, Thank you for your reply! (I apologize for the delay in my own.) I’ll first address your final point (regarding what spec is buying me vs. just using normal functions): I’m still trying to figure that out myself! 😁 I.e., the boundaries of spec’s applicability/appropriateness are not yet a

Re: spec and à la carte conformance of map vals (and maybe a bug)

On Monday, December 19, 2016 at 2:42:49 PM UTC-6, Josh Tilles wrote: > > Hi all, > > On several occasions, Alex Miller has emphasized that we should be wary of > “baking in” conformers when defining specs. I agree with him, but it’s not > clear to me how to “opt in” to using conformers on map val

spec and à la carte conformance of map vals (and maybe a bug)

Hi all, On several occasions, Alex Miller has emphasized that we should be wary of “baking in” conformers when defining specs. I agree with him, but it’s not clear to me how to “opt in” to using conformers on map vals. As far as I can tell, I’m either limited to using unqualified keys —which enabl

Re: Is this behavior of clojure.core/pr a bug?

The user-provided examples and comments at ClojureDocs.org are not official Clojure documentation, but in many cases contain useful additional info. I have just added examples to clojure.core/pr similar to those that motivated this thread, and Timothy Baldridge's suggestion to use transit in cases

Re: Is this behavior of clojure.core/pr a bug?

Has anybody written a pr-edn that enforces the rules of https://github.com/edn-format/edn, refusing to print anything nonconformant? This would solve the original problem on this thread without requiring any changes to Clojure. On Fri, Aug 5, 2016 at 9:42 PM, Blake Miller wrote: > I agree with

Re: Is this behavior of clojure.core/pr a bug?

I agree with Herwig in principal ... even though EDN is not meant to cover the whole set of possible pure Clojure data, if it can be made to cover more (all other things being equal) that would be a Good Thing. I think it would be possible to fix these edge cases with reader macro dispatches witho

Re: Is this behavior of clojure.core/pr a bug?

2016-08-04 13:56 GMT+02:00 Timothy Baldridge : > The problem is that many do not understand that Clojure data is a superset > of EDN. The two were never meant to be completely compatible. There are > many things, especially when dealing with keywords and symbols, where its > possible to have data

Re: Is this behavior of clojure.core/pr a bug?

The problem is that many do not understand that Clojure data is a superset of EDN. The two were never meant to be completely compatible. There are many things, especially when dealing with keywords and symbols, where its possible to have data that doesn't properly round-trip. An added problem when

Re: Is this behavior of clojure.core/pr a bug?

2016-08-04 1:41 GMT+02:00 Timothy Baldridge : > I highly suggest using transit. It's much faster and formally specified. > https://github.com/cognitect/transit-format > > It's issues like this that caused the creation of transit in the first > place. > I thought transit was created to take advan

Re: Is this behavior of clojure.core/pr a bug?

> Can anyone think of a good reason why pr should *not* throw an exception on > (pr (keyword “foo bar")) > since there’s no way of expressing that keyword as valid EDN? This would break backwards compatibility, something Clojure rarely does. On Thu, Aug 4, 2016 at 1:16 PM Blake Miller wrote: >

Re: Is this behavior of clojure.core/pr a bug?

Er, I mean "built-in reader macro dispatch". On Thursday, August 4, 2016 at 1:14:16 AM UTC, Blake Miller wrote: > > You're right, Dan. Having mulled it over a little more, it's not clear to > me why there ought to be any pure Clojure data (no Java objects) that > cannot be serialized as EDN. Emi

Re: Is this behavior of clojure.core/pr a bug?

You're right, Dan. Having mulled it over a little more, it's not clear to me why there ought to be any pure Clojure data (no Java objects) that cannot be serialized as EDN. Emitting a #keyword reader literal for this edge case would make sense to me. -- You received this message because you ar

Re: Is this behavior of clojure.core/pr a bug?

e/pr (clojure.core/keyword "A >> valid keyword"))) => ":A valid keyword" >> >> >> >> So, it seems like clojure.core/pr and clojure.core/read-string disagree >> about EDN. >> >> >> >> Is EDN formally specified

Re: Is this behavior of clojure.core/pr a bug?

t; > Is EDN formally specified? https://github.com/edn-format/edn/issues/56 > seems to suggest it is not. > > I ran into this problem using ptaoussanis/sente to pass EDN over a > websocket. The EDN contained a keyword with a space in it, and the > clojure(jvm) part of sente h

Re: Is this behavior of clojure.core/pr a bug?

EDN formally specified? https://github.com/edn-format/edn/issues/56 seems to suggest it is not. I ran into this problem using ptaoussanis/sente to pass EDN over a websocket. The EDN contained a keyword with a space in it, and the clojure(jvm) part of sente had no problem serializing it, but th

Re: Is this behavior of clojure.core/pr a bug?

Thanks, Timothy. I'll give transit a try. -- 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 unsubs

Re: Is this behavior of clojure.core/pr a bug?

The docstring of clojure.core/pr https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L3552-L3555 actually says (in lieu of a formal EDN specification?) "pr and prn print in a way that objects can be read by the reader" ...and the example I showed appears to violate th

Re: Is this behavior of clojure.core/pr a bug?

hub.com/edn-format/edn/issues/56 > seems to suggest it is not. > > I ran into this problem using ptaoussanis/sente to pass EDN over a > websocket. The EDN contained a keyword with a space in it, and the > clojure(jvm) part of sente had no problem serializing it, but the > ClojureScri

Is this behavior of clojure.core/pr a bug?

es/56 seems to suggest it is not. I ran into this problem using ptaoussanis/sente to pass EDN over a websocket. The EDN contained a keyword with a space in it, and the clojure(jvm) part of sente had no problem serializing it, but the ClojureScript part of sente barfed on it. I thought it was a

Re: intern with :dynamic - either a bug or undocumented behavior?

the performance point of >> view. Problem is the Var's property isDynamic is set by 'def' special form >> only, while 'intern' doesn't do it. >> >> Am I correct in thinking that either the doc needs to be updated to >> reflect a special sta

Re: intern with :dynamic - either a bug or undocumented behavior?

mic is set by 'def' special form > only, while 'intern' doesn't do it. > > Am I correct in thinking that either the doc needs to be updated to > reflect a special status of 'def' in regard to dynamic Vars, or 'intern' > has a bug? &g

intern with :dynamic - either a bug or undocumented behavior?

reflect a special status of 'def' in regard to dynamic Vars, or 'intern' has a bug? I personally think its a bug in 'intern'. It can be circumvented by using Java interop on the Var, like (.setDynamic #'my-var) after interning it, but it looks ugly. The re

Re: set return value is unordered, is that a bug or by design?

Sets are unordered data structures, so it's by design. - James On 31 May 2016 at 13:54, wrote: > I would expect the returned set to be > > #{1 2 3} but i get the following. Copied from repl > > > user=> (set [1 1 2 2 3 3]) > > #{1 3 2} > > > user=> (set '(1 1 2 3 2 4 5 5)) > > #{1 4 3 2 5} > >

Re: set return value is unordered, is that a bug or by design?

sets & maps make no guarantee about the order of their entries. In fact, they deliberately use hash functions to keep simple keys like 1,2,3 "spread out" in their hash-codes. This causes the "random" ordering when printed. If you want a set to print in order (often worth the trouble, I think), use

Re: set return value is unordered, is that a bug or by design?

I believe you may have meant sorted-set On Tue, May 31, 2016 at 6:10 AM, vandr0iy wrote: > You could use sorted-map, if you wish to have them ordered: > > https://clojuredocs.org/clojure.core/sorted-map > > there is also sorted-map-by, which lets

Re: set return value is unordered, is that a bug or by design?

You could use sorted-map, if you wish to have them ordered: https://clojuredocs.org/clojure.core/sorted-map there is also sorted-map-by, which lets you define the comparator based on which the values have to be sorted On 05/31/2016 02:54 PM, james.naad...@gmail.com wrote: > > I would expect the

set return value is unordered, is that a bug or by design?

I would expect the returned set to be #{1 2 3} but i get the following. Copied from repl user=> (set [1 1 2 2 3 3]) #{1 3 2} user=> (set '(1 1 2 3 2 4 5 5)) #{1 4 3 2 5} -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group,

Re: Shouldn't we consider this a bug? "Unable to resolve symbol: % in this context"?

The problem is: how do you tell the difference between a pre- and post-condition map, and a map you want to return from the function? The only way to do it is to explicitly return nil. - James On 15 February 2016 at 04:48, Laws wrote: > If I write this in a file: > > (defn different-order [ord

Shouldn't we consider this a bug? "Unable to resolve symbol: % in this context"?

If I write this in a file: (defn different-order [order] {:pre [ (map? order) (:waiter order) (:customer order) (:menu-item-name order) ] :post [ (map? %) (:waiter %) (:customer %) (:menu-item-name %)

Re: The following behavior of into function is a bug or the intended result?

he input elements exceeds 9, the order > is not maintained any more. > > (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 :h] > [9 :i]]) > ; => {7 :g, 1 :a, 4 :d, 6 :f, 3 :c, 2 :b, 9 :i, 5 :e, 8 :h} > > Is this a bug or the intended result? > -- Y

Re: Is the following behavior of into function a bug or the intended result?

input elements exceeds 9, the order > is not maintained any more. > > (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 :h] > [9 :i]]) > ; => {7 :g, 1 :a, 4 :d, 6 :f, 3 :c, 2 :b, 9 :i, 5 :e, 8 :h} > > Is this a bug or the intended result? > > -- > You rec

The following behavior of into function is a bug or the intended result?

ned any more. (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 :h] [9 :i]]) ; => {7 :g, 1 :a, 4 :d, 6 :f, 3 :c, 2 :b, 9 :i, 5 :e, 8 :h} Is this a bug or the intended result? -- You received this message because you are subscribed to the Google Groups "Clojure"

Is the following behavior of into function a bug or the intended result?

ned any more. (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 :h] [9 :i]]) ; => {7 :g, 1 :a, 4 :d, 6 :f, 3 :c, 2 :b, 9 :i, 5 :e, 8 :h} Is this a bug or the intended result? -- You received this message because you are subscribed to the Google Groups "Clojure"

Re: core.typed question (maybe a bug?)

Hm, Is it possible that core.typed may be influenced by the repl state? New day and a new try I got these both working: (t/ann dt->hiccup [(t/HVec [Keyword (t/U Keyword (t/HVec [Keyword Number])) t/Any t/Any *]) -> html-form-group]) (defmulti dt->hiccup (t/fn [col :- (t/HVec [Keyword (t/U Keyw

Re: core.typed question (maybe a bug?)

I added your explanation the the wiki of core.typed: https://github.com/clojure/core.typed/wiki/Intersection-vs.-Union I hope that is fine for you. Am Donnerstag, 16. April 2015 23:25:42 UTC+2 schrieb Ambrose Bonnaire-Sergeant: > > It might help thinking in terms of Java interfaces, Foo and B

Re: core.typed question (maybe a bug?)

Now thats a really nice explanation of union versus intersection in termes of types. Thank you very much for that, Sven Am Donnerstag, 16. April 2015 23:25:42 UTC+2 schrieb Ambrose Bonnaire-Sergeant: > > It might help thinking in terms of Java interfaces, Foo and Bar. > > (definterface Foo >

Re: core.typed question (maybe a bug?)

It might help thinking in terms of Java interfaces, Foo and Bar. (definterface Foo (foo [])) (definterface Bar (bar [])) (I Foo Bar) is a value that extends both Foo and Bar. (deftype IImp [] Foo (foo [this]) Bar (bar [this])) (->IImp) is of type Foo, Bar, (I Foo Bar) and (U Foo Bar

Re: core.typed question (maybe a bug?)

I meant when I change: (t/HVec [Keyword (t/U Keyword (t/HVec [Keyword Number])) t/Any t/Any *]) to (t/HVec [Keyword (t/I Keyword (t/HVec [Keyword Number])) t/Any t/Any *]) ^^

Re: core.typed question (maybe a bug?)

Oh, you changed it to (t/HVec [Keyword (t/I Keyword (t/HVec [Keyword Number])) t/Any t/Any *])? Unions are like `or`, intersections like `and`. This might work for checking the definition, as function bodies are checked with a set of assumptions about parameter types. However it should be impossi

Re: core.typed question (maybe a bug?)

I don't see an intersection, what do you mean? Thanks, Ambrose On Thu, Apr 16, 2015 at 4:43 PM, Sven Richter wrote: > Hi, > > I tried both destructuring and the nth form instead of second and first. > None of which worked. > > However, if I change the Union to Intersection in > > (t/HVec [Keywo

Re: core.typed question (maybe a bug?)

Hi, I tried both destructuring and the nth form instead of second and first. None of which worked. However, if I change the Union to Intersection in (t/HVec [Keyword (t/U Keyword (t/HVec [Keyword Number])) t/Any t/Any *]) it works for the definition of the multimethod. Does that make sense? I

Re: core.typed question (maybe a bug?)

I don't think second's type is is smart enough. Try using nth or destructuring instead: (let [[f s] v] (if (vector? s) (first s) s)) or (if (vector? (nth v 1)) (first (nth v 1)) s) Thanks, Ambrose On Thu, Apr 16, 2015 at 3:39 PM, Sven Richter wrote: > Hi, > > I have this code: > > (defali

core.typed question (maybe a bug?)

Hi, I have this code: (defalias html-label (t/HVec [Keyword (t/HMap :mandatory {:for String}) String])) (defalias html-form (t/HVec [Keyword (t/HMap :mandatory {:id String}) t/Any *])) (defalias html-form-group (t/HVec [html-label html-form])) (t/ann dt->hiccup [(HVec [Keyword (U Keyword (HVe

Re: is this a bug in clojure.core/into ?

quot;b" 2]) '(["c" 3] ["d" 4])} > user=> (into {} '((["a" 1] ["b" 2]) (["c" 3] ["d" 4]))) > java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast > to java.util.Map$Entry (NO_SOURCE_FILE:0) > -- -- >8 --

is this a bug in clojure.core/into ?

ntry (NO_SOURCE_FILE:0) user=> ;; expecting {'(["a" 1] ["b" 2]) '(["c" 3] ["d" 4])} user=> (into {} '((["a" 1] ["b" 2]) (["c" 3] ["d" 4]))) java.lang.ClassCastException: clojure.lang.PersistentVector cannot

Re: Is this behavior with recur and pre/post a bug?

Thanks for checking Steve. Ambrose On Sun, Jul 27, 2014 at 5:09 AM, Steve Miner wrote: > I tried the latest patch from Ambrose for CLJ-1475. Looks good to me. > Well done. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this

Re: Is this behavior with recur and pre/post a bug?

Awesome job, everyone! You guys rock! Michael On Saturday, July 26, 2014 3:09:56 PM UTC-6, miner wrote: > > I tried the latest patch from Ambrose for CLJ-1475. Looks good to me. > Well done. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: Is this behavior with recur and pre/post a bug?

I tried the latest patch from Ambrose for CLJ-1475. Looks good to me. Well done. -- 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 b

Re: Is this behavior with recur and pre/post a bug?

I reuploaded the patch 3 times for various reasons, please refresh to get the latest. Thanks, Ambrose On Sun, Jul 27, 2014 at 12:44 AM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > I handled preconditions, and added a new patch. > > Thanks, > Ambrose > > > On Sat, Jul 26, 2

Re: Is this behavior with recur and pre/post a bug?

I handled preconditions, and added a new patch. Thanks, Ambrose On Sat, Jul 26, 2014 at 11:52 PM, Michael O'Keefe < michael.p.oke...@gmail.com> wrote: > Nice work everyone on the patches -- I'm very impressed! > > There's been a couple of questions about how to interpret this. My thought > is w

Re: Is this behavior with recur and pre/post a bug?

Nice work everyone on the patches -- I'm very impressed! There's been a couple of questions about how to interpret this. My thought is we should try and mimic an explicit recursion: In other words: (defn g [xs acc] {:pre [(or (nil? xs) (sequential? xs)) (number? acc)] :post [(number? %)]

Re: Is this behavior with recur and pre/post a bug?

Doh! I forgot preconditions :D Fixing.. Ambrose On Sat, Jul 26, 2014 at 11:30 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Hi Steve, > > I think I got it right, please have a look: > http://dev.clojure.org/jira/browse/CLJ-1475 > > Thanks, > Ambrose > > > On Sat, Jul 26,

Re: Is this behavior with recur and pre/post a bug?

Hi Steve, I think I got it right, please have a look: http://dev.clojure.org/jira/browse/CLJ-1475 Thanks, Ambrose On Sat, Jul 26, 2014 at 10:38 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > I'll give it a shot.. > > > On Sat, Jul 26, 2014 at 9:59 PM, Steve Miner wrote:

Re: Is this behavior with recur and pre/post a bug?

I'll give it a shot.. On Sat, Jul 26, 2014 at 9:59 PM, Steve Miner wrote: > I'm giving up on this bug. My approach was adding too much complexity to > handle an edge case. Hacking the fn macro is not as easy as it looks. :-) > > I recommend the loop work-around if you run into this problem.

Re: Is this behavior with recur and pre/post a bug?

I'm giving up on this bug. My approach was adding too much complexity to handle an edge case. Hacking the fn macro is not as easy as it looks. :-) I recommend the loop work-around if you run into this problem. Or refactor the recursive code into a separate function and call it from another fu

Re: Is this behavior with recur and pre/post a bug?

The intuitive behaviour (to me) would be that :pre is applied to every recur as stated and post is applied only to the eventually returned value and this *_should_ *be considered a bug. My logic is as follows: 1. A (pure, for simplicity of this argument) function, in the absence of

Re: Is this behavior with recur and pre/post a bug?

Yes :pre should apply to every recur, like usual without :post. user=> ((fn [a] {:pre [(number? a)]} (recur 'a)) 1) AssertionError Assert failed: (number? a) user/eval5376/fn--5377 (form-init687485383035947214.clj:1) That probably means that if :post is present, the preconditions should be moved

Re: Is this behavior with recur and pre/post a bug?

My first patch was buggy with destructured args so I had to withdraw it. While working on a better patch, I came up against a related issue: Should the :pre conditions apply to every recur "call". I'm saying no. The :pre conditions should be checked just once on the initial function call and ne

Re: Is this behavior with recur and pre/post a bug?

6 AM UTC-4, Michael O'Keefe wrote: > > Adrian, thanks for your input on whether this is a bug or not. Your > viewpoint may yet prove to be the "accepted" one but I still felt like the > original way I wrote the function should have meant: > . In that sense, it feels &

Re: Is this behavior with recur and pre/post a bug?

Adrian, thanks for your input on whether this is a bug or not. Your viewpoint may yet prove to be the "accepted" one but I still felt like the original way I wrote the function should have meant: . In that sense, it feels like my original function g should have been semantically

Re: Is this behavior with recur and pre/post a bug?

Ticket CLJ-1475 with my patch. http://dev.clojure.org/jira/browse/CLJ-1475 -- 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 patien

Re: Is this behavior with recur and pre/post a bug?

Now that Steve mentions it, I have fixed this kind of issue in my own defn macros. IIRC adding an inner loop form did the trick. Thanks, Ambrose On Fri, Jul 25, 2014 at 10:35 PM, wrote: > I do not believe this should be considered a bug. Recur is a special form > that rebinds the bindi

Re: Is this behavior with recur and pre/post a bug?

I do not believe this should be considered a bug. Recur is a special form that rebinds the bindings at the point of recursion with new values. It does not return a value. It does not get evaluated in the normal sense of the word. You cannot type check a value on a valueless expression. Just

Re: Is this behavior with recur and pre/post a bug?

ull!". I've run out of time to deal with this right now but, Steve, if you get to it before me, feel free to submit the bug report. Thanks all for the helpful discussions! Michael On Friday, July 25, 2014 7:58:51 AM UTC-6, miner wrote: > > I will call it a bug. It's de

Re: Is this behavior with recur and pre/post a bug?

I will call it a bug. It's definitely surprising to the user, and therefore worthy of a ticket. On first glance, it seems that the fix isn't too hard. In core.clj where the macro fn is redefined, we just need to wrap the section that handles the post condition either with a loop* o

Re: Is this behavior with recur and pre/post a bug?

gt; > On Jul 25, 2014, at 12:27 AM, Michael O'Keefe > wrote: > > > Andy, good advice and I agree. Thanks. I'll think on it then. > > Would you want one of your users going though this kind of thought > process: I won't file a ticked because I don't thin

Re: Is this behavior with recur and pre/post a bug?

On Jul 25, 2014, at 12:27 AM, Michael O'Keefe wrote: > Andy, good advice and I agree. Thanks. I'll think on it then. Would you want one of your users going though this kind of thought process: I won't file a ticked because I don't think it can be fixed? It's a b

Re: Is this behavior with recur and pre/post a bug?

Ambrose, thanks -- I was NOT aware of that. Sorry I misunderstood your original. Andy, good advice and I agree. Thanks. I'll think on it then. Cheers, Michael On Thursday, July 24, 2014 10:20:57 PM UTC-6, Ambrose Bonnaire-Sergeant wrote: > > On Fri, Jul 25, 2014 at 12:13 PM, Michael O'Keefe

Re: Is this behavior with recur and pre/post a bug?

; Ambrose >> >> >> On Fri, Jul 25, 2014 at 6:56 AM, Michael O'Keefe >> wrote: >> >>> Hello All, >>> >>> I encountered the following behavior in Clojure 1.6 and wanted to check >>> if it should be considered a bug or not. I

Re: Is this behavior with recur and pre/post a bug?

On Fri, Jul 25, 2014 at 12:13 PM, Michael O'Keefe < michael.p.oke...@gmail.com> wrote: > > >- Ambrose, both (number? %) and number? are valid post-condition >forms; the issue is that the post-condition check bumps the recur out of >tail position > > > I'm aware of the context, I just wa

Re: Is this behavior with recur and pre/post a bug?

Ambrose > > > On Fri, Jul 25, 2014 at 6:56 AM, Michael O'Keefe > wrote: > >> Hello All, >> >> I encountered the following behavior in Clojure 1.6 and wanted to check >> if it should be considered a bug or not. I would say yes but wanted to >>

Re: Is this behavior with recur and pre/post a bug?

Hi Michael, I believe your post condition should read {:post [(number? %)]}. Thanks, Ambrose On Fri, Jul 25, 2014 at 6:56 AM, Michael O'Keefe wrote: > Hello All, > > I encountered the following behavior in Clojure 1.6 and wanted to check if > it should be considered a bug or

Re: Is this behavior with recur and pre/post a bug?

I do not know whether it is considered a bug or not, but it is definitely caused by the postcondition handling causing the recur to be knocked out of tail position. Here is a reference to the code: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L4185-L4192 Andy On Thu

Re: Is this behavior with recur and pre/post a bug?

Indeed this is the case and no; I would not consider it a bug. Because you have specified a post condition on the return value, the clojure.core/fn macro is macroexpanding properly to support that post condition. By recursively macroexpanding the form, you can see the what the form will

Is this behavior with recur and pre/post a bug?

Hello All, I encountered the following behavior in Clojure 1.6 and wanted to check if it should be considered a bug or not. I would say yes but wanted to double check on the list first. Here's a minimal test case that elicited the error: (defn f [xs acc] (if (nil? xs) acc (

Re: a bug?

013 at 8:53 PM, Timothy Baldridge > wrote: > >> Holding on to the head would result in a out of memory error, not a stack >> overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the >> JIRA ticket). Anyways, it works in 1.5.1: >> >> user=&g

Re: a bug?

head would result in a out of memory error, not a stack > overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the > JIRA ticket). Anyways, it works in 1.5.1: > > user=> (clojure-version) > "1.5.1" > user=> (reduce (fn [a b] (map + [1 1] a)) [

Re: a bug?

The problem is probably too much nested laziness. Try: (reduce (fn [a b] (doall (map + [1 1] a))) [1 1] (range 1500)) Related: https://groups.google.com/d/msg/clojure/-d8m7ooa4c8/pmaO7QubhosJ Jonathan On Wed, Mar 27, 2013 at 8:48 PM, Michael Klishin < michael.s.klis...@gmail.com> wrote: > >

Re: a bug?

Holding on to the head would result in a out of memory error, not a stack overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the JIRA ticket). Anyways, it works in 1.5.1: user=> (clojure-version) "1.5.1" user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (ra

Re: a bug?

2013/3/27 larry google groups > The error says the type is clojure.lang.PersistentVector and not lazyseq > The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can learn more about what chunking is for in http://clojure-doc.org/articles/language/laziness.html. Something in this co

Re: a bug?

The error says the type is clojure.lang.PersistentVector and not lazyseq. I know very little about this, but I think (map) is returning a lazyseq, but the anonymous function inside of reduce is returning a clojure.lang.PersistentVector. On Wednesday, March 27, 2013 3:23:21 PM UTC-4, John Law

a bug?

Hi, Laziness makes my head hurt. Is there any reason this is desirable behaviour?: user=> (clojure-version) "1.4.0" user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1000)) (1001 1001) user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500)) StackOverflowError clojure.lang.Persiste

Re: pr-str captures stdout- Is this intentional or a bug?

OK, that viewpoint does sound reasonable- Thanks. On Saturday, February 9, 2013 6:55:32 PM UTC-6, Armando Blancas wrote: > > There's nothing wrong with pr-str. Debug output should go to stderr. > > user=> (def k (pr-str (for [x (range 5)] >(do (.println *err* x

Re: pr-str captures stdout- Is this intentional or a bug?

this makes it a little more obvious maybe? => (pr-str (seq (println 1))) 1 "nil" => (= "nil" (pr-str (seq (println 1 1 true => (pr-str (lazy-seq (println 1))) "(1\r\n)" => (= "(1\r\n)" (pr-str (lazy-seq (println 1 true On Sun, Feb 10, 2013 at 1:55 AM, Armando Blancas wrote: > There'

Re: pr-str captures stdout- Is this intentional or a bug?

There's nothing wrong with pr-str. Debug output should go to stderr. user=> (def k (pr-str (for [x (range 5)] (do (.println *err* x) (.println *err* "nothing") x 0 nothing 1 nothing

Re: pr-str captures stdout- Is this intentional or a bug?

these examples to illustrate what you are saying: => (= "(debug 1\r\n2 nil 3)" (pr-str (lazy-seq (list 2 (println "debug" 1) 3 true => (= "(1\r\n)" (pr-str (lazy-seq (println 1 true On Sat, Feb 9, 2013 at 10:57 PM, Conrad wrote: > For those reading this, the issue is NOT that outpu

Re: pr-str captures stdout- Is this intentional or a bug?

For those reading this, the issue is NOT that output in the REPL looks funny. The problem is that if, for instance, you put debug code into a chunk of code that makes use of "pr-str" your debug code is actually WRITTEN TO THE STRING. This is because "pr-str" works by using "with-out-str". This

  1   2   >