Re: Can we please deprecate the :use directive ?

[Korny Sietsma]

Agree that :use should be deprecated, mostly as it's quite a barrier to
folks new to the language that you need to know 3 different parts of the ns
macro before you start.

However "objectively bad" is strong language indeed. ":refer :all" is vital
anywhere you want a DSL - if using something like Korma, for example, you
have 3 options :

1. Use :as and fill your code with ugly things like "(k/select user
(k/where {:name [k/like " fred"]})

2. Use ":refer [select where like..." and almost every other symbol in
Korma - might be ok if you have a perfect IDE, but still needlessly verbose

3. Use ":refer :all". It's perfectly fine, IMHO, when used responsibly.

- Korny
 On 5 Aug 2013 09:09, "Anthony Grimes"  wrote:

> I can't think of a single good reason to not deprecate :use. :require can
> do everything :use could do now.
>
> This isn't about whether or not (:use ..) without :only is bad. I'd go as
> far as to say that outside of test files (and sometimes not even those) and
> repl sessions, :use without :only is objectively bad. Not much
> justification you can give me that'll make it unbad. But that isn't what
> this is about. Deprecating :use doesn't make doing the aforementioned bad
> thing impossible, and :refer :all was added to require for that specific
> purpose. :require still lets you do bad things if you really want to. All
> we're doing by deprecating :use is removing cruft and making things less
> complicated for new people. We currently have two things, and one of them
> does all the things the other one does and more, yet we still have both of
> them.
>
> Just my $0.02.
>
> On Tuesday, July 23, 2013 8:50:50 AM UTC-7, Greg wrote:
>>
>> I think I read somewhere that :use is no longer encouraged, but I could
>> be mistaken.
>>
>> From what I've read, it seems like most people agree that Clojure has too
>> many ways of including/importing/**referencing/requiring/using things:
>>
>> http://blog.8thlight.com/**colin-jones/2010/12/05/**
>> clojure-libs-and-namespaces-**require-use-import-and-ns.html
>>
>> The above gives a very nice explanation of all the various difference,
>> but it also acknowledges their complexity.
>>
>> Since :use uses :require, and since :require can do everything that :use
>> can, can we simplify Clojure programming a bit for newcomers by deprecating
>> the use of :use? The situation in ClojureScript is even worse because it
>> adds :require-macros on top of all the other ways of including files.
>>
>> Ideally, it would be awesome if there was just a single directive for
>> everything, but perhaps there's some complicated low-level reason why
>> that's not possible. :-\
>>
>> Thoughts?
>>
>> Thanks,
>> Greg
>>
>> P.S. If this has already been brought up you have my sincere apologies.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Steven Degutis]

The only time I've seen :as lead to ugly code was when it was in a DSL that
would probably have been nicer to use if it was a data-based DSL like
Hiccup rather than code-based.


On Mon, Aug 5, 2013 at 3:40 AM, Korny Sietsma  wrote:

> Agree that :use should be deprecated, mostly as it's quite a barrier to
> folks new to the language that you need to know 3 different parts of the ns
> macro before you start.
>
> However "objectively bad" is strong language indeed. ":refer :all" is
> vital anywhere you want a DSL - if using something like Korma, for example,
> you have 3 options :
>
> 1. Use :as and fill your code with ugly things like "(k/select user
> (k/where {:name [k/like " fred"]})
>
> 2. Use ":refer [select where like..." and almost every other symbol in
> Korma - might be ok if you have a perfect IDE, but still needlessly verbose
>
> 3. Use ":refer :all". It's perfectly fine, IMHO, when used responsibly.
>
> - Korny
>  On 5 Aug 2013 09:09, "Anthony Grimes"  wrote:
>
>> I can't think of a single good reason to not deprecate :use. :require can
>> do everything :use could do now.
>>
>> This isn't about whether or not (:use ..) without :only is bad. I'd go as
>> far as to say that outside of test files (and sometimes not even those) and
>> repl sessions, :use without :only is objectively bad. Not much
>> justification you can give me that'll make it unbad. But that isn't what
>> this is about. Deprecating :use doesn't make doing the aforementioned bad
>> thing impossible, and :refer :all was added to require for that specific
>> purpose. :require still lets you do bad things if you really want to. All
>> we're doing by deprecating :use is removing cruft and making things less
>> complicated for new people. We currently have two things, and one of them
>> does all the things the other one does and more, yet we still have both of
>> them.
>>
>> Just my $0.02.
>>
>> On Tuesday, July 23, 2013 8:50:50 AM UTC-7, Greg wrote:
>>>
>>> I think I read somewhere that :use is no longer encouraged, but I could
>>> be mistaken.
>>>
>>> From what I've read, it seems like most people agree that Clojure has
>>> too many ways of including/importing/**referencing/requiring/using
>>> things:
>>>
>>> http://blog.8thlight.com/**colin-jones/2010/12/05/**
>>> clojure-libs-and-namespaces-**require-use-import-and-ns.html
>>>
>>> The above gives a very nice explanation of all the various difference,
>>> but it also acknowledges their complexity.
>>>
>>> Since :use uses :require, and since :require can do everything that :use
>>> can, can we simplify Clojure programming a bit for newcomers by deprecating
>>> the use of :use? The situation in ClojureScript is even worse because it
>>> adds :require-macros on top of all the other ways of including files.
>>>
>>> Ideally, it would be awesome if there was just a single directive for
>>> everything, but perhaps there's some complicated low-level reason why
>>> that's not possible. :-\
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Greg
>>>
>>> P.S. If this has already been brought up you have my sincere apologies.
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also
>>> sharing with the NSA.
>>>
>>>  --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moder

core.async: macro and visibilities of async operations

[Alice]

(defmacro foo
  [c]
  `(!! c :hi))

I thought this would not work because foo is expanded after go is expanded, 
so 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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Phillip Lord]

Anthony Grimes  writes:
> I can't think of a single good reason to not deprecate :use. :require can 
> do everything :use could do now.

Wait for it, wait for it

> This isn't about whether or not (:use ..) without :only is bad. I'd go as 
> far as to say that outside of test files (and sometimes not even those) and 
> repl sessions, :use without :only is objectively bad. 

Yeah, you see, you can think of a single good reason, although you then
contradict yourself just to make it clear that it's not the case.

I mean, is there really any good reason why namespace qualifing
"deftest" should be necessary. Reason -- it's familiar and there are not
that many functions in clojure.test.

Another good reason, I have given before. I have written hundreds of
lines of code, with *no* calls at all to clojure.core, and lots to my
own library. Why under these circumstances is using clojure.core by
default and requiring my own library conducive to clear code?


> Not much justification you can give me that'll make it unbad. But that
> isn't what this is about. Deprecating :use doesn't make doing the
> aforementioned bad thing impossible, and :refer :all was added to
> require for that specific purpose. :require still lets you do bad
> things if you really want to. All we're doing by deprecating :use is
> removing cruft and making things less complicated for new people. We
> currently have two things, and one of them does all the things the
> other one does and more, yet we still have both of them.


Essentially, there are four things that can be done here. You can make
a function available (require), you make it usable by it's name (use),
you can make it available by it's namespace (refer), or you can make it
available to another name (aliasing).

The changes suggested do nothing toward reducing these things. As you
say, you will still able to do all of them. New people will find be
introduced to "use" in the repl and find no equivalent in the ns
directive. And lots of people will have to replace ":use" directives
with something else which does the same, but is longer.

Phil

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Tassilo Horn]

Alice  writes:

> (defmacro foo
>   [c]
>   `(
> (let [c (chan)]
>   (go (prn (foo c)))
>   (>!! c :hi))
>
> I thought this would not work because foo is expanded after go is expanded, 
> so  What am I missing?

`go` explicitly macroexpands the form given to it rather than relying on
the standard outside-in macroexpansion order.  You can see that in the
clojure.core.async.impl.ioc-macros namespace, i.e., there's an `expand`
function called by the :list implementation of the -item-to-ssa
multimethod.

Bye,
Tassilo

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 5. August 2013 12:17:53 UTC+2 schrieb Alice:
>
> (defmacro foo
>   [c]
>   `(
> (let [c (chan)]
>   (go (prn (foo c)))
>   (>!! c :hi))
>
> I thought this would not work because foo is expanded after go is 
> expanded, so  What am I missing?
>
>
I'm not sure what your expectations are exactly. It works, because go does 
recursively expand all macros in it's body before doing any work.

King regards
Meikel 

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Alice]

I didn't know that macros can do that! Thanks for the detailed answer.

On Monday, August 5, 2013 8:00:16 PM UTC+9, Tassilo Horn wrote:
>
> Alice > writes: 
>
> > (defmacro foo 
> >   [c] 
> >   `( > 
> > (let [c (chan)] 
> >   (go (prn (foo c))) 
> >   (>!! c :hi)) 
> > 
> > I thought this would not work because foo is expanded after go is 
> expanded, 
> > so  > What am I missing? 
>
> `go` explicitly macroexpands the form given to it rather than relying on 
> the standard outside-in macroexpansion order.  You can see that in the 
> clojure.core.async.impl.ioc-macros namespace, i.e., there's an `expand` 
> function called by the :list implementation of the -item-to-ssa 
> multimethod. 
>
> Bye, 
> Tassilo 
>

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Tassilo Horn]

Alice  writes:

> I didn't know that macros can do that!

Then you might want to have a look at `macroexpand-1` and `macroexpand`
from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
clojure.tools.macro.

Bye,
Tassilo

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Mikera]

On Monday, 5 August 2013 09:40:04 UTC+1, Korny wrote:

> Agree that :use should be deprecated, mostly as it's quite a barrier to 
> folks new to the language that you need to know 3 different parts of the ns 
> macro before you start.
>
I really don't think :use was ever a significant problem for newcomers: 
it's fairly obvious what it does if you come from another language that has 
similar package-importing constructs. The majority of other languages 
behave more like "use" than "require".

To me the things that make Clojure namespace handling a nightmare for 
beginners are:
- Bad error messages (no.1 problem!)
- Confusion with keywords vs. symbols (why ":use" in ns declarations vs 
"use" at the repl?)
- Confusion about quoting and when / where it is needed (again compared 
with "use" at the REPL)
- Confusion about when you should use lists vs. vectors vs symbols etc., 
and how this interacts with the extra magic syntax like ":as"
- Problems with circular loading of namespaces (and how this affects your 
code structure)
 
I count myself as someone who was quite confused by all these things 
initially, but I never had a problem understanding ":use" as a concept.

>  However "objectively bad" is strong language indeed. ":refer :all" is 
> vital anywhere you want a DSL - if using something like Korma, for example, 
> you have 3 options :
>
> 1. Use :as and fill your code with ugly things like "(k/select user 
> (k/where {:name [k/like " fred"]}) 
>
> 2. Use ":refer [select where like..." and almost every other symbol in 
> Korma - might be ok if you have a perfect IDE, but still needlessly verbose 
>
> 3. Use ":refer :all". It's perfectly fine, IMHO, when used responsibly.
>
Absolutely agreed: method 3 is a decent approach for DSL scenarios. 

This is why I am in favour of keeping ":use" for such situations. There's 
no value in making a breaking change that removes a helpful syntactical 
feature (aside from wasting the time of people who like ":use", it will 
just make namespaces even more verbose and it will invalidate a lot of 
tutorials / example code which I don't think is very welcoming to newcomers 
either).

For example, which is easier to explain to a newcomer:

(ns foo
  (:use my.dsl)
  (:require [some.library :as bar])
  (:import baz.java.Class))

(ns foo
  (:require [my.dsl :refer :all])
  (:require [some.library :as bar])
  (:import baz.java.Class))

The second version is more verbose, has more "magic keywords" (count 
them!), and is IMHO somewhat confusing in the sense that you are using 
":require" to do two very different things. ":use" is a simpler and more 
concise syntax for what the ns declarations above are trying to express 
(and has the advantage of consistency with "use" at the REPL).

Reductio ad absurdum: If we take the logic of deprecating ":use" and 
overloading ":require" to its logical conclusion, surely we should also 
deprecate ":import" and replace it with something like (:require 
[:java-package baz.java :java-classes [Class]])? Replacing ":import" in 
this way would also simplify ns declarations and make things easier for 
newcomers, right? :-)
 

>  - Korny 
>  On 5 Aug 2013 09:09, "Anthony Grimes" > 
> wrote:
>
>> I can't think of a single good reason to not deprecate :use. :require can 
>> do everything :use could do now.
>>
>> This isn't about whether or not (:use ..) without :only is bad. I'd go as 
>> far as to say that outside of test files (and sometimes not even those) and 
>> repl sessions, :use without :only is objectively bad. Not much 
>> justification you can give me that'll make it unbad. But that isn't what 
>> this is about. Deprecating :use doesn't make doing the aforementioned bad 
>> thing impossible, and :refer :all was added to require for that specific 
>> purpose. :require still lets you do bad things if you really want to. All 
>> we're doing by deprecating :use is removing cruft and making things less 
>> complicated for new people. We currently have two things, and one of them 
>> does all the things the other one does and more, yet we still have both of 
>> them.
>>
>> Just my $0.02.
>>
>> On Tuesday, July 23, 2013 8:50:50 AM UTC-7, Greg wrote:
>>>
>>> I think I read somewhere that :use is no longer encouraged, but I could 
>>> be mistaken. 
>>>
>>> From what I've read, it seems like most people agree that Clojure has 
>>> too many ways of including/importing/**referencing/requiring/using 
>>> things: 
>>>
>>> http://blog.8thlight.com/**colin-jones/2010/12/05/**
>>> clojure-libs-and-namespaces-**require-use-import-and-ns.html
>>>  
>>>
>>> The above gives a very nice explanation of all the various difference, 
>>> but it also acknowledges their complexity. 
>>>
>>> Since :use uses :require, and since :require can do everything that :use 
>>> can, can we simplify Clojure programming a bit for newcomers by deprecating 
>>> the use of :use? T

Re: Can we please deprecate the :use directive ?

[Mikera]

On Monday, 5 August 2013 11:35:22 UTC+1, Phillip Lord wrote:

> Anthony Grimes > writes: 
> > I can't think of a single good reason to not deprecate :use. :require 
> can 
> > do everything :use could do now. 
>
> Wait for it, wait for it 
>
> > This isn't about whether or not (:use ..) without :only is bad. I'd go 
> as 
> > far as to say that outside of test files (and sometimes not even those) 
> and 
> > repl sessions, :use without :only is objectively bad. 
>
> Yeah, you see, you can think of a single good reason, although you then 
> contradict yourself just to make it clear that it's not the case. 
>
> I mean, is there really any good reason why namespace qualifing 
> "deftest" should be necessary. Reason -- it's familiar and there are not 
> that many functions in clojure.test. 
>
> Another good reason, I have given before. I have written hundreds of 
> lines of code, with *no* calls at all to clojure.core, and lots to my 
> own library. Why under these circumstances is using clojure.core by 
> default and requiring my own library conducive to clear code? 
>
>
> > Not much justification you can give me that'll make it unbad. But that 
> > isn't what this is about. Deprecating :use doesn't make doing the 
> > aforementioned bad thing impossible, and :refer :all was added to 
> > require for that specific purpose. :require still lets you do bad 
> > things if you really want to. All we're doing by deprecating :use is 
> > removing cruft and making things less complicated for new people. We 
> > currently have two things, and one of them does all the things the 
> > other one does and more, yet we still have both of them. 
>
>
> Essentially, there are four things that can be done here. You can make 
> a function available (require), you make it usable by it's name (use), 
> you can make it available by it's namespace (refer), or you can make it 
> available to another name (aliasing). 
>

+1 to this - different operations deserve different names.

I'd add that there are many situations, especially when using DSLs, where 
you don't really want your code cluttered with aliases. It's just 
unnecessary noise - what you want to do is set up your namespace and have 
the relevant functions directly available as appropriate for you domain.

Aliases can also get problematic when you have to manage code that starts 
to have multiple aliases defined differently in different places. It makes 
refactoring / transferring code between namespaces much more fiddly, 
especially when code that used one alias in one namespace needs to be 
converted to use a different alias in another namespaces (also, aliases can 
collide too.).

If you don't like"use" then just don't put it in your own code. But 
removing helpful existing functionality that many people have in their code 
bases as a breaking change just because some other people don't want to use 
it is bad language design IMHO.
 

>
> The changes suggested do nothing toward reducing these things. As you 
> say, you will still able to do all of them. New people will find be 
> introduced to "use" in the repl and find no equivalent in the ns 
> directive. And lots of people will have to replace ":use" directives 
> with something else which does the same, but is longer. 

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Mikera]

On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:

> The only time I've seen :as lead to ugly code was when it was in a DSL 
> that would probably have been nicer to use if it was a data-based DSL like 
> Hiccup rather than code-based.
>

It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
e.g.

(mat/dot (ops/+ [1 2 3] 1) (ops/- [1 2 3] 1))

vs:

(dot (+ [1 2 3] 1) (- [1 2 3] 1))

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Stefan Kamphausen]

On Monday, August 5, 2013 2:13:02 PM UTC+2, Mikera wrote:
>
>
> To me the things that make Clojure namespace handling a nightmare for 
> beginners are:
> - Bad error messages (no.1 problem!)
> - Confusion with keywords vs. symbols (why ":use" in ns declarations vs 
> "use" at the repl?)
> - Confusion about quoting and when / where it is needed (again compared 
> with "use" at the REPL)
> - Confusion about when you should use lists vs. vectors vs symbols etc., 
> and how this interacts with the extra magic syntax like ":as"
> - Problems with circular loading of namespaces (and how this affects your 
> code structure)
>

well summarized. 

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Timothy Baldridge]

Your macro is incorrect. Notice what happens to un-namespaced symbols
inside a syntax quote:

(ns 'user)
(macroexpand `(foo))

=>(user/foo)

So your use of >! is getting translated into mynamespace/>!. Core.async
sees your macro and expands it, it just doesn't condsider mynamespace/>! to
be a put! call. Instead it sees it as any other function.

To get this to work the way you want, you need to do one of the following

`(~'>! c 42)

or

`(clojure.core.async/>! c 42)

Or, if you've done the following

(ns user
  (require [clojure.core.async :as async))

Then you can do this:

`(async/>! c 42)

Timothy Baldridge


On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:

> Alice  writes:
>
> > I didn't know that macros can do that!
>
> Then you might want to have a look at `macroexpand-1` and `macroexpand`
> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
> clojure.tools.macro.
>
> Bye,
> Tassilo
>
> --
> --
> 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/groups/opt_out.
>
>
>


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

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

Re: core.async: macro and visibilities of async operations

[Alice]

I've used those as a debugging tool, and never thought about using it 
inside a macro.

On Monday, August 5, 2013 8:52:56 PM UTC+9, Tassilo Horn wrote:
>
> Alice > writes: 
>
> > I didn't know that macros can do that! 
>
> Then you might want to have a look at `macroexpand-1` and `macroexpand` 
> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from 
> clojure.tools.macro. 
>
> Bye, 
> Tassilo 
>

-- 
-- 
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/groups/opt_out.

[ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Chas Emerick]

As you might know, I've been tinkering with an easier-to-use variant of 
ClojureScript's browser-REPL for some time.  I've finally wrapped that up into 
its own project, Austin:

https://github.com/cemerick/austin

Everything you need to know is there.  The tl;dr is:

1. You can have a ClojureScript REPL running for your project in ~10 seconds 
(backed by phantomjs by default, but it's easy to wire up any other browser 
runtime, headless or GUI).

2. Setting up a ClojureScript REPL where your app's front-end initiates the 
REPL connection is _nearly_ as easy, and the same mechanism works whether 
you're running one REPL or ten across one or many projects without touching or 
worrying about :port configuration, etc.

I've only just started documenting and adding higher-level convenience features 
and APIs to Austin, so your feedback and contributions are most welcome.

Have fun!

Cheers,

- Chas

-- 
-- 
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/groups/opt_out.

Re: [ANN] core.typed 0.1.19 - core.async support

[Ambrose Bonnaire-Sergeant]

This release didn't quite go as planned. While trying release core.typed
without
a core.async dependency I managed to break support for core.async.

Fix coming.

Thanks,
Ambrose


On Sun, Aug 4, 2013 at 12:52 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> This should be exciting news for some, and perhaps the last reason
> to use Go for others ;)
>
> core.typed now includes support for core.async.
>
> - typed core.async 
> examples
> .
> - companion 
> namespace
>
> There's been some guessing about the types, I need feedback concerning
> their correctness and utility!
>
> Some other interesting things happened in this release. For the fully
> story see the 
> changelog
> .
>
> Enjoy!
> Ambrose
>

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Alice]

I'm not sure I understand your point. Syntax-quote fully qualifies 
unqualified symbols with the current namespace, so it shouldn't be a 
problem as long as I don't redefine the >! in the file that defines the 
macro. On the other hand, ~'>! would be dangerous because you don't know 
what it will be evaluated to in the user's namespace.

On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>
> Your macro is incorrect. Notice what happens to un-namespaced symbols 
> inside a syntax quote:
>
> (ns 'user)
> (macroexpand `(foo))
>
> =>(user/foo)
>
> So your use of >! is getting translated into mynamespace/>!. Core.async 
> sees your macro and expands it, it just doesn't condsider mynamespace/>! to 
> be a put! call. Instead it sees it as any other function. 
>
> To get this to work the way you want, you need to do one of the following
>
> `(~'>! c 42)
>
> or
>
> `(clojure.core.async/>! c 42)
>
> Or, if you've done the following
>
> (ns user 
>   (require [clojure.core.async :as async))
>
> Then you can do this:
>
> `(async/>! c 42)
>
> Timothy Baldridge
>
>
> On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  >wrote:
>
>> Alice > writes:
>>
>> > I didn't know that macros can do that!
>>
>> Then you might want to have a look at `macroexpand-1` and `macroexpand`
>> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
>> clojure.tools.macro.
>>
>> Bye,
>> Tassilo
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: core.async: macro and visibilities of async operations

[Timothy Baldridge]

Right, so if syntax quote fully qualifies unqualified symbols with the
current namespace, what good is user/>! to core.async? It has no clue that
you want that to be a put and not something else. So yes, either async/>!
or a fully qualified symbol is what you want here.

Timothy Baldridge


On Mon, Aug 5, 2013 at 7:40 AM, Alice  wrote:

> I'm not sure I understand your point. Syntax-quote fully qualifies
> unqualified symbols with the current namespace, so it shouldn't be a
> problem as long as I don't redefine the >! in the file that defines the
> macro. On the other hand, ~'>! would be dangerous because you don't know
> what it will be evaluated to in the user's namespace.
>
>
> On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>
>> Your macro is incorrect. Notice what happens to un-namespaced symbols
>> inside a syntax quote:
>>
>> (ns 'user)
>> (macroexpand `(foo))
>>
>> =>(user/foo)
>>
>> So your use of >! is getting translated into mynamespace/>!. Core.async
>> sees your macro and expands it, it just doesn't condsider mynamespace/>! to
>> be a put! call. Instead it sees it as any other function.
>>
>> To get this to work the way you want, you need to do one of the following
>>
>> `(~'>! c 42)
>>
>> or
>>
>> `(clojure.core.async/>! c 42)
>>
>> Or, if you've done the following
>>
>> (ns user
>>   (require [clojure.core.async :as async))
>>
>> Then you can do this:
>>
>> `(async/>! c 42)
>>
>> Timothy Baldridge
>>
>>
>> On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:
>>
>>> Alice  writes:
>>>
>>> > I didn't know that macros can do that!
>>>
>>> Then you might want to have a look at `macroexpand-1` and `macroexpand`
>>> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
>>> clojure.tools.macro.
>>>
>>> Bye,
>>> Tassilo
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

Re: core.async: macro and visibilities of async operations

[Alice]

I didn't have to fully qualify >! because I referred it using :refer. I'm 
Sorry if that was not clear.

On Monday, August 5, 2013 10:45:16 PM UTC+9, tbc++ wrote:
>
> Right, so if syntax quote fully qualifies unqualified symbols with the 
> current namespace, what good is user/>! to core.async? It has no clue that 
> you want that to be a put and not something else. So yes, either async/>! 
> or a fully qualified symbol is what you want here. 
>
> Timothy Baldridge
>
>
> On Mon, Aug 5, 2013 at 7:40 AM, Alice >wrote:
>
>> I'm not sure I understand your point. Syntax-quote fully qualifies 
>> unqualified symbols with the current namespace, so it shouldn't be a 
>> problem as long as I don't redefine the >! in the file that defines the 
>> macro. On the other hand, ~'>! would be dangerous because you don't know 
>> what it will be evaluated to in the user's namespace.
>>
>>
>> On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>>
>>> Your macro is incorrect. Notice what happens to un-namespaced symbols 
>>> inside a syntax quote:
>>>
>>> (ns 'user)
>>> (macroexpand `(foo))
>>>
>>> =>(user/foo)
>>>
>>> So your use of >! is getting translated into mynamespace/>!. Core.async 
>>> sees your macro and expands it, it just doesn't condsider mynamespace/>! to 
>>> be a put! call. Instead it sees it as any other function. 
>>>
>>> To get this to work the way you want, you need to do one of the following
>>>
>>> `(~'>! c 42)
>>>
>>> or
>>>
>>> `(clojure.core.async/>! c 42)
>>>
>>> Or, if you've done the following
>>>
>>> (ns user 
>>>   (require [clojure.core.async :as async))
>>>
>>> Then you can do this:
>>>
>>> `(async/>! c 42)
>>>
>>> Timothy Baldridge
>>>
>>>
>>> On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:
>>>
 Alice  writes:

 > I didn't know that macros can do that!

 Then you might want to have a look at `macroexpand-1` and `macroexpand`
 from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
 clojure.tools.macro.

 Bye,
 Tassilo

 --
 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@**googlegroups.com

 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@**googlegroups.com.

 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .



>>>
>>>
>>> -- 
>>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>>> zero–they had no way to indicate successful termination of their C 
>>> programs.”
>>> (Robert Firth) 
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: Can we please deprecate the :use directive ?

[Greg]

> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
> e.g.

Agreed. It's nice that :require :refer :all is available for such instances, 
isn't it?

-Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 8:22 AM, Mikera  wrote:

> On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:
> The only time I've seen :as lead to ugly code was when it was in a DSL that 
> would probably have been nicer to use if it was a data-based DSL like Hiccup 
> rather than code-based.
> 
> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
> e.g.
> 
> (mat/dot (ops/+ [1 2 3] 1) (ops/- [1 2 3] 1))
> 
> vs:
> 
> (dot (+ [1 2 3] 1) (- [1 2 3] 1))
> 
> -- 
> -- 
> 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/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can we please deprecate the :use directive ?

[Greg]

>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
> 
> Agreed. It's nice that :require :refer :all is available for such instances, 
> isn't it?

* Or for the more gentlemanly and considerate among us, just (:require ... 
:refer [+ - / *]).

-Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 10:04 AM, Greg  wrote:

>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
> 
> Agreed. It's nice that :require :refer :all is available for such instances, 
> isn't it?
> 
> -Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 8:22 AM, Mikera  wrote:
> 
>> On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:
>> The only time I've seen :as lead to ugly code was when it was in a DSL that 
>> would probably have been nicer to use if it was a data-based DSL like Hiccup 
>> rather than code-based.
>> 
>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
>> 
>> (mat/dot (ops/+ [1 2 3] 1) (ops/- [1 2 3] 1))
>> 
>> vs:
>> 
>> (dot (+ [1 2 3] 1) (- [1 2 3] 1))
>> 
>> -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Incanter 1.5.2 has been released

[Jakub Holy]

I can see that http://liebke.github.io/incanter/core-api.html still reads 
"Incanter 1.5.1" so either it hasn't been long enough since you tagged it 
or something else must be done to update the docs.

Thank you!

On Monday, August 5, 2013 8:10:38 AM UTC+2, Alex Ott wrote:
>
> Ooops, completely forgot to do this - it's done now
>
> thank you
>
>
> On Mon, Aug 5, 2013 at 3:55 AM, Tom Faulhaber 
> 
> > wrote:
>
>> Thanks for keeping the ball rolling, Alex. We appreciate it very much!
>>
>> Could you tag the release on github so that autodoc will build for it 
>> correctly? 
>>
>> Thanks,
>>
>> Tom
>>
>>
>> On Sunday, August 4, 2013 11:20:07 AM UTC-7, Alex Ott wrote:
>>>
>>> Hi all
>>>
>>> I've just pushed new release of Incanter to Clojars. This is mostly 
>>> bugfix release. More information is at http://data-sorcery.org/2013/**
>>> 08/04/incanter-1-5-2-bugfix-**release/
>>>
>>> -- 
>>> With best wishes,Alex Ott
>>> http://alexott.net/
>>> Twitter: alexott_en (English), alexott (Russian)
>>> Skype: alex.ott 
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
> Skype: alex.ott 
>

-- 
-- 
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/groups/opt_out.

Re: core.async: macro and visibilities of async operations

[Timothy Baldridge]

This works fine on my box:

foo=> (ns foo (require [clojure.core.async :refer [go !!]]))
nil
foo=> (defmacro foo
 #_=>   [c]
 #_=>   `(

foo=> (let [c (chan)]
 #_=>   (go (prn (foo c)))
 #_=>   (>!! c :hi))
:hi
nil
foo=>

Timothy Baldridge


On Mon, Aug 5, 2013 at 7:59 AM, Alice  wrote:

> I didn't have to fully qualify >! because I referred it using :refer. I'm
> Sorry if that was not clear.
>
>
> On Monday, August 5, 2013 10:45:16 PM UTC+9, tbc++ wrote:
>
>> Right, so if syntax quote fully qualifies unqualified symbols with the
>> current namespace, what good is user/>! to core.async? It has no clue that
>> you want that to be a put and not something else. So yes, either async/>!
>> or a fully qualified symbol is what you want here.
>>
>> Timothy Baldridge
>>
>>
>> On Mon, Aug 5, 2013 at 7:40 AM, Alice  wrote:
>>
>>> I'm not sure I understand your point. Syntax-quote fully qualifies
>>> unqualified symbols with the current namespace, so it shouldn't be a
>>> problem as long as I don't redefine the >! in the file that defines the
>>> macro. On the other hand, ~'>! would be dangerous because you don't know
>>> what it will be evaluated to in the user's namespace.
>>>
>>>
>>> On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>>>
 Your macro is incorrect. Notice what happens to un-namespaced symbols
 inside a syntax quote:

 (ns 'user)
 (macroexpand `(foo))

 =>(user/foo)

 So your use of >! is getting translated into mynamespace/>!. Core.async
 sees your macro and expands it, it just doesn't condsider mynamespace/>! to
 be a put! call. Instead it sees it as any other function.

 To get this to work the way you want, you need to do one of the
 following

 `(~'>! c 42)

 or

 `(clojure.core.async/>! c 42)

 Or, if you've done the following

 (ns user
   (require [clojure.core.async :as async))

 Then you can do this:

 `(async/>! c 42)

 Timothy Baldridge


 On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:

> Alice  writes:
>
> > I didn't know that macros can do that!
>
> Then you might want to have a look at `macroexpand-1` and `macroexpand`
> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
> clojure.tools.macro.
>
> Bye,
> Tassilo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@**googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/**group**/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@**googlegroups.com.
>
> For more options, visit 
> https://groups.google.com/**grou**ps/opt_out
> .
>
>
>


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

