Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Michael Klishin
2013/7/24 Ye He 

> But you can't force people not to use :use without :only, and the tool I
> mentioned will replace that kind of misuses.


I'd start by adding a scary warning to the compiler first,
and then remove support for :use in a couple of versions.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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-07-23 Thread Ye He
Sorry, It's a typo. What I mean is it can be replaced. But you can't force 
people not to use :use without :only, and the tool I mentioned will replace 
that kind of misuses.
-- 
Regards,
Ye He

On 24 July 2013 at 4:46:44 PM, Michael Klishin (michael.s.klis...@gmail.com) 
wrote:


2013/7/24 Ye He 
Well, obviously :use can't be replaced by (require :refer).

Are you sure? require with :refer :all does exactly what :use does as far as I 
know.
 
According to DRY, I strongly agree the deprecation of :use. But that doesn't 
mean interpreter shouldn't support it right now since we have legacy code base. 
However, we could come to an agreement to less use of :use.

That's what "deprecate" means.
--  
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin
--  
--  
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 a topic in the Google 
Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/i2VzAlT6oqM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Michael Klishin
2013/7/24 Ye He 

> Well, obviously :use can't be replaced by (require :refer).


Are you sure? require with :refer :all does exactly what :use does as far
as I know.


> According to DRY, I strongly agree the deprecation of :use. But that
> doesn't mean interpreter shouldn't support it right now since we have
> legacy code base. However, we could come to an agreement to less use of
> :use.


That's what "deprecate" means.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: cannot import namespace reducers

2013-07-23 Thread Johannes Brauer
if I remember correctly I solved the problem by reinstalling Java 7 from 
Oracle. Thereafter my $JAVA_HOME points to:
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home

Johannes
Am 24.07.2013 um 03:02 schrieb Keith Maynard 
mailto:kpmayn...@gmail.com>>
:

Please spam the list!!! I am sure anyone who receives that message is probably 
running Mac OS X 10.7.x or later and trying to unravel the mess between Java 6 
and Java 7.  Please post recommendations. I finally got Eclipse to see the 
jdl1.7.0_25.jdk now how do I get the OS to replace the Apple installed 1.6.x?

On Sunday, 16 June 2013 17:29:40 UTC-4, Las wrote:

Then you are having a path problem.
Your lein is still using java6
Check your $PATH and $JAVA_HOME env. variables.

As this not strictly clojure related, let's not spam the list, im happy to help 
off list

Sent from my phone

On Jun 16, 2013 11:22 PM, "Johannes Brauer"  wrote:
I am on clojure 1.5.1 and I use lein repl.

But after

(require '[clojure.core.reducers :as r])

I still get the same error message as with Java 6:
CompilerException java.lang.ClassNotFoundException: jsr166y.ForkJoinPool, 
compiling:(clojure/core/reducers.clj:56:21)

A second input of
(require '[clojure.core.reducers :as r])

generates the message:
Exception namespace 'clojure.core.reducers' not found  clojure.core/load-lib 
(core.clj:5380)

Johannes

Am 16.06.2013 um 23:16 schrieb László Török 
:

are you on clojure 1.5+ ?

If I launch the REPL using "lein repl"

and then

(require 'clojure.core.reducers)

it works ok for me.


2013/6/16 Johannes Brauer 
now, I've Java 7 installed and get another error message:
Exception namespace 'clojure.core.reducers' not found  clojure.core/load-lib 
(core.clj:5380)

any further hints?

Johannes
Am 16.06.2013 um 22:43 schrieb Johannes Brauer 
:

thank you, Las, for the quick tip. I will give Java 7 a try. I hope there are 
no problems on Mac OS 10.8.4

Johannes
Am 16.06.2013 um 22:15 schrieb László Török 
:

.. sorry, gmail's new annoying keyboard shortcut

b) include the dependency to the forkjoin library [1] that is not included in 
Java6

Las

[1] http://mavenhub.com/mvn/central/org.coconut.forkjoin/jsr166y/070108


2013/6/16 László Török 
Hi,

there are two ways to deal with this:

a) use Java 7


2013/6/16 Johannes 
Hi,

trying
(require '[clojure.core.reducers :as r])
at the repl prompt the error message
CompilerException java.lang.ClassNotFoundException: jsr166y.ForkJoinPool, 
compiling:(clojure/core/reducers.clj:56:21)

What is going wrong?

Johannes



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





--
László Török



--
László Török

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







Staatlich anerkannte private Fachhochschule
NORDAKADEMIE
Gemeinnützige Aktiengesellschaft
Köllner Chaussee 11
25337 Elmshorn

Vorstand:
Prof. Dr. Georg Plate (Vorsitzender), Dipl.-Ing. Jörg Meier (stellv. Vorstand)

Vorsitzender des Aufsichtsrats:
Dr. h.c. Hans-Heinrich Bruns

Sitz:
Elmshorn, Amtsgericht Pinneberg, HRB 1682


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

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Baishampayan Ghose
Lee,

For that use-case, you can always use something like (:require the-ns
:refer :all).

Regards,
BG

On Wed, Jul 24, 2013 at 1:27 AM, Lee Spector  wrote:
>
> On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote:
>
>> Yea, I have a single namespace with project-specific common utilities which 
>> I refer to as u/some-util-function.  For me, it's a bit scary to have 
>> implicit symbols in scope.  A typo can make a local binding refer to 
>> something that might not exist in production, or at least not what's 
>> intended. Conversely, I don't want extra code in my project that has nothing 
>> to do with the project.  Seems useful to enforce a separation of the 
>> artifact from the tools that made it, more-so for a lib that other things 
>> depend on than a production app.
>>
>> The 'user' namespace can cover the use-case of convenience functions?
>>
>> Or, you can add those symbols dynamically at run-time when you need to with 
>> something like:
>> https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26
>>
>> or some aggregated (require ..) calls.
>>
>
> I'm sure I'm coming from a minority perspective on this, but for the kind of 
> work I do it's often more important to be able to quickly sketch out and test 
> ideas, without any ceremony about which functions come from where, than it is 
> to ensure safety in a "production" environment which is really just me 
> running it right now.
>
> In fact I'd sometimes like to go the other way and use everything in a whole 
> directory subtree, or even to get rid of "using" altogether and have the 
> runtime system find the function wherever it can (within reason :-) and let 
> me know if it can't or if there's a conflict.
>
> I do understand that there are a great many programming contexts in which it 
> would be foolish and dangerous to manage references so loosely and implicitly 
> and dynamically. In fact it's a bad idea in some of my work too, so I'm 
> slightly more disciplined than this some of the time.
>
> But my point is just that different users will have different priorities, and 
> from where I sit, at least, it'd be nice to keep :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.
>
>



-- 
Baishampayan Ghose
b.ghose at gmail.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 ?

2013-07-23 Thread Ye He
Well, obviously :use can't be replaced by (require :refer). According to 
DRY, I strongly agree the deprecation of :use. But that doesn't mean 
interpreter shouldn't support it right now since we have legacy code base. 
However, we could come to an agreement to less use of :use. It's trivial to 
obey the rule with the help of some automation tools like Slamhound 
https://github.com/technomancy/slamhound which generates namespace import 
for you (of course, without :use). So why bother to use :use? My own 
experience when encountering the situation that I have to guess where a 
function belongs to is that I run Slamhound once and get a better ns 
declaration, then if I'm not allowed to change the code base, I revert it 
back.

On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg Slepak wrote:
>
> I think I read somewhere that :use is no longer encouraged, but I could be 
> mistaken. 
>
> From what I've read, it seems like most people agree that Clojure has too 
> many ways of including/importing/referencing/requiring/using things: 
>
>
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>  
>
> The above gives a very nice explanation of all the various difference, but 
> it also acknowledges their complexity. 
>
> Since :use uses :require, and since :require can do everything that :use 
> can, can we simplify Clojure programming a bit for newcomers by deprecating 
> the use of :use? The situation in ClojureScript is even worse because it 
> adds :require-macros on top of all the other ways of including files. 
>
> Ideally, it would be awesome if there was just a single directive for 
> everything, but perhaps there's some complicated low-level reason why 
> that's not possible. :-\ 
>
> Thoughts? 
>
> Thanks, 
> Greg 
>
> P.S. If this has already been brought up you have my sincere apologies. 
>
> -- 
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA. 
>
>

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




Re: [ANN] verily, non-magic testing lib

2013-07-23 Thread Steven Degutis
It's been brought to my attention that this project is an utter waste of
time, brings no real improvement over the existing solutions, and was
wrought in complete arrogance. So I've deleted the project. Sorry for
wasting a thread on this.


On Wed, Jul 24, 2013 at 12:30 AM, Steven Degutis wrote:

> Whoops. Looks like I didn't check the namespace well enough, there's
> already a lib called "verily". (Sorry Justin.)
>
> Will think up a new name soon.
>
>
> On Tue, Jul 23, 2013 at 11:55 PM, Steven Degutis wrote:
>
>> https://github.com/evanescence/verily
>>
>> Verily is a new testing lib with a few goals:
>>
>>- Build off existing Clojure concepts (functions, vars, etc)
>>- Be as functional/immutable as possible
>>- Be easy to use from terminal or REPL
>>- Have composable pieces that are easy to swap out
>>- Keep running tests separate from reporting the results
>>
>>
>> Some upcoming features:
>>
>>- Some convenience functions for assertions
>>- Better reports
>>
>> -Steven
>>
>
>

-- 
-- 
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] verily, non-magic testing lib

2013-07-23 Thread Steven Degutis
Whoops. Looks like I didn't check the namespace well enough, there's
already a lib called "verily". (Sorry Justin.)

Will think up a new name soon.


On Tue, Jul 23, 2013 at 11:55 PM, Steven Degutis wrote:

> https://github.com/evanescence/verily
>
> Verily is a new testing lib with a few goals:
>
>- Build off existing Clojure concepts (functions, vars, etc)
>- Be as functional/immutable as possible
>- Be easy to use from terminal or REPL
>- Have composable pieces that are easy to swap out
>- Keep running tests separate from reporting the results
>
>
> Some upcoming features:
>
>- Some convenience functions for assertions
>- Better reports
>
> -Steven
>

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




Confused again by core.async

2013-07-23 Thread Alan Shaw
Hi,
I hope I can get a lightbulb on what's happening here:

https://github.com/nodename/async-plgd/blob/master/src/hoare/problem.clj

Testing fan-in on a pair of processes and getting nutty results.

Thanks,

-A

-- 
-- 
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] verily, non-magic testing lib

