Re: Contribute Specter to Clojure core?

[Erik Assum]

My thoughts on this were spurred by this tweet from Nikita Prokopov 
https://twitter.com/nikitonsky/status/837049980053516310

I generally don't have the need to alter stuff deep down in data structures, 
but when I do, I don't mind writing the functions to do so. 

The two things that worries me about Specter are
1) One more path-DSL to learn for both my team and I. 
2) If Clojure were an OO-language, wouldn't I be violating the law of Demeter 
https://en.m.wikipedia.org/wiki/Law_of_Demeter when using specter?

I realize that these are not arguments for or against Specter going into 
Clojure, more my thoughts on why I'm not using it. 

Erik. 
-- 
i farta

> Den 16. feb. 2017 kl. 04.05 skrev Alex Miller :
> 
> 
>> On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:
>> Alex – care to elaborate? When I get this question it would be nice to be 
>> able to tell people why the core team isn't interested.
> 
> The default answer to all such questions is no. Clojure has a small library 
> and Rich wants it to remain that way. 
> -- 
> 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: Contribute Specter to Clojure core?

[Mark Engelberg]

The first time I watched Nathan talk about Specter, I had the exact same
thoughts -- "My data structures aren't that complex, I can't relate to
these examples, I don't need Specter, I'm fine with Clojure's get-in,
update-in, assoc-in."

But then, I challenged myself for one day to use Specter's select,
transform, set-val with navigators as an alternative to Clojure's
built-ins, just to get a feel for how they worked.

Once the library was already required there at the top of my namespace, and
once I became accustomed to the navigators, suddenly, by the end of that
day I was seeing *all kinds of places* where I could use Specter in
non-obvious ways in my code to make it dramatically leaner and more elegant.

Note that this was code where I was getting along just fine without
Specter.  Yes, I could get along without it, but Specter made the code
better.  And, oh yeah, faster as well.

There seems to be a kind of thinking expressed here that Specter somehow
corrupts your programming style and makes you more likely to create
unnecessarily deep data structures.  But your data structures don't
actually have to be all that deep to derive benefit from Specter.  My data
structures weren't all that deep before Specter, and they aren't any deeper
now -- I just have richer tools to work with.

So take this as one data point:  my assessment of Specter before I actually
tried it turned out to be wrong, and its utility greatly exceeded my
expectations.  Try it for a day or two, and maybe you too will "see the
light".

--Mark






On Sat, Mar 4, 2017 at 1:22 AM, Erik Assum  wrote:

> My thoughts on this were spurred by this tweet from Nikita Prokopov
> https://twitter.com/nikitonsky/status/837049980053516310
>
> I generally don't have the need to alter stuff deep down in data
> structures, but when I do, I don't mind writing the functions to do so.
>
> The two things that worries me about Specter are
> 1) One more path-DSL to learn for both my team and I.
> 2) If Clojure were an OO-language, wouldn't I be violating the law of
> Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter when using specter?
>
> I realize that these are not arguments for or against Specter going into
> Clojure, more my thoughts on why I'm not using it.
>
> Erik.
> --
> i farta
>
> Den 16. feb. 2017 kl. 04.05 skrev Alex Miller :
>
>
> On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:
>>
>> Alex – care to elaborate? When I get this question it would be nice to be
>> able to tell people why the core team isn't interested.
>>
>
> The default answer to all such questions is no. Clojure has a small
> library and Rich wants it to remain that way.
>
> --
> 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.
>

-- 
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: Application silently shuts down by itself after running for some hours

[Scott Bauer]

Out of curiosity, have you tried catching any and all errors as opposed to 
expecting to see an error message logged upon the system dying?

While searching for possible causes, I did come across this similar post 
 
from a few years ago... not sure if it will help, but it may.


