Re: [lein] compile sass?

[Mike Haney]

Cool, I'll give your fork a try.  I've been using lein-shell to just run sassc 
directly, but it's annoying because sassc bombs if the target folder doesn't 
exist.

-- 
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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Mikera]

core.matrix isn't that big of a dependency itself - it only gets expensive 
in/when you load the implementations (NDArray, vectorz-clj, Clatrix etc.). 
Which should be a choice of the ultimate user.

It is possible to just depend on the protocols, but I think that risks 
breakage since protocols are really just an implementation detail. Best to 
depend on the API in clojure.core.matrix (which are mostly just simple 
functions that delegate to the right protocols)

On Sunday, 28 December 2014 23:42:18 UTC+8, Jony Hudson wrote:
>
> @Chris Thanks, hope it's useful for you. I might have a play with ggvis 
> and see how it works out.
>
> @Mike Yeah, it would definitely be good to support core.matrix datasets. 
> One thing that would be nice would be to avoid the overhead of loading all 
> of core.matrix for those that don't use it. Do you think it would work to 
> just have gg4clj depend on the 'protocols' ns in core.matrix? Would be very 
> happy to take a PR if you've got time to look at it :-)
>
>
> Jony
>
> On Friday, 26 December 2014 15:36:42 UTC, Jony Hudson wrote:
>>
>> Hi all,
>>
>>  from the README:
>>
>> gg4clj is a lightweight wrapper to make it easy to use R's ggplot2 
>>> library from Clojure. It provides a straightforward way to express R code 
>>> in Clojure, including easy mapping between Clojure data and R's data.frame, 
>>> and some plumbing to send this code to R and recover the rendered graphics. 
>>> It also provides a Gorilla REPL renderer plugin to allow rendered plots to 
>>> be displayed inline in Gorilla worksheets. It is not a Clojure rewrite of 
>>> ggplot2 - it calls R, which must be installed on your system (see below), 
>>> to render the plots. You'll need to be familiar with R and ggplot2, or else 
>>> the commands will seem fairly cryptic.
>>
>>
>> Demo worksheet, showing it in action here: 
>> http://viewer.gorilla-repl.org/view.html?source=github&user=JonyEpsilon&repo=gg4clj&path=ws/demo.clj
>> Source here: https://github.com/JonyEpsilon/gg4clj
>>
>> Works better than I thought it would!
>>
>>
>> Jony
>>
>

-- 
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: Sparse matrix support for Clojure with vectorz-clj 0.28.0

[Mike Anderson]

Looks like you have some good changes in your Vectorz branch - any chance 
you could tidy up and make a PR?

I like the idea of specialised getSlices and getColumns in particular - 
these should be much faster than getting the slices one-by-one if the data 
is very sparse.