2013-07-23 Thread Steven Degutis
https://github.com/evanescence/verily

Verily is a new testing lib with a few goals:

   - Build off existing Clojure concepts (functions, vars, etc)
   - Be as functional/immutable as possible
   - Be easy to use from terminal or REPL
   - Have composable pieces that are easy to swap out
   - Keep running tests separate from reporting the results


Some upcoming features:

   - Some convenience functions for assertions
   - Better reports

-Steven

-- 
-- 
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-07-23 Thread John Gabriele
On Tuesday, July 23, 2013 11:50:50 AM UTC-4, Greg Slepak wrote:
>
> I think I read somewhere that :use is no longer encouraged, but I could be 
> mistaken. 
>
> From what I've read, it seems like most people agree that Clojure has too 
> many ways of including/importing/referencing/requiring/using things: 
>
>
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>  
>
> The above gives a very nice explanation of all the various difference, but 
> it also acknowledges their complexity. 
>
> Since :use uses :require, and since :require can do everything that :use 
> can, can we simplify Clojure programming a bit for newcomers by deprecating 
> the use of :use? The situation in ClojureScript is even worse because it 
> adds :require-macros on top of all the other ways of including files. 
>
> Ideally, it would be awesome if there was just a single directive for 
> everything, but perhaps there's some complicated low-level reason why 
> that's not possible. :-\ 
>
> Thoughts? 
>
>
I find that use of `:use` makes code more difficult to read.

Names from clojure.core are written without the namespace; everything else 
I expect to see a namespace in front to provide context.

Yes, I also write dates like -MM-DD. :)

-- John

-- 
-- 
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: cannot import namespace reducers

2013-07-23 Thread Keith Maynard
Please spam the list!!! I am sure anyone who receives that message is 
probably running Mac OS X 10.7.x or later and trying to unravel the mess 
between Java 6 and Java 7.  Please post recommendations. I finally got 
Eclipse to see the jdl1.7.0_25.jdk now how do I get the OS to replace the 
Apple installed 1.6.x?

