DSL in RTL (Right to Left) languages.

[clojure . user]

Hi

I need to write a dsl in Arabic which is a RTL. I am not sure how to get 
started with such a dsl in clojure. Any pointers with be really appreciated.

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: Clojure for Desktop UI Design Application

[Colin Yates]

IntelliJ is swing! Well, knock me other with a feather :). Still wouldn't
want to go anywhere near building a Swing app though :).
On 14 Jan 2015 01:36, Colin Fleming colin.mailingl...@gmail.com wrote:

 On 14 January 2015 at 05:50, Colin Yates colin.ya...@gmail.com wrote:

 My evolution of Java UI was swingJSPstrutsJSFvelocity then onto
 JavaScript/ExtJS. My instinct now when I hear the words Java and
 UI is to run a mile :).


 This is where I point out that you're currently using a Swing app every
 day :-)



 I haven't looked at JavaFX (I think I had bailed before that appeared).


 On 13 January 2015 at 16:05, Timothy Baldridge tbaldri...@gmail.com
 wrote:
  I've long thought that the Clojure world needs a JavaFX/React hybrid.
  JavaFX2's API is extremely consistent, making it quite easy to program
  against, but yes it still requires bindings and in-place mutation.
 
  However a React-like diff-ing engine on it would be quite impressive.
 But
  now you're into the fun land of writing a library in order to write your
  app.
 
  On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin.ya...@gmail.com
 wrote:
 
  Wow, there is a lot to deal with :), so let me throw out some ideas:
   - have you considered building a web-app instead of a desktop app? If
 so,
  have a look at one of the react based languages (om or reagent would
 be my
  choice). Alternatively take a look at other
  http://en.wikipedia.org/wiki/Functional_reactive_programming
 libraries.
 
  It is a different way of working, but its programming model restricts
 you
  in a way that removes many problems (if you see what I mean).
 
  Also, I would be reaching for an in-memory database (assuming a server
  isn't involved) about now, datatomic would be the obvious choice.
 
  I don't think what you are trying to do is stupid, I do think you might
  want to do some thought experiments about different architectures and
  paradigms (specifically FRP related paradigms).
 
  Oh, and have a quick scan through http://swannodette.github.io/,
 there are
  a few mind-changing posts.
 
  On Monday, 12 January 2015 18:53:07 UTC, MS wrote:
 
  (Cross-posted on StackOverflow)
 
  I'm trying to design a desktop UI for schematics, layout, drawing
 stuff.
  Just looking for high level advice from actual software designers.
 
  Assuming an in-memory database, (clojure map of arbitrary depth for
 all
  user data, and possibly another one for application preferences,
 etc.), I'm
  examining how to do the model-view-controller thing on these, where
 the data
  may be rendered *and modified by* any one or more of:
 
   1. A standalone text field that shows a single parameter, such as box
  width.
   2. An inspector type of view that shows multiple parameters of a
  selected object, such as box width, height, color, checkboxes, etc.
   3. A table/spreadsheet type of view that shows multiple parameters of
  multiple objects, potentially the whole database
   4. A graphical rendering of the whole thing, such as both schematic
 and
  layout view.
 
  Modifying any one of these should show up immediately in every other
  active view, both text and graphical, not after clicking ok... so
 no modal
  boxes allowed.  If for some reason the table view, an inspector view,
 and a
  graphical rendering are all in view, dragging the corner of the box
  graphically should immediately show up in the text, etc.
 
  The platform in question is JavaFX, but I'd like a clean separation
  between UI and everything else, so I want to avoid `bind`ing in the
 JFX
  sense, as that ties my design data very tightly to JFX Properties,
 increases
  the graininess of the model, and forces me to work outside the
 standard
  clojure functions for dealing with data, and/or deal heavily with the
 whole
  `getValue`/`setValue` world.
 
  I'm still assuming at least *some* statefulness/mutability, and the
 use
  of built-in Clojure functionality such as the ability to `add-watch`
 on an
  atom/var/ref and let the runtime signal dependent functions.
 
  Platform-specific interaction will rest tightly with the actual UI,
 such
  as reifying `ActionListener`s, and dealing with `ObservableValue`s
 etc., and
  will attempt to minimize the reliance on things like JavaFX
 `Property` for
  actual application data.  I'm not entertaining FRP for this.
 
  I don't mind too much extending JFX interfaces or making up my own
  protocols to use application-specific `defrecord`s, but I'd prefer
 for the
  application data to remain as straight Clojure data, unsullied by the
  platform.
 
  The question is how to set this all up, with closest adherence to the
  immutable model and minimal (or well-bounded) dependence on JFX.  I
 see a
  few options:
 
   1. Fine-grain: Each parameter value/primitive (ie Long, Double,
 Boolean,
  or String) is an atom, and each view which can modify the value
 reaches in
  as far as it needs to in the database to change the value.  This
 could suck
  as there could potentially be thousands 

Re: Clojure for Desktop UI Design Application

[Fluid Dynamics]

On Tuesday, January 13, 2015 at 10:15:26 AM UTC-5, Colin Yates wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If so, 
 have a look at one of the react based languages (om or reagent would be my 
 choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.


Unless you want to go open source... 

-- 
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 Desktop UI Design Application

[Mike Haney]

My evolution is similar to Colin's, with more SWT than Swing.  And I 
understand where you're coming from - did Java for 15 years and C++ before 
that.  I didn't even really learn about functional programming until about 
3 years ago, and after an aborted dive into learning Scala I switched to 
Clojure 18 months ago and haven't looked back.

Anyway, given what I know today If I had to write a desktop GUI, my first 
instinct would be Clojurescript+node-webkit.

There's not as much to learn as you might think.  It sounds like you 
already know Clojure, so Clojurescript isn't a big leap.  Core.async is 
not, but by no means a requirement - you can safely ignore it for now and 
only reach for it if it solves a particular problem you are having.  For 
the database, there is Datascript which is basically Datomic in the 
browser.  This would give you a very capable embedded database that you can 
simply serialize to a file to store your document in a desktop app.  

Coming from a mostly server background, I found the React model very 
familiar and easy to pick up.  You get a request, query the database, and 
render a template.  It looks very different in React, but conceptually it's 
the same thing as PHP or Spring MVC or whatever.  You also gain access to a 
huge number of JS widgets for just about anything you can imagine, from 
fancy input controls to graphs and charts and even 3d rendering.  

Here's a simple model you can start with and build on as-needed - use 
Datascript as your source of truth for your data, and all your event 
handlers and other application logic simply transacts against this DB. 
 Your views simply query the DB to construct their data.  All that's left 
is triggering when the view refreshes to reflect changes in the DB, and 
that will depend on which React wrapper library you are using.  

In my experience, to integrate with Datascript the easiest to hardest 
choices are: Rum, Quiescent, Reagent, Om.  I've recently switched to Rum 
(by the same guy who wrote Datascript) and it's dead simple - like 3 lines 
of code, done!  But Rum is very new and fairly low level, so it might not 
be the easiest to start with.  For overall ease of use, Reagent is a great 
choice although the integration with Datascript is a bit more work.  If 
you're interested, I can go into more detail on how you might integrate 
Datascript with a given library.



On Tuesday, January 13, 2015 at 10:21:24 AM UTC-6, MS wrote:

 Hi, thanks for the response.  Yes I've thought about a web-based platform. 
  There are tools like LightTable and UpVerter which are inspiring, and I 
 understand the V8 javascript engine renders stuff pretty quickly. 
  Unfortunately that would require getting up to speed on yet another way of 
 thinking about things, clojurescript, etc.  I'm kind of still stuck in the 
 90's and I have only so much brain power/attention/time available. :)  I'll 
 take a look at datomic.  There are so many libraries and various tools for 
 asynchronous frp javascript web based back-end server json immutable 
 reactive things I really can't keep up with all the cool kids.  

 On Tuesday, January 13, 2015 at 7:15:26 AM UTC-8, Colin Yates wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If 
 so, have a look at one of the react based languages (om or reagent would be 
 my choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff. 
  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for 
 all user data, and possibly another one for application preferences, etc.), 
 I'm examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A 

Clojure and JVM Performance talk 3 Feb at Skills Matter London

[Bruce Durling]

Roll up! Roll up!

The first talk at Skills Matter for the London Clojurians will be on 3 Feb.

Tom Crayford will be talking JVM performance tuning and clojure for
your edification, entertainment and enjoyment!

More details and registration here:

https://skillsmatter.com/meetups/6953-opening-the-grimoire-some-things-about-clojure-performance

I'm sure Skills Matter will be as speedy as always with a video of the
talk which will also be at the above URL.

cheers,
Bruce

-- 
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 Desktop UI Design Application

[Mike Haney]

I know it seems overwhelming, and if you try to keep up with all the latest 
cool libraries, 

-- 
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: DSL in RTL (Right to Left) languages.

[Jan-Paul Bultmann]

I would wrap everything in a tree walking macro that first reverses all lists 
and then starts evaluating other macros.

I'd love to see an Arabic clojure file btw :D
But non English source always makes me shudder a bit, one of the great things 
about programming is that everybody speaks English ;)

cheers Jan

 On 14 Jan 2015, at 05:52, clojure.u...@gmail.com wrote:
 
 Hi
 
 I need to write a dsl in Arabic which is a RTL. I am not sure how to get 
 started with such a dsl in clojure. Any pointers with be really appreciated.
 
 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.

-- 
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 Desktop UI Design Application

[Gary Trakhman]

On Tue Jan 13 2015 at 2:05:03 PM Christopher Small metasoar...@gmail.com
wrote:

 On the other hand, while the web app route may feel a bit overwhelming, it
 really is worth learning. Once you program web, you can deliver to any
 platform. It's ubiquitous. And once you get the hang of it, the paradigm
 isn't really all that challenging. But up to you obviously.


This rationale is the basis for my last 1.5 years of extra-work effort.
Good luck :-).

