Re: [core.spec] Stricter map validations?

[Greg Mitchell]

Saw this thread on the REPL, interesting discussion.

On Tuesday, October 3, 2017 at 10:57:34 AM UTC-7, Alex Miller wrote:
>
>
> It's not about easier, it's about possible. Open grows, closed breaks.
>   
>

I agree with the broad brush, but it's important to listen to this 
usability feedback before releasing an important feature like Spec. As an 
aside, seriously great work with Spec; it's the biggest thing Clojure was 
missing for institutional support I think. 

At Google, we use Protocol Buffers 
 heavily to achieve some 
similar goals to Spec, and I think there are good lessons to look at. Like 
you said, the spec (whether proto or capital-s Spec) needs to be forwards 
compatible across distributed clients if it's going to describe data in an 
useful way as the project evolves. Protos achieve that by convention - best 
practice recommends fields are always optional and the type can never 
change - and technically by always accepting unknown fields.

Where they differ highlights the pain points that people in this thread 
mentioned. 
- Protos cannot be created with extra fields, so there's nothing like the 
sanitizing issue puzzler mentioned. The generalization is to strictly 
specify the output of a function/system, but gracefully handle input. This 
makes me think there should be something like a s/conform-strict function 
that coerces data to only the Spec'd keys, and ensures keys are defined.
- Protos specify the type of a field along with its name, and both are 
checked at compile time, so there aren't the late-caught errors like the OP 
pointed out. Rich has good reasoning for wanting to re-use keys, but 
typically the solution is to create a named composite type (a message in 
proto terms) that is trivial to re-use as a field type. The idea of 
specifying keys separately is different from how literally every type 
system does things, so it's inherently not "easy" in Rich's definition of 
being mentally at hand. That's going to create pain for people learning the 
tool. You should strongly think about ways to reduce that friction.

Protos describe a strictly specified open message, which doesn't neatly fit 
in your categories or open or closed. It's an important technical precedent 
to think about though.

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

Re: [ANN] Amazonica: Clojure client for the entire AWS api

[Greg Mitchell]

Thanks for creating this library, Michael. Your solutions for writing the 
library are creative for sure, and this library has helped with developing 
with AWS. However, I've been using the amazonica library to communicate 
with AWS components in an enterprise-scale project for about a year now, 
and I've come to believe that some of the design choices in the library and 
its maintenance are big anti-patterns. All of these are things I've 
struggled with in developing against Amazonica:

* The documentation is sparse and the code is not self-documenting. 
Clojure in general tends to have worse and less documentation than Java. 
This is usually mitigated in well-designed Clojure libraries by being able 
to break into the source and read short, comprehensible functions with 
descriptive names. Amazonica is in the worst of both worlds by having no 
documentation in source, sparse documentation on github, and using 
dynamically generated code. Specific improvements to documentation I'd love 
to see: a comprehensive list of keys that credential maps and functions 
take as well as their valid values. The one or two examples per API on 
Github are insufficient for different combinations of functionality in 
real-world use cases. Pointing to AWS javadoc is not sufficient because 
Amazonica does name-munging and unwrapping - in order to understand the 
Amazonica input/output, you have to be an expert with the library and look 
at the implementation for name-munging. It is effectively a new API. A 
comprehensive list of functions would be nice, but finding them at the repl 
is a reasonable work around.

* Dynamically generating an API doesn't save anyone time
This is an extension of the previous point. You have almost 800 lines of 
code, mostly dedicated to reflection and interning methods. It's impressive 
that the whole thing works as well as it does, but doesn't actually save 
time vs. explicitly targeting an API with small wrapper functions. That has 
the benefit of being very obvious and easy to understand (as described 
above). It does mean you have to do some work when the Java SDK changes or 
you add a client, but I see there is already some nasty logic to switch on 
the client class if it has a different interface. There's a performance 
cost in reflection too. 

* Functions are both variadic and dispatch on argument type
Especially without clear javadoc style documentation for function 
arguments, types, and keys, having functions that take a smorgasborg of 
different arguments is incredibly confusing. I think the root of this 
problem is the choice to make the client methods variadic, because then 
there can't be well-specified arities for the various cases (no credentials 
or arguments, credential map, just arguments, credential map and 
arguments), using repl. If the functions instead had 0, 1, and 2 arities 
that took nothing, an argument map, or a credential map and an argument 
map, it would be so much clearer. Also argument maps are generally a little 
easier to work with than destructuring the rest.

* There are no releases or tags on github
My company has a tedious process for importing third-party packages into 
source control. It's not ideal, but I'm sure it's not unique. It would be 
great to be able to pull in a stable release built against well-specified 
versions of dependencies.

I hope this doesn't come across as harsh, that's not my intent. I really do 
appreciate you writing this library, and I realize that given how mature it 
is, completely changing the implementation is probably unfeasible. I just 
want to raise these concerns and see whether other people share them. If 
so, maybe they can serve as patterns or anti-patterns for future libraries.

-Greg Mitchell

On Monday, March 25, 2013 2:51:42 PM UTC-7, Michael Cohen wrote:
>
> Curious to hear opinions on this:
>
> https://github.com/mcohen01/amazonica 
>

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

Re: Cyclic Agents

[Greg MacDonald]

Oh that makes sense. Thanks a lot!

On Thu, Sep 11, 2014 at 1:36 AM, Carlo Zancanaro 
wrote:

> Hey Greg,
>
> On Thu, Sep 11, 2014 at 12:30:11AM -0700, Greg MacDonald wrote:
> > So how come two agents can't contain one another? The following code
> causes
> > a StackOverflowError. In the real world things can't contain other things
> > cyclically so I suspect that's why, but if someone could explain this
> > better to me I'd appreciate it. :) - Greg
> >
> > (defn test-agents
> >   []
> >   (let [a (agent {})
> > b (agent {})]
> > (send-off a #(assoc %1 :other %2) b)
> > (send-off b #(assoc %1 :other %2) a)))
>
> As far as I can tell this works properly, but printing it is a problem
> (as it's a structure with a cycle in it: a -> b -> a -> b -> ... a).
>
> We can see that it works, though:
>
>   user=> (defn test-agents []
>(let [a (agent {:a true}),
>  b (agent {:b true})]
>  (send-off a assoc :other b)
>  (send-off b assoc :other a)
>  [a b]))
>   #'user/test-agents
>   user=> (def ag (test-agents))
>   #'user/ag
>   user=> (:a @(first ag))
>   true ;; the "first" one is a
>   user=> (:b @(:other @(first ag)))
>   true ;; a's "other" is b
>   user=> (:a @(:other @(:other @(first ag
>   true ;; b's "other" is a
>
>
> Carlo
>

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

Cyclic Agents

[Greg MacDonald]

Hi Everyone,

So how come two agents can't contain one another? The following code causes 
a StackOverflowError. In the real world things can't contain other things 
cyclically so I suspect that's why, but if someone could explain this 
better to me I'd appreciate it. :) - Greg

(defn test-agents
  []
  (let [a (agent {})
b (agent {})]
(send-off a #(assoc %1 :other %2) b)
(send-off b #(assoc %1 :other %2) 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/d/optout.

clojure streams

[Greg MacDonald]

Hi Everyone,

Does anyone know the status of clojure streams is? I would like to try them 
out but I can't find the svn repository mentioned on the website: 
http://clojure.org/streams. Thx!

-Greg

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

Re: Clojure on iOS devices - Swift as a host?

[Greg Knapp]

That is cool :)

On Tuesday, 24 June 2014 19:29:00 UTC+1, Mike Fikes wrote:
>
> (Apologies to Greg for having essentially hijacked this thread, but I 
> suspect he'd find this cool.) 
>
> I have no experience with the Swift REPL yet, but I'm still finding this a 
> little surreal:
>
>
> <https://lh6.googleusercontent.com/-Z7ulXotc4N4/U6nCQgnWuPI/AJc/700UBdqm3d0/s1600/repl.jpg>
>
> (It's a picture of me holding an iPod touch, jacked into it wirelessly via 
> a ClojureScript REPL, live updating a UITextField's text.)
>
>

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

Re: Clojure on iOS devices - Swift as a host?

[Greg Knapp]

I wasn't really pointing at performance with my post. More about native app 
development, for OSX we have Clojure on the JVM which is fine. I don't see 
Apple allowing Java on iOS anytime though.

Thanks for the replies so far, this was purely food for thought.

On Wednesday, 4 June 2014 16:11:56 UTC+1, Aaron France wrote:
>
> @Timothy, you mention speed a lot, but I'm not sure where in the OP it 
> mentioned wanting to do this for speed at all. I think the intention is to 
> be able to Clojure on a different platform, is all.
>
>
> On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes > 
> wrote:
>
>> I have been experimenting writing an iOS app using ClojureScript embedded 
>> in JavaScriptCore, where the ClojureScript essentially implements the logic 
>> of my view controllers which drive native UI.
>>
>> So far, this approach seems like a reasonable one to “writing iOS apps 
>> using Clojure.”
>>
>> You essentially trade off direct tooling support and gain the ease of 
>> developing using ClojureScript (this is important to me, as my server is in 
>> Clojure and I can effectively master one language.)
>>
>> --
>> 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/d/optout.
>>
>
>

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

Clojure on iOS devices - Swift as a host?

[Greg Knapp]

The recent release of Swift made me revisit Clojure on LLVM. This post from 
2010  
suggests it's a very difficult task.

Swift would make this job easier? As with ClojureScript, generate Swift 
code / provide interop and Clojurian's can produce native iOS apps?

Perhaps the biggest hole to be filled would be tooling (Xcode is not 
Clojure/Lisp friendly? i.e. no playground support)

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

Re: Joy of Clojure example not working

[Greg D]

Yes, the examples in the book are missing some lines. I think the following 
log shows what they were going for:

joy.udp=> (remove-method compiler ::osx)
joy.udp=> (def unix (into unix {::c-compiler "/usr/bin/gcc"}))
joy.udp=> (def osx (into osx {:c-compiler "gcc"}))
oy.udp=> osx
{:home "/Users", :llvm-compiler "clang", :os :joy.udp/osx, 
:joy.udp/prototype {:home "/home", :os :joy.udp/unix, :c-compiler "cc", 
:dev "/dev"}, :c-compiler "gcc"}
joy.udp=> unix
{:home "/home", :joy.udp/c-compiler "/usr/bin/gcc", :os :joy.udp/unix, 
:c-compiler "cc", :dev "/dev"}
joy.udp=> (compiler osx)
"gcc"
joy.udp=> (compile-cmd osx)
"/usr/bin/gcc"

About your question:

> Isn't there a core function/macro where I can derive and set hierarchy all 
> at once?
>
Such a function would need to know in advance what hierarchy you want to 
construct. If you have a desired pattern of hierarchy that you want to 
reuse, you could define a function to create it using "derive" and 
optionally "make-hierarchy". 


On Monday, May 19, 2014 4:38:00 PM UTC-7, gamma235 wrote:
>
> I actually just wanna know why I need to use derive so many times. Isn't 
> there a core function/macro where I can derive and set hierarchy all at 
> once? I'm just looking for a more efficient way. My bad for not stating 
> that more clearly in the original post. 
>
> The real problem though is the last two calls to compile-cmd. I've been 
> messing with it for a couple of days so any help there would be well 
> appreciated.
>
> Thanks
>
> J
>
>

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

Re: ArithmeticException from unchecked-add

[Greg D]

Thanks. I've got to pay more attention to the distinction between long and 
Long in the documentation.

The docs for unchecked-add (
> http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/unchecked-add
> ) 
> only cover the case of both arguments being primitive longs. 
>


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

ArithmeticException from unchecked-add

[Greg D]

I didn't expect this one.  See the illustrative sequence below.

Should I be reporting this as a bug, or re-read the docs?

; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)

user> (require '[clojure.stacktrace :as st])

user> (unchecked-add (Long/MAX_VALUE) (Long/MAX_VALUE) )
-2

user> (unchecked-add ^long(Long/MAX_VALUE) ^long(Long/MAX_VALUE) )
-2

user> (unchecked-add ^Long(Long/MAX_VALUE) ^Long(Long/MAX_VALUE) )
ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
(Numbers.java:1424)

user> (st/e)
java.lang.ArithmeticException: integer overflow
 at clojure.lang.Numbers.throwIntOverflow (Numbers.java:1424)
clojure.lang.Numbers.add (Numbers.java:1723)
clojure.lang.Numbers$LongOps.add (Numbers.java:447)
clojure.lang.Numbers.add (Numbers.java:126)
clojure.lang.Numbers.unchecked_add (Numbers.java:1671)
user$eval2514.invoke (form-init3948440390155694364.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6703)
clojure.lang.Compiler.eval (Compiler.java:)
nil

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

Re: Best way to pass parameters?

[Greg D]

Not an answer to your question, but you may want to check out:
Datomic: The fully transactional, cloud-ready, immutable 
database.

On Monday, May 19, 2014 10:07:15 AM UTC-7, Ivan Schuetz wrote:
>
> Hi,
>
> I'm building a webservice, have 2 layers: webservice and database.
>
> Webservice layer receives e.g. a product, to add to the database:
>
> {:id 1 :name "phone" :price 100}
>
> Database layer has a method to insert the product, insert-product.
>
> I could do 1):
>
> (defn insert-product [params])
>
> or 2):
>
> (defn insert-product [id name price])
>
> or 3):
>
> (defn insert-product [{:keys [id name price]})
>
>
> I tend to prefer 2) because it's safer than 1) and will allow me to add 
> type check later, don't think this is possible with 3). It doesn't feel 
> very idiomatic though and makes me feel like I might be "thinking in 
> Java"...
>
>
> I also want make possible to change the keys before inserting in the 
> database, where 2) and 3) are better than 1).
>
>
> Is 2) the best option? Is there any reason to use 3) instead? Or is there 
> maybe a different, better way?
>
>
>
> 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/d/optout.

Re: Joy of Clojure example not working

[Greg D]

The second edition of Joy of Clojure, MEAP v10 shows the same error and 
progressive solution about half way down pdf-page 318 in section 9.2.4.

On Monday, May 19, 2014 6:39:26 AM UTC-7, gamma235 wrote:
>
> Hi guys, I am working through the pre-release second edition of Joy of 
> Clojure's section on multi-methods (section 9.2.~ : pg. 313), and am 
> getting different outputs from what they have printed in the book. I could 
> just skip over it, but I really want to understand this stuff. Could 
> someone tell me how to get the *(compile-cmd osx) *call at the end of the 
> code to produce the expected output:  *"/usr/bin/gcc" *? I have commented 
> out redundancy and moved a couple of lines for readability. Thanks in 
> advance! 
>
> J
>
>> (ns joy.udp
>>   (:refer-clojure :exclude [get]))
>>
>> (defn beget [this proto]
>>   (assoc this ::prototype proto))
>>
>> (defn get [m k]
>>   (when m
>> (if-let [[_ v] (find m k)]
>>   v
>>   (recur (::prototype m) k
>>
>> (def put assoc)
>>
>> ;;; compiler
>> (defmulti compiler :os)
>> (defmethod compiler ::unix [m] (get m :c-compiler))
>> (defmethod compiler ::osx [m] (get m :llvm-compiler))
>>
>> (def clone (partial beget {}))
>>
>  
>
>> (def unix {:os ::unix, :c-compiler "cc", :home "/home", :dev "/dev"})
>>
>  
>
>> (def osx (-> (clone unix)
>>  (put :os ::osx)
>>  (put :llvm-compiler "clang")
>>  (put :home "/Users")))
>>
>> ;;; home
>> (defmulti home :os)
>> (defmethod home ::unix [m] (get m :home))
>> (defmethod home ::bsd [m] "/home")
>>
>  
>
>> ;; the error on the call to (home osx) is contingent upon toggling the 
>> following lines. 
>
> ;(derive ::osx ::unix)
>> ;(derive ::osx ::bsd)
>> (prefer-method home ::unix ::bsd)
>> ;(remove-method home ::bsd)   
>> (derive (make-hierarchy) ::osx ::unix) 
>>
>> ;;; compile-cmd
>> (defmulti compile-cmd (juxt :os compiler))
>>
>> (defmethod compile-cmd [::osx "gcc"] [m]
>>   (str "/usr/bin/" (get m :c-compiler)))
>>
>> (defmethod compile-cmd :default [m]
>>   (str "Unsure where to locate " (get m :c-compiler)))
>> ;;
>>
>> (home osx) 
>>
> ;=> java.lang.IllegalArgumentException: No method in multimethod 'home' 
>> for dispatch value: :joy.udp/osx …
>>
>  ;; Should be: ;=> "/Users"
>
>
> (compile-cmd osx)
>
> ;=> "Unsure where to locate cc" 
>
>  ;; Should be: ;=> "/usr/bin/gcc"
>
>  
>
>> (compile-cmd unix)
>
> ;=> "Unsure where to locate cc"
>
> ;; this is the expected output 
>
>

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

Re: Must a page refresh fire an init event?

[Greg Knapp]

Sorry to revive and old thread but when searching for "clojurescript atom 
page refresh" this is one of the top results.

Thought it was worth mentioning that Alan Dipert has written a storage atom 
library <https://github.com/alandipert/storage-atom> that conveniently 
wraps around your application state atom and persists it in the browser's 
local storage (instead of using cookies). The usual warning about the type 
of information you should/shouldn't store in the client applies.

Regards, Greg

On Sunday, 22 January 2012 15:06:24 UTC, Folcon wrote:
>
> Hi Alex,
>
> No nothing like that, more like keeping track of where the user was so a 
> page refresh doesn't kill their state.
>
> I'm still working out how "one" does things, it took me a little while to 
> get how to add new template pages as I can't really use the browser repl. 
> (I'm waiting for lein integration). It will be a lot easier to understand 
> how things work when I can use my emacs repl :)...
>
> Regards,
> Folcon
>

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

Re: Improving pprint behavior for anonymous functions

[Greg D]

Simpler yet using metadata:
(ns example.ppfn)

(defn print-pf [pf]
  (if-let [ppf (::ppf (meta pf))] ppf pf))

(defmacro partial* [& args]
  `(let [m#  (pr-str '(partial* ~@args))
 pf# (with-meta (partial ~@args) {::ppf m#})]
 (defmethod print-method (class pf#) [o# w#] (print-simple 
(example.ppfn/print-pf o#) w#))
 pf#))

In use:
user=> (def p1 (partial* + 1))
#'user/p1
user=> (p1 5)
6
user=> p1
(example.ppfn/partial* + 1)
user=> (def comma-join (partial* clojure.string/join ", "))
#'user/comma-join
user=> (comma-join ['a 'b 'c])
"a, b, c"
user=> comma-join
(example.ppfn/partial* clojure.string/join ", ")

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

Re: Improving pprint behavior for anonymous functions

[Greg D]

The code below accounts for partials of the same arity.  However, there 
might be a better way to do this with clojure.reflect:
(defn print-partial [a-fn]
  (let [c  (class a-fn)
fields (into {} (->> c .getDeclaredFields
 (map #(vector (.getName %)
   (do (.setAccessible % true)
   (.get % a-fn))
f  (get fields "f")
fname  (loop [[ns & namespaces] (all-ns)]
 (let [nsmap (into {} (map #(try (vector (deref (second %)) 
(first %))
 (catch Exception e
   [::e nil]))
   (ns-publics ns)))]
   (if-let [fname (get nsmap f)]
 #_(symbol (str ns) fname)
 (str (ns-name ns) "/" fname)
 (if (empty? namespaces)
   f
   (recur namespaces)
args   (loop [args ""
  arg-num  1]
 (if-let [arg (get fields (str "arg" arg-num))]
   (recur (str args " " (pr-str arg)) (inc arg-num))
   args))]
(str "(partial " fname args ")")))

(defmacro partial* [fname arg0 & args]
  `(let [pf#  (partial ~fname ~arg0 ~@args)
 cpf# (class pf#)]
 (defmethod print-method cpf# [o# w#]
   (print-simple (print-partial o#) w#))
 pf#))

Trying out:
(def p6 (partial* + 1 2 3))
#'user/p6
user=> p6
(partial clojure.core/+ 1 2 3)
user=> (def t7 (partial* * 1 1 7))
#'user/t7
user=> t7
(partial clojure.core/* 1 1 7)
user=> p6
(partial clojure.core/+ 1 2 3)
user=> (def comma-join (partial* clojure.string/join ", "))
#'user/comma-join
user=> comma-join
(partial clojure.string/join ", ")
user=> (p6 100)
106
user=> (t7 5)
35
user=> (comma-join ['a 'b 'c])
"a, b, c"





On Friday, April 25, 2014 2:55:23 PM UTC-7, Greg D wrote:
>
> Got it. The macro, as is, will displace the print method for the same 
> arity.
>
> On Friday, April 25, 2014 2:50:34 PM UTC-7, Gary Trakhman wrote:
>>
>> Ah, I think I was mistaken in a detail, but generally correct.  Try it 
>> with two partials of the same arity.
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2460
>>
>>
>> On Fri, Apr 25, 2014 at 5:47 PM, Greg D  wrote:
>>
>>> I guess I don't understand the problem, or what is meant by "different 
>>> classes".  A counter-example would be helpful.
>>>
>>> Further transcript using the macro:
>>> (def p6 (partial* + 1 2 3))
>>> #'user/p6
>>> user=> (class p6)
>>> clojure.core$partial$fn__4194
>>> user=> (def p10 (partial* + 1 2 3 4))
>>> #'user/p10
>>> user=> (class p10)
>>> clojure.core$partial$fn__4196
>>>
>>> user=> p6
>>> (partial + 1 2 3)
>>> user=> p10
>>> (partial + 1 2 3 4)
>>> user=> (p6 100)
>>> 106
>>> user=> (p10 100)
>>> 110
>>>
>>> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>>>
>>>> That's not going to work, all the return classes of partial are the 
>>>> same class.
>>>>
>>>>
>>>> On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:
>>>>
>>>>> I don't know if this is considered good Clojure, but you could define 
>>>>> a print-method within a macro to set up the normal string representation 
>>>>> for the partial function:
>>>>> (defmacro partial* [fname arg0 & args]
>>>>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>>>>  cpf# (class pf#)]
>>>>>  (defmethod print-method cpf# [o# w#]
>>>>>(if (nil? '~args)
>>>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
>>>>> ")") w#)
>>>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
>>>>> ~@(map #(str " " (pr-str %)) args) ")") w#)))
>>>>>  pf#))
>>>>>
>>>>> A transcript of some quick examples:
>>>>> user=> (def p6 (partial* + 1 2 3))
>>>>> #'user/p6
>>>>> user=> p6
>>>>> (partial + 1 2 3)
>>>>> user=> (p6 7)
>>

Re: Improving pprint behavior for anonymous functions

[Greg D]

Got it. The macro, as is, will displace the print method for the same arity.

On Friday, April 25, 2014 2:50:34 PM UTC-7, Gary Trakhman wrote:
>
> Ah, I think I was mistaken in a detail, but generally correct.  Try it 
> with two partials of the same arity.
>
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2460
>
>
> On Fri, Apr 25, 2014 at 5:47 PM, Greg D 
> > wrote:
>
>> I guess I don't understand the problem, or what is meant by "different 
>> classes".  A counter-example would be helpful.
>>
>> Further transcript using the macro:
>> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> (class p6)
>> clojure.core$partial$fn__4194
>> user=> (def p10 (partial* + 1 2 3 4))
>> #'user/p10
>> user=> (class p10)
>> clojure.core$partial$fn__4196
>>
>> user=> p6
>> (partial + 1 2 3)
>> user=> p10
>> (partial + 1 2 3 4)
>> user=> (p6 100)
>> 106
>> user=> (p10 100)
>> 110
>>
>> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>>
>>> That's not going to work, all the return classes of partial are the same 
>>> class.
>>>
>>>
>>> On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:
>>>
>>>> I don't know if this is considered good Clojure, but you could define a 
>>>> print-method within a macro to set up the normal string representation for 
>>>> the partial function:
>>>> (defmacro partial* [fname arg0 & args]
>>>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>>>  cpf# (class pf#)]
>>>>  (defmethod print-method cpf# [o# w#]
>>>>(if (nil? '~args)
>>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
>>>> w#)
>>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
>>>> ~@(map #(str " " (pr-str %)) args) ")") w#)))
>>>>  pf#))
>>>>
>>>> A transcript of some quick examples:
>>>> user=> (def p6 (partial* + 1 2 3))
>>>> #'user/p6
>>>> user=> p6
>>>> (partial + 1 2 3)
>>>> user=> (p6 7)
>>>> 13
>>>> user=> (def re-find-foo (partial* re-find #"foo"))
>>>> #'user/re-find-foo
>>>> user=> re-find-foo
>>>> (partial re-find #"foo")
>>>> user=> (re-find-foo "abcdefooghi")
>>>> "foo"
>>>>
>>>>
>>>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> There has been one thing bugging me for a long time that seems worth 
>>>>> it to fix, and I was wondering if anyone else has had the same problem. I 
>>>>> have enjoyed using Clojure's REPL and embracing a Clojure-style data 
>>>>> model 
>>>>> for my app, where everything is a glorified map or vector and there are 
>>>>> no 
>>>>> private fields. I even have a simple dump feature that tells me the 
>>>>> entire 
>>>>> state of my app <https://github.com/google/hesokuri> that was 
>>>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>>>> black box data structures.
>>>>>
>>>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>>>> anonymous functions with closures. For instance, (partial + 42) returns 
>>>>> an 
>>>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>>>> #
>>>>>
>>>>> So I've avoided anonymous functions in my app except when they exist 
>>>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>>>> function practically. The best solution I've come up with is to transform 
>>>>> anonymous functions when preparing the application dump. (See the 
>>>>> implementation<https://github.com/google/hesokuri/blob/b60cb7222cfdd672e394ef6f22b80c94278fe3a0/src/hesokuri/see.clj#L35>)
>>>>>  
>>>>> This makes (partial + 42) look like this:
>>>>>
>>>>> {:fn-class clojure.c

Re: Improving pprint behavior for anonymous functions

[Greg D]

I guess I don't understand the problem, or what is meant by "all the return 
classes of partial are the same class".  A counter-example would be helpful.

Further transcript using the macro:
user=> (def p6 (partial* + 1 2 3))
#'user/p6
user=> (class p6)
clojure.core$partial$fn__4194
user=> (def p10 (partial* + 1 2 3 4))
#'user/p10
user=> (class p10)
clojure.core$partial$fn__4196
user=> p6
(partial + 1 2 3)
user=> p10
(partial + 1 2 3 4)
user=> (p6 100)
106
user=> (p10 100)
110

On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
> That's not going to work, all the return classes of partial are the same 
> class.
>
>
> On Fri, Apr 25, 2014 at 5:26 PM, Greg D 
> > wrote:
>
>> I don't know if this is considered good Clojure, but you could define a 
>> print-method within a macro to set up the normal string representation for 
>> the partial function:
>> (defmacro partial* [fname arg0 & args]
>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>  cpf# (class pf#)]
>>  (defmethod print-method cpf# [o# w#]
>>(if (nil? '~args)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
>> w#)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
>> #(str " " (pr-str %)) args) ")") w#)))
>>  pf#))
>>
>> A transcript of some quick examples:
>> user=> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> p6
>> (partial + 1 2 3)
>> user=> (p6 7)
>> 13
>> user=> (def re-find-foo (partial* re-find #"foo"))
>> #'user/re-find-foo
>> user=> re-find-foo
>> (partial re-find #"foo")
>> user=> (re-find-foo "abcdefooghi")
>> "foo"
>>
>>
>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>>
>>> Hi,
>>>
>>> There has been one thing bugging me for a long time that seems worth it 
>>> to fix, and I was wondering if anyone else has had the same problem. I have 
>>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>>> my app, where everything is a glorified map or vector and there are no 
>>> private fields. I even have a simple dump feature that tells me the entire 
>>> state of my app <https://github.com/google/hesokuri> that was 
>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>> black box data structures.
>>>
>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>> anonymous functions with closures. For instance, (partial + 42) returns an 
>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>> #
>>>
>>> So I've avoided anonymous functions in my app except when they exist 
>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>> function practically. The best solution I've come up with is to transform 
>>> anonymous functions when preparing the application dump. (See the 
>>> implementation<https://github.com/google/hesokuri/blob/b60cb7222cfdd672e394ef6f22b80c94278fe3a0/src/hesokuri/see.clj#L35>)
>>>  
>>> This makes (partial + 42) look like this:
>>>
>>> {:fn-class clojure.core$partial$fn__4228,
>>>  "arg1" 42,
>>>  "f" {:fn-class clojure.core$_PLUS_}}
>>>
>>> Which isn't great (I'd like to have filenames and line numbers for each 
>>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>>> The function's JVM class and the closured values are revealed. It would be 
>>> nice to implement this natively. Having only passing familiarity with the 
>>> Clojure code base, to solve it I think one could:
>>>
>>>- give anonymous functions a .getClosure method which creates a view 
>>>of the closure on-demand
>>>- (optional) change their .toString implementation to include this 
>>>information
>>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction 
>>> etc...)" 
>>>?) 
>>>
>>> Another feature that would go nicely with this is smarter equality 
>>> semantics for anonymous functions, so 

Re: Improving pprint behavior for anonymous functions

[Greg D]

I guess I don't understand the problem, or what is meant by "different 
classes".  A counter-example would be helpful.

Further transcript using the macro:
(def p6 (partial* + 1 2 3))
#'user/p6
user=> (class p6)
clojure.core$partial$fn__4194
user=> (def p10 (partial* + 1 2 3 4))
#'user/p10
user=> (class p10)
clojure.core$partial$fn__4196
user=> p6
(partial + 1 2 3)
user=> p10
(partial + 1 2 3 4)
user=> (p6 100)
106
user=> (p10 100)
110

On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
> That's not going to work, all the return classes of partial are the same 
> class.
>
>
> On Fri, Apr 25, 2014 at 5:26 PM, Greg D 
> > wrote:
>
>> I don't know if this is considered good Clojure, but you could define a 
>> print-method within a macro to set up the normal string representation for 
>> the partial function:
>> (defmacro partial* [fname arg0 & args]
>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>  cpf# (class pf#)]
>>  (defmethod print-method cpf# [o# w#]
>>(if (nil? '~args)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
>> w#)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
>> #(str " " (pr-str %)) args) ")") w#)))
>>  pf#))
>>
>> A transcript of some quick examples:
>> user=> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> p6
>> (partial + 1 2 3)
>> user=> (p6 7)
>> 13
>> user=> (def re-find-foo (partial* re-find #"foo"))
>> #'user/re-find-foo
>> user=> re-find-foo
>> (partial re-find #"foo")
>> user=> (re-find-foo "abcdefooghi")
>> "foo"
>>
>>
>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>>
>>> Hi,
>>>
>>> There has been one thing bugging me for a long time that seems worth it 
>>> to fix, and I was wondering if anyone else has had the same problem. I have 
>>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>>> my app, where everything is a glorified map or vector and there are no 
>>> private fields. I even have a simple dump feature that tells me the entire 
>>> state of my app <https://github.com/google/hesokuri> that was 
>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>> black box data structures.
>>>
>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>> anonymous functions with closures. For instance, (partial + 42) returns an 
>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>> #
>>>
>>> So I've avoided anonymous functions in my app except when they exist 
>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>> function practically. The best solution I've come up with is to transform 
>>> anonymous functions when preparing the application dump. (See the 
>>> implementation<https://github.com/google/hesokuri/blob/b60cb7222cfdd672e394ef6f22b80c94278fe3a0/src/hesokuri/see.clj#L35>)
>>>  
>>> This makes (partial + 42) look like this:
>>>
>>> {:fn-class clojure.core$partial$fn__4228,
>>>  "arg1" 42,
>>>  "f" {:fn-class clojure.core$_PLUS_}}
>>>
>>> Which isn't great (I'd like to have filenames and line numbers for each 
>>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>>> The function's JVM class and the closured values are revealed. It would be 
>>> nice to implement this natively. Having only passing familiarity with the 
>>> Clojure code base, to solve it I think one could:
>>>
>>>- give anonymous functions a .getClosure method which creates a view 
>>>of the closure on-demand
>>>- (optional) change their .toString implementation to include this 
>>>information
>>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction 
>>> etc...)" 
>>>?) 
>>>
>>> Another feature that would go nicely with this is smarter equality 
>>> semantics for anonymous functions, so that any two anonymous functions 
>>> gene

Re: Improving pprint behavior for anonymous functions

[Greg D]

I don't know if this is considered good Clojure, but you could define a 
print-method within a macro to set up the normal string representation for 
the partial function:
(defmacro partial* [fname arg0 & args]
  `(let [pf#  (partial ~fname ~arg0 ~@args)
 cpf# (class pf#)]
 (defmethod print-method cpf# [o# w#]
   (if (nil? '~args)
 (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") w#)
 (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
#(str " " (pr-str %)) args) ")") w#)))
 pf#))

A transcript of some quick examples:
user=> (def p6 (partial* + 1 2 3))
#'user/p6
user=> p6
(partial + 1 2 3)
user=> (p6 7)
13
user=> (def re-find-foo (partial* re-find #"foo"))
#'user/re-find-foo
user=> re-find-foo
(partial re-find #"foo")
user=> (re-find-foo "abcdefooghi")
"foo"


On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>
> Hi,
>
> There has been one thing bugging me for a long time that seems worth it to 
> fix, and I was wondering if anyone else has had the same problem. I have 
> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
> my app, where everything is a glorified map or vector and there are no 
> private fields. I even have a simple dump feature that tells me the entire 
> state of my app  that was 
> ridiculously easy to implement, and that takes advantage of the lack of 
> black box data structures.
>
> One thing that doesn't really fit in this paradigm is (ironically) 
> anonymous functions with closures. For instance, (partial + 42) returns an 
> anonymous function, and in the REPL or an app dump, it looks hideous:
> #
>
> So I've avoided anonymous functions in my app except when they exist 
> transiently, and don't appear in the dump (for instance, in (map #(str % 
> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
> function practically. The best solution I've come up with is to transform 
> anonymous functions when preparing the application dump. (See the 
> implementation)
>  
> This makes (partial + 42) look like this:
>
> {:fn-class clojure.core$partial$fn__4228,
>  "arg1" 42,
>  "f" {:fn-class clojure.core$_PLUS_}}
>
> Which isn't great (I'd like to have filenames and line numbers for each 
> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
> The function's JVM class and the closured values are revealed. It would be 
> nice to implement this natively. Having only passing familiarity with the 
> Clojure code base, to solve it I think one could:
>
>- give anonymous functions a .getClosure method which creates a view 
>of the closure on-demand
>- (optional) change their .toString implementation to include this 
>information
>- add logic to clojure.pprint to use the .getClosure method (I guess 
>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction etc...)" 
>?)
>
> Another feature that would go nicely with this is smarter equality 
> semantics for anonymous functions, so that any two anonymous functions 
> generated at the same point in code with equal closures are equal. This 
> means if I have a function like this:
>
> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>
> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
> making functions behave a lot more like values. I would love to have this 
> particular feature too, although I'm having trouble coming up with a 
> non-contrived example.
>
> I'd like to hear some thoughts on this. Thanks!
>
> Matt
>
>
>
>

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

Re: puzzled by RuntimeException

[Greg D]

Thanks Alex and Steve,

I've based a ton of work on keywords where the second character is numeric.

The http://clojure.org/readers page should be the normative reference.
>

The work is based on *reliance* on the definitions in the readers page. I 
believe it is unambiguous in demanding a colon as the first character of a 
keyword, and allowing the second character to be numeric.

I am frightened that opinions differ; especially Rich's, obviously.

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

Re: puzzled by RuntimeException

[Greg D]

I believe this is a problem in REPL-y, which is used when using 'lein repl'.

I used Cider to start a nREPL server, then used 'leing repl :connect' to 
get the REPL-y interface.

The problem was evident in the latter, but not the former.  I opened an 
issue for REPL-y.

Thanks again, Steve

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

Re: puzzled by RuntimeException

[Greg D]

Steve,

Thanks.  I did a quick check, and it seems that I don't get exceptions when 
I start the repl as you do.

I normally start mine with 'lein repl'.  You've given me a good lead to 
investigate.

Greg

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

puzzled by RuntimeException

[Greg D]

The sequence in the transcript below shows runtime exceptions when a 
numeric keyword is followed by a list starting with a symbol or character.

Would anyone help me with a reason for the failing cases?

user=> (clojure-version)
"1.6.0"
user=> '(:42 a)
(:42 a)
user=> '(:42 "a")
(:42 "a")
user=> '(:42 \a)
(:42 \a)
user=> '(:42 nil)
(:42 nil)
user=> '(:42 true)
(:42 true)
user=> '(:42 :43)
(:42 :43)
user=> '(:42 (a))

RuntimeException EOF while reading, starting at line 1  
clojure.lang.Util.runtimeException (Util.java:221)

RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:221)
user=> '(:42 ("a"))
(:42 ("a"))
user=> '(:42 (\a))

RuntimeException EOF while reading, starting at line 1  
clojure.lang.Util.runtimeException (Util.java:221)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:221)

user=> '(:42 (nil))

RuntimeException EOF while reading, starting at line 1  
clojure.lang.Util.runtimeException (Util.java:221)

user=> RuntimeException Unmatched delimiter: )  
clojure.lang.Util.runtimeException (Util.java:221)


user=> '(:42 (true))

RuntimeException EOF while reading, starting at line 1  
clojure.lang.Util.runtimeException (Util.java:221)

user=> RuntimeException Unmatched delimiter: )  
clojure.lang.Util.runtimeException (Util.java:221)


user=> '(:42 (:43))
(:42 (:43))
user=> 

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

Re: Thoughts on bags?

[Greg D]

Added link missing in previous post.

A simple multiset/bag implementation for 
Clojure

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

Re: Thoughts on bags?

[Greg D]

While searching for MultiSet or Bag resources, I found this implementation 
by Achim Passen at: A simple multiset/bag implementation for Clojure.

However, I found I could meet my needs by adding functions to treat 
vectors, or other collection types, as unordered. These can then be used 
directly, or in the definition of your own specialized types.

For the hash, from Clojure Data Structures:

(defn hash-unordered [collection]
  (-> (reduce unchecked-add-int 0 (map hash collection))
  (mix-collection-hash (count collection


For equality:
(defn equals-unordered [coll-a coll-b]
  "Treat collections as unordered for 1st level of comparison."
  (or (identical? coll-a coll-b)
  (and (empty? coll-a) (empty? coll-b))
  (and (= (hash-unordered coll-a) (hash-unordered coll-b))
   (let [set-a (set coll-a)
 set-b (set coll-b)]
 (and (= set-a set-b)
  (loop [[item & items] (seq set-a)]
(let [finder #(= item %)
  found-a (filter finder coll-a)
  found-b (filter finder coll-b)]
  (if (not= (count found-a) (count found-b))
false
(if (empty? items)
  true
  (recur items))

Neither Achim's deftype, nor the above, is likely as efficient as 
implementation as a core collection MultiSet.

The attached file has a trivial implementation of a deftype showing the 
functions in use. It defines a shopping cart where the items are kept on a 
vector, which is treated as an unordered collection. A transcript of 
playing with the shopping cart follows:

user=> (load-file "shopping_cart.clj")
#'example.multi-set/make-shopping-cart
user=> (use 'example.multi-set)
nil
user=> (def cart0 (make-shopping-cart 'carrots 'beans 'eggs))
#'user/cart0
user=> cart0
(make-shopping-cart carrots beans eggs)
user=> (def cart1 (make-shopping-cart 'eggs 'carrots 'beans))
#'user/cart1
user=> cart1
(make-shopping-cart eggs carrots beans)
user=> (def cart2 (make-shopping-cart 'ham 'eggs 'carrots 'beans))
#'user/cart2
user=> cart2
(make-shopping-cart ham eggs carrots beans)
user=> (= cart0 cart1)
true
user=> (= cart1 cart2)
false  

Greg

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


shopping_cart.clj
Description: Binary data

Re: Emacs - error with `nrepl-jack-in'

[greg r]

You should consider going to CIDER:

https://github.com/clojure-emacs/cider

The command is 'cider-jack-in'.

Here's a page with a lot of install info:

http://clojure-doc.org/articles/tutorials/emacs.html

There are many web pages out there with obsolete information on Clojure and 
emacs.
The above page is one of the most up-to-date.

Regards,
Greg

On Thursday, April 17, 2014 9:45:13 PM UTC-4, Thorsten Jolitz wrote:
>
>
> Hi List, 
>
> just installed lein2 and can start 'lein2 repl' successfully on the 
> command-line. 'lein repl' works too, since I defined an alias in my 
> .bashrc. 
>
> After installing packages clojure-mode and nrepl in Emacs, I get this 
> error when trying `nrepl-jack-in': 
>
> ,- 
> | error in process sentinel: Could not start nREPL server: /bin/bash: Line 
> | 1: lein: Command not found. 
> `- 
>
> I'm on Archlinx with 
>
> #+begin_src emacs-lisp 
>  (emacs-version) 
> #+end_src 
>
> #+results: 
> : GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.7) 
> :  of 2014-01-28 on var-lib-archbuild-extra-x86_64-juergen 
>
> I googled some related sites and it seems it might be an Emacs (exec-) 
> path 
> problem, but a reboot did not help. 
>
> -- 
> cheers, 
> Thorsten 
>
>

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

Re: Thoughts on bags?

[Greg D]

While searching for MultiSet or Bag resources, I found this implementation 
by Achim Passen at: A simple multiset/bag implementation for 
Clojure<https://github.com/achim/multiset>
.

However, I found I could meet my needs by adding functions to treat 
vectors, or other collection types, as unordered.

For the hash, from Clojure Data 
Structures<http://clojure.org/data_structures#hash>
:

(defn hash-unordered [collection]
  (-> (reduce unchecked-add-int 0 (map hash collection))
  (mix-collection-hash (count collection


For equality:
(defn equals-unordered [coll-a coll-b]
  "Treat collections as unordered for 1st level of comparison."
  (or (identical? coll-a coll-b)
  (and (empty? coll-a) (empty? coll-b))
  (let [set-a (set coll-a)
set-b (set coll-b)]
(and (= set-a set-b)
 (loop [[item & items] (seq set-a)]
   (let [finder #(= item %)
 found-a (filter finder coll-a)
 found-b (filter finder coll-b)]
 (if (not= (count found-a) (count found-b))
   false
   (if (empty? items)
 true
 (recur items)

Neither Achim's deftype, nor the above, is likely as efficient as a core 
collection MultiSet. In the meantime, I hope these observations are useful.

Greg

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

Re: Questions regarding Map vs Record and usage

[Greg D]

FWIW, I use:

   - (->Book "Lord of the Rings", "Tolkien")
  - when I define the record instance with the default fields, and the 
  number of default fields is a small number
   - (map->Book {:title "The Fellowship of the Ring",
  :author "Tolkien",
  :series "The Lord of the Rings",
  :publisher "Mariner Books",
  :year 2012,
  :ISBN-10 "0547928211",
  :my-rating 10}) 
  - The explicit key names are good documentation when 
  - there are many fields in the defrecord, or
     - when adding entries not in the defrecord (eg. my-rating)
  
Greg

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

Re: alternative syntax for Clojure? Haskell?

[greg r]

I can't answer your question from my own experience, but there does seem to 
be a way to develop your own language on the JVM:

https://www.eclipse.org/Xtext/index.html

You could create a "DSL" to your precise specifications.

Regards,
Greg


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

self-evaluation of record instances

[Greg D]

Greetings,

The nuance below took a long time to identify and reduce from a test 
failure. Should it be considered a bug?

$ lein repl
nREPL server started on port 52758 on host 127.0.0.1
REPL-y 0.3.0
Clojure 1.6.0


user=> (defrecord Fields0 [])  ; record with 0 fields
user.Fields0
user=> (defrecord Fields1 [f]) ; record with 1 field
user.Fields1
user=> (def f0 (->Fields0)); instance with empty map
#'user/f0
user=> (def f0x (map->Fields0 {:x 0})) ; instance with not-empty map, due 
to extra field
#'user/f0x
user=> (def f1 (map->Fields1 {}))  ; instance with not-empty map, 
declared field is nil
#'user/f1
user=> f0
#user.Fields0{}
user=> f0x
#user.Fields0{:x 0}
user=> f1
#user.Fields1{:f nil}
user=> (eval f0)   ; *** morphs to empty map on eval ***
{}
user=> (eval f0x)  ; self-evaluates when non-empty map, 
field added
#user.Fields0{:x 0}
user=> (eval f1)   ; self-evaluates when non-empty map, 
declared field
#user.Fields1{:f nil}
user=> 

Greg

p.s. A little help with "not quite getting 
refs"<https://groups.google.com/forum/#!topic/clojure/o9FiG1kCt6I>, 
please? Or is this the wrong forum for such a question?

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

not quite getting refs

[Greg D]

I've looked, but can't find, a discussion of the choice of a history 
mechanism for refs.

I can't understand why the transactions just don't check #'identical? for 
the ref value, rather than maintaining a history queue. In other words, I 
don't see why
(dosync (ref-set foo @foo)))
should cause other ongoing transactions, that use foo, to retry. Nothing 
about foo has changed that will alter a retried transaction.

Since an #'identical? mechanism would seem to

   - be easier to implement
   - be faster to check at the end of a tranaction
   - cause fewer retries

it must be that I don't really "get it" yet. Does anyone have a doc pointer 
that would help with the details?

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

Re: STM history queues, when is a snapshot pushed

[Greg D]

Having learned a little more about refs and transactions from M. Fogus and 
C. Houser "The Joy of Clojure, Second Edition", 
I altered the stress-ref function from 10.2.4. Using Clojure 1.5.1:

(defn stress-ref [r]
  (let [slow-tries (atom 0)]
(future
 (dosync
  (swap! slow-tries inc)
  (Thread/sleep 200)
  @r)
 (println (format "r is: %s, meta: %s, history: %d, after: %d tries"
  @r (meta @r) (.getHistoryCount r) @slow-tries)))
(dotimes [i 500]
  (Thread/sleep 10)
  (dosync (alter r #(let [r0 (first %)]
 (condp = r0
 :identical %
 := (with-meta % {:mkw (inc (:mkw (meta 
%)))})
 (with-meta [(inc r0)] {:mkw (inc (:mkw (meta 
%)))}))
:done))

Using this function in the following ways
user=> (stress-ref (ref (with-meta [:identical] {:mkw 0})))
:done
r is: [:identical], meta: {:mkw 0}, history: 10, after: 26 tries

user=> (stress-ref (ref (with-meta [:=] {:mkw 0})))
:done
r is: [:=], meta: {:mkw 500}, history: 10, after: 26 tries

user=> (stress-ref (ref (with-meta [0] {:mkw 0})))
:done
r is: [500], meta: {:mkw 500}, history: 10, after: 26 tries

>From these results I infer that a snapshot is pushed to history whenever 
alter (et al) are used. Any efficiencies need to be implemented in the 
Clojure code, eg.
(defn stress-ref-equal [r]
  (let [slow-tries (atom 0)]
(future
 (dosync
  (swap! slow-tries inc)
  (Thread/sleep 200)
  @r)
 (println (format "r is: %s, meta: %s, history: %d, after: %d tries"
  @r (meta @r) (.getHistoryCount r) @slow-tries)))
(dotimes [i 500]
  (Thread/sleep 10)
  (dosync (let [r0 (first @r)]
(condp = r0
:identical (ensure r)
:= (ensure r)
(alter r #(with-meta [(inc r0)] {:mkw (inc (:mkw (meta 
%)))}))
:done))

user=> (stress-ref-equal (ref (with-meta [:identical] {:mkw 0})))
r is: [:identical], meta: {:mkw 0}, history: 0, after: 1 tries
:done

user=> (stress-ref-equal (ref (with-meta [:=] {:mkw 0})))
r is: [:=], meta: {:mkw 0}, history: 0, after: 1 tries
:done

user=> (stress-ref-equal (ref (with-meta [0] {:mkw 0})))
:done
r is: [500], meta: {:mkw 500}, history: 10, after: 26 tries

The documentation at Refs and Transactions  only 
refers to "change" without defining what is meant by change. Given the 
admonition not to rely on inferences as made above, what's a coder to do? 
Future optimization of refs and transactions may break the code.

As a beginner, I can't tell if I'm just confused, or if this is actually 
confusing.

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

STM history queues, when is a snapshot pushed

[Greg D]

Is a new snapshot pushed onto the history queue of a ref when

   1. every time the ref is a target of alter, commute, ref-set, reset, 
   alter-meta!, or reset-meta!, or
   2. only when the committed value for the ref is not identical to the 
   value at the end of the history queue?
   
When checking the committability of a ref before the end of a transaction, 
is the check that

   1. the end position of the history queue for that ref is the same as it 
   was at the beginning of the transaction, or
   2. the value of the ref at the end of the history queue is identical to 
   the value at the beginning of the transaction?

For both questions, choice 1 appears to be unquestionable safe, but could 
sponsor a higher number of retries. The choice 2s may conserve some 
retries, but I'm not sure about the safety. 

For both questions, the implementation complexity and efficiency seem 
similar.

At any rate, the actual implementation is not a part of the documented API, 
yet could affect how one codes transaction functions. Even if I dug through 
the Java source to form my own impressions, one is not supposed to rely on 
such behaviour.

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

Re: non-equality (=) of records nuance

[Greg D]

I'm on 1.5.1

I have a workaround:

   - instead of 
   - (map->Foo this)
   - use
  -  (map->Foo (into {} this))
  

On Tuesday, March 18, 2014 5:47:46 PM UTC-7, Alex Miller wrote:
>
> What Clojure version are you on?

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

non-equality (=) of records nuance

[Greg D]

Greetings,

I'm confused by the failure of 2 record instances to compare as equal, only 
when generated by a protocol method and having extra fields.

The code below shows this, with uninformative REPL responses snipped. The 
attached file has similar code as a clojure.test.

Would somebody please help me understand the underlying mechanism. I'll 
need to develop a workaround to avoid confounding library users.

Thanks, Greg

user=> ;;; Set up protocol and records
user=> (defprotocol FooBar (clone [this]) (switch [this]))
user=> (defrecord Foo [])
user=> (defrecord Bar [])
user=> (extend-type Foo FooBar (clone [this] (map->Foo this)) (switch 
[this] (map->Bar this)))
user=> (extend-type Bar FooBar (clone [this] (map->Bar this)) (switch 
[this] (map->Foo this)))

user=> ;;; Create 4 (.equal) instances of Bar, no fields; all works as 
expected
user=> (def foo0 (->Foo))
user=> (def bar0 (->Bar))
user=> (def bar1 (->Bar))
user=> (def bar-switch-foo0 (switch foo0))
user=> (def bar-clone-bar0 (clone bar0))
user=> bar0
#user.Bar{}
user=> bar1
#user.Bar{}
user=> bar-switch-foo0
#user.Bar{}
user=> bar-clone-bar0
#user.Bar{}
user=> (= bar0 bar1); gets expected true
true
user=> (= bar0 bar-switch-foo0) ; gets expected true
true
user=> (= bar0 bar-clone-bar0)  ; gets expected true
true

user=> ;;; Create 4 (.equal) instances of Bar with an added field; 
unexpected results
user=> (def x-foo0 (map->Foo {:field "xtra"}))
user=> (def x-bar0 (map->Bar {:field "xtra"}))
user=> (def x-bar1 (map->Bar {:field "xtra"}))
user=> (def bar-switch-x-foo0 (switch x-foo0))
user=> (def bar-clone-x-bar0 (clone x-bar0))
user=> x-bar0
#user.Bar{:field "xtra"}
user=> x-bar1
#user.Bar{:field "xtra"}
user=> bar-switch-x-foo0
#user.Bar{:field "xtra"}
user=> bar-clone-x-bar0
#user.Bar{:field "xtra"}
user=> (= x-bar0 x-bar1); gets expected true
true
user=> (= x-bar0 bar-switch-x-foo0) ; gets UNEXPECTED
false
user=> (= x-bar0 bar-clone-x-bar0)  ; gets UNEXPECTED
false
user=> (= bar-switch-x-foo0 bar-clone-x-bar0)   ; gets UNEXPECTED
false
user=> (.equals x-bar0 bar-switch-x-foo0)   ; .equals is true
true
user=> (.equals x-bar0 bar-clone-x-bar0); .equals is true
true
user=> (.equals bar-switch-x-foo0 bar-clone-x-bar0) ; .equals is true
true

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


record_instance_equality_test.clj
Description: Binary data

Re: Help about using clojure in org mode in Emacs with CIDER

[greg r]

The worg documentation for the Clojure language has been updated:
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html

The installation instructions should result in a current 
Clojure/CIDER/clojure-mode/Leiningen system.

Regards,
Greg

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Help about using clojure in org mode in Emacs with CIDER

[greg r]

Hi Bastien, yes I will post a report at the mailing list today.

Regards,
Greg

On Tuesday, January 28, 2014 12:55:20 AM UTC-5, Bastien Guerry wrote:
>
> Hi Greg, 
>
> greg r > writes: 
>
> > I compared a computer set up with the latest of everything (org/emacs 
> > /CIDER) and compared to an older computer still using nrepl-jack-in 
> > and older versions of everything else.  The behavior is definitely 
> > different with the newer system, and can be seen with a very simple 
> > case: 
>
> Can you report this to the org-mode mailing list? 
> https://lists.gnu.org/mailman/listinfo/emacs-orgmode 
>
> Thanks, 
>
> -- 
>  Bastien 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Help about using clojure in org mode in Emacs with CIDER

[greg r]

I compared a computer set up with the latest of everything 
(org/emacs/CIDER) and compared to an older computer still using 
nrepl-jack-in and older versions of everything else.  The behavior is 
definitely different with the newer system, and can be seen with a very 
simple case:

Code block:
#+begin_src clojure :results value raw
[1 2 3 4]
#+end_src

New: (CIDER)
#+RESULTS:
[1 2 3 4]

Old: (nrepl)
#+RESULTS:
| 1 | 2 | 3 | 4 |

It appears the conversion to org table is not happening.

Regards,
Greg

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Help about using clojure in org mode in Emacs with CIDER

[greg r]

We had a discussion about this in the cider-emacs group:

https://groups.google.com/forum/#!topic/cider-emacs/xj-HYTAA-D0

Bastien's page on using Overtone with Clojure in org code blocks is very 
informative with regards to setting it all up:

http://bzg.fr/emacs-org-babel-overtone-intro.html

Note that the worg page for Clojure is out of date:

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html

This references swank-clojure which is depracated.
I would like to edit this page to bring it up to date with Cider, and I 
would like to help
as soon as I figure out the process with keys and git!

Good luck with org-mode, cider and Clojure code blocks.  It's a great way 
to code and experiment, as well
as create dynamic documents.  I've had very good results with the system.

Regards,
Greg

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

No such namespace warning with Clojurescript repl

[Greg Chapman]

I've been working through the Clojurescript tutorial here: 
https://github.com/magomimmo/modern-cljs

When compiling step 2, which adds a file requiring clojure.browser.repl, I 
get a "WARNING: No such namespace: e at line 71" (in repl.cljs). The code 
in repl.cljs is:

  (event/listen connection
> :success
> (fn [e]
>   (net/transmit
>repl-connection
>:evaluate-javascript
>(.getResponseText e/currentTarget
>  ()
>
>
which does appear to be treating the event object e as a namespace. Should 
that be changed to (.- currentTarget e) ? 


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: How to go about 'proving' why dynamically typed languages are better.

[Greg Bowyer]

js> Array(16).join("wat" - 1) + " Batman!"
"NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!"
js> 


On Tuesday, October 8, 2013 6:07:47 AM UTC-7, Laurent PETIT wrote:
>
> 2013/10/8 Robert Day >
>
>>
>> On 08/10/13 13:49, Nando Breiter wrote:
>>
>>>
>>>
>>>
>>> If you try and add 10 to "Hello" in a typed language, you get an error. 
>>> If you try to do the same in a dynamic language, you get an error.
>>>
>>
>> Not necessarily...
>>
>> $ perl
>> print 10 + "Hello", "\n"
>>
>>
>> ^D
>> 10
>> $
>>
>>
> Then don't use Perl :-p
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: How to go about 'proving' why dynamically typed languages are better.

[Greg]

I support the sentiment expressed in your email. +1

Type systems are nice, just don't force them upon anyone. Keep the C++ at bay.

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

On Oct 6, 2013, at 7:16 AM, Chris Zheng  wrote:

> Thanks Mike for your reminder to be pragmatic. It is definitely the way to 
> go. Clojure's an incredible language for this.
> 
> This is going to be a longish post as I should better explain my position. It 
> is just a brief sketch of the problem but I think that we should be thinking 
> about it more as a fun exercise rather than a way to troll the 
> haskell/scala/ml mailing lists.
> 
> I'm not the type of person to get overly academic but I still want to have 
> `faith` in the tools that I'm using. In Indian traditions of philosophy, the 
> term `shraddah` is translated as `faith` but it literally means `that which 
> binds you` or `that which is unwavering`. Logical foundations of practices 
> and beliefs are debated by practitioners and scholars alike. To debate and 
> win against those in opposition, one has to have a good reason to believe in 
> their practice. In other words, academics is a VERY powerful tool for faith.
> 
> Because of the vast amounts of academic work around types, we now have a 
> `type` priesthood and an increasingly mass of `type converts` who are very 
> inflammatory against anything non-typed languages. The cult of haskell will 
> always look down on the cult of lisp/javascript/python/ruby, laugh and say 
> `you guys suck because you don`t have A, B, C which are features of type 
> inference`.
> 
> Now with the `cult of clojure`, we can say YES WE DO (Typed Clojure)… but not 
> only that, we should also be able to say: 
> 
> "Because we have optional typing, here are a bunch of problems that we can 
> solve very easy because X, Y and Z are not restricted by type inference."
> 
> Now The the debate actually moves forward, so that we ask ourselves whether 
> type-inference is suitable for solving a particular class of problems rather 
> than putting ourselves into opposite camps.
> 
> I have to come back to Godel's work as it is (quoting the lecturer) `The most 
> profound result to have come out of logic for the last 2000 years, ever since 
> the time of Aristotle`. What Godel did, was to write a hack that crashed a 
> what was thought to be an uncrashable system.
> 
> Principia Mathematica (PM) was a huge book which described how one can of 
> about using a subset of mathematics to reason without running into Russell`s 
> Paradox (which is the mathematical equivalent of saying `this statement is 
> false`). It was found that ANY system that referred back to oneself had the 
> potential to have this problem and so all of this circular referencing had to 
> be eliminated. The reason why the book was so thick was because most of the 
> book was devoted to teaching people how to write mathematics without using 
> circular reference. It was dense.
> 
> Godel constructed an equivalent system of calculation to that of PM and 
> showed that anytime the `+` operator was in the system, then it was possible 
> to get the system to talk about itself. Therefore, the phrase `This statement 
> is unprovable using our system` will result in a paradox in a system that was 
> thought the be free of them. Thus, Godel used the logic presented in the 
> framework itself to cause its own downfall.
> 
> This result put mathematics in its place, not as the single source of truth 
> as Russell and Whitehead, the authors of PM had wanted, but as an incredibly 
> tool despite its inconsistencies. It also eliminated the need for future 
> mathematicians to waste their time in order to build a complete system of 
> mathematics - Godel had proved beyond a shadow of a doubt that this was an 
> impossible task.
> 
> I see history repeating itself with the offspring of PM (type theory). Like 
> PM, It is brilliant and to be honest, it is too abstract for me. However, it 
> is my understanding that a lot of the leading research is repeating that of 
> PM but with an emphasis on computation. To avoid Russell`s paradox, types are 
> always hierarchical, never circular. To express circular referencing of types 
> in a none circular way requires a lot of time of a lot of smart people. 
> 
> There is therefore a lot of pomp and ceremony in order to create a `correct` 
> and `complete` system of programming I don't think any of the researchers 
> claim this but it is sure marketed that way. 
> 
> I believe that we have to put type theory in its proper place as a tool for 
> programmers and not as the saviour for programming (that mantle belongs to 
> lisp of course =p ) For example:
>  - one area that is difficult using types is to define multiple hierarchies 
> over objects - like properies of can-fly, can-swim, can-run over birds, 
> mammals and reptiles.
>  - Another area is with partial data. That is, when does a rose not become a 
> ros

Re: Clojure for the Brave and True, an online book for beginners

[Greg]

I think it could benefit from more posts on using Clojure with IDE/Editor ___.

Perhaps outsource some of that with links to existing posts on the topic.

I hesitate to recommend this to anyone because I can't recommend Emacs (even 
though it's my primary terminal editor).

- Greg

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

On Sep 2, 2013, at 11:35 AM, Daniel Higginbotham  wrote:

> Hi all,
> 
> I've been putting together http://www.braveclojure.com/ and would love 
> feedback. I've tried to make it entertaining and super beginner-friendly.
> 
> Thanks!
> Daniel
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: as-> macro enhancement request?

[Greg]

> Your example could be written:
> 
> (-> foo
>bar
>(baz quuz)
>blah)

That misses the point of having a generic threading macro.

> But I suspect you meant something like this:
> 
> (-> foo
>bar
>(as-> <> (baz whiz <> quuz))
>blah)

That's ugly.

>> Would love it if as-> allowed removing unnecessary characters, this way:
>> 
>> (as-> <> foo
>> bar
>> (baz <> quux)
>> blah)
>> 
>> 
>> Anyway, very minor quibble, just putting it out there.

+1

- Greg

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

On Aug 20, 2013, at 10:22 PM, Sean Corfield  wrote:

> Your example could be written:
> 
> (-> foo
>bar
>(baz quuz)
>blah)
> 
> But I suspect you meant something like this:
> 
> (-> foo
>bar
>(as-> <> (baz whiz <> quuz))
>blah)
> 
> In other words, you use as-> with -> for just those cases where you
> need something that isn't in the first or last argument position.
> 
> That's why it's (as-> expr name & forms) with the expression in the
> first argument position.
> 
> Sean
> 
> 
> 
> On Tue, Aug 20, 2013 at 6:52 PM, Ken Restivo  wrote:
>> I like the as-> macro, mostly because it'd theoretically obviate the need to 
>> include the Swiss Arrows library anymore.
>> 
>> There's one reason why I keep going back to Swiss Arrows though: the ability 
>> to include single-arg functions in the chain that do not have the explicit 
>> token.
>> 
>> i.e. in Swiss Arrows, I can do:
>> 
>> (-<> foo
>> bar
>> (baz <> quux)
>> blah)
>> 
>> Note, it's clean and simple, no need for a bunch of noise and <>'s where not 
>> needed, only when calling functions with arity > 1.
>> 
>> But with as->, I have to do:
>> 
>> (as-> <> foo
>> (bar <>)
>> (baz <> quux)
>> (blah <>))
>> 
>> And that just seems unnecessarily noisy to me.
>> 
>> 
>> Would love it if as-> allowed removing unnecessary characters, this way:
>> 
>> (as-> <> foo
>> bar
>> (baz <> quux)
>> blah)
>> 
>> 
>> Anyway, very minor quibble, just putting it out there.
>> 
>> Thanks.
>> 
>> -ken
>> 
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/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, visit https://groups.google.com/groups/opt_out.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] slothcfg - Improved version of awesome but abandoned 'configleaf' project!

[Greg]

> So, just to be clear, you thought you'd just go ahead and fork, rename, and 
> reannounce my project, instead of sending me an email?

My initial impulse was to send you a pull request however, I saw that there 
were already two outstanding pull requests.

Justin had made his pull request over a year ago, and Paul about four months 
ago. They both added several commits on top of them and you didn't give either 
one of them a reply, nor had you updated the repo in over a year.

I needed this to work now, and given your lack of responsiveness to the others, 
I did not want to have to wait potentially over a year to hear back from you 
(if ever). Your project seemed about as abandoned and forgotten as it could be. 
I'm sorry if I've upset you though, that was not my intention. If you'd like to 
collaborate together please let me know, and also know that you are free to 
shoot me emails off-list.

Sincerely,
Greg

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

On Aug 16, 2013, at 7:14 PM, David Santiago  wrote:

> So, just to be clear, you thought you'd just go ahead and fork, rename, and 
> reannounce my project, instead of sending me an email? I'm quite open to 
> collaboration and try to work quickly with people on patches, such as with 
> Julian Eduard's recent work to make Hickory work on Clojurescript. I'm sorry 
> it has two open pull requests, but one of those is an exceedingly low 
> priority doc fix and the other simply escaped my attention span, amongst all 
> the other things I work on.
> 
>   Good luck with the project, 
>  David
> 
> 
> On Fri, Aug 16, 2013 at 2:03 PM, Greg  wrote:
> Hey folks,
> 
> After the configleaf plugin stopped working (most likely because of a change 
> in Leiningen), I decided to take it under my wing as and call it slothcfg so 
> that folks could grab the new changes via Clojars & Leiningen.
> 
> Features
> slothcfg for Leiningen 2 fills in the missing features in Leiningen 2's 
> profile support:
> 
> Makes the project.clj file available to your code at runtime so that you can 
> use it as a config file!
> Build profiles for Leiningen that can be set and remain in effect until unset.
> Built-in templates to create .cljs, .cljx or .cljs config files.
> The new plugin features lots of updates:
> 
> What's new in 1.0.0 (aka 1.0.1):
> 
> Renamed project to slothcfg so that users can pull new features from Clojars.
> Removed all use of :use (it's bad, mmm'k?)
> Removed robert-hooke dependency because it comes with leiningen 2.
> Consolidated the set-profile and unset-profile tasks under a generic slothcfg 
> task to future-proof slothcfg.
> Added :file-ext option to specify config file extension.
> Added :template option to allow the option of providing your own mustache 
> template.
> Added :middleware option to optionally transform the project map.
> Added templates for .cljx and .cljs :file-ext.
> Updated .clj template to use 'defonce' now.
> Templates now store config map in an atom to allow for updates within the 
> project.
> dissoc :checkout-deps-shares from the project map to fix an incompatibility 
> with Leiningen 2.3.0 that caused an "Unreadable form" RuntimeException.
> Included @ninjudd's PR to configleaf to add :keyseq and :var options
> Restructured and updated text in README.md
> Grab it at Github: https://github.com/taoeffect/slothcfg
> 
> Cheers!
> Greg
> 
> --
> 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.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[ANN] slothcfg - Improved version of awesome but abandoned 'configleaf' project!

[Greg]

Hey folks,

After the configleaf plugin stopped working (most likely because of a change in 
Leiningen), I decided to take it under my wing as and call it slothcfg so that 
folks could grab the new changes via Clojars & Leiningen.

Features
slothcfg for Leiningen 2 fills in the missing features in Leiningen 2's profile 
support:

Makes the project.clj file available to your code at runtime so that you can 
use it as a config file!
Build profiles for Leiningen that can be set and remain in effect until unset.
Built-in templates to create .cljs, .cljx or .cljs config files.
The new plugin features lots of updates:

What's new in 1.0.0 (aka 1.0.1):

Renamed project to slothcfg so that users can pull new features from Clojars.
Removed all use of :use (it's bad, mmm'k?)
Removed robert-hooke dependency because it comes with leiningen 2.
Consolidated the set-profile and unset-profile tasks under a generic slothcfg 
task to future-proof slothcfg.
Added :file-ext option to specify config file extension.
Added :template option to allow the option of providing your own mustache 
template.
Added :middleware option to optionally transform the project map.
Added templates for .cljx and .cljs :file-ext.
Updated .clj template to use 'defonce' now.
Templates now store config map in an atom to allow for updates within the 
project.
dissoc :checkout-deps-shares from the project map to fix an incompatibility 
with Leiningen 2.3.0 that caused an "Unreadable form" RuntimeException.
Included @ninjudd's PR to configleaf to add :keyseq and :var options
Restructured and updated text in README.md
Grab it at Github: https://github.com/taoeffect/slothcfg

Cheers!
Greg

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Halp Clojurinoes! Cannot deploy to Clojars! :-(

[Greg]

> My public key:
> 
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.


Errr... that's a typo in my email, not my public key. Not sure how it got 
there. Just copied this from the Clojars textarea:



-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org

mQENBFHwCAYBCADU8xbAOx5OK6I/utcb4FoRFvYn3Y1p02VZ+RrQrngjchj3WKdN
IxJA+5LY/N2MO1B5kznl+diP5VUmrZy4PGQK3WwCfY7Hi3PRPSUj8OtOtPeqXjh2
dXvNfq9pLJQB3ABYjB2aLyHTu5/nzUXlJKHIS5LxAx6J6VwDrachncH0h+eNhK9q
8z5zauwlUIcueUNuMxeVKYvgHlLRnqnBxHTeSKmXdJuFvucs+WWaR+Syjo7Bcduy
kVGyeMehWuX+NAUCYD7cmF2GqwKkJZLVUu/hWrZ9+iM1X39SJ82rYshEmvqzQKhG
lKE2Cc8dT/4sLzHN7J7PP3m+eOmnXBoF3g5PABEBAAG0TVRhbyBFZmZlY3QgKEZv
ciBjb21wYW55IGVtYWlsIGNyZWF0ZWQgYnkgR3JlZyBTbGVwYWspIDxjb250YWN0
QHRhb2VmZmVjdC5jb20+iQE+BBMBAgAoBQJR8AgGAhsvBQkHhh+ABgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRDtGHNC2xR/HIjdCADCwEZ53JIn4s7JXIw7sAGC
J8oCvoZcYhbZE5k5dMj3yROe+EhCTRRo6ZvXxlWtIqJxBNvLsYB7ZpMY/rRtlmXE
oNYWCUxlHtuFb2BlQmuElFRIinTbcE7IKjm7ElSTLcCbGr8Xh0mcpEsLhtR+jE9T
fT6APZZnovp8ZN40nJ9d0x+JZHXnaEhi4bSahHz4AJlZfsyJe4RvVGRggh/+9Elb
K+KIGco5PAWxtpMxNw25jpNcS2MM8LlouNNAoaIDPNCBbbpoyiBlgGGc9RFaQEkw
6IpYn3wU6EB67iExr8JaYbLof0/86VZtgrH+GpkeoeejAbceZWBFnPlGKbDEkJ7q
uQENBFHwCAYBCADACIZjUGDGdvz06f6GWm+1bMv8kcVBNvrCqbudYcZ9u8B1noag
QpcIkQPkq9k1lD9QW4tOr6dS73dL00Ktqz9pcVE2AxDReqJcWwG2zUlJtA1Rvvt9
5qAc+svTfGrooJzwD5UEfp6C6Ezm7Qxwjp/sAOUSOtH7m3/RS6RAVUe1fOM3mpGS
phaEqjfNZZtwVTQYEBJ6YYkMhjrHSAsLM9zbddS/UIXQ56L4SzZAFiVIEYz38U3p
ErllsRrGsioGyCaNOnEKHPofHQqUg9Rwd/ImsKrN/V6Vv2bZsHSS3mwfrCRj1ob3
nJJb4svZKgDimXvPtbZTn7R+0nAZt1fy4o+vABEBAAGJAkQEGAECAA8FAlHwCAYC
Gy4FCQeGH4ABKQkQ7RhzQtsUfxzAXSAEGQECAAYFAlHwCAYACgkQjVTkdAahZuy/
wwgApmhYICMkVDFvzMmXZdu7Zl0fkKO/jHxrPzNBxZB4b7GffPDQFzLJVeWOj3Kr
fpAp/km+wFLrPJm6+9qxGsWdXNtVHN1RKMSYF7yLDr9CR7pTxKBj1pG7+AQ7tLgd
XI39mcsGdw8EkEh2RNXthbcKvBP6nvrewdvO3wjuMtmAAgLL4aienHLRnca4vmx2
78BBYOaam/u0Lt7w8rBxqtgkJFG6Hx5pPp1TW2x3CJRGRJX2eoakEzWYrMb9z0gl
Q0wZx33oM+jClwdTKYNQkJjzt8fe5F20b/adVh3DCGFXoNs/LuIVEm1KQp58f54z
PMVDO7yEFLaY2iY9WHiNmnRGUzRpCACoTdFFksQWCPc+vh7Ma+k4+AZodLEQgZ9o
Qp9tx34fCHUG4SnIo9IkuouiQAaAieR8vNrceScsihYBMwb0TFr23Cf59kjQEp2q
W76jH3raEHN+04029dqIpOywYxWgY92gKW33hxSjnr/Z8MNd4lVr1ES452BoZwle
U9ZBs3xYOh7pZv6aaM0y9sw4vBmpm0t/HdwdH+/O79uE8qiZ49VO6QhQT3Xx6+Vw
V+p2pENTo3HJXRWA+pibeWA47+uSczCeBRGpbBwXLO/L5AaYaK3m+PvVQz4Nnisl
iyKQ4cpVJ9VPQPVYQ0Dyp+QJeZfKRpYWv/6kr3kFjY8UefZw189O
=AGtu
-END PGP PUBLIC KEY BLOCK-

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

On Aug 16, 2013, at 3:49 PM, Greg  wrote:

> I've been trying for at least an hour to deploy a project to Clojars to no 
> avail—Wait...
> 
> OK, apparently it made its way into Clojars despite giving me errors 
> everything single time:
> 
> However, under "Promotion" it says:
> 
> Could not verify signature of 
> /home/clojars/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom. Ensure your 
> public key is in your profile.
> 
> Yes, my public key is in my profile. It's been pasted into my profile as hard 
> as I could paste it into there.
> 
> My ~/.lein/profiles.clj file:
> 
>  {:user {:plugins [[http-kit/lein-template "1.0.0-SNAPSHOT"]
>[lein-ancient "0.4.4"]
>[lein-pprint "1.1.1"]
>[lein-localrepo "0.5.2"]
>[lein-set-version "0.3.0"]]
>  :signing {:gpg-key "cont...@taoeffect.com"}
>  :deploy-repositories [["clojars" {:creds :gpg}]
>["myclojars"
> {:url "https://clojars.org/repo/";
>  :creds :gpg}]]
>  :dependencies [[slamhound "1.3.3"]
> ; see https://github.com/cemerick/pomegranate for 
> adding dependencies at runtime
> [com.cemerick/pomegranate "0.2.0"]]
>  :aliases {"slamhound" ["with-profile" "no-aot" "run" "-m" 
> "slam.hound"]}}
>  :no-aot [:default {:aot ^:replace []}]}
> 
> My decrypted ~/.lein/credentials.clj.gpg:
> 
> {#"clojars"
>  {:username "taoeffect" :password ""}}
> 
> My failed attempt to deploy:
> 
> [prompt] $ lein deploy clojars
> Wrote /Users/gslepak/Programming/Clojure/slothcfg-git/pom.xml
> Created 
> /Users/gslepak/Programming/Clojure/slothcfg-git/target/slothcfg-1.0.0.jar
> 
> You need a passphrase to unlock the secret key for
> user: "Tao Effect (For company email created by Greg Slepak) 
> "
> 2048-bit RSA key, ID 06A166EC, created 2013-07-24 (main key ID DB147F1C)
> 
> 
> You need a passphrase

Halp Clojurinoes! Cannot deploy to Clojars! :-(

[Greg]

I've been trying for at least an hour to deploy a project to Clojars to no 
avail—Wait...

OK, apparently it made its way into Clojars despite giving me errors everything 
single time:

However, under "Promotion" it says:

Could not verify signature of 
/home/clojars/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom. Ensure your 
public key is in your profile.

Yes, my public key is in my profile. It's been pasted into my profile as hard 
as I could paste it into there.

My ~/.lein/profiles.clj file:

 {:user {:plugins [[http-kit/lein-template "1.0.0-SNAPSHOT"]
   [lein-ancient "0.4.4"]
   [lein-pprint "1.1.1"]
   [lein-localrepo "0.5.2"]
   [lein-set-version "0.3.0"]]
 :signing {:gpg-key "cont...@taoeffect.com"}
 :deploy-repositories [["clojars" {:creds :gpg}]
   ["myclojars"
{:url "https://clojars.org/repo/";
 :creds :gpg}]]
 :dependencies [[slamhound "1.3.3"]
; see https://github.com/cemerick/pomegranate for 
adding dependencies at runtime
[com.cemerick/pomegranate "0.2.0"]]
 :aliases {"slamhound" ["with-profile" "no-aot" "run" "-m" 
"slam.hound"]}}
 :no-aot [:default {:aot ^:replace []}]}

My decrypted ~/.lein/credentials.clj.gpg:

{#"clojars"
 {:username "taoeffect" :password ""}}

My failed attempt to deploy:

[prompt] $ lein deploy clojars
Wrote /Users/gslepak/Programming/Clojure/slothcfg-git/pom.xml
Created 
/Users/gslepak/Programming/Clojure/slothcfg-git/target/slothcfg-1.0.0.jar

You need a passphrase to unlock the secret key for
user: "Tao Effect (For company email created by Greg Slepak) 
"
2048-bit RSA key, ID 06A166EC, created 2013-07-24 (main key ID DB147F1C)


You need a passphrase to unlock the secret key for
user: "Tao Effect (For company email created by Greg Slepak) 
"
2048-bit RSA key, ID 06A166EC, created 2013-07-24 (main key ID DB147F1C)

Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom (3k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:pom:1.0.0 from/to clojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom, 
ReasonPhrase: Forbidden.
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar (15k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:jar:1.0.0 from/to clojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar, 
ReasonPhrase: Forbidden.
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar.asc (1k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:jar.asc:1.0.0 from/to clojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar.asc, 
ReasonPhrase: Forbidden.
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom.asc (1k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:pom.asc:1.0.0 from/to clojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom.asc, 
ReasonPhrase: Forbidden.
Failed to deploy artifacts: Could not transfer artifact 
slothcfg:slothcfg:pom:1.0.0 from/to clojars (https://clojars.org/repo/): Access 
denied to: https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom, 
ReasonPhrase: Forbidden.

My second failed attempt to deploy:

[prompt] $ lein deploy myclojars slothcfg 1.0.0 target/slothcfg-1.0.0.jar 
target/slothcfg-1.0.0.jar.asc pom.xml pom.xml.asc
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom (3k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:pom:1.0.0 from/to myclojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.pom, 
ReasonPhrase: Forbidden.
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.asc (1k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:asc:1.0.0 from/to myclojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.asc, 
ReasonPhrase: Forbidden.
Sending slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar (15k)
to https://clojars.org/repo/
Could not transfer artifact slothcfg:slothcfg:jar:1.0.0 from/to myclojars 
(https://clojars.org/repo/): Access denied to: 
https://clojars.org/repo/slothcfg/slothcfg/1.0.0/slothcfg-1.0.0.jar, 
ReasonPhrase: Forbidden.
org.sonatype.aether.deployment.DeploymentException: Failed to deploy artifacts: 
Could not transfer artifact slothcfg:slothcfg:pom:1.0.0 from/to myc

Re: [ANN] Leiningen 2.3.0 released

[Greg]

Hey Phil, thanks for the update!

> As usual, you can get the latest version by running `lein upgrade`.

I used Homebrew to upgrade. Do you happen to know what the relationship is 
between your `lein upgrade` command and the `brew upgrade leiningen` command?

For example, if lein was installed view Homebrew, should it also be upgraded 
via Homebrew, or can it be upgraded later via the lein upgrade command? Or 
could that cause problems?

For safety's sake, I didn't test what would happen myself and just used 
Homebrew to update it.

- Greg

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

On Aug 8, 2013, at 11:28 PM, Phil Hagelberg  wrote:

> 
> Hello everyone.
> 
> I'm happy to announce the release of Leiningen version 2.3.0. This
> version contains mostly minor fixes, but some highlights include faster
> test runs when using selectors (by skipping fixtures), better support
> for detecting ambiguous version resolutions via :pedantic, and fixes to
> better isolate different profiles in different :target-paths.
> 
> * Add `:eval-in :pprint` for debugging. (Phil Hagelberg)
> * Support cleaning extra dirs with `:clean-targets`. (Yoshinori Kohyama)
> * Test-selectors skip fixtures too, not just running tests. (Gary Fredericks)
> * Place licenses and readmes into jars. (Phil Hagelberg)
> * Include LICENSE as separate file in templates. (Wolodja Wentland)
> * Allow aborting on ambiguous version resolution with `:pedantic`. (Nelson 
> Morris, Phil Hagelberg)
> * Scope `:compile-path` and `:native-path` under profile-specific target dir. 
> (Phil Hagelberg)
> * Fix bug where uberjar filename would include provided profile. (Phil 
> Hagelberg)
> * Deprecate explicit `self-install` command. (Phil Hagelberg)
> * Fix bugs around long lines in jar manifests. (Leon Barrett)
> * Support nested checkout dependencies. (Phil Hagelberg)
> * Fix bugs around `:filespecs`. (Jean Niklas L'orange)
> 
> As usual, you can get the latest version by running `lein upgrade`.
> 
> Thanks to all the contributors who helped make this happen.
> 
> happy hacking,
> Phil



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> How does gen-class etc. fit into this new (ns) world?

I'm not sure. I've stepped away from this thread (and the mailing list in 
general) for a bit to focus on the mounting amount of work I have to finish 
before the deadline hits, so I haven't had much more time to think about this, 
and I'm also not very familiar with :gen-class.

Looking at the example in The Joy of Clojure, my first impression is that 
:gen-class looks like one hell of an ugly beast by itself:

(ns joy.gui.DynaFrame
  (:gen-class
:name joy.gui.DynaFrame
:extends javax.swing.JFrame
:implements [clojure.lang.IMeta]
:prefix df-
:state state
:init init
:constructors {[String] [String]}
:methods [[display [java.awt.Container] void]
  ^{:static true} [version [] String]])
  (:import ... ))

Looking at that, I think most of it can be kept as-is, except perhaps for the 
sake of supporting both versions of ns it might be worth turning the outer 
parenthesis into brackets. Also, what is the purpose of the :name keyword? Are 
there legitimate situations where you'd want to have a name other than the 
namespace that can't be called poor design? Other than that, I don't personally 
have any ideas on how that could be simplified.

I hope to respond to the other emails in this thread when I get the time to, 
especially Timothy's. Hopefully that'll happen once I finish one project in 
about a week or so.

Cheers,
Greg

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

On Aug 9, 2013, at 6:23 PM, Mark Derricutt  wrote:

> How does gen-class etc. fit into this new (ns) world?
> 
> 
> On 6/08/2013, at 4:28 AM, Greg  wrote:
> 
>> I haven't put enough thought into this as I could, but this seems good 
>> enough already to kick the ball rolling.
>> 
>> If the above syntax can't be made to support the old school syntax as well, 
>> another thought would be to create a new name for the declaration, calling 
>> it "include" or something like that instead of "ns".
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> If this syntax were unified into something like you suggest we have a problem:
> 
> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?

Look what happens after we also do this:

foo=> (defn IBar [] "a")
#'foo/IBar
foo=> (ns user)
nil
user=> (class foo.IBar)
java.lang.Class
user=> (class foo/IBar)
foo$IBar

Now foo/IBar refers to the function, so my understanding is that interfaces are 
bound to vars just like functions.

So, to answer your question:

> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?


IBar is a class, it's the same as an import statement.

If you want the var, do either:

(ns user [foo])
foo/IBar

Or, if you want to refer the protocol so that you don't have to qualify it as 
above, simply do this:

(ns user [foo (IBar)])

It's the same thing as writing this at a REPL:

(require '[foo :refer (IBar)])

- Greg

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

On Aug 6, 2013, at 1:09 PM, Timothy Baldridge  wrote:

> Sure, put this into a repl:
> 
> (ns foo)
> 
> (defprotocol IBar
>   (do-stuff [this]))
> 
> (ns user
>   (require [foo])
>   (import [foo IBar]))
> 
> (class foo/IBar)
> (class foo.IBar)
> 
> 
> If this syntax were unified into something like you suggest we have a problem:
> 
> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?
> 
> Timothy
> 
> 
> On Tue, Aug 6, 2013 at 10:56 AM, Greg  wrote:
> >> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> >> Assume I have a namespace called foo that defines a protocol (and hence an 
> >> interface) called bar. I then also have a namespace called foo.bar. How do 
> >> I tell the new syntax to import each? If I simply say "go get foo.bar" 
> >> what are you going to load, the .clj file, or the java interface?
> 
> It would also help to have an example of how it's currently done.
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 6, 2013, at 12:41 PM, Greg  wrote:
> 
> >> It's exactly the same as a normal require. Ns allows vectors/seqs 
> >> symbols/keywords to be used interchangeably. Some people use (:require) 
> >> others use (require), ns just uses ns/namespace to get the data on the 
> >> first of each item after the symbol.
> >
> > Wow that's confusing!
> >
> > I just view that as yet another reason to change the syntax.
> >
> > To answer your question though, I'd do both syntax's a favor and interpret 
> > "[require [clojure.string :as c]]" using the new syntax. It would save a 
> > lot of newbies many headaches. Think of the newbies.
> >
> >> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> >> Assume I have a namespace called foo that defines a protocol (and hence an 
> >> interface) called bar. I then also have a namespace called foo.bar. How do 
> >> I tell the new syntax to import each? If I simply say "go get foo.bar" 
> >> what are you going to load, the .clj file, or the java interface?
> >
> > I think part of the problem here is that I'm not very well educated on this 
> > topic yet. Perhaps you can help:
> >
> > - If you defined a protocol Foo in user, is it referenced as user.Foo from 
> > another ns, or user/Foo ? Or both??
> >
> > - Can you have a function Foo at the same time as a protocol Foo in the 
> > same namespace?
> >
> > - What about records? Can you have a record Foo and a protocol Foo?
> >
> > - Can you have a class Foo and an protocol Foo?
> >
> > Clojure and I are already confused here:
> >
> > baz=> (defprotocol g (dostuff [this]))
> > g
> > baz=> g
> > {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists 
> > ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
> > :method-builders {#'baz/dostuff # > baz$eval300$fn__301@7c2aa00c>}}
> > baz=> (defn g [] "a")
> > #'baz/g
> > baz=> g
> > #
> >
> > And I'm not sure how to get the protocol back...
> >
> > - Greg
> >
> > --
> > Please do not email me anything that you are not comfortable also sharing 
> > with the NSA.
> >
> > On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:
> >
> >>>>> (ns foo
> >>>>> [require [clojure.string :as c]])
> >>
> >>>> I've never seen that before

Re: [Proposal] Simplified 'ns' declaration

[Greg]

>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?

It would also help to have an example of how it's currently done.

- Greg

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

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

>> It's exactly the same as a normal require. Ns allows vectors/seqs 
>> symbols/keywords to be used interchangeably. Some people use (:require) 
>> others use (require), ns just uses ns/namespace to get the data on the first 
>> of each item after the symbol. 
> 
> Wow that's confusing!
> 
> I just view that as yet another reason to change the syntax.
> 
> To answer your question though, I'd do both syntax's a favor and interpret 
> "[require [clojure.string :as c]]" using the new syntax. It would save a lot 
> of newbies many headaches. Think of the newbies.
> 
>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?
> 
> I think part of the problem here is that I'm not very well educated on this 
> topic yet. Perhaps you can help:
> 
> - If you defined a protocol Foo in user, is it referenced as user.Foo from 
> another ns, or user/Foo ? Or both??
> 
> - Can you have a function Foo at the same time as a protocol Foo in the same 
> namespace?
> 
> - What about records? Can you have a record Foo and a protocol Foo?
> 
> - Can you have a class Foo and an protocol Foo?
> 
> Clojure and I are already confused here:
> 
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists 
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #
> 
> And I'm not sure how to get the protocol back...
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:
> 
>>>>> (ns foo 
>>>>> [require [clojure.string :as c]])
>> 
>>>> I've never seen that before. What does it do?
>> 
>> It's exactly the same as a normal require. Ns allows vectors/seqs 
>> symbols/keywords to be used interchangeably. Some people use (:require) 
>> others use (require), ns just uses ns/namespace to get the data on the first 
>> of each item after the symbol. 
>> 
>> 
>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?
>> 
>> Timothy
>> 
>> 
>> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord  
>> wrote:
>> Greg  writes:
>> 
>>>> I am dubious about distinguishing between lists and vectors. Currently,
>>>> as far as I can tell, the ns is agnostic, and only cares about them
>>>> being sequential. This is probably one of the sources of confusion for
>>>> beginners -- they see both and don't see why
>>> 
>>> The reason for distinguishing between lists and vectors is as you say, it's
>>> confusing for beginnings. Also, it allows the syntax to have greater
>>> functionality/power.
>> 
>> Really dubious about this. Having to keep in my head when I need to use
>> [] and when I need to use () is a significant problem when starting. It
>> was my realisation that for the ns declaration you don't that made
>> things easier.
>> 
>>>> Also, I am confused as to how you distinguish between
>>>> [core [matrix math bs]] being equivalent to :use while
>>>&g

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> It's exactly the same as a normal require. Ns allows vectors/seqs 
> symbols/keywords to be used interchangeably. Some people use (:require) 
> others use (require), ns just uses ns/namespace to get the data on the first 
> of each item after the symbol. 

Wow that's confusing!

I just view that as yet another reason to change the syntax.

To answer your question though, I'd do both syntax's a favor and interpret 
"[require [clojure.string :as c]]" using the new syntax. It would save a lot of 
newbies many headaches. Think of the newbies.

> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> Assume I have a namespace called foo that defines a protocol (and hence an 
> interface) called bar. I then also have a namespace called foo.bar. How do I 
> tell the new syntax to import each? If I simply say "go get foo.bar" what are 
> you going to load, the .clj file, or the java interface?

I think part of the problem here is that I'm not very well educated on this 
topic yet. Perhaps you can help:

- If you defined a protocol Foo in user, is it referenced as user.Foo from 
another ns, or user/Foo ? Or both??

- Can you have a function Foo at the same time as a protocol Foo in the same 
namespace?

- What about records? Can you have a record Foo and a protocol Foo?

- Can you have a class Foo and an protocol Foo?

Clojure and I are already confused here:

baz=> (defprotocol g (dostuff [this]))
g
baz=> g
{:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists ([this]), 
:name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
:method-builders {#'baz/dostuff #}}
baz=> (defn g [] "a")
#'baz/g
baz=> g
#

And I'm not sure how to get the protocol back...

- Greg

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

On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:

>> >> (ns foo 
>> >>  [require [clojure.string :as c]])
> 
> >> I've never seen that before. What does it do?
> 
> It's exactly the same as a normal require. Ns allows vectors/seqs 
> symbols/keywords to be used interchangeably. Some people use (:require) 
> others use (require), ns just uses ns/namespace to get the data on the first 
> of each item after the symbol. 
> 
> 
> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> Assume I have a namespace called foo that defines a protocol (and hence an 
> interface) called bar. I then also have a namespace called foo.bar. How do I 
> tell the new syntax to import each? If I simply say "go get foo.bar" what are 
> you going to load, the .clj file, or the java interface?
> 
> Timothy
> 
> 
> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord  
> wrote:
> Greg  writes:
> 
> >> I am dubious about distinguishing between lists and vectors. Currently,
> >> as far as I can tell, the ns is agnostic, and only cares about them
> >> being sequential. This is probably one of the sources of confusion for
> >> beginners -- they see both and don't see why
> >
> > The reason for distinguishing between lists and vectors is as you say, it's
> > confusing for beginnings. Also, it allows the syntax to have greater
> > functionality/power.
> 
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
> 
> >> Also, I am confused as to how you distinguish between
> >> [core [matrix math bs]] being equivalent to :use while
> >> Is [one reload middleware] also :use? Or :require?
> >
> > Nested vectors = :use.
> >
> > Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix 
> > math
> > bs))
> >
> > It's a bit confusing in the current syntax (if I have it correct), because
> > from it, it's not clear why "core" isn't "used".
> >
> > [one reload middleware]
> >
> > Is equivalent to:
> >
> > (:require [one.reload :as reload]
> >   [one.middleware :as middleware])
> 
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise.
> 
> I do like the idea of enforcing nesting though in
> 
> [core [matrix math bs]]
> 
> Phil
> 
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise. 

Sorry, I'm not sure what you're saying at the end there.

If you want to rename a namespace you can do it explicitly with :as, like I 
gave in the example with "enlive-html":

[net.cgrand enlive-html :as html]

- Greg

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

On Aug 6, 2013, at 11:39 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> Greg  writes:
> 
>>> I am dubious about distinguishing between lists and vectors. Currently,
>>> as far as I can tell, the ns is agnostic, and only cares about them
>>> being sequential. This is probably one of the sources of confusion for
>>> beginners -- they see both and don't see why
>> 
>> The reason for distinguishing between lists and vectors is as you say, it's
>> confusing for beginnings. Also, it allows the syntax to have greater
>> functionality/power.
> 
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
> 
>>> Also, I am confused as to how you distinguish between 
>>> [core [matrix math bs]] being equivalent to :use while
>>> Is [one reload middleware] also :use? Or :require?
>> 
>> Nested vectors = :use.
>> 
>> Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix math
>> bs))
>> 
>> It's a bit confusing in the current syntax (if I have it correct), because
>> from it, it's not clear why "core" isn't "used".
>> 
>> [one reload middleware]
>> 
>> Is equivalent to:
>> 
>> (:require [one.reload :as reload]
>>  [one.middleware :as middleware])
> 
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise. 
> 
> I do like the idea of enforcing nesting though in 
> 
> [core [matrix math bs]]
> 
> Phil
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

Thanks Timothy for your very thoughtful reply!

You bring up some very valid points.

> a) How do you plan on having this backwards-compatible with existing code? 
> You will have to support both the old and new versions on the same Clojure 
> compiler. Notice that this is completely valid in the current compiler:
> 
> (ns foo 
>   [require [clojure.string :as c]])

I've never seen that before. What does it do?

Someone else mentioned (I'm sorry, I don't remember who, or whether it was even 
in this thread), that you could simply distinguish between lists and vectors, 
and if that's not good enough, then distinguishing between lists/vectors that 
start with a keyword, and those that don't.

> Once again, please notice that your "old school" example could also have been 
> written in a much more concise manner: 


It could have, I agree, but its syntax doesn't force you to. This one does. 
It's always "concise", as you say.

The example you gave is also still too ambiguous for newcomers to understand, 
and contains a lot of unnecessary elements.

Ambiguity
It's not clear from your example why parenthesis are used sometimes and vectors 
are used in other cases.

Unnecessary elements

(:require [one.reload :as reload]
  [one.middleware :as middleware])

Versus:

[one reload middleware]

> With the current design we can clearly distinguish between loading a java 
> class, and loading a clojure namespace. 

I'm sorry, I tried running your example in a REPL and got:

CompilerException java.lang.RuntimeException: Unable to resolve symbol: bar in 
this context, compiling:(NO_SOURCE_PATH:0:0)

I also tried using definterface instead of defprotocol, but got the same error.

I assume there's some minor error in the example you gave, but let me try and 
and address your question anyway: you could either introduce a new keyword 
(like :as-class), or use :as to rename them to avoid conflicts. After all, it's 
already possible to have conflicts between just two namespaces if you try to 
alias them to the same symbol/var.

- Greg

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

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

> For this to even have a chance at making it into Clojure you need to consider 
> all the edge cases. So I have two questions
> 
> a) How do you plan on having this backwards-compatible with existing code? 
> You will have to support both the old and new versions on the same Clojure 
> compiler. Notice that this is completely valid in the current compiler:
> 
> (ns foo 
>   [require [clojure.string :as c]])
> 
> b) You will also need a very concise, clear definition on why the new 
> approach is better. Once again, please notice that your "old school" example 
> could also have been written in a much more concise manner: 
> 
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html]
> [ring.adapter.jetty :refer (run-jetty)]
> [ring.middleware.file :refer (wrap-file)]
> [ring.middleware.file-info :refer (wrap-file-info)]
> [ring.middleware.stacktrace :refer (wrap-stacktrace)]
> [ring.util.response :refer (file-response)])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
> 
> As a support to the current method let me point out the following. We have 3 
> constructs in this case, each only does one thing:
> 
> a) refer-clojure - allows you to :exclude certain symbols from being imported 
> by default
> b) require loads clojure namespaces
> c) import loads Java classes
> 
> Your example also has the following problem:
> 
> bar=> (ns foo.bar)
> nil
> foo.bar=>
> 
> foo.bar=> (ns foo)
> nil
> foo=> (defprotocol bar (dostuff [this]))
> bar
> foo=> (ns user)
> nil
> user=> (ns user (:require [foo.bar]) (:import [foo.bar]))
> nil
> user=> bar
> foo.bar
> user=> (class bar)
> java.lang.Class
> 
> With the current design we can clearly distinguish between loading a java 
> class, and loading a clojure namespace. In the example above, we need this if 
> we want to clearly load both the java interface foo.bar as well as the 
> clojure namespace foo.bar.
> 
> How would the new syntax express such a ns statement, and how would the 
> semantics be clearer in this approach?
> 
> Timothy Baldridge
> 
> 
> On Tue, Aug 6, 2013 at 8:51 AM, Greg  wrote:
> Folks, I feel this thread has gotten derailed by the discussion of implicit 
> imports.
> 
> This thread is not

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> I am dubious about distinguishing between lists and vectors. Currently,
> as far as I can tell, the ns is agnostic, and only cares about them
> being sequential. This is probably one of the sources of confusion for
> beginners -- they see both and don't see why

The reason for distinguishing between lists and vectors is as you say, it's 
confusing for beginnings. Also, it allows the syntax to have greater 
functionality/power.

> Also, I am confused as to how you distinguish between 
> [core [matrix math bs]] being equivalent to :use while
> Is [one reload middleware] also :use? Or :require?

Nested vectors = :use.

Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix math 
bs))

It's a bit confusing in the current syntax (if I have it correct), because from 
it, it's not clear why "core" isn't "used".

[one reload middleware]

Is equivalent to:

(:require [one.reload :as reload]
  [one.middleware :as middleware])

- Greg

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

On Aug 6, 2013, at 11:07 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> Greg  writes:
>> New School:
>> 
>> (ns two.namespace
>>  [clojure [core :except (ancestors printf)]]
>>  [core [matrix math bs]] ; same as (:use (core matrix math bs))
>>  [[some-ns]] ; same as (:use some-ns)
>>  [ring.adapter.jetty (run-jetty :as jetty)]
>>  [ring.middleware.file ("warp-*")] ; refers all functions beginning with 
>> "wrap-"
>>; regex not supported because too 
>> confusing
>>  [ring.middleware.file-info (wrap-file-info)]
>>  [ring.middleware.stacktrace (wrap-stacktrace)]
>>  [ring.util.response (file-response)]
>>  [one reload middleware]
>>  [net.cgrand enlive-html :as html]
>>  [org.apache.maven.artifact.resolver ArtifactResolver] 
>>  [java.io File InputStream])
>> 
>> Four key rules to the new syntax:
>> 
>> 1) vectors can only contain namespaces and the keywords :as and :except
>> 2) vectors within vectors will refer everything in the the namespaces 
>> specified in them
>> 3) lists can only contain functions and the keyword :as to rename functions.
> 
> 
> I am dubious about distinguishing between lists and vectors. Currently,
> as far as I can tell, the ns is agnostic, and only cares about them
> being sequential. This is probably one of the sources of confusion for
> beginners -- they see both and don't see why, when in fact on the outer
> brackets are necessarily round. 
> 
> Also, I am confused as to how you distinguish between 
> 
> [core [matrix math bs]] being equivalent to :use while
> 
> Is [one reload middleware] also :use? Or :require?
> 
> If there was one thing I would deprecate it's that the first element of
> the vector is special.
> 
> I find the fact that these two:
> 
> (ns bob [:require [tawny owl reasoner]])
> (ns john [:require [tawny.owl reasoner]])
> 
> are totally different, very confusing. Throw in this
> 
> (ns john [:require [tawny.owl]])
> 
> In the first case "tawny.owl" is a prefix, and in the second it means
> "require tawny.owl".
> 
> Phil
> 
> 
> 
> 
> 
>> 4) namespaces are referred by placing a space after the namespace prefix
>> 
>> Also, an added feature/rule is that globbing-based strings can be used to 
>> save on typing (as shown in the example above).
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
>> On Aug 6, 2013, at 7:55 AM, Curtis Summers  wrote:
>> 
>>> I agree that wildcards make it "easy" (in the nearness sense), but from a 
>>> long-term maintainability standpoint, I'd prefer to have explicit imports 
>>> as is.  When I'm reading your code a year from now and need to look-up the 
>>> docs on a class, wildcards make me (and anyone else in the future) have to 
>>> do that look-up every time.  It's almost the same argument as to why (:use) 
>>> is a bad idea--you're dumping a bunch of symbols into your namespace.  So, 
>>> you're trading some upfront ease for some long-term simplicity.
>>> 
>>> Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
>>> the parallel in the Clojure world with so much "getting started/example" 
>>> code showing :use instead of :require).
>>> 
>>> -Curtis
>>> 
>>> 
>>> The argument for wildcards is very simple.  Go to just

Re: Can we please deprecate the :use directive ?

[Greg]

> Struggling a bit. Moving the keywords to the end of the vector rather
> than the beginning? This reduces complexity?

I changed the syntax a bit since posting that, please have a look at the 
"[Proposal] Simplified 'ns' declaration" thread.

- Greg

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

On Aug 6, 2013, at 7:22 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> 
> 
> Struggling a bit. Moving the keywords to the end of the vector rather
> than the beginning? This reduces complexity?
> 
> Phil
> 
> 
> Greg  writes:
> 
>> Looking at it again, we don't even need an explicit :require anymore:
>> 
>> (ns one.fresh-server
>>  "optional doc string goes here"
>>  [clojure.core :refer-except [ancestors printf]]
>>  [core.matrix :refer :all]
>>  [ring.adapter.jetty :refer [run-jetty]]
>>  [ring.middleware.file :refer [wrap-file]]
>>  [ring.middleware.file-info :refer [wrap-file-info]]
>>  [ring.middleware.stacktrace :refer [wrap-stacktrace]]
>>  [ring.util.response :refer [file-response]]
>>  [one.reload :as-ns]
>>  [one.middleware :as-ns]
>>  [net.cgrand.enlive-html :as html]
>>  [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
>>  [java.io.File :as-class])
>> 
>> - Greg
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

Folks, I feel this thread has gotten derailed by the discussion of implicit 
imports.

This thread is not about that. It's not about asterisks, or :use, it's about a 
simplified syntax for the 'ns' form.

PLEASE use the "Re: Can we please deprecate the :use directive ?" thread to 
discuss whether implicit imports are a good idea or not. All of comments here 
about implicitly interning symbols from a namespace are just as relevant to 
this proposed syntax as they are to the currently existing one.

Once again, the (latest version) of the syntax being proposed is:

Old School:

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

New School:

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

Four key rules to the new syntax:

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

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

- Greg

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

On Aug 6, 2013, at 7:55 AM, Curtis Summers  wrote:

> I agree that wildcards make it "easy" (in the nearness sense), but from a 
> long-term maintainability standpoint, I'd prefer to have explicit imports as 
> is.  When I'm reading your code a year from now and need to look-up the docs 
> on a class, wildcards make me (and anyone else in the future) have to do that 
> look-up every time.  It's almost the same argument as to why (:use) is a bad 
> idea--you're dumping a bunch of symbols into your namespace.  So, you're 
> trading some upfront ease for some long-term simplicity.
> 
> Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
> the parallel in the Clojure world with so much "getting started/example" code 
> showing :use instead of :require).
> 
> -Curtis
> 
> 
> The argument for wildcards is very simple.  Go to just about any Java 
> tutorial, for example:
> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
> 
> The sample code starts off with a dozen wildcard imports.  If I want to try 
> to use these techniques in Clojure, I have absolutely no idea which specific 
> classes to require.  This creates a tremendous obstacle to consuming Java 
> libraries.  This has affected me personally on several occasions, preventing 
> me from successfully figuring out how to use some Java library from Clojure.
> 
> Maybe it's not ideal if Clojure has to walk the classpath, but the 
> alternative is that I have to manually walk the classpath and jars myself 
> with no idea what I'm looking for.  Surely it's better for this to be handled 
> through an automated process.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

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

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


There are just four key rules to understand:

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

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

- Greg

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

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

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

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

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

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

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

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

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

Then it would be this:

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

Instead of:

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

- Greg

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

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

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

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


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

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

Look at the beauty of that! :-D

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

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

- Greg

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

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

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

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

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

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

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

New School:

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

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

Notice that this:

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

Has now changed to:

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

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

[:refer-all [core]]

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

[:refer-all core]

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

- Greg

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

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

> 
> On Aug 5, 2013, at 12:41 PM, Greg wrote:
> 
>>> Can you build in a way to get :require :refer :all to work on a bunch of 
>>> sub-namespaces together on one line, as one currently can with :use, 
>>> without listing each namespace completely on a separate line with a 
>>> separate :refer :all?
>> 
>> Certainly. I'm not saying this is how the exact syntax would go, but the 
>> general idea is to rely on the keywords to specify what (and how) you want 
>> to import stuff:
>> 
>> Instead of:
>> 
>> (ns one.fresh-server
>>  (:use (core matrix math bs))
>> 
>> You could do something like:
>> 
>> (ns one.fresh-server
>>  [core :refer-all [matrix math bs]])
> 
> I like it.
> 
> I can't personally assess the costs and benefits of the overall proposal, but 
> this would address my concern nicely.
> 
> -Lee
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Proposal] Simplified 'ns' declaration

[Greg]

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

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

Instead of:

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

You could do something like:

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

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

Summary:

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

Cheers!
- Greg

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

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

> 
> On Aug 5, 2013, at 12:28 PM, Greg wrote:
> 
>> Branching off of the "Can we please deprecate the :use directive ?" thread, 
>> I was wondering what the Clojure community thinks of radically simplifying 
>> the "ns" declaration while keeping all of its power.
> 
> Can you build in a way to get :require :refer :all to work on a bunch of 
> sub-namespaces together on one line, as one currently can with :use, without 
> listing each namespace completely on a separate line with a separate :refer 
> :all?
> 
> -Lee
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Proposal] Simplified 'ns' declaration

[Greg]

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

Old School:

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

New School:

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

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

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

Thoughts?

- Greg

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can we please deprecate the :use directive ?

[Greg]

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

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

- Greg

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

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

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

Re: Can we please deprecate the :use directive ?

[Greg]

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

Also, this is a mistake:

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

Should read something like:

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

- Greg

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

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

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

Re: Can we please deprecate the :use directive ?

[Greg]

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

- :refer-clojure
- :use
- :import

See below...

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


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

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

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

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

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

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


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

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

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

This complexity isn't necessary.

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

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

Into this:

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

Ta da!

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

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

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

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

Re: Can we please deprecate the :use directive ?

[Greg]

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

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

-Greg

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

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

>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
> 
> Agreed. It's nice that :require :refer :all is available for such instances, 
> isn't it?
> 
> -Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 8:22 AM, Mikera  wrote:
> 
>> On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:
>> The only time I've seen :as lead to ugly code was when it was in a DSL that 
>> would probably have been nicer to use if it was a data-based DSL like Hiccup 
>> rather than code-based.
>> 
>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
>> e.g.
>> 
>> (mat/dot (ops/+ [1 2 3] 1) (ops/- [1 2 3] 1))
>> 
>> vs:
>> 
>> (dot (+ [1 2 3] 1) (- [1 2 3] 1))
>> 
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can we please deprecate the :use directive ?

[Greg]

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

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

-Greg

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

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

> On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:
> The only time I've seen :as lead to ugly code was when it was in a DSL that 
> would probably have been nicer to use if it was a data-based DSL like Hiccup 
> rather than code-based.
> 
> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, 
> e.g.
> 
> (mat/dot (ops/+ [1 2 3] 1) (ops/- [1 2 3] 1))
> 
> vs:
> 
> (dot (+ [1 2 3] 1) (- [1 2 3] 1))
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN Langohr 1.0 (final) is released

[Greg]

Thanks for the explanation!

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

On Jul 29, 2013, at 4:25 PM, Michael Klishin  
wrote:

> 2013/7/29 Greg 
> I'm not familiar enough with either project to understand.
> 
> Langohr is a RabbitMQ client that exposes every feature RabbitMQ has in the 
> API.
> 
> clamq is an attempt to provide a generic messaging library with different 
> transports,
> thus hiding all project-specific features. That's the opposite of what 
> Langohr tries to be.
> -- 
> 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.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN Langohr 1.0 (final) is released

[Greg]

> Langohr README answers your question pretty well.

I'm not familiar enough with either project to understand.

- Greg

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

On Jul 29, 2013, at 3:04 PM, Michael Klishin  
wrote:

> 2013/7/29 Greg 
> Is there a reason you decided to write your own instead of contributing to 
> that project?
> 
> Langohr README answers your question pretty well.
> -- 
> 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.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] cljzmq-0.1.1 - A Clojure binding for ØMQ

[Greg]

Awesome! Thanks! It's nice to know this exists, might have a use for it in the 
future.

Cheers,
Greg

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

On Jul 29, 2013, at 9:00 AM, Trevor Bernard  wrote:

> Hello,
> 
> I'd like to announce the immediate availability of cljzmq-0.1.1 on maven 
> central.
> 
> https://github.com/zeromq/cljzmq
> 
> For sample usage, I've started porting the zguide examples here:
> 
> https://github.com/trevorbernard/cljzmq-examples
> 
> Pull requests welcome!
> 
> Warmest regards,
> 
> Trev
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN Langohr 1.0 (final) is released

[Greg]

Neat! Bookmarked. :-)

What about clamq?

https://github.com/sbtourist/clamq

Is there a reason you decided to write your own instead of contributing to that 
project?

Cheers,
Greg

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

On Jul 29, 2013, at 2:35 AM, Michael Klishin  
wrote:

> Langohr [1] is a small, easy to use Clojure client for RabbitMQ.
> 
> 1.0.1 is a long overdue 1.0 release of the library that has been 2 years
> in the making and is one of the most popular ClojureWerkz projects.
> 
> Release notes and some notes about future plans:
> http://blog.clojurewerkz.org/blog/2013/07/29/langohr-1-dot-0-1-is-released/
> 
> 1. http://clojurerabbitmq.info
> -- 
> 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.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Interest in a commercial IDE for Clojure?

[Greg]

Korny,

I think there were multiple posts from me on that day.

This is the one: 
https://groups.google.com/d/msg/clojure/fWOZ9AJzBtU/djhcj4nYVxgJ

Cheers!
Greg

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

On Jul 28, 2013, at 1:28 AM, Korny Sietsma  wrote:

> >* jump-to-symbol-definition
> > - see my post on ST2 in the "is intellij idea a >good idea" thread 
> > dated July 25th.
> 
> I checked that post and couldn't see anything about jump to symbol - I'm 
> mobile though so may have missed something. Can ST2 or 3 do this?
> 
> - Korny 
> On 28 Jul 2013 04:45, "Greg"  wrote:
> Steven:
> 
> ST2 has the following features that you wanted:
> 
> * paredit or better
>   - https://github.com/odyssomay/paredit
> * keyboard shortcuts that dont kill my wrists/pinkies/fingers
>   - you can make whatever shortcuts you want
> * jump-to-symbol-definition
>   - see my post on ST2 in the "is intellij idea a good idea" thread dated 
> July 25th.
> * jump-to-file
>   - the built-in "goto anything" works for that, and there are 
> file-specific plugins too
> * tabs (a la macvim)
>   - not sure what you mean, but there a plugin called "Lispindent" that 
> works great
> * splits (a la emacs)
>   - not sure what you mean, but there's a "Split Into Lines" command
> * magit or better (might be willing to ignore this omission though)
>   - Use these 3 plugins together: GitGutter, Side Bar Git, and SublimeGit
> * not-super-bloated UI
>   - ST fits this definition perfectly
> * themeable (dont care if it has a good theme, i can make one if need be, i 
> just need it to be themeable)
>   - ST is themeable (see my post in the other thread on July 25th)
> * something like nrepl.el
>   - ST has SublimeREPL, which has a fork that works with nREPL. Link in 
> the other thread.
> 
> So looks like you're pretty much covered by ST already. :-)
> 
> Cheers,
> Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Jul 27, 2013, at 11:57 AM, Steven Degutis  wrote:
> 
>> I would be willing to pay /really/ good money for an editor that has a few 
>> features:
>> 
>> * paredit or better
>> * proper syntax highlighting of clojure (emacs rocks at this, ST2 sucks at 
>> it)
>> * ST2-quality fuzzy matching at every completionable prompt (emacs's 
>> ido-mode is alright but ST2's is way better)
>> * keyboard shortcuts that dont kill my wrists/pinkies/fingers
>> * jump-to-symbol-definition
>> * jump-to-file
>> * tabs (a la macvim)
>> * splits (a la emacs)
>> * magit or better (might be willing to ignore this omission though)
>> * not-super-bloated UI
>> * themeable (dont care if it has a good theme, i can make one if need be, i 
>> just need it to be themeable)
>> * something like nrepl.el
>> 
>> (where ST2 means Sublime Text 2)
>> 
>> That's *all* I care about, nothing else matters to me. But no editor can get 
>> *all* these things right.
>> 
>> -Steven
>> 
>> 
>> On Sat, Jul 27, 2013 at 6:54 AM, Colin Fleming  
>> wrote:
>> Hi all,
>> 
>> I was planning to wait a little longer before going public, but since it's 
>> pretty relevant to the other IntelliJ thread going on at the moment I 
>> thought I'd jump in. For the last couple of months of happy unemployment 
>> I've been working on a fork of La Clojure which is now about 70% migrated to 
>> Clojure and significantly improved. It's a lot of work to develop a tool 
>> like this, and one of the options I'm considering is starting a company to 
>> develop it as a commercial product - JetBrains have never maintained 
>> development of La Clojure very actively. I've been doing a little market 
>> research but there's really not much data around about whether there are 
>> enough people working with Clojure to sustain a product like that, and also 
>> the community is currently very focused on open source.
>> 
>> One problem is that the IDE space is already fairly fractured - there's 
>> Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some 
>> point, and of course the current public version of La Clojure. But there's 
>> still not a great option for something that's powerful but easy to use - CCW 
>> is probably the closest thing to this right now. However I think it's 
>> telling that a large fraction of people in the State of Cloju

Re: [ANN] 18th tutorial of modern-cljs series

[Greg]

Awesome! I'm glad to see that you added support for combining cljx with 
cljsbuild! :-)

Also looking forward to learning about Piggieback (that was already on my todo 
list, so I'm glad you covered it!).

Suggestion: have the different profiles all compile to the same *.js file, and 
combine all of the -dbg and -pre files together, just make it so that after you 
build with a profile, everything is set to that profile, and then to try the 
other version, just build with a different profile. Fewer files to update and 
deal with that way.

Cheers,
Greg

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

On Jul 26, 2013, at 6:34 AM, Giacomo Cosenza  wrote:

> Hi all,
> I just published the 18th episode of the modern-cljs series. 
> 
> It talks about two topics:
> 
> - the setup and configuration of a bREPL on top of an nREPL by using the 
> piggieback nrepl middleware created by Chas (I always meet its great works on 
> my way wherever I go - he's just amazing);
> - the setup and configuration of a more comfortable project structure by 
> using the lein profiles.
> 
> Here is the link
> 
> https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-18.md
> 
> HIH
> 
> Mimmo
> 
> p.s. the next month I'll be on vacation and I cant' guarantee to be able to 
> add new tutorials to the series.  
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Interest in a commercial IDE for Clojure?

[Greg]

Oh, some other thoughts/requests/ideas:

- Xocde-style refactoring for renaming symbols inline in the current scope. 
Sublime-style renaming would be OK too.
- For the jump-to-symbol stuff, don't actually change the view to the other 
symbol. Perhaps make an alternate command that lets you see that source but in 
a hover/floaty/popup window so that you don't have to navigate back to where 
you were.

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

On Jul 27, 2013, at 3:10 PM, Greg  wrote:

> Colin:
> 
> I think ST has a good business model via its constant nags. $70 USD to get it 
> to STFU and support the developer seems fair, while allowing those who can't 
> afford it to use it and tolerate the nags.
> 
> If you don't give people a way to use your IDE for free then most people 
> won't use it because there are plenty of free or nearly-free alternatives out 
> there that are already great (like Sublime). Having a large user-base will 
> help you in the long run, because without on your IDE won't have a community 
> behind it to support word-of-mouth and things like plugins, etc.
> 
> That said, I'd love an improved version of La Clojure for IntelliJ!
> 
> Here's a wish list if you decide to go for it:
> 
> - Perfect support for Leiningen, including support for all the crazy 
> customizations and sub-projects.
> - Bug-free or fewer bugs. The current Leiningen plugin has some bugs where it 
> prevents you from adding new jar files to the module (sometimes, not always).
> - Fantastic support for jumping to the definition of any symbol in your 
> leiningen project, whether it's Java source or Clojure source.
> - Support for ClojureScript.
> - Auto-complete of the Xcode variety, where for the selected function/method 
> in the drop down list you are shown all the documentation for it.
> 
> And, assuming you implemented all of the above, then it'd also be nice to 
> auto-import namespaces (similar to how IntelliJ already does it for Java 
> source).
> 
> Cheers!
> Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Jul 27, 2013, at 7:54 AM, Colin Fleming  
> wrote:
> 
>> Hi all,
>> 
>> I was planning to wait a little longer before going public, but since it's 
>> pretty relevant to the other IntelliJ thread going on at the moment I 
>> thought I'd jump in. For the last couple of months of happy unemployment 
>> I've been working on a fork of La Clojure which is now about 70% migrated to 
>> Clojure and significantly improved. It's a lot of work to develop a tool 
>> like this, and one of the options I'm considering is starting a company to 
>> develop it as a commercial product - JetBrains have never maintained 
>> development of La Clojure very actively. I've been doing a little market 
>> research but there's really not much data around about whether there are 
>> enough people working with Clojure to sustain a product like that, and also 
>> the community is currently very focused on open source.
>> 
>> One problem is that the IDE space is already fairly fractured - there's 
>> Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some 
>> point, and of course the current public version of La Clojure. But there's 
>> still not a great option for something that's powerful but easy to use - CCW 
>> is probably the closest thing to this right now. However I think it's 
>> telling that a large fraction of people in the State of Clojure 2012 survey 
>> still identified development tools as a major pain point.
>> 
>> I think that the IntelliJ platform is a fantastic base to build something 
>> like this on. Clojure as a language makes it pretty challenging to develop a 
>> lot of the great functionality that JetBrains are famous for, but I think 
>> there's scope to do a lot of great things. Certainly for mixed Clojure/Java 
>> projects it would be difficult to beat, but even for Clojure only projects I 
>> can imagine a lot of fantastic functionality built on their infrastructure. 
>> My plan would be to release a standalone IDE and a plugin for people using 
>> IntelliJ Ultimate for web dev, Ruby/Python or whatever. Since it's mostly 
>> Clojure now (and I'm migrating what's left as I get to it) there's a real 
>> possibility of a Clojure plugin/extension API. I envision charging 
>> PyCharm/RubyMine type prices, say $200 for company licenses or $100 for 
>> individual developers.
>> 
>> So, I'd love to hear what people think. 

Re: Interest in a commercial IDE for Clojure?

[Greg]

Colin:

I think ST has a good business model via its constant nags. $70 USD to get it 
to STFU and support the developer seems fair, while allowing those who can't 
afford it to use it and tolerate the nags.

If you don't give people a way to use your IDE for free then most people won't 
use it because there are plenty of free or nearly-free alternatives out there 
that are already great (like Sublime). Having a large user-base will help you 
in the long run, because without on your IDE won't have a community behind it 
to support word-of-mouth and things like plugins, etc.

That said, I'd love an improved version of La Clojure for IntelliJ!

Here's a wish list if you decide to go for it:

- Perfect support for Leiningen, including support for all the crazy 
customizations and sub-projects.
- Bug-free or fewer bugs. The current Leiningen plugin has some bugs where it 
prevents you from adding new jar files to the module (sometimes, not always).
- Fantastic support for jumping to the definition of any symbol in your 
leiningen project, whether it's Java source or Clojure source.
- Support for ClojureScript.
- Auto-complete of the Xcode variety, where for the selected function/method in 
the drop down list you are shown all the documentation for it.

And, assuming you implemented all of the above, then it'd also be nice to 
auto-import namespaces (similar to how IntelliJ already does it for Java 
source).

Cheers!
Greg

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

On Jul 27, 2013, at 7:54 AM, Colin Fleming  wrote:

> Hi all,
> 
> I was planning to wait a little longer before going public, but since it's 
> pretty relevant to the other IntelliJ thread going on at the moment I thought 
> I'd jump in. For the last couple of months of happy unemployment I've been 
> working on a fork of La Clojure which is now about 70% migrated to Clojure 
> and significantly improved. It's a lot of work to develop a tool like this, 
> and one of the options I'm considering is starting a company to develop it as 
> a commercial product - JetBrains have never maintained development of La 
> Clojure very actively. I've been doing a little market research but there's 
> really not much data around about whether there are enough people working 
> with Clojure to sustain a product like that, and also the community is 
> currently very focused on open source.
> 
> One problem is that the IDE space is already fairly fractured - there's Emacs 
> and CCW, Clooj, Sublime Text and the promise of Light Table at some point, 
> and of course the current public version of La Clojure. But there's still not 
> a great option for something that's powerful but easy to use - CCW is 
> probably the closest thing to this right now. However I think it's telling 
> that a large fraction of people in the State of Clojure 2012 survey still 
> identified development tools as a major pain point.
> 
> I think that the IntelliJ platform is a fantastic base to build something 
> like this on. Clojure as a language makes it pretty challenging to develop a 
> lot of the great functionality that JetBrains are famous for, but I think 
> there's scope to do a lot of great things. Certainly for mixed Clojure/Java 
> projects it would be difficult to beat, but even for Clojure only projects I 
> can imagine a lot of fantastic functionality built on their infrastructure. 
> My plan would be to release a standalone IDE and a plugin for people using 
> IntelliJ Ultimate for web dev, Ruby/Python or whatever. Since it's mostly 
> Clojure now (and I'm migrating what's left as I get to it) there's a real 
> possibility of a Clojure plugin/extension API. I envision charging 
> PyCharm/RubyMine type prices, say $200 for company licenses or $100 for 
> individual developers.
> 
> So, I'd love to hear what people think. I'd appreciate it if we could stay 
> away from the politics of open source vs proprietary - several people have 
> told me privately that they'd rather use OSS and that's fine, proprietary 
> isn't for everyone. What I'd like to know is if the idea is appealing to many 
> people here?
> 
> In case it's a concern for anyone, I've discussed this with JetBrains.
> 
> Thanks for any feedback,
> 
> Cheers,
> Colin
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> F

Re: Interest in a commercial IDE for Clojure?

[Greg]

> paredit - Yes, he wrote a kind of paredit for ST2. But it's really missing 
> several important functions. Plus it doesn't work as well as paredit.el does. 
> I tried to remedy these with no luck.

There were two plugins. The 1st link on Google is to and older one that points 
to the new one I sent you. Did you try the new one?

> shortcuts - Sure, that's true about emacs too. But having a well-thought-out 
> system is different than just randomly changing shortcuts. Shortcuts are 
> surprisingly tied together in subtle ways.

Then put some thought into your shortcut assignments. :-p

> And for the record lispindent is awful, I remember someone recently 
> explaining why in a gist comment, either tim baldridge or tomjack (or someone 
> else who goes in IRC a lot).

In my experience it's a vast improvement over the default.

> splits - I mean split-panes, like both vim and emacs have. ST2 does okay in 
> this area, but could use improvements to get as good as emacs. I think I 
> heard ST3 is working on that.


Did you try out the Origami plugin? It's excellent: 
https://github.com/SublimeText/Origami

> No idea how to edit it, so I considered it a lost cause.

Just regular expressions. If you know regex, then all you have to do is stare 
at the file for a while and it should become obvious what it's doing. You can 
also play around a bit with it.

> nrepl - The post above says that ST's repl support is super-crashy. That 
> doesn't give me a whole lot of confidence.


OK, well, were they talking about the fork I was referring to? Are you sure? 
Did you try it yourself?

I haven't experienced a single crash so far.

I see you didn't comment on the jump-to-* recommendations... why not?

Cheers,
Greg


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

On Jul 27, 2013, at 2:56 PM, Steven Degutis  wrote:

> Greg, thanks for your reply. Please see my responses:
> 
> paredit - Yes, he wrote a kind of paredit for ST2. But it's really missing 
> several important functions. Plus it doesn't work as well as paredit.el does. 
> I tried to remedy these with no luck.
> 
> shortcuts - Sure, that's true about emacs too. But having a well-thought-out 
> system is different than just randomly changing shortcuts. Shortcuts are 
> surprisingly tied together in subtle ways.
> 
> tabs - I meant tab-bar, and in this area ST2 is pretty much okay. It's a 
> little awkward that the same shortcuts switch between splits and tabs though. 
> And for the record lispindent is awful, I remember someone recently 
> explaining why in a gist comment, either tim baldridge or tomjack (or someone 
> else who goes in IRC a lot).
> 
> splits - I mean split-panes, like both vim and emacs have. ST2 does okay in 
> this area, but could use improvements to get as good as emacs. I think I 
> heard ST3 is working on that.
> 
> magit - I'll check it out, thanks.
> 
> themeable - true. But related to this is the terrible Clojure syntax file for 
> ST2, where almost everything is highlighted the same. For example only the 
> colon in a keyword is highlighted special, the rest of the keyword is 
> un-highlighed. And it's not just a theme issue, it's the same for every 
> theme, so it must be a syntax definition problem. I tried to fix it up, found 
> it was really just a TM bundle, and was terrified by its size. No idea how to 
> edit it, so I considered it a lost cause.
> 
> nrepl - The post above says that ST's repl support is super-crashy. That 
> doesn't give me a whole lot of confidence.
> 
> -Steven
> 
> 
> On Sat, Jul 27, 2013 at 1:44 PM, Greg  wrote:
> Steven:
> 
> ST2 has the following features that you wanted:
> 
> * paredit or better
>   - https://github.com/odyssomay/paredit
> * keyboard shortcuts that dont kill my wrists/pinkies/fingers
>   - you can make whatever shortcuts you want
> * jump-to-symbol-definition
>   - see my post on ST2 in the "is intellij idea a good idea" thread dated 
> July 25th.
> * jump-to-file
>   - the built-in "goto anything" works for that, and there are 
> file-specific plugins too
> * tabs (a la macvim)
>   - not sure what you mean, but there a plugin called "Lispindent" that 
> works great
> * splits (a la emacs)
>   - not sure what you mean, but there's a "Split Into Lines" command
> * magit or better (might be willing to ignore this omission though)
>   - Use these 3 plugins together: GitGutter, Side Bar Git, and SublimeGit
> * not-super-bloated UI
>   - ST fits this definition perfectly
> * themeable (dont care if it has a good theme, i can make one if need be, i 
> ju

Re: Interest in a commercial IDE for Clojure?

[Greg]

Steven:

ST2 has the following features that you wanted:

* paredit or better
- https://github.com/odyssomay/paredit
* keyboard shortcuts that dont kill my wrists/pinkies/fingers
- you can make whatever shortcuts you want
* jump-to-symbol-definition
- see my post on ST2 in the "is intellij idea a good idea" thread dated 
July 25th.
* jump-to-file
- the built-in "goto anything" works for that, and there are 
file-specific plugins too
* tabs (a la macvim)
- not sure what you mean, but there a plugin called "Lispindent" that 
works great
* splits (a la emacs)
- not sure what you mean, but there's a "Split Into Lines" command
* magit or better (might be willing to ignore this omission though)
- Use these 3 plugins together: GitGutter, Side Bar Git, and SublimeGit
* not-super-bloated UI
- ST fits this definition perfectly
* themeable (dont care if it has a good theme, i can make one if need be, i 
just need it to be themeable)
- ST is themeable (see my post in the other thread on July 25th)
* something like nrepl.el
- ST has SublimeREPL, which has a fork that works with nREPL. Link in 
the other thread.

So looks like you're pretty much covered by ST already. :-)

Cheers,
Greg

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

On Jul 27, 2013, at 11:57 AM, Steven Degutis  wrote:

> I would be willing to pay /really/ good money for an editor that has a few 
> features:
> 
> * paredit or better
> * proper syntax highlighting of clojure (emacs rocks at this, ST2 sucks at it)
> * ST2-quality fuzzy matching at every completionable prompt (emacs's ido-mode 
> is alright but ST2's is way better)
> * keyboard shortcuts that dont kill my wrists/pinkies/fingers
> * jump-to-symbol-definition
> * jump-to-file
> * tabs (a la macvim)
> * splits (a la emacs)
> * magit or better (might be willing to ignore this omission though)
> * not-super-bloated UI
> * themeable (dont care if it has a good theme, i can make one if need be, i 
> just need it to be themeable)
> * something like nrepl.el
> 
> (where ST2 means Sublime Text 2)
> 
> That's *all* I care about, nothing else matters to me. But no editor can get 
> *all* these things right.
> 
> -Steven
> 
> 
> On Sat, Jul 27, 2013 at 6:54 AM, Colin Fleming  
> wrote:
> Hi all,
> 
> I was planning to wait a little longer before going public, but since it's 
> pretty relevant to the other IntelliJ thread going on at the moment I thought 
> I'd jump in. For the last couple of months of happy unemployment I've been 
> working on a fork of La Clojure which is now about 70% migrated to Clojure 
> and significantly improved. It's a lot of work to develop a tool like this, 
> and one of the options I'm considering is starting a company to develop it as 
> a commercial product - JetBrains have never maintained development of La 
> Clojure very actively. I've been doing a little market research but there's 
> really not much data around about whether there are enough people working 
> with Clojure to sustain a product like that, and also the community is 
> currently very focused on open source.
> 
> One problem is that the IDE space is already fairly fractured - there's Emacs 
> and CCW, Clooj, Sublime Text and the promise of Light Table at some point, 
> and of course the current public version of La Clojure. But there's still not 
> a great option for something that's powerful but easy to use - CCW is 
> probably the closest thing to this right now. However I think it's telling 
> that a large fraction of people in the State of Clojure 2012 survey still 
> identified development tools as a major pain point.
> 
> I think that the IntelliJ platform is a fantastic base to build something 
> like this on. Clojure as a language makes it pretty challenging to develop a 
> lot of the great functionality that JetBrains are famous for, but I think 
> there's scope to do a lot of great things. Certainly for mixed Clojure/Java 
> projects it would be difficult to beat, but even for Clojure only projects I 
> can imagine a lot of fantastic functionality built on their infrastructure. 
> My plan would be to release a standalone IDE and a plugin for people using 
> IntelliJ Ultimate for web dev, Ruby/Python or whatever. Since it's mostly 
> Clojure now (and I'm migrating what's left as I get to it) there's a real 
> possibility of a Clojure plugin/extension API. I envision charging 
> PyCharm/RubyMine type prices, say $200 for company licenses or $100 for 
> individual developers.
> 
> So, I'd love to hear what people think. I'd 

Re: is intellij idea a good ide for clojure development?

[Greg]

BTW, if anyone here has decent Python experience and wants to try out Sublime 
for Clojure development, the plugin I linked to could really be improved by 
supporting regular expressions... :-)

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

On Jul 25, 2013, at 10:54 PM, Greg  wrote:

>> 'jumping to a symbol's definition (and back again)?  Those didn't seem to be 
>> there last time, and I'd struggle to live without them on a project of any 
>> size.'
>> 
>> Besides paredit, this is absolutely the most important feature for me 
>> day-to-day.  Nothing will replace emacs unless it has that.  The emacs one 
>> follows a stack-discipline, which is brilliant, and can even follow into 
>> dependency jars.
> 
> 
> Yes, Sublime Text (both 2 and 3) have the ability to jump to a symbol 
> (there's probably a way to switch to the previous view also, not sure what 
> the shortcut is for that).
> 
> ST3 has a built-in "Go to definition" menu item that ST2 doesn't have. I 
> haven't tried that yet with Clojure though because a bunch of awesome ST2 
> plugins haven't yet been ported to ST3.
> 
> ST2 has an awesome plugin (that just merged a patch I sent in today) called 
> Find Function Definition. It's a great hack for implementing "Go to 
> definition". To get it to work nicely with clojure, just copy/paste this into 
> your User Settings for that plugin:
> 
>   {
>   "definitions":
>   [
>   // the extra space at the end is important!
>   // otherwise foo will match a function def of foo-bar
>   "(defn $NAME$ ",
>   "(defn- $NAME$ ",
>   "(defn ^URL $NAME$ ",
>   "(defn ^String $NAME$ ",
>   "(defn ^File $NAME$ ",
>   "(defmacro $NAME$ ",
>   "class $NAME$ ", // java class
>   // but sometimes they will put a newline instead of a 
> space
>   // so if the above fail, try these:
>   "(defmacro $NAME$",
>   "(defn $NAME$",
>   "(defn- $NAME$",
>   "(defn ^URL $NAME$",
>   "(defn ^String $NAME$",
>   "(defn ^File $NAME$",
>   // if jumping becomes too slow, comment out the 
> following
>   "(def $NAME$ ",
>   "(defonce $NAME$ ",
>   "(declare $NAME$ "
>   ]
>   }
> 
> And then copy/paste this into your Syntax Specific User settings for Clojure 
> (open a .clj file, then find that menu item under Preferences > Settings — 
> More):
> 
>   {
>   "extensions": ["cljs", "clj", "cljx"],
>   "word_separators": "./\\()\"':,.;~@%^&|+=[]{}`~"
>   }
> 
> That might not be a perfect list of characters that act as word separators in 
> Clojure, but it has covered all the cases I've tried so far. Bind whatever 
> keyboard shortcut you want to the "go_to_function" command, and then after 
> positioning the caret over a function or var name, hit the shortcut. It will 
> search through all of files in the navbar on the left (i.e. your project) for 
> one of the above strings, replacing $NAME$ with the name of the symbol at the 
> caret.
> 
> Obviously this won't search within your mavin jar files, so what I've done is 
> simply extracted the source out of them for dependencies that I use and 
> placed those files within my project in a folder that's ignored by git. Thus, 
> "Find Function Definition" now works on just about every symbol I try it on! 
> :-)
> 
> I might make a blog post about my ST2 Clojure setup if there's any interest 
> in that.
> 
>> 4. On Sublime Text (ST)
>> 
>> 
>> Non-free.
> 
> 
> I'd say it's free for people who don't care about nag prompts. If you don't 
> want to support the developer, you can use all the features for as long as 
> you like at the cost of having to click "Cancel" at a nag prompt every so 
> often.
> 
> Cheers!
> Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
>

Re: is intellij idea a good ide for clojure development?

[Greg]

> You submit patches to nonfree software?!

How do you make a screwy-eyed emoticon?

The plugin is free software. ST is nagware. Oh, and IntelliJ, as others have 
already pointed out, is also free software (community edition, which is great).

-Greg

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

On Jul 25, 2013, at 10:58 PM, Cedric Greevey  wrote:

> You submit patches to nonfree software?!
> 
> 
> On Thu, Jul 25, 2013 at 10:54 PM, Greg  wrote:
>> 'jumping to a symbol's definition (and back again)?  Those didn't seem to be 
>> there last time, and I'd struggle to live without them on a project of any 
>> size.'
>> 
>> Besides paredit, this is absolutely the most important feature for me 
>> day-to-day.  Nothing will replace emacs unless it has that.  The emacs one 
>> follows a stack-discipline, which is brilliant, and can even follow into 
>> dependency jars.
> 
> 
> Yes, Sublime Text (both 2 and 3) have the ability to jump to a symbol 
> (there's probably a way to switch to the previous view also, not sure what 
> the shortcut is for that).
> 
> ST3 has a built-in "Go to definition" menu item that ST2 doesn't have. I 
> haven't tried that yet with Clojure though because a bunch of awesome ST2 
> plugins haven't yet been ported to ST3.
> 
> ST2 has an awesome plugin (that just merged a patch I sent in today) called 
> Find Function Definition. It's a great hack for implementing "Go to 
> definition". To get it to work nicely with clojure, just copy/paste this into 
> your User Settings for that plugin:
> 
>   {
>   "definitions":
>   [
>   // the extra space at the end is important!
>   // otherwise foo will match a function def of foo-bar
>   "(defn $NAME$ ",
>   "(defn- $NAME$ ",
>   "(defn ^URL $NAME$ ",
>   "(defn ^String $NAME$ ",
>   "(defn ^File $NAME$ ",
>   "(defmacro $NAME$ ",
>   "class $NAME$ ", // java class
>   // but sometimes they will put a newline instead of a 
> space
>   // so if the above fail, try these:
>   "(defmacro $NAME$",
>   "(defn $NAME$",
>   "(defn- $NAME$",
>   "(defn ^URL $NAME$",
>   "(defn ^String $NAME$",
>   "(defn ^File $NAME$",
>   // if jumping becomes too slow, comment out the 
> following
>   "(def $NAME$ ",
>   "(defonce $NAME$ ",
>   "(declare $NAME$ "
>   ]
>   }
> 
> And then copy/paste this into your Syntax Specific User settings for Clojure 
> (open a .clj file, then find that menu item under Preferences > Settings — 
> More):
> 
>   {
>   "extensions": ["cljs", "clj", "cljx"],
>   "word_separators": "./\\()\"':,.;~@%^&|+=[]{}`~"
>   }
> 
> That might not be a perfect list of characters that act as word separators in 
> Clojure, but it has covered all the cases I've tried so far. Bind whatever 
> keyboard shortcut you want to the "go_to_function" command, and then after 
> positioning the caret over a function or var name, hit the shortcut. It will 
> search through all of files in the navbar on the left (i.e. your project) for 
> one of the above strings, replacing $NAME$ with the name of the symbol at the 
> caret.
> 
> Obviously this won't search within your mavin jar files, so what I've done is 
> simply extracted the source out of them for dependencies that I use and 
> placed those files within my project in a folder that's ignored by git. Thus, 
> "Find Function Definition" now works on just about every symbol I try it on! 
> :-)
> 
> I might make a blog post about my ST2 Clojure setup if there's any interest 
> in that.
> 
>> 4. On Sublime Text (ST)
>> 
>> 
>> Non-free.
> 
> 
> I'd say it's free for people who don't care about nag prompts. If you don't 
> want to support the developer, you can use all the features for as long as 
> you like at the cost of having to click "Cancel" at a nag promp

Re: is intellij idea a good ide for clojure development?

[Greg]

> 'jumping to a symbol's definition (and back again)?  Those didn't seem to be 
> there last time, and I'd struggle to live without them on a project of any 
> size.'
> 
> Besides paredit, this is absolutely the most important feature for me 
> day-to-day.  Nothing will replace emacs unless it has that.  The emacs one 
> follows a stack-discipline, which is brilliant, and can even follow into 
> dependency jars.


Yes, Sublime Text (both 2 and 3) have the ability to jump to a symbol (there's 
probably a way to switch to the previous view also, not sure what the shortcut 
is for that).

ST3 has a built-in "Go to definition" menu item that ST2 doesn't have. I 
haven't tried that yet with Clojure though because a bunch of awesome ST2 
plugins haven't yet been ported to ST3.

ST2 has an awesome plugin (that just merged a patch I sent in today) called 
Find Function Definition. It's a great hack for implementing "Go to 
definition". To get it to work nicely with clojure, just copy/paste this into 
your User Settings for that plugin:

{
"definitions":
[
// the extra space at the end is important!
// otherwise foo will match a function def of foo-bar
"(defn $NAME$ ",
"(defn- $NAME$ ",
"(defn ^URL $NAME$ ",
"(defn ^String $NAME$ ",
"(defn ^File $NAME$ ",
"(defmacro $NAME$ ",
"class $NAME$ ", // java class
// but sometimes they will put a newline instead of a 
space
// so if the above fail, try these:
"(defmacro $NAME$",
"(defn $NAME$",
"(defn- $NAME$",
"(defn ^URL $NAME$",
"(defn ^String $NAME$",
"(defn ^File $NAME$",
// if jumping becomes too slow, comment out the 
following
"(def $NAME$ ",
"(defonce $NAME$ ",
"(declare $NAME$ "
]
}

And then copy/paste this into your Syntax Specific User settings for Clojure 
(open a .clj file, then find that menu item under Preferences > Settings — 
More):

{
"extensions": ["cljs", "clj", "cljx"],
"word_separators": "./\\()\"':,.;~@%^&|+=[]{}`~"
}

That might not be a perfect list of characters that act as word separators in 
Clojure, but it has covered all the cases I've tried so far. Bind whatever 
keyboard shortcut you want to the "go_to_function" command, and then after 
positioning the caret over a function or var name, hit the shortcut. It will 
search through all of files in the navbar on the left (i.e. your project) for 
one of the above strings, replacing $NAME$ with the name of the symbol at the 
caret.

Obviously this won't search within your mavin jar files, so what I've done is 
simply extracted the source out of them for dependencies that I use and placed 
those files within my project in a folder that's ignored by git. Thus, "Find 
Function Definition" now works on just about every symbol I try it on! :-)

I might make a blog post about my ST2 Clojure setup if there's any interest in 
that.

> 4. On Sublime Text (ST)
> 
> 
> Non-free.


I'd say it's free for people who don't care about nag prompts. If you don't 
want to support the developer, you can use all the features for as long as you 
like at the cost of having to click "Cancel" at a nag prompt every so often.

Cheers!
Greg

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

On Jul 25, 2013, at 8:32 PM, Gary Trakhman  wrote:

> 'jumping to a symbol's definition (and back again)?  Those didn't seem to be 
> there last time, and I'd struggle to live without them on a project of any 
> size.'
> 
> Besides paredit, this is absolutely the most important feature for me 
> day-to-day.  Nothing will replace emacs unless it has that.  The emacs one 
> follows a stack-discipline, which is brilliant, and can even follow into 
> dependency jars.
> 
> 
> On Thu, Jul 25, 2013 at 8:27 PM, Korny Sietsma  wrote:
> Indeed - I was using a community-edition intellij setup the other day, and 
> only realised when I went to edit some JavaScript, and found some 

Re: is intellij idea a good ide for clojure development?

[Greg]

Everyone has their preferences, and the best thing to do is to try it all and 
pick what you like.

That said... here's my experience with IntelliJ, and others

Table of Contents:
1. On IntelliJ
2. On Emacs and "Emacs Live"
3. On Light Table
4. On Sublime Text (ST)
5. Conclusion

1. On IntelliJ
-

I've tried Eclipse, NetBeans, and IntelliJ for Java development.

Of those, I only tried IntelliJ for Clojure development because I despise 
Eclipse's bloat and poor UI design, and Netbeans, while better (IMO), just 
isn't as slick and fast, and... intelligent :-p as IntelliJ. I really cannot 
wrap my head around why so many people like Eclipse. I think it must be a 
Mac/Windows-type phenomenon or something. There I've gone and pissed off half 
the users on this list... :-p

IntelliJ's La Clojure and Leiningen plugins are alright. They have some code 
sense autocompletion stuff, and you can jump to definitions (to an extent, it 
doesn't always work).

Overall it's my 2nd favorite choice for Clojure only because it too, is too 
bloated for my liking. Not as bloated as the other two "big IDEs", but still 
bloated.

2. On Emacs and "Emacs Live"


I've used Emacs off and on for about 3 years now. I spent weeks, probably 
months customizing it, trying out the emacs-starter-kit and making it my own. I 
let it along after I went on a Clojure sabbatical for a while and lived in 
Xcode.

When I came back, I saw this "Emacs Live" project and decided to give emacs one 
more shot because of it.

IMO, it sucks. Emacs is always going to suck from a UI and GTD perspective. It 
will only be embraced by the hardcore tinkerers who get a kick out of spending 
equal time tinkering with their editor as they do actual coding. It's kinda 
like the software equivalent of owning a Harley Davidson, except you look a 
nerd instead of an intimidating biker.

Emacs Live is also slow. Out of the box it's slow to launch on my fast 2010 MBP 
2.4Ghz Core i5 with 8GB of RAM and an SSD. They'll tell ya to run emacsclient 
and all that but it's just more bullshit.

If you like tinkering and memorizing a bunch of keyboard shortcuts, go with 
Emacs. Make sure you have a nice IRC client though because you're going to need 
it when things stop working. Emacs has one built-in btw, but you might need to 
get a regular GUI-based IRC client first, you know, so that you can figure out 
the Emacs-based one. :-p

3. On Light Table
---

Light Table seems promising but in my testing it's not ready for daily use, 
mostly due to lack of plugins and missing features.

4. On Sublime Text (ST)


Sublime Text is fucking awesome. This is my #1 choice for Clojure development.

While ST3 is in beta, it's best to use version 2 because many plugins, 
including the REPL integration via the SublimeREPL plugin, only work with 
version 2. There are some issues with nREPL at the moment, so use this fork 
until they can fix it in the main project (found via Github Issues): 
https://github.com/emestee/SublimeREPL

ST has many things going for it:

- Incredible customization via hundreds of plugins supported by a giant 
community
- Brilliant plugin and customization system that puts Emacs to shame in terms 
of balance between power and usability
- Fast. And faster launch times than Emacs Live
- Beautiful UI with many different color schemes and themes available (note: 
themes are not the same thing as syntax color schemes. I recommend the Soda 
Dark theme with Monkai Soda coloring.
- Built-in package manager for plugins, with the option to install plugins 
without using it too.
- Organized settings that use the well known and very readable JSON format. You 
don't have code mixed with settings like you do with Emacs, and there is a 
standard place that everything is supposed to go, unlike the free-for-all 
nightmare that Emacs has.
- There's a paredit plugin available for it if you care (I don't, and haven't 
used it).

It's worth spending some time customizing Sublime Text, but the good news is 
that your time won't be spent in vain, and once you have it set up the way you 
like, there's no need to continue tinkering like crazy.

5. Conclusion
-

- Yes, IntelliJ is a very good IDE for Clojure development.
- Sublime Text is better. :-)
- Cross your fingers for Light Table

Cheers,
Greg

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

On Jul 25, 2013, at 1:27 PM, Chris Gill  wrote:

> I find this interesting. I've been using light table mostly, but recently I 
> tried my hand at socket programming and light table flopped on this type of a 
> project. I ended up using lein repl for most of my work which became a pain 
> and now I'm looking

Can we please deprecate the :use directive ?

[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: [ANN] - 17th tutorial - Enlive by REPLing - of the modern-cljs series

[Greg]

Excellent work as usual Mimmo!

I continue to find your tutorials very helpful. Thank you very much for 
creating them!

-Greg

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

On Jul 14, 2013, at 11:53 AM, Mimmo Cosenza  wrote:

> Hi all, I just published the 17th tutorial of the modern-cljs series. 
> 
> https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-17.md
> 
> It shows how to integrate input validators in a form. To be respectful of the 
> progressive enhancement strategy, in this tutorial I started implementing the 
> validators into the server-side code by using Enlive. In the next tutorial 
> I'm going to do the same thing by using Enfocus.
> 
> My best
> 
> Mimmo
>  
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: --> macro proposal

[Greg]

This email just in case any Googler's stumble across this thread searching for 
a generalized threading macro (and a happy conclusion to it). Googling for 
examples on this macro was very difficult in my experience, so maybe this might 
help someone.

As I found out via the "The case for as->> ("as-last")" thread, a generalized 
threading macro was apparently introduced in Clojure 1.5: the as-> form:

clojure.core/as->
([expr name & forms])
Macro
  Binds name to expr, evaluates the first form in the lexical context
  of that binding, then binds name to that result, repeating for each
  successive form, returning the result of the last form.

As this tweet demonstrates, here's how it looks:

(as-> "/tmp" x (java.io.File. x) (file-seq x) (filter (memfn 
isDirectory) x) (count x))

First 'x' is bound to "/tmp" and a file is made out of it. 'x' is rebound again 
to the resulting file and a put through the 'file-seq' function, etc.

- Greg

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

On Jul 7, 2010, at 9:02 AM, Laurent PETIT  wrote:

> 2010/7/7 aria42 :
>> I've needed --> a few times in my code. I don't think I need it as
>> much as just -> or ->>. Most of the time I've needed it is because I
>> or someone else essentially had parameters
>> in the wrong order. Maybe it belongs in contrib along with -?> which
>> I've needed sparingly as well, but have found useful and would've been
>> non-trivial to have conjured.
> 
> -?> is particularly suitable when doing lots of java interop. I use it
> quite a lot in my own code in counterclockwise, for example.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: The case for as->> ("as-last")

[Greg]

Oh happy day! :-D

Today I was looking at some clojure code on using core.async with ClojureScript 
[1], and the example used this strange "as->" expression that I'd never seen 
before (I'm from the 1.2 era, just getting back into the Clojure game), and I 
was trying to figure out what the heck this thing was.

There are no examples on clojuredocs.org, and without an example I couldn't be 
sure whether my interpretation of (doc as->) was correct. All attempts to 
search the web for "as->" failed miserably because search engines don't care 
for special characters, so I searched the list and found this thread.

It turns out my wish for a generalized threading macro three years ago came 
true!!

https://groups.google.com/forum/#!msg/clojure/6Cb8MD5EC3w/y1mNNK3ZUxYJ

Thank you Rich (or whoever's responsible)!!! :-D

Cheers,
Greg

[1] http://swannodette.github.io/2013/07/12/communicating-sequential-processes/

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

On Feb 18, 2013, at 3:33 PM, Víctor M. V.  wrote:

> Fair enough. Now I'm beggining to truly appreciate as->, thank you. I still 
> believe as->> would be somewhat useful but I don't see it getting added to 
> clojure.core now.
> 
> On Mon, Feb 18, 2013 at 9:10 PM, Marko Topolnik  
> wrote:
> as-> is meant to be used as the only threading form. In your example you'd 
> want to replace the initial ->> with as->.
> 
> 
> On Monday, February 18, 2013 9:04:55 PM UTC+1, vemv wrote:
> That extra parenses trick is neat, never thought of that!
> 
> As for as->> being redundant - it could be considered so indeed, given that 
> as-> can be lambified: (->> [] (#(as-> % x (map inc x - but that's pretty 
> damn ugly haha. If you were thinking something else, please let me know.
> 
> Thanks - Victor
> 
> On Mon, Feb 18, 2013 at 8:44 PM, Marko Topolnik  wrote:
> On Monday, February 18, 2013 5:40:51 PM UTC+1, vemv wrote:
> 
> And neither can be solved by adding a lambda:
> 
> (-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail
> 
> Lambda does solve it, you are just missing the parens around the lambda:
> 
> (-> [[1 1 1] 2 3] (nth 0) (#(map inc %)))
>  
> 
> 
> Clojure 1.5's as->, though, can come to the rescue.
> 
> (-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool
> 
> Now, I only wish 1.5 came with as->> macro! Its implemetation is trivial 
> anyway.
> 
> (->> [1 2 3] (as->> _ (nth _ 0)))
> 
> Of course, for the given examples, using these "as" forms is overkill. But if 
> you've ever ended up writing large expressions (especially when 
> experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and 
> as->> can provide a more sequential, structured alternative.
> 
> Couldn't find any related discussion about the uses of as->, as its name is 
> unfriendly to Google/JIRA searches. Thoughts?
> 
> as-> is actually a generalization of both -> and ->>: you get to choose where 
> to involve the previous result in each form. That is why as->> would be 
> redundant.
> 
> -Marko
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com.
> 
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more opt

Re: Pedestal introduction question

[Greg]

Thanks! Yeah it's probably just a mistake in the docs.

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

On Jul 4, 2013, at 10:08 AM, gianluca torta  wrote:

> right, sorry!
> 
> I found the double role of "template" in this sample file on the pedestal 
> repo:
> https://github.com/pedestal/samples/blob/master/chat/chat-client/app/src/chat_client/web/rendering.cljs
> 
> maybe the doc you originally refer to is inspired by this, but something got 
> lost in the doc
> 
> -Gianluca
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Pedestal introduction question

[Greg]

Where did you see the first :require? I can't find it in the code sample.

> one deriving from:
> (:require ...
> [io.pedestal.app.render.push.templates :as templates]
> ...)

Thanks,
Greg

--
Sent from my mobile device.
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Jul 4, 2013, at 7:41 AM, gianluca torta  wrote:

> Hi,
> 
> I am pretty new to clojure and trying to learn a lot from this great list
> 
> anyway, looking at the code you point to, it seems that the name "templates" 
> has two roles:
> one deriving from:
> (:require ...
> [io.pedestal.app.render.push.templates :as templates]
> ...)
> one deriving from:
> (def templates (html-templates/hello-world-templates))
> 
> looks like the one used for calling add-template etc. is the first one
> 
> hth
> 
> -Gianluca
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.

Pedestal introduction question

[Greg]

I know there's a pedestal-users mailing list, and I sent my question to it, but 
for whatever reason it hasn't shown up there (perhaps it's still in the 
moderation queue?). Hopefully someone here might be able to help.

On this page: http://pedestal.io/documentation/application-introduction/

There is the following code (at the very bottom of the page):

(def templates (html-templates/hello-world-templates))

(defn count-model [old-state message]
  (condp = (msg/type message)
msg/init (:value message)
:inc (inc old-state)))

(defn render-page [renderer [_ path] input-queue]
  (let [parent (push/get-parent-id renderer path)
html (templates/add-template renderer path (:hello-world-page 
templates))]
(dom/append! (dom/by-id parent) (html {:message ""}

I don't understand how a map, in this case `templates', is also being used as a 
namespace: `(templates/add-template renderer ... )'.

What's going on?

Many thanks,
Greg

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

Linux Journal July "Intro to Clojure on the Web"

[greg r]

by Reuven Lerner.  10 pages.  Compojure is next.

http://www.linuxjournal.com/content/july-2013-issue-linux-journal-networking

Regards,
Greg

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Is there a better way to update a map atom?

[Greg]

OK, I've found something that shows how these two work when used in the 
implementation of a generator:

https://gist.github.com/daveray/1263503

I think I understand what the problem is now:

(reset! id (inc @id))

There's a "time gap" in between the dereference of 'id' and its assignment back 
to 'id' (after being incremented).

With swap!, no such problem exists, because it's an atomic operation where 
there is no such "time gap" between dereferencing, applying a function, and 
setting the new value. That all takes place in on magical atomic moment.

If I've got this wrong, please let me know!

Cheers,
Greg

On Jun 28, 2013, at 11:19 PM, Greg  wrote:

> Can anyone explain the relationship between swap! and reset! ?
> 
> Why is using swap! in this example "safe" and using reset! not?
> 
> I've tried searching google for comparisons of the two but can't find 
> anything, and the documentation doesn't help much.
> 
> Thanks,
> Greg
> 
> On Jan 21, 2013, at 6:22 PM, Stephen Compall  
> wrote:
> 
>> On Jan 21, 2013 3:28 PM, "Jim - FooBar();"  wrote:
>> > ...or you can go all the way, skipping reset! completely:
>> >
>> > (swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object 
>> > %3)) {} objects) ))
>> 
>> Which also has the benefit of being safe, unlike any reset!-based update.
>> 
>> --
>> Stephen Compall
>> If anyone in the MSA is online, you should watch this flythrough.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Latest JOGL with Clojure in Eclipse?

[Greg]

If you haven't considered LWJGL as an alternative to JOGL, I highly recommend 
it. I remember preferring it over JOGL when I compared them some years ago. 
Many popular game engines use it (like jMonkeyEngine).

http://www.lwjgl.org/
http://mybuddymichael.com/writings/using-lwjgl-from-clojure.html

On Dec 5, 2012, at 5:41 AM, "Andrew P. Lentvorski, Jr."  
wrote:

> Anybody have some advice for me about the latest JOGL(2.0 rc11) with Clojure 
> on Eclipse?  I'm running Eclipse Juno SR1 with Counterclockwise on OS X 
> 10.6.8.
> 
> The JOGL tutorial sets up by creating a JOGL project that you then make new 
> Java projects depend upon.  This works fine for Java and seems to be 
> considered the "official" way of making things go with Eclipse and Java.  I 
> can create a new Java project, add the JOGL project to the Java Build Path, 
> set up OpenGL and draw a basic triangle.  The project finds all the 
> dependencies and everything runs.
> 
> This doesn't seem to work for Clojure for some reason.  I could post specific 
> errors, but given that I'm a clojure newbie, I figured I should probably take 
> a further step back since I'm likely to be barking up the wrong tree 
> completely.  So, my question is:
> 
> What is the proper way to get JOGL running under Clojure on Eclipse?
> 
> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Is there a better way to update a map atom?

[Greg]

Can anyone explain the relationship between swap! and reset! ?

Why is using swap! in this example "safe" and using reset! not?

I've tried searching google for comparisons of the two but can't find anything, 
and the documentation doesn't help much.

Thanks,
Greg

On Jan 21, 2013, at 6:22 PM, Stephen Compall  wrote:

> On Jan 21, 2013 3:28 PM, "Jim - FooBar();"  wrote:
> > ...or you can go all the way, skipping reset! completely:
> >
> > (swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object 
> > %3)) {} objects) ))
> 
> Which also has the benefit of being safe, unlike any reset!-based update.
> 
> --
> Stephen Compall
> If anyone in the MSA is online, you should watch this flythrough.
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

[Greg]

Thanks Mike (or do you go by "Mikera" as your email alias suggests?),

I think you make very good points, so I withdraw my request.

I'm curious though... Just as a learning experience, would it be possible to 
"tack on" such syntax implicit indexing and slicing using Clojure's extend-type 
function?

Thanks,
Greg

On Jun 27, 2013, at 6:45 AM, Mikera  wrote:

> I agree that negative indexing (and presumably also modulo indexing for the 
> upper index?) is very useful. Stuff like this comes up all the time in 
> core.matrix
> 
> However I don't think it makes sense as a standard feature in Clojure's 
> low-level data constructs for several reasons:
> a) It's a breaking change for people who are handling out-of-bounds cases
> b) In new code it will mask out-of-bounds errors, which can conceal some 
> nasty bugs
> c) Cramming more implicit features into existing constructs is a bad idea in 
> general: explicit is better
> d) It probably adds a small performance overhead. Not worth making everyone 
> pay a cost for one special case feature
> 
> This kind of thing is IMHO better handled by either wrapping the vector in a 
> function, or creating some kind of extra collection wrapper that provides the 
> negative indexing functionality.
> 
> On Thursday, 27 June 2013 04:19:24 UTC+1, Michael-Keith Bernard (SegFaultAX) 
> wrote:
> Vectors and maps are already functions of their indices and keys, 
> respectively. I don't really think it makes sense for other sequence types 
> (seqs, lists, etc.) because they aren't naturally associative in the same 
> way. Finally, there isn't a Clojure form I'm aware of that allows negative 
> indices in the same way eg Python does, but I for one would find that 
> incredibly useful.
> 
> On Wednesday, June 26, 2013 8:01:02 PM UTC-7, Greg Slepak wrote:
> There is one feature that I really miss from newLISP and seems like it could 
> be a natural extension to Clojure, and that is implicit indexing for lists 
> and arrays.
> 
> Clojure already has something similar in its use of keywords to act as 
> functions that look themselves up in a map.
> 
> This is basically the same concept, but using numbers instead. Implicit 
> indexing creates a really elegant syntax for finding elements and ranges in a 
> list or array. Here's an example:
> 
> > (setf mylist '(a b c d e f g))
> (a b c d e f g)
> > (mylist 0)
> a
> > (mylist -1)
> g
> > (0 3 mylist)
> (a b c)
> 
> Has this been considered already? Would this be something that could be added 
> to the language syntax?
> 
> Thanks for your consideration!
> 
> Sincerely,
> Greg
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.

Adding implicit indexing to Clojure lists and arrays?

[Greg]

There is one feature that I really miss from newLISP and seems like it could be 
a natural extension to Clojure, and that is implicit indexing for lists and 
arrays.

Clojure already has something similar in its use of keywords to act as 
functions that look themselves up in a map.

This is basically the same concept, but using numbers instead. Implicit 
indexing creates a really elegant syntax for finding elements and ranges in a 
list or array. Here's an example:

> (setf mylist '(a b c d e f g))
(a b c d e f g)
> (mylist 0)
a
> (mylist -1)
g
> (0 3 mylist)
(a b c)

Has this been considered already? Would this be something that could be added 
to the language syntax?

Thanks for your consideration!

Sincerely,
Greg

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

[greg r]

You might want to check out "Clojure Data Analysis Handbook" by Eric 
Rochester.  There is an example using org.clojure/data.json and Incanter to 
read JSON format into an Incanter dataset.  You might find other recipes in 
the book useful as well:

http://www.packtpub.com/clojure-data-analysis-cookbook/book

I'm going through it (slowly) and learning a lot.  It's not a beginner's 
book.  Full blast functional programming for sure.

Regards,
Greg

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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] clj-configurator – A powerful yet simple Clojure configuration library.

[Greg V]

Hello everyone!

I made a little configuration library:

https://github.com/myfreeweb/clj-configurator

Supports any configuration format (TOML, YAML, JSON, EDN, whatever) -- you 
just parse it yourself.
Supports environment variables and Java system properties.
Automatically figures out types based on defaults.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Clojure 1.5 print-table, org-mode babel, and org-mode HTML gen

[greg r]

I think I was wrong about the extra elisp code required for nrepl to 
evaluate babel Clojure code blocks.  This was from last year:

https://groups.google.com/forum/?fromgroups=#!searchin/nrepl-el/babel/nrepl-el/txLYH9tH6AU/hj0NkyF8YZ8J

I checked my .emacs file and the extra code for clojure babel is commented 
out, so the later versions of nrepl must have this feature included.
Too many months ago, I really need to put better notes and comments in my 
.emacs file!

Greg

On Monday, March 4, 2013 4:25:23 PM UTC-5, Mark C wrote:
>
> Very cool. Great looking doc! I just installed LaTeX and TeXworks so it's 
> off to play. (Other than incanter I already have the rest working, 
> including nrepl -  though I have to start up nrepl with nrepl-jack-in. Is 
> that what you were planning on doing? It would be cool to have it launched 
> by the first compile!).
>
>
>

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