>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.g

Re: core.async: macro and visibilities of async operations

[Tassilo Horn]

Alice  writes:

> I've used those as a debugging tool, and never thought about using it
> inside a macro.

For almost all macros you'll probably ever define, you don't need to
drive macro expansion yourself.  You need it only if you have to
transform code that might be anywhere inside the macro's arguments,
possibly only created by nested macro calls, like !> and !< in case of
`go`.

I had a similar (but simpler) scenario once, where I had some macro
defining a rule in terms of a pattern and an action.  Such a rule could
be applied like a function, but it could also be applied as a test where
it wouldn't perform its action but just return a thunk encapsulating the
action.  But that encapsulation with a thunk cannot work if the action
uses `recur` to call the rule function recursively.  So in that case,
my macro had to replace recurs with normal recursive calls in the
"execute as test" case.

Bye,
Tassilo

> On Monday, August 5, 2013 8:52:56 PM UTC+9, Tassilo Horn wrote:
>>
>> Alice > writes: 
>>
>> > I didn't know that macros can do that! 
>>
>> Then you might want to have a look at `macroexpand-1` and `macroexpand` 
>> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from 
>> clojure.tools.macro. 
>>
>> Bye, 
>> Tassilo 
>>
>
> -- 

-- 
-- 
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/groups/opt_out.

