Re: Strings, Symbols, Keywords, Vars, NS, Type/Class…

[pmbauer]

Github page embeds your pdf as an image, browser sad.

https://github.com/franks42/kitjensink/raw/master/extras/ClojureVarsNamespaceType6.pdf

On Thursday, March 1, 2012 5:14:19 PM UTC-7, FrankS wrote:
>
> It is my experience that the way how these fundamental Clojure entities, 
> like Strings, Symbols, Keywords, Vars, NS, and Type/Class, are related, is 
> not so easy to figure out. This is not so much about programming Clojure, 
> but more about getting a better feel how the language is held together one 
> level below.
>
> I've created this graph that visually shows what core-functions will give 
> you a var from a symb, a str from a ns, etc.:
>
> "https://github.com/franks42/kitjensink/wiki/Symbs,-Vars,-NSs,-and-such";
>
> It's still work in progress, but compiling the info for this picture was 
> already very therapeutic and enlightning.
>
> Any comments or suggestions how to improve are most welcome.
>
> ---
>
> One part that added to my confusion about how these different types are 
> related, is the fact that the function signature and documentation is 
> sometimes unclear and feels inconsistent. For example, different 
> functions/macros let you pass a namespace as a string, a symbol-name, a 
> quoted-symbol or a ns-instance, or some (arbitrary) combination. Sometimes 
> a "name" refers to a symbol, sometimes a string, both in docs and in 
> implementation… I often find myself getting exceptions thrown because I 
> know a ns is expected, but I "guessed" wrongly about which type of 
> ns-identifier that particular function demanded. 
> Is that a common experience? 
> Is that "by design"? (not being facetious - sometimes you want to throw 
> exceptions if the wrong type is presented, or implementing all possible 
> function signatures that would support an ns passed as 
> string/symbol/instance simply adds too much additional testing).
>
> Regards, FrankS.
>
>

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

Re: ANN: ClojureScript revision 927 release

[pmbauer]

Weekend made.
Thank you!

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

Re: Exception handling changes in Clojure 1.3.0

[pmbauer]

I don't know what the right solution is either, but here is a JIRA ticket 
with an attached regression test.  A start.
http://dev.clojure.org/jira/browse/CLJ-855

On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote:
>
> I was a little worried about this when the exception behavior for fns was 
> changed. I think it's solvable, but don't know right now what the solution 
> is.
>
> -S
>

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

Re: Exception handling changes in Clojure 1.3.0

[pmbauer]

Fair enough. :) Complete test coverage is intractable.
But in clojure, there are only a handful of tests that contain a catch and none 
that test try/catch semantics.  Maybe I'm looking in the wrong place...

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

Re: Exception handling changes in Clojure 1.3.0

[pmbauer]

Would now be a bad time to observe there was a large change made to the way 
exceptions are handled, and the lack of guard-rails (no tests for exception 
handling behavior) may have contributed to this regression?
https://github.com/clojure/clojure/commit/8fda34e4c77cac079b711da59d5fe49b74605553

On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote:
>
> I was a little worried about this when the exception behavior for fns was 
> changed. I think it's solvable, but don't know right now what the solution 
> is.
>
> -S
>

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

Re: Reuse of generic Clojure/ClojureScript code?

[pmbauer]

Do you know if that solution will extend to sharing clojure core libraries 
where that makes sense (a lot of copy-n-pasted code in 
[core|set|string|walk|zip].cljs)?

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

Re: autoboxing in 1.3 RC-0

[pmbauer]

see 
https://github.com/clojure/test.benchmark/blob/master/src/main/clojure/alioth/mandelbrot.clj#L49

There's two ways to get rid of the reflection warning:
1) another function, appropriately type hinted
2) explicit conversion to long

According to my measurements for this particular case, option 2 is 
fractionally faster by ~3% over option 1.
Expectation would be the explicit conversion to long shouldn't be needed.