On Monday, 29 December 2014 09:43:54 UTC+8, Matt Revelle wrote:
>
>
> On Dec 28, 2014, at 7:28 PM, Mike Anderson  
> wrote:
>
> Interesting idea. The challenge is that I'm not sure how to add 
> representation specification in an implementation independent way. It's a 
> quirk of vectorz that it has both indexed and hashed storage, I probably 
> wouldn't expect any other implementations to have that. Likewise row and 
> column oriented storage are fairly obvious choices but I still wouldn't 
> expect every implementation to support both.
>
> Any idea how you would specify the API?
>
> I guess we could simply pass an optional map argument of options, but 
> behaviour would be completely implementation specific. 
>
>
> I think the map is the way to go. You’re probably correct about few other 
> implementations having as many options, but adding a map of “preferences” 
> seems like a good option. Creating a sparse matrix might then look like:
>
> ;; preferences as a separate arg
> (new-sparse-array [10 10] :vectorz {:order :row :indexed true})
>
> ;; an alternative, preferences combined with implementation selection
> (new-sparse-array [10 10] {:impl :vectorz :order :row :indexed 
> true})
>
> Implementations should throw an exception if they don’t support (or 
> understand) the preferences.
>
> On Monday, 29 December 2014 02:12:05 UTC+8, Matt Revelle wrote:
>>
>> Glad to see the addition of new-sparse-array to core.matrix. It looks 
>> like it defaults to SparseRowMatrix for the Vectorz implementation? Should 
>> the API provide a way to specify which sparse matrix representation (e.g., 
>> row- vs column-based, indexed vs hashed) should be used? I'd suggest a 
>> 3-arity new-sparse-array which takes a keyword indicating the 
>> representation to use as well as a new function which returns a list of 
>> available representations for a specific implementation.
>>
>> I think at this point you incorporated (looks like we have some 
>> duplication too, doh) all the changes I had made for sparse matrix support 
>> in Vectorz, but will verify.
>>
>
> I definitely haven't covered all the potential code paths - in particular 
> a lot of things aren't yet optimised for sparse operations. So any review / 
> patches would be appreciated!
>
>
> I did some optimization of sparse ops but the code probably needs to be 
> cleaned up before submitting (e.g., generalized and/or moved to the correct 
> level in class hierarchy). Those changes were made hastily when I needed to 
> quickly get a program running fast.
>
> A  branch containing all performance changes based on an older revision of 
> the develop branch is available here:
> https://github.com/mattrepl/vectorz/tree/sparse-speed
>
> There is a related sparse-speed branch in my forks of vectorz-clj and 
> core.matrix.
>
> We should also look into other sparse array representations for Vectorz 
> from: Matlab, MTJ (https://github.com/fommil/matrix-toolkits-java, 
> specifically the LinkedSparseMatrix for row and column ops), etc.
>
> -Matt
>
>  
>
>>
>> On Saturday, December 27, 2014 4:56:55 AM UTC-5, Mike Anderson wrote:
>>>
>>> Here is a little belated Christmas present for Clojure data aficionados:
>>>
>>> ;; setup
>>> (use 'clojure.core.matrix)
>>> (set-current-implementation :vectorz)
>>>
>>> ;; create a big sparse matrix with a trillion elements (initially zero)
>>> (def A (new-sparse-array [100 100]))
>>>
>>> ;; we are hopefully smart enough to avoid printing the whole array!
>>> A
>>> => #
>>>
>>> ;; mutable setter operations supported so that you can set individual 
>>> sparse elements
>>> (dotimes [i 1000]
>>>  (mset! A (rand-int 100) (rand-int 100) (rand-int 100)))
>>>
>>> ;; all standard core.matrix operations supported
>>> (esum A)
>>> => 50479.0
>>>
>>> ;; efficient addition
>>> (time (add A A))
>>> => "Elapsed time: 12.849859 msecs"
>>>
>>> ;; matrix multiplication / inner products actually complete in sensible 
>>> time
>>> ;; (i.e. much faster than than the usual O(n^3) which might take a few 
>>> thousand years)
>>> (time (mmul A (transpose A)))
>>> => "Elapsed time: 2673.085171 msecs"
>>>
>>>
>>> Some nice things to note about the implementation:
>>> - Everything goes through the core.matrix API, so your code won't have 
>>> to change to use sparse matrices :-)
>>> - Sparse matrices are 100% interoperable with non-sparse (dense) matrices
>>> - Sparse arrays are fully mutable. Management of storage / indexing 
>>> happens automatically
>>> - It isn't just matrices - you can have sparse vectors, N-dimensional 
>>> arrays etc.
>>> - Code is pure JVM - no native dependencies to worry about
>>>
>>> This is all still very much alpha - so any comments /

Re: ANN: Sparse matrix support for Clojure with vectorz-clj 0.28.0

[Matt Revelle]

> On Dec 28, 2014, at 7:28 PM, Mike Anderson  
> wrote:
> 
> Interesting idea. The challenge is that I'm not sure how to add 
> representation specification in an implementation independent way. It's a 
> quirk of vectorz that it has both indexed and hashed storage, I probably 
> wouldn't expect any other implementations to have that. Likewise row and 
> column oriented storage are fairly obvious choices but I still wouldn't 
> expect every implementation to support both.
> 
> Any idea how you would specify the API?
> 
> I guess we could simply pass an optional map argument of options, but 
> behaviour would be completely implementation specific. 

I think the map is the way to go. You’re probably correct about few other 
implementations having as many options, but adding a map of “preferences” seems 
like a good option. Creating a sparse matrix might then look like:

