Re: One more argument for cyclic dependencies

[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  wrote:

> 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 with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: clojure.java.shell2 drop in replacement for clojure.java.shell

[Max Gonzih]

Ok, thank you for your reply. I will give it a try then soon on one of 
my pet projects! Thanks!


On 05/18/2015 09:25 PM, Marc Limotte wrote:

Hi Max.

I'm not actively doing any work on it.  Mainly because there are no 
requests for changes.  It's pretty straight-forward.  I haven't tested 
it with later versions of Clojure, but I'm not aware of any breaking 
changes, so I would expect it to work.


There are some alternatives, e.g. https://github.com/Raynes/conch

marc


On Mon, May 18, 2015 at 2:55 PM, Max Gonzih > wrote:


Hello,

I just found about this nice improvement over default java.shell
provided by clojure stdlib.
What is current status of this project? Is it still useful or
maybe there are alternatives?
Does it support latest clojure versions (1.6 or even maybe 1.7-beta)?

Thanks!

On Tuesday, June 25, 2013 at 5:57:58 PM UTC+2, mlimotte wrote:

I'm announcing java.shell2
. It is backward
compatible with clojure.java.shell.  This is a Clojure library
to facilitate launching of sub-processes and piping
(streaming) data.

Features
- A declarative syntax for defining new processes to specify
input, output, encoding, and other behavior
- Handling for common use-cases (i.e. pass stdout/err of the
process to the same destination as the parent, merge stderr of
the process to stdout, output directly to a File, etc)
- The pipe macro handles all the complexity of managing
multipe streams and threads for streaming data through
multiple processes and clojure functions.
- Backward compatible with existing code that uses
clojure.java.shell (i.e. a drop-in replacement)

Shell has additional predicates like :pass, which will connect
STDOUT or STDERR of the process to the STDOUT/ERR of the
parent JVM.

(sh "wc" "-l" :in input :err :pass :out (io/file "/tmp/foo"))

So the above form reads input (which can be a file, stream,
string, etc), forwards the output to a file and redirects
STDERR to STDERR of the JVM.

And here's an example of a pipe:

(pipe
  (sh "cat" :in input)
  my-filter-fn;A clojure function -- data is streamed
  (sh "wc" "-l"))


This library was developed at The Climate Corporation
, so a big thank you to them for allowing
me to open source this code under an EPL license. Climate Corp
has one of the largest Clojure development teams.  We are an
established startup with offices in San Francisco and Seattle;
and are currently hiring full-time Clojure developers, data
scientists, product managers and more
.

See the README for more details and many examples in the unit
tests.

I know there are other shell libraries for Clojure.  My main
motivation is that I wanted something closer to the
clojure.java.shell api.

Marc Limotte


-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the 
Google Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/hS4T84fctqk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google
G

Re: One more argument for cyclic dependencies

[Tassilo Horn]

Mars0i  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 agent that's registered 
> with it.
>
> The agents have to interact with each other, and the way that they
> find out about each others' states is typically through the the
> SimState object that's automatically passed to step().  The point is
> that the only way for teach Student to know about other instances of
> Students is by knowing about an object that also has to know about
> Students. There's the cycle.
>
> [snip]
>
> I use gen-class in order to implement Steppable and to extend
> SimState.  The type hint that I delete and restore is for the second
> argument to the step() function required by Steppable:
>
> (defn -step [^students.Student this ^students.StudentsSimState sim-state]

Since Steppable is an interface, you could define Student using
`deftype` or `defrecord` instead of `gen-class`.  Then you can call
(step my-student sim-state) without type hint which should be equally
fast as (.step ^Student my-student ^StudentSimState sim-state).

And instead of having one SimState-extending class per kind of agent,
you could have just one class `SimStateImpl` which has as a field
`attrs` which is a map.  In that map, you could put stuff specific to
Students or stuff specific to Teachers (or whatever kinds of agents you
have).

Then, the only point where you might need a type hint is where you
access the `attrs` map.  But here, the type is always `SimStateImpl`.

Alternatively, you could also define a protocol for accessing the
`attrs` map, or many protocols if it's better for you to have many
SimState-extending classes.

Bye,
Tassilo

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

Hi,

Thanks for taking the time to profile the code. I implemented the two 
suggestions (using the two argument arity of lte 

 
and using aset instead of aset-long 
).
 


https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/2655a83f7fcf51e4fedae164d7d17386a0c8854f/src/rdp/214_intermediate_arr.clj

lein run -m rdp.214-intermediate-arr 1 true
;; took around 250s.

The changes didn't seem to make a difference. The before and after runs all 
take between 250 - 260s. I kept the reduce as-is. From your reply, it looks 
like these two changes reduced the execution time by almost 30s. Any 
thoughts of why there isn't much of a difference for me? - I am using 
Clojure 1.7.3-beta3 and Oracle Java 1.8.0_45 on OSX Mavericks. 

On Saturday, 16 May 2015 08:32:12 UTC+5:30, Steven Yi wrote:
>
> Ah, I see.  Well, I think then you can ignore the stuff about warming 
> up, as this certainly takes a while to run here: 
>
> "Elapsed time: 314763.93 msecs" 
>
> I tried profiling with Yourkit and saw a couple of things to change: 
>
> ;; I think lte with more than two args ends up being slower than 
> unrolling out here 
> ;; I also tried type-hinting values from paper to ^long to avoid lte 
> calls with Number 
> (defn- covered? 
>   [[^long canvas-x ^long canvas-y] paper] 
>   (and (<= ^long (:x1 paper) canvas-x ) (<= canvas-x ^long (:x2 paper)) 
>(<= ^long (:y1 paper) canvas-y ) (<= canvas-y ^long (:y2 paper 
>
> ;; for the reduce function in visible-color-frequencies-arr 
> ;; using aset instead of aset-long, as it looked like aset-long was 
> using reflection 
>  (aset colorCounts color (+ 1 (aget colorCounts color))) 
>
> That got it down to: 
>
> "Elapsed time: 279864.041477 msecs" 
>
> I suspect you might get improvement too if you change 
> visible-color-frequencies-arr to use loop-recur instead of reduce 
> since you're doing a bit of magic there. 
>
> Unfortunately I have to stop at the moment as I have to leave on a 
> trip early in the morning, but hopefully that's useful. 
>
> steven 
>
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

Hi,

Thank you for taking the time. That is a rather smart algo. The code and 
the changes were easy to understand. 

I didn't implement the parallelized version as my aim was to understand why 
the clojure version was so slow compared to the equivalent C# version. 
(Btw, you have access to a 12 core machine! :O)

Ok. Two versions of the code - 

https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/2655a83f7fcf51e4fedae164d7d17386a0c8854f/src/rdp/214_intermediate_leifp.clj

lein run -m rdp.214-intermediate-leifp 1
;; took around 100s

https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/2655a83f7fcf51e4fedae164d7d17386a0c8854f/src/rdp/214_intermediate_arr_leifp.clj

lein run -m rdp.214-intermediate-arr-leifp 1 true
;; took around 70s

The first file (214_intermediate_leifp.clj) is similar to what you had 
after point 1. 

The second file (214_intermediate_arr_leifp.clj) is your algo combined with 
the tips provided in the posts above - mainly - using type hints; native 
arrays, two argument arity of `<=` etc. It also uses a record `Paper` 
instead of a map. However the record values are accessed by the keyword 
instead of direct field access. 

Applying those tips to my algo, reduced the time taken from 500s to 250s. 
For your algo, those tips only reduced the time taken by 1/4th. Which makes 
sense as your algo performs far less operations, so there are lesser number 
of operations that can get a speed bump... 

That said, I am none the wiser on how to write to fast single threaded 
clojure :( 

On Tuesday, 19 May 2015 05:34:21 UTC+5:30, Leif wrote:
>
> Summary:  With a new algorithm + parallelism, I reduced it from 528s to 
> 11s.
>
> This sounded fun, so I took a crack at it, starting with your solution.  
> Description and patch files here: 
> https://gist.github.com/leifp/a864bca941ecdacb5840
>
> Starting with your solution, I:
>
>1. Divided the canvas into 100 blocks, created an index of {blockindex 
>-> papers that intersect that block}. The reasoning is that if we 
> calculate 
>which block a pixel is in, we only need to check the papers that intersect 
>that block.  In the extreme case, certain blocks only intersected one 
> paper 
>(the background).  In the original code we would have had to check all 100 
>papers for each pixel in that block; now we just check one. (5x average 
>speedup)
>2. Changed the code to calculate color areas for a block at a time; 
>after that, it was a simple 2-line change to parallelize the work using 
> pmap. 
>(8x speedup on 12-core machine) 
>3. Make paper a record; use direct field access (this resulted in a 
>modest ~10% improvement, but maybe not worth it).
>
> So clojure was helpful in trying out algorithm ideas and parallelizing the 
> code.  The final program would no doubt also be faster in C#, but my goal 
> is "fast enough."
>
> Further idea (which I don't think I'll implement):  Index the papers using 
> an data structure built for geometrical indexing, like an R-tree or 
> variation, to get a near-optimal index without tuning.
>
> I hope my solution is interesting to you.  Questions / comments welcome.
> Leif
>
> P.S.  I apologize for the messy, repetitive, stream-of-consciousness code.
>
>
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: One more argument for cyclic dependencies

[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 your explanations seem to imply that there are
already interfaces in your example, I am a bit confused.
* I was under the impression that Clojure only restricted cyclic
dependencies between ns forms. Have you tried calling
import/require/gen-class directly?
* what error do you see? Is the type hint itself refused because Clojure
cannot resolve it? Is that still the case if you fully qualify your type
hint? Do you have more of a speedup if you hint with the concrete,
gen-classed class than with the interface it implements?

I'm inclined to fully agree with you that mutual dependencies between types
should be supported, but I do not really see how they are not.

On Tuesday, 19 May 2015, Mars0i  wrote:

> 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, etc.
>
> I've started using MASON, a library for agent-based models (ABMs) written
> in Java.  Using gen-class to follow the MASON model works pretty well, even
> if the result is somewhat "Java-esque" Clojure.
>
> Using MASON in the normal way involves cyclic dependencies.  This is no
> problem if I let Clojure figure out the types at runtime--but I can get a
> speed improvement of 11 times the original speed if I add type hints, after
> a bit of code reorganization to avoid almost all of the cyclic type
> dependencies.  And by adding one additional type hint--more on this
> below--I get a further 6.5X speed improvement, for a total improvement due
> to type hints of roughly 70X.  Note that speed often matters for ABMs that
> involve stochastic effects; it's typically necessary to run the same
> simulation many times, and it's useful to be able to do the needed runs in
> minutes or hours rather than days.
>
> However, the last type hint involves a cyclic type dependency.  It doesn't
> generate a cyclic dependency error, but gives class not found errors no
> matter which of two interdependent classes is compiled first. My solution
> is to delete the type hint, compile all of the Clojure files, add the type
> hint back, and recompile that one modified file. That's how I get the full
> 85X speed improvement.  (*That* is an ugly solution.)
>
> The cyclic dependencies are due to decisions by MASON's designers that
> seem entirely reasonable for an agent-based modeling framework--even if I
> would do things differently--and *have* done things differently (in a
> narrowly-focused, application-specific ABM framework that's purely
> functional except for reporting).
>
> **
>
> So: In order to use a well-designed Java library, I have to choose between
> slow code or awkward workarounds for a cyclic dependency.
>
> **
>
> Let me emphasize that I *do not* think that Clojure should incorporate
> every feature that someone thinks useful.  I certainly don't think that
> Clojure should provide every feature offered by Java.  Ugh.  I love Clojure
> because it doesn't include everything plus the kitchen sink, but instead
> provides a small set of flexible, simple, well-thought out functions.
>
> However, the lack of cyclic dependencies is not the absence of a
> substantial language feature.  It's an arbitrary limitation placed on
> compile time that's not present at run time.  Allowing cyclic dependencies
> wouldn't make Clojure less simple or elegant, because it wouldn't really
> add anything to the language.
>
> (Yes, if cyclic dependencies are allowed, then people can abuse them.
> People can also abuse type hints, interwoven side effects and laziness,
> macros, and non-idiomatic coding styles.  The Clojure community teaches
> routinely teaches novices how to avoid these mistakes.)
>
> (If cyclic dependencies are really considered so harmful, one could hide
> them behind a special compiler option that emits a warning when used.)
>
> ---
>
> Optional reading: Why there's a cyclic dependency in MASON simulations.
>
> 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 agent that's registered
> with it.
>
> The agents have to interact with each other, and the way that they find
> out about each others' states is typically through the the SimState object
> that's automatically passed to step().  The point is that the only way for
> teach Student to know about other instances of Students is by knowi

Re: Looking for a clojure expert to help fill in a language feature reference

[Dan Cancro]

Hi Atamert

It's for everyone.

Yes, it is completely public.  All there is to it is this big Google 
spreadsheet 
. I 
do it on my own time and don't get paid anything.  My goals are to reduce 
the amount of time that is spent researching and choosing among technology 
options and also to get people to work together instead of competing and 
creating factions.

On Monday, May 18, 2015 at 1:36:19 PM UTC+2, Atamert Ölçgen wrote:
>
> Hi Dan,
>
> Who are the people you help understand the tradeoffs and features of 
> technologies? Is this a public project with a public website?
>
> On Mon, May 18, 2015 at 11:51 AM, Dan Cancro  > wrote:
>
>> Hi,
>>
>> I'm not a Clojure user but I maintain a reference to help people 
>> understand the tradeoffs and features of technologies.  I was hoping 
>> someone among you would be interested in helping to contribute some 
>> knowledge about it to the project.
>>
>> Click here to see the reference 
>> 
>> .
>>
>> It should not take more than a few minutes for someone who knows Clojure 
>> well and will really help people understand quickly what it's about and how 
>> it's different.
>>
>> If you would like to help out, I've made a questionnaire that should make 
>> it a little easier:
>>
>> Click here to complete a short questionnaire about Clojure 
>> 
>>
>> I'm sure I've left out a lot of benefits that Clojure delivers.  Please 
>> let me know about the big things I've missed and I'll add them to the list.
>>
>> Thanks,
>> Dan
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
> www.olcgen.com
>  

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding JavaDocs for Interoperability with Java?

[Timur]

Hi everyone,

Is it possible to add JavaDocs to Clojure so that it can support Java 
programmers. For instance a JavaDoc to a protocol or to an interface 
defined in Clojure which is later on read by a Java developer?

Regards,

Timur

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: One more argument for cyclic dependencies

[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 students.StudentsWithUI]

(note Student is before Students) I get:

java.lang.ClassNotFoundException: students.Students, 
compiling:(students/Student.clj:45:1)

Line 45 is is the step defn line.  If I put Students before Student in 
project.clj, I get:

java.lang.ClassNotFoundException: students.Student, 
compiling:(Students.clj:59:59)

Line 59 is where I call (Student.) to create a number of Student instances.

The type hint is fully qualified, and it doesn't matter whether call to 
Student. to create instances is fully qualified, or abbreviated after 
import -ing the Student class in the ns statement.

Thanks everyone!  I'll give further details and responses later.  If 
anyone's interested, the code is here:

https://github.com/mars0i/majure/tree/master/3opt2

An unoptimized version is here:

https://github.com/mars0i/majure/tree/master/3plus

And the Java version on which its based is here:

https://github.com/mars0i/majure/tree/master/0plus



On Tuesday, May 19, 2015 at 4:21:52 AM UTC-5, Gary Verhaegen wrote:
>
> 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 your explanations seem to imply that there are 
> already interfaces in your example, I am a bit confused.
> * I was under the impression that Clojure only restricted cyclic 
> dependencies between ns forms. Have you tried calling 
> import/require/gen-class directly?
> * what error do you see? Is the type hint itself refused because Clojure 
> cannot resolve it? Is that still the case if you fully qualify your type 
> hint? Do you have more of a speedup if you hint with the concrete, 
> gen-classed class than with the interface it implements?
>
> I'm inclined to fully agree with you that mutual dependencies between 
> types should be supported, but I do not really see how they are not.
>
> On Tuesday, 19 May 2015, Mars0i > wrote:
>
>> 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, etc.
>>
>> I've started using MASON, a library for agent-based models (ABMs) written 
>> in Java.  Using gen-class to follow the MASON model works pretty well, even 
>> if the result is somewhat "Java-esque" Clojure.
>>
>> Using MASON in the normal way involves cyclic dependencies.  This is no 
>> problem if I let Clojure figure out the types at runtime--but I can get a 
>> speed improvement of 11 times the original speed if I add type hints, after 
>> a bit of code reorganization to avoid almost all of the cyclic type 
>> dependencies.  And by adding one additional type hint--more on this 
>> below--I get a further 6.5X speed improvement, for a total improvement due 
>> to type hints of roughly 70X.  Note that speed often matters for ABMs that 
>> involve stochastic effects; it's typically necessary to run the same 
>> simulation many times, and it's useful to be able to do the needed runs in 
>> minutes or hours rather than days.
>>
>> However, the last type hint involves a cyclic type dependency.  It 
>> doesn't generate a cyclic dependency error, but gives class not found 
>> errors no matter which of two interdependent classes is compiled first. My 
>> solution is to delete the type hint, compile all of the Clojure files, add 
>> the type hint back, and recompile that one modified file. That's how I get 
>> the full 85X speed improvement.  (*That* is an ugly solution.)
>>
>> The cyclic dependencies are due to decisions by MASON's designers that 
>> seem entirely reasonable for an agent-based modeling framework--even if I 
>> would do things differently--and *have* done things differently (in a 
>> narrowly-focused, application-specific ABM framework that's purely 
>> functional except for reporting).
>>
>> **
>>
>> So: In order to use a well-designed Java library, I have to choose 
>> between slow code or awkward workarounds for a cyclic dependency.
>>
>> **
>>
>> Let me emphasize that I *do not* think that Clojure should incorporate 
>> every feature that someone thinks useful.  I certainly don't think that 
>> Clojure should provide every feature offered by Java.  Ugh.  I love Clojure 
>> because it doesn't include everything plus the kitchen sink, but instead 
>> provides a small set of flexible, simple, well-thought out functions.
>>
>> However, the la

Re: One more argument for cyclic dependencies

[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 namespace is compiled, the second has not yet been compiled, so 
there are no .class files for that namespace yet.  That's why I can solve 
the problem by deleting the ^student.Students type hint in the argument 
list for step() in Student.clj, compiling everything, and then recompiling 
Student.clj with the type hint added back, after I've compiled Students.clj.

I don't view the links I provided as a substitute for providing a minimal 
working example, as Gary requested.  I might post an MWE later.  No time 
now.

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: One more argument for cyclic dependencies

[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 that's not necessary at 
this stage.  I'll see what can be done with deftype, defrecord, and/or 
defprotocol.

Tassilo, I don't call step() directly.  It's called automatically by a 
scheduler object in SimState, which is the superclass of Students.  So step() 
has to be visible to Java.  I think I have to use gen-class for the Student 
class in order to allow the Students (i.e. SimState) class to find the step 
method.  But as I said, I'm going to see if I can make do with deftype, 
defrecord, etc.  Emerick's flowchart is not 100% complete--there are just too 
many cases.  I'll explore your other suggestions, too.  (I only added type 
hints when they made a difference to speed.  For each new type hint, I checked 
whether it made a difference, and took out the ones that didn't.)

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: One more argument for cyclic dependencies

[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.

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Steven Yi]

Hi Amith,

Just got back from a trip and had a chance to look at this again.  I'm
not sure why you didn't see a change there; I'm running the same
version of Clojure and Java here.

I did another change to move from using a reduce to nested
loop-recurs.  That with a some additional type hints for ^Paper, and
moving the retrieval of :height and :width outside of the loops got a
performance increase of almost 3x from the original:

"Elapsed time: 109335.307414 msecs"

The modified code is here:

https://gist.github.com/kunstmusik/e1081d417142a90d5cfa

Some general notes:

- covered? - type-hinted ^Paper
- visible-color - switched to pass in ^long x and y, used fn form for
passed-in function and type-hinted ^Paper argument
- visible-color-frequencies - switched to nested loop-recur, moved out
height and width to single call outside critical loop

Could you try the version from the gist there to see if you get a
similar speedup?

Cheers!
steven

On Tue, May 19, 2015 at 4:38 AM, Amith George  wrote:
> Hi,
>
> Thanks for taking the time to profile the code. I implemented the two
> suggestions (using the two argument arity of lte and using aset instead of
> aset-long).
>
> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/2655a83f7fcf51e4fedae164d7d17386a0c8854f/src/rdp/214_intermediate_arr.clj
>
> lein run -m rdp.214-intermediate-arr 1 true
> ;; took around 250s.
>
> The changes didn't seem to make a difference. The before and after runs all
> take between 250 - 260s. I kept the reduce as-is. From your reply, it looks
> like these two changes reduced the execution time by almost 30s. Any
> thoughts of why there isn't much of a difference for me? - I am using
> Clojure 1.7.3-beta3 and Oracle Java 1.8.0_45 on OSX Mavericks.
>
> On Saturday, 16 May 2015 08:32:12 UTC+5:30, Steven Yi wrote:
>>
>> Ah, I see.  Well, I think then you can ignore the stuff about warming
>> up, as this certainly takes a while to run here:
>>
>> "Elapsed time: 314763.93 msecs"
>>
>> I tried profiling with Yourkit and saw a couple of things to change:
>>
>> ;; I think lte with more than two args ends up being slower than
>> unrolling out here
>> ;; I also tried type-hinting values from paper to ^long to avoid lte
>> calls with Number
>> (defn- covered?
>>   [[^long canvas-x ^long canvas-y] paper]
>>   (and (<= ^long (:x1 paper) canvas-x ) (<= canvas-x ^long (:x2 paper))
>>(<= ^long (:y1 paper) canvas-y ) (<= canvas-y ^long (:y2 paper
>>
>> ;; for the reduce function in visible-color-frequencies-arr
>> ;; using aset instead of aset-long, as it looked like aset-long was
>> using reflection
>>  (aset colorCounts color (+ 1 (aget colorCounts color)))
>>
>> That got it down to:
>>
>> "Elapsed time: 279864.041477 msecs"
>>
>> I suspect you might get improvement too if you change
>> visible-color-frequencies-arr to use loop-recur instead of reduce
>> since you're doing a bit of magic there.
>>
>> Unfortunately I have to stop at the moment as I have to leave on a
>> trip early in the morning, but hopefully that's useful.
>>
>> steven
>>
> --
> 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 unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/JgxFQLP2E34/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Steven Yi]

Hi Amith,

One last optimization yields a 4x increase over the last version, and
now 12x over the original:

"Elapsed time: 22848.384642 msecs"

Code here:

https://gist.github.com/kunstmusik/db6e14118e818abf3bb8

Changes from last version:

- parse-inputs - Put parsed Paper objects into an array instead of a vector.
- visible-color iterates through the array of Paper objects using a loop-recur

I spent a moment looking at this using JVisualVM and saw from the
previous version that there was a lot of time spent in sequence
related stuff and in the some function.  I realized from using some it
was going through the vector items pretty often, and since that list
of items is static, are read-only within the context of the code, and
the values aren't shared around a codebase, I went ahead and optimized
it to use a fixed array.

Hope this runs well on your side too!
steven


On Tue, May 19, 2015 at 12:49 PM, Steven Yi  wrote:
> Hi Amith,
>
> Just got back from a trip and had a chance to look at this again.  I'm
> not sure why you didn't see a change there; I'm running the same
> version of Clojure and Java here.
>
> I did another change to move from using a reduce to nested
> loop-recurs.  That with a some additional type hints for ^Paper, and
> moving the retrieval of :height and :width outside of the loops got a
> performance increase of almost 3x from the original:
>
> "Elapsed time: 109335.307414 msecs"
>
> The modified code is here:
>
> https://gist.github.com/kunstmusik/e1081d417142a90d5cfa
>
> Some general notes:
>
> - covered? - type-hinted ^Paper
> - visible-color - switched to pass in ^long x and y, used fn form for
> passed-in function and type-hinted ^Paper argument
> - visible-color-frequencies - switched to nested loop-recur, moved out
> height and width to single call outside critical loop
>
> Could you try the version from the gist there to see if you get a
> similar speedup?
>
> Cheers!
> steven
>
> On Tue, May 19, 2015 at 4:38 AM, Amith George  wrote:
>> Hi,
>>
>> Thanks for taking the time to profile the code. I implemented the two
>> suggestions (using the two argument arity of lte and using aset instead of
>> aset-long).
>>
>> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/2655a83f7fcf51e4fedae164d7d17386a0c8854f/src/rdp/214_intermediate_arr.clj
>>
>> lein run -m rdp.214-intermediate-arr 1 true
>> ;; took around 250s.
>>
>> The changes didn't seem to make a difference. The before and after runs all
>> take between 250 - 260s. I kept the reduce as-is. From your reply, it looks
>> like these two changes reduced the execution time by almost 30s. Any
>> thoughts of why there isn't much of a difference for me? - I am using
>> Clojure 1.7.3-beta3 and Oracle Java 1.8.0_45 on OSX Mavericks.
>>
>> On Saturday, 16 May 2015 08:32:12 UTC+5:30, Steven Yi wrote:
>>>
>>> Ah, I see.  Well, I think then you can ignore the stuff about warming
>>> up, as this certainly takes a while to run here:
>>>
>>> "Elapsed time: 314763.93 msecs"
>>>
>>> I tried profiling with Yourkit and saw a couple of things to change:
>>>
>>> ;; I think lte with more than two args ends up being slower than
>>> unrolling out here
>>> ;; I also tried type-hinting values from paper to ^long to avoid lte
>>> calls with Number
>>> (defn- covered?
>>>   [[^long canvas-x ^long canvas-y] paper]
>>>   (and (<= ^long (:x1 paper) canvas-x ) (<= canvas-x ^long (:x2 paper))
>>>(<= ^long (:y1 paper) canvas-y ) (<= canvas-y ^long (:y2 paper
>>>
>>> ;; for the reduce function in visible-color-frequencies-arr
>>> ;; using aset instead of aset-long, as it looked like aset-long was
>>> using reflection
>>>  (aset colorCounts color (+ 1 (aget colorCounts color)))
>>>
>>> That got it down to:
>>>
>>> "Elapsed time: 279864.041477 msecs"
>>>
>>> I suspect you might get improvement too if you change
>>> visible-color-frequencies-arr to use loop-recur instead of reduce
>>> since you're doing a bit of magic there.
>>>
>>> Unfortunately I have to stop at the moment as I have to leave on a
>>> trip early in the morning, but hopefully that's useful.
>>>
>>> steven
>>>
>> --
>> 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 unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/JgxFQLP2E34/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this me

Re: Adding JavaDocs for Interoperability with Java?

[Plínio Balduino]

Hi, Timur

AFAIK, JavaDocs are just comments with some predefined tags that are
completely ignored by Java compiler. As Clojure works directly with
bytecode, I think it's not possible to insert any kind of JavaDoc in
Clojure compiled interface or class.

Regards

Plínio Balduino

On Tue, May 19, 2015 at 6:41 AM, Timur  wrote:

> Hi everyone,
>
> Is it possible to add JavaDocs to Clojure so that it can support Java
> programmers. For instance a JavaDoc to a protocol or to an interface
> defined in Clojure which is later on read by a Java developer?
>
> Regards,
>
> Timur
>
> --
> 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 unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding JavaDocs for Interoperability with Java?

[Colin Fleming]

Hi Timur,

The problem with JavaDoc is that it's a source-level attribute, so in order
to be used from a Java editor the editor would have to understand Clojure.
This is actually possible in Cursive - as far as I'm aware no other system
does this right now. The other aspect would be generating JavaDoc HTML when
offline documentation is produced - I don't know if the javadoc tool is
extensible in order to allow this.

However the bigger issue is that most of the elements exposed to Java don't
support any documentation. definterface, gen-class, deftype & defrecord do
not. defprotocol does, but the interface generated from the protocol is
really an implementation detail, I don't think it's intended to be used for
interop. Some new commenting convention would need to be developed.

For all these reasons, I generally recommend defining your interop
interfaces in Java and just implementing them in Clojure.

Cheers,
Colin

On 19 May 2015 at 21:41, Timur  wrote:

> Hi everyone,
>
> Is it possible to add JavaDocs to Clojure so that it can support Java
> programmers. For instance a JavaDoc to a protocol or to an interface
> defined in Clojure which is later on read by a Java developer?
>
> Regards,
>
> Timur
>
> --
> 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 unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Richard Möhn]

Just trying to bump this up a bit. "Coding" will start soon, so I'd be 
happy about some more input. Especially if you have further thoughts or 
wishes along the lines of 
https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion.

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding JavaDocs for Interoperability with Java?

['wparke...@yahoo.com' via Clojure]

A few other thoughts here:

- To elaborate on Colin's suggestion a bit, if you define Java interfaces 
in Java, it's easy to create a function that reifies those interfaces (this 
means that it returns an object that implements arbitrary interfaces).  In 
this case the only interop a consumer would need to worry about would be a 
call to a Clojure function that returns an instance of the relevant object. 
 Such a function would basically serve the role of a factory constructor. 
 Everything else would be plain Java from their point of 
view. https://clojuredocs.org/clojure.core/reify
- Apologies if it's too obvious, but Clojure does have a docs tool. 
 Obviously it wouldn't look the same as Javadocs, but it might fit your 
needs with a little elaboration in the docstrings on how to call them from 
Java. https://github.com/weavejester/codox
- If you really need Javadoc (corporate compliance reasons?), you could 
create a Java class that uses the Clojure Java API to call the Clojure 
functions and expose that class.  I personally prefer using gen-class with 
static methods that call the relevant Clojure functions, since manually 
writing a Java wrapper for Clojure functions gets a little tedious, but it 
does allow complete hiding of the Clojure code behind a Java 
wrapper. 
http://clojure.github.io/clojure/javadoc/clojure/java/api/package-summary.html

On Tuesday, May 19, 2015 at 4:41:29 AM UTC-5, Timur wrote:
>
> Hi everyone,
>
> Is it possible to add JavaDocs to Clojure so that it can support Java 
> programmers. For instance a JavaDoc to a protocol or to an interface 
> defined in Clojure which is later on read by a Java developer?
>
> Regards,
>
> Timur
>

-- 
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 unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.