Re: Calling proxy without reflection

https://dev.clojure.org/jira/browse/CLJ-2379 > On 2 Aug 2018, at 10:22, Nicola Mometto wrote: > > yes, the problem is with `proxy` and redefinition, I'm working on a patch to > fix this > >> On 2 Aug 2018, at 07:55, Mark Engelberg > <mailto:mark.engelb...@gmail.co

Re: Calling proxy without reflection

yes, the problem is with `proxy` and redefinition, I'm working on a patch to fix this > On 2 Aug 2018, at 07:55, Mark Engelberg wrote: > > For those following along at home, it turned out not to be a problem with the > lein-virgil plugin. It's apparently a bug in Clojure. Renzo and I

Re: Calling proxy without reflection

> mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9 cannot be > cast to mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test > (wrappers.clj:82) > > > Thanks for looking at this. > > > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto <mailto:brobro

Re: Calling proxy without reflection

vironment. > > I find that the problematic example does work in the user namespace, but it > doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be > really specific). > > On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto <mailto:brobro...@gmail.co

Re: Calling proxy without reflection

roxy [Object Interface] [] (test [] 1))) >> (defn get-test [o] (.test ^Interface o)) >> >> => (get-test p) >> This throws an error that it can't cast the proxy to Interface. >> >> If you remove the ^Interface type hint, then get-test will work but will >> tr

Re: Calling proxy without reflection

nterface type hint, then get-test will work but will > trigger reflection. > > Thanks for looking at this. It seems like it should work, but it doesn't. > > > On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto <mailto:brobro...@gmail.com>> wrote: > That's exactly what you

Re: Calling proxy without reflection

That's exactly what you should do and it does work, e.g.: user=> (set! *warn-on-reflection* true) true user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a 1}))) {:a 1} In your small example you have two errors that might be fishy: a missing arg vector to pass to the

Re: concat and mapcat not sufficiently lazy

y this before. This is a > pattern I use frequently in my code; I guess I just never had deep enough > recursion for it to slow things down enough for me to realize what was > happening. > > > > On Wed, Jul 18, 2018 at 12:53 AM, Nicola Mometto <mailto:brobro...@gmail.co

Re: concat and mapcat not sufficiently lazy

This behaviour is known and there are a couple of tickets about it : https://dev.clojure.org/jira/browse/CLJ-1583 https://dev.clojure.org/jira/browse/CLJ-1218 On Wed, 18 Jul 2018, 08:28 Mark Engelberg, wrote: > I'm kind of surprised I haven't run across this before, but tonight I was >

Re: [ANN] Clojure 1.9.0 is now available!

The code that caused this issue is https://github.com/clojure/clojure/commit/a1c3dafec01ab02fb10d91f98b9ffd3241e860c0?diff=unified#diff-03234b041c0917ec98f2ad9477a0a014R260 But this is not a bug in the clojure code nor a regression, in fact you can reproduce this in any clojure version with the

Re: Help ship Clojure 1.9!

Yes, clojurescript makes use of a previous experimental feature of tools.reader that allowed Infinity and -Infinity to be read as Double/POSITIVE_INFINITY and Double/NEGATIVE_INFINITY, without special casing how the compiler emitted infinity literals, as clojure previously printed them as

Re: [ANN] Clojure 1.9.0-alpha20

That looks like a cljs issue, it shouldn't emit NaNs at all there, not relevant to the clojure change around how they are printed. On 8 Sep 2017 8:03 a.m., "Tommi Reiman" wrote: Hi. The combo: [org.clojure/clojure "1.9.0-alpha20"] [org.clojure/clojurescript "1.9.660"]

Re: Bizzarre cond-> behavior

correct > On 21 Jul 2017, at 12:11, Peter Hull wrote: > > That was quick! So, if I understand it, the problem is not with cond->, it's > the chain of let-bindings it expands to? > Pete > > > -- > You received this message because you are subscribed to the Google >

Re: Bizzarre cond-> behavior

Ticket with patch + explanation: https://dev.clojure.org/jira/browse/CLJ-2210 <https://dev.clojure.org/jira/browse/CLJ-2210> > On 21 Jul 2017, at 11:06, Nicola Mometto <brobro...@gmail.com> wrote: > > I have a patch that fixes this, will open a ticket later today. > >

Re: Bizzarre cond-> behavior

