Re: om next quickstart

2015-11-28 Thread William la Forge 
Switched to java version "1.8.0_31" to no avail.

-- 
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: om next quickstart

2015-11-28 Thread William la Forge 
Perhaps this is the problem? openjdk version "1.8.0_40"

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

om next quickstart

2015-11-28 Thread William la Forge 
Working my way through the quickstart tutorial for om 
next: https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29

Got to the point (not very far) where I enter this command: lein run -m 
clojure.main script/figwheel.clj

clojure.lang.Compiler$CompilerException: java.io.FileNotFoundException: 
Could not locate figwheel_sidecar/repl__init.class or 
figwheel_sidecar/repl.clj on classpath. Please check that namespaces with 
dashes use underscores in the Clojure file name., 
compiling:(C:\Users\Bill\Documents\GitHub\om-tutorial\script\figwheel.clj:1:1)

Any ideas? Here's my figwheel.clj file:

(require '[figwheel-sidecar.repl :as r]
 '[figwheel-sidecar.repl-api :as ra])

(ra/start-figwheel!
  {:figwheel-options {}
   :build-ids ["dev"]
   :all-builds
   [{:id "dev"
 :figwheel true
 :source-paths ["src"]
 :compiler {:main 'om-tutorial.core
:asset-path "js"
:output-to "resources/public/js/main.js"
:output-dir "resources/public/js"
:verbose true}}]})

(ra/cljs-repl)

And my project.clj file:

(defproject om-tutorial "0.1.0-SNAPSHOT"
  :description "My first Om program!"
  :dependencies [[org.clojure/clojure "1.7.0"]
 [org.clojure/clojurescript "1.7.170"]
 [org.omcljs/om "1.0.0-alpha22"]
 [figwheel-sidecar "0.5.0-SNAPSHOT" :scope "test"]])

Also tried figwheel-sidecar 0.5.0 and 0.5.0-2. Same results.

Bill

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

[ANN] com.stuartsierra/component "0.3.1"

2015-11-28 Thread Stuart Sierra 
https://github.com/stuartsierra/component

Bugfix release 0.3.1 contains the following changes:

   - Fix #40 ,
   incorrect values for ex-data keys in missing-dependency error

Leiningen dependency:

[com.stuartsierra/component "0.3.1"]


Full change log


-- 
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: crazy idea...

2015-11-28 Thread Lee Spector 

Jules,

There's work using random variation and selection to do some of the more 
ambitious things you've suggested. 

See, for example, http://geneticimprovement2015.com

It'd be great to see work in this area being done in Clojure, perhaps in 
conjunction with some of the more deterministic methods you've suggested here.

 -Lee



> On Nov 28, 2015, at 1:53 PM, Lucas Bradstreet  
> wrote:
> 
> Kibit (https://github.com/jonase/kibit) does many of the things that
> you describe, though it doesn't go as far you dream. It also uses
> core.logic to suggest equivalent substitutions.
> 
> I'd be happy to see more work in this area.
> 
> Lucas
> 
> On 29 November 2015 at 02:01, Jules  wrote:
>> Guys,
>> 
>> I've had pieces of this idea wandering around my head for years now and have
>> finally decided that the time might be right for putting them together in
>> the context of Clojure. I'm sure that others have had similar ideas before :
>> 
>> Imagine my Clojure program which reads in your Clojure program and spits out
>> a smaller, simpler, faster Clojure program which does exactly what yours
>> did...
>> 
>> Of course, you are such a good programmer that your program could not be
>> improved ? In which case we need you writing my Clojure program :-)
>> 
>> This is opening the door onto a very large but very interesting problem
>> space.
>> 
>> Starting the project off in a language that is homoiconic should deliver
>> enormous benefits straight away as the language itself provides a reader, an
>> Abstract Syntax Tree (itself) , a macro language (itself) etc...
>> 
>> I have some initial ideas -
>> 
>> - I was thinking of looking at core.logic to see if I might be able to use
>> it to match code to which refactorings might be applied.
>> 
>> - I was wondering whether analysing a class/methods transitive bytecode
>> might be enough to decide whether a function/method was effectively pure or
>> not.
>> 
>> - I was wondering whether a simple initial approach would be to inline all
>> but the recursive macros and functions in a program and then work backwards
>> from the fully expanded program applying refactorings to extract shared code
>> etc.
>> 
>> - I was thinking that some of this machinery would be a nice thing to have
>> in a Clojure IDE, advising you about potential refactorings and applying
>> them as you type.
>> 
>> - I was imagining that ultimately the inputs might not be have to be
>> Clojure, but maybe anything that compiled down to Java bytecode.
>> 
>> - I was wondering whether there was much synergy with core.typed.
>> 
>> - I was wondering whether you could work out how many cpu cycles a function
>> might take to run by inspecting its bytecode or optimise for mechanical
>> sympathy if your system knew a bit about the right things.
>> 
>> - I was wondering whether my program could benchmark functions then rewrite
>> them and benchmark them again to confirm that they were faster.
>> 
>> - i was considering which metrics should be used to decide that a program
>> was simpler,
>> 
>> - I was wondering whether a Clojure program could learn much about writing
>> Clojure programs from analysing all the Clojure programs stored on e.g.
>> GitHub.
>> 
>> - I am dreaming of the day when programs are written by more abstract
>> programs which are written by more abstract programs... which are written by
>> AIs :-)
>> 
>> 
>> I guess I am talking about writing an Expert System whose problem domain is
>> Clojure [and Java bytecode], which encodes a set of rules for transforming
>> one form of its input into another form that in some way satisfies some sort
>> of [sub]goal. A system which can plan refactorings from an initial state to
>> an 'improved' goal state.
>> 
>> I haven't written any code yet. I realise that this is a huge subject and
>> that the best thing to do would be to talk to lots of people much smarter
>> than myself about it - so here I am.
>> 
>> What does everyone think ?
>> 
>> Is this worth discussing or just pie in the sky ?
>> 
>> Looking forward to hearing your thoughts,
>> 
>> 
>> Jules
>> 
>> --
>> 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 th

