Re: How to add jar files to leiningen projects?

2011-07-12 Thread Shantanu Kumar
> It would be ideal if it could be run outside of the project structure, as
> would be the case if an additional arity was added to the install function
> in leiningen.install.

Thanks for the report -- I have pushed version 0.1.1 so it should now
be possible to install it as a plugin and run from any directory.

Regards,
Shantanu

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


Re: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Michael Wood
Hi Ken

On 12 July 2011 03:12, Ken Wesson  wrote:
> On Mon, Jul 11, 2011 at 7:51 PM, Mike Meyer  wrote:
>> On Mon, 11 Jul 2011 16:21:45 -0400
>> Ken Wesson  wrote:
>>> > So, "repository" does not imply "server" at all,
>>> This is getting silly. "Repository" is a word that brings immediately
>>> to mind typing checkin and checkout commands at a command prompt in
>>> order to work on source code that is stored remotely. And remotely
>>> implies "server".
>>
>> I was with you until you said "stored remotely".
>
> Well, the source code is being worked on collaboratively by
> geographically separated people in many cases, and from multiple
> office cubicle computers in the most geographically-concentrated case.
> The canonical master version of the source code must reside in some
> single place, which can be at most one of those developers' computers;
> so for the rest of them, it's stored remotely.

This may be the case, but a "repository" in no way implies that there
are multiple developers involved.  Just as (I thought we had agreed
before this thread was revived) a "repository" in no way implies a
network.

Also, even if there is some central, authoritative repository, the
individual developers may (e.g. in the case of Git or Mercurial) still
have local repositories that are not inextricably linked to the
central repository.

> What's stored locally may range from a single file being worked on at
> a time to a copy of the whole code base, but there is still generally
> a master copy and there is still therefore some mechanism for updating
> the master copy and resolving edit conflicts that collide there.

The conflict resolution in CVS or Subversion or Mercurial or Git all
happens locally.  Not in some central server or repository.  Some
crude form of conflict detection might happen in the central
repository, but so what?  That does not mean that "repository =>
network", which was your original argument, and it does not mean that
a repository is inherently shared between multiple developers.

> That mechanism requires the computer holding the non-master copy or
> single file to push its diffs to the computer holding the master copy
> (and then the latter is a server) or the computer holding the master
> copy to pull diffs from the others (and then all the REST are
> servers!).


If there is a central repository then yes, changes need to be pushed
to it or pulled into it from elsewhere.  But the existence of a
networked repository or a repository shared on a multi-user machine
with no networking involved does not preclude the existence of
non-networked, single-user repositories.  So again, a repository does
not imply that there is a network involved.

> So not only is there a "stored remotely" in there out of necessity for
> anything but a single-developer-on-a-single-machine project, but
> there's also a "server" in there, or even multiple servers. The
> alternatives I can think of are:
>
> 1. One developer, one computer. Version control may be overkill in
> such a case anyway and it's not how big, major projects are developed.

I'd disagree that version control is overkill, but that has is
irrelevant.  Anyway, we're not talking about "big, major projects".
We're talking about the meaning of the word "repository".

> 2. Many developers, one computer. No "remote storage" and if the
> developers are co-located no server; otherwise a terminal server. The
> former is obviously not parallelizable (though edit conflicts are thus
> a non-issue -- single global lock FTW!!!1!1) and the latter is a
> throwback to the 1980s or earlier. :)
>
> 3. Many computers, one developer manually synching files or just
> carrying the codebase around on a thumbdrive. No servers, no remote
> storage that isn't simply overwritten when returned-to. The extra
> copies, if any, merely amount to backups. Most likely with a
> one-developer project with a tower and a laptop, or developing a phone
> app on a computer and on their phone.
>
> 4. An ad hoc, peer-to-peer system with many evolving versions of the
> codebase and patches swapped back and forth but no canonical "master"
> copy. This *might* be workable on a small project (a handful of
> developers, not too many LOC) but surely cannot scale much above that
> without becoming total chaos. There might be no "server" beyond email
> in such a case, used for exchanging diff files or whatever. But I
> expect any project organized that way to melt down above a fairly
> small size of codebase and/or developer headcount. Versions will
> become too divergent, the bigger and more numerous they are, until
> patches that worked on the sender's copy often won't work, or won't
> work without extensive modification, on the recipient's, and then the
> ability to share improvements begins to break down rapidly when that
> point is reached. In effect, the codebases begin to evolve into
> separate species that can no longer interbreed. Perhaps this is how
> bacteria, despite being able to share genes 

Re: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 3:52 AM, Michael Wood  wrote:
> Hi Ken
> On 12 July 2011 03:12, Ken Wesson  wrote:
>> On Mon, Jul 11, 2011 at 7:51 PM, Mike Meyer  wrote:
>>> I was with you until you said "stored remotely".
>>
>> Well, the source code is being worked on collaboratively by
>> geographically separated people in many cases, and from multiple
>> office cubicle computers in the most geographically-concentrated case.
>> The canonical master version of the source code must reside in some
>> single place, which can be at most one of those developers' computers;
>> so for the rest of them, it's stored remotely.
>
> This may be the case, but a "repository" in no way implies that there
> are multiple developers involved.

No, simple statistics suffices for that. When a project is big enough
to use a repository and not simply a source tree on one guy's
computer, it's generally got multiple developers.

> Also, even if there is some central, authoritative repository, the
> individual developers may (e.g. in the case of Git or Mercurial) still
> have local repositories that are not inextricably linked to the
> central repository.

Except that to make any change "official" it must be pulled/pushed
into that central repository -- which requires a client/server
protocol in the general case.

> The conflict resolution in CVS or Subversion or Mercurial or Git all
> happens locally.  Not in some central server or repository.

Perhaps, but detection has to happen centrally, wherever resolution is handled.

> Some crude form of conflict detection might happen in the central
> repository, but so what?

"So what?" So, without conflict detection you have anarchy and with it
you have a server. Take your pick. :)

> If there is a central repository then yes, changes need to be pushed
> to it or pulled into it from elsewhere.  But the existence of a
> networked repository or a repository shared on a multi-user machine
> with no networking involved does not preclude the existence of
> non-networked, single-user repositories.

What (other than satisfying Maven's peculiar, autistic needs from its
world) is the use case, precisely, for such repositories?

>> 1. One developer, one computer. Version control may be overkill in
>> such a case anyway and it's not how big, major projects are developed.
>
> I'd disagree that version control is overkill, but that has is
> irrelevant.

Obviously not, since it cuts to the heart of whether *in practice* the
typical repository will be networked or not.

Version control is overkill unless the project has gotten above a
threshold in terms of sheer size of code body. Though we might
disagree on the exact positioning of that threshold, the likelihood is
overwhelming that by the time it's even approached a project has
accreted multiple developers -- for one thing, it's hard for a single
developer to keep that much code straight in his head, unless it's so
modularized that the components are essentially separate projects with
fairly stable APIs and each below the threshold for version control
being a big win. For another that would have to be one heckuva
prolific single developer; for a code base to get really huge usually
requires it to have many people adding to it.


-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Meikel Brandmeyer
Hi,

Am Dienstag, 12. Juli 2011 03:12:20 UTC+2 schrieb Ken Wesson:

So, unless 4 can be made workable, ...
>

Did you try darcs?

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

Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Sergey Didenko
> Public relations -- Project status and activity. This area seems to
> suggest the main Clojure page should be covered in tickers and feeds
> of various kinds
>

I think the main site needs just a pane with a big noticeable header "News",
that shows one-two latest important stories and updates one time per 5-15
days. Also has a link, a few links on where to read much more news (feeds
for blogs, aggregators, twitters, etc). It's purpose not to "create
clutter", but to give an impression that "Clojure" is not outdated for a
random visitor.

Just a script that updates the date can backfire very badly if other site
areas look outdated in the eyes of a random visitor.

That is coming from the common pattern observed in usability studies - a
random visitor in "scanning mode" needs to decide quickly whether to trust
the site. Thus a lot of clutter is bad, no news is bad, the latest date in
the footer without noticeable news is bad.


An argument could be made that Clojure is aimed more at those who do
> that sort of "analytical comprehension" than those looking for the
> latest jazzy fad, but an argument could also be made that attracting a
> broader base is good and "jazzy fad" is a straw-man argument. :)
>

When people are looking for a new shiny thing among 100 of other just new
things, they can turn into "scanning mode" despite the fact that in other
conditions they " do
that sort of "analytical comprehension" "

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

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 4:22 AM, Sergey Didenko
 wrote:
>
>> Public relations -- Project status and activity. This area seems to
>> suggest the main Clojure page should be covered in tickers and feeds
>> of various kinds
>
> I think the main site needs just a pane with a big noticeable header "News",
> that shows one-two latest important stories and updates one time per 5-15
> days. Also has a link, a few links on where to read much more news (feeds
> for blogs, aggregators, twitters, etc). It's purpose not to "create
> clutter", but to give an impression that "Clojure" is not outdated for a
> random visitor.

I know what the purpose would be. And also what the effect would be if
it was done badly, say by cramming every remotely relevant news feed
onto the front page. :)

> Just a script that updates the date can backfire very badly if other site
> areas look outdated in the eyes of a random visitor.

?

> When people are looking for a new shiny thing among 100 of other just new
> things, they can turn into "scanning mode" despite the fact that in other
> conditions they " do
> that sort of "analytical comprehension" "

What other new shiny languages are there with any traction? Scala, and maybe F#?

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Aw: Re: How to add jar files to leiningen projects?

2011-07-12 Thread finbeu
Hi Shantanu,

