Re: Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[pat . killean]

FWIW I removed the CSP from atom and now have figwheel running inside atom 
and its awesome

On Friday, October 7, 2016 at 8:25:18 PM UTC-4, Ray King wrote:
>
> Thanks for all the direct and public replies so far, we take great 
> reassurance from them.
>
> Recapping the constraints:
>
> We have an existing Java library, which is a collection of algorithms 
> (Statistical inferencing stuff), architecturally they are stateless. Pass 
> in a Map, and it returns a Map.  There is a coordination layer which we 
> have moved to Clojure, this just a Map/Reduce & transform router. For 
> example, we would run a simulation a few alternative models concurrently. 
> The Clojure code distributed work maps to threads and instances in 
> different memory spaces and consolidated all the results as pour back in 
> asynchronously. It handles failures and continuation etc.  This part works 
> fine. The difference of reimplementing this layer in Clojure is night and 
> day, forget Java and Scala for this, the rewrite was painless and scaling 
> options we have given ourselves are fantastic.
>
> We still have Java dependencies, there in is the rub.
>
> We want to move as much as this stuff client side as possible, 
> Clojurescript and only leave the bounds of the customer's machine for 
> certain operations where we need to offload these work maps to cloud bound 
> processors.
>
> In the perfect world, we would have an electron app with render processes 
> handling the GUI elements and the primary process doing some light 
> processing and distribution and coordination of the work maps. In fact, we 
> have prototyped this, and it appears viable.
>
> In the short term, we have running a JVM based server on the client 
> machine as that is what host the algorithm library.
>
> (By the way, this library will eventually be reimplemented in Clojure 
> script, but as there is a need to for precision & correctness we currently 
> have a test suit that 3x larger than the code base and we still trying to 
> get our heads around the float points in JS)
>
> The above is what motivated the question.
>
> 1. Cljs and Electron, Tick no problems.
>
> 2. Packaging up a web socket server in electron for deployment and later 
> version updating? Has it been done, Clues thoughts, etc.?
>
> 3. Developer workflow, (Productivity). 
> 
> a. Currently, we have the library, Java code, and Clojure layer in one 
> code base and repository. Using Lein, and Cursive to hack on it. Which by 
> itself is fine.
>
> b. Bring 'Cljs' & electron into play, using ATOM with 'Dirac' and 
> 'Cljs-oops' with 'Boot' starting becoming a lot more ergonomic and lighter 
> then Intellij, Cursive and Lein.
>
> We would like to unite these two worlds into one repository and one tool 
> chain. From that one environment, we should be able to work on the GUI 
> layer, live reload, inspect and tango on. (ATOM, Dirac and Boot). Then move 
> without friction and context changes to hacking some Clojure, running some 
> unit test and now specs with 1.9.0-alpha. Then back again, to the front.
>
> The fact is all the above (Clj, Cljs, Electron and Java can work together, 
> and deliver good results). But we have yet to find a unified tooling chain. 
> Being an IDE/Editor, 'repl', build and dependency management. That handles 
> the architectural options that 'Clj' and 'Cljs' is enabling.
>
> Yes, 'lein' abstracts us from mistakes of past 'Maven' but it is not the 
> promised landed. I want to write code executable testable code to manage my 
> project, to extract what I need from the code base, compile and package 
> into immutable file sets. 
>
> Darken by two decades of Java, Maven and dependence management yet not 
> brave enough to ride the grunt while gulping down bower packages which are 
> made by copy and paste mystery meats. I am thankful for the Google Closure 
> Complier that tree shakes out some of the JS crap that always seems to find 
> its way into JS apps. I am hoping that 'boot; will become the tool that 
> bridges 'Clj' and 'Cljs'.
>
> Please share your thoughts and wash apart any ignorance I have in this 
> area.  Indeed, if you have a directory structure and tooling around a 
> unifying a 'Clj', 'Java', 'Cljs' and 'JS' project, please share.
>
> Thanks again for the suggestions, I hope this post elaborate more upon 
> what I mean when I say developer workflow, productivity and ergonomics.
>
>
> On Friday, October 7, 2016 at 6:13:30 AM UTC+11, Daniel Compton wrote:
>>
>> Hi Ray
>>
>> We have a ClojureScript + Electron + Re-Frame application that we run. 
>> Those three work together quite nicely. I’m not totally clear what it would 
>> look like for Clojure + Boot + ProtoRepl to co-exist with the first three? 
>> Can you explain what you’re envisioning some more?
>>
>> On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter  
>> wrote:
>>
>>> Hi Ray,
>>>
>>> I'm in a pretty much identical situation, except that I'm using re-frame 
>>> for the 

Re: Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Ray King]

Thanks for all the direct and public replies so far, we take great 
reassurance from them.

Recapping the constraints:

We have an existing Java library, which is a collection of algorithms 
(Statistical inferencing stuff), architecturally they are stateless. Pass 
in a Map, and it returns a Map.  There is a coordination layer which we 
have moved to Clojure, this just a Map/Reduce & transform router. For 
example, we would run a simulation a few alternative models concurrently. 
The Clojure code distributed work maps to threads and instances in 
different memory spaces and consolidated all the results as pour back in 
asynchronously. It handles failures and continuation etc.  This part works 
fine. The difference of reimplementing this layer in Clojure is night and 
day, forget Java and Scala for this, the rewrite was painless and scaling 
options we have given ourselves are fantastic.

We still have Java dependencies, there in is the rub.

We want to move as much as this stuff client side as possible, 
Clojurescript and only leave the bounds of the customer's machine for 
certain operations where we need to offload these work maps to cloud bound 
processors.