I have a patch that fixes this, will open a ticket later today. > On 21 Jul 2017, at 10:07, James Reeves wrote: > > I can also confirm, tested on Clojure 1.8.0. The macro doesn't seem to take > long at all; it's the expanded code that takes a significant time to compile.

Re: [ANN] Primitive Operator

Hi Phillip, I've had a very quick look at the code and I've spotted a few issues, here's my feedback: 1- all your functions will cause input args and return value to be boxed. There's a few ways to avoid it, none of which are particularly pretty. If your library is not worried about

Re: 'get' behaviors

Issue #1 had been logged in CLJ-1242, but it was later decided to just focus on making equality not throw as contains/get throwing is consistent with java behaviour, see comments from Stu and Alex here

Re: Destructing lists using -> Difference between '(:opt1 true) and [:opt1 true]

AFAIK treating kv lists as maps in destructuring was only introduced to support kwargs destructuring, hence why it's not supported for vectors. On 02/01/17 18:00, Sean Corfield wrote: This one had me scratching my head a bit too… here’s what I _/think/_ is going on: First off, note that

Re: Reducing non-Clojure maps may not behave as expected

Something like what I proposed in http://dev.clojure.org/jira/browse/CLJ-1807 would help solve this ambiguity On 21/12/16 15:22, Mike Rodriguez wrote: On Wednesday, December 21, 2016 at 9:02:36 AM UTC-6, Alex Miller wrote: On Wednesday, December 21, 2016 at 7:24:17 AM UTC-6, Mike

Re: [ANN] Clojure 1.9.0-alpha11

I've used `:alias` to alias clojure.core in the past, I've seen it being used in more than one project On 20 Aug 2016 8:32 a.m., "Colin Fleming" wrote: > (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...) >> (:import ...) ) > > > Is this not

Re: [ANN] Clojure 1.9.0-alpha9

I'd say that's a bug with 1.8 rather than 1.9 > On 6 Jul 2016, at 13:01, Leon Grapenthin wrote: > > @Alex Miller: Please reconsider. What you state does not apply to 1.8, i. e. > the ns is required in :or and such code is broken in 1.9 > > 1.8/1.9 differences: > (let

Re: [ANN] Clojure 1.9.0-alpha5

I commented about this in the #clojure-dev slack channel, I believe http://dev.clojure.org/jira/browse/CLJ-1874 to be the cause of this issue > On 9 Jun 2016, at 14:32, Alex Miller wrote: > > I think it's quite likely that you have multiple copies of tools.analyzer >

Re: [ANN] Clojure 1.9.0-alpha4

How is this a regression? It doesn't cause any code that used to work to stop working. The fact that tail destructuring now causes non-sequential collections to be destructured by sequential destructuring should be just considered an instance of GIGO and an implementation detail. > On 4 Jun

Re: lazy-seq and somewhat greedy apply

Two things at play here: 1- concat is defined to have 4 different arities: 0-arg, 1-arg, 2-arg, 3+args. In order to figure out which arity to use, apply has to realize at least as many elements as the minimum number of args required by the largest arity, which in this case is 3 2- apply has a

Re: clojure.spec

Looks like it is, in the meanwhile this patch should fix it: http://sprunge.us/XTiA > On 23 May 2016, at 23:03, Nicola Mometto <brobro...@gmail.com> wrote: > > Possibly CLJ-1544 related? > >> On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant >> <a

Re: clojure.spec

Possibly CLJ-1544 related? > On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant > wrote: > > I'm having trouble calling `s/gen`, might be some sort of AOT compilation > error. > (I'm guessing this line has something to do with it). > > I'm using the latest

Re: clojure.spec

