Re: Migrating nREPL out of Clojure Contrib

[Dan Larkin]

And I helped! ... cue shake n bake commercial

> On Jul 18, 2017, at 11:02, Chas Emerick <c...@cemerick.com> wrote:
> 
> To be clear ("well ACTUALLY" :-P), development hasn't ceased, just
> slowed to a trickle. (There are commits this year, so there?) Part of
> that is nREPL being intentionally a slow-moving bit of bedrock for other
> people to build on. That's not to discount my original stipulations (1)
> and (2) ofc.
> 
> Forking is obviously easiest. Like I said, anyone can do that anytime.
> 
> The benefit to rebooting is to shake off whatever responsibilities or
> constraints are associated with the (eventually prior) copyright
> assignment. What happens to a codebase that is subject to a CA that is
> forked elsewhere? Are future contributions subject to that CA? I assume
> not, but IANAL. Does the "Copyright (c) Rich Hickey" banner that's
> supposed to be on all files stay there permanently? Pretty sure, but
> IANAL. If all of the nontrivial contributors to the project decide they
> want to change the license later, do we also need to obtain Rich's
> assent? I have no idea. Do I want to maintain explanations of the right
> answers to these kinds of questions for a (fork of a) project that's no
> longer within contrib? Most definitely not.
> 
> (Parenthetically, it strikes me as very strange for a project to have a
> copyright assignment to an individual that hasn't lodged any commits, at
> least insofar as the project gone "solo". It's interesting that I don't
> have that intuition if the assignee is an org like Apache or whatever, a
> discrepancy that I'll have to think on.)
> 
> That was a good question! Answering helped clarify things for me:
> specifically, if I'm going to maintain the project outside of contrib, I
> will reboot it as previously described.
> 
> Thanks,
> 
> - Chas
> 
> On 7/18/2017 13:19, Dan Larkin wrote:
>> Hi Chas!
>> 
>> This is great news, I'm glad to hear development will resume. What's the 
>> downside to just forking? aka why bother rebooting from scratch?
>> 
>> 
>>> On Jul 18, 2017, at 05:48, Chas Emerick <c...@cemerick.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I've been approached many, many times over the years (and more frequently 
>>> since the development and inclusion of socket-repl) about the potential of 
>>> moving nREPL[1] out of clojure contrib…either back to its original 
>>> location[2], or under one of the various Clojure community organizations. 
>>> I've generally demurred or ghosted on these suggestions, sometimes out of a 
>>> lack of time/attention, and often out of just not wanting to stir the pot. 
>>> The pace of them has quickened somewhat lately though, and I'd like to put 
>>> the whole topic to bed and hopefully get the project to a better footing in 
>>> the process.
>>> 
>>> First, to stipulate a few things:
>>> • nREPL is an essential bit of infrastructure in Clojure tooling
>>> • On balance, I have neglected the project in recent years, to the 
>>> detriment of all of the users of the aforementioned tooling.
>>> • On balance, contributors and potential contributors have been less 
>>> involved (or turned away entirely) because of the well-known friction that 
>>> comes with the contrib process and requirements. (tbh, this is a factor in 
>>> #2, though not the majority)
>>> • No one (least of all me) would object to nREPL having its 
>>> contribution process managed through github or gitlab.
>>> So basically everyone wants nREPL to be a "regular" project, and subject to 
>>> and beneficiary of the same expectations as 99.9% of all of the other OSS 
>>> projects we all interact with daily. How does that happen?
>>> 
>>> 
>>> 
>>> The only routes AFAICT are:
>>> 
>>> • to fork back elsewhere, which would require keeping the EPL license 
>>> and copyright assignment of the current codebase. Literally anyone can do 
>>> this at any time, without any coordination with anyone else.
>>> • for me to reboot the project. This would not be difficult given I 
>>> "own" the vast majority of the project's commits. This would allow for the 
>>> elimination of the copyright assignment, and potentially a different 
>>> license (I'm partial to MPLv2, but we'll see). If this route is taken, we 
>>> could set up a project issue where the other contributors of nontrivial 
>>> patches could agree (or not) to the reconstitution of their code w/o the 
>>>

Re: Migrating nREPL out of Clojure Contrib

[Dan Larkin]

Hi Chas!

This is great news, I'm glad to hear development will resume. What's the 
downside to just forking? aka why bother rebooting from scratch?


> On Jul 18, 2017, at 05:48, Chas Emerick  wrote:
> 
> Hi all,
> 
> I've been approached many, many times over the years (and more frequently 
> since the development and inclusion of socket-repl) about the potential of 
> moving nREPL[1] out of clojure contrib…either back to its original 
> location[2], or under one of the various Clojure community organizations. 
> I've generally demurred or ghosted on these suggestions, sometimes out of a 
> lack of time/attention, and often out of just not wanting to stir the pot. 
> The pace of them has quickened somewhat lately though, and I'd like to put 
> the whole topic to bed and hopefully get the project to a better footing in 
> the process.
> 
> First, to stipulate a few things:
>   • nREPL is an essential bit of infrastructure in Clojure tooling
>   • On balance, I have neglected the project in recent years, to the 
> detriment of all of the users of the aforementioned tooling.
>   • On balance, contributors and potential contributors have been less 
> involved (or turned away entirely) because of the well-known friction that 
> comes with the contrib process and requirements. (tbh, this is a factor in 
> #2, though not the majority)
>   • No one (least of all me) would object to nREPL having its 
> contribution process managed through github or gitlab.
> So basically everyone wants nREPL to be a "regular" project, and subject to 
> and beneficiary of the same expectations as 99.9% of all of the other OSS 
> projects we all interact with daily. How does that happen?
> 
> 
> 
> The only routes AFAICT are:
> 
>   • to fork back elsewhere, which would require keeping the EPL license 
> and copyright assignment of the current codebase. Literally anyone can do 
> this at any time, without any coordination with anyone else.
>   • for me to reboot the project. This would not be difficult given I 
> "own" the vast majority of the project's commits. This would allow for the 
> elimination of the copyright assignment, and potentially a different license 
> (I'm partial to MPLv2, but we'll see). If this route is taken, we could set 
> up a project issue where the other contributors of nontrivial patches could 
> agree (or not) to the reconstitution of their code w/o the copyright 
> assignment, etc.
> In either case, this "new" nREPL project's artifacts would end up being 
> distributed under a different maven groupId (`com.cemerick`, if I'm to 
> continue deploying, etc). The clojure-contrib nREPL project remain, and any 
> releases that are done from it after the fork/reboot would continue to be 
> under the `org.clojure` coordinates. Downstream projects need to choose 
> whether or not to change dependencies; I'd expect the vast majority of future 
> motion to gravitate to the reboot, but that's just speculation at this point.
> 
> 
> 
> I would like to hear here (no more private mails, please! :-) from any nREPL 
> users, contributors, etc. As much as possible, I would like not to 
> debate/re-litigate the merits of contrib and its process here; let's focus on 
> what steps will yield the best outcome for nREPL and its stakeholders.
> 
> 
> 
> Thanks!
> 
> 
> 
> - Chas
> 
> 
> [1] https://github.com/clojure/tools.nrepl/
> [2] https://github.com/cemerick/nrepl
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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.

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

[Dan Larkin]

George this is super cool!  I can't wait to see this show up in swank-clojure 
*ahem* Phil.


On Feb 2, 2011, at 12:03 PM, George Jahad wrote:

 
 show's a very cool function, but has a different purpose, (afaik).
 
 It displays the structure of an instance, but not it's contents.  get-
 all-fields displays the contents.  For example, if a is defined like
 so:
 
 (def a (partial conj [98]))
 
 get-all-fields will show me that the parameters to partial, f and
 arg1, are conj and [98] respectively:
 
 (pprint (get-all-fields a))
 {:__meta {:line 2009},
 :arg1 [98],
 :const__0 #Var@6b28215d: #core$apply clojure.core$apply@39bb49e2,
 :f #core$conj clojure.core$conj@1548d6e2}
 
 
 
 On Feb 2, 7:36 am, Miki miki.teb...@gmail.com wrote:
 FYI: There is clojure.contrib.repl-utils/show
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from 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: agents sending-off to other agents blocks?

[Dan Larkin]

Ah thanks for pointing out release-pending-sends, I didn't know about that; 
it's exactly what I need in my case.

On Jun 16, 2010, at 9:52 AM, YD wrote:

 Yeah, it's intended, just like what Ulrich showed. The same comment
 appears on the doc of release-pending-sends.
 In your case, the inner send-off doesn't rely on the result of the
 outter send-off. So, you can use release-pending-sends.
 The following code will have hey printed right away.

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

agents sending-off to other agents blocks?

[Dan Larkin]

Hey all,

I've cooked up this example code to demonstrate a point:

(send-off
 (agent nil)
 (fn [_]
   (send-off
(agent nil)
(fn [_]
  (println Hey!)))
   (Thread/sleep 4000))) ; Hey! isn't printed for 4 seconds (when the outer 
agent finishes).

Which is that actions sent to an agent from another agent won't be started 
until the first agent returns from its current action.

Does anyone have insight as to the reasoning here? Is it a bug? If it's 
intended behavior is there something I can do to circumvent it?


Dan

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

[Dan Larkin]

Thanks for finding that Moritz :)