Re: crazy idea...

2015-11-28 Thread Lucas Bradstreet 
Kibit (https://github.com/jonase/kibit) does many of the things that
you describe, though it doesn't go as far you dream. It also uses
core.logic to suggest equivalent substitutions.

I'd be happy to see more work in this area.

Lucas

On 29 November 2015 at 02:01, Jules  wrote:
> Guys,
>
> I've had pieces of this idea wandering around my head for years now and have
> finally decided that the time might be right for putting them together in
> the context of Clojure. I'm sure that others have had similar ideas before :
>
> Imagine my Clojure program which reads in your Clojure program and spits out
> a smaller, simpler, faster Clojure program which does exactly what yours
> did...
>
> Of course, you are such a good programmer that your program could not be
> improved ? In which case we need you writing my Clojure program :-)
>
> This is opening the door onto a very large but very interesting problem
> space.
>
> Starting the project off in a language that is homoiconic should deliver
> enormous benefits straight away as the language itself provides a reader, an
> Abstract Syntax Tree (itself) , a macro language (itself) etc...
>
> I have some initial ideas -
>
> - I was thinking of looking at core.logic to see if I might be able to use
> it to match code to which refactorings might be applied.
>
> - I was wondering whether analysing a class/methods transitive bytecode
> might be enough to decide whether a function/method was effectively pure or
> not.
>
> - I was wondering whether a simple initial approach would be to inline all
> but the recursive macros and functions in a program and then work backwards
> from the fully expanded program applying refactorings to extract shared code
> etc.
>
> - I was thinking that some of this machinery would be a nice thing to have
> in a Clojure IDE, advising you about potential refactorings and applying
> them as you type.
>
> - I was imagining that ultimately the inputs might not be have to be
> Clojure, but maybe anything that compiled down to Java bytecode.
>
> - I was wondering whether there was much synergy with core.typed.
>
> - I was wondering whether you could work out how many cpu cycles a function
> might take to run by inspecting its bytecode or optimise for mechanical
> sympathy if your system knew a bit about the right things.
>
> - I was wondering whether my program could benchmark functions then rewrite
> them and benchmark them again to confirm that they were faster.
>
> - i was considering which metrics should be used to decide that a program
> was simpler,
>
> - I was wondering whether a Clojure program could learn much about writing
> Clojure programs from analysing all the Clojure programs stored on e.g.
> GitHub.
>
> - I am dreaming of the day when programs are written by more abstract
> programs which are written by more abstract programs... which are written by
> AIs :-)
>
>
> I guess I am talking about writing an Expert System whose problem domain is
> Clojure [and Java bytecode], which encodes a set of rules for transforming
> one form of its input into another form that in some way satisfies some sort
> of [sub]goal. A system which can plan refactorings from an initial state to
> an 'improved' goal state.
>
> I haven't written any code yet. I realise that this is a huge subject and
> that the best thing to do would be to talk to lots of people much smarter
> than myself about it - so here I am.
>
> What does everyone think ?
>
> Is this worth discussing or just pie in the sky ?
>
> Looking forward to hearing your thoughts,
>
>
> Jules
>
> --
> 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.

crazy idea...

2015-11-28 Thread Jules 
Guys,

I've had pieces of this idea wandering around my head for years now and 
have finally decided that the time might be right for putting them together 
in the context of Clojure. I'm sure that others have had similar ideas 
before :

Imagine my Clojure program which reads in your Clojure program and spits 
out a smaller, simpler, faster Clojure program which does exactly what 
yours did...

Of course, you are such a good programmer that your program could not be 
improved ? In which case we need you writing my Clojure program :-)

This is opening the door onto a very large but very interesting problem 
space.

Starting the project off in a language that is homoiconic should deliver 
enormous benefits straight away as the language itself provides a reader, 
an Abstract Syntax Tree (itself) , a macro language (itself) etc...

I have some initial ideas -

- I was thinking of looking at core.logic to see if I might be able to use 
it to match code to which refactorings might be applied.

- I was wondering whether analysing a class/methods transitive bytecode 
might be enough to decide whether a function/method was effectively pure or 
not.