Coming from clojure, React really made investing in the web seem sane and
worthwhile by offering composable abstraction.  I still think it's a good
idea to learn web tech, but it was kind of a frustrating slog.

Another really helpful piece of 'tech' that fits with clojure philosophies
is http://suitcss.github.io/
https://github.com/suitcss/suit/blob/master/doc/design-principles.md

I think that plus React are great starting points.

-- 
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 Desktop UI Design Application

[Jason Lewis]

If you're looking for functional reactive programming in Clojure (rather
than going web-based), there's a great library for Clojure bindings to
RxJava: https://github.com/ReactiveX/RxClojure

Jason Lewis

vox  410.428.0253
twitter  @canweriotnow
blog http://decomplecting.org
else http://about.me/jason.lewis

On Tue, Jan 13, 2015 at 10:15 AM, Colin Yates colin.ya...@gmail.com wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If so,
 have a look at one of the react based languages (om or reagent would be my
 choice). Alternatively take a look at other
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.

 It is a different way of working, but its programming model restricts you
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might
 want to do some thought experiments about different architectures and
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff.
 Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for all
 user data, and possibly another one for application preferences, etc.), I'm
 examining how to do the model-view-controller thing on these, where the
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box
 width.
  2. An inspector type of view that shows multiple parameters of a
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and
 layout view.

 Modifying any one of these should show up immediately in every other
 active view, both text and graphical, not after clicking ok... so no
 modal boxes allowed.  If for some reason the table view, an inspector view,
 and a graphical rendering are all in view, dragging the corner of the box
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation
 between UI and everything else, so I want to avoid `bind`ing in the JFX
 sense, as that ties my design data very tightly to JFX Properties,
 increases the graininess of the model, and forces me to work outside the
 standard clojure functions for dealing with data, and/or deal heavily with
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use
 of built-in Clojure functionality such as the ability to `add-watch` on an
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc.,
 and will attempt to minimize the reliance on things like JavaFX `Property`
 for actual application data.  I'm not entertaining FRP for this.

 I don't mind too much extending JFX interfaces or making up my own
 protocols to use application-specific `defrecord`s, but I'd prefer for the
 application data to remain as straight Clojure data, unsullied by the
 platform.

 The question is how to set this all up, with closest adherence to the
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean,
 or String) is an atom, and each view which can modify the value reaches
 in as far as it needs to in the database to change the value.  This could
 suck as there could potentially be thousands of individual values (for
 example points on a hand-drawn curve), and will require lots of
 `(deref...)` junk.  I believe this is how JFX would want to do this, with
 giant arrays of Properties at the leaf nodes, etc., which feels bloated.
 With this approach it doesn't seem much better than just coding it up in
 Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a
 Clojure map.  The entire map is replaced when any one of its values
 changes.  Fewer total atoms to deal with, and allows for example long
 arrays of straight-up numbers for various things.  But this gets
 complicated when some objects in the database require more nesting than
 others.
  3. Coarse-grain: There is just one atom: the database.  Any time
 anything changes, the entire database is replaced, and every view needs to
 

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

[Christopher Small]

Awesome project!

I'll echo the encouragement towards having Neanderthal implement the 
core.matrix protocols. You'll have much higher adoption if folks know they 
can just plug your tool in by changing a single line setting the underlying 
implementation to Neanderthal. And as Mikera points out, it would be nice 
if we kept the Clojure matrix API space cohesive.

-- 
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 Desktop UI Design Application

