from:"Christopher"

EDIT: ...for the development of dynamic web applications.


On Tuesday, December 18, 2018 at 8:31:25 PM UTC-8, Christopher Small wrote:
>
>
> Hi Juraj
>
> Glad you have it working now!
>
> I mostly use oz from the Clojure REPL as an exploratory tool in my work on 
> Polis (see https://www.youtube.com/watch?v=2tBVMAm0-00). I have yet to 
> use the Reagent API in a dynamic front end, but I have used Vega & 
> Vega-Lite in a vanilla React app (see https://github.com/matsengrp/olmsted), 
> so I know what's possible and look forward to being able to do the 
> equivalent in ClojureScript.
>
> I'm a vim user, so I use vim-fireplace to connect my REPL to my text 
> editor. This lets me write and execute plot building code directly from the 
> comfort of my editor, and have a separate browser window open for looking 
> at the results. This gives me a pretty tight feedback loop for visualizing 
> and exploring data. If you're using the Reagent API with Figwheel, you 
> should get a pretty similar feedback loop for development of 
>
> To be perfectly honest, debugging can be a bit challenging when first 
> using Vega & Vega-Lite. The IDL's Vega Editor has some helpful tools for 
> analyzing specs for problems, and a tight feedback loop of tweaking and 
> re-evaluating plot code can help keep you on the right path till you get 
> your bearing. They're also working on some really neat debugging tools to 
> help visualize the compiled dataflow topology in order to better diagnose 
> issues, so hopefully this area will improve.
>
> The best way to get started is to go to the Vega & Vega-Lite Examples 
> pages (https://vega.github.io/vega/examples/ & 
> https://vega.github.io/vega-lite/examples/), which helpfully showcase a 
> panapoly of specs available for use as starting points. Once you find a 
> related spec, it's usually only a few changes to a get a "bare bones" 
> adaptation to your data. From there, you can generally stitch in spec code 
> from other examples as needed to get the plot you want. If some "stitching" 
> doesn't work, look for other examples combining similar functionality if 
> possible, and if not raise an issue. The IDL is super responsive and active 
> in their development and release cycle, so bugs generally get solved very 
> quickly; In fact on rare occasions where I've found a Vega bug or something 
> I wanted to do but couldn't easily, I've frequently discovered that there's 
> already been a fix released, or had them specifically address the problem 
> within a matter of weeks.
>
> Thanks again
>
> Chris
>
>
>
>

-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite


Great to hear. Thanks for checking it out!


On Tuesday, December 18, 2018 at 10:38:12 AM UTC-8, Alan Thompson wrote:
>
> Looks very nice.  I will definitely be using this in the future.
> Alan
>
>

-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite


Hi Juraj

Glad you have it working now!

I mostly use oz from the Clojure REPL as an exploratory tool in my work on 
Polis (see https://www.youtube.com/watch?v=2tBVMAm0-00). I have yet to use 
the Reagent API in a dynamic front end, but I have used Vega & Vega-Lite in 
a vanilla React app (see https://github.com/matsengrp/olmsted), so I know 
what's possible and look forward to being able to do the equivalent in 
ClojureScript.

I'm a vim user, so I use vim-fireplace to connect my REPL to my text 
editor. This lets me write and execute plot building code directly from the 
comfort of my editor, and have a separate browser window open for looking 
at the results. This gives me a pretty tight feedback loop for visualizing 
and exploring data. If you're using the Reagent API with Figwheel, you 
should get a pretty similar feedback loop for development of 

To be perfectly honest, debugging can be a bit challenging when first using 
Vega & Vega-Lite. The IDL's Vega Editor has some helpful tools for 
analyzing specs for problems, and a tight feedback loop of tweaking and 
re-evaluating plot code can help keep you on the right path till you get 
your bearing. They're also working on some really neat debugging tools to 
help visualize the compiled dataflow topology in order to better diagnose 
issues, so hopefully this area will improve.

The best way to get started is to go to the Vega & Vega-Lite Examples pages 
(https://vega.github.io/vega/examples/ & 
https://vega.github.io/vega-lite/examples/), which helpfully showcase a 
panapoly of specs available for use as starting points. Once you find a 
related spec, it's usually only a few changes to a get a "bare bones" 
adaptation to your data. From there, you can generally stitch in spec code 
from other examples as needed to get the plot you want. If some "stitching" 
doesn't work, look for other examples combining similar functionality if 
possible, and if not raise an issue. The IDL is super responsive and active 
in their development and release cycle, so bugs generally get solved very 
quickly; In fact on rare occasions where I've found a Vega bug or something 
I wanted to do but couldn't easily, I've frequently discovered that there's 
already been a fix released, or had them specifically address the problem 
within a matter of weeks.

Thanks again

Chris



-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

Hi Juraj

The code you pasted *should* work. If you're still having trouble with
this, please raise a GH issue with all pertinent system/setup details so we
can sort it out there: https://github.com/metasoarous/oz/issues.

I can say that sometimes it takes a while for the websocket connection to
establish, and the exact time may depend a bit on machine details. This is
what Boris is getting at about having to to call `(oz/v! ...)` again
(Thanks for chiming in Boris!). The first thing to try is to just wait a
bit longer after calling `(oz/start-plot-server!)`, and try reevaluating
`(oz/v line-plot)`.

Oh... one last thing to check. If you had tried an older version of oz
prior to this and are just hoping to check out the updates (which I'm
wondering about in part because I see you're running the old example code,
though you could have gotten that from the video), it might be worth
running `lein clean` in case this is a problem with a stale build target.

Thanks!

Chris



On Tue, Dec 18, 2018 at 4:45 AM  wrote:

> Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and
> evaluating the whole blob from lighttable.
>
> I had to call (oz/v! line-plot) again to get it to show the figure,
> rather then the opening text. And you can leave out the (oz/start-plot-
> server!). It will start a server if it needs one.
>
> I guess I have a similar workflow as Christopher, and similar needs in
> terms of visualization. I have used vega-lite through vizard and now oz for
> about a year now, after trying so many different visualization packages for
> clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica,
> rojure->ggplot2, vizard). Really happy that oz takes vizard further.
> vega/vega-lite works really well with clojure.
>
>
>
> On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>>
>> I'd like to try this but got stuck pretty early:
>>
>> (ns clojure-repl-experiments.visualizations.oz
>>   (:require [oz.core :as oz]))
>>
>>
>> (oz/start-plot-server!)
>>
>>
>> (defn group-data [& names]
>>   (apply concat (for [n names]
>>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
>> (repeatedly
>> #(rand-int 100)))
>>
>>
>> (def line-plot
>>   {:data {:values (group-data "monkey" "slipper" "broom")}
>>:encoding {:x {:field "x"}
>>   :y {:field "y"}
>>   :color {:field "col" :type "nominal"}}
>>:mark "line"})
>>
>>
>> ;; Render the plot to the
>> (oz/v! line-plot)
>>
>>
>>
>> It has opened a new browser window at http://localhost:10666/ but I see
>> nothing only errors in the JS console:
>> socket.cljs?rel=1502542805393:64 WebSocket connection to
>> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection
>> establishment: net::ERR_CONNECTION_REFUSED
>> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
>> 10:10:10.089
>>
>> Does it require some special setup (figwheel)?
>>
>>
>>
>>
>> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>>>
>>>
>>> Greetings!
>>>
>>> I'm happy to announce today the release of Oz 1.4.0.
>>>
>>> https://github.com/metasoarous/oz
>>>
>>> If you're on the Slack #datascience channel, you may have already caught
>>> wind of some earlier versions. But in the interest of introducing it more
>>> broadly, I'm posting an overview here for those of you who aren't familiar.
>>> If you *are* familiar, you may still wish to scroll down to the bottom
>>> as there are some new features available in the latest release.
>>>
>>>
>>> *Vega & Vega-Lite*
>>>
>>> Oz is based on the fantastic Vega & Vega-Lite data visualization JS
>>> libraries, and so to really understand what Oz has to offer, it's best to
>>> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics,
>>> an approach to data visualization which emphasizes writing declarative
>>> descriptions of how properties of data should translate to aesthetic
>>> attributes of a visualization. This approach guided the design of the R's
>>> popular ggplot2 library, and has since influenced numerous libraries in
>>> other languages.
>>>
>>> Vega & Vega-Lite take this vision further in two important ways:
>>>
>>>1. In Vega & Vega-Lite, data visualizations are described using *pure
>>>data*. This makes it more declarative

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-17 Thread Christopher Small

Good catch! The examples page was split up into separate pages for Vega vs 
Vega-Lite, and I just updated the README to reflect this.

Thanks for taking a look and letting me know!

Chris


On Monday, December 17, 2018 at 12:45:34 PM UTC-8, Colin Yates wrote:
>
> Looks great! The link to examples (https://vega.github.io/examples) 404s.
>
> Sent from my iPhone
>
> On 17 Dec 2018, at 20:41, Christopher Small  > wrote:
>
>
> Greetings!
>
> I'm happy to announce today the release of Oz 1.4.0.
>
> https://github.com/metasoarous/oz
>
> If you're on the Slack #datascience channel, you may have already caught 
> wind of some earlier versions. But in the interest of introducing it more 
> broadly, I'm posting an overview here for those of you who aren't familiar. 
> If you *are* familiar, you may still wish to scroll down to the bottom as 
> there are some new features available in the latest release.
>
>
> *Vega & Vega-Lite*
>
> Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
> libraries, and so to really understand what Oz has to offer, it's best to 
> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, 
> an approach to data visualization which emphasizes writing declarative 
> descriptions of how properties of data should translate to aesthetic 
> attributes of a visualization. This approach guided the design of the R's 
> popular ggplot2 library, and has since influenced numerous libraries in 
> other languages.
>
> Vega & Vega-Lite take this vision further in two important ways:
>
>1. In Vega & Vega-Lite, data visualizations are described using *pure 
>data*. This makes it more declarative, and confers all the benefits we 
>know and love about data-driven programming in Clojure. For instance, you 
>can send a chunk of Vega or Vega-Lite data over the wire from one program 
>to another effortlessly (as Oz does), and load it up in another process 
>without having to worry about the security concerns of executing someone 
>else's code. The bottom line is that Vega & Vega-Lite are philosophically 
>and technically compatible with "the Clojure way" (IT'S. JUST. DATA.).
>2. Vega & Vega-Lite take the Grammar of Graphics one step further by 
>introducing a Grammar of Interaction. You can declaratively describe the 
>addition of controls (dropdowns, checkboxes, etc) and interactive 
>properties of the visualization itself (click, hover, etc), and use the 
>data from these interactions to inform other parts of a visualization. For 
>example, you might highlight a set of points in one part of a 
>visualization, and display summary statistics about that selection in 
>another. This is facilitated in part by a general purpose dataflow 
> language 
>as part of the greater spec.
>
> Vega itself is highly customizable and flexible, but somewhat verbose and 
> not suitable for day to day visualization tasks. Vega-Lite steps in as a 
> somewhat higher level and more automated flavor which itself compiles down 
> to Vega. I have been using them together for a better part of a year now, 
> and can say without reservation that they are amazing. For years I've 
> longed for a ggplot2 from Clojure, and at long last I've found something 
> that to my surprise has not only matched, but truly surpassed the standard 
> bearer. In short, I'm sold.
>
> If you want to get a better sense of Vega, and Vega-Lite in particular, 
> I'd recommend this great talk from the creators at the Interactive Data Lab 
> at the University of Washington in Seattle: 
> https://www.youtube.com/watch?v=9uaHRWj04D4
>
> If you're interested in a (mostly) more philosophical look at Vega & 
> Vega-Lite, and their connections to Clojure philosophy, I did a little talk 
> at a local Clojure meetup which you may find interesting: 
> https://www.youtube.com/watch?v=hXq5Bb40zZY=815s
>
>
> *Oz*
>
> Oz itself is a very small and focused library, as most of the work falls 
> on Vega & Vega-Lite. It offers the following features:
>
>- A REPL API for for pushing vega and vega-lite data to a browser 
>window over websockets, for REPL-based data science workflows
>- Client side vega and vega-lite Reagent components, for more dynamic 
>usage from ClojureScript apps
>- A grammar for composing Vega & Vega-Lite together in the context of 
>html as hiccup, for document and dashboard generation
>- Plot/document publishing/sharing features via GitHub gists, the 
>IDL's live vega editor <http://vega.github.io/editor>, and the new 
>http://ozviz.io
>
> The last two features in particular are where Oz really

[ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-17 Thread Christopher Small


Greetings!

I'm happy to announce today the release of Oz 1.4.0.

https://github.com/metasoarous/oz

If you're on the Slack #datascience channel, you may have already caught 
wind of some earlier versions. But in the interest of introducing it more 
broadly, I'm posting an overview here for those of you who aren't familiar. 
If you *are* familiar, you may still wish to scroll down to the bottom as 
there are some new features available in the latest release.


*Vega & Vega-Lite*

Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
libraries, and so to really understand what Oz has to offer, it's best to 
start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, 
an approach to data visualization which emphasizes writing declarative 
descriptions of how properties of data should translate to aesthetic 
attributes of a visualization. This approach guided the design of the R's 
popular ggplot2 library, and has since influenced numerous libraries in 
other languages.

Vega & Vega-Lite take this vision further in two important ways:

   1. In Vega & Vega-Lite, data visualizations are described using *pure 
   data*. This makes it more declarative, and confers all the benefits we 
   know and love about data-driven programming in Clojure. For instance, you 
   can send a chunk of Vega or Vega-Lite data over the wire from one program 
   to another effortlessly (as Oz does), and load it up in another process 
   without having to worry about the security concerns of executing someone 
   else's code. The bottom line is that Vega & Vega-Lite are philosophically 
   and technically compatible with "the Clojure way" (IT'S. JUST. DATA.).
   2. Vega & Vega-Lite take the Grammar of Graphics one step further by 
   introducing a Grammar of Interaction. You can declaratively describe the 
   addition of controls (dropdowns, checkboxes, etc) and interactive 
   properties of the visualization itself (click, hover, etc), and use the 
   data from these interactions to inform other parts of a visualization. For 
   example, you might highlight a set of points in one part of a 
   visualization, and display summary statistics about that selection in 
   another. This is facilitated in part by a general purpose dataflow language 
   as part of the greater spec.

Vega itself is highly customizable and flexible, but somewhat verbose and 
not suitable for day to day visualization tasks. Vega-Lite steps in as a 
somewhat higher level and more automated flavor which itself compiles down 
to Vega. I have been using them together for a better part of a year now, 
and can say without reservation that they are amazing. For years I've 
longed for a ggplot2 from Clojure, and at long last I've found something 
that to my surprise has not only matched, but truly surpassed the standard 
bearer. In short, I'm sold.

If you want to get a better sense of Vega, and Vega-Lite in particular, I'd 
recommend this great talk from the creators at the Interactive Data Lab at 
the University of Washington in Seattle: 
https://www.youtube.com/watch?v=9uaHRWj04D4

If you're interested in a (mostly) more philosophical look at Vega & 
Vega-Lite, and their connections to Clojure philosophy, I did a little talk 
at a local Clojure meetup which you may find interesting: 
https://www.youtube.com/watch?v=hXq5Bb40zZY=815s


*Oz*

Oz itself is a very small and focused library, as most of the work falls on 
Vega & Vega-Lite. It offers the following features:

   - A REPL API for for pushing vega and vega-lite data to a browser window 
   over websockets, for REPL-based data science workflows
   - Client side vega and vega-lite Reagent components, for more dynamic 
   usage from ClojureScript apps
   - A grammar for composing Vega & Vega-Lite together in the context of 
   html as hiccup, for document and dashboard generation
   - Plot/document publishing/sharing features via GitHub gists, the IDL's 
   live vega editor , and the new 
   http://ozviz.io

The last two features in particular are where Oz really brings some 
interesting value to the table beyond the role of a minimal wrapper. I have 
found the ability to create and quickly share visualizations and scientific 
documents from the comfort of my favorite text editor and REPL a godsend. 
While the first several years of my programming experience were in notebook 
environments (Mathematica, MATLAB, Sage, etc), I now find the experience of 
writing and executing code from a web application a burden. Part of my goal 
with Oz was to create a viable alternative to this workflow, and so far 
I've been very pleased. The last piece to this now in place (the ability to 
share hiccup+vega documents via http://ozviz.io), I'm excited to put this 
work out more broadly and hear what the community thinks about this 
approach to the creation and sharing of scientific documents.

There are some other updates and improvements which those of you familiar

Re: group rows on basis of value in a column in CSV with clojure

2018-07-09 Thread Christopher Small

You may want to take a look at my library semantic-csv, which lets you cast 
rows as maps instead of vectors, so that you can group-by a column name 
instead of a positional index.

https://github.com/metasoarous/semantic-csv


On Saturday, July 7, 2018 at 11:07:50 PM UTC-7, Varun J.P wrote:
>
> Hi All, 
> Thanks for the tip to use (group-by last …)
> It was working fine until my csv file got updated. Now i am not sure abt 
> the number of columns in my csv. It could change in every row, but I still 
> need to group it with Heading 3 itself. 
>
> Example of my updated CSV is as below
>
> Heading1 Heading 2 Heading 3 Heading 4 Heading 5
>> abc 123 Value1 newValue 
>> def 234 Value1 anotherValue oneMoreValue
>> ghi dfgew Value1 aValue 
>> jkl 456 Value5 
>> pqr 567 Value5 
>> stu 678 value3 
>> vwx sdf value4 
>> yza 900 value4 
>
>  
> Now i cant use (group-by last ...) instead i tried using  
>
> (group-by (nth (nth testvector 0) 2) testvector) where testvector is a 
> vector of vector but is throwing an error 
>
>> "ClassCastException java.lang.String cannot be cast to clojure.lang.IFn  
>> clojure.core/group-by/fn--7011 
>> (core.clj:6870)" 
>
>
> Can someone suggest a different approch 
>
>
>
>
>
> On Tuesday, July 3, 2018 at 10:42:08 PM UTC+5:30, Philipp Neumann wrote:
>>
>> Hi.
>>
>> This is a job for (group-by last ...)
>>
>> Regards
>>
>> Varun J.P  schrieb am Di., 3. Juli 2018, 19:05:
>>
>>> My CSV file is something like the attached file which could have 'n' 
>>> number of line. I need to group by the values in the last column. 
>>> Current I believe the below code will return me a vector of vector. 
>>>
>>> (defn read-csv-file
>>>
>>>  [path]
>>>
>>>  (try
>>>
>>>(with-open [input-file (io/reader path)]
>>>
>>>  (let [a_list (doall (map (comp first clojure-csv.core/parse-csv) (
>>> line-seq input-file)))]
>>>
>>>(rest (into [] a_list
>>>
>>>(catch Exception exception (throw exception
>>>
>>>
>>> i need to iterate through this vector of vector and create a new vector 
>>> of vector containing only elements of the first group, then in next 
>>> iteration i need the second set and so on. 
>>>
>>> Example CSV 
>>>
 Heading1 Heading 2 Heading 3 
 abc 123 Value1 
 def 234 Value1 
 ghi dfgew Value1 
 jkl 456 Value5 
 pqr 567 Value5 
 stu 678 value3 
 vwx sdf value4 
 yza 900 value4 
>>>
>>>
>>>
>>> so when this CSV is parsed i will have something like 
>>> [
>>> [abc 123 Value1]
>>> [def 234 Value1]
>>> [ghi dfgew Value1]
>>> [jkl 456 Value5]
>>> [pqr 567 Value5]
>>> [stu 678 value3]
>>> [vwx sdf value4]
>>> [yza 900 value4]]
>>> So when i iterate through this i need to group the vector of vector by 
>>> the last column 
>>> so my first iteration output should be something like 
>>>
>>> [
>>> [abc 123 Value1]
>>> [def 234 Value1]
>>> [ghi dfgew Value1]]
>>> 2nd iteration should be 
>>> [
>>> [jkl 456 Value5]
>>> [pqr 567 Value5]]
>>> 3rd should be 
>>>
>>> [
>>> [stu 678 value3]] 
>>> and so on.
>>>
>>> How would i achieve this in clojure. is there any build in csv parsing 
>>> function
>>>
>>> Regards 
>>> JP
>>>
>>>
>>>
>>> -- 
>>> 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 call a function read from an EDN file?

2018-03-12 Thread Christopher Lee


down votefavorite 


Clojure noob here.

After reading in the google-creds.edn file like so:

"(edn/read-string (slurp "config/google-creds.edn"))"

How do I call the function get-auth-map on this EDN file, along with the 
OAuth scope (["https://www.googleapis.com/auth/calendar;]) ?

-- 
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: Simulations in Clojure/Clojurescript

2018-01-27 Thread Christopher Small

I'll second looking at Vega and Vega-lite. Grammar of graphics is wonderful.

With regards to simulation on Cljs, keep in mind that JS is limited in
numerical precision relative to the JVM, and this can be important in some
simulation contexts. Just make sure you are aware of the probabilistic
implications for your application.

Chris


On Sat, Jan 27, 2018 at 4:54 PM, Tiago Antão  wrote:

> Hi,
>
> Have a look at Vega and Vega lite for visualization... Amazing chart
> library
>
> On Jan 27, 2018 11:48 AM, "Michael Nardell"  wrote:
>
>> Tiago ::Thanks, for your input. Worth more considerably more than $00.02
>> for me right now. Since the last week or so, I have been diving into
>> ClojureScript. In particular I am loving exploring D3.js, with an
>> interactive, live coding experience. I am not sure if I should admit this
>> in public.. but I actually really miss Macromedia Director + Lingo. Offered
>> an interactive environment for building highly visual simulations and then
>> distributing on the web. I am seeing ClojureScript + FigWheel + D3.js
>> (and/or other viz libraries) as a way to get that experience back.
>>
>> MIke
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/xHAoFwEZ-aA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Simulations in Clojure/Clojurescript

2018-01-12 Thread Christopher Small

Joy of Clojure is a wonderful book.

Sounds like you have the right idea.

Enoy!


On Fri, Jan 12, 2018 at 9:55 AM, Michael Nardell  wrote:

> Bobby :: Thanks for the recommended reading, I am finding it useful for
> pointing me in a new direction in my thinking. Also, finding Chapter 9 in *The
> Joy of Clojure, *where it discusses Records and Protocols, helpful
> guidance. In particular, it seems like I could start by using 'plain-old'
> maps and functions, and easily 'slot-in' Records/ Protocols when/if  design
> or performance considerations warrant their introduction.
>
> Mike
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/xHAoFwEZ-aA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Simulations in Clojure/Clojurescript

2018-01-10 Thread Christopher Small

A Wize One once said

> Closures are the poor man's objects

It's easy to build "object-like" things in clojure. Just create a map 
pointing to whatever you like, including stateful things, like atoms. Then 
write functions which take that map and do stuff with it. Clojure's Records 
and Protocols are more formal ways of doing this, with added performance 
optimization and bidirectional polymophism, so they may be worth looking 
into. You may also want to take a look at spec.

You may be right about an object-oriented approach being the most natural 
here. But, I'd encourage you to keep an open mind. Clojure has this 
particular way of encouraging you to and rewarding you for describing your 
problem domain in terms of pain data, and writing program logic as (mostly) 
pure functions around that data. When statefulness is required, we're often 
careful about how we introduce it, and find ways to isolate it as much as 
possible from the non-stateful bits, thereby maximizing how much of the 
code we can keep pure. If you're already familiar with other functional 
languages, I may be saying nothing too new here. But Clojure still has a 
pretty unique take on the data-driven paradigm, so you may find yourself 
thinking about things in new ways. Even if you end up doing something 
pretty object-oriented, think about how you can steer things in this 
general direction, and other ways you might tackle the problem.

Good luck

Chris

On Wednesday, January 10, 2018 at 3:13:00 PM UTC-8, Michael Nardell wrote:
>
> Greetings :: I am new to Clojure and have not really gotten my feet wet 
> with Clojurescript yet. The advice I always give someone when leaning 
> programming or a new language is to pick a project that they are interested 
> in and dive in. For me, that project would be creating educational 
> simulations that model complex systems. 
>
> Part of my challenge with this as a project is that it is leading me 
> towards programming (at least partially) with objects to model the discrete 
> components in these systems. Arguably simulations are one of the domains 
> where objects are the right paradigm. The question I pose to the group is 
> how to work with objects in Clojure, in a manner that "goes with the grain" 
> of the language. Perhaps best to ground my question in a concrete example:
>
> I had created simulations / visualizations of Hubel and Wiesel's model of 
> the  center-surround receptive fields in the retina. My past simulations I 
> used a collection of objects to model  photo receptors (i.e. rods/cones),  
> horizontal, bi-polar cells, connected together to represent the behavior of 
> either on-center or off-center receptive fields. Kind of a simple neural 
> network. Would like to preserve the object nature of nodes in the network, 
> since the nodes have state and should be represented by graphics in a gui. 
> Ultimately I would like to move toward a "constructor kit" approach that 
> would allow students and teachers to model and simulate a whole variety of 
> various systems that can be represented as a network of processes with 
> feed-forward and feed-back connections. 
>
> Interested to know of any useful examples and guidance for doing objects 
> the Clojure/Clojurescript way. Certainly one of the examples I want to look 
> at closely is the Ant Hill that Rich Hickey demonstrated. 
>
> As is the case with a neophyte - any advice is well appreciated. 
>
> Mike
>
>

-- 
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: Port graphs: What would Rich Hickey do?

2018-01-04 Thread Christopher Small

Yes; Datomic really is great. There's plenty of wonderful stuff I haven't
even mentioned, like database as a value, persistent history, snapshots at
a timepoint, transaction metadata, smart peer replication etc. It's kind of
the best thing since sliced bread. But if you don't need all that jazz and
are fine with keeping things in memory for your problem, you may wish to
consider DataScript. It's free and open source and has remarkably good
coverage of the entity, pull and q APIs, and can run in cljs or clj.

One final note: with respect to "type headache" and "chain[ing] anything to
anything", you're right; this is a major benefit over traditional SQL.
Attribute are fundamentally polymorphic, which can be super helpful with
tricky modelling problems.

Chris


On Thu, Jan 4, 2018 at 10:48 AM, Ben Kovitz <bkov...@gmail.com> wrote:

> On Tuesday, January 2, 2018 at 3:11:45 PM UTC-5, Christopher Small wrote:
>
>
>> http://docs.datomic.com/entities.html
>>
>
>
>> http://docs.datomic.com/pull.html
>>
>
> Thanks—this is really good stuff! Not that I expected anything less, but
> it's a happy surprise that it applies so well to graphs. Now I'm wondering
> if I should just use Datomic rather than borrow ideas from it.
>
> One thing I'm convinced of now is that it's OK to assign ids to
> everything. I was cringing at that idea before, because it seems like an
> unnecessary layer of indirection and one more thing that could go wrong.
> But clearly Datomic's approach of assigning every "entity" an id enables
> some wonderful simplicity, since it enables one to very conveniently chain
> entities together. And when basically everything is an entity, that means
> you can chain anything to anything—which addresses the "type headache" I
> was trying to avoid.
>
> --
> Ben Kovitz
> http://pages.iu.edu/~bkovitz/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/uSwY475pbGA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Port graphs: What would Rich Hickey do?

2018-01-02 Thread Christopher Small

> ...noticed that the attribute names in the datoms are a lot like the port
labels in port graphs. A port label is essentially an attribute key whose
value is the edges incident to it. And when you chain data patterns in
Datalog queries, that's a lot like navigating through a graph.

That's very much in line with what I was thinking you might want to do in
this setting.

You should also take a look at the entity api. It let's you traverse the
graph via these entity objects which behave more or less like a dictionary
of the av pairs associated with a particular entity in the database.
Importantly though, when an attribute points to another entity (a reference
attribute), it is returned as yet another of these entity objects, letting
you traverse the graph using get, in a pretty similar fashion to what
you're describing.

http://docs.datomic.com/entities.html

You may also check out the pull api. It let's you pull facts out of the
graph as regular old maps by specifying what attributes & paths you wish to
pull out of the graph. The result is that you can read from the underlying
graph database as though it was a document store, but where the documents
are dynamically computed/queried from the graph based on the pull
expression you provide. You can also use pull expressions inside the
`:find` clause of either a DataScript of Datomic datalog query, which is
often a convenient way of specifying both a set of entities (via a datalog
query) and statement of facts to pull about them.

http://docs.datomic.com/pull.html

Collectively, these three interfaces give you quite a lot of expressiveness
and flexibility in how you query/traverse your data.



On Tue, Jan 2, 2018 at 12:31 PM, Ben Kovitz <bkov...@gmail.com> wrote:

> Christopher Small,
>
> Your suggestion to look into Datomic definitely turned up a new idea. I
> went through the Datalog tutorial at http://www.learndatalogtoday.org
> (which is excellent, by the way), and noticed that the attribute names in
> the datoms are a lot like the port labels in port graphs. A port label is
> essentially an attribute key whose value is the edges incident to it. And
> when you chain data patterns in Datalog queries, that's a lot like
> navigating through a graph.
>
> The new, hopefully simple, easy-to-use, and not error-prone idea is to use
> the clojure.lang.IPersistentMap  interface to query and update graphs.
> Nodes, edge, attribute names, port labels, and a few "reserved keywords"
> like :adj-nodes and :edge, could navigate the graph as if it were an
> ordinary nested map with get-in, assoc-in, and the like, without ever
> needing to wrap anything inside a record to tell what it is. Here are some
> sample queries and what they could return:
>
> (get-in g [node port-label :adj-nodes])
>   a coll of all the nodes with an edge to [node port-label]
> (get-in g [node port-label :adj-node])
>   one node with an edge to [node port-label], or nil
> (get-in g [node port-label])
>   true or false, according to whether node has a port named port-label
> (get-in g [node k])
>   value of node's attr k
> (get-in g [edge k])
>   value of edge's attr k
> (get g node-or-edge)
>   the entire map of attrs associated with node-or-edge, or nil if it does
> not exist
> (get-in g [node k1 k2 k3])
>   treat node's attrs as a nested map
> (get-in [node port-label :edges])
>   a coll of all the edges that link to [node port-label]
> (get-in [node port-label :edge])
>   a single edge that links to port-label, or nil
> (get-in [node port-label1 port-label2])
>   coll of all nodes that link to [node port-label1] from a port named
> port-label2
>
> And here are some function calls that would return a modified graph:
>
> (assoc-in g [node k] v)
>   sets node attr k to v
> (assoc-in g [edge k] v)
>   sets edge attr k to v  (and similarly for multiple keys)
> (assoc-in g [node1 port-label1 port-label2 node2] :edge)
>   makes an edge between [node1 port-label1] and [node2 port-label2]
> (assoc-in g [node1 port-label1 port-label2 :edge k] v)
>   sets value of edge attr k to v
>
> I haven't yet thought this through completely, and I suspect that some
> parts are still error-prone. For example, notice in the last function call
> that it's not clear whether you should include node2. The approach might be
> "too cute"—that is, brittle because it tries to impose one kind of
> structure (nested maps) onto one that isn't fully isomorphic (graphs).
>
> But I like the basic idea of having a "little language" for designating
> whatever you want, and the little language is nothing but a sequence that
> tells how to navigate through the graph to find (or make) what you're
> interested in.
>
> This would solve the fundamental problem of how to designate an edge
> without imposin

Re: Port graphs: What would Rich Hickey do?

2018-01-01 Thread Christopher Small

Do you need to be able to attach data to specific edges instances? Or would 
it be sufficient to be able to have different types of edges, and be able 
to associate data with those abstract edge types?

If the latter, you might want to look at Datomic (also authored by Rich 
Hickey), DataScript (an in-memory approximation) or RDF (data language of 
the Semantic Web). They model graphs as `(entity, attribute, value)` 
triples, where `attribute`s can act as labeled, directional arrows between 
entities, and can themselves show up in the `entity` position of other 
triples, thus allowing you to have "meta-attributes" (attributes pointing 
to/from other attributes).

Obviously, this is a little bit different from your "ports" idea (I haven't 
read about this; is it published on anywhere?), but in some ways a helpful 
restriction. For example, `mom` vs `child` is isomorphic to an edge labeled 
`isMotherOf`. But simpler, because there's less to specify, and in 
particular, less to get wrong with respect to which kinds of ports can 
connect to which kinds of other ports. So IMHO, simple labeled directional 
edges are best when semantically sufficient.

If either data needs to be attached to edges, or there are semantics of the 
modeling of things in terms of ports which are advantageous, you can still 
use EAV to model this data. You would just have entities modeling the edges 
and/or ports, and connect them using triples along the lines of `[[edge 
:my.graph.edge/from node-or-port-1] [edge :my.graph.edge/to node-or-port-2] 
[edge :my.graph.edge/label "a really cool edge"]]`. With Datomic or 
DataScript, you'd then be able to put together a set of Datalog rules which 
represent whatever higher level graph relations that might be useful. 
(Datalog is awesome, BTW)

Interested to hear what you think of this idea :-)

Chris

On Monday, January 1, 2018 at 3:07:28 PM UTC-7, Ben Kovitz wrote:
>
> I'm making a little library for myself to represent a kind of graph. I 
> want to
> make it simple, the way Rich Hickey designed much of Clojure. My designs so
> far have lacked that kind of plainness and ease of use. I keep wondering,
> "What would Rich Hickey do?" Even if you're not Rich Hickey, maybe you can
> suggest something. I'd love to hear some ideas about how to design this.
>
> This kind of graph is different from most graphs in two ways:
>
> (1) Edges connect to "ports" rather than simply to nodes. A port is a tuple
> (node, port-label). So, for example, if you had nodes :elizabeth and 
> :charles,
> you might have an edge connecting :elizabeth's "child" port to :charles's
> "mother" port, rather than simply an edge connecting :elizabeth and 
> :charles.
>
> (2) Edges can connect to edges as well as to ports. For example, the
> aforementioned edge might itself be connected by an edge to the "attests" 
> port
> of a node :royal-document-22416.
>
> These differences from ordinary graphs preclude the use of the loom 
> protocols
> or implementations such as ubergraph. I would like also to allow any 
> arbitrary
> map to be associated with any node or edge, just as ubergraph allows. By 
> the
> way, if you know of a standard name for this kind of graph, please tell me.
> It's not quite the same as a hypergraph. Note also that directed graphs 
> are a
> special case of this kind of graph, since the port labels can imply 
> asymmetry
> if you like. For example, if you only use labels :in and :out for ports, 
> then
> you have an ordinary directed graph.
>
> The fact that edges can connect to edges seems to be the main source of my
> difficulties. I would like to allow nodes and port labels to be of any data
> type: keywords, strings, vectors, anything, even graphs and edges from 
> graphs.
> The library should make no assumptions about the data types of the nodes 
> and
> port labels. So, when passing arguments to functions in the library, you 
> can't
> have a convention like "a 2-element vector represents a port" or "a 
> 2-element
> vector of 2-element vectors represents an edge".
>
> 
>
> Here are the main design ideas that I've entertained so far:
>
> 1. I could wrap nodes, ports, and edges in records, like this:
>
>   (defrecord Node [nodeid])
>   (defrecord Port [nodeid port-label])
>   (defrecord Edge [connpt1 connpt2])
>
> where connpt1 and connpt2 are "connection points": either a port or an 
> edge.
> This completely disambiguates everything. Library functions never look 
> inside
> a nodeid or port-label, but they can look inside a connection point as 
> needed.
>
> To add a node or edge to a graph g, you could call:
>
>   (defn add [g elem] ...)
>
> where elem must be a Node or Edge record.
>
> A problem with this is that it's a pain to use. Every time you call a 
> function
> like 'add', you have to wrap all the nodes. Wrapping edges is slightly 
> more of
> a nuisance.
>
> Another problem is that some decisions seem unclear and

Re: Clojure for big data

2017-10-19 Thread Christopher Penrose

And I will have to look at Onyx much more closely :)

On Thursday, October 19, 2017 at 2:01:52 PM UTC-7, Christopher Small wrote:
>
> Onyx has been very well maintained, has excellent documentation, and 
> doesn't suffer any of the AOT 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: Clojure for big data

2017-10-19 Thread Christopher Small

Thanks for the helpful information Christopher. I'll have to look at
Powderkeg.

The AOT issue is a big one. Being able to launch things from the REPL is
huge. That's actually one of the many advantages of Onyx over Storm (if
you're looking at the streaming side of things). Towards the end of my
using Storm I became increasingly frustrated with the project. At the time,
it was an Apache Incubator project, and development had slowed to a grind.
The Clojure API became woefully incompatible with more recent Clojures,
preventing us from upgrading for some time. They also began shifting focus
away from the Clojure API, and in turn the documentation became woefully
out of date. I've heard that some of these issues got a bit better as the
project came out of Incubator status, but others remain. In contrast, Onyx
has been very well maintained, has excellent documentation, and doesn't
suffer any of the AOT issues.

Chris



On Thu, Oct 19, 2017 at 1:02 PM, Christopher Penrose <cpenr...@steelcase.com
> wrote:

>
> The #bigdata channel over on Clojurians slack is also suspiciously quiet,
>> as are many of the Google groups.
>>
>> Ray.
>>
>
> I worked with Sparkling and Flambo about a year ago, while Mr. Macbeth is
> a fellow Portlander and has a solid API, I found Sparkling to be somewhat
> more direct and compact.  For ETL via Hadoop I wouldn't hesitate to try
> either of these libraries.  I found them to be stable and preferable to
> using Spark in Scala.  However, I used Powderkeg (https://github.com/
> HCADatalab/powderkeg) a bit and found it the most intriguing.  Christophe
> Grand last updated PowderKeg three hours ago (from time of my posting
> obviously).  Powderkeg relies heavily on Clojure transducers and is the
> only Clojure Spark library I am aware of which doesn't require AOT
> compilation -- you can use a Clojure repl to directly spawn jobs on a Spark
> cluster.  If you are interested in Clojure interoperability with Spark, I
> would look at Powderkeg first.
>
> If you require Spark Streaming, you might be better off writing Scala, or
> considering another streaming solution such as Storm.  The closest I have
> come to getting Spark Streaming to work in Clojure was with Powderkeg.  It
> might be worth seeing if Powderkeg has made progress in this area.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/ESkUu0Tmqmg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Clojure for big data

2017-10-18 Thread Christopher Small

Hi Ray

> This is partly prompted by the lack of activity on the Github repos.

Maybe you have higher standards here than I do... last commits on Flambo 
and Sparkling were 3 and 2 months ago, respectively. That doesn't raise any 
alarm bells for me personally. Moreover, looking at the contributor graphs, 
I don't particularly get the impression that the projects have ground to a 
halt:

https://github.com/gorillalabs/sparkling/graphs/contributors
https://github.com/yieldbot/flambo/graphs/contributors

I haven't used either, but I've heard good things from folks who've used 
Flambo. Last I heard, Flambo was a pretty key component of Yieldbot's 
infrastructure, and they seem to be doing well, so I wouldn't expect the 
project to go away any time soon. I don't know as much about Sparkling, but 
it seems to have actually started as a fork of Flambo, so I'd imagine the 
APIs are at least somewhat similar, and if one went defunct, you'd probably 
have a migration path towards the other.

You may also want to take a look at 
Onyx: https://github.com/onyx-platform/onyx. It's written from the ground 
up in Clojure, and is really wonderfully designed, with a very data-centric 
(Clojuric) API. They have a very active Gitter chat room 
(https://gitter.im/onyx-platform/onyx), and the developers are very 
friendly and helpful folks. You should know ahead of time that in contrast 
with Spark and MR, which are "batch centric" technologies, Onyx is 
foundationally a built on a streaming model, with support for typical batch 
processes built on top of this streaming base. IIRC, this is modeled after 
some of the Dataflow work Google has been doing, and due to the shifting 
economics around the cost of data transmission, this approach ends up being 
pretty competitive for batch workflows, while also offering a path towards 
more seamless streaming workflows should such a setup benefit you.

I haven't spent a ton of time on the Clojurians slack channel, or any big 
data Google groups, but there is a Clojure Datascience site/chat room that 
I host which has at least some activity. Most of the chatter there has been 
more on the side of statistics, machine learning, data viz and such, and 
less specifically on big data per se, but we'd welcome you to join and 
broaden the discussion: https://gitter.im/metasoarous/clojure-datascience. 
There's actually been an uptick in activity there since the Conj, and I'd 
love to see that momentum continue.

Good luck

Chris

On Wednesday, October 18, 2017 at 4:03:11 AM UTC-7, Ray Miller wrote:
>
> Hi,
>
> Here at Metail we have been using Clojure for medium-sized data processing 
> on AWS EMR. We started out with Cascalog about 5 years ago, switched to 
> Parkour 2 years ago, and are now considering a move to Spark.
>
> My question is: is Clojure still a good choice for medium/large data 
> processing on EMR?
>
> This is partly prompted by the lack of activity on the Github repos. Are 
> the Parkour, Flambo and Sparkling libraries rock solid, or simply not 
> getting enough use to trigger bugs and feature requests? 
>
> The #bigdata channel over on Clojurians slack is also suspiciously quiet, 
> as are many of the Google groups.
>
> Ray.
>

-- 
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: Clojurecademy: Learning Clojure Made Easy

2017-10-03 Thread Christopher Small


Concerns over licensing and user agreements and logins aside...

REALLY COOL WORK! I haven't dug deeply yet, but it seems you've built a 
framework for building Clojure based courses here, not just a fixed set of 
curriculum. And to this effort, bravo! I hope to see this become a very 
useful tool for teaching Clojure, and help bring more new programmers to 
the language.

I've actually been wondering what it might be like to build something like 
this for Cljs UI work. I know we have klipse and some related things, but 
something that packaged that together with some real course structure would 
be really phenomenal. Any ideas on that?

With gratitude

Chris


On Monday, October 2, 2017 at 2:37:28 PM UTC-7, Ertuğrul Çetin wrote:
>
> Hi Bost,
>
> It's important for courses, I mean once your course get updated you will 
> be notified, also you can continue to a course where you left off etc.
> Of course this site is not the only platform that you can learn Clojure, 
> it just has different approach. Also it is not just learning Clojure, with 
> powerful Clojurecademy DSL(
> https://clojurecademy.github.io/dsl-documentation/) Clojure developers 
> can create any course they want and you can learn Algorithms & Data 
> Structures, Data Science etc. in Clojure. It's related to content of course.
>
> Best,
>
> On Monday, October 2, 2017 at 10:30:01 PM UTC+2, Bost wrote:
>>
>> It looks like I can't learn clojure using your site unless I sign up 
>> with my email and such. 
>> Hmm... Until now I went pretty far with learning clojure without 
>> signing up anywhere. 
>> So what are your reasons for demanding a sign up? 
>> Thanks. 
>>
>>
>> 2017-10-02 18:47 GMT+02:00 Ertuğrul Çetin : 
>> > Hi everyone, 
>> > 
>> > I've created site called Clojurecademy which seems like Codecademy for 
>> > Clojure with powerful DSL to create courses. Feel free to provide 
>> feedback 
>> > so we can improve Clojure adoption together! 
>> > 
>> > Link: https://clojurecademy.com 
>> > 
>> > -- 
>> > 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: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Yup; I'm aware. That's what tipped me off. Didn't see the comment
mentioning OWL until I'd already posted, hence the second message.

Again, intriguied to look into this further now.

On Thu, Jul 13, 2017 at 2:01 PM, ru <soro...@oogis.ru> wrote:

> Christopher!
>
> OWL is extention of RDF.
>
> --Ru
>
> четверг, 13 июля 2017 г., 21:21:59 UTC+3 пользователь Christopher Small
> написал:
>
>> Are these ontologies as in RDF ontologies?
>>
>> On Monday, July 10, 2017 at 6:41:32 AM UTC-7, ru wrote:
>>>
>>> Hi,
>>>
>>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>>
>>> Integrated Development Environment for [rete4frames](https://github.c
>>> om/rururu/rete4frames) rule engine and expert system shell based on
>>> [Protege-3.5 ontology editor](http://protege.stanford.edu) supplemented
>>> with visual creation of algorithms. It combines two well-known paradigms of
>>> software development: algorithms for strictly defined processes and rules
>>> for fuzzy, fragmentarily defined processes and phenomenons.
>>>
>>> New feature: Algorithms.
>>>
>>> Algorithms are created using drag-and-drop of standard blocks from a
>>> palette on a canvas of a flow-chart and following connection them by stream
>>> lines. After that the standard blocks are filled with *Clojure* code as
>>> of "let" macro body.
>>> Important distinction of these algorithms from a common notion of
>>> algorithm in that they can represent *parallel processes*.
>>>
>>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/OG-kV8q9854/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Hah; This answers part of my question (had a tab open, and didn't see the 
"1 new pending message"). I've been vaguely curious about this project, and 
didn't realize there was a connection ideas from RDF. I'm interested to 
learn more now.

On Thursday, July 13, 2017 at 9:45:15 AM UTC-7, ru wrote:
>
> Arthur!
>
> By the way, I must notice that Protege exists in two flavors: 
> Protege-frames and Protege-OWL. Protege-frames historically precedes 
> Protege-OWL. Protege-OWL theoretically is more powerful, but from practical 
> point of view Protege-frames has more comprehensive application area (not 
> only my opinion). So, I develop this variant of Protege.
>
> Sincerely,
>Ru
>
> среда, 12 июля 2017 г., 21:58:11 UTC+3 пользователь art...@signafire.com 
> написал:
>>
>> Hey, this is pretty neat thanks for sharing. I've had to research 
>> Ontologies for work the last few weeks, it'll help to dive into the source. 
>> Very cool.
>>
>> On Monday, July 10, 2017 at 9:41:32 AM UTC-4, ru wrote:
>>>
>>> Hi,
>>>
>>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>>
>>> Integrated Development Environment for [rete4frames](
>>> https://github.com/rururu/rete4frames) rule engine and expert system 
>>> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
>>> supplemented with visual creation of algorithms. It combines two well-known 
>>> paradigms of software development: algorithms for strictly defined 
>>> processes and rules for fuzzy, fragmentarily defined processes and 
>>> phenomenons.
>>>
>>> New feature: Algorithms.
>>>
>>> Algorithms are created using drag-and-drop of standard blocks from a 
>>> palette on a canvas of a flow-chart and following connection them by stream 
>>> lines. After that the standard blocks are filled with *Clojure* code as 
>>> of "let" macro body.  
>>> Important distinction of these algorithms from a common notion of 
>>> algorithm in that they can represent *parallel processes*. 
>>>
>>> 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.

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Are these ontologies as in RDF ontologies?

On Monday, July 10, 2017 at 6:41:32 AM UTC-7, ru wrote:
>
> Hi,
>
> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>
> Integrated Development Environment for [rete4frames](
> https://github.com/rururu/rete4frames) rule engine and expert system 
> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
> supplemented with visual creation of algorithms. It combines two well-known 
> paradigms of software development: algorithms for strictly defined 
> processes and rules for fuzzy, fragmentarily defined processes and 
> phenomenons.
>
> New feature: Algorithms.
>
> Algorithms are created using drag-and-drop of standard blocks from a 
> palette on a canvas of a flow-chart and following connection them by stream 
> lines. After that the standard blocks are filled with *Clojure* code as 
> of "let" macro body.  
> Important distinction of these algorithms from a common notion of 
> algorithm in that they can represent *parallel processes*. 
>
> 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.

Re: How to implement a distributed and concurrent system in Clojure?

2017-07-01 Thread Christopher Small

There's an onyx-kafka plugin I believe, so you should be in luck!

On Fri, Jun 30, 2017 at 10:25 PM, Derek Troy-West 
wrote:

> I still have Storm topologies in prod, but I'm investigating Kafka Streams
> and Onyx right now.
>
>
> On Saturday, July 1, 2017 at 9:38:08 AM UTC+10, Bobby Calderwood wrote:
>>
>> Onyx is super cool, has matured substantially, and has a great team
>> behind it.
>>
>> I've also had success building with Kafka (and its ecosystem libraries
>> Kafka Connect and Kafka Streams) and Datomic.
>>
>> Cheers,
>> Bobby
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/4GRJVxctlU0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: How to implement a distributed and concurrent system in Clojure?

2017-06-30 Thread Christopher Small

I'd have to know a little bit more about the specifics of your message
driven architecture to say for sure, but in general I'd still highly
recommend Onyx over Storm. In the last two years the Distributed Masonry
crew have done a TON of fabulous work with Onyx, including closing the
performance gap (maybe someone can chime in here about the current sate of
that gap) by switching to Aeron for message passing (the old version used
HornetMQ I believe). It's also significantly more battle tested now, and
the team just recently got $500k for building out tooling and services
around Onyx. There are also quite a few new features, like improved
agregation support, and so on. They also implemented a runtime for onyx
jobs in cljc, meaning you can test out jobs locally without all the
overhead of firing up zookeeper! EVEN IN THE BROWSER! Imagine that;
dynamically building and testing (with small data) a distributed system in
the browser via some domain-specific UI, and then pushing it to the cluster
when you're ready to let her rip... Nothing like this exists for Storm or
any of the other competitors in this space. I've even heard some dashing
and enterprizing group of fellows are considering building a re-frame-esque
event-driven UI system using Onyx. Who knows? The future is bright.

Chris

PS; Conflict of Interest Disclaimer: I have recieved no moneys or favors
from Distributed Masonry for frequent and prefuse recommendation of their
products. They're just that cool.

On Fri, Jun 30, 2017 at 12:53 AM, Matan <dev.ma...@gmail.com> wrote:

> This thread is a bit old, but it's seen two year awakenings before... and
> still shows up high in google searches.
> I wonder how you folks see it now. Onyx is a bit older by now, and not
> much seems new out there. What would you choose for reliable and resilient
> distributed computing with clojure, if you had to start over at this time?
> in particular, for a message driven architecture not a streaming one.
>
>
> On Monday, July 20, 2015 at 3:52:44 AM UTC+3, Derek Troy-West wrote:
>>
>> We use Storm/Trident fairly extensively for distributed computation, it
>> has not been painless and the documentation is poor, however it does
>> perform well once you understand its peculiarities. I'm keeping an
>> interested eye on Onyx but my bandwidth is fairly limited at the moment.
>>
>> The only things I would add to your post are:
>>
>> * It's possible to write Storm and Trident topologies purely in Clojure,
>> in fact parts of Storm were originally written in Clojure. I'm not sure the
>> DSL were an afterthought, but I agree they are fairly impenetrable at
>> first. Storm has a large learning curve and lots of quirks, and the
>> documentation is pretty bad (in-fact, completely wrong in parts).
>>
>> * Storm is currently limited to Clojure 1.5.1, thought the latest beta
>> release has been updated to 1.6.0
>>
>> * Recently the momentum of the project appears to have picked up, but
>> certainly for a while there (just after apache incubation) it appeared a
>> bit stagnant. I presume they were busy settling the project in.
>>
>>
>> On Monday, July 20, 2015 at 3:11:24 AM UTC+10, Christopher Small wrote:
>>>
>>>
>>> I'll also add that if you're interested in the Storm model (distributed
>>> stream processing), you may want to check out Onyx (
>>> https://github.com/onyx-platform/onyx). It's newer, but I have a
>>> feeling that moving forward we're going to see it take a dominant position
>>> as far as that flavor of distributed computing goes. The reasons for this
>>> (briefly):
>>>
>>> * Data all the topologies: Because computational topologies are data
>>> structures, it's far simpler to have more dynamic computational workflows
>>> than with storms opaque macros.
>>> * It's more Clojure centric: Parts of Storm are Clojure, but the Clojure
>>> API seems almost an afterthought, reading the documentation. (However,
>>> support is on the way for other JVM languages).
>>> * Pace of development: Storm is now an Apache Incubator project, and
>>> development is slower than molasses. I was working on a project for over a
>>> year and many times encountered issues with stale dependencies that didn't
>>> play nicely with newer things.
>>> * Designed with batch processing in mind: Even though both are designed
>>> around streaming first, Onyx has a little more explicit support for batched
>>> computations.
>>>
>>> For a while, the biggest advantage of Storm was that it was a lot
>>> faster, but the gap there has closed considerably recently (perhaps
>>> entirely?). Storm is still

Re: Beginner: let with Java object

2017-05-26 Thread Christopher Howard

I restarted the Emacs CIDER REPL, and now it seems to work fine. Maybe I
just don't understand how to use this CIDER REPL properly.

On 05/26/2017 07:58 AM, Gary Trakhman wrote:
> There shouldn't be a difference, I would suspect a typo in your file.
> 
> The error 'ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)' would lead me to
> look for things like '(img)' where the object ends up in call position
> of the s-expression.
> 
> On Fri, May 26, 2017 at 11:54 AM Christopher Howard
> <christopher.how...@qlfiles.net <mailto:christopher.how...@qlfiles.net>>
> wrote:
> 
> When I run
> 
> tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
> (show img))
> 
> from the REPL, this returns a javax.swing.JFrame object, and displays
> the frame and image as expected. However, if put the same in
> 
> (defn -main
>   "Generates image."
>   [& args]
>   (let [img (new-image 32 32)]
> (set-pixel img 10 10 cyan)
> (show img)))
> 
> in more core.clj, and run (-main) from the REPL, I get error
> 
> ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)
> 
> Why the difference?
> 
> --
> https://qlfiles.net
> 
> --
> 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 - 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
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

-- 
https://qlfiles.net

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

Beginner: let with Java object

2017-05-26 Thread Christopher Howard

When I run

tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
(show img))

from the REPL, this returns a javax.swing.JFrame object, and displays
the frame and image as expected. However, if put the same in

(defn -main
  "Generates image."
  [& args]
  (let [img (new-image 32 32)]
(set-pixel img 10 10 cyan)
(show img)))

in more core.clj, and run (-main) from the REPL, I get error

ClassCastException java.awt.image.BufferedImage cannot be cast to
clojure.lang.IFn  tutorial.core/-main (core.clj:11)

Why the difference?

-- 
https://qlfiles.net

-- 
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 to Clojure

2017-01-12 Thread Christopher Small

I would _strongly_ recommend you consider HoneySQL over KormaSQL. Korma is 
based on macros, making it much more difficult to 
dynamically/programatically construct queries. HoneySQL by contrast is 
simply a translational layer from Clojure data structures to SQL queries, 
so the probablem of querying SQL databases is reduced to one of composing 
Clojure data structures. This is signifcantly more in line with the Clojure 
philosophy of being a "data-driven" programming language. Zach Tellman's 
talk Always be Composing (https://www.youtube.com/watch?v=3oQTSP4FngY) 
makes an excellent argument in this vein.

My 2c

Chris



On Thursday, January 12, 2017 at 11:43:17 AM UTC-8, (hash-map :new "to 
clojure" :need "assistance") wrote:
>
> Hi Dennis,
>
> Thanks very much for getting back to me - this sounds really good. I've 
> had a look at sqlkorma seems simple enough to get started working with.
>
> Once again, thanks very much most appreciated.
>
>
> On Tuesday, January 10, 2017 at 12:05:48 AM UTC, Dennis Roberts wrote:
>>
>> From what you've described, it seems as though it would be easy to build 
>> the server side of this application in Clojure.
>>
>> I found Clojure to be very easy to pick up. I won't say that the first 
>> few applications that I wrote in Clojure were great Clojure code, but it 
>> was easy for me to move from Java to Clojure.
>>
>> Ring is a good start. You might also want to check into some libraries 
>> built on top of  Ring such as https://github.com/weavejester/compojure 
>> and https://github.com/metosin/compojure-api. We've found compojure-api 
>> to be extremely handy.
>>
>> I haven't played with any AWS clients in Clojure, so I'm afraid I can't 
>> answer that question.
>>
>> Clojure does integrate well with relational databases in general. We're 
>> using PostgreSQL, but any database that has a JDBC driver available should 
>> be easy to use. You may want to check into some of the Clojure libraries 
>> that provide DSLs for generating SQL statements. I've tried 
>> http://sqlkorma.com/ and https://github.com/jkk/honeysql, and I've had 
>> fairly good luck with both of them.
>>
>> Dennis
>>
>> On Monday, January 9, 2017 at 4:06:30 PM UTC-7, (hash-map :new "to 
>> clojure" :need "assistance") wrote:
>>>
>>> Hi all!
>>>
>>> So, I'm new to Clojure! I'm coming in from a Java background and am 
>>> currently working on a project that has prompted me to have a look at 
>>> whether Clojure would be useful. 
>>> I have started by going through the "Brave Clojure" website and working 
>>> through the exercises and what I've seen has at many times just made me 
>>> smile at the (at least so far) intuitiveness, simplicity and power of the 
>>> language. My use case is this:
>>>
>>> A real time (sealed bid) auctioning system. We have a maximum number of 
>>> bids (example 100) that's set by the owner of the product. Our clients then 
>>> bid on the product. Once a bid is made, it's committed to a database and 
>>> the counter increments. The next bid is processed, and so on. Once the 
>>> maximum number of bids is reached, bidding stops. This auctioning system is 
>>> for a mobile application however the main code for the real time system 
>>> sits on a web server. The mobile app is a very thin client so simply makes 
>>> a call to the app server via an API which then processes that request (and 
>>> returns the result). 
>>>
>>> Requests are processed in order - so we're following a "first come first 
>>> serve" approach. If at any time a request is due to be processed and the 
>>> counter hits 100, all requests should gracefully "fail" and be blocked from 
>>> bidding. Now this is obviously possible in Java, albeit with a lot more 
>>> code and thinking about the different ways to make everything thread-safe, 
>>> etc. This is a completely new project so there's no restriction on 
>>> languages to be used, etc. PS: We're all Java developers.
>>>
>>> I was really attracted to Clojure because of a) the JVM b) the fact that 
>>> it seems to be able to handle concurrency effortlessly c) our API needs to 
>>> scale and so we want to ensure that we can handle the 100K+ connections 
>>> easily when the project reaches that stage. Obviously this is more to do 
>>> with the hardware, but the way we build the API is a definite factor. 
>>> Finally, there seems to be less verbose codebases on Clojure and it might 
>>> help to keep our overall codebase light and readable! 
>>>
>>> My questions therefore are these:
>>>
>>> With the time we have (around 1 month for this stage), is this something 
>>> we can easily build in Clojure?
>>> Is the movement from Java to Clojure easy for someone completely new to 
>>> Clojure?
>>> Are the libraries that we might use for this - I had a look at Ring 
>>> briefly robust for our use case?
>>> Does Clojure have good support for using AWS for example? (You can call 
>>> Java from Clojure so I guess this wouldn't really be an issue.)
>>> Does it interface well with

Re: Saving / Loading a Datascript DB

2016-09-27 Thread Christopher Small

This should be pretty easy. You can use `datascript.core/datoms` to produce 
a sequence of datoms which you serialize as EDN, CSV or (gasp) JSON. For 
reading back in, you can use `datascript.core/conn-from-datoms`.

Chris


On Monday, September 26, 2016 at 5:15:16 AM UTC-7, Wukong Sun wrote:
>
> Hi,
>
>   Is there a easy way to save/load a datascript DB to file?
>
>   I'm not looking to use datomic. I just need a way to save my datascript 
> db to file and to read it later.
>
> Thanks!
>

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

Re: Encapsulating Sub-Systems with Protocols

2016-09-15 Thread Christopher Small

I've used protocols this way. In fact, this pattern meshes quite well with 
Stuart Sierra's Component lib/pattern. By building system components around 
protocols, subsystems/components can be made swappable. This is rather 
integral to the current design of Datsys actually.

Of course, as other's have pointed out, whether this is worth while is 
totally dependent on whether or not you actually need that kind of 
polymorphism. But if you do, it's a great way to go.

Chris


On Thursday, September 15, 2016 at 1:21:43 PM UTC-7, Cameron Barre wrote:
>
> Has anyone used protocols to create explicit boundaries between the bigger 
> pieces of their systems? We want to track/control the interactions between 
> these sub-systems and are considering using protocols to define public 
> APIs. Is this good practice? Would it be better to simply create our API 
> like a normal library and be explicit about which functions are part of the 
> public API? 
>

-- 
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

2016-08-20 Thread Christopher Small

I couldn't help myself...

https://xkcd.com/1172/


-- 
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: Preparing proposal for presentation on replikativ

2016-08-02 Thread Christopher Small

Hi Christian

Would love to see this talk (embarrassed I still haven't watched the video 
you posted in Gitter though...).

As you'd suspect, I'm definitely like to see a good bit on 
DataScript/Datomic. Aside from that, I think a good focus on the strengths 
and weakness (/challenges/work-to-be-done) would be very informative, and 
help illustrate some of the implications of the approach. In particular, 
challenges in dealing with larg(ish) data sets and/or data that changes 
very frequently are very interesting.

Cheers, and good luck :-)

Chris



On Monday, August 1, 2016 at 4:57:44 AM UTC-7, Christian Weilbach wrote:
>
> Hi, 
>
> I would like to present replikativ at the EuroClojure 2016 conference 
> (1). I would talk about the motivation and how it is implemented 
> (core.async, the foundational libraries, integration with 
> DataScript...). There is the background theory of CRDTs, the general 
> problem of data replication and synchronization, the particular case of 
> DataScript/Datomic replication, mobile or web frontend development etc. 
> I will have to focus on some aspects. Do you have any particular 
> interests I should address? 
>
> Best, 
> Christian 
>
> (1) https://github.com/replikativ/replikativ 
>
>

-- 
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: where to find clojure gigs?

2016-07-13 Thread Christopher Small

In my experience, these sites don't frequently have much short-term 
contract work, but they do every now and again. I've found for shorter term 
projects, networking is the way to go. Hit up all the events you can and 
make connections, when people need an extra hand let them know how they can 
get in touch. Takes a bit of work, but that's what has been most fruitful 
for me.



On Wednesday, July 13, 2016 at 3:07:30 PM UTC-7, Alan Thompson wrote:
>
> Try these:
>
>
>- https://functionaljobs.com/
>- https://jobs.braveclojure.com/
>- https://clojurians.slack.com/messages/jobs/details/
>- http://stackoverflow.com/jobs
>
>
> Also, make sure you list clojure and related tech you know when posting to 
> Monster, Indeed, CareerBuilder, StackOverFlow/jobs, LinkedIn, GlassDoor, 
> etc.
>
>
> On Wed, Jul 13, 2016 at 1:59 PM, ojito  
> wrote:
>
>> I'm looking for short term clojure gigs to work on? Does anyone know 
>> where to find such gigs or know anyone who needs some clojure work done?
>>
>> -- 
>> 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: [ANN] Nightcode 2: Total Rewrite

2016-07-13 Thread Christopher Small

OMG. Thank you for this brilliant introduction. And of course all your hard 
work, as well :-)


On Wednesday, July 13, 2016 at 7:35:53 PM UTC-7, Zach Oakes wrote:
>
> As I understand it, the Boot.java I linked to basically does that. You 
> just run its main function and it takes care of downloading Boot to the 
> right spot and invoking it.
>
> On Wednesday, July 13, 2016 at 10:18:05 PM UTC-4, Colin Fleming wrote:
>>
>> What I do for Leiningen in Cursive is basically mimic what the lein 
>> script does, and download the uberjars to .lein/self-installs, and then run 
>> processes with those on the classpath. Would something similar for Boot 
>> work? As I understand it, boot.sh is just a tricky wrapper around an 
>> embedded jar, so hopefully that would work. I'm also selfishly interested 
>> in this because I don't support boot yet but I want to.
>>
>> On 14 July 2016 at 14:12, Zach Oakes  wrote:
>>
>>> If I get desperate I may do that, but the main users I care about are 
>>> beginners, and they generally have trouble installing CLI tools. I'm hoping 
>>> it is a trivial fix and I'll be able to get Boot working in 2.1.0 :)
>>>
>>> On Wednesday, July 13, 2016 at 9:44:50 PM UTC-4, Mark wrote:

 How about, until the issues are resolved, you require boot to be 
 installed?
 On Jul 13, 2016 6:52 PM, "Zach Oakes"  wrote:

> That Boot tab is quite a tease ;) I wanted to finish support for it so 
> bad, but technical difficulties prevented me from doing it. I definitely 
> plan to still do so, and any help would be appreciated.
>
> The issue is actually pretty simple: I need to be able to call Boot 
> commands without having Boot installed. I do so for Leiningen by 
> literally 
> adding it as a dependency and calling its build commands programatically. 
> Boot simply isn't designed to work that way.
>
> After talking to the Boot folks, they suggested I add Boot.java 
>  to 
> my project and start a process that calls its main method with the 
> appropriate task names. Easy enough, but that does not actually work. It 
> turns out that AOT compilation causes this java file to not behave 
> correctly.
>
> If anyone is interested in investigating this, I created a minimal 
> case for this issue here: https://github.com/oakes/boot-clj-issue
>
> Once that is resolved, it will be pretty trivial to enable building 
> Boot projects.I actually would like to make the built-in templates use 
> Boot 
> by default instead of Leiningen. Boot scripts in particular will be 
> awesome 
> for beginners.
>
> On Wednesday, July 13, 2016 at 6:44:01 PM UTC-4, Sean Corfield wrote:
>>
>> I see a Boot tab in the REPL area but looking at the source code, 
>> detecting build.boot is disabled (and, indeed, I can’t get NC to 
>> recognize 
>> any of my Boot-only projects).
>>
>>  
>>
>> Can you speak to where you are on Boot support?
>>
>>  
>>
>> Thanks,
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>>
>> On 7/13/16, 10:58 AM, "Zach Oakes" > behalf of zso...@gmail.com> wrote:
>>
>> TL;DR: Nightcode, a Clojure IDE, just got a makeover: 
>> https://sekao.net/nightcode/
>>
>>  
>>
>>  
>>
>> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient 
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To

Re: [ANN] walmartlabs/datascope 0.1.0

2016-06-27 Thread Christopher Small


Well done! This looks awesome. Can't wait to try it!

Chris



On Monday, June 27, 2016 at 10:57:56 AM UTC-7, Howard M. Lewis Ship wrote:
>
>
> A library that can be used to render typical Clojure data structures using 
> Graphviz.
>
> https://github.com/walmartlabs/datascope
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
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: IoT: Clojurescript -> Jerryscript?

2016-05-27 Thread Christopher Small

I imagine this should be possible, as long as JerryScript isn't missing any 
features needed by the js code the cljs compiles to. I'd bet most code 
would be fine, as long as it doesn't depend on OS features. So I would Just 
Try It with a simple hello world app and see how complicated you can get 
from there.

I started a project that was trying to provide a microcontroller computing 
API abstracting over the subtle differences between different targets 
(BeagleBone, Pi, and Arduino over Firmata). The biggest issue with this is 
that JVM Clojure is a sluggard to boot, and for some microcontroller units 
too memory-hungry. And of course having to use Firmata with Arduino is a 
major restriction. In talking with others about this, I thought that 
targeting node would be a perfect solution for BeagleBone or Pi, but being 
able to directly target Arduino (w/o Firmata) would be awesome :-)

I haven't had any time for this project with other open source things on my 
plate, but I'd be happy to provide guidance if you're interested in working 
on implementations of this API targeted at Jerryscript.

https://github.com/clj-bots/pin-ctrl

Cheers :-)

Chris

On Friday, May 27, 2016 at 9:33:17 AM UTC-7, Gregg Reynolds wrote:
>
> Hi folks,
>
> I just came across http://samsung.github.io/jerryscript/ , which Samsung 
> apparently open-sourced last fall.  Jerryscript is a bit of a misnomer, its 
> not a language but a JS engine designed for IoT devices.  Sorta like 
> node.js only smaller, I guess.
>
> Seems to run on Zephyr on Arduino101 
> ,
>  
> believe it or not.
>
> If we can run JS on constrained IoT devices, then we ought to be able to 
> write the code in Clojurescript, no?
>
> Anybody have any further info on this?  I'm going to be looking at the 
> Clojurescript source this weekend to try to get an idea of how hard it 
> would be to target Jerryscript (or iot.js, which is a companion thing).  
> Any advice/help would be appreciated.
>
> Thanks,
>
> Gregg
>

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

Re: Clojure docstring style

2016-05-15 Thread Christopher Small


Seems like this shouldn't be a problem as long as you only try to render a 
link if there's actually such a var. This might be a little messier, but 
would make things (overall) nicer (I think) because you wouldn't have to 
think about a separate bit of syntax. The rendering would just happen 
differently depending on whether or not there was something to link to. I 
already do markdown in most of my docstrings anyway, and I'd prefer not 
having to rewrite a bunch of docstrings to take advantage of such a 
feature; I'm sure there are others with me as well :-)

This arguably violates least-surprise / separation of concerns, but in my 
opinion not so significantly that the costs outweigh the benefits (again, 
as long as you only tried to link if you knew it was a var).

My 2 cents...

Chris


On Sunday, May 15, 2016 at 2:03:02 PM UTC-7, James Reeves wrote:
>
> If the docstrings are written in markdown, this would conflict as 
> something in backticks isn't necessarily a var name.
>
> In Codox, I used the wiki-link style: [[clojure.core/map]].
>
> - James
>
> On 15 May 2016 at 18:40, cskksc  wrote:
>
>> Hello,
>> We are working on a new feature in CIDER which would parse a docstring 
>> and create hyperlinks that follow the functions/vars/interop-forms 
>> mentioned there.
>> It is very similar to the "See Also" links shown by ClojureDocs 
>> . Right now, we are using backticks to identify 
>> the reference forms and create links.
>>
>> So a function like;
>>
>> (defn test-mde
>>   "Does something with `user-ns/user-fn`.
>>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>>   []
>>   (+ 1 1))
>>
>> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>>
>> What style do you tend to use in such docstrings ?
>> It would help us figure out whether to continue with the backticks or do 
>> something else, like adding a configuration variable for this.
>>
>> Thanks,
>> Chaitanya
>>
>> -- 
>> 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.

[ANN] Datsync: Datomic <-> DataScript syncing utilities

2016-05-04 Thread Christopher Small

Greetings

I'm happy to announce an early SNAPSHOT release of Datsync, a
Clojure(script) library for syncing Datomic and DataScript databases.

Github: https://github.com/metasoarous/datsync
Coordinates: [datsync "0.1.0-SNAPSHOT"]

The library is built around a small handful of functions for translating
transaction data between Datomic and DataScript. At the moment, all that is
supported out of the box (without a bit of thinking on your part) is whole
DB replication and sync, with all writes going through Datomic before
getting sent out clients.

Our near term goals for the project include:

* additional utilities for handling read/write authorization and efficient
partial syncing
* offline DataScript availability (true bidirectional sync)

Some other resources:

* My Clojure West talk about Datsync and some of the patterns it enables:
https://www.youtube.com/watch?v=aI0zVzzoK_E
* Catalysis; an example Datsync + Posh application template:
https://github.com/metasoarous/catalysis
* Posh; a wonderful library for implementing declarative re-frame style
signal graphs as DataScript queries (currently Reagent only, but soon will
support Rum, Quiescent, etc): https://github.com/mpdairy/posh


Hope you enjoy :-)

Chris Small

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

2016-03-15 Thread Christopher Small

Ditto; same boat as Mars0i.

I think the work Dragan has done is wonderful, and that he bears no 
responsibility to implement the core.matrix api himself. I'm also 
personally not interested in touching it without core.matrix support, 
because similarly for me, the performance/flexibility tradeoff isn't worth 
it. I wish I had time to work on this myself, since it would be an awesome 
contribution to the community, but I just don't have the time right now 
with everything else on my plate (including a 1 year old (figurative plate, 
obviously)). So I would highly encourage anyone interested in numerical 
computing and clojure looking for a project to sharpen their teeth on to 
put some time here. I think it would be a real asset to the community.

The one thing I *would* like to as from you, Dragan, is that you help us 
(well, Mike perhaps more than anyone) understand what you really don't like 
about the core.matrix architecture. In previous threads where we've 
discussed this, I felt like nothing concrete ever came up. You seem to not 
like that the fact that the API doesn't mirror BLAS, and I get your 
thinking here (even if I don't necessarily agree). Is that really the 
extent of it, or did I miss something?

It was mentioned that core.matrix has a BLAS-style API ns, but you still 
seem uninterested in this, since those functions delegate to a non-BLAS 
API. If I'm right, your concern is that this would lead to leaky 
abstractions, and affect performance, yes? I haven't looked at this API or 
it's implementation, but I have an idea that might satisfy everyone. What 
if it were possible to specify a core.matrix implementation directly 
through the BLAS API, with the rest of the "standard" core.matrix API based 
off these functions (by default; custom implementations could still be 
provided I'm sure...)? (Does this seem doable Mike?) Could this get us the 
best of both worlds and make core.matrix look more attractive to you Dragan 
(even if you don't feel personally interested in working on the 
Neanderthal/core.matrix implementation yourself)? Those who want and know 
the BLAS API can use it, without any overhead or leakiness, and everything 
would remain interoperable with other libraries. If this still wouldn't do 
it, what would? You clearly have very deep knowledge in this subject, and I 
think I speak for the Clojure numerical computing community (and 
core.matrix community in particular) in expressing that we'd greatly 
appreciate any insights you can give which would help make the ecosystem as 
a whole better.

With gratitude

Chris

On Tuesday, March 15, 2016 at 6:42:45 AM UTC-7, Bobby Bobble wrote:
>
> I'm in the same boat as Mars0i in that I've written a load of code with 
> core.matrix, which I'm happy with and which I will never have time to 
> rewrite for Neanderthal. If I had a new project that was 
> performance-critical I might bother to learn Neanderthal but for my 
> existing project, speed is secondary to maintainability now. If my boss 
> asked me to speed it up by 60x I'd love to be able to just switch to 
> implementation :Neanderthal with core.matrix! One keyword and boom.
>
> On Tuesday, March 15, 2016 at 3:54:03 AM UTC, Mars0i wrote:
>>
>> Dragan, I still support you doing whatever you want with your time, and 
>> I'm grateful that you've produced was I gather is a great library.  
>> Wonderful.  I don't feel that you have to implement the core.matrix 
>> api--but I really, really wish someone would produce a core.matrix 
>> interface to Neanderthal.  (I don't know how difficult that will be; I just 
>> know that I'm not the right person to do it.)  
>>
>> Some of the following has been said before, but some the points below 
>> seem to have been lost in the current discussion.
>>
>> I want to try Neanderthal, but I may never do so until someone produces a 
>> core.matrix mapping.  That needn't be a problem for you, Dragan, but my 
>> time is too precious to reimplement my existing code for a new api.  Even 
>> with new code, I'm always going to prefer core.matrix in the foreseeable 
>> future unless I have very special needs, because being able to swap out 
>> implementations is just too convenient for me.  core.matrix allows me to 
>> easily figure out which library is most efficient in my application.  I 
>> also want there to be a standard api for matrix operations, and at this 
>> point, core.matrix is the standard imo.  
>>
>> I came to Clojure from Common Lisp, where there are 5-10 matrix libraries 
>> with different APIs and different efficiency profiles, several seemingly 
>> best for different purposes (the Curse of Lisp mentioned by Mikera, applied 
>> to our case).  I am just very grateful that, instead of CL's mess of 
>> libraries and APIs, in the Clojure world Mikera and others decided to 
>> construct a standard API for matrix implementations.  What he's promoting 
>> is not marketing, nor religion--it's just convenience and coherence.  It's 
>> part of what

Re: [ANN] Inlein 0.1.0

2016-03-14 Thread Christopher Small

Wonderful! I love this approach and will probably use this for future 
scripting tasks.

I know that planck (http://planck-repl.org/) has successfully achieved cljs 
scripting capacity on OSX (and I've heard there's progress on Linux support 
as well, but am fuzzy on the details). Do you think support for planck or 
something similar might be achievable through inlien? This would make it an 
attractive candidate for snappy, short-lived scripting tasks as well.

With gratitude

Chris

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

2016-03-09 Thread Christopher Small

Sounds great; and sure thing, will do :-)

The basic idea I had was to implement a bidirectional index mapping names
<-> indices. This requires making sure you keep the index up to date any
time you change the data, but seemed the easiest way forward.

My fork is here: https://github.com/metasoarous/core.matrix/commits/develop

Here are a couple of related issues:

https://github.com/mikera/core.matrix/issues/193
https://github.com/mikera/core.matrix/issues/220

Hope you can come up with something nice!

I would focus first on coming up with what seems like a nice set of
protocols, so that we can be flexible with implementations. Ideally, we'd
be able to just apply some wrapper to any core.matrix array, vector,
matrix, etc that provided named/labeled access to the data, and would be
fairly seamless with the rest of the library. But you should also be able
to wrap something like Renjin's dataframes (as Daniel Slutsky mentioned;
just implement the protocols using their classes, I imagine). There might
have to be some iteration here. Like: initial protocol design -> initial
implementation -> redraft potocols -> try new implementation -> redraft
protocols, etc. I've noticed that it can be difficult to properly abstract
implementation details away from the protocol/API on the first go (though
you might have mastered this more than I :-)).

My 2c

Goodluck!

Chris



On Wed, Mar 9, 2016 at 4:29 PM, <arthur.maciejew...@gmail.com> wrote:

> Chris, thanks for the reply.
>
> It's good to know that I'm not the only one who misses this functionality!
> My goal is definitely to be compatible with Incanter and core.matrix, as
> they both seem mature, and I will never have the time to implement that
> functionality from scratch myself. I'll be studying the source of Pandas
> over the next few days, as I want to have a good idea of how they implement
> their dataframes before starting on the Clojure version. My long-term goal
> is for future authors to look to this set of core tools for data analysis
> as the basis for any packages they build.
>
> If you'd like to publish whatever you've written (hacked up code is ok),
> I'll take a look at that as a starting point, or at least as one possible
> design.
>
> - Arthur
>
>
>
> On Wednesday, March 9, 2016 at 6:47:44 PM UTC-5, Christopher Small wrote:
>>
>>
>> If you're going to do any work in this area, I would highly encourage you
>> to do in as part of the core.matrix library. That is what Incanter is or
>> will be using for it's dataset implementation. But it's nice that those
>> abstractions and implementations be separate from Incanter itself, since
>> Incanter is a rather large dependency.
>>
>> Core.matrix is certainly (in my eyes) becoming the de facto matrix
>> computation library in the Clojure ecosystem, and I think in the level of
>> interop between different implementations there, and extent of utilization
>> by the clojure community, we rival the python offerings. However, while
>> core.matrix has some dataset protocols, api functions and basic
>> implementations, there's still some work to get the full expressiveness of
>> the data.frame pattern as seen in R and Pandas. Specifically, there is no
>> support for setting rownames (or arbitrary "name" assignments beyond that
>> of a single dimension (columns...)). This is something I started working on
>> a while back, but wasn't able to finish. I could potentially push what I
>> came up with to a fork, but unfortunately, I don't have any more time to
>> work on the problem at the moment.
>>
>> Mike Anderson is a great project maintainer, and will probably be happy
>> to help guide you in stitching together a solution.
>>
>> Best
>>
>> Chris
>>
>>
>>
>>
>>
>> On Wednesday, March 9, 2016 at 12:57:31 PM UTC-8, arthur.ma...@gmail.com
>> wrote:
>>>
>>> Is there any desire or need for a Clojure DataFrame?
>>>
>>>
>>> By DataFrame, I mean a structure similar to R's data.frame, and Python's
>>> pandas.DataFrame.
>>>
>>> Incanter's DataSet may already be fulfilling this purpose, and if so,
>>> I'd like to know if and how people are using it.
>>>
>>> From quickly researching, I see that some prior work has been done in
>>> this space, such as:
>>>
>>> * https://github.com/cardillo/joinery
>>> * https://github.com/mattrepl/data-frame
>>> *
>>> http://spark.apache.org/docs/latest/sql-programming-guide.html#dataframes
>>>
>>> Rather than going off and creating a competing implementation (
>>> https://xkcd.com/927/), I'd like to know if anyone here is active

Re: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)

2016-03-09 Thread Christopher Small

If you're going to do any work in this area, I would highly encourage you 
to do in as part of the core.matrix library. That is what Incanter is or 
will be using for it's dataset implementation. But it's nice that those 
abstractions and implementations be separate from Incanter itself, since 
Incanter is a rather large dependency.

Core.matrix is certainly (in my eyes) becoming the de facto matrix 
computation library in the Clojure ecosystem, and I think in the level of 
interop between different implementations there, and extent of utilization 
by the clojure community, we rival the python offerings. However, while 
core.matrix has some dataset protocols, api functions and basic 
implementations, there's still some work to get the full expressiveness of 
the data.frame pattern as seen in R and Pandas. Specifically, there is no 
support for setting rownames (or arbitrary "name" assignments beyond that 
of a single dimension (columns...)). This is something I started working on 
a while back, but wasn't able to finish. I could potentially push what I 
came up with to a fork, but unfortunately, I don't have any more time to 
work on the problem at the moment.

Mike Anderson is a great project maintainer, and will probably be happy to 
help guide you in stitching together a solution.

Best

Chris

On Wednesday, March 9, 2016 at 12:57:31 PM UTC-8, arthur.ma...@gmail.com 
wrote:
>
> Is there any desire or need for a Clojure DataFrame?
>
>
> By DataFrame, I mean a structure similar to R's data.frame, and Python's 
> pandas.DataFrame.
>
> Incanter's DataSet may already be fulfilling this purpose, and if so, I'd 
> like to know if and how people are using it.
>
> From quickly researching, I see that some prior work has been done in this 
> space, such as:
>
> * https://github.com/cardillo/joinery
> * https://github.com/mattrepl/data-frame
> * 
> http://spark.apache.org/docs/latest/sql-programming-guide.html#dataframes
>
> Rather than going off and creating a competing implementation (
> https://xkcd.com/927/), I'd like to know if anyone here is actively 
> working on, or would like to work on a DataFrame and related utilities for 
> Clojure (and by extension Java)? Is it something that's sorely needed, or 
> is everybody happy with using Incanter or some other library that I'm not 
> aware of? If there's already a defacto standard out there, would anyone 
> care to please point it out?
>
> As background information:
>
> My specific use-case is in NLP and ML, where I often explore and prototype 
> in Python, but I'm then left to deal with a smattering of libraries on the 
> JVM (Mallet, Weka, Mahout, ND4J, DeepLearning4j, CoreNLP, etc.), each with 
> their own ad-hoc implementations of algorithms, matrices, and utilities for 
> reading data. It would be great to have a unified way to explore my data in 
> the Clojure REPL, and then serve the same code and models in production.
>
> I would love for Clojure to have a broadly compatible ecosystem similar to 
> Python's Numpy/Pandas/Scikit-*/Scipy/matplotlib/GenSim,etc. Core.Matrix and 
> Incanter appear to fulfill a large chunk of those roles, but I am not aware 
> if they've yet become the defacto standards in the community.
>
> Any feedback is greatly 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: ANN replikativ 0.1.0 - strong eventual consistent P2P replication for clj and cljs

2016-01-22 Thread Christopher Small

Replicative lets you distribute state, so any time you'd like a distributed 
system to be able to share state, this is something you could consider to 
do that. In particular, every web application is a distributed system, so 
it's something you could use any time you wanted eventually consistent 
state between server(s) and clients. So the real question is what shared 
state offers.

If you're not doing shared state, you're probably doing something where you 
send messages through some remote transactor that (ideally) ensures 
consistency of the system. But that means two things:

* You can't be working offline (at least, not without a lot of work that 
starts to look like ad-hoc distributed state)
* If you want optimistic UI updates (good for responsiveness & UX), you 
have to figure out how to undo UI updates if those transactions fail

Replicative solves both of these problems. You can work offline on your 
copy of the data, and then when you're able to reconnect, it does a "merge" 
(analogous to a git merge). Ideally, the merge is clean and the remotes get 
copies of the work you did, and everyone is happy. But, if there are any 
kind of conflicting changes that need to be merged, you have to go through 
history conflict resolution process, again, quite like you would have to in 
git.

So in very broad strokes, replicative is sort of like auto-synced git for 
application data.

Chris

On Thursday, January 21, 2016 at 9:00:28 PM UTC-8, Teemu Kaukoranta wrote:
>
> Thank you, this looks immensely interesting! I'm still having trouble 
> understanding when exactly one should use replikativ; are you saying it 
> will make it easier to build offline applications? 
>
> There's two things that make this difficult to understand: its academic 
> nature, and the fact that many of us are just so used to the central server 
> that it's hard to imagine anything else. 

-- 
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 replikativ 0.1.0 - strong eventual consistent P2P replication for clj and cljs

2016-01-22 Thread Christopher Small

Can you listen for changes on a server store?

Also, have you developed a mechanism for just sharing parts of a 
distributed data structure?

Chris




On Tuesday, January 19, 2016 at 12:28:28 PM UTC-8, Christian Weilbach wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> Hello, 
>
> after three years of laying ground-work for a cross-platform database 
> in form of many libraries (1), doing research about CRDTs and 
> stretching core.async and other libraries as far as possible, I am 
> happy to finally announce a first release of replikativ: 
>
> replikativ is a replication system for confluent replicated data types 
> (CRDTs). It is primarily designed to work as a decentralized database 
> for web applications, but can be used to distribute any state durably 
> between different peers with different runtimes (JVM, js atm.). 
> Instead of programming thin web-clients around a central server/cloud, 
> you operate on your local data like a native application both on 
> client- and (if you wish to) server-side. You can also view it in 
> reverse as a cloud being expanded to all end-points. You can write to 
> CRDTs whenever you want and also access values whenever you want no 
> matter if the remote peer(s) (servers) is available or not. In 
> combination with our CDVCS datatype you can imagine it as git for data 
> (expressed e.g. in edn) + automatic eventual consistent replication. 
>
> https://github.com/replikativ/replikativ 
>
>
> While there are still some issues and the design is not completely 
> finished, I am pretty confident from our different design iterations 
> and our running prototype that the current one can avoid 
> race-conditions and is robust to errors. The interesting standard 
> CRDTs are still missing, but I decided to first hear some feedback 
> before growing the codebase and implementing optimizations. 
>
> Let's build more open systems and share data, 
> Christian 
>
> (1) https://github.com/replikativ/ 
>
> P.S.: The prototype https://topiq.es is currently hosted on a home 
> server, if it loads too slowly, I will move it, but so far I felt a 
> bit romantic about my basement and didn't want to spend money for an 
> AWS instance or something else. Feel free to host your own instances 
> and to connect them ;), it should be straightforward. 
> -BEGIN PGP SIGNATURE- 
> Version: GnuPG v2.0.22 (GNU/Linux) 
>
> iQEcBAEBAgAGBQJWnpxRAAoJEKel+aujRZMk/uUIAMbAHVHOo0zNbbRr6QsapiLN 
> ohQHTVqixkj/8qS3+z6ZmEGy572t2DH+QzXpHOqtqAS3mxGMikFKk078yWAYD3W3 
> QbZoxssDjgu/CGWsGAjuUetd8DoI1vI1T1oAVTo4IDo9uot5NEDHs3s5ZLB50NIX 
> WOjm/muSPwkTt6B+oIp8ZsEYCH6RyLzTqkK6rOXxF0OoPv2XuK+TMgQJVzskmiaI 
> 59Yf1TLizERN6DpyZbtFrWiVlgFF0+0K7GyW1qa7Bp7Yf9LE9yGra2WMjRwDdg7z 
> 3SbZb5aXc/yaGztu+yN0wq3BWFCRSZQ9fh+VjrltGMA9BfExr53/aed1bIIcAtY= 
> =v65c 
> -END PGP SIGNATURE- 
>

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

Re: clojure, not the go to for data science

2015-12-19 Thread Christopher Small

You're quite welcome; I was happy to add your work there :-) It's always
wonderful seeing folks using Clojure for scientific research. I'm happy to
add similar showcasings to the list.

I should add that I've been wanting to make it easier for folks to submit
suggestions through the site, and add interactive features, but I've been a
bit busy. If anyone else is interested in contributing, I'd be grateful.

Cheers

Chris



On Sat, Dec 19, 2015 at 11:31 AM, Boris V. Schmid <boris.sch...@gmail.com>
wrote:

> Just noticed one of my research paper made it to the showcase :-). Thanks
> for that!
>
> As for clojure resources: I have been mainly used clojure itself, and
> visualization libraries, (incanter, quil and gg4clj [to make plots in R
> with ggplot2, but you can use it to run any R code]), and sometimes a stray
> java library for smoothing or clustering things. The inter-op with java is
> often not too bad. I use light table as an IDE.
>
> Boris
>
>
> On Thursday, April 9, 2015 at 3:17:44 AM UTC+2, Christopher Small wrote:
>>
>> Made some updates to http://clojure-datascience.herokuapp.com/. In
>> particular, went with the tagline "Resources for the budding Clojure Data
>> Scientist." Couldn't come up with anything else sufficiently punny and
>> appropriate.
>>
>> Again; please contribute! I'll be starting a list in the about page
>> mentioning everyone who's contributed.
>>
>> Chris
>>
>>
>> On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:
>>>
>>> Clojure isn't the first tool coming into mind on data science at the
>>> moment but the number of useful libraries are growing up. You can check out
>>> https://github.com/razum2um/awesome-clojure#science-and-data-analysis.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Procedurally generated animation in Clojure

2015-11-11 Thread Christopher Small

Oh; and nice work Mike! :-)

Chris


On Wednesday, November 11, 2015 at 8:48:22 AM UTC-8, Christopher Small 
wrote:
>
> If you haven't tried it in a while, you may want to look again. They've 
> created an alternate API or mode which is more functional/immutable. 
> Perhaps that _is_ what you saw though, and you're just referring to the 
> mutable Java underpinnings leaking through...
>
> My 2c
>
> Chris
>
>
> On Tuesday, November 10, 2015 at 12:22:01 PM UTC-8, Mars0i wrote:
>>
>> Cool.  Thanks.  I experimented with the quil 
>> <https://github.com/quil/quil> wrapper around Processing 
>> <https://processing.org/> at one point.  I'm glad quil exists, but the 
>> underlying non-functional-programming model of Processing can sometimes 
>> make it awkward.
>>
>

-- 
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: Procedurally generated animation in Clojure

2015-11-11 Thread Christopher Small

If you haven't tried it in a while, you may want to look again. They've 
created an alternate API or mode which is more functional/immutable. 
Perhaps that _is_ what you saw though, and you're just referring to the 
mutable Java underpinnings leaking through...

My 2c

Chris


On Tuesday, November 10, 2015 at 12:22:01 PM UTC-8, Mars0i wrote:
>
> Cool.  Thanks.  I experimented with the quil 
>  wrapper around Processing 
>  at one point.  I'm glad quil exists, but the 
> underlying non-functional-programming model of Processing can sometimes 
> make it awkward.
>

-- 
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: complex numbers in clojure

2015-11-02 Thread Christopher Small

I'll just add that core matrix complex doesn't prevent you from using
rationals, as most of the math happens on real/imaginary matrix pairs.
However, any time you try to return a scalar value (not a matrix), it wraps
the result using the alanforr library, so you'd be potentially restricted
there, though I'm not sure if the alanforr library would automatically cast
or error out. If someone came up with another complex library, it probably
wouldn't be too hard to make that swappable, just as the underlying matrix
implantations are presently (in core.matrix.complex).

Chris

On Mon, Nov 2, 2015, 7:03 AM 'Alan Forrester' via Clojure <
clojure@googlegroups.com> wrote:

> On 2 Nov 2015, at 13:11, Grahack  wrote:
>
> > I'm resurrecting this thread in case there is something new that
> happened concerning complex numbers that was not logged here.
> > So was there some progress made?
> >
> > I also wanted to add that mixing rationals and complex wuold be super
> cool, like:
> >
> > (* 1/2 i) => i/2)
>
> There is now a complex number library that  the Java commons-math3 Complex
> library:
>
> https://github.com/alanforr/complex/.
>
> This library does not mix rationals and complex since the underlying Java
> library uses doubles.
>
> Mike Anderson has written a complex matrix library:
>
> https://github.com/mikera/core.matrix.complex.
>
> Alan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/lY1r6zw6LeU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Chris

Sent via mobile

-- 
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: Trying to understand Clojure/Java concurrency performance?

2015-10-08 Thread Christopher Small

I'd just like to point something which may have been glossed over from 
Timothy's post (and now Andrey's as well).

> ... if you're doing actual processing, handling that many connections on 
a box seems like premature optimization.

> Have the ability to handle 2M persistent connections does not depends 
only on the server/language and how they handle the "hello world" 
request/response, where are other players in the equation: persistence and 
your business logic, operating system tuning, virtual/bare metal hardware, 
network hardware...

If you're interested in the question of a maximum number of connections 
from a purely theoretical standpoint, then great; it's an interesting 
question. But if you're really thinking about it from the perspective of 
making an infrastructure decision for a real world project, I'd have to 
agree with Andrey and Timothy here. In most real world scenarios, you're 
not going to be able to get even close to those upper limits, and you'll 
see other aspects of the runtimes become much more important. So I wouldn't 
put too much weight on this particular question in isolation. If your 
application's processing per connection really is super minimal with almost 
0 real work being done (as in a chat server, as mentioned), then it's a 
factor worth considering. But most of the time we need to do things with 
our data, so it's important that we consider the bigger picture.

I'll also echo the sentiment that scaling horizontally over vertically has 
a lot of advantages, so it's worth considering designing your architecture 
in this direction regardless of which language you choose.

Best

Chris
 

-- 
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: Library suggestions requested for clojure-toolbox.com

2015-10-07 Thread Christopher Small

Would love to see Semantic CSV up there under the CSV parsers.

{:name "semantic-csv"
 :category "CSV parsers"
 :URL "https://github.com/metasoarous/semantic-csv;
 :description "Higher level tools for working with CSV data"}

Cheers

Chris


On Monday, October 5, 2015 at 12:41:11 PM UTC-7, James Reeves wrote:
>
> If you've written or know about a Clojure or ClojureScript library, and 
> it's not already on clojure-toolbox.com , 
> I'd like to hear about it.
>
> Post the name and URL (and an optional category) as reply to this message, 
> and I'll add it to the site.
>
> - 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.

Tools comparable to Luigi for Clojure or the JVM?

2015-09-16 Thread Christopher Small

Check out prismatic's plumbing. Its a reall y lovely tool that among other 
things let's you create directed graph structures representing computational 
pipelines, and then compile them into callable functions. It's has different 
compilers for profiling, lazy evaluation, parallelized computation and eager 
seqiential processing. I don't know that anyone has done it, but it should be 
possible to compile down to something distributed if needed. I've been 
interested in compiling to onyx actually. 

Best

Chris

Disclaimer: Written on cell phone

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

Re: Clojure/Pedestal vs Go

2015-09-15 Thread Christopher Small

I also am no Go expert. All I'll add is that I overheard that the lead 
author rejected a proposal to add `map` to the language, stating that it is 
"too niche". Doesn't bode well for FP in Go...

-- 
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 implement a distributed and concurrent system in Clojure?

2015-07-19 Thread Christopher Small


I'll also add that if you're interested in the Storm model (distributed 
stream processing), you may want to check out Onyx 
(https://github.com/onyx-platform/onyx). It's newer, but I have a feeling 
that moving forward we're going to see it take a dominant position as far 
as that flavor of distributed computing goes. The reasons for this 
(briefly):

* Data all the topologies: Because computational topologies are data 
structures, it's far simpler to have more dynamic computational workflows 
than with storms opaque macros.
* It's more Clojure centric: Parts of Storm are Clojure, but the Clojure 
API seems almost an afterthought, reading the documentation. (However, 
support is on the way for other JVM languages).
* Pace of development: Storm is now an Apache Incubator project, and 
development is slower than molasses. I was working on a project for over a 
year and many times encountered issues with stale dependencies that didn't 
play nicely with newer things.
* Designed with batch processing in mind: Even though both are designed 
around streaming first, Onyx has a little more explicit support for batched 
computations.

For a while, the biggest advantage of Storm was that it was a lot faster, 
but the gap there has closed considerably recently (perhaps entirely?). 
Storm is still more battle tested, but there are folks starting to use it 
in production.

The biggest reason I see Onyx taking sway over Storm is the data centric 
approach. I see this resonating with the community's data all the things 
philosophy as a way of maximizing composability and productivity. 
Anecdotally, folks using Onyx are already saying this about it.

My 2 c

Chris



On Sunday, July 19, 2015 at 9:38:09 AM UTC-7, Devin Walters (devn) wrote:

 http://docs.paralleluniverse.co/pulsar/ is out there. I can't say I've 
 used it in anger, but I did enjoy experimenting with it.
 On Sun, Jul 19, 2015 at 11:24 AM Colin Yates colin...@gmail.com 
 javascript: wrote:

 I don’t have anything to add at that scale, but I wanted to echo Stuart’s 
 comment about the serialisability of EDN. Moving EDN between the front and 
 back tiers  on our app has cut down a bunch of boilerplate. That principle 
 can scale across machines as well.

 On 19 Jul 2015, at 16:54, Stuart Sierra the.stua...@gmail.com 
 javascript: wrote:

 Absolutely would use again. But I'm biased towards Clojure already. :)
 –S

 On Sunday, July 19, 2015 09goral wrote:

 Thanks Stuart for your answer, it is very helpfull. Would you choose 
 Clojure again ?

 2015-07-19 17:13 GMT+02:00 Stuart Sierra:


 This is an old thread, but it showed up in my Google Groups so I 
 figured I would give an answer.

 I have worked on fairly large (10-50 machines) distributed systems 
 written entirely in Clojure


 -- 
 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 
 javascript:
 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 javascript:


 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.

  -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com 
 javascript:
 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 javascript:
 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 javascript:.
 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: Clojars Private/Commercial Repos

2015-06-30 Thread Christopher Small


This is being done now with npm: https://www.npmjs.com/. Cost is $7/mo, 
which seems reasonable.


On Tuesday, June 30, 2015 at 12:00:55 PM UTC-7, Jason Lewis wrote:

 I think my company would be willing to pay a reasonable fee for private 
 Clojars repos, on something like the Github model? Not sure what the lein 
 overhead would be, I know grabbing Datomic Pro from non-Clojars with creds 
 is a motherf@#@#ing pain in the ass at times (but only in comparison to the 
 conveninece of Clojars. 

 Maybe a private-Clojars solution could be a good way to support the 
 project and encourage a standardized lein/project.clj method of grabbing 
 non-free artifacts?

 On Tue, Jun 30, 2015 at 2:17 PM Dave Dixon dave.d...@gmail.com 
 javascript: wrote:

 +1. Neither S3 or Archiva have worked out well for us long term.


 On Monday, June 29, 2015 at 6:50:44 PM UTC-7, Daniel Compton wrote:

 Hi folks

 I wondered if one possible solution for ensuring Clojars long-term 
 viability and maintenance would be to use it to host private repositories 
 for paying users as well? For many people, the thought of setting up and 
 maintaining Nexus or Archiva isn't an appealing one. I'm aware of the S3 
 wagon, and perhaps that's what people use if they don't want Nexus.

 I'd be interested to hear what other people are doing, and whether 
 Clojars would be a good middle ground between simplicity and functionality. 
 Many Clojure users already have Clojars accounts and will have setup Lein 
 to deploy here already. Additionally, many people would support Clojars for 
 the goodwill factor.

 On the other hand I'm aware this would require more development effort, 
 there may not be much demand for this, and the infrastructure costs may not 
 be large enough that it's worth going down this route.

 Just a thought, 

 Daniel.
 -- 
 --
 Daniel

  -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.



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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-22 Thread Christopher Small

Just a couple of comments:

As I was typing, Mars0i's message came in, with much of much what I wanted
to say about documentation, but I'll reiterate a couple of key points: You
can have an intuitive API that's poorly documented, just as it's possible
to have a terrible API with great documentation (though certainly it's
_easier_ to document a nice, clean API...). Those two things are relatively
orthogonal. Your comments about documentation came in response to a line of
thought about shortcomings of the core.matrix API, but bad documentation is
not actually a shortcoming of the API proper. And not building around
core.matrix because the API is bad is different than not building around it
because the API is poorly documented (though both understandable),
particularly when the latter is relatively easy to fix (even after the
fact).

However, I have to personally disagree about the state of the
documentation. I think it's actually pretty decent. For example, on the
GitHub page (README) there is a link to a wiki page for implementers that I
think is fairly straight forward. If you go to the protocols namespace (as
suggested in the implementers wiki page), the protocols which _must_ be
implemented are well demarcated, and most of the protocols have pretty good
documentation. There is certainly room for improvement though. The example
of * vs mmul mentioned could have been avoided had
https://github.com/mikera/core.matrix/blob/master/src/main/clojure/clojure/core/matrix/examples.clj
(linked to from the README) more clearly denoted what * does, and added
mmul as well (since I think that's what folks would use more frequently
anyway...). There's probably also room for more thorough/robust high-level
descriptions of key concepts. But I think overall the documentation is far
from _bad_. That's just my opinion though; if other people are having
trouble with the docs, there may be more room for improvement than I
realize.

Dragan, you point out that in the Clojure community there are dozens of
Clojure libraries for SQL, http, visualization, etc, and all have their
place. That's certainly true, but you're comparing kittens to koalas here.
Matrices/arrays are *data types*, while the things you mention are
libraries that do things with already standardized data types. Something
common to every single Clojure SQL library out there is that it's likely
going to return a seq of vectors or maps; in either case, these are the
data types around which vast swaths of the Clojure code out there has
already been built. So there's less need for standardization here. The
situation around matrix/array programming is very different; here you have
tightly coupled abstract data types and functionality/operations, and there
is a lot that could be built up around them and which benefits from a
standardization. I've talked with folks at some of the big(gish) Clojure
companies doing ML, and they love core.matrix for this very reason.

A perfect example of something similar is graphs; graphs are data types
which are tightly coupled with a number of operations, and loom is a
project which has been around for a while to try and unify an API around
these data types and operations. When Mark Engelberg realized that loom
didn't fit all his needs (which had to do with more robust/general graph
types and operations; much more extensive than just beefing up performance
on a subset of the functionality...), he didn't go and create his own
thing. Well... he did... but he did it in such a way that his constructions
also implemented the loom protocols, so what you wrote would still be
relatively interoperable with loom code. This is a great example because
even though his approach is much more general and I think should/could be
*THE* graph api, he still was able to make things as compatible as he
possibly could. This is the beauty of Clojure at it's greatest.

As for complex matrices, there's already a project underway for this, with
a rather elegant approach that would allow for any underlying
implementation to be used: https://github.com/mikera/core.matrix.complex.
Of course, a native implementation that supported complex types would be
lovely, and could potentially be a lot faster than doing things this way,
but it's not true that there's no complex story.

As for performance benchmarks, I have to echo Mike that it seemed strange
to me that you were claiming you were faster on ALL benchmarks when I'd
only seen data on one. Would you mind sharing your full benchmarking
analyses?

With all that out of the way... I'm glad that you're willing to play ball
here with the core.matrix community, and thank you for what I think has
been a very productive discussion. I think we all went from talking _past_
each other, to understanding what the issues are and can now hopefully
start moving forward and making things happen. While I think we'd all love
to have you (Dragan) personally working on the core.matrix implementations,
I agree with Mars0i that just

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-22 Thread Christopher Small

For benchmarking, there's this:
https://github.com/mikera/core.matrix.benchmark. It's pretty simple though.
It would be nice to see something more robust and composable, and with
nicer output options. I'll put a little bit of time into that now, but
again, a bit busy to do as much as I'd like here :-)

Chris


On Mon, Jun 22, 2015 at 9:14 AM, Dragan Djuric draga...@gmail.com wrote:


 As for performance benchmarks, I have to echo Mike that it seemed strange
 to me that you were claiming you were faster on ALL benchmarks when I'd
 only seen data on one. Would you mind sharing your full benchmarking
 analyses?


 I think this might be a very important issue, and I am glad that you
 raised it. Has anyone shared any core.matrix (or, to be precise,
 core.matrix) benchmark data? I know about Java benchmark code project that
 include vectorz, but I think it would help core.matrix users to see the
 actual numbers. One main thing vectorz (and core.matrix) is claiming is
 that it is *fast*. Mike seemed a bit (pleasantly) surprised when I shared
 my results for vectorz mmul...

 So, my proposal would be that you (or anyone else able and willing) create
 a simple Clojure project that simply lists typical core.matrix use cases,
 or just the core procedures in core.matrix code that you want to measure
 and that you are interested to see Neanderthal doing. Ready criterium
 infrastructure is cool, but I'm not even ask for that if you do not have
 time. Just a setup with matrix objects and core.matrix function calls that
 you want measured. Share your numbers and that project on Github and I will
 contribute comparative code for Neanderthal benchmarks, and results for
 both codes run on my machine. Of course, that would be micro benchmarks,
 but useful anyway for you, one Neanderthal user (me :) and for all
 core.matrix users.

 You interested?

 With all that out of the way... I'm glad that you're willing to play ball
 here with the core.matrix community, and thank you for what I think has
 been a very productive discussion. I think we all went from talking _past_
 each other, to understanding what the issues are and can now hopefully
 start moving forward and making things happen. While I think we'd all love
 to have you (Dragan) personally working on the core.matrix implementations,
 I agree with Mars0i that just having you agree to work-with/advise others
 who would do the actual work is great. I'd personally love to take that on
 myself, but I already have about a half dozen side projects I'm working on
 which I barely have time for. Oh, and a four month old baby :scream:! So if
 there's anyone else who's willing, I may leave it to them :-)


 I'm also glad we understand each other better now :)

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


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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-22 Thread Christopher Small

Well, we also weren't claiming to win ALL benchmarks compared to anything
:-)

But your point is well taken, better benchmarking should be pretty valuable
to the community moving forward.

Chris


On Mon, Jun 22, 2015 at 12:10 PM, Dragan Djuric draga...@gmail.com wrote:

 So, there are exactly two measurements there: matrix multiplication and
 vector addition for dimension 100 (which is quite small and should favor
 vectorz). Here are the results on my machine:

 Matrix multiplications are given at the neanderthal web site at
 http://neanderthal.uncomplicate.org/articles/benchmarks.html in much more
 details than that, so I won't repeat that here.

 Vector addition according to criterium: 124ns vectorz vs 78ns neanderthal
 on my i7 4790k

 Mind you that the project you pointed uses rather old library versions. I
 updated them to the latest versions. Also, the code does not run for both
 old and new versions properly (it complains about :clatrix) so I had to
 evaluate it manually in the repl.

 I wonder why you complained that I didn't show more benchmark data about
 my claims when I had shown much more (and relevant) data than it is
 available for core.matrix, but I would use the opportunity to appeal to
 core.matrix community to improve that.

 On Monday, June 22, 2015 at 8:13:29 PM UTC+2, Christopher Small wrote:

 For benchmarking, there's this:
 https://github.com/mikera/core.matrix.benchmark. It's pretty simple
 though. It would be nice to see something more robust and composable, and
 with nicer output options. I'll put a little bit of time into that now, but
 again, a bit busy to do as much as I'd like here :-)

 Chris


 On Mon, Jun 22, 2015 at 9:14 AM, Dragan Djuric drag...@gmail.com wrote:


 As for performance benchmarks, I have to echo Mike that it seemed
 strange to me that you were claiming you were faster on ALL benchmarks when
 I'd only seen data on one. Would you mind sharing your full benchmarking
 analyses?


 I think this might be a very important issue, and I am glad that you
 raised it. Has anyone shared any core.matrix (or, to be precise,
 core.matrix) benchmark data? I know about Java benchmark code project that
 include vectorz, but I think it would help core.matrix users to see the
 actual numbers. One main thing vectorz (and core.matrix) is claiming is
 that it is *fast*. Mike seemed a bit (pleasantly) surprised when I shared
 my results for vectorz mmul...

 So, my proposal would be that you (or anyone else able and willing)
 create a simple Clojure project that simply lists typical core.matrix use
 cases, or just the core procedures in core.matrix code that you want to
 measure and that you are interested to see Neanderthal doing. Ready
 criterium infrastructure is cool, but I'm not even ask for that if you do
 not have time. Just a setup with matrix objects and core.matrix function
 calls that you want measured. Share your numbers and that project on Github
 and I will contribute comparative code for Neanderthal benchmarks, and
 results for both codes run on my machine. Of course, that would be micro
 benchmarks, but useful anyway for you, one Neanderthal user (me :) and for
 all core.matrix users.

 You interested?

 With all that out of the way... I'm glad that you're willing to play
 ball here with the core.matrix community, and thank you for what I think
 has been a very productive discussion. I think we all went from talking
 _past_ each other, to understanding what the issues are and can now
 hopefully start moving forward and making things happen. While I think we'd
 all love to have you (Dragan) personally working on the core.matrix
 implementations, I agree with Mars0i that just having you agree to
 work-with/advise others who would do the actual work is great. I'd
 personally love to take that on myself, but I already have about a half
 dozen side projects I'm working on which I barely have time for. Oh, and a
 four month old baby :scream:! So if there's anyone else who's willing, I
 may leave it to them :-)


 I'm also glad we understand each other better now :)

 --
 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/dFPOOw8pSGI/unsubscribe.
 To unsubscribe from this group and all its topics, 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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-19 Thread Christopher Small

I see now Dragan; you're concerned not about whether easily implementing
and swapping in/out implementations of core.matrix is possible, but whether
it can be done while maintaining the performance characteristics of
Neanderthal, yes? That did not come through in your earlier comments in
this thread.

Certainly, performance is one of those things that can leak in an
abstraction. But I'd like to echo Matt's enquiry: If you think a unified
API might be possible but that core.matrix isn't it, I think we'd all love
to hear what you think it's missing and/or what would would need to be
rearchitected in order for it to fit the bill.

As for any sort of responsibility to implement core.matrix, I don't think
anyone is arguing you have such a responsibility, and I hope our _pleading_
hasn't come across as such. We are simply impressed with your work, and
would like to take advantage of it, but also see a drawback you don't: at
present Neanderthal is less interoperable with many existing tools, and
trying it out on an existing project would require a rewrite (as would
migrating away from it if we weren't happy).

Certainly, a third party library implementing core.matrix with Neanderthal
is a possibility, but I'm a bit worried that a) it would add extra burden
keeping things in sync and feel a little second class; and more importantly
b) it might be easier to maintain more of the performance benefits if it's
directly integrating (I could imagine less indirection this way, but could
be totally wrong). So let me ask you this:

Assuming a) someone forks Neanderthal and makes a core.matrix
implementation with close performance parity to the direct Neanderthal API
and/or b) folks working on core.matrix are able to address some of your
issues with the core.matrix architecture, would you consider a merge?


With gratitude

Chris



On Fri, Jun 19, 2015 at 1:45 PM, Matt Revelle mreve...@gmail.com wrote:

 On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote:

 I do not even claim that an unified api is not possible. I think that to
 some extent it is. I just doubt in core.matrix eligibility for THE api in
 numerical computing. For it makes easy things easy and hard things
 impossible.


 Are you saying you don't believe core.matrix should be _the_ abstract API
 for matrices/arrays in Clojure? If so, what are your concerns? Feel free to
 point to me a previous post if it's already been stated. It also sounds
 like you're alluding to the thread in the Numerical Clojure group about a
 broad numerical computing lib for complex numbers and various math
 functions, but I'm not following how that matters here.

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


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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-17 Thread Christopher Small

First of all, nice work :-)


In the docs you keep referring to core.matrix as though it was a particular
implementation, saying things like X times faster than core.matrix. This
is misleading; core.matrix is an abstract API, which can have many
implementations. Saying something is faster than it doesn't mean anything.
In particular, it's misleading to compare Neanderthal to core.matrix by
comparing it to Vectorz and jBlas, since faster implementations could be
written and are underway. Perhaps something a little more verbose like
Neanderthal to the fastest (current?) core.matrix implementations would
be less misleading.

On a stylistic note, I like the website design overall, but the graph paper
lines on the back ground are a bit distracting in relation to the text.
Perhaps a white background behind the text, with the graph lines on the
margins would capture the same effect but be less distracting?


At the risk of being a nag, I'd also like to reiterate the desire of the
community to avoid library fragmentation and see Neanderthal implement the
core.matrix protocols. Mike elegantly explicated the reasons for this in
his earlier post: if we all build around a common abstract API, we maximize
the Clojure dream of composability of anything written towards and for that
API. This is important to a lot of Clojurians.

Earlier in the thread you expressed concerns about whether it would really
be so easy to have Neanderthal's as a core.matrix API. Mike Anderson's
response to me suggests he thought you were questioning whether swapping
core.matrix implementations was really so easy. Just in case you were
doubtful of the former more so than the latter, perhaps I can clarify.

Core.matrix is built entirely around abstract protocols which represent the
various matrix operations one might care about for a matrix computation
library. There are protocols for addition, inner product, outer product,
multiply and add, invert, etc. All you would have to do to make Neanderthal
functional as a core.matrix implementation is implement these protocols in
some namespace within your project (perhaps `
uncomplicate.neanderthal.core-matrix`). As Mike pointed out, you wouldn't
even have to implement _all_ the protocols, since core.matrix comes with
default implementations of the things you don't define. Once you'd made the
implementations, you register an example matrix object with core.matrix at
the end of your namespace, and then when a user requires that namespace,
the Neanderthal implementation would be registered, and users could start
instantiating Neanderthal matrices that are 100% compatible with the
core.matrix API. Setting things up this way, you wouldn't even have to
abandon your own API. The two could live in harmony along side each other,
letting folks require and use whichever they like. It really is just that
simple; implement a few protocols, and the API will work. It sounds too
good to be true, and I didn't believe it at first either, but it works.

I get that you've put a lot of energy into this, and commend you for it. I
personally would love to take advantage of that hard work, and am sure
others would as well. However, I think you're going to find adoption
difficult if Neanderthal risks fragmenting the presently coherent state of
numerical computing in Clojure, and imposes inflexibilities upon those who
would use it in their own code. I personally am not willing to boost
performance at the cost of flexibility.

OK; I'll leave it at that.


Respectfully,

Chris


On Wed, Jun 17, 2015 at 8:07 AM, Dragan Djuric draga...@gmail.com wrote:

 Version 0.2.0 has just been released to Clojars

 New features:

 * implemented BLAS support for floats
 * implemented fmap!, freduce, and fold functions for all existing types of
 matrices and vectors

 Changes:

 No API changes were required for these features.

 On Tuesday, January 13, 2015 at 2:13:13 AM UTC+1, Dragan Djuric wrote:

 I am pleased to announce a first public release of new *very fast *native
 matrix and linear algebra library for Clojure based on ATLAS BLAS.
 Extensive *documentation* is at http://neanderthal.uncomplicate.org
 See the benchmarks at
 http://neanderthal.uncomplicate.org/articles/benchmarks.html.

 Neanderthal is a Clojure library that

 Main project goals are:

- Be as fast as native ATLAS even for linear operations, with no
copying overhead. It is roughly 2x faster than jBLAS for large matrices,
and tens of times faster for small ones. Also faster than core.matrix for
small and large matrices!
- Fit well into idiomatic Clojure - Clojure programmers should be
able to use and understand Neanderthal like any regular Clojure library.
- Fit well into numerical computing literature - programmers should
be able to reuse existing widespread BLAS and LAPACK programming know-how
and easily translate it to Clojure code.

 Implemented features

- Data structures: double vector, double general dense matrix (GE);
-

Re: Opinion on core.async vs callbacks in abstract APIs?


Lots of great thoughts here; thanks so much for the feedback!

It seems the general opinion so far leans towards keeping things simple. I 
definitely resonate with this statement: having to write some glue code 
feels less frustrating than when libs make assumptions that I don't like.

Unfortunately, the abstractness of my question is allowing things to drift 
a little further than I intended. So to ground things a bit, in my 
particular use case promises wouldn't work because I need to allow for a 
stream of events. Promises only let you capture a single event.

Additionally, I feel it worth responding to some of Timothy's comments 
about the difficulty of getting a core.async centric API right. While I 
agree that in general (and particular with more complicated APIs) getting 
things right can be tricky, the situation I'm dealing with (I think) can be 
dealt with quite simply. Imagine a stream of events coming in from The Real 
World (TM), and that we'd like to process somehow. The solution I've been 
chewing on is a function that let's us specify a single channel on which 
events should be placed. The nice thing about this is that it assumes 
almost nothing about how you'll use core.async, only that you'll be using 
it. You can decide whether you want a buffer or not, whether it should drop 
or slide or block/park, whether it should be tapped, etc.

The potentially nice thing about core.async for this use case over 
callbacks (as far as the implementation is concerned) is that should we 
decide to stop listening to events, we can just close! the channel. This 
can then serve as a signal to the underlying code/process actually reading 
in events that it can stop. With callbacks, it will probably be necessary 
to have something that manages these processes and listens for kill 
signals, potentially complicating things quite a bit. (It's possible there 
is an elegant solution here, and I haven't thought about it too much yet, 
but this is my current intuition...)

I should also mention that Manifold did come to mind for this project, and 
it's something I'll probably look at and consider again. Thanks for 
bringing it up.

Please continue to share your thoughts given all this :-)

With gratitude

Chris



On Monday, June 1, 2015 at 10:18:46 PM UTC-7, Leonardo Borges wrote:

 For people interested in using the 'futures' approach, this might be of 
 interest: https://github.com/leonardoborges/imminent


 It's a library that implements composable futures for Clojure on top of 
 JVM's ForkJoin framework. It allows you to attach callbacks as well as 
 apply combinators such as map etc...


 On 2 Jun 2015 3:04 pm, Timothy Baldridge tbald...@gmail.com 
 javascript: wrote:

 The problem with futures is that you can't attach callbacks to them, you 
 can only block a thread waiting on them. So futures interface quite poorly 
 with async libraries, hence the reason core.async was created in the first 
 place. 

 Core.async is a dependency, but it's hardly one that changes fast. The 
 last breaking change was about a year and a half ago (Jan 2014). Besides 
 that, all changes are additional opt-in features. That's a lot less 
 change than most libraries in the Clojure ecosystem.  

 Timothy

 On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin jus...@gmail.com 
 javascript: wrote:

 As for the core.async, I think it is too personal and has too much raw 
 power, to be all that restricted in some logical bottleneck upon results 
 return from the third-party lib. 
 Not counting the fact it is a (a) dependency that (b) changes fast.

 On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:

 Greetings

 I imagine most of us here would rather use core.async channels over 
 callbacks in their application code, particularly with more complicated 
 applications. But is it okay/preferable for Clojure libraries to force 
 their users to use core.async channels as part of an API (an event 
 channel, 
 for example)? 

 As much as I love core.async, I can't help but wonder whether sticking 
 with callbacks for an API isn't a simpler/better design strategy. It's 
 easy 
 enough to drop messages on a channel in a callback, and this let's users 
 opt-in. But if one expects core.async channels are what most would prefer 
 anyway, is it okay to foist them upon everyone?

 As a follow up, does your opinion on the matter change if 
 implementations of an API become simpler using core.async channels?


 Looking forward to your thoughts :-)

 Chris Small



 PS I'm asking because I'm working on a physical computing API (
 https://github.com/clj-bots/pin-ctrl) and debating between using 
 channels vs callbacks for the edge detection functionality (if you're not 
 familiar, edge detection let's you asynchronously handle changes in pin 
 state, such as button pushes). If you're interested in this question as it 
 applies specifically to this application, feel free to join the discussion 
 on our gitter channel: https://gitter.im

Re: complex number library

You sir, rock.

On Tue, Jun 2, 2015 at 10:41 AM, Mike Anderson mike.r.anderson...@gmail.com
 wrote:

 OK, here's a basic version that I think has most of the key elements in
 place.

 A lot more protocols still need implementing, but it should be a
 reasonable basis to build upon:

 https://github.com/mikera/core.matrix.complex


 On Tuesday, 2 June 2015 16:35:25 UTC+1, Christopher Small wrote:

  The array representation could simply be a deftype which uses two
 underlying arrays for the real and complex parts of the array respectively.

 Oh man; that is flipping brilliant. And simple...

  The implementation should be fairly straightforward, but if anyone
 wants I can create a repo and bang out a bare-bones implementation in an
 hour or so that people can build upon.

 Please!


 Chris



  --
 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/gocQu7XTaNo/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 numerical-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: complex number library

2015-06-02 Thread Christopher Graham

How about changing the name of the complex-number function to, ideally, 
complex?
complex-number seems irritating to (have to) read. Further, calling this 
function is a form of type coercion. (float ...), (int ...), etc., are 
idiomatic Clojure, whereas (float-number ...), (int-number ...), etc., were 
not included in the language.


On Sunday, May 31, 2015 at 6:55:46 PM UTC-4, Alan Forrester wrote:

 https://clojars.org/complex 

 https://github.com/alanforr/complex 
 https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Falanforr%2Fcomplexsa=Dsntz=1usg=AFQjCNHm4m5mR8UisNf-JFm-AbPGOX2Srg
  

 Complex is a Clojure library for doing complex number calculations 
 that wraps the Java commons-math3 Complex library. 

 complex 

 A Clojure library for doing calculations with complex numbers. Wraps 
 the Java commons-math3 Complex library. 

 Usage 

 A complex number can be created by invoking the complex number 
 function. With one argument the function produces a complex number in 
 which only the real component is non-zero. With two arguments, the 
 first argument is the real part, the second argument is the imaginary 
 part: 

 = (complex-number 1) 

 Complex (1.0, 0.0) 

 = (complex-number 1 2) 

 Complex (1.0, 2.0). 

 The library can be used to do complex arithmetic. The + function can 
 have any number of real or complex arguments but always produces a 
 complex result. 

 = (+ 1 (complex-number 3 4)) 

 Complex (4.0, 4.0). 

 The same is true of the other arithmetical operations *,-,/. The 
 arithmetical functions are fastest on a per number basis when used on 
 only two arguments. They are also faster when their arguments are 
 complex. 

 The library also provides other functions, such as (pow a b), which 
 raises a to the power b, (sin a) which calculates the sine of a, and 
 several other functions. For details, see the docs. 

 Alan 


-- 
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: complex number library

That sounds pretty solid imo.

On Tue, Jun 2, 2015 at 5:53 PM, Mike Anderson mike.r.anderson...@gmail.com
wrote:

 I agree that complex would be a better name.

 It would be also be nice if it the 1-arg version could be idempotent (i.e.
 returns an existing complex number unchanged). The downside is that this
 would mean a slight performance hit because it would prevent the use of
 primitive arguments. Maybe we should do this but still use primitive type
 hints for the 2-arg version?


 On Wednesday, 3 June 2015 01:17:49 UTC+1, Christopher Graham wrote:

 How about changing the name of the complex-number function to, ideally,
 complex?
 complex-number seems irritating to (have to) read. Further, calling this
 function is a form of type coercion. (float ...), (int ...), etc., are
 idiomatic Clojure, whereas (float-number ...), (int-number ...), etc., were
 not included in the language.


 On Sunday, May 31, 2015 at 6:55:46 PM UTC-4, Alan Forrester wrote:

 https://clojars.org/complex

 https://github.com/alanforr/complex
 https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Falanforr%2Fcomplexsa=Dsntz=1usg=AFQjCNHm4m5mR8UisNf-JFm-AbPGOX2Srg

 Complex is a Clojure library for doing complex number calculations
 that wraps the Java commons-math3 Complex library.

 complex

 A Clojure library for doing calculations with complex numbers. Wraps
 the Java commons-math3 Complex library.

 Usage

 A complex number can be created by invoking the complex number
 function. With one argument the function produces a complex number in
 which only the real component is non-zero. With two arguments, the
 first argument is the real part, the second argument is the imaginary
 part:

 = (complex-number 1)

 Complex (1.0, 0.0)

 = (complex-number 1 2)

 Complex (1.0, 2.0).

 The library can be used to do complex arithmetic. The + function can
 have any number of real or complex arguments but always produces a
 complex result.

 = (+ 1 (complex-number 3 4))

 Complex (4.0, 4.0).

 The same is true of the other arithmetical operations *,-,/. The
 arithmetical functions are fastest on a per number basis when used on
 only two arguments. They are also faster when their arguments are
 complex.

 The library also provides other functions, such as (pow a b), which
 raises a to the power b, (sin a) which calculates the sine of a, and
 several other functions. For details, see the docs.

 Alan

  --
 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/gocQu7XTaNo/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 numerical-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: Opinion on core.async vs callbacks in abstract APIs?

Lazy seqs by themselves wouldn't work, since it needs to be asynchronous,
and it's always possible that when you ask for the next element, that there
won't have been any new events yet. I suppose that you could return a lazy
sequence of futures, which is interesting, but not particularly idiomatic.
At that point I'd rather just use core.async, because that's what it starts
to look like.

On Tue, Jun 2, 2015 at 1:19 AM, Gary Verhaegen gary.verhae...@gmail.com
wrote:

 Have you considered returning a lazy seq of events?


 On Tuesday, 2 June 2015, Christopher Small metasoar...@gmail.com wrote:


 Lots of great thoughts here; thanks so much for the feedback!

 It seems the general opinion so far leans towards keeping things simple.
 I definitely resonate with this statement: having to write some glue
 code feels less frustrating than when libs make assumptions that I don't
 like.

 Unfortunately, the abstractness of my question is allowing things to
 drift a little further than I intended. So to ground things a bit, in my
 particular use case promises wouldn't work because I need to allow for a
 stream of events. Promises only let you capture a single event.

 Additionally, I feel it worth responding to some of Timothy's comments
 about the difficulty of getting a core.async centric API right. While I
 agree that in general (and particular with more complicated APIs) getting
 things right can be tricky, the situation I'm dealing with (I think) can be
 dealt with quite simply. Imagine a stream of events coming in from The Real
 World (TM), and that we'd like to process somehow. The solution I've been
 chewing on is a function that let's us specify a single channel on which
 events should be placed. The nice thing about this is that it assumes
 almost nothing about how you'll use core.async, only that you'll be using
 it. You can decide whether you want a buffer or not, whether it should drop
 or slide or block/park, whether it should be tapped, etc.

 The potentially nice thing about core.async for this use case over
 callbacks (as far as the implementation is concerned) is that should we
 decide to stop listening to events, we can just close! the channel. This
 can then serve as a signal to the underlying code/process actually reading
 in events that it can stop. With callbacks, it will probably be necessary
 to have something that manages these processes and listens for kill
 signals, potentially complicating things quite a bit. (It's possible there
 is an elegant solution here, and I haven't thought about it too much yet,
 but this is my current intuition...)

 I should also mention that Manifold did come to mind for this project,
 and it's something I'll probably look at and consider again. Thanks for
 bringing it up.

 Please continue to share your thoughts given all this :-)

 With gratitude

 Chris



 On Monday, June 1, 2015 at 10:18:46 PM UTC-7, Leonardo Borges wrote:

 For people interested in using the 'futures' approach, this might be of
 interest: https://github.com/leonardoborges/imminent


 It's a library that implements composable futures for Clojure on top of
 JVM's ForkJoin framework. It allows you to attach callbacks as well as
 apply combinators such as map etc...


 On 2 Jun 2015 3:04 pm, Timothy Baldridge tbald...@gmail.com wrote:

 The problem with futures is that you can't attach callbacks to them,
 you can only block a thread waiting on them. So futures interface quite
 poorly with async libraries, hence the reason core.async was created in the
 first place.

 Core.async is a dependency, but it's hardly one that changes fast. The
 last breaking change was about a year and a half ago (Jan 2014). Besides
 that, all changes are additional opt-in features. That's a lot less
 change than most libraries in the Clojure ecosystem.

 Timothy

 On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin jus...@gmail.com
 wrote:

 As for the core.async, I think it is too personal and has too much raw
 power, to be all that restricted in some logical bottleneck upon results
 return from the third-party lib.
 Not counting the fact it is a (a) dependency that (b) changes fast.

 On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:

 Greetings

 I imagine most of us here would rather use core.async channels over
 callbacks in their application code, particularly with more complicated
 applications. But is it okay/preferable for Clojure libraries to force
 their users to use core.async channels as part of an API (an event 
 channel,
 for example)?

 As much as I love core.async, I can't help but wonder whether
 sticking with callbacks for an API isn't a simpler/better design 
 strategy.
 It's easy enough to drop messages on a channel in a callback, and this
 let's users opt-in. But if one expects core.async channels are what most
 would prefer anyway, is it okay to foist them upon everyone?

 As a follow up, does your opinion on the matter change if
 implementations of an API become simpler

Re: Opinion on core.async vs callbacks in abstract APIs?

@Erik: I should clarify in this situation, the _user_ of the API would
decide whether they want to stop listening to events. So there's not so
much that _they_ would have to specify in terms of shutdown routines. I'm
more concerned about how API implementations get notified that they don't
need to deal with new events.

-- 
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: complex number library

 The array representation could simply be a deftype which uses two
underlying arrays for the real and complex parts of the array respectively.

Oh man; that is flipping brilliant. And simple...

 The implementation should be fairly straightforward, but if anyone wants
I can create a repo and bang out a bare-bones implementation in an hour or
so that people can build upon.

Please!


Chris

-- 
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: Opinion on core.async vs callbacks in abstract APIs?

Yes, potentially. And their temporal distribution could be any imaginable.

The idea is that we're dealing with things like button presses, which could
happen as frequently or infrequently as a physical device might need, and
for which an application would have to be prepared for the duration of the
device being in operation. I imagine most production applications
probably wouldn't need to stop listening to events (though they
could...). Mostly, this is for interactive REPL development; If you're
tinkering around with things and decide you want to shut off or change the
edge direction of a given pin, you don't want the old callbacks to keep
firing.

Chris


On Tue, Jun 2, 2015 at 8:21 AM, Erik Price e...@zensight.co wrote:

 Oh, so the events are for all intents and purposes infinite?

 On Tue, Jun 2, 2015 at 11:10 AM, Christopher Small metasoar...@gmail.com
 wrote:

 @Erik: I should clarify in this situation, the _user_ of the API would
 decide whether they want to stop listening to events. So there's not so
 much that _they_ would have to specify in terms of shutdown routines. I'm
 more concerned about how API implementations get notified that they don't
 need to deal with new events.

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


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


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

Re: complex number library

2015-06-01 Thread Christopher Small

Are these operations (*, +, etc) interoperable with core.matrix operations? 
That may end up being pretty key for a lot of numerical users.

Chris


On Sunday, May 31, 2015 at 3:55:46 PM UTC-7, Alan Forrester wrote:

 https://clojars.org/complex 

 https://github.com/alanforr/complex 

 Complex is a Clojure library for doing complex number calculations 
 that wraps the Java commons-math3 Complex library. 

 complex 

 A Clojure library for doing calculations with complex numbers. Wraps 
 the Java commons-math3 Complex library. 

 Usage 

 A complex number can be created by invoking the complex number 
 function. With one argument the function produces a complex number in 
 which only the real component is non-zero. With two arguments, the 
 first argument is the real part, the second argument is the imaginary 
 part: 

 = (complex-number 1) 

 Complex (1.0, 0.0) 

 = (complex-number 1 2) 

 Complex (1.0, 2.0). 

 The library can be used to do complex arithmetic. The + function can 
 have any number of real or complex arguments but always produces a 
 complex result. 

 = (+ 1 (complex-number 3 4)) 

 Complex (4.0, 4.0). 

 The same is true of the other arithmetical operations *,-,/. The 
 arithmetical functions are fastest on a per number basis when used on 
 only two arguments. They are also faster when their arguments are 
 complex. 

 The library also provides other functions, such as (pow a b), which 
 raises a to the power b, (sin a) which calculates the sine of a, and 
 several other functions. For details, see the docs. 

 Alan 


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

Opinion on core.async vs callbacks in abstract APIs?

2015-06-01 Thread Christopher Small

Greetings

I imagine most of us here would rather use core.async channels over
callbacks in their application code, particularly with more complicated
applications. But is it okay/preferable for Clojure libraries to force
their users to use core.async channels as part of an API (an event channel,
for example)?

As much as I love core.async, I can't help but wonder whether sticking with
callbacks for an API isn't a simpler/better design strategy. It's easy
enough to drop messages on a channel in a callback, and this let's users
opt-in. But if one expects core.async channels are what most would prefer
anyway, is it okay to foist them upon everyone?

As a follow up, does your opinion on the matter change if implementations
of an API become simpler using core.async channels?


Looking forward to your thoughts :-)

Chris Small



PS I'm asking because I'm working on a physical computing API (
https://github.com/clj-bots/pin-ctrl) and debating between using channels
vs callbacks for the edge detection functionality (if you're not familiar,
edge detection let's you asynchronously handle changes in pin state, such
as button pushes). If you're interested in this question as it applies
specifically to this application, feel free to join the discussion on our
gitter channel: https://gitter.im/clj-bots/chat

-- 
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: Using :refer 'sparingly'

2015-05-17 Thread Christopher Small

I agree with the general sentiment expressed here, but would just like to 
add that `:refer`-ing a few frequently used functions (as Colin Yates 
stated, particularly when it's assumed there is strong coupling or 
closeness between the two namespaces involved), is a much more minor 
nuisance than `:refer :all`. At least with `:refer [some-fn 
some-other-fn]`, you _can_ figure out where the function came from by going 
up to the `ns` declaration, and if you're fast with your editor, this is 
easy to do. Both `:refer :all` and `:use`/ `(use)` should (IMHO) only be 
used for hacking around at the repl.

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

Re: Clojure needs a web framework with more momentum

I've been enjoying this thread, but don't currently have the bandwidth to
read everyone's messages and figure out in my head what the distribution of
opinions is or who is on what side of this conversation.

Fortunately, I built a tool for this! It's called pol.is, and it uses real
time data visualization and machine learning to help make sense of large
scale conversations. It falls somewhere between an open ended survey and a
comment thread. Instead of getting more difficult to grok with the number
of people comments, it gets EASIER, because there is more data with which
the ML  stats make magic.

I started a conversation on the state of Web Development in Clojure:
https://pol.is/7scufp.

You don't need to create an account to log in and participate, but if you
connect a social account (twitter, facebook), we can show your avatar and
name where you fall in the conversation, so you can see where everyone else
stands in relation to yourself.

Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)

Chris

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

Re: Clojure needs a web framework with more momentum

Cheers, and thanks :-) It's free, so feel... free to use it :-)

On Mon, May 4, 2015 at 8:28 AM, Marcus Blankenship mar...@creoagency.com
wrote:

 Ok, honestly, this is super cool.  Well done!

 On May 4, 2015, at 8:19 AM, Christopher Small metasoar...@gmail.com
 wrote:

 I've been enjoying this thread, but don't currently have the bandwidth to
 read everyone's messages and figure out in my head what the distribution of
 opinions is or who is on what side of this conversation.

 Fortunately, I built a tool for this! It's called pol.is, and it uses
 real time data visualization and machine learning to help make sense of
 large scale conversations. It falls somewhere between an open ended survey
 and a comment thread. Instead of getting more difficult to grok with the
 number of people comments, it gets EASIER, because there is more data with
 which the ML  stats make magic.

 I started a conversation on the state of Web Development in Clojure:
 https://pol.is/7scufp.

 You don't need to create an account to log in and participate, but if you
 connect a social account (twitter, facebook), we can show your avatar and
 name where you fall in the conversation, so you can see where everyone else
 stands in relation to yourself.

 Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)

 Chris



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


 Best,
 Marcus

 Marcus Blankenship
 \\\ Technical Coach, Startup Advisor, Calvinist
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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


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

Re: Embedded systems and transpiling Clojure to Nim

Using clj-bots/chat is fine with me. If there ends up being much noise with
respect to this specific native compilation thread vs the project as a
whole, we can set up another gitter channel.

Cheers

On Mon, May 4, 2015 at 5:04 PM, Alan Moore kahunamo...@coopsource.org
wrote:

 All,

 Looks like I have some more research to do... A year or so ago I looked
 into going the Python/PyPy route but it's PPC support had previously
 stalled. I was intrigued by it's interpreter/tracing JIT structure.

 It seems to me that there would be a huge win, similar to the Clojure/JVM,
 ClojureScript/Javascript bump, for targeting Python. This would allow
 Clojure to integrate with many libraries for devops, big data, scientific
 and non-traditional IT communities. Pixie looks pretty nice - maybe that
 will work. TBD.

 I think I'd prefer to stay with the Clojure dialect rather than CL/others,
 partly because I am used to Clojure and partly because one of my use cases
 requires the same exact code running in an embedded system and in the
 browser, e.g. don't want to maintain separate versions of key algorithms.

 Herwig - I like your suggestion re: rclojure. That seems like a harder
 but more fruitful approach than other porting options. Do you have any
 references to this kind of approach in other languages?

 Fergal - I agree, many IoT projects are targeting Javascript which could
 obviously use ClojureScript. I've been looking at the duktape javascript
 library (supported by the AllSeen Alliance) but have yet to try it out on
 our target or running ClojureScript generated code. I will also look
 at Elixir.

 Thanks for the feedback everyone. If anyone is interested in taking this
 topic offline so as not to spam this group with our corner case, let's use
 Chris' chat as a point of contact (if he doesn't mind):

 For those who missed his link, here it is:

 https://gitter.im/clj-bots/chat

 See you over there.

 Alan

 On Mon, May 4, 2015 at 1:25 AM, adrians nman...@gmail.com wrote:

 Alan, have you looked at Clasp? I'm not sure if CL is something you like,
 but maybe it has potential for your application.

 https://github.com/drmeister/clasp


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




 --
 --
 *Whatever you can do, or dream you can do, begin it. Boldness has genius,
 power, and magic in it. Begin it now.* - *Goethe*

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


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

Re: Clojure needs a web framework with more momentum

And Flask was inspired by Sinatra, IIRC. Also, the rails folks thought that
Sinatra would be a joke and no one would take it seriously. They were
surprised. Ditto with Merb, which was a similarly more modular, and became
so popular that rails actually merged with it.

Clojure's Noir used to be similarly minimalistic, but it became deprecated
and split up into peices which live on today as lib-noir, and can be used
with (e.g.) Luminus.

Chris


On Mon, May 4, 2015 at 5:25 PM, larry google groups 
lawrencecloj...@gmail.com wrote:

  Very interesting discussion going on here. As a beginner, what I'd like
 to see is not something
  like Django or Rails, but something like Flask.

 Flask started off as a sort of joke -- a few Python programmers,
 responding to criticism of bloat in Django, said it should be possible to
 create a single file web app. And they succeeded.

 You can certainly create a single-file web app in Clojure, and I think
 there are several examples on the web, that are very much comparable to the
 simple examples given for Flask. But, again, I agree with those above who
 suggested that maybe this should be offered as a lein template.




 On Monday, May 4, 2015 at 6:06:46 AM UTC-4, John Louis Del Rosario wrote:

 Very interesting discussion going on here. As a beginner, what I'd like
 to see is not something like Django or Rails, but something like Flask.
 Where someone can just (require 'someframework) and it works. Maybe it
 could have thin wrappers over compojure, etc., since it will need to be
 opinionated anyway. It's still very simple, but takes away a lot of the
 guesswork and the distributed docs across multiple projects problem.

 Additional features can be done as libraries then, but specific for
 `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.

 Just my 2c.

 On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:

 I recently did some research into web frameworks on Github. Here's what
 I found:


 FRAMEWORK   LANG  CONTRIBUTORS COMMITS

 LuminusClojure28678
 CaribouClojure 2275

 BeegoGolang991522

 PhoenixElixir  1241949

 YesodHaskell   1303722

 LaravelPHP2684421

 PlayScala   4176085

 SymfonyPHP113020914

 RailsRuby   269151000


 One could conclude from this that the Clojure community isn't that
 interested in web development but the last Clojure survey suggests
 otherwise. Clojure's library composition approach to everything only
 goes so far with large web applications, as Aaron Bedra reminded us in
 March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower
 means less momentum and more bugs. Furthermore, I have a hunch that
 Clojure's poor adoption as indicated by Indeed.com maybe due to this
 immaturity in the web framework sphere. Why is it that Elixir, with a
 much smaller community and lifespan than Clojure's, has managed to put 4
 times as much mindshare into its main web framework when its module
 output, as measured by modulecounts.com, is a tiny fraction of
 Clojure's?

 gvim




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


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

Re: Clojure needs a web framework with more momentum

2015-05-03 Thread Christopher Small

I really like what you said here Mark:

From a technological standpoint, I think we're there.  The things we most
 need are informational resources and higher-level shared resources, such as
 UI widgets.  For example:


I fully agree. I don't think we've moved in a wrong direction at all. Just
that we need to continue building on what we already have, and do so in the
right directions.

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

Re: Clojure needs a web framework with more momentum

2015-05-03 Thread Christopher Small


Perhaps we need to see an example of a minimalistic/modular approach that 
_has_ won out.

Node's express has  5k commits, 177 contribs, 18k stars. Possibly the 
most popular node framework out there. Tagline?

 Fast, unopinionated, minimalist web framework for node.



On Sunday, May 3, 2015 at 11:52:22 AM UTC-7, Leon Grapenthin wrote:

 No, it isn't. And never has this author proven that programmers with 
 bipolar personality are programming more LISP then other languages. 

 Many larger libraries in the Clojure community are well documented and 
 finished-off properly.

 Web frameworks have been tried and not been picked up. Users have chosen 
 the modular compose it yourself approach. Framework authors have simply 
 stopped maintaining what nobody wanted anyway or split them up into smaller 
 pieces. 


 On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote:


  The web development industry as reflected in job postings at 
  Indeed.co.uk is still dominated by the likes of Rails, Django, 
 Laravel, 
  Zend, Symfony  Spring so I'm not sure how you've concluded that 
 there's 
  been a 15-year trend towards composition. 

 That is a good point, though I would also point out that, according to 
 Indeed.com, the use of Clojure is also growing. To me, what's important is 
 the growth of the Clojure community, rather than the growth of some 
 sub-community focused on a particular niche. 

 However, I acknowledge you may have a point about the failure of any of 
 the Clojure frameworks to take off. It's possible this is another 
 manifestation of the Bipolar Programmer problem: 

 http://www.lambdassociates.org/blog/bipolar.htm

 Brilliance and failure are so often mixed together and our initial 
 reaction is it shouldn't be.   But it happens and it happens a lot.  Why? 
 ...But brilliance is not enough.  You need application too, because the 
 material is harder at university.   So pretty soon our man is getting B+, 
 then Bs and then Cs for his assignments.   He experiences alternating 
 feelings of failure cutting through his usual self assurance.  He can still 
 stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, 
 but what he hands in is not so great.

 ...So BBMs love Lisp.  And the stunning originality of Lisp is reflective 
 of the creativity of the BBM; so we have a long list of ideas that 
 originated with Lispers - garbage collection, list handling, personal 
 computing, windowing and areas in which Lisp people were amongst the 
 earliest pioneers.  So we would think, off the cuff, that Lisp should be 
 well established, the premiere programming language because hey - its great 
 and we were the first guys to do this stuff.

 But it isn't and the reasons why not are not in the language, but in the 
 community itself, which contains not just the strengths but also the 
 weaknesses of the BBM.

 One of these is the inability to finish things off properly.  The phrase 
 'throw-away design' is absolutely made for the BBM and it comes from the 
 Lisp community.   Lisp allows you to just chuck things off so easily, and 
 it is easy to take this for granted.  I saw this 10 years ago when looking 
 for a GUI to my Lisp (Garnet had just gone West then).  No problem, there 
 were 9 different offerings.  The trouble was that none of the 9 were 
 properly documented and none were bug free. Basically each person had 
 implemented his own solution and it worked for him so that was fine.   This 
 is a BBM attitude; it works for me and I understand it.   It is also the 
 product of not needing or wanting anybody else's help to do something.





 On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote:

 On 03/05/2015 14:39, larry google groups wrote: 
  The industry has been moving against frameworks for 15 years now. The 
  peak of the monolithic framework craze was Struts, back in 2000. After 
  that, people started craving something less bloated. That's why the 
  whole industry was so excited when Rails emerged in 2004. Bruce Eckel 
  summed up the sudden change of mood in his essay The departure of the 
  hyper-enthusiasts: 
  
  http://www.artima.com/weblogs/viewpost.jsp?thread=141312 
  
  But after awhile, people began to feel that even Rails was bloated, 
  which lead to the emergence of micro-frameworks like Sinatra. 
  
  And then, continuing with the trend, we've seen the emergence of 
  eco-systems, such as Clojure, that allow the trend to go further: 
  Clojure supports such high levels composition that frameworks are no 
  longer needed. And this is the direction the industry has been moving 
  for the last 15 years. Clojure is simply out in front. Most languages 
  don't allow this level of composition. 
  

 The web development industry as reflected in job postings at 
 Indeed.co.uk is still dominated by the likes of Rails, Django, Laravel, 
 Zend, Symfony  Spring so I'm not sure how you've concluded that there's 
 been a 15-year trend towards composition.

Re: Clojure needs a web framework with more momentum

2015-05-02 Thread Christopher Small

For rails sure. What about Elixer  Yesod? Those could be just as modular
for all I know... I'm just saying that one way or the other, those things
should be taken into account since they are important.

OO junk leads to bloat.

On Sat, May 2, 2015 at 5:15 PM, gvim gvi...@gmail.com wrote:

 On 03/05/2015 00:53, Christopher Small wrote:

 I disagree with the premise entirely. I think that the Clojure community
 has just done a better job of building smaller, more modular tooling.
 And this is frankly something I prefer, and find refreshing in the
 Clojure sphere (as compared with my previous Rails webdev experience).

 Note that to put things on the same footing, you'd want to be noting
 that Luminus depend on Ring and Compojure, with commit counts 761 and
 865 resp, and contributor counts 73 and 29 resp.

 I'm not saying that Clojure can't improve it's offering in web dev with
 added libraries etc, but I wouldn't want to see us move away from the
 modularity with which we've built things, because I think it's a win.

 Just my 2 c

 Chris Small


 Most decent web frameworks these days are built from modular components so
 this distinction is a bit laboured. Rails is built on top of Active* and
 Rack so the Ring/Compojure distinction is illusory. Laravel is built on top
 of Symfony components it could be argued that Symfony has played a similar
 role to Ring/Compojure in the PHP community.

 Clojure's modular approach is great but I just don't see the need to
 polarise when there's such a strong business case for structured
 frameworks. If you look at most of the jobs in web development at
 Indeed.com they're almost exclusively framework-based. Modular is great but
 it would also be nice to see a few more Clojure jobs advertised.

 gvim


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


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

Re: Embedded systems and transpiling Clojure to Nim

Hah; I have no experience with it. Is it that bad?

At least there's another Lisp in there. Lisps all the way down!

On Fri, May 1, 2015 at 1:58 PM, Raoul Duke rao...@gmail.com wrote:

  Another possibility is https://github.com/takeoutweight/clojure-scheme.
 It
  compiles Clojure to Gambit Scheme to C to metal.

 another possibility is to stab oneself in the eye with a sharp stick.

 just sayin'.

 :-)

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


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

Re: Embedded systems and transpiling Clojure to Nim

Well... Correct me if I'm wrong, but this entire thread is about compiling 
Clojure to native targets. Are folks here really talking about embedding a 
JVM?

Has cljs been poor roi? :-)

Chris


On Friday, May 1, 2015 at 2:25:27 PM UTC-7, raould wrote:

 I just would guess that anything other than an embedded JVM would 
 be... poor r.o.i., to be polite. 


-- 
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: Embedded systems and transpiling Clojure to Nim


Another possibility is https://github.com/takeoutweight/clojure-scheme. It 
compiles Clojure to Gambit Scheme to C to metal. It's been a couple of 
years since there was any activity on that project, but it's possible some 
attention there could get it where you need it. 

Nim seems interesting though. I wasn't really aware of it; only the 
combinatorial game by the same name.

In any case, I think this is an awesome goal. I'd particularly like to see 
an option for running Clojure of some ilk on Arduino and the like.

Cheers

Chris

-- 
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: Embedded systems and transpiling Clojure to Nim

Both Nim and Pixie ultimately compile to C, and would have just as many
layers of indirection.

On Fri, May 1, 2015 at 2:37 PM, Raoul Duke rao...@gmail.com wrote:

 all i'm trying to say is that the more layers of indirection you add,
 the more i won't give you any money on kickstarter.

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


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

Re: Embedded systems and transpiling Clojure to Nim