I am not using the value from the current agent in the new agent though, so 
this dispatch delay is a little annoying.

I suppose I can use a future instead of an agent, though it doesn't have all 
the nice properties that agents do (once action a time).

Maybe I'll write a function that pulls from a BlockingQueue and run it on a 
Thread.

Anyway, thanks again.

Dan


On Jun 12, 2010, at 3:46 PM, Moritz Ulrich wrote:

 Sorry for the second mail, but here is the passage from clojure.org
 which mentions the behavior you've seen:
 
 5. If during the function execution any other dispatches are made
 (directly or indirectly), they will be held until after the state of
 the Agent has been changed.
 
 
 Maybe it's done to prevent problems when the function the
 currently-active agent sent to another agent depends on the value of
 the original agent.
 
 On Sat, Jun 12, 2010 at 9:43 PM, Moritz Ulrich
 ulrich.mor...@googlemail.com wrote:
 I'm not sure why it's doing this, but I read about this in the api
 documentation - It's intended
 
 On Sat, Jun 12, 2010 at 9:41 PM, Dan Larkin d...@danlarkin.org wrote:
 Hey all,
 
 I've cooked up this example code to demonstrate a point:
 
 (send-off
  (agent nil)
  (fn [_]
   (send-off
(agent nil)
(fn [_]
  (println Hey!)))
   (Thread/sleep 4000))) ; Hey! isn't printed for 4 seconds (when the 
 outer agent finishes).
 
 Which is that actions sent to an agent from another agent won't be started 
 until the first agent returns from its current action.
 
 Does anyone have insight as to the reasoning here? Is it a bug? If it's 
 intended behavior is there something I can do to circumvent it?
 
 
 Dan
 
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 
 
 
 --
 Moritz Ulrich
 Programmer, Student, Almost normal Guy
 
 http://www.google.com/profiles/ulrich.moritz
 
 
 
 
 -- 
 Moritz Ulrich
 Programmer, Student, Almost normal Guy
 
 http://www.google.com/profiles/ulrich.moritz
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from 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: Trait-like behavior with Protocols

