date:20130805

(defmacro foo
  [c]
  `(! ~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 ! isn't visible to go.
What am I missing?

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

2013-08-05 Thread Phillip Lord

Anthony Grimes disciplera...@gmail.com 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

Alice dofflt...@gmail.com writes:

 (defmacro foo
   [c]
   `(! ~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 ! isn't visible to go.
 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

2013-08-05 Thread Meikel Brandmeyer (kotarak)

Hi,

Am Montag, 5. August 2013 12:17:53 UTC+2 schrieb Alice:

 (defmacro foo
   [c]
   `(! ~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 ! isn't visible to go.
 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

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 doff...@gmail.com javascript: writes: 

  (defmacro foo 
[c] 
`(! ~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 ! isn't visible to go. 
  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

Alice dofflt...@gmail.com 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 ?

2013-08-05 Thread 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 discip...@gmail.com javascript: 
 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.htmlhttp://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.

Re: Can we please deprecate the :use directive ?

2013-08-05 Thread Mikera

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

 Anthony Grimes discip...@gmail.com javascript: 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 likeuse 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 ?

2013-08-05 Thread 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 ?

2013-08-05 Thread 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

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 t...@gnu.org wrote:

 Alice dofflt...@gmail.com 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

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 doff...@gmail.com javascript: 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

2013-08-05 Thread 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

2013-08-05 Thread 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 
 exampleshttps://github.com/clojure/core.typed/tree/master/examples/async
 .
 - companion 
 namespacehttps://github.com/clojure/core.typed/blob/master/src/main/clojure/clojure/core/typed/async.clj

 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 
 changeloghttps://github.com/clojure/core.typed/blob/master/CHANGELOG.md
 .

 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

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 ts...@gnu.org 
 javascript:wrote:

 Alice doff...@gmail.com javascript: 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.comjavascript:
 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 javascript:
 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 javascript:.
 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

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 dofflt...@gmail.com 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 ts...@gnu.org wrote:

 Alice doff...@gmail.com 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=enhttp://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_outhttps://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

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 doff...@gmail.com javascript: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 ts...@gnu.org wrote:

 Alice doff...@gmail.com 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=enhttp://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_outhttps://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.comjavascript:
 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 javascript:
 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 javascript:.
 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 ?

 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 mike.r.anderson...@gmail.com 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 ?

 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 g...@kinostudios.com 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 mike.r.anderson...@gmail.com 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

2013-08-05 Thread 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 
 tomfau...@gmail.comjavascript:
  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/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.comjavascript:
 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 javascript:
 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 javascript:.

 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

This works fine on my box:

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

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 dofflt...@gmail.com 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 doff...@gmail.com 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)

`(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 ts...@gnu.org wrote:

Alice doff...@gmail.com 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=enhttp://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_outhttps://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=enhttp://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_outhttps://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)

--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful

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

Alice dofflt...@gmail.com 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 doff...@gmail.com javascript: 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

2013-08-05 Thread 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 jakub.h...@iterate.no 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 tomfau...@gmail.comwrote:

 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/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=enhttp://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_outhttps://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 ?

2013-08-05 Thread Phillip Lord

Greg g...@kinostudios.com 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

2013-08-05 Thread 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 
 exampleshttps://github.com/clojure/core.typed/tree/master/examples/async
 .
 - companion 
 namespacehttps://github.com/clojure/core.typed/blob/master/src/main/clojure/clojure/core/typed/async.clj

 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 
 changeloghttps://github.com/clojure/core.typed/blob/master/CHANGELOG.md
 .

 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

2013-08-05 Thread 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 ?

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 phillip.l...@newcastle.ac.uk wrote:

 Greg g...@kinostudios.com writes:
 It's pretty ugly

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

2013-08-05 Thread 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.

2013-08-05 Thread 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 ?

* 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 g...@kinostudios.com 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, but we already 
 had those before.
 
 Please also explain at the same time, why (use 'core.matrix)

Re: Incanter 1.5.2 has been released

2013-08-05 Thread 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 jakub...@iterate.nojavascript:
  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 tomfau...@gmail.comwrote:

 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/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=enhttp://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_outhttps://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 javascript:.

 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 ?

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 g...@kinostudios.com 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 g...@kinostudios.com 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

Re: Can we please deprecate the :use directive ?


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

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


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

2013-08-05 Thread Mark Engelberg

On Mon, Aug 5, 2013 at 9:32 AM, Lee Spector lspec...@hampshire.edu 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

2013-08-05 Thread 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

 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 lspec...@hampshire.edu 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 ?


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 discip...@gmail.com 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

2013-08-05 Thread 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 mingli.y...@gmail.com 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


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


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

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 dnolen.li...@gmail.com 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 mingli.y...@gmail.comwrote:

 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

 (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 lspec...@hampshire.edu 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

 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 g...@kinostudios.com 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 lspec...@hampshire.edu 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

2013-08-05 Thread Tim Visher

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

On Mon, Aug 5, 2013 at 9:21 AM, Chas Emerick c...@cemerick.com 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

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 g...@kinostudios.com 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 g...@kinostudios.com 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 lspec...@hampshire.edu 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

Re: [Proposal] Simplified 'ns' declaration

 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 tbaldri...@gmail.com 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 g...@kinostudios.com 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 g...@kinostudios.com 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

Re: [Proposal] Simplified 'ns' declaration

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 g...@kinostudios.com 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 tbaldri...@gmail.com
 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 g...@kinostudios.com 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

Re: [Proposal] Simplified 'ns' declaration

2013-08-05 Thread 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 tbaldri...@gmail.comwrote:

 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 g...@kinostudios.com 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 tbaldri...@gmail.com
 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 g...@kinostudios.com 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

Re: [Proposal] Simplified 'ns' declaration

2013-08-05 Thread Mark Engelberg

On Mon, Aug 5, 2013 at 11:14 AM, Timothy Baldridge tbaldri...@gmail.comwrote:

 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


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

2013-08-05 Thread 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 tbaldri...@gmail.comwrote:

 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 g...@kinostudios.com 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 tbaldri...@gmail.com
 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

Re: [Proposal] Simplified 'ns' declaration

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 odysso...@gmail.com 
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 
 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 tbaldri...@gmail.com 
 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 g...@kinostudios.com 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

Re: [Proposal] Simplified 'ns' declaration

2013-08-05 Thread 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 ?

2013-08-05 Thread 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 lspec...@hampshire.edu 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.
 
 
 
--
Softaddictslprefonta...@softaddicts.ca 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

Mark Engelberg mark.engelb...@gmail.com 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

2013-08-05 Thread 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 mark.engelb...@gmail.comwrote:

 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

2013-08-05 Thread 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 mark.engelb...@gmail.com javascript:; 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.comjavascript:;
 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 javascript:;
 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 javascript:;.
 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

2013-08-05 Thread 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 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.comjavascript:;
 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 javascript:;
 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 javascript:;.
 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

2013-08-05 Thread 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 twash...@gmail.comwrote:

 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: [Proposal] Simplified 'ns' declaration

2013-08-05 Thread 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 javascript: 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

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 zso...@gmail.com javascript:

 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.comjavascript:
 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 javascript:
 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 javascript:.
 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

2013-08-05 Thread 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

2013-08-05 Thread 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

2013-08-05 Thread 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.

2013-08-05 Thread 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

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.


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

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 mathn...@gmail.com 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

2013-08-05 Thread John D. Hume

On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta kovas.bog...@gmail.com 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] Nightcode, an IDE for Clojure and Java

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 
TextEditorPanehttp://javadoc.fifesoft.com/rsyntaxtextarea/org/fife/ui/rsyntaxtextarea/TextEditorPane.html,
 
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 
 math...@gmail.comjavascript:
  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.comjavascript:
 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 javascript:
 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 javascript:.
 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

On Mon, Aug 5, 2013 at 6:55 PM, John D. Hume duelin.mark...@gmail.comwrote:

 On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta kovas.bog...@gmail.comwrote:

 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

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

2013-08-05 Thread Alan Shaw

The Misc section, containing the Sieve of Eratosthenes and a highly
concurrent (and interesting) matrix multiplier, completes my
Clojurehttp://twitter.com/search?q=%23Clojure
core.async http://twitter.com/search?q=%23coreasync 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

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