;; preferences as a separate arg
(new-sparse-array [10 10] :vectorz {:order :row :indexed true})

;; an alternative, preferences combined with implementation selection
(new-sparse-array [10 10] {:impl :vectorz :order :row :indexed true})

Implementations should throw an exception if they don’t support (or understand) 
the preferences.

> On Monday, 29 December 2014 02:12:05 UTC+8, Matt Revelle wrote:
> Glad to see the addition of new-sparse-array to core.matrix. It looks like it 
> defaults to SparseRowMatrix for the Vectorz implementation? Should the API 
> provide a way to specify which sparse matrix representation (e.g., row- vs 
> column-based, indexed vs hashed) should be used? I'd suggest a 3-arity 
> new-sparse-array which takes a keyword indicating the representation to use 
> as well as a new function which returns a list of available representations 
> for a specific implementation.
> 
> I think at this point you incorporated (looks like we have some duplication 
> too, doh) all the changes I had made for sparse matrix support in Vectorz, 
> but will verify.
> 
> I definitely haven't covered all the potential code paths - in particular a 
> lot of things aren't yet optimised for sparse operations. So any review / 
> patches would be appreciated!

I did some optimization of sparse ops but the code probably needs to be cleaned 
up before submitting (e.g., generalized and/or moved to the correct level in 
class hierarchy). Those changes were made hastily when I needed to quickly get 
a program running fast.

A  branch containing all performance changes based on an older revision of the 
develop branch is available here:
https://github.com/mattrepl/vectorz/tree/sparse-speed

There is a related sparse-speed branch in my forks of vectorz-clj and 
core.matrix.

We should also look into other sparse array representations for Vectorz from: 
Matlab, MTJ (https://github.com/fommil/matrix-toolkits-java 
, specifically the 
LinkedSparseMatrix for row and column ops), etc.

-Matt

>  
> 
> On Saturday, December 27, 2014 4:56:55 AM UTC-5, Mike Anderson wrote:
> Here is a little belated Christmas present for Clojure data aficionados:
> 
> ;; setup
> (use 'clojure.core.matrix)
> (set-current-implementation :vectorz)
> 
> ;; create a big sparse matrix with a trillion elements (initially zero)
> (def A (new-sparse-array [100 100]))
> 
> ;; we are hopefully smart enough to avoid printing the whole array!
> A
> => #
> 
> ;; mutable setter operations supported so that you can set individual sparse 
> elements
> (dotimes [i 1000]
>  (mset! A (rand-int 100) (rand-int 100) (rand-int 100)))
> 
> ;; all standard core.matrix operations supported
> (esum A)
> => 50479.0
> 
> ;; efficient addition
> (time (add A A))
> => "Elapsed time: 12.849859 msecs"
> 
> ;; matrix multiplication / inner products actually complete in sensible time
> ;; (i.e. much faster than than the usual O(n^3) which might take a few 
> thousand years)
> (time (mmul A (transpose A)))
> => "Elapsed time: 2673.085171 msecs"
> 
> 
> Some nice things to note about the implementation:
> - Everything goes through the core.matrix API, so your code won't have to 
> change to use sparse matrices :-)
> - Sparse matrices are 100% interoperable with non-sparse (dense) matrices
> - Sparse arrays are fully mutable. Management of storage / indexing happens 
> automatically
> - It isn't just matrices - you can have sparse vectors, N-dimensional arrays 
> etc.
> - Code is pure JVM - no native dependencies to worry about
> 
> This is all still very much alpha - so any comments / patches / more rigorous 
> testing much appreciated!
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Numerical Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/numerical-clojure/LLpq4WHx-k8/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email

Re: ANN: Sparse matrix support for Clojure with vectorz-clj 0.28.0

[Mike Anderson]

Interesting idea. The challenge is that I'm not sure how to add 
representation specification in an implementation independent way. It's a 
quirk of vectorz that it has both indexed and hashed storage, I probably 
wouldn't expect any other implementations to have that. Likewise row and 
column oriented storage are fairly obvious choices but I still wouldn't 
expect every implementation to support both.

Any idea how you would specify the API?

I guess we could simply pass an optional map argument of options, but 
behaviour would be completely implementation specific. 