[Timothy Baldridge]

Before coming to Clojure I did 2 years of work on WPF/Silverlight apps, and
let me say what those platforms offer blows the web stuff out of the water.
Yes it's not cross-platform, but the ability to describe a layout with data
is unparalleled in the web world. I could sit down, and have a UI to a CRUD
app in half a day. No CSS, no DOM elements to force into a layout I wanted,
etc. Ask anyone who's worked with WPF and they'll tell you yep it's based
on mutability, but writing a UI is really easy.

JavaFX comes close to this, but I'd like to use pure data to interact with
it. I did some work on that in the past, and came up with something that
was pretty usable, but I think a React approach could take it even further.
Anyways, the results of my work allowed you to create JavaFX interfaces
like this:


{:type   :border-pane :center {:type :group
  :children [{:type:circle
 :radius  (planet-sizes size)
:centerY (/ (planet-sizes size) 2)
 :centerX 0}]} :bottom
{:type   :stack-pane  :maxHeight  110
:prefHeight 110
  :children   [{:type :pie-chart
 :data (map(fn
[{percent :planet.biome/percentage
 type:planet.biome/type}]
(slide/build-item {:type
:pie-chart-data
 :name  (str type)
:value percent}))
  (:planet/biomes planet))}]}}

Notice how you don't have to muck with all the junk found in the
browser, you just describe an panel, say what you want to put where
(center, bottom, etc). and the layout engine takes care of the rest.
And this entire thing is GPU accelerated so drawing of the GUI is
pretty fast. The web side of things has a place, but it's also mired
in decades of legacy, that's stuff you don't find in modern UI
toolkits like JavaFX, QT and WPF.


Timothy


On Tue, Jan 13, 2015 at 12:46 PM, Gary Trakhman gary.trakh...@gmail.com
wrote:

 On Tue Jan 13 2015 at 2:05:03 PM Christopher Small metasoar...@gmail.com
 wrote:

 On the other hand, while the web app route may feel a bit overwhelming,
 it really is worth learning. Once you program web, you can deliver to any
 platform. It's ubiquitous. And once you get the hang of it, the paradigm
 isn't really all that challenging. But up to you obviously.


 This rationale is the basis for my last 1.5 years of extra-work effort.
 Good luck :-).

 Coming from clojure, React really made investing in the web seem sane and
 worthwhile by offering composable abstraction.  I still think it's a good
 idea to learn web tech, but it was kind of a frustrating slog.

 Another really helpful piece of 'tech' that fits with clojure philosophies
 is http://suitcss.github.io/
 https://github.com/suitcss/suit/blob/master/doc/design-principles.md

 I think that plus React are great starting points.

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




-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: Clojure for Desktop UI Design Application

[Christopher Small]

Something else to consider...

If you really want to avoid doing a web app with all the complexity of 
server code, client code, html, css, database, etc, then you might want to 
look into [quil](https://github.com/quil/quil). It's a clojure wrapper of 
the processing library for doing data visualizations, code art, and even 
small GUI applications. It's not something you typically see used for 
large-scale applications, but it's quite fun and is actually fairly 
impressive considering it's scope.

On the other hand, while the web app route may feel a bit overwhelming, it 
really is worth learning. Once you program web, you can deliver to any 
platform. It's ubiquitous. And once you get the hang of it, the paradigm 
isn't really all that challenging. But up to you obviously.

Good luck

-- 
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 Desktop UI Design Application

[Colin Fleming]

On 14 January 2015 at 05:50, Colin Yates colin.ya...@gmail.com wrote:

 My evolution of Java UI was swingJSPstrutsJSFvelocity then onto
 JavaScript/ExtJS. My instinct now when I hear the words Java and
 UI is to run a mile :).


This is where I point out that you're currently using a Swing app every day
:-)



 I haven't looked at JavaFX (I think I had bailed before that appeared).


 On 13 January 2015 at 16:05, Timothy Baldridge tbaldri...@gmail.com
 wrote:
  I've long thought that the Clojure world needs a JavaFX/React hybrid.
  JavaFX2's API is extremely consistent, making it quite easy to program
  against, but yes it still requires bindings and in-place mutation.
 
  However a React-like diff-ing engine on it would be quite impressive. But
  now you're into the fun land of writing a library in order to write your
  app.
 
  On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin.ya...@gmail.com
 wrote:
 
  Wow, there is a lot to deal with :), so let me throw out some ideas:
   - have you considered building a web-app instead of a desktop app? If
 so,
  have a look at one of the react based languages (om or reagent would be
 my
  choice). Alternatively take a look at other
  http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.
 
  It is a different way of working, but its programming model restricts
 you
  in a way that removes many problems (if you see what I mean).
 
  Also, I would be reaching for an in-memory database (assuming a server
  isn't involved) about now, datatomic would be the obvious choice.
 
  I don't think what you are trying to do is stupid, I do think you might
  want to do some thought experiments about different architectures and
  paradigms (specifically FRP related paradigms).
 
  Oh, and have a quick scan through http://swannodette.github.io/, there
 are
  a few mind-changing posts.
 
  On Monday, 12 January 2015 18:53:07 UTC, MS wrote:
 
  (Cross-posted on StackOverflow)
 
  I'm trying to design a desktop UI for schematics, layout, drawing
 stuff.
  Just looking for high level advice from actual software designers.
 
  Assuming an in-memory database, (clojure map of arbitrary depth for
 all
  user data, and possibly another one for application preferences,
 etc.), I'm
  examining how to do the model-view-controller thing on these, where
 the data
  may be rendered *and modified by* any one or more of:
 
   1. A standalone text field that shows a single parameter, such as box
  width.
   2. An inspector type of view that shows multiple parameters of a
  selected object, such as box width, height, color, checkboxes, etc.
   3. A table/spreadsheet type of view that shows multiple parameters of
  multiple objects, potentially the whole database
   4. A graphical rendering of the whole thing, such as both schematic
 and
  layout view.
 
  Modifying any one of these should show up immediately in every other
  active view, both text and graphical, not after clicking ok... so no
 modal
  boxes allowed.  If for some reason the table view, an inspector view,
 and a
  graphical rendering are all in view, dragging the corner of the box
  graphically should immediately show up in the text, etc.
 
  The platform in question is JavaFX, but I'd like a clean separation
  between UI and everything else, so I want to avoid `bind`ing in the JFX
  sense, as that ties my design data very tightly to JFX Properties,
 increases
  the graininess of the model, and forces me to work outside the standard
  clojure functions for dealing with data, and/or deal heavily with the
 whole
  `getValue`/`setValue` world.
 
  I'm still assuming at least *some* statefulness/mutability, and the use
  of built-in Clojure functionality such as the ability to `add-watch`
 on an
  atom/var/ref and let the runtime signal dependent functions.
 
  Platform-specific interaction will rest tightly with the actual UI,
 such
  as reifying `ActionListener`s, and dealing with `ObservableValue`s
 etc., and
  will attempt to minimize the reliance on things like JavaFX `Property`
 for
  actual application data.  I'm not entertaining FRP for this.
 
  I don't mind too much extending JFX interfaces or making up my own
  protocols to use application-specific `defrecord`s, but I'd prefer for
 the
  application data to remain as straight Clojure data, unsullied by the
  platform.
 
  The question is how to set this all up, with closest adherence to the
  immutable model and minimal (or well-bounded) dependence on JFX.  I
 see a
  few options:
 
   1. Fine-grain: Each parameter value/primitive (ie Long, Double,
 Boolean,
  or String) is an atom, and each view which can modify the value
 reaches in
  as far as it needs to in the database to change the value.  This could
 suck
  as there could potentially be thousands of individual values (for
 example
  points on a hand-drawn curve), and will require lots of `(deref...)`
 junk.
  I believe this is how JFX would want to do this, with giant arrays of
  Properties at the leaf 

Re: Clojure for Desktop UI Design Application

[TP]

On Tue, Jan 13, 2015 at 10:16 AM, Mike Haney txmikes...@gmail.com wrote:

 Anyway, given what I know today If I had to write a desktop GUI, my first
 instinct would be Clojurescript+node-webkit


Since I'm still investigating Clojure, my first instinct when writing a
desktop GUI --- similar to what Timothy Baldridge mentions --- is to use C#
+ WPF. In particular I really like the Model-View-ViewModel architecture
enabled by the fancy data binding that XAML/WPF can do. And the relatively
new Assisticant [1] [2] seems to make that even easier (though I've haven't
actually used it yet).

Given that I'm more comfortable with .NET... for functional programming
I've started to use F# for real work (as opposed to toy apps/solving
koans while learning Clojure). While you can write WPF apps with F# there
is still some work to do. FsXaml [3] [4] is trying to address this need.
And while I'm still learning, it seems like F# can do React-like
Functional Reactive Programming [5]. Of course ClojureCLR [6] is also an
alternative for .NET-centric types but I only looked at it briefly.