[Dan Larkin]

On Feb 8, 2010, at 6:13 PM, aria42 wrote:

 Is it possible to have default implementations associated with
 functions in a protocol? This is most useful when some protocol
 functions are defined in terms of other. For instance,
 
 (defprotocol Span
  (start [self])
  (stop [self])
  (span-length [self]))
 
 Now I know I can just make span-length a function on Span as opposed
 to part of the protocol. Is that what one should do?

Can you show me what this looks like?

Thanks,
Dan

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

[Dan Larkin]

On Dec 11, 2009, at 3:04 PM, Sean Devlin wrote:

 Wouldn't ::quit do the same thing?


It wouldn't, because the repl is evaluating in the context of wherever you put 
the (debug-repl) call, so its namespace won't be dr.

What about instead of using keywords for commands, we use functions for 
commands:

(debug-repl-quit)


 One possible implementation of this is to use keywords as commands to the 
 debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom 
 interesting, we could use ones like :quit or :pop as commands intercepted by 
 the debug repl before evaluation. We could even respond to a set of commands 
 and send any unrecognized commands along to the evaluator.
 
 If hijacking namespace-less keywords for that purpose is distasteful, we 
 could also put the commands in a namespace, for example:
 
 :dr/quit

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

[Dan Larkin]

On Dec 2, 2009, at 5:04 PM, dysinger wrote:

 We need to hire another two full-time devs (!) to work on a clojure
 project
 (distributed backend on clojure). Don't be nervous about that old job
 - take a
 risk! Wake up and work in your PJs with interesting code and get paid
 to code in
 clojure! (I live on Kauai, HI)
 
 The team currently consists of myself (dysinger), phil (technomancy),
 dan
 (danlarkin), george (gjahad) and Steve (scgilardi) and we all use and
 love Emacs
 (requirement so we can pair).
 
 We would prefer a well rounded polyglot w/ some real exposure to jvm,
 lisps and
 functional programming. We practice remote TDD pair-programming
 (Skype/Gizmo/Emacs/Screen) on our team. A typical day is a morning
 stand-up on
 voip followed by pair-programming sessions. Occasional spikes require
 solo work.
 
 If you feel you have clojure under your belt, please drop a resume
 with an intro
 on why you want this job to j...@sonian.net. If you are involved in
 any
 open source clojure code, please include links. If you have sent me an
 email in
 the past, please try again (sorry I have been swamped).
 
 It's impossible to know what it's like to work for us and us with you
 in
 interviews. We don't do grueling interviews. Our pattern for
 interviewing is 30 days
 paid work where either party can walk away. We currently aren't
 looking for
 part-timers or people with distracting interests on the side. This is
 a
 dead-serious job

We aren't /that/ serious :)


 with a funded start-up and we need focus. The job
 includes a
 15 MBP  3g.
 
 Tim Dysinger
 VP of Engineering,
 Sonian Networks
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from 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: New string utilities library ready

[Dan Larkin]