On Monday, 29 December 2014 02:12:05 UTC+8, Matt Revelle wrote:
>
> Glad to see the addition of new-sparse-array to core.matrix. It looks like 
> it defaults to SparseRowMatrix for the Vectorz implementation? Should the 
> API provide a way to specify which sparse matrix representation (e.g., row- 
> vs column-based, indexed vs hashed) should be used? I'd suggest a 3-arity 
> new-sparse-array which takes a keyword indicating the representation to use 
> as well as a new function which returns a list of available representations 
> for a specific implementation.
>
> I think at this point you incorporated (looks like we have some 
> duplication too, doh) all the changes I had made for sparse matrix support 
> in Vectorz, but will verify.
>

I definitely haven't covered all the potential code paths - in particular a 
lot of things aren't yet optimised for sparse operations. So any review / 
patches would be appreciated!
 

>
> On Saturday, December 27, 2014 4:56:55 AM UTC-5, Mike Anderson wrote:
>>
>> Here is a little belated Christmas present for Clojure data aficionados:
>>
>> ;; setup
>> (use 'clojure.core.matrix)
>> (set-current-implementation :vectorz)
>>
>> ;; create a big sparse matrix with a trillion elements (initially zero)
>> (def A (new-sparse-array [100 100]))
>>
>> ;; we are hopefully smart enough to avoid printing the whole array!
>> A
>> => #
>>
>> ;; mutable setter operations supported so that you can set individual 
>> sparse elements
>> (dotimes [i 1000]
>>  (mset! A (rand-int 100) (rand-int 100) (rand-int 100)))
>>
>> ;; all standard core.matrix operations supported
>> (esum A)
>> => 50479.0
>>
>> ;; efficient addition
>> (time (add A A))
>> => "Elapsed time: 12.849859 msecs"
>>
>> ;; matrix multiplication / inner products actually complete in sensible 
>> time
>> ;; (i.e. much faster than than the usual O(n^3) which might take a few 
>> thousand years)
>> (time (mmul A (transpose A)))
>> => "Elapsed time: 2673.085171 msecs"
>>
>>
>> Some nice things to note about the implementation:
>> - Everything goes through the core.matrix API, so your code won't have to 
>> change to use sparse matrices :-)
>> - Sparse matrices are 100% interoperable with non-sparse (dense) matrices
>> - Sparse arrays are fully mutable. Management of storage / indexing 
>> happens automatically
>> - It isn't just matrices - you can have sparse vectors, N-dimensional 
>> arrays etc.
>> - Code is pure JVM - no native dependencies to worry about
>>
>> This is all still very much alpha - so any comments / patches / more 
>> rigorous testing much appreciated!
>>
>>
>>
>>

-- 
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: Class Loader Issue - Using Clojure for Annotation Processing

[Frankie Sardo]

Apologies for resurrecting the thread but I wanted to add a link to a 
minimalistic example that reproduces the issue, if anybody comes across it:

https://github.com/frankiesardo/annotation-processing