I spent some time trying to grok LightTable, but the
Clojure/ClojureScript/Javascript/leiningen/Google Closure
compiler/JVM/node-webkit combo caused me to give up for now. It didn't help
that Windows support tends to be an afterthought. BTW LightTable is
seriously considering jettisoning node-webkit and switching to the github
Atom shell instead [7].

[1] http://assisticant.net/

[2] http://www.pluralsight.com/courses/clean-view-models-assisticant

[3] https://github.com/fsprojects/FsXaml

[4] Reed Copsey: New libraries for Client Side development in F#
https://www.youtube.com/watch?v=z6R85_X2ivE

[5] http://fsharpforfunandprofit.com/posts/concurrency-reactive/

[6] https://github.com/clojure/clojure-clr

[7]
https://groups.google.com/forum/#!searchin/light-table-discussion/atom$20shell$20chris$20granger

-- 
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 Desktop UI Design Application

[Mikera]

I'd be pretty interested in this too. Though not quite enough to write it 
myself (I've made good enough interfaces with Swing interop).

The thought occurs that there may be quite a bit of common code that could 
be shared with respect to diffing / cursors etc. that would work equally 
well for Om, JavaFX2, maybe also some OpenGL rendering. This similarity 
might even be exploited to build re-targetable GUI code. OK I'll stop 
speculating now

On Wednesday, 14 January 2015 00:05:40 UTC+8, tbc++ wrote:

 I've long thought that the Clojure world needs a JavaFX/React hybrid. 
 JavaFX2's API is extremely consistent, making it quite easy to program 
 against, but yes it still requires bindings and in-place mutation. 

 However a React-like diff-ing engine on it would be quite impressive. But 
 now you're into the fun land of writing a library in order to write your 
 app. 

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com 
 javascript: wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If 
 so, have a look at one of the react based languages (om or reagent would be 
 my choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing 
 stuff.  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for 
 all user data, and possibly another one for application preferences, etc.), 
 I'm examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use 
 of built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use application-specific `defrecord`s, but I'd prefer for the 
 application data to remain as straight Clojure data, unsullied by the 
 platform.

 The question is how to set this all up, with closest adherence to the 
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a 
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, 
 Boolean, or String) is an atom, and each view which can modify the value 
 reaches in as far as it needs to in the database to change the value.  
 This could suck as there could potentially be thousands of individual 
 values (for example points on a hand-drawn curve), and will require lots of 
 `(deref...)` junk.  I believe this is how JFX would want to do this, with 
 giant arrays of Properties at the leaf 

Re: Clojure for Desktop UI Design Application

[Colin Yates]

Wow, there is a lot to deal with :), so let me throw out some ideas:
 - have you considered building a web-app instead of a desktop app? If so, 
have a look at one of the react based languages (om or reagent would be my 
choice). Alternatively take a look at 
other http://en.wikipedia.org/wiki/Functional_reactive_programming 
libraries. 

It is a different way of working, but its programming model restricts you 
in a way that removes many problems (if you see what I mean).

Also, I would be reaching for an in-memory database (assuming a server 
isn't involved) about now, datatomic would be the obvious choice.

I don't think what you are trying to do is stupid, I do think you might 
want to do some thought experiments about different architectures and 
paradigms (specifically FRP related paradigms).

Oh, and have a quick scan through http://swannodette.github.io/, there are 
a few mind-changing posts.

On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff. 
  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for all 
 user data, and possibly another one for application preferences, etc.), I'm 
 examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use of 
 built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use application-specific `defrecord`s, but I'd prefer for the 
 application data to remain as straight Clojure data, unsullied by the 
 platform.

 The question is how to set this all up, with closest adherence to the 
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a 
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, 
 or String) is an atom, and each view which can modify the value reaches 
 in as far as it needs to in the database to change the value.  This could 
 suck as there could potentially be thousands of individual values (for 
 example points on a hand-drawn curve), and will require lots of 
 `(deref...)` junk.  I believe this is how JFX would want to do this, with 
 giant arrays of Properties at the leaf nodes, etc., which feels bloated. 
  With this approach it doesn't seem much better than just coding it up in 
 Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a 
 Clojure map.  The entire map is replaced when any one of its values 
 changes.  Fewer total atoms to deal with, and allows for example long 
 arrays of straight-up numbers for various things.  But this gets 
 complicated when some objects in the database require more nesting than 
 others.
  3. Coarse-grain: There is just one atom: the database.  Any time anything 
 changes, the entire database is replaced, and every view needs to re-render 
 its particular portion.  This feels a bit like using a hammer to swat a 
 fly, and a naive implementation would require everything to re-render all 
 the time.  But I still think this is the best trade off, as any primitive 
 has a clear access path from the root node, whether it is accessed on a 
 per-primitive level or per-record level.

 I 

