[ANN] "Real" air traffic control system: 3D view from the cockpit of any aircraft during flights.

[ru]

Hi,

 "Real" air traffic control system - client-server ClojureScript-Clojure 
application based on:

1. *rete4frames* expert system shell (http://github.com/rururu/rete4frames/
),
2. *Flightradar24*  web service (http://www.flightradar24.com/), 
2. *Leaflet* JavaScript GIS libraty (http://leafletjs.com/), 
3. *Cesium* webGL virtual globe and map engine (http://cesiumjs.org/)
4.. *httpkit, compojure, core.async* and others Clojure libraries. 

This example is in the repository https://github.com/rururu/rete4flights.

New functionality: You have 3D view from the cockpit of any aircraft during 
flights.

Enjoy!

Sincerely,
  Ru

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

[ANN] Inlein 0.1.0

[Jean Niklas L'orange]

Hi all Clojurians,

Alex Miller did some research 
 on slow 
boot times with Clojure/scripting in
Clojure not too long ago.

What I found weird was that there were no tool for doing Clojure scripting. 
It's
possible to do this with both Leiningen and Boot, but neither were 
originally
designed for scripts nor fast startup times. I have personally found this a 
bit
annoying in the past, as I have had good reasons to use Clojure for 
scripting.

Therefore, I have created a new tool called Inlein . You 
can think of it as a
Leiningen for scripts, where the project.clj is inlined into the script 
itself.
Inlein itself starts up very fast, so the startup time of a script is more 
or
less only the time it takes to start Clojure and the dependencies you drag 
in.

You could probably use this for a lot of things. The first thing that comes 
to
mind is obviously long-running scripts and CLI programs, but it could also 
be
used for customised REPLs, independent of Boot and Leiningen.

There are probably many uses for Inlein that I haven't thought of yet, but 
if
you want inspiration, you can have a look in the examples directory 
.

Inlein is located over at https://github.com/hyPiRion/inlein and the 0.1.0
version can be downloaded from
https://github.com/hyPiRion/inlein/releases/0.1.0/

To get started, you can take a look over at the Getting Started page 
 on the
wiki.

-- Jean Niklas

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

New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Dragan Djuric]

I am soon going to release a new version of Neanderthal.

I reinstalled ATLAS, so I decided to also update benchmarks with threaded 
ATLAS bindings.

The results are still the same for doubles on one core: 10x faster than 
Vectorz and 2x faster than JBlas.

The page now covers some more cases: multicore ATLAS (on my 4-core 
i7-4790k) and floats. Neanderthal is 60 times faster with multi-threaded 
ATLAS and floats than Vectorz (core.matrix).

For the rest of the results, please follow the link. This will work with 
older versions of Neanderthal.

https://www.reddit.com/r/Clojure/comments/4a8o9n/new_matrix_multiplication_benchmarks_neanderthal/
http://neanderthal.uncomplicate.org/articles/benchmarks.html

-- 
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 am wondering if there is a better way to validate and read-in clojure data?

[Gary Verhaegen]

First off, unless you have a very good reason not to, you know the
differences, and you know what you are doing, always use the "read"
functions from clojure.edn rather than from clojure.core.

When you say "bad data", is it malformed (as in not valid EDN) or is it not
conforming to the expected schema? If the former, you can either rely on
the error reporting of clojure.edn/read-string, or (if you only need to
parse a very limited subset of EDN) write your own parser that reports
errors in a more suitable way for your use-case. Should you decide to go
that way, you may want to look into instaparse. I would advise against
going that way, though, but it's hard to know with the level of details you
have provided about what tou are actually trying to achieve.

If you get valid EDN but not the expected content, there are plenty of
"validation" libraries that may be used for the task; two that directly
come to mind are prismatic schema and validateur (slightly different
use-cases, but, again, you have not really explained what you are trying to
accomplish).

If it is well formed and follows the expected schema, I am not sure how you
can detect that it is not right. Maybe more unit tests?

On Saturday, 12 March 2016, john  wrote:

> I am producing clojure data with XSLT. At first I embraced the result in
> a vector of vectors so that a single (read-string) would read the whole
> structure in one take.
> Unfortunately when the XSLT sheet produces bad data I don't see easily
> what is going wrong.
>
> So is there an alternative for read-string?
>
> This is the code I am using right now. Instead of XSLT outputting a vector
> of vectors I output vectors separated by "@@@"
> -  Code ---
> ;; dependency [clojure-saxon "0.9.4"]
>
> (def xsl-sheet (xml/compile-xslt (java.io.File. "sheet.xsl")))
>
> (defn convert->transactions[[meta-params xml]]
>   (.toString (xsl-sheet (xml/compile-xml xml) meta-params)))
>
> (defn read-in [the-str]
>   (try (map
> #(try (read-string %1)
>   (catch Exception e
> (println "read-in Error:" (.getMessage e)
>  " token: " %1
>  " token-pos" %2
>  )))
>   (str/split the-str #"@@@") (range 10
>
>
> -  Code ---
>
>
> Is there a more elegant way to read-in and get nice errors ?
>
> Many Greetings
>
> John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Including debugging information for Clojure code

[James Norton]

I have been experimenting with using the Java Debug Interface (JDI) with 
Clojure, but I am confused about how to get Clojure to include debugging 
information when compiling to Java byte code. I have created NREPL 
middleware that is able to attach to the VM using com.sun.jdi.Bootstrap and 
listen for `set-breakpoint` operations, but it fails with 
a com.sun.jdi.AbsentInformationException when I try to call .sourceNames on 
a reference type (obtained by calling .allClasses on the VM). In the Java 
world this exception indicates that the -g option was not passed to javac - 
I don't know what the equivalent is in the Clojure world.

I hope the explanation of what I'm trying to do makes sense here. I'm out 
of my depth so I may be completely off on how things work, but I know there 
must be some way to get the debugging information included based on the 
fact that Cursive and CIDER seem to work. If anyone could explain or point 
me to an explanation I would be very grateful.

Thanks,

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.

Re: [ANN] Inlein 0.1.0

[Sunil S Nandihalli]

Thanks Jean for this. A quick comparison to lein-exec
 shows that your stuff is very
similar to lein-exec but probably much simpler to use with much faster
startup times.  I tried it.

Thanks again.

Sunil.

On Sun, Mar 13, 2016 at 7:39 PM, Jean Niklas L'orange  wrote:

> Hi all Clojurians,
>
> Alex Miller did some research
>  on
> slow boot times with Clojure/scripting in
> Clojure not too long ago.
>
> What I found weird was that there were no tool for doing Clojure
> scripting. It's
> possible to do this with both Leiningen and Boot, but neither were
> originally
> designed for scripts nor fast startup times. I have personally found this
> a bit
> annoying in the past, as I have had good reasons to use Clojure for
> scripting.
>
> Therefore, I have created a new tool called Inlein .
> You can think of it as a
> Leiningen for scripts, where the project.clj is inlined into the script
> itself.
> Inlein itself starts up very fast, so the startup time of a script is more
> or
> less only the time it takes to start Clojure and the dependencies you drag
> in.
>
> You could probably use this for a lot of things. The first thing that
> comes to
> mind is obviously long-running scripts and CLI programs, but it could also
> be
> used for customised REPLs, independent of Boot and Leiningen.
>
> There are probably many uses for Inlein that I haven't thought of yet, but
> if
> you want inspiration, you can have a look in the examples directory
> .
>
> Inlein is located over at https://github.com/hyPiRion/inlein and the 0.1.0
> version can be downloaded from
> https://github.com/hyPiRion/inlein/releases/0.1.0/
>
> To get started, you can take a look over at the Getting Started page
>  on the
> wiki.
>
> -- Jean Niklas
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: New Clojars feature: atomic deploys

[Andrey Antukh]

Nice work!

I don't know if this is a side effect of that feature but I found that
deploying snapshot seems broken.

After deploying a snapshot, I try to use it from an other package and I get
the following error:

Could not find artifact funcool:httpurr:jar:0.5.0-20160313.*195427-3* in
clojars (https://clojars.org/repo/)
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment
variable.

Navigating (using the browser) we can found that under
https://clojars.org/repo/funcool/httpurr/0.5.0-SNAPSHOT/ we have

httpurr-0.5.0-20160313.*195434*-3.jar13-Mar-2016 19:54
httpurr-0.5.0-20160313.195434-3.jar.md513-Mar-2016 19:54
httpurr-0.5.0-20160313.195434-3.jar.sha1   13-Mar-2016 19:54
httpurr-0.5.0-20160313.195434-3.pom13-Mar-2016 19:54
httpurr-0.5.0-20160313.195434-3.pom.md513-Mar-2016 19:54
httpurr-0.5.0-20160313.195434-3.pom.sha1   13-Mar-2016 19:54

So, the snapshot is successfully uploaded but for some reason, leiningen
tries to download a wrong file.

I don't know if this is something wrong from my side but I have changed
nothing for a while.

On Tue, Mar 8, 2016 at 5:29 PM, Ning Sun  wrote:

> Thanks! This is a great feature and especially important for users with
> a poor network connection.
>
> On 03/08/2016 10:43 PM, Mayank Jain wrote:
> > Thank you so much for this! I've personally faced this issue before. So
> > I know how helpful this change is. Great job! :)
> >
> > On Mar 8, 2016 7:39 PM, "Toby Crawley"  > <mailto:t...@tcrawley.org>> wrote:
> >
> > We just pushed a new release of Clojars that includes a new
> > implementation of our internal deploy logic. The big change there is
> > deployments are now atomic - if the deployment fails (due to a
> network
> > interruption/corruption or invalid artifacts), then we no longer
> write
> > it to the repository.
> >
> > We verify the deployment by applying a set of validations (see
> > https://github.com/clojars/clojars-web/wiki/Pushing#validations)
> after
> > all of the artifacts have been uploaded, but before we send back a
> > response to the final PUT. This allows us to return a (hopefully
> > helpful) error message if any of the validations fail.
> >
> > >From a user perspective, deployment should behave the same for the
> > most part - the only thing that would be different is we now validate
> > after all of the artifacts are uploaded instead of applying some
> > validations for each artifact. This means that if you try to redeploy
> > a non-SNAPSHOT version, for example, it used to fail on the first
> > artifact, but will now fail after the /last/ artifact has been
> > uploaded.
> >
> > As part of this change, we repaired any invalid non-SNAPSHOT
> > maven-metadata.xml files that had resulted from partial deploys
> > (likely from network interruptions) in the past.
> >
> > Since this is a big internal change, please let us know if you see
> any
> > issues or oddness with deployment. You can file an issue
> > (https://github.com/clojars/clojars-web/issues), or find us in
> > #clojars on either the Clojurians slack or Freenode.
> >
> > - Toby
> >
> > --
> > 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
> > <mailto: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
> > <mailto:clojure%2bunsubscr...@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
> > <mailto:clojure%2bunsubscr...@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 - p

Re: New Clojars feature: atomic deploys

[Toby Crawley]

On Sun, Mar 13, 2016 at 4:06 PM, Andrey Antukh  wrote:
> Nice work!

Thanks!

>
> I don't know if this is a side effect of that feature but I found that
> deploying snapshot seems broken.
>
> After deploying a snapshot, I try to use it from an other package and I get
> the following error:
>
> Could not find artifact funcool:httpurr:jar:0.5.0-20160313.195427-3 in
> clojars (https://clojars.org/repo/)
> This could be due to a typo in :dependencies or network issues.
> If you are behind a proxy, try setting the 'http_proxy' environment
> variable.
>

Would you mind opening an issue for this
(https://github.com/clojars/clojars-web/issues) with answers for the
following:

How are you specifying the dependency in the other package? As
"0.5.0-SNAPSHOT" or "0.5.0-20160313.195427-3"?

"0.5.0-20160313.195427-3" doesn't appear in
https://clojars.org/repo/funcool/httpurr/0.5.0-SNAPSHOT/maven-metadata.xml,
so I'm not sure where lein is getting it from. Can you provide the
contents of 
~/.m2/repository/funcool/httpurr/0.5.0-SNAPSHOT/maven-metadata-clojars.xml
and maven-metadata-local.xml?

- Toby

-- 
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 am wondering if there is a better way to validate and read-in clojure data?

[Matching Socks]

Writing text with XSLT is a delicate matter at best, and XSLT certainly 
does not help with notational guarantees as it does when writing XML.  You 
might find it a better use of the respective strengths of the tools, for 
the XSLT to emit simple XML and the Clojure program to read it into data 
structures with clojure.xml/parse. Those structures in turn could then be 
translated to whatever you like via map or zipper functions, or plain 
loops.  

By the way, you might be able to avoid serializing this intermediate XML as 
text and re-parsing that very same text.  The JAXP Transformer can send 
output to a SAXResult, and clojure.xml/parse exposes a SAX ContentHandler.  
Wiring it up could be a challenge, but in effect the Transformer would 
populate the Clojure persistent data structures.

-- 
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 Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Mikera]

It would be great if Neanderthal simply implemented the core.matrix 
protocols, then people could use it as a core.matrix implementation for 
situations where it makes sense. I really think it is an architectural 
dead-end for Neanderthal to develop a separate API. You'll simply get less 
users for Neanderthal and fragment the Clojure library ecosystem which 
doesn't help anyone.

In the absence of that, we'll just need to develop separate BLAS 
implementations for core.matrix. 

Would be great if you could implement the core.matrix protocols and solve 
this issue. It really isn't much work, I'd even be happy to do it myself if 
Neanderthal worked on Windows (last time I tried it doesn't).

On Sunday, 13 March 2016 23:34:23 UTC+8, Dragan Djuric wrote:
>
> I am soon going to release a new version of Neanderthal.
>
> I reinstalled ATLAS, so I decided to also update benchmarks with threaded 
> ATLAS bindings.
>
> The results are still the same for doubles on one core: 10x faster than 
> Vectorz and 2x faster than JBlas.
>
> The page now covers some more cases: multicore ATLAS (on my 4-core 
> i7-4790k) and floats. Neanderthal is 60 times faster with multi-threaded 
> ATLAS and floats than Vectorz (core.matrix).
>
> For the rest of the results, please follow the link. This will work with 
> older versions of Neanderthal.
>
>
> https://www.reddit.com/r/Clojure/comments/4a8o9n/new_matrix_multiplication_benchmarks_neanderthal/
> http://neanderthal.uncomplicate.org/articles/benchmarks.html
>

-- 
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 Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Dragan Djuric]

On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:

> It would be great if Neanderthal simply implemented the core.matrix 
> protocols, then people could use it as a core.matrix implementation for 
> situations where it makes sense. I really think it is an architectural 
> dead-end for Neanderthal to develop a separate API. You'll simply get less 
> users for Neanderthal and fragment the Clojure library ecosystem which 
> doesn't help anyone.
>

Mike, I explained that many times in detail what's wrong with core.matrix, 
and I think it is a bit funny that you jump in every time Neanderthal is 
mentioned with the same dreams about core.matrix, without even trying 
Neanderthal, or discussing the issues that I raised. Every time your answer 
is that core.matrix is fine for *YOUR* use cases. That's fine with me and I 
support your choice, but core.matrix fell short for *MY* use cases, and 
after detailed inspection I decided it was unsalvageable. If I thought I 
could improve it, it would have been easier for me to do that than to spend 
my time fiddling with JNI and GPU minutes.

I understand your emotions about core.matrix, and I empathize with you. I 
support your contributions to Clojure open-source space, and am glad if 
core.matrix is a fine solution for a number of people. Please also 
understand that it is not a solution to every problem, and that it can also 
be an obstacle, when it fells short in a challenge.
 

> In the absence of that, we'll just need to develop separate BLAS 
> implementations for core.matrix. 
>

I support you. If you do a good job, I might even learn something now and 
improve Neanderthal.
 

> Would be great if you could implement the core.matrix protocols and solve 
> this issue. It really isn't much work, I'd even be happy to do it myself if 
> Neanderthal worked on Windows (last time I tried it doesn't).
>

I am happy that it is not much work, since it will be easy for you or 
someone else to implement it ;) Contrary to what you said on slack, I am 
*not against it*. I said that many times. Go for it. The only thing that I 
said is that *I* do not have time for that nor I have any use of 
core.matrix.

Regarding Windows - Neanderthal works on Windows. I know this because a 
student of mine compiled it (he's experimenting with an alternative GPU 
backend for Neanderthal and prefers to work on Windows). As I explained to 
you in the issue that you raised on GitHub last year, You have to install 
ATLAS on your machine, and Neanderthal has nothing un-Windowsy in its code. 
There is nothing Neanderthal specific there, it is all about comiling 
ATLAS. Follow any ATLAS or Nympu + ATLAS or R + ATLAS guide for 
instructions. Many people did that installation, so I doubt it'd be a real 
obstacle for you.

 

> On Sunday, 13 March 2016 23:34:23 UTC+8, Dragan Djuric wrote:
>>
>> I am soon going to release a new version of Neanderthal.
>>
>> I reinstalled ATLAS, so I decided to also update benchmarks with threaded 
>> ATLAS bindings.
>>
>> The results are still the same for doubles on one core: 10x faster than 
>> Vectorz and 2x faster than JBlas.
>>
>> The page now covers some more cases: multicore ATLAS (on my 4-core 
>> i7-4790k) and floats. Neanderthal is 60 times faster with multi-threaded 
>> ATLAS and floats than Vectorz (core.matrix).
>>
>> For the rest of the results, please follow the link. This will work with 
>> older versions of Neanderthal.
>>
>>
>> https://www.reddit.com/r/Clojure/comments/4a8o9n/new_matrix_multiplication_benchmarks_neanderthal/
>> http://neanderthal.uncomplicate.org/articles/benchmarks.html
>>
>

-- 
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] Inlein 0.1.0

[Rangel Spasov]

Very nice, super simple to get started with. Got it running within a 
minute! Definite will make use of this : )

On Sunday, March 13, 2016 at 7:09:22 AM UTC-7, Jean Niklas L'orange wrote:
>
> Hi all Clojurians,
>
> Alex Miller did some research 
>  on 
> slow boot times with Clojure/scripting in
> Clojure not too long ago.
>
> What I found weird was that there were no tool for doing Clojure 
> scripting. It's
> possible to do this with both Leiningen and Boot, but neither were 
> originally
> designed for scripts nor fast startup times. I have personally found this 
> a bit
> annoying in the past, as I have had good reasons to use Clojure for 
> scripting.
>
> Therefore, I have created a new tool called Inlein . 
> You can think of it as a
> Leiningen for scripts, where the project.clj is inlined into the script 
> itself.
> Inlein itself starts up very fast, so the startup time of a script is more 
> or
> less only the time it takes to start Clojure and the dependencies you drag 
> in.
>
> You could probably use this for a lot of things. The first thing that 
> comes to
> mind is obviously long-running scripts and CLI programs, but it could also 
> be
> used for customised REPLs, independent of Boot and Leiningen.
>
> There are probably many uses for Inlein that I haven't thought of yet, but 
> if
> you want inspiration, you can have a look in the examples directory 
> .
>
> Inlein is located over at https://github.com/hyPiRion/inlein and the 0.1.0
> version can be downloaded from
> https://github.com/hyPiRion/inlein/releases/0.1.0/
>
> To get started, you can take a look over at the Getting Started page 
>  on the
> wiki.
>
> -- Jean Niklas
>
>

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

Including debugging information for Clojure code

[Jason Gilman]

I'd recommend asking on slack. There's a cider channel where they hang out and 
may be able to answer your question. You can join here 
https://clojurians.slack.com/

I'd really like to know this information for Proto REPL as well. 

-- 
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 Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Mikera]

On Monday, 14 March 2016 08:19:25 UTC+8, Dragan Djuric wrote:
>
> On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:
>
>> It would be great if Neanderthal simply implemented the core.matrix 
>> protocols, then people could use it as a core.matrix implementation for 
>> situations where it makes sense. I really think it is an architectural 
>> dead-end for Neanderthal to develop a separate API. You'll simply get less 
>> users for Neanderthal and fragment the Clojure library ecosystem which 
>> doesn't help anyone.
>>
>
> Mike, I explained that many times in detail what's wrong with core.matrix, 
> and I think it is a bit funny that you jump in every time Neanderthal is 
> mentioned with the same dreams about core.matrix, without even trying 
> Neanderthal, or discussing the issues that I raised. Every time your answer 
> is that core.matrix is fine for *YOUR* use cases. That's fine with me and I 
> support your choice, but core.matrix fell short for *MY* use cases, and 
> after detailed inspection I decided it was unsalvageable. If I thought I 
> could improve it, it would have been easier for me to do that than to spend 
> my time fiddling with JNI and GPU minutes.
>

It would be great if you could explain this statement. What *precisely* are 
your technical objections?

Please remember that core.matrix is primarily intended as an API, not a 
matrix implementation itself. The point is that different matrix 
implementations can implement the standard protocols, and users and library 
writers can then code to a standard API while maintaining flexibility to 
use the implementation that best suits their use cases (of which 
Neanderthal could certainly be one).
 

>
> I understand your emotions about core.matrix, and I empathize with you. I 
> support your contributions to Clojure open-source space, and am glad if 
> core.matrix is a fine solution for a number of people. Please also 
> understand that it is not a solution to every problem, and that it can also 
> be an obstacle, when it fells short in a challenge.
>

Interested to understand that statement. Please let me know what use cases 
you think don't work for core.matrix. A lot of people have worked on the 
API to make it suitable for a large class of problems, so I'm interested to 
know if there are any we have missed. 

For any point you have here, I'm happy to either:
a) Explain how it *does* work
b) Take it as an issue to address in the near future.
 

>  
>
>> In the absence of that, we'll just need to develop separate BLAS 
>> implementations for core.matrix. 
>>
>
> I support you. If you do a good job, I might even learn something now and 
> improve Neanderthal.
>  
>
>> Would be great if you could implement the core.matrix protocols and solve 
>> this issue. It really isn't much work, I'd even be happy to do it myself if 
>> Neanderthal worked on Windows (last time I tried it doesn't).
>>
>
> I am happy that it is not much work, since it will be easy for you or 
> someone else to implement it ;) Contrary to what you said on slack, I am 
> *not against it*. I said that many times. Go for it. The only thing that I 
> said is that *I* do not have time for that nor I have any use of 
> core.matrix.
>
> Regarding Windows - Neanderthal works on Windows. I know this because a 
> student of mine compiled it (he's experimenting with an alternative GPU 
> backend for Neanderthal and prefers to work on Windows). As I explained to 
> you in the issue that you raised on GitHub last year, You have to install 
> ATLAS on your machine, and Neanderthal has nothing un-Windowsy in its code. 
> There is nothing Neanderthal specific there, it is all about comiling 
> ATLAS. Follow any ATLAS or Nympu + ATLAS or R + ATLAS guide for 
> instructions. Many people did that installation, so I doubt it'd be a real 
> obstacle for you.
>

Every time I have tried it has failed on my machine. I'm probably doing 
something wrong, but it certainly isn't obvious how to fix it. Can you 
point me to a canonical guide and binary distribution that works "out of 
the box"? 

-- 
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 there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)

[Mikera]

On Friday, 11 March 2016 09:21:09 UTC+8, arthur.ma...@gmail.com wrote:
>
> Renjin and Spark's dataframes are not going to be easily removed from 
> their respective codebases, as far as my brief perusal of the source can 
> tell. I agree that N-D DataFrames would be a good addition to the 
> ecosystem, similar to the goals of Python's xarray (xarray.pydata.org). 
> However, it is not a priority for myself as of this time. Thanks for 
> pointing out the DataSet proposal. I'll take a look at that later.
>
> On a slightly related note, where is the best place to ask core.matrix 
> questions? I have some small questions about sparse matrix support in 
> core.matrix, and what sparse formats are implemented.
>

There is the Numerical Clojure group: 
https://groups.google.com/forum/#!forum/numerical-clojure

For quick questions / discussion many people are on the #data-science 
channel in the Clojure slack  

Or you can just file a core.matrix issue with a question: I'm usually quite 
responsive with these and they may serve as a reference for future people 
who run into similar questions: 
https://github.com/mikera/core.matrix/issues

-- 
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 Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Leif]

I also think the core.matrix crusade is unnecessary.  Here are my two cents:

1. No one jumps in every time someone writes a new web routing library 
saying "No!  You'll fragment the clojure
web routing community!  Use compojure!"  I think we should pick and 
choose based on our needs.
2. We should build on well-tested, stable APIs, true.  Dragan has built on 
top of BLAS (basically stable for over
35 years) and LAPACK (25-35 years depending on how you count).
3. Dragan has no need or desire to implement the core.matrix API, but I'm 
sure someone that wants native speed
*and* compatibility with core.matrix will do so when the need arises.
4. If you want accessibility to the widest possible community of numerical 
programmers, bear in mind that most
of them aren't clojure or even java programmers anyway.  BLAS and 
LAPACK are the way to make them feel
at home.  Pure-java numerical programming is a rather strange 
cul-de-sac community already.
5. Numerical programming is a field where you, unfortunately, have to drop 
layers of abstraction more
frequently than other fields.  I'd rather drop down into ATLAS than 
<>.

In short, having two libraries that do the same thing is not a problem, and 
if it becomes a problem, I think we as a community can deal with it fairly 
quickly.

--Leif

On Sunday, March 13, 2016 at 8:19:25 PM UTC-4, Dragan Djuric wrote:
>
> On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:
>
>> It would be great if Neanderthal simply implemented the core.matrix 
>> protocols, then people could use it as a core.matrix implementation for 
>> situations where it makes sense. I really think it is an architectural 
>> dead-end for Neanderthal to develop a separate API. You'll simply get less 
>> users for Neanderthal and fragment the Clojure library ecosystem which 
>> doesn't help anyone.
>>
>
> Mike, I explained that many times in detail what's wrong with core.matrix, 
> and I think it is a bit funny that you jump in every time Neanderthal is 
> mentioned with the same dreams about core.matrix, without even trying 
> Neanderthal, or discussing the issues that I raised. Every time your answer 
> is that core.matrix is fine for *YOUR* use cases. That's fine with me and I 
> support your choice, but core.matrix fell short for *MY* use cases, and 
> after detailed inspection I decided it was unsalvageable. If I thought I 
> could improve it, it would have been easier for me to do that than to spend 
> my time fiddling with JNI and GPU minutes.
>
> I understand your emotions about core.matrix, and I empathize with you. I 
> support your contributions to Clojure open-source space, and am glad if 
> core.matrix is a fine solution for a number of people. Please also 
> understand that it is not a solution to every problem, and that it can also 
> be an obstacle, when it fells short in a challenge.
>  
>
>> In the absence of that, we'll just need to develop separate BLAS 
>> implementations for core.matrix. 
>>
>
> I support you. If you do a good job, I might even learn something now and 
> improve Neanderthal.
>  
>
>> Would be great if you could implement the core.matrix protocols and solve 
>> this issue. It really isn't much work, I'd even be happy to do it myself if 
>> Neanderthal worked on Windows (last time I tried it doesn't).
>>
>
> I am happy that it is not much work, since it will be easy for you or 
> someone else to implement it ;) Contrary to what you said on slack, I am 
> *not against it*. I said that many times. Go for it. The only thing that I 
> said is that *I* do not have time for that nor I have any use of 
> core.matrix.
>
> Regarding Windows - Neanderthal works on Windows. I know this because a 
> student of mine compiled it (he's experimenting with an alternative GPU 
> backend for Neanderthal and prefers to work on Windows). As I explained to 
> you in the issue that you raised on GitHub last year, You have to install 
> ATLAS on your machine, and Neanderthal has nothing un-Windowsy in its code. 
> There is nothing Neanderthal specific there, it is all about comiling 
> ATLAS. Follow any ATLAS or Nympu + ATLAS or R + ATLAS guide for 
> instructions. Many people did that installation, so I doubt it'd be a real 
> obstacle for you.
>
>  
>
>> On Sunday, 13 March 2016 23:34:23 UTC+8, Dragan Djuric wrote:
>>>
>>> I am soon going to release a new version of Neanderthal.
>>>
>>> I reinstalled ATLAS, so I decided to also update benchmarks with 
>>> threaded ATLAS bindings.
>>>
>>> The results are still the same for doubles on one core: 10x faster than 
>>> Vectorz and 2x faster than JBlas.
>>>
>>> The page now covers some more cases: multicore ATLAS (on my 4-core 
>>> i7-4790k) and floats. Neanderthal is 60 times faster with multi-threaded 
>>> ATLAS and floats than Vectorz (core.matrix).
>>>
>>> For the rest of the results, please follow the link. This will work with 
>>> older versions of Neanderthal.
>>>
>>>
>>> https://www.reddit.com/r/Clojure/c

Re: Including debugging information for Clojure code

[Colin Fleming]

I don't have much time right now, but AFAIK Cursive is the only debugger
using JDI - CIDER has a source manipulation debugger. I don't generally
have to do anything special to debug, although I use an IntelliJ layer on
top of JDI. I can try to check if it's doing anything with that flag. You
can also check if your classes have debug info using Javap or a decompiler.

I have to run now, but if you have further questions or you can't get it
working let me know and I can dig further.

On 14 March 2016 at 15:13, Jason Gilman  wrote:

> I'd recommend asking on slack. There's a cider channel where they hang out
> and may be able to answer your question. You can join here
> https://clojurians.slack.com/
>
> I'd really like to know this information for Proto REPL as well.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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