On Friday, March 3, 2017 at 10:57:20 AM UTC-5, JokkeB wrote:
>
> I have an application which I run with "lein run". The main looks 
> something like this
>
> (defn -main []
>  (log/info "start")
>  (log/info "channel returned" (async/ ) (websocket-server 9122
>  (log/info "quit"))
>
> start-server returns a channel created with async/reduce which shouldn't 
> ever produce a value. I see the "start" logged, the application runs for a 
> day or two (not sure if the time is always the same) and then it closes 
> without any errors or without logging "channel returned" or "quit". 
>
> If there is an error in my code and the program quits I should see the 
> "quit" message. If there is a memory leak or something I would assume I'd 
> get an error message. Has anyone experienced anything similar?
>
> Could the reason be running it with lein (I haven't tried a jar)? If so, 
> why?
>
>

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

1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Alex Miller]

This is definitely related to the gen-class spec, but I'm not at a computer to 
look at enough stuff to say if the bug is your code or the spec. 

You might try quoting rhe class name in case it's getting resolved to a class 
instance? Might be crazy talk.

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

Re: Trying to make an uberjar

[Cecil Westerhof]

2017-03-04 8:13 GMT+01:00 Jeaye :

> On Sat, Mar 04, 2017 at 08:09:39AM +0100, Cecil Westerhof wrote:
> > 2017-03-04 7:44 GMT+01:00 Jeaye :
> >
> > > Cecil,
> > >
> > > > But when running:
> > > > lein uberjar
> > > > I still get:
> > > > This code is executed when starting Clojure.
> > > > Compiling quotes.core
> > > > Warning: The Main-Class specified does not exist within the jar. It
> may
> > > not
> > > > be executable as expected. A gen-class directive may be missing in
> the
> > > > namespace which contains the main method, or the namespace has not
> been
> > > > AOT-compiled.
> > > > Created /home/cecil/Clojure/Quotes/target/quotes-0.0.1.jar
> > > > Created /home/cecil/Clojure/Quotes/target/quotes-0.0.1-
> standalone.jar
> > > >
> > > > What do I need to change to make an uberjar. (Jars are generated, but
> > > > cannot be used.)
> > >
> > > The warning which lein provided is trying to tell you exactly what you
> > > need to do. In the `ns` form of your quotes.core namespace, you should
> add
> > > a (:gen-class). Example:
> > >
> > > ```clojure
> > > (ns quotes.core
> > >   (:gen-class))
> > > ```
> > >
> >
> > ​That was what was needed. Thanks.
> >
> > And I could remove the added:
> > :profiles {
> > :uberjar {:aot :all}
> >   }
>
> For the best performance, you likely want AOT (ahead-of-time) compilation.
> In general, I'd recommend keeping that uberjar profile with `{:aot :all}`.
>

​That is why it is smart to communicate small non essential changes: people
can set you on the right track. :-)

I put that back. I now removed the ‘:aot [quotes.core]’, or should I keep
that also?

When I first got the error I found two different pieces of advice. One for
both changes. When those did not work I asked here.


I should pick up Clojure again. I only did one little project (long ago) to
try it out. But that is no way to learn a language. Sadly there is no real
use here for it. :'-(

-- 
Cecil Westerhof

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

Re: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Saturday, March 4, 2017 at 7:24:05 AM UTC-6, Alex Miller wrote:
>
> This is definitely related to the gen-class spec, but I'm not at a 
> computer to look at enough stuff to say if the bug is your code or the 
> spec. 
>
> You might try quoting rhe class name in case it's getting resolved to a 
> class instance? Might be crazy talk.
>

That produced pretty much the same error:

In: [3 :methods 32 2] val: "java.lang.Object" fails spec: 
:clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
:return-type] predicate: simple-symbol?

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Saturday, March 4, 2017 at 7:58:38 AM UTC-6, Mars0i wrote:
>
> On Saturday, March 4, 2017 at 7:24:05 AM UTC-6, Alex Miller wrote:
>>
>> This is definitely related to the gen-class spec, but I'm not at a 
>> computer to look at enough stuff to say if the bug is your code or the 
>> spec. 
>>
>> You might try quoting rhe class name in case it's getting resolved to a 
>> class instance? Might be crazy talk.
>>
>
> That produced pretty much the same error:
>
> In: [3 :methods 32 2] val: "java.lang.Object" fails spec: 
> :clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
> :return-type] predicate: simple-symbol?
>
>  
Oh--sorry.  You  probably meant the other kind of quoting, i.e. with 
apostrophe, the Clojure special form quote.  That fixed it.  Thanks very 
much.

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

Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Steve Murphy]

Hello--

Heard interesting things about clojure, thought I'd play with it, so I 
downloaded the clojure-1.8.0 zip file,
exploded it, and tried to build it with ant... all this on my ubuntu 16.04 
workstation.

I discovered my java installation is a bit incomplete for this... I 
installed the openjdk-8-jdk and openjdk-8-jdk-headless and ant packages.
I had to update my JAVA_HOME :

declare -x JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

and:

murf@parse1:~/Downloads/clojure-1.8.0$ ant
Buildfile: /home/murf/Downloads/clojure-1.8.0/build.xml

clean:
   [delete] Deleting directory /home/murf/Downloads/clojure-1.8.0/target

init:
[mkdir] Created dir: /home/murf/Downloads/clojure-1.8.0/target/classes
[mkdir] Created dir: 
/home/murf/Downloads/clojure-1.8.0/target/classes/clojure

compile-java:
[javac] Compiling 167 source files to 
/home/murf/Downloads/clojure-1.8.0/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction 
with -source 1.6
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 warning

compile-clojure:
 [java] Compiling clojure.core to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.core.protocols to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.core.server to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.main to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.set to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.edn to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.xml to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.zip to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.inspector to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.walk to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.stacktrace to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.template to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.test to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.test.tap to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.test.junit to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.pprint to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.java.io to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.repl to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.java.browse to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.java.javadoc to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.java.shell to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.java.browse-ui to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.string to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.data to 
/home/murf/Downloads/clojure-1.8.0/target/classes
 [java] Compiling clojure.reflect to 
/home/murf/Downloads/clojure-1.8.0/target/classes

build:

compile-tests:
[mkdir] Created dir: 
/home/murf/Downloads/clojure-1.8.0/target/test-classes
[javac] Compiling 3 source files to 
/home/murf/Downloads/clojure-1.8.0/target/test-classes
[javac] warning: [options] bootstrap class path not set in conjunction 
with -source 1.6
[javac] 1 warning
 [echo] Direct linking = true
 [java] Compiling clojure.test-clojure.protocols.examples to 
/home/murf/Downloads/clojure-1.8.0/target/test-classes
 [java] Compiling clojure.test-clojure.genclass.examples to 
/home/murf/Downloads/clojure-1.8.0/target/test-classes
 [java] Compiling clojure.test-clojure.compilation.load-ns to 
/home/murf/Downloads/clojure-1.8.0/target/test-classes
 [java] Compiling clojure.test-clojure.annotations to 
/home/murf/Downloads/clojure-1.8.0/target/test-classes