On Sunday, 16 June 2013 17:29:40 UTC-4, Las wrote:
>
> Then you are having a path problem. 
> Your lein is still using java6
> Check your $PATH and $JAVA_HOME env. variables. 
>
> As this not strictly clojure related, let's not spam the list, im happy to 
> help off list
>
> Sent from my phone
> On Jun 16, 2013 11:22 PM, "Johannes Brauer" 
> > 
> wrote:
>
>>  I am on clojure 1.5.1 and I use lein repl. 
>>
>>  But after  
>>
>>  (require '[clojure.core.reducers :as r])
>>
>>  I still get the same error message as with Java 6:
>> CompilerException java.lang.ClassNotFoundException: jsr166y.ForkJoinPool, 
>> compiling:(clojure/core/reducers.clj:56:21)
>>
>>  A second input of
>> (require '[clojure.core.reducers :as r])
>>
>>  generates the message:
>> Exception namespace 'clojure.core.reducers' not found 
>>  clojure.core/load-lib (core.clj:5380)
>>
>>  Johannes
>>
>>  Am 16.06.2013 um 23:16 schrieb László Török 
>> >
>> :
>>
>>  are you on clojure 1.5+ ? 
>>
>>  If I launch the REPL using "lein repl"
>>
>>  and then
>>
>>  (require 'clojure.core.reducers)
>>  
>>  it works ok for me.
>>  
>>
>> 2013/6/16 Johannes Brauer >
>>
>>> now, I've Java 7 installed and get another error message: 
>>> Exception namespace 'clojure.core.reducers' not found 
>>>  clojure.core/load-lib (core.clj:5380)
>>>
>>>  any further hints?
>>>  
>>>  Johannes
>>>   Am 16.06.2013 um 22:43 schrieb Johannes Brauer 
>>> 
>>> >
>>> :
>>>  
>>>  thank you, Las, for the quick tip. I will give Java 7 a try. I hope 
>>> there are no problems on Mac OS 10.8.4 
>>>
>>>  Johannes
>>>  Am 16.06.2013 um 22:15 schrieb László Török 
>>> >
>>> :
>>>
>>>  .. sorry, gmail's new annoying keyboard shortcut 
>>>
>>>  b) include the dependency to the forkjoin library [1] that is not 
>>> included in Java6 
>>>
>>>  Las
>>>
>>>  [1] http://mavenhub.com/mvn/central/org.coconut.forkjoin/jsr166y/070108
>>>  
>>>
>>> 2013/6/16 László Török >
>>>
 Hi, 

  there are two ways to deal with this:

  a) use Java 7
   

 2013/6/16 Johannes >

> Hi, 
>
>  trying
>  (require '[clojure.core.reducers :as r])
> at the repl prompt the error message
> CompilerException java.lang.ClassNotFoundException: 
> jsr166y.ForkJoinPool, compiling:(clojure/core/reducers.clj:56:21) 
>  
>  What is going wrong?
>
>  Johannes
>
>  
>  
>  -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient 
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
  


   -- 
 László Török
  
>>>  
>>>
>>>
>>>  -- 
>>> László Török
>>>  
>>>  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>>  
>>>  
>>> --
>>>
>>>
>>> Staatlich anerkannte private Fachhochschule
>>> NORDAKADEMIE
>>> Gemeinnützige Aktiengesellschaft
>>> Köllner Chaussee 11
>>> 25337 Elmshorn
>>>
>>> Vorstand:
>>> Prof. Dr. Georg Plate (Vorsitzender), Dipl.-Ing. Jörg Meier (stellv. 
>>> Vorstand)
>>>
>>> Vorsitzender des Aufsichtsrats:
>>> Dr. h.c. Hans-Heinrich Bruns
>>>
>>> Sitz:
>>> Elmshorn, Amtsgericht Pinneberg, HRB 1682
>>>
>>>  
>>>  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo..

Re: Can't get namespace metadata

2013-07-23 Thread Colin Fleming
As an aside from this, how problematic is AOT compilation? It seems to be
the source of many bugs (for example, my own
CLJ-1227).
Is there a list anywhere of things to watch out for when AOT compiling?


On 24 July 2013 04:06, Stuart Sierra  wrote:

> I can confirm this behavior. It's not the fault of the `ns`
> macro, however. This works just fine:
>
> user=> (ns ^{:doc "This is foo"} foo)
> nil
> foo=> (in-ns 'user)
> #
> user=> (meta (the-ns 'foo))
> {:doc "This is foo"}
>
> AOT-compilation appears to be the culprit (as usual). This
> has been known for a long time, see CLJ-130, which I just
> updated.
>
> [CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130
>
> -S
>
>
>
>
>
> On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
>>
>> Example:
>>
>> user=> (meta (find-ns 'clojure.set))
>> nil
>> user=> (meta (find-ns 'clojure.string))
>> nil
>> user=> (meta (find-ns 'clojure.core))
>> {:doc "Fundamental library of the Clojure language"}
>>
>> clojure.core is the only namespace that has metadata. Apparently because
>> it has metadata set differently https://github.com/clojure/**
>> clojure/blob/master/src/clj/**clojure/core.clj#L6158,
>> so I blame *ns *macro.
>>
>> I tested this with clojure 1.2-1.5, so it is not a regression, and unless
>> I'm doing something wrong, this was broken from the beginning.
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Sean Corfield
On Tue, Jul 23, 2013 at 2:13 PM, Ben Wolfson  wrote:
> If that's all that's required for one thing to complect two others,
> clojure's rife with the stuff. if-let complects if and let. Destructuring
> assignment complects assignment and getting values from a data structure (as
> the macroexpansion of (let [[a b] x]) demonstrates.

Those examples provide an overall simplification for common
constructs. As the 'use' docstring says, it is "Like 'require, but
also refers to each lib's namespace using clojure.core/refer." so it
explicitly combines two already somewhat complex operations.

When we added :refer to 'require' we also complected things but we
improved expressiveness and we allowed the overall 'ns' construct to
be more uniform and consistent so I think, on balance, that was a win
(and I certainly like having one construct - :require - in my ns
declarations rather than a mix of :use and :require). We probably
should have taken that opportunity to deprecate :use at the same time
but as I recall, :refer was added very late in the cycle and arguing
over deprecating :use would have detracted from the discussion of the
utility of adding :refer to :require in the first place.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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-07-23 Thread Stefan Kamphausen


On Tuesday, July 23, 2013 11:13:11 PM UTC+2, Ben wrote:
>
> On Tue, Jul 23, 2013 at 1:55 PM, Sean Corfield 
> 
> > wrote:
>
>> On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson > 
>> wrote:
>> > On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen 
>> > 
>> >
>> > wrote:
>> >> It complects require and refer ;-)
>> > How so?
>>
>> Because use = require + refer (essentially).
>>
>
> If that's all that's required for one thing to complect two others, 
> clojure's rife with the stuff. if-let complects if and let. Destructuring 
> assignment complects assignment and getting values from a data structure 
> (as the macroexpansion of (let [[a b] x]) demonstrates. split-with 
> complects take-while and drop-while. let complects lambda abstraction and 
> function application. Etc. I had assumed that "a complects b and c" on the 
> one hand meant more than "a can be expressed using b and c" and on the 
> other was a criticism.
>


you're right.  I did not think a lot before writing the above.  Please, 
don't take it too seriously.


Kind regards,
Stefan

-- 
-- 
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-07-23 Thread Laurent PETIT
2013/7/23 Softaddicts :
> Maybe we need an simpler alternative to the ns macro without all
> these complex options :)
>
> With a short name like ns-stop-banging-your-head-on-the-wall :)

would violate the "rule" use often => short name ;-)

>
> Or the reverse, ns-make-your-life-more-chaotic...

Deal :-D

>
> :)
>
> Luc P.
>
>> It's not as if *some* (cough cough) parts of Clojure were'nt
>> opinionated, right? :-)
>>
>> Having in the (ns) macro the possibility to use :use, to use :require,
>> to use :refer-clojure, to use :require-macros can be daunting, and not
>> only for newcomers!
>>
>> And not to mention that the vast majority of the docstring for ns
>> talks about :gen-class defaults !
>>
>> And all this choice for only historical reasons is not opinionated
>> enough for my taste!
>>
>> I'd be willing too, to deprecate a couple things:
>>
>> :use :all in favor of :require :all
>> :use :only in favor of :require :only
>>
>> Let's be opinionated! :-D
>>
>> I think that's the only subset that has a chance to pass without
>> having to gather a commitee at the next Clojure-conj ;-)
>>
>>
>> 2013/7/23 Softaddicts :
>> > None of what has been said so far makes me believe that our usage of
>> > "use" is "bad". It's like a rope, you can use it for useful purposes or 
>> > you can
>> > hang yourself. You use it at your own taste and will.
>> >
>> > Lack of discipline does not constitute for me a reason to trash a feature 
>> > as scarce
>> > as his usefulness seems to be.
>> >
>> > :refer :all can be used as badly as :use.
>> >
>> > I am not convinced that removing a facade and leaving the feature available
>> > through a backdoor makes life better for anyone. :use is easily searchable 
>> > and
>> > quite obvious. Not sure about spotting :refer :all in 15 name space require
>> > clauses.
>> >
>> > You will simply end up say "do not use refer all" instead
>> > of warning against using use.
>> >
>> > Gee, What a lot of "use"s in this thread :)
>> >
>> > Luc P.
>> >
>> >> One of the main issues I have faced with :use is, understanding a
>> >> non-trivial codebase becomes very difficult and almost always requires
>> >> Emacs Meta-dot.
>> >>
>> >> I'd vote for deprecating :use.
>> >>
>> >> Shantanu
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with 
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google Groups 
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an 
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >>
>> > --
>> > Softaddicts sent by ibisMail from my ipad!
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with 
>> > your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google Groups 
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscr

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Softaddicts
Maybe we need an simpler alternative to the ns macro without all
these complex options :)

With a short name like ns-stop-banging-your-head-on-the-wall :)

Or the reverse, ns-make-your-life-more-chaotic...

:)

Luc P.

> It's not as if *some* (cough cough) parts of Clojure were'nt
> opinionated, right? :-)
> 
> Having in the (ns) macro the possibility to use :use, to use :require,
> to use :refer-clojure, to use :require-macros can be daunting, and not
> only for newcomers!
> 
> And not to mention that the vast majority of the docstring for ns
> talks about :gen-class defaults !
> 
> And all this choice for only historical reasons is not opinionated
> enough for my taste!
> 
> I'd be willing too, to deprecate a couple things:
> 
> :use :all in favor of :require :all
> :use :only in favor of :require :only
> 
> Let's be opinionated! :-D
> 
> I think that's the only subset that has a chance to pass without
> having to gather a commitee at the next Clojure-conj ;-)
> 
> 
> 2013/7/23 Softaddicts :
> > None of what has been said so far makes me believe that our usage of
> > "use" is "bad". It's like a rope, you can use it for useful purposes or you 
> > can
> > hang yourself. You use it at your own taste and will.
> >
> > Lack of discipline does not constitute for me a reason to trash a feature 
> > as scarce
> > as his usefulness seems to be.
> >
> > :refer :all can be used as badly as :use.
> >
> > I am not convinced that removing a facade and leaving the feature available
> > through a backdoor makes life better for anyone. :use is easily searchable 
> > and
> > quite obvious. Not sure about spotting :refer :all in 15 name space require
> > clauses.
> >
> > You will simply end up say "do not use refer all" instead
> > of warning against using use.
> >
> > Gee, What a lot of "use"s in this thread :)
> >
> > Luc P.
> >
> >> One of the main issues I have faced with :use is, understanding a
> >> non-trivial codebase becomes very difficult and almost always requires
> >> Emacs Meta-dot.
> >>
> >> I'd vote for deprecating :use.
> >>
> >> Shantanu
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google Groups 
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >>
> > --
> > Softaddicts sent by ibisMail from my ipad!
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Ben Wolfson
On Tue, Jul 23, 2013 at 1:55 PM, Sean Corfield wrote:

> On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson  wrote:
> > On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen 
> > wrote:
> >> It complects require and refer ;-)
> > How so?
>
> Because use = require + refer (essentially).
>

If that's all that's required for one thing to complect two others,
clojure's rife with the stuff. if-let complects if and let. Destructuring
assignment complects assignment and getting values from a data structure
(as the macroexpansion of (let [[a b] x]) demonstrates. split-with
complects take-while and drop-while. let complects lambda abstraction and
function application. Etc. I had assumed that "a complects b and c" on the
one hand meant more than "a can be expressed using b and c" and on the
other was a criticism.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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] London Clojure Dojo, Tuesday 30th July 2013

2013-07-23 Thread Philip Potter
Roll up! Roll up!

The next London Clojure dojo will be on Tuesday 30th July at
ThoughtWorks. Sign up here:

http://london-clj-dojo-july-2013-tw-ml.eventbrite.co.uk/

Hope to see lots of you there!

-- 
-- 
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: anaphoric macro?

2013-07-23 Thread eliassonaand
Thanks a lot guys, I'll try it out tomorrow.
Anders

-- 
-- 
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-07-23 Thread Laurent PETIT
It's not as if *some* (cough cough) parts of Clojure were'nt
opinionated, right? :-)

Having in the (ns) macro the possibility to use :use, to use :require,
to use :refer-clojure, to use :require-macros can be daunting, and not
only for newcomers!

And not to mention that the vast majority of the docstring for ns
talks about :gen-class defaults !

And all this choice for only historical reasons is not opinionated
enough for my taste!

I'd be willing too, to deprecate a couple things:

:use :all in favor of :require :all
:use :only in favor of :require :only

Let's be opinionated! :-D

I think that's the only subset that has a chance to pass without
having to gather a commitee at the next Clojure-conj ;-)


2013/7/23 Softaddicts :
> None of what has been said so far makes me believe that our usage of
> "use" is "bad". It's like a rope, you can use it for useful purposes or you 
> can
> hang yourself. You use it at your own taste and will.
>
> Lack of discipline does not constitute for me a reason to trash a feature as 
> scarce
> as his usefulness seems to be.
>
> :refer :all can be used as badly as :use.
>
> I am not convinced that removing a facade and leaving the feature available
> through a backdoor makes life better for anyone. :use is easily searchable and
> quite obvious. Not sure about spotting :refer :all in 15 name space require
> clauses.
>
> You will simply end up say "do not use refer all" instead
> of warning against using use.
>
> Gee, What a lot of "use"s in this thread :)
>
> Luc P.
>
>> One of the main issues I have faced with :use is, understanding a
>> non-trivial codebase becomes very difficult and almost always requires
>> Emacs Meta-dot.
>>
>> I'd vote for deprecating :use.
>>
>> Shantanu
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
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-07-23 Thread Lee Spector

On Jul 23, 2013, at 4:43 PM, Gary Trakhman wrote:
> 
> For instance, we have defrecords now, no one's going to reach for defstruct 
> because records are documented and promoted more thoroughly.  

FWIW I'm even a contrarian on defstruct :-! although I've switched to records 
anyway on account of speed.


On Jul 23, 2013, at 4:55 PM, Sean Corfield wrote:
> 
> Because use = require + refer (essentially).


Is using :refer :all semantically identical to using :use? Or does 
"essentially" have a gap here?
 
If it's identical then I guess I don't care much either way, although I'd 
prefer to stick with the shorter thing that's already in my code.

 -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: Can we please deprecate the :use directive ?

2013-07-23 Thread Sean Corfield
On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson  wrote:
> On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen 
> wrote:
>> It complects require and refer ;-)
> How so?

Because use = require + refer (essentially).
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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-07-23 Thread Ben Wolfson
On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen wrote:

>
> It complects require and refer ;-)
>

How so?

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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-07-23 Thread Stefan Kamphausen


On Tuesday, July 23, 2013 9:42:39 PM UTC+2, Shantanu Kumar wrote:
>
> One of the main issues I have faced with :use is, understanding a 
> non-trivial codebase becomes very difficult and almost always requires 
> Emacs Meta-dot.


which is particularly annoying when you read code on a blog (as mentioned 
by the OP) or on paper 
 

>
> I'd vote for deprecating :use.
>
> inc

It complects require and refer ;-)

stefan 

-- 
-- 
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-07-23 Thread Gary Trakhman
I think what we're proposing is not about removing the capability to do
'use'.  That will remain, it's clojure after all.  You could also implement
it yourself easily enough.  The issue is whether it's worthwhile to have it
as a core function, without some kind of notice that better things exist.

For instance, we have defrecords now, no one's going to reach for defstruct
because records are documented and promoted more thoroughly.  But 'use' is
more pervasive, and also 'easier'.  As the language grows, it'll be good
for newcomers to have less things to think about, so deprecation is a way
to counter bad inertia.

The damage of 'use' is also less visible on the small scale, so that's why
it's hard to make an argument about it.  :require is proportionately more
verbose for an effect.  Use's verbosity is inversely proportional to its
effect, so it takes extra effort to limit its effects.

A limited scope by default is what I mean by 'good', for similar reasons
that clojure goes with 'immutability by default'.


On Tue, Jul 23, 2013 at 3:57 PM, Lee Spector  wrote:

>
> On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote:
>
> > Yea, I have a single namespace with project-specific common utilities
> which I refer to as u/some-util-function.  For me, it's a bit scary to have
> implicit symbols in scope.  A typo can make a local binding refer to
> something that might not exist in production, or at least not what's
> intended. Conversely, I don't want extra code in my project that has
> nothing to do with the project.  Seems useful to enforce a separation of
> the artifact from the tools that made it, more-so for a lib that other
> things depend on than a production app.
> >
> > The 'user' namespace can cover the use-case of convenience functions?
> >
> > Or, you can add those symbols dynamically at run-time when you need to
> with something like:
> >
> https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26
> >
> > or some aggregated (require ..) calls.
> >
>
> I'm sure I'm coming from a minority perspective on this, but for the kind
> of work I do it's often more important to be able to quickly sketch out and
> test ideas, without any ceremony about which functions come from where,
> than it is to ensure safety in a "production" environment which is really
> just me running it right now.
>
> In fact I'd sometimes like to go the other way and use everything in a
> whole directory subtree, or even to get rid of "using" altogether and have
> the runtime system find the function wherever it can (within reason :-) and
> let me know if it can't or if there's a conflict.
>
> I do understand that there are a great many programming contexts in which
> it would be foolish and dangerous to manage references so loosely and
> implicitly and dynamically. In fact it's a bad idea in some of my work too,
> so I'm slightly more disciplined than this some of the time.
>
> But my point is just that different users will have different priorities,
> and from where I sit, at least, it'd be nice to keep :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.
>
>
>

-- 
-- 
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-07-23 Thread Softaddicts
None of what has been said so far makes me believe that our usage of
"use" is "bad". It's like a rope, you can use it for useful purposes or you can
hang yourself. You use it at your own taste and will.

Lack of discipline does not constitute for me a reason to trash a feature as 
scarce
as his usefulness seems to be. 

:refer :all can be used as badly as :use.

I am not convinced that removing a facade and leaving the feature available
through a backdoor makes life better for anyone. :use is easily searchable and
quite obvious. Not sure about spotting :refer :all in 15 name space require
clauses.

You will simply end up say "do not use refer all" instead
of warning against using use.

Gee, What a lot of "use"s in this thread :)

Luc P.

> One of the main issues I have faced with :use is, understanding a 
> non-trivial codebase becomes very difficult and almost always requires 
> Emacs Meta-dot.
> 
> I'd vote for deprecating :use.
> 
> Shantanu
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Sean Corfield
On Tue, Jul 23, 2013 at 12:57 PM, Lee Spector  wrote:
> I'm sure I'm coming from a minority perspective on this, but for the kind of 
> work I do it's often more important to be able to quickly sketch out and test 
> ideas, without any ceremony about which functions come from where, than it is 
> to ensure safety in a "production" environment which is really just me 
> running it right now.
>
> In fact I'd sometimes like to go the other way and use everything in a whole 
> directory subtree, or even to get rid of "using" altogether and have the 
> runtime system find the function wherever it can (within reason :-) and let 
> me know if it can't or if there's a conflict.
>
> I do understand that there are a great many programming contexts in which it 
> would be foolish and dangerous to manage references so loosely and implicitly 
> and dynamically. In fact it's a bad idea in some of my work too, so I'm 
> slightly more disciplined than this some of the time.
>
> But my point is just that different users will have different priorities, and 
> from where I sit, at least, it'd be nice to keep :use.

Well, you can always use (require '[some.ns :refer :all]) instead of
(use 'some.ns) but I recognize the former is a lot more typing.

Certainly in the REPL, working in the user ns, I can see a good
argument for (use 'some.ns) while you're evolving a solution, but I
think :use in the ns macro should be deprecated (i.e., :use should at
some point go away but perhaps the use function should stay for
REPL-based exploration?).

Tightening up the ns macro so it issues warning for undocumented
constructs would also be a good idea:

(ns some.ns
  (require [foo.bar :as f])) ;; supported and works, but really should
be :require instead!
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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-07-23 Thread Cedric Greevey
On Tue, Jul 23, 2013 at 3:26 PM, Gary Trakhman wrote:

> What's problematic about it is that it's slightly easier to do the wrong
> thing.  It seems insignificant, but 98% of times you use use, it's going to
> be wrong.  Also, 'use only' means I have to change my calling NS twice in
> different parts of the emacs buffer any time I change a function name in
> the called namespace.
>
>
> On Tue, Jul 23, 2013 at 3:08 PM, Cedric Greevey wrote:
>
>> :use...:only doesn't strike me as especially problematic, since it
>> documents the specific symbols it's importing and from where.
>>
>
Is it "wrong" 98% of the times you use ":use...:only"?

And if you change the name of the function "fnname" where it's defined,
yeah you'll have to change "fnname" wherever it's used as well, whether
those uses say "fnname" or "mylib.core/fnname" or "m/fnname" or even
"(:require [mylib.core :refer :rename {fnname othername}])".

Of course, the latter suggests the question of whether it's "wrong" to use
:require ... :refer :only as well. :)

-- 
-- 
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-07-23 Thread Lee Spector

On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote:

> Yea, I have a single namespace with project-specific common utilities which I 
> refer to as u/some-util-function.  For me, it's a bit scary to have implicit 
> symbols in scope.  A typo can make a local binding refer to something that 
> might not exist in production, or at least not what's intended. Conversely, I 
> don't want extra code in my project that has nothing to do with the project.  
> Seems useful to enforce a separation of the artifact from the tools that made 
> it, more-so for a lib that other things depend on than a production app.
> 
> The 'user' namespace can cover the use-case of convenience functions?
> 
> Or, you can add those symbols dynamically at run-time when you need to with 
> something like: 
> https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26
> 
> or some aggregated (require ..) calls.
> 

I'm sure I'm coming from a minority perspective on this, but for the kind of 
work I do it's often more important to be able to quickly sketch out and test 
ideas, without any ceremony about which functions come from where, than it is 
to ensure safety in a "production" environment which is really just me running 
it right now.

In fact I'd sometimes like to go the other way and use everything in a whole 
directory subtree, or even to get rid of "using" altogether and have the 
runtime system find the function wherever it can (within reason :-) and let me 
know if it can't or if there's a conflict.

I do understand that there are a great many programming contexts in which it 
would be foolish and dangerous to manage references so loosely and implicitly 
and dynamically. In fact it's a bad idea in some of my work too, so I'm 
slightly more disciplined than this some of the time.

But my point is just that different users will have different priorities, and 
from where I sit, at least, it'd be nice to keep :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.




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Shantanu Kumar
One of the main issues I have faced with :use is, understanding a 
non-trivial codebase becomes very difficult and almost always requires 
Emacs Meta-dot.

I'd vote for deprecating :use.

Shantanu

-- 
-- 
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-07-23 Thread Gary Trakhman
What's problematic about it is that it's slightly easier to do the wrong
thing.  It seems insignificant, but 98% of times you use use, it's going to
be wrong.  Also, 'use only' means I have to change my calling NS twice in
different parts of the emacs buffer any time I change a function name in
the called namespace.


On Tue, Jul 23, 2013 at 3:08 PM, Cedric Greevey  wrote:

> :use...:only doesn't strike me as especially problematic, since it
> documents the specific symbols it's importing and from where.
>
>
> On Tue, Jul 23, 2013 at 3:04 PM, Sean Corfield wrote:
>
>> We only have :use in a couple of "legacy" tests and two scratch
>> projects. We've switched from :use to :require .. :refer :all for
>> situations where :use used to make sense (primarily in a test ns where
>> we want to just refer in all of the ns being tested). We have a
>> handful of places where we :refer :all elsewhere because the code
>> reads better without ns aliases all over the place and we bring in a
>> lot of functions.
>>
>> Certainly in blogs and documentation, :require .. :as short alias
>> seems a better approach for teaching / explaining things but I'm sure
>> I'm guilty of :use in earlier blog posts about Clojure (... checking
>> ... yup, three blog posts from early 2012 contain :use, mostly with
>> :only, so those should be updated to use :require / :refer instead).
>>
>> Sean
>>
>> On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman 
>> wrote:
>> > We should scour clojuresphere for uses of 'use' and automatically post
>> > github issues to the projects of interest, and redefine the ns macro to
>> > issue a warning with use.
>> >
>> > Does anyone actually like 'use'?
>> >
>> > Require is always more evident.
>> >
>> >
>> > On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner 
>> > wrote:
>> >>
>> >> +1, :use is IMO an antipattern.
>> >>
>> >> I hate it mainly in blogs, where they explain some new API. They :use
>> like
>> >> 3 namespaces and you have to guess which fn is from which ns :)
>> >>
>> >> JW
>> >>
>> >>
>> >> On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
>> >>>
>> >>> I think I read somewhere that :use is no longer encouraged, but I
>> could
>> >>> be mistaken.
>> >>>
>> >>> From what I've read, it seems like most people agree that Clojure has
>> too
>> >>> many ways of including/importing/referencing/requiring/using things:
>> >>>
>> >>>
>> >>>
>> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>> >>>
>> >>> The above gives a very nice explanation of all the various difference,
>> >>> but it also acknowledges their complexity.
>> >>>
>> >>> Since :use uses :require, and since :require can do everything that
>> :use
>> >>> can, can we simplify Clojure programming a bit for newcomers by
>> deprecating
>> >>> the use of :use? The situation in ClojureScript is even worse because
>> it
>> >>> adds :require-macros on top of all the other ways of including files.
>> >>>
>> >>> Ideally, it would be awesome if there was just a single directive for
>> >>> everything, but perhaps there's some complicated low-level reason why
>> that's
>> >>> not possible. :-\
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Thanks,
>> >>> Greg
>> >>>
>> >>> P.S. If this has already been brought up you have my sincere
>> apologies.
>> >>>
>> >>> --
>> >>> Please do not email me anything that you are not comfortable also
>> sharing
>> >>> with the NSA.
>> >>>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more 

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Gary Trakhman
Yea, I have a single namespace with project-specific common utilities which
I refer to as u/some-util-function.  For me, it's a bit scary to have
implicit symbols in scope.  A typo can make a local binding refer to
something that might not exist in production, or at least not what's
intended. Conversely, I don't want extra code in my project that has
nothing to do with the project.  Seems useful to enforce a separation of
the artifact from the tools that made it, more-so for a lib that other
things depend on than a production app.

The 'user' namespace can cover the use-case of convenience functions?

Or, you can add those symbols dynamically at run-time when you need to with
something like:
https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26

or some aggregated (require ..) calls.


On Tue, Jul 23, 2013 at 2:46 PM, Steven Degutis  wrote:

> For much the same reason, I've been using :require with :as and a
> one-or-two-letter alias, so I can do x/whatever. Generally works well.
>
>
> On Tue, Jul 23, 2013 at 1:38 PM, Lee Spector wrote:
>
>>
>> On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote:
>>
>> > We should scour clojuresphere for uses of 'use' and automatically post
>> github issues to the projects of interest, and redefine the ns macro to
>> issue a warning with use.
>> >
>> > Does anyone actually like 'use'?
>> >
>> > Require is always more evident.
>>
>> I like it and I use it regularly, mainly, I guess, when all of the
>> namespaces are my own and I know there are no conflicts. I split things
>> into namespaces to keep the project organized, etc., but I don't want to
>> have to qualify everything everywhere.
>>
>>  -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.
>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Cedric Greevey
:use...:only doesn't strike me as especially problematic, since it
documents the specific symbols it's importing and from where.


On Tue, Jul 23, 2013 at 3:04 PM, Sean Corfield wrote:

> We only have :use in a couple of "legacy" tests and two scratch
> projects. We've switched from :use to :require .. :refer :all for
> situations where :use used to make sense (primarily in a test ns where
> we want to just refer in all of the ns being tested). We have a
> handful of places where we :refer :all elsewhere because the code
> reads better without ns aliases all over the place and we bring in a
> lot of functions.
>
> Certainly in blogs and documentation, :require .. :as short alias
> seems a better approach for teaching / explaining things but I'm sure
> I'm guilty of :use in earlier blog posts about Clojure (... checking
> ... yup, three blog posts from early 2012 contain :use, mostly with
> :only, so those should be updated to use :require / :refer instead).
>
> Sean
>
> On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman 
> wrote:
> > We should scour clojuresphere for uses of 'use' and automatically post
> > github issues to the projects of interest, and redefine the ns macro to
> > issue a warning with use.
> >
> > Does anyone actually like 'use'?
> >
> > Require is always more evident.
> >
> >
> > On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner 
> > wrote:
> >>
> >> +1, :use is IMO an antipattern.
> >>
> >> I hate it mainly in blogs, where they explain some new API. They :use
> like
> >> 3 namespaces and you have to guess which fn is from which ns :)
> >>
> >> JW
> >>
> >>
> >> On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
> >>>
> >>> I think I read somewhere that :use is no longer encouraged, but I could
> >>> be mistaken.
> >>>
> >>> From what I've read, it seems like most people agree that Clojure has
> too
> >>> many ways of including/importing/referencing/requiring/using things:
> >>>
> >>>
> >>>
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
> >>>
> >>> The above gives a very nice explanation of all the various difference,
> >>> but it also acknowledges their complexity.
> >>>
> >>> Since :use uses :require, and since :require can do everything that
> :use
> >>> can, can we simplify Clojure programming a bit for newcomers by
> deprecating
> >>> the use of :use? The situation in ClojureScript is even worse because
> it
> >>> adds :require-macros on top of all the other ways of including files.
> >>>
> >>> Ideally, it would be awesome if there was just a single directive for
> >>> everything, but perhaps there's some complicated low-level reason why
> that's
> >>> not possible. :-\
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Greg
> >>>
> >>> P.S. If this has already been brought up you have my sincere apologies.
> >>>
> >>> --
> >>> Please do not email me anything that you are not comfortable also
> sharing
> >>> with the NSA.
> >>>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> 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

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Sean Corfield
We only have :use in a couple of "legacy" tests and two scratch
projects. We've switched from :use to :require .. :refer :all for
situations where :use used to make sense (primarily in a test ns where
we want to just refer in all of the ns being tested). We have a
handful of places where we :refer :all elsewhere because the code
reads better without ns aliases all over the place and we bring in a
lot of functions.

Certainly in blogs and documentation, :require .. :as short alias
seems a better approach for teaching / explaining things but I'm sure
I'm guilty of :use in earlier blog posts about Clojure (... checking
... yup, three blog posts from early 2012 contain :use, mostly with
:only, so those should be updated to use :require / :refer instead).

Sean

On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman  wrote:
> We should scour clojuresphere for uses of 'use' and automatically post
> github issues to the projects of interest, and redefine the ns macro to
> issue a warning with use.
>
> Does anyone actually like 'use'?
>
> Require is always more evident.
>
>
> On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner 
> wrote:
>>
>> +1, :use is IMO an antipattern.
>>
>> I hate it mainly in blogs, where they explain some new API. They :use like
>> 3 namespaces and you have to guess which fn is from which ns :)
>>
>> JW
>>
>>
>> On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
>>>
>>> I think I read somewhere that :use is no longer encouraged, but I could
>>> be mistaken.
>>>
>>> From what I've read, it seems like most people agree that Clojure has too
>>> many ways of including/importing/referencing/requiring/using things:
>>>
>>>
>>> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>>>
>>> The above gives a very nice explanation of all the various difference,
>>> but it also acknowledges their complexity.
>>>
>>> Since :use uses :require, and since :require can do everything that :use
>>> can, can we simplify Clojure programming a bit for newcomers by deprecating
>>> the use of :use? The situation in ClojureScript is even worse because it
>>> adds :require-macros on top of all the other ways of including files.
>>>
>>> Ideally, it would be awesome if there was just a single directive for
>>> everything, but perhaps there's some complicated low-level reason why that's
>>> not possible. :-\
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Greg
>>>
>>> P.S. If this has already been brought up you have my sincere apologies.
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also sharing
>>> with the NSA.
>>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Steven Degutis
For much the same reason, I've been using :require with :as and a
one-or-two-letter alias, so I can do x/whatever. Generally works well.


On Tue, Jul 23, 2013 at 1:38 PM, Lee Spector  wrote:

>
> On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote:
>
> > We should scour clojuresphere for uses of 'use' and automatically post
> github issues to the projects of interest, and redefine the ns macro to
> issue a warning with use.
> >
> > Does anyone actually like 'use'?
> >
> > Require is always more evident.
>
> I like it and I use it regularly, mainly, I guess, when all of the
> namespaces are my own and I know there are no conflicts. I split things
> into namespaces to keep the project organized, etc., but I don't want to
> have to qualify everything everywhere.
>
>  -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.
>
>
>

-- 
-- 
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-07-23 Thread Softaddicts
We have production code using it.
It's easy to say that it's a bad pattern after the fact.

We have been using it in a disciplined way.
It simplifies our life in the REPL we have some tools we want to see included 
automatically each time we switch to a name space. 

Anything else aside from clojure.core is required using an alias.
This minimized name clashes to zero so far.

This is easily spottable in the ns macro declarations and is not a source of
confusion for us.

We have less manipulations to do in the REPL when attaching to the live app
with these "defaults" included.

I do not mind about the deprecation warning as a first step.
However I would like some breathing space before it gets removed entirely.
It's just another to do on top of the pile of work we have these times...

Luc P.


> We should scour clojuresphere for uses of 'use' and automatically post
> github issues to the projects of interest, and redefine the ns macro to
> issue a warning with use.
> 
> Does anyone actually like 'use'?
> 
> Require is always more evident.
> 
> 
> On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner wrote:
> 
> > +1, :use is IMO an antipattern.
> >
> > I hate it mainly in blogs, where they explain some new API. They :use like
> > 3 namespaces and you have to guess which fn is from which ns :)
> >
> > JW
> >
> >
> > On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
> >>
> >> I think I read somewhere that :use is no longer encouraged, but I could
> >> be mistaken.
> >>
> >> From what I've read, it seems like most people agree that Clojure has too
> >> many ways of including/importing/**referencing/requiring/using things:
> >>
> >> http://blog.8thlight.com/**colin-jones/2010/12/05/**
> >> clojure-libs-and-namespaces-**require-use-import-and-ns.html
> >>
> >> The above gives a very nice explanation of all the various difference,
> >> but it also acknowledges their complexity.
> >>
> >> Since :use uses :require, and since :require can do everything that :use
> >> can, can we simplify Clojure programming a bit for newcomers by deprecating
> >> the use of :use? The situation in ClojureScript is even worse because it
> >> adds :require-macros on top of all the other ways of including files.
> >>
> >> Ideally, it would be awesome if there was just a single directive for
> >> everything, but perhaps there's some complicated low-level reason why
> >> that's not possible. :-\
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >> Greg
> >>
> >> P.S. If this has already been brought up you have my sincere apologies.
> >>
> >> --
> >> Please do not email me anything that you are not comfortable also sharing
> >> with the NSA.
> >>
> >>  --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Lee Spector

On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote:

> We should scour clojuresphere for uses of 'use' and automatically post github 
> issues to the projects of interest, and redefine the ns macro to issue a 
> warning with use.  
> 
> Does anyone actually like 'use'? 
> 
> Require is always more evident.

I like it and I use it regularly, mainly, I guess, when all of the namespaces 
are my own and I know there are no conflicts. I split things into namespaces to 
keep the project organized, etc., but I don't want to have to qualify 
everything everywhere.

 -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: Can we please deprecate the :use directive ?

2013-07-23 Thread Gary Trakhman
We should scour clojuresphere for uses of 'use' and automatically post
github issues to the projects of interest, and redefine the ns macro to
issue a warning with use.

Does anyone actually like 'use'?

Require is always more evident.


On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner wrote:

> +1, :use is IMO an antipattern.
>
> I hate it mainly in blogs, where they explain some new API. They :use like
> 3 namespaces and you have to guess which fn is from which ns :)
>
> JW
>
>
> On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
>>
>> I think I read somewhere that :use is no longer encouraged, but I could
>> be mistaken.
>>
>> From what I've read, it seems like most people agree that Clojure has too
>> many ways of including/importing/**referencing/requiring/using things:
>>
>> http://blog.8thlight.com/**colin-jones/2010/12/05/**
>> clojure-libs-and-namespaces-**require-use-import-and-ns.html
>>
>> The above gives a very nice explanation of all the various difference,
>> but it also acknowledges their complexity.
>>
>> Since :use uses :require, and since :require can do everything that :use
>> can, can we simplify Clojure programming a bit for newcomers by deprecating
>> the use of :use? The situation in ClojureScript is even worse because it
>> adds :require-macros on top of all the other ways of including files.
>>
>> Ideally, it would be awesome if there was just a single directive for
>> everything, but perhaps there's some complicated low-level reason why
>> that's not possible. :-\
>>
>> Thoughts?
>>
>> Thanks,
>> Greg
>>
>> P.S. If this has already been brought up you have my sincere apologies.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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




Re: Can we please deprecate the :use directive ?

2013-07-23 Thread Jozef Wagner
+1, :use is IMO an antipattern. 

I hate it mainly in blogs, where they explain some new API. They :use like 
3 namespaces and you have to guess which fn is from which ns :)

JW

On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
>
> I think I read somewhere that :use is no longer encouraged, but I could be 
> mistaken. 
>
> From what I've read, it seems like most people agree that Clojure has too 
> many ways of including/importing/referencing/requiring/using things: 
>
>
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>  
>
> The above gives a very nice explanation of all the various difference, but 
> it also acknowledges their complexity. 
>
> Since :use uses :require, and since :require can do everything that :use 
> can, can we simplify Clojure programming a bit for newcomers by deprecating 
> the use of :use? The situation in ClojureScript is even worse because it 
> adds :require-macros on top of all the other ways of including files. 
>
> Ideally, it would be awesome if there was just a single directive for 
> everything, but perhaps there's some complicated low-level reason why 
> that's not possible. :-\ 
>
> Thoughts? 
>
> Thanks, 
> Greg 
>
> P.S. If this has already been brought up you have my sincere apologies. 
>
> -- 
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA. 
>
>

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




Re: Can't get namespace metadata

2013-07-23 Thread Alexander Yakushev
Thank you for confirming this, Stuart. Hopefully this will be fixed someday.

On Tuesday, July 23, 2013 7:06:18 PM UTC+3, Stuart Sierra wrote:
>
> I can confirm this behavior. It's not the fault of the `ns`
> macro, however. This works just fine:
>
> user=> (ns ^{:doc "This is foo"} foo)
> nil
> foo=> (in-ns 'user)
> #
> user=> (meta (the-ns 'foo))
> {:doc "This is foo"}
>
> AOT-compilation appears to be the culprit (as usual). This
> has been known for a long time, see CLJ-130, which I just
> updated.
>
> [CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130
>
> -S
>
>
>
>
> On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
>>
>> Example:
>>
>> user=> (meta (find-ns 'clojure.set))
>> nil
>> user=> (meta (find-ns 'clojure.string))
>> nil
>> user=> (meta (find-ns 'clojure.core))
>> {:doc "Fundamental library of the Clojure language"}
>>
>> clojure.core is the only namespace that has metadata. Apparently because 
>> it has metadata set differently 
>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6158,
>>  
>> so I blame *ns *macro.
>>
>> I tested this with clojure 1.2-1.5, so it is not a regression, and unless 
>> I'm doing something wrong, this was broken from the beginning.
>>
>

-- 
-- 
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't get namespace metadata

2013-07-23 Thread Stuart Sierra
I can confirm this behavior. It's not the fault of the `ns`
macro, however. This works just fine:

user=> (ns ^{:doc "This is foo"} foo)
nil
foo=> (in-ns 'user)
#
user=> (meta (the-ns 'foo))
{:doc "This is foo"}

AOT-compilation appears to be the culprit (as usual). This
has been known for a long time, see CLJ-130, which I just
updated.

[CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130

-S




On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
>
> Example:
>
> user=> (meta (find-ns 'clojure.set))
> nil
> user=> (meta (find-ns 'clojure.string))
> nil
> user=> (meta (find-ns 'clojure.core))
> {:doc "Fundamental library of the Clojure language"}
>
> clojure.core is the only namespace that has metadata. Apparently because 
> it has metadata set differently 
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6158,
>  
> so I blame *ns *macro.
>
> I tested this with clojure 1.2-1.5, so it is not a regression, and unless 
> I'm doing something wrong, this was broken from the beginning.
>

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




Can we please deprecate the :use directive ?

2013-07-23 Thread Greg
I think I read somewhere that :use is no longer encouraged, but I could be 
mistaken.

>From what I've read, it seems like most people agree that Clojure has too many 
>ways of including/importing/referencing/requiring/using things:

http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html

The above gives a very nice explanation of all the various difference, but it 
also acknowledges their complexity.

Since :use uses :require, and since :require can do everything that :use can, 
can we simplify Clojure programming a bit for newcomers by deprecating the use 
of :use? The situation in ClojureScript is even worse because it adds 
:require-macros on top of all the other ways of including files.

Ideally, it would be awesome if there was just a single directive for 
everything, but perhaps there's some complicated low-level reason why that's 
not possible. :-\

Thoughts?

Thanks,
Greg

P.S. If this has already been brought up you have my sincere apologies.

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

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




Re: futures - The Joy Of Clojure book question

2013-07-23 Thread Lars Nilsson
On Tue, Jul 23, 2013 at 11:12 AM, Baishampayan Ghose  wrote:
> It's definitely got to do with the code, the right way to test it out
> will be to wrap the form in a function and then calling it twice. Like
> so -
>
> (time
>   (let [x (fn [] (Thread/sleep 2000)
>(+ 1 1))]
>  [(x) (x)]))
> ;=> "Elapsed time: 4002.0 msecs"
> ;=> [2 2]
>
> Hope that helps.
>
> Regards,
> BG
>
>
> On Tue, Jul 23, 2013 at 8:34 PM, Ryan Moore  wrote:
>> There is an example in the book The Joy of Clojure on p.262 that uses
>> futures that I evaluated in the REPL.
>>
>> user> (time
>>(let [x (future (do (Thread/sleep 2000)
>>   (+ 1 1)))]
>> [@x @x]))
>> "Elapsed time: 2000.809 msecs"
>> [2 2]
>>
>> I figured that taking out the future would cause the execution to take twice
>> as long, however, when I try this:
>>
>> user> (time
>>(let [x (do (Thread/sleep 2000)
>>   (+ 1 1))]
>> [x x]))
>> "Elapsed time: 2000.512 msecs"
>> [2 2]
>>
>> as you see it takes about the same amount of time. Does this have something
>> to do with the REPL evaluating things or maybe the newer version of Clojure
>> handles things differently from the Joy of Clojure book?

Can also show the difference using two different vars

  (time (let [x (future (do (Thread/sleep 2000) (+ 1 1)))
  y (future (do (Thread/sleep 3000) (+ 2 2)))]
  [@x @y]))

"Elapsed time: 3003.802 msecs"
[2 4]

  (time (let [x (do (Thread/sleep 2000) (+ 1 1))
  y (do (Thread/sleep 3000) (+ 2 2))]
  [x y]))

"Elapsed time: 5003.049 msecs"
[2 4]

Basically, [x x] doesn't do the evaluation, it happens in the let once
for x. For [@x @x] the thread is kicked off once to do the
computation, and the first @x waits for the result (if not already
available) while the second @x uses the cached value.

In my modified version, the second case the two Thread/sleep happens
in sequence, while in the first they take place in parallel thanks to
the futures.

Lars Nilsson

-- 
-- 
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: futures - The Joy Of Clojure book question

2013-07-23 Thread Baishampayan Ghose
It's definitely got to do with the code, the right way to test it out
will be to wrap the form in a function and then calling it twice. Like
so -

(time
  (let [x (fn [] (Thread/sleep 2000)
   (+ 1 1))]
 [(x) (x)]))
;=> "Elapsed time: 4002.0 msecs"
;=> [2 2]

Hope that helps.

Regards,
BG


On Tue, Jul 23, 2013 at 8:34 PM, Ryan Moore  wrote:
> There is an example in the book The Joy of Clojure on p.262 that uses
> futures that I evaluated in the REPL.
>
> user> (time
>(let [x (future (do (Thread/sleep 2000)
>   (+ 1 1)))]
> [@x @x]))
> "Elapsed time: 2000.809 msecs"
> [2 2]
>
> I figured that taking out the future would cause the execution to take twice
> as long, however, when I try this:
>
> user> (time
>(let [x (do (Thread/sleep 2000)
>   (+ 1 1))]
> [x x]))
> "Elapsed time: 2000.512 msecs"
> [2 2]
>
> as you see it takes about the same amount of time. Does this have something
> to do with the REPL evaluating things or maybe the newer version of Clojure
> handles things differently from the Joy of Clojure book?
>
> Thanks
>
> --
> --
> 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.
>
>



-- 
Baishampayan Ghose
b.ghose at gmail.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.




futures - The Joy Of Clojure book question

2013-07-23 Thread Ryan Moore
There is an example in the book The Joy of Clojure on p.262 that uses 
futures that I evaluated in the REPL.

user> (time
   (let [x (future (do (Thread/sleep 2000)
   (+ 1 1)))]
 [@x @x]))
"Elapsed time: 2000.809 msecs"
[2 2]

I figured that taking out the future would cause the execution to take 
twice as long, however, when I try this:

user> (time
   (let [x (do (Thread/sleep 2000)
   (+ 1 1))]
 [x x]))
"Elapsed time: 2000.512 msecs"
[2 2]

as you see it takes about the same amount of time. Does this have something 
to do with the REPL evaluating things or maybe the newer version of Clojure 
handles things differently from the Joy of Clojure book?

Thanks

-- 
-- 
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: Making RPCs with Shoreleave

2013-07-23 Thread Tony Garcia
Hi,

I'm using Shoreleave in one of our projects and it works fine for us. I 
followed the same tutorial and everything was OK.

I've seen something similar when I was using the autogeneration of the js 
file. For some reason after updating the cljs the continuous compilation 
breaks the shoreleave RPC. When it happens I fix it by cleaning and 
compiling the whole thing again.

Tony.

On Sunday, 21 July 2013 16:08:07 UTC+1, Alex Fowler wrote:
>
> Considering the severity of the bug that i found, i want to ask if someone 
> is using Shoreleave's rpc without any problems?  Maybe it's me missing 
> something? Or maybe someone run into the same problem too?
>
> On Saturday, July 20, 2013 2:16:02 PM UTC+4, Alex Fowler wrote:
>>
>> That wasn't hte case either. After some buzz with ddellacosta and others 
>> on #clojure, it was found that the RPC call is unable to find that very 
>> remote procedure I was requesting. Then I have verified that all is 
>> properly stored in the remote procedures registry on backend and that the 
>> front end makes proper calls. The problem was that the backend was 
>> expecting edn while the frontend was sending it in html-form format in 
>> request body. I am just a beginner with Clojure's web stack, so I think 
>> that maybe I missed some wrappers with Noir or Ring, but I was doing all 
>> according to the tutorial and it failed to work. So I had to manually 
>> override several functions from Shoreleave back-end and front-end to behave 
>> coherently and send and receive data in edn format. I think this makes a 
>> patch for the library since the RPC functionality is broken out-of-the-box. 
>> Unless I am missing something crucial, but examples I found miss that 
>> either...
>>
>>
>>
>> четверг, 18 июля 2013 г., 15:42:35 UTC+4 пользователь terjesb написал:
>>>
>>> The default /_shoreleave endpoint should work if you're running using 
>>> lein ring server.
>>>
>>> Are you running a WAR in a container? If so, I don't think Shoreleave 
>>> currently picks up the context. If you have only one client app, you could 
>>> proxy this using nginx in front on your container. For multiple client apps 
>>> (also standalone, without a container), you may need to do what I did:
>>>
>>> override default "/_shoreleave" in your app: (wrap-rpc 
>>> "/your-context/_shoreleave")
>>>
>>> and then (binding [shoreleave.remotes.http-rpc/*remote-uri* 
>>> "/your-context/_shoreleave"] ) around your client calls.
>>>
>>> Terje.
>>>
>>>
>>>
>>>
>>> kl. 10:50:17 UTC+2 mandag 15. juli 2013 skrev Alex Fowler følgende:

 Did not work.. all that is strange since I've been following the manual 
 step-by-step.. looks like the shoreleave's wrapper does not even create a 
 http route for itself... any other ideas?

 On Friday, July 12, 2013 7:14:42 AM UTC+4, Samrat Man Singh wrote:
>
> I think you need to (use projectname.ajax) in your projectname.handler 
> page. If I remember correctly, there's also a way to specify which 
> namespace your remote function is in.
>
> On Thursday, July 11, 2013 10:42:15 PM UTC+5:45, Alex Fowler wrote:
>>
>> Hi all, this is my first experience with Shoreleave and I'm trying to 
>> use it's RPC mechanism to perform AJAX tasks. However, on a call to a 
>> remote procedure, I get this:
>>
>> `
>>
>>1. POST http://localhost:8080/_shoreleave 404 (Not Found) 
>>cljs.js:25223 
>>   1. 
>> goog.net.XhrIo.sendcljs.js:25223
>>   2. xhr__delegatecljs.js:31416
>>   3. xhrcljs.js:31423 
>>   4. 
>> remote_callback__delegatecljs.js:32504
>>   5. remote_callbackcljs.js:32515
>>   6. load_storecljs.js:32745 
>>   7. 
>> mk__AMPERSAND__load_store__delegatecljs.js:32755
>>   8. 
>> mk__AMPERSAND__load_storecljs.js:32763
>>   9. example_storecljs.js:33341
>>   10. simplecljs.js:33361 
>>   11. setup_guicljs.js:33962 
>>   12. setup_allcljs.js:33982 
>>   13. startupcljs.js:41166 
>>   14. onloadapp:2 
>>   
>> XHR ERROR: Not Found 
>> `
>>
>> What is wrong and how do I fix it? I have been following this 
>> tutorial: Shoreleave Tutorial 10 - Introducing 
>> Ajax
>>  my 
>> code (relevant parts) is this:
>>
>> Project.clj:
>> `
>> (defproject projectname "0.1.0-SNAP

Re: Socket.IO and Clojure?

2013-07-23 Thread Ustun Ozgur
A bit off-topic, but in some situations where bidirectional communication 
is 
not necessary, one might consider EventSource instead of Websockets 
to push data from server to the client. For some reason, EventSource is not 
as well known as Websockets.

It has some advantages like being more backwards compatible.

http://www.html5rocks.com/en/tutorials/eventsource/basics/
http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource
https://github.com/Yaffle/EventSource

Ustun


On Wednesday, July 17, 2013 8:07:34 AM UTC+3, Sean Corfield wrote:
>
> At work we're starting down the path of building a new piece of 
> functionality based on WebSockets and the external team we're working 
> with is a Node.js shop so their go to solution is Socket.IO and 
> they've produced a very nice front end in CoffeeScript and a prototype 
> back end on Node.js. 
>
> I'd really like to have our back end on the JVM, of course, and so I'd 
> like to find a JVM-based Socket.IO solution that I use from/with 
> Clojure... 
>
> This seems like a reasonable option: 
>
> https://github.com/mrniko/netty-socketio 
>
> A little bit of experimentation with lein-try (Thank you Ryan!) shows 
> that it's pretty easy to get a basic server up and running in the REPL 
> - and I was able to get several of their demos running unchanged 
> against Clojure, instead of their Java applications, so that was 
> promising. 
>
> Are there other folks out there doing Socket.IO stuff with Clojure? 
> What approaches have you taken? 
>
> Obviously, we could run Node.js and have it hit a Clojure-based REST 
> API to do the integration, and that might be less pain long term 
> but... 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

-- 
-- 
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: anaphoric macro?

2013-07-23 Thread Chris Ford
I use a similar macro in my music
code,
because I want to take a sequence and explicitly give parts of it names.

(defmacro defs [names docstring values]
  `(do ~@(map
 (fn [name value] `(def ~name ~docstring ~value))
 names (eval values

(defs
  [C D E F G A B]
  "A key, expressed as a translation function."
  (map
(comp from (from 60) major)
(range)))

This macro is not part of the public API. :-)



On 23 July 2013 10:52, Alex Baranosky  wrote:

> Good point BG,
>
> I think it is almost certainly not a good idea :)  But educational,
> definitely.
>
>
> On Tue, Jul 23, 2013 at 12:48 AM, Baishampayan Ghose wrote:
>
>> Since the bindings are a function of the data that's passed in, IMO
>> you don't need a anaphoric macro for this.
>>
>> For example -
>>
>> (defmacro def-names [names & body]
>>   (let [bindings* (vec (mapcat (juxt symbol identity) names))]
>> `(let ~bindings*
>>~@body)))
>>
>> As to whether it's a good idea or not, I'd say it depends but YMMV.
>>
>> Regards,
>> BG
>>
>> On Tue, Jul 23, 2013 at 12:48 PM,   wrote:
>> > Hi,
>> > I want to write a macro that introduces new variables from data.
>> > The data is a vector and looks like this for example: ["a" "b" "c"]
>> >
>> > I want to use the macro like this:
>> > (def-names ["a" "b" "c"] (str a b))
>> >
>> > What code I want the macro to produce from the above is the following:
>> > (let [a "a"
>> >b "b"
>> >c "c"]
>> >   (str a b))
>> >
>> > Is it possible to do that?
>> > Is it a good thing to do that or is it bad practice?
>> >
>> > Thanks
>> > --anders
>> >
>> >
>> >
>> > --
>> > --
>> > 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.
>> >
>> >
>>
>>
>>
>> --
>> Baishampayan Ghose
>> b.ghose at gmail.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.
>>
>>
>>
>  --
> --
> 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: Interest in a Full Featured Clojure Blog Engine

2013-07-23 Thread Manuel Paccagnella


Il giorno martedì 23 luglio 2013 04:11:48 UTC+2, frye ha scritto:
>
> Hey all, 
>
>
> *A)* Thanks for all the feedback on this topic. There's a few interesting 
> things here. Notably that there are at least these existing blog engines:
>
>- http://github.com/bitemyapp/neubite (apparently needs a WYSIWYG 
>editor)
>- https://github.com/yogthos/yuggoth (although this advertises itself 
>as a full blog engine)
>
>
> *B)* I'll also look into putting HTML code within Markdown text. Wrt *
> Asciidoc*, what I wonder is i) does it handle all media types (images, 
> video, audio, etc) and ii) are there well-developed web-editors for 
> asciidoc ?
>

i) Yes  :)
ii) I haven't found none. However, it should be quite feasible to write 
AsciiDoc markup in plain text and render a preview in real time in-browser 
using 
asciidoctor.js.
 

 

>
> *C)* Also, the idea of a static site or blog generator (like Jekyll) is 
> good. But that strikes me as a sub-set of a full-featured blog engine. My 
> concept of having a small core (or kernel, if you like), would certainly 
> allow for a static site generator as a plug-in. Looks like there are 
> already working examples with: http://liquidz.github.io/misaki
>
>
> I would still like something.. a blog library that you can thread into 
> your existing site. It wouldn't make too many assumptions about your setup 
> (data store, http framework, templating, workflow, etc). And it would allow 
> you to plug-in pieces on an as needed basis. I can't see that in neubite or 
> yuggoth, unless I missed it. Please let me know. 
>
>
I agree. That way it could be used any number of markup languages for posts 
(and pages): Markdown, AsciiDoc, HTML, etc.
 

>
> Thanks 
>
> Tim Washington 
> Interruptsoftware.ca / Bkeeping.com 
>
>
>
> On Mon, Jul 22, 2013 at 6:22 AM, Manuel Paccagnella <
> manuel.pa...@gmail.com > wrote:
>
>> There is also Yuggoth: https://github.com/yogthos/yuggoth
>>
>> It's pretty feature-complete as I can see, but I haven't looked at the 
>> source for its the architecture. Trivia: It has been written starting with 
>> Luminus, and the author is writing a book about web development in Clojure 
>> for The Pragmatic Programmers.
>>
>> Il giorno domenica 21 luglio 2013 22:10:45 UTC+2, frye ha scritto:
>>>
>>> Ooh. Ok, lemme check it out. 
>>>
>>>
>>>
>>> On Sat, Jul 20, 2013 at 10:34 PM, Chris Allen wrote:
>>>
 http://github.com/bitemyapp/**neubite/

 Could probably use a WYSIWYG editor, beyond that, pretty serviceable.


  
>

-- 
-- 
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: Interest in a Full Featured Clojure Blog Engine

2013-07-23 Thread Manuel Paccagnella


Il giorno martedì 23 luglio 2013 03:32:52 UTC+2, frye ha scritto:
>
>
>
>
> On Sun, Jul 21, 2013 at 5:16 PM, Manuel Paccagnella <
> manuel.pa...@gmail.com > wrote:
>>
>>
>>>- what I should use to model workflow; possibly 
>>> lamina
>>>? 
>>>
>>> I'm not sure Lamina is the right tool for this job. What are your ideas 
>> for modeling and executing workflows?
>>
>  
> When I say "Workflow", I mean something along the lines of a Petri Net (
> http://www.informatik.uni-hamburg.de/TGI/PetriNets/). I've used Lamina in 
> order to handle multiple channels in my domain. And that was just me 
> wondering out loud if it can be grafted onto the task. I don't see any well 
> fleshed out Petri Nets or Finite State Machines in Clojure (although 
> googling gives you a bunch of user trials and whatnot)
>

I've pondered a bit about this, I like your idea. 

Regarding finite state machines, have you seen 
devs? 

 

>
>
>>>- 
>>>- what's the best interface & messages to pass between the core 
>>>service and plug-ins; I'm thinking of the 
>>> nreplprotocol, but I need to work 
>>> out: 
>>>
>>>
>>>1. communication between plug-ins 
>>>   2. way to list possible actions (namespace qualify action names) 
>>>   3. way to publish actions  
>>>   4. way for core service to listen for messages from a plug-in  
>>>   5. way to pass binary data (asset(s)) between stefon and plug-in
>>>
>>>
>>>
>> I've not investigated this in depth, but why not a simple HTTP interface 
>> that talks EDN?
>>
>
> I plan on having an HTTP plug-in, using an edn transport; but that would 
> be a chunk of code that uses the plug-in architecture, and talks to HTTP 
> clients
>
>
>  
>
>>  
>>
>>> I think the next week or so will be investigating this list. It 
>>> represents most of the hurdles I see in getting a successful core / plug-in 
>>> architecture running. Insight or expertise on any of these points is very 
>>> welcome.
>>>
>>
>> I don't know if you have read 
>> this, 
>> but maybe it could give you some ideas about the plugin architecture. "The 
>> blog engine as data". The plugin system could be the kernel, and maybe most 
>> features could be implemented as plugins. Just dreaming out loud :)
>>
>
> Yes, what you describe is very much the concept that I have 
>

-- 
-- 
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: anaphoric macro?

2013-07-23 Thread Alex Baranosky
Good point BG,

I think it is almost certainly not a good idea :)  But educational,
definitely.

On Tue, Jul 23, 2013 at 12:48 AM, Baishampayan Ghose wrote:

> Since the bindings are a function of the data that's passed in, IMO
> you don't need a anaphoric macro for this.
>
> For example -
>
> (defmacro def-names [names & body]
>   (let [bindings* (vec (mapcat (juxt symbol identity) names))]
> `(let ~bindings*
>~@body)))
>
> As to whether it's a good idea or not, I'd say it depends but YMMV.
>
> Regards,
> BG
>
> On Tue, Jul 23, 2013 at 12:48 PM,   wrote:
> > Hi,
> > I want to write a macro that introduces new variables from data.
> > The data is a vector and looks like this for example: ["a" "b" "c"]
> >
> > I want to use the macro like this:
> > (def-names ["a" "b" "c"] (str a b))
> >
> > What code I want the macro to produce from the above is the following:
> > (let [a "a"
> >b "b"
> >c "c"]
> >   (str a b))
> >
> > Is it possible to do that?
> > Is it a good thing to do that or is it bad practice?
> >
> > Thanks
> > --anders
> >
> >
> >
> > --
> > --
> > 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.
> >
> >
>
>
>
> --
> Baishampayan Ghose
> b.ghose at gmail.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.
>
>
>

-- 
-- 
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: anaphoric macro?

2013-07-23 Thread Alex Baranosky
Hi Anders,

(defmacro def-name [name-vec & body]
  `(let ~(vec (interleave (map symbol name-vec)
  name-vec))
   ~@body))

user=> (macroexpand '(def-name ["a" "b" "c"] 1 2 3))
(let* [a "a" b "b" c "c"] 1 2 3)

user=> (def-name ["a" "b" "c"] a)
"a"
user=> (def-name ["a" "b" "c"] b)
"b"
user=> (def-name ["a" "b" "c"] (str a b))
"ab"

Best,
Alex

On Tue, Jul 23, 2013 at 12:18 AM,  wrote:

> Hi,
> I want to write a macro that introduces new variables from data.
> The data is a vector and looks like this for example: ["a" "b" "c"]
>
> I want to use the macro like this:
> (def-names ["a" "b" "c"] (str a b))
>
> What code I want the macro to produce from the above is the following:
> (let [a "a"
>b "b"
>c "c"]
>   (str a b))
>
> Is it possible to do that?
> Is it a good thing to do that or is it bad practice?
>
> Thanks
> --anders
>
>
>
> --
> --
> 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: anaphoric macro?

2013-07-23 Thread Baishampayan Ghose
Since the bindings are a function of the data that's passed in, IMO
you don't need a anaphoric macro for this.

For example -

(defmacro def-names [names & body]
  (let [bindings* (vec (mapcat (juxt symbol identity) names))]
`(let ~bindings*
   ~@body)))

As to whether it's a good idea or not, I'd say it depends but YMMV.

Regards,
BG

On Tue, Jul 23, 2013 at 12:48 PM,   wrote:
> Hi,
> I want to write a macro that introduces new variables from data.
> The data is a vector and looks like this for example: ["a" "b" "c"]
>
> I want to use the macro like this:
> (def-names ["a" "b" "c"] (str a b))
>
> What code I want the macro to produce from the above is the following:
> (let [a "a"
>b "b"
>c "c"]
>   (str a b))
>
> Is it possible to do that?
> Is it a good thing to do that or is it bad practice?
>
> Thanks
> --anders
>
>
>
> --
> --
> 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.
>
>



-- 
Baishampayan Ghose
b.ghose at gmail.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.




anaphoric macro?

2013-07-23 Thread eliassonaand
Hi,
I want to write a macro that introduces new variables from data.
The data is a vector and looks like this for example: ["a" "b" "c"]

I want to use the macro like this:
(def-names ["a" "b" "c"] (str a b))

What code I want the macro to produce from the above is the following:
(let [a "a"
   b "b"
   c "c"]
  (str a b))

Is it possible to do that?
Is it a good thing to do that or is it bad practice?

Thanks
--anders
  
 

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