Re: Incanter 1.5.2 has been released

[Alex Ott]

I don't know, how often the documentation is regenerated - I think, that
Tom can clarify this...


On Mon, Aug 5, 2013 at 3:19 PM, Jakub Holy  wrote:

> I can see that http://liebke.github.io/incanter/core-api.html still reads
> "Incanter 1.5.1" so either it hasn't been long enough since you tagged it
> or something else must be done to update the docs.
>
> Thank you!
>
>
> On Monday, August 5, 2013 8:10:38 AM UTC+2, Alex Ott wrote:
>
>> Ooops, completely forgot to do this - it's done now
>>
>> thank you
>>
>>
>> On Mon, Aug 5, 2013 at 3:55 AM, Tom Faulhaber wrote:
>>
>>> Thanks for keeping the ball rolling, Alex. We appreciate it very much!
>>>
>>> Could you tag the release on github so that autodoc will build for it
>>> correctly?
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>>
>>> On Sunday, August 4, 2013 11:20:07 AM UTC-7, Alex Ott wrote:

 Hi all

 I've just pushed new release of Incanter to Clojars. This is mostly
 bugfix release. More information is at http://data-sorcery.org/2013/**0
 **8/04/incanter-1-5-2-bugfix-**rel**ease/

 --
 With best wishes,Alex Ott
 http://alexott.net/
 Twitter: alexott_en (English), alexott (Russian)
 Skype: alex.ott

>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> With best wishes,Alex Ott
>> http://alexott.net/
>> Twitter: alexott_en (English), alexott (Russian)
>> Skype: alex.ott
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Incanter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to incanter+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Phillip Lord]

Greg  writes:
>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
>
> Agreed. It's nice that :require :refer :all is available for such instances, 
> isn't it?

Which leads to the crux of the question.

Given that the functionality is there, and that you agree that it is
useful, can you please therefore explain why you think a breaking change
to ns is a good thing to remove something that we are still going to be
able to do, but in a more verbose way.

Please also explain at the same time, why (use 'core.matrix) remains
clear and why this should not change to "(require 'core.matrix :refer
:all)".


The namespace declaration is too complex. The existence of ":use" is not
what causes this.

Phil

-- 
-- 
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/groups/opt_out.

Re: [ANN] core.typed 0.1.19 - core.async support

[Ambrose Bonnaire-Sergeant]

0.1.20 is cut, the examples should work.

[org.clojure/core.typed "0.1.20"]

Also, you probably need to have (clojure.core.typed/typed-deps
clojure.core.typed.async) just below your ns form. core.typed doesn't seem
to infer the companion namespace sometimes.

Thanks,
Ambrose

On Mon, Aug 5, 2013 at 9:29 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> This release didn't quite go as planned. While trying release core.typed
> without
> a core.async dependency I managed to break support for core.async.
>
> Fix coming.
>
> Thanks,
> Ambrose
>
>
> On Sun, Aug 4, 2013 at 12:52 PM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
>
>> Hi,
>>
>> This should be exciting news for some, and perhaps the last reason
>> to use Go for others ;)
>>
>> core.typed now includes support for core.async.
>>
>> - typed core.async 
>> examples
>> .
>> - companion 
>> namespace
>>
>> There's been some guessing about the types, I need feedback concerning
>> their correctness and utility!
>>
>> Some other interesting things happened in this release. For the fully
>> story see the 
>> changelog
>> .
>>
>> Enjoy!
>> Ambrose
>>
>
>

-- 
-- 
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/groups/opt_out.

Clojars "Could not transfer artifact... ReasonPhrase: Forbidden"

[Timothy Washington]

Hi all,

I'm having problems deploying a project to Clojars. I've just reset my
Clojars i) password and ii) SSH public key. And now, from my development
system, I want to push my project. Yet I get the below error: "*Could not
transfer artifact... ReasonPhrase: Forbidden*". I'm very sure that the
password is correct, and that the SSH keys match on my system, and clojars.
Are there any other gymnastics that has to happen?