On Friday, December 12, 2014 7:46:07 PM UTC, Frankie Sardo wrote:
>
> Hi all,
> I'd like to use Clojure for processing Java annotations at compile time. 
> (Particularly useful for Android)
>
> https://github.com/frankiesardo/icepick/blob/clojure/src/icepick/core.clj
>
> I'm extending javax.annotation.processing.AbstractProcessor, I can create 
> the generated class, I can test it fine. Everything works well. 
> But when I'm actually using it by packaging the jar with META-INF/services 
> the compiler throws an ExceptionInInitializerError.
>
> I've been reading about the issues with Clojure and ServiceLoader 
> http://blog.mattiasholmqvist.se/?p=631 but it's not clear to me how I can 
> make the java compiler initialise my generated class right. I tried forcing 
> the context class loader to false 
>
> (alter-var-root #'*use-context-classloader* (constantly false)) 
>
> as some discussion here mentioned it 
> https://groups.google.com/forum/#!topic/clojure/gRhD0HOwFGc but it 
> doesn't seem to do anything.
>
> I found it very natural to write annotation processing with Clojure and it 
> would be a shame giving up. I lack the knowledge to tackle this problem 
> deep down and I wonder if you guys have any wisdom to share?
>
> Cheers
> Frankie
>
>
>

-- 
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: Sparse matrix support for Clojure with vectorz-clj 0.28.0

[Matt Revelle]

Glad to see the addition of new-sparse-array to core.matrix. It looks like 
it defaults to SparseRowMatrix for the Vectorz implementation? Should the 
API provide a way to specify which sparse matrix representation (e.g., row- 
vs column-based, indexed vs hashed) should be used? I'd suggest a 3-arity 
new-sparse-array which takes a keyword indicating the representation to use 
as well as a new function which returns a list of available representations 
for a specific implementation.

I think at this point you incorporated (looks like we have some duplication 
too, doh) all the changes I had made for sparse matrix support in Vectorz, 
but will verify.

On Saturday, December 27, 2014 4:56:55 AM UTC-5, Mike Anderson wrote:
>
> Here is a little belated Christmas present for Clojure data aficionados:
>
> ;; setup
> (use 'clojure.core.matrix)
> (set-current-implementation :vectorz)
>
> ;; create a big sparse matrix with a trillion elements (initially zero)
> (def A (new-sparse-array [100 100]))
>
> ;; we are hopefully smart enough to avoid printing the whole array!
> A
> => #
>
> ;; mutable setter operations supported so that you can set individual 
> sparse elements
> (dotimes [i 1000]
>  (mset! A (rand-int 100) (rand-int 100) (rand-int 100)))
>
> ;; all standard core.matrix operations supported
> (esum A)
> => 50479.0
>
> ;; efficient addition
> (time (add A A))
> => "Elapsed time: 12.849859 msecs"
>
> ;; matrix multiplication / inner products actually complete in sensible 
> time
> ;; (i.e. much faster than than the usual O(n^3) which might take a few 
> thousand years)
> (time (mmul A (transpose A)))
> => "Elapsed time: 2673.085171 msecs"
>
>
> Some nice things to note about the implementation:
> - Everything goes through the core.matrix API, so your code won't have to 
> change to use sparse matrices :-)
> - Sparse matrices are 100% interoperable with non-sparse (dense) matrices
> - Sparse arrays are fully mutable. Management of storage / indexing 
> happens automatically
> - It isn't just matrices - you can have sparse vectors, N-dimensional 
> arrays etc.
> - Code is pure JVM - no native dependencies to worry about
>
> This is all still very much alpha - so any comments / patches / more 
> rigorous testing much appreciated!
>
>
>
>

-- 
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 write tests fro vertx and Clojure

[rogergl]

Maybe it is a better solution to put the code I wan't to test outside the 
vertices and just leave the basic eventbus setup insides the vertices ?

Regards
 Rpger


-- 
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 do you name your protocols?

[Jozef Wagner]

I was not implying anything about what Rich have said. While the SPI term 
may be used in the 'enterprise' field too much (and in an unnecessary 
complicated manner), I think it has perfectly valid uses in Clojure. The 
API tells you what a function or a macro does for you, but SPI tells you 
what you have to do in order to integrate with existing functionalities.

BTW I think protocol methods should be in SPI too. (Stuart's components 
library made IMO a bit unfortunate decision to expose 'start' and 'stop' 
protocol methods directly) See 
http://kotka.de/blog/2011/07/Separation_of_concerns.html 
for a related write-up.

Jozef

On Sunday, December 28, 2014 4:18:47 PM UTC+1, adrian...@mail.yu.edu wrote:
>
> You're overlooking the fact that a "service provider interface" is simply 
> enterprise design pattern jargon for a subset of public APIs that expose 
> the underlying interfaces of the library to consumers. Saying that Rich is 
> saying protocols should "never ever" be part of the public API is both 
> misleading and false. 
>
> On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote:
>>
>> Protocols should never ever be part of public API. Protocols can be part 
>> of the SPI, if custom extensions are to be supported. Otherwise they are an 
>> implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968
>>
>> Jozef
>>
>> On Sun, Dec 28, 2014 at 8:11 AM, Mikera  wrote:
>>
>>> That depends if the protocols are part of your user-facing API or not - 
>>> a lot of the time I find that protocols are best hidden as implementation 
>>> details rather than exposed to users.
>>>
>>> In core.matrix, for example, users never see the protocols directly: 
>>> only implementers of new matrix libraries need to care
>>>
>>> On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:

 Changing old protocol names should trigger a major revision change in 
 the minimum because it breaks backwards compatibility. 

 --Ashton 

 Sent from my iPhone 

 > On Dec 27, 2014, at 11:18 AM, Michael Klishin  
 wrote: 
 > 
 >> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) 
 wrote: 
 >> clj-time seems to be naming protocols inconsistently. It uses   
 >> ISomething, Something and SomethingProtocol naming. 
 > 
 > I suspect it is because it has 60 contributors and most users never 
 have to 
 > extend the protocols. 
 > 
 > Feel free to submit a PR that standardises all names on Something. 
 > --   
 > @michaelklishin, github.com/michaelklishin 
 > 
 > -- 
 > 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: How to write tests fro vertx and Clojure