thanks a lot for that! Looks great. I just downloaded it, but now lein 
doesn't work anymore. It fails on windows using lein.bat.

Even 

lein new blabla

fails

If I remove the plugin, lein works again.

Brgds,

- Finn

C:\Documents and Settings\finn.beutel\My Documents\Clojure\lein>"java" -
client  -Xbootclasspath/a:"C:\Documents and Settings\finn.beutel\.m2\rep
ository\org\clojure\clojure\1.2.1\clojure-1.2.1.jar"  
-Dleiningen.original.pwd="
C:\Documents and Settings\finn.beutel\My Documents\Clojure\lein"  -cp ""
"";".;%RSWJ%\Libs\rswa.jar";";C:\Documents and Settings\finn.beutel\.lein
\plugins\lein-localrepo-0.1.1.jar";"";test;src;"C:\Documents and 
Settings\finn.
beutel\.lein\self-installs\leiningen-1.6.0-standalone.jar"  clojure.main
-e "(use 'leiningen.core)(-main)" NUL
Exception in thread "main" java.lang.NoClassDefFoundError: and
Caused by: java.lang.ClassNotFoundException: and
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: and.  Program will exit.

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

2011-07-12 Thread Shantanu Kumar


On Jul 12, 1:17 pm, finbeu  wrote:
> Hi Shantanu,
>
> thanks a lot for that! Looks great. I just downloaded it, but now lein
> doesn't work anymore. It fails on windows using lein.bat.

It appears you are using Lein 1.6.0, which has a bug related to
RobertHook. Can you try downgrading to Lein 1.5.2?

Regards,
Shantanu

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


Re: Ring+Swank

2011-07-12 Thread Joost
On Jul 12, 7:27 am, Tarantoga  wrote:
> Hi all,
> I'd like to make a web-app to which I could connect using slime and
> make some changes there while the application is still running. How to
> start Swank-server from the working Ring-application?

The simplest way during development is to start swank (using
leiningen) first, and then load & start the web server from the REPL.
This ensures swank will start even if your code has a compilation
error somewhere.

Doing it the other way around isn't difficult either:

(require 'swank.swank)
(swank.swank/start-repl 4005) ; that's the standard swank port number

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

2011-07-12 Thread Colin Yates
"What other new shiny languages are there with any traction? Scala, and
maybe F#?"

"new" and "traction" are pretty subjective.  Sometimes (as in my case) the
searcher just needs enough to sell themselves on the tool they have already
chosen, i.e. just enough facts to fit my theory.

FWIW, I like clojure.org the way it is.  Without sounding like a complete
muppet, I think of Clojure as a set of surgeon's tools, all clean and layed
out on a shiny metal tray.  Minimalist, simple, clean and massively
effective once you have thought about it are the attributes I associate with
Clojure and clojure.org fits that.  On the other hand, I think of Scala as a
bunch of "handy man" tools in a bag, slightly less coherent, messy and a bit
more excitable and scala-lang.org re-enforces that.

My three lines of Clojure are significantly more than the zero lines of
scala I have written :)

On 12 July 2011 09:25, Ken Wesson  wrote:

> On Tue, Jul 12, 2011 at 4:22 AM, Sergey Didenko
>  wrote:
> >
> >> Public relations -- Project status and activity. This area seems to
> >> suggest the main Clojure page should be covered in tickers and feeds
> >> of various kinds
> >
> > I think the main site needs just a pane with a big noticeable header
> "News",
> > that shows one-two latest important stories and updates one time per 5-15
> > days. Also has a link, a few links on where to read much more news (feeds
> > for blogs, aggregators, twitters, etc). It's purpose not to "create
> > clutter", but to give an impression that "Clojure" is not outdated for a
> > random visitor.
>
> I know what the purpose would be. And also what the effect would be if
> it was done badly, say by cramming every remotely relevant news feed
> onto the front page. :)
>
> > Just a script that updates the date can backfire very badly if other site
> > areas look outdated in the eyes of a random visitor.
>
> ?
>
> > When people are looking for a new shiny thing among 100 of other just new
> > things, they can turn into "scanning mode" despite the fact that in other
> > conditions they " do
> > that sort of "analytical comprehension" "
>
> What other new shiny languages are there with any traction? Scala, and
> maybe F#?
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

2011-07-12 Thread Shantanu Kumar
As I am the culprit of having introduced it with a naive example, I'd
better admit it may not be very useful in practical scenarios across a
wide variety of use cases. For example, when there is an assertion
error with message "`m` should be a map" 14 levels down the stack, I'd
really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
so that I can debug it quickly.

Pre-conditions and Post-conditions are a valuable debugging aid, and
to enable that we need very precise information. Unfortunately passing
a string error message cannot encapsulate enough error context. A more
complex example can be where the correctness of input must be
determined collectively (in association with other args) -- in those
cases one can only fall back on comparing input values and raise
IllegalArgumentException accordingly.

Regards,
Shantanu