*$ ~/Projects/stefon$ lein deploy clojars*
*No credentials found for clojars*
*See `lein help deploy` for how to configure credentials.*
*Username: xxx*
*Password: *
*Wrote /home/webkell/Projects/stefon/pom.xml*
*Created
/home/webkell/Projects/stefon/target/provided/stefon-0.1.0-SNAPSHOT.jar*
*Retrieving stefon/stefon/0.1.0-SNAPSHOT/maven-metadata.xml (1k)*
*from https://clojars.org/repo/*
*Sending stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom
(4k)*
*to https://clojars.org/repo/*
*Could not transfer artifact stefon:stefon:pom:0.1.0-20130805.150327-2
from/to clojars (https://clojars.org/repo/): Access denied to:
https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom,
ReasonPhrase: Forbidden.*
*Sending stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.jar
(7k)*
*to https://clojars.org/repo/*
*Could not transfer artifact stefon:stefon:jar:0.1.0-20130805.150327-2
from/to clojars (https://clojars.org/repo/): Access denied to:
https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.jar,
ReasonPhrase: Forbidden.*
*Failed to deploy artifacts: Could not transfer artifact
stefon:stefon:pom:0.1.0-20130805.150327-2 from/to clojars (
https://clojars.org/repo/): Access denied to:
https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom,
ReasonPhrase: Forbidden.*



Thanks

Tim Washington
Interruptsoftware.ca / Bkeeping.com

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Greg]

This email contains a proposal for a way to get rid of at-least the following 
forms from the (ns) declaration:

- :refer-clojure
- :use
- :import

See below...

> The namespace declaration is too complex. The existence of ":use" is not
> what causes this.


I agree that it is not the *sole* cause, but I do believe that it is a 
significant part of the problem.

> can you please therefore explain why you think a breaking change
> to ns is a good thing to remove something that we are still going to be
> able to do, but in a more verbose way.

The 'ns' declaration is complex because there are too many ways to do 
essentially the same thing. "use" is one of those ways that is completely 
unnecessary and creates unnecessary complexity.

Clojure's documentation also contributes to this problem, but in some ways it's 
a victim of the poor design of the 'ns' declaration. Just look at this monster:

user=> (doc ns)
-
clojure.core/ns
([name docstring? attr-map? references*])
Macro
  Sets *ns* to the namespace named by name (unevaluated), creating it
  if needed.  references can be zero or more of: (:refer-clojure ...)
  (:require ...) (:use ...) (:import ...) (:load ...) (:gen-class)
  with the syntax of refer-clojure/require/use/import/load/gen-class
  respectively, except the arguments are unevaluated and need not be
  quoted. (:gen-class ...), when supplied, defaults to :name
  corresponding to the ns name, :main true, :impl-ns same as ns, and
  :init-impl-ns true. All options of gen-class are
  supported. The :gen-class directive is ignored when not
  compiling. If :gen-class is not supplied, when compiled only an
  nsname__init.class will be generated. If :refer-clojure is not used, a
  default (refer 'clojure) is used.  Use of ns is preferred to
  individual calls to in-ns/require/use/import:

  (ns foo.bar
(:refer-clojure :exclude [ancestors printf])
(:require (clojure.contrib sql combinatorics))
(:use (my.lib this that))
(:import (java.util Date Timer Random)
 (java.sql Connection Statement)))


The above does not explain completely how to use 'ns'. You have to read the 
documentation for the syntax of all of the other forms its supports.

Deprecating :use would be a significant step in reducing the complexity of the 
'ns' declaration, and improving the readability of Clojure's code. It would be 
one less piece to the monster.

There's a great quote by I don't remember who (Apple-related?), that to create 
something truly great, you have to keep removing all the unnecessary bits till 
there's nothing unnecessary left to remove. Something like that (if anyone 
knows the quote I'm talking about, please share).

This complexity isn't necessary.

Perhaps I'm mistaken, but I don't see why with a little bit of compiler 
intelligence, we can't convert this:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:use core.matrix
[ring.adapter.jetty :only (run-jetty)]
[ring.middleware.file :only (wrap-file)]
[ring.middleware.file-info :only (wrap-file-info)]
[ring.middleware.stacktrace :only (wrap-stacktrace)]
[ring.util.response :only (file-response)])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

Into this:

(ns one.fresh-server
  (:require [clojure.core :refer [ancestors printf]]
[core.matrix :refer :all]
[ring.adapter.jetty :refer [run-jetty]]
[ring.middleware.file :refer [wrap-file]]
[ring.middleware.file-info :refer [wrap-file-info]]
[ring.middleware.stacktrace :refer [wrap-stacktrace]]
[ring.util.response :refer [file-response]]
[one.reload :as-ns]
[one.middleware :as-ns]
[net.cgrand.enlive-html :as html]
[org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
[java.io.File :as-class]))

Ta da!

There we've removed the unnecessary :use, :import, and :refer-clojure forms, 
and added :as-ns and :as-class shortcuts. Require now supports both Java 
Classes and Clojure Namespaces.

We've removed practically all the complexity! The only complexity remaining are 
the keyword-options to available in the :require clauses, but we already had 
those before.

> Please also explain at the same time, why (use 'core.matrix) remains
> clear and why this should not change to "(require 'core.matrix :refer
> :all)".

I must have missed this part of the thread. I did not say it shouldn't maybe 
someone else did. I'm for deprecating "use" completely, while retaining its 
abilities through "require".

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 10:52 AM, Phillip Lord  wrote:

> Greg  writes:
>>> It's pretty ugly to use aliases for numeric

Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Chas Emerick]

On Aug 5, 2013, at 9:21 AM, Chas Emerick wrote:

> As you might know, I've been tinkering with an easier-to-use variant of 
> ClojureScript's browser-REPL for some time.  I've finally wrapped that up 
> into its own project, Austin:
> 
>   https://github.com/cemerick/austin
> 
> Everything you need to know is there.  The tl;dr is:
> 
> 1. You can have a ClojureScript REPL running for your project in ~10 seconds 
> (backed by phantomjs by default, but it's easy to wire up any other browser 
> runtime, headless or GUI).
> 
> 2. Setting up a ClojureScript REPL where your app's front-end initiates the 
> REPL connection is _nearly_ as easy, and the same mechanism works whether 
> you're running one REPL or ten across one or many projects without touching 
> or worrying about :port configuration, etc.
> 
> I've only just started documenting and adding higher-level convenience 
> features and APIs to Austin, so your feedback and contributions are most 
> welcome.
> 
> Have fun!
> 
> Cheers,
> 
> - Chas

BTW, I put a screencast demonstrating Austin over here:

http://www.youtube.com/watch?v=a1Bs0pXIVXc

- Chas

-- 
-- 
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/groups/opt_out.

[ANN] Clotilde is Linda in Clojure.

[François DE SERRES]

 

Hi, 

9 months and half a dozen books later, here's my first (hopefully) useful 
Clojure program: https://github.com/justiniac/clotilde

Clotilde implements the basic ops of the Linda process coordination 
language: http://en.wikipedia.org/wiki/Linda_(coordination_language)

More on the topic: 
http://www.sciencedirect.com/science/article/pii/S0890540199928237
I'd be so happy to get feedback ;o) 
Also, I am now in search of a (possibly NP complex) short Linda program to 
translate into Clotilde.
Mucho thankies!
--
François

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Greg]

* That email was just an idea to explore, not perfection.

Also, this is a mistake:

 (:require [clojure.core :refer [ancestors printf]]

Should read something like:

 (:require [clojure.core :refer-except [ancestors printf]]

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 12:00 PM, Greg  wrote:

> This email contains a proposal for a way to get rid of at-least the following 
> forms from the (ns) declaration:
> 
> - :refer-clojure
> - :use
> - :import
> 
> See below...
> 
>> The namespace declaration is too complex. The existence of ":use" is not
>> what causes this.
> 
> 
> I agree that it is not the *sole* cause, but I do believe that it is a 
> significant part of the problem.
> 
>> can you please therefore explain why you think a breaking change
>> to ns is a good thing to remove something that we are still going to be
>> able to do, but in a more verbose way.
> 
> The 'ns' declaration is complex because there are too many ways to do 
> essentially the same thing. "use" is one of those ways that is completely 
> unnecessary and creates unnecessary complexity.
> 
> Clojure's documentation also contributes to this problem, but in some ways 
> it's a victim of the poor design of the 'ns' declaration. Just look at this 
> monster:
> 
> user=> (doc ns)
> -
> clojure.core/ns
> ([name docstring? attr-map? references*])
> Macro
>   Sets *ns* to the namespace named by name (unevaluated), creating it
>   if needed.  references can be zero or more of: (:refer-clojure ...)
>   (:require ...) (:use ...) (:import ...) (:load ...) (:gen-class)
>   with the syntax of refer-clojure/require/use/import/load/gen-class
>   respectively, except the arguments are unevaluated and need not be
>   quoted. (:gen-class ...), when supplied, defaults to :name
>   corresponding to the ns name, :main true, :impl-ns same as ns, and
>   :init-impl-ns true. All options of gen-class are
>   supported. The :gen-class directive is ignored when not
>   compiling. If :gen-class is not supplied, when compiled only an
>   nsname__init.class will be generated. If :refer-clojure is not used, a
>   default (refer 'clojure) is used.  Use of ns is preferred to
>   individual calls to in-ns/require/use/import:
> 
>   (ns foo.bar
> (:refer-clojure :exclude [ancestors printf])
> (:require (clojure.contrib sql combinatorics))
> (:use (my.lib this that))
> (:import (java.util Date Timer Random)
>  (java.sql Connection Statement)))
> 
> 
> The above does not explain completely how to use 'ns'. You have to read the 
> documentation for the syntax of all of the other forms its supports.
> 
> Deprecating :use would be a significant step in reducing the complexity of 
> the 'ns' declaration, and improving the readability of Clojure's code. It 
> would be one less piece to the monster.
> 
> There's a great quote by I don't remember who (Apple-related?), that to 
> create something truly great, you have to keep removing all the unnecessary 
> bits till there's nothing unnecessary left to remove. Something like that (if 
> anyone knows the quote I'm talking about, please share).
> 
> This complexity isn't necessary.
> 
> Perhaps I'm mistaken, but I don't see why with a little bit of compiler 
> intelligence, we can't convert this:
> 
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]
> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
> 
> Into this:
> 
> (ns one.fresh-server
>   (:require [clojure.core :refer [ancestors printf]]
> [core.matrix :refer :all]
> [ring.adapter.jetty :refer [run-jetty]]
> [ring.middleware.file :refer [wrap-file]]
> [ring.middleware.file-info :refer [wrap-file-info]]
> [ring.middleware.stacktrace :refer [wrap-stacktrace]]
> [ring.util.response :refer [file-response]]
> [one.reload :as-ns]
> [one.middleware :as-ns]
> [net.cgrand.enlive-html :as html]
> [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
> [java.io.File :as-class]))
> 
> Ta da!
> 
> There we've removed the unnecessary :use, :import, and :refer-clojure forms, 
> and added :as-ns and :as-class shortcuts. Require now supports both Java 
> Classes and Clojure Namespaces.
> 
> We've removed practically all the complexity! The only complexity remaining 
> are the keyword-options to available in the :require clauses, bu

Re: Incanter 1.5.2 has been released

[Tom Faulhaber]

The documentation is, in general, updated automatically when there is a 
github checkin that causes a change to the docs.

However, github doesn't seem to trigger a webhook call when a tag is added, 
so autodoc didn't get called.

I just ran it manually and we're now happily in 1.5.2-land.

Tom

On Monday, August 5, 2013 7:46:24 AM UTC-7, Alex Ott wrote:
>
> I don't know, how often the documentation is regenerated - I think, that 
> Tom can clarify this...
>
>
> On Mon, Aug 5, 2013 at 3:19 PM, Jakub Holy 
> > wrote:
>
>> I can see that http://liebke.github.io/incanter/core-api.html still 
>> reads "Incanter 1.5.1" so either it hasn't been long enough since you 
>> tagged it or something else must be done to update the docs.
>>
>> Thank you!
>>
>>
>> On Monday, August 5, 2013 8:10:38 AM UTC+2, Alex Ott wrote:
>>
>>> Ooops, completely forgot to do this - it's done now
>>>
>>> thank you
>>>
>>>
>>> On Mon, Aug 5, 2013 at 3:55 AM, Tom Faulhaber wrote:
>>>
 Thanks for keeping the ball rolling, Alex. We appreciate it very much!

 Could you tag the release on github so that autodoc will build for it 
 correctly? 

 Thanks,

 Tom


 On Sunday, August 4, 2013 11:20:07 AM UTC-7, Alex Ott wrote:
>
> Hi all
>
> I've just pushed new release of Incanter to Clojars. This is mostly 
> bugfix release. More information is at http://data-sorcery.org/2013/**
> 0**8/04/incanter-1-5-2-bugfix-**rel**ease/
>
> -- 
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
> Skype: alex.ott 
>
  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@**googlegroups.com

 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@**googlegroups.com.

 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .
  
  

>>>
>>>
>>>
>>> -- 
>>> With best wishes,Alex Ott
>>> http://alexott.net/
>>> Twitter: alexott_en (English), alexott (Russian)
>>> Skype: alex.ott 
>>>
>>  -- 
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Incanter" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to incanter+u...@googlegroups.com .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
> Skype: alex.ott 
>

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Greg]

Looking at it again, we don't even need an explicit :require anymore:

(ns one.fresh-server
  "optional doc string goes here"
  [clojure.core :refer-except [ancestors printf]]
  [core.matrix :refer :all]
  [ring.adapter.jetty :refer [run-jetty]]
  [ring.middleware.file :refer [wrap-file]]
  [ring.middleware.file-info :refer [wrap-file-info]]
  [ring.middleware.stacktrace :refer [wrap-stacktrace]]
  [ring.util.response :refer [file-response]]
  [one.reload :as-ns]
  [one.middleware :as-ns]
  [net.cgrand.enlive-html :as html]
  [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
  [java.io.File :as-class])

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 12:10 PM, Greg  wrote:

> * That email was just an idea to explore, not perfection.
> 
> Also, this is a mistake:
> 
>  (:require [clojure.core :refer [ancestors printf]]
> 
> Should read something like:
> 
>  (:require [clojure.core :refer-except [ancestors printf]]
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 12:00 PM, Greg  wrote:
> 
>> This email contains a proposal for a way to get rid of at-least the 
>> following forms from the (ns) declaration:
>> 
>> - :refer-clojure
>> - :use
>> - :import
>> 
>> See below...
>> 
>>> The namespace declaration is too complex. The existence of ":use" is not
>>> what causes this.
>> 
>> 
>> I agree that it is not the *sole* cause, but I do believe that it is a 
>> significant part of the problem.
>> 
>>> can you please therefore explain why you think a breaking change
>>> to ns is a good thing to remove something that we are still going to be
>>> able to do, but in a more verbose way.
>> 
>> The 'ns' declaration is complex because there are too many ways to do 
>> essentially the same thing. "use" is one of those ways that is completely 
>> unnecessary and creates unnecessary complexity.
>> 
>> Clojure's documentation also contributes to this problem, but in some ways 
>> it's a victim of the poor design of the 'ns' declaration. Just look at this 
>> monster:
>> 
>> user=> (doc ns)
>> -
>> clojure.core/ns
>> ([name docstring? attr-map? references*])
>> Macro
>>   Sets *ns* to the namespace named by name (unevaluated), creating it
>>   if needed.  references can be zero or more of: (:refer-clojure ...)
>>   (:require ...) (:use ...) (:import ...) (:load ...) (:gen-class)
>>   with the syntax of refer-clojure/require/use/import/load/gen-class
>>   respectively, except the arguments are unevaluated and need not be
>>   quoted. (:gen-class ...), when supplied, defaults to :name
>>   corresponding to the ns name, :main true, :impl-ns same as ns, and
>>   :init-impl-ns true. All options of gen-class are
>>   supported. The :gen-class directive is ignored when not
>>   compiling. If :gen-class is not supplied, when compiled only an
>>   nsname__init.class will be generated. If :refer-clojure is not used, a
>>   default (refer 'clojure) is used.  Use of ns is preferred to
>>   individual calls to in-ns/require/use/import:
>> 
>>   (ns foo.bar
>> (:refer-clojure :exclude [ancestors printf])
>> (:require (clojure.contrib sql combinatorics))
>> (:use (my.lib this that))
>> (:import (java.util Date Timer Random)
>>  (java.sql Connection Statement)))
>> 
>> 
>> The above does not explain completely how to use 'ns'. You have to read the 
>> documentation for the syntax of all of the other forms its supports.
>> 
>> Deprecating :use would be a significant step in reducing the complexity of 
>> the 'ns' declaration, and improving the readability of Clojure's code. It 
>> would be one less piece to the monster.
>> 
>> There's a great quote by I don't remember who (Apple-related?), that to 
>> create something truly great, you have to keep removing all the unnecessary 
>> bits till there's nothing unnecessary left to remove. Something like that 
>> (if anyone knows the quote I'm talking about, please share).
>> 
>> This complexity isn't necessary.
>> 
>> Perhaps I'm mistaken, but I don't see why with a little bit of compiler 
>> intelligence, we can't convert this:
>> 
>> (ns one.fresh-server
>>   (:refer-clojure :exclude [ancestors printf])
>>   (:use core.matrix
>> [ring.adapter.jetty :only (run-jetty)]
>> [ring.middleware.file :only (wrap-file)]
>> [ring.middleware.file-info :only (wrap-file-info)]
>> [ring.middleware.stacktrace :only (wrap-stacktrace)]
>> [ring.util.response :only (file-response)])
>>   (:require [one.reload :as reload]
>> [one.middleware :as middleware]
>> [net.cgrand.enlive-html :as html])
>>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>>(java.io File
>> 
>> Into this:
>> 
>> (ns one.fresh-server
>>   (:require [clojure.core :refer [ancestors printf]]
>> [core.matrix :refer :all

Re: Can we please deprecate the :use directive ?

[Lee Spector]

On Aug 5, 2013, at 4:40 AM, Korny Sietsma wrote:
> 
> 3. Use ":refer :all". It's perfectly fine, IMHO, when used responsibly.

I agree in principle, but as I mentioned earlier in a related thread, when I 
actually tried to convert my :use instances to :require :refer :all I learned 
(I think!) that this cannot be done without substantially increasing the size 
of the ns declaration.

The problem is that :use allows one to list a bunch of namespaces in one 
declaration reasonably concisely, as in:

(ns use2require.core
   (:use [use2require myfns yourfns]))

while :require :refer :all requires a separate entry (and a separate :refer 
:all) for each namespace, as in:

(ns use2require.core
   (:require [use2require.myfns :refer :all]
 [use2require.yourfns :refer :all]))

or

(ns use2require.core
   (:require [use2require [myfns :refer :all]
  [yourfns :refer :all]]))

Of course it's not a big deal with only two namespaces, but if you have dozens 
then this would be a real escalation in the size of the ns declaration.

Or am I missing something, and maybe there's a more concise way to use :require 
:refer :all that approximates the amount of code required for :use?

FYI the thread in which I previously posted this, and on which several others 
had comments, can be found at:

http://grokbase.com/t/gg/clojure/137v769emd/help-actually-changing-use-to-require-refer-all
 

If I haven't missed something then I'd advocate for an enhancement to :require 
:refer :all that fixes this OR the retention of :use.

 -Lee

-- 
-- 
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/groups/opt_out.

[Proposal] Simplified 'ns' declaration

[Greg]

Branching off of the "Can we please deprecate the :use directive ?" thread, I 
was wondering what the Clojure community thinks of radically simplifying the 
"ns" declaration while keeping all of its power.

Old School:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:use core.matrix
[ring.adapter.jetty :only (run-jetty)]
[ring.middleware.file :only (wrap-file)]
[ring.middleware.file-info :only (wrap-file-info)]
[ring.middleware.stacktrace :only (wrap-stacktrace)]
[ring.util.response :only (file-response)])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

New School:

(ns one.fresh-server
  "optional doc string goes here"
  [clojure.core :refer-except [ancestors printf]]
  [core.matrix :refer :all]
  [ring.adapter.jetty :refer [run-jetty]]
  [ring.middleware.file :refer [wrap-file]]
  [ring.middleware.file-info :refer [wrap-file-info]]
  [ring.middleware.stacktrace :refer [wrap-stacktrace]]
  [ring.util.response :refer [file-response]]
  [one.reload :as-ns]
  [one.middleware :as-ns]
  [net.cgrand.enlive-html :as html]
  [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
  [java.io.File :as-class])

I haven't put enough thought into this as I could, but this seems good enough 
already to kick the ball rolling.

If the above syntax can't be made to support the old school syntax as well, 
another thought would be to create a new name for the declaration, calling it 
"include" or something like that instead of "ns".

Thoughts?

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Lee Spector]

On Aug 5, 2013, at 12:28 PM, Greg wrote:

> Branching off of the "Can we please deprecate the :use directive ?" thread, I 
> was wondering what the Clojure community thinks of radically simplifying the 
> "ns" declaration while keeping all of its power.

Can you build in a way to get :require :refer :all to work on a bunch of 
sub-namespaces together on one line, as one currently can with :use, without 
listing each namespace completely on a separate line with a separate :refer 
:all?

 -Lee

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Mark Engelberg]

On Mon, Aug 5, 2013 at 9:32 AM, Lee Spector  wrote:

> Can you build in a way to get :require :refer :all to work on a bunch of
> sub-namespaces together on one line, as one currently can with :use,
> without listing each namespace completely on a separate line with a
> separate :refer :all?
>


I agree that subnamespaces are important.   Relatedly, I frequently
struggle with the fact that Clojure's import doesn't support wildcards.
When using Java libraries, very frequently the Java tutorials or library
documentation use wildcards to import a whole family of subnamespaces.
It's extremely difficult to use such libraries from Clojure, because there
is no good way to discover from the Java documentation the entire list of
libraries you need to import.

-- 
-- 
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/groups/opt_out.

PoC: Combining Wikidata and Clojure logic programming

[Mingli Yuan]

Hi, folks,

After one night quick work, I had gave a proof-of-concept to demonstrate
the feasibility that we can combine Wikidata and Clojure logic programming
together.

The source code is at here:
https://github.com/mountain/knowledge

An example of an entity:
https://github.com/mountain/knowledge/blob/master/src/entities/albert_einstein.clj

Example of types:
https://github.com/mountain/knowledge/blob/master/src/meta/types.clj

Example of predicates:
https://github.com/mountain/knowledge/blob/master/src/meta/properties.clj

Example of inference:
https://github.com/mountain/knowledge/blob/master/test/knowledge/test.clj

Also we found it is very easy to get any other language version than
English.

Since I am new to Clojure logic programming, I have questions for the way I
take - what will happen when we have millions of triples? Should I take
another approach by using some RDF store?

   - How many memory will it cost?
   - How about the performance?
   - How about the loading process of one million clojure source file or
   java class file?

Hope you can give some helpful comments. Thanks in advance.

Regards,
Mingli

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> Can you build in a way to get :require :refer :all to work on a bunch of 
> sub-namespaces together on one line, as one currently can with :use, without 
> listing each namespace completely on a separate line with a separate :refer 
> :all?

Certainly. I'm not saying this is how the exact syntax would go, but the 
general idea is to rely on the keywords to specify what (and how) you want to 
import stuff:

Instead of:

(ns one.fresh-server
  (:use (core matrix math bs))

You could do something like:

(ns one.fresh-server
  [core :refer-all [matrix math bs]])

By having a single syntax (vectors), it becomes really simple to learn how to 
use the new "ns" (or "ns-include", w/e) declaration. (doc ns) would need to 
spend almost no time on syntax, and just explain the various possible keywords. 
I think this might also make it a lot simpler for editors and IDEs to integrate 
with Clojure.

Summary:

- Just one syntax to know: vectors
- Keyword options handle everything else

Cheers!
- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 12:32 PM, Lee Spector  wrote:

> 
> On Aug 5, 2013, at 12:28 PM, Greg wrote:
> 
>> Branching off of the "Can we please deprecate the :use directive ?" thread, 
>> I was wondering what the Clojure community thinks of radically simplifying 
>> the "ns" declaration while keeping all of its power.
> 
> Can you build in a way to get :require :refer :all to work on a bunch of 
> sub-namespaces together on one line, as one currently can with :use, without 
> listing each namespace completely on a separate line with a separate :refer 
> :all?
> 
> -Lee
> 
> -- 
> -- 
> 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/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can we please deprecate the :use directive ?

[Lee Spector]

On Aug 5, 2013, at 8:15 AM, Mikera wrote:

> On Monday, 5 August 2013 11:35:22 UTC+1, Phillip Lord wrote:
> Anthony Grimes  writes: 
> > I can't think of a single good reason to not deprecate :use. :require can 
> > do everything :use could do now. 
> 
> Wait for it, wait for it 
> 
> > This isn't about whether or not (:use ..) without :only is bad. I'd go as 
> > far as to say that outside of test files (and sometimes not even those) and 
> > repl sessions, :use without :only is objectively bad. 
> 
> Yeah, you see, you can think of a single good reason, although you then 
> contradict yourself just to make it clear that it's not the case. 
> 
> I mean, is there really any good reason why namespace qualifing 
> "deftest" should be necessary. Reason -- it's familiar and there are not 
> that many functions in clojure.test. 
> 
> Another good reason, I have given before. I have written hundreds of 
> lines of code, with *no* calls at all to clojure.core, and lots to my 
> own library. Why under these circumstances is using clojure.core by 
> default and requiring my own library conducive to clear code? 

I think that these are good points and that there are indeed good reasons to 
keep :use or something with equivalent functionality and conciseness (which, as 
far as I can tell, :require :use :all doesn't quite deliver).

More generally, I think we should keep in mind that different Clojure 
programmers work in different programming contexts with different needs and 
priorities.

In my own context it'd actually be best to be able to say (ns foo 
:use-whatever-you-need) and leave it to the system to find things and tell me 
if there are conflicts.

Yes, that would be insane in some contexts, and if I used this thing and then 
wanted to port my code to some other context, like controlling a nuclear power 
plant, then I'd want a utility function something like 
print-explicit-ns-declaration-for-everything-you-need, which I could use to 
produce the mess that I'd then substitute for the concise thing before it goes 
into production, so I could make sure that all of the references were really 
correct, etc.

I don't expect everyone to think this is a good idea in their programming 
contexts, but from where I sit it would really be fantastic. I also don't 
expect anyone to implement this unless they have similar needs and interests 
and time, and I don't expect Clojure to be changed to support anything like 
this. My point is just that the needs and priorities are diverse, and I wish 
people wouldn't be so enthusiastic about deprecating features that are valued 
by others in the community.

 -Lee

-- 
-- 
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/groups/opt_out.

Re: PoC: Combining Wikidata and Clojure logic programming

[David Nolen]

Very interesting. The rel feature is really still a bit of an experimental
thing and we'd like to replace it eventually with something less
problematic like pldb http://github.com/threatgrid/pldb.

Still, core.logic isn't really a database and your needs may be better
served by something with different goals.

David


On Mon, Aug 5, 2013 at 12:41 PM, Mingli Yuan  wrote:

> Hi, folks,
>
> After one night quick work, I had gave a proof-of-concept to demonstrate
> the feasibility that we can combine Wikidata and Clojure logic programming
> together.
>
> The source code is at here:
> https://github.com/mountain/knowledge
>
> An example of an entity:
>
> https://github.com/mountain/knowledge/blob/master/src/entities/albert_einstein.clj
>
> Example of types:
> https://github.com/mountain/knowledge/blob/master/src/meta/types.clj
>
> Example of predicates:
> https://github.com/mountain/knowledge/blob/master/src/meta/properties.clj
>
> Example of inference:
> https://github.com/mountain/knowledge/blob/master/test/knowledge/test.clj
>
> Also we found it is very easy to get any other language version than
> English.
>
> Since I am new to Clojure logic programming, I have questions for the way
> I take - what will happen when we have millions of triples? Should I take
> another approach by using some RDF store?
>
>- How many memory will it cost?
>- How about the performance?
>- How about the loading process of one million clojure source file or
>java class file?
>
> Hope you can give some helpful comments. Thanks in advance.
>
> Regards,
> Mingli
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Lee Spector]

On Aug 5, 2013, at 12:39 PM, Mark Engelberg wrote:
> 
> I agree that subnamespaces are important.   Relatedly, I frequently struggle 
> with the fact that Clojure's import doesn't support wildcards.  When using 
> Java libraries, very frequently the Java tutorials or library documentation 
> use wildcards to import a whole family of subnamespaces.  It's extremely 
> difficult to use such libraries from Clojure, because there is no good way to 
> discover from the Java documentation the entire list of libraries you need to 
> import.

I believe that there was a discussion about wildcards on this list several 
years ago, and that there was pretty firm resistance to including them.

But FWIW I'd love to have them too. And in fact I'd love to be able to 
:use/:require "*"! (Which I guess would be equivalent to 
:use-whatever-you-need, which I just mentioned in the other thread... while 
acknowledging that this would be insane in some programming contexts, but not 
in all).

 -Lee

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Lee Spector]

On Aug 5, 2013, at 12:41 PM, Greg wrote:

>> Can you build in a way to get :require :refer :all to work on a bunch of 
>> sub-namespaces together on one line, as one currently can with :use, without 
>> listing each namespace completely on a separate line with a separate :refer 
>> :all?
> 
> Certainly. I'm not saying this is how the exact syntax would go, but the 
> general idea is to rely on the keywords to specify what (and how) you want to 
> import stuff:
> 
> Instead of:
> 
> (ns one.fresh-server
>   (:use (core matrix math bs))
> 
> You could do something like:
> 
> (ns one.fresh-server
>   [core :refer-all [matrix math bs]])

I like it.

I can't personally assess the costs and benefits of the overall proposal, but 
this would address my concern nicely.

 -Lee

-- 
-- 
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/groups/opt_out.

Re: PoC: Combining Wikidata and Clojure logic programming

[Timothy Baldridge]

This looks a re-implementation of many of the goals of Datomic. Perhaps you
can use Datomic as a datastore, and then use Datomic's datalog, or a custom
query engine (such as core.logic
https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/datomic.clj)
to do your queries?

Timothy


On Mon, Aug 5, 2013 at 10:52 AM, David Nolen  wrote:

> Very interesting. The rel feature is really still a bit of an experimental
> thing and we'd like to replace it eventually with something less
> problematic like pldb http://github.com/threatgrid/pldb.
>
> Still, core.logic isn't really a database and your needs may be better
> served by something with different goals.
>
> David
>
>
> On Mon, Aug 5, 2013 at 12:41 PM, Mingli Yuan wrote:
>
>> Hi, folks,
>>
>> After one night quick work, I had gave a proof-of-concept to demonstrate
>> the feasibility that we can combine Wikidata and Clojure logic programming
>> together.
>>
>> The source code is at here:
>> https://github.com/mountain/knowledge
>>
>> An example of an entity:
>>
>> https://github.com/mountain/knowledge/blob/master/src/entities/albert_einstein.clj
>>
>> Example of types:
>> https://github.com/mountain/knowledge/blob/master/src/meta/types.clj
>>
>> Example of predicates:
>> https://github.com/mountain/knowledge/blob/master/src/meta/properties.clj
>>
>> Example of inference:
>> https://github.com/mountain/knowledge/blob/master/test/knowledge/test.clj
>>
>> Also we found it is very easy to get any other language version than
>> English.
>>
>> Since I am new to Clojure logic programming, I have questions for the way
>> I take - what will happen when we have millions of triples? Should I
>> take another approach by using some RDF store?
>>
>>- How many memory will it cost?
>>- How about the performance?
>>- How about the loading process of one million clojure source file or
>>java class file?
>>
>> Hope you can give some helpful comments. Thanks in advance.
>>
>> Regards,
>> Mingli
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 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/groups/opt_out.
>
>
>



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

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

>> (ns one.fresh-server
>>  [core :refer-all [matrix math bs]])
> 
> I like it.

Ideally, the whole thing would be well thought out enough to allow these very 
basic principles to be combined in complicated ways (kinda like the idea behind 
Lisp itself).

Getting rid of ambiguities might help make it more readable and 
"generalizable". For example, it could be specified that vectors can contain 
only namespaces and keywords, and lists can only contain functions.

If that rule is applied, the original example plus the :refer-all keyword would 
look like this:

New School:

(ns two.namespace
  "optional doc string goes here"
  [core :refer-all [matrix math bs]]
  [clojure :refer-all [core :except (ancestors printf)]]
  [ring.adapter.jetty :refer (run-jetty)]
  [ring.middleware.file :refer (wrap-file)]
  [ring.middleware.file-info :refer (wrap-file-info)]
  [ring.middleware.stacktrace :refer (wrap-stacktrace)]
  [ring.util.response :refer (file-response)]
  [one.reload :as-ns]
  [one.middleware :as-ns]
  [net.cgrand.enlive-html :as html]
  [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
  [java.io.File :as-class])

Now the functions are emphasized as being functions (because only functions are 
allowed in lists).

Notice that this:

[clojure.core :refer-except (ancestors printf)]

Has now changed to:

[clojure :refer-all [core :except (ancestors printf)]]

What if we want to :refer-all everything that's in the first level of the 
namespace? I see no reason why we couldn't just do this then:

[:refer-all [core]]

Or optionally, in the case where there's just one namespace in the vector:

[:refer-all core]

OK, that's enough from me on this for now, gotta run (lot of work to do!).

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 12:59 PM, Lee Spector  wrote:

> 
> On Aug 5, 2013, at 12:41 PM, Greg wrote:
> 
>>> Can you build in a way to get :require :refer :all to work on a bunch of 
>>> sub-namespaces together on one line, as one currently can with :use, 
>>> without listing each namespace completely on a separate line with a 
>>> separate :refer :all?
>> 
>> Certainly. I'm not saying this is how the exact syntax would go, but the 
>> general idea is to rely on the keywords to specify what (and how) you want 
>> to import stuff:
>> 
>> Instead of:
>> 
>> (ns one.fresh-server
>>  (:use (core matrix math bs))
>> 
>> You could do something like:
>> 
>> (ns one.fresh-server
>>  [core :refer-all [matrix math bs]])
> 
> I like it.
> 
> I can't personally assess the costs and benefits of the overall proposal, but 
> this would address my concern nicely.
> 
> -Lee
> 
> -- 
> -- 
> 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/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> OK, that's enough from me on this for now, gotta run (lot of work to do!).


Sorry, after sending that, I couldn't resist simplifying 'ns' even further!

(ns two.namespace
  "optional doc string goes here"
  [core :refer-all [matrix math bs]]
  [clojure :refer-all [core :except (ancestors printf)]]
  [ring.adapter.jetty :refer (run-jetty)]
  [ring.middleware.file :refer (wrap-file)]
  [ring.middleware.file-info :refer (wrap-file-info)]
  [ring.middleware.stacktrace :refer (wrap-stacktrace)]
  [ring.util.response :refer (file-response)]
  [one :refer reload]
  [one :refer middleware]
  [net.cgrand :refer [enlive-html :as html]]
  [org.apache.maven.artifact.resolver :refer ArtifactResolver] 
  [java.io :refer File])

Look at the beauty of that! :-D

Now not only have we gotten rid of :use, :require, :import, :refer-clojure, but 
we're starting to chip away at the mountain of keywords and we still have *all* 
of the power we had before! We got rid of :as-ns, :as-class and :all!

Keep simplifying till you can't simplify anymore! That's the Lisp way! :-)

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 1:14 PM, Greg  wrote:

>>> (ns one.fresh-server
>>>  [core :refer-all [matrix math bs]])
>> 
>> I like it.
> 
> Ideally, the whole thing would be well thought out enough to allow these very 
> basic principles to be combined in complicated ways (kinda like the idea 
> behind Lisp itself).
> 
> Getting rid of ambiguities might help make it more readable and 
> "generalizable". For example, it could be specified that vectors can contain 
> only namespaces and keywords, and lists can only contain functions.
> 
> If that rule is applied, the original example plus the :refer-all keyword 
> would look like this:
> 
> New School:
> 
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one.reload :as-ns]
>   [one.middleware :as-ns]
>   [net.cgrand.enlive-html :as html]
>   [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
>   [java.io.File :as-class])
> 
> Now the functions are emphasized as being functions (because only functions 
> are allowed in lists).
> 
> Notice that this:
> 
> [clojure.core :refer-except (ancestors printf)]
> 
> Has now changed to:
> 
> [clojure :refer-all [core :except (ancestors printf)]]
> 
> What if we want to :refer-all everything that's in the first level of the 
> namespace? I see no reason why we couldn't just do this then:
> 
> [:refer-all [core]]
> 
> Or optionally, in the case where there's just one namespace in the vector:
> 
> [:refer-all core]
> 
> OK, that's enough from me on this for now, gotta run (lot of work to do!).
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 12:59 PM, Lee Spector  wrote:
> 
>> 
>> On Aug 5, 2013, at 12:41 PM, Greg wrote:
>> 
 Can you build in a way to get :require :refer :all to work on a bunch of 
 sub-namespaces together on one line, as one currently can with :use, 
 without listing each namespace completely on a separate line with a 
 separate :refer :all?
>>> 
>>> Certainly. I'm not saying this is how the exact syntax would go, but the 
>>> general idea is to rely on the keywords to specify what (and how) you want 
>>> to import stuff:
>>> 
>>> Instead of:
>>> 
>>> (ns one.fresh-server
>>>  (:use (core matrix math bs))
>>> 
>>> You could do something like:
>>> 
>>> (ns one.fresh-server
>>>  [core :refer-all [matrix math bs]])
>> 
>> I like it.
>> 
>> I can't personally assess the costs and benefits of the overall proposal, 
>> but this would address my concern nicely.
>> 
>> -Lee
>> 
>> -- 
>> -- 
>> 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/groups/opt_out.
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ClojureScript] [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Tim Visher]

This looks awesome. I can't wait to dig into it.

On Mon, Aug 5, 2013 at 9:21 AM, Chas Emerick  wrote:
> As you might know, I've been tinkering with an easier-to-use variant of 
> ClojureScript's browser-REPL for some time.  I've finally wrapped that up 
> into its own project, Austin:
>
> https://github.com/cemerick/austin
>
> Everything you need to know is there.  The tl;dr is:
>
> 1. You can have a ClojureScript REPL running for your project in ~10 seconds 
> (backed by phantomjs by default, but it's easy to wire up any other browser 
> runtime, headless or GUI).
>
> 2. Setting up a ClojureScript REPL where your app's front-end initiates the 
> REPL connection is _nearly_ as easy, and the same mechanism works whether 
> you're running one REPL or ten across one or many projects without touching 
> or worrying about :port configuration, etc.
>
> I've only just started documenting and adding higher-level convenience 
> features and APIs to Austin, so your feedback and contributions are most 
> welcome.
>
> Have fun!
>
> Cheers,
>
> - Chas
>
> --
> Note that posts from new members are moderated - please be patient with your 
> first post.
> ---
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>
>

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

I don't really understand why we would need to simplify something that is
already so simple. Teach people the following:

(ns my-namespace
  ...calls to import fns...)

Where import functions can be either :require or :import:

(:import [clojure.lang Number AFn]) ;; use for Java imports

(:require [clojure.string :as string :refer [split]]) ;; use for clojure
imports

:refer :all can be used to refer everything

Boom! everything you need to know to get started with Clojure's ns. What's
the problem?

That being said, if you really want your syntax above, nothing is stopping
you from using your own import function, they are pluggable after all:

(ns foo
  (:println "Hello World"))

Hello World
=> nil

So you could easily write something like this:

(ns foo
  (:simple-ns/simple
[clojure.core match logic async]))

Timothy Baldridge




On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:

> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>
>
> Sorry, after sending that, I couldn't resist simplifying 'ns' even further!
>
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer reload]
>   [one :refer middleware]
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>   [java.io :refer File])
>
>
> Look at the beauty of that! :-D
>
> Now not only have we gotten rid of :use, :require, :import,
> :refer-clojure, but we're starting to chip away at the mountain of keywords
> and we still have *all* of the power we had before! We got rid of :as-ns,
> :as-class and :all!
>
> Keep simplifying till you can't simplify anymore! That's the Lisp way! :-)
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 1:14 PM, Greg  wrote:
>
> (ns one.fresh-server
>  [core :refer-all [matrix math bs]])
>
>
> I like it.
>
>
> Ideally, the whole thing would be well thought out enough to allow these
> very basic principles to be combined in complicated ways (kinda like the
> idea behind Lisp itself).
>
> Getting rid of ambiguities might help make it more readable and
> "generalizable". For example, it could be specified that vectors can
> contain only namespaces and keywords, and lists can only contain functions.
>
> If that rule is applied, the original example plus the :refer-all keyword
> would look like this:
>
> *New School:*
>
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one.reload :as-ns]
>   [one.middleware :as-ns]
>   [net.cgrand.enlive-html :as html]
>   [org.apache.maven.artifact.resolver.ArtifactResolver :as-class]
>   [java.io.File :as-class])
>
>
> Now the functions are emphasized as being functions (because only
> functions are allowed in lists).
>
> Notice that this:
>
> [clojure.core :refer-except (ancestors printf)]
>
>
> Has now changed to:
>
> [clojure :refer-all [core :except (ancestors printf)]]
>
>
> What if we want to :refer-all everything that's in the first level of the
> namespace? I see no reason why we couldn't just do this then:
>
> [:refer-all [core]]
>
>
> Or optionally, in the case where there's just one namespace in the vector:
>
> [:refer-all core]
>
>
> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 12:59 PM, Lee Spector  wrote:
>
>
> On Aug 5, 2013, at 12:41 PM, Greg wrote:
>
> Can you build in a way to get :require :refer :all to work on a bunch of
> sub-namespaces together on one line, as one currently can with :use,
> without listing each namespace completely on a separate line with a
> separate :refer :all?
>
>
> Certainly. I'm not saying this is how the exact syntax would go, but the
> general idea is to rely on the keywords to specify what (and how) you want
> to import stuff:
>
> Instead of:
>
> (ns one.fresh-server
>  (:use (core matrix math bs))
>
> You could do something like:
>
> (ns one.fresh-server
>  [core :refer-all [matrix math bs]])
>
>
> I like it.
>
> I can't personally assess the costs and benefits of the overall proposal,
> but this would address my concern nicely.
>
> -Lee
>
> --
> --
> You received this message because you are subscribed to the G

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> I don't really understand why we would need to simplify something that is 
> already so simple.

Because it's not simple to many people. It's one of the main things people use 
as an example when discussing complexity in clojure.

There are many threads and blog posts where people explain why they consider 
the "ns" declaration to be complicated.

> That being said, if you really want your syntax above, nothing is stopping 
> you from using your own import function

When I have time, I might do something like that, but not the way you 
illustrated, because that's unnecessarily complicated in my view.

I might either add a hook to to 'ns', or if that's not possible, overwrite it 
to support both syntaxes, or create a different name, like "include".

Then it would be this:

(include two.namespace
  [clojure :refer-all [core :except (ancestors printf)]]
  [core :refer-all [matrix math bs]]
  [ring.adapter.jetty :refer (run-jetty)]
  [ring.middleware.file :refer (wrap-file)]
  [ring.middleware.file-info :refer (wrap-file-info)]
  [ring.middleware.stacktrace :refer (wrap-stacktrace)]
  [ring.util.response :refer (file-response)]
  [one :refer [reload middleware]]
  [net.cgrand :refer [enlive-html :as html]]
  [org.apache.maven.artifact.resolver :refer ArtifactResolver] 
  [java.io :refer File])

Instead of:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:use core.matrix
[ring.adapter.jetty :only (run-jetty)]
[ring.middleware.file :only (wrap-file)]
[ring.middleware.file-info :only (wrap-file-info)]
[ring.middleware.stacktrace :only (wrap-stacktrace)]
[ring.util.response :only (file-response)])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 1:46 PM, Timothy Baldridge  wrote:

> I don't really understand why we would need to simplify something that is 
> already so simple. Teach people the following: 
> 
> (ns my-namespace
>   ...calls to import fns...)
> 
> Where import functions can be either :require or :import:
> 
> (:import [clojure.lang Number AFn]) ;; use for Java imports
> 
> (:require [clojure.string :as string :refer [split]]) ;; use for clojure 
> imports
> 
> :refer :all can be used to refer everything
> 
> Boom! everything you need to know to get started with Clojure's ns. What's 
> the problem?
> 
> That being said, if you really want your syntax above, nothing is stopping 
> you from using your own import function, they are pluggable after all:
> 
> (ns foo
>   (:println "Hello World"))
> 
> Hello World
> => nil
> 
> So you could easily write something like this:
> 
> (ns foo
>   (:simple-ns/simple
> [clojure.core match logic async]))
> 
> Timothy Baldridge
> 
> 
> 
> 
> On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:
>> OK, that's enough from me on this for now, gotta run (lot of work to do!).
> 
> 
> Sorry, after sending that, I couldn't resist simplifying 'ns' even further!
> 
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer reload]
>   [one :refer middleware]
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver] 
>   [java.io :refer File])
> 
> Look at the beauty of that! :-D
> 
> Now not only have we gotten rid of :use, :require, :import, :refer-clojure, 
> but we're starting to chip away at the mountain of keywords and we still have 
> *all* of the power we had before! We got rid of :as-ns, :as-class and :all!
> 
> Keep simplifying till you can't simplify anymore! That's the Lisp way! :-)
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 1:14 PM, Greg  wrote:
> 
 (ns one.fresh-server
  [core :refer-all [matrix math bs]])
>>> 
>>> I like it.
>> 
>> Ideally, the whole thing would be well thought out enough to allow these 
>> very basic principles to be combined in complicated ways (kinda like the 
>> idea behind Lisp itself).
>> 
>> Getting rid of ambiguities might help make it more readable and 
>> "generalizable". For example, it could be specified that vectors can contain 
>> only namespaces and keywords, and lists can only contain functions.
>> 
>> If that rule is applied, the original example plus the :refer-all keyword 
>> would look like this:
>> 
>> New School:
>> 
>> (ns two.namespace
>>   "optional doc string go

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

There's no syntax to ns, ns simply assumes that everything after the
symbol/doc is in the form (function-to-execute & args). The only special
case is gen-class, and even that is fixed up to look like everything else.
Why invent special syntax where none exists now?

I think the issue is more around people not understanding the difference
(and problems behind) refer vs import instead of an actual problem with the
require macro.

On that subject when last discussed, it was mentioned that Clojure doesn't
have a import * method because it's basically impossible to implement.

To quote Rich: "Java packages are not enumerable. The only way to do so is
to walk the classpath/jars etc. I don't think import * is a good idea, as
it brings more into a namespace than you are going to use, making Clojure's
namespace enumeration, e.g. ns-imports, that much less useful. "

https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J

Timothy


On Mon, Aug 5, 2013 at 11:58 AM, Greg  wrote:

> I don't really understand why we would need to simplify something that is
> already so simple.
>
>
> Because it's not simple to many people. It's one of the main things people
> use as an example when discussing complexity in clojure.
>
> There are many threads and blog posts where people explain why they
> consider the "ns" declaration to be complicated.
>
>
> That being said, if you really want your syntax above, nothing is stopping
> you from using your own import function
>
>
> When I have time, I might do something like that, but not the way you
> illustrated, because that's unnecessarily complicated in my view.
>
> I might either add a hook to to 'ns', or if that's not possible, overwrite
> it to support both syntaxes, or create a different name, like "include".
>
> Then it would be this:
>
> (include two.namespace
>
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [core :refer-all [matrix math bs]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer [reload middleware]]
>
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>   [java.io :refer File])
>
>
> Instead of:
>
>
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]
> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
>
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 1:46 PM, Timothy Baldridge 
> wrote:
>
> I don't really understand why we would need to simplify something that is
> already so simple. Teach people the following:
>
> (ns my-namespace
>   ...calls to import fns...)
>
> Where import functions can be either :require or :import:
>
> (:import [clojure.lang Number AFn]) ;; use for Java imports
>
> (:require [clojure.string :as string :refer [split]]) ;; use for clojure
> imports
>
> :refer :all can be used to refer everything
>
> Boom! everything you need to know to get started with Clojure's ns. What's
> the problem?
>
> That being said, if you really want your syntax above, nothing is stopping
> you from using your own import function, they are pluggable after all:
>
> (ns foo
>   (:println "Hello World"))
>
> Hello World
> => nil
>
> So you could easily write something like this:
>
> (ns foo
>   (:simple-ns/simple
> [clojure.core match logic async]))
>
> Timothy Baldridge
>
>
>
>
> On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:
>
>> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>>
>>
>> Sorry, after sending that, I couldn't resist simplifying 'ns' even
>> further!
>>
>> (ns two.namespace
>>   "optional doc string goes here"
>>   [core :refer-all [matrix math bs]]
>>   [clojure :refer-all [core :except (ancestors printf)]]
>>   [ring.adapter.jetty :refer (run-jetty)]
>>   [ring.middleware.file :refer (wrap-file)]
>>   [ring.middleware.file-info :refer (wrap-file-info)]
>>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>>   [ring.util.response :refer (file-response)]
>>   [one :refer reload]
>>   [one :refer middleware]
>>   [net.cgrand :refer [enlive-html :as html]]
>>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>>   [java.io :refer File])
>>
>>
>> Look at the beauty of that! :-D
>>
>> Now not only have we

Re: [Proposal] Simplified 'ns' declaration

[Jonathan Fischer Friberg]

There is syntax to ns. It's not syntax in the traditional way, but it's
essentially the same thing. And Greg is right that it often causes
confusion.

I +1 the second version. The first version's :as-class was too messy.

It could very easily be made backwards-compliant as well. All we have to do
is check if the first item in the list/vec is a keyword. If it is, then
it's the old-style ns. If not, it's the new.

Jonathan

On Mon, Aug 5, 2013 at 8:14 PM, Timothy Baldridge wrote:

> There's no syntax to ns, ns simply assumes that everything after the
> symbol/doc is in the form (function-to-execute & args). The only special
> case is gen-class, and even that is fixed up to look like everything else.
> Why invent special syntax where none exists now?
>
> I think the issue is more around people not understanding the difference
> (and problems behind) refer vs import instead of an actual problem with the
> require macro.
>
> On that subject when last discussed, it was mentioned that Clojure doesn't
> have a import * method because it's basically impossible to implement.
>
> To quote Rich: "Java packages are not enumerable. The only way to do so
> is to walk the classpath/jars etc. I don't think import * is a good idea,
> as it brings more into a namespace than you are going to use, making Clojure's
> namespace enumeration, e.g. ns-imports, that much less useful. "
>
>
> https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J
>
> Timothy
>
>
> On Mon, Aug 5, 2013 at 11:58 AM, Greg  wrote:
>
>> I don't really understand why we would need to simplify something that is
>> already so simple.
>>
>>
>> Because it's not simple to many people. It's one of the main things
>> people use as an example when discussing complexity in clojure.
>>
>> There are many threads and blog posts where people explain why they
>> consider the "ns" declaration to be complicated.
>>
>>
>> That being said, if you really want your syntax above, nothing is
>> stopping you from using your own import function
>>
>>
>> When I have time, I might do something like that, but not the way you
>> illustrated, because that's unnecessarily complicated in my view.
>>
>> I might either add a hook to to 'ns', or if that's not possible,
>> overwrite it to support both syntaxes, or create a different name, like
>> "include".
>>
>> Then it would be this:
>>
>> (include two.namespace
>>
>>   [clojure :refer-all [core :except (ancestors printf)]]
>>   [core :refer-all [matrix math bs]]
>>   [ring.adapter.jetty :refer (run-jetty)]
>>   [ring.middleware.file :refer (wrap-file)]
>>   [ring.middleware.file-info :refer (wrap-file-info)]
>>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>>   [ring.util.response :refer (file-response)]
>>   [one :refer [reload middleware]]
>>
>>   [net.cgrand :refer [enlive-html :as html]]
>>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>>   [java.io :refer File])
>>
>>
>> Instead of:
>>
>>
>> (ns one.fresh-server
>>   (:refer-clojure :exclude [ancestors printf])
>>   (:use core.matrix
>> [ring.adapter.jetty :only (run-jetty)]
>> [ring.middleware.file :only (wrap-file)]
>> [ring.middleware.file-info :only (wrap-file-info)]
>> [ring.middleware.stacktrace :only (wrap-stacktrace)]
>> [ring.util.response :only (file-response)])
>>   (:require [one.reload :as reload]
>> [one.middleware :as middleware]
>> [net.cgrand.enlive-html :as html])
>>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>>(java.io File
>>
>>
>> - Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>> On Aug 5, 2013, at 1:46 PM, Timothy Baldridge 
>> wrote:
>>
>> I don't really understand why we would need to simplify something that is
>> already so simple. Teach people the following:
>>
>> (ns my-namespace
>>   ...calls to import fns...)
>>
>> Where import functions can be either :require or :import:
>>
>> (:import [clojure.lang Number AFn]) ;; use for Java imports
>>
>> (:require [clojure.string :as string :refer [split]]) ;; use for clojure
>> imports
>>
>> :refer :all can be used to refer everything
>>
>> Boom! everything you need to know to get started with Clojure's ns.
>> What's the problem?
>>
>> That being said, if you really want your syntax above, nothing is
>> stopping you from using your own import function, they are pluggable after
>> all:
>>
>> (ns foo
>>   (:println "Hello World"))
>>
>> Hello World
>> => nil
>>
>> So you could easily write something like this:
>>
>> (ns foo
>>   (:simple-ns/simple
>> [clojure.core match logic async]))
>>
>> Timothy Baldridge
>>
>>
>>
>>
>> On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:
>>
>>> OK, that's enough from me on this for now, gotta run (lot of work to
>>> do!).
>>>
>>>
>>> Sorry, after sending that, I couldn't resist simplifying 'ns' even
>>> further!
>>>
>>> (ns two.namespace
>>>   "o

Re: [Proposal] Simplified 'ns' declaration

[Mark Engelberg]

On Mon, Aug 5, 2013 at 11:14 AM, Timothy Baldridge wrote:

> On that subject when last discussed, it was mentioned that Clojure doesn't
> have a import * method because it's basically impossible to implement.
>

Well, surely the word "impossible" is inaccurate, since other languages
(e.g., Scala) do it.


>
> To quote Rich: "Java packages are not enumerable. The only way to do so
> is to walk the classpath/jars etc. I don't think import * is a good idea,
> as it brings more into a namespace than you are going to use, making Clojure's
> namespace enumeration, e.g. ns-imports, that much less useful. "
>

The argument for wildcards is very simple.  Go to just about any Java
tutorial, for example:
http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java

The sample code starts off with a dozen wildcard imports.  If I want to try
to use these techniques in Clojure, I have absolutely no idea which
specific classes to require.  This creates a tremendous obstacle to
consuming Java libraries.  This has affected me personally on several
occasions, preventing me from successfully figuring out how to use some
Java library from Clojure.

Maybe it's not ideal if Clojure has to walk the classpath, but the
alternative is that I have to manually walk the classpath and jars myself
with no idea what I'm looking for.  Surely it's better for this to be
handled through an automated process.

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Lee Spector]

On Aug 5, 2013, at 2:14 PM, Timothy Baldridge wrote:
> 
> To quote Rich: "Java packages are not enumerable. The only way to do so is to 
> walk the classpath/jars etc. I don't think import * is a good idea, as it 
> brings more into a namespace than you are going to use, making Clojure's 
> namespace enumeration, e.g. ns-imports, that much less useful. "
> 
> https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J

I think that was the old discussion that I remembered and mentioned in a 
previous post.

Now that I look back at it and see that this was only about "import" l wonder: 
Is there a similar aversion to allowing wildcards in :require/:use 
specifications?

I see that that the discussion about import is continuing as I type, and I'd 
personally be pro-wildcard in all cases, but perhaps these are separate issues 
and wildcards might be allowed in :require/:use however that turns out?

 -Lee

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Jonathan Fischer Friberg]

I forgot to add:

I think simplicity is really important, and I think one of clojure's strong
points are exactly that - simplicity. Simplifying something is not always
the right thing to do, but in this case I can't see why it wouldn't. After
all, the syntax is almost exactly the same.

To comment on the message Mark just sent, I don't agree. :)
I think it's java that is at fault here. I think wildcards should never
have been part of java to begin with. The argument here is basically
exactly the same as why :use shouldn't be used, so I wont explain it
further.

Jonathan

On Mon, Aug 5, 2013 at 8:25 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> There is syntax to ns. It's not syntax in the traditional way, but it's
> essentially the same thing. And Greg is right that it often causes
> confusion.
>
> I +1 the second version. The first version's :as-class was too messy.
>
> It could very easily be made backwards-compliant as well. All we have to
> do is check if the first item in the list/vec is a keyword. If it is, then
> it's the old-style ns. If not, it's the new.
>
> Jonathan
>
>
> On Mon, Aug 5, 2013 at 8:14 PM, Timothy Baldridge wrote:
>
>> There's no syntax to ns, ns simply assumes that everything after the
>> symbol/doc is in the form (function-to-execute & args). The only special
>> case is gen-class, and even that is fixed up to look like everything else.
>> Why invent special syntax where none exists now?
>>
>> I think the issue is more around people not understanding the difference
>> (and problems behind) refer vs import instead of an actual problem with the
>> require macro.
>>
>> On that subject when last discussed, it was mentioned that Clojure
>> doesn't have a import * method because it's basically impossible to
>> implement.
>>
>> To quote Rich: "Java packages are not enumerable. The only way to do so
>> is to walk the classpath/jars etc. I don't think import * is a good
>> idea, as it brings more into a namespace than you are going to use,
>> making Clojure's namespace enumeration, e.g. ns-imports, that much less
>> useful. "
>>
>>
>> https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J
>>
>> Timothy
>>
>>
>> On Mon, Aug 5, 2013 at 11:58 AM, Greg  wrote:
>>
>>> I don't really understand why we would need to simplify something that
>>> is already so simple.
>>>
>>>
>>> Because it's not simple to many people. It's one of the main things
>>> people use as an example when discussing complexity in clojure.
>>>
>>> There are many threads and blog posts where people explain why they
>>> consider the "ns" declaration to be complicated.
>>>
>>>
>>> That being said, if you really want your syntax above, nothing is
>>> stopping you from using your own import function
>>>
>>>
>>> When I have time, I might do something like that, but not the way you
>>> illustrated, because that's unnecessarily complicated in my view.
>>>
>>> I might either add a hook to to 'ns', or if that's not possible,
>>> overwrite it to support both syntaxes, or create a different name, like
>>> "include".
>>>
>>> Then it would be this:
>>>
>>> (include two.namespace
>>>
>>>   [clojure :refer-all [core :except (ancestors printf)]]
>>>   [core :refer-all [matrix math bs]]
>>>   [ring.adapter.jetty :refer (run-jetty)]
>>>   [ring.middleware.file :refer (wrap-file)]
>>>   [ring.middleware.file-info :refer (wrap-file-info)]
>>>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>>>   [ring.util.response :refer (file-response)]
>>>   [one :refer [reload middleware]]
>>>
>>>   [net.cgrand :refer [enlive-html :as html]]
>>>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>>>   [java.io :refer File])
>>>
>>>
>>> Instead of:
>>>
>>>
>>> (ns one.fresh-server
>>>   (:refer-clojure :exclude [ancestors printf])
>>>   (:use core.matrix
>>> [ring.adapter.jetty :only (run-jetty)]
>>> [ring.middleware.file :only (wrap-file)]
>>> [ring.middleware.file-info :only (wrap-file-info)]
>>> [ring.middleware.stacktrace :only (wrap-stacktrace)]
>>> [ring.util.response :only (file-response)])
>>>   (:require [one.reload :as reload]
>>> [one.middleware :as middleware]
>>> [net.cgrand.enlive-html :as html])
>>>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>>>(java.io File
>>>
>>>
>>> - Greg
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also
>>> sharing with the NSA.
>>>
>>> On Aug 5, 2013, at 1:46 PM, Timothy Baldridge 
>>> wrote:
>>>
>>> I don't really understand why we would need to simplify something that
>>> is already so simple. Teach people the following:
>>>
>>> (ns my-namespace
>>>   ...calls to import fns...)
>>>
>>> Where import functions can be either :require or :import:
>>>
>>> (:import [clojure.lang Number AFn]) ;; use for Java imports
>>>
>>> (:require [clojure.string :as string :refer [split]]) ;; use for clojure
>>> imports
>>>
>>>

Re: Can we please deprecate the :use directive ?

[Brian Marick]

I find that having both `:use` and `:require` in my `ns` declarations can, with 
a little judicious formatting, communicate something about which packages are 
core and which are peripheral. Having to obfuscate that distinction with a 
`:refer :all` tacked - in a visually obscure way - onto `:require` forms would 
make me sad. Not wildly sad, but wistfully sad that people would prefer a 
breaking change to simply avoiding something they don't want to use.

Or:

On Aug 5, 2013, at 11:48 AM, Lee Spector  wrote:

> My point is just that the needs and priorities are diverse, and I wish people 
> wouldn't be so enthusiastic about deprecating features that are valued by 
> others in the community.


Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Greg]

Here's a new syntax that gets rid of everything except for :as and 
:except/:exclude:

(ns two.namespace
  [clojure [core :except (ancestors printf)]]
  [core [matrix math bs]] ; same as (:use (core matrix math bs))
  [[some-ns]] ; same as (:use some-ns)
  [ring.adapter.jetty (run-jetty :as jetty)]
  [ring.middleware.file ("warp-*")] ; refers all functions beginning with 
"wrap-"
; regex not supported because too confusing
  [ring.middleware.file-info (wrap-file-info)]
  [ring.middleware.stacktrace (wrap-stacktrace)]
  [ring.util.response (file-response)]
  [one reload middleware]
  [net.cgrand enlive-html :as html]
  [org.apache.maven.artifact.resolver ArtifactResolver] 
  [java.io File InputStream])


There are just four key rules to understand:

1) vectors can only contain namespaces and the keywords :as and :except
2) vectors within vectors will refer everything in the the namespaces specified 
in them
3) lists can only contain functions and the keyword :as to rename functions.
4) namespaces are referred by placing a space after the namespace prefix

