Re: Surprising behaviour related to records, protocols and AOT

As discovered by Kevin Downey , (use [loom.graph] :reload) in tests was causing the namespace to be reloaded, which redefined the records in loom.graph, but didn't reload loom.attrs , so the extends didn't get run again for the new record type breaking all kinds of

Re: Surprising behaviour related to records, protocols and AOT

Thank you for the link, but I don't think what you outlined there is the same as what I have. I'm referring to records by class and protocols defined in the namespace, so I think my situation is different. On Monday, October 28, 2013 12:08:52 PM UTC-4, red...@gmail.com wrote: > > I don't know ab

Re: Surprising behaviour related to records, protocols and AOT

I don't know about the rest of this thread, but loom seems to suffer from what I've outlined in http://dev.clojure.org/jira/browse/CLJ-322?focusedCommentId=32246&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-32246 pulling in the interface that the protocol generates

Re: Surprising behaviour related to records, protocols and AOT

I was wondering if anybody has found a solution to this problem. I'm experiencing the same issue in this project . If you disable aot (this line), the tests start failing with a similar error message. Th

Re: Surprising behaviour related to records, protocols and AOT

Thank you for your explanation. I also suspect there is some subtle issue with the class file being used by the different constructors. However, I would be surprised if this behaviour is intended, and that the 'hackery' you proposed is the only, and prefered way of solving this. To better illust

Re: Surprising behaviour related to records, protocols and AOT

I guess extend-type does changes only to generated java class and the var defrecordissue.arecord->ARecord contains the 'old' version of ARecord constructor. Obviously it would be weird for defprotocol to change the variable in another namespace. Especially when you can extend a record from anyw

Re: Surprising behaviour related to records, protocols and AOT

Changing 3) to also import the record class: (ns defrecordissue.aot1 (:require [defrecordissue.aprotocol] [defrecordissue.arecord]) (:import [defrecordissue.arecord ARecord])) makes no difference. Compilation still fails with the same exception. This is obviously

Re: Surprising behaviour related to records, protocols and AOT

I guess you have to import defrecord generated class before you want to use it, check the sample from clojuredocs about defrecord ; If you define a defrecord in one namespace and want to use it > ; from another, first require the namespace and then import > ; the record as a regular class. > ; Th

Surprising behaviour related to records, protocols and AOT

Hi, Today I encountered a, to me, slightly surprising behaviour seemingly related clojure records. The setup is as follows: 1. One namespace defines a record type: (ns defrecordissue.arecord) (defrecord ARecord []) 2. Another namespace defines a protocol, and extends it to the recor