test-example:
 [java] Exception in thread "main" java.io.FileNotFoundException: Could 
not locate clojure/tools/namespace/find__init.class or 
clojure/tools/namespace/find.clj on classpath., 
compiling:(/home/murf/Downloads/clojure-1.8.0/src/script/run_test.clj:2:1)
 [java] at clojure.lang.Compiler.load(Compiler.java:7391)
 [java] at clojure.lang.Compiler.loadFile(Compiler.java:7317)
 [java] at clojure.main$load_script.invokeStatic(main.clj:275)
 [java] at clojure.main$script_opt.invokeStatic(main.clj:335)
 [java] at clojure.main$script_opt.invoke(main.clj:330)
 [java] at clojure.main$main.invokeStatic(main.clj:421)
 [java] at cloju

Re: Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Andy Fingerhut]

The clojure-1.8.0.zip file should also contain a pre-built JAR file named
clojure-1.8.0.jar, if you want to just use that and run with it.

I do not know if it is intentional or a mistake that some of the files
necessary to build are not included in that zip file.  It may be
intentional, with the idea that the zip file is what you get if you want
everything already built, without having to do so yourself.

If you want to build Clojure yourself from source, one way that works is to
get all of the files in the git repository, e.g. with this command:

git clone https://github.com/clojure/clojure.git

Andy

On Sat, Mar 4, 2017 at 9:59 AM, Steve Murphy  wrote:

> Hello--
>
> Heard interesting things about clojure, thought I'd play with it, so I
> downloaded the clojure-1.8.0 zip file,
> exploded it, and tried to build it with ant... all this on my ubuntu 16.04
> workstation.
>
> I discovered my java installation is a bit incomplete for this... I
> installed the openjdk-8-jdk and openjdk-8-jdk-headless and ant packages.
> I had to update my JAVA_HOME :
>
> declare -x JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
>
> and:
>
> murf@parse1:~/Downloads/clojure-1.8.0$ ant
> Buildfile: /home/murf/Downloads/clojure-1.8.0/build.xml
>
> clean:
>[delete] Deleting directory /home/murf/Downloads/clojure-1.8.0/target
>
> init:
> [mkdir] Created dir: /home/murf/Downloads/clojure-1.8.0/target/classes
> [mkdir] Created dir: /home/murf/Downloads/clojure-
> 1.8.0/target/classes/clojure
>
> compile-java:
> [javac] Compiling 167 source files to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [javac] 1 warning
>
> compile-clojure:
>  [java] Compiling clojure.core to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.core.protocols to
> /home/murf/Downloads/clojure-1.8.0/target/classes
>  [java] Compiling clojure.core.server to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.main to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.set to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.edn to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.xml to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.zip to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.inspector to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.walk to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.stacktrace to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.template to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.test to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.test.tap to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.test.junit to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.pprint to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.java.io to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.repl to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.java.browse to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.java.javadoc to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.java.shell to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.java.browse-ui to
> /home/murf/Downloads/clojure-1.8.0/target/classes
>  [java] Compiling clojure.string to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.data to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>  [java] Compiling clojure.reflect to /home/murf/Downloads/clojure-
> 1.8.0/target/classes
>
> build:
>
> compile-tests:
> [mkdir] Created dir: /home/murf/Downloads/clojure-
> 1.8.0/target/test-classes
> [javac] Compiling 3 source files to /home/murf/Downloads/clojure-
> 1.8.0/target/test-classes
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] 1 warning
>  [echo] Direct linking = true
>  [java] Compiling clojure.test-clojure.protocols.examples to
> /home/murf/Downloads/clojure-1.8.0/target/test-classes
>  [java] Compiling clojure.test-clojure.genclass.examples to
> /home/murf/Downloads/clojure-1.8.0/target/test-classes
>  [java] Compiling clojure.test-clojure.compilation.load-ns to
> /home/murf/Dow

Re: Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Gregg Reynolds]

On Mar 4, 2017 1:43 PM, "Steve Murphy"  wrote:

Hello--

Heard interesting things about clojure, thought I'd play with it, so I
downloaded the clojure-1.8.0 zip file,
exploded it, and tried to build it with ant... all this on my ubuntu 16.04
workstation.


Welcome to Clojure. If you want to play with the language, building it is
about the last thing you want to do.  You can download the jar, but the
best way to get going is to use one of the std build systems that take care
of all the housekeeping. I've never manually downloaded Clojure, always let
the tools deal with that. The most popular by far are
https://github.com/boot-clj/boot and https://leiningen.org.  with either
you can start coding inmediately.

hth, g

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

Re: Trying to make an uberjar

[Jeaye]