On Thursday, September 15, 2011 8:16:10 PM UTC-7, pmbauer wrote:
>
> I ran into this exact issue on an alioth benchmark.
> Adding the explicit (long ...) conversion gets rid of the reflection 
> warning, but didn't have a significant effect on performance.
> The inner loop is still boxing the return value.
>
> On Thursday, September 15, 2011 8:36:53 AM UTC-7, Sean Corfield wrote:
>>
>> On Thu, Sep 15, 2011 at 7:50 AM, David Nolen  wrote:
>> > Loop itself will return boxed values I think.
>>
>> Looks that way. The following code has no reflection warning:
>>
>> (loop [x 1 changed 0]
>>  (if (= x 10)
>>changed
>>(recur (inc x)
>>   (long (loop [y 1 changed-y changed]
>>   changed-y)
>> -- 
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>> Railo Technologies, Inc. -- http://www.getrailo.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

Re: autoboxing in 1.3 RC-0

[pmbauer]

I ran into this exact issue on an alioth benchmark.
Adding the explicit (long ...) conversion gets rid of the reflection 
warning, but didn't have a significant effect on performance.
The inner loop is still boxing the return value.

On Thursday, September 15, 2011 8:36:53 AM UTC-7, Sean Corfield wrote:
>
> On Thu, Sep 15, 2011 at 7:50 AM, David Nolen  wrote:
> > Loop itself will return boxed values I think.
>
> Looks that way. The following code has no reflection warning:
>
> (loop [x 1 changed 0]
>  (if (= x 10)
>changed
>(recur (inc x)
>   (long (loop [y 1 changed-y changed]
>   changed-y)
> -- 
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.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

Re: Example of a real-world ClojureScript web application

[pmbauer]

Bit of copyright violation, that.
If you want the Closure e-book, get a licensed copy.  We should encourage legal 
means of obtaining information rather than post links to hosts that aren't 
authorized to distribute materials.

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

Re: Stanford AI Class

[pmbauer]

+1

On Friday, August 12, 2011 3:16:15 PM UTC-7, Sergey Didenko wrote:
>
> BTW, Is there a case when AI self-modifying program is much more elegant 
> than AI just-data-modifying program?
>
> I just can't figure out any example when there is a lot of sense to go the 
> self-modifying route.
>

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

Re: Creating a map algorithmically

[pmbauer]

For the sieve, if performance matters, clojure's native data structures may 
not be the best choice.
A mutable array of boolean primitives could be more apropos.

(defn prime-sieve [^long n]
  (let [^booleans sieve (make-array Boolean/TYPE (inc n))]
...)

... using aset/aget to write/read sieve.

On Tuesday, August 9, 2011 1:18:46 PM UTC-7, Chouser wrote:
>
> On Tue, Aug 9, 2011 at 12:50 PM, Kevin Sookocheff
>  wrote:
> > Hi,
> >
> > I have a question regarding the map data structure. I'm trying to program 
> a
> > Sieve of Eratosthenes using the algorithm at Wikipedia:
> >
> > Input: an integer n > 1
> >
> > Let A be an array of bool values, indexed by integers 2 to n,
> > initially all set to true.
> >
> > for i = 2, 3, 4, ..., while i^2 ≤ n:
> >   if A[i] is true:
> > for j = i^2, i^2 + i, i^2 + 2i, ..., while j ≤ n:
> >   A[j] = false
> >
> > Now all i such that A[i] is true are prime.
> >
> > I'm having a problem creating the data structure A.
> >
> > What I want to do is create a map of integers from 2 to n all initialized 
> to
> > true that I can then prune using the algorithm.
> >
> > Any ideas?
>
> Since the keys are consecutive integers, you might consider a vector
> of booleans:
>
> (def A (vec (repeat (inc n) true)))
>
> You can then use assoc to set any particular index to false:
>
> (assoc A 5 false)
>
> Differences using a vector instead of a hash-map: will stay in numeric
> order, doesn't allow arbitrary dissoc, nth and assoc may be faster,
> use less memory, (vector-of :bool) will definitely use less memory,
> and probably others.  Depending on your goals, a vector may or may not
> be preferable to a hash-map.
>
> --Chouser
>
>

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

Re: ClojureScript Compile errors

[pmbauer]

>
> Why all the attention to :use - I thought everyone agreed using it is  
> a bad idea?
>
Really? I thought it's use was only considered bad form in the absence of 
:only 

> The only benefit I see is that you can avoid a (minimum 2  
> character) prefix.
>
I would think the obvious benefit is its inclusion makes it easier port and 
share code between ClojureScript and Clojure.
Every difference beyond the necessary (interop, no runtime compiler) makes 
re-use that much more difficult (see macro use, binding semantics, numerics, 
ns macro differences).
Now if that's not a target and there is no expectation of sharing then all 
this is of course a non-issue.

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

Re: ClojureScript Compile errors

[pmbauer]

In Clojure, there is a clear distinction between using Clojure namespaces 
and importing interop packages.
Is it a goal then to blur that line in ClojureScript?
'use' couldn't be used analogously just for ClojureScript names as it is in 
Clojure?



On Friday, August 5, 2011 5:14:36 PM UTC-7, Rich Hickey wrote:
>
> On Aug 5, 2011, at 3:06 PM, David Nolen wrote:
>
> > On Fri, Aug 5, 2011 at 2:51 PM, Fogus  wrote:
> > The following lines looks problematic:
> >
> >(ns mainpage
> >(:use lib.dom-helpers))
> >
> > That is, ClojureScript only supports the (ns foo (:require [a.b :as
> > c])) form.  Try changing your ns declaration accordingly.
> >
> > The error message could be slightly better I agree.  ;-)
> >
> > :F
> >
> > Is there any particular reason / design rationale to not support use?
> >
>
> :use requires the ability to determine all the names in a namespace,  
> something we don't generally have in ClojureScript, especially for JS  
> pseudo-namespaces.
>
> Rich
>
>

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

Re: ClojureScript Compile errors

[pmbauer]

You don't need 'use' in production? ;)
*ducks*

On Friday, August 5, 2011 12:06:29 PM UTC-7, David Nolen wrote:
>
> On Fri, Aug 5, 2011 at 2:51 PM, Fogus  wrote:
>
>> The following lines looks problematic:
>>
>>(ns mainpage
>>(:use lib.dom-helpers))
>>
>> That is, ClojureScript only supports the (ns foo (:require [a.b :as
>> c])) form.  Try changing your ns declaration accordingly.
>>
>> The error message could be slightly better I agree.  ;-)
>>
>> :F
>
>
> Is there any particular reason / design rationale to not support use?
>
> David 
>

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

Re: Libraries and build management hell

[pmbauer]

>
> I might be able to disprove your scurrilous charge if ...
>
I doubt that since your earlier assertion was factually incorrect. 

> > See mvn install:install-file
> >
> > http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
>
> Not relevant. We were discussing use of lein deps.
>
Wrong again. Lein shares a repository format and location with maven for 
dependencies.

You would do well to educate yourself on a topic before picking an argument 
with those who are.

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

Re: Libraries and build management hell

[pmbauer]

"What if you have the JAR on a disk somewhere, for other reasons, but
until now it wasn't a dependency of that particular project?"

Your assertion that dependency management systems are in any way 
disadvantaged to manual dependency management in terms of SPOF or requiring 
a network connection is merely incorrect.

See mvn install:install-file

http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html


On Sunday, July 31, 2011 9:06:49 PM UTC-7, Ken Wesson wrote:
>
> On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield  
> wrote:
> > On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson  wrote:
> >> If you add a new dependency, the network connection is needed.
> >
> > If you add a new dependency and you don't already have the JAR
> > downloaded, you need a network connection one way or another to go get
> > that JAR, yes?
>
> What if you have the JAR on a disk somewhere, for other reasons, but
> until now it wasn't a dependency of that particular project?
>
> -- 
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
>

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

Re: Possible Issue with Listing 11.5 from the "Joy of Clojure"

[pmbauer]

"Please post all Errors and Corrections here"
http://www.manning-sandbox.com/thread.jspa?threadID=41321&tstart=0

On Friday, July 29, 2011 9:10:00 PM UTC-7, Julien Chastang wrote:
>
> Thanks for your in-depth analysis. 
>
> In conclusion, the 11.5 listing is broken specifically with the 
> reification of the seq function. The problem is that the seq function 
> allows the array reference to escape in an unsafe manner. The issue is 
> concurrency as well as visibility. As you suggest, the only fix is to 
> safely copy (via the locking function, i.e. synchronized block) the 
> contents of the array into a data structure that would be passed back 
> to the calling code. 
>
> By the way, I still think you need a lock in the count function in the 
> case where the caller tries to invoke the count function on a 
> partially constructed object. You may be able to reason otherwise, but 
> it is simply confusing to do so. Just access shared mutables in a safe 
> manner and you will be OK. 
>
> On Jul 29, 3:38 pm, Ken Wesson  wrote: 
> > On Fri, Jul 29, 2011 at 3:19 PM, Julien  wrote: 
> > > This listing is an attempt to make the function safe for concurrent 
> > > modification. My claim is that count and seq should also be locking 
> > > around "a" for exactly same reason as aget and aset. In particular, 
> > > locking is not only ensuring mutual exclusion but also *visibility*. 
> > > The danger is that count and seq may be accessing stale values of "a". 
> > 
> > In the case of "count" that danger doesn't exist; Java arrays are of 
> > fixed size from creation, so the "count" value cannot change. 
> > 
> > The case of "seq" is trickier: the array can indeed change contents 
> > midway through iteration. But there's no simple fix. One could write 
> > something like 
> > 
> > (let [cnt (dec (count a)) 
> >   step (fn step [i] 
> >  (lazy-seq 
> >(if (> i cnt) 
> >  (do (monitorexit a) nil) 
> >  (cons x (step (inc i))] 
> >   (monitorenter a) 
> >   (step 0)) 
> > 
> > to hold a lock all the way through seq traversal, but if the seq is 
> > only partially traversed (either deliberately, or because of a thrown 
> > exception) the lock will never get released. 
> > 
> > More complicatedly, you could create a CloseableSeq defprotocol that 
> > extends ISeq and Closeable and create closeable seqs (line-seq could 
> > benefit from this as well); for the above the close operation would be 
> > (monitorexit a) (and for line-seq (.close rdr)). Closeable seqs could 
> > then be created in (with-open ...) and handled in an exception-safe 
> > manner -- so long as you made sure to consume or doall the seq before 
> > the end of the with-open scope. In the array seq case, the seq would 
> > still seem to work after the scope exited, but it would show an array 
> > in a possible state of flux again instead of a fixed state. 
> > 
> > Given all this complication, easiest might be 
> > 
> > (seq [this] 
> >   (locking a 
> > (seq (into [] a 
> > 
> > which has the downside of copying the array into a vector but the 
> > upside of being thread- and exception-safe; the seq is backed by a 
> > fixed snapshot of the array. And can be traversed lazily and at 
> > leisure without holding onto a lock the whole time; the lock's held 
> > only during the copying. If you're worried about seeing inconsistent 
> > cell values during a traversal of a short array this is what you ought 
> > to use. 
> > 
> > But you should probably prefer to avoid arrays for the most part. :) 
> > 
> > Note: you will still potentially see *stale* values; the array can 
> > change after the snapshot is made. To avoid that you'd always have to 
> > lock during the operation where you want to be seeing the most up to 
> > date values. But you wouldn't see *inconsistent* values. If the array 
> > contains all 1s, and then someone else locks it, changes each cell to 
> > 2, and unlocks, and you are traversing the seq given above, you might 
> > get back (1 1 1 1 2 2 2 ...) which violates the intended invariant of 
> > all-the-same-number. With the snapshot you'll possibly see all-1s even 
> > after it's been updated to all-2s but you will never see a mixture. 
> > With locking the array the whole time you're working with the seq, 
> > you'll see all-2s if the array was ever updated to all-2s and 
> > otherwise the thing that will eventually update it to all-2s will 
> > block until you're done with the seq. 
> > 
> > > See Java Concurrency in Practice, Section 3.1 for more of a 
> > > discussion. My reasoning is based on the assumption that locking is 
> > > simply an abstraction for the Java synchronized keyword. That 
> > > assumption may or may not be correct. 
> > 
> > It is correct, though Clojure exposes the lower-level monitorenter and 
> > monitorexit; both Java synchronized and Clojure locking boil down to 
> > (the bytecode emitted by) 
> > 
> > (try 
> >   (monitorenter foo) 
> 

[ANN] (first phoenix-clojure-user-group-meetings)

[pmbauer]

Announcement Link, details: 
https://groups.google.com/d/topic/clj-phx/l_S4qcOSuaY/discussion

August 30th, 6:30 PM
Food provided.
Please use the group mailing list for replies, RSVPs (
http://groups.google.com/group/clj-phx)

Hosted by *Shutterfly *.

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

Re: Clojure User Group, Phoenix

[pmbauer]

Great! I've created a mailing list:

http://groups.google.com/ <http://groups.google.com/group/clj-phx>
group/clj-phx <http://groups.google.com/group/clj-phx>

On Thursday, July 28, 2011 8:17:14 PM UTC-7, Charlie Griefer wrote:
>
> On Thu, Jul 28, 2011 at 8:12 PM, pmbauer  wrote:
> > Anyone in the Phoenix area care to help start a Clojure user group?
> > http://clj-phx.wikispaces.com/Startup+Discussion
>
> I'm in.  I'm a total n00b, but I'm definitely in.
>
> -- 
> Charlie Griefer
> http://charlie.griefer.com/
>
> I have failed as much as I have succeeded. But I love my life. I love
> my wife. And I wish you my kind of success.
>
>

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

Clojure User Group, Phoenix

[pmbauer]

Anyone in the Phoenix area care to help start a Clojure user group?
http://clj-phx.wikispaces.com/Startup+Discussion

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

Re: format and printf can't be used with BigInt

[pmbauer]

That wasn't called for.

Given Stu linked to the page (and is linked in the 1.3 release notes), it's 
reasonable to assume the permission error is merely a mistake and not some 
nefarious plot to withhold information from the Clojure community.

On Thursday, July 28, 2011 4:48:34 PM UTC-7, Ken Wesson wrote:
>
> On Thu, Jul 28, 2011 at 7:30 PM, Sean Corfield  
> wrote:
> > I think one of the authors / core members needs to change the
> > permissions. I have edit access on the parent page
> > http://dev.clojure.org/display/doc/Enhanced+Primitive+Support and the
> > sibling page http://dev.clojure.org/display/doc/Bit+Operations but,
> > like you, don't have view access to the Numerics page.
>
> > On Thu, Jul 28, 2011 at 7:27 AM, Perry James  
> wrote:
>
> >> You cannot view this page
>
> I can't think of a single good reason why any of these pages should
> not be world-readable. We're an open source project. It's not as if we
> have trade secrets or something.
>
> I have no problem, of course, with restricting *edit* privileges to
> those with accounts that have proven to be responsible adults.
>
> -- 
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
>

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

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[pmbauer]

These "unhappy" threads need to die a horrible death.

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

Re: Alright, fess up, who's unhappy with clojurescript?

[pmbauer]

Fair point, but Rhino doesn't always have the correct semantics.

For example, one common JS idiom for default params:
eval("undefined || 2 + 2") => returns true instead of 4

But mostly, Rhino is just a JS engine with no DOM, so is less than ideal for 
browser UI development.
 

> > I do so hope however that someone manages to pull that out for a "lets 
> run this NOW on Java 7" as that would be a great improvement over rhino. 
>
> Does it really matter? Nobody would really deploy ClojureScript based 
> on Rhino, right? As long as Rhino has the correct semantics its fine 
> as a repl. We allready have a programming language that runs fast on 
> the JVM, its called 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

Re: better community docs: getting started

[pmbauer]

>
> I do not think we should attempt a recommended IDE (not even Clooj).
> We should offer a path for all existing IDEs / editors. 
>
... 

> Use an editor not listed here? Try Clooj
> (i.e., use this as a simple catch-all if we haven't covered what you
> already used today).
>

That's one way of organizing it.

The slightly serious explorer will of course pick setup documentation for 
their favorite IDE/editor, and that should be provided.

But think of the casual dev wanting to know what Clojure and a typical 
Clojure toolchain can do for her ASAP.
Most Java devs have never used a repl-aware edit buffer, something most of 
us take for granted.
No common IDE/editor setup can expose her to a lisp-style toolchain in a 
single click.  None.

For usability, nothing beats the single-click.  In seconds, Clooj gives her 
a one-stop-shop.
So I see Clooj as something worth putting right along with try-clojure.org.
It not only showcases Clojure, but is rapid exposure to the lisp-style 
toolchain.

That's why I would give Clooj some prominence rather than burying it at the 
bottom of the decision tree.
Anyone knowing what they're looking for will of course move on to the setup 
of their preference (emacs,vi,eclipse), so they don't lose anything.
But the neophyte who doesn't know what they're looking for should have the 
lowest barrier to entry possible - usability.

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

Re: Leiningen on OpenBSD

[pmbauer]

FWIW, lein and JDK 1.7 play fine together on both my linux systems (Ubuntu 
10.10 and 11.04).

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

Re: better community docs: getting started

[pmbauer]

+1 on clooj.
One click and you have a working build environment, REPL, and REPL-aware 
editor.

https://github.com/downloads/arthuredelstein/clooj/clooj-0.1.5-standalone.jar

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

Re: better community docs: contrib

[pmbauer]

P.S.
JIRA account ID: pmbauer

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

Re: better community docs: contrib

[pmbauer]

Would be glad to help.
I have a JIRA account (CA signed, etc) but no perms to add/edit pages.

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

Re: BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

Fair enough.  That addresses my concern.

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

Re: BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

Fair enough.

But, it would be nice to eventually have a ClojureScript jar available in a 
public maven repo someplace.
Not having one would needlessly complicate projects that already use a 
maven-based build tool (mvn, lein, cake) and want to depend on it as part of 
their build.

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

Re: :require farms in Clojure?

[pmbauer]

Something akin to the clj-nstools ns+ in clojure proper would sure make life 
easier.

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

Re: BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

If ClojureScript isn't "mavenified", how else do you easily make it a 
dependency in a web application?

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

Re: BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

I know.
But the sorts of (presently non-portable) scripts in "scripts" (see 
bootstrap, repl) ad-hoc test strategy, etc in ClojureScript are begging for 
dependency management and a build tool.

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

BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

PS
re: 3rd point (portable helper scripts) Even better would be ClojureScript with 
maven support - much bigger effort, sure.

I'd be willing to help work on that and submit some patches/plugins if that was 
an authorized direction.

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

BUG REPORT: ClojureScript : Portable Path Support

[pmbauer]

Per instructions from redinger and jgehtland (patch addressing one issue 
attached).

Three separate issues so far re: path support on windows

* compiler path regex is not portable, cljs/compiler.clj:1096 (see attached 
patch, thanks amalloy for the assist)

* generated JS has path problems on windows
goog.addDependency(*
"..\..\..\..\..\..\..\/C:/tmp/clojurescript/samples/twitterbuzz/out/cljs/core.js"
*, ['cljs.core'], ['goog.string', 'goog.string.StringBuffer', 'goog.object', 
'goog.array']);

* helper launch scripts on windows (under cygwin), more a feature than bug

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en>From 6b7b35504af661e16fc24487d309719cda974d31 Mon Sep 17 00:00:00 2001
From: unknown 
Date: Wed, 20 Jul 2011 18:56:19 -0700
Subject: [PATCH] Made path pattern portable.

---
 src/clj/cljs/compiler.clj |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 mode change 100644 => 100755 src/clj/cljs/compiler.clj

diff --git a/src/clj/cljs/compiler.clj b/src/clj/cljs/compiler.clj
old mode 100644
new mode 100755
index b1f2213..b7090b0
--- a/src/clj/cljs/compiler.clj
+++ b/src/clj/cljs/compiler.clj
@@ -1093,7 +1093,7 @@ goog.require = function(rule){Packages.clojure.lang.RT[\"var\"](\"cljs.compiler\
 
 (defn path-seq
   [file-str]
-  (string/split file-str (re-pattern java.io.File/separator)))
+  (string/split file-str (re-pattern (java.util.regex.Pattern/quote (java.io.File/separator)
 
 (defn to-path
   [parts]
-- 
1.7.5.1

Re: Results from 2011 State of Clojure survey

[pmbauer]

On Tuesday, July 12, 2011 6:18:12 PM UTC-7, Chas Emerick wrote:
>
> I hesitate to go even more meta, but since I started the thread, I thought 
> I would say:
>
> I talked for a bit in the results post about mailing list threads going 
> into the weeds; at least IMO, this one qualifies.  It wouldn't be the worst 
> thing in the world if it died right here. :-)
>
> Cheers,
>
> - Chas
>

Too late.  Your thread has been YAKT (Yet Another Ken Thread). 

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

Re: Which Clojure environments support arglist-on-space?

[pmbauer]

Slimv supports this for clojure via swank.

http://www.vim.org/scripts/script.php?script_id=2531

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

Re: Contagious BigDecimals?

[pmbauer]

(re: why then...)
P.S.
I mean in more general context of how double contagion is handled in most 
languages.
Clojure 1.3 alphas auto-promote floats to doubles in almost every case eg. 
exception: (type (float 1.0))

On Monday, May 23, 2011 4:16:48 PM UTC-7, pmbauer wrote:
>
> If you add an inexact number and an exact number, the only thing that
>> makes sense is to return something that is inexact.
>
>
> So why then are double's contagious when mixing double and float values in 
> a calculation? 
> Doubles and floats are both inexact, but floats are at least less exact 
> than doubles.
>

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

Re: Contagious BigDecimals?

[pmbauer]

>
> If you add an inexact number and an exact number, the only thing that
> makes sense is to return something that is inexact.


So why then are double's contagious when mixing double and float values in a 
calculation? 
Doubles and floats are both inexact, but floats are at least less exact than 
doubles.

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

Re: Clojure 1.3 Alpha 7

[pmbauer]

Use Case: Auto-generated record -> relational mapping?
Tables with more than 19 columns is not unheard of.

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

Re: Clojure stack

[pmbauer]

I'm beginning to think this has degenerated a bit into argument for 
arguments sake.

Yes, JRE.  You don't need the JDK to read/eval .clj files. And in the 
context of where this all started, namely, critiques to the current getting 
started experience for new users, a 75MB JDK + 100MB IDE is exactly the sort 
of heavyweight, intimidating experience that detracts from initial exposure. 
Clojure isn't just competing with Groovy, Scala, and other JVM languages for 
developer attention. Websites like try-clojre.org have their place, but 
aren't really in this context.

Official support for a starter kit that automatically downloads or packages 
clojure, jline, etc would go a long way to lowering barrier-to-entry.
Lein is one such option, but unlikely to get official recognition giving 
clojure/core's (arguably correct) decision to stick to maven.

Groovy is really exemplary in this regard: installer on windows, .deb/apt 
packaging on linux (clojure has one, but it's 1.0).

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

Re: Clojure stack

[pmbauer]

Mmm, not quite.
Doesn't clojure run just fine with the 15MB JVM?

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

Re: Clojure stack

[pmbauer]

>
> If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :)
>
Not quite.
As far as official disto's go, the current state is a little raw for getting 
started
And having the official getting started instructions be (as you suggested) 
"So now you go download this 100MB IDE" is a little heavy. No?

There's room for something in-between.

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

Re: Clojure stack

[pmbauer]

>
> The recommended way definitely should be one of the painless installs.
> This works:
>
> * Download NetBeans, configuring on the NB homepage for J2SE, and run 
> installer 
>
So does this:
>
> * Download Eclipse J2SE
>
Sure, but that's still a lot of work just to get a simple repl.

The easiest way (by far, and it doesn't work on Windows):
$ wget https://github.com/technomancy/leiningen/raw/stable/bin/lein; lein 
repl

clojure.org and the standard distro could use a little tlc.

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

Re: Clojure stack

[pmbauer]

The official way to get started has way too many sharp edges
(Download JDK, install, set JAVA_HOME, add JAVA_HOME/bin to path, download 
clojure.zip, extract, sacrifice chicken, run java -cp clojure.jar clojure.main) 
... at which point you get a kinda crappy REPL. Oops.

Compare to (on linux):
sudo apt-get install groovy; groovysh # even installs openjdk if needed

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

Re: Joy of Clojure errata: Chapter 5

[pmbauer]

>> Sorry; I don't really care for web forums much. I think mailing lists
> >> and Usenet are much to be preferred.
> >
> > Please do use Manning's forum for this.
>
> Actually, I can't. My copy is borrowed, for now, rather than my own,
> so I don't have an account there.
>
Actually, you can.
You just have to take a few minutes to create an account so errata can go to 
the appropriate place.
http://www.manning-sandbox.com/accountCreate!default.jspa

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

Re: Clojure stack

[pmbauer]

I've found the community to be very friendly and helpful.
 

> The problem is that the entire contents of the clojure.org site is 
> written by an expert, for experts.
>

...and necessary.
More verbose, newbie-friendly docs are important too, but take a lot more 
time and effort (clojuredocs.org, clojureatlas.com have great promise in 
this regard)

So I don't think this newbie-unfriendliness is out of malice or arrogance as 
much as perhaps one of focus and lack of resources.
Great newbie-friendly docs, starter kits, etc. take time and work - work 
that's honestly tedious compared to implementing a new concurrency construct 
or blazing fast primitive support. And in fairness, if you have the mind to 
do the latter, I'd rather not have that person wasted working on the former.

Granted there are broken windows on clojure.org that detract from its image:
e.g.
  * spotty details on the contribution process (info scattered between jira, 
clojure.org, mailing list, no process info links on github)
  * missing info/visiblity on state of clojure.next
  * public hudson server often showing builds broken for weeks/months

 

> EXAMPLE 2: Cryptic code 
>
> single-character variables
>

That it is a bit of an eye-brow-raiser for people of the "Uncle Bob" clean 
coder school that emphasizes verbose, literate naming conventions.
It's something to get used to - every language has its idioms. 

The biggest inhibitor by far for adoption is tool support (unless you attend 
the Church of Emacs).
Compared to Scala and (especially) Groovy, Clojure tool quality is green, 
but acceptable for a three-year-old language.
These things take time.

  
 *"It wouldn't be Lisp without existential angst" 
@stuartsierra
*

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

Re: clojure contrib build failure on win7

[pmbauer]

clojure-contrib was left broken 1.5 months past.
clojure/core are no longer maintaining the monolithic clojure-contrib 
library as it is deprecated.

A bunch of new projects are starting to fill the void (see listing at 
https://github.com/clojure)
Some functionality isn't making the migration - some from lack of support - 
and much work is left.

For details: http://dev.clojure.org/display/design/Clojure+Contrib

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

Re: Joy of Clojure errata: Chapter 5

[pmbauer]

Manning's forum would be a better home for errata than the Clojure mailing 
list.
http://www.manning-sandbox.com/forum.jspa?forumID=624

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[pmbauer]

ALT-<[LEFT|RIGHT] ARROW> - nav back/forward
I was very pleased to have proper browsing history support - great way
to do breadcrumbs.

P.S.
When I started learning clojure a year ago, one of the biggest pain
points was not having a resource like this.
Dynamic languages, in general, and clojure, in particular, lack the
self-documenting relational ontology that static language jocks take
for granted.
It's difficult to quickly find relationships (e.g. find all the
functions that operate on ISeq or Seqable); having half of Clojure
implemented in Clojure and the other half in Java doesn't make it easy
to automate this navigation with tools either.

Major kudos on this.

On May 3, 4:39 pm, Chas Emerick  wrote:
> On May 3, 2011, at 6:06 PM, Sean Corfield wrote:
>
> > It's a very cool way to visualize the Clojure world and to explore
> > what's available. One thing I found - which would definitely stop me
> > paying for it as-is - I get lost when I drill down: there's no way to
> > navigate 'back' to what I was looking at and no sense of history (like
> > a crumb trail). Messing around with the demo I just realized I can use
> > the browser back button / hot key but that feels clunky - being able
> > to navigate more easily with keyboard shortcuts within the atlas
> > itself would make it a lot nicer to use. Perhaps left arrow / right
> > arrow to go back / forward thru the direct history and up arrow / down
> > arrow to jump up and down the hierarchy?
>
> That's interesting; I very intentionally built in "proper" support for 
> browser back/forward actions (as you discovered), thinking that that would be 
> a good local maxima in terms of history navigation.  FWIW, click-and-hold on 
> the back or forward buttons in your browser will give you the "breadcrumbs" 
> you're looking for.
>
> I'm not entirely convinced that left/right shortcuts would make sense — that 
> would simply map to back/forward in the browser, which already have keyboard 
> shortcuts.  I'll think about it for a bit.
>
> I'd like to plumb at this up/down notion a bit.  Perhaps it's not clear, but 
> the ontology is not a hierarchy – there absolutely are cycles in its graph.  
> For example:
>
> http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure...
>
> Which way is "up" (or "down") from isa? here?
>
> > It doesn't appear to include any of the contrib libraries (I know
> > that's a mammoth task for 1.2.0). Do you plan to include the new
> > contrib libraries in 1.3.0 since they seem more "integrated" now?
>
> I hope that Clojure Atlas will include contrib libraries in the future, 
> though I can't imagine I'll be building the ontologies for them.  As you say, 
> 1.2.0 contrib is large, but "new contrib" is likely to get much, much larger 
> (presumably larger than the standard library) since contributing to it is far 
> easier than classic contrb.  I'm thinking about various ways to allow for 
> community-constructed ontologies for various libraries, including contrib of 
> all versions.
>
> - Chas

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

Re: Future of clojure.contrib.core/-?> macro

[pmbauer]

Ivan,
clojure/core use a different workflow than is typical for github
projects.
The github readme doesn't indicate, but you may find the process here:

http://clojure.org/contributing
http://clojure.org/patches

Cheers,
pm

On Apr 20, 1:44 am, Ivan Koblik  wrote:
> Hello Konrad,
>
> Git workflow is a little bit different. You don't really need commit rights
> to contribute. I found a rather nice explanation of Git workflow 
> here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow
>
> Hope it helps.
>
> Cheers,
> Ivan.
>
> On 19 April 2011 16:40, Konrad Hinsen  wrote:
>
>
>
> > On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
>
> > >> Concerning my own modules in old contrib, there are three that I use
> > myself and that I am planning to maintain, independently of where they will
> > end up:
> > >> - clojure.contrib.monads
> > >> - clojure.contrib.macro-utils
> > >> - clojure.contrib.generic
>
> > > There is an empty repos already waiting for your macro utils:
> >https://github.com/clojure/tools.macro
>
> > Great, thanks, I'll start with that one. Monads depend on it anyway. But I
> > need commit permissions, which I probably don't have, but I don't even know
> > how to find out without trying to do a commit. Can you please add me in the
> > right place? My github account is khinsen.
>
> > > I have put some suggested names for the other new projects at
> >http://dev.clojure.org/display/design/Contrib+Library+Names. Please review
> > and comment, either there or here on the list.
>
> > It seems that for now the top-level namespaces (well, next-to-top) are
> > - clojure.core
> > - clojure.data
> > - clojure.java
> > - clojure.tools
>
> > I would like to suggest a new one, clojure.control, for control structures.
> > This would be the natural home for monads, but also for parallelization
> > frameworks and even for threading macros. None of this really fits into
> > "data" or "tools".
>
> > If the goal is to keep the number of top-level namespaces as small as
> > possible, I'd even propose to put clojure.contrib.generic under that label.
> > Otherwise, I'd propose yet another namespace, clojure.interfaces, where the
> > various submodules of generic would find their home next to other protocols
> > and interfaces of general interest.
>
> > Konrad.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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

Re: Future of clojure.contrib.core/-?> macro

[pmbauer]

clojure/core use an alternative workflow to typical OSS on github, so
the eqqon link is not apropos.
The clojure github readme doesn't advertise the workflow, but you can
find it here:

http://clojure.org/contributing
http://clojure.org/patches

On Apr 20, 1:44 am, Ivan Koblik  wrote:
> Hello Konrad,
>
> Git workflow is a little bit different. You don't really need commit rights
> to contribute. I found a rather nice explanation of Git workflow 
> here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow
>
> Hope it helps.
>
> Cheers,
> Ivan.
>
> On 19 April 2011 16:40, Konrad Hinsen  wrote:
>
>
>
> > On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
>
> > >> Concerning my own modules in old contrib, there are three that I use
> > myself and that I am planning to maintain, independently of where they will
> > end up:
> > >> - clojure.contrib.monads
> > >> - clojure.contrib.macro-utils
> > >> - clojure.contrib.generic
>
> > > There is an empty repos already waiting for your macro utils:
> >https://github.com/clojure/tools.macro
>
> > Great, thanks, I'll start with that one. Monads depend on it anyway. But I
> > need commit permissions, which I probably don't have, but I don't even know
> > how to find out without trying to do a commit. Can you please add me in the
> > right place? My github account is khinsen.
>
> > > I have put some suggested names for the other new projects at
> >http://dev.clojure.org/display/design/Contrib+Library+Names. Please review
> > and comment, either there or here on the list.
>
> > It seems that for now the top-level namespaces (well, next-to-top) are
> > - clojure.core
> > - clojure.data
> > - clojure.java
> > - clojure.tools
>
> > I would like to suggest a new one, clojure.control, for control structures.
> > This would be the natural home for monads, but also for parallelization
> > frameworks and even for threading macros. None of this really fits into
> > "data" or "tools".
>
> > If the goal is to keep the number of top-level namespaces as small as
> > possible, I'd even propose to put clojure.contrib.generic under that label.
> > Otherwise, I'd propose yet another namespace, clojure.interfaces, where the
> > various submodules of generic would find their home next to other protocols
> > and interfaces of general interest.
>
> > Konrad.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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