In the perfect world, we would have an electron app with render processes 
handling the GUI elements and the primary process doing some light 
processing and distribution and coordination of the work maps. In fact, we 
have prototyped this, and it appears viable.

In the short term, we have running a JVM based server on the client machine 
as that is what host the algorithm library.

(By the way, this library will eventually be reimplemented in Clojure 
script, but as there is a need to for precision & correctness we currently 
have a test suit that 3x larger than the code base and we still trying to 
get our heads around the float points in JS)

The above is what motivated the question.

1. Cljs and Electron, Tick no problems.

2. Packaging up a web socket server in electron for deployment and later 
version updating? Has it been done, Clues thoughts, etc.?

3. Developer workflow, (Productivity). 

a. Currently, we have the library, Java code, and Clojure layer in one code 
base and repository. Using Lein, and Cursive to hack on it. Which by itself 
is fine.

b. Bring 'Cljs' & electron into play, using ATOM with 'Dirac' and 
'Cljs-oops' with 'Boot' starting becoming a lot more ergonomic and lighter 
then Intellij, Cursive and Lein.

We would like to unite these two worlds into one repository and one tool 
chain. From that one environment, we should be able to work on the GUI 
layer, live reload, inspect and tango on. (ATOM, Dirac and Boot). Then move 
without friction and context changes to hacking some Clojure, running some 
unit test and now specs with 1.9.0-alpha. Then back again, to the front.

The fact is all the above (Clj, Cljs, Electron and Java can work together, 
and deliver good results). But we have yet to find a unified tooling chain. 
Being an IDE/Editor, 'repl', build and dependency management. That handles 
the architectural options that 'Clj' and 'Cljs' is enabling.

Yes, 'lein' abstracts us from mistakes of past 'Maven' but it is not the 
promised landed. I want to write code executable testable code to manage my 
project, to extract what I need from the code base, compile and package 
into immutable file sets. 

Darken by two decades of Java, Maven and dependence management yet not 
brave enough to ride the grunt while gulping down bower packages which are 
made by copy and paste mystery meats. I am thankful for the Google Closure 
Complier that tree shakes out some of the JS crap that always seems to find 
its way into JS apps. I am hoping that 'boot; will become the tool that 
bridges 'Clj' and 'Cljs'.

Please share your thoughts and wash apart any ignorance I have in this 
area.  Indeed, if you have a directory structure and tooling around a 
unifying a 'Clj', 'Java', 'Cljs' and 'JS' project, please share.

Thanks again for the suggestions, I hope this post elaborate more upon what 
I mean when I say developer workflow, productivity and ergonomics.


On Friday, October 7, 2016 at 6:13:30 AM UTC+11, Daniel Compton wrote:
>
> Hi Ray
>
> We have a ClojureScript + Electron + Re-Frame application that we run. 
> Those three work together quite nicely. I’m not totally clear what it would 
> look like for Clojure + Boot + ProtoRepl to co-exist with the first three? 
> Can you explain what you’re envisioning some more?
>
> On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter  > wrote:
>
>> Hi Ray,
>>
>> I'm in a pretty much identical situation, except that I'm using re-frame 
>> for the gui that connects to the websocket the local clojure app provides. 
>> I haven't gotten as far as you yet, since I haven't yet started the "port" 
>> of the gui from browser to electron. I also have two code bases, but am 
>> wondering if the merge makes sense. So, I would be very interested to see 
>> read about your 

Re: Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Daniel Compton]

Hi Ray

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

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

> Hi Ray,
>
> I'm in a pretty much identical situation, except that I'm using re-frame
> for the gui that connects to the websocket the local clojure app provides.
> I haven't gotten as far as you yet, since I haven't yet started the "port"
> of the gui from browser to electron. I also have two code bases, but am
> wondering if the merge makes sense. So, I would be very interested to see
> read about your experience!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Daniel

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

Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Mathias De Wachter]

Hi Ray,

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

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

Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Ray King]

Is there a blog post or has anyone tried to get a Clojure + ClojureScript + 
Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

TL;DR
Background - Why?

1. We have a Clojure code base which deploys as a Jar local on a user's PC. 
It is running as a web socket server, serving a local browser application 
which talks to it, using messages and response events. It also as an 
intelligent proxy gateway to remote servers. 

2. We have started to build a new client application and that progressing 
nicely (Om.next). We are going to need to pop it into an Electron Shell 
(Local File Access and Needs to talk to some hardware device). We are 
approaching the client like a server.  The Render threads handling 'defui' 
and process thread handling the state reconciliation and talk to the local 
socket server.

3. Today we have Clojure Server in one code base, and separate Repo, the 
Clojurescript in another, ProtoRepl in Atom for the Clojure stuff and 
'binaryage / Dirac and cljs-devtools'. All very nice and everyone is happy.

4. The objective is to bring both the new client (Om.Next Electron) and the 
socket client-server and into one project. The rationale here is that start 
blurring the line between the main thread in electron and the socket server 
and move code into the client as we deprecate some of the Java 
dependencies. We are going to have to maintain a Clojure code base, as the 
Application is simulation intensive and multi-treaded, in Clojure the 
steady progression towards Java treading insanity is indeed halted. We hope 
to simplify the server side down to an nRepl like architecture where we are 
just sending evals from the client and farm out processing locally or 
remotely.

5. Before attempting to bring all these project elements together, I wanted 
to see if anyone has done the above and published a blog about it? I also 
wanted to get some community feedback. From Googling the pieces are out 
there, just not in a unified fashion.
Should the above be unique and appears to be of interest to others. I will 
ensure that we publish and share anything we come up with in the area.
Then we will feedback our experiences.

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