Re: Clojure for Desktop UI Design Application

[Timothy Baldridge]

I've long thought that the Clojure world needs a JavaFX/React hybrid.
JavaFX2's API is extremely consistent, making it quite easy to program
against, but yes it still requires bindings and in-place mutation.

However a React-like diff-ing engine on it would be quite impressive. But
now you're into the fun land of writing a library in order to write your
app.

On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin.ya...@gmail.com wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If so,
 have a look at one of the react based languages (om or reagent would be my
 choice). Alternatively take a look at other
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.

 It is a different way of working, but its programming model restricts you
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might
 want to do some thought experiments about different architectures and
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff.
 Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for all
 user data, and possibly another one for application preferences, etc.), I'm
 examining how to do the model-view-controller thing on these, where the
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box
 width.
  2. An inspector type of view that shows multiple parameters of a
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and
 layout view.

 Modifying any one of these should show up immediately in every other
 active view, both text and graphical, not after clicking ok... so no
 modal boxes allowed.  If for some reason the table view, an inspector view,
 and a graphical rendering are all in view, dragging the corner of the box
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation
 between UI and everything else, so I want to avoid `bind`ing in the JFX
 sense, as that ties my design data very tightly to JFX Properties,
 increases the graininess of the model, and forces me to work outside the
 standard clojure functions for dealing with data, and/or deal heavily with
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use
 of built-in Clojure functionality such as the ability to `add-watch` on an
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc.,
 and will attempt to minimize the reliance on things like JavaFX `Property`
 for actual application data.  I'm not entertaining FRP for this.

 I don't mind too much extending JFX interfaces or making up my own
 protocols to use application-specific `defrecord`s, but I'd prefer for the
 application data to remain as straight Clojure data, unsullied by the
 platform.

 The question is how to set this all up, with closest adherence to the
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean,
 or String) is an atom, and each view which can modify the value reaches
 in as far as it needs to in the database to change the value.  This could
 suck as there could potentially be thousands of individual values (for
 example points on a hand-drawn curve), and will require lots of
 `(deref...)` junk.  I believe this is how JFX would want to do this, with
 giant arrays of Properties at the leaf nodes, etc., which feels bloated.
 With this approach it doesn't seem much better than just coding it up in
 Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a
 Clojure map.  The entire map is replaced when any one of its values
 changes.  Fewer total atoms to deal with, and allows for example long
 arrays of straight-up numbers for various things.  But this gets
 complicated when some objects in the database require more nesting than
 others.
  3. Coarse-grain: There is just one atom: the database.  Any time
 anything changes, the entire database 

Re: Clojure for Desktop UI Design Application

[MS]

Hi, thanks for the response.  Yes I've thought about a web-based platform. 
 There are tools like LightTable and UpVerter which are inspiring, and I 
understand the V8 javascript engine renders stuff pretty quickly. 
 Unfortunately that would require getting up to speed on yet another way of 
thinking about things, clojurescript, etc.  I'm kind of still stuck in the 
90's and I have only so much brain power/attention/time available. :)  I'll 
take a look at datomic.  There are so many libraries and various tools for 
asynchronous frp javascript web based back-end server json immutable 
reactive things I really can't keep up with all the cool kids.  

On Tuesday, January 13, 2015 at 7:15:26 AM UTC-8, Colin Yates wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If so, 
 have a look at one of the react based languages (om or reagent would be my 
 choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff. 
  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for all 
 user data, and possibly another one for application preferences, etc.), I'm 
 examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use 
 of built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use application-specific `defrecord`s, but I'd prefer for the 
 application data to remain as straight Clojure data, unsullied by the 
 platform.

 The question is how to set this all up, with closest adherence to the 
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a 
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, 
 or String) is an atom, and each view which can modify the value reaches 
 in as far as it needs to in the database to change the value.  This could 
 suck as there could potentially be thousands of individual values (for 
 example points on a hand-drawn curve), and will require lots of 
 `(deref...)` junk.  I believe this is how JFX would want to do this, with 
 giant arrays of Properties at the leaf nodes, etc., which feels bloated. 
  With this approach it doesn't seem much better than just coding it up in 
 Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a 
 Clojure map.  The entire map is replaced when any 

Re: Clojure for Desktop UI Design Application

[zirkonit]

What about node-webkit + Clojurescript? I think it would be ideal 
environment for desktop GUI?

On Tuesday, January 13, 2015 at 7:05:40 PM UTC+3, tbc++ wrote:

 I've long thought that the Clojure world needs a JavaFX/React hybrid. 
 JavaFX2's API is extremely consistent, making it quite easy to program 
 against, but yes it still requires bindings and in-place mutation. 

 However a React-like diff-ing engine on it would be quite impressive. But 
 now you're into the fun land of writing a library in order to write your 
 app. 

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com 
 javascript: wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If 
 so, have a look at one of the react based languages (om or reagent would be 
 my choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing 
 stuff.  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for 
 all user data, and possibly another one for application preferences, etc.), 
 I'm examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use 
 of built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use application-specific `defrecord`s, but I'd prefer for the 
 application data to remain as straight Clojure data, unsullied by the 
 platform.

 The question is how to set this all up, with closest adherence to the 
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a 
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, 
 Boolean, or String) is an atom, and each view which can modify the value 
 reaches in as far as it needs to in the database to change the value.  
 This could suck as there could potentially be thousands of individual 
 values (for example points on a hand-drawn curve), and will require lots of 
 `(deref...)` junk.  I believe this is how JFX would want to do this, with 
 giant arrays of Properties at the leaf nodes, etc., which feels bloated.  
 With this approach it doesn't seem much better than just coding it up in 
 Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a 
 Clojure map.  The entire map is replaced when any one of its values 
 changes.  Fewer total atoms to deal with, and allows for example long 
 arrays of 

Re: Clojure for Desktop UI Design Application

[MS]

If I come up with anything that might usefully tie Clojure data structures 
to JavaFX UI elements in a clean way, I may release it on github.  For now 
it's just one or two .clj files with all my random monkey-coding, using 
lots of half-examples from various sources, which is pretty much how I 
learn.  I played around with Seesaw (Swing-based) for a little bit, but it 
started to get a little too abstract for me, and anyway, as a friend of 
mine recently said, Swing looks like ass, even if you set it to look like 
the native platform, and I need my app to be rich, etc.  There's also a 
certain part of me that feels that all these asynchronous libraries out 
there (react? core.async?  I really don't know what I'm talking about [I'm 
a hardware engineer]), add a lot of overhead with threads, etc., and I may 
be wrong, but it feels like there would need to be fewer layers between 
clicking the mouse and having something show up.  I believe any 
cad/drawing/design tool needs to be as reactive and real-time as any game, 
so max 16ms latency.  I'm not saying I have any evidence these libraries 
are slow... I'm just saying it feels like overkill when I'm not writing a 
big web server or anything.  I'm probably wrong.

