Re: One more argument for cyclic dependencies

2015-05-23 Thread Mars0i
Wow--thanks very much for looking at the code, Tassilo. Ah, yeah, the problem is that you still need to extend the existing SimState class and thus you need gen-class. In case SimState is a non-abstract class and also comes with an interface ISimState, you could probably get rid of

Re: One more argument for cyclic dependencies

2015-05-23 Thread Tassilo Horn
Mars0i marsh...@logical.net writes: Tassilo, thanks for being willing to look at the code. I appreciate it. There's no need to look at it to solve the delete/restore/recompile problem. (If you or anyone else still want to look at the source for any reason, it's at

Re: One more argument for cyclic dependencies

2015-05-22 Thread Tassilo Horn
Mars0i marsh...@logical.net writes: However, in all versions (gen-class, reify, deftype, defrecord, proxy), I can only get maximum speed by the same awkward trick that I used with gen-class: I remove a type hint in Student.clj, compile all of the files, then I add back the type hint in

Re: One more argument for cyclic dependencies

2015-05-22 Thread Mars0i
Problem solved. I finally got rid of the problem that required me to delete a type hint, compile, add it back, and recompile, by moving the gen-interface and deftype calls that I used to define the Student class into the same namespace I used to define the Students class. (I think that's

Re: One more argument for cyclic dependencies

2015-05-22 Thread Mars0i
I've now tried implementing the Student class (see previous posts) using reify, deftype, defrecord, and proxy, in each case specifying that they implement an interface (SteppableStudent) that extends the MASON Java interface Steppable. (The extended interface adds one method.) The reify and

Re: One more argument for cyclic dependencies

2015-05-20 Thread Mars0i
Thanks Justin. Exploring the options now, at least for the Student class, which only has to implement an interface. Given the requirements of the standard ways of using the MASON libs, it initially seemed to me that gen-class was my only option. It's clear now that there are other

Re: One more argument for cyclic dependencies

2015-05-20 Thread Justin Smith
I'll second the recommendation to use protocols or interfaces to solve this. Clojure is fairly opinionated in that the tools available should push you toward developing against interfaces or protocols rather than concrete implementations. Things become much simpler when you accept this. You can

Re: One more argument for cyclic dependencies

2015-05-19 Thread Jeroen van Dijk
Maybe I misunderstand the problem, but can't you have the Agents implement protocols (in a different namespace) and refer to that? On Tue, May 19, 2015 at 5:19 AM, Mars0i marsh...@logical.net wrote: Sorry, the reference to an 85X speed difference was a typo. Should be 70X. -- You received

Re: One more argument for cyclic dependencies

2015-05-19 Thread Gary Verhaegen
I do not understand the problem. Could you elaborate a bit? Maybe provide a minimal-ish project that reproduces the error? In particular: * dependencies between types are easily solved in Java by introducing interfaces as an indirection layer for the type system, or with protocols in Clojure. As

Re: One more argument for cyclic dependencies

2015-05-19 Thread Tassilo Horn
Mars0i marsh...@logical.net writes: MASON simulations typically consist of (a) One or more agents, which implement an interface (Steppable) with a single method, step(). (b) An instance of a class that extends SimState, which contains a scheduler that repeatedly calls step() in every

Re: One more argument for cyclic dependencies

2015-05-19 Thread Mars0i
Thanks Tassilo, Jeroen, Gary. I have to think about those suggestions and investigate, but I wanted to quickly specify the error in response to Gary's question. If, in project.clj, I specify: :aot [students.AltState students.Student students.Students students.TemperingSteppable

Re: One more argument for cyclic dependencies

2015-05-19 Thread Mars0i
Just to clarify a couple of things concerning my last post: Strictly speaking, the ClassNotFoundException is not the result of the order of namespaces in the :aot sequence in project.clj, but from the fact that if I start from a clean state with no compiled namespaces, then when the first

Re: One more argument for cyclic dependencies

2015-05-19 Thread Mars0i
Tassilo, Jeroen, I used gen-class because Chas Emerick's type selection flowchart (https://github.com/cemerick/clojure-type-selection-flowchart) indicated that it was needed in order to allow named classes and interface implementations, and that's what I thought I needed. However, perhaps

Re: One more argument for cyclic dependencies

2015-05-19 Thread Mars0i
Gary wrote: * I was under the impression that Clojure only restricted cyclic dependencies between ns forms. Have you tried calling import/require/gen-class directly? Not much. I did try one trick that involved switching namespaces inside a file, but it didn't work. I can try other things. --

Re: One more argument for cyclic dependencies

2015-05-18 Thread Mars0i
Sorry, the reference to an 85X speed difference was a typo. Should be 70X. -- 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

One more argument for cyclic dependencies

2015-05-18 Thread Mars0i
Sorry for the length of this post--I feel I have to spell out the details in order to head off irrelevant responses. I'm saving you the trouble of reading a long chain posts just focused on misunderstandings. For anything below, I'd be happy to find out that I'm wrong, confused, misguided,