On Jul 11, 10:40 pm, Timothy Washington  wrote:
> Note: This message was originally posted by ' Shantanu' on the "*Re: Clojure
> for large programs*" thread.
>
> I took a look at  Shantanu's macros, and I like the concept a lot. But I
> would prefer something baked into the :pre condition itself. The reason is
> that it just removes a layer of indirection. If you dig into '*
> clj/clojure/core.clj*', you can see that the 'fn' macro is using 'assert' to
> test these conditions. Assert allows error messages to be applied, ie:
>
>    *user => (assert false) *
>
> *user => (assert false "fubar") *
>
> However, (defmacro fn ...) assumes that just the boolean condition is being
> passed in, A). But I'd like to have the option to pass in a message B).
>
> *A) *
>
> **
>
> *(def fubar *
>
> *  (fn []*
>
> *    {:pre [ (true? false) ] }*
>
> *    (println "Hello World")))*
>
> *(fubar)*
>
> *
> *
>
> *B) *
>
>    *(def thing *
>
> *  (fn []*
>
> *    {:pre [ [(true? false) "A false message"] ] }*
>
> *    (println "Hello World")))*
>
> *(thing)*
>
> I reworked the 'fn' macro, only for the :pre condition, as a demonstration 
> (see
> here ). The calling semantics don't change
> that much. Is there any interest in putting this into core? I'd
> use Shantanu's workaround otherwise, or in the interim.
>
> Thanks
>
> Tim Washington
> twash...@gmail.com
> 416.843.9060
>
> On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar 
> wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 3, 7:39 pm, Timothy Washington  wrote:
> > > I'm using pre / post assertions quite a bit in a project I'm building.
> > And I
> > > too would love to see better or custom error messages for each assertion.
>
> > That should be possible with a macro. For example, I use this:
>
> >https://bitbucket.org/kumarshantanu/clj-miscutil/src/acfb97c662d9/src...
>
> > Maybe you need something like this(?):
>
> > (defmacro verify-my-arg
> >  "Like assert, except for the following differences:
> >  1. does not check for *assert* flag
> >  2. throws IllegalArgumentException"
> >  [err-msg arg]
> >  `(if ~arg true
> >     (throw (IllegalArgumentException. ~err-msg
>
> > Then use it thus:
>
> > (defn foo [m]
> >  {:pre [(verify-my-arg "m must be a map" (map? m))]}
> >  (println m))
>
> > Regards,
> > Shantanu
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

2011-07-12 Thread Tarantoga
Thanks, that really works!

On Jul 12, 12:54 pm, Joost  wrote:
> On Jul 12, 7:27 am, Tarantoga  wrote:
>
> > Hi all,
> > I'd like to make a web-app to which I could connect using slime and
> > make some changes there while the application is still running. How to
> > start Swank-server from the working Ring-application?
>
> The simplest way during development is to start swank (using
> leiningen) first, and then load & start the web server from the REPL.
> This ensures swank will start even if your code has a compilation
> error somewhere.
>
> Doing it the other way around isn't difficult either:
>
> (require 'swank.swank)
> (swank.swank/start-repl 4005) ; that's the standard swank port number

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

2011-07-12 Thread Roman Roelofsen
Either this, or use the "when" form.
http://clojuredocs.org/clojure_core/clojure.core/when

2011/7/11 Tassilo Horn :
> Antonio Recio  writes:
>
> Hi Antonio,
>
>> I get the error "Too many arguments to if" with this. Do you have any
>> suggestion?
>
> `if' expects exacly one test, one then-form, and one else-form.  Your
> first and second `if' contain two forms in else.  You have to wrap them
> in a `do'.
>
> --8<---cut here---start->8---
> (defn make-tree [tree [n1 n2 n3 n4]]
>  (.addItem tree n1)
>  (if (empty? n2)
>    (.setChildrenAllowed tree n1 false)
>    (do
>      (doto tree
>        (.addItem n2)
>        (.setParent n2 n1)
>        (.expandItemsRecursively n1))
>      (if (empty? n3)
>        (.setChildrenAllowed tree n2 false)
>        (do
>          (doto tree
>            (.addItem n3)
>            (.setParent n3 n2)
>            (.expandItemsRecursively n2))
>          (if (empty? n4)
>            (.setChildrenAllowed tree n3 false)
>            (do
>              (doto tree
>                (.addItem n4)
>                (.setParent n4 n3)
>                (.expandItemsRecursively n3)
>                (.setChildrenAllowed n4 false)
>                tree
> --8<---cut here---end--->8---
>
> 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

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


Aw: Re: How to add jar files to leiningen projects?

2011-07-12 Thread finbeu
Yeah! I downgraded to 1.5.2 and now it works. 

Thanks a lot. Really nice.

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

2011-07-12 Thread Adam Burry
On Jul 12, 7:58 am, Colin Yates  wrote:
> FWIW, I like clojure.org the way it is.  Without sounding like a complete
> muppet, I think of Clojure as a set of surgeon's tools, all clean and layed
> out on a shiny metal tray.  Minimalist, simple, clean and massively
> effective once you have thought about it are the attributes I associate with
> Clojure and clojure.org fits that.  On the other hand, I think of Scala as a
> bunch of "handy man" tools in a bag, slightly less coherent, messy and a bit
> more excitable and scala-lang.org re-enforces that.

You've never seen a surgery up close.

Many of the tools are wrapped in plastic and you need a helper to find
them, open them, hand them to you, and clean them. You've got so many
layers on you can't feel anything. The patient is moaning with pain
and draped in so much stuff you can hardly tell they are human. And
for big jobs you use the same Black and Decker tools that home
builders use.

Adam

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

2011-07-12 Thread Colin Yates
That sounds more like Enterprise Java Development to me :)

On 12 July 2011 13:20, Adam Burry  wrote:

> On Jul 12, 7:58 am, Colin Yates  wrote:
> > FWIW, I like clojure.org the way it is.  Without sounding like a
> complete
> > muppet, I think of Clojure as a set of surgeon's tools, all clean and
> layed
> > out on a shiny metal tray.  Minimalist, simple, clean and massively
> > effective once you have thought about it are the attributes I associate
> with
> > Clojure and clojure.org fits that.  On the other hand, I think of Scala
> as a
> > bunch of "handy man" tools in a bag, slightly less coherent, messy and a
> bit
> > more excitable and scala-lang.org re-enforces that.
>
> You've never seen a surgery up close.
>
> Many of the tools are wrapped in plastic and you need a helper to find
> them, open them, hand them to you, and clean them. You've got so many
> layers on you can't feel anything. The patient is moaning with pain
> and draped in so much stuff you can hardly tell they are human. And
> for big jobs you use the same Black and Decker tools that home
> builders use.
>
> Adam
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Results from 2011 State of Clojure survey

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 8:20 AM, Adam Burry  wrote:
> You've never seen a surgery up close.
>
> Many of the tools are wrapped in plastic and you need a helper to find
> them, open them, hand them to you, and clean them. You've got so many
> layers on you can't feel anything. The patient is moaning with pain

Let me know which hospital you went to so I can avoid ever traveling
there. Obviously their anesthesiologists aren't worth the paper their
degrees are printed on.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Sergey Didenko
You know that from inside. A Clojure "outsider" can have a completely other
point of view.

He can choose between Python, server side Javascript, new C#, Go, Scala, F#,
Haskell, Erlang, haXe, Clojure.

Besides the languages itself, the "outsider" wants to evaluate libraries,
community, platforms, support, etc.

That could be much more challenging than comparing a few bare languages.

On Tue, Jul 12, 2011 at 11:25 AM, Ken Wesson  wrote:

> > When people are looking for a new shiny thing among 100 of other just new
> > things, they can turn into "scanning mode" despite the fact that in other
> > conditions they " do
> > that sort of "analytical comprehension" "
>
> What other new shiny languages are there with any traction? Scala, and
> maybe F#?

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

2011-07-12 Thread Colin Yates
"Besides the languages itself, the "outsider" wants to evaluate libraries,
community, platforms, support, etc.
That could be much more challenging than comparing a few bare languages."

Absolutely!  I asked a couple of times for recommendations, and was quite
surprised at the lack of forthcoming recommendations.

The dilemna that I am for-ever battling is "get something done in a poor way
now" or "invest in something so we can do it better in the future".
 Adopting Clojure is definitely in the second camp (for me), and the lack of
knowing which supporting libraries (for example) to use makes it more of an
expense.

Of course, what I want to do is plough that ground myself and produce a
single "101 Enterprise Clojure Development" but time time time.  The
professional me wants/needs it done for me, the geek in me wants to do it
myself and give back to the community.

(since I opened the door :)): my current thoughts are:

 - clojure 1.3 (complete with integration pain with 1.2 libraries)
 - maven 2 (with maven 3 polyglot once it is stablised and publicly
available) with the clojure-maven plugin
 - bamboo (hence the maven decision rather than cake or lein) for CI and
release management
 - cucumber for higher level "does it do the requirements" tests (not
getting hung up on the highly overloaded testing terminology)
 - lazy-test for "does the code do what the developer expects" tests
 - emacs/slime for coding
 - some ring based web framework (probably clojure)
 - either mongodb or a graph database for persistence (need to determine the
inter-relatedness of the graphs)
 - the venerable git
 - one of the gazillion high quality Clojure libraries on github

As an enterprise developer I need to be able to come to those conclusions
myself, of course, but some sign posts would be very useful.
http://planet.clojure.in/,
http://ericlavigne.wordpress.com/2011/01/30/a-tour-of-the-clojure-landscape/
, http://www.clojure-toolbox.com/ etc. are very useful points.

The more I look, the more I am extremely impressed by the high quality blogs
around Clojure, in particular http://cemerick.com, although that is one of
many.

(still only 3 lines of Clojure written!)

On 12 July 2011 13:55, Sergey Didenko  wrote:

> You know that from inside. A Clojure "outsider" can have a completely other
> point of view.
>
> He can choose between Python, server side Javascript, new C#, Go, Scala,
> F#, Haskell, Erlang, haXe, Clojure.
>
> Besides the languages itself, the "outsider" wants to evaluate libraries,
> community, platforms, support, etc.
>
> That could be much more challenging than comparing a few bare languages.
>
>
> On Tue, Jul 12, 2011 at 11:25 AM, Ken Wesson  wrote:
>
>> > When people are looking for a new shiny thing among 100 of other just
>> new
>> > things, they can turn into "scanning mode" despite the fact that in
>> other
>> > conditions they " do
>> > that sort of "analytical comprehension" "
>>
>> What other new shiny languages are there with any traction? Scala, and
>> maybe F#?
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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

monads > macros

2011-07-12 Thread James Keats

I'm mildly concerned about macros being seen as the "secret weapon" of
clojure(/lisp).

In their place, i wish monads would get a wider attention and embrace.

Discuss? :-)

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

2011-07-12 Thread Tamreen Khan
Are monads all that special? My understanding is that even in Haskell
its wise to not use monads all that much, since it starts to make the
code look a little too imperative if not wielded correctly. They're
not really the meat of haskell/fp. Macros on the other hand are an
important part of lisp, although their overuse is also discouraged :)

On Tuesday, July 12, 2011, James Keats  wrote:
>
> I'm mildly concerned about macros being seen as the "secret weapon" of
> clojure(/lisp).
>
> In their place, i wish monads would get a wider attention and embrace.
>
> Discuss? :-)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: monads > macros

2011-07-12 Thread James Keats


On Jul 12, 2:36 pm, Tamreen Khan  wrote:
> Are monads all that special? My understanding is that even in Haskell
> its wise to not use monads all that much, since it starts to make the
> code look a little too imperative if not wielded correctly. They're
> not really the meat of haskell/fp. Macros on the other hand are an
> important part of lisp, although their overuse is also discouraged :)
>

My humble understanding is that macros complicate composability,
whereas monads facilitate 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: How to add jar files to leiningen projects?

2011-07-12 Thread Mark Rathwell
Works great, Shantanu.  Thanks!

On Tue, Jul 12, 2011 at 3:12 AM, Shantanu Kumar wrote:

> > It would be ideal if it could be run outside of the project structure, as
> > would be the case if an additional arity was added to the install
> function
> > in leiningen.install.
>
> Thanks for the report -- I have pushed version 0.1.1 so it should now
> be possible to install it as a plugin and run from any directory.
>
> Regards,
> Shantanu
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

2011-07-12 Thread David Nolen
On Tue, Jul 12, 2011 at 9:40 AM, James Keats wrote:

>
>
> On Jul 12, 2:36 pm, Tamreen Khan  wrote:
> > Are monads all that special? My understanding is that even in Haskell
> > its wise to not use monads all that much, since it starts to make the
> > code look a little too imperative if not wielded correctly. They're
> > not really the meat of haskell/fp. Macros on the other hand are an
> > important part of lisp, although their overuse is also discouraged :)
> >
>
> My humble understanding is that macros complicate composability,
> whereas monads facilitate it.
>

Monads bring their own composability issues. Read up on monad transformers
and how they result in complexities like the monad zipper.

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: monads > macros

2011-07-12 Thread László Török
2011/7/12 David Nolen 

> On Tue, Jul 12, 2011 at 9:40 AM, James Keats wrote:
>
>>
>>
>> On Jul 12, 2:36 pm, Tamreen Khan  wrote:
>> > Are monads all that special? My understanding is that even in Haskell
>> > its wise to not use monads all that much, since it starts to make the
>> > code look a little too imperative if not wielded correctly. They're
>> > not really the meat of haskell/fp. Macros on the other hand are an
>> > important part of lisp, although their overuse is also discouraged :)
>> >
>>
>> My humble understanding is that macros complicate composability,
>> whereas monads facilitate it.
>>
>
> Monads bring their own composability issues. Read up on monad transformers
> and how they result in complexities like the monad zipper.
>
+1
plus read Jim Duey's http://intensivesystems.net/writings.html then try to
write code with monads...you can spend a week trying to fit the pieces
together, i'm not sure the holy grail of composability (whatever that means
to you) is worth the investment

Las


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



-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

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

2011-07-12 Thread Justin Ko


On Jul 11, 2:12 pm, Max Weber  wrote:
> Hi,
>
> I like to write some integration/acceptance tests in Clojure. At the moment
> I'm using cuke4duke (cucumber), but I'm not satisfied with it. For my unit