On Sat, Mar 04, 2017 at 02:44:31PM +0100, Cecil Westerhof wrote:
> 2017-03-04 8:13 GMT+01:00 Jeaye :
> 
> > On Sat, Mar 04, 2017 at 08:09:39AM +0100, Cecil Westerhof wrote:
> > > 2017-03-04 7:44 GMT+01:00 Jeaye :
> > >
> > > > Cecil,
> > > >
> > > > > But when running:
> > > > > lein uberjar
> > > > > I still get:
> > > > > This code is executed when starting Clojure.
> > > > > Compiling quotes.core
> > > > > Warning: The Main-Class specified does not exist within the jar. It
> > may
> > > > not
> > > > > be executable as expected. A gen-class directive may be missing in
> > the
> > > > > namespace which contains the main method, or the namespace has not
> > been
> > > > > AOT-compiled.
> > > > > Created /home/cecil/Clojure/Quotes/target/quotes-0.0.1.jar
> > > > > Created /home/cecil/Clojure/Quotes/target/quotes-0.0.1-
> > standalone.jar
> > > > >
> > > > > What do I need to change to make an uberjar. (Jars are generated, but
> > > > > cannot be used.)
> > > >
> > > > The warning which lein provided is trying to tell you exactly what you
> > > > need to do. In the `ns` form of your quotes.core namespace, you should
> > add
> > > > a (:gen-class). Example:
> > > >
> > > > ```clojure
> > > > (ns quotes.core
> > > >   (:gen-class))
> > > > ```
> > > >
> > >
> > > ​That was what was needed. Thanks.
> > >
> > > And I could remove the added:
> > > :profiles {
> > > :uberjar {:aot :all}
> > >   }
> >
> > For the best performance, you likely want AOT (ahead-of-time) compilation.
> > In general, I'd recommend keeping that uberjar profile with `{:aot :all}`.
> >
> 
> ​That is why it is smart to communicate small non essential changes: people
> can set you on the right track. :-)
> 
> I put that back. I now removed the ‘:aot [quotes.core]’, or should I keep
> that also?
> 
> When I first got the error I found two different pieces of advice. One for
> both changes. When those did not work I asked here.
> 
> 
> I should pick up Clojure again. I only did one little project (long ago) to
> try it out. But that is no way to learn a language. Sadly there is no real
> use here for it. :'-(

There's no need for `:aot [quotes.core]` if you're using `:aot :all` in your 
uberjar profile. The only other reason you'd want it is to AOT that namespace 
outside of the uberjar profile. That's up to you, but typically not a concern.

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


signature.asc
Description: PGP signature

Re: Trying to make an uberjar

[Cecil Westerhof]

2017-03-04 21:15 GMT+01:00 Jeaye :

> > > > ​That was what was needed. Thanks.
> > > >
> > > > And I could remove the added:
> > > > :profiles {
> > > > :uberjar {:aot :all}
> > > >   }
> > >
> > > For the best performance, you likely want AOT (ahead-of-time)
> compilation.
> > > In general, I'd recommend keeping that uberjar profile with `{:aot
> :all}`.
> > >
> >
> > ​That is why it is smart to communicate small non essential changes:
> people
> > can set you on the right track. :-)
> >
> > I put that back. I now removed the ‘:aot [quotes.core]’, or should I keep
> > that also?
>
> There's no need for `:aot [quotes.core]` if you're using `:aot :all` in
> your uberjar profile. The only other reason you'd want it is to AOT that
> namespace outside of the uberjar profile. That's up to you, but typically
> not a concern.
>

​Thank you. I thought so, but it is better to be sure.

-- 
Cecil Westerhof

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

Re: Contribute Specter to Clojure core?

[Moe Aboulkheir]

On Sat, Mar 4, 2017 at 6:35 AM, Asim Jalis  wrote:

> What might be a Clojurey syntax for doing path navigation? In other words
> how could get-in be extended so that it could parse nested vectors like it
> parses nested maps? Thinking out aloud, an integer in the path when the
> data structure at that level is a vector should treat the integer as an
> index.
>

If I'm reading you correctly, that is Clojure's current behaviour - (get-in
{:a [{:b "X"}]}  [:a 0 :b]) => "X"

Take care,
Moe

-- 
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: Contribute Specter to Clojure core?

[Gregg Reynolds]

On Mar 3, 2017 6:27 PM, "John Newman"  wrote:

I think the path navigator DSL feels slightly un-Clojurey. But other than
that, I think Specter is pure magic and Nathan is right that editing deeply
nested data structures in Clojure is a point of deficiency, especially for
people coming from mutable languages/data structures. To that extent, I
think Specter does a yeoman's job of filling that "missing piece" of
Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey
to me.


+1.  the functionality is great, but the api imho is not just a little
unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at
least.

Specter is a specific solution to a general problem.  all such solutions
will probably boil down to more or less the same thing,
implementation-wise.  but the interface makes all the diff.  for example,
it's easy to imagine a more xsl-like (or even css-like) syntax with the
same functionality.

so fwiw i would oppose making specter part of core, but i would
enthusiatically support making the functionality of specter part of core,
in some form yet to be determined.

-g

-- 
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: Vars as global thread-locals?

[Didier]

Hum, you're having me question myself.

See, I don't think dynamically scoped Vars are intended for anything in 
particular, they are what they are. Yes, they are useful when you need to 
pass configuration down a call stack, as long as you make sure you handle 
the thread-boundaries along the way. They can also be used to share per 
thread data throughout a thread's execution, which is what ThreadLocal in 
java does. So basically, I see two use cases. One, you want shared read 
only data accessible throughout a call stack (for that, they aren't as good 
as true dynamics, because you'll need to manually handle the thread 
boundaries). Or you want shared writable state per-thread, making this not 
per-thread would be dangerous, and can be done if you re-bind it manually 
across threads or when using constructs that does so like future.

The reason they are made per-thread, and not truly dynamic, as in, taking 
on the value down the stack no matter what, is because threads could 
content on it, and it could cause bugs, so its made per-thread for safety. 
Here's an example of such caveat:

(def ^:dynamic *dd*)

(binding [*dd* (atom "John")]
  (let [a (future (reset! *dd* "Bob"))
b (future (reset! *dd* "Mike"))]
@*dd*))

Run this many times, and *dd*'s value could be either Mike or Bob based on 
which threads wins the race.

So the limitation of dynamic scope are inherent to dynamic scoping where 
you have threads. Clojure's attempt at solving this limitation is to make 
them per-thread, with explicit cross thread management through (bound-fn). 
After a few releases, Clojure decided to make future and a few other 
constructs implicitly propagate the dynamic var across threads as that was 
often what people were expecting. All to say, when using dynamic Vars in 
Clojure, you must be thread aware and understand the caveats. There is no 
better way that I'm aware of to handle dynamic scope in a multi-threaded 
environment.

Clojure has root bindings, which Java ThreadLocals does not have. Clojure 
lets you say, if this thread does not have a value for the dynamic Var, 
fetch the root value instead. This is really useful in the use case of read 
only data, like configuration, because you can set a default config. You 
can simulate this in Java with initialValue.

Now, the initialValue lets you do one more thing, it can let you generate 
per-thread values on get, without needing to set it. Such as setting a 
random int on the first get, and subsequent get from that thread will from 
then on return that same generated random int. In Clojure, this is what 
I've seen for such use case:

(def ^:dynamic *id*)

(defmacro with-id [& body]
  `(binding [*id* (rand-int 1)]
~@body))