Also, an added feature/rule is that globbing-based strings can be used to save 
on typing (as shown in the example above).

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 5, 2013, at 2:31 PM, Jonathan Fischer Friberg  
wrote:

> I forgot to add:
> 
> I think simplicity is really important, and I think one of clojure's strong 
> points are exactly that - simplicity. Simplifying something is not always the 
> right thing to do, but in this case I can't see why it wouldn't. After all, 
> the syntax is almost exactly the same.
> 
> To comment on the message Mark just sent, I don't agree. :)
> I think it's java that is at fault here. I think wildcards should never have 
> been part of java to begin with. The argument here is basically exactly the 
> same as why :use shouldn't be used, so I wont explain it further.
> 
> Jonathan
> 
> On Mon, Aug 5, 2013 at 8:25 PM, Jonathan Fischer Friberg 
>  wrote:
> There is syntax to ns. It's not syntax in the traditional way, but it's 
> essentially the same thing. And Greg is right that it often causes confusion.
> 
> I +1 the second version. The first version's :as-class was too messy.
> 
> It could very easily be made backwards-compliant as well. All we have to do 
> is check if the first item in the list/vec is a keyword. If it is, then it's 
> the old-style ns. If not, it's the new.
> 
> Jonathan
> 
> 
> On Mon, Aug 5, 2013 at 8:14 PM, Timothy Baldridge  
> wrote:
> There's no syntax to ns, ns simply assumes that everything after the 
> symbol/doc is in the form (function-to-execute & args). The only special case 
> is gen-class, and even that is fixed up to look like everything else. Why 
> invent special syntax where none exists now? 
> 
> I think the issue is more around people not understanding the difference (and 
> problems behind) refer vs import instead of an actual problem with the 
> require macro. 
> 
> On that subject when last discussed, it was mentioned that Clojure doesn't 
> have a import * method because it's basically impossible to implement. 
> 
> To quote Rich: "Java packages are not enumerable. The only way to do so is to 
> walk the classpath/jars etc. I don't think import * is a good idea, as it 
> brings more into a namespace than you are going to use, making Clojure's 
> namespace enumeration, e.g. ns-imports, that much less useful. "
> 
> https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J
> 
> Timothy
> 
> 
> On Mon, Aug 5, 2013 at 11:58 AM, Greg  wrote:
>> I don't really understand why we would need to simplify something that is 
>> already so simple.
> 
> Because it's not simple to many people. It's one of the main things people 
> use as an example when discussing complexity in clojure.
> 
> There are many threads and blog posts where people explain why they consider 
> the "ns" declaration to be complicated.
> 
> 
>> That being said, if you really want your syntax above, nothing is stopping 
>> you from using your own import function
> 
> When I have time, I might do something like that, but not the way you 
> illustrated, because that's unnecessarily complicated in my view.
> 
> I might either add a hook to to 'ns', or if that's not possible, overwrite it 
> to support both syntaxes, or create a different name, like "include".
> 
> Then it would be this:
> 
> (include two.namespace
> 
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [core :refer-all [matrix math bs]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer [reload middleware]]
> 
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact

Re: [Proposal] Simplified 'ns' declaration

[Mark Engelberg]

On Mon, Aug 5, 2013 at 11:31 AM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

I think it's java that is at fault here. I think wildcards should never
> have been part of java to begin with. The argument here is basically
> exactly the same as why :use shouldn't be used, so I wont explain it
> further.


Well, Clojure is hosted on Java and clean interop is one of its goals.

The fact of the matter is that many Java libraries are designed and
documented with the existence of the wildcard in mind.  The code is
fragmented across many small classes that are designed to be imported en
masse with a wildcard.  The documentation often does not even provide any
details about which specific classes are located where, it simply shows to
use the wildcard to get them all.

Whether this is Java's "fault", the fact that Clojure does not embrace this
idiom has concretely hurt my ability to use Java code.

-- 
-- 
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/groups/opt_out.

Re: Can we please deprecate the :use directive ?

[Softaddicts]

I agree on this, just started to replace some :use by refer all and I have to
maintain the convention to place these at the end of the :require list
otherwise they get obfuscated if they end up in the middle.
There are only one or two per name space and we can have six to a dozen
required name spaces with aliases in our name spaces.

:use is much more obvious. we usually place them after the :require section and 
they
can not be missed by a reader. 

I can live with this but not really convinced that it improves readability.
Still debatable.

Luc.


> I find that having both `:use` and `:require` in my `ns` declarations can, 
> with a little judicious formatting, communicate something about which 
> packages are core and which are peripheral. Having to obfuscate that 
> distinction with a `:refer :all` tacked - in a visually obscure way - onto 
> `:require` forms would make me sad. Not wildly sad, but wistfully sad that 
> people would prefer a breaking change to simply avoiding something they don't 
> want to use.
> 
> Or:
> 
> On Aug 5, 2013, at 11:48 AM, Lee Spector  wrote:
> 
> > My point is just that the needs and priorities are diverse, and I wish 
> > people wouldn't be so enthusiastic about deprecating features that are 
> > valued by others in the community.
> 
> 
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
> 
> -- 
> -- 
> 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/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Tassilo Horn]