On Tuesday, January 13, 2015 at 8:05:40 AM UTC-8, tbc++ wrote:

 I've long thought that the Clojure world needs a JavaFX/React hybrid. 
 JavaFX2's API is extremely consistent, making it quite easy to program 
 against, but yes it still requires bindings and in-place mutation. 

 However a React-like diff-ing engine on it would be quite impressive. But 
 now you're into the fun land of writing a library in order to write your 
 app. 

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com 
 javascript: wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If 
 so, have a look at one of the react based languages (om or reagent would be 
 my choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing 
 stuff.  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for 
 all user data, and possibly another one for application preferences, etc.), 
 I'm examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use 
 of built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use 

Re: Clojure for Desktop UI Design Application

[Colin Yates]

My evolution of Java UI was swingJSPstrutsJSFvelocity then onto
JavaScript/ExtJS. My instinct now when I hear the words Java and
UI is to run a mile :).

I haven't looked at JavaFX (I think I had bailed before that appeared).


On 13 January 2015 at 16:05, Timothy Baldridge tbaldri...@gmail.com wrote:
 I've long thought that the Clojure world needs a JavaFX/React hybrid.
 JavaFX2's API is extremely consistent, making it quite easy to program
 against, but yes it still requires bindings and in-place mutation.

 However a React-like diff-ing engine on it would be quite impressive. But
 now you're into the fun land of writing a library in order to write your
 app.

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin.ya...@gmail.com wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If so,
 have a look at one of the react based languages (om or reagent would be my
 choice). Alternatively take a look at other
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.

 It is a different way of working, but its programming model restricts you
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might
 want to do some thought experiments about different architectures and
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there are
 a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff.
 Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for all
 user data, and possibly another one for application preferences, etc.), I'm
 examining how to do the model-view-controller thing on these, where the data
 may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box
 width.
  2. An inspector type of view that shows multiple parameters of a
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and
 layout view.

 Modifying any one of these should show up immediately in every other
 active view, both text and graphical, not after clicking ok... so no modal
 boxes allowed.  If for some reason the table view, an inspector view, and a
 graphical rendering are all in view, dragging the corner of the box
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation
 between UI and everything else, so I want to avoid `bind`ing in the JFX
 sense, as that ties my design data very tightly to JFX Properties, increases
 the graininess of the model, and forces me to work outside the standard
 clojure functions for dealing with data, and/or deal heavily with the whole
 `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use
 of built-in Clojure functionality such as the ability to `add-watch` on an
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., and
 will attempt to minimize the reliance on things like JavaFX `Property` for
 actual application data.  I'm not entertaining FRP for this.

 I don't mind too much extending JFX interfaces or making up my own
 protocols to use application-specific `defrecord`s, but I'd prefer for the
 application data to remain as straight Clojure data, unsullied by the
 platform.

 The question is how to set this all up, with closest adherence to the
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean,
 or String) is an atom, and each view which can modify the value reaches in
 as far as it needs to in the database to change the value.  This could suck
 as there could potentially be thousands of individual values (for example
 points on a hand-drawn curve), and will require lots of `(deref...)` junk.
 I believe this is how JFX would want to do this, with giant arrays of
 Properties at the leaf nodes, etc., which feels bloated.  With this approach
 it doesn't seem much better than just coding it up in Java/C++.
  2. Medium-grain: Each object/record in the database is an atom of a
 Clojure map.  The entire map is replaced when any one of its values changes.
 Fewer 

Re: Clojure for Desktop UI Design Application

[Colin Yates]

One lesson I would share is that things are usually much quicker than
we expect. Always prove it is too slow before believing your
intuition.

On 13 January 2015 at 16:28, MS 5lvqbw...@sneakemail.com wrote:
 If I come up with anything that might usefully tie Clojure data structures
 to JavaFX UI elements in a clean way, I may release it on github.  For now
 it's just one or two .clj files with all my random monkey-coding, using lots
 of half-examples from various sources, which is pretty much how I learn.  I
 played around with Seesaw (Swing-based) for a little bit, but it started to
 get a little too abstract for me, and anyway, as a friend of mine recently
 said, Swing looks like ass, even if you set it to look like the native
 platform, and I need my app to be rich, etc.  There's also a certain part
 of me that feels that all these asynchronous libraries out there (react?
 core.async?  I really don't know what I'm talking about [I'm a hardware
 engineer]), add a lot of overhead with threads, etc., and I may be wrong,
 but it feels like there would need to be fewer layers between clicking the
 mouse and having something show up.  I believe any cad/drawing/design tool
 needs to be as reactive and real-time as any game, so max 16ms latency.  I'm
 not saying I have any evidence these libraries are slow... I'm just saying
 it feels like overkill when I'm not writing a big web server or anything.
 I'm probably wrong.

 On Tuesday, January 13, 2015 at 8:05:40 AM UTC-8, tbc++ wrote:

 I've long thought that the Clojure world needs a JavaFX/React hybrid.
 JavaFX2's API is extremely consistent, making it quite easy to program
 against, but yes it still requires bindings and in-place mutation.

 However a React-like diff-ing engine on it would be quite impressive. But
 now you're into the fun land of writing a library in order to write your
 app.

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If
 so, have a look at one of the react based languages (om or reagent would be
 my choice). Alternatively take a look at other
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.

 It is a different way of working, but its programming model restricts you
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might
 want to do some thought experiments about different architectures and
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing stuff.
 Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for
 all user data, and possibly another one for application preferences, etc.),
 I'm examining how to do the model-view-controller thing on these, where the
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box
 width.
  2. An inspector type of view that shows multiple parameters of a
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and
 layout view.

 Modifying any one of these should show up immediately in every other
 active view, both text and graphical, not after clicking ok... so no 
 modal
 boxes allowed.  If for some reason the table view, an inspector view, and a
 graphical rendering are all in view, dragging the corner of the box
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation
 between UI and everything else, so I want to avoid `bind`ing in the JFX
 sense, as that ties my design data very tightly to JFX Properties, 
 increases
 the graininess of the model, and forces me to work outside the standard
 clojure functions for dealing with data, and/or deal heavily with the whole
 `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use
 of built-in Clojure functionality such as the ability to `add-watch` on an
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and
 will attempt to minimize the reliance on things like JavaFX `Property` 