Some minor feedback while reading through `clojure.spec`: `clojure.spec/->sym` has been implemented in a significant number of libraries already (see: https://crossclj.info/clojure/var->sym.html), I propose we include this in `clojure.core` under the name of `var->sym` > On 23 May 2016, at

Re: Reflection warning: {} argument can’t be resolved as java.util.Map

Actually s/constant/literal/ https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3003-L3005 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3057-L3060

Re: Reflection warning: {} argument can’t be resolved as java.util.Map

On 16 May 2016, at 15:53, Alex Miller wrote: > > This is kind of an interesting case. From poking at it a bit, the {} is typed > as a IPersistentMap, and IPM does NOT extend java.util.Map (although the > implementations like PersistentArrayMap and PersistentHashMap do via

Re: I knew that primitives were better, but this is ridiculous

I generally agree with this suggestion, I just want to point out that, if incorporated with your previous suggestion of using `double` primitive type hints, using `.-x` vs `:x` to acess the field will make a difference: the former will access the primitive field while the latter will cause it

Re: I knew that primitives were better, but this is ridiculous

that would've helped in this case if turned on, without any need for types: try compiling OP's code after running `(set! *unchecked-math* :warn-on-boxed)` > On 12 May 2016, at 23:05, Raoul Duke <rao...@gmail.com> wrote: > > On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto <brobro..

Re: I knew that primitives were better, but this is ridiculous

Static types wouln't have helped at all in this case. Types are about correctness, not performances. This comment was needless > On 12 May 2016, at 22:52, Raoul Duke wrote: > > > y'know, if only there were something, i dunno, something static that > could you know have

Re: I knew that primitives were better, but this is ridiculous

Not necessarily, when combined with functions that take a variable number of arguments. Example: user=> (do (apply concat () (range)) nil) nil If apply did realize the range lazy sequence, that form would never terminate rather than returning nil. In your case however memory failed me and I

Re: I knew that primitives were better, but this is ridiculous

Those benchmarks are flawed and you're not testing what you think you are. The first benchmark is the slowest of all because it's: - realizing the nums lazy sequence - realizing the vpairs lazy sequence - destructuring a vector - creating and realizing a lazy sequene of record types - only then

Re: ^:const changes data type

Using `^:const` can lead to some funky behaviour, like the one you're seeing. AFAIK The only official documentation about it can be found in the clojure 1.3 changelog, https://github.com/clojure/clojure/blob/master/changes.md#215-const-defs where it is described as "^:const lets you name

Re: changes in logging in 1.8?

Unlikely, as the default behaviour hasn't changed. Nicola > On 15 Mar 2016, at 12:27, Stuart Sierra wrote: > > Not sure, but possible related to http://dev.clojure.org/jira/browse/CLJ-1208 > "Namespace is not loaded on defrecord class init" > –S > > On Friday,

Re: Understanding init (the zero arity function) for transducers.

Looking at both the implementation for TransformerIterator (sequence), transduce and eduction, it's clear that the 0-arg arity is never invoked on a transducer, while it's ever only used to provide the reducing step function of transduce its init value, if not provided explicitely. I have to

Re: Compile time constants not generated with the appropriate type.

ime. I'm not sure why that is > different then no.disassemble... > > On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote: > > > On 24 Feb 2016, at 11:58, Michael du Breuil <wicked.she...@gmail.com> wrote: > > > > That just performs a runtime cast to

Re: Compile time constants not generated with the appropriate type.

(float ) but I'm not > at all familiar with how the byte code is generated and how to actually > replace that with what I'm looking for. Sure, although I don't think doing this kind of constant folding this is going to be a priority. > > On Wednesday, February 24, 2016 at 3:58:46 AM

Re: Compile time constants not generated with the appropriate type.

t; Unless I'm missing something on how to interpret bytecode :) I can post more > source if you want but that is one interop call and its generated code, the > rest will look the same. > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote: > Can you pos

Re: Compile time constants not generated with the appropriate type.

Can you post the code? > On 24 Feb 2016, at 10:26, Michael du Breuil > wrote: > > I have some interop code that I have carefully specified all the arguments to > be in the correct type (IE the function signature takes 3 floats, so I cast > everything to float

Re: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

As the author of said libraries, I'd love to see somebody pick them up during GSoC and continue the work. The reason why development seems to have stalled, is different for each library: - tools.analyzer and tools.analyzer.jvm are pretty much done and stable, all that's left to do is fixing a

Re: record implementing interface with boolean signature, how to???

you're missing the `this` argument in the argvec. (compareAndSet [this oldv newv] ..) the boolean type hint shoulnd't be necessary. On Wed, Feb 3, 2016 at 8:18 PM, William la Forge wrote: > Having a bit of a problem implementing the IAtom interface in a record. >

Re: java.lang.NoSuchFieldError: __thunk__0__

Can you log this issue in clojure's JIRA? On Friday, January 15, 2016 at 11:21:17 PM UTC, Ryan Fowler wrote: > > I've got a head-scratcher. > > A combination of aot compiling, ring-jetty, slf4j-timbre, timbre and > core.async causes "java.lang.NoSuchFieldError: __thunk__0__" > > I've created a

Re: Destructuring seems to work with PersistentList and not with PersistentVector

that's an implementation detail you should not rely on. it only works to support keyword arguments to functions On 23 Jan 2016 17:36, "Harold" wrote: > Hello, > > While destructuring yesterday, I encountered this difference: > > > (let [{:keys [:a :b]} '(:a 1 :b 2)] [a b]) >

Re: Clojure beyond Java 6 ?

Do you have a link where we can read about those issues? > On 21 Jan 2016, at 18:14, Sean Corfield wrote: > > Colin Fleming wrote on Wednesday, January 20, 2016 at 6:33 PM: >>> I feel like a broken record here, but I'd like to protest again at this >>> characterisation.

Re: [ANN] Clojure 1.8.0-RC5

Thanks for your reports Andy, useful and prompt as always :) > On 13 Jan 2016, at 16:32, Andy Fingerhut wrote: > > Results of some testing done on 1.8.0-RC5: > > Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often. > Reason: there have been

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