"When I’m done with the book I will pick up the work on a pure Java
implementation that will supersede Cuke4Duke"

http://aslakhellesoy.com/post/6734058541/cucumber-one-oh

> tests I'm already using lazytest. In the acceptance tests I like to apply
> the typical Given When Then template (like cucumber do). So are there any
> nice alternatives to cucumber/cuke4duke?
>
> I know circumspec , but the
> project makes no progress anymore? What is the relationship between
> circumspec and lazytest ? How can
> acceptance tests be written with lazytest, which follow the Given When Then
> template (like 
> thiscircumspec
> example)?
>
> Best regards
>
> Max

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


Convert HTML to Vector Notation

2011-07-12 Thread Asim Jalis
Is there a way to convert a large HTML document to a vector notation.
So something that converts "Hello" to [:n1
{:a1 = "v1"} [:n2 "Hello]].

I am using hiccup to generate HTML and need a way to convert existing
HTML templates to the hiccup format.

Thanks!

Asim

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

2011-07-12 Thread David Santiago
Check out the library clj-tagsoup: https://github.com/nathell/clj-tagsoup

   David

On Tue, Jul 12, 2011 at 11:10 AM, Asim Jalis  wrote:
> Is there a way to convert a large HTML document to a vector notation.
> So something that converts "Hello" to [:n1
> {:a1 = "v1"} [:n2 "Hello]].
>
> I am using hiccup to generate HTML and need a way to convert existing
> HTML templates to the hiccup format.
>
> Thanks!
>
> Asim
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: monads > macros

2011-07-12 Thread Thorsten Wilms

On 07/12/2011 03:28 PM, James Keats wrote:


I'm mildly concerned about macros being seen as the "secret weapon" of
clojure(/lisp).

In their place, i wish monads would get a wider attention and embrace.


Do you want to suggest that it would be common that an issue can be 
solved with either a macro or a monad,

or is it all about attention and how often one or the other is mentioned?

At least some monads, even if not called so, are present in lots of 
languages. But good macro functionality is typical for lisps.


It's not my perception that there is a lot of noise about macros, 
whereas articles about monads are like bunnies and have taken to the 
meta-level.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.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: monads > macros

2011-07-12 Thread Alan Malloy
On Jul 12, 9:33 am, Thorsten Wilms  wrote:
> It's not my perception that there is a lot of noise about macros,
> whereas articles about monads are like bunnies and have taken to the
> meta-level.

I was going to write an article about how to use monads to simplify
the implementation of the code for your monad+macro article, but it
sounds like someone's beaten me to 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: monads > macros

2011-07-12 Thread Raoul Duke
>> In their place, i wish monads would get a wider attention and embrace.

please y'all note that there's much more to
category-theory-in-programming-languages than just monads. :-)

http://www.haskell.org/haskellwiki/Typeclassopedia

sincerely.

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

2011-07-12 Thread Mike Meyer
On Mon, 11 Jul 2011 20:49:01 -0400
Ken Wesson  wrote:

> On Mon, Jul 11, 2011 at 7:39 PM, Mike Meyer  wrote:
> > On Mon, 11 Jul 2011 07:51:33 -0400
> > Ken Wesson  wrote:
> >
> >> On Sun, Jul 10, 2011 at 2:01 AM, mike.w.me...@gmail.com  
> >> wrote:
> >> [snip most of post whose sole purpose seems to be to gainsay anything I 
> >> write]
> >
> > Because in that article, you were (unusual for you) way off base.
> 
> As you say, it would be unusual for me if that were the case -- good
> reason to suspect that perhaps I wasn't, but rather was
> misinterpreted, or something.

You write clearly enough that misinterpretation isn't likely. You were
simply making false statements.

> > SQL doesn't have a position anything like HTTP GET/POST syntax.
> 
> Sure it does. Queries are bundled into a wire protocol and sent over
> the network in pretty much every system I've seen that used a
> database. You have the web server over *here*, and it is visible to
> the internet because the gateway forwards port 80 to it *here*; it
> talks over the LAN to the DBMS over *here* to run various queries and
> build a page to serve ...
> 
> > HTTP's GET/POST syntax is a wire protocol.
> 
> HTTP is a wire protocol. The syntax of GET/POST requests is carried on
> that protocol (as are HTML files and other files sent back to the
> client) but is not the protocol itself.
> 
> > Once you it, you can write code to talk to a server, and get a
> > response.
> 
> Not if all you know is "GET /index.html". You need to speak HTTP and
> then send that.

If all you know is "GET /index.html", then you don't know the syntax
of the HTTP GET statement. The terminator - a pair of line endings -
is part of the syntax. If you send that string and the terminator to
an HTTP server, it should send back the contents of index.html.

> > If you know SQL, you can't use a database *at all*. You have
> > to know an API for the database in question
> Just as you need to know HTTP and not just "GET /index.html". The
> difference here is that the databases haven't all settled on one
> embedding, analogous to HTTP, for the SQL requests, but all the
> vendors use their own different one.

Sorry, but "GET /index.html" *is* HTTP. Oh, it's not all of it, by any
means - but it's enough to talk to a server.  A much closer analogy
would be that SQL is like the URL syntax in the HTTP GET/POST
request. Knowing the URL isn't enough to talk to a web server. You
have to know the wire protocol, or the API for a library that
implements it for you.

> > Last time I looked, there wasn't a standard wire protocol
> > for SQL servers.
> Which doesn't change much of anything. There's HTTP 1.0 and HTTP 1.1
> for web servers for that matter, though mostly you can ignore the
> differences and, indeed, these days HTTP 1.0 as a whole. It's not hard
> to imagine a world where a non-HTTP protocol became a rival to HTTP,
> either -- for instance, one with built-in support for mirroring of
> static content instead of having to fudge around with things like
> Akamai for that, perhaps even one where individual browsers made parts
> of their caches (not https stuff, though, obviously, or form contents)
> available automatically as alternative sources to take some of the
> load off central servers and possibly even maintain some availability
> when they were down. If that were to happen, would the things that
> interpret GET requests suddenly stop qualifying for being considered
> to be "servers"?

Only if they also stopped listening for requests on something like a
socket. Which was your objection to running a repository: you think it
means you have to have something listening on a socket. This isn't the
case. In particular, it isn't the case for the maven repository that
was being recommended as a solution to the problem.

 http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

2011-07-12 Thread Konrad Hinsen

On 12 Jul 2011, at 15:40, James Keats wrote:


My humble understanding is that macros complicate composability,
whereas monads facilitate it.


The composability issue with macros lies in writing them, not using  
them. Monads are all about composing computations with specific  
properties, where the monad abstracts away those properties. But I  
don't see any common point between macros and monads other than that  
both words start with 'm'.


One approach that has been proposed to improve composability of macros  
is to adopt a continuation-passing style. This would make macros a  
candidate for the continuation monad, so perhaps monads may be of use  
in implementing complex macros.


Konrad.

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


Re: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Mike Meyer
On Mon, 11 Jul 2011 21:12:20 -0400
Ken Wesson  wrote:

> On Mon, Jul 11, 2011 at 7:51 PM, Mike Meyer  wrote:
> > On Mon, 11 Jul 2011 16:21:45 -0400
> > Ken Wesson  wrote:
> >> > So, "repository" does not imply "server" at all,
> >> This is getting silly. "Repository" is a word that brings immediately
> >> to mind typing checkin and checkout commands at a command prompt in
> >> order to work on source code that is stored remotely. And remotely
> >> implies "server".
> >
> > I was with you until you said "stored remotely".
> there's also a "server" in there, or even multiple servers. The
> alternatives I can think of are:
> 
> 1. One developer, one computer.
> 
> 2. Many developers, one computer. No "remote storage" and if the
> developers are co-located no server; otherwise a terminal server. The
> former is obviously not parallelizable (though edit conflicts are thus
> a non-issue -- single global lock FTW!!!1!1) and the latter is a
> throwback to the 1980s or earlier. :)

Most systems that support such a model - and yes, they're still being
both developed and used - are well enough written to avoid a single
global lock.

> 3. Many computers, one developer

> 4. An ad hoc, peer-to-peer system with many evolving versions of the
> codebase and patches swapped back and forth

This is the model used by the Linux kernel, among others. You might
argue that one of Linus's repositories is a "master" copy, as that's
the one that Linux kernel releases are cut from, but that's really the
only thing that distinguishes it from any of the others. Each
developer gets to decide where they want to take patches from and
which patches they're actually going to use in any given build, but
most can't put code in the so-called "master" repository.

> So, unless 4 can be made workable, 

I'd say a project with 14 million LOC and thousands of developers
using it for five years demonstrates that it's both workable and
scalable.

   http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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


Odp: Re: Convert HTML to Vector Notation

2011-07-12 Thread Daniel Janus
Hey, thanks for recommending my library! :-)

Best,
Daniel

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

Re: monads > macros

2011-07-12 Thread Christian Marks


On Jul 12, 9:28 am, James Keats  wrote:
> I'm mildly concerned about macros being seen as the "secret weapon" of
> clojure(/lisp).
> In their place, i wish monads would get a wider attention and embrace.
>
> Discuss? :-)

What is your concern, specifically? I don't see a position being
articulated.  Can you cite the relevant literature on type theory
and macros?

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

2011-07-12 Thread Alan Malloy
On Jul 12, 12:01 pm, Konrad Hinsen  wrote:
> The composability issue with macros lies in writing them, not using them.

Strongly disagree. Macros compose reasonably well when writing them
(eg, using let in the implementation of with-open is trivial); it's
composing already-written macros with other pieces of your codebase
that's hard. (reduce and xs) won't test that every element of xs is
truthy, because and is a macro and thus can't be used as a higher-
order function.

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