Re: Clojure for Desktop UI Design Application

[Gary Trakhman]

You made the analogy to games/graphics, React model treats the DOM akin to
a graphics buffer, and they themselves present it as similar to the doom3
architecture.  In practice, it feels a lot like a scene graph, with the
update/render methods on every component.

I don't know how easy it is to fit javafx into this, but it works out with
the DOM pretty well.  If JavaFX can be described as a renderer of a static
data structure, then you should be able to do the same kind of tree-diffing
optimizations that React does to minimize what needs to be redrawn, and to
present a functional/data interface.

On Tue Jan 13 2015 at 11:52:36 AM Colin Yates colin.ya...@gmail.com wrote:

 One lesson I would share is that things are usually much quicker than
 we expect. Always prove it is too slow before believing your
 intuition.

 On 13 January 2015 at 16:28, MS 5lvqbw...@sneakemail.com wrote:
  If I come up with anything that might usefully tie Clojure data
 structures
  to JavaFX UI elements in a clean way, I may release it on github.  For
 now
  it's just one or two .clj files with all my random monkey-coding, using
 lots
  of half-examples from various sources, which is pretty much how I
 learn.  I
  played around with Seesaw (Swing-based) for a little bit, but it started
 to
  get a little too abstract for me, and anyway, as a friend of mine
 recently
  said, Swing looks like ass, even if you set it to look like the native
  platform, and I need my app to be rich, etc.  There's also a certain
 part
  of me that feels that all these asynchronous libraries out there
 (react?
  core.async?  I really don't know what I'm talking about [I'm a hardware
  engineer]), add a lot of overhead with threads, etc., and I may be wrong,
  but it feels like there would need to be fewer layers between clicking
 the
  mouse and having something show up.  I believe any cad/drawing/design
 tool
  needs to be as reactive and real-time as any game, so max 16ms latency.
 I'm
  not saying I have any evidence these libraries are slow... I'm just
 saying
  it feels like overkill when I'm not writing a big web server or anything.
  I'm probably wrong.
 
  On Tuesday, January 13, 2015 at 8:05:40 AM UTC-8, tbc++ wrote:
 
  I've long thought that the Clojure world needs a JavaFX/React hybrid.
  JavaFX2's API is extremely consistent, making it quite easy to program
  against, but yes it still requires bindings and in-place mutation.
 
  However a React-like diff-ing engine on it would be quite impressive.
 But
  now you're into the fun land of writing a library in order to write your
  app.
 
  On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com
 wrote:
 
  Wow, there is a lot to deal with :), so let me throw out some ideas:
   - have you considered building a web-app instead of a desktop app? If
  so, have a look at one of the react based languages (om or reagent
 would be
  my choice). Alternatively take a look at other
  http://en.wikipedia.org/wiki/Functional_reactive_programming
 libraries.
 
  It is a different way of working, but its programming model restricts
 you
  in a way that removes many problems (if you see what I mean).
 
  Also, I would be reaching for an in-memory database (assuming a server
  isn't involved) about now, datatomic would be the obvious choice.
 
  I don't think what you are trying to do is stupid, I do think you might
  want to do some thought experiments about different architectures and
  paradigms (specifically FRP related paradigms).
 
  Oh, and have a quick scan through http://swannodette.github.io/, there
  are a few mind-changing posts.
 
  On Monday, 12 January 2015 18:53:07 UTC, MS wrote:
 
  (Cross-posted on StackOverflow)
 
  I'm trying to design a desktop UI for schematics, layout, drawing
 stuff.
  Just looking for high level advice from actual software designers.
 
  Assuming an in-memory database, (clojure map of arbitrary depth for
  all user data, and possibly another one for application preferences,
 etc.),
  I'm examining how to do the model-view-controller thing on these,
 where the
  data may be rendered *and modified by* any one or more of:
 
   1. A standalone text field that shows a single parameter, such as box
  width.
   2. An inspector type of view that shows multiple parameters of a
  selected object, such as box width, height, color, checkboxes, etc.
   3. A table/spreadsheet type of view that shows multiple parameters of
  multiple objects, potentially the whole database
   4. A graphical rendering of the whole thing, such as both schematic
 and
  layout view.
 
  Modifying any one of these should show up immediately in every other
  active view, both text and graphical, not after clicking ok... so
 no modal
  boxes allowed.  If for some reason the table view, an inspector view,
 and a
  graphical rendering are all in view, dragging the corner of the box
  graphically should immediately show up in the text, etc.
 
  The platform in question is JavaFX, but I'd like a clean 

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

[adrian . medina]

Ditto to the others. This looks great, and I have a lot of core.matrix 
compatible code I'd love to test it out against! Thanks for releasing this! 

On Tuesday, January 13, 2015 at 5:07:51 PM UTC-5, Sam Raker wrote:

 I'd like to politely add to the calls for this to become a pluggable 
 core.matrix backend.

 On Tuesday, January 13, 2015 at 4:38:22 PM UTC-5, Dragan Djuric wrote:

 It would be nice if that would be that easy. However, I am sceptical...

 On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.



-- 
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 Desktop UI Design Application

[blake]

Yeah, Adobe Flex can do that, too, with all the same caveats.

On Tue, Jan 13, 2015 at 12:09 PM, Timothy Baldridge tbaldri...@gmail.com
wrote:

 Before coming to Clojure I did 2 years of work on WPF/Silverlight apps,
 and let me say what those platforms offer blows the web stuff out of the
 water. Yes it's not cross-platform, but the ability to describe a layout
 with data is unparalleled in the web world. I could sit down, and have a UI
 to a CRUD app in half a day. No CSS, no DOM elements to force into a layout
 I wanted, etc. Ask anyone who's worked with WPF and they'll tell you yep
 it's based on mutability, but writing a UI is really easy.

 JavaFX comes close to this, but I'd like to use pure data to interact with
 it. I did some work on that in the past, and came up with something that
 was pretty usable, but I think a React approach could take it even further.
 Anyways, the results of my work allowed you to create JavaFX interfaces
 like this:


 {:type   :border-pane :center {:type :group   
:children [{:type:circle   
:radius  (planet-sizes size)   
:centerY (/ (planet-sizes size) 2) 
  :centerX 0}]} :bottom {:type   :stack-pane   
:maxHeight  110  :prefHeight 
 110  :children   [{:type :pie-chart   
  :data (map   
  (fn [{percent :planet.biome/percentage   
type:planet.biome/type}]   
(slide/build-item {:type  :pie-chart-data  
:name  
 (str type)
  :value percent}))
 (:planet/biomes planet))}]}}

 Notice how you don't have to muck with all the junk found in the browser, you 
 just describe an panel, say what you want to put where (center, bottom, etc). 
 and the layout engine takes care of the rest. And this entire thing is GPU 
 accelerated so drawing of the GUI is pretty fast. The web side of things has 
 a place, but it's also mired in decades of legacy, that's stuff you don't 
 find in modern UI toolkits like JavaFX, QT and WPF.


 Timothy


 On Tue, Jan 13, 2015 at 12:46 PM, Gary Trakhman gary.trakh...@gmail.com
 wrote:

 On Tue Jan 13 2015 at 2:05:03 PM Christopher Small metasoar...@gmail.com
 wrote:

 On the other hand, while the web app route may feel a bit overwhelming,
 it really is worth learning. Once you program web, you can deliver to any
 platform. It's ubiquitous. And once you get the hang of it, the paradigm
 isn't really all that challenging. But up to you obviously.


 This rationale is the basis for my last 1.5 years of extra-work effort.
 Good luck :-).

 Coming from clojure, React really made investing in the web seem sane and
 worthwhile by offering composable abstraction.  I still think it's a good
 idea to learn web tech, but it was kind of a frustrating slog.

 Another really helpful piece of 'tech' that fits with clojure
 philosophies is http://suitcss.github.io/
 https://github.com/suitcss/suit/blob/master/doc/design-principles.md

 I think that plus React are great starting points.

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




 --
 “One of the main causes of the fall of the Roman Empire was that–lacking
 zero–they had no way to indicate successful termination of their C
 programs.”
 (Robert Firth)

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

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

