Re: ANN: Klipse for Kids

[JvJ]

Pretty good.  However: In chapter 1, you might want to clear up the fact 
that 7*8 is 7 x 8 early on.  Kids may not be familiar with the * as a 
multiplication symbol.  I realize it's explained later, but it's better to 
avoid confusion beforehand.

On Tuesday, 2 August 2016 10:52:30 UTC-7, Mars0i wrote:
>
> This looks very, very nice.  The instant feedback is especially helpful.  
> (You are probably already working on is capturing errors to make them less 
> daunting.)
>
> Klipse reminded me of Carin Meier's beautiful and poignant Hello World 
> for the Next Generation. 
> 
>
> I always wondered whether *The Little Schemer* 
>  would work with kids. I 
> suspect not, until mid teens, at least.
>

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

Quil and Core.async - Problems blocking thread with

[JvJ]

I'm experimenting with using core.async with game scripting.  For testing 
purposes, I put together a small sketch with quil.

The issue I'm having is that the quil sketch's draw function seems to break 
whenever the 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: Get Lein to run 32-bit JVM on Windows

[JvJ]

My solution was to dual-boot linux.  I think it's about time anyway.

On Tuesday, 5 July 2016 12:17:02 UTC-7, JvJ wrote:
>
> I think when I wrote LEIN_CMD, I meant LEIN_JAVA_CMD.  I've already set it 
> to the x86 JVM path, with no luck so far.
>
> (System/getProperty "os.arch") still returns "amd64", and overtone still 
> doesn't work right.
>
> On Tuesday, 5 July 2016 02:02:53 UTC-7, David Powell wrote:
>>
>> I think you need to set LEIN_JAVA_CMD to affect the jvm actually used to 
>> start leiningen itself.
>>
>> On Tue, Jul 5, 2016 at 9:35 AM, JvJ <kfjwh...@gmail.com> wrote:
>>
>>> Is it possible to configure Leiningen to run a 32-bit JVM by default?  
>>> I've already tried changing the LEIN_CMD and JAVA_HOME to the x86 
>>> executable paths, but it still runs the amd64 JVM.
>>>
>>> Any tips?  I'm doing this for overtone, since it doesn't support amd64 
>>> on Windows.
>>>
>>> --
>>> 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.
>>>
>>
>>

-- 
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: Get Lein to run 32-bit JVM on Windows

[JvJ]

I think when I wrote LEIN_CMD, I meant LEIN_JAVA_CMD.  I've already set it 
to the x86 JVM path, with no luck so far.

(System/getProperty "os.arch") still returns "amd64", and overtone still 
doesn't work right.

On Tuesday, 5 July 2016 02:02:53 UTC-7, David Powell wrote:
>
> I think you need to set LEIN_JAVA_CMD to affect the jvm actually used to 
> start leiningen itself.
>
> On Tue, Jul 5, 2016 at 9:35 AM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> Is it possible to configure Leiningen to run a 32-bit JVM by default?  
>> I've already tried changing the LEIN_CMD and JAVA_HOME to the x86 
>> executable paths, but it still runs the amd64 JVM.
>>
>> Any tips?  I'm doing this for overtone, since it doesn't support amd64 on 
>> Windows.
>>
>> --
>> 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.
>>
>
>

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

Get Lein to run 32-bit JVM on Windows

[JvJ]

Is it possible to configure Leiningen to run a 32-bit JVM by default?  I've 
already tried changing the LEIN_CMD and JAVA_HOME to the x86 executable paths, 
but it still runs the amd64 JVM.

Any tips?  I'm doing this for overtone, since it doesn't support amd64 on 
Windows.

-- 
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: clojure.spec

[JvJ]

Approximate ETA for this, if known?

On Wednesday, 25 May 2016 09:08:29 UTC-7, Alex Miller wrote:
>
> Coming.
>
> On Wednesday, May 25, 2016 at 10:59:52 AM UTC-5, JvJ wrote:
>>
>> Any plans for cljs support?
>>
>

-- 
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: clojure.spec

[JvJ]

Any plans for cljs support?

On Monday, 23 May 2016 07:12:29 UTC-7, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

-- 
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: clojure.spec

[JvJ]

So happy that there's now a standard way to do this!  It sounds like it 
would help with my latest project.

Unfortunately, my latest project is called "SPECS" so I guess I'll have 
to find a different name.

On Monday, 23 May 2016 07:12:29 UTC-7, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

-- 
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: new learner question

[JvJ]

>
>
>
> Nope, that's fine. (Although you can't nest one anonymous function inside 
> another as then it would be ambiguous what % refers to.)
>

To further clarify when anonymous functions can't be nested:

#(+ % (+ % (+ % (+ % ==> totally legal 

#(+ % (#(* 2 %) %)) ===> totally not legal

In the first example, % is always the same.  However, in the second 
example, the #() form tries to introduce a *new* function, which can't be 
nested with this syntax.

However.
#(+ % ((fn [x] (* 2 x)) %)) ===> totally fine.  You can nest as many 
functions as you want if you write them as (fn [] ...)

-- 
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: new learner question

[JvJ]

Your use of % is syntactically correct.

However, think of what is happening in the second example.

Every time take-while invokes your function #(= (first %) %), % is bound to 
an element of the list s.

So, something like this would happen when take-while is checking the first 
element: (= (first 1) 1).

The exception just means that the function "first" can only work on 
sequences.  Numbers are not sequences.


