Re: A generalization of iterate

[nchurch]

A, right.  Silly me.  This is something I have trouble remembering.  For 
some reason when you use regular concat, the error message is helpful 
(can't recur from non-tail position); with lazy-cat it shows a mismatch of 
argument numbers.

On Wednesday, September 23, 2015 at 2:10:47 PM UTC-7, Max Countryman wrote:
>
> Your problem with recur is because you can only recur from the tail 
> position. 
>
> On Sep 23, 2015, at 12:28, nchurch > 
> wrote:
>
> Yeah, it consumes stack just like the Clojurescript version of Iterate. 
>  I'm curious if anyone knows how to avoid this.  The Clojure version of 
> Iterate is Java; and for some reason 'recur' can't be used inside of 
> lazy-cat (not really documented, but apparently true). 
>
> On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>>
>> I wonder if something like this is a little easier to read?
>>
>> (defn generate
>>   ([f coll]
>>(generate f coll (reverse coll)))
>>   ([f coll args]
>>(let [next-val (apply f args)]
>>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
>> next-val))
>>
>> Where your Fibonacci example becomes:
>>
>> (take 100 (generate +’ [1 1]))
>>
>> As for your other questions, I can’t be of much help. But isn’t there 
>> nontrivial memory overhead to consider with this approach?
>>
>>
>> On Sep 22, 2015, at 18:19, nchurch  wrote:
>>
>> I was going through 4clojure (highly recommended!) and doing the 
>> Fibonacci exercise.  It occurred to me that the iterate function could be 
>> generalized in a reasonable way, so that the next value is generated by 
>> applying the function to the last N items so far, where N is the number of 
>> initial arguments beyond the function.  Thus:
>>
>> (generate inc 1) 
>>
>> works just like iterate, while
>>
>> (generate + 1 1)
>>
>> generates the Fibonacci sequence.
>>
>> Here's the code:
>>
>> (defn generate
>>   [f & more]
>>   (letfn [(recurse
>> [coll args]
>> (let [next-val (apply f args)]
>>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
>> next-val)]
>> (recurse more (reverse more
>>
>>
>> Code is also on Github <https://github.com/nchurch/generate>.
>>
>> I see this as part of a larger class of generalized sequence functions: for 
>> instance, extra arguments in a function given to *reduce* could refer to N 
>> arguments back in the sequence (might be useful, for instance, in smoothing 
>> a sequence of values using an average).
>>
>> Questions: is there an existing home for this kind of functionality?  And 
>> could the above code be improved?  (I just used the definition of *iterate* 
>> as a starting point.)
>>
>>
>>
>>
>> -- 
>> 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 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.

Re: A generalization of iterate

[nchurch]

Yeah, it consumes stack just like the Clojurescript version of Iterate. 
 I'm curious if anyone knows how to avoid this.  The Clojure version of 
Iterate is Java; and for some reason 'recur' can't be used inside of 
lazy-cat (not really documented, but apparently true). 

On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>
> I wonder if something like this is a little easier to read?
>
> (defn generate
>   ([f coll]
>(generate f coll (reverse coll)))
>   ([f coll args]
>(let [next-val (apply f args)]
>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
> next-val))
>
> Where your Fibonacci example becomes:
>
> (take 100 (generate +’ [1 1]))
>
> As for your other questions, I can’t be of much help. But isn’t there 
> nontrivial memory overhead to consider with this approach?
>
>
> On Sep 22, 2015, at 18:19, nchurch > 
> wrote:
>
> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
> exercise.  It occurred to me that the iterate function could be generalized 
> in a reasonable way, so that the next value is generated by applying the 
> function to the last N items so far, where N is the number of initial 
> arguments beyond the function.  Thus:
>
> (generate inc 1) 
>
> works just like iterate, while
>
> (generate + 1 1)
>
> generates the Fibonacci sequence.
>
> Here's the code:
>
> (defn generate
>   [f & more]
>   (letfn [(recurse
> [coll args]
> (let [next-val (apply f args)]
>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
> next-val)]
> (recurse more (reverse more
>
>
> Code is also on Github <https://github.com/nchurch/generate>.
>
> I see this as part of a larger class of generalized sequence functions: for 
> instance, extra arguments in a function given to *reduce* could refer to N 
> arguments back in the sequence (might be useful, for instance, in smoothing a 
> sequence of values using an average).
>
> Questions: is there an existing home for this kind of functionality?  And 
> could the above code be improved?  (I just used the definition of *iterate* 
> as a starting point.)
>
>
>
>
> -- 
> 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.

A generalization of iterate

[nchurch]

I was going through 4clojure (highly recommended!) and doing the Fibonacci 
exercise.  It occurred to me that the iterate function could be generalized 
in a reasonable way, so that the next value is generated by applying the 
function to the last N items so far, where N is the number of initial 
arguments beyond the function.  Thus:

(generate inc 1) 

works just like iterate, while

(generate + 1 1)

generates the Fibonacci sequence.

Here's the code:

(defn generate
  [f & more]
  (letfn [(recurse
[coll args]
(let [next-val (apply f args)]
  (lazy-cat coll (recurse [next-val] (conj (butlast args) 
next-val)]
(recurse more (reverse more


Code is also on Github <https://github.com/nchurch/generate>.

I see this as part of a larger class of generalized sequence functions: for 
instance, extra arguments in a function given to *reduce* could refer to N 
arguments back in the sequence (might be useful, for instance, in smoothing a 
sequence of values using an average).

Questions: is there an existing home for this kind of functionality?  And could 
the above code be improved?  (I just used the definition of *iterate* as a 
starting point.)



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

[nchurch]

Did you ever look into Hoplon/Javelin?  Haven't heard much about it on this 
group recently, and curious why

On Saturday, December 6, 2014 10:37:20 PM UTC-8, James MacAulay wrote:
>
> What prompted me to write Zelkova?
>
> The short answer is curiosity and gut feeling. The long answer:
>
> I consider core.async (and CSP in general) to be an excellent low-level 
> abstraction for coordinating concurrency, but I feel like it relies way too 
> much on mutating operations for me to want to use it much directly in 
> application code. Like any other mutating code, I want to push it to the 
> edges as much as possible. Along those lines, I had previously explored 
> using core.async with JS promises [1] and "async futures" [2].
>
> Promises and futures are great (pseudo-?)immutable constructs for 
> representing single "eventual values", but don't really help at all with 
> values that change over time. So I wanted to build an FRP library based on 
> core.async, which seemed like an obviously strong foundation for FRP that 
> was surprisingly under-explored as such. At first I made some initial stabs 
> at modelling a system after Bacon.js, which at the time I considered more 
> attractive than Elm's style of FRP. However, I was fighting too much with 
> core.async to make it work, and it just felt like the wrong direction.
>
> I decided to read Evan Czaplicki's 2012 thesis on Elm to understand that 
> different perspective better, and the more I understood it the more 
> compelling I found that approach. I had a very similar experience with the 
> paper as Eric Normand recently described [3], and that Concurrent ML code 
> was just begging to be ported to core.async :)
>
> The fact that Elm's signal graphs are static does present some challenges, 
> but it also brings real benefits (as Evan outlines well in his talk that I 
> linked in the original post). People are still figuring out how best to 
> structure larger applications in Elm, but I see a lot of potential. At its 
> best, Elm code is some of the clearest code I've seen, with almost zero 
> "baggage" (read: incidental complexity).
>
> Furthermore, Zelkova brings its own advantages by being embedded in and 
> implemented entirely in Clojure/ClojureScript. You can reach outside the 
> strictness of the signal graph whenever you need to, and continue using the 
> same nice language as when you're working "from within" a graph. Needless 
> to say, development in Clojure also helps immensely with implementing the 
> library itself.
>
> [1]: https://github.com/jamesmacaulay/cljs-promises
> [2]: 
> https://github.com/jamesmacaulay/async-tools/blob/master/test/cljx/jamesmacaulay/async_tools/core_test.cljx#L62-L82
> [3]: http://www.lispcast.com/elm-frp-clojure-core-async
>
> On Saturday, 6 December 2014 07:01:30 UTC-5, eric wrote:
>>
>> Hi,
>>
>> May I ask what prompted you to write this? A coding exercise or some 
>> real-world need? I'm asking because I've been keeping an eye on FRP for a 
>> while. From what I understand it's conceptually not ready for anything 
>> other than toy problems yet. Like Elm's restriction on static flow graphs. 
>> It's like programming without 1st class functions, you don't get very far.
>>
>> eric
>>
>> On Monday, October 20, 2014 11:56:45 AM UTC+11, James MacAulay wrote:
>>>
>>> I've just published an FRP library based on Elm[1]:
>>>
>>> https://github.com/jamesmacaulay/zelkova
>>>
>>> Here's what the app code looks like:
>>>
>>>
>>> https://github.com/jamesmacaulay/zelkova/blob/4b06c49678e11e3af7b1eda7a18929a512f7753d/examples/mario/src/mario/core.cljs#L118-L133
>>>
>>> Right now Zelkova includes ports of Elm's Signal, Mouse, Keyboard, and 
>>> Window libraries, plus part of its Time library[2]. Zelkova's signal 
>>> namespace works in both Clojure and ClojureScript, but the rest only have 
>>> implementations for ClojureScript in the browser.
>>>
>>> Elm-style FRP is a bit different from other flavours like those of Rx or 
>>> Bacon.js. In particular, Elm's signal graphs are static (can't be 
>>> reconfigured once they start running) and don't allow for 
>>> signals-of-signals.
>>>
>>> Zelkova is the same way, but its signal functions actually return 
>>> "recipes" for signals which don't start processing values until a "live" 
>>> graph gets spawned from one of them. This allows multiple live graphs to 
>>> run concurrently while sharing logical structure, and should make some 
>>> things easier in the future (like porting Elm's time-travelling debugger). 
>>> Theoretically this should also make it possible to compile some kinds of 
>>> signal graphs into transducers instead of running them as networks of 
>>> core.async channels.
>>>
>>> If you're interested in the differences and tradeoffs between the 
>>> different forms of FRP out there, Evan Czaplicki gave an excellent talk on 
>>> the subject at Strange Loop this year:
>>>
>>> https://www.youtube.com/watch?v=Agu6jipKfYw
>>>
>>> Cheers,
>>> James
>>>
>>> [1] http:/

Re: lazy sequence termination

[nchurch]

Could you include the code in client/get?  Not sure where that comes
from and it would be helpful to run the code to see what happensno
guarantees though =)

On May 28, 1:05 pm, Mond Ray  wrote:
> Quite a few views but no bites ... what have I done wrong in asking this
> question? If you can't help with the problem would you please take a moment
> to help me understand what has put you off?
>
> Too much code not enough data?
>
> Problem too complex to grasp with the supplied info?
>
> Too dull?
>
> Am I asking too much ... in other words I have got this far and I should be
> expected to know the answer (I really feel like I should too by the way!)
>
> Use of the term Clojurians?
>
> Something else?
>
> Thanks
>
> Ray
>
>
>
>
>
>
>
> On Tuesday, 28 May 2013 13:44:57 UTC+2, Mond Ray wrote:
>
> > Hi Clojurians,
>
> > I have a program which generates a lazy sequence to read ATOM feed chunks.
> > That part works OK but now I want to only take a limited number of the
> > chunks based on some predicate. My predicate is currently returning an
> > empty list so I think (hope!) I am missing something simple.
>
> > Here is an excerpt from the feed (yes the feed is in JSON and I have used
> > cheshire to map to Clojure data):
>
> > {:FEED_ID "5650f3ad-b793-42c6-9fef-80ba105f847d", :TITLE "Delta Feed",
> > :UPDATED "2013-05-28T11:15:34.860+02:00", :GENERATOR "Products", :LINK
> > {:REL "Self", :HREF "http://some-url"}, :PREVIOUS_LINK {:REL
> > "prev-archive", :HREF "http://another-url"}, .
>
> > Here is the sequence generator:
>
> > (defn fetch-atom-chunk
> >   "Returns an ATOM chunk from the feed-url"
> >   [feed-url]
> >   (:ATOM_FEED (:body (client/get feed-url {:as :json}
>
> > (defn fetch-atom-feed
> >   "Returns a list of ATOM chunks from the feed-url going back to the
> > from-date"
> >   ;  [feed-url from-date] (fetch-atom-feed feed-url from-date ())
> >   [feed-url]
> >   (let [chunk (fetch-atom-chunk feed-url)]
> >     (lazy-seq
> >       (cons chunk (fetch-atom-feed (:HREF (:PREVIOUS_LINK chunk)))
>
> > Here is the predicate:
>
> > (defn feed-date-to-clj-date
> >   "Patch for ATOM feed date formats like '2013-05-27T14:35:00.982+02:00'
> >    we have to remove the final ':' from the string to enable its
> > conversion"
> >   [feed-date]
> >   (.parse (java.text.SimpleDateFormat. "-MM-dd'T'HH:mm:ss.SSSZ")
> >     (str/replace feed-date #"(.*)(\d\d):(\d\d)" "$1$2$3")))
>
> > (defn after?
> >   "Returns true if first-date is after second-date"
> >   [first-date second-date]
> >   (> (.getTime first-date) (.getTime second-date)))
>
> > (defn more-feed-chunks-needed?
> >   "Look at the atom chunk and decide if we have enough"
> >   [from-date atom-chunk]
> >   (after? from-date (feed-date-to-clj-date (:UPDATED atom-chunk
>
> > And here is how I run it forever:
>
> > (fetch-atom-feed "https://producta.blah.com/feed/current";)
>
> > And here is how I run it with a predicate:
>
> > (def date-from (.parse (java.text.SimpleDateFormat. "-MM-dd")
> > "2013-05-27"))
> > (take-while #(more-feed-chunks-needed? date-from %) (fetch-atom-feed "
> >https://producta.blah.com/feed/current";))
>
> > Maybe this is too detailed for the group (do let me know) but otherwise I
> > would appreciate your advice / tips on what I could try.
>
> > Thanks
>
> > Ray

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

writing a multimap implementation: problems with transients, metadata

[nchurch]

So, inspired by this post on SO:

http://stackoverflow.com/questions/10942607/clojure-multi-maps

I've been trying to write some multimap functions, in a transient
version:

https://gist.github.com/anonymous/5660467

This was my first experience with transients, and it's been
problematic.  First problem: transients do not support or preserve
metadata, or so it seems.  I wanted my multimaps to function also as
regular maps until the multi- functionality is needed, so I needed a
way to distinguish "multi" entries from regular ones.  At first blush,
you'd just test to see if the entry is a set; but if you think about
it, you might want to make a regular map have set entries too.  No
problem, that's what metadata's for, right?  But of course this code
doesn't work:

(defn plural? [item]
  (get (meta item) :multi))

(defn pluralize! [item]
  (if (plural? item)
item
(transient (with-meta (set (list item)) {:multi true}

Since transients do not preserve metadata.

Is this an oversight in Clojure, or something that's intentionally
missing?  The following thread throws a little light on the matter but
is not conclusive (and I couldn't find anything more recent):

https://groups.google.com/group/clojure-dev/browse_thread/thread/acb8e6c1ace4613f/0bd110fd226fe547

In the meantime, how would I best accomplish what I am trying to do
with this use of metadata?

And here's still another issue:

(defn persist-all! [mmap]
  (let [persisted-map (persistent! mmap)
mkeys (keys persisted-map)]
(loop [item (first mkeys)
   restof (rest mkeys)
   wmap (transient persisted-map)]
...

You can see here that in order to get the keys from the transient
multimap, I have to persist it first (since you can't seq on
transients, and calling keys requires seq-ability); but then to
persist all the sets, I re-convert the persisted transient multimap to
a transient (since I'm about to do a bunch of changes on the multimap
at once, which would seem to be what transients are for in the first
place).  That seems redundant, but I haven't found any way around it:
I don't see how to get the keys otherwise, and once I've called
persist! I can't re-use the underlying transient.

I'm sure all these problems are eminently solvable by approaching the
problem in a different way; but I thought this was a good opportunity
to seed some discussion about using transients (and metadata).

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

[nchurch]

Thanks for the pointer; really helpful.  I'll have to watch that talk
by Chris Houser as that is what I will try to do (extend ISeq).

On May 12, 9:06 am, Konrad Scorciapino  wrote:
> It can only handle Object objects. Check 
> outhttp://stackoverflow.com/questions/16044897/why-cant-i-call-seq-funct...
>
> 2013/5/11 nchurch 
>
>
>
>
>
>
>
> > I'm trying to get a map out of a Goog events object (and also out of
> > Domina events objects).  Calling js->clj on either of these, even in
> > the most recent version of cljs, doesn't seem to do anything; it just
> > returns the inscrutable #<[object Object]> at the REPL.  (It doesn't
> > seem to produce maps outside the REPL either, since a console.log of a
> > lookup on the result of js->clj returns an unimplemented protocol
> > error.)
>
> > Is there a problem with js->clj, or is there perhaps a limitation on
> > what kinds of js objects it can handle?
>
> > Thanks,
>
> > Nick.
>
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visithttps://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.

js->clj not working

[nchurch]

I'm trying to get a map out of a Goog events object (and also out of
Domina events objects).  Calling js->clj on either of these, even in
the most recent version of cljs, doesn't seem to do anything; it just
returns the inscrutable #<[object Object]> at the REPL.  (It doesn't
seem to produce maps outside the REPL either, since a console.log of a
lookup on the result of js->clj returns an unimplemented protocol
error.)

Is there a problem with js->clj, or is there perhaps a limitation on
what kinds of js objects it can handle?

Thanks,

Nick.

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

Domina API: value vs. text

[nchurch]

I've been playing around with Domina; I'm curious why there are
different functions for getting the value of forms and of text nodes,
(value ) and (text ) respectively.  (I realize this comes from JQuery,
and I'm a comparative Web noob.)

I also noticed that the various set! functions operate on plural
nodes, whereas the "get" functions will only operate on a single
node.  This is a little surprising.

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

[nchurch]

Thanks Ryan!  This stuff is hugely helpful.

One other thing you might consider around design discussions: it would
be very useful to read XML both into clojure.xml-style structures and
also Hiccup-style structures (you already do it the other way in sexp-
as-element).  Hiccup is a lot more compact and readable, and if your
project uses both XML and HTML (which I imagine most would) it would
be nice to share the same abstraction.

David Santiago's Hickory project does this for HTML, but isn't
appropriate for XML.

-Nick.

On Oct 22, 7:07 pm, Ryan Senior  wrote:
> This is related to the (lack of) support for namespaces.  I removed the
> prefixes from the attributes below and it roundtripped fine for me.
>
> As far as I know, there is no work around for this kind of thing.  The fix
> is for data.xml to support namespaces.  I'll get some more design
> discussions going around namespaces this week.
>
> -Ryan
>
>
>
>
>
>
>
> On Mon, Oct 22, 2012 at 8:41 PM, nchurch  wrote:
> > Am I making a mistake, or is this a bug?
>
> > (use 'clojure.data.xml)
>
> > (def p (parse (reader "<../../>small.xml")))
>
> > where "small.xml" is
>
> > 
> > http://schemas.android.com/apk/res/android";
> >     android:keyWidth="10%p"
> >     android:horizontalGap="0px"
> >     android:verticalGap="0px"
> >     android:keyHeight="@dimen/key_height"
>
> > 
>
> > And happens to be taken from an Android UI-defining XML file.
>
> > But:
>
> > (emit-str p)
> > -->
> > XMLStreamException Prefix cannot be null
> > com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.writeAttribute
> > (XMLStreamWriterImpl.java:564)
>
> > If this has to do with the lack of namespace support, are there any
> > workarounds?
>
> > Thanks,
>
> > Nick.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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

roundtripping using data.xml?

[nchurch]

Am I making a mistake, or is this a bug?

(use 'clojure.data.xml)

(def p (parse (reader "<../../>small.xml")))

where "small.xml" is


http://schemas.android.com/apk/res/android";
android:keyWidth="10%p"
android:horizontalGap="0px"
android:verticalGap="0px"
android:keyHeight="@dimen/key_height"
>


And happens to be taken from an Android UI-defining XML file.

But:

(emit-str p)
-->
XMLStreamException Prefix cannot be null
com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.writeAttribute
(XMLStreamWriterImpl.java:564)

If this has to do with the lack of namespace support, are there any
workarounds?

Thanks,

Nick.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Hiccup -> HTML -> PNG

[nchurch]

Thank you gentlemen, I'm trying out PhantomJS and it looks good so
far; will let you know how the full project goes.

On Oct 17, 4:18 am, David Powell  wrote:
> I'm using PhantomJS 
> It is a headless WebKit build that can render webpages as png or pdf,
> amongst other stuff.  It isn't a java lib though - it is a command-line
> executable.
>
> Not HTML, but possibly useful, I also use Batik 
>  to render svg generated in clojure to
> png.
>
> --
> Dave

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

Hiccup -> HTML -> PNG

[nchurch]

Has anyone generated PNGs (or any image) from Hiccup in Clojure?  I
see an older Java library for this:

http://code.google.com/p/java-html2image/

Curious to hear about any experience with this library, or if there is
a better solution out there.

Thanks,

Nick.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 clojure-doc.org (aka CDS), a new community-driven Clojure documentation site

[nchurch]

Quick question: would it be possible to copy stuff from
dev.clojure.org?  I wrote some stuff over there, under the CA
agreement, but it's kind of a wiki format so it might be unclear who
'owns' it.

BTW, I noticed the front page of clojure.org got its headings cleaned
upthank you to whoever did that!  Really looks great.

On Oct 8, 9:26 am, Michael Klishin 
wrote:
> ## Announcing clojure-doc.org
>
> I am starting a new thread because the existing one about CDS is now
> polluted by all kinds of off-topics.
>
> About a week ago, John Gabrielle announced CDS (Clojure Documentation
> Site): a new Clojure documentation resource
> for the Clojure community by the Clojure community.
>
> We are past dealing with all the plumbing and happy to announce that our
> work is now public athttp://clojure-doc.organd
> you are welcome join the effort: we tried to make it as easy as possible.
>
> ## How It Works
>
> We have a repository on GitHub [1] that has Markdown files, toolchain setup
> instructions and several article
> stubs. The stubs help contributors pick a topic to write about and not
> worry too much about how to structure the document.
> They are training wheels for documentation writing, if you will.
>
> To contribute, for the repository [1], create a topic branch, make your
> changes and submit a pull request on GitHub. No
> contributor agreement process, no JIRA, no patches. Then an existing
> contributor will either merge your pull request or
> suggest changes.
>
> The toolchain currently requires Ruby *and* Python (for code highlighting).
> We decided that it's good enough for now.
> There are instructions about setting everything up in the README.
>
> There is no separate mailing list, so if you want to ask or suggest
> something, do it here.
>
> ## What We Have So Far
>
> Given that CDS is literally a few days old (after we migrated to the new
> toolchain and got to actual content), there is not
> much to show but a few tutorials and guides should give you an idea of what
> we want it to look like:
>
>  *http://clojure-doc.org/articles/tutorials/getting_started.html
>  *http://clojure-doc.org/articles/tutorials/introduction.html
>  *http://clojure-doc.org/articles/language/functions.html
>  *http://clojure-doc.org/articles/ecosystem/community.html
>  *http://clojure-doc.org/articles/ecosystem/libraries_directory.html
>
> ## What CDS Covers
>
> CDS' goal is to cover more than just the language. It is certainly
> cruicially important to have good tutorials and comprehensive
> guides on Clojure. But when using Clojure in real world projects, you will
> need to know about the JVM ecosystem, Leiningen,
> how to write tests, what libraries are out there, how to profile code, JVM
> tooling for ops, how to develop and distribute libraires,
> and much more.
>
> So there is group of articles about "the Ecosystem stuff": think Leiningen,
> popular libraries or how to use VisualVM to find
> hot spots and investigate concurrency hazards in your apps.
>
> This means that if you feel that documenting sequences is boring but
> excited about the ops side of software engineering, you
> can still contribute to CDS and enjoy the process.
>
> When documenting various tools, sometimes it makes more sense to just link
> to existing documentation, which is what we
> do for Leiningen.
>
> ## Low-hanging Fruits
>
> There are currently several articles that already have their structure in
> place, what is left is writing the content and code
> examples. For example, you don't have to be a genius or a Clojure expert to
> write articles such as
>
>  * Books
>  * Java interop
>  * Collections and Sequences
>  * Namespaces (ok, you *have* to be a genius to explain the ns macro well
> but some people certainly can do that)
>
> If you want to start working on one of those articles or have existing
> content you've authored that can be ported,
> please let us know.
>
> Topics like Concurrency & Parallelism and Laziness will take more effort,
> this is why we did not bother with writing any
> initial structure for their articles.
>
> ## Call to Arms
>
> If your company uses Clojure or has interest in adopting it and has "open
> source Fridays", "hacker time" or something
> similar, consider contributing to CDS. This will literally benefit the
> entire Clojure community, all the current and future users.
>
> Not only every single Clojure user benefits from better documentation, it
> also gets outdated way slower than that hot new open source
> library you wanted to tinker with. In other words, it's one of the best
> ways to invest of your OSS time budget (if you ask me).
>
> No contribution is too small: feel free to suggest grammar improvements,
> better code examples, submit pull requests with just
> one new paragraph or even a couple of spelling corrections. Editing and
> proof-reading is also a great way to contribute.
>
> If you have design and/or frontend development skills, you are more than
> welcome to make CDS more legible, e

Re: ANN: a Clojure docs site, and github organization

[nchurch]

> Just to keep in touch with our marvelous legal systems in North America, read 
> this:
...
> how much I am frustrated by this shattered world

Indeed!  The law is nothing but an overly complex, haphazardly
designed, historically encrufted programming language for morals.

Its compiler is frighteningly well-maintained, though.

On Oct 6, 6:24 pm, Softaddicts  wrote:
> It works for Oracle because they have the $$$ to support it. You just 
> confirmed
> that we are on the same wavelength, they have the weapons to nail anyone who
> would like to exercise exclusive rights on some contribution made under their 
> CA
> even if that individual lives in Kazakhstan.
>
> They have the infra structure and several offices in various
> Countries and continents to cover their ass.
>
> Just to keep in touch with our marvelous legal systems in North America, read 
> this:
>
> http://hrdailyadvisor.blr.com/archive/2010/08/20/Epinions_Employment_...
>
> The first question/answer is pretty instructive. It's easier to avoid the 
> whole issue
> with a piece of paper. Maybe in ten years things will have settled somehow.
> The above is dated from 2010 that's not far away.
>
> I will not anything else to this thread, the world is as it is. I you think 
> that you are
> frustrated, maybe we should have a drink together and I could explain how
> much I am frustrated by this shattered world
>
> Do you expect to drop at the Conj ?
>
> Luc
>
>
>
>
>
>
>
>
>
> > 2012/10/7 Softaddicts 
>
> > > The validity of a scanned signature or electronic keys is subject to
> > > interpretation
> > > and assessment on a per case basis especially in civil contracts by the
> > > diverse
> > > legal systems on Earth.
>
> > > It's not the Clojure community that is behind, it's the legal systems of
> > > many countries
> > > that did not follow the pace of technology. Some will not recognize
> > > scanned signatures
> > > at all.
>
> > > On the other hand, original hand written signatures are recognized almost
> > > every where.
>
> > A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many
> > lawyers as
> > Clojure/core, lawyers several times as experienced and about x10,000 times
> > as much experience with this stuff as a company. And it works for them.
>
> > > As much as you complain about the paper CA, you should complain about
> > > the legal systems of these countries that do not follow US and western
> > > Europe
> > > attempts to recognize technology changes and adapt to it.
>
> > > You analyze the issue by the wrong end
>
> > > It's not a technology issue, it's a legal one.
>
> > > You could have the best electronic authentication scheme, if it's not
> > > recognized by a country's legal system, it's useless in court in this
> > > country.
> > > If claims rights on contributions not backed by a CA in a valid form as
> > > defined in this
> > > country, it's a lost case.
>
> > > Big organizations have the tools and budgets to fight in various legal
> > > systems
> > > out there. Not small open source projects or projects without big 
> > > sponsors.
>
> > > I understand and approve the requirement of the original hand written
> > > signature in
> > > this context. That's a real life issue that cannot be dealt with by
> > > technology alone.
>
> > > If a national mail system is not able to get reliably an envelope to the 
> > > US
> > > within 4/5 weeks, I would be very concerned about the state of their legal
> > > system.
>
> > Sorry to break it to you, but legal systems outside of a few countries are
> > seriously
> > broken and it will take decades and many lives to fix this. And I assure
> > you, people who
> > live in those countries are just as concerned as you are, thanks for caring.
>
> > So the system is how it is. Clojure/core can
> > accept this unfortunate fact and find a way to accept CA submissions
> > electronically.
>
> > Or they can ignore all the complaints (again, not about the CA per se, but
> > how it is currently submitted) and lose many potential contributions.
>
> > Contributions from people who really want to make Clojure better, ready to
> > spend
> > many hours of their time contributing but were not lucky enough to be born
> > in the Wonderland called Canada, where the law rules and the sun shines (at
> > least 2 months of the year).
>
> > It always starts with contributing something small. Then something else
> > small.
> > Then something slightly more significant. And next thing you know, you are
> > a major
> > contributor. That's how it started for every single active OSS contributor
> > I know.
> > --
> > 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,

Re: ANN: core.logic Go solver

[nchurch]

Thanks David!  I'll try to fix that in the next few days.

On Oct 5, 5:57 am, David Nolen  wrote:
> On Fri, Oct 5, 2012 at 8:51 AM, nchurch  wrote:
> > Hmm!  Then I must have hit the limit for how many arguments I can put
> > in an arglist, there in fresh: (i.e. (fresh [~@positions]).  I had no
> > idea there \was a limit.  Can't see any way around that at the
> > moment.  I never dreamed I'd try to put > 256 arguments in a
> > function
>
> It's pretty easy to surmount. Remember fresh is just sugar over let:
>
> (fresh [x y]
>   ...)
>
> =>
>
> (let [x (lvar 'x)
>       y (lvar 'y)]
>   ...)
>
> You can construct lvars yourself and put them into a sequence and then pull
> them apart.
>
> (let [board (take 255 (make-seq-of-lvars))]
>   (all
>     ... goals ...))
>
> I don't have time to go into all the details but this blog post should give
> you some more guidance:http://dosync.posterous.com/friendlier-shorter
>
> Note that it's quite easy to mix the functional and logical style ;)
>
> 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: ANN: core.logic Go solver

[nchurch]

Hmm!  Then I must have hit the limit for how many arguments I can put
in an arglist, there in fresh: (i.e. (fresh [~@positions]).  I had no
idea there \was a limit.  Can't see any way around that at the
moment.  I never dreamed I'd try to put > 256 arguments in a
function

On Oct 5, 5:46 am, David Nolen  wrote:
> On Fri, Oct 5, 2012 at 8:42 AM, nchurch  wrote:
> > CompilerException java.lang.ClassFormatError: Too many arguments in
> > method signature in class file go/core
> > $eval2878$fn__2881$fn__2882$_inc__2883$fn__2884$_inc__2885$fn__2890,
> > compiling:(NO_SOURCE_PATH:1)
>
>  Yeah that's not core.logic related. You're creating an anonymous fn via
> the macro make-boards and generating too many fn arguments.
>
> 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: ANN: core.logic Go solver

[nchurch]

I realized what the latter issue is: I forgot to relationalize
"opposite".  It turns out not to matter when you're checking for
alive, but it does matter checking for dead for some reason.  See the
new push.

The board size limitation issue has a \very odd error message that
doesn't seem to come from core.logic:

CompilerException java.lang.ClassFormatError: Too many arguments in
method signature in class file go/core
$eval2878$fn__2881$fn__2882$_inc__2883$fn__2884$_inc__2885$fn__2890,
compiling:(NO_SOURCE_PATH:1)

On Oct 5, 5:15 am, David Nolen  wrote:
> On Fri, Oct 5, 2012 at 1:53 AM, nchurch  wrote:
> > Here's a Go solver
>
> > code:
> >https://github.com/nchurch/go/blob/master/src/go/core.clj
>
> > README:
> >https://github.com/nchurch/go
>
> Neat!
>
> > There are some issues that I'd like to get input on.  For one thing,
> > I've used mutual recursion (as the Wiki article on mutual recursion
> > says, Prolog depends on mutual recursion); I don't see any
> > straightforward and clean way to eliminate it (you can't just
> > trampoline).  Probably because of this, you can't generate boards
> > bigger than 15X15.
>
> I don't think mutual recursion itself should cause a problem. core.logic
> has a fancy trampoline built inside of it derived from miniKanren.
>
> Can't say much more about the later issue w/o examining the code more
> closely.
>
> Thanks for sharing this!
>
> 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

mapv-in or map-in?

[nchurch]

I ended up needing the following utility, modified from the Clojure
source:

(defn mapv-in
  "maps f over a nested vector structure"
  ([f coll]
(let [f #(if (coll? %)(mapv-in f %)(f %))]
 (-> (reduce (fn [v o] (conj! v (f o))) (transient []) coll)
 persistent!

I wrote just as much as I needed.  Has anyone else needed to map some
function over nested structures?  Is there some standard
implementation out there?

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

ANN: core.logic Go solver

[nchurch]

Here's a Go solver

code:
https://github.com/nchurch/go/blob/master/src/go/core.clj

README:
https://github.com/nchurch/go

It's a really fun use of core.logic: you can test for pieces being
alive or dead; you can also generate all the boards that make a given
piece alive or dead.  See the README.

There are some issues that I'd like to get input on.  For one thing,
I've used mutual recursion (as the Wiki article on mutual recursion
says, Prolog depends on mutual recursion); I don't see any
straightforward and clean way to eliminate it (you can't just
trampoline).  Probably because of this, you can't generate boards
bigger than 15X15.

Also, there's an interesting discrepancy between generating alive-for
boards and dead-for boards which I don't quite understand; in the case
of dead boards, the unification ends up outputting nil for any piece
that helps kill the piece in question.

OK, I have to stop now: Core.logic is terribly addictive.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Regarding Starting Clojure

[nchurch]

Thanks guys!  (And also to the other announcement.)

On Oct 4, 2:07 pm, Mayank Jain  wrote:
> On Fri, Oct 5, 2012 at 12:58 AM, Michael Fogus  wrote:
> > > Here's one approach: Make a github of the code and content that runs the
> > site. People fork and make pull requests.
>
> > You talked me into it.
>
> >https://github.com/fogus/www-readevalprintlove-org
>
> Awesome! So beautiful! I can just keep staring at it :)
>
> Can you share what all exactly do we need to add to this site for now?
> And how do you think we can go about it?
> 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
>
> --
> Regards,
> Mayank.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Regarding Starting Clojure

[nchurch]

Clojuredocs is already out there and quite good (though not modified
much as of late).  However, it doesn't show up very high on Google
(not even on the first page for "Clojure").  There's also Learn
Clojure, which has a clean design but hasn't been updated in a while
(and also doesn't seem to have a Github link, so unsure how to
contribute).

It would be nice to see Clojure.org itself have a contribution
process, not unlike Clojure itself.

On Oct 2, 3:46 am, Yakovlev Roman  wrote:
> You can make your site with many examples and good documentation and maybe
> it will be at first place at google if it will have great value.
>
> A lot of people here will agree with that. Site could be better place to
> get started ! but old site still there.
>
> As far as i know there is a company behind Scala called "TypeSafe" and they
> got tons of money recently to make the lanugage more popular and attractive
> to newbie users. So maybe we see good main site and good web frameworks
> around Scala ( lift and play).
> So maybe Clojure also need something like this. Though "Relevance" company
> supports clojure somehow but i guess not enough for now.
>
>
>
>
>
>
>
> On Tuesday, October 2, 2012 1:13:49 AM UTC+4, aboy021 wrote:
>
> > I decided to quickly compare the website experience of starting Clojure
> > and starting Scala.
>
> > I do a Google search for Clojure
> > I decide to try the first link, Clojure.org
> > There's some basic information. I follow the somewhat obscure link halfway
> > down the side, "Getting Started"
> > Ok, that looks promising, now I can get a REPL to interact with.
> > I follow the link to the Getting Started Documentation (
> >http://dev.clojure.org/display/doc/Getting+Started) (isn't that where I
> > already was?)
> > Still flailing a bit, I follow the link to Mark Volkmann's Tutorial.
> > This is the first chance I've had to see what Clojure actually looks like
> > and how to program in it.
>
> > In stark contrast, I try searching for Scala.
> > I get presented with an appealing, nicely laid out page with large links
> > to an introduction to the language and a page on getting started.
> > There are links in an easy to navigate menu with Information about the
> > language, documentation, code examples, Software, and Developer information.
>
> > Now, I'm no Scala developer, but at first glance it seems like I've found
> > a great touch stone that I can use to find out what's happening in the
> > language, how it looks, what it can do for me, and I can learn how to write
> > it.
>
> > Another thing that the scala-lang site has is Code Examples. Code examples
> > are a really nice way for you to get a taste of how a language can solve
> > common problems, and they can give you a real sense of the flavour of the
> > language.
>
> > A lot of the information for Clojure seems to be there, it's just not laid
> > out in an attractive easy to use format. Perhaps we could have a fundraiser
> > to pay for a web designer to make a nice modern website that contains the
> > information in an easier to digest and more centralised way
>
> > The getting started issue is an ongoing problem for Clojure. It's an issue
> > that keeps coming up in the surveys and on the mailing list. Other
> > languages are doing it really well, Scala is just a convenient example.
> > What does the Clojure community need to do to help support the creation of
> > something that is on par?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Regarding Starting Clojure

[nchurch]

I should clarify that the issue with Clojure.org isn't really \design,
per seit's the choice of what to present on what level.  Scala
gives you pointers for what you need to know, right away at the top:
About Scala, Documentation, Code Examples, Software, Scala
Developers.  Whereas Clojure has a sidebar taller that the average
screen; one of the subjects is:

Multimethods and
Hierarchies

Which doesn't \mean anything unless you already know multimethods
\well.

A lot of good material is on the site already; but it seems to have
been added incrementally without any big choices being made about how
to organize it.


On Oct 1, 11:20 pm, nchurch  wrote:
> To cite some concrete examples:
>
> "Datomic"
>
> 0 hits on Clojure.org
>
> "Clojurescript"
>
> 1 hit
>
> On Oct 1, 11:09 pm, nchurch  wrote:
>
>
>
>
>
>
>
> > I put together the Getting Started confluence page.  I'm sure it could
> > still be improved, but adding further to it won't really fix the
> > problems you've noticed, and that many other people have noted.  It's
> > still on a secondary site, and Confluence doesn't really give you a
> > lot of design optionsalso ordinary Clojure Contributors don't have
> > the ability to \delete existing pages, so new material will for now
> > just add clutter on the sidebar.
>
> > At least one respected Clojurian that I know of has offered to write a
> > new clojure.org site, but replacing or updating it has not been a
> > priority.
>
> > Brent is right that you can find what you need on Clojure.org without
> > it being "pretty", but the current (and now quite old) site sends new
> > users some messages we may not necessarily intend:
>
> > 1. People hoping merely to Get Something Done will be looking to a
> > streamlined site as evidence that they won't have to waste too much
> > time getting up and running with their work.  These users will note,
> > consciously or not, that the information they really need is one among
> > many choices buried on a link off the bottom of a page linked from the
> > \sixth subheading on the sidebar of the main site.  (Yes, Getting
> > Started apparently falls under 'Reference'which is itself
> > secondary to 'Swag'.)
>
> > 2. People looking to make a creative contribution will look for
> > evidence that what they have to offer is valued.  If that contribution
> > is tools for building well-designed websites, Clojure.org will not
> > give the impression that anyone in the community would care.  This
> > impression would be false, but you'd have to look quite a bit harder
> > to realize this.
>
> > Some people may not mind turning away new user #1; but turning away
> > new user #2 is unfortunate in any possible world.
>
> > If I wanted to give someone an elevator pitch for Clojure, I'd admit
> > that it is new and has some rough edges; but that it offers tremendous
> > flexibility, power, and concision; and that it is evolving into an
> > environment where an entire web application, from data all the way up
> > to presentation, can be written in the same carefully-designed
> > language and environment.
>
> > That's \huge, but it doesn't come across in Clojure.org at all.
>
> > On Oct 1, 2:13 pm, aboy021  wrote:
>
> > > I decided to quickly compare the website experience of starting Clojure 
> > > and
> > > starting Scala.
>
> > > I do a Google search for Clojure
> > > I decide to try the first link, Clojure.org
> > > There's some basic information. I follow the somewhat obscure link halfway
> > > down the side, "Getting Started"
> > > Ok, that looks promising, now I can get a REPL to interact with.
> > > I follow the link to the Getting Started Documentation
> > > (http://dev.clojure.org/display/doc/Getting+Started) (isn't that where I
> > > already was?)
> > > Still flailing a bit, I follow the link to Mark Volkmann's Tutorial.
> > > This is the first chance I've had to see what Clojure actually looks like
> > > and how to program in it.
>
> > > In stark contrast, I try searching for Scala.
> > > I get presented with an appealing, nicely laid out page with large links 
> > > to
> > > an introduction to the language and a page on getting started.
> > > There are links in an easy to navigate menu with Information about the
> > > language, documentation, code examples, Software, and Developer 
> > > information.
>
> > > Now, I

Re: Regarding Starting Clojure

[nchurch]

To cite some concrete examples:

"Datomic"

0 hits on Clojure.org

"Clojurescript"

1 hit

On Oct 1, 11:09 pm, nchurch  wrote:
> I put together the Getting Started confluence page.  I'm sure it could
> still be improved, but adding further to it won't really fix the
> problems you've noticed, and that many other people have noted.  It's
> still on a secondary site, and Confluence doesn't really give you a
> lot of design optionsalso ordinary Clojure Contributors don't have
> the ability to \delete existing pages, so new material will for now
> just add clutter on the sidebar.
>
> At least one respected Clojurian that I know of has offered to write a
> new clojure.org site, but replacing or updating it has not been a
> priority.
>
> Brent is right that you can find what you need on Clojure.org without
> it being "pretty", but the current (and now quite old) site sends new
> users some messages we may not necessarily intend:
>
> 1. People hoping merely to Get Something Done will be looking to a
> streamlined site as evidence that they won't have to waste too much
> time getting up and running with their work.  These users will note,
> consciously or not, that the information they really need is one among
> many choices buried on a link off the bottom of a page linked from the
> \sixth subheading on the sidebar of the main site.  (Yes, Getting
> Started apparently falls under 'Reference'which is itself
> secondary to 'Swag'.)
>
> 2. People looking to make a creative contribution will look for
> evidence that what they have to offer is valued.  If that contribution
> is tools for building well-designed websites, Clojure.org will not
> give the impression that anyone in the community would care.  This
> impression would be false, but you'd have to look quite a bit harder
> to realize this.
>
> Some people may not mind turning away new user #1; but turning away
> new user #2 is unfortunate in any possible world.
>
> If I wanted to give someone an elevator pitch for Clojure, I'd admit
> that it is new and has some rough edges; but that it offers tremendous
> flexibility, power, and concision; and that it is evolving into an
> environment where an entire web application, from data all the way up
> to presentation, can be written in the same carefully-designed
> language and environment.
>
> That's \huge, but it doesn't come across in Clojure.org at all.
>
> On Oct 1, 2:13 pm, aboy021  wrote:
>
>
>
>
>
>
>
> > I decided to quickly compare the website experience of starting Clojure and
> > starting Scala.
>
> > I do a Google search for Clojure
> > I decide to try the first link, Clojure.org
> > There's some basic information. I follow the somewhat obscure link halfway
> > down the side, "Getting Started"
> > Ok, that looks promising, now I can get a REPL to interact with.
> > I follow the link to the Getting Started Documentation
> > (http://dev.clojure.org/display/doc/Getting+Started) (isn't that where I
> > already was?)
> > Still flailing a bit, I follow the link to Mark Volkmann's Tutorial.
> > This is the first chance I've had to see what Clojure actually looks like
> > and how to program in it.
>
> > In stark contrast, I try searching for Scala.
> > I get presented with an appealing, nicely laid out page with large links to
> > an introduction to the language and a page on getting started.
> > There are links in an easy to navigate menu with Information about the
> > language, documentation, code examples, Software, and Developer information.
>
> > Now, I'm no Scala developer, but at first glance it seems like I've found a
> > great touch stone that I can use to find out what's happening in the
> > language, how it looks, what it can do for me, and I can learn how to write
> > it.
>
> > Another thing that the scala-lang site has is Code Examples. Code examples
> > are a really nice way for you to get a taste of how a language can solve
> > common problems, and they can give you a real sense of the flavour of the
> > language.
>
> > A lot of the information for Clojure seems to be there, it's just not laid
> > out in an attractive easy to use format. Perhaps we could have a fundraiser
> > to pay for a web designer to make a nice modern website that contains the
> > information in an easier to digest and more centralised way
>
> > The getting started issue is an ongoing problem for Clojure. It's an issue
> > that keeps coming up in the surveys and on the mailing list. Other
> > lan

Re: Regarding Starting Clojure

[nchurch]

I put together the Getting Started confluence page.  I'm sure it could
still be improved, but adding further to it won't really fix the
problems you've noticed, and that many other people have noted.  It's
still on a secondary site, and Confluence doesn't really give you a
lot of design optionsalso ordinary Clojure Contributors don't have
the ability to \delete existing pages, so new material will for now
just add clutter on the sidebar.

At least one respected Clojurian that I know of has offered to write a
new clojure.org site, but replacing or updating it has not been a
priority.

Brent is right that you can find what you need on Clojure.org without
it being "pretty", but the current (and now quite old) site sends new
users some messages we may not necessarily intend:

1. People hoping merely to Get Something Done will be looking to a
streamlined site as evidence that they won't have to waste too much
time getting up and running with their work.  These users will note,
consciously or not, that the information they really need is one among
many choices buried on a link off the bottom of a page linked from the
\sixth subheading on the sidebar of the main site.  (Yes, Getting
Started apparently falls under 'Reference'which is itself
secondary to 'Swag'.)

2. People looking to make a creative contribution will look for
evidence that what they have to offer is valued.  If that contribution
is tools for building well-designed websites, Clojure.org will not
give the impression that anyone in the community would care.  This
impression would be false, but you'd have to look quite a bit harder
to realize this.

Some people may not mind turning away new user #1; but turning away
new user #2 is unfortunate in any possible world.

If I wanted to give someone an elevator pitch for Clojure, I'd admit
that it is new and has some rough edges; but that it offers tremendous
flexibility, power, and concision; and that it is evolving into an
environment where an entire web application, from data all the way up
to presentation, can be written in the same carefully-designed
language and environment.

That's \huge, but it doesn't come across in Clojure.org at all.




On Oct 1, 2:13 pm, aboy021  wrote:
> I decided to quickly compare the website experience of starting Clojure and
> starting Scala.
>
> I do a Google search for Clojure
> I decide to try the first link, Clojure.org
> There's some basic information. I follow the somewhat obscure link halfway
> down the side, "Getting Started"
> Ok, that looks promising, now I can get a REPL to interact with.
> I follow the link to the Getting Started Documentation
> (http://dev.clojure.org/display/doc/Getting+Started) (isn't that where I
> already was?)
> Still flailing a bit, I follow the link to Mark Volkmann's Tutorial.
> This is the first chance I've had to see what Clojure actually looks like
> and how to program in it.
>
> In stark contrast, I try searching for Scala.
> I get presented with an appealing, nicely laid out page with large links to
> an introduction to the language and a page on getting started.
> There are links in an easy to navigate menu with Information about the
> language, documentation, code examples, Software, and Developer information.
>
> Now, I'm no Scala developer, but at first glance it seems like I've found a
> great touch stone that I can use to find out what's happening in the
> language, how it looks, what it can do for me, and I can learn how to write
> it.
>
> Another thing that the scala-lang site has is Code Examples. Code examples
> are a really nice way for you to get a taste of how a language can solve
> common problems, and they can give you a real sense of the flavour of the
> language.
>
> A lot of the information for Clojure seems to be there, it's just not laid
> out in an attractive easy to use format. Perhaps we could have a fundraiser
> to pay for a web designer to make a nice modern website that contains the
> information in an easier to digest and more centralised way
>
> The getting started issue is an ongoing problem for Clojure. It's an issue
> that keeps coming up in the surveys and on the mailing list. Other
> languages are doing it really well, Scala is just a convenient example.
> What does the Clojure community need to do to help support the creation of
> something that is on par?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Fund raiser for our projects

[nchurch]

It's worth pointing out that the tools Clojure is built on (chiefly
Java) are themselves the products of companies.  If Sun hadn't stayed
behind Java, we'd probably still be coding Java in a C ecosystem,
rather than Clojure in a Java ecosystem.

Sun of course was a huge companybut that doesn't stop anyone from
trying a Kickstarter for Clojure.  The model might be a bit like
Flash: sell a great development tool, and put it in the middle of a
curated, complete, and documented set of libraries.

A single, coherent environment for creating web apps all the way from
database to browser would be delightful (and unprecedented).



On Sep 5, 4:02 pm, Brian Marick  wrote:
> On Sep 5, 2012, at 12:15 PM, Simone Mosciatti wrote:
>
> > I would say raise money to help people improve their project (documentation 
> > is a very important part that).
>
> Many people who are good at writing code are not good at writing 
> documentation. Writing good explanations is hard, even if you have a knack 
> for it. It's not something J. Random Superprogrammer can just automatically 
> do by virtue of his enormous brain.
>
> If money is to be spent, it would be better spent on people other than the 
> developers, people who *don't* know the project (because the troubles they 
> have learning it will inform their documentation), are quick studies, and are 
> skilled explainers.
>
> -
> Brian Marick, Artisanal Labrador
> Contract programming in Ruby and Clojure
> Occasional consulting on Agile
> Writing /Functional Programming for the Object-Oriented 
> Programmer/:https://leanpub.com/fp-oo

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

getting started updates

[nchurch]

The Getting Started page hasn't been updated in a while; I've just
added some material (particularly about Clojurescript and additional
libraries like Seesaw and core.logic).  Any suggestions?

http://dev.clojure.org/display/doc/Getting+Started

In particular, does anyone know of good tutorials aside from Mark
Volkmann's?  This is a good resource, but it would be nice to have a
crash-course that gives people the key stuff only.  You can get pretty
far just knowing Lisp (non)-syntax, sequences/maps/vectors/sets, map/
filter/reduce, destructuring, atoms, and basic Java interop.

Has anyone noticed, by the way, that

http://clojure.org/books

is empty?  There's such a nice crop of books out there, it's a shame
not to be showing them.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: New release of Domina (now with reworked eventing)

[nchurch]

Looking forward to trying it out.  Has anyone used both Enfocus and
Domina?  Any comparisons on the usage and features of the two?  Also,
has anyone put either of these together with JQuery UI code?

On Apr 27, 7:47 am, Luke VanderHart  wrote:
> Some of you may already be aware of of Domina, a jQuery-inspired DOM
> manipulation library I've been working on. It's been out there for a while,
> but I just finished up a round of changes that I think bring it to a
> certain degree of completion for basic use (although there's definitely a
> lot of cool stuff that still remains to be added).
>
> Most notable is a new set of eventing functions; I hope they'll provide an
> easy-to-use, low-level foundation for building more complex data- and
> event-driven web applications.
>
> Please check it out:https://github.com/levand/domina/
>
> Feedback, pull request, etc. are welcome.
>
> Thanks!
>
> -Luke

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: a goal succeeding when given another goal succeeds for all elements in a list

[nchurch]

That makes a lot more sense with the variable names, thanks!  I think
I hadn't realized until this point that a goal is also a function.
Much to learn

On Apr 27, 2:53 am, Daniel Kwiecinski 
wrote:
> Ok, so the function (let's name it for-all)  is:
>
> (defn for-all
>   "A goal that succeeds if all goals succeeds."
>   [goal first-param list]
>   (fresh [head rest]
>    (conso head rest list)
>    (goal first-param head)
>    (for-all goal first-param rest)))
>
> it takes 3 parameters. 1. a goal, 2. first parameter to the goal 3. list of
> parameters which will be applied as a second one to the goal. The 'for-all'
> goal succeeds when goal 'goal' succeeds for all pairs:
> first-param a, first-param b, first-param c , where a, b, c,  are
> elements of 'list' list.
>
> Conso is a goal which takes 3 parameters. 1. an element, 2. list of
> elements, 3 list of elements. And succeeds when 3rd list is equal to 2nd
> list with prepended element (  L = H | R )
> In goal 'for-all' conso is used for destructuring a 'list' list and store
> its head and rest in fresh variables. For such obtained head we try to
> apply 'goal' goal AND continue recursively in the same fashion with the
> rest of the list.
>
> Kind Regards,
> Daniel Kwiecinski
> lambder.com
>
> On 26 April 2012 23:57, nchurch  wrote:
>
>
>
>
>
>
>
> > For the benefit of bystanders, could anyone explain why and how
> > Daniel's for-all function works?  (I've gotten to chapter 4 of TRS.)
>
> > On Apr 26, 2:04 pm, David Nolen  wrote:
> > > core.logic can remember previous results via tabling.
>
> > > As far as n-queens - that's a problem best left for constraint logic
> > > programming (CLP). core.logic doesn't have constraint programming
> > > facilities yet, but I've mentioned the desire to implement cKanren many
> > > times on this list.
>
> > > Haven't really considered how CLP and tabling could be combined in
> > > core.logic - but it's been done elsewhere.
>
> > > David
>
> > > On Thu, Apr 26, 2012 at 4:55 PM, Daniel Kwiecinski <
>
> > > daniel.kwiecin...@gmail.com> wrote:
> > > > So how would you tackle, lets say n-queen problem on m square board
> > (for
> > > > realy huge m) knowing that additional small set of chess pieces can be
> > > > added to the problem (let's say K K N N B) the new pieces attack
> > fraction
> > > > of the board potentially not taken by any queens so far. Some of prev
> > > > solutions would be no longer valid of course but for sure adding new
> > pieces
> > > > will not add new queen placements. It only limits it. Would be it
> > possible
> > > > to extend Clojure.logic to reuse prev results, or I should forget
> > about it
> > > > and restart search from scratch?
>
> > > > Daniel
> > > > On Apr 26, 2012 7:55 PM, "David Nolen"  wrote:
>
> > > >> On Thu, Apr 26, 2012 at 1:38 PM, Daniel Kwiecinski <
> > > >> daniel.kwiecin...@gmail.com> wrote:
>
> > > >>> Does it make sense at all to you.
>
> > > >> Makes sense, but sounds outside the scope of what core.logic currently
> > > >> does.
>
> > > >> 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
>
> > > >  --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Clojure" group.
> > > > To post to this group, send email to clojure@googlegroups.com
> > > > Note that posts from new members are moderated - please be patient with
> > > > your first post.
> > > > To unsubscribe from this group, send email to
> > > > clojure+unsubscr...@googlegroups.com
> > > > For more options, visit this group 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: a goal succeeding when given another goal succeeds for all elements in a list

[nchurch]

For the benefit of bystanders, could anyone explain why and how
Daniel's for-all function works?  (I've gotten to chapter 4 of TRS.)

On Apr 26, 2:04 pm, David Nolen  wrote:
> core.logic can remember previous results via tabling.
>
> As far as n-queens - that's a problem best left for constraint logic
> programming (CLP). core.logic doesn't have constraint programming
> facilities yet, but I've mentioned the desire to implement cKanren many
> times on this list.
>
> Haven't really considered how CLP and tabling could be combined in
> core.logic - but it's been done elsewhere.
>
> David
>
> On Thu, Apr 26, 2012 at 4:55 PM, Daniel Kwiecinski <
>
>
>
>
>
>
>
> daniel.kwiecin...@gmail.com> wrote:
> > So how would you tackle, lets say n-queen problem on m square board (for
> > realy huge m) knowing that additional small set of chess pieces can be
> > added to the problem (let's say K K N N B) the new pieces attack fraction
> > of the board potentially not taken by any queens so far. Some of prev
> > solutions would be no longer valid of course but for sure adding new pieces
> > will not add new queen placements. It only limits it. Would be it possible
> > to extend Clojure.logic to reuse prev results, or I should forget about it
> > and restart search from scratch?
>
> > Daniel
> > On Apr 26, 2012 7:55 PM, "David Nolen"  wrote:
>
> >> On Thu, Apr 26, 2012 at 1:38 PM, Daniel Kwiecinski <
> >> daniel.kwiecin...@gmail.com> wrote:
>
> >>> Does it make sense at all to you.
>
> >> Makes sense, but sounds outside the scope of what core.logic currently
> >> does.
>
> >> 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
>
> >  --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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

lein-cljsbuild on Windows?

[nchurch]

It sounds like lein deps is not getting all the dependencies (there
should be four files to .lein-plugins and one to lib); it must be a
windows-specific issue as I have no problem cloning the project on
Mac; and unfortunately I do not have access to Windows, so can't say
what the problem may be.  There may be a Windows issue with lein-
cljsbuild; see this thread:

http://groups.google.com/group/clojure/browse_thread/thread/52e41094d69f6577

I wonder if you could copy the dependencies manually.  Another thing
you could try is to intall lein-cljsbuild globally with lein plugin
install.

On Apr 26, 2:36 am, Guofeng Zhang  wrote:
> Trying ctest.
>
> if I clone the project then run " lein cljsbuild auto" in it, I got:
> Copying 3 files to D:\projects\app\clojure\contrib\ctest\.lein-plugins
> Compiling ClojureScript.
> Error: Could not find or load main class clojure.main
>
> If I run "lein deps", then run "lein cljsbuild auto", I got:
> That's not a task. Use "lein help" to list all tasks.
>
> Do I need extra configuration for my environment?
>
> Leiningen 1.7.1 on Java 1.7.0_03 Java HotSpot(TM) 64-Bit Server VM
>  Windows 7
>
> Thanks
>
>
>
>
>
>
>
> -Original Message-
> From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of 
> nchurch
> Sent: Thursday, April 26, 2012 12:49 PM
> To: Clojure
> Subject: Re: Having trouble running clojurescript repl
>
> BTW, I pushed a minimal lein-cljsbuild project with REPL here:
>
> https://github.com/nchurch/ctest
>
> On Apr 25, 9:30 pm, Sean Neilan  wrote:
> > Holy shnikes! That did it!
>
> > Thank you so much!
>
> > I'll submit a patch to the documentation.
>
> > On Wed, Apr 25, 2012 at 11:27 PM, David Nolen wrote:
>
> > > sounds like you didn't set CLOJURESCRIPT_HOME or that it was set
> > > incorrectly.
>
> > > On Wed, Apr 25, 2012 at 9:40 PM, Sean Neilan  wrote:
>
> > >> Hi All,
>
> > >> I'm not sure if this has been asked before.
>
> > >> I followed the quickstart guide:
> > >>https://github.com/clojure/clojurescript/wiki/Quick-Startanddid
>
> > >> git clone git://github.com/clojure/clojurescript.git
> > >> cd clojurescript
> > >> ./script/bootstrap
>
> > >> Then I tried
> > >> rmc-235-244:clojurescript seanneilan$ ./script/repl Clojure
> > >> 1.3.0-beta1 user=> which worked
>
> > >> But, when I did
> > >> user=> (require '[cljs.repl :as repl]) I got FileNotFoundException
> > >> Could not locate cljs/repl__init.class or cljs/repl.clj on
> > >> classpath:   clojure.lang.RT.load (RT.java:430)
>
> > >> I tried running
> > >> rmc-235-244:clojurescript seanneilan$ ./script/repljs
>
> > >> But I got
> > >> Exception in thread "main" java.lang.RuntimeException:
> > >> java.io.FileNotFoundException: Could not locate
> > >> cljs/repl__init.class or cljs/repl.clj on classpath:
> > >>  at clojure.lang.Util.runtimeException(Util.java:153)
> > >> at clojure.lang.Compiler.eval(Compiler.java:6417)
> > >>  at clojure.lang.Compiler.eval(Compiler.java:6372)
> > >> at clojure.core$eval.invoke(core.clj:2745)
> > >>  at clojure.main$eval_opt.invoke(main.clj:296)
> > >> at clojure.main$initialize.invoke(main.clj:315)
> > >>  at clojure.main$null_opt.invoke(main.clj:348)
> > >> at clojure.main$main.doInvoke(main.clj:426)
> > >>  at clojure.lang.RestFn.invoke(RestFn.java:421)
> > >> at clojure.lang.Var.invoke(Var.java:405)
> > >>  at clojure.lang.AFn.applyToHelper(AFn.java:163)
> > >> at clojure.lang.Var.applyTo(Var.java:518)
> > >>  at clojure.main.main(main.java:37) Caused by:
> > >> java.io.FileNotFoundException: Could not locate
> > >> cljs/repl__init.class or cljs/repl.clj on classpath:
> > >>  at clojure.lang.RT.load(RT.java:430) at
> > >> clojure.lang.RT.load(RT.java:398)
> > >>  at clojure.core$load$fn__4636.invoke(core.clj:5377)
> > >> at clojure.core$load.doInvoke(core.clj:5376)
> > >>  at clojure.lang.RestFn.invoke(RestFn.java:408)
> > >> at clojure.core$load_one.invoke(core.clj:5191)
> > >>  at clojure.core$load_lib.doInvoke(core.clj:5228)
> > >> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> > >>  at clojure.core$apply.invoke(core.clj:602)
> > >> at clojure.core$load_libs.doInvoke(core.clj:5262)
> > >>  at clojure.lang.RestFn

Re: Having trouble running clojurescript repl

[nchurch]

BTW, I pushed a minimal lein-cljsbuild project with REPL here:

https://github.com/nchurch/ctest

On Apr 25, 9:30 pm, Sean Neilan  wrote:
> Holy shnikes! That did it!
>
> Thank you so much!
>
> I'll submit a patch to the documentation.
>
> On Wed, Apr 25, 2012 at 11:27 PM, David Nolen wrote:
>
>
>
>
>
>
>
> > sounds like you didn't set CLOJURESCRIPT_HOME or that it was set
> > incorrectly.
>
> > On Wed, Apr 25, 2012 at 9:40 PM, Sean Neilan  wrote:
>
> >> Hi All,
>
> >> I'm not sure if this has been asked before.
>
> >> I followed the quickstart guide:
> >>https://github.com/clojure/clojurescript/wiki/Quick-Startand did
>
> >> git clone git://github.com/clojure/clojurescript.git
> >> cd clojurescript
> >> ./script/bootstrap
>
> >> Then I tried
> >> rmc-235-244:clojurescript seanneilan$ ./script/repl
> >> Clojure 1.3.0-beta1
> >> user=>
> >> which worked
>
> >> But, when I did
> >> user=> (require '[cljs.repl :as repl])
> >> I got
> >> FileNotFoundException Could not locate cljs/repl__init.class or
> >> cljs/repl.clj on classpath:   clojure.lang.RT.load (RT.java:430)
>
> >> I tried running
> >> rmc-235-244:clojurescript seanneilan$ ./script/repljs
>
> >> But I got
> >> Exception in thread "main" java.lang.RuntimeException:
> >> java.io.FileNotFoundException: Could not locate cljs/repl__init.class or
> >> cljs/repl.clj on classpath:
> >>  at clojure.lang.Util.runtimeException(Util.java:153)
> >> at clojure.lang.Compiler.eval(Compiler.java:6417)
> >>  at clojure.lang.Compiler.eval(Compiler.java:6372)
> >> at clojure.core$eval.invoke(core.clj:2745)
> >>  at clojure.main$eval_opt.invoke(main.clj:296)
> >> at clojure.main$initialize.invoke(main.clj:315)
> >>  at clojure.main$null_opt.invoke(main.clj:348)
> >> at clojure.main$main.doInvoke(main.clj:426)
> >>  at clojure.lang.RestFn.invoke(RestFn.java:421)
> >> at clojure.lang.Var.invoke(Var.java:405)
> >>  at clojure.lang.AFn.applyToHelper(AFn.java:163)
> >> at clojure.lang.Var.applyTo(Var.java:518)
> >>  at clojure.main.main(main.java:37)
> >> Caused by: java.io.FileNotFoundException: Could not locate
> >> cljs/repl__init.class or cljs/repl.clj on classpath:
> >>  at clojure.lang.RT.load(RT.java:430)
> >> at clojure.lang.RT.load(RT.java:398)
> >>  at clojure.core$load$fn__4636.invoke(core.clj:5377)
> >> at clojure.core$load.doInvoke(core.clj:5376)
> >>  at clojure.lang.RestFn.invoke(RestFn.java:408)
> >> at clojure.core$load_one.invoke(core.clj:5191)
> >>  at clojure.core$load_lib.doInvoke(core.clj:5228)
> >> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> >>  at clojure.core$apply.invoke(core.clj:602)
> >> at clojure.core$load_libs.doInvoke(core.clj:5262)
> >>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
> >> at clojure.core$apply.invoke(core.clj:602)
> >>  at clojure.core$require.doInvoke(core.clj:5343)
> >> at clojure.lang.RestFn.invoke(RestFn.java:408)
> >>  at user$eval1.invoke(NO_SOURCE_FILE:1)
> >> at clojure.lang.Compiler.eval(Compiler.java:6406)
> >>  ... 11 more
>
> >> I'm not sure what's going on. Thank you for your time!
>
> >> -Sean
> >> s...@seanneilan.com
>
> >>  --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/clojure?hl=en
>
> >  --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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: Having trouble running clojurescript repl

[nchurch]

Did you try using lein-cljsbuild (together with the instructions on
Using Clojurescript in a Web Page on Quick Start)?  That works fine
for me.  The instructions on the lein-cljsbuild REPL are here (repl
listen should be enough to get you going):

https://github.com/emezeske/lein-cljsbuild/blob/0.1.8/doc/REPL.md

On Apr 25, 6:40 pm, Sean Neilan  wrote:
> Hi All,
>
> I'm not sure if this has been asked before.
>
> I followed the quickstart 
> guide:https://github.com/clojure/clojurescript/wiki/Quick-Startand did
>
> git clone git://github.com/clojure/clojurescript.git
> cd clojurescript
> ./script/bootstrap
>
> Then I tried
> rmc-235-244:clojurescript seanneilan$ ./script/repl
> Clojure 1.3.0-beta1
> user=>
> which worked
>
> But, when I did
> user=> (require '[cljs.repl :as repl])
> I got
> FileNotFoundException Could not locate cljs/repl__init.class or
> cljs/repl.clj on classpath:   clojure.lang.RT.load (RT.java:430)
>
> I tried running
> rmc-235-244:clojurescript seanneilan$ ./script/repljs
>
> But I got
> Exception in thread "main" java.lang.RuntimeException:
> java.io.FileNotFoundException: Could not locate cljs/repl__init.class or
> cljs/repl.clj on classpath:
>  at clojure.lang.Util.runtimeException(Util.java:153)
> at clojure.lang.Compiler.eval(Compiler.java:6417)
>  at clojure.lang.Compiler.eval(Compiler.java:6372)
> at clojure.core$eval.invoke(core.clj:2745)
>  at clojure.main$eval_opt.invoke(main.clj:296)
> at clojure.main$initialize.invoke(main.clj:315)
>  at clojure.main$null_opt.invoke(main.clj:348)
> at clojure.main$main.doInvoke(main.clj:426)
>  at clojure.lang.RestFn.invoke(RestFn.java:421)
> at clojure.lang.Var.invoke(Var.java:405)
>  at clojure.lang.AFn.applyToHelper(AFn.java:163)
> at clojure.lang.Var.applyTo(Var.java:518)
>  at clojure.main.main(main.java:37)
> Caused by: java.io.FileNotFoundException: Could not locate
> cljs/repl__init.class or cljs/repl.clj on classpath:
>  at clojure.lang.RT.load(RT.java:430)
> at clojure.lang.RT.load(RT.java:398)
>  at clojure.core$load$fn__4636.invoke(core.clj:5377)
> at clojure.core$load.doInvoke(core.clj:5376)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5191)
>  at clojure.core$load_lib.doInvoke(core.clj:5228)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>  at clojure.core$apply.invoke(core.clj:602)
> at clojure.core$load_libs.doInvoke(core.clj:5262)
>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:602)
>  at clojure.core$require.doInvoke(core.clj:5343)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at user$eval1.invoke(NO_SOURCE_FILE:1)
> at clojure.lang.Compiler.eval(Compiler.java:6406)
>  ... 11 more
>
> I'm not sure what's going on. Thank you for your time!
>
> -Sean
> s...@seanneilan.com

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

Re: ClojureScript One in Eclipse

[nchurch]

> Note that the browser-connected REPL (at least, when run via 
> one.sample.repl/go) hoists itself up on top of the REPL you start via Run > 
> Clojure >Application, and assumes that it's in a console, and therefore 
> doesn't play well with the ccw REPL, assumes the opposite.

I assume this means the browser repl from cljs-template would not work
from ccw either?  (I tried it, and I get a continuous stream of EOF
errors scrolling by.)

Turcio, did you figure anything else out about your configuration of
One in ccw?

Thanks,

Nick.

On Feb 20, 7:05 am, Chas Emerick  wrote:
> Yes, I just cloned and started ClojureScript One usingccw.  I was able to get 
> the dev server up and running, and click around in all the tabs without any 
> exceptions.
>
> You didn't say whether you did this or not, but in addition to the 
> directories specified in :extra-classpath-dirs, you need to add the 
> :source-path, as well as all of the jars in lib/.
>
> Note that thebrowser-connectedREPL(at least, when run via one.sample.repl/go) 
> hoists itself up on top of theREPLyou start via Run > Clojure Application, 
> and assumes that it's in a console, and therefore doesn't play well with 
> theccwREPL, assumes the opposite.  Specifically, thebrowser-connectedREPLuses 
> stdin, one of the few places where "regular" REPLs outpaceREPLservers like 
> nREPL (whichccwuses) and swank.  For this reason, you can't use 
> thebrowser-connectedREPLfrom within SLIME either AFAIK.
>
> That shouldn't stop you from being able to useccwfor editing ClojureScript 
> files, managing the server side of things in accwREPL, etc.  You'd just need 
> to use lein for thebrowser-connectedREPL.
>
> Quality support for ClojureScript inccwwould probably require:
>
> 1. Finishing the leiningen integration (underway now, though we're targeting 
> Leiningen 2 to start, and perhaps backfilling Leiningen 1.x support depending 
> on various factors).
> 2. One of: adding an "inferior-clojure" mode so that 
> thebrowser-connectedREPLwill work sanely; or, figuring out how to support 
> thebrowser-connectedREPLwithin the scope of nREPL; or, something else I've 
> not thought of in the last 5 minutes. :-)
>
> Cheers,
>
> - Chas
>
> On Feb 19, 2012, at 5:28 PM, turcio wrote:
>
>
>
>
>
>
>
> > Actually, has anybody succeeded to run ClojureScript One from Eclipse?
>
> > Daniel
>
> > On Feb 17, 12:14 pm, turcio  wrote:
> >> Hi,
> >> I'm trying to run ClojureScript One usingCCWplugin in Eclipse. I
> >> created a new project and imported all the source code into it. Then I
> >> added folders to the build path that reflect the following
> >> configuration from project.clj:
>
> >> :git-dependencies [["https://github.com/clojure/clojurescript.git";
> >> "886d8dc81812962d30a741d6d05ce9d90975160f"]
> >>                      ["https://github.com/levand/domina.git";
> >> "8933b2d12c44832c9bfaecf457a1bc5db251a774"]]
> >>   :extra-classpath-dirs [".lein-git-deps/clojurescript/src/clj"
> >>                          ".lein-git-deps/clojurescript/src/cljs"
> >>                          ".lein-git-deps/domina/src/cljs"
> >>                          "src/app/cljs"
> >>                          "src/app/cljs-macros"
> >>                          "src/lib/clj"
> >>                          "src/lib/cljs"
> >>                          "templates"]
>
> >> I also executed "lein bootstrap" and added libraries to the build path
> >> in Eclipse.
>
> >> Now I'm running the app by right clicking on project folder, then Run
> >> as->Clojure application. InreplI execute: (in-ns 'one.sample.repl)
> >> (dev-server)). Thebrowsershows up the homepage, but when I click on
> >> Development tab the exception listed below occurs. Some files
> >> ClojureScript fiiles are generated but not all. Also empty "out"
> >> directory is created in the root folder.
>
> >> Any ideas?
>
> >> Thanks,
> >> Daniel
>
> >> ***
> >>  *
>
> >> 2012-02-17 12:06:17.393:WARN::/development
> >> java.lang.AssertionError: Assert failed: Can't recur here|frame
> >>         at cljs.compiler$fn__877.invoke(compiler.clj:762)
> >>         at clojure.lang.MultiFn.invoke(MultiFn.java:177)
> >>         at cljs.compiler$analyze_seq.invoke(compiler.clj:1033)
> >>         at cljs.compiler$analyze.invoke(compiler.clj:1086)
> >>         at cljs.compiler$analyze.invoke(compiler.clj:1079)
> >>         at cljs.compiler$fn__801.invoke(compiler.clj:606)
> >>         at clojure.lang.MultiFn.invoke(MultiFn.java:177)
> >>         at cljs.compiler$analyze_seq.invoke(compiler.clj:1033)
> >>         at cljs.compiler$analyze.invoke(compiler.clj:1086)
> >>         at cljs.compiler$analyze.invoke(compiler.clj:1079)
> >>         at cljs.compiler$parse_invoke$fn__1014.invoke(compiler.clj:979)
> >>         at clojure.core$map$fn__3811.invoke(core.clj:2432)
> >>         at clojure.lang.LazySeq.sval(LazySeq.java:42)
> >>         at clojure.lang.Lazy

Re: revisiting community funding?

[nchurch]

I like BernardH's idea of doing it anonymously; if nobody from Core
minds, we could set up an anonymous survey to see how much interest
there is.

cej38, your suggestions are very soundpersonally, I would love to
see curated, distilled APIs for common things a Clojure programmer
needs to do from Java or JavaScript, not just I/O.

However, it's ultimately a matter of what developers want to do, and
what core people think should be done.  So long as work leads to
improvement of the Clojure language and ecosystemwhich happens
continually anywayI don't think one should care where funds go.
In the long term, offering bounties for specific things might be a way
to spur fast progress of needed things, but I feel that should only be
tried after basic community funding works.

It seems like open source software development settles into a groove
that isn't Pareto efficient, even if it's much better than closed
source.  Think about how much time we all invest in learning and
developing Clojure.  The more the ecosystem expands, the more our
investments of learning and development come to be worth, and the less
likely we are to lose them to some other technology taking over down
the road.  And yet the ecosystem itself only gets worked on as a
second priority to other work.

It's a dilemma: either you get unsharable, secret technology worked on
full-time, or you get sharable technology part-time (with maintenance
dependent on the vicissitudes of life).  I'd like to think a generous
and not overly expectatious community can transcend it.


On Mar 23, 7:12 am, cej38  wrote:
> I am willing to contribute, and have in the past, but I think that
> instead of just contributing some cash and hoping things that we want
> will be worked on, I would propose that we structure it some.  In
> fact, I come up with a few projects that could be of use to the whole
> community, or at least a large subset of the community.  The clojure/
> core team could determine how much time that they think it will take
> to finish a project (or at least make real progress), and then have a
> fundraising goal for that project.  It would be kinda like we are
> hiring them to work on the projects that we want to see finished.
>
> A few ideas of topics:
> clojure-in-clojure
> a standard IO API that different VM implementations support
> Liebke's map/reduce
> fleshing out clojure.contrib libraries to bring them back to par with
> contrib 1.2 (a standard API page like what was had through
> clojure.contrib 1.2 would be REALLY awsome)
> faster numerics

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

revisiting community funding?

[nchurch]

There was a brief period of community funding for Rich's work back in
2010.  When that ended, we now know the result was Datomica huge
win.

But there are other people who work on Clojure and Clojurescript;
great things could happen from the focus that comes from being able to
work on them full time.  I know I'd be willing to give a couple
hundred to fund such an effort, and given how much people spend to go
to conferences, I'd be surprised if many others didn't feel the same
way.  And then there are now many companies that depend on Clojure.

I'm curious how Clojure/core would feel about this.  Is there still a
concern about creating "unreasonable expectations"?  Are there people
outside Clojure/core who would be willing to work on something?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: using Clojail dynamically

[nchurch]

Thank you both!  That works.

I'm not sure I understand why, though.  From the error message, you
would think it needs fewer steps of evaluation, not more.  Meanwhile,
if I do:

(defn non-sandbox [func inputs]
  (map (fn [inp] (eval `(~func ~inp))) inputs))

this has no problem taking a function.  But I also notice it works on
both quoted and unquoted forms.  So is this something I don't
understand about Clojure, not Clojail?

On Mar 9, 7:41 am, Alan Malloy  wrote:
> Indeed. Don't pass it the function +, pass it the symbol '+.
>
> On Mar 9, 1:20 am, "Meikel Brandmeyer (kotarak)" 
> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > without being too deep in clojail and the like...
>
> > Try quoting the func and input values to your function-sandbox function.
>
> > Sincerely
> > Meikel

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

using Clojail dynamically

[nchurch]

I've just been trying out Clojail, and ran into a difficulty.  Suppose
you make a sandbox:

(def sb (sandbox secure-tester))

and you want to dynamically assemble function calls to run inside the
sandbox.  Well, the sandbox takes a quoted expression, so you do
something like this:

(defn function-sandbox [func inputs]
  (map (fn [inp] (sb `(~func ~inp))) inputs))

and try:

(function-sandbox inc [1 2 3])

but:

RuntimeException EvalReader not allowed when *read-eval* is false.
clojure.lang.Util.runtimeException

Naturally, eval is disallowed by the sandbox.

All the examples in the docs show using the sandbox with a literal
quoted expression; how do you use it with expressions assembled at
runtime?

Thanks,

Nick.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Setting up Emacs to edit Clojure for Windows folks

[nchurch]

Cedric, you should append this to "The Unix-Hater's Handbook"I'm
not providing a link because I'm sure you already know it!

---Fellow Unix-hater, and Mac OS user (add flame suppressor here)

On Jan 25, 10:21 pm, Cedric Greevey  wrote:
> On Thu, Jan 26, 2012 at 12:25 AM, Sean Corfield  
> wrote:
> > On Wed, Jan 25, 2012 at 9:18 PM, Cedric Greevey  wrote:
> >> In other words, "ported software setup sucks!"? :)
>
> > That's not the conclusion I would have drawn... ;)
>
> >> Rather ironic, when the tendency, at least historically, has been for
> >> Windows (and Mac) to have superior usability when it comes to native
>
> > That depends on your point of view. I don't consider Windows
> > particularly usable - and I've used every version of it from 3.1 to
> > date... I'm sure we'll just agree to disagree on this one...
>
> I guess you're talking about a different kind of usability than I am.
>
> On the one hand, there's "it works properly and doesn't constantly
> crash". That's where Windows software has tended to be deficient (and,
> until recently, security).
>
> On the other hand, there's "setup for the typical configuration is
> point, click, reboot, done, and then you can sit down at it and use it
> with domain knowledge, general computer skills, and little else, and
> generally only need to consult some thick manual, or a cheat-sheet, or
> forums, or Wikipedia, or something when you're doing something unusual
> or advanced rather than common tasks such as cut, copy, and paste".
> That's where Unix software has tended to be deficient, often requiring
> complicated setup (though sometimes not) and almost always requiring a
> cheat-sheet, at least, to use it if you aren't a very regular,
> experienced user of the software. Frequently solution-space knowledge
> is even needed -- knowledge of compilers, terminology like "buffer",
> and so forth. Non-industry-standard bindings, mouse input semantics,
> selection and menu behavior (if there even are menus), and terminology
> abound in the typical case, up to and including various idiosyncratic
> neologisms specific to a single piece of software and not used by
> unrelated software with the same function (e.g. only emacs calls the
> clipboard or clipboards a "kill ring"; not only doesn't Notepad, nor
> does Editpad, Notepad++, vi, nano ...).
>
> Newer stuff, particularly designed for use with a package manager at
> install time and either Gnome or KDE, has tended to avoid these
> problems, though. Hence the "at least historically" above.
>
> Of course, this isn't limited purely to Unix. Before widespread
> networking and large market penetration of Windows PCs, idiosyncratic
> software and multiple attempts at standards proliferated on most
> platforms, excluding the Mac which came OOTB with a standard GUI
> toolkit. Old MS-DOS software is as guilty as vintage Unix software,
> with Wordstar and ancient versions of Lotus Notes (even for a while
> after it got a GUI!) being particularly infamous for requiring of
> users enormous feats of application-specific memorization and/or
> cheat-sheets.
>
> On the other hand, nobody uses those old pieces of MS-DOS software
> anymore. For some reason correspondingly old Unix software has a
> to-some-dismaying tendency to stay in use year after year. :)
>
> Actually, this may be a downside of open source. The likely reason is
> that the old MS-DOS software is proprietary, no longer maintained by
> the original developers, and in all likelihood no longer even exists
> as source, whereas the old Unix software is open source and people
> that got used to it stuck with it and even kept developing it
> themselves, so the software outlives generation after generation of
> hardware and is functionally immortal, but inertia keeps it full of
> legacy idiosyncrasies from before common idioms of computer
> interaction became standardized as a consequence of the computer
> becoming a common household tool rather than something only used at
> work, at school, and by geeks. So, open source seems to result in
> keeping old, pre-standardization things in use until the *users* die
> off rather than the hardware generation that begat it.
>
> On the positive side, nobody is forced at gunpoint to use any of it
> and standard-compliant alternatives that you can just sit at and use
> tend to exist in most cases. (Though a usable, FOSS alternative to the
> GIMP (GUI, of course, but *highly* idiosyncratic to anyone used to
> Photoshop) still seems strangely lacking ...)
>
> Mind you, it still can impinge on others from time to time. For
> example, by causing a not-insignificant fraction of mailing list
> traffic on some lists to consist of questions like "how do I make
> ancient ASCII-terminal-oriented piece of software Foo play nice with
> Unicode characters transmitted over the network?" and answers to same.
> :)

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

Re: ClojureScript One - Getting Started with ClojureScript

[nchurch]

Just wanted to add my thanks on this as well!  It looks beautiful

Nick.

On Jan 12, 11:46 am, Daniel Jomphe  wrote:
> Will we be able to read the account of the experience of translating the
> app from CoffeeScript to ClojureScript?
>
> And/or reading both code bases.
>
> Not sure if this account is covered 
> byhttps://github.com/brentonashworth/one/issues/22

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: accessing multiple return values

[nchurch]

> I think, I'll stop here.  You won't convince me that this approach is
> practicable anytime soon. ;-)

I certainly won't try too hard either.  I'm not questioning here
whether it is immediately practicable to implement (maybe not, and in
case a very long discussion) but is it potentially useful? (A shorter
discussion.)

In answer to your questions:

The name of a returned value, of course, \does become part of the
interface.  Perhaps library writers would want to have a discipline of
using their own internal names and then passing them out in one final
values call inside of a let.

As to the second: the recursive (bar ...) call has no effect on any
foo-values used outside of it, whether before or after.  This accords
with our expectation for how functions work.

Think of Values as a magical macro that \at \runtime reaches outside
of the function it was used in and writes a little let inside the
calling function's scope.  Is this possible?  I don't think so.
Presumably it would have to be part of the language, just like Values
is part of Common Lisp.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Understanding the quoting of a symbol in a list

[nchurch]

If I could hazard a guess, it has to do with symbol lookup in maps.
Try the following:

('foo {'foo 1})

('foo {'bloo 1} 4)

when you do ('foo 1), it can't find foo in 1 (because it isn't there,
and 1 isn't even a map), so it returns nil.  If you do ('foo 1 2),
you've just provided a default value, which it dutifully returns.

It's interesting that symbols don't care whether they are passed maps
or notfun fact!


On Jan 3, 2:47 pm, Bill Caputo  wrote:
> Hi All,
>
> So, I've been doing some experimentation in order to better understand
> the reader, and I can't figure out why I get the following results for
> these four calls:
>
> => ('foo)        ; ((quote foo))
> java.lang.IllegalArgumentException: Wrong number of args (0) passed
> to: Symbol (NO_SOURCE_FILE:0)
>
> => ('foo 1)     ; ((quote foo) 1)
> nil
>
> => ('foo 1 2)   ; ((quote foo) 1 2)
> 2
>
> => ('foo 1 2 3)
> java.lang.IllegalArgumentException: Wrong number of args (3) passed
> to: Symbol (NO_SOURCE_FILE:0)
>
> What I expected is that either foo would be invoked (and so I'd see an
> error because it didn't exist) *or* I'd get a list ala (foo 1 2)
>  - further, I can't understand why I get "nil" for an arity of 1 but
> "2" for an arity of two).
>
> Anyone have an explanation? I'm off to find the impl for "Symbol" and
> see if I can figure out how it is being invoked here...
>
> Thanks,
> Bill

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: accessing multiple return values

[nchurch]

You're quite correct that the namespace \mechanism as it stands would
not work for thisgood point.  I guess I am just suggesting using
the \syntax to do something let-like.  Perhaps it would be better to
make up a completely different syntax.

As for your example, I'm still not sure we understand each other:

(let [x (foo 17), dx foo/double-x]
(do-something-with x dx))

Yes, that is how it would \look (I've dropped the user. as it isn't
needed here).  But why is the \name user.foo/double-x changing?  It is
dictated in the definition of foo, which is not itself changing.  And
(keeping in mind what I said above) once you refer to the \value in
this way, it does not change.  Later uses of foo should indeed \shadow
this usage, not \change it.

At any rate, it would be better to describe these as names within a
function execution's \scope, not a function \namespace.  Hopefully
that is less confusing.

As for storing values: as I said they should be \function-local, so
that in

(defn bar [...]
   (foo ...)
   (+ foo/double-x ...)
)

foo/double-x expires after bar returns.


On Jan 3, 2:15 pm, Tassilo Horn  wrote:
> nchurch  writes:
> > Replying to Tassilo: I'm not quite sure I understand this problem:
>
> >> then changing its name requires changing all places where
> >> clojure.core.quotient/remainder is used
>
> > surely the call to Values takes place inside the function definition,
> > which happens \once.  If you want a different variable name on \use,
> > you use a let; if you want to return a different variable name on
> > \definition, you use a let inside the function (or perhaps Values
> > could have some sugar for renaming variables).
>
> I understand your proposal in such a way, that in a function
>
>   (defn foo [x]
>     (let [double-x (* 2 x)]
>       (values x double-x)))
>
> the `values' was actually a macro that
>
>   1. creates a namespace for the function (user.foo)
>
>   2. creates a var holding the last second value (user.foo/double-x)
>      where the name of the var is dictated by the local var holding the
>      value
>
>   3. expands into code that sets user.foo/double-x at runtime and then
>      returns the first value x
>
> Then, if I want to use the second value returned by foo in my code, I'd
> so something like
>
>   (let [x (foo 17), dx user.foo/double-x]
>     (do-something-with x dx))
>
> Since I have to refer to user.foo/double-x to get the second value, once
> that name changes, I have to change my code, too.
>
> But probably, I've simply misunderstood your intent.
>
> > It's true that quotient/remainder must be thread-local (in fact it
> > should really be function-local), but this makes it no different than
> > a let-variable or a function parameter; it doesn't necessarily mean it
> > is mutable.  Is X mutable in
>
> > (let [X 1
> >       X (inc X)])
>
> > ?
>
> Nope, the latter X shadows the former X.  But there's no such thing for
> vars in a namespace.
>
> > If you slapped that X in a data structure, you would not find it
> > changing under your nose.  quotient/remainder really has to behave in
> > the same wayimagine the quotient call creates an invisible let
> > every time.
>
> Sorry, I don't get you.  What am I misinterpreting in your approach?  To
> me, it looks like you want to bind the multiple values to vars in an
> ad-hoc namespace corresponding to a function.  Then, there's no such
> thing as a lexical scope provided by let.  A namespace is a globally
> accessible thingy.
>
> > Perhaps I should explain why I think this is "simple".  It's simple
> > because a) it allows you to ignore the extra values unless you want
> > them and
>
> Well, the Common Lisp approach does so, too.
>
> > b) it gives you ready-to-use names.  To my taste, b) is very
> > important.
>
> To me, that's a major downside.
>
> > (quotient 5 2)
> > (quotient 8 3)
>
> > quotient(5 2)/remainder  --> 1
>
> Huh, you want to create a namespace not only for each function but for
> each function call?  And then store the multiple values for each of
> them?
>
> Bye,
> Tassilo

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

Re: accessing multiple return values

[nchurch]

This is a really neat macro, but would people want to rewrite their
programs in continuation-passing style just to be able to return
multiple values sometimes?  (And a macro is not a first-class
entity.)  Of course, much of the time, the easiest thing to do \is to
return a vector or some other destructureable object.  But this
changes the interface: the function no longer directly returns a
singular value.  Metadata avoids this problem, but doesn't work on
numbers, among other things.  So there really are cases where having
multiple return values would help (when you want a function to give
you one value unless you want more)preferably without judo!
(altough judo is great too.)

Replying to Tassilo: I'm not quite sure I understand this problem:

> then changing its
> name requires changing all places where clojure.core.quotient/remainder is 
> used

surely the call to Values takes place inside the function definition,
which happens \once.  If you want a different variable name on \use,
you use a let; if you want to return a different variable name on
\definition, you use a let inside the function (or perhaps Values
could have some sugar for renaming variables).

It's true that quotient/remainder must be thread-local (in fact it
should really be function-local), but this makes it no different than
a let-variable or a function parameter; it doesn't necessarily mean it
is mutable.  Is X mutable in

(let [X 1
  X (inc X)])

?

If you slapped that X in a data structure, you would not find it
changing under your nose.  quotient/remainder really has to behave in
the same wayimagine the quotient call creates an invisible let
every time.

Perhaps I should explain why I think this is "simple".  It's simple
because a) it allows you to ignore the extra values unless you want
them and b) it gives you ready-to-use names.  To my taste, b) is very
important.  One of the reasons I dislike OOP is all the boilerplate
like

this.x = x.

But how many times do you have to write

(let [x (some-expensive function ... )]

just so you can use the returned value more than once?  What we would
do here is write

some-expensive-function/

the next time we want to use the value (assuming this is the notation
for getting the \default value)so in this case we don't even \care
about multiple return values.

If we think of this as a name-generating facility that happens to
handle multiple values, we could imagine extensions to it for
distinguishing more values

(quotient 5 2)
(quotient 8 3)

quotient(5 2)/remainder  --> 1

(rand(1) 12)
(rand(2) 12)

rand(1)(12)/

This is all rather fanciful, and admittedly a huge extension to the
language; but what's the harm in thinking about these things?

The next time you are telling your kids a bedtime story, you might
start as follows:

"A man ate some soup.  The man was bald, and the soup had an unhappy
grasshopper in it.  The grasshopper"

Scratch that: you should tell it as follows:

Let there be a man my-man, and some soup my-soup, and a grasshopper my-
grasshopper.  my-man ate some of my-soup.  my-man was bald.  my-soup
had my-grasshopper in it.  And my-grasshopper was unhappy

This makes for earlier bedtimes but worse storytelling.


On Jan 3, 12:36 am, Cedric Greevey  wrote:
> On Mon, Jan 2, 2012 at 2:16 PM, Tassilo Horn  wrote:
> > nchurch  writes:
>
> > Hi,
>
> >> Someone was asking on the list here about multiple return values,
> >> which Clojure does not have.
>
> >> If the facility were ever added, perhaps multiple values could be
> >> accessed via namespaces.  Functions would possess another level of
> >> namespace and have the ability to inject values into the environment
> >> under that namespace.  For instance:
>
> >> (defn quotient [x y]
> >>      .
> >>      (values quotient remainder))
>
> >> (clojure.core/quotient 5 2)
> >> --> 2
> >> clojure.core/quotient/remainder
> >> --> 1
>
> >> This seems simpler than the Common Lisp way.
>
> > I don't think so.  And there are several major problems with that
> > approach.  First of all, your clojure.core.quotient/remainder var needs
> > to be a mutable, thread-local var, because else you couldn't be sure
> > that 1 is the remainder of the quotient call directly above, or the
> > remainder of a call that happened a blink later in another thread (or
> > ForkJoinTask).
>
> > Another problem is that if the var name is determined by the name of the
> > local var in the function which is given to `values', then changing its
> > name requires changing all places where clojure.core.quotient/remainder
> > is used.
>
> On top of all that, how often is this needed anyway where
> destructuring o

accessing multiple return values

[nchurch]

Someone was asking on the list here about multiple return values,
which Clojure does not have.

If the facility were ever added, perhaps multiple values could be
accessed via namespaces.  Functions would possess another level of
namespace and have the ability to inject values into the environment
under that namespace.  For instance:

(defn quotient [x y]
 .
 (values quotient remainder))

(clojure.core/quotient 5 2)
--> 2
clojure.core/quotient/remainder
--> 1

This seems simpler than the Common Lisp way.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Lithub and Marginalia

[nchurch]

There is really one more Lithub concern (at least), and that is how to
structure entry points into a huge codebase like Clojurehow to
present simplifications and toy examples, etc., and walk the reader
through it.  I think the other two things are such big wins, though,
that this third concern can take a back seat.

On Dec 26, 12:13 pm, nchurch  wrote:
> > Like this?  http://brighterplanet.github.com/flight/impact_model.html
> > You can see how they handle it (from a Ruby-centric perspective) 
> > here:https://github.com/brighterplanet/numbers/blob/gh-pages/_posts/2010-1...
>
> (The original thread seems to have disappeared; it can be found 
> here:http://groups.google.com/group/clojure/browse_thread/thread/7f31a8e7a)
>
> This does seem to be a good way of doing a Lithub.  For that matter,
> there is the recent release of Clojure fs utils with Marginalia docs
> athttp://raynes.github.com/fs/
>
> I'd say this kind of thing needs really only two steps to be a full
> Lithub.  One, this should be the \main way of viewing code, i.e. in
> place ofhttps://github.com/Raynes/fs.  There does seem to be a
> certain amount of customization of Github possible from the
> Brighterplanet example, so maybe a Marginalia-centric Lithub within
> Github is possible.  Maybe it would even be possible to give three
> views of the same material: code and docs side-by-side, docs with
> links to code, and vice-versa.
>
> The second step is a matter of search-engine optimizationsomething
> I know very little about, I have to admit.  Look at this line in the
> fs utils Marginalia, for instance:
>
> Return the base name (final segment/file part) of a path.
>
> (defn base-name
>   [path]
>   (.getName (file path)))
>
> All the keywords you need to find that function are there; it even
> provides three alternatives!  If I were searching off the top of my
> head, I'd probably Google: return file part of path in Clojure.  But
> this returns a mess of links that don't really lead to that function;
> the Marginalia line doesn't even show up in the first few pages of
> results (granted, it's fairly new).
>
> Imagine if that kind of thing \were the first link, every time.
> Consider how much time people spend every day looking for library
> functionsany improvement in that process would be a big
> productivity and coding-flow gain.  Having independent HTML anchors
> for each function in a Marginalia page would be a startmuch
> simpler than convincing Google to rank specific functions first.  If
> the Google-whispering proves to be too difficult, the next best thing
> would be optimizing search within the Lithub sites, so that the top
> links are always to Clojure library functions and how to call them,
> without any distraction.

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

Lithub and Marginalia

[nchurch]

> Like this?  http://brighterplanet.github.com/flight/impact_model.html

> You can see how they handle it (from a Ruby-centric perspective) here: 
> https://github.com/brighterplanet/numbers/blob/gh-pages/_posts/2010-12-02-github-pages-rocco-and-rake-file-tasks.markdown

(The original thread seems to have disappeared; it can be found here:
http://groups.google.com/group/clojure/browse_thread/thread/7f31a8e7aa98a547/5562eb25b9d70365?lnk=gst&q=Lithub#5562eb25b9d70365.)

This does seem to be a good way of doing a Lithub.  For that matter,
there is the recent release of Clojure fs utils with Marginalia docs
at http://raynes.github.com/fs/

I'd say this kind of thing needs really only two steps to be a full
Lithub.  One, this should be the \main way of viewing code, i.e. in
place of https://github.com/Raynes/fs.  There does seem to be a
certain amount of customization of Github possible from the
Brighterplanet example, so maybe a Marginalia-centric Lithub within
Github is possible.  Maybe it would even be possible to give three
views of the same material: code and docs side-by-side, docs with
links to code, and vice-versa.

The second step is a matter of search-engine optimizationsomething
I know very little about, I have to admit.  Look at this line in the
fs utils Marginalia, for instance:

Return the base name (final segment/file part) of a path.

(defn base-name
  [path]
  (.getName (file path)))

All the keywords you need to find that function are there; it even
provides three alternatives!  If I were searching off the top of my
head, I'd probably Google: return file part of path in Clojure.  But
this returns a mess of links that don't really lead to that function;
the Marginalia line doesn't even show up in the first few pages of
results (granted, it's fairly new).

Imagine if that kind of thing \were the first link, every time.
Consider how much time people spend every day looking for library
functionsany improvement in that process would be a big
productivity and coding-flow gain.  Having independent HTML anchors
for each function in a Marginalia page would be a startmuch
simpler than convincing Google to rank specific functions first.  If
the Google-whispering proves to be too difficult, the next best thing
would be optimizing search within the Lithub sites, so that the top
links are always to Clojure library functions and how to call them,
without any distraction.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Literate programming

[nchurch]

While we're on the topic of a literate Github, let me just point out
that we might want to go just a little beyond Github to the way we
write code itself.  Look again at the capitalize-every-word function I
defined above.  In my original unshortened commentary, I included also
this:

.
To split a string into words (in the simplest case):
Split the string on a separator, the canonical one being space, but
also including punctuation characters such as ",';:./(){}-+_|\
BUT: Re-assembling the string will not reproduce the old string in
general unless space is the only character that splits.  In order to
preserve this simple abstraction, we would need to rewrite split and
assemble.  We could also change the string in-place.

Ossia: To split a string into words:
Split the string on space.  Use clojure.string/split.
.

You can see that I am writing here not only about the current good-
enough implementation, but a \future implementation, should it ever be
needed.  In fact, I discovered a bug in my code before I ever wrote
the code; but the question is what to do about the bug!

What I really want you to notice is how we are faced with a choice:
either we improve the library code (presumably by making split
optionally return an array of separators matched by the regex for
later reassembly by join, perhaps in metadata of some sort), or we go
with a less felicitous abstraction.  There probably should be some
sort of formal analogue to this decision point in the natural language
text.

What does this mean for a Github?  It may meanand no doubt this
will be controversialthat once we have the capability of a
function search engine, we don't really worry about there being
canonical library code any more.  If I face this particular problem,
maybe I decide to re-write Join and Split to my own specifications.  I
then put them out there under my own namespace, and when someone needs
to use them they just type (use '[nchurch :only join split]) wherever
they are in their file, or whatever the exact incantation is (this is
one place I always need to go to the docs).  They have no trouble
browsing multiple alternatives, because they can see at a glance how
each one differs.

Now we have possibly multiple joins and splits; and so the community
no longer has a standard!  Well, it would seem to me this fits well
with Github's always-fork philosophy.  I do think there is only one
way to write a good library function, but it may be that there will
need to be a proliferation of alternativeseach making its own
argument and tradeoffs across various levels of abstraction, to return
to the theme of literate programmingbefore an optimal basis is
discovered.  (There must have been a time before phillips head vs.
regular.)  And when that happens, perhaps it goes into
clojure.string (modulo legalities about contributor agreements
something that might also be handled at the Github level, by the
way.).








On Dec 22, 11:19 pm, nchurch  wrote:
> I'll do everything I can to help.  I have tons of thoughts (as you
> might guess); but I haven't demonstrated myself to be a great coder,
> yet.  I feel like I'm a coder who needs something like literate
> programming to be great, so it's kind of a chicken-and-egg problem.
> I'm already partway there with the existence of Clojure, but although
> it's the most intelligent language I've every come across (and it is
> at least Lisp), it still isn't enough.
>
> On Dec 22, 11:14 pm, daly  wrote:
>
>
>
>
>
>
>
> > On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> > > Firstly, there really needs to be something like a Github for literate
> > > programming.
>
> > What a great idea!
> > I'll see what I can do.
>
> > Tim Daly

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Literate programming

[nchurch]

I'll do everything I can to help.  I have tons of thoughts (as you
might guess); but I haven't demonstrated myself to be a great coder,
yet.  I feel like I'm a coder who needs something like literate
programming to be great, so it's kind of a chicken-and-egg problem.
I'm already partway there with the existence of Clojure, but although
it's the most intelligent language I've every come across (and it is
at least Lisp), it still isn't enough.

On Dec 22, 11:14 pm, daly  wrote:
> On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> > Firstly, there really needs to be something like a Github for literate
> > programming.
>
> What a great idea!
> I'll see what I can do.
>
> Tim Daly

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Literate programming

[nchurch]

Why should I write English in the first place?  Because it helps me to
think; and it helps me to "program" other people to think like me.
But I would never have learned English unless along the way it gave me
near-term results.  It should follow, then, that telling people to
write literate programs for the sake of posterity is never going to be
enough to change mindsets.  Taking an illiterate [sic] program and
making it literate as you are doing with Clojure will be a tour-de-
force, and an intimidating one at that.  I think that making literate
programming incrementally useful, however, is \inevitably going to
involve tooling.

Of two kinds, if you follow the logic above: social, and personal.
Firstly, there really needs to be something like a Github for literate
programming.  Why?  Because a literate program will be easier to
\understand, but also easier to \find (see example below).  Imagine a
sort of "function search engine"code liberated from namespaces and
leiningen projects, annotated and independently useable.  If there
were a community that actually \took \advantage of findability and
understandability, it would greatly speed coding (think of how much
time you have to spend hunting for documentation), and in the process
not only \promote literate programming but make it \advantageous.

On the personal side, writing English as part of coding has to be
maximally efficient for us humans: no retyping.  The identifiers we
use in English should flow into the code, and vice-versa.  Take the
following example:

To CAPITALIZE EVERY WORD in a STRING:
Split the STRING on SPACE into WORDS;
CAPITALIZE the first letter of every WORD, producing CAPITALIZED
WORDS.
Re-assemble[JOIN] the string on SPACE, to make the CAPITALIZED
STRING.

Using functions from clojure.string: split, join, capitalize; see
documentation:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html
http://clojure.org/other_functions
http://www.fatvat.co.uk/2009/01/regular-expressions-in-clojure.html
http://clojure.github.com/clojure/clojure.string-api.html

(defn capitalize-every-word [m-string]
  (let [m-space " "
regex-space #"\s"
words (split m-string regex-space)
capitalized-words (map capitalize words)
capitalized-string (join m-space capitalized-words)]
capitalized-string))

(defn c-e-w [m-string]
  (join " " (map capitalize (split m-string #"\s"

Now there is actually not that much novel text here, and typing it out
was an enlightening exercise (to really see how enlightening, you'd
have to see the full example; but I've omitted it because the
Internets are already complaining about a long post not written in
their native Twitterese).  But it was  very cumbersome and time-
consuming to do it.  This cumbersomeness was incidental: because my
activities were split among editing, browsing, and coding, for one
thing; and also (not a complaint, Rich!) because our programming
languages do not incorporate basic English concepts like abbreviation
and definition-in-place.

(One of the big advantages of writing English along with code is that
you come up with sensible identifiers.  Without English, it's a
puzzling exercise done completely out of context.)

You can't tell me this isn't a problem for IDE's to handle.  At a
minimum, I want my IDE to link up the identifiers between code and
English.  If they do, look at what happens: the identifiers get
enriched by natural language context (notice, for instance, how JOIN
gets associated with 'assemble'), and if we push everything to our
social tool, the code ends up with more paths to be located by.

We don't yet have Google-level findability for code, of course; but I
would argue that this is not a technological defect, it is simply a
failure of description!  Once we have literate code, Google will build
a function search engine for us.


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: core.logic and arithmetic equations?

[nchurch]

David:

Very good news.  This stuff is awesome as is, but still really excited
to see cKanren in all its optimized glory! Thanks for all your work on
it.

Nick.

On Dec 5, 4:13 pm, David Nolen  wrote:
> I'm a third (?) of the way through implementing cKanren which brings
> Constraint Logic Programming (CLP) to core.logic. It going a bit slower
> than expected since this is not a simple port - I'm making quite a few
> representation / efficiency changes. cKanren supports arithmetic w/
> integers, CLP(FD). It also supports CLP(Tree), which is constraint logic
> programming over tree terms (Clojure persistent data structures).
>
> Once cKanren is up and running it shouldn't be hard for someone to extend
> core.logic to handle reals - CLP(R).
>
> David
>
>
>
>
>
>
>
> On Mon, Dec 5, 2011 at 4:08 PM, nchurch  wrote:
> > I'm wondering if core.logic can be used to solve equations over reals
> > or rationals; all the examples I've seen are with with integers and
> > 'Oleg numbers'.  I'm talking about something like this:
>
> >http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.5
>
> > What spurred me was this week's unit of the Stanford AI class, where
> > you have to get multiple values out of an equation like X1 = x2* (f/
> > Z).  Seems like a case for relational programming, but it's not with
> > LVars!
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group 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

core.logic and arithmetic equations?

[nchurch]

I'm wondering if core.logic can be used to solve equations over reals
or rationals; all the examples I've seen are with with integers and
'Oleg numbers'.  I'm talking about something like this:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.5

What spurred me was this week's unit of the Stanford AI class, where
you have to get multiple values out of an equation like X1 = x2* (f/
Z).  Seems like a case for relational programming, but it's not with
LVars!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: REPL magic: get the previous expression?

[nchurch]

My particular use-case was to be able to write tests for things
entered at the REPL.  I'm almost done with a basic version of it and
will post it to the list when done.  It would be much easier if the
expressions were there anyway.  I guess the issue is that people may
not always be using Lein or Readline; they may be in Eclipse,
Netbeans, etc., which have their own REPLS.  Considering all that it
might make sense to just ask the user to launch a subrepl, which would
be both more robust and easier to implement.

I did look at lein.repl, thanks for the pointer!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: REPL magic: get the previous expression?

[nchurch]

I mean I want to write a utility that has access to the previous
expression entered at the REPL no matter where this utility is
called.  Since the up-arrow key has this access, it must be
possible

On Nov 9, 12:57 pm, Michael Beattie  wrote:
> What do you mean?  If it's programatically then why not use a loop or
> something?

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

REPL magic: get the previous expression?

[nchurch]

Does anyone know how to programmatically get the previous expression
entered at the REPL?  You can get it interactively by pressing the up-
arrow key; and of course you can get the previous \result through the
variable *1.  Is there any similar variable or function (perhaps in
Java-land) that would give you the previous \expression?

Thanks,

Nick.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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

[nchurch]

I have used Clojure in it for calculating some of the quiz/homework
answersit's been helpful.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Lazy behavior

[nchurch]

The problem you're having doesn't have anything to do with file
reads.  Every time you call (take 5 data), you're calling it on the
same item 'data'; your variable 'data' doesn't change between each
call.  The chief thing you have to understand about Clojure is that
variables never change.  Never.  If you want 'change' you need to use
refs, atoms, etc.

So for instance if you wrote

(let [x (iterate inc 1)]
   [(take 5 x) (take 5 x)])

you'd get

[(1 2 3 4 5) (1 2 3 4 5)]

You need to make the next call on the \rest of the sequence, which you
can get by calling (drop n data).  Then your processing function could
be something like

(loop [x data]
  (your-processing-function-here (take 5 x))
  (recur (drop 5 x)))

That will walk right through the sequence or the file or whatever you
have (if it's infinite, make sure to write a terminating condition,
e.g.:

(loop [x (iterate inc 1)]
  (print (take 5 x))
  (if (> (first x) 50) nil
(recur (drop 5 x
)



On Oct 31, 2:53 pm, Nicolas  wrote:
> Hi everybody!
>
> I'am experimenting with clojure and as an exercice I use the facebook
> puzzles (http://www.facebook.com/careers/puzzles.php?puzzle_id=20)
> Most puzzles require to read from a text file "efficiently". So I try
> to not read the full file at a time, but process it lazily.
>
> For that I made a very small helper library that try to benefit of
> lazy sequences:
>
> ;Pattern instances are immutables and thread safe
> (def split-pattern (java.util.regex.Pattern/compile "\\s"))
>
> (defn split-words [string]
>   "Split the provided string into words. Separators are space and
> tabs"
>   (if (nil? string)
>     nil
>     (vec (remove #(.equals % "") (.split split-pattern string)
>
> (defn read-text-file [file-name]
>    "Read a text file, line per line, lazily returning nil when end of
> file has been reached. Each line is a vector of words"
>    (let [reader (java.io.BufferedReader. (java.io.FileReader. file-
> name))]
>      (map split-words (repeatedly #(.readLine reader)
>
> (defn next-line [lines]
>   (first (take 1 lines)))
>
> So basically, a file is a lazy sequence of lines, and each line is a
> vector of words.
>
> Lazy behavior seems to be working at first, it I write:
>
>  (let [data (read-text-file "liars.txt")]
>   (take 5 data))
>
> -> (["5"] ["Stephen" "1"] ["Tommaso"] ["Tommaso" "1"] ["Galileo"])
>
> It correctly return the 5 first lines of my file. Perfect that's
> exactly what I want.
>
> But when really using it, it doesn't work. If I call several time the
> take function, it always return the first lines instead of providing
> the next ones:
>
> (let [data (read-text-file "liars.txt")]
>   [(take 5 data) (take 5 data)])
> =>[(["5"] ["Stephen" "1"] ["Tommaso"] ["Tommaso" "1"] ["Galileo"])
> (["5"] ["Stephen" "1"] ["Tommaso"] ["Tommaso" "1"] ["Galileo"])]
>
> If I call take 10 directly, it works as expected:
>
> (let [data (read-text-file "liars.txt")]
>   (take 10 data))
> =>(["5"] ["Stephen" "1"] ["Tommaso"] ["Tommaso" "1"] ["Galileo"]
> ["Isaac" "1"] ["Tommaso"] ["Galileo" "1"] ["Tommaso"] ["George" "2"])
>
> You would say, why not just take all data from the stream and then
> process it?
>
> Well the file has a specific format, first line contain some data,
> then few next line contain another data and so on. So I want to have a
> function that will read only a subpart of the file for example,
> another function another part and call them sequentially. But as shown
> in the simple previous example it simply doesn't work.
>
> My understanding is that some immutable thing is in the middle and it
> act like the data reference isn't changed between calls. That not what
> I want obviously as I'am getting data from a java stream, that is not
> supposed to be immutable.
>
> And how can I manage correctly this kind of cases? Efficiantly and
> idiomatically.
>
> Thanks in advance,
>
> Nicolas.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: easy sum of squares refactor question

[nchurch]

Glad I could help!  SICP is a wonderful book, and Clojure is a dream
come true in that it gives you a step from SICP into the real world.
Clojure would be just about perfect if it had general tail call
optimization and continuations, but I don't really miss those so far
(in any case they can't really be added until the JVM supports them).
And the seq abstraction and readable data structures are such a huge
plus I'd never go back to Scheme.  I remember getting frustrated with
those exact two deficiencies when using Scheme, and wanting to have a
language that fixed that; along came Clojure.  Clojure is also
constantly improving and getting more polished, and moving into more
and more fields of use.

On Oct 31, 10:06 am, Aquahappy  wrote:
> Thanks so much for your help!!! I'm so glad you had the time to
> respond to my newbie question.
>
> And as if you read my mind as I was going through the SICP lecture and
> referencing chapter two in Manning's Joy of Clojure book I was
> wondering how to turn this explicit recursive call taken from the
> scheme example into a Clojure non-tail recursion using 'recur'. I had
> been unsuccessful in my trials, so thank you times two!!!
>
> I'm off to try this out in my REPL!
>
> Many bows,
> Joshua
>
> On Oct 30, 11:29 pm, nchurch  wrote:
>
>
>
>
>
>
>
> > Another solution, this time using Clojure's tail recursion:
>
> > (defn sum2 [func incr a b]
> >   (loop [accum 0
> >          x a]
> >     (if (> x b)
> >       accum
> >       (recur (+ (func x) accum) (incr x)
>
> > This may be getting ahead of where you are now, so come back and look
> > when you've covered map, reduce, and tail recursion!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: easy sum of squares refactor question

[nchurch]

Another solution, this time using Clojure's tail recursion:

(defn sum2 [func incr a b]
  (loop [accum 0
 x a]
(if (> x b)
  accum
  (recur (+ (func x) accum) (incr x)

This may be getting ahead of where you are now, so come back and look
when you've covered map, reduce, and tail recursion!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: easy sum of squares refactor question

[nchurch]

All you have to do is abstract the function you want (by 'abstract' I
mean "put it in the argument list and replace the function with the
variable"):

(defn sum2 [func incr a b]
  (if (> a b)
0
(+ (fn a) (sum2 func incr (incr a) b


You wouldn't want to use this code in the real world since it involves
non-tail recursionsomething more idiomatic would be like this:

(defn sum3 [func incr a b]
  (if (> a b)
0
(reduce + (map func (take-while #(<= % b) (iterate incr a))

I admit this is not as elegant-looking; recursive functions are nearly
always more elegant!  Note I've used the short form for anonymous
functions; I could have written (fn[x] (<= x 3)) instead, but the
short form is preferable for inline functions.  (You need to rename
your function var to something other than 'fn', since that is a
Clojure keyword.)


On Oct 30, 6:48 pm, Aquahappy  wrote:
> Hi All,
>
> I'm watching Brian Harvey's SICP lecture #3 from Berkeley 61A/Spring
> 2011 and had a question about how I could refactor the following
> function so that the (+a 1) can be abstracted to be a function and
> passed in.
>
> Here is the original:
>
> (defn square  [x] (* x x))
>
> (defn sum [fn a b]
>   (if (> a b)
>     0
>     (+ (fn a) (sum fn (+ a 1) b
>
> => (sum square 2 4)
> 29
>
> That works. So then I want to replace (+ a 1) with a function like:
>
> (defn addone [a] (inc a))
>
> but I'm not sure how this would be structured.
>
> I'm new to clojure and realize this is a stepping stone to learning
> about higher order functions so apologies in advance for any code
> ugliness due to my newness to clojure.
>
> Thanks for your help!!!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Conj extracurricular activities spreadsheet

[nchurch]

This is not coding-related, but do we have any musicians in the
group?  I'm going to have a violin with me and would love to jam or
sight-read.  Maybe the Overtone guys would be interested in this?

If there's any interest I'll set up a doodle poll to see what
instruments people might play or have.

On Oct 25, 11:10 am, Roger Austin  wrote:
> One idea would be to organize something for people wanting to set up local
> clojure meetups. I don't think this needs to be a BOF, but I don't know the 
> best
> way to promote the idea.
>
> Anyone coming with family and/or spouse-dates? If so, let us locals know so
> we can suggest some local activities.
> --
> LinkedIn:http://www.linkedin.com/pub/roger-austin/8/a4/60
> Twitter:  http://twitter.com/RogerTheGeek
> Google+:  https://plus.google.com/117357905892731200369

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: clojinc: a Clojure tutorial in the form of an extended REPL session

[nchurch]

You clone it from github (git clone ) and run the
code one form at a time in core.clj; or, just copy the code in
core.clj from the code browser on github itself.

On Sep 7, 10:16 pm, Vincent  wrote:
> How to use this ?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: new Getting Started page

[nchurch]

> 2. Fun stuff to do with the basic repl
>     - some swing stuff
>         - copy and pastable code snippets
>     - some parallel stuff with futures or pmap or something
>     - something with the stm
>     - agents are cool, right?
>     - links to 4clojure and project euler

Kevin

I think having a minimal 'tour' like this would be good; do any of the
bloggers out there have anything that would be suitable?  Mark
Volkmann's page is pretty good, but it's comprehensive rather than
selective.  And try-clojure doesn't really go far enough in.

I've edited the page a little bit to make it less prescriptive towards
Clooj.

http://dev.clojure.org/display/doc/Getting+Started+for+Beginners

Note that if people are satisfied with java -cp etc., then they
already got those instructions on the clojure.org page.  I also put in
a little link to that in case people come from somewhere else.

I love command-line REPLs as much as the next person.  I use Python as
my calculator; just fire it up from any directory I happen to be in;
it does everything!  The problem is Clojure doesn't really \have
this.  From a select directory coming to a computer near you, java -cp
clojure.jar clojure.main (if you can remember to type that) doesn't
even give you command history (though if you want that, all you have
to do is follow the instructions at
http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started#Enhancing_Clojure_REPL_with_JLine,
simple!).

There seem to be a variety of options in various stages of completion
or abandonment for smoothing all this over (see
http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started#Additional_Installation_Options),
but should we recommend any of them as the first choice?  I'm not even
sure we should put up labrepl, because there are no instructions for
running it (not at least anything that would be useful to a
newcomer).

My final problem with introducing people to java -cp etc. is really an
aesthetic one: it makes it look like Clojure was released yesterday
and primarily consists of rough edges and incomplete functionality.
It's like Lily Tomlin's skit: We're the Phone Company, We Don't Care!
It often seems that programmers say to users: We're Programmers, We
Don't Care if you Understand!  (Fellow programmers are users too.)
What does java -cp really mean?  Perhaps you would like to type man
java and find out what those flags are, along with lots of others?
Why do you need to type both the jar file name and .main?  Care to
spend a half hour on the Java site looking for an explanation?  What
do you do when you want to run Clojure in your own project
directories?  You're either supposed to know this or be prepared to
dive around the Net and find out.

The fact is, knowledge of Clojure has nothing to do with all these
implementation details, but these unexplained things are the first
thing a new Clojure user sees.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: new Getting Started page

[nchurch]

Jonathan---

I think some of your criticisms of Clooj are valid, as Lee has said;
my question is not whether Clooj is perfect or even good, my question
is if there is a better option for an outright newcomer.  An outright
newcomer may not be so worried about adding jars, or used to existing
REPL behavior; an outright newcomer cannot be assumed to know anything
about running java at the command line (and having to run Clojure from
the directory where it is installed seems pretty ad-hoc and unclean
anyhow).  Finally, when it does come time to add jars, he should be
looking at Lein, as I suggested.

(One thing this reminds me of is that especially in the post-Lion era,
we should remind users to intall java if they have not already done
so.)

The suggestion to make Clooj the starting point actually came about
from the group, as you can see in the thread below:

http://groups.google.com/group/clojure/browse_thread/thread/5c4c36afcd73b24e/a8e3b4c6ac7b20a0?lnk=gst&q=clooj#a8e3b4c6ac7b20a0

In any case, aside from Clooj, do you have any other issues with my
proposed Getting Started page, or do you think the current Getting
Started page is better?

(It's worth pointing out that the java -cp command is already on
clojure.org, so I'm not sure if we need to repeat it on dev.clojure.)

Thanks,

Nick.

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

new Getting Started page

[nchurch]

There was some discussion about the Getting Started page last night at
the Bay Area meetup.  I've put together an (I think) improved version
at

http://dev.clojure.org/display/doc/Getting+Started+for+Beginners

Any suggestions/additions/deletions?  If this overall looks good, may
I replace the current page at

http://dev.clojure.org/display/doc/Getting+Started

with this one?  I'd put the current page under "other options",
because it gives a lot of choices.

My hope was to give a relatively clean path for beginners (who are the
audience for Getting Started), instead of just throwing everything
there is at them without comment.  Someone who has been around Clojure
for a while knows that Lein is much more standard than Gradle, but to
a reader of the current Getting Started page they look the same.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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

[nchurch]

> But my question is : is it ready yet ?

As a quick and simple way to get a REPL and edit code it seems to work
fine.  I added a sentence about its newness just so people would be
aware of it...if the author prefers no tutorial so far, then of course
it should be taken down.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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

[nchurch]

Here's a tutorial on getting started with Clooj:

http://dev.clojure.org/display/doc/getting+started+with+Clooj

If this looks good to people, I'll try to get permission to reorganize
the Getting Started docs a little.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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?

[nchurch]

> nchurch, I arrest you, try you, and find you guilty of the heinous
> charge of top-posting, thou knave, thou scum, thou waster of
> bandwidth!

I confess that I have erred and strayed from thy ways like a lost
sheep

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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?

[nchurch]

+1 to writing an etiquette document.  I have to confess I wrote a long
post a few weeks ago without realizing these sorts of posts belonged
on blogs (it was, oddly enough, another James Keats thread, on the
subject of Steve Yegge.  I figured if \Yegge writes long blogs).
I didn't intend to ruffle any feathers there, but my opinion that some
things were not being given enough priority was taken as disrespecting
people's efforts so far.  But there seems to be some more attention to
documentation now and the newbie experience, so I'm happy (and trying
to help) = )

Ken was helpful to me then when he pointed out that my post was simply
too long.  I suspect this was much more useful to the forum than
someone partly reading the post and responding out of context.
Similarly, writing (hopefully gentle) admonishments about etiquette
might help steer things in the right direction.  If someone simply
responded with a few lines to this particular thread: "This is not the
kind of discussion this forum is for; it is also too late in the
process to be a constructive criticism", there might have been more
light and less heat.

Furthermore, if people want to offer etiquette pointers on the tone
and framing of a particular post, why not simply use the "reply to
author" link?  There's a quote from the New Testament that I can't
quite rememberwait.thank you Google: "If thy brother shall
trespass against thee, go and tell him his fault between thee and him
alone."

(I note, however, that this was presumably written before Facebook,
which makes privacy sound almost as quaint as King James and
Shakespeare.)

As for the subsequent part about "And if he neglect to hear the
cljurch, let him be as an troll to you" ((this is from the New
Internet Version)), I guess that would be equivalent to simply
ignoring him.

(If it said: "then ANN thou out upon him and the list that he be an
troll"we would have a horse of a different color.)

On Jul 25, 10:21 am, Colin Yates  wrote:
> +1 - I think an etiquette document needs to be written.
>
> On 25 July 2011 15:10, Steve  wrote:
>
>
>
>
>
>
>
> > On Jul 25, 7:54 pm, James Keats  wrote:
>
> > > Best regards; love you, man, and sorry again for any misunderstanding
> > > or unintended miscommunication.
>
> > My humble suggestion is when you find yourself in your 5th or 6th
> > paragraph of an opinion piece there's a reasonable chance what you're
> > writing belongs on your blog rather than here.
>
> > - 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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

[nchurch]

> How about making the main suggestion be clooj instead, with emacs,
> eclipse, netbeans in the list of alternative options? :)

Sounds like consensus around Clooj.  Released on July 18th, top option
on July 25th!  Things move at lightspeed around here

The one thing I want to say about Emacs is that at some point we might
want to tell newcomers that it is as close to a standard dev
environment for experienced Clojure programmers as there is (along
with all the necessary warnings about its difficulties).  I've been
using Emacs for such a long time I've forgotten how horrible it can be
thoughhence my apparent missrec...

(If Aquamacs consistently worked with Clojure, Emacs would not be as
bad of a problem on Mac at least.  Some people do seem to get it
workingRich Hickey, for instance.  But I trust he has better
things to do with his time than write Getting Started guides for
Aquamacs.)

I just found out that I don't have permission on dev.clojure to move
pages (which would be needed to reorganize docs obviously).  Does
anyone around here have that permission and want to do it, or shall I
go about and try to get the permission?  Maybe someone with more
experience and having been on dev.clojure longer would be preferred,
but I feel pretty confident I can do \this at least = )

Other than not recommending Emacs, do people think that the overall
organization I suggested is a good idea?  I should reiterate that
other information needs to be accessible; for now I'd just like to see
us not presenting people with twelve options as their first view of
Getting Started, all in link form (after at least two clickthroughs
from clojure.org, typically).  Of course people are capable of
digesting the information in the current form, but it takes more time
and mindshareand why should it?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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

[nchurch]

> The community getting started page could be much better. In particular, 
> people have opined that there should be a clear, no-choices-
> to-make path "For Newbies" section.Help welcome!

I just got edit privileges on dev.clojure and am eager work on it.
How do people want to see Getting Started on dev.clojure organized?
Right now there are 12 (!) headings right under Getting Started.  How
about reducing it to four:

1) Getting Clojure
2) Editing Clojure
3) Using Clojure
4) Tools

This is the order in which newcomers need to do things.

Under 1) would be a guide for setting up Lein with the Lein REPL.  At
the end would be a list of links for alternative options.
Under 2) would be a guide for setting up Emacs (immediately divided
into Mac, Windows, Linux).  At the end would be a list of alternative
options: Eclipse, Netbeans, IntelliJ, etc.
Under 3), guides to setting up web programming (+ ClojureScript now?),
Incanter, and any other killer apps---but not an infinite list by any
means.  Less common applications again would be relegated to links
(which may link within dev.clojure of course).
Under 4), anything that doesn't fit under the first three: build tools
and debuggers with a standard option for each, and once again
alternative choices at the end.  (Lein has of course already been
covered.)

The basic idea is to make some choices, and tuck all the extra
information out of the top level.  Perhaps there could also be a link
at the top for an index to everything, as well.

If we really wanted to be radically open, we could include with each
option some of the data from the recent State of Clojure survey,
describing what proportion of the community actually use the option in
question.  This is exactly the kind of thing newcomers want to know,
and have trouble finding.  Perhaps it is impolitic to be so open about
it, but

I don't know how complicated this would be to do, but is there any way
to make a kind of community scratch space for the documentation?  It
would be nice to try out and work on reorganized and rewritten
documentation before it is linked to directly from clojure.org.  Just
a thought.

N.

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