[Sam Raker]

I'd like to politely add to the calls for this to become a pluggable 
core.matrix backend.

On Tuesday, January 13, 2015 at 4:38:22 PM UTC-5, Dragan Djuric wrote:

 It would be nice if that would be that easy. However, I am sceptical...

 On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.



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

[Dragan Djuric]

It would be nice if that would be that easy. However, I am sceptical...

On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.


-- 
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: Help with Incanter and Emacs

[Sam Raker]

For something that's been deprecated for a while now, `use` sure still 
shows up in A LOT of docs/tutorials/books/etc.

On Monday, January 12, 2015 at 7:48:44 PM UTC-5, Robert Berger wrote:

 Wish this was in the Incanter docs and in the Readme

 On Tuesday, August 13, 2013 at 12:09:20 PM UTC-7, Tim Visher wrote:

 LOL. I just realized I'd been missing that all along. 

 It seems like the community is more and more leaning to something like 
 this, just FYI. 

 (ns default.core 
   (:require (incanter [core  :refer :all] 
 [charts:refer :all] 
 [stats  :refer :all] 
 [datasets :refer :all]))) 

 `:use` has been discussed in the interest of deprecating it many times. 

 I did not test the above declaration. 

 On Tue, Aug 13, 2013 at 2:40 PM, Akhil Wali green.tr...@gmail.com 
 wrote: 
  Well this is embarrassing. 
  
  I was having a wrong use syntax .. 
  Changed the import line to this and it works. 
  
  (ns default.core 
(:use [incanter core charts stats datasets])) 
  
  Thanks for the help though!! 
  
  On Tuesday, August 13, 2013 11:57:46 PM UTC+5:30, Akhil Wali wrote: 
  
  Yes, by nrepl-jack-in. 
  
  On Tuesday, August 13, 2013 11:54:24 PM UTC+5:30, Tim Visher wrote: 
  
  And you're connecting to the project how? 
  
  On Tue, Aug 13, 2013 at 2:11 PM, Akhil Wali green.tr...@gmail.com 
  wrote: 
   Well 
   Here's my project.clj. 
   
   (defproject someproj 0.1.0-SNAPSHOT 
 :dependencies [[org.clojure/clojure 1.5.1] 
[incanter 1.5.2]]) 
   
   Here's my .lein/profiles.clj as well. 
   
   {:user {:plugins [[lein-ritz 0.7.0] 
 [compojure-app/lein-template 0.2.7]] 
   :dependencies [[ritz/ritz-nrepl-middleware 0.7.0]] 
   :repl-options {:nrepl-middleware 
  [ritz.nrepl.middleware.javadoc/wrap-javadoc 
   
   ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}}} 
   
   
   
   On Tuesday, August 13, 2013 11:35:58 PM UTC+5:30, Tim Visher wrote: 
   
   On Tue, Aug 13, 2013 at 1:59 PM, Akhil Wali green.tr...@gmail.com 

   wrote: 
Hi All, 

A really noob question. 

Why do I get FileNotFoundException Could not locate 
incanter__init.class or 
incanter.clj on classpath:   clojure.lang.RT.load (RT.java:443) 
when i 
load 
a file that uses incanter in emacs? 
Here's the file... 

(ns default.core 
  (:require incanter core charts stats datasets)) 

(defn plot [] 
  (view (scatter-plot :Sepal.Length :Sepal.Width 
  :group-by :Species 
  :data (get-dataset :iris 

(plot) 

This works in lein repl just fine. 
I'm using Emacs 24 and nrepl.el 0.1.8. 

This issue was posted on Github way long back. Seems to be 
 solved, 
but 
by 
simply upgrading emacs. Doesn't really work in my case. 
Any advise? 
   
   Couple things. 
   
   1. I'm assuming you've declared the proper dependencies in your 
   `project.clj` file since this works from `lein repl`, however it's 
   worth checking. 
   
   2. How are you connecting to your project? Simply loading the 
   namespace won't work if you haven't properly jack in. There's a 
 number 
   of options here but the simplest is probably to use `M-x 
   nrepl-jack-in` (usually bound to `C-c M-j`) from this file. It 
 should 
   Just Work™. 
   
   If that doesn't work, I'd probably post some more details about 
 the 
   project somewhere. At least the `project.clj` and the whole ns 
 would 
   be helpful in a gist of some sort. 
   
   -- 
   
   In Christ, 
   
   Timmy V. 
   
   http://blog.twonegatives.com/ 
   http://five.sentenc.es/ -- Spend less time on mail 
   
   -- 
   -- 
   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/groups/opt_out. 
  
  -- 
  -- 
  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 
  

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

[Mikera]

It works for the development branch of Incanter 2.0 - which is a pretty 
significant project with a lot of matrix code. You can switch between 
Clatrix (native BLAS via JBlas), persistent vectors (regular Clojure 
vectors) and vectorz-clj (pure JVM code) transparently. 

I think it would be the same for Neanderthal - I don't see anything that 
would be inconsistent with core.matrix from an API perspective.

On Wednesday, 14 January 2015 05:38:22 UTC+8, Dragan Djuric wrote:

 It would be nice if that would be that easy. However, I am sceptical...

 On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.



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