[rogergl]

I think I'm getting close. The eventbus_test.clj 

 runs 
and I changed my test to:

(deftest eb-send
  (core/deploy-verticle "/project/vertices/time.clj")
  (let [addr const/topic-time
id (atom nil)]
(reset! id
(eb/on-message
  addr
  (fn [m]
(t/test-complete
  (is true)
  (eb/unregister-handler @id)
(is (not (nil? @id)

But I get:

ERROR in (eb-send) (core.clj:70)
Uncaught exception, not in assertion.
expected: nil
  actual: org.vertx.java.core.VertxException: No container instance 
available. If embedded, see vertx.platform.
 at vertx.core$get_container.invoke (core.clj:70)

It seems as if  (core/deploy-verticle "/project/vertices/time.clj") is the 
problem. 

Regards
  Roger

-- 
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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Jony Hudson]

@Chris Thanks, hope it's useful for you. I might have a play with ggvis and 
see how it works out.

@Mike Yeah, it would definitely be good to support core.matrix datasets. 
One thing that would be nice would be to avoid the overhead of loading all 
of core.matrix for those that don't use it. Do you think it would work to 
just have gg4clj depend on the 'protocols' ns in core.matrix? Would be very 
happy to take a PR if you've got time to look at it :-)


Jony

On Friday, 26 December 2014 15:36:42 UTC, Jony Hudson wrote:
>
> Hi all,
>
>  from the README:
>
> gg4clj is a lightweight wrapper to make it easy to use R's ggplot2 library 
>> from Clojure. It provides a straightforward way to express R code in 
>> Clojure, including easy mapping between Clojure data and R's data.frame, 
>> and some plumbing to send this code to R and recover the rendered graphics. 
>> It also provides a Gorilla REPL renderer plugin to allow rendered plots to 
>> be displayed inline in Gorilla worksheets. It is not a Clojure rewrite of 
>> ggplot2 - it calls R, which must be installed on your system (see below), 
>> to render the plots. You'll need to be familiar with R and ggplot2, or else 
>> the commands will seem fairly cryptic.
>
>
> Demo worksheet, showing it in action here: 
> http://viewer.gorilla-repl.org/view.html?source=github&user=JonyEpsilon&repo=gg4clj&path=ws/demo.clj
> Source here: https://github.com/JonyEpsilon/gg4clj
>
> Works better than I thought it would!
>
>
> Jony
>

-- 
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 write tests fro vertx and Clojure

[Toby Crawley]

On Sun, Dec 28, 2014 at 9:52 AM, rogergl  wrote:
> it seems as if there is a test package for vertx and Clojure
> (vertx.testools)
>
> Since I would like to test my vertices I tried this simple approach:
>
> (tt/as-embedded (fn []
> (core/deploy-verticle "project/vertices/time.clj")
>  (tt/test-complete*)))

The above code will cause the test to exit immediately, before the
verticle finishes deploying. You probably want to call test-complete*
from an on-message handler listening to const/topic-time. See
https://github.com/vert-x/mod-lang-clojure/blob/master/api/src/test/clojure/vertx/eventbus_test.clj
for examples of this technique.

If that doesn't make sense or you are still having issues, feel free
to open an issue on https://github.com/vert-x/mod-lang-clojure/ and
we'll see if we can get you fixed up.

>
> But this gives me a timeout.
>
> BTW: The vertice is really simple:
>
> (core/periodic 1000
>(let [now (h/now)]
>  (eb/publish const/topic-time (h/to-transit {:date-time
> now}
>
>
> The question is: Is it possible to tests vertices that use the eventbus ?
> And if it is possible how it is done ?
>

-- 
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 do you name your protocols?

[adrian . medina]

You're overlooking the fact that a "service provider interface" is simply 
enterprise design pattern jargon for a subset of public APIs that expose 
the underlying interfaces of the library to consumers. Saying that Rich is 
saying protocols should "never ever" be part of the public API is both 
misleading and false. 

On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote:
>
> Protocols should never ever be part of public API. Protocols can be part 
> of the SPI, if custom extensions are to be supported. Otherwise they are an 
> implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968
>
> Jozef
>
> On Sun, Dec 28, 2014 at 8:11 AM, Mikera  > wrote:
>
>> That depends if the protocols are part of your user-facing API or not - a 
>> lot of the time I find that protocols are best hidden as implementation 
>> details rather than exposed to users.
>>
>> In core.matrix, for example, users never see the protocols directly: only 
>> implementers of new matrix libraries need to care
>>
>> On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:
>>>
>>> Changing old protocol names should trigger a major revision change in 
>>> the minimum because it breaks backwards compatibility. 
>>>
>>> --Ashton 
>>>
>>> Sent from my iPhone 
>>>
>>> > On Dec 27, 2014, at 11:18 AM, Michael Klishin  
>>> wrote: 
>>> > 
>>> >> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) 
>>> wrote: 
>>> >> clj-time seems to be naming protocols inconsistently. It uses   
>>> >> ISomething, Something and SomethingProtocol naming. 
>>> > 
>>> > I suspect it is because it has 60 contributors and most users never 
>>> have to 
>>> > extend the protocols. 
>>> > 
>>> > Feel free to submit a PR that standardises all names on Something. 
>>> > --   
>>> > @michaelklishin, github.com/michaelklishin 
>>> > 
>>> > -- 
>>> > 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.

How to write tests fro vertx and Clojure

[rogergl]

Hi,

it seems as if there is a test package for vertx and Clojure 
(vertx.testools)

Since I would like to test my vertices I tried this simple approach:

(tt/as-embedded (fn []
(core/deploy-verticle "project/vertices/time.clj")
 (tt/test-complete*)))

But this gives me a timeout. 

BTW: The vertice is really simple:

(core/periodic 1000
   (let [now (h/now)]
 (eb/publish const/topic-time (h/to-transit {:date-time 
now}


The question is: Is it possible to tests vertices that use the eventbus ? 
And if it is possible how it is done ?

Regards
  Roger

-- 
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 get a list of changes in Datomic

[rogergl]

Thanks,

that helped a lot.

Regards
  Roger


>>

-- 
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: Sparse matrix support for Clojure with vectorz-clj 0.28.0

[Mars0i]

This is cool.  Kind of makes me wish my sparse matrices were larger than 
300x300.  I'll experiment with it anyway.

On Saturday, December 27, 2014 4:56:55 AM UTC-5, Mike Anderson wrote:
>
> Here is a little belated Christmas present for Clojure data aficionados:
>
> ;; setup
> (use 'clojure.core.matrix)
> (set-current-implementation :vectorz)
>
> ;; create a big sparse matrix with a trillion elements (initially zero)
> (def A (new-sparse-array [100 100]))
>
> ;; we are hopefully smart enough to avoid printing the whole array!
> A
> => #
>
> ;; mutable setter operations supported so that you can set individual 
> sparse elements
> (dotimes [i 1000]
>  (mset! A (rand-int 100) (rand-int 100) (rand-int 100)))
>
> ;; all standard core.matrix operations supported
> (esum A)
> => 50479.0
>
> ;; efficient addition
> (time (add A A))
> => "Elapsed time: 12.849859 msecs"
>
> ;; matrix multiplication / inner products actually complete in sensible 
> time
> ;; (i.e. much faster than than the usual O(n^3) which might take a few 
> thousand years)
> (time (mmul A (transpose A)))
> => "Elapsed time: 2673.085171 msecs"
>
>
> Some nice things to note about the implementation:
> - Everything goes through the core.matrix API, so your code won't have to 
> change to use sparse matrices :-)
> - Sparse matrices are 100% interoperable with non-sparse (dense) matrices
> - Sparse arrays are fully mutable. Management of storage / indexing 
> happens automatically
> - It isn't just matrices - you can have sparse vectors, N-dimensional 
> arrays etc.
> - Code is pure JVM - no native dependencies to worry about
>
> This is all still very much alpha - so any comments / patches / more 
> rigorous testing much appreciated!
>
>
>
>

-- 
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 get a list of changes in Datomic

[Tj Gabbour]

Hi!

If I understand correctly... consider something like the following:

(let [log (d/log (db/conn))
  my-tx 123456789123456]
  (->> (d/tx-range log my-tx (inc my-tx))
   seq
   pprint))

You get a bunch of datoms and transaction ID.

You can access a datom's fields with: :e :a :v :tx :added.

At first, the datoms look depressing because attributes look like 74 instead 
of :mouse/name. So use(d/ident db 74) to get :mouse/name. (You might like 
to make a little util which turns these datoms into a nice map or record. 
Records are nice because they seem to print fields in the :e :a :v :tx 
:added order you declare.)

FWIW, you may see two datoms where the entities are the same, but :added is 
different. That's because you changed something; the entity's old value was 
retracted and the new value was added.

Hope this helps,

 Tj



On Saturday, December 27, 2014 7:57:51 PM UTC+1, rogergl wrote:
>
> I would like to replay all changes since a specific timestamp.  It seems 
> as if I can get all transactions with 
>
> (q '[:find ?t :where 
>  [_ :db/txInstant ?t]
>  ] (db conn))
>
> Using as-of would allow me to replay the state at a given point in time. 
> But that would replay the complete state and not just the changes.
>
> Is it possbile to get just the changes for a specific transaction ?
>
> I tried 
>
>   (q '[:find ?c ?n  :where 
>  [?tx :db/txInstant g]
>  [?c :db/txInstant ?n ?tx]] (db conn))
>
> to test if I can get back a result for a specific transaction. That did 
> not work although 
> 
>  g 
> was a value from the first query.
>
> Regards
>   Roger
>
>

-- 
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 do you name your protocols?

[Mikera]

I tend to agree.

However it is worth noting that there are some libraries in the Clojure 
ecosystem e.g. Om and stuartsierra/component that do expect users to 
interact directly with protocols as part of the public API. So this doesn't 
seem to be yet adopted as a universal rule.

On Sunday, 28 December 2014 15:50:06 UTC+8, Jozef Wagner wrote:
>
> Protocols should never ever be part of public API. Protocols can be part 
> of the SPI, if custom extensions are to be supported. Otherwise they are an 
> implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968
>
> Jozef
>
> On Sun, Dec 28, 2014 at 8:11 AM, Mikera  > wrote:
>
>> That depends if the protocols are part of your user-facing API or not - a 
>> lot of the time I find that protocols are best hidden as implementation 
>> details rather than exposed to users.
>>
>> In core.matrix, for example, users never see the protocols directly: only 
>> implementers of new matrix libraries need to care
>>
>> On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:
>>>
>>> Changing old protocol names should trigger a major revision change in 
>>> the minimum because it breaks backwards compatibility. 
>>>
>>> --Ashton 
>>>
>>> Sent from my iPhone 
>>>
>>> > On Dec 27, 2014, at 11:18 AM, Michael Klishin  
>>> wrote: 
>>> > 
>>> >> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) 
>>> wrote: 
>>> >> clj-time seems to be naming protocols inconsistently. It uses   
>>> >> ISomething, Something and SomethingProtocol naming. 
>>> > 
>>> > I suspect it is because it has 60 contributors and most users never 
>>> have to 
>>> > extend the protocols. 
>>> > 
>>> > Feel free to submit a PR that standardises all names on Something. 
>>> > --   
>>> > @michaelklishin, github.com/michaelklishin 
>>> > 
>>> > -- 
>>> > 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.