help with some code

2011-07-12 Thread Paul Meehan

Hi

I was wondering if anyone could shed some light on the 
following code:


(def alist '(1  fn [x y](+ x y)))

(apply (second alist) '(1 3))

The result at REPL is 3 i.e. the second element of '(1 3).

Should the result not be 4 i.e. the result of applying the 
arguments 1 and 3 to the anonymous function?



thanks
Paul C. Meehan

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


Help with some code

2011-07-12 Thread Paul Meehan

Hi

I was wondering if anyone could shed some light on the
following code:

(def alist '(1  fn [x y](+ x y)))

(apply (second alist) '(1 3))

The result at REPL is 3 i.e. the second element of '(1 3).

Should the result not be 4 i.e. the result of applying the
arguments 1 and 3 to the anonymous function?

thanks
Paul C. Meehan

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

2011-07-12 Thread Benny Tsai
alist is missing parens around the fn, so it's really a list of 4 elements 
like so:

  (1, fn, [x y], (+ x y))

So (second alist) returns just the symbol 'fn.  And when you apply a Symbol 
to a list, the result is the last item in the list (not sure why).

To do what you want, alist should be defined like this:

  (def alist '(1 (fn [x y] (+ x y

Also, it seems that the definition of the function needs to be eval'ed first 
to become an apply-able function.  The following returns 4 in my REPL:

  (apply (eval (second alist)) '(1 3))

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

2011-07-12 Thread Benny Tsai
Hi Paul,

I posted an answer to your question in the "monads > macros" discussion.

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

Re: help with some code

2011-07-12 Thread Joop Kiefte
Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+ x y be better?
Then you don't need the eval :)

2011/7/12 Benny Tsai 

> alist is missing parens around the fn, so it's really a list of 4 elements
> like so:
>
>
>   (1, fn, [x y], (+ x y))
>
> So (second alist) returns just the symbol 'fn.  And when you apply a Symbol
> to a list, the result is the last item in the list (not sure why).
>
> To do what you want, alist should be defined like this:
>
>   (def alist '(1 (fn [x y] (+ x y
>
> Also, it seems that the definition of the function needs to be eval'ed
> first to become an apply-able function.  The following returns 4 in my REPL:
>
>   (apply (eval (second alist)) '(1 3))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: help with some code

2011-07-12 Thread Benny Tsai
Nice, yes, that works just as well :)

On Tuesday, July 12, 2011 4:09:09 PM UTC-6, LaPingvino wrote:
>
> Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+ x y be better? 
> Then you don't need the eval :)
>
> 2011/7/12 Benny Tsai 
>
>> alist is missing parens around the fn, so it's really a list of 4 elements 
>> like so:
>>
>>
>>   (1, fn, [x y], (+ x y))
>>
>> So (second alist) returns just the symbol 'fn.  And when you apply a 
>> Symbol to a list, the result is the last item in the list (not sure why).
>>
>> To do what you want, alist should be defined like this:
>>
>>   (def alist '(1 (fn [x y] (+ x y
>>
>> Also, it seems that the definition of the function needs to be eval'ed 
>> first to become an apply-able function.  The following returns 4 in my REPL:
>>
>>   (apply (eval (second alist)) '(1 3))
>>  
>> -- 
>> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 2:31 PM, Mike Meyer  wrote:
> You write clearly enough that misinterpretation isn't likely. You were
> simply making false statements.

I do not do that, and I won't tolerate being called names and
badmouthed in public. This discussion is over.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: help with some code

2011-07-12 Thread Paul Meehan
Cheers guys - still getting to grips with Clojure, but 
getting there.


On 07/12/2011 23:13, Benny Tsai wrote:

Nice, yes, that works just as well :)

On Tuesday, July 12, 2011 4:09:09 PM UTC-6, LaPingvino wrote:

Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+
x y be better? Then you don't need the eval :)

2011/7/12 Benny Tsai 

alist is missing parens around the fn, so it's
really a list of 4 elements like so:


  (1, fn, [x y], (+ x y))

So (second alist) returns just the symbol 'fn.
 And when you apply a Symbol to a list, the result
is the last item in the list (not sure why).

To do what you want, alist should be defined like
this:

  (def alist '(1 (fn [x y] (+ x y

Also, it seems that the definition of the function
needs to be eval'ed first to become an apply-able
function.  The following returns 4 in my REPL:

  (apply (eval (second alist)) '(1 3))
-- 
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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be 
patient with your first post.

To unsubscribe from 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: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 3:11 PM, Mike Meyer  wrote:
> On Mon, 11 Jul 2011 21:12:20 -0400
> Ken Wesson  wrote:
>> 2. Many developers, one computer. No "remote storage" and if the
>> developers are co-located no server; otherwise a terminal server. The
>> former is obviously not parallelizable (though edit conflicts are thus
>> a non-issue -- single global lock FTW!!!1!1) and the latter is a
>> throwback to the 1980s or earlier. :)
>
> Most systems that support such a model - and yes, they're still being
> both developed and used - are well enough written to avoid a single
> global lock.

Another misunderstanding. Many developers working at one physical,
co-located computer has the keyboard and monitor as "a single global
lock". In the terminal server case there could be a finer locking
granularity. As for "still developed and used", what for? Perhaps
top-secret stuff where they really want to guard against the code
leaking? I guess they might use this model to develop the code that
runs on Predator drones, or something, not because more modern methods
don't exist but because more secure methods don't exist; the code
never leaves the one server and really robust credentials can be
checked before someone can log in to even view it there, AND they get
a log of the IP address of everyone who does see it. Trying to leak it
would be a pain involving copying one screenful, pasting it,
scrolling, etc. And access could be further limited to a LAN inside a
high security facility with armed guards and code-locked physical
doors.

However, another outlier exception rather than example of typical
software development and repository use. :)

>> 4. An ad hoc, peer-to-peer system with many evolving versions of the
>> codebase and patches swapped back and forth
>
> This is the model used by the Linux kernel, among others. You might
> argue that one of Linus's repositories is a "master" copy, as that's
> the one that Linux kernel releases are cut from, but that's really the
> only thing that distinguishes it from any of the others. Each
> developer gets to decide where they want to take patches from and
> which patches they're actually going to use in any given build, but
> most can't put code in the so-called "master" repository.

Which means it's not really case 4 at all. ANY open source project
potentially has "eccentric patches" circulate among techie users and
developers that don't appear in the master branch -- at the very least
if they want to give a patch extensive testing before committing it to
master, then several developers might apply it to their local versions
for a while and see how things go.

>> So, unless 4 can be made workable,
>
> I'd say a project with 14 million LOC and thousands of developers
> using it for five years demonstrates that it's both workable and
> scalable.

Except that it has an official build repository with more stringent
criteria for what gets in there, so not really.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 8:55 AM, Sergey Didenko
 wrote:
> You know that from inside. A Clojure "outsider" can have a completely other
> point of view.
>
> He can choose between Python

Not new

> server side Javascript

Not new

> new C#

Despite what you just said, not new

> Go

Haven't heard of it, so probably not shiny enough

> Scala, F#

Mentioned those

> Haskell

Not new

> Erlang

Not new

> haXe

Haven't heard of it, so probably not shiny enough

> Clojure.

So far, looks like the "shiny and new" category is Clojure, Scala, F#,
and maybe one or both of the Go and haXe you mentioned. The rest
definitely aren't particularly new.

> Besides the languages itself, the "outsider" wants to evaluate libraries,
> community, platforms, support, etc.

That puts Clojure and Scala ahead of F# and the three of them ahead of
nearly everything else.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Tamreen Khan
What does something being shiny and new have to do with how good its
libraries, community, platforms, and support are? Heck, I'd say something
being new would detract from it library-wise. Sergey's point was that when
someone begins a new project they have the options of all those languages;
Clojure isn't just competing with new and shiny things.

On Tue, Jul 12, 2011 at 6:23 PM, Ken Wesson  wrote:

> On Tue, Jul 12, 2011 at 8:55 AM, Sergey Didenko
>  wrote:
> > You know that from inside. A Clojure "outsider" can have a completely
> other
> > point of view.
> >
> > He can choose between Python
>
> Not new
>
> > server side Javascript
>
> Not new
>
> > new C#
>
> Despite what you just said, not new
>
> > Go
>
> Haven't heard of it, so probably not shiny enough
>
> > Scala, F#
>
> Mentioned those
>
> > Haskell
>
> Not new
>
> > Erlang
>
> Not new
>
> > haXe
>
> Haven't heard of it, so probably not shiny enough
>
> > Clojure.
>
> So far, looks like the "shiny and new" category is Clojure, Scala, F#,
> and maybe one or both of the Go and haXe you mentioned. The rest
> definitely aren't particularly new.
>
> > Besides the languages itself, the "outsider" wants to evaluate libraries,
> > community, platforms, support, etc.
>
> That puts Clojure and Scala ahead of F# and the three of them ahead of
> nearly everything else.
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

2011-07-12 Thread Paul Meehan

Sorry to repoen the discussion, but I got this:

=> (def alist '(1 ~(fn [x y](+ x y
#'user/alist

=> (apply (second alist) '(1 3))

#clojure.lang.Cons cannot be cast to clojure.lang.IFn 
(NO_SOURCE_FILE:0)>


On 07/12/2011 23:13, Benny Tsai wrote:

Nice, yes, that works just as well :)

On Tuesday, July 12, 2011 4:09:09 PM UTC-6, LaPingvino wrote:

Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+
x y be better? Then you don't need the eval :)

2011/7/12 Benny Tsai 

alist is missing parens around the fn, so it's
really a list of 4 elements like so:


  (1, fn, [x y], (+ x y))

So (second alist) returns just the symbol 'fn.
 And when you apply a Symbol to a list, the result
is the last item in the list (not sure why).

To do what you want, alist should be defined like
this:

  (def alist '(1 (fn [x y] (+ x y

Also, it seems that the definition of the function
needs to be eval'ed first to become an apply-able
function.  The following returns 4 in my REPL:

  (apply (eval (second alist)) '(1 3))
-- 
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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be 
patient with your first post.

To unsubscribe from 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: help with some code

2011-07-12 Thread Bronsa
this is because in order to use ~ to evaluate the fn, you need to use the
backtick ` instead of the single quote '
Il giorno 13/lug/2011 00.34, "Paul Meehan"  ha scritto:
>
> Sorry to repoen the discussion, but I got this:
>
>
> => (def alist '(1 ~(fn [x y](+ x y
> #'user/alist
>
> => (apply (second alist) '(1 3))
>
> #
>
>
> On 07/12/2011 23:13, Benny Tsai wrote:
>>
>> Nice, yes, that works just as well :)
>>
>> On Tuesday, July 12, 2011 4:09:09 PM UTC-6, LaPingvino wrote:
>>>
>>> Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+ x y be better?
Then you don't need the eval :)
>>>
>>> 2011/7/12 Benny Tsai 

 alist is missing parens around the fn, so it's really a list of 4
elements like so:


   (1, fn, [x y], (+ x y))

 So (second alist) returns just the symbol 'fn.  And when you apply a
Symbol to a list, the result is the last item in the list (not sure why).

 To do what you want, alist should be defined like this:

   (def alist '(1 (fn [x y] (+ x y

 Also, it seems that the definition of the function needs to be eval'ed
first to become an apply-able function.  The following returns 4 in my REPL:

   (apply (eval (second alist)) '(1 3))
 --
 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 post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
your first post.
>> To unsubscribe from 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: help with some code

2011-07-12 Thread Benny Tsai
For that method, you need a back-quote ` (used in macro definition) in front 
of the 1, not a single quote ' (used to make a form data instead of code).

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

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 6:27 PM, Tamreen Khan  wrote:
> What does something being shiny and new have to do with how good its
> libraries, community, platforms, and support are?

See below.

> Heck, I'd say something being new would detract from it library-wise.

Not necessarily, if it can interoperate with existing libraries, such
as is often the case with new JVM languages that can use existing Java
libraries.

> Sergey's point was that when
> someone begins a new project they have the options of all those languages;
> Clojure isn't just competing with new and shiny things.

In Sergey's own words:

When people are looking for a new shiny thing among 100 of
other just new things, they can turn into "scanning mode"
despite the fact that in other conditions they "do that sort of
"analytical comprehension""

So the discussion was specifically about a hypothetical developer
checking out *new* things. That developer probably already knows about
(and has rejected, for whatever reasons) C#, Python, Javascript, etc.
(aside from whatever they're currently using, but may want to move
beyond or supplement).

It's not hard to think up the likely objections from a lot of people,
too, and why they'd be looking for something new:

C#: Microsoft; no complete free software implementation

Python: poor performance

Javascript: interpreted, so slow; "isn't this just for adding annoying
ads to web pages"?; "I turn that shit off in my browser, why would I
want to actually write the stuff?" :)

Haskell: in its own universe without familiar tools and libraries;
ditto Scheme, Common Lisp, Smalltalk

Erlang: too different (but this is also likely to be leveled at Lisps
including Clojure).

C, C++: Pointer arithmetic, SIGSEGV, what is this, the dark ages?
Sounds like the goddamned Spanish inquisition!

Java: verbose, you need to write three classes and implement a whole
passel of interfaces, dependency inject a few megabytes of XML, and
apply the Singleton, Visitor, and Iterator patterns just to blow your
nose in this language.


Of course, there are others whose objections are much simpler:

C#: Not Lisp.

Erlang: Not Lisp.

Java: Not Lisp.

Python: List comprehensions and first class functions, but where are
my macros? Not Lisp.

Javascript: eval works on *strings*? You have *got* to be kidding me.
Not Lisp. Next!

Haskell: A bit like Scheme and it even has monads but syntaxy, with
type warts everywhere and no macros. So, not Lisp.

Smalltalk: the BlockContext lacks some of the capabilities of true
first class functions and *where* are my macros? Not Lisp.

C, C++: function pointers but no ability to declare anonymous
functions that close over locals and return them? And what the hell
kind of macro system is THAT?! Sorry. Not Lisp.

;)

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Mike Meyer
On Tue, 12 Jul 2011 18:13:57 -0400
Ken Wesson  wrote:

> On Tue, Jul 12, 2011 at 2:31 PM, Mike Meyer  wrote:
> > You write clearly enough that misinterpretation isn't likely. You were
> > simply making false statements.
> 
> I do not do that, and I won't tolerate being called names and
> badmouthed in public. This discussion is over.

I'm sorry, I didn't mean to imply that you were lying.  I'm sure you
thought the statements were true. You were just wrong in this case.

 http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

2011-07-12 Thread Mike Meyer
On Tue, 12 Jul 2011 18:20:38 -0400
Ken Wesson  wrote:

> On Tue, Jul 12, 2011 at 3:11 PM, Mike Meyer  wrote:
> > On Mon, 11 Jul 2011 21:12:20 -0400
> > Ken Wesson  wrote:
> >> 2. Many developers, one computer. No "remote storage" and if the
> >> developers are co-located no server; otherwise a terminal server. The
> >> former is obviously not parallelizable (though edit conflicts are thus
> >> a non-issue -- single global lock FTW!!!1!1) and the latter is a
> >> throwback to the 1980s or earlier. :)
> >
> > Most systems that support such a model - and yes, they're still being
> > both developed and used - are well enough written to avoid a single
> > global lock.
> 
> Another misunderstanding. Many developers working at one physical,
> co-located computer has the keyboard and monitor as "a single global
> lock". In the terminal server case there could be a finer locking
> granularity. As for "still developed and used", what for? 

What makes you think a computer can have only a single
keyboard/monitor? After all, what is a terminal server but a computer
with lots of keyboard/monitors that routes the terminals out to
network servers of some kind? But this is all irrelevant - from the
point of view of an application, it doesn't make any difference if
someone is issuing commands from a device directly connected to the
hardware, from a device connected to a terminal server, or sitting at
a second computer and connected back to the single computer where the
work is being done.

Which is why such things are still being developed. There's
fundamentally no difference between many developers running commands
on the single computer to manipulate the data and many developers
running clients that talk to apache running on that single computer
and causing it to issue those commands. This lets a developer leverage
the apache networking code to create a client/server model, and most
modern SCMs can be run that way.

> >> 4. An ad hoc, peer-to-peer system with many evolving versions of the
> >> codebase and patches swapped back and forth
> >
> > This is the model used by the Linux kernel, among others. You might
> > argue that one of Linus's repositories is a "master" copy, as that's
> > the one that Linux kernel releases are cut from, but that's really the
> > only thing that distinguishes it from any of the others. Each
> > developer gets to decide where they want to take patches from and
> > which patches they're actually going to use in any given build, but
> > most can't put code in the so-called "master" repository.
> 
> Which means it's not really case 4 at all.

Well, it's very clearly not cases 1, 2 or 3. There are many developers
and many computers, and case 4 is the only one that allows for
that. So this is either case 4, or you need to provide another case
for it.

> >> So, unless 4 can be made workable,
> >
> > I'd say a project with 14 million LOC and thousands of developers
> > using it for five years demonstrates that it's both workable and
> > scalable.
> Except that it has an official build repository with more stringent
> criteria for what gets in there, so not really.

Half right. As I said, it's got one repository that the official
builds come from. Other people are free use builds from their own
repositories, and often do - I don't think any of the GNU/Linux
distributions actually use binaries built by Linus. Instead, they each
have their own "master" repository from which they do their "official"
builds.

However, the criteria for what gets into that so-called "master"
repository are no more stringent than for any other repository in the
project: only patches the owner wants get in.

  http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

2011-07-12 Thread David Santiago
No problem. It's a key piece of one of my own libraries, so thank
goodness it was already there when I found myself needing it.

   David

On Tue, Jul 12, 2011 at 3:09 PM, Daniel Janus  wrote:
> Hey, thanks for recommending my library! :-)
> Best,
> Daniel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

2011-07-12 Thread Brian Goslinga
On Jul 11, 5:44 am, Sunil S Nandihalli 
wrote:
> Hello everybody,
>  I think a lazy version of shuffle would be a good addtion to the core. I
> tried googling for one and 
> foundhttp://ytakenaka.blogspot.com/2011/05/lazy-shuffle-clojure.htmlwhich was
> infact slower than original shuffle and was unable to reproduce the
> performance claims made there in. In fact the experiment showed that the
> lazy-shuffle was about 10 times slower (of course depends on the size of the
> collection to be shuffled).. Can somebody help me ?
>
> Thanks,
> Sunil.
I once created a lazy version of shuffle that worked on some random
access collection (such as vector) using the Fisher-Yates algorithm
that virtually swapped elements by using a map to keep track of index-
>element remappings. It seemed to work rather well if you wanted a
minority of the items in the original collection. I should try to dig
up that code...

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


Immutable Piece-table

2011-07-12 Thread Ghadi Shayban

I put up a simple demo that implements a piece table data structure in
Clojure

(This is totally an excuse to use finger trees, which Chris Houser
implemented and excellently presented at the first conj)

A piece table is good for buffer management in a text editor, as it
gets around making changes in place.  All changes are made to a
separate append-only buffer.

I'll spare you the details but if you look at the code you'll see why
a finger tree is a good base structure...
Each piece in the table has a different "weight" (the length of the
piece), and you need to find a point without traversing the whole
sequence.

https://github.com/ghadishayban/piece-table/blob/master/src/piecetable/core.clj

More about piece-tables
http://www.cs.unm.edu/~crowley/papers/sds.pdf

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

2011-07-12 Thread ckirkendall
I did just recently port Jim Weirich's ruby based rspec-given to
Clojure.  It is a very simple BDD framework build on top of
clojure.test as a set of macros.  You can find the link here.

https://github.com/ckirkendall/ClojureGiven


Creighton Kirkendall

On Jul 11, 2:12 pm, Max Weber  wrote:
> Hi,
>
> I like to write some integration/acceptance tests in Clojure. At the moment
> I'm using cuke4duke (cucumber), but I'm not satisfied with it. For my unit
> tests I'm already using lazytest. In the acceptance tests I like to apply
> the typical Given When Then template (like cucumber do). So are there any
> nice alternatives to cucumber/cuke4duke?
>
> I know circumspec , but the
> project makes no progress anymore? What is the relationship between
> circumspec and lazytest ? How can
> acceptance tests be written with lazytest, which follow the Given When Then
> template (like 
> thiscircumspec
> example)?
>
> Best regards
>
> Max

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

2011-07-12 Thread ckirkendall
Recently I sat through a presentation on Jim Weirich's ruby based
rspec-given.  I decided to see if it was possible to port it as a set
of macros over clojure.test.   Turns out that it was fairly easy to
port the concepts over to clojure.

Link:
https://github.com/ckirkendall/ClojureGiven

Basic Syntax:

(ns cljgiven.test.core
  (:use [cljgiven.core])
  (:use [clojure.test]))

(defspec basic-spec
  (Given [t1 (+ 1 x)
  t2 (- 2 t1)])   ;this is lazy
  (Given! [y 3])  ;this is not
  (Context "let us test t1"
   (Given [x (+ 1 y)]);this is lazy
   (When result (+ 1 t1)) ;lazy Givens above evaluated now
   (Then (= 6 result)))
  (Context "let us test t2"
   (Given! [x (+ 1 3)])   ;not lazy
   (When result2 (+ t2 x))
   (Then (= 2 result2

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

2011-07-12 Thread Stuart Campbell
If you use vectors instead of lists, you can avoid quoting altogether:

user> (def alist [1 (fn [x y] (+ x y))])
#'user/alist
user> (apply (second alist) [1 3])
4

Regards,
Stuart

On 13 July 2011 08:09, Joop Kiefte  wrote:

> Didn't try, but shoudn't (def alist `(1 ~(fn [x y] (+ x y be better?
> Then you don't need the eval :)
>
>
> 2011/7/12 Benny Tsai 
>
>> alist is missing parens around the fn, so it's really a list of 4 elements
>> like so:
>>
>>
>>   (1, fn, [x y], (+ x y))
>>
>> So (second alist) returns just the symbol 'fn.  And when you apply a
>> Symbol to a list, the result is the last item in the list (not sure why).
>>
>> To do what you want, alist should be defined like this:
>>
>>   (def alist '(1 (fn [x y] (+ x y
>>
>> Also, it seems that the definition of the function needs to be eval'ed
>> first to become an apply-able function.  The following returns 4 in my REPL:
>>
>>   (apply (eval (second alist)) '(1 3))
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from 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: Results from 2011 State of Clojure survey

2011-07-12 Thread Chas Emerick
I hesitate to go even more meta, but since I started the thread, I thought I 
would say:

I talked for a bit in the results post about mailing list threads going into 
the weeds; at least IMO, this one qualifies.  It wouldn't be the worst thing in 
the world if it died right here. :-)

Cheers,

- Chas

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

2011-07-12 Thread Jeremy Dunck
On Tue, Jul 12, 2011 at 5:48 PM, Ken Wesson  wrote:
...
> It's not hard to think up the likely objections from a lot of people,
> too, and why they'd be looking for something new:
...
> Python: poor performance
>
> Javascript: interpreted, so slow; "isn't this just for adding annoying
> ads to web pages"?; "I turn that shit off in my browser, why would I
> want to actually write the stuff?" :)

For what it's worth, the story is changing on both of these.  See V8
and PyPy.  I agree these still hold as common objections, but the
facts argue the perception now.

http://arewefastyet.com/old-awfy.php

http://www.youtube.com/watch?v=5DtlBC_Zbq4

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


Change in reduce behavior in 1.3.0?

2011-07-12 Thread Sebastián Galkin
I think I've found a change in the behavior of reduce function, passing from 
1.2.1 to 1.3.0.

Given the following:

(defn lazy []
  (lazy-seq
(print "*")
(cons :foo (lazy

(defn show []
  (reduce
(fn [r x] (print "!"))
[]
(take 10 (lazy

This is the output of a call to show using clojure 1.2.1:

*!*!*!*!*!*!*!*!*!*!

So, the reducing function is called for the first time, after the lazy 
sequence produced _only_ one value.

This is the output of a call to show using clojure 1.3.0-beta1:

**!*!*!*!*!*!*!*!*!!

As you can see, the reducing function is not called until the lazy sequence 
has produced _two_ values.

Is this change in behavior known and intended? Can someone explain what 
change in clojure code produced it?

Uninteresting detail: I discovered this trying to migrate my Swing 
application from 1.2.1 to 1.3.0. My lazy sequence is a stream of user events 
(clicks, menu selects, etc), my reducing function is an event handler. Each 
time the handler is called, it gets the "state" of the application before 
the event, and returns the "new state" of the application after the event 
was processed. It seemed a nice way to see the user interaction. But this 
behavior change, has broken things. Now I need two user "interactions" to 
get the first one processed.


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

2011-07-12 Thread Sebastián Galkin
Notice there is no parenthesis before fn in the list definition.
So, it's equivalent to calling ('fn 1 3), ie. calling the Symbol 
implementation of AFn, which searches the sym in the first argument and 
returns the second arguments in can't find it. That's why it's returning 3.

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

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 7:47 PM, Mike Meyer  wrote:
>> Another misunderstanding. Many developers working at one physical,
>> co-located computer has the keyboard and monitor as "a single global
>> lock". In the terminal server case there could be a finer locking
>> granularity. As for "still developed and used", what for?
>
> What makes you think a computer can have only a single
> keyboard/monitor?

And yet another misunderstanding. If it has more, it's a terminal
server of some sort rather than just having its one local console. And
there's that "s" word again. :)

> But this is all irrelevant

Hardly.

> from the point of view of an application, it doesn't make any difference if
> someone is issuing commands from a device directly connected to the
> hardware, from a device connected to a terminal server, or sitting at
> a second computer and connected back to the single computer where the
> work is being done.

The application's perspective is what's irrelevant. It just means the
sysadmin has to secure a telnetd/sshd/whatever rather than a version
control server.

> Which is why such things are still being developed. There's
> fundamentally no difference between many developers running commands
> on the single computer to manipulate the data and many developers
> running clients that talk to apache running on that single computer
> and causing it to issue those commands.

Well, actually, there is. You see, when using a terminal server to
talk to a central unix box, a) all of the CPU and memory resources for
separate editing sessions, as well as those for file access and doing
the version control work (if any), are consumed on the server, and b)
all of your developers are stuck using vi and/or emacs in text mode on
a crummy little 80x24 display.

When using regular version control servers, on the other hand, a) the
server's only responsible for the CPU and memory use needed for file
access and version control work, with the editing etc. using the
developers' own desktop machines' resources, and b) the developers get
to use whatever editors, IDEs, and whatnot they're most comfortable
with, and get to use GUIs if they want to, so have more choice.

The security situation is also starkly different. There's a server to
secure in every case; but in the first case, you also have a bunch of
people running around with shell accounts on the server, whereas their
interactions with the server are far more constrained in the second
case. On the other hand, you can more tightly control the source code
in the first case -- all other things being equal (e.g. the only
machines that can talk to the server are in a locked-down part of a
military base, say, including the server), dumb terminals instead of
smart desktop computers means the source code isn't copied to many
general-purpose computers but stays on just the one. Spying means
actually taking pictures of the terminal screen while scrolling,
rather than just smuggling in a thumb drive or something; the server
can be in an even more tightly locked down room with even fewer people
having access than the terminals.

So, for the standard threat model (this big open source project is a
likely target for hackers out to bring the web site down for kicks or
maliciously sneak bad stuff such as security holes into the product
we're building; we have thousands of potential developers and can't
vet them all; and we're operating on a budget) remote, smart clients
and a dumb server works better. For the military-paranoia threat model
(Iran will try very hard to get ahold of the source code for our
next-generation Predator drones; we have 18 developers, all unix
wizards with top security clearance; and we have thirty billion
black-budget Pentagon dollars to spare on beefing up the server to
handle high loads) dumb terminals and smart server works better, given
the whole lot are on a closed, local network behind physically locked
and guarded doors.

>> Which means it's not really case 4 at all.
>
> Well, it's very clearly not cases 1, 2 or 3.

No, it's case zero: standard multi-developer, multi-computer, single
canonical master copy on one computer/cluster somewhere. The thing
cases 1 through 4 were *alternatives* to.

>> Except that it has an official build repository with more stringent
>> criteria for what gets in there, so not really.
>
> Half right.

All right.

> As I said, it's got one repository that the official
> builds come from. Other people are free use builds from their own
> repositories, and often do

Same as any case-zero, open source development effort.

> I don't think any of the GNU/Linux
> distributions actually use binaries built by Linus. Instead, they each
> have their own "master" repository from which they do their "official"
> builds.

Forks, each their own example of case zero.

> However, the criteria for what gets into that so-called "master"
> repository are no more stringent than for any other repository in the
> project: only patches the owner want

Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 9:45 PM, Jeremy Dunck  wrote:
> On Tue, Jul 12, 2011 at 5:48 PM, Ken Wesson  wrote:
> ...
>> It's not hard to think up the likely objections from a lot of people,
>> too, and why they'd be looking for something new:
> ...
>> Python: poor performance
>>
>> Javascript: interpreted, so slow; "isn't this just for adding annoying
>> ads to web pages"?; "I turn that shit off in my browser, why would I
>> want to actually write the stuff?" :)
>
> For what it's worth, the story is changing on both of these.  See V8
> and PyPy.  I agree these still hold as common objections, but the
> facts argue the perception now.

Yes, I know. In my opinion, the objections to JS and to Erlang that I
named are illegitimate (besides performance as an objection to JS,
anyway); but they're likely to reflect common perception and knee-jerk
reactions, too, and it is upon this fact that I was remarking.

Python's major weakness, in this multicore age, is the global
interpreter lock -- has there been any progress on creating a viable
Python breed that has true concurrency?

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: monads > macros

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 3:01 PM, Konrad Hinsen
 wrote:
> On 12 Jul 2011, at 15:40, James Keats wrote:
>
>> My humble understanding is that macros complicate composability,
>> whereas monads facilitate it.
>
> The composability issue with macros lies in writing them, not using them.
> Monads are all about composing computations with specific properties, where
> the monad abstracts away those properties. But I don't see any common point
> between macros and monads other than that both words start with 'm'.

Well, they *do* also have a total of five letters, including an 'a'
and and an 'o' as well as two consonants besides the initial 'm'. Oh,
and the second letter is a vowel in both cases.

I think maybe Haskell also relies on monads for some of the things
where a Lisp traditionally relies on macros, such as implementing
control structures -- Haskell has lazy function arguments, and it's
already clear from sequence-m and maybe-m that monads can implement
some kinds of conditionals and loops and even a form of exception
handling.

> One approach that has been proposed to improve composability of macros is to
> adopt a continuation-passing style. This would make macros a candidate for
> the continuation monad, so perhaps monads may be of use in implementing
> complex macros.

That popcorn-popping sound you hear is heads exploding out there in
the audience.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Jeremy Dunck
On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson  wrote:
...
> Python's major weakness, in this multicore age, is the global
> interpreter lock -- has there been any progress on creating a viable
> Python breed that has true concurrency?

FWIW, Jython and IronPython don't suffer from the GIL.

CPython chooses to not penalize single-threaded performance in order
to boost multi-threaded.  The GIL-removal approaches tried so far have
been based on finer-grained locks, which have single-threaded
overhead.

I think this makes sense given the maturity of the ecosystem and the
single-threaded legacy.

But PyPy doesn't have that constraint, and gives such good
improvements over CPython that I think they'd be wise to abandon the
single-threaded favoritism.

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

2011-07-12 Thread Ken Wesson
On Tue, Jul 12, 2011 at 11:06 PM, Jeremy Dunck  wrote:
> On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson  wrote:
> ...
>> Python's major weakness, in this multicore age, is the global
>> interpreter lock -- has there been any progress on creating a viable
>> Python breed that has true concurrency?
>
> FWIW, Jython and IronPython don't suffer from the GIL.
>
> CPython chooses to not penalize single-threaded performance in order
> to boost multi-threaded.  The GIL-removal approaches tried so far have
> been based on finer-grained locks, which have single-threaded
> overhead.

Sounds like the interpreter is guarding global mutable state that is
mutated during ordinary program execution (and not just during
application bootstrap when the equivalents of defs and defns are run
to populate namespaces). Perhaps a deeper redesign is in order?

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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


Re: Results from 2011 State of Clojure survey

2011-07-12 Thread Jeremy Dunck
On Tue, Jul 12, 2011 at 10:09 PM, Ken Wesson  wrote:
> On Tue, Jul 12, 2011 at 11:06 PM, Jeremy Dunck  wrote:
>> On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson  wrote:
>> ...
>>> Python's major weakness, in this multicore age, is the global
>>> interpreter lock -- has there been any progress on creating a viable
>>> Python breed that has true concurrency?
>>
>> FWIW, Jython and IronPython don't suffer from the GIL.
>>
>> CPython chooses to not penalize single-threaded performance in order
>> to boost multi-threaded.  The GIL-removal approaches tried so far have
>> been based on finer-grained locks, which have single-threaded
>> overhead.
>
> Sounds like the interpreter is guarding global mutable state that is
> mutated during ordinary program execution (and not just during
> application bootstrap when the equivalents of defs and defns are run
> to populate namespaces). Perhaps a deeper redesign is in order?

Perhaps, but I think the more likely outcome is that PyPy becomes the
"standard" interpreter.

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

2011-07-12 Thread Devin Walters
Perhaps this discussion requires its own thread?

Sent via mobile

On Jul 12, 2011, at 10:15 PM, Jeremy Dunck  wrote:

> On Tue, Jul 12, 2011 at 10:09 PM, Ken Wesson  wrote:
>> On Tue, Jul 12, 2011 at 11:06 PM, Jeremy Dunck  wrote:
>>> On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson  wrote:
>>> ...
 Python's major weakness, in this multicore age, is the global
 interpreter lock -- has there been any progress on creating a viable
 Python breed that has true concurrency?
>>> 
>>> FWIW, Jython and IronPython don't suffer from the GIL.
>>> 
>>> CPython chooses to not penalize single-threaded performance in order
>>> to boost multi-threaded.  The GIL-removal approaches tried so far have
>>> been based on finer-grained locks, which have single-threaded
>>> overhead.
>> 
>> Sounds like the interpreter is guarding global mutable state that is
>> mutated during ordinary program execution (and not just during
>> application bootstrap when the equivalents of defs and defns are run
>> to populate namespaces). Perhaps a deeper redesign is in order?
> 
> Perhaps, but I think the more likely outcome is that PyPy becomes the
> "standard" interpreter.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: Build tool for mixed Clojure/Java projects

2011-07-12 Thread Kevin Kelley

Guys, geez, go cure cancer or something.

Kevin

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

2011-07-12 Thread Christian Marks


On Jul 10, 10:16 pm, FL  wrote:
\>  If you replace your
...
> > (defn order-perm [perm]
> >         (let [n (count perm)]
...
> with the more compact
>
> (defn order-permo [perm]
>              (reduce (fn [order i] (if (= i (next-cycle-leader perm i))
>                                     (math/lcm (cycle-length perm i)
> order)
>                                      order))
>                           1 perm))
>
> you'll be rewarded with better performance with permutations of size
> <= 10,


Thank you. Based on this I've simplified the code further.
The (new) predicate (cycle-leader? perm i) is true if and only if
i is the least element of the unique cycle containing i
in the permutation perm. This is more readable, though the
extra test compared with the original adds to execution time.

(ns knuth
(:require [clojure.contrib.math :as math]))

(defn random-perm [n]  (shuffle (range n)))

(defn cycle-leader? [perm i]
(loop [j (nth perm i)]
(cond (< j i) false
  (= j i) true
  :else (recur (nth perm j)

(defn cycle-length [perm i]
(loop [cycle 1 j (nth perm i)]
(if (= i j)
cycle
(recur (inc cycle) (nth perm j)

(defn order-perm [perm]
   (reduce
  (fn [order i] (if (cycle-leader? perm i)
(math/lcm (cycle-length perm i) order)
order))
   1 perm))

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

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

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

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

Re: Change in reduce behavior in 1.3.0?

2011-07-12 Thread Meikel Brandmeyer
Hi,

I think the culprit is here: 
https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64

The line "(recur cls (next s) f (f val (first s)))" must be written as

(let [v (f val (first s))]
  (recur cls (next s) f v))

for your scenario to work.

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

Re: Immutable Piece-table

2011-07-12 Thread Ben Smith-Mannschott
On Wed, Jul 13, 2011 at 02:33, Ghadi Shayban  wrote:
>
> I put up a simple demo that implements a piece table data structure in
> Clojure
>
> (This is totally an excuse to use finger trees, which Chris Houser
> implemented and excellently presented at the first conj)
>
> A piece table is good for buffer management in a text editor, as it
> gets around making changes in place.  All changes are made to a
> separate append-only buffer.
>
> I'll spare you the details but if you look at the code you'll see why
> a finger tree is a good base structure...
> Each piece in the table has a different "weight" (the length of the
> piece), and you need to find a point without traversing the whole
> sequence.
>
> https://github.com/ghadishayban/piece-table/blob/master/src/piecetable/core.clj

That's a nice use of finger trees. I'll take it along this morning to
read on the subway.

> More about piece-tables
> http://www.cs.unm.edu/~crowley/papers/sds.pdf

Ah, the memories! :-)

Wirth and Gutknecht's Oberon System used this technique (under the
name 'piece chain') for the built-in text editing facility. In their
case the pieces also carried attribute (font, size, style, color)
information for the run of text being described. The raw text backing
the chain remained on disk.

Newly entered text was appended to a separate on disk file. So, on
disk text files had the property of being immutable or append only
while you were editing. Saving the current document replaced the old
version atomically in the disk directory. This always struck me as a
tiny bit FP, though one would never confuse Oberon with FP or a lisp.

The implementation is described here:
http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf (~ 5MB!)
Starting at page 83. There are figures on pp 84-86.

// Ben

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