Mark Engelberg  writes:

>> I think it's java that is at fault here. I think wildcards should
>> never have been part of java to begin with. The argument here is
>> basically exactly the same as why :use shouldn't be used, so I wont
>> explain it further.
>
> Well, Clojure is hosted on Java and clean interop is one of its goals.
>
> The fact of the matter is that many Java libraries are designed and
> documented with the existence of the wildcard in mind.  The code is
> fragmented across many small classes that are designed to be imported
> en masse with a wildcard.

The good thing in Java land is that IDEs like Eclipse automatically
replace "import foo.*;" with a list of imports that are actually used in
the compilation unit.

Bye,
Tassilo

-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Jonathan Fischer Friberg]

I guess you're right. There should be a way to import many java classes
just as importing an entire clojure namespace.

We could also have exactly the same syntax for clojure namespaces as java
classes. So instead of

[org.apache.maven.artifact.resolver ArtifactResolver]

we would have

[org.apache.maven.artifact.resolver :refer [ArtifactResolver]]

or

[org.apache.maven.artifact.resolver :refer :all]

Which would be equivalent to a wildcard.

I'm not sure myself which is best. It might be a good idea to separate java
importing and ns importing.

Jonathan

On Mon, Aug 5, 2013 at 9:04 PM, Mark Engelberg wrote:

> On Mon, Aug 5, 2013 at 11:31 AM, Jonathan Fischer Friberg <
> odysso...@gmail.com> wrote:
>
> I think it's java that is at fault here. I think wildcards should never
>> have been part of java to begin with. The argument here is basically
>> exactly the same as why :use shouldn't be used, so I wont explain it
>> further.
>
>
> Well, Clojure is hosted on Java and clean interop is one of its goals.
>
> The fact of the matter is that many Java libraries are designed and
> documented with the existence of the wildcard in mind.  The code is
> fragmented across many small classes that are designed to be imported en
> masse with a wildcard.  The documentation often does not even provide any
> details about which specific classes are located where, it simply shows to
> use the wildcard to get them all.
>
> Whether this is Java's "fault", the fact that Clojure does not embrace
> this idiom has concretely hurt my ability to use Java code.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Laurent PETIT]

Wildcards for java imports will probably never be resolvable when the ns is
called. By that I mean that java class loaders are not enumerable, so you
cannot get this to work generally.
This is a technical detail which objectively prevents the possibility to
import "massively" class symbols into a namespace.

But as you said, languages such as java, etc. manage around this
restriction.
I'm no expert in this area, but my guess is that it's later during the
compilation, when an unknown type is used for the first time, that the
packages declared with wildcards are queried, and a that time with a
specific type name to search for.

What this means for clojure is that it's the compiler that would need to be
changed. When faced with an unknown symbol, after having unsuccessfully
resolved it by the usual ways, it would then query the class loader using
as package prefix the wildcard-imported packages, in turn. And then report
if nothing was found (error), more than one matching package was found
(ambiguity), or just compile if one and only one package was found.

This would still follow the principle of : pay only for what you need,
since for namespaces not declaring any wildcard-package, there would be no
unnecessary findClass calls to the class loader.

I'm speaking here because I can see value in what Mark and Lee are
suggesting. Indeed, when doing what we all love in the Repl, that is rapid
development, we can live with the costs of some extra packages / ns
lookups.

And it would still be possible, when time comes to "freeze" a namespace, to
call some helper method to help get an un-wildcardized ns declaration.

My 0,02€,

Laurent

Le lundi 5 août 2013, Tassilo Horn a écrit :

> Mark Engelberg > writes:
>
> >> I think it's java that is at fault here. I think wildcards should
> >> never have been part of java to begin with. The argument here is
> >> basically exactly the same as why :use shouldn't be used, so I wont
> >> explain it further.
> >
> > Well, Clojure is hosted on Java and clean interop is one of its goals.
> >
> > The fact of the matter is that many Java libraries are designed and
> > documented with the existence of the wildcard in mind.  The code is
> > fragmented across many small classes that are designed to be imported
> > en masse with a wildcard.
>
> The good thing in Java land is that IDEs like Eclipse automatically
> replace "import foo.*;" with a list of imports that are actually used in
> the compilation unit.
>
> Bye,
> Tassilo
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: [ClojureScript] [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Laurent PETIT]

Can you all guys please stop starting sooo many interesting topics while
I'm on holidays ? ;-)

Le lundi 5 août 2013, Chas Emerick a écrit :

> On Aug 5, 2013, at 9:21 AM, Chas Emerick wrote:
>
> > As you might know, I've been tinkering with an easier-to-use variant of
> ClojureScript's browser-REPL for some time.  I've finally wrapped that up
> into its own project, Austin:
> >
> >   https://github.com/cemerick/austin
> >
> > Everything you need to know is there.  The tl;dr is:
> >
> > 1. You can have a ClojureScript REPL running for your project in ~10
> seconds (backed by phantomjs by default, but it's easy to wire up any other
> browser runtime, headless or GUI).
> >
> > 2. Setting up a ClojureScript REPL where your app's front-end initiates
> the REPL connection is _nearly_ as easy, and the same mechanism works
> whether you're running one REPL or ten across one or many projects without
> touching or worrying about :port configuration, etc.
> >
> > I've only just started documenting and adding higher-level convenience
> features and APIs to Austin, so your feedback and contributions are most
> welcome.
> >
> > Have fun!
> >
> > Cheers,
> >
> > - Chas
>
> BTW, I put a screencast demonstrating Austin over here:
>
> Demo of Austin, an alternative ClojureScript browser-REPL
> implementation 
>
> - Chas
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: Clojars "Could not transfer artifact... ReasonPhrase: Forbidden"

[Timothy Washington]

Ok, got this sorted out. Thanks to xeqi @ #leiningen @ irc.freenode.org.


Tim Washington
Interruptsoftware.ca / Bkeeping.com



On Mon, Aug 5, 2013 at 11:24 AM, Timothy Washington wrote:

> Hi all,
>
> I'm having problems deploying a project to Clojars. I've just reset my
> Clojars i) password and ii) SSH public key. And now, from my development
> system, I want to push my project. Yet I get the below error: "*Could not
> transfer artifact... ReasonPhrase: Forbidden*". I'm very sure that the
> password is correct, and that the SSH keys match on my system, and clojars.
> Are there any other gymnastics that has to happen?
>
>
> *$ ~/Projects/stefon$ lein deploy clojars*
> *No credentials found for clojars*
> *See `lein help deploy` for how to configure credentials.*
> *Username: xxx*
> *Password: *
> *Wrote /home/webkell/Projects/stefon/pom.xml*
> *Created
> /home/webkell/Projects/stefon/target/provided/stefon-0.1.0-SNAPSHOT.jar*
> *Retrieving stefon/stefon/0.1.0-SNAPSHOT/maven-metadata.xml (1k)*
> *from https://clojars.org/repo/*
> *Sending stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom
> (4k)*
> *to https://clojars.org/repo/*
>  *Could not transfer artifact stefon:stefon:pom:0.1.0-20130805.150327-2
> from/to clojars (https://clojars.org/repo/): Access denied to:
> https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom,
> ReasonPhrase: Forbidden.*
> *Sending stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.jar
> (7k)*
> *to https://clojars.org/repo/*
>  *Could not transfer artifact stefon:stefon:jar:0.1.0-20130805.150327-2
> from/to clojars (https://clojars.org/repo/): Access denied to:
> https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.jar,
> ReasonPhrase: Forbidden.*
> *Failed to deploy artifacts: Could not transfer artifact
> stefon:stefon:pom:0.1.0-20130805.150327-2 from/to clojars (
> https://clojars.org/repo/): Access denied to:
> https://clojars.org/repo/stefon/stefon/0.1.0-SNAPSHOT/stefon-0.1.0-20130805.150327-2.pom,
> ReasonPhrase: Forbidden.*
>
>
>
> Thanks
>
> Tim Washington
> Interruptsoftware.ca / Bkeeping.com
>
>

-- 
-- 
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/groups/opt_out.

[ANN] Call for papers: Dutch Clojure Day

[skuro]

Hi all,

After four successful years of the October Amsterdam 
Clojure event, 
the two biggest Clojure communities in the Netherlands, 
AmsClj
 and EHRD.clj , joined forces to put 
together the greatest free event in Europe about Clojure: the Dutch Clojure 
Day  will take place on Saturday, October 
12th in Amsterdam, the Netherlands. One full day of presentations, 
[un]conferences and more in the weekend before EuroClojure, at a train ride 
distance from it in the Amsterdam city 
center
.

We will accept talk proposals through September 15th, to be submitted 
here.
 
Shortly thereafter we will publish the final programme.

Thanks,
c.


-- 
-- 
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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Stefan du Fresne]

Just a note: my understanding was that even in Java-land using import * is 
not recommended. I've done professional Java development since 2006 and in 
that time I don't think I've ever used import *. I've certainly seen it *in 
*production code, but I've never felt the need to use it myself.

On Tuesday, 6 August 2013 07:04:16 UTC+12, puzzler wrote:
>
> On Mon, Aug 5, 2013 at 11:31 AM, Jonathan Fischer Friberg <
> odys...@gmail.com > wrote:
>
> I think it's java that is at fault here. I think wildcards should never 
>> have been part of java to begin with. The argument here is basically 
>> exactly the same as why :use shouldn't be used, so I wont explain it 
>> further.
>
>
> Well, Clojure is hosted on Java and clean interop is one of its goals.
>
> The fact of the matter is that many Java libraries are designed and 
> documented with the existence of the wildcard in mind.  The code is 
> fragmented across many small classes that are designed to be imported en 
> masse with a wildcard.  The documentation often does not even provide any 
> details about which specific classes are located where, it simply shows to 
> use the wildcard to get them all.
>
> Whether this is Java's "fault", the fact that Clojure does not embrace 
> this idiom has concretely hurt my ability to use Java code.
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

Arie, it looks like this is occurring for a lot of people. In lein.clj, I'm 
using two different methods to launch a process, a "fast" method that 
leverages Leiningen's trampoline feature, and a "slow" method that runs 
nightcode.lein which in turn runs Leiningen commands (i.e. it adds a level 
of indirection).

The "Run with REPL" button uses the slow method, because it doesn't work 
correctly with the fast method. I'm having a hard time figuring out why the 
slow method fails for some people, and not others. I've made some changes, 
so if you have the time, please try cloning the repo and running `lein 
run`, and see if the "Run with REPL" button still throws that error. Any 
help in this regard would be really appreciated.

On Sunday, August 4, 2013 6:40:54 AM UTC-4, Arie van Wingerden wrote:
>
> Hi Zach,
>
> 0.0.1 worked OK.
> 0.0.3 gives this error when "Run with REPL":
>Error: Could not find or load main class nightcode.lein
>
> TIA,
>   Arie
>
>
> 2013/8/3 Zach Oakes >
>
>> Thanks for the complements! I just released 0.0.2, which should make 
>> Run/Build faster and more reliable. It also fixes shortcuts on OS X so they 
>> use command instead of control.
>>
>>
>> On Saturday, August 3, 2013 8:07:31 AM UTC-4, Manuel Paccagnella wrote:
>>>
>>> Wow, it looks very promising. I'd also like add a +1 for smart indent 
>>> and paredit. 
>>>
>>> Kudos to you Zach!
>>>
>>> Manuel
>>>
>>> Il giorno venerdì 2 agosto 2013 15:03:03 UTC+2, Zach Oakes ha scritto:

 I’ve been working on a simple IDE for the past few months. It started 
 as an attempt to add Leiningen integration to Clooj, but eventually I 
 decided to start a new project from scratch. It is very alpha-quality, so 
 please be gentle:

 http://nightcode.info/

 Here’s what it has:

 -Written in Clojure (the UI is written with seesaw)

 -Built-in copy of Leiningen to build Clojure and pure-Java projects

 -Built-in templates for several common types of Clojure and Java 
 projects

 -Always-on REPL in the corner to try Clojure commands

 -Android integration (includes the lein-droid plugin, LogCat output, 
 etc)

 -ClojureScript integration (includes the lein-cljsbuild plugin)

 -Cool looking dark theme, because that’s trendy these days

 Here’s what it’s missing:

 -Fast build times (it launches Leiningen in a separate process, which 
 is slw...I plan on fixing this and would love any help)

 -Important editing features (code completion, text replace, etc)

 -Quick switching between recent files

 -Jump to definition, built-in documentation

 -Integration between editor and REPL (eval form or entire file)

 -Integration with git
 -Many other things -- please give me your thoughts!

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: Two Dimensional Associative Map

[Kevin Downey]

On 8/2/13 8:08 PM, JvJ wrote:
> Actually, what I'm looking for is a way to use arbitrary types of keys 
> rather than integers.
> 
> I have this so far:
> 
>  Table data structure.
>  For now, the table data structure is a map of maps.
> 
> (defn row
>   "Get a row of the table.
>  If only the key is passed, a row
> lookup function is returned."
>   ([r]
>  #(row r %))
>   ([r m]
>  (get m r)))
> 
> (defn col
>   "Get a column of the table."
>   ([c]
>  #(col c %))
>   ([c m]
>  (for [[rk r] m
>:let [x (get r c)]
>:when x]
>[rk x])))
> 
> (defn t-get
>   "Get values in a table."
>   [m &{:keys [r c]}]
>   (cond
>(and r c) (get-in m [r c])
>r (row r m)
>c (col c m)
>:else m))
> 
> (defn t-update
>   "Update a value or values in the map."
>   [m f &{:keys [r c]}]
>   (cond
>(and r c) (update-in m [r c] f)
>r (update-in m [r] f)
>
>;; This O(n) column update is making me angry!
>c (let [res (f (into {} (t-get m :c c)))]
>(println "f result: " res)
>(reduce
> (fn [acc k]
>   (if-let [v (get res k)]
> (update-in acc [k] assoc c v)
> (if (contains? (get m k) c)
>   (update-in acc [k] dissoc c)
>   acc)))
> m
> (clojure.set/union (set (keys m))
>(set (keys res)))
> 
> (defn t-set
>   "Set a value or values in the map."
>   [m v & r]
>   (apply t-update m (constantly v) r))
> 
> It works pretty well for swapping out rows or individual cells, but setting 
> a column seems like an inefficient operation.  I don't know how much I'll be
> using that.
> 
> On Thursday, 1 August 2013 17:59:40 UTC-7, JvJ wrote:
>>
>> I'm looking for an associative data structure that can be accessed by both 
>> rows and columns, and could potentially be sparse.
>>
>> Suppose the following table is called t:
>>
>> |   | :A   | :B   | :C   ||---+--+--+--|| 1 |  | 
>>  | '[x y z] || 2 | "2a" | "2b" |  || 3 |  |  |  || 3 
>> | :3a  |  | "Foo"|
>>
>>
>> Then (t :A) would return {2 "2a", 3 :3a}, and (t 2) would return {:A "2a", 
>> :B "2b"}.
>> (t :A 2) or (t 2 :A) would return "2a".
>>
>> I'm thinking of implementing it as a simple map of maps with some extra 
>> functions, but I'm not sure if
>> that would be the best option.
>>
>>
>>
> 

please, please, use clojure.set/index, it does what you want, better the
code you shared.

-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?



signature.asc
Description: OpenPGP digital signature

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Phil Hagelberg]

On Friday, August 2, 2013 8:49:06 AM UTC-7, Zach Oakes wrote:
> As for my choice of public domain, I always do that for my projects.
 
Of course it's your choice, but are you aware there are jurisdictions in 
which users cannot legally make copies of code released in the public 
domain?

-Phil

[1] 
- 
https://en.wikipedia.org/wiki/Public_domain#Dedicating_works_to_the_public_domain
[2] - https://en.wikipedia.org/wiki/Moral_rights

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Phil Hagelberg]

> As for my choice of public domain, I always do that for my
> projects. I realize that I am going against the grain, but it's a
> principled issue for me. I wrote about it on my blog, but if you'd
> like to discuss it further we should do it elsewhere because it can
> easily derail the thread.

Oops; replied before I read the whole email. I'll assume your aware of this 
then; moving on.

-Phil

>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Clotilde is Linda in Clojure.

[François DE SERRES]

Quoted patterns need to be handled correctly by clotilde.innards/-match-fn.
Tried to make it a macro and to unquote pattern, but 
clojure.core.match/match complains.
See test-match-fn.
Gah!

Le lundi 5 août 2013 16:37:16 UTC+2, François DE SERRES a écrit :
>
> Hi, 
>
> 9 months and half a dozen books later, here's my first (hopefully) useful 
> Clojure program: https://github.com/justiniac/clotilde
>
> Clotilde implements the basic ops of the Linda process coordination 
> language: http://en.wikipedia.org/wiki/Linda_(coordination_language)
>
> More on the topic: 
> http://www.sciencedirect.com/science/article/pii/S0890540199928237
> I'd be so happy to get feedback ;o) 
> Also, I am now in search of a (possibly NP complex) short Linda program to 
> translate into Clotilde.
> Mucho thankies!
> --
> François
>
>

-- 
-- 
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/groups/opt_out.

ANN: paredit-widget, simple swing-based clojure paredit widget

[kovas boguta]

https://github.com/kovasb/paredit-widget

This is a simple project that does the obvious: provide a simple widget
that implements paredit. It is intended to be embedded as part of other
applications, and thus is minimal.

This is a rough cut and contributions welcome, particularly for
cross-platform issues. (would also love to have rainbow parens :)

The bulk of the work is done by Laurent's paredit.clj ; this just provides
a thin swing UI wrapper so that one can actually interact with it.

The bigger idea is that code editing should be available a la carte.

Tying something as fundamental as code editing together with IDE concerns
(file & project management, artifact generation, debugging, etc)  is a
mistake with profound consequences.

-- 
-- 
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/groups/opt_out.

Re: [ANN] Clotilde is Linda in Clojure.

[Lee Spector]

On Aug 5, 2013, at 10:37 AM, François DE SERRES wrote:
> 9 months and half a dozen books later, here's my first (hopefully) useful 
> Clojure program: https://github.com/justiniac/clotilde
> 
> Clotilde implements the basic ops of the Linda process coordination language: 
> http://en.wikipedia.org/wiki/Linda_(coordination_language)
> 
> More on the topic: 
> http://www.sciencedirect.com/science/article/pii/S0890540199928237
> 
> I'd be so happy to get feedback ;o) 
> Also, I am now in search of a (possibly NP complex) short Linda program to 
> translate into Clotilde.
> Mucho thankies!

Thanks so much for this François -- I've always been intrigued with Linda and 
I've played with the concepts a bit, and I'm happy to see this emerging in 
Clojure.

Do you happen to have a simple example of a program that uses and demonstrates 
the core features of the library? That would make it a lot easier to see the 
system's potential and to start playing with it. I do see the tests in 
clotilde.core-test but those seem to focus on testing individual pieces, not 
showing what a simple program using the library would look like.

 -Lee

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[kovas boguta]

I've just released paredit-widget, https://github.com/kovasb/paredit-widget

with the intention of creating a drop-in paredit solution for projects like
nightcode. Its still pretty experimental but might be an interesting test
case to try to integrate.





On Sun, Aug 4, 2013 at 8:19 PM, Matthew Chadwick  wrote:

> this is great!
>
> please please add structural editing (not simply bracket-matching in a
> text-editor, but direct manipulation of Clojure data structures (including
> code). I've been trying out some ideas in this area & would be happy to
> help out.
>
>
> On Friday, August 2, 2013 11:03:03 PM UTC+10, Zach Oakes wrote:
>>
>> I’ve been working on a simple IDE for the past few months. It started as
>> an attempt to add Leiningen integration to Clooj, but eventually I decided
>> to start a new project from scratch. It is very alpha-quality, so please be
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>>
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>
>> -Built-in templates for several common types of Clojure and Java projects
>>
>> -Always-on REPL in the corner to try Clojure commands
>>
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is
>> slw...I plan on fixing this and would love any help)
>>
>> -Important editing features (code completion, text replace, etc)
>>
>> -Quick switching between recent files
>>
>> -Jump to definition, built-in documentation
>>
>> -Integration between editor and REPL (eval form or entire file)
>>
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

[John D. Hume]

On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta  wrote:

> https://github.com/kovasb/paredit-widget
>


> The bigger idea is that code editing should be available a la carte.
>
> Tying something as fundamental as code editing together with IDE concerns
> (file & project management, artifact generation, debugging, etc)  is a
> mistake with profound consequences.
>

That's an interesting idea. How would you envision interactions like "jump
to definition" or even auto-completion working in an editor decoupled from
ICE concerns?

-- 
-- 
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/groups/opt_out.

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

[John D. Hume]

On Mon, Aug 5, 2013 at 8:55 PM, John D. Hume wrote:

> ICE concerns?
>
IDE concerns.

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

kovasb, that looks really great. Could you modify it to allow passing in an 
existing JTextArea? Right now it appears to be instantiating its own, 
whereas I am using 
TextEditorPane,
 
which inherits JTextArea.

On Monday, August 5, 2013 9:51:15 PM UTC-4, kovasb wrote:
>
> I've just released paredit-widget, 
> https://github.com/kovasb/paredit-widget
>
> with the intention of creating a drop-in paredit solution for projects 
> like nightcode. Its still pretty experimental but might be an interesting 
> test case to try to integrate.
>
>
>
>
>
> On Sun, Aug 4, 2013 at 8:19 PM, Matthew Chadwick 
> 
> > wrote:
>
>> this is great!
>>
>> please please add structural editing (not simply bracket-matching in a 
>> text-editor, but direct manipulation of Clojure data structures (including 
>> code). I've been trying out some ideas in this area & would be happy to 
>> help out.
>>
>>
>> On Friday, August 2, 2013 11:03:03 PM UTC+10, Zach Oakes wrote:
>>>
>>> I’ve been working on a simple IDE for the past few months. It started as 
>>> an attempt to add Leiningen integration to Clooj, but eventually I decided 
>>> to start a new project from scratch. It is very alpha-quality, so please be 
>>> gentle:
>>>
>>> http://nightcode.info/
>>>
>>> Here’s what it has:
>>>
>>> -Written in Clojure (the UI is written with seesaw)
>>>
>>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>>
>>> -Built-in templates for several common types of Clojure and Java projects
>>>
>>> -Always-on REPL in the corner to try Clojure commands
>>>
>>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>>
>>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>>
>>> -Cool looking dark theme, because that’s trendy these days
>>>
>>> Here’s what it’s missing:
>>>
>>> -Fast build times (it launches Leiningen in a separate process, which is 
>>> slw...I plan on fixing this and would love any help)
>>>
>>> -Important editing features (code completion, text replace, etc)
>>>
>>> -Quick switching between recent files
>>>
>>> -Jump to definition, built-in documentation
>>>
>>> -Integration between editor and REPL (eval form or entire file)
>>>
>>> -Integration with git
>>> -Many other things -- please give me your thoughts!
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

[kovas boguta]

On Mon, Aug 5, 2013 at 6:55 PM, John D. Hume wrote:

> On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta wrote:
>
>> https://github.com/kovasb/paredit-widget
>>
>
>
>> The bigger idea is that code editing should be available a la carte.
>>
>> Tying something as fundamental as code editing together with IDE concerns
>> (file & project management, artifact generation, debugging, etc)  is a
>> mistake with profound consequences.
>>
>
> That's an interesting idea. How would you envision interactions like "jump
> to definition" or even auto-completion working in an editor decoupled from
> IDE concerns?
>

The IDE keeps track of what the global set of definitions is and where they
are. It can easily issue a command to the editor to scroll to a place, or
feed the editor a list of possible completions.

What is part of the editor API is an open question, but I think supporting
the basics for tooltips, syntax highlighting, autocompletion is good as
long as it is data-driven.

It would also make sense to have good integration between the editor and
the model (eg the parsley parse tree) so that one could easily direct the
editor to highlight a piece of the tree in a certain way, but I think the
model should sit outside the editor per se.

-- 
-- 
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/groups/opt_out.

ANN: paredit-widget, simple swing-based clojure paredit widget

[Zach Oakes]

Hi kovasb, I mentioned this in the other thread but it's best to ask here: Can 
you provide a way to pass an existing JTextArea to it, rather than 
instantiating your own?

-- 
-- 
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/groups/opt_out.

At Long Last Hoare

[Alan Shaw]

The "Misc" section, containing the Sieve of Eratosthenes and a highly
concurrent (and interesting) matrix multiplier, completes my
Clojure
core.async  port of the examples
from Hoare's 1978 Communicating Sequential Processes paper:

https://github.com/nodename/async-plgd

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

I just pushed 0.0.4 to the website. I received reports that it fixes the 
nightcode.lein error, but please let me know if anyone experiences 
otherwise.

On Friday, August 2, 2013 9:03:03 AM UTC-4, Zach Oakes wrote:
>
> I’ve been working on a simple IDE for the past few months. It started as 
> an attempt to add Leiningen integration to Clooj, but eventually I decided 
> to start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
>
> http://nightcode.info/
>
> Here’s what it has:
>
> -Written in Clojure (the UI is written with seesaw)
>
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>
> -Built-in templates for several common types of Clojure and Java projects
>
> -Always-on REPL in the corner to try Clojure commands
>
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>
> -ClojureScript integration (includes the lein-cljsbuild plugin)
>
> -Cool looking dark theme, because that’s trendy these days
>
> Here’s what it’s missing:
>
> -Fast build times (it launches Leiningen in a separate process, which is 
> slw...I plan on fixing this and would love any help)
>
> -Important editing features (code completion, text replace, etc)
>
> -Quick switching between recent files
>
> -Jump to definition, built-in documentation
>
> -Integration between editor and REPL (eval form or entire file)
>
> -Integration with git
> -Many other things -- please give me your thoughts!
>

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

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

[kovas boguta]

Thanks for the feedback. I just extended the paredit-widget function to be
able to consume pre-existing widgets:

(p/paredit-widget (javax.swing.JTextArea. "(foo bar)"))

fyi right now the implementation isn't taking advantage of parsley's
incremental parsing support, and instead is reparsing the text with every
paredit command execution. This might be an issue for big files, but is
fixable.


On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
>
> Hi kovasb, I mentioned this in the other thread but it's best to ask
here: Can you provide a way to pass an existing JTextArea to it, rather
than instantiating your own?
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/groups/opt_out.