@(future (with-id (println (str "My request id is: " *id*))
   "Success"))

It's not as convenient per-say, since you have to be explicit and call the 
macro from each Thread before getting the value, but it solves the use case.

Remember that ThreadLocals are more inconvenient to get though, since you 
need to get the ThreadLocal and then get the value out of it. So in some 
ways, Clojure dynamics can also be seen as more convenient.

Up to now, I feel like there is nothing I can not do with a Clojure Dynamic 
Var that I could with a ThreadLocal. They're not identical, but to me, the 
two fulfills equal use cases. And since under the hood, Clojure dynamic 
Vars are implemented with ThreadLocal, they should perform similarly too.

You say you can pass around references of ThreadLocals, but I'm not sure 
what the point of that would be, like what use case would it allow? In 
general, and even the Java doc page says so, you'll put the ThreadLocal in 
a static variable, i.e., private static final ThreadLocal 
threadId. At that point, it's equal to (def ^:dynamic threadId).

Anyways, you can also do that in Clojure, you can pass around the Var such 
as:

(defn printVar [v]
  (println @v))

(with-local-vars [*threadId* 0]
  (.start (Thread. (bound-fn [] (var-set *threadId* 1) (printVar 
*threadId*
  (.start (Thread. (bound-fn [] (var-set *threadId* 2) (printVar 
*threadId*)

I have a function printVar that takes a Var and prints it. Then I create a 
new Var called *threadId* and I set it to two different values, one for 
each Thread. I pass the Var to my Var printing function, and as you can see 
if you run this, it works like it would in Java if you did the same with 
ThreadLocal, printing different values based on the thread.

I hope this helps.


On Friday, 3 March 2017 07:02:21 UTC-8, Ernesto Garcia wrote:
>
> On Sunday, February 26, 2017 at 6:23:28 AM UTC+1, Didier wrote:
>>
>> Dynamic scoping and Java ThreadLocals gives you equal functionality, so 
>> I'd use them equally. This is because Clojure supports thread bound dynamic 
>> scope.
>>
>
> I wouldn't say that. While dynamically scoped Vars are meant to be context 
> that you implicitly pass down to your call stack, ThreadLocals are 
> r

Re: Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Alex Miller]

On Saturday, March 4, 2017 at 1:53:58 PM UTC-6, Andy Fingerhut wrote:
>
> The clojure-1.8.0.zip file should also contain a pre-built JAR file named 
> clojure-1.8.0.jar, if you want to just use that and run with it.
>

Most people obtain the jar by using a build tool that downloads the 
pre-built jar from the Maven central repo. Or you can just get the jar from 
the zip as Andy indicates. 

I do not know if it is intentional or a mistake that some of the files 
> necessary to build are not included in that zip file.  It may be 
> intentional, with the idea that the zip file is what you get if you want 
> everything already built, without having to do so yourself.
>

tools.namespace is used for some testing utilities and not for the src and 
so it not included in the jar (same as test.generative, test.check, etc).
 

> If you want to build Clojure yourself from source, one way that works is 
> to get all of the files in the git repository, e.g. with this command:
>
> git clone https://github.com/clojure/clojure.git
>

This is the best and recommended way to get the Clojure source. Once you 
do, you should be able to build it with Maven by doing 

 mvn clean package 

or run the tests with

mvn clean test 

I run these pretty much every day and the build box runs them on every 
commit so you should always expect them to work.
 

>
> Andy
>
> On Sat, Mar 4, 2017 at 9:59 AM, Steve Murphy  wrote:
>
>> Hello--
>>
>> Heard interesting things about clojure, thought I'd play with it, so I 
>> downloaded the clojure-1.8.0 zip file,
>> exploded it, and tried to build it with ant... all this on my ubuntu 
>> 16.04 workstation.
>>
>> I discovered my java installation is a bit incomplete for this... I 
>> installed the openjdk-8-jdk and openjdk-8-jdk-headless and ant packages.
>> I had to update my JAVA_HOME :
>>
>> declare -x JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
>>
>> and:
>>
>> murf@parse1:~/Downloads/clojure-1.8.0$ ant
>> Buildfile: /home/murf/Downloads/clojure-1.8.0/build.xml
>>
>> clean:
>>[delete] Deleting directory /home/murf/Downloads/clojure-1.8.0/target
>>
>> init:
>> [mkdir] Created dir: /home/murf/Downloads/clojure-1.8.0/target/classes
>> [mkdir] Created dir: 
>> /home/murf/Downloads/clojure-1.8.0/target/classes/clojure
>>
>> compile-java:
>> [javac] Compiling 167 source files to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>> [javac] warning: [options] bootstrap class path not set in 
>> conjunction with -source 1.6
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] 1 warning
>>
>> compile-clojure:
>>  [java] Compiling clojure.core to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.core.protocols to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.core.server to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.main to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.set to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.edn to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.xml to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.zip to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.inspector to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.walk to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.stacktrace to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.template to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.test to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.test.tap to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.test.junit to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.pprint to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.java.io to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.repl to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.java.browse to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.java.javadoc to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.java.shell to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.java.browse-ui to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.string to 
>> /home/murf/Downloads/clojure-1.8.0/target/classes
>>  [java] Compiling clojure.data to 

Re: Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Alex Miller]

>
>
> Welcome to Clojure. If you want to play with the language, building it is 
> about the last thing you want to do.  
>

Actually, it's quite fun to add debugging to parts of Clojure and use that 
modified version and I think it's nice that it is so easy to hack on if you 
like.

-- 
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: Contribute Specter to Clojure core?

[Gregg Reynolds]

On Mar 4, 2017 3:52 PM, "Gregg Reynolds"  wrote:



On Mar 3, 2017 6:27 PM, "John Newman"  wrote:

I think the path navigator DSL feels slightly un-Clojurey. But other than
that, I think Specter is pure magic and Nathan is right that editing deeply
nested data structures in Clojure is a point of deficiency, especially for
people coming from mutable languages/data structures. To that extent, I
think Specter does a yeoman's job of filling that "missing piece" of
Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey
to me.


+1.  the functionality is great, but the api imho is not just a little
unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at
least.

Specter is a specific solution to a general problem.  all such solutions
will probably boil down to more or less the same thing,
implementation-wise.  but the interface makes all the diff.  for example,
it's easy to imagine a more xsl-like (or even css-like) syntax with the
same functionality.


more to the point, imho everything specter is doing could be expressed in a
more naturally clojure idiom.

for example, let's take the first example at ,
https://github.com/nathanmarz/specter/blob/master/README.md, which amounts
to "apply f to every value in a map structure, at every level". this would
be a good thing to have. essentially, update-in with wildcards.  sth like
(update-in-v* m even? inc) would do quite nicely, i think. update-in-v
means map values (as opposed to update-in-k) the * makes it recursive,
even? is the predicate that selects values, inc is the fn to apply.

-- 
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: Could not locate clojure/tools/namespace/find__init.class or clojure/tools/namespace/find.clj on classpath.

[Gregg Reynolds]

On Mar 4, 2017 4:34 PM, "Alex Miller"  wrote:


> Welcome to Clojure. If you want to play with the language, building it is
> about the last thing you want to do.
>

Actually, it's quite fun to add debugging to parts of Clojure and use that
modified version and I think it's nice that it is so easy to hack on if you
like.


sure, but you are Alex Miller! ;)


-- 
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: Contribute Specter to Clojure core?

[Gregg Reynolds]

On Mar 4, 2017 5:08 PM, "John Newman"  wrote:

Gregg, agreed. But as an aside, as an external library, like core.async,
Specter is a shining example of why Clojure (and lisp) is such an awesome
platform.


+1001.  to be clear, i am _not_ saying specter is anthing less than
awesome. just talking ui.

The fact that Nathan was able to even implement this functionality, in some
places even more performant than core idioms, imho proves that Clojure has
power well beyond what the core team can or will provide to users. That's a
good sell for both Clojure as a platform and for Specter as a library.


yepper.

-g

-- 
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: Contribute Specter to Clojure core?

[John Newman]

Gregg, agreed. But as an aside, as an external library, like core.async,
Specter is a shining example of why Clojure (and lisp) is such an awesome
platform. The fact that Nathan was able to even implement this
functionality, in some places even more performant than core idioms, imho
proves that Clojure has power well beyond what the core team can or will
provide to users. That's a good sell for both Clojure as a platform and for
Specter as a library.

On Sat, Mar 4, 2017 at 5:39 PM Gregg Reynolds  wrote:

>
>
> On Mar 4, 2017 3:52 PM, "Gregg Reynolds"  wrote:
>
>
>
> On Mar 3, 2017 6:27 PM, "John Newman"  wrote:
>
> I think the path navigator DSL feels slightly un-Clojurey. But other than
> that, I think Specter is pure magic and Nathan is right that editing deeply
> nested data structures in Clojure is a point of deficiency, especially for
> people coming from mutable languages/data structures. To that extent, I
> think Specter does a yeoman's job of filling that "missing piece" of
> Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey
> to me.
>
>
> +1.  the functionality is great, but the api imho is not just a little
> unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at
> least.
>
> Specter is a specific solution to a general problem.  all such solutions
> will probably boil down to more or less the same thing,
> implementation-wise.  but the interface makes all the diff.  for example,
> it's easy to imagine a more xsl-like (or even css-like) syntax with the
> same functionality.
>
>
> more to the point, imho everything specter is doing could be expressed in
> a more naturally clojure idiom.
>
> for example, let's take the first example at ,
> https://github.com/nathanmarz/specter/blob/master/README.md, which
> amounts to "apply f to every value in a map structure, at every level".
> this would be a good thing to have. essentially, update-in with wildcards.
>  sth like (update-in-v* m even? inc) would do quite nicely, i think.
> update-in-v means map values (as opposed to update-in-k) the * makes it
> recursive, even? is the predicate that selects values, inc is the fn to
> apply.
>
> --
> 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: Contribute Specter to Clojure core?

[Didier]

This got me thinking, what is Clojure?

As I see it, Clojure is a combination of syntax and semantics combined with 
a standard library of functions and macros. Given the Clojure syntax, and 
the Clojure special forms, and Clojure core, I have myself Clojure.

Given that, we should be careful when adding things into core, since that 
makes the burden of writing a Clojure compiler heavier, as anyone who would 
like to port Clojure to another platform would need to re-implement the 
full standard library.

With this in mind, I don't think Specter is essential. In fact, I think the 
things we'd want into Core are everything that handles IO, and the basic 
operations that allows the Clojure language features and semantics.

If we add Specter to core, we make it a first class semantic. Its DSL 
becomes part of the syntax of Clojure.

Now, adding it to contribs could be fine, but I'm not too sure what the 
contribs are. Are they simply packages maintained by the Clojure team 
itself, or are they actually part of the standard library?

Either way, the beauty of Clojure is that libraries are unconstrained, so 
Specter would gain nothing from being added to core or part of contrib 
except for better publicity. So I'd vote for no.

On Saturday, 4 March 2017 15:13:41 UTC-8, Gregg Reynolds wrote:
>
>
>
> On Mar 4, 2017 5:08 PM, "John Newman" > 
> wrote:
>
> Gregg, agreed. But as an aside, as an external library, like core.async, 
> Specter is a shining example of why Clojure (and lisp) is such an awesome 
> platform. 
>
>
> +1001.  to be clear, i am _not_ saying specter is anthing less than 
> awesome. just talking ui.
>
> The fact that Nathan was able to even implement this functionality, in 
> some places even more performant than core idioms, imho proves that Clojure 
> has power well beyond what the core team can or will provide to users. 
> That's a good sell for both Clojure as a platform and for Specter as a 
> library.
>
>
> yepper.
>
> -g
>

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

What makes Clojure Clojure?

[Didier]

The Specter post about if it should be made into core or not got me 
wondering what makes Clojure Clojure.

I'm trying to wrap my head around what is the most minimal set of things 
that uniquely make up Clojure.

Right now, in that set I've got:

   - The Clojure syntax and its semantics
   - The Clojure special forms and their semantics
   - The Clojure core libraries and their semantics

So if I implemented a compiler that worked with the above set, it would be 
a valid Clojure compiler.

Now, ClojureScript appears to me like it is not Clojure, but a dialect of 
it. I say that because it breaks some of the syntax semantics of Clojure, 
like not allowing macros in the same namespace as functions. It also breaks 
some of the core semantics, like def creating standard JS vars and not 
Clojure Vars. In this respect, a language like hy-lang is also a Clojure 
dialect, granted it shares even less of the Clojure set.

Is ClojureCLR a dialect of Clojure, or is it a true Clojure implementation?

One last thing that is interesting about Clojure versus other languages is 
that it does not provide standard IO. These two things make it so that it 
is kind of dependent on its host to complete its offering as a programming 
language, which means any Clojure compiler will need to provide a mechanism 
for IO. Those would always differ from Clojures to Clojures, so I don't 
think that's part of what makes Clojure Clojure.

What are others thoughts on this?

P.S.: There's no point to this thread, its mostly curiosity.

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

What makes Clojure Clojure?

[Alex Miller]

Rich considers ClojureScript and ClojureCLR to be dialects of Clojure, not 
different languages.

-- 
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: What makes Clojure Clojure?

[John Newman]

Yeah, only Rich can really answer that question, right? :) But for me,
Clojure is increasingly becoming cljc. When a library advertises
compatibility in both clj and cljs, it just looks shinier to me. Feels like
a trend for Clojure libraries in general. And if agents and STM were on
cljs, I'd probably reach of those tools more often on both platforms.

On that note, if some Clojure concurrency magician would implement a
lightweight threading library in cljc, which worked on both single-threaded
cljs (offloading to webworkers where available) and JVM/CLR, allowing for
STM on cljc... Hell, I'd throw down on a bounty for that. It would really
bring cljs and clj into closer parity. And it would make cljs even more
appetizing to js programmers. And it would reunite cljs with one of clj's
original selling points - how immutability and persistent structures allow
for unparalleled (lol) concurrency solutions.

I almost got a rudimentary pmap thing working in cljs on core.async with
webworkers by using a binding-hack macro I found online somewhere. I
couldn't find great docs out there though on how to implement a lightweight
threading library.

On Sat, Mar 4, 2017 at 6:51 PM Didier  wrote:

> The Specter post about if it should be made into core or not got me
> wondering what makes Clojure Clojure.
>
> I'm trying to wrap my head around what is the most minimal set of things
> that uniquely make up Clojure.
>
> Right now, in that set I've got:
>
>- The Clojure syntax and its semantics
>- The Clojure special forms and their semantics
>- The Clojure core libraries and their semantics
>
> So if I implemented a compiler that worked with the above set, it would be
> a valid Clojure compiler.
>
> Now, ClojureScript appears to me like it is not Clojure, but a dialect of
> it. I say that because it breaks some of the syntax semantics of Clojure,
> like not allowing macros in the same namespace as functions. It also breaks
> some of the core semantics, like def creating standard JS vars and not
> Clojure Vars. In this respect, a language like hy-lang is also a Clojure
> dialect, granted it shares even less of the Clojure set.
>
> Is ClojureCLR a dialect of Clojure, or is it a true Clojure implementation?
>
> One last thing that is interesting about Clojure versus other languages is
> that it does not provide standard IO. These two things make it so that it
> is kind of dependent on its host to complete its offering as a programming
> language, which means any Clojure compiler will need to provide a mechanism
> for IO. Those would always differ from Clojures to Clojures, so I don't
> think that's part of what makes Clojure Clojure.
>
> What are others thoughts on this?
>
> P.S.: There's no point to this thread, its mostly curiosity.
>
> --
> 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: lein jar, uberjar don't allow hyphens in paths?

[Sean Corfield]

Java doesn’t allow – in names. That’s why Clojure and Clojure tooling maps – in 
names to _ in files (and classes).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: Mars0i
Sent: Friday, March 3, 2017 9:17 PM
To: Clojure
Subject: lein jar, uberjar don't allow hyphens in paths?

It looks like 'lein uberjar' and 'lein jar' don't like namespace path elements 
that contain hyphens.

Example:

lein new app foo-bar
cd foo-bar

Now edit src/foo_bar/core.clj, changing

(ns foo-bar.core
  (:gen-class))

to

(ns foo-bar.core
  (:gen-class
    :name foo-bar.core))

Then 'lein uberjar' reports:

Compiling foo-bar.core
Warning: The Main-Class specified does not exist within the jar. It may not be 
executable as expected. A gen-class directive may be missing in the namespace 
which contains the main method.

Also, 'java -jar target/uberjar/foo-bar-0.1.0-SNAPSHOT-standalone.jar' prints:

Error: Could not find or load main class foo_bar.core

A similar problem seems to occur with 'lein jar'.

However, no problem occurs with 'lein run', or with 'lein uberjar' if :name is 
left out of the ns form, or if :name is used but the project namespace 
qualifier does not contain a hyphen.

I think this has to do with the fact that when I use :name with foo-bar, 
core.class ends up in target/uberjar/classes/foo-bar, while its related inner 
class files end up in target/uberjar/classes/foo_bar.  If I don't use :name or 
if the path doesn't contain a dash, all of the classes end up in the same 
directory, e.g. foo_bar.  (I don't know much about jar files or subtleties of 
how the jvm interprets them.)

I have a standalone project that runs fine with 'lein run' but I'm unable to 
make an uberjar because of this problem.  (I apparently to need the :name 
element in order to create an instance of the same class in my -main function.) 
 The project is small enough that it won't be much trouble to rename filenames 
and namespace paths in order to get rid of dashes, but I'm wondering if there's 
a different solution.  

I'm also wondering whether this is a bug/flaw in Leiningen.  I can submit an 
issue if so.
-- 
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: Contribute Specter to Clojure core?

[Herwig Hochleitner]

2017-03-05 0:25 GMT+01:00 Didier :
> I'm not too sure what the contribs are. Are they simply packages maintained
> by the Clojure team itself, or are they actually part of the standard
> library?

As I understand it, they aren't any more sanctioned than any
third-party library, but the goal is to provide a stock of clojure
libraries under the same license as clojure itself. Also they provide
a common CI and path into maven central.

2017-03-04 22:52 GMT+01:00 Gregg Reynolds :
> it's easy to imagine a more xsl-like (or even css-like) syntax with the same
> functionality

I don't know how it squares up against specter in terms of
performance, but I've always been fond of the selector-engine in
enlive, from an engineering elegance POV, as an interface for tree
query and update.
It utilizes zippers, but only ever does a single pass (save for some
weird selectors). Can specter substantially improve on zippers for
this workload?
Is there an underlying abstraction, that could sit next to clojure.zip
or clojure.data.zip?

-- 
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: lein jar, uberjar don't allow hyphens in paths?

[Mars0i]

On Saturday, March 4, 2017 at 8:19:44 PM UTC-6, Sean Corfield wrote:
>
> Java doesn’t allow – in names. That’s why Clojure and Clojure tooling maps 
> – in names to _ in files (and classes).
>

Right, and this normally causes no problems (with a little bit of care).  I 
experience no problems with the hyphen/underscroe mapping using 'lein run' 
or running from the repl.  It's only 'lein jar' or 'lein uberjar' that 
seems unable to manage the mapping properly when there's an underscore in a 
directory name, i.e. a hyphen in a non-terminal namespace path element.

-- 
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: Version control at the function level - a la Rich

[Ken Restivo]

On Fri, Feb 17, 2017 at 01:56:04PM -0800, Josh Tilles wrote:
> I’m pretty sure you’re looking for codeq: 
> http://blog.datomic.com/2012/10/codeq.html
> 
> On Friday, February 17, 2017 at 4:39:12 PM UTC-5, Terje Dahl wrote:
> >
> > I recall Rich Hickey talking about this a few years back, but can't find 
> > anything about it.  
> > Am I just imaging it?
> > Or could someone point me in the right direction
> >
> 

I also remember him making some good points about this in his
"Spec-ulation" keynote recently.

https://www.youtube.com/watch?v=oyLBGkS5ICk

-ken

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