Re: Setting the font size

2016-10-06 Thread Cecil Westerhof
2016-10-05 13:22 GMT+02:00 Sanel Zukan :
> Setting fonts under Seesaw isn't the most intuitive option, so you'd
> have to dig into Swing core for this and investigate
> java.swing.UIManager documentation.
>
> Here is a function that I often use in my applications:
>
> (defn set-font
>   "Set default font for the whole Swing application. Make sure
> to call it before UI was shown."
>   [name size]
>   (let [res  (FontUIResource. name Font/PLAIN size)
> what ["Button.font" "ToggleButton.font"
>   "RadioButton.font" "CheckBox.font"
>   "ColorChooser.font" "ComboBox.font"
>   "Label.font" "List.font"
>   "MenuBar.font" "MenuItem.font"
>   "RadioButtonMenuItem.font"
>   "CheckBoxMenuItem.font" "Menu.font"
>   "PopupMenu.font" "OptionPane.font"
>   "Panel.font" "ProgressBar.font"
>   "ScrollPane.font" "Viewport.font"
>   "TabbedPane.font" "Table.font"
>   "TableHeader.font" "TextField.font"
>   "PasswordField.font" "TextArea.font"
>   "TextPane.font" "EditorPane.font"
>   "TitledBorder.font" "ToolBar.font"
>   "ToolTip.font" "Tree.font"]]
> (doseq [key what]
>   (UIManager/put key res
>
> I use it like:
>
> (defn runner []
>   (seesaw/native!)
>   (seesaw/invoke-later
>(set-font "Sans Serif" 11)
>(seesaw/show! )))

Thanks that works. I should put it always on my high-resolution screen then.

Two points:
When using:
(seesaw/invoke-later
I get:
Exception in thread "main" java.lang.RuntimeException: No such
namespace: seesaw

What do I need to do to get rid of this?

Is it possible to increase the font in the title from the window?
Probably not, because I think that is done by the Operating System.
But maybe I am wrong.


> On Wednesday, October 5, 2016 at 10:47:14 AM UTC+2, Cecil Westerhof wrote:
>>
>> I already asked it on Clojure-seesaw, but the last three months there
>> has been no activity there. So I ask it here also.
>>
>> Some time ago I wrote a Clojure program that uses SeeSaw. I just
>> bought a high resolution monitor and now I cannot read the text in my
>> JFrames anymore. How can I increase the default font size?
>>
>> I create the frames like:
>>   (let [
>> ^JFrame
>> other-frm (frame :title "Other"  :on-close
>> :hide:resizable? false)
>>
>> I now generate buttons like:
>> ^JButton
>> all-authors   (button :text "All Authors"
>>   :font {:size 25}
>>   :listen [:action (fn [e] (show-all-authors))])
>>
>> But I have to set the font for every label in this way.
>>
>> At another part I have:
>>   (grid-bag-layout
>>search-panel
>>:fill  :HORIZONTAL
>>:ipadx 8
>>:ipady 4
>>:gridy i
>>:gridx 0 ^JLabel (label description)
>>:gridx 1 ^JTextField
>>(text  :columns 40
>>   :listen
>>   [:action (fn [e]
>>(let [
>>  search-str (text e)
>>  ]
>>  (when (not (empty? search-str))
>>(function search-str
>>   ]
>>
>> At the moment I do not know how to set the font there.
>>
>> Is there also a way to increase/decrease the fontsize in the whole
>> application. I now have amiddle and high resolution screen. It would
>> be nice if when I put things on the other monitor, the fonts would
>> scale.

-- 
Cecil Westerhof

-- 
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: Setting the font size

2016-10-06 Thread Sanel Zukan
Cecil Westerhof  writes:
> Two points:
> When using:
> (seesaw/invoke-later
> I get:
> Exception in thread "main" java.lang.RuntimeException: No such
> namespace: seesaw
>
> What do I need to do to get rid of this?

 (require '[seesaw.core :as seesaw])

> Is it possible to increase the font in the title from the window?
> Probably not, because I think that is done by the Operating System.
> But maybe I am wrong.

No; this is OS specific and the only safe option is to manually draw
frame titlebar and borders, handling all mouse/keyboard/DnD events by
yourself.

Other option is to go with frameworks that has this feature, like WebLaF
(http://weblookandfeel.com/).

Best,
Sanel

-- 
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: Setting the font size

2016-10-06 Thread Cecil Westerhof
2016-10-06 12:08 GMT+02:00 Sanel Zukan :
> Cecil Westerhof  writes:
>> Two points:
>> When using:
>> (seesaw/invoke-later
>> I get:
>> Exception in thread "main" java.lang.RuntimeException: No such
>> namespace: seesaw
>>
>> What do I need to do to get rid of this?
>
>  (require '[seesaw.core :as seesaw])

I saw that I already had:
(use 'seesaw.core)
and called:
(invoke-later

So I changed your call also into (invoke-later. Is this OK, or is
there a reason to do it your way?


> No; this is OS specific and the only safe option is to manually draw
> frame titlebar and borders, handling all mouse/keyboard/DnD events by
> yourself.
>
> Other option is to go with frameworks that has this feature, like WebLaF
> (http://weblookandfeel.com/).

Well, for the moment I accept it then.

-- 
Cecil Westerhof

-- 
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: Recursive clojure.spec doesn't work

2016-10-06 Thread Alex Miller
Can you share a specific case? 

-- 
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: Setting the font size

2016-10-06 Thread Sanel Zukan
Cecil Westerhof  writes:
> I saw that I already had:
> (use 'seesaw.core)
> and called:
> (invoke-later
>
> So I changed your call also into (invoke-later. Is this OK, or is
> there a reason to do it your way?

That is fine. It is more idiomatic to use 'require' to avoid namespace
conflicts, as explained on 
http://stackoverflow.com/questions/871997/difference-between-use-and-require.

Best,
Sanel

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Dragan Djuric
Hey Mike,

A friend asked me if I know of any good (usable) deep learning libraries 
for Clojure. I remembered you had some earlier neural networks library that 
was at least OK for experimenting, but seems abandoned for your current 
work in a similar domain. A bit of digging lead me to this post.

I understand that this library may not be completely ready yet, but I 
wandered wheter now you were able to give a better estimation of where it 
stands in comparison with other DL offerings, like what deeplearning4j guys 
are doing, or even with the established non-Java libraries such as Theano, 
Torch, Caffe, and TensorFlow. What is the chance of you releasing it even 
if it is not 100% ready? 

I get the reluctance to commit to a certain API, but I don't think everyone 
will rush to commit their code to the API you release anyway, and the open 
development will certainly help both the (potential) users and your team 
(by returning free testing & feedback).


On Tuesday, May 31, 2016 at 7:17:35 AM UTC+2, Mikera wrote:
>
> I've been working with a number of collaborators on a deep learning 
> library for Clojure. 
>
> Some key features:
> - An abstract API for key machine learning functionality
> - Ability to declare graphs / stacks of operations (somewhat analogous to 
> tensorflow)
> - Support for multiple underlying implementations (ClojureScript, JVM, 
> CPU, GPU)
> - Integration with core.matrix for N-dimensional data processing
>
> We intend to release as open source. We haven't released yet because we 
> want to get the API right first but it is looking very promising.
>
> On Tuesday, 31 May 2016 02:34:41 UTC+8, kovasb wrote:
>>
>> Anyone seriously working on deep learning with Clojure?
>>
>> I'm working with Torch at the day job, and have done work integrating 
>> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what 
>> needs to be done. A bit too much to bite off on my own in my spare time. 
>>
>> So is anyone out there familiar enough with these tools to have a 
>> sensible conversation of what could be done in Clojure?
>>
>> The main question on my mind is: what level of abstraction would be 
>> useful?
>>
>> All the existing tools have several layers of abstraction. In Tensorflow, 
>> at the bottom theres the DAG of operations, and above that a high-level 
>> library of python constructs to build the DAG (and now of course libraries 
>> going higher still). In Torch, its more complicated: there's the excellent 
>> tensor library at the bottom; the NN modules that are widely used; and 
>> various non-orthogonal libraries and modules stack on top of those. 
>>
>> One could try to integrate at the bottom layer, and then re-invent the 
>> layers above that in Clojure. Or one could try to integrate at the higher 
>> layers, which is more complicated, but gives more leverage from the 
>> existing ecosystem. 
>>
>> Any thoughts?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

-- 
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: Setting the font size

2016-10-06 Thread Cecil Westerhof
2016-10-06 14:33 GMT+02:00 Sanel Zukan :
> Cecil Westerhof  writes:
>> I saw that I already had:
>> (use 'seesaw.core)
>> and called:
>> (invoke-later
>>
>> So I changed your call also into (invoke-later. Is this OK, or is
>> there a reason to do it your way?
>
> That is fine. It is more idiomatic to use 'require' to avoid namespace
> conflicts, as explained on 
> http://stackoverflow.com/questions/871997/difference-between-use-and-require.

OK, it was a little work, but I use the require variant now. I have:
(ns quotes.core
(:require
 [clj-time.local:asl]
 [clojure.java.jdbc :asjdbc]
 [clojure.pprint:refer [pprint print-table]]
 [clojure.string:refer [lower-case]]
 [seesaw.core   :asseesaw]
 [yesql.core:refer [defquery defqueries]]
 ))

(import '(javax.swing JButton JCheckBox JDialog JFrame JLabel JOptionPane JPanel
  JTextField UIManager plaf.FontUIResource)
'(java.awtFont GridBagLayout GridBagConstraints))

-- 
Cecil Westerhof

-- 
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] Re-launching Expectations!

2016-10-06 Thread Sean Corfield
Expectations – a minimalist’s unit testing framework – is being re-launched!

 

adding signal, removing noise

 

Jay Fields’ awesome unit testing library and all of the associated tooling has 
now been pulled together under a single GitHub organization:

 

https://github.com/clojure-expectations

 

The documentation is available here:

 

https://clojure-expectations.github.io

 

(for now, this is just a copy of Jay’s documentation site for Expectations but 
the plan is to expand it to include all of the tooling as well)

 

If you use Expectations and any of its current tooling, we’d like to have your 
input – please feel free to open GitHub issues with suggestions!

 

If you don’t use Expectations but you like BDD-style terminology, perhaps it’s 
time to take a look?

 

Why has this happened?

 

Expectations doesn’t currently support the clojure.test “protocol” that CIDER 
(and other tooling) expects, but making that happen is going to involve quite a 
few changes (or additions) to how Expectations works, as well as a ripple 
effect through the tooling.

 

The current maintainers did not necessarily have the time to invest in such 
changes, but were very open to pooling their work and making it easier for 
others to get involved. World Singles is a heavy user of Expectations so I have 
a vested interest in helping to maintain the Expectations ecosystem going 
forward, especially after adding support for Boot.

 

I’d like to thank Jay Fields for creating Expectations – it has made me love 
testing all over again! – and also thanks to Gareth Jones and Jake McCrary for 
their Leiningen and Emacs tooling.

 

Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN

An Architect's View -- http://corfield.org/

 

"Perfection is the enemy of the good."

-- Gustave Flaubert, French realist novelist (1821-1880)

 

 

-- 
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] Re-launching Expectations!

2016-10-06 Thread Colin Yates
Thanks Sean. I did have a look at that a whilst ago (when I was
considering migrating to core clojure.test from midge). I think I 'get
it', but is there a 'benefits over clojure.test' blog anywhere?

I wonder if it is the benefits are more subjective - I personally like
the names I give to tests etc.

Anyways, thanks for picking this up.

On 6 October 2016 at 18:05, Sean Corfield  wrote:
> Expectations – a minimalist’s unit testing framework – is being re-launched!
>
>
>
> adding signal, removing noise
>
>
>
> Jay Fields’ awesome unit testing library and all of the associated tooling
> has now been pulled together under a single GitHub organization:
>
>
>
> https://github.com/clojure-expectations
>
>
>
> The documentation is available here:
>
>
>
> https://clojure-expectations.github.io
>
>
>
> (for now, this is just a copy of Jay’s documentation site for Expectations
> but the plan is to expand it to include all of the tooling as well)
>
>
>
> If you use Expectations and any of its current tooling, we’d like to have
> your input – please feel free to open GitHub issues with suggestions!
>
>
>
> If you don’t use Expectations but you like BDD-style terminology, perhaps
> it’s time to take a look?
>
>
>
> Why has this happened?
>
>
>
> Expectations doesn’t currently support the clojure.test “protocol” that
> CIDER (and other tooling) expects, but making that happen is going to
> involve quite a few changes (or additions) to how Expectations works, as
> well as a ripple effect through the tooling.
>
>
>
> The current maintainers did not necessarily have the time to invest in such
> changes, but were very open to pooling their work and making it easier for
> others to get involved. World Singles is a heavy user of Expectations so I
> have a vested interest in helping to maintain the Expectations ecosystem
> going forward, especially after adding support for Boot.
>
>
>
> I’d like to thank Jay Fields for creating Expectations – it has made me love
> testing all over again! – and also thanks to Gareth Jones and Jake McCrary
> for their Leiningen and Emacs tooling.
>
>
>
> Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
>
> An Architect's View -- http://corfield.org/
>
>
>
> "Perfection is the enemy of the good."
>
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: [ANN] Re-launching Expectations!

2016-10-06 Thread Sean Corfield
> is there a 'benefits over clojure.test' blog anywhere?

Not that I’m aware of. I added a GH issue against the website content for that. 
Jay wrote a series of blog posts about Expectations back in 2011 that included 
the justification for it:

http://blog.jayfields.com/2011/11/clojure-expectations-introduction.html 

> I wonder if it is the benefits are more subjective

Yes, I find the BDD-style of Expectations much more to my liking than the 
assertive style of clojure.test – the latter feels very imperative to me. So 
there’s definitely an element of stylistic preference at play here.

> I personally like the names I give to tests etc.

Jay has an opinion on that – see 
http://blog.jayfields.com/2011/11/clojure-expectations-unit-testing-wrap.html

I’m split on the topic. There’s a practical reason for giving tests names, and 
that relates to tooling and, in particular, what CIDER and other tools expect 
(and in fact that is what has triggered this whole re-launching: in order to 
better support tooling at large, Expectations needs to provide a way to give 
predictable names to tests so that tooling can run and re-run individual tests).

Sean



-- 
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] Re-launching Expectations!

2016-10-06 Thread Colin Yates
Thanks Sean.

On 6 October 2016 at 19:03, Sean Corfield  wrote:
>> is there a 'benefits over clojure.test' blog anywhere?
>
> Not that I’m aware of. I added a GH issue against the website content for 
> that. Jay wrote a series of blog posts about Expectations back in 2011 that 
> included the justification for it:
>
> http://blog.jayfields.com/2011/11/clojure-expectations-introduction.html
>
>> I wonder if it is the benefits are more subjective
>
> Yes, I find the BDD-style of Expectations much more to my liking than the 
> assertive style of clojure.test – the latter feels very imperative to me. So 
> there’s definitely an element of stylistic preference at play here.
>
>> I personally like the names I give to tests etc.
>
> Jay has an opinion on that – see 
> http://blog.jayfields.com/2011/11/clojure-expectations-unit-testing-wrap.html
>
> I’m split on the topic. There’s a practical reason for giving tests names, 
> and that relates to tooling and, in particular, what CIDER and other tools 
> expect (and in fact that is what has triggered this whole re-launching: in 
> order to better support tooling at large, Expectations needs to provide a way 
> to give predictable names to tests so that tooling can run and re-run 
> individual tests).
>
> Sean
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: Recursive clojure.spec doesn't work

2016-10-06 Thread Aaron
Well I'm referring to the OP's original example:

(s/def :html/element
>   (s/cat
>:tag keyword?
>:attrs map?
>:children (s/* (s/alt :element (s/spec :html/element)
>  :string  string?
>
> The exception says: "Unable to resolve spec: :html/element".
>

On Thursday, October 6, 2016 at 7:43:14 AM UTC-4, Alex Miller wrote:
>
> Can you share a specific case? 

-- 
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 + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

2016-10-06 Thread Daniel Compton
Hi Ray

We have a ClojureScript + Electron + Re-Frame application that we run.
Those three work together quite nicely. I’m not totally clear what it would
look like for Clojure + Boot + ProtoRepl to co-exist with the first three?
Can you explain what you’re envisioning some more?

On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter <
mathias.dewach...@gmail.com> wrote:

> Hi Ray,
>
> I'm in a pretty much identical situation, except that I'm using re-frame
> for the gui that connects to the websocket the local clojure app provides.
> I haven't gotten as far as you yet, since I haven't yet started the "port"
> of the gui from browser to electron. I also have two code bases, but am
> wondering if the merge makes sense. So, I would be very interested to see
> read about your experience!
>
> --
> 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.
>
-- 

Daniel

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread kovas boguta
+1 to Dragan's inquiry.

FWIW, was reviewing the state of affairs the other day:

- MXNet currently has the best JVM interop story, among DL frameworks that
have competitive perf. - DL4J has improved a lot recently but still looks
like it has a ways to go in terms of perf.

Right now I'm more interesting in word2vec type things, which don't require
a deep net, so I might give Neanderthal a shot.

By the way, I'd love to see matrix/tensor benchmarks of Neanderthal and
Vectorz vs ND4J, MXNet's NDArray, and BidMat..  :)



On Thu, Oct 6, 2016 at 8:44 AM, Dragan Djuric  wrote:

> Hey Mike,
>
> A friend asked me if I know of any good (usable) deep learning libraries
> for Clojure. I remembered you had some earlier neural networks library that
> was at least OK for experimenting, but seems abandoned for your current
> work in a similar domain. A bit of digging lead me to this post.
>
> I understand that this library may not be completely ready yet, but I
> wandered wheter now you were able to give a better estimation of where it
> stands in comparison with other DL offerings, like what deeplearning4j guys
> are doing, or even with the established non-Java libraries such as Theano,
> Torch, Caffe, and TensorFlow. What is the chance of you releasing it even
> if it is not 100% ready?
>
> I get the reluctance to commit to a certain API, but I don't think
> everyone will rush to commit their code to the API you release anyway, and
> the open development will certainly help both the (potential) users and
> your team (by returning free testing & feedback).
>
>
> On Tuesday, May 31, 2016 at 7:17:35 AM UTC+2, Mikera wrote:
>>
>> I've been working with a number of collaborators on a deep learning
>> library for Clojure.
>>
>> Some key features:
>> - An abstract API for key machine learning functionality
>> - Ability to declare graphs / stacks of operations (somewhat analogous to
>> tensorflow)
>> - Support for multiple underlying implementations (ClojureScript, JVM,
>> CPU, GPU)
>> - Integration with core.matrix for N-dimensional data processing
>>
>> We intend to release as open source. We haven't released yet because we
>> want to get the API right first but it is looking very promising.
>>
>> On Tuesday, 31 May 2016 02:34:41 UTC+8, kovasb wrote:
>>>
>>> Anyone seriously working on deep learning with Clojure?
>>>
>>> I'm working with Torch at the day job, and have done work integrating
>>> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what
>>> needs to be done. A bit too much to bite off on my own in my spare time.
>>>
>>> So is anyone out there familiar enough with these tools to have a
>>> sensible conversation of what could be done in Clojure?
>>>
>>> The main question on my mind is: what level of abstraction would be
>>> useful?
>>>
>>> All the existing tools have several layers of abstraction. In
>>> Tensorflow, at the bottom theres the DAG of operations, and above that a
>>> high-level library of python constructs to build the DAG (and now of course
>>> libraries going higher still). In Torch, its more complicated: there's the
>>> excellent tensor library at the bottom; the NN modules that are widely
>>> used; and various non-orthogonal libraries and modules stack on top of
>>> those.
>>>
>>> One could try to integrate at the bottom layer, and then re-invent the
>>> layers above that in Clojure. Or one could try to integrate at the higher
>>> layers, which is more complicated, but gives more leverage from the
>>> existing ecosystem.
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] diff-eq - generate signal processing functions using difference equations

2016-10-06 Thread Steven Yi
Hi All,

I'm pleased to announce the release of diff-eq, a library for
generating signal processing functions using difference equations.

https://github.com/kunstmusik/diff-eq
https://clojars.org/kunstmusik/diff-eq

The library provides the dfn macro which takes in a set of difference
equations and analyzes, rewrites, reorders, and generates a function
suitable for sample-at-a-time processing.  The dfn macro will take
care to handle historical values for input and generated signals.

The README.md shows examples of writing one-pole, one-zero, biquad
(transposed direct form II), and zero-delay feedback one-pole filters
using diff-eq.

The goal for this project was to stay within the math of difference
equations and not have to worry about translating that into working
signal processing code, particularly dealing with storage/retrieval of
history. The generated code uses arrays for memory and optimizes to
use a simple array get/set for single-sample history, or an
array-backed ring-buffer for signals where multiple values of history
are required. Function arguments and return values are automatically
type hinted for doubles so users will not need to do so in their own
code.

The scope of the project is currently focused around audio signal
processing.  A list of todos is given the docs/intro.md page, with the
support of initial conditions and initial state as the primary issues
that will be tackled next. As always, feedback very welcome!

Thanks!
steven

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


Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Dragan Djuric
Hi Kovas,


> By the way, I'd love to see matrix/tensor benchmarks of Neanderthal and 
> Vectorz vs ND4J, MXNet's NDArray, and BidMat..  :)
>

I don't have exact numbers, but will try to give you a few pointers to help 
you if you decide to investigate this further:

0. Neanderthal's scope is matrices and linear algebra. NNs and other stuff 
is something that could be built on top of it (assuming that the features 
needed are implemented, which may or may not be true yet), but certainly 
not in Neanderthal.

1. Neanderthal is a 100% Clojure solution. One of the main goals, other 
than the speed, of course, is that it is simple and straightforward, with 
no overhead. That means that you always know what backend you are using, 
and you get exactly the speed of that backend. If it works, you are sure it 
works at the full speed, with no slow fallback. Theoretically, of course, 
there is always some overhead of FFI, but in Neanderthal it is so miniscule 
that you can ignore it for all uses that come to my mind. So, basically, 
Neanderthal is as fast as ATLAS on CPU and CLBlast on GPU (both offer 
state-of-the-art speed) or any (not yet existing) pure java engine that I 
might plug in in the future if necessary.

2. All those other libraries, besides not targeting Clojure at all except 
for general "you can call Java from Clojure", are trying to be everything 
for everyone. That has its strengths, because you are, generally, able to 
accommodate more use cases. On the other hand, it complicates things too 
much, and can lead to overblown beasts. For example, it might seem good to 
support MKL, and, ATLAS, and OpenBLAS, and netlib BLAS, and some imaginary 
fallback solution, like ND4J does (or tries to do), but what's the point of 
it when today they have more or less the same performance (MKL being a bit 
faster - in percentages only - but requires $$), and supporting all that 
stuff makes code AND the installation much, much, more compelex. BLAS is so 
mature that I think it is better to choose one solution and offer it out of 
the box. Technically, neanderthal can support all other native blas 
libraries too, but I intentionally restricted that option because I think 
fiddling with it does more harm than good. I prefer to give users one Ford 
model T, than let them choose between 20 different horse carriages. And, if 
they can even choose the color, provided that their choice is black :)

3. ND4J is, in my opinion, a typical overblown solution. deeplearning4j 
guys got the investment dollars, and have to rush to the market with 
business-friendly solution, which usually favors having a checklist of 
features regardless of whether those features make sense for the little 
guy. I hope they succeed in the business sense, but the code I'm seeing 
from them does not seem promising to me regarding Java getting a great 
DL/NN library.

4. NDArray is actually, as the name suggests, a nd array library, and not a 
matrix library. Why is this important?  Vectors and matrices are something 
that has been very well researched through decades. The ins and outs of 
algorithm/architecture fit are known and implemented in BLAS libraries, so 
you are sure that you get the full performance. N-dimensional vectors 
(sometime referred as tensors, although that name is not accurate IMO) not 
so much. So, it is easy that an operation that looks convenient does not 
lead to a good performance. I do not say it is bad, because if you need 
that operation, it is better to have something than nothing, but for now I 
decided to not support 3+ dimensions. This is something that might belong 
to Neanderthal or on top of it. A long term goal, to be sure. Another 
aspect of that story is knowledge: most books that I read from the fields 
of ML/AI give all formulas as vectors of matrices. Basically, matrices are 
at least 95% (if not more) of potential users need or even understand!

5. BidiMat seems to have much larger scope. For example, at their benchmark 
page, I see benchmarks for machine learning algorithms, but for nothing 
matrix-y.

The speed comparison; it boils down to this: both Neanderthal and those 
libraries use (or can be linked to use) the same native BLAS libraries. I 
took great care to make sure Neanderthal does not incur any copying or 
calling overhead. From what I saw glancing at the code of other libraries, 
they didn't. They might support that if you set up everything well among 
lots of options, or they don't if you do not know how to ensure this. So I 
doubt any of those could be noticeably faster, and they can be much slower 
if you slip somewhere.
I would also love to see straightforward numbers, but I was unable to find 
anything like that for those libraries. BidiMat, for example, gives 
benchmarks of K-Means on MNIST dataset - I do not know how this can be used 
to discern how fast is it with matrices, other that it is, generally, fast 
at K-Means.

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

Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Dragan Djuric
Just a small addition: I looked at BidiMat's code and even at the JNI/C 
level they are doing some critical things that work on small scale but byte 
unexpectedly when JVM needs to rearrange memory and also may trigger 
copying.

On Thursday, October 6, 2016 at 10:46:04 PM UTC+2, Dragan Djuric wrote:
>
> Hi Kovas,
>
>
>> By the way, I'd love to see matrix/tensor benchmarks of Neanderthal and 
>> Vectorz vs ND4J, MXNet's NDArray, and BidMat..  :)
>>
>
> I don't have exact numbers, but will try to give you a few pointers to 
> help you if you decide to investigate this further:
>
> 0. Neanderthal's scope is matrices and linear algebra. NNs and other stuff 
> is something that could be built on top of it (assuming that the features 
> needed are implemented, which may or may not be true yet), but certainly 
> not in Neanderthal.
>
> 1. Neanderthal is a 100% Clojure solution. One of the main goals, other 
> than the speed, of course, is that it is simple and straightforward, with 
> no overhead. That means that you always know what backend you are using, 
> and you get exactly the speed of that backend. If it works, you are sure it 
> works at the full speed, with no slow fallback. Theoretically, of course, 
> there is always some overhead of FFI, but in Neanderthal it is so miniscule 
> that you can ignore it for all uses that come to my mind. So, basically, 
> Neanderthal is as fast as ATLAS on CPU and CLBlast on GPU (both offer 
> state-of-the-art speed) or any (not yet existing) pure java engine that I 
> might plug in in the future if necessary.
>
> 2. All those other libraries, besides not targeting Clojure at all except 
> for general "you can call Java from Clojure", are trying to be everything 
> for everyone. That has its strengths, because you are, generally, able to 
> accommodate more use cases. On the other hand, it complicates things too 
> much, and can lead to overblown beasts. For example, it might seem good to 
> support MKL, and, ATLAS, and OpenBLAS, and netlib BLAS, and some imaginary 
> fallback solution, like ND4J does (or tries to do), but what's the point of 
> it when today they have more or less the same performance (MKL being a bit 
> faster - in percentages only - but requires $$), and supporting all that 
> stuff makes code AND the installation much, much, more compelex. BLAS is so 
> mature that I think it is better to choose one solution and offer it out of 
> the box. Technically, neanderthal can support all other native blas 
> libraries too, but I intentionally restricted that option because I think 
> fiddling with it does more harm than good. I prefer to give users one Ford 
> model T, than let them choose between 20 different horse carriages. And, if 
> they can even choose the color, provided that their choice is black :)
>
> 3. ND4J is, in my opinion, a typical overblown solution. deeplearning4j 
> guys got the investment dollars, and have to rush to the market with 
> business-friendly solution, which usually favors having a checklist of 
> features regardless of whether those features make sense for the little 
> guy. I hope they succeed in the business sense, but the code I'm seeing 
> from them does not seem promising to me regarding Java getting a great 
> DL/NN library.
>
> 4. NDArray is actually, as the name suggests, a nd array library, and not 
> a matrix library. Why is this important?  Vectors and matrices are 
> something that has been very well researched through decades. The ins and 
> outs of algorithm/architecture fit are known and implemented in BLAS 
> libraries, so you are sure that you get the full performance. N-dimensional 
> vectors (sometime referred as tensors, although that name is not accurate 
> IMO) not so much. So, it is easy that an operation that looks convenient 
> does not lead to a good performance. I do not say it is bad, because if you 
> need that operation, it is better to have something than nothing, but for 
> now I decided to not support 3+ dimensions. This is something that might 
> belong to Neanderthal or on top of it. A long term goal, to be sure. 
> Another aspect of that story is knowledge: most books that I read from the 
> fields of ML/AI give all formulas as vectors of matrices. Basically, 
> matrices are at least 95% (if not more) of potential users need or even 
> understand!
>
> 5. BidiMat seems to have much larger scope. For example, at their 
> benchmark page, I see benchmarks for machine learning algorithms, but for 
> nothing matrix-y.
>
> The speed comparison; it boils down to this: both Neanderthal and those 
> libraries use (or can be linked to use) the same native BLAS libraries. I 
> took great care to make sure Neanderthal does not incur any copying or 
> calling overhead. From what I saw glancing at the code of other libraries, 
> they didn't. They might support that if you set up everything well among 
> lots of options, or they don't if you do not know how to ensure this. So I 
> doubt any of those could 

Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-06 Thread 'Xman' via Clojure
It's been many years of postponing learning programming, because I 
considered the popular languages of that time not right.
It took me nearly 3 years to learn and build a website using another stack 
(I wont advertise here), 
and without having much previous knowledge in programming.  I have not 
deployed the website yet. 
I would like to know if Clojure is a great option to make websites ?

I found out that there are new features on the web that Clojure is better 
for, but I don't use those features in the present. 
When I choose to learn a language I decide by myself, and after listening 
to a video talk, it gives me reasons to think that its better.
I want to learn the language and "frameworks" (or how to create the 
architecture) much quicker than previous attempt.

I'd like to know if its possible to do that in less than 6 months or if I 
should stay with the framework I know ?

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-06 Thread Gregg Reynolds
the

On Oct 6, 2016 4:39 PM, "'Xman' via Clojure" 
wrote:
>
> It's been many years of postponing learning programming, because I
considered the popular languages of that time not right.
> It took me nearly 3 years to learn and build a website using another
stack (I wont advertise here),
> and without having much previous knowledge in programming.  I have not
deployed the website yet.
> I would like to know if Clojure is a great option to make websites ?
>

yes.

> I found out that there are new features on the web that Clojure is better
for, but I don't use those features in the present.
> When I choose to learn a language I decide by myself, and after listening
to a video talk, it gives me reasons to think that its better.
> I want to learn the language and "frameworks" (or how to create the
architecture) much quicker than previous attempt.
>
> I'd like to know if its possible to do that in less than 6 months or if I
should stay with the framework I know ?
>

welcome to clojure. but, this is a question that cannot be answered in any
meaningful way.  of course it is possible, but  I dare say that that's not
your real question.  you want to know if it is worth the effort, no?  if
you have an open mind and are capable of learning (not always the case)
then yes, it is worth the effort.   then again, since you have not said
what "framework" you're talking about, maybe no.

how are we to know what "much quicker than previous attempt" is supposed to
mean?

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.

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-06 Thread Sean Corfield
On 10/6/16, 2:05 PM, "'Xman' via Clojure"  wrote:

> I would like to know if Clojure is a great option to make websites ?

 

Yes and no. There are a lot of folks here building web _applications_ with 
Clojure and according to the annual informal “State of Clojure” survey, web 
development is the more common use for Clojure. See my comments on “frameworks” 
below…

 

> I found out that there are new features on the web that Clojure is

> better for, but I don't use those features in the present. 

 

Well, immutability, the abstractions, and the ease with which you can write 
code that can safely use multiple threads are applicable to even fairly basic 
web applications. I think you’d find that if you were using Clojure, you would 
just naturally use those features.

 

> I want to learn the language and "frameworks" (or how to create the 
> architecture)

 

…many technologies used for web sites leverage frameworks. Clojure’s approach 
is generally more focused on composing libraries to construct a solution. One 
of the things that a lot of folks coming to Clojure find confusing or strange 
is that there really are no actively maintained “frameworks” in the sense of 
Django or Rails or Drupal etc.

 

There’s also really no “standard” architecture for a Clojure web application. 
At its core, it’s almost certain to have Ring (or http-kit), maybe Compojure, 
some “standard” middleware (a concept not always familiar to folks from other 
technologies), and then the rest will be built to suit whatever they prefer… 
much will depend on what persistent storage technology they decide to use, 
whether they are comfortable with an asynchronous programming model, and so on…

 

> I'd like to know if its possible to do that in less than 6 months

 

Possible? Yes, it should be. If you have just a few years of programming 
experience, you likely won’t have any deeply ingrained habits that would make 
learning Clojure more difficult (as can be the case sometimes for folks deeply 
steeped in OOP thinking). It’s hard to say how proficient you’d be after six 
months. Some folks take to FP (functional programming) a lot quicker than 
others, regardless of their background. But, overall, Clojure itself is a 
relatively small, simple language. The idioms can be harder to internalize.

 

> or if I should stay with the framework I know ?

 

That depends on why you are learning programming in the first place. If you 
want to become a better programmer in general, then learning a functional 
programming language such as Clojure is going to be a good thing, even if you 
ultimately decide to stick with the other technology. The “Pragmatic 
Programmer” book suggests attempting to learn a new programming language every 
year – that may not be practical for everyone but it’s certainly a good 
“stretch goal” for self-improvement.

 

Most people who learn Clojure seem to really enjoy using it. Hoping to 
experience that “joy” is a good reason to try it out.

 

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

 

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-06 Thread TR NS


On Thursday, October 6, 2016 at 5:39:43 PM UTC-4, Xman wrote:
>
> It's been many years of postponing learning programming, because I 
> considered the popular languages of that time not right.
> It took me nearly 3 years to learn and build a website using another stack 
> (I wont advertise here), 
>

I am going to take a guess that it was either PHP or Ruby on Rails. Don't 
consider it advertising but it would help to know where you are coming 
from. We all started somewhere.
 

> and without having much previous knowledge in programming.  I have not 
> deployed the website yet. 
> I would like to know if Clojure is a great option to make websites ?
>

Sure. But there are a lot options people consider "great" these days.
 

>
> I found out that there are new features on the web that Clojure is better 
> for, but I don't use those features in the present. 
> When I choose to learn a language I decide by myself, and after listening 
> to a video talk, it gives me reasons to think that its better.
> I want to learn the language and "frameworks" (or how to create the 
> architecture) much quicker than previous attempt.
>
> I'd like to know if its possible to do that in less than 6 months or if I 
> should stay with the framework I know ?
>

Depends. Lisp may be a bit of a learning curve for you, not to mention it's 
JVM underpinnings. There are a variety of good complete options out there 
today, Node.js based options like Angler and Meteor, and ReactJS has blown 
up, also Elm is getting a lot talk these days. Then there is the 
Elixir/Phoenix option which is looking pretty sweet, especially if you 
expect heavy loads. Having said all that, Clojure is pretty impressive too. 
So it has more to do with what you want to achieve and the reason you would 
like to learn it then with any specific platform. IMO.


 

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread kovas boguta
On Thu, Oct 6, 2016 at 4:46 PM, Dragan Djuric  wrote:


> s more harm than good. I prefer to give users one Ford model T, than let
> them choose between 20 different horse carriages. And, if they can even
> choose the color, provided that their choice is black :)
>

Thanks the for the comments, which I largely agree with.

I understand your design philosophy and agree its a useful point in the
space to have.

One question:

Is it possible to feed Neanderthal's matrix representation (the underlying
bytes) into one of these other libraries, to obtain
computations Neanderthal doesn't support?

My situation: Neanderthal covers some of the algorithms I'd like to
implement. It looks easier to get started with and understand than the
alternatives. But down the line I'll likely want to do convolution,
sigmoid, the typical Neural Network layers. Note, I don't care about
'tensors' exactly; the bookkeeping to simulate a tensor can be automated,
but the fundamental operations cannot. So there is a question of whether to
just absorb the learning curve and shortcomings of these more general
libraries rather than to risk switching horses midstream.

I imagine I'm not alone in this.. if there was a straightforward story for
how to interop Neanderthal when necessary with some more general library
that would be powerful. Unfortunately I'm not sufficiently expert to
evaluate which of the choices would be most pragmatic and how to pull it
off.

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Mikera
Hi Dragan,

We have things working quite well (including stuff like cuDNN integration 
for convolution networks on the GPU). We also have all of the standard 
stuff (many different layer types, dropout, noise function, regularisation 
etc.). However I think it still needs a bunch of work before we stabilise 
on the core API.

Opening the source is not entirely my decision, this is a collaboration 
with the Thinktopic folks (Jeff Rose et al.). I'm personally in favour of 
being pretty open about this stuff but I do think that it would be a 
mistake if people build too much stuff on top of the wrong API which is 
likely to happen if we release prematurely.

Things I'm paricularly keen to have nailed down in particular before we go 
public:
1. A tensorflow-like DAG model that allows arbitrary operations to be 
composed compose into (possibly nested) graphs
2. Enough abstraction that different backends work (ClojureScript, 
Pure-JVM, Native, GPU etc.). core.matrix provides most of this, but there 
are still some deep-learning specific operations that need tuning and can 
be quite backend-specific, e.g. cuDNN has some specific ways of dealing 
with mini-batches which we need to get right. I'd love to try Neanderthal 
with this too if we can get the core.matrix integration working.
3. Decent, stable APIs for the algorithms that you typically want to run 
for mini-batch training, cross-validation etc.
4. Pluggable gradient optimisation methods (we currently have stuff like 
ADADELTA, SDG, ADAM etc. but would like to make sure this is sufficiently 
general to support any optimisation method)

I'll have a talk with the Thinktopic folks and see if we can come up with a 
timeline for a open source release. In the meantime, if anyone is *really* 
interested then we may be able to arrange collaboration on a private basis.




On Thursday, 6 October 2016 20:44:11 UTC+8, Dragan Djuric wrote:
>
> Hey Mike,
>
> A friend asked me if I know of any good (usable) deep learning libraries 
> for Clojure. I remembered you had some earlier neural networks library that 
> was at least OK for experimenting, but seems abandoned for your current 
> work in a similar domain. A bit of digging lead me to this post.
>
> I understand that this library may not be completely ready yet, but I 
> wandered wheter now you were able to give a better estimation of where it 
> stands in comparison with other DL offerings, like what deeplearning4j guys 
> are doing, or even with the established non-Java libraries such as Theano, 
> Torch, Caffe, and TensorFlow. What is the chance of you releasing it even 
> if it is not 100% ready? 
>
> I get the reluctance to commit to a certain API, but I don't think 
> everyone will rush to commit their code to the API you release anyway, and 
> the open development will certainly help both the (potential) users and 
> your team (by returning free testing & feedback).
>
>
> On Tuesday, May 31, 2016 at 7:17:35 AM UTC+2, Mikera wrote:
>>
>> I've been working with a number of collaborators on a deep learning 
>> library for Clojure. 
>>
>> Some key features:
>> - An abstract API for key machine learning functionality
>> - Ability to declare graphs / stacks of operations (somewhat analogous to 
>> tensorflow)
>> - Support for multiple underlying implementations (ClojureScript, JVM, 
>> CPU, GPU)
>> - Integration with core.matrix for N-dimensional data processing
>>
>> We intend to release as open source. We haven't released yet because we 
>> want to get the API right first but it is looking very promising.
>>
>> On Tuesday, 31 May 2016 02:34:41 UTC+8, kovasb wrote:
>>>
>>> Anyone seriously working on deep learning with Clojure?
>>>
>>> I'm working with Torch at the day job, and have done work integrating 
>>> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what 
>>> needs to be done. A bit too much to bite off on my own in my spare time. 
>>>
>>> So is anyone out there familiar enough with these tools to have a 
>>> sensible conversation of what could be done in Clojure?
>>>
>>> The main question on my mind is: what level of abstraction would be 
>>> useful?
>>>
>>> All the existing tools have several layers of abstraction. In 
>>> Tensorflow, at the bottom theres the DAG of operations, and above that a 
>>> high-level library of python constructs to build the DAG (and now of course 
>>> libraries going higher still). In Torch, its more complicated: there's the 
>>> excellent tensor library at the bottom; the NN modules that are widely 
>>> used; and various non-orthogonal libraries and modules stack on top of 
>>> those. 
>>>
>>> One could try to integrate at the bottom layer, and then re-invent the 
>>> layers above that in Clojure. Or one could try to integrate at the higher 
>>> layers, which is more complicated, but gives more leverage from the 
>>> existing ecosystem. 
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

-- 
You received this

Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Mikera
On Friday, 7 October 2016 08:25:31 UTC+8, kovasb wrote:
>
> On Thu, Oct 6, 2016 at 4:46 PM, Dragan Djuric  > wrote:
>  
>
>> s more harm than good. I prefer to give users one Ford model T, than let 
>> them choose between 20 different horse carriages. And, if they can even 
>> choose the color, provided that their choice is black :)
>>
>
> Thanks the for the comments, which I largely agree with. 
>
> I understand your design philosophy and agree its a useful point in the 
> space to have. 
>
> One question:
>
> Is it possible to feed Neanderthal's matrix representation (the underlying 
> bytes) into one of these other libraries, to obtain 
> computations Neanderthal doesn't support? 
>
> My situation: Neanderthal covers some of the algorithms I'd like to 
> implement. It looks easier to get started with and understand than the 
> alternatives. But down the line I'll likely want to do convolution, 
> sigmoid, the typical Neural Network layers. Note, I don't care about 
> 'tensors' exactly; the bookkeeping to simulate a tensor can be automated, 
> but the fundamental operations cannot. So there is a question of whether to 
> just absorb the learning curve and shortcomings of these more general 
> libraries rather than to risk switching horses midstream. 
>
> I imagine I'm not alone in this.. if there was a straightforward story for 
> how to interop Neanderthal when necessary with some more general library 
> that would be powerful. Unfortunately I'm not sufficiently expert to 
> evaluate which of the choices would be most pragmatic and how to pull it 
> off. 
>

I'm hoping to work with Dragan to get core.matrix integration working with 
Neanderthal, now that Windows support is finally arriving. This would get 
you a few big advantages:
1. Neanderthal could be used as a drop-in replacement for other core.matrix 
implementations if it fits your use case
2. You would get extra core.matrix features (additional operations, higher 
dimensional array operations, type conversion, broadcasting etc. 
essentially for free)
3. We minimise the risk of fragmentation in the Clojure numerical ecosystem 
:-)
4. We could use Neanderthal as a optional backend for libraries like 
Incanter or our new NN libraries without any major re-engineering

I'm certainly willing to contribute a fully compliant core.matrix 
implementation for Neanderthal (will take me a couple of days as long as 
the Windows build works smoothly). This might not optimise all of the 
possible operations, but should get high performance in most of the common 
use cases.

Hope you will all support this effort!
 

>  

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread kovas boguta
On Thu, Oct 6, 2016 at 9:20 PM, Mikera  wrote:

> Hi Dragan,
>
> We have things working quite well (including stuff like cuDNN integration
> for convolution networks on the GPU). We also have all of the standard
> stuff (many different layer types, dropout, noise function, regularisation
> etc.). However I think it still needs a bunch of work before we stabilise
> on the core API.
>


> Things I'm paricularly keen to have nailed down in particular before we go
> public:
>

FWIW it sounds like you've achieved a huge amount already.

There are many people in the Clojure community who can come up with a DAG
abstraction. There are very, very few who have the skill and time to assess
and integrate the various native libs necessary to achieve the fundamental
operations in a clojure-friendly way.

If people build on the 'wrong' api, thats a good problem to have. The field
is so in flux anyway. The problem can also be mitigated through minimalism
in what is released in the beginning.

In any case, looking forward to hopefully seeing this stuff one day.

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread kovas boguta
On Thu, Oct 6, 2016 at 9:26 PM, Mikera  wrote:

>
> I'm hoping to work with Dragan to get core.matrix integration working with
> Neanderthal, now that Windows support is finally arriving. This would get
> you a few big advantages:
>

Yes, I can see how my problem relates to the core.matrix vision. The only
missing piece is the actual operations I want (nn layers) :)

-- 
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] zprint, lein-zprint Pretty print your code and data [ALPHA]

2016-10-06 Thread Kim Kinnear
 


I'm pleased to announce the ALPHA release of a new Clojure pretty print 
library and associated leiningen plugin to apply it to your source files.  
The zprint library will pretty print your structures (and code, actually) 
at the repl, as well as reformat your source files when driven by 
lein-zprint.


https://github.com/kkinnear/zprint

https://github.com/kkinnear/lein-zprint

 

What, really?  Another pretty printer?

 

Yes, I know.  We've already got clojure.pprint, fipp, puget, cljfmt.

These are all great libraries! There is a full discussion of why zprint 
exists in the readme.  


The short story is that zprint completely reformats Clojure source, totally 
ignoring all of the line breaks and whitespace in your files.  It also runs 
as a library at the repl (and in your code) to print structures very nicely 
out of the box, and is totally configurable.


In short, zprint and lein-zprint try to do it all, beautifully, out of the 
box.

 

At present, this is an alpha release because only one other person has ever 
used zprint, and so it needs some additional people to try it out. I expect 
the configuration parameters to remain largely stable, as they have been 
evolving over the past year or so.  New ones will be added, as zprint is 
still under active development.


When I announce it for real, I'll add some more words to try to convince people 
to try it, but for now I need some people who care a lot about how their 
code and s-expressions look to give take it out for a spin.  I'm very 
interested in your feedback!  You can create an issue on github, or contact 
me by email (see my overview at github).


Thanks -- Kim

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

2016-10-06 Thread Sunil S Nandihalli
I think deeplearning4J is a contender for deeplearning in clojure. I have
not used it .. but I repeatedly see the sponsored link on clojure-reddit.
Since nobody mentioned it .. I thought of mentioning it

On Fri, Oct 7, 2016 at 7:40 AM, kovas boguta  wrote:

> On Thu, Oct 6, 2016 at 9:26 PM, Mikera 
> wrote:
>
>>
>> I'm hoping to work with Dragan to get core.matrix integration working
>> with Neanderthal, now that Windows support is finally arriving. This would
>> get you a few big advantages:
>>
>
> Yes, I can see how my problem relates to the core.matrix vision. The only
> missing piece is the actual operations I want (nn layers) :)
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: Recursive clojure.spec doesn't work

2016-10-06 Thread Yehonathan Sharvit
This recursive definition also works - the difference is that the inner 
:html/element is not wrapped in s/spec:

(s/def :html/element
  (s/cat
:tag keyword?
:attrs map?
:children (s/* (s/alt :element :html/element
  :string  string?

I'm a bit confused about when recursion works and when it doesn't

On Thursday, 6 October 2016 21:52:07 UTC+3, Aaron wrote:
>
> Well I'm referring to the OP's original example:
>
> (s/def :html/element
>>   (s/cat
>>:tag keyword?
>>:attrs map?
>>:children (s/* (s/alt :element (s/spec :html/element)
>>  :string  string?
>>
>> The exception says: "Unable to resolve spec: :html/element".
>>
>
> On Thursday, October 6, 2016 at 7:43:14 AM UTC-4, Alex Miller wrote:
>>
>> Can you share a specific case? 
>
>

-- 
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] zprint, lein-zprint Pretty print your code and data [ALPHA]

2016-10-06 Thread Yehonathan Sharvit
Looks very nice!
I'd like to integrate zprint into KLIPSE .
But for that I need zprint to be ported to clojurescript.

Could you do it?

On Friday, 7 October 2016 05:39:39 UTC+3, Kim Kinnear wrote:
>
>
> I'm pleased to announce the ALPHA release of a new Clojure pretty print 
> library and associated leiningen plugin to apply it to your source files.  
> The zprint library will pretty print your structures (and code, actually) 
> at the repl, as well as reformat your source files when driven by 
> lein-zprint.
>
>
> https://github.com/kkinnear/zprint
>
> https://github.com/kkinnear/lein-zprint
>
>  
>
> What, really?  Another pretty printer?
>
>  
>
> Yes, I know.  We've already got clojure.pprint, fipp, puget, cljfmt.
>
> These are all great libraries! There is a full discussion of why zprint 
> exists in the readme.  
>
>
> The short story is that zprint completely reformats Clojure source, 
> totally ignoring all of the line breaks and whitespace in your files.  It 
> also runs as a library at the repl (and in your code) to print structures 
> very nicely out of the box, and is totally configurable.
>
>
> In short, zprint and lein-zprint try to do it all, beautifully, out of 
> the box.
>
>  
>
> At present, this is an alpha release because only one other person has ever 
> used zprint, and so it needs some additional people to try it out. I expect 
> the configuration parameters to remain largely stable, as they have been 
> evolving over the past year or so.  New ones will be added, as zprint is 
> still under active development.
>
>
> When I announce it for real, I'll add some more words to try to convince 
> people 
> to try it, but for now I need some people who care a lot about how their 
> code and s-expressions look to give take it out for a spin.  I'm very 
> interested in your feedback!  You can create an issue on github, or contact 
> me by email (see my overview at github).
>
>
> Thanks -- Kim
>

-- 
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] defn podcast episode #11 with Alex Miller

2016-10-06 Thread Vijay Kiran
Hello everyone,

Episode 11 of defn is now available on the Interwebs. 

You can listen to it on SoundCloud: 
https://soundcloud.com/defn-771544745/episode-11-alex-miller or subscribe 
via iTunes https://itunes.apple.com/us/podcast/defn/id1114899563

The show notes are available on https://defn.audio


Enjoy!
Ray & Vijay
defn Podcast
PS: We have a brand new Logo! :)

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