On Monday, 23 May 2016 18:10:47 UTC-7, Phil Virgo wrote:
>
> I just starting to try and teach myself Clojure.  Kindly let me know if 
> there is a more appropriate place I should post simple questions.
>
>
> (def s '(1 1 1 4 99) 
>
> (take-while  #(= (first s) %) s)  ; works fine: (1 1 1)
>
> (take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know 
> how to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom 
> (RT.java:505)
>
> It appears as though "%" cannot be used within a nested function - but 
> this works 
>
> (#(prn (+ 3 %) % ) 5) ; works fine:  8 5
>
> Does anyone know what is the rule of statement construction being violated?
>
> ~thanks
>

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

Seeking feedback on custom core.async utility functions

[JvJ]

I recently wrote two utility functions for core.async, and I'm wondering if 
there could be some improvemets, or if I'm reinventing the wheel and 
there's something else out there that would accomplish the same thing.

Source code is available here: 
https://github.com/JvJ/specs/blob/master/src/specs/core.cljc#L469

Here are the functions:

   - timeout-at: Like timeout, but instead of specifying a wait period, you 
   specify a point in time when you want the channel to close. (Uses clj-time 
   DateTime objects).
   - beacon: Send out a signal on a channel at regular intervals of m 
   milliseconds from the present time.  Instead of waiting m milliseconds 
   every time through the loop,
   future points in time are calculated at exact intervals of m from when 
   the beacon is started.  It uses timeout-at to send the signal as closely as 
   possible to the
   requested time points.  The default output values is true.
   
   If something happens that makes one of the time points get skipped, a 
   different value is output.  The default value to indicate a skipped time 
   point is false.
   
   Beacon can also act like core/iterate if you want.  You can pass a 
   function to update both the successful output values and the skipped-time 
   output values, and
   the return value of the last output is used as the input to the function 
   to create the next output.


So, are these functions useful, or am I missing some totally obvious other 
way to do it.

By the way, the motivation here is to signal an async game update loop at a 
constant framerate, while at the same time keeping track of skipped frames.

Thanks.

-- 
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: clj-time/do-at not workin as expected

[JvJ]

Actually, I've been using async channels the whole time.  I just wanted to 
use scheduling rather than timeouts if possible.  So, I'd like to be able 
to say "wait until this time" instead of "wait for an amount of time".

On Friday, 20 May 2016 01:29:20 UTC-7, Colin Yates wrote:
>
> Have you considered using async channels? 
> JvJ writes: 
>
> > Chime seems great, but I'm looking for something cross-platform 
> (java/js). 
>
>

-- 
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: clj-time/do-at not workin as expected

[JvJ]

Chime seems great, but I'm looking for something cross-platform (java/js).

-- 
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: clj-time/do-at not workin as expected

[JvJ]

Ooooh, now I get it.  Is there something equivalent do the kind of delayed 
operation I'm expecting?

On Thursday, 19 May 2016 20:22:31 UTC-7, Sean Corfield wrote:
>
> The docstring could be clearer…
>
>  
>
> The do-at macro (which uses the do-at* function), evaluates the expression 
> in the context of the time being what you specified. Mostly useful for 
> testing I suspect:
>
>  
>
> boot.user=> (t/do-at (-> 1 t/minutes t/from-now) (println "Hi!" (t/now)))
>
> Hi! #object[org.joda.time.DateTime 0x169f53b5 2016-05-20T03:20:53.021Z]
>
> nil
>
> boot.user=> (t/now)
>
> #object[org.joda.time.DateTime 0x11798c1b "2016-05-20T03:19:54.145Z"]
>
>  
>
> See how the time printed is a minute in the future of the actual time?
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> On 5/19/16, 7:52 PM, "JvJ" <clo...@googlegroups.com  on 
> behalf of kfjwh...@gmail.com > wrote:
>
>  
>
>
> Whenever I call do-at or do-at*, the result expression is executed 
> immediately instead of at the specified time.
>
>  
>
> specs.core> (tm/do-at* (-> 30 tm/seconds tm/from-now) (fn [] (println 
> "SUP")))
>
> SUP
>
> ;; => nil
>
>  
>
> In the above example, "SUP" is printed instantaneously, even before the 
> return value of do-at* is printed.
>
>  
>
> Is this a bug, or is there some other reason for it?
>
>  
>
>

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

clj-time/do-at not workin as expected

[JvJ]

Whenever I call do-at or do-at*, the result expression is executed 
immediately instead of at the specified time.

specs.core> (tm/do-at* (-> 30 tm/seconds tm/from-now) (fn [] (println 
"SUP")))
SUP
;; => nil


In the above example, "SUP" is printed instantaneously, even before the 
return value of do-at* is printed.

Is this a bug, or is there some other reason for it?

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

Why is there no core/system-time in Clojure if it is in ClojureScript?

[JvJ]

I know it's a minor concern.  This can be accomplished by a simple reader 
conditional and System/currentTimeMillis in cljc, but is there any reason 
that core/system-time is not in standard clojure?

I feel like basic utility functions should be as cross-platform as possible 
to minimize reliance on reader conditionals in cross-platform 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: Is java.lang.Class not a dependable map key?

[JvJ]

I think I will do something like this.  Maybe instead of converting the 
class name to a keyword, I'll just make a separate protocol IComponent or 
something, that has a component-type function that returns a constant 
keyword determined by the macro at compile time...

On Wednesday, 18 May 2016 15:50:21 UTC-7, tbc++ wrote:
>
> Well, if you store it in metadata you'll have to look it up in the 
> metadata which is a hashmap lookup. As a method on a class it's a method 
> call that returns a constant. 
>
> On Wed, May 18, 2016 at 3:12 PM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> Will it be much better than type metadata, though?
>>
>> On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote:
>>>
>>> Or define components to have a member called (name-as-kw [this]) 
>>> returning a keyword version of the name of the type. 
>>>
>>> On Wed, May 18, 2016 at 1:31 PM, James Reeves <ja...@booleanknot.com> 
>>> wrote:
>>>
>>>> Why not use the name of the class as the key?
>>>>
>>>> - James
>>>>
>>>> On 18 May 2016 at 20:02, JvJ <kfjwh...@gmail.com> wrote:
>>>>
>>>>> I'm creating an entity-component-system architecture.  To use it, you 
>>>>> define component types, and put a bunch of components in a map to make an 
>>>>> entity.
>>>>>
>>>>> The rule for entities is that they can only have one component of any 
>>>>> given type, so I figured I would use the class to index it.  However, 
>>>>> since 
>>>>> this doesn't seem possible,
>>>>> I think I'll just make my own "defcomponent" macro which acts almost 
>>>>> like defrecord, but makes sure that the constructor associates an 
>>>>> appropriate keyword type tag
>>>>> in the metadata.
>>>>>
>>>>> Looking up the metadata is slightly slower than normal type 
>>>>> reflection, but I doubt it will make much of a difference.
>>>>>
>>>>> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>>>>>>
>>>>>> I don't think there's a general workaround, and I'm not sure I have 
>>>>>> enough context to know what you are doing specifically.
>>>>>>
>>>>>> On Wed, May 18, 2016 at 2:28 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>>>
>>>>>>> I suspected as much.  It would be possible to mitigate the problem 
>>>>>>> by not using the repl, but I want the library I'm making to be built 
>>>>>>> around 
>>>>>>> a repl-oriented workflow (like every good clojure library should).
>>>>>>>
>>>>>>> Is there any way around this, or do I have to resort to :type 
>>>>>>> metadata?
>>>>>>>
>>>>>>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>>>>>>>
>>>>>>>> When you reload a namespace with a record, the class for that 
>>>>>>>> record gets recreated.  It will be functionally equivalent, but a 
>>>>>>>> different 
>>>>>>>> object.  I'll bet that classes hash on identity.  (Though if they 
>>>>>>>> hashed on 
>>>>>>>> name, you'd still have this problem.)
>>>>>>>>
>>>>>>>> On Wed, May 18, 2016 at 1:31 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I'm encountering a very strange error in some tests.
>>>>>>>>>
>>>>>>>>> The details are a bit complex, but I'm using type-indexed maps.
>>>>>>>>>
>>>>>>>>> So, given an object o, the map would be {(type o) o}.  When I try 
>>>>>>>>> to lookup with the key (type o), I don't get the value, even though I 
>>>>>>>>> can 
>>>>>>>>> clearly see it in the map.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have a map instance called new-still in my tests, and I can 
>>>>>>>>> clearly see that this is its value
>>>>>>>>>
>>>>>>>>> {specs.core_test.Position {:x 0, :y 0}}
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> H

Re: Is java.lang.Class not a dependable map key?

[JvJ]

Will it be much better than type metadata, though?

On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote:
>
> Or define components to have a member called (name-as-kw [this]) returning 
> a keyword version of the name of the type. 
>
> On Wed, May 18, 2016 at 1:31 PM, James Reeves <ja...@booleanknot.com 
> > wrote:
>
>> Why not use the name of the class as the key?
>>
>> - James
>>
>> On 18 May 2016 at 20:02, JvJ <kfjwh...@gmail.com > wrote:
>>
>>> I'm creating an entity-component-system architecture.  To use it, you 
>>> define component types, and put a bunch of components in a map to make an 
>>> entity.
>>>
>>> The rule for entities is that they can only have one component of any 
>>> given type, so I figured I would use the class to index it.  However, since 
>>> this doesn't seem possible,
>>> I think I'll just make my own "defcomponent" macro which acts almost 
>>> like defrecord, but makes sure that the constructor associates an 
>>> appropriate keyword type tag
>>> in the metadata.
>>>
>>> Looking up the metadata is slightly slower than normal type reflection, 
>>> but I doubt it will make much of a difference.
>>>
>>> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>>>>
>>>> I don't think there's a general workaround, and I'm not sure I have 
>>>> enough context to know what you are doing specifically.
>>>>
>>>> On Wed, May 18, 2016 at 2:28 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>
>>>>> I suspected as much.  It would be possible to mitigate the problem by 
>>>>> not using the repl, but I want the library I'm making to be built around 
>>>>> a 
>>>>> repl-oriented workflow (like every good clojure library should).
>>>>>
>>>>> Is there any way around this, or do I have to resort to :type metadata?
>>>>>
>>>>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>>>>>
>>>>>> When you reload a namespace with a record, the class for that record 
>>>>>> gets recreated.  It will be functionally equivalent, but a different 
>>>>>> object.  I'll bet that classes hash on identity.  (Though if they hashed 
>>>>>> on 
>>>>>> name, you'd still have this problem.)
>>>>>>
>>>>>> On Wed, May 18, 2016 at 1:31 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>>>
>>>>>>> I'm encountering a very strange error in some tests.
>>>>>>>
>>>>>>> The details are a bit complex, but I'm using type-indexed maps.
>>>>>>>
>>>>>>> So, given an object o, the map would be {(type o) o}.  When I try to 
>>>>>>> lookup with the key (type o), I don't get the value, even though I can 
>>>>>>> clearly see it in the map.
>>>>>>>
>>>>>>>
>>>>>>> I have a map instance called new-still in my tests, and I can 
>>>>>>> clearly see that this is its value
>>>>>>>
>>>>>>> {specs.core_test.Position {:x 0, :y 0}}
>>>>>>>
>>>>>>>
>>>>>>> However, when I try to compare the first key to the Position class 
>>>>>>> (which it should be), I get this:
>>>>>>>
>>>>>>>
>>>>>>> Fail in run-systems-tst
>>>>>>> expected: (= (first (keys new-still)) Position)
>>>>>>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> How is it that the class specs.core_test.Position is not equal to 
>>>>>>> itself??
>>>>>>> Is this a bug, or just some quirk of compilation?
>>>>>>>
>>>>>>> Thanks. 
>>>>>>>
>>>>>>> -- 
>>>>>>> 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 em

Re: Is java.lang.Class not a dependable map key?

[JvJ]

I'm creating an entity-component-system architecture.  To use it, you 
define component types, and put a bunch of components in a map to make an 
entity.

The rule for entities is that they can only have one component of any given 
type, so I figured I would use the class to index it.  However, since this 
doesn't seem possible,
I think I'll just make my own "defcomponent" macro which acts almost like 
defrecord, but makes sure that the constructor associates an appropriate 
keyword type tag
in the metadata.

Looking up the metadata is slightly slower than normal type reflection, but 
I doubt it will make much of a difference.

On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote:
>
> I don't think there's a general workaround, and I'm not sure I have enough 
> context to know what you are doing specifically.
>
> On Wed, May 18, 2016 at 2:28 PM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> I suspected as much.  It would be possible to mitigate the problem by not 
>> using the repl, but I want the library I'm making to be built around a 
>> repl-oriented workflow (like every good clojure library should).
>>
>> Is there any way around this, or do I have to resort to :type metadata?
>>
>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>>>
>>> When you reload a namespace with a record, the class for that record 
>>> gets recreated.  It will be functionally equivalent, but a different 
>>> object.  I'll bet that classes hash on identity.  (Though if they hashed on 
>>> name, you'd still have this problem.)
>>>
>>> On Wed, May 18, 2016 at 1:31 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>
>>>> I'm encountering a very strange error in some tests.
>>>>
>>>> The details are a bit complex, but I'm using type-indexed maps.
>>>>
>>>> So, given an object o, the map would be {(type o) o}.  When I try to 
>>>> lookup with the key (type o), I don't get the value, even though I can 
>>>> clearly see it in the map.
>>>>
>>>>
>>>> I have a map instance called new-still in my tests, and I can clearly 
>>>> see that this is its value
>>>>
>>>> {specs.core_test.Position {:x 0, :y 0}}
>>>>
>>>>
>>>> However, when I try to compare the first key to the Position class 
>>>> (which it should be), I get this:
>>>>
>>>>
>>>> Fail in run-systems-tst
>>>> expected: (= (first (keys new-still)) Position)
>>>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>>>
>>>>
>>>>
>>>> How is it that the class specs.core_test.Position is not equal to 
>>>> itself??
>>>> Is this a bug, or just some quirk of compilation?
>>>>
>>>> Thanks. 
>>>>
>>>> -- 
>>>> 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.
>>>>
>>>
>>> -- 
>> 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.
>>
>
>

-- 
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: Is java.lang.Class not a dependable map key?

[JvJ]

I suspected as much.  It would be possible to mitigate the problem by not 
using the repl, but I want the library I'm making to be built around a 
repl-oriented workflow (like every good clojure library should).

Is there any way around this, or do I have to resort to :type metadata?

On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote:
>
> When you reload a namespace with a record, the class for that record gets 
> recreated.  It will be functionally equivalent, but a different object.  
> I'll bet that classes hash on identity.  (Though if they hashed on name, 
> you'd still have this problem.)
>
> On Wed, May 18, 2016 at 1:31 PM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> I'm encountering a very strange error in some tests.
>>
>> The details are a bit complex, but I'm using type-indexed maps.
>>
>> So, given an object o, the map would be {(type o) o}.  When I try to 
>> lookup with the key (type o), I don't get the value, even though I can 
>> clearly see it in the map.
>>
>>
>> I have a map instance called new-still in my tests, and I can clearly see 
>> that this is its value
>>
>> {specs.core_test.Position {:x 0, :y 0}}
>>
>>
>> However, when I try to compare the first key to the Position class (which 
>> it should be), I get this:
>>
>>
>> Fail in run-systems-tst
>> expected: (= (first (keys new-still)) Position)
>>   actual: (not (= specs.core_test.Position specs.core_test.Position))
>>
>>
>>
>> How is it that the class specs.core_test.Position is not equal to itself??
>> Is this a bug, or just some quirk of compilation?
>>
>> Thanks. 
>>
>> -- 
>> 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.
>>
>
>

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

Why do transducers on channels need buffer size of at least 1?

[JvJ]

I don't have much experience with core.async, and I recently tried using 
channels with transducers.  Strangely, I found that you need a buffer with 
a size
of at least one in order for the transducer to be applied.

I have a few toy functions:

(defn push-nums
  "Push a few numbers on a channel."
  [n c]
  (go (loop [i 0]
(when (< i n)
  (>! c i)
  (recur (inc i
  (>! c :end)))

(defn print-nums
  "Take the numbers from the channel and print them."
  [c]
  (go
(loop []
(let [n ( A num:  0
;=> A num:  1
;=> A num:  2
;=> A num:  3
;=> A num:  4
;=> Finished with nums!!

(let [c (chan 1 (map inc))] (push-nums 5 c) (print-nums c))
;=> A num:  1
;=> A num:  2
;=> A num:  3
;=> A num:  4
;=> A num:  5


 The transducer only gets applied when the argument 1 is passed in.  I 
assume this is by design, but I don't like the fact that
using transducers effectively limits certain options with channels.

Does anyone know if there's a type of buffer that can be used to get around 
this?



-- 
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: I knew that primitives were better, but this is ridiculous

[JvJ]

Actually, I just achieved substantial performance gains with cross-map 
iteration.

Previously, if I was iterating over rows/cols, I would check each one for 
the relevant components.  Now, I do an intersection operation on the 
row/col indexes before iterating.  It works pretty well, and gives simpler 
code.

I'm also trying to boost performance of the transient cross-map, and I 
started a new thread about that if anyone has advice.

On Friday, 13 May 2016 12:47:21 UTC-7, James Reeves wrote:
>
> On 13 May 2016 at 19:50, Michael Willis  > wrote:
>>
>> Every time I go to the hammock (so to speak) to think over how to design 
>> such a system, I realize that I'm just re-inventing the database, so I come 
>> away feeling like somewhere, somehow there must already exist an in-memory 
>> database that will suit the problem, but I haven't determined what it is 
>> yet.
>>
>
> This was my reason for developing Ittyon 
> . It's essentially an in-memory 
> database with arbitrary indexing and network support for games. I couldn't 
> find any other database which met my specific criteria, but Ittyon has many 
> similarities with Datomic/Datascript in its design.
>
> - James 
>

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

Iterate over transient map

[JvJ]

I'm implementing a data structure, cross-map 
<https://github.com/JvJ/cross-map>, which cross-indexes keys with the 
structure [row column].

I'm also trying to implement a transient version to speed things up a bit. 
 However, I would like to do certain iteration operations on the transient 
itself without having to call persistent! if possible.

I realize that the transient-to-persistent conversion should ideally be 
O(1), but there are certain cases where I have to iterate over some 
structures to achieve what I'm looking for.

Is there a way to get some kind of iterator for a transient map?  I 
understand that lazy-sequences are bad for mutability, but even a 
java-style imperative iterator would be good.

Thanks

-- 
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: I knew that primitives were better, but this is ridiculous

[JvJ]

I'm intrigued, but I don't know exactly what you mean.

On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote:
>
> Have you considered defining specific indexes? For instance, if you know 
> ahead of time that you want to search for entities that have both position 
> and velocity, you could define an index that keys both of those values.
>
> - James
>
>
>
> On 12 May 2016 at 23:50, JvJ <kfjwh...@gmail.com > wrote:
>
>> Maybe this is a little off-topic, but on the general topic of 
>> performance, other than just numerical performance, what's the best way to 
>> get information/advice on how to improve it.
>>
>> I went about doing these tests (and other tests) because I'm trying to 
>> create a game scripting framework in clojure, which I want to build around
>> an entity-component-system architecture.  Entities are maps of 
>> components, and system functions are defined to sort of "pattern match" 
>> against
>> entities to see if they have the required components.  (i.e. an 
>> update-position function would add velocity to position, so it only applies 
>> to entities
>> with both a position and a velocity component).
>>
>> The first step in this process is to find a way to store these so that it 
>> would be as fast as possible to iterate over "all entities with this set of 
>> components",
>> while avoiding things like filter operations.
>>
>> I started off by making cross-map <https://github.com/JvJ/cross-map>, 
>> which cross-indexes any entries with keys of the form [r c], where r is a 
>> row and c is a column, and allows O(1) access
>> of entire rows and columns.
>>
>> Still, though, the performance tests 
>> <https://github.com/JvJ/cross-map/blob/master/test/cross_map/perf.cljc> 
>> aren't what I expected they would be, and I'm wondering how to go about 
>> dealing with that.
>>
>> Again, this isn't strictly about numerical performance, but it's why I'm 
>> doing these kinds of tests in the first place.
>>
>> Thanks.
>>
>> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>>>
>>> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto <brob...@gmail.com> 
>>> wrote: 
>>> > Fair enough, but in this case types wouldn't really have helped: the 
>>> author did use `Double` type hints, mistakenly assuming that would make its 
>>> code use primitive types, which it does not since `Double` is boxed and not 
>>> primitive. 
>>> > Clojure already has compile time warnings about boxed math 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)` 
>>>
>>> Thanks for the details re: double. Apologies for being annoyed/ing. 
>>>
>>> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We 
>>> can relive the ignominious history of "$!" in Haskell. 
>>>
>> -- 
>> 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.
>>
>
>

-- 
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: I knew that primitives were better, but this is ridiculous

[JvJ]

Maybe this is a little off-topic, but on the general topic of performance, 
other than just numerical performance, what's the best way to get 
information/advice on how to improve it.

I went about doing these tests (and other tests) because I'm trying to 
create a game scripting framework in clojure, which I want to build around
an entity-component-system architecture.  Entities are maps of components, 
and system functions are defined to sort of "pattern match" against
entities to see if they have the required components.  (i.e. an 
update-position function would add velocity to position, so it only applies 
to entities
with both a position and a velocity component).

The first step in this process is to find a way to store these so that it 
would be as fast as possible to iterate over "all entities with this set of 
components",
while avoiding things like filter operations.

I started off by making cross-map <https://github.com/JvJ/cross-map>, which 
cross-indexes any entries with keys of the form [r c], where r is a row and 
c is a column, and allows O(1) access
of entire rows and columns.

Still, though, the performance tests 
<https://github.com/JvJ/cross-map/blob/master/test/cross_map/perf.cljc> 
aren't what I expected they would be, and I'm wondering how to go about 
dealing with that.

Again, this isn't strictly about numerical performance, but it's why I'm 
doing these kinds of tests in the first place.

Thanks.

On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>
> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto <brob...@gmail.com 
> > wrote: 
> > Fair enough, but in this case types wouldn't really have helped: the 
> author did use `Double` type hints, mistakenly assuming that would make its 
> code use primitive types, which it does not since `Double` is boxed and not 
> primitive. 
> > Clojure already has compile time warnings about boxed math 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)` 
>
> Thanks for the details re: double. Apologies for being annoyed/ing. 
>
> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We 
> can relive the ignominious history of "$!" in Haskell. 
>

-- 
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: I knew that primitives were better, but this is ridiculous

[JvJ]

I've tried core.typed a few times, but I always find it too difficult to 
work with.

On Thursday, 12 May 2016 15:05:50 UTC-7, raould wrote:
>
> On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto  > wrote: 
> > Static types wouln't have helped at all in this case. Types are about 
> correctness, not performances. This comment was needless 
>
> Here I thought maybe knowing when something was or was not something 
> could have been useful in, you know, making the code (benchmarks in 
> this case) actually do what the author wanted it to be doing. Silly 
> me. 
>
> I will always have my fingers crossed for core.typed. :-) 
>

-- 
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: I knew that primitives were better, but this is ridiculous

[JvJ]

>
>
> 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 benchmarking the reduce operation. 


I was under the impression that the call to "apply list" would realize the 
lazy sequences beforehand.


On Thursday, 12 May 2016 13:09:57 UTC-7, Nicola Mometto wrote:
>
> 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 benchmarking the reduce operation. 
>
> In the second benchmark you're still benchmarking the destructuring of 
> vector pairs and the creation and realization of a lazy sequence of types 
> The third benchmark is like the second in that you're creating and 
> realizing a lazy sequence but it's slightly faster than the second one 
> because you're not including destructuring in the mix 
> The last benchmark is the fastest of all because you're just iterating 
> over an already realized sequence. 
>
> In no benchmark you're actually using any primitive types, you're always 
> using boxed Doubles 
>
> > On 12 May 2016, at 20:58, JvJ <kfjwh...@gmail.com > wrote: 
> > 
> > I've been doing some performance tests on various floating point 
> operations.  In particular, I wanted to check what would be the fastest way 
> to implement a 2-d floating point vector in clojure. 
> > 
> > Here's my tests: 
> > 
> > ;;; V+ Tests 
> > ;;; Implementing floating-point vectors as: 
> > ;;; structs, deftype, vector 
> > (defrecord v2r 
> > [^Double x ^Double y]) 
> > 
> > (defn rv+ 
> >   [^v2r v1 ^v2r v2] 
> >   (v2r. (+ (.x v1) (.x v2)) 
> > (+ (.y v1) (.y v2 
> > 
> > (deftype v2t 
> > [^Double x ^Double y]) 
> > 
> > (defn tv+ 
> >   [^v2t v1 ^v2t v2] 
> >   (v2t. (+ (.x v1) (.x v2)) 
> > (+ (.y v1) (.y v2 
> > 
> > (defn vv+ 
> >   [v1 v2] 
> >   (mapv + v1 v2)) 
> > 
> > 
> > (defn testvecs 
> >   "Tests the vector add operations by reducing a 
> >   random list by each of the v+ operations on 
> >   identical sets of random vectors" 
> >   [n] 
> >   (let [nums (repeatedly (* 2 n) rand) 
> > vpairs (partition 2 nums) 
> > v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs)) 
> > v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs)) 
> > v2v-list (apply list (map vec vpairs))] 
> > (println "V2 Record:") 
> > (bench (reduce rv+ v2r-list)) 
> > (println "V2 Type:") 
> > (bench (reduce tv+ v2t-list)) 
> > (println "V2 Vector:") 
> > (bench (reduce vv+ v2v-list)) 
> > (println "Just Doubles:") 
> > (bench (reduce + nums 
> > 
> > 
> >  Here's my output: 
> > 
> > V2 Record: 
> > Evaluation count : 420 in 60 samples of 7 calls. 
> >  Execution time mean : 164.379725 ms 
> > Execution time std-deviation : 4.478128 ms 
> >Execution time lower quantile : 149.546749 ms ( 2.5%) 
> >Execution time upper quantile : 172.317132 ms (97.5%) 
> >Overhead used : 1.873322 ns 
> > 
> > Found 8 outliers in 60 samples (13. %) 
> > low-severe 4 (6.6667 %) 
> > low-mild 3 (5. %) 
> > high-mild 1 (1.6667 %) 
> >  Variance from outliers : 14.2105 % Variance is moderately inflated by 
> outliers 
> > V2 Type: 
> > Evaluation count : 1860 in 60 samples of 31 calls. 
> >  Execution time mean : 32.238857 ms 
> > Execution time std-deviation : 2.331682 ms 
> >Execution time lower quantile : 26.769206 ms ( 2.5%) 
> >Execution time upper quantile : 35.318368 ms (97.5%) 
> >Overhead used : 1.873322 ns 
> > 
> > Found 8 outliers in 60 samples (13. %) 
> > low-severe 5 (8. %) 
> > low-mild 3 (5. %) 
> >  Variance from outliers : 53.4940 % Variance is severely inflated by 
> outliers 
> > V2 Vector: 
> > Evaluation count : 2040 in 60 samples of 34 calls. 
> >  Execution time mean : 30.175015 ms 
> > Execution time std-deviation : 3.870306 ms 
> 

I knew that primitives were better, but this is ridiculous

[JvJ]

I've been doing some performance tests on various floating point 
operations.  In particular, I wanted to check what would be the fastest way 
to implement a 2-d floating point vector in clojure.

Here's my tests:

;;; V+ Tests
;;; Implementing floating-point vectors as:
;;; structs, deftype, vector
(defrecord v2r
[^Double x ^Double y])

(defn rv+
  [^v2r v1 ^v2r v2]
  (v2r. (+ (.x v1) (.x v2))
(+ (.y v1) (.y v2

(deftype v2t
[^Double x ^Double y])

(defn tv+
  [^v2t v1 ^v2t v2]
  (v2t. (+ (.x v1) (.x v2))
(+ (.y v1) (.y v2

(defn vv+
  [v1 v2]
  (mapv + v1 v2))


(defn testvecs
  "Tests the vector add operations by reducing a
  random list by each of the v+ operations on
  identical sets of random vectors"
  [n]
  (let [nums (repeatedly (* 2 n) rand)
vpairs (partition 2 nums)
v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs))
v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs))
v2v-list (apply list (map vec vpairs))]
(println "V2 Record:")
(bench (reduce rv+ v2r-list))
(println "V2 Type:")
(bench (reduce tv+ v2t-list))
(println "V2 Vector:")
(bench (reduce vv+ v2v-list))
(println "Just Doubles:")
(bench (reduce + nums



 Here's my output:

*V2 Record:*
Evaluation count : 420 in 60 samples of 7 calls.
 Execution time mean : 164.379725 ms
Execution time std-deviation : 4.478128 ms
   Execution time lower quantile : 149.546749 ms ( 2.5%)
   Execution time upper quantile : 172.317132 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 4 (6.6667 %)
low-mild 3 (5. %)
high-mild 1 (1.6667 %)
 Variance from outliers : 14.2105 % Variance is moderately inflated by 
outliers
*V2 Type:*
Evaluation count : 1860 in 60 samples of 31 calls.
 Execution time mean : 32.238857 ms
Execution time std-deviation : 2.331682 ms
   Execution time lower quantile : 26.769206 ms ( 2.5%)
   Execution time upper quantile : 35.318368 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 5 (8. %)
low-mild 3 (5. %)
 Variance from outliers : 53.4940 % Variance is severely inflated by 
outliers
*V2 Vector:*
Evaluation count : 2040 in 60 samples of 34 calls.
 Execution time mean : 30.175015 ms
Execution time std-deviation : 3.870306 ms
   Execution time lower quantile : 21.877116 ms ( 2.5%)
   Execution time upper quantile : 37.668717 ms (97.5%)
   Overhead used : 1.873322 ns

Found 10 outliers in 60 samples (16.6667 %)
low-severe 5 (8. %)
low-mild 2 (3. %)
high-mild 3 (5. %)
 Variance from outliers : 78.9869 % Variance is severely inflated by 
outliers
*Just Doubles:*
Evaluation count : 20640 in 60 samples of 344 calls.
 Execution time mean : 4.309871 ms
Execution time std-deviation : 537.444033 µs
   Execution time lower quantile : 2.389294 ms ( 2.5%)
   Execution time upper quantile : 4.716009 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 5 (8. %)
low-mild 2 (3. %)
high-mild 1 (1.6667 %)
 Variance from outliers : 78.9282 % Variance is severely inflated by 
outliers



The performance is amazingly better when using primitive doubles, even 
though all operations are doing effectively the same thing: 2 floating 
point add operations. I assume that the overhead of allocating a new 
vector2 object is responsible for the decline in performance.

Did I use type hints correctly?  Is there a way to keep the "x and y" 
vector abstraction and still get something approaching primitive 
performance?

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

Unsure if Protocol Design is Good

[JvJ]

I've been working on a custom implementation of a map called a hist-map, 
which keeps a history of additions and removals in its metadata, so that 
full diffs are not necessary.

I want to make persistent and transient versions of this map.  Both 
versions should support certain common operations, but they will also have 
some mutually exclusive methods.  I've defined the protocols like this:

*(defprotocol IHistMap*
*  (id [this]  "Get the UUID of this map.")*
*  (adds [this] "Get the additions performed on this map.")*
*  (rems [this] "Get the removals performed on this map."))*

*(defprotocol IPersistentHistMap*
*  (clear [this] "Resets additions and removals.  The map will also get a 
new ID."))*

*(defprotocol ITransientHistMap*
*  (clear! [this] "Resets additions and removals.  The map will also get a 
new ID."))*



My plan is to have a PersistentHistMap class which implements IHistMap and 
IPersistentHistMap, and a TransientHistMap class, which implements IHistMap 
and ITransientHistMap.

Somehow, this solution doesn't seem optimal.  I feel like nothing should be 
able to implement just IHistMap without providing some kind of clear 
operation, but the clear operations need to be distinguished between 
mutable and immutable types.

Is there some way to make the other two protocols "depend" on the first, or 
some other solution that I haven't thought of?

Thanks

-- 
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: Transducers improve performance more than expected

[JvJ]

That is very good to know.

On Tuesday, 10 May 2016 20:30:41 UTC-7, Alex Miller wrote:
>
> range is reducible and boils down to just a local loop in most cases, so 
> shouldn't create any heap garbage (well, other than whatever your reducing 
> function does). 
>
> See:
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LongRange.java#L229-L238
>
> Additionally, it can act as a chunked lazy sequence, and in that usage it 
> stores no values either, each chunk is just a start + a step and values are 
> produced by offset. It does cache the lazy chunked sequence though, so 
> you'll get a linked list of chunks essentially (representing 32 values 
> each). 
>
> More than you want to know can be found here: 
> http://dev.clojure.org/jira/browse/CLJ-1515
>
> Similar tricks are played with the other sequence "generators" like 
> iterate, cycle, and repeat, although those don't chunk (
> http://dev.clojure.org/jira/browse/CLJ-1603). 
>
> But to your original question about whether using sequences bloats memory 
> - yes in the general case. For large sequences, you should consider 
> alternatives - collections (like vectors) or in extreme cases Clojure 
> primitive vectors (see vector-of), Java collections, or arrays (usually the 
> most compact). Like everything else, sequences are a tradeoff, and 
> generally a good one due to caching and immutability, tempered by chunking 
> and transients. I'm glad we have more options now though with transducers. 
>
>
> On Tuesday, May 10, 2016 at 7:21:12 PM UTC-5, tbc++ wrote:
>>
>> In addition, as of 1.7, (range 1000) no longer creates a lazy sequence. 
>> It creates something that acts a bit like a sequence, but is reducable. So 
>> doing something like (reduce + 0 (range 1000)) is super fast and creates 
>> almost no garbage at all. 
>>
>> On Tue, May 10, 2016 at 5:46 PM, Alan Thompson <cloo...@gmail.com 
>> > wrote:
>>
>>> I don't understand what you mean. '(range 1000)' produces a lazy 
>>> sequence, and '(reduce + ...)' doesn't hold onto the head of the lazy 
>>> sequence. Therefore, each element can be GC'd as soon as added into the 
>>> running total, the the lazy sequence only produces new elements as they are 
>>> requested by the reduction (chunking aside, of course).
>>> Alan
>>>
>>> On Tue, May 10, 2016 at 4:14 PM, JvJ <kfjwh...@gmail.com > 
>>> wrote:
>>>
>>>> That brings me to another thing I've wondered about.  It is a typical 
>>>> clojure idiom to do something like (reduce + (range 1000)).
>>>>
>>>> But, unlike imperative loops, this will cache all those 1000 elements.  
>>>> This can kind of bloat memory, especially with large sequences?
>>>>
>>>> How can you get around it (other than tail-recursion or the while 
>>>> construction)?
>>>>
>>>> On Tuesday, 10 May 2016 09:45:50 UTC-7, Alex Miller wrote:
>>>>>
>>>>> Because some of the time you don't want caching. For example, if you 
>>>>> want to (later) reduce over a large (larger than memory even) external 
>>>>> resource. eductions allow you to define the source in one spot but defer 
>>>>> the (eager) reduction until later.
>>>>>
>>>>> On Tuesday, May 10, 2016 at 11:22:24 AM UTC-5, JvJ wrote:
>>>>>>
>>>>>> In that case, why aren't eductions just lazy sequences?
>>>>>>
>>>>>> On Monday, 9 May 2016 16:07:55 UTC-7, Alex Miller wrote:
>>>>>>>
>>>>>>> eductions are non-caching (will re-perform their work each time they 
>>>>>>> are used), so most of the time I would say lazy sequences are 
>>>>>>> preferable.
>>>>>>>
>>>>>>> On Monday, May 9, 2016 at 4:54:48 PM UTC-5, JvJ wrote:
>>>>>>>>
>>>>>>>> In a similar vein, do you think that eductions are generally a 
>>>>>>>> better idea than lazy sequences/for comprehensions?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>> 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
&g

Re: Transducers improve performance more than expected

[JvJ]

That brings me to another thing I've wondered about.  It is a typical 
clojure idiom to do something like (reduce + (range 1000)).

But, unlike imperative loops, this will cache all those 1000 elements. 
 This can kind of bloat memory, especially with large sequences?

How can you get around it (other than tail-recursion or the while 
construction)?

On Tuesday, 10 May 2016 09:45:50 UTC-7, Alex Miller wrote:
>
> Because some of the time you don't want caching. For example, if you want 
> to (later) reduce over a large (larger than memory even) external resource. 
> eductions allow you to define the source in one spot but defer the (eager) 
> reduction until later.
>
> On Tuesday, May 10, 2016 at 11:22:24 AM UTC-5, JvJ wrote:
>>
>> In that case, why aren't eductions just lazy sequences?
>>
>> On Monday, 9 May 2016 16:07:55 UTC-7, Alex Miller wrote:
>>>
>>> eductions are non-caching (will re-perform their work each time they are 
>>> used), so most of the time I would say lazy sequences are preferable.
>>>
>>> On Monday, May 9, 2016 at 4:54:48 PM UTC-5, JvJ wrote:
>>>>
>>>> In a similar vein, do you think that eductions are generally a better 
>>>> idea than lazy sequences/for comprehensions?
>>>>
>>>>>
>>>>>

-- 
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: Transducers improve performance more than expected

[JvJ]

In that case, why aren't eductions just lazy sequences?

On Monday, 9 May 2016 16:07:55 UTC-7, Alex Miller wrote:
>
> eductions are non-caching (will re-perform their work each time they are 
> used), so most of the time I would say lazy sequences are preferable.
>
> On Monday, May 9, 2016 at 4:54:48 PM UTC-5, JvJ wrote:
>>
>> In a similar vein, do you think that eductions are generally a better 
>> idea than lazy sequences/for comprehensions?
>>
>> On Sunday, 8 May 2016 22:24:15 UTC-7, Herwig Hochleitner wrote:
>>>
>>> My theory has been, that transducer stacks inline much better, hence 
>>> allow for more optimizations by the jit.
>>> In particular I suspect that escape analysis works better on them, so 
>>> the compiler can even move some of the remaining allocations to the stack.
>>>
>>> To verify this, try running with -verbose:gc and with either 
>>> -XX:-DoEscapeAnalysis then -XX:+DoEscapeAnalysis
>>>
>>>

-- 
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: Transducers improve performance more than expected

[JvJ]

In a similar vein, do you think that eductions are generally a better idea 
than lazy sequences/for comprehensions?

On Sunday, 8 May 2016 22:24:15 UTC-7, Herwig Hochleitner wrote:
>
> My theory has been, that transducer stacks inline much better, hence allow 
> for more optimizations by the jit.
> In particular I suspect that escape analysis works better on them, so the 
> compiler can even move some of the remaining allocations to the stack.
>
> To verify this, try running with -verbose:gc and with either 
> -XX:-DoEscapeAnalysis then -XX:+DoEscapeAnalysis
>
>

-- 
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: Strange exception: Cannot cast to compile stub??

[JvJ]

Changing the set! syntax fixed the issue.  Thanks!  There's no way I could 
have figured that out on my own.

On Monday, 9 May 2016 01:12:36 UTC-7, red...@gmail.com wrote:
>
> There is a jira issue http://dev.clojure.org/jira/browse/CLJ-1226 and it 
> looks like it is marked as fixed in 1.8 
>
> On 05/09/2016 01:10 AM, Kevin Downey wrote: 
> > If I recall correctly, looking at the code at around line 483, I think I 
> > have seen that error arise when using (set! (.fieldName this-reference) 
> > value) inside defrecord and deftype bodies. if you use (set! fieldName 
> > value) syntax you might be fine. 
> > 
> > On 05/08/2016 07:21 PM, JvJ wrote: 
> >> I'm implementing a data structure with persistent and transient 
> >> implementations.   (Code is 
> >> here: 
> https://github.com/JvJ/cross-map/blob/master/src/cross_map/core.cljc#L446). 
>
> >> 
> >> When I try to convert a persistent cross-map to a transient cross-map, 
> I 
> >> get the following exception: 
> >> 
> >> ClassCastException cross_map.core.TransientCrossMap cannot be cast to 
> >> compile__stub.cross_map.core.TransientCrossMap 
> >>  cross-map.core.TransientCrossMap (core.cljc:483) 
> >> 
> >> I don't understand what this means.  Does anyone have insight on it. 
> >> 
> >> -- 
> >> 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  
> >> <mailto:clojure+u...@googlegroups.com >. 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
>
>
> -- 
> And what is good, Phaedrus, 
> And what is not good— 
> Need we ask anyone to tell us these 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: Strange exception: Cannot cast to compile stub??

[JvJ]

I'm not using potemkin.

On Sunday, 8 May 2016 20:12:49 UTC-7, Alex Miller wrote:
>
> Any chance you're using an older version of potemkin? There was a bug like 
> this exposed by Clojure 1.8.  https://github.com/ztellman/vertigo/issues/7

-- 
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: Strange exception: Cannot cast to compile stub??

[JvJ]

Second update: It's the conversion from transient back to persistent that 
causes the problem.

On Sunday, 8 May 2016 19:24:18 UTC-7, JvJ wrote:
>
> Update to this topic:  I can create a transient cross-map, but the failure 
> occurs when I call "into" on a persistent cross-map.  I knew that into used 
> transients internally in certain cases, but is there something that I'm 
> missing?
>
> On Sunday, 8 May 2016 19:21:35 UTC-7, JvJ wrote:
>>
>> I'm implementing a data structure with persistent and transient 
>> implementations.   (Code is here: 
>> https://github.com/JvJ/cross-map/blob/master/src/cross_map/core.cljc#L446
>> ).
>>
>> When I try to convert a persistent cross-map to a transient cross-map, I 
>> get the following exception:
>>
>> ClassCastException cross_map.core.TransientCrossMap cannot be cast to 
>> compile__stub.cross_map.core.TransientCrossMap 
>>  cross-map.core.TransientCrossMap (core.cljc:483)
>>
>> I don't understand what this means.  Does anyone have insight on it.
>>
>

-- 
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: Strange exception: Cannot cast to compile stub??

[JvJ]

Update to this topic:  I can create a transient cross-map, but the failure 
occurs when I call "into" on a persistent cross-map.  I knew that into used 
transients internally in certain cases, but is there something that I'm 
missing?

On Sunday, 8 May 2016 19:21:35 UTC-7, JvJ wrote:
>
> I'm implementing a data structure with persistent and transient 
> implementations.   (Code is here: 
> https://github.com/JvJ/cross-map/blob/master/src/cross_map/core.cljc#L446
> ).
>
> When I try to convert a persistent cross-map to a transient cross-map, I 
> get the following exception:
>
> ClassCastException cross_map.core.TransientCrossMap cannot be cast to 
> compile__stub.cross_map.core.TransientCrossMap 
>  cross-map.core.TransientCrossMap (core.cljc:483)
>
> I don't understand what this means.  Does anyone have insight on it.
>

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

Strange exception: Cannot cast to compile stub??

[JvJ]

I'm implementing a data structure with persistent and transient 
implementations.   (Code is here: 
https://github.com/JvJ/cross-map/blob/master/src/cross_map/core.cljc#L446).

When I try to convert a persistent cross-map to a transient cross-map, I 
get the following exception:

ClassCastException cross_map.core.TransientCrossMap cannot be cast to 
compile__stub.cross_map.core.TransientCrossMap 
 cross-map.core.TransientCrossMap (core.cljc:483)

I don't understand what this means.  Does anyone have insight on it.

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

Transducers improve performance more than expected

[JvJ]

I've been doing some code profiling lately, and I made one small change 
that drastically improved performance.


I had this function:

(defn run-systems
  "Run the systems in the order specified over
  the cross-map specified."
  ([cm] (run-systems system-order cm))
  ([order cm]
   (reduce (fn [acc f]
 (->> (get-profile f)
  (cross-cols acc)

  (mapcat (comp entity-pairs f))

  (into cm )))
cm order)))



Executing this function 1000 times in a row gives a runtime of about 218 ms.

By making a small change and using mapcat as a transducer:

(defn run-systems
  "Run the systems in the order specified over
  the cross-map specified."
  ([cm] (run-systems system-order cm))
  ([order cm]
   (reduce (fn [acc f]
 (->> (get-profile f)
  (cross-cols acc)
  (into cm (mapcat (comp entity-pairs f)
cm order)))


The runtime goes all the way down to 169 ms.

I knew that removing intermediate collections helped performance, but I 
wasn't expecting such a drastic improvement.

Does anyone know similar simple tricks (either transducer-related or not 
transducer-related) that could further improve performance of these types 
of operations?

(Runtime results are averaged over many runs using the criterium profiling 
library, so it's not just a fluke of thread scheduling).

-- 
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: [ClojureScript] #{:ann} funcool/struct - yet another validation library for Clojure and ClojureScript.

[JvJ]

I've been using Schema.  How does struct compare?

-- 
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 do "key" and "val" not work on 2-element vectors?

[JvJ]

Would it negatively impact performance to do a type check?  If the input is 
a MapEntry, use the current key/val, and then use nth for other cases.

On Wednesday, 4 May 2016 10:52:35 UTC-7, Alex Miller wrote:
>
> Yes, there were some changes relating to tuples in the 1.8 alphas that 
> made 2-element vectors valid map entries. However, this was done by having 
> IPersistentVector extend IMapEntry which meant that (from a type 
> perspective) all vectors were valid map entries. In practice, this led to 
> some tricky conditional code both inside and outside Clojure itself to 
> account for the separate cases of generic vectors and 2-element vectors 
> acting as map entries (this comes up when doing generic tree walk 
> traversals on heterogeneous data). This caused some pretty subtle breakage. 
> In the end, nearly all of that was backed out prior to release of 1.8. It 
> may be considered again in the future - as we found, there are tradeoffs.
>
> Re performance, I think you'll find that key and val are many orders of 
> magnitude faster than first and second as they will take a sequence view of 
> entry.
>
> By no means rigorous, but a quick test (just reporting last timing):
>
> (def me (first {:a 1}))
>
> (dotimes [_ 20] (time (dotimes [_ 100] (key me
> "Elapsed time: 0.86 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (val me
> "Elapsed time: 0.959 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (first me
> "Elapsed time: 52.712 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (second me
> "Elapsed time: 56.786 msecs"
>
> If you want something portable between map entries and vectors and also 
> fast, I would prefer nth:
>
> (dotimes [_ 20] (time (dotimes [_ 100] (nth me 0
> "Elapsed time: 0.573 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (nth me 1
> "Elapsed time: 0.573 msecs"
>
> (def v [:a 1])
> (dotimes [_ 20] (time (dotimes [_ 100] (first v
> "Elapsed time: 48.3 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (second v
> "Elapsed time: 54.236 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (nth v 0
> "Elapsed time: 2.011 msecs"
>
> (dotimes [_ 20] (time (dotimes [_ 100] (nth v 1
> "Elapsed time: 2.093 msecs"
>
>
> On Wednesday, May 4, 2016 at 11:52:40 AM UTC-5, adrian...@mail.yu.edu 
>  wrote:
>>
>> I may be misremembering here, but I think this was briefly implemented 
>> for an alpha release of 1.8.0. I think the entire feature in question is 
>> being reworked for the future, but I'm uncertain of the details. Perhaps 
>> others can chime in with the background motivating those changes and 
>> reversions? 
>>
>> On Wednesday, May 4, 2016 at 12:44:19 PM UTC-4, JvJ wrote:
>>>
>>>
>>> I've noticed that, in Clojure, there is a MapEntry type that supports 
>>> the operations "key" and "val", but in Clojurescript, MapEntry is replaced 
>>> by simple 2-element vectors.
>>>
>>> Furthermore, 2-element vectors can be used in almost all other cases 
>>> where a MapEntry is expected, and MapEntries support all vector 
>>> operations,but "key" and "val" are
>>> not supported on these vectors.
>>>
>>> Is there a particular design reason for this?  It doesn't seem like much 
>>> more than an inconvenience
>>>
>>

-- 
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 do "key" and "val" not work on 2-element vectors?

[JvJ]

I'm also wondering if there is any advantage at all to using key/val over 
first/second.  The only downside I can see is that the code won't be clear.

On Wednesday, 4 May 2016 09:52:40 UTC-7, adrian...@mail.yu.edu wrote:
>
> I may be misremembering here, but I think this was briefly implemented for 
> an alpha release of 1.8.0. I think the entire feature in question is being 
> reworked for the future, but I'm uncertain of the details. Perhaps others 
> can chime in with the background motivating those changes and reversions? 
>
> On Wednesday, May 4, 2016 at 12:44:19 PM UTC-4, JvJ wrote:
>>
>>
>> I've noticed that, in Clojure, there is a MapEntry type that supports the 
>> operations "key" and "val", but in Clojurescript, MapEntry is replaced by 
>> simple 2-element vectors.
>>
>> Furthermore, 2-element vectors can be used in almost all other cases 
>> where a MapEntry is expected, and MapEntries support all vector 
>> operations,but "key" and "val" are
>> not supported on these vectors.
>>
>> Is there a particular design reason for this?  It doesn't seem like much 
>> more than an inconvenience
>>
>

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

Why do "key" and "val" not work on 2-element vectors?

[JvJ]

I've noticed that, in Clojure, there is a MapEntry type that supports the 
operations "key" and "val", but in Clojurescript, MapEntry is replaced by 
simple 2-element vectors.

Furthermore, 2-element vectors can be used in almost all other cases where 
a MapEntry is expected, and MapEntries support all vector operations,but 
"key" and "val" are
not supported on these vectors.

Is there a particular design reason for this?  It doesn't seem like much 
more than an inconvenience

-- 
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: Cider test - Print to Report?

[JvJ]

I guess "results" isn't the right word at all.

What I meant was, can I print arbitrary strings/values to the report?

I'd just like to display additional information to help debug test 
failures.  I know I can print to the standard output stream, but having it 
in the report generated by cider would be nicer.

On Monday, 2 May 2016 21:01:07 UTC-7, Bozhidar Batsov wrote:
>
> Can you be a bit more specific? What do you mean by "report results"?
>
> On 2 May 2016 at 20:29, JvJ <kfjwh...@gmail.com > wrote:
>
>> I've been using cider test, and I think it's great.
>>
>> However, I would like to know if it's possible to report results so that 
>> they appear in cider's automatically-generated test report.
>>
>> Does anyone know if this is possible?
>>
>> Thanks.
>>
>> -- 
>> 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.
>>
>
>

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

Cider test - Print to Report?

[JvJ]

I've been using cider test, and I think it's great.

However, I would like to know if it's possible to report results so that 
they appear in cider's automatically-generated test report.

Does anyone know if this is possible?

Thanks.

-- 
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: Benchmarking in Clojurescript -- Necessary or not?

[JvJ]

Even in terms of ratios between different operations?

On Monday, 25 April 2016 19:05:41 UTC-7, Francis Avila wrote:
>
>
>
> On Monday, April 25, 2016 at 6:45:13 PM UTC-5, JvJ wrote:
>>
>> What I want to know is this:  Will the JVM benchmarking numbers reflect 
>> how the JS implementation performs?
>>
>
> No 
>

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

Benchmarking in Clojurescript -- Necessary or not?

[JvJ]

I've been implementing custom persistent map  and its transient counterpart 
<https://github.com/JvJ/cross-map/blob/master/src/cross_map/core.cljc> 
*(currently 
incomplete, but it won't be for long).*
I would like to test how they perform compared to the default PersistentMap 
and TransientMap implementations.

So far, to do this, I've been using a benchmarking library called Criterium 
<https://github.com/hugoduncan/criterium>.  Criterium is great, but it has 
one major disadvantage as far as my project is concerned: It's 
JVM-specific, where as my project is cross-platform JVM and JS.

What I want to know is this:  Will the JVM benchmarking numbers reflect how 
the JS implementation performs?

I understand that JVM and JS are different platforms with different 
capabilities, and that in general JS is slower than JVM.  What I really 
want to know is whether or not the ratios will hold up.

For instance:  If running a set of operations my custom map takes on 
average 2.5 times longer than the same set of operations on a normal 
PersistentHashMap, will that "2.5 times" figure still approximately hold up 
across platforms?

Thanks


-- 
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: Porting Clojure to Native Platforms

[JvJ]

Interesting point about the performance of JIT and GC on JVM.  I didn't 
realize that they could be so highly performant.

Also, I had thought "Metal Clojure" would have been a good name for this 
project, but you went ahead and stole it before I even thought of it!

On Monday, 25 April 2016 14:49:25 UTC-7, tbc++ wrote:
>
> I wrote Pixie and did a fair amount of benchmarking on it. As it stands 
> tracing JITs work well on tight loops. That means in a perfect world you 
> would only have one hot trace through a given set of functions. That's 
> actually harder to pull off than it sounds. 
>
> Take for instance the PersistentHashMap. If you dig into that 
> implementation you'll see dozens of if statements that are hit in different 
> conditions. If you're adding a new branch, adding a new leaf, copying nodes 
> of different types (there are three node types). So simply adding to a 
> hashmap requires dozens of conditional branches and the result of those 
> branches changes every time you add a new item. 
>
> So what I ended up doing for Pixie is disabling the JIT when digging into 
> the hashmap implementations. The PHM was implemented in RPython directly 
> and the JIT wouldn't try to optimize it. However, sometimes the JIT calls 
> back into user code (equals comparisons, and hashcode calculations), so 
> then you have to re-enable the JIT in a place where there isn't much of a 
> loop context. 
>
> There's many other locations like that. You may think you have a simple 
> loop, but then somewhere deep in your code you have a call to update-in, 
> which creates a lazy seq for the path, then iterates on that while digging 
> into several hashmaps and boom, the JIT just bails out. 
>
>
> The more I read up on it though, the more I see examples of tracing JITs 
> working poorly for "application code". That is, normal code you'd run in a 
> webserver. That sort of stuff just has so many if statements that the JIT 
> almost always optimizes the wrong thing.
>
> On Mon, Apr 25, 2016 at 3:12 PM, lvh <_...@lvh.io > wrote:
>
>> Hi Tim,
>>
>> On Apr 25, 2016, at 3:50 PM, Timothy Baldridge > > wrote:
>>
>> A LLVM/C++/RPython based version of Clojure would on a good day come in 
>> at about 1/10 the speed of Clojure on the JVM for general use cases. 
>>
>>
>> Whoa! The RPython one is particularly interesting; are those the figures 
>> you saw out of your efforts in porting Clojure to PyPy? Did you ever get a 
>> chance to interact with the PyPy folks when you saw such (IMHO) 
>> pathological performance figures? (No blame; a genuine question!)
>>
>>
>> lvh
>>
>>
>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke > > wrote:
>>
>>> > The main motivation would be performance gains.
>>>
>>> blah? so many impedance mismatches and layers of indirection that i
>>> don't think it will gain much? i mean, it would probably be better to
>>> spend time tuning gc parameters or something. just a rant / guess.
>>> e.g. robovm is for some use cases perfectly fine performance wise
>>> believe it or not.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>> -- 
>> 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.
>>
>>
>> -- 
>> 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 

Re: Porting Clojure to Native Platforms

[JvJ]

I wasn't trying to solve any particular problem.  I was just wondering 
about the possibility of it.

The main motivation would be performance gains.

On Monday, 25 April 2016 12:55:20 UTC-7, Dan Girellini wrote:
>
> Not knowing the problem you’re specifically trying to solve, would using 
> using the GNU java compiler work to take byte code to native?
>
>
> On April 25, 2016 at 12:47:37 PM, JvJ (kfjwh...@gmail.com ) 
> wrote:
>
>
>
> I've been wondering lately about getting Clojure to compile to native 
> code, and so I've been doing some looking around.
>
> There are a few projects that are on the right track, such as TinyClojure 
> <https://github.com/WillDetlor/TinyClojure> and Ferret 
> <http://nakkaya.com/2011/06/29/ferret-an-experimental-clojure-compiler/>, 
> but they are incomplete and don't seem to be under active development any 
> more.
>
> I'm wondering about the requirements, how much work it would take, and 
> whether or not it would be worth it.  My current thinking is of a 
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that 
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a 
>reference-counting scheme rather than a garbage collector?  This may 
>improve performance. 
>- In a similar vein, can the allocation strategy be controlled for 
>these structures in such a way as to optimize cache locality? 
>- Can we take advantage of tail-call optimization in existing C++ 
>compilers? 
>- It wouldn't have to depend on an existing runtime environment like 
>JVM or JavaScript. 
>- 
>   - Could this reduce reliance on reflection and increase performance? 
>   - Could a new, clojure-optimized runtime be created that improves 
>   performance? 
>- Could certain anonymous functions be optimized or inlined in a way 
>that improves performance over JVM/JS implementations? 
>- Is there a way to compile C++ code at runtime?  This would be 
>essential for the REPL and for Macros. 
>
>
> Let me know if anyone has any thoughts on the matter.
>
> Thanks
> --
> 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.
>
>

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

Porting Clojure to Native Platforms

[JvJ]

I've been wondering lately about getting Clojure to compile to native code, 
and so I've been doing some looking around.

There are a few projects that are on the right track, such as TinyClojure 
 and Ferret 
, 
but they are incomplete and don't seem to be under active development any 
more.

I'm wondering about the requirements, how much work it would take, and 
whether or not it would be worth it.  My current thinking is of a 
Clojure->C/C++ compiler.

So far, I have a few topics for discussion that I'm unclear about that 
might be necessary for this kind of project:

   - Can the Immutable Persistent Data Structures be implemented with a 
   reference-counting scheme rather than a garbage collector?  This may 
   improve performance.
   - In a similar vein, can the allocation strategy be controlled for these 
   structures in such a way as to optimize cache locality?
   - Can we take advantage of tail-call optimization in existing C++ 
   compilers?
   - It wouldn't have to depend on an existing runtime environment like JVM 
   or JavaScript.
  - Could this reduce reliance on reflection and increase performance?
  - Could a new, clojure-optimized runtime be created that improves 
  performance?
   - Could certain anonymous functions be optimized or inlined in a way 
   that improves performance over JVM/JS implementations?
   - Is there a way to compile C++ code at runtime?  This would be 
   essential for the REPL and for Macros.


Let me know if anyone has any thoughts on the matter.

Thanks

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

Transient Collection Identity

[JvJ]

While doing operations on transient collections, I've noticed that the 
result of assoc! or conj! is always identical to the original structure 
(i.e. it satisfies "identical?", and is not merely equivalent).

Is this always the case, or can the return value of assoc! or conj! 
sometimes be a different object?

-- 
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: How to forward-declare deftypes

[JvJ]

What I ended up doing was forward-declaring a wrapper to the constructor of 
the later class.  I actually am implementing a protocol, but the concrete 
types representing the persistent and transient versions need to reference 
each other.  Also, I'm using deftype over defrecord because I want the 
objects to be alternative map implementations, and I want mutable fields 
for the transients.

On Thursday, 21 April 2016 16:22:14 UTC-7, tbc++ wrote:
>
> Few things to consider: code against protocols where possible (removes the 
> need to forward declare methods). Forward declare the constructor functions:
>
> (declare ->Foo)
>
> ...
>
> (defn some-code []
>   (->Foo 1 2))
>
> (defrecord Foo [x y])
>
> If you need to do type checks check for a protocol instead. 
>
> Timothy
>
>
> On Thu, Apr 21, 2016 at 5:01 PM, Sean Corfield <se...@corfield.org 
> > wrote:
>
>> Pretty sure Michal Marczyk mentioned this in his Clojure/West talk last 
>> week:
>>
>>  
>>
>>
>> https://www.youtube.com/watch?v=vZtkqDIicqI=14=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb
>>
>>  
>>
>> (I don’t remember exactly what he said was the workaround)
>>
>>  
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>>
>> On 4/21/16, 2:05 PM, "JvJ" <clo...@googlegroups.com  on 
>> behalf of kfjwh...@gmail.com > wrote:
>>
>>  
>>
>> I'm working with two deftypes that I want to be able to references each 
>> other.  (They're persistent and transient implementations of the same 
>> collection.)
>>
>>  
>>
>> So far, it seems that the normal clojure.core/declare doesn't work in 
>> this case.  Is there another way to do it?
>>
>>  
>>
>> Thanks
>>
>> .
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

How to forward-declare deftypes

[JvJ]

I'm working with two deftypes that I want to be able to references each 
other.  (They're persistent and transient implementations of the same 
collection.)

So far, it seems that the normal clojure.core/declare doesn't work in this 
case.  Is there another way to do it?

Thanks

-- 
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: Memory Locality - Maps vs. Vectors vs. Transient Maps & Vectors

[JvJ]

I don't think I'll go with primitive arrays.  A big part of the reason I'm 
using Clojure is for the immutable persistence.  I just want to use them in 
the most efficient way possible.  I know I'm not going to get hyper-blazing 
C-level performance.

On Wednesday, 20 April 2016 15:38:11 UTC-7, Stuart Sierra wrote:
>
> The first answer: test & measure. Benchmark your code, use a JVM profiler 
> to find hotspots, etc. Test every change you make to see if it has a 
> measurable improvement. Any assumptions about what “should” be 
> faster/slower are likely to be wrong.
>
> The long answer:
>
> The JVM does not give you much control over how objects are arranged in 
> memory. In Java and Clojure, almost everything is a pointer to an object on 
> the heap. Java collection classes and Clojure collections store pointers to 
> objects; they do not store values “in-line” like an array of structs in C. 
> The JVM *may* have optimizations that try to arrange objects “near” other 
> objects, but you have no control over this.
>
> So my (untested) expectation is that all Clojure collection types are 
> more-or-less equal in terms of memory locality.
>
> The only built-in data structure that offers the possibility of contiguous 
> allocation in Java — without dropping down to native code — is an array of 
> primitives, such as integers or doubles. Clojure has built-in functions to 
> create and manipulate Java primitive arrays, if that works for your use 
> case.
>
> –S
>
>
> On Wednesday, April 20, 2016 at 2:03:10 PM UTC-4, JvJ wrote:
>>
>> I'm writing some code that I would like to perform as quickly as 
>> possible.  Currently, I am iterating over large hash maps and performing 
>> assocs and dissocs.
>>
>> I don't know much about performance optimization, but I am told that 
>> memory locality is a big factor.  I would like to know how Persistent Maps, 
>> Persistent Vectors, Transient Maps, and Transient Vectors compare to one 
>> another in this respect.
>>
>> Also, the objects in the collection that I'm iterating over will 
>> themselves be maps.  So, if I had a vector with good memory locality, but 
>> it stored what are effectively pointers to maps allocated elsewhere, will 
>> that nullify the benefits of memory locality?
>>
>> Thanks
>>
>

-- 
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: Possible to override assoc-in or update-in?

[JvJ]

That was actually the example I used to implement this.  As it turns out, 
assoc-in, update-in, etc. work on anything that supports assoc.

On Wednesday, 20 April 2016 13:39:40 UTC-7, Andy Fingerhut wrote:
>
> I don't know if assoc-in etc. work on the clojure.data.priority-map data 
> structures, but your questions at least reminded me of the implementation 
> of that data structure, which uses two maps internally to maintain the 
> priority map, and keeps their contents consistent with each other [1].  It 
> also implements all of the methods that regular Clojure maps do, so all 
> normal map operations work on priority-maps, too.  Its implementation may 
> give you some ideas for one way to do what you are hoping for.
>
> Andy
>
> [1] https://github.com/clojure/data.priority-map
>
>
> On Wed, Apr 20, 2016 at 10:18 AM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> I had a bit of trouble fully understanding the EAV concept or the pldb 
>> code.  There's not a good overview of EAV architecture that doesn't focus 
>> on databases.  I'm not much of a DB guy.  So, I'm not sure if I got the 
>> essence of the EAV pattern with my new implementation, but here it is 
>> anyway:
>>
>> I think the legacy of object-orientation was so embedded in my brain that 
>> I failed to see the simple solution: rows and columns.  I was thinking of 
>> items in the map as "containers" of items, when I could have been thinking 
>> of them as rows in a table.  The table is effectively a sparse matrix.
>>
>> The implementation's main map is of type { [row col]->Item }.  It also 
>> uses two other maps: row-idx:{row->{col item}} and 
>> col-idx:{col->{row->item}}.
>>
>> Whenever an assoc occurs on key [r c] and item i, here is how the values 
>> are updated:
>> main-map<-(assoc main-map [r c] i)
>> row-idx<-(assoc-in row-idx [r c] i)
>> col-idx<-(assoc-in col-idx [c r] i)
>>
>> This way, we efficiently maintain row-idx and col-idx, two complementary 
>> nested maps that mirror each others' structure.
>>
>> Did I get close to the EAV pattern here?  Also, I wonder if this approach 
>> is scalable to higher-dimensional tables, for instance where each item is 
>> associated with a 3-tuple.
>>
>> On Monday, 18 April 2016 17:18:45 UTC-7, tbc++ wrote:
>>>
>>> Core.logic has one such implementation: 
>>> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
>>>  
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fcore.logic%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fclojure%2Fclojure%2Fcore%2Flogic%2Fpldb.clj=D=1=AFQjCNGjJWdatQscPmDIx3xpBMuwPmOH7A>
>>>  
>>> might be a place to start. 
>>>
>>> On Mon, Apr 18, 2016 at 5:35 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>
>>>> Can you point me to a working example of one of these structures?
>>>>
>>>> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>>>>
>>>>> And by "fairly common these days", I mean that I run into this sort of 
>>>>> structure a lot in clojure with anything that is trying to logic or query 
>>>>> operations. Probably isn't that common outside of projects in that 
>>>>> domain. 
>>>>>
>>>>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge <tbald...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> assoc-in is defined in terms of assoc: 
>>>>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>>>>
>>>>>> And this structure is fairly common these days, it's basically a 
>>>>>> index of tuples [e a v], and you're creating a eav index and then an av 
>>>>>> index. Datomic does this same sort of thing, for the datom [e a v t] it 
>>>>>> creates indices for :eavt :avet and a few others that escape my memory 
>>>>>> at 
>>>>>> the moment.  
>>>>>>
>>>>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>>>
>>>>>>> I'm implementing a map data structure where most of the values are 
>>>>>>> maps or sets, and these values can be cross-indexed by the keys they 
>>>>>>> contain.  I don't know if it already has a name, but I'm calling it a 
>>>>>>> cross-map.  It's similar to a two-way map, but they're not the same 
>>>>>>> thing

Re: Memory Locality - Maps vs. Vectors vs. Transient Maps & Vectors

[JvJ]

Do you think that maps vs vectors would make a difference in the transient 
case?

On Wednesday, 20 April 2016 13:42:12 UTC-7, Andy Fingerhut wrote:
>
> Transients are a performance optimization that can give quite significant 
> performance increases when you know you will be doing many updates to a 
> Clojure vector or map.  A long sequence of updates on a transient tends to 
> allocate much less memory than the corresponding sequence of updates on a 
> non-transient data structure.
>
> Andy
>
> On Wed, Apr 20, 2016 at 11:03 AM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> I'm writing some code that I would like to perform as quickly as 
>> possible.  Currently, I am iterating over large hash maps and performing 
>> assocs and dissocs.
>>
>> I don't know much about performance optimization, but I am told that 
>> memory locality is a big factor.  I would like to know how Persistent Maps, 
>> Persistent Vectors, Transient Maps, and Transient Vectors compare to one 
>> another in this respect.
>>
>> Also, the objects in the collection that I'm iterating over will 
>> themselves be maps.  So, if I had a vector with good memory locality, but 
>> it stored what are effectively pointers to maps allocated elsewhere, will 
>> that nullify the benefits of memory locality?
>>
>> Thanks
>>
>> -- 
>> 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.
>>
>
>

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

Memory Locality - Maps vs. Vectors vs. Transient Maps & Vectors

[JvJ]

I'm writing some code that I would like to perform as quickly as possible. 
 Currently, I am iterating over large hash maps and performing assocs and 
dissocs.

I don't know much about performance optimization, but I am told that memory 
locality is a big factor.  I would like to know how Persistent Maps, 
Persistent Vectors, Transient Maps, and Transient Vectors compare to one 
another in this respect.

Also, the objects in the collection that I'm iterating over will themselves 
be maps.  So, if I had a vector with good memory locality, but it stored 
what are effectively pointers to maps allocated elsewhere, will that 
nullify the benefits of memory locality?

Thanks

-- 
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: Possible to override assoc-in or update-in?

[JvJ]

I had a bit of trouble fully understanding the EAV concept or the pldb 
code.  There's not a good overview of EAV architecture that doesn't focus 
on databases.  I'm not much of a DB guy.  So, I'm not sure if I got the 
essence of the EAV pattern with my new implementation, but here it is 
anyway:

I think the legacy of object-orientation was so embedded in my brain that I 
failed to see the simple solution: rows and columns.  I was thinking of 
items in the map as "containers" of items, when I could have been thinking 
of them as rows in a table.  The table is effectively a sparse matrix.

The implementation's main map is of type { [row col]->Item }.  It also uses 
two other maps: row-idx:{row->{col item}} and col-idx:{col->{row->item}}.

Whenever an assoc occurs on key [r c] and item i, here is how the values 
are updated:
main-map<-(assoc main-map [r c] i)
row-idx<-(assoc-in row-idx [r c] i)
col-idx<-(assoc-in col-idx [c r] i)

This way, we efficiently maintain row-idx and col-idx, two complementary 
nested maps that mirror each others' structure.

Did I get close to the EAV pattern here?  Also, I wonder if this approach 
is scalable to higher-dimensional tables, for instance where each item is 
associated with a 3-tuple.

On Monday, 18 April 2016 17:18:45 UTC-7, tbc++ wrote:
>
> Core.logic has one such implementation: 
> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fcore.logic%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fclojure%2Fclojure%2Fcore%2Flogic%2Fpldb.clj=D=1=AFQjCNGjJWdatQscPmDIx3xpBMuwPmOH7A>
>  
> might be a place to start. 
>
> On Mon, Apr 18, 2016 at 5:35 PM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> Can you point me to a working example of one of these structures?
>>
>> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>>
>>> And by "fairly common these days", I mean that I run into this sort of 
>>> structure a lot in clojure with anything that is trying to logic or query 
>>> operations. Probably isn't that common outside of projects in that domain. 
>>>
>>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge <tbald...@gmail.com> 
>>> wrote:
>>>
>>>> assoc-in is defined in terms of assoc: 
>>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>>
>>>> And this structure is fairly common these days, it's basically a index 
>>>> of tuples [e a v], and you're creating a eav index and then an av index. 
>>>> Datomic does this same sort of thing, for the datom [e a v t] it creates 
>>>> indices for :eavt :avet and a few others that escape my memory at the 
>>>> moment.  
>>>>
>>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ <kfjwh...@gmail.com> wrote:
>>>>
>>>>> I'm implementing a map data structure where most of the values are 
>>>>> maps or sets, and these values can be cross-indexed by the keys they 
>>>>> contain.  I don't know if it already has a name, but I'm calling it a 
>>>>> cross-map.  It's similar to a two-way map, but they're not the same thing.
>>>>>
>>>>> For instance, a common operation would be something like "give me all 
>>>>> values of this map that contain the key :a."
>>>>>
>>>>> In order to do this efficiently, I'm maintaining a second map that 
>>>>> maps keys in the values of the main map to keys of the main map whose 
>>>>> values contain that key.
>>>>>
>>>>> If that sounds confusing, consider this:
>>>>> main-map:
>>>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>>>>
>>>>> Corresponding cross-indices:
>>>>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>>>>
>>>>> As you can see, each key maintains references to those entries where 
>>>>> it is found.
>>>>>
>>>>> When a nested update occurs that adds an entry to one of the main 
>>>>> map's values, the efficient thing to do would be to simply conj that new 
>>>>> key onto its corresponding cross-index set.
>>>>>
>>>>> However, I am trying to implement this as a clojure IPersistentMap, 
>>>>> and the only method I can override is assoc, not assoc-in.
>>>>>
>>>>> Using regular assoc, I would have to compare the old value's keys to 
>>>>> the new value's keys and find the set dif

Re: Possible to override assoc-in or update-in?

[JvJ]

Can you point me to a working example of one of these structures?

On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>
> And by "fairly common these days", I mean that I run into this sort of 
> structure a lot in clojure with anything that is trying to logic or query 
> operations. Probably isn't that common outside of projects in that domain. 
>
> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge <tbald...@gmail.com 
> > wrote:
>
>> assoc-in is defined in terms of assoc: 
>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>
>> And this structure is fairly common these days, it's basically a index of 
>> tuples [e a v], and you're creating a eav index and then an av index. 
>> Datomic does this same sort of thing, for the datom [e a v t] it creates 
>> indices for :eavt :avet and a few others that escape my memory at the 
>> moment.  
>>
>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ <kfjwh...@gmail.com > 
>> wrote:
>>
>>> I'm implementing a map data structure where most of the values are maps 
>>> or sets, and these values can be cross-indexed by the keys they contain.  I 
>>> don't know if it already has a name, but I'm calling it a cross-map.  It's 
>>> similar to a two-way map, but they're not the same thing.
>>>
>>> For instance, a common operation would be something like "give me all 
>>> values of this map that contain the key :a."
>>>
>>> In order to do this efficiently, I'm maintaining a second map that maps 
>>> keys in the values of the main map to keys of the main map whose values 
>>> contain that key.
>>>
>>> If that sounds confusing, consider this:
>>> main-map:
>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>>
>>> Corresponding cross-indices:
>>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>>
>>> As you can see, each key maintains references to those entries where it 
>>> is found.
>>>
>>> When a nested update occurs that adds an entry to one of the main map's 
>>> values, the efficient thing to do would be to simply conj that new key onto 
>>> its corresponding cross-index set.
>>>
>>> However, I am trying to implement this as a clojure IPersistentMap, and 
>>> the only method I can override is assoc, not assoc-in.
>>>
>>> Using regular assoc, I would have to compare the old value's keys to the 
>>> new value's keys and find the set difference of the two, which is not an 
>>> O(1) operation.
>>>
>>> Is there any way to override the behaviour of nested associations or 
>>> updates?
>>>
>>> Thanks
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Possible to override assoc-in or update-in?

[JvJ]

I'm implementing a map data structure where most of the values are maps or 
sets, and these values can be cross-indexed by the keys they contain.  I don't 
know if it already has a name, but I'm calling it a cross-map.  It's similar to 
a two-way map, but they're not the same thing.

For instance, a common operation would be something like "give me all values of 
this map that contain the key :a."

In order to do this efficiently, I'm maintaining a second map that maps keys in 
the values of the main map to keys of the main map whose values contain that 
key.

If that sounds confusing, consider this:
main-map: 
{:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}

Corresponding cross-indices:
{:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}

As you can see, each key maintains references to those entries where it is 
found.

When a nested update occurs that adds an entry to one of the main map's values, 
the efficient thing to do would be to simply conj that new key onto its 
corresponding cross-index set.

However, I am trying to implement this as a clojure IPersistentMap, and the 
only method I can override is assoc, not assoc-in.

Using regular assoc, I would have to compare the old value's keys to the new 
value's keys and find the set difference of the two, which is not an O(1) 
operation.

Is there any way to override the behaviour of nested associations or updates?

Thanks

-- 
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: Pmap on hash maps

[JvJ]

Orders of magnitude?  Is it even worth running things in parallel in this 
case?

On Sunday, 17 April 2016 07:20:30 UTC-7, tbc++ wrote:
>
> The cost of creating that extra collection will be vastly overshadowed by 
> the cost of running pmap. pmap involves the use of several locks, and 
> thread co-ordination primitives, these will most likely be orders of 
> magnitude more expensive than an extra allocation. 
>
> Timothy
>
> On Sun, Apr 17, 2016 at 12:38 AM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> Perhaps I should have rephrased.  I meant calling it in such a way that 
>> the result is a hash map.
>>
>> I know I could do something like:
>>
>> (into a (pmap f a))
>>
>> This will give the same result, but there's an extra collection in there 
>> that I'm not sure is necessary.
>>
>>
>> On Saturday, 16 April 2016 20:15:51 UTC-7, Alex Miller wrote:
>>>
>>> You can call pmap on hash maps!
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Pmap on hash maps

[JvJ]

Perhaps I should have rephrased.  I meant calling it in such a way that the 
result is a hash map.

I know I could do something like:

(into a (pmap f a))

This will give the same result, but there's an extra collection in there 
that I'm not sure is necessary.

On Saturday, 16 April 2016 20:15:51 UTC-7, Alex Miller wrote:
>
> You can call pmap on hash maps!

-- 
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: Extending IAssociative/Associative in clj and cljs

[JvJ]

I know I have to do it with CLJC.  I just didn't want to mess around with 
too many reader conditionals.

On Saturday, 16 April 2016 19:52:30 UTC-7, tbc++ wrote:
>
> You have to do it with CLJC. Not optimal, but that's the way it goes right 
> now. And yeah Associative.java is broken up into multiple smaller protocols 
> in CLJS. 
>
> Timothy
>
> On Sat, Apr 16, 2016 at 8:19 PM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>>
>> I was attempting to create a cross-platform (clojure and clojurescript) 
>> datatype that would act as an associative collection.  I can see that cljs 
>> has a number of protocols for this under cljs.core.  However, those 
>> protocols are not present in clojure.  There is the java interface 
>> Associative, but that's not really a clojure protocol.
>>
>> Is there an easy way to write cross-platform code that can extend 
>> associative collections?
>>
>> Thanks
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Extending IAssociative/Associative in clj and cljs

[JvJ]

I was attempting to create a cross-platform (clojure and clojurescript) 
datatype that would act as an associative collection.  I can see that cljs 
has a number of protocols for this under cljs.core.  However, those 
protocols are not present in clojure.  There is the java interface 
Associative, but that's not really a clojure protocol.

Is there an easy way to write cross-platform code that can extend 
associative collections?

Thanks

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

Pmap on hash maps

[JvJ]

Does anyone know if there exists a convenient method to call something like 
pmap on a hash map?

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

CLJS Analyzer - How To fully qualify a symbol?

[JvJ]

I'm writing a cross-platform app.  One of the macros I use takes a symbol 
as a parameter, and I want to make sure that I can obtain a fully qualified 
version of that symbol.

For example, if I have the following environment:

(ns foo

-- 
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: Core.async performance with many channels

[JvJ]

It seems to do rather well.

On Wednesday, 6 April 2016 08:29:07 UTC-7, Francis Avila wrote:
>
> On Monday, April 4, 2016 at 6:30:07 PM UTC-5, Howard M. Lewis Ship wrote:
>>
>> David Nolen had an early ClojureScript core.async demo with thousands of 
>> channels, controlling individual pixels.
>>
>
> This is the demo you are referring to: 
> http://swannodette.github.io/2013/08/02/10-processes/
>  
>

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

Webassembly as a Clojure target platform

[JvJ]

Is there any plan in the future to have clojure (or some dialect of 
clojure) compile to webassembly?  I can't say for sure if it is the "next 
big thing" for the web, but it is a very interesting concept.

I suppose that, if Java bytecode could cross-compile to Webassembly, we 
would essentially get this for free, but I'm not sure if that will happen.

-- 
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: Core.async performance with many channels

[JvJ]

This thing just an idea at this point.  Basically, your typical game loop 
will consist of iterating over a collection of objects and calling some 
kind of update operation on each.  I would like to replace this with 
asynchronous signaling.  Signaling could include messages like "update this 
object".  These messages would trigger certain async processes to start in 
the object.  This may allow for more flexible and asynchronous programming, 
since not everything has to fit into an update cycle.

On Sunday, 3 April 2016 21:10:16 UTC-7, Rangel Spasov wrote:
>
> Without knowing too much about the internals, but having used 
> core.async/channels a lot, I don't think "hundreds" of channels will be a 
> problem ever. However, as always the devil is in the details. People might 
> be able to give better feedback if you give more details about your use 
> case. 
>
> On Saturday, April 2, 2016 at 7:59:50 PM UTC-7, JvJ wrote:
>>
>>
>> Lately, I've been working on a game in Clojure, and I've been trying out 
>> various ways of modelling the game state and objects.
>>
>> One of these ideas is to give each object its own channel and make a 
>> fully asynchronous architecture.
>>
>> I would like to know if having potentially hundreds of channels operating 
>> at once would be a significant performance issue.
>>
>> Thanks.
>>
>

-- 
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: Cross platform date/time libarary

[JvJ]

OK.  As long as a single import in a cljc will suffice.

On Sunday, 3 April 2016 21:20:54 UTC-7, Sean Corfield wrote:
>
> On 4/3/16, 7:36 PM, "JvJ" <clo...@googlegroups.com  on 
> behalf of kfjwh...@gmail.com > wrote: 
> > Is there a date/time library that is written for both clojure and 
> clojurescript? 
>
> Probably the closest thing is this pair of libraries: 
>
> https://github.com/clj-time/clj-time 
>
> https://github.com/andrewmcveigh/cljs-time 
>
> Same API, different implementations. 
>
> Sean Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
>
>
>
>
>
>
>

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

Cross platform date/time libarary

[JvJ]

Is there a date/time library that is written for both clojure and 
clojurescript?

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

Core.async performance with many channels

[JvJ]

Lately, I've been working on a game in Clojure, and I've been trying out 
various ways of modelling the game state and objects.

One of these ideas is to give each object its own channel and make a fully 
asynchronous architecture.

I would like to know if having potentially hundreds of channels operating 
at once would be a significant performance issue.

Thanks.

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

Prismatic Schema -- Type signature of reducing functions

[JvJ]

When using functions with schema type signatures for reduce, I run into 
output schema errors whenever I try to short-circuit the reducing operation 
by wrapping the return value in reduced.  How can I modify the type 
signature so that it accepts output values of types A and (reduced A)?

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

Emacs cider mode has problems with macros

[JvJ]

Something unusual happens when I'm writing macros while in modes cider and 
ClojureC with autocomplete enabled.

I have a macro derive-component (definition is too long to put in here). 
When I attempt to use this macro, as follows:

;; s refers to schema.core in this context

(derive-component
 Position
 "It has x and y coordinates."
   [s/Int s/Int])


If I try to type anywhere within the above form, I get a massive exception 
printout in the repl.  Furthermore, my cursor automatically switches to the 
repl from the file buffer.

I realize that something may be wrong with my macro definition, but that's 
not the point.  The repl should be able to handle these errors gracefully. 
 Furthermore, There is nothing to my knowledge that should be actively 
evaluating code.

Does anyone know what may be doing this?

Thanks

Here's the error stack trace:

RuntimeException [Int Int] is not a valid sequence schema; a valid sequence 
schema consists of zero or more `one` elements, followed by zero or more 
`optional` elements, followed by an optional schema that will match the 
remaining elements.  schema.core/parse-sequence-schema (core.clj:901)
java.lang.IllegalArgumentException: Don't know how to create ISeq from: 
clojure.lang.Symbol
 at clojure.lang.RT.seqFrom (RT.java:528)
clojure.lang.RT.seq (RT.java:509)
clojure.core/seq (core.clj:137)
clojure.core.protocols$seq_reduce.invoke (protocols.clj:30)
clojure.core.protocols/fn (protocols.clj:84)
clojure.core.protocols$fn__6452$G__6447__6465.invoke (protocols.clj:13)
clojure.core$reduce.invoke (core.clj:6519)
clojure.core$mapv.invoke (core.clj:6616)
cider.nrepl.middleware.info$format_eldoc$fn__26048.invoke (info.clj:290)
clojure.core$map$fn__4553.invoke (core.clj:2622)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.RT.seq (RT.java:507)
clojure.core/seq (core.clj:137)
clojure.core$map$fn__4553.invoke (core.clj:2616)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.RT.seq (RT.java:507)
clojure.core/seq (core.clj:137)
clojure.core$dorun.invoke (core.clj:3009)
clojure.core$doall.invoke (core.clj:3025)
clojure.walk$walk.invoke (walk.clj:46)
clojure.walk$postwalk.invoke (walk.clj:58)
clojure.core$partial$fn__4527.invoke (core.clj:2493)
clojure.core$map$fn__4553.invoke (core.clj:2622)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.RT.seq (RT.java:507)
clojure.lang.LazilyPersistentVector.create 
(LazilyPersistentVector.java:30)
clojure.core$vec.invoke (core.clj:361)
clojure.walk$walk.invoke (walk.clj:45)
clojure.walk$postwalk.invoke (walk.clj:58)
clojure.core$partial$fn__4527.invoke (core.clj:2493)
clojure.core$map$fn__4553.invoke (core.clj:2624)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.Cons.next (Cons.java:39)
clojure.lang.RT.next (RT.java:674)
clojure.core/next (core.clj:64)
clojure.core.protocols/fn (protocols.clj:170)
clojure.core.protocols$fn__6478$G__6473__6487.invoke (protocols.clj:19)
clojure.core.protocols$seq_reduce.invoke (protocols.clj:31)
clojure.core.protocols/fn (protocols.clj:101)
clojure.core.protocols$fn__6452$G__6447__6465.invoke (protocols.clj:13)
clojure.core$reduce.invoke (core.clj:6519)
clojure.core$into.invoke (core.clj:6600)
clojure.walk$walk.invoke (walk.clj:49)
clojure.walk$postwalk.invoke (walk.clj:58)
clojure.walk$stringify_keys.invoke (walk.clj:107)
clojure.tools.nrepl.transport.FnTransport.send (transport.clj:28)
clojure.tools.nrepl.middleware.pr_values$pr_values$fn$reify__13898.send 
(pr_values.clj:27)
cider.nrepl.middleware.info$eldoc_reply.invoke (info.clj:302)
cider.nrepl.middleware.info$wrap_info$fn__26058.invoke (info.clj:315)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)
cemerick.piggieback$wrap_cljs_repl$fn__20579.invoke (piggieback.clj:299)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)
cider.nrepl.middleware.track_state$wrap_tracker$fn__27148.invoke 
(track_state.clj:200)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)
cider.nrepl.middleware.pprint$wrap_pprint$fn__22366.invoke 
(pprint.clj:106)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)
cider.nrepl.middleware.inspect$wrap_inspect$fn__20853.invoke 
(inspect.clj:137)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)
clojure.tools.nrepl.middleware.pr_values$pr_values$fn__13895.invoke 
(pr_values.clj:22)
clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
(middleware.clj:22)

Re: Error with company-mode autocomplete

[JvJ]

Solved by adding the seq-library to my load 
path: https://github.com/NicolasPetton/seq.el

On Saturday, 19 March 2016 15:13:40 UTC-7, JvJ wrote:
>
> I downloaded a new emacs config (
> https://github.com/clojure-emacs/example-config), and it appears to be 
> using company for auto-completion.  However, the autocomplete never works. 
>  I get the following error each time:
>
>
> Error while checking syntax automatically: (void-function seq-find) [2 
> times]
> eldoc error: (void-function seq-position)
>
>
> Does anyone know the cause of this or how it could be fixed?
>
> Thanks.
>

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

Error with company-mode autocomplete

[JvJ]

I downloaded a new emacs config 
(https://github.com/clojure-emacs/example-config), and it appears to be 
using company for auto-completion.  However, the autocomplete never works. 
 I get the following error each time:


Error while checking syntax automatically: (void-function seq-find) [2 
times]
eldoc error: (void-function seq-position)


Does anyone know the cause of this or how it could be fixed?

Thanks.

-- 
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] Elements of Clojure

[JvJ]

So far, this appears to be primarily focused on style and programming 
practice.  Is that going to be the primary focus of the book?

On Thursday, 17 March 2016 10:47:55 UTC-7, Zach Tellman wrote:
>
> I'm writing a book about Clojure, aimed at people who already know the 
> core concepts, and want to use them more effectively.  The first chapter, 
> "Names", is complete and can be read for free.  Details can be found at 
> http://elementsofclojure.com/.  
>
> I'm happy to answer any questions here, or on the book's mailing list at 
> https://groups.google.com/forum/#!forum/elements-of-clojure.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note 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: Prismatic Schema - Self-reference in schema definitions

[JvJ]

Thanks for the tip here.  abstract-map-schema works really well.

One thing that I would add to it if I could would be a dispatch function 
rather than just keywords, but I don't need that at the moment.

On Sunday, 6 March 2016 18:41:53 UTC-8, Jason Wolfe wrote:
>
> If I'm understanding correctly, this sounds like a 
> `schema.experimental.abstract-map-schema` to me (it's basically shorthand 
> for what Bobby suggests) .  There's an example in the readme. 
>
> Best, Jason
>
> On Sunday, March 6, 2016 at 5:28:31 AM UTC+5:30, JvJ wrote:
>>
>> I've been using Schema, and there's a kind of type definition that I'm 
>> having trouble with.  I'm not sure exactly how to describe it, so I'll 
>> provide an example.
>>
>> I'm working on a digital card game in which there are numerous zones that 
>> a card may be in.  Each card needs to know which zone it is in, and there 
>> may be additional information depending on the zone.
>>
>> For instance, if a card is in a player's hand, no additional information 
>> is required.  However, if the card is on the board, it needs to understand 
>> its position on the board.
>>
>> I have the following definition for zone types:
>>
>> (def Zone
>>   "A schema for referring to the various game zones."
>>   (s/enum :Hand
>>   :Deck
>>   :Board
>>   :Field
>>   :Discard
>>   :Void))
>>
>> I want to define a different schema type for each of these, and then 
>> define a zone spec:
>>
>> (def ZoneSpec {(required-key :zone-type) Zone
>>:data > specified earlier>
>> })
>>
>> I want to ensure that whichever data is provided specified the schema 
>> associated with the zone type.
>>
>> Is there a way to do this?
>>
>> Thanks.
>>
>

-- 
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: Prismatic Schema - Why is "both" deprecated?

[JvJ]

In this example, one of the schemas is a predicate schema.  What if neither 
of them are?

On Sunday, 6 March 2016 18:48:21 UTC-8, Jason Wolfe wrote:
>
> In place of (s/both long (s/pred odd?)) you can do (s/conditional odd? 
> long), but (s/constrained long odd?) probably provides better error 
> messages (since it validates long before odd?). I think there are some 
> examples in the readme. 
>
> If this isn't what you're looking for, can you please provide some more 
> details of your use case? 
>
> Thanks,
> Jason
>
>
>
> On Sunday, March 6, 2016 at 5:38:35 AM UTC+5:30, JvJ wrote:
>>
>>
>> I've noticed that there is the function "both" in Schema.
>>
>> Both says that it can be replaced by conditional, but I'm not sure 
>> exactly how to go about doing this.
>>
>> Can someone provide an example?
>>
>> Thanks
>>
>

-- 
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: Prismatic Schema - Self-reference in schema definitions

[JvJ]

Algebraic data types are exactly what I'm looking for, actually.  I think 
I'll try something like that.

On Saturday, 5 March 2016 16:28:22 UTC-8, Bobby Eickhoff wrote:
>
> Note also that I'm giving each Zone "object" it's own :type property.  
> That's how I'm able to dispatch on the type.  It also plays well with 
> multimethods.
>
> On Saturday, March 5, 2016 at 7:26:27 PM UTC-5, Bobby Eickhoff wrote:
>>
>> It sounds like what you're describing is (structurally) an algebraic data 
>> type, i.e. a generic type with specific variants.  I've been able to do 
>> something like this in my own projects.  Here I'm considering Zone the 
>> general type and each variant is Zone:Hand, Zone:Deck, 
>>
>> (def Zone:Hand
>>   ...)
>>
>> (def Zone:Deck
>>   ...)
>>
>> (def Zone
>>   (s/conditional
>> #(= (:type %) :Hand) Zone:Hand
>>     #(= (:type %) :Deck) Zone:Deck
>> ...))
>>
>> Does that help?
>>
>> On Saturday, March 5, 2016 at 6:58:31 PM UTC-5, JvJ wrote:
>>>
>>> I've been using Schema, and there's a kind of type definition that I'm 
>>> having trouble with.  I'm not sure exactly how to describe it, so I'll 
>>> provide an example.
>>>
>>> I'm working on a digital card game in which there are numerous zones 
>>> that a card may be in.  Each card needs to know which zone it is in, and 
>>> there may be additional information depending on the zone.
>>>
>>> For instance, if a card is in a player's hand, no additional information 
>>> is required.  However, if the card is on the board, it needs to understand 
>>> its position on the board.
>>>
>>> I have the following definition for zone types:
>>>
>>> (def Zone
>>>   "A schema for referring to the various game zones."
>>>   (s/enum :Hand
>>>   :Deck
>>>   :Board
>>>   :Field
>>>   :Discard
>>>   :Void))
>>>
>>> I want to define a different schema type for each of these, and then 
>>> define a zone spec:
>>>
>>> (def ZoneSpec {(required-key :zone-type) Zone
>>>:data >> specified earlier>
>>> })
>>>
>>> I want to ensure that whichever data is provided specified the schema 
>>> associated with the zone type.
>>>
>>> Is there a way to do this?
>>>
>>> Thanks.
>>>
>>

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

Prismatic Schema - Why is "both" deprecated?

[JvJ]

I've noticed that there is the function "both" in Schema.

Both says that it can be replaced by conditional, but I'm not sure exactly 
how to go about doing this.

Can someone provide an example?

Thanks

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

Prismatic Schema - Self-reference in schema definitions

[JvJ]

I've been using Schema, and there's a kind of type definition that I'm 
having trouble with.  I'm not sure exactly how to describe it, so I'll 
provide an example.

I'm working on a digital card game in which there are numerous zones that a 
card may be in.  Each card needs to know which zone it is in, and there may 
be additional information depending on the zone.

For instance, if a card is in a player's hand, no additional information is 
required.  However, if the card is on the board, it needs to understand its 
position on the board.

I have the following definition for zone types:

(def Zone
  "A schema for referring to the various game zones."
  (s/enum :Hand
  :Deck
  :Board
  :Field
  :Discard
  :Void))

I want to define a different schema type for each of these, and then define 
a zone spec:

(def ZoneSpec {(required-key :zone-type) Zone
   :data 
})

I want to ensure that whichever data is provided specified the schema 
associated with the zone type.

Is there a way to do this?

Thanks.

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

Prismatic Schema - Self-reference in schema definitions

[JvJ]

I've been using Schema, and there's a kind of type definition that I'm 
having trouble with.  I'm not sure exactly how to describe it, so I'll 
provide an example.

I'm working on a digital card game in which there are numerous zones that a 
card may be in.  Each card needs to know which zone it is in, and there may 
be additional information depending on the zone.

For instance, if a card is in a player's hand, no additional information is 
required.  However, if the card is on the board, it needs to understand its 
position on the board.

I have the following definition for zone types:

(def Zone
  "A schema for referring to the various game zones."
  (s/enum :Hand
  :Deck
  :Board
  :Field
  :Discard
  :Void))

I want to define a different schema type for each of these, and then define 
a zone spec:

(def ZoneSpec {(required-key :zone-type) Zone
}

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

Chaining compojure routes

[JvJ]

I'm just starting to use ring/compojure to create web apps.

One thing I would like to do is have an updatable collection of apps that 
can be accessed based on the URL input.

For example, if I have an app named "foo", then website.com/foo would 
redirect to that app.

So far, I have the following implementation:

(def route-m
  {"foo" (routes (GET "/foo" [] "Hello Foo!"))
   "bar" (routes
  (GET "/bar/baz" [] "Hello Foo!")
  (GET "/bar/quux" [] "Hello Quux!"))})

(def test-r
  (routes
   (GET "/hey"
[]
"HEY!")
   (GET "/:app*" [app]
(route-m app


The issue with this method is the fact that the "sub-routes" need to have 
the full path instead of just the sub-path.  For example, "foo" needs to 
define its routes in terms of "foo/..." instead of just "/...".

Is there any way around this?

Thanks.

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

Kicking off a process in Compojure Defroutes / http-kit runserver

[JvJ]

I'm working on a web app, and I'm using defroutes to define my application 
and runserver to initialize it.  However, when run-server is called, I 
can't find a way to run code before the app starts listening for requests.  
I'd like to start a background async process that can interact with 
incoming web requests.  Is there an easy way to do this using defroutes, or 
will I have to come up with something on my own?

Thanks

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

Check if value is a ring handler

[JvJ]

Is there a way to dynamically check whether or not a given function 
qualifies as a ring handler?

-- 
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: Emulating the Syntax quote

[JvJ]

Here's the solution I came up with:

(s/defn qualify :- s/Symbol
  "Convert a symbol to a qualified symbol.  If the
symbol does not already refer to an existing var,
default to the current namespace."
  [sym :- s/Symbol]
  (let [res (resolve sym)
ns (or (and res (-> res (meta) (:ns) (.name) (name)))
   (-> *ns* (.name) (name)))
nme (name sym)]
(symbol ns nme)))

On Wednesday, 20 January 2016 08:36:49 UTC-8, kovasb wrote:
>
> Are you looking for https://clojuredocs.org/clojure.core/resolve ?
>
>
> On Wed, Jan 20, 2016 at 3:11 AM, JvJ <kfjwh...@gmail.com > 
> wrote:
>
>> With the syntax quote, all symbols become namespace-qualified.  (I.e `a 
>> => user/a, `def=> clojure.core/def)
>>
>> Is there a way to determine how a given symbol would be qualified in the 
>> current environment, and to find out what it's implicit namespace would be?
>>
>> --
>> 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.
>>
>
>

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

Emulating the Syntax quote

[JvJ]

With the syntax quote, all symbols become namespace-qualified.  (I.e `a => 
user/a, `def=> clojure.core/def)

Is there a way to determine how a given symbol would be qualified in the 
current environment, and to find out what it's implicit namespace would be?

-- 
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: defmulti with prismatic schema

[JvJ]

I've already figured out that the dispatch function can be schematized, but 
good call on the wrapper.  I'll try that.

On Monday, 18 January 2016 00:58:19 UTC-8, Jason Wolfe wrote:
>
> You can find some context here and in the linked PRs:
>
> https://github.com/plumatic/schema/pull/119
>
> Basically, the reason we don't have defmulti is that it's difficult to 
> implement properly, and didn't seem worth the effort and maintenance cost.  
>
> The simplest workaround is to create a schematized wrapper function that 
> calls through to your `defmulti`, and make that the public API (name the 
> wrapper `foo` and your defmulti `foo*` or something).
>
> There are also two partial solutions:
>  - Schematize each defmethod individually (as you mention)
>  - Schematize the dispatch function (this can do the inputs, but not the 
> outputs)
>
> Hope this helps,
> Jason
>
>
>
>
> On Sunday, January 17, 2016 at 12:29:43 AM UTC, JvJ wrote:
>>
>> Hello,
>>
>> I understand that Prismatic Schema has a means of annotating defmethod, 
>> but what should I do about defmulti?
>>
>> Thanks
>>
>

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

Parsing complex parameter lists

[JvJ]

I'm extending def macros, and I would like to know if there is an easy way 
to handle parsing the complex parameter lists that can be passed into these 
macros.

For example, defn has a parameter list something like the following:

[name doc-string? attr-map? arg-vec pre-post-map? & body]


There are so many possible conditions here.  I feel like there should be an 
easy way to do it, but my solutions so far seem too complex.

-- 
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: Cross-platform check if value is a channel

[JvJ]

So, you can just check if #(safisfies? 
clojure.core.async.impl.protocols/Channel %)

On Monday, 18 January 2016 10:48:10 UTC-8, Alex Miller wrote:
>
> There is a ticket for this http://dev.clojure.org/jira/browse/ASYNC-126 
> and you'll notice there is actually an implementation buried inside right 
> now:
>
> clojure.core.async.impl.protocols/closed?
>
> On Sunday, January 17, 2016 at 10:53:57 PM UTC-6, JvJ wrote:
>>
>> Is there a way of checking to see if something is a channel?  Does it 
>> work in both clj and cljs?
>>
>

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

Cross-platform check if value is a channel

[JvJ]

Is there a way of checking to see if something is a channel?  Does it work 
in both clj and cljs?

-- 
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: Prismatic Schema: Defining a schema for key-value pairs

[JvJ]

That is exactly what I am looking for!

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

defmulti with prismatic schema

[JvJ]

Hello,

I understand that Prismatic Schema has a means of annotating defmethod, but 
what should I do about defmulti?

Thanks

-- 
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: Prismatic Schema: Defining a schema for key-value pairs

[JvJ]

Do you know if there's a way to identify the particular key that failed in 
the error message?

On Saturday, 16 January 2016 02:01:49 UTC-8, JvJ wrote:
>
> That is exactly what I am looking for!

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

Prismatic Schema: Defining a schema for key-value pairs

[JvJ]

I've recently started using prismatic schema, and I'm attempting to define 
a schema for a map data structure.

I understand that it is possible to use a schema to define the types of 
both keys and values in the map, like so:

(def my-map {key-schema val-schema})


However, I would like to use the schema to enforce certain relationships 
between the keys and values.  In particular, this one:

(fn [[k v]]
   (isa? (type v) k))


Is it possible to define an associative map schema that applies a predicate 
to key-value pairs rather than just keys and values separately?

Thanks

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

Expectations mode not running tests

[JvJ]

I've been attempting to use expectations and emacs expectations-mode to run 
test on namespaces.  However, when I attempt to execute tests in 
expectations mode, I get the following error message:

expectations-eval: Symbol’s function definition is void: nrepl-send-string

I'm not sure if this has something to do with my project setup, but I 
expect my emacs configuration is to blame.

Any ideas on how it may be fixed?

Thanks.

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

cljc require-macros

[JvJ]

I've been writing some cljc files lately, and importing the clj/cljs 
versions of particular libraries is becoming somewhat difficult.

I usually have to do some complicated reader-conditionals like this:


(ns my-ns
(:require #?(:clj [clojure.core.typed :as t :refer [ann defalias Int]]
:cljs [cljs.core.typed :as t :refer [Int]]))

#?@( :cljs ( (:require-macros [cljs.core.typed :as t :refer [ann 
defalias]]))
  :clj ()))


When including cross-platform libraries, I am able to refer all necessary 
symbols in a :require clause for clj files, but I need to separate macros 
from other symbols with cljs files.

Is there an easier or more straightforward way to do this with cljc files?

Thanks

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

core.typed - Can't resolve alias name

[JvJ]

Reposting from the core.typed google group.  Didn't get a response.

I'm just starting with core.typed, and I can't seem to get it to work 
properly in the REPL.

I start by defining an alias (Fhtagn), but when I later try to type-check 
it, the name "Fhtagn" is unresolved.

Am I using it wrong, or is this just a consequence of using the REPL?


guymover.game-server> (t/defalias Fhtagn (t/HMap :mandatory {:a t/Int :b t/
Str}))
nil
guymover.game-server> (t/cf {:a 1 :b ""} Fhtagn)
Type Error (C:\Users\Kaylen\AppData\Local\Temp\form-init7559705448676355576.
clj) Internal Error (:) Cannot resolve name guymover.game-server/
Fhtagn
Error

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

core.async multi-channel?

[JvJ]

Is it possible to create a core.async channel that has one input and 
simultaneously delivers the same message to multiple endpoints?

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