- I was wondering whether a simple initial approach would be to inline all 
but the recursive macros and functions in a program and then work backwards 
from the fully expanded program applying refactorings to extract shared 
code etc.

- I was thinking that some of this machinery would be a nice thing to have 
in a Clojure IDE, advising you about potential refactorings and applying 
them as you type.

- I was imagining that ultimately the inputs might not be have to be 
Clojure, but maybe anything that compiled down to Java bytecode.

- I was wondering whether there was much synergy with core.typed.

- I was wondering whether you could work out how many cpu cycles a function 
might take to run by inspecting its bytecode or optimise for mechanical 
sympathy if your system knew a bit about the right things.

- I was wondering whether my program could benchmark functions then rewrite 
them and benchmark them again to confirm that they were faster.

- i was considering which metrics should be used to decide that a program 
was simpler,

- I was wondering whether a Clojure program could learn much about writing 
Clojure programs from analysing all the Clojure programs stored on e.g. 
GitHub.

- I am dreaming of the day when programs are written by more abstract 
programs which are written by more abstract programs... which are written 
by AIs :-)


I guess I am talking about writing an Expert System whose problem domain is 
Clojure [and Java bytecode], which encodes a set of rules for transforming 
one form of its input into another form that in some way satisfies some 
sort of [sub]goal. A system which can plan refactorings from an initial 
state to an 'improved' goal state.

I haven't written any code yet. I realise that this is a huge subject and 
that the best thing to do would be to talk to lots of people much smarter 
than myself about it - so here I am.

What does everyone think ?

Is this worth discussing or just pie in the sky ?

Looking forward to hearing your thoughts,


Jules

-- 
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: Current Cider SNAPSHOT not working??

2015-11-28 Thread Karel Miarka 
Thanks Bozhidar for pointing out the link. There is a lot of new 
interesting information. I feel it is time to dig into my project.clj 
generated a few months ago and think about the new recommended workflow.

On Saturday, November 28, 2015 at 5:51:57 PM UTC+1, Bozhidar Batsov wrote:
>
> Did you go over the instructions here 
> https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl
>  
> ?
>
>

-- 
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: Current Cider SNAPSHOT not working??

2015-11-28 Thread Karel Miarka 
Thanks Alexander, all the warnings disappeared by adding the 
:nrepl-middleware key to the :figwheel section!

On Friday, November 27, 2015 at 10:39:27 PM UTC+1, alexander adhyatma wrote:
>
> you need to add com.cemerick/piggieback to the project.clj (dependency 
> section) as well as adding cider/cider-nrepl "0.10.0-SNAPSHOT" and 
> refactor-nrepl to the plugin section.
> then in the :figwheel section, you need to add 
>
> :nrepl-middleware ["cemerick.piggieback/wrap-cljs-repl" 
> "cider.nrepl/cider-middleware" "refactor-nrepl.middleware/wrap-refactor"]
>
> should be running great. 
>
>>
>>>

-- 
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: Current Cider SNAPSHOT not working??

2015-11-28 Thread Bozhidar Batsov 
Did you go over the instructions here
https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl
?

On 27 November 2015 at 23:33, alexander adhyatma 
wrote:

> you need to add com.cemerick/piggieback to the project.clj (dependency
> section) as well as adding cider/cider-nrepl "0.10.0-SNAPSHOT" and
> refactor-nrepl to the plugin section.
> then in the :figwheel section, you need to add
>
> :nrepl-middleware ["cemerick.piggieback/wrap-cljs-repl"
> "cider.nrepl/cider-middleware" "refactor-nrepl.middleware/wrap-refactor"]
>
> should be running great.
>
>
> On Friday, November 27, 2015 at 7:53:32 PM UTC+7, Karel Miarka wrote:
>>
>> The plugins were pulled, cider namespace required, everything is OK when
>> I connect from Cider to "lein repl". Works fine in both spacemacs and
>> prelude.
>>
>> Both cider & refactor middleware warnings occur only in spacemacs when I
>> start "lein figwheel" with nREPL as I'm used to.
>> In prelude there was only the cider middleware warning, refactor was not
>> complaining.
>> In spacemacs both warnings appear also with clojure-emacs/example-config
>> which uses 0.9.1 Cider release when connecting agains "lein figwheel".
>>
>> It worked fine with my old 32bit setup. I used to run just "lein
>> figwheel" for both server and client to save memory. And then connected to
>> the nREPL 2x and run figwheel.side-car/cljs-repl in one of them.
>>
>> Thanks for the help. I will try to play with my project.clj file or solve
>> it by running "lein repl" for the server and "lein figwheel" for the client
>> part.
>>
>> On Friday, November 27, 2015 at 12:56:00 AM UTC+1, Artur Malabarba wrote:
>>>
>>> Looks like your plugins are not getting pulled by leiningen.
>>>
>>> Delete your .m2/ snapshots and then start lein repl in a terminal. Do
>>> you see the plugins being pulled?
>>>
>>> In this repl, are you able to require cider namespaces? Try: (require
>>> 'cider.nrepl.middleware.debug)
>>>
>>> --
> 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.