On Aug 19, 2009, at 2:22 PM, Chouser wrote:

 I use (require '[clojure.contrib.str-utils2 :as str2]) for
 now and would recommend just 'str' if the lib name changes.


Except, of course, since there is already a str function, 'str' would  
be a bad alias.

'strutils' or 'str-utils' sound fine to me, but I'm not so great at  
the name game.

I'm in favor of str-utils2 replacing str-utils, though.

Dan

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

[Dan Larkin]

On May 18, 2009, at 9:23 AM, Laurent PETIT wrote:


 2009/5/18 Mark Volkmann r.mark.volkm...@gmail.com:

 On Mon, May 18, 2009 at 7:36 AM, Rich Hickey richhic...@gmail.com  
 wrote:

 I'll be doing two sessions involving Clojure at JavaOne this June.  
 One
 is a traditional talk (TS-4164), the other is as a participant in  
 the
 Script Bowl 2009: A Scripting Languages Shootout (PAN-5348).

 The 'script' bowl is a friendly competition, basically a place to  
 show
 off your language and seek audience acclaim.

 Scripting language gurus returning from 2008 are Groovy, JRuby,
 Jython, and Scala. This year there is also a new kid on the block:
 Clojure.

 There are two very brief rounds, 4 minutes per language each round .

 round 1: Core language and libraries round (show something really  
 cool
 with the core language and libraries)

 round 2: Community round (show some significant community
 contributions)

 Note there is no comparative aspect, each language presenter talks  
 up
 their own language and the audience decides, so it's not an
 opportunity to draw contrasts explicitly. It's about being pro-
 Clojure, not anti- anything else.

 The audience is Java developers, many of whom will have never seen
 Clojure or any Lisp.

 I'd appreciate some suggestions *and help* preparing demos for the
 Script Bowl. What (that could be demonstrated in 4 minutes) would  
 make
 you think - 'Clojure looks cool, I need to look into it'?

 I think this should be a demo of the basic use of Refs and STM. The
 tough part is keeping this simple enough to explain and demo in 4
 minutes. The bank example at
 http://java.ociweb.com/mark/clojure/article.html#ReferenceTypes is  
 too
 long. Maybe a simplified version of that can be created.

 What community contribution(s) should we showcase?

 I think this should be a simple demo of Compojure. I have one at
 http://java.ociweb.com/mark/clojure/article.html#WebApps that you are
 welcomed to use.

 I fear demonstrating compojure might be interpreted just as yet
 another web framework (mean yet another solution to a well-known
 problem - a problem which already has good solutions in each and every
 language, including java - wicket, GWT, webworks, etc.).
 And then people will just focus on this yet another web framework
 thought, and not be open to see where the power of clojure comes into
 play in compojure.

 In the other hand, I don't have a better idea yet, but what about
 clojure.contrib.walk (to demonstrate that it is possible to define
 very generic algorithms that can then be applied to almost every other
 clojure datastructure) ?

I agree with Laurent.  Every language has a web framework, probably  
many; it's not very unique to clojure.  I think something involving  
runtime code modification and/or STM would be neat to show off.




 --
 R. Mark Volkmann
 Object Computing, Inc.




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: error-kit + test-is

[Dan Larkin]

Sorry for the necro, but I just started using error-kit and read this  
thread for the first time today.

Both error-kit (errors no longer inherit from *error* AFAICT) and test- 
is (the report function syntax) have changed since David last posted a  
working function, so I've updated it work with the latest revision of  
contrib.  Would it make sense for this to be included in  
error_kit.clj? That way raised? would automatically work when testing  
any error-kit'ed code.

Attached is a patch for adding raised? to error-kit.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



error_kit_test_is.patch
Description: Binary data



On Feb 16, 2009, at 12:13 PM, David Nolen wrote:

 (defmethod assert-expr 'raised? [msg [_ error-type  body :as form]]
  (let [error-name (qualify-sym error-type)]
`(with-handler
   (do
 ~...@body
 (report :fail ~msg '~form ~(str error-name  not raised.)))
   (handle ~error-type {:as err#}
   (report :pass ~msg '~form nil))
   (handle *error* {:as err#}
 (report :fail ~msg '~form (:tag err#))

 You're right I think the entire first handle statement was wrong.  I  
 believe handle does the isa? check on the error type, correct? If so  
 then this will allow inherited error types to pass the test.

 Many, many thanks for the feedback.

 test-is + error-kit is a great combo.

 --~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google  
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 To unsubscribe from 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: alternate syntax

[Dan Larkin]

But.. but... macros? code is no longer data?


On Feb 23, 2009, at 10:42 AM, Mark Volkmann wrote:


 I have an idea I'd like to float to see if there are reasons why it's
 a bad idea.

 What if Clojure had an alternate surface syntax that was translated
 into standard Clojure syntax by a kind of preprocessor?

 Many people that don't like Lisp dialects don't like them because of
 the parentheses. I'm trying to address that.

 Here's a simple example of valid Clojure code.

 (defn pig-latin [word]
  (let [first-letter (first word)]
(if (.contains aeiou (str first-letter))
  (str word ay)
  (str (subs word 1) first-letter ay

 (println (pig-latin red))
 (println (pig-latin orange))

 Here's what that same code would look like in my alternate syntax.

 defn pig-latin [word]
  let [first-letter (first word)]
if .contains aeiou (str first-letter)
  str word ay
  str (subs word 1) first-letter ay

 println (pig-latin red)
 println (pig-latin orange)

 The rules for turning this into standard Clojure syntax are pretty  
 simple.

 1) If a line is indented farther than the previous one, it is part of
 the previous line.
 2) If a line doesn't start with a (, then add one.
 3) If the next line is indented less than this one, add the
 appropriate number of )'s at the end.
 4) If the first token on a line is if and the first non-whitespace
 character after it is not (
then assume the rest of the line is the condition and wrap it in  
 ( ).

 A translation from standard Clojure syntax to this alternate form
 should also be possible.

 Is this a bad idea?

 -- 
 R. Mark Volkmann
 Object Computing, Inc.

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: generic functions update

[Dan Larkin]

On Feb 21, 2009, at 2:23 PM, mikel wrote:


 If there's interest in having models and generic functions in contrib,
 I'll get a contributor agreement to Rich.


Aye there is, from me at least.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Circular Dependancy Question

[Dan Larkin]

So I've got a circular dependency problem.  There's a few ways to move  
functions and (require )s around but the problem remains -- these  
three files fundamentally depend on one another:

parser.clj - lexer  parser (using joshua choi's excellent fnparse  
library)
defaulttags.clj - multimethods for handing conditionals, looping,  
including other templates, etc.
template.clj - user facing code. Has functions to load templates  
from disk and helper functions for rendering templates.

And here's a dependency breakdown:

defaulttags.clj
   depends on template.clj for loading new templates from disk from an  
include template tag
   depends on parser.clj for parsing the templates it loads

template.clj
   depends on parser.clj for parsing/rendering templates it loads from  
disk
   also loads defaulttags.clj so the multimethods get registered


There's also another file, right now called foo.clj, which defines two  
functions (represent and invoke-templatetag) and has no dependencies,  
but is required by all 3 files.  I had to create the foo.clj file to  
get around an earlier circular dependency issue, and that works and  
there's no problem with it right now... just saying that's how  
parser.clj can call the tags registered in defaulttags.clj even though  
it doesn't import it.


So anyway, I guess that's a long-winded explanation of my current  
circular dependency problem. It'd be great if someone could suggest a  
remedy.

But as an aside, does this seem to anyone else like a wart on an  
otherwise great language? Thinking about file layout should not be one  
of my priorities... the language should not encourage me to put  
everything together in one file just to get it to work.  I should be  
able to separate functionality in a way that makes sense to the app  
I'm building.

Thanks for reading,
Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Circular Dependancy Question

[Dan Larkin]

On Feb 14, 2009, at 2:14 PM, Stephen C. Gilardi wrote:


 On Feb 14, 2009, at 1:40 PM, Dan Larkin wrote:

 But as an aside, does this seem to anyone else like a wart on an  
 otherwise great language? Thinking about file layout should not be  
 one of my priorities... the language should not encourage me to put  
 everything together in one file just to get it to work.  I should  
 be able to separate functionality in a way that makes sense to the  
 app I'm building.

 Within one namespace, we use declare to avoid this problem. Perhaps  
 declare could be extended (or another function created) to work with  
 namespace-qualified symbols that refer to namespaces and vars that  
 may not yet exist. I would imagine this would involve creating the  
 namespace and var within it if either didn't yet exist and pushing  
 the namespace name onto some deferred load queue so it's  
 guaranteed loaded by the time the top level load is complete.

 For this to be effective in our preferred way to declare  
 dependencies, it should be a new clause in within ns.

 Any thoughts?


What you describe is the first way I thought about it.  Some sort  
of :external-depends or something...

But thinking about it more, would it be possible to emulate the way  
python handles circular dependencies?  When a file is imported in  
python the interpreter evaluates top-level forms to create a list of  
exports. Of course the clojure reader has fundamental differences from  
the python reader, but couldn't clojure do something similar?  After  
all, (read (PushbackReader. (StringReader. (def a (foo 5) just  
returns a list, couldn't each (require )'d namespace be read, searched  
for exports and dependencies (which would have the same thing done to  
them) and then they could be evaluated? That way all the vars  
necessary for linking are present.

Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Parsec style library

[Dan Larkin]

On Feb 3, 2009, at 9:42 PM, sbkogs wrote:


 Parsec is a very powerful parsing library for Haskell.  I was mainly
 attracted to Haskell because of this library (ala Pugs project which
 used Parsec to create a Perl6 parser).

 I am wondering if there is an ongoing effort to write similar library
 for Clojure.  I have seen a very nice implementation of Monads in
 Clojure.Contrib which can be used to build this library.  Having such
 powerful and easy way to build a parser could attract many more users
 to Clojure.  BTW, I have seen a parser combinator file by jim in the
 files section, which could be used as a stepping stone.

 If anybody is working on similar library, please drop me a line.  I
 have some bandwidth to spend towards such work/fun.


http://github.com/joshua-choi/fnparse/tree/master

It's very good!


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: somehow (quote foo) came back from the REPL

[Dan Larkin]

On Feb 2, 2009, at 8:32 PM, Terrence Brannon wrote:


 I was fooling around in the REPL and from the looks of the transcript,
 I typed the very same thing, yet in one case the REPL returned (quote
 foo) and in the other case it returned foo.

 Transcript follows:

 user= \newline
 \newline
 user= \c
 \c
 user= nil
 nil
 user= false
 false
 user= :foo
 :foo
 user= 'foo
 (quote foo)
 user= 'foo
 foo

 How did that happen?

My guess is you typed the single quote character twice by mistake:

user= ''foo
(quote foo)




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Got a Clojure library?

[Dan Larkin]

Name: clojure-json
URL: http://github.com/danlarkin/clojure-json/
Author: Dan Larkin
Tags: parsing, web, data-interchange
License: BSD
Dependencies: clojure-contrib (only for running tests)
Description:
A JSON encoder/decoder for clojure.  Supports reading/writing from  
strings and files, pretty printing and custom encoders for java  
classes not handled by default. Complete with low memory usage  
characteristics and best of all... it's fast!



On Jan 29, 2009, at 10:04 AM, Rich Hickey wrote:


 People regularly post here about Clojure libraries they are working
 on, and it is great to see the explosion of new libs for Clojure!

 I'd like to try to get a directory of Clojure libs together and up on
 the Clojure site. Towards that end, I'd appreciate it, if you are the
 author of a Clojure library (including contrib authors!), you reply in
 this thread with:

 The name of your library
 Library home page URL
 Your name
 Category (db, web, UI, parsing etc)
 License
 A one-paragraph description. Include 3rd party dependencies if any.

 (did I miss anything important?)

 Thanks!

 Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Alternatives to contains?

[Dan Larkin]

On Jan 29, 2009, at 2:55 PM, Cosmin Stejerean wrote:



 On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser taron...@gmail.com  
 wrote:

 I know this has been discussed on the list before to some extent, but
 does clojure by default have any operations which actually do what
 contains? sounds like it would do, for all collections? I know that
 you can easily write something similar using some, but often times
 you just want to find if something is in a list of items.

 I've seen Rich say that contains? is for associative things, but I
 think it is an unfortunate name - if the idea is to express that the
 collection has a value for that key, I think the name would ideally
 express that, like:

 contains-key?
 has-key?
 maps?

 I would prefer has-key? for checking if a key is in a map and  
 contains? for checking if an element is in a collection.

What about leaving contains? as is and adding in? which would work  
like in in python.

(contains? [1 2 50] 50) = false
(in? [1 2 50] 50) = true



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Alternatives to contains?

[Dan Larkin]

On Jan 29, 2009, at 5:23 PM, Cosmin Stejerean wrote:

 If in? was to be added how would it behave when given a map as the  
 first argument? I would rather have contains? do the right thing  
 for list/vectors/sets and keep its current behavior for maps. If we  
 do actually need a function like contains that ONLY accepts a map as  
 the first argument I think a name like has-key? is the most intuitive.



I think in? would behave like contains? when given a map:

(in? {:a 1 :b 2 :c 3} :a) = true
(in? {:a 1 :b 2 :c 3} :d) = false



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

On Jan 17, 2009, at 6:29 PM, Stephen C. Gilardi wrote:

 I think it's interesting experimental code. Please do send in a CA  
 and let's get something like this into ns-utils.


I am now listed on http://clojure.org/contributing so feel free to  
commit resolve* (or something like 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
To unsubscribe from 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: What's best way to get rid of #File?

[Dan Larkin]

On Jan 20, 2009, at 8:42 PM, wubbie wrote:


 Hi
 I would just print the files, excluding #File and  .
 what's the best way?

 user= (filter recently-modified? (file-seq (File. .)))
 (#File . #File ./.my-hints.clj.swn #File ./my-hints.clj)


http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#getName()


 Thanks
 -Sun
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

(defn require-resolve
   [id]
   (let [sym (symbol id)
 ns-symbol (symbol (namespace sym))
 var-symbol (symbol (name sym))]
 (require ns-symbol)
 (ns-resolve (find-ns ns-symbol)
 var-symbol)))

The name is terrible, I know.

You can pass a symbol or a string in fully qualified clojure syntax  
and it returns a clojure.lang.Var, which the caller can resolve with  
var-get... maybe this function should call var-get itself... that's up  
for debate.


Adobo:~ dan$ clj
Clojure
(defn require-resolve
   [id]
   (let [sym (symbol id)
 ns-symbol (symbol (namespace sym))
 var-symbol (symbol (name sym))]
 (require ns-symbol)
 (ns-resolve (find-ns ns-symbol)
 var-symbol)))
#'user/require-resolve
user= (require-resolve clojure.contrib.def/defvar-)
#'clojure.contrib.def/defvar-
user= (var-get (require-resolve clojure.contrib.def/defvar-))
#def$defvar___115 clojure.contrib.def$defvar___...@e40293
user= ((require-resolve clojure.contrib.str-utils/str-join) , [1  
2 3 4 5])
1,2,3,4,5

Stephen, if you think this is something suitable for  
clojure.contrib.ns-utils then I'll submit my CA to Rich and you can  
pull it in, otherwise it's here for anyone to use.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

On Jan 17, 2009, at 6:29 PM, Stephen C. Gilardi wrote:

 Hi Dan,

 That's interesting. I've given it some thought and I've come to see  
 it as a version of resolve that tries harder than the default.  
 Here's an implementation that makes its capabilities purely a  
 superset of those of resolve. This version works well even with  
 definitions that don't come from libs like those in clojure.core:

 (defn resolve*
  [sym]
  (let [ns (namespace sym)
name (name sym)
ns (if ns (symbol ns) (ns-name *ns*))
name (symbol name)]
(or (and (find-ns ns) (ns-resolve ns name))
(do
  (require ns)
  (ns-resolve ns name)

 This version takes a symbol just like resolve does. It doesn't  
 support passing in a string. I think any string to symbol  
 transformation is easy one for a caller to make if it needs to. I  
 had an interim version that supported separating the namespace and  
 name into two arguments, but that would be more like ns-resolve* and  
 resolve* is every bit as capable.

Hi Stephen,

Yes, you're right, this does make sense as a superset of clojure.core/ 
resolve -- also resolve* is a name that fits much better.



 I'm interested in hearing any thoughts you may have on this version  
 as it relates to the problem you're trying to solve. I like that in  
 Clojure we now have a canonical way to load in a namespace  
 definition: require. This idea of yours leverages that. Together  
 with that, we also have a canonical way for one namespace to declare  
 and satisfy its dependence on another: (ns (:require...)). Given  
 those two facilities, I wonder what use case you envision for  
 require-resolve (or resolve*). Is this intended to be used at the  
 repl? Does it offer a compelling advantage for some kind of work  
 over calling require directly and then letting the default symbol  
 resolution mechanism do the work?

I like how you phrase that.  Yes, you're correct, for dependencies you  
can identify at coding time (ns (:require ..)) works just fine, but  
for runtime-introduced dependencies a (require ...) is necessary.

My first use case is a settings file.  The settings file (clojure  
code itself) defines a bunch of settings (duh) which include  
middleware functions, template loader functions (and more to come  
for sure).  So without resolve* there are two options:

 1) Import all of the functions to which I need to refer and then  
identify them directly.
 2) Give a two-tuple with namespace and var symbols, which can  
then be (require ..) and (ns-resolve ..)'d later on.

So basically option #1 sucks and #2 is just a more verbose version of  
using resolve*.


My second use case is an url-dispatching system.  It's a port (mostly  
-- java's regex doesn't have named groups and clojure doesn't have  
keyword arguments) of django's url dispatching system.  Basically you  
define a list of regexes and which function you want to be called when  
the url matches that regex.

So it's the same conundrum as with the settings file, really.  Either  
I can require all of the functions I want to call or give two-tuples  
of namespace and var -- or use require*




 Stephen, if you think this is something suitable for  
 clojure.contrib.ns-utils then I'll submit my CA to Rich and you can  
 pull it in, otherwise it's here for anyone to use.

 I think it's interesting experimental code. Please do send in a CA  
 and let's get something like this into ns-utils.

 --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
To unsubscribe from 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] Ring: A Web application library for Clojure.

[Dan Larkin]

I'm incredibly impressed!  Have only looked at the code briefly but I  
read the whole post and I'm really excited for where this is going.


On Jan 12, 2009, at 11:45 PM, Mark McGranaghan wrote:


 Hi All,

 I'm happy to announce the alpha release of 'Ring', a library inspired
 by Python's WSGI and Ruby's Rack for developing web applications in
 Clojure.

 I've made it as easy as humanly possible for you to try it out:

git clone git://github.com/mmcgrana/ring.git
cd ring
java -Djava.ext.dirs=jars clojure.main src/ring/examples/
 hello_world.clj

 And your up and running with your first Ring web app, which you can
 see at http://localhost:8080/ in your browser.

 The basic idea of Ring is that web apps are just Clojure functions
 that take a standardized request as a single argument and return and
 standardized response. For example, the hello_world.clj script from
 above is:

   (ns ring.examples.hello-world
 (:require ring.jetty)
 (:import java.util.Date java.text.SimpleDateFormat))

   (def formatter (SimpleDateFormat. HH:mm:ss));

   (defn app
 [req]
 {:status  200
  :headers {Content-Type text/html}
  :body(str h3Hello World from Ring/h3
pThe current time is 
(.format formatter (Date.)) ./p)})

   (ring.jetty/run {:port 8080} app)

 Its nice to be able to get to Hello World so quickly, but the real
 power of Ring is that apps are just functions - hence we can combine,
 wrap, curry, and generally manipulate them as first class values.

 For example, someone asked in #clojure today how they could make their
 web app provide a cleaned backtrace as an HTML response when it raised
 exceptions. To add such exception handling to our Hello World Ring app
 we would just use the ring.backtrace middleware:

(ring.jetty/run {:port 8080} app)

becomes

(ring.jetty/run {:port 8080}
  (ring.backtrace/wrap
app))

 Similarly, one might want to have changes to a web app's code be
 reflected in real time in the development environment, so as to avoid
 constantly having to reboot the webserver. The ring.reload middleware
 accomplishes exactly that:

(ring.jetty/run {:port 8080}
  (ring.backtrace/wrap
(ring.reload/wrap '(ring.examples.hello-world)
  app)

 These are some of the features that originally motivated me to develop
 Ring, but the complete list of functionality available to Ring apps is
 larger and continues to grow:

 * ring.jetty: Handler for the Jetty webserver.
 * ring.file: Middleware that serves static files out of a public
 directory.
 * ring.file-info: Middleware that augments response headers with info
 about File responses.
 * ring.dump: Endpoint that dumps the Ring requests as HTML responses
 for debugging.
 * ring.show-exceptions: Middleware that catches exceptions and
 displays readable backtraces for debugging.
 * ring.reload: Middleware to automatically reload selected libs before
 each requests, minimizing server restarts.
 * ring.builder: Helpers for combining Ring endpoints and middleware
 into Ring apps.
 * ring.lint: Linter for the Ring interface, ensures compliance with
 the Ring spec.
 * ring.examples.*: Various example Ring apps.

 You can find more details about Ring at its project page on GitHub,
 including a README file for new users and a draft SPEC file that
 documents the Ring interface:

 http://github.com/mmcgrana/ring

 I've built an open source web app on Ring: http://cljre.com. The
 source for this simple app, available at http://github.com/mmcgrana/cljre.com 
 ,
 could serve as a good introduction to how apps can consume Ring
 requests and to the use of modular Ring middleware; see in particular
 the src/cljre/app.clj file, where most of that application is defined.

 Also, I think I should mention how I see Ring relating to the Java
 Servlet abstraction and to existing and new Clojure web frameworks.
 Ring heavily leverages the Servlet API internally, as I strongly
 believe in not reinventing wheels such as basic HTTP parsing.
 Furthermore, I think that the interface that Ring presents to Clojure
 web application developers by pre-processing the servlet requests is
 dramatically more useful than that of the raw servlet. Ring uses
 Servlets for what they are really good at - implementing HTTP - and
 presents a simple API against which additional logic can be defined in
 the application layer.

 In terms of Clojure web frameworks, I think that there is a lot to be
 gained by leveraging the Ring interface, especially from the modular
 functionality provided by Ring middleware. I'd like in particular to
 be able to run Compojure apps in Ring - if the users and authors of
 Compojure are interested I'd be happy to work with them to see what we
 can do.

 If you've made it this far, thanks a lot for reading! I welcome any
 comments or suggestions that you have about Ring, the draft SPEC
 document, or the Clojure web app space in general.

 Thanks again,
 

python style triple-double-quotes

[Dan Larkin]

Fellow clojurecrats,

I'm here to ask for python style triple-double-quotes syntax in clojure.

For those unfamiliar they're documented here: 
http://docs.python.org/reference/lexical_analysis.html#strings

This is also a nice summary: 
http://diveintopython.org/getting_to_know_python/documenting_functions.html

Rich, you said you were considering it in March 
(http://groups.google.com/group/clojure/browse_thread/thread/8690a80c263d3b52/e8d73aebf11c2698
 
), did anything ever come of that?


Dan

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is: first major rewrite

[Dan Larkin]

Hey this looks great!

On Dec 7, 2008, at 10:51 AM, Stuart Sierra wrote:


 Hi folks,
...

 2. each= and all-true are gone, replaced by the new macro are,
 which works with any predicate:
(are =
  2 (+ 1 1)
  4 (+ 2 2))


Just one bone to pick, though.  The are macro doesn't work so well  
if I want to test a custom assert-expr function that only deals with a  
single expression.

Since this works fine:

(deftest array
   (is (:json= [1 2 3 4 5])))

it would be nice if I could write:

(deftest basics
   (are :json=
[1 2 3 4 5]
{:bar 2 :foo 1}
[[1 2 3 4 5]]
{:bam {:foo 1} :baz {:bar 2}}
[{:foo 1} {:bar 2}]))


The :json= handler for assert-expr encodes and then decodes the expr  
into/from JSON.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Surprise effect

[Dan Larkin]

For what it's worth SBCL has this same behavior (although I don't like  
it).

On Dec 4, 2008, at 5:45 AM, Konrad Hinsen wrote:


 On Dec 4, 2008, at 10:50, Meikel Brandmeyer wrote:

 On 4 Dez., 10:08, Konrad Hinsen [EMAIL PROTECTED] wrote:
 user= a'
 2
 user= a
 a

 a' is parsed as:
 a = symbol = evaluate = 2 = print prompt
 ' = reader macro = wait for more

 Then you type the second a and it goes on:
 a = translate 'a = (quote a) = a = print prompt

 So reader is actually in quote mode when, you type
 the second a. It sees the conversation like this

 A. Apparently there doesn't have to be whitespace before the
 quote, and there can be any amount after it. Not what I expected, but
 that's fine.

 Thanks,
   Konrad.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: newby problems running clojure on Mac OS X

[Dan Larkin]

ant and svn are in /usr/bin/ on my leopard install, which means they  
either came with OS X itself or the OS X development tools.  I'd check  
if you've got them already before installing.


On Nov 10, 2008, at 11:15 AM, Justin Henzie wrote:


 I am using the svn version 1086 and this works fine for me.

 If you have never used subversion don't worry it is very simple to
 use.

 Here are basic instructions.

 Download ant from
http://ant.apache.org/bindownload.cgi

 Supposing you downloaded apache-ant-1.7.1-bin.tar.gz

 Open a terminal and untar the resulting tar.gz uzing

tar -xvzf apache-ant-1.7.1-bin.tar.gz

 You can either leave the apache-ant-1.7.1 where it is, or move it to a
 sensible location, my preference is

sudo mv apache-ant /usr/local
sudo ln -sf /usr/local/apache-ant-1.7.1 /usr/local/ant

 Then add the following to your ~/.bashrc or whatever shell equivalent
 you are using

 export PATH=$PATH:/usr/local/ant/bin

 Download subversion from

 http://www.metissian.com/projects/macosx/subversion/

 Choose the 1.3 dmg

 Install subversion

 Open a terminal and cut and paste the line immediately below this one
 into the terminal

svn co https://clojure.svn.sourceforge.net/svnroot/clojure clojure

 This will create a new directory ./clojure

 cd to the following path

./clojure/trunk

 Type:

ant

 When ant completes you will have a new clojure .jar in the directory,
 I move mine to ~/.clojure and include that diretory in my classpath.

 You should now be good to go.  Good luck

 -jh




 On Nov 9, 8:43 pm, Stephen C. Gilardi [EMAIL PROTECTED] wrote:
 On Nov 9, 2008, at 9:57 PM, [EMAIL PROTECTED] wrote:

 I've downloaded clojure as described in the getting started pages.
 When I run clojure as described it works and I can execute the
 JOptionPane example and it appears and works.

 I downloaded clojure_20080916.zip, expanded it, ran ant within it
 and then started clojure with:

 java -jar clojure.jar

 on Leopard using Java 1.6.0_07 and it works:

 user= (System/getProperties)
 {java.runtime.name=Java(TM) SE Runtime Environment,
 sun.boot.library.path=/System/Library/ ...

 If you're checking Clojure out using svn, we're in a transitional  
 time
 at the HEAD (seehttp://clojure.svn.sourceforge.net/viewvc/clojure/).
 The most recent recommended version for general use is 1088.

 svn update -r 1088

 or

 svn co -r 1088

 If you continue to have trouble, please give more detail about your
 hardware (ppc vs. intel) and software (os and java versions) setup  
 and
 what steps you're following.

 --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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---