onses. > > On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote: > While it's true that AOT has many issues, it's getting better release after > release and this is definitely a bug. > I don't understand why you wouldn't expect this to work, you *should*. > >

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

While it's true that AOT has many issues, it's getting better release after release and this is definitely a bug. I don't understand why you wouldn't expect this to work, you *should*. OP: can you open a ticket for this bug? I'd love to have a look at this and try to fix it. > On 29 Dec 2015,

Re: [ANN] Clojure 1.8.0-RC3

Before 1.8, clojure would accept wrong forms like (throw my-exception 1 2 3). This is now an exception http://dev.clojure.org/jira/browse/CLJ-1456. > On 8 Dec 2015, at 13:05, Noam Ben-Ari wrote: > > Hi, > I have just tried 1.8.0-RC3 and saw a problem. > > I have a project

Re: Naming convention for atoms, refs, etc.?

I seriously doubt that's ever going to happen. There's no good reason to do that. > On 6 Dec 2015, at 21:00, Gregg Reynolds <d...@mobileink.com> wrote: > > > On Dec 6, 2015 2:45 PM, "Nicola Mometto" <brobro...@gmail.com> wrote: > > > > 'foo@ is

Re: Naming convention for atoms, refs, etc.?

'foo@ is not a valid symbol name > On 6 Dec 2015, at 20:44, Gregg Reynolds wrote: > > Ps. Note the nice symmetry between *foo* and @foo@. > > On Dec 6, 2015 2:42 PM, "Gregg Reynolds" wrote: > Postfix @? Haven't pondered this before but I like the

Re: [ANN] Clojure 1.8.0-RC3

all the clojure contrib libraries are regularly tested against new clojure versions http://build.clojure.org/ > On 2 Dec 2015, at 16:17, Sreenivas Reddy T > wrote: > > I would love a project where the tool runs all test cases of libraries > against new

Re: Extend ns macro?

def interns the var at compile time, binding is a runtime operation > On 2 Dec 2015, at 16:56, Gregg Reynolds wrote: > > > > On Wed, Dec 2, 2015 at 8:11 AM, gianluca torta wrote: > for some reason, it looks like the implementation of the ns macro

Re: [ANN] Clojure 1.8.0-RC2

*clojure-version* is not a function, it's not affected by direct linking > On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant > wrote: > > I'm missing something, alter-var-root'ing *clojure-version* works just fine > when calling (clojure-version). > >

Re: [ANN] Clojure 1.8.0-RC2

It doesn't, but direct linking only affects invocations > On 20 Nov 2015, at 15:21, Ambrose Bonnaire-Sergeant > <abonnaireserge...@gmail.com> wrote: > > Wait, how does the compiler know that *clojure-version* isn't a function? > > On Fri, Nov 20, 2015 at 10:01 AM

Re: Reflection warning on try/catch inside go block

It's possibly a tools.analyzer issue, I'll take a look ASAP > On 16 Nov 2015, at 12:41, Alice wrote: > > Sorry, I was having some copy & paste mistake, but I'm seeing the same > warning with .printStackTrace. > > On Monday, November 16, 2015 at 9:25:06 PM UTC+9, Herwig

Re: [ANN] Clojure 1.8.0-RC1 is now available

r 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote: > It.. depends :( > > If your type hint is a *primitive* then you want to put it in the arglist. If > you put it in the Var, the best case scenario is that you'll get either > reflection warnings or boxed maths, and the worst

Re: [ANN] Clojure 1.8.0-RC1 is now available

? I've always seen > the function name hinted. > > On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto <brobro...@gmail.com > <mailto:brobro...@gmail.com>> wrote: > Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8 > >> On 12 Nov 2015, at 19:14,

Re: [ANN] Clojure 1.8.0-RC1 is now available

> this should throw an error on definition? > > CLJ-1846 is instead a valid type hint that is in conflict with the call. > Which now throws an error. > > > On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote: > This is :rettag in action. > Any reason w

Re: [ANN] Clojure 1.8.0-RC1 is now available

Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8 > On 12 Nov 2015, at 19:14, Nicola Mometto <brobro...@gmail.com> wrote: > > > Depends on how you look at it. > From my point of view, both examples are using an otherwise valid type hint, >

Re: [ANN] Clojure 1.8.0-RC1 is now available

Given the number of bytecode/type hinting issues we've seen caused by direct linking and the lack of real benchmarks demonstrating its benefits, I'm also wondering what's the rationale between including it in the current release. > On 10 Nov 2015, at 18:15, Ghadi Shayban

Re: [ANN] Clojure 1.8.0-RC1 is now available

This is :rettag in action. Any reason why this error should be acceptable while the CLJ-1846 one isn't? > On 12 Nov 2015, at 12:55, Alex Miller wrote: > > That's not a valid type hint. Var meta is evaluated, in this case to the > double function object. You really want: >

Re: [ANN] Clojure 1.8.0-RC1 is now available

Here's a minimal repro case: user=> (defn foo ^long [] 1) #'user/foo user=> (Integer/bitCount ^int (foo)) VerifyError (class: user$eval13, method: invokeStatic signature: ()Ljava/lang/Object;) Expecting to find integer on stack java.lang.Class.getDeclaredConstructors0 (Class.java:-2) > On 11

Re: [ANN] Clojure 1.8.0-RC1 is now available

e.org/jira/browse/CLJ-1846 > <http://dev.clojure.org/jira/browse/CLJ-1846> > > Shantanu > > On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote: > Here's a minimal repro case: > > user=> (defn foo ^long [] 1) > #'user/foo > user=>

Re: [ANN] Clojure 1.8.0-RC1 is now available

wse/CLJ-1846> > > Shantanu > > On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote: > Here's a minimal repro case: > > user=> (defn foo ^long [] 1) > #'user/foo > user=> (Integer/bitCount ^int (foo)) > VerifyError (class: user$eval13, method: invokeSt

Re: Newbie Question: Why is "reduced?" used in the reductions function?

The `reduced?` check is there in case somebody returns a `reduced` as acc value from the reducing function, as a way to terminate the reduction early: user=> (reductions (fn [_ x] (if (= 10 x) (reduced x) x)) (range)) (0 1 2 3 4 5 6 7 8 9 10) deref is the way to retrieve the value of a reduced

Re: tools.analyzer help

Hi Gregg, tools.analyzer (specifically tools.analyzer.jvm) doesn't do any evaluation of the forms by default if you're using the `analyze` function, however there's an `analyze+eval` function that will do that if you need. Note that t.a.jvm is a *clojure* analyzer that will only be able to

Re: clojure 1.8 java.lang.VerifyError method: invokeStatic signature: Can only throw Throwable objects

http://dev.clojure.org/jira/browse/CLJ-1809 Lars Rune Nøstdal writes: > Hi, > Anyone playing around with 1.8 from Git? It has problems compiling this for > some reason: > > (defn blah [] > (let [a (atom nil) > b nil] > (try > (println "hi") > (catch Throwable e >

Re: Bug in DynamicClassLoader?

See http://dev.clojure.org/jira/browse/CLJ-1663 András Pálinkás writes: > Can anyone explain to me why do we call super.findClass here: > https://github.com/clojure/clojure/blob/41af6b24dd5be8bd62dc2b463bc53b55e18cd1e5/src/jvm/clojure/lang/DynamicClassLoader.java#L69 > > I believe, on this

Re: Using type hints to optimize protocol invocation

Protocol callsites are already optimized in clojure. Here's the emitted bytecode for a protocol invocation: 0: aload_0 1: aconst_null 2: astore_0 3: dup 4: invokestatic #36 // Method

Re: [ANN] Clojure 1.8.0-alpha4

There is some weirdeness going on with the new release. Compare: Clojure 1.7.0 user= (def foo String) #'user/foo user= (defn ^{:tag foo} a []) #'user/a with Clojure 1.8.0-master-SNAPSHOT user= (def foo String) #'user/foo user= (defn ^{:tag foo} a []) CompilerException

Re: #{:rant} Questions about contribution policy and clojure compiler source.

I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a

Re: [ANN] Clojure 1.7.0-beta2

Fluid Dynamics writes: That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...). It can be surprising behaviour, but it's not an inconsistency. As per the documentation, metadata on the symbol being def'd *is* evaluated, metadata on the argvec isn't. Evaluating `String` produces

Re: [ANN] Clojure 1.7.0-beta2

Alex Miller writes: On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto brobro...@gmail.com wrote: Now, if you want to argue that the compiler should immediately throw an error as soon as the wrong type hint is used rather than silently ignore it and fail when the type-hinted form is used, I'll

Re: [ANN] Clojure 1.7.0-beta2

The type-hint on init-state is wrong. It has to be either (defn {:tag 'longs} init-state [] (long-array 1)) or (preferred) (defn init-state ^longs [] (long-array 1)) shlomivak...@gmail.com writes: I tried playing around with the new primitive type hints and got the following weird behavior

Re: Meaning of part of the doc string for `ns-resolve`

It's talking about fully qualified symbols that map to an actual var. E.g user= (ns-resolve *ns* 'clojure.string/join) #'clojure.string/join Brian Marick writes: The last sentence of the `ns-resolve` documentation reads: Note that if the symbol is fully qualified, the var/Class to

Re: Strange behaviour of a callable record

I've opened an enhancement ticket with a patch that changes this behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 Alexey Cherkaev writes: Hi, I have encountered the problem with Clojure 1.6.0, when I create the record that implements IFn. For example, (defrecord Foo [x]

Re: Strange behaviour of a callable record

You're not implementing IFn.applyTo, you should. Why applyTo is used in the second example while invoke is used in the other cases has to do with implementation details of how def expressions are compiled/evaluated. Alexey Cherkaev writes: Hi, I have encountered the problem with Clojure

Re: [ANN] Clojure 1.7.0-alpha6 released

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

Re: [ANN] Clojure 1.7.0-alpha6 released

: 1.589569 msecs nil Clojure 1.7.0-master-SNAPSHOT user= (def a (iterate inc 0)) #'user/a user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 4.831726 msecs nil user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 4.058695 msecs nil Nicola Mometto writes: The recent

Re: [ANN] Clojure 1.7.0-alpha6 released

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

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Clojure 1.5.1 user= (def bar (cons 1 (map #(do (println %) (+ (nth bar %) %)) (range #'user/bar user= (take 10 bar) (0 1 IndexOutOfBoundsException clojure.lang.RT.nthFrom (RT.java:795) It is possible that it is lein/REPLy that's causing the output not to be print, I've seen it done a

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

Clojure 1.6.0 user= (def foo (delay (str @foo))) #'user/foo user= @foo StackOverflowError clojure.lang.Delay.deref (Delay.java:37) user= same with Clojure 1.7.0-master-SNAPSHOT, I don't see it returning nil as you said. On Fri, Feb 13, 2015 at 7:53 AM, Fluid Dynamics a2093...@trbvm.com wrote:

Re: heaps in clojure vs SML

If you set! *warn-on-reflection* to true, you'd see a lot of reflection warnings from your code. Type-hinting the code like this: http://sprunge.us/ATiV makes your example execute in 120ms on my machine. Maris writes: I implemented leftist heap (from Purely Functional Data Structures book)

Re: [ANN] Clojure 1.7.0-alpha5 now available

and CLJ-1544. Many other tickets were found to be duplicates of one of these as well. Big thanks to Nicola Mometto for doing the hard work on debugging and providing fixes for these. For all changes new in alpha5, see the issues marked (alpha5) in the full changes below

Re: Set equality bug?

Looking at the PHM impl, this looks like it's caused by (float 0.5) and (double 0.5) hashing differently. user= (= (float 0.5) (double 0.5)) true user= (map hash [(float 0.5) (double 0.5)]) (1056964608 1071644672) Nicola Mometto writes: Looks like it's a bug in PersistentHashMap: user

Re: Set equality bug?

Looks like it's a bug in PersistentHashMap: user= (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)}) false user= (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)}) true Immo Heikkinen writes: (= (float 0.5) (double 0.5)) = true (= #{(float 0.5)} #{(double 0.5)}) = true

Re: Set equality bug?

to me. Jozef Wagner writes: More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036 On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto brobro...@gmail.com wrote: Looking at the PHM impl, this looks like it's caused by (float 0.5) and (double 0.5) hashing differently. user= (= (float

Re: [ANN] Clojure 1.7.0-alpha5 now available

There actually is a dependency cycle in manifold, it's just not in the ns macro: manifold.stream.graph depends on manifold.graph here: https://github.com/ztellman/manifold/blob/master/src/manifold/stream/graph.clj#L5 maniphold.stream depends on manifold.stream.graph here:

Re: [ANN] Clojure 1.7.0-alpha5 now available

Can you try a custom version of clojure 1.7.0-alpha5 with commit e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still get the exception? Nicola Sean Corfield writes: Here’s what I see reproducing this in the REPL - this main project doesn't use core.async (but does use a

Re: Potential bug in trampoline

This looks like a serious bug in PersistentList, it has nothing to do with trampoline. Here's a minimal case: user= ((fn [ args] (apply (fn [a b] (apply list b)) args)) 1 2 3) (1 2 3) Hongseok Yang writes: Hi, While trying to use trampoline to optimise tail recursion in my Clojure

Re: Potential bug in trampoline

I created http://dev.clojure.org/jira/browse/CLJ-1633 with a patch implementing the proposed fix in the stackoverflow answer by the user d.j.sheldrick. Hongseok Yang writes: Hi, While trying to use trampoline to optimise tail recursion in my Clojure project, I came across some strange

Re: reduced doesn't work inside reductions

This has already been fixed, and reductions will support reduced in 1.7.0. In the meantime you can use 1.7.0-alpha4. Nicola myguidingstar writes: (reduce (fn [acc x] (if ( acc 10) (reduced acc) (+ acc x))) 0 (range 100)) ;; = 15

Re: thread-any macro %

as- only binds the specified expression rather than each result in step and only works from within - Timothy Baldridge writes: That was added to clojure.core in 1.6 and is known as as- https://clojuredocs.org/clojure.core/as-%3E On Sat, Nov 15, 2014 at 6:55 AM, Krzysiek Herod

Re: how clojure infers types.

Actually `set` and a lot of other clojure.core functions are neither inlineable nor have type hints. Phillip Lord writes: I have a piece of code that looks like this (.getOWLEquivalentClassesAxiom (owl-data-factory) (set classlist) (union-annotations classlist)) The

Re: how clojure infers types.

is not assignable from java.util.Set. Phil Nicola Mometto brobro...@gmail.com writes: Actually `set` and a lot of other clojure.core functions are neither inlineable nor have type hints. Phillip Lord writes: I have a piece of code that looks like this (.getOWLEquivalentClassesAxiom

Re: Namespace metadata

Might be an instance of http://dev.clojure.org/jira/browse/CLJ-130 Haim Ashkenazi writes: Sorry, I pressed send too soon :) Here it is from the start: When I first wrote ayler https://github.com/babysnakes/ayler/wiki (a simple namespace browser) I used to get the doc for namespace by

Re: Namespace metadata

it in riemann in a namespace that is not AOT at all. On Wed, Oct 29, 2014 at 3:03 PM, Nicola Mometto brobro...@gmail.com wrote: Might be an instance of http://dev.clojure.org/jira/browse/CLJ-130 Haim Ashkenazi writes: Sorry, I pressed send too soon :) Here it is from the start: When I

Re: tools.analyzer.jvm clojure.lang.Var$Unbound cannot be cast to clojure.lang.DynamicClassLoader

Hi Nick, I looked into it, I'm not sure if this should be considered a clojure bug, a lein bug or a t.a.jvm one (I'd expect Compiler/LOADER to always be bound during compilation) but in the meantime I've pushed a workaround that should fix this and a 0.6.2 version is on its way to Maven Central.

  1   2   >