Re: Unknown constant tag 32 in class file error

[Ken Wesson]

On Tue, Jul 5, 2011 at 4:32 PM, Alessio Stalla  wrote:
> On 5 Lug, 18:49, Ken Wesson  wrote:
>> 1. A too-large string literal should have a specific error message,
>> rather than generate a misleading one suggesting a different type of
>> problem.
>
> There is no such thing as a too-large string literal in a class file.

That's not what Patrick just said.

>> 2. The limit should not be different from that on String objects in
>> general, namely 2147483647 characters which nobody is likely to hit
>> unless they mistakenly call read-string on that 1080p Avatar blu-ray
>> rip .mkv they aren't legally supposed to possess.
>
> That's a limitation imposed by the Java class file format.

And therefore a bug in the Java class file format, which should allow
any size String that the runtime allows. Using 2 bytes instead of 4
bytes for the length field, as you claim they did, seems to be the
specific error. One would have thought that Java of all languages
would have learned from the Y2K debacle and near-miss with
cyber-armageddon, but limiting a field to 2 of something instead of 4
out of a misguided perception that space was at a premium was exactly
what caused that, too!

>> 3. Though both of the above bugs are in Oracle's Java implementation,
>
> By the above, 1. is a Clojure bug and 2. is not a bug at all.

Oh, 2 is a bug alright. By your definition, Y2K bugs in a piece of
software would also not be bugs. The users of such software would beg
to differ.

>> it would seem to be a bug in Clojure's compiler if it is trying to
>> make the entire source code of a namespace into a string *literal* in
>> dynamically-generated bytecode somewhere rather than a string
>> *object*.
>
> Actually it seems it's the IDE, rather than Clojure, that is
> evaluating a form containing such a big literal. Since Clojure has no
> interpreter, it needs to compile that form.

The same problem has been reported from multiple IDEs, so it seems to
be a problem with eval and/or load-file. The question is not why they
might be using String *objects* that exceed 64K, since they'll need to
use Strings as large as the file gets*. It's why they'd *generate
bytecode* containing String *literals* that large.

And it's not IDEs that generate bytecode it's
clojure.lang.Compiler.java that generates bytecode in this scenario.

* There is a way to reduce the size requirements; crudely, line-seq
could be used to implement a lazy seq of top-level forms built by
consuming lines until delimiters are balanced and them emitting a new
form string, then evaluating these forms one by one. This works with
typical source files that have short individual top-level forms and
have at least 1 line break between any two such and would allow
consuming multi-gig source files if anyone ever had need for such a
thing (I'd hope never to see it unless it was machine-generated for
some purpose). Less crudely, a reader for files could be implemented
that didn't just slurp the file and call read-string on it but instead
read from an IO stream and emitted a seq of top-level forms converted
already into reader-output data structures (but unevaluated). In fact,
read-string could then be implemented in terms of this and a
StringInputStream whose implementation is left as an exercise for the
reader but which ought to be nearly trivial.

>> Sensible alternatives are a) get the string to whatever
>> consumes it by some other means than embedding it as a single
>> monolithic constant in bytecode,
>
> This is what we currently do in ABCL (by storing literal objects in a
> thread-local variable and retrieving them later when the compiled code
> is loaded), but it only works for the runtime compiler, not the file
> compiler (in Clojure terms, it won't work with AOT compilation).

Yes, this is the same issue raised in connection with allowing
arbitrary objects in code in eval.

>> b) convert long strings into shorter
>> chunks and emit a static initializer into the bytecode to reassemble
>> them with concatenation into a single runtime-computed string constant
>> stored in another static field,
>
> This is what I'd like to have :)

Frankly it seems like a bit of a hack to me, though since it would be
used to work around a Y2K-style bug in Java it might be poetic justice
of a sort.

>> and c) restructure whatever consumes
>> the string to consume a seq, java.util.List, or whatever of strings
>> instead and feed it digestible chunks (e.g. a separate string for each
>> defn or other top-level form, in order of appearance in the input file
>> -- surely nobody has *individual defns* exceeding 64KB).
>
> The problem is not in the consumer, but in the form containing the
> string; to do what you're proposing, the reader, upon encountering a
> big enough string, would have to produce a seq/List/whatever instead,
> the compiler would need to be able to dump such an object to a class,
> and all Clojure code handling strings would have to be prepared to
> handle such an object, too. I think it's a l

Re: clojure and maths

[Konrad Hinsen]

On 6 Jul 2011, at 06:35, jlk wrote:


I've been playing around with math in clojure lately and have run up
against a few hurdles that I'm not sure how to overcome, any help
would be appreciated!  Mostly I've been trying to use the apache
commons math library (http://commons.apache.org/math/), but have been
hitting similar problems with other libraries too.  I suppose I'm
hitting a composablilty and Static typing problem?


Right. The problem is that OO (more precisely Java's way of doing OO)  
imposes some limitations that quickly get in the way when you want to  
implement mathematical concept hierarchies in terms of a class  
hierarchy. So ultimately the root of your problem is that you want to  
use Java math libraries, not that you are using Clojure. Yes, I know,  
one of the good points of Clojure is access to all those Java  
libraries...



So the wrapping continues as
(defn nbd [x] (proxy [BigDecimal FieldElement] [x] (nbd (.toString
(add [y] (.add this y which works out to be a whole lot of
inefficient and boring wrapper code when all I really want to do it
insert a getField method into BigDecimal.


It might be worth investigating if all that wrapper code could be  
generated by a few Clojure macros.



Of course I could wrap backward, so that every time I actually want to
use a BigDecimal i call .toBigDecimal on the BigReal object first, but
again it seems clunky and forces the user to deal with types that are
essentially identical.


I'd say this is worse because it means converting between data  
representations all the time. Better keep one data representation and  
make it fit into your framework.



The only fix I see here is writing a new Complex class that implements
the FieldElement interface, since using a Complex class from somewhere
else will hit similar problems to the above.


Right, that's the most flexible solution, but also likely to be the  
least efficient one.


For a Clojure approach to this specific problem, see

http://clojure.github.com/clojure-contrib/complex-numbers-api.html

which is based on the generic arithmetic from

http://clojure.github.com/clojure-contrib/generic.arithmetic-api.html

and thus ultimately on multimethods. There is a performance penalty to  
such approaches, but it lets you formulate mathematical hierarchies  
much better than Java's OO style. Note that this approach is not based  
on types or on mathematical concepts such as fields, but only on  
operations: the real and imaginary parts of a complex number can be  
any value that supports arithemetic. This permits complex numbers with  
nonsensical elements, but I have not found this to be a problem in  
real life.



Another issue is inserting the data.  Using maths from the repl, being
able to get the syntax [0 1 2] return a maths capable object would be
much nicer than (create-math-vector 0 1 2).


Generic arithmetic can take care of that.

similarly with complex numbers, writing (complex x y) is very long  
compared to xiy, or x +

iy.  Would it be possible to modify the reader so that, eg. 3i5 would
return a complex type?


Yes, but I doubt you'd have much success lobbying for such a change.  
The tradeoff between cost (increased complexity of the reader) and  
utility (limited to a small number of users) doesn't look very  
promising. Moreover, my personal experience doing REPL math in Python  
shows that complex constants are pretty rare.



So basically I'm stuck - short of writing a maths library from scratch
with pluggable types and dispatch by operation name, anyone got any
ideas?  Cheers for your help


One idea (but not a simple one to implement) is to define a domain- 
specific language for maths (standard Clojure syntax but with  
different semantics) and compile it into standard Clojure using a set  
of 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: Unknown constant tag 32 in class file error

[Ken Wesson]

On Wed, Jul 6, 2011 at 1:16 AM, Peter T  wrote:
>> > > Does the file you are evaluating have more than 65535 characters?
>
> Nope. It's about 1400 LOC and not syntactically unique (no unusually
> long constants, etc.). It's also not the longest ns in the project:
> the longest is around 2000 LOC and is still evaluating fine. If I had
> to try find something unusual about the ns, I'd say that it
> probably :requires more namespaces than others (22).

Well, this is odd!

> 1. I'm more or less satisfied: if I know I can always work around the
> problem by using shorter namespaces, I'm happy.

It creates a tension, though:

1. In another recent thread people have been arguing for relatively
large namespaces.

2. It isn't nice to have code modularization boundaries dictated as
much by bug workaround considerations as by architectural ones!

> 2. While the namespace size seems to be a factor, I'm not convinced
> that the problem is as linear as "big namespace = problem". I have
> other namespaces that are larger (in line count, character count, and
> definitions) that have been evaluating fine without a problem. This
> problem feels more random/subtle to me.

The fact, mentioned recently in that other thread, that clojure.core
is 200K and around 6Kloc and compiles fine also points in this
direction.

My guess would be that it's some function of namespace size in bytes,
number of vars, and possibly as you say number of referred vars -- so
maybe also imports and anything else that grows the namespace's symbol
table too.

> 4. There seems to be a discrepancy in behaviour depending on how the
> compilation is requested: project-wide command-line compilation seems
> to keep working even when Slime/Swank evaluation fails.

It looks like it affects load-file but not AOT compilation. Both
presumably use eval, and eventually Compiler.java, to get the job
done, so the problem is probably in load-file's implementation
specifically. The simplest hypothesis, that it's granularity (the
compiler chokes on a single huge wodge of forms crammed down its
throat in one go but works fine if given the same forms one by one)
fails to fully explain the data because it predicts that AOT should
fail on the namespaces where load-file fails, but evaluating the
top-level forms one by one works as expected. This suggests again that
load-file is the problem rather than Compiler.java, or possibly that
AOT feeds forms to the compiler differently from load-file.

> 5. Personally I don't have any problem with hard limits (e.g. keep
> your namespaces/whatever below X lines/definitions/whatever) even if
> they're aggressive- but I think it'd be preferable to have an error
> message to point out the limit when it gets hit (if that's indeed
> what's happening).

I *do* have a problem with such limits; including limits on function
size. Architecture should be up to the programmer, and even if it is a
*bad idea* for programmers write huge namespaces or huge individual
functions, IMO that isn't a judgment call appropriate for the
*language compiler* to make. And let's not forget that we're a Lisp,
so we do meta-programming, and so we probably want to be able to
digest files, functions, and individual s-expressions that no sane
human would ever write but that may very well occur in
machine-generated inputs to the compiler.

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

[Ken Wesson]

On Wed, Jul 6, 2011 at 2:06 AM, Meikel Brandmeyer  wrote:
> Hi,
>
> Am Dienstag, 5. Juli 2011 18:55:48 UTC+2 schrieb Ken Wesson:
>
>> I'd be very interested to know how one checks out a file from a CVS
>> repository without cvs-pserver running. You do a cvs checkout whatever
>> at the command prompt, the command interpreter runs the cvs client,
>> and the cvs client then connects to ??? (apparently not the
>> cvs-pserver you're not running) using ??? (apparently not cvs's wire
>> protocol over TCP/IP on the 127.0.0.1 loopback interface) to perform
>> the checkout ...
>
> Maybe by doing a “cvs -d /path/to/your/local/repository/directory checkout”?
> (without having an ancient cvs around to test...)

How would that be implemented, though? Without the server running to
enforce mutual exclusion and detect edit collisions and everything,
the whole notion of "checkin" and "checkout" appears to become
meaningless.

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

[Meikel Brandmeyer]

Hi,

Am Mittwoch, 6. Juli 2011 09:23:08 UTC+2 schrieb Ken Wesson:

>> Maybe by doing a “cvs -d /path/to/your/local/repository/directory 
checkout”?
>> (without having an ancient cvs around to test...)
>
> How would that be implemented, though? Without the server running to
> enforce mutual exclusion and detect edit collisions and everything,
> the whole notion of "checkin" and "checkout" appears to become
> meaningless.

Obviously this is implemented in cvs because the form above comes from its 
documentation. In fact since it is on the local machine I would expect 
something like flock or lockf to work. What happens if “local” means NFS...

So in fact I would consider “local” to be the trivial case to ensure mutual 
exclusion and edit collisions detection if everyone obeys to flock or such.

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: Clojure for large programs

[Peter Taoussanis]

Don't know if it counts as "large", but I'm running a 20,000+ LOC
project for a 100%-Clojure web app at www.wusoup.com.

My 2c: I'm not an experienced developer by any stretch of the
imagination; this is something I'm working on completely alone, and
yet I've so far found the whole thing incredibly manageable. I'd
attribute that largely to Clojure.

Then again, I only noticed this thread because of its relation to the
"unknown constant tag" one ;p

I'd like to open-source the whole app at some stage (or at least some
large parts of it), but I'm also always happy to answer any questions
from the perspective of someone using exclusively Clojure for a small
(but hopefully growing) "production" application.

One of the things I've most enjoyed about Clojure (and it being
functional) is the ease with which I can bash on a function in the
REPL during development: testing it with all sorts of weird/nil input,
making sure that it'll be well behaved even if something else along
the way gets confused.

The modularity I can get with "functional" functions is reassuring for
me as a lone developer since once I've written something and it's gone
through that "bashing" stage- I'm normally pretty confident that it's
more or less "right". I very rarely end up needing to come back to fix
problems related to unexpected input, etc.

Most of the time when I need to "fix" a function it's because I simply
had the wrong idea about what it actually needed to do, rather than
because it was doing it wrong. If that makes any sense.


For a large project I think you probably need to be more disciplined
with something like Clojure than, say, Java. But that's the whole
"with great power" thing again: I think you get something valuable in
return for being asked to exercise some discipline.

Can't really comment on how easily Clojure works for large groups of
developers as such. The flexibility thing might start losing it's
charm when you have 10 different coding styles competing with one
another under time constraints, etc. (where discipline starts to go
out the window in favour of "getting stuff done").

- Peter Taoussanis

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

Re: clojure and maths

[Ken Wesson]

On Wed, Jul 6, 2011 at 3:14 AM, Konrad Hinsen
 wrote:
> For a Clojure approach to this specific problem, see
>
>        http://clojure.github.com/clojure-contrib/complex-numbers-api.html
>
> which is based on the generic arithmetic from
>
>        http://clojure.github.com/clojure-contrib/generic.arithmetic-api.html
>
> and thus ultimately on multimethods. There is a performance penalty to such
> approaches, but it lets you formulate mathematical hierarchies much better
> than Java's OO style. Note that this approach is not based on types or on
> mathematical concepts such as fields, but only on operations: the real and
> imaginary parts of a complex number can be any value that supports
> arithemetic. This permits complex numbers with nonsensical elements, but I
> have not found this to be a problem in real life.

I wonder if generic math should become part of core for 1.4?
Multimethods of course are too slow for core arithmetic functions but
we have protocols now and when a protocol is implemented inline in a
datatype it runs as efficiently as any Java method call. The compiler
would still need to special-case +, -, etc. with primitive arguments
and those would retain the blinding speed of primitive arithmetic. The
biggest issue would be extending the protocol to boxed primitives,
BigInteger, and BigDecimal; extending a protocol to a class that
doesn't implement it inline isn't as efficient. BigInteger and
BigDecimal arithmetic, already slow, would get a tiny bit slower; it's
the impact on plain Integer, Double, etc. that could be worrying.

Can the compiler generate more efficient calls to protocol methods in
the presence of type hints or type inference sufficient to know the
correct protocol implementation? So if you (extend-protocol + Integer
...) during bootstrap, (+ some-integer some-other-integer) could be as
efficient as the current non-protocol-based + is when the compiler
knows the first argument is an Integer, whether from hinting it or by
some other means?

>> similarly with complex numbers, writing (complex x y) is very long
>> compared to xiy, or x +
>> iy.  Would it be possible to modify the reader so that, eg. 3i5 would
>> return a complex type?
>
> Yes, but I doubt you'd have much success lobbying for such a change. The
> tradeoff between cost (increased complexity of the reader) and utility
> (limited to a small number of users) doesn't look very promising. Moreover,
> my personal experience doing REPL math in Python shows that complex
> constants are pretty rare.

You can make it as simple as (i 3 5) by appropriately defining a
function or a macro i. (You might want to use definline so you can
both use i in HOFs, e.g. (map i list-of-real-parts
list-of-imaginary-parts), and get slightly more efficient bytecode out
of embedded complex values in code, with (i a b) as efficient at
generating a complex number as [a b] is at generating a vector when at
least one of a and b is not a literal constant; though (i 3 5) would
not be competitive with [3 5] for runtime speed without reader and
compiler(!) changes to embed complex numbers directly in code. When
you really need efficient access to a complex constant you'd thus need
to bind a non-dynamic global Var to the constant and then use it, e.g.

(defn slowish-math-routine [foo]
  (frobnicate foo (i 3 5))

might become

(def i35 (i 3 5))

(defn faster-math-routine [foo]
  (frobnicate foo i35))

to get the kind of speed of access you get with embedded vector
constants, embedded map constants, and suchlike.

(This is one more problem with Clojure's lack of ability to embed
arbitrary objects in eval'd sexps: it makes non-built-in data types
and even things like sorted-map not quite first class citizens because
you have to jump through extra hoops to make it possible to embed
constants of these types in code and get the same runtime efficiency
as with [x], {x y}, #{x}, etc. With the arbitrary object in code
capability efficient literals could be made even without read-table
access: #=(i 3 5) would embed a Complex in code given an appropriate
function i defined somewhere where it would be available at read time.
A bit ugly but not much worse than the existing literal syntax for
hashsets.)

>> So basically I'm stuck - short of writing a maths library from scratch
>> with pluggable types and dispatch by operation name, anyone got any
>> ideas?  Cheers for your help
>
> One idea (but not a simple one to implement) is to define a domain-specific
> language for maths (standard Clojure syntax but with different semantics)
> and compile it into standard Clojure using a set of macros.

Indeed; you can define some macro like (with-my-math body-goes-here)
that locally redefines some stuff, e.g.

(definline make-complex [x y] `(Complex. ~x ~y))

(defprotocol Addable
  (plus [this other]))

...

(defmacro with-my-math ...)

...

(with-my-math ...)

and the latter expanding to

(xlet
  [i make-complex
   + plus]
   - minus
   ...]
  ...)

But what is "xlet"? Plain

Re: Clojure for large programs

[Ken Wesson]

On Wed, Jul 6, 2011 at 3:49 AM, Peter Taoussanis  wrote:
> Can't really comment on how easily Clojure works for large groups of
> developers as such. The flexibility thing might start losing it's
> charm when you have 10 different coding styles competing with one
> another under time constraints, etc. (where discipline starts to go
> out the window in favour of "getting stuff done").

So far, the Clojure culture has strongly encouraged a sense for
particular idiomatic coding conventions for most common tasks; so
hopefully "10 different coding styles competing with one another"
won't be the sort of issue it might be if you were using, say, Common
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

[Michael Wood]

On 6 July 2011 08:06, Meikel Brandmeyer  wrote:
> Hi,
>
> Am Dienstag, 5. Juli 2011 18:55:48 UTC+2 schrieb Ken Wesson:
>
>> I'd be very interested to know how one checks out a file from a CVS
>> repository without cvs-pserver running. You do a cvs checkout whatever
>> at the command prompt, the command interpreter runs the cvs client,
>> and the cvs client then connects to ??? (apparently not the

It doesn't "connect to" anything.  It reads and writes the files
directly when used like this.

>> cvs-pserver you're not running) using ??? (apparently not cvs's wire
>> protocol over TCP/IP on the 127.0.0.1 loopback interface) to perform
>> the checkout ...
>
> Maybe by doing a “cvs -d /path/to/your/local/repository/directory checkout”?
> (without having an ancient cvs around to test...)

Exactly.  And I've just tested it to be sure.  Also, CVS originally
did not support networking at all.  It was originally designed to be
used by different users on a multi-user machine.

Anyway, the point was that "repository" needn't have anything to do
with networking.

-- 
Michael Wood 

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

[Ken Wesson]

On Wed, Jul 6, 2011 at 3:33 AM, Meikel Brandmeyer  wrote:
> Hi,
>
> Am Mittwoch, 6. Juli 2011 09:23:08 UTC+2 schrieb Ken Wesson:
>
>> How would that be implemented, though? Without the server running to
>> enforce mutual exclusion and detect edit collisions and everything,
>> the whole notion of "checkin" and "checkout" appears to become
>> meaningless.
>
> Obviously this is implemented in cvs because the form above comes from its
> documentation. In fact since it is on the local machine I would expect
> something like flock or lockf to work. What happens if “local” means NFS...

Sorry, but I think version control and, particularly, dealing with
edit collisions is not something you can solve as easily as just
slapping a lock onto each file access, or else version control servers
could just be FTP servers that locked their shared files during each
access.

> So in fact I would consider “local” to be the trivial case to ensure mutual
> exclusion and edit collisions detection if everyone obeys to flock or such.

And then there's the niggling little matter of Unix file locks being
advisory rather than mandatory. Do you really want proper resolution
of edit collisions (or, worse, the integrity of the under-the-hood
state maintained for the repository vis a vis making sense and being
valid data structures) to be entirely on the honor system? At
*minimum* it would seem that a real database with ACID and
transactions would be needed -- A to avoid race conditions (no
advisory locks here!), C to keep the internal state invariants valid,
I to be able to deal with edit collisions in a sane manner, and D for
the obvious reasons. And a suitable software front-end. And now we're
back to having at least one server in the mix, namely the DBMS at the
backend. :)

Here's a simple question to ask yourself whenever considering using
advisory file locks to guard complex on-disk data with invariants to
maintain: *If the power goes off halfway through some kind of
transaction, can the system recover without a lot of manual hacking to
patch up the state of the on-disk data structures? Will my losses be
limited solely to the one transaction in progress at the moment of the
outage?*

If you don't have a satisfactory answer there, then you probably need
a real database. Of course perhaps you are clever and can design your
own on-disk data structures that will fail-soft in some manner under
such circumstances and convince yourself beyond a reasonable doubt
that it'll work, but if not ...

-- 
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: clojure and maths

[Konrad Hinsen]

On 6 Jul, 2011, at 9:58 , Ken Wesson wrote:

> I wonder if generic math should become part of core for 1.4?

Not really the most important question for now - what  matters more is how 
generic math should best be implemented in Clojure. I don't think generic math 
should become the default (i.e. replace clojure.core/+ etc.) before we have an 
implementation with no significant speed penalty compared to the current 
number-only maths routines.

> Multimethods of course are too slow for core arithmetic functions but
> we have protocols now and when a protocol is implemented inline in a
> datatype it runs as efficiently as any Java method call.

clojure.contrib.generic uses multimethods for binary dispatch. This cannot be 
done using protocols. Generic maths with Java-style dispatch is probably less 
useful, though of course faster.

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

[Michael Wood]

On 6 July 2011 09:23, Ken Wesson  wrote:
> On Wed, Jul 6, 2011 at 2:06 AM, Meikel Brandmeyer  wrote:
>> Hi,
>>
>> Am Dienstag, 5. Juli 2011 18:55:48 UTC+2 schrieb Ken Wesson:
>>
>>> I'd be very interested to know how one checks out a file from a CVS
>>> repository without cvs-pserver running. You do a cvs checkout whatever
>>> at the command prompt, the command interpreter runs the cvs client,
>>> and the cvs client then connects to ??? (apparently not the
>>> cvs-pserver you're not running) using ??? (apparently not cvs's wire
>>> protocol over TCP/IP on the 127.0.0.1 loopback interface) to perform
>>> the checkout ...
>>
>> Maybe by doing a “cvs -d /path/to/your/local/repository/directory checkout”?
>> (without having an ancient cvs around to test...)
>
> How would that be implemented, though? Without the server running to
> enforce mutual exclusion and detect edit collisions and everything,

If by "edit collisions" you mean merge conflicts, these are all done
on the client.  Of course if two clients are trying to write to the
same file in the repository at the same time there could be problems,
so I do think that talking to a server over the network is best, but
CVS originally did not support this and still supports non-networked
access.

> the whole notion of "checkin" and "checkout" appears to become
> meaningless.

No, not meaningless.  Just perhaps less reliable.

CVS does not support atomic commits either, which some people find
acceptable and others do not.

-- 
Michael Wood 

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

[Ken Wesson]

On Tue, Jul 5, 2011 at 3:35 PM, Bassel Hajj  wrote:
> (map #(get % ["45"]) d)

Gah. Please don't quote the whole thing when replying to a digest.
Preferably don't use digest mode if you're going to reply a lot anyway
as replying to digests breaks threading for those of us whose mailers
support it, but if you must, trim all but the part of the post you're
responding to. Here it takes a lot of digging to even find what your
code snippet is in response to, not to mention the sheer length of
your post due to the quoted material.

-- 
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: clojure and maths

[Ken Wesson]

On Wed, Jul 6, 2011 at 4:23 AM, Konrad Hinsen
 wrote:
> On 6 Jul, 2011, at 9:58 , Ken Wesson wrote:
>
>> Multimethods of course are too slow for core arithmetic functions but
>> we have protocols now and when a protocol is implemented inline in a
>> datatype it runs as efficiently as any Java method call.
>
> clojure.contrib.generic uses multimethods for binary dispatch. This cannot be 
> done using protocols. Generic maths with Java-style dispatch is probably less 
> useful, though of course faster.

It's clearly the only option if you want to remain speed-competitive
with the current implementation of core math. And
clojure.contrib.generic would presumably not be going away, for those
who really need binary dispatch much more than they do speed.

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

[Michael Wood]

On 6 July 2011 10:14, Ken Wesson  wrote:
> On Wed, Jul 6, 2011 at 3:33 AM, Meikel Brandmeyer  wrote:
>> Hi,
>>
>> Am Mittwoch, 6. Juli 2011 09:23:08 UTC+2 schrieb Ken Wesson:
>>
>>> How would that be implemented, though? Without the server running to
>>> enforce mutual exclusion and detect edit collisions and everything,
>>> the whole notion of "checkin" and "checkout" appears to become
>>> meaningless.
>>
>> Obviously this is implemented in cvs because the form above comes from its
>> documentation. In fact since it is on the local machine I would expect
>> something like flock or lockf to work. What happens if “local” means NFS...
>
> Sorry, but I think version control and, particularly, dealing with
> edit collisions is not something you can solve as easily as just
> slapping a lock onto each file access, or else version control servers
> could just be FTP servers that locked their shared files during each
> access.

Maybe so, but that is all beside the point.  The point was that
"repository" needn't mean "networked".

>> So in fact I would consider “local” to be the trivial case to ensure mutual
>> exclusion and edit collisions detection if everyone obeys to flock or such.
>
> And then there's the niggling little matter of Unix file locks being
> advisory rather than mandatory. Do you really want proper resolution
> of edit collisions (or, worse, the integrity of the under-the-hood
> state maintained for the repository vis a vis making sense and being
> valid data structures) to be entirely on the honor system? At

If the CVS clients are the only ones doing the locking, then why not?

> *minimum* it would seem that a real database with ACID and
> transactions would be needed -- A to avoid race conditions (no
> advisory locks here!), C to keep the internal state invariants valid,

This is why various people moved away from CVS.  To get atomic commits etc.

> I to be able to deal with edit collisions in a sane manner, and D for
> the obvious reasons. And a suitable software front-end. And now we're
> back to having at least one server in the mix, namely the DBMS at the
> backend. :)

Right, I agree it's best to have a server controlling access to the
repository, but that does not mean that the concept of a repository is
linked to having a server or a network.

> Here's a simple question to ask yourself whenever considering using
> advisory file locks to guard complex on-disk data with invariants to
> maintain: *If the power goes off halfway through some kind of
> transaction, can the system recover without a lot of manual hacking to
> patch up the state of the on-disk data structures? Will my losses be
> limited solely to the one transaction in progress at the moment of the
> outage?*

Right, and this is a problem with CVS.

> If you don't have a satisfactory answer there, then you probably need
> a real database. Of course perhaps you are clever and can design your
> own on-disk data structures that will fail-soft in some manner under
> such circumstances and convince yourself beyond a reasonable doubt
> that it'll work, but if not ...

CVS is an old version control system that was far better than the
other things around at the time it was invented, but most people seem
to agree that other, more modern, version control systems are better
and/or more reliable.

-- 
Michael Wood 

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

[Ken Wesson]

On Wed, Jul 6, 2011 at 4:30 AM, Michael Wood  wrote:
> On 6 July 2011 10:14, Ken Wesson  wrote:
>> Sorry, but I think version control and, particularly, dealing with
>> edit collisions is not something you can solve as easily as just
>> slapping a lock onto each file access, or else version control servers
>> could just be FTP servers that locked their shared files during each
>> access.
>
> Maybe so, but that is all beside the point.  The point was that
> "repository" needn't mean "networked".

Maybe just "repository that isn't fragile or outright broken" then. ;)

> If the CVS clients are the only ones doing the locking, then why not?

ARE they the only ones doing the locking OR otherwise accessing the
files, though?

>> *minimum* it would seem that a real database with ACID and
>> transactions would be needed -- A to avoid race conditions (no
>> advisory locks here!), C to keep the internal state invariants valid,
>
> This is why various people moved away from CVS.  To get atomic commits etc.
>
>> I to be able to deal with edit collisions in a sane manner, and D for
>> the obvious reasons. And a suitable software front-end. And now we're
>> back to having at least one server in the mix, namely the DBMS at the
>> backend. :)
>
> Right, I agree it's best to have a server controlling access to the
> repository, but that does not mean that the concept of a repository is
> linked to having a server or a network.

No, just the concept of a reliable repository. ;)

>> If you don't have a satisfactory answer there, then you probably need
>> a real database. Of course perhaps you are clever and can design your
>> own on-disk data structures that will fail-soft in some manner under
>> such circumstances and convince yourself beyond a reasonable doubt
>> that it'll work, but if not ...
>
> CVS is an old version control system that was far better than the
> other things around at the time it was invented, but most people seem
> to agree that other, more modern, version control systems are better
> and/or more reliable.

Unsurprisingly. With apologies to Leonard McCoy:

"Non-atomic commits. Funduscopic examination. What is this, the Dark Ages?"

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

[Michael Wood]

On 6 July 2011 10:37, Ken Wesson  wrote:
> On Wed, Jul 6, 2011 at 4:30 AM, Michael Wood  wrote:
>> On 6 July 2011 10:14, Ken Wesson  wrote:
>>> Sorry, but I think version control and, particularly, dealing with
>>> edit collisions is not something you can solve as easily as just
>>> slapping a lock onto each file access, or else version control servers
>>> could just be FTP servers that locked their shared files during each
>>> access.
>>
>> Maybe so, but that is all beside the point.  The point was that
>> "repository" needn't mean "networked".
>
> Maybe just "repository that isn't fragile or outright broken" then. ;)

Perhaps, but I'd still say that even if the repository is made
available over the network and only the server is directly accessing
the repository, it is still a repository and the server is not
accessing it over the network, so the repository itself doesn't have
anything to do with the network ;)

>> If the CVS clients are the only ones doing the locking, then why not?
>
> ARE they the only ones doing the locking OR otherwise accessing the
> files, though?

Yes, unless you have malicious users, in which case you will need the
server.  I'm not saying it's not a potential security problem.  Just
that co-operative locking of files can work depending on the
circumstances.

>>> *minimum* it would seem that a real database with ACID and
>>> transactions would be needed -- A to avoid race conditions (no
>>> advisory locks here!), C to keep the internal state invariants valid,
>>
>> This is why various people moved away from CVS.  To get atomic commits etc.
>>
>>> I to be able to deal with edit collisions in a sane manner, and D for
>>> the obvious reasons. And a suitable software front-end. And now we're
>>> back to having at least one server in the mix, namely the DBMS at the
>>> backend. :)
>>
>> Right, I agree it's best to have a server controlling access to the
>> repository, but that does not mean that the concept of a repository is
>> linked to having a server or a network.
>
> No, just the concept of a reliable repository. ;)
>
>>> If you don't have a satisfactory answer there, then you probably need
>>> a real database. Of course perhaps you are clever and can design your
>>> own on-disk data structures that will fail-soft in some manner under
>>> such circumstances and convince yourself beyond a reasonable doubt
>>> that it'll work, but if not ...
>>
>> CVS is an old version control system that was far better than the
>> other things around at the time it was invented, but most people seem
>> to agree that other, more modern, version control systems are better
>> and/or more reliable.
>
> Unsurprisingly. With apologies to Leonard McCoy:
>
> "Non-atomic commits. Funduscopic examination. What is this, the Dark Ages?"

:)

-- 
Michael Wood 

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

[Meikel Brandmeyer]

Hi,

Am Dienstag, 5. Juli 2011 16:15:12 UTC+2 schrieb faenvie:

> you plugin really rocks.

Thanks. Glad it helps. :)

> have you thought about contributing clojuresque as 'clojure-plugin'
> for gradle to the gradle project ?  so that it will be more integrate
> and managed like ... say the scala-plugin for gradle ?

This would be certainly a possibility, but at the moment the
quality and functionality are not sufficient to warrant
integration into gradle proper. Eg. testing is rather a hack
at the moment and nowhere near the integration level the other
plugins have.

In the end this will be the decision of the gradle maintainers.
There seem to be plans to outsource the plugins into some kind
of forge to allow non-core maintainership but still some official
supervision of quality etc.

It was noticed positively that clojuresque exists, though.

> maybe after gradle has released it's 1.0 version ?

And some more clojuresque versions, I guess. :)

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: Clojure for large programs

[Johan Gardner]

What you say especially resonates with me regarding the 'ease of use' wrt
hammering code in a highly iterative/productive way, and I have approached a
number of 'enterprise' size solutions in exactly that way with extremely
robust results (IMO of course :-)).

On 6 July 2011 08:49, Peter Taoussanis  wrote:

> Don't know if it counts as "large", but I'm running a 20,000+ LOC
> project for a 100%-Clojure web app at www.wusoup.com.
>
> My 2c: I'm not an experienced developer by any stretch of the
> imagination; this is something I'm working on completely alone, and
> yet I've so far found the whole thing incredibly manageable. I'd
> attribute that largely to Clojure.
>
> Then again, I only noticed this thread because of its relation to the
> "unknown constant tag" one ;p
>
> I'd like to open-source the whole app at some stage (or at least some
> large parts of it), but I'm also always happy to answer any questions
> from the perspective of someone using exclusively Clojure for a small
> (but hopefully growing) "production" application.
>
> One of the things I've most enjoyed about Clojure (and it being
> functional) is the ease with which I can bash on a function in the
> REPL during development: testing it with all sorts of weird/nil input,
> making sure that it'll be well behaved even if something else along
> the way gets confused.
>
> The modularity I can get with "functional" functions is reassuring for
> me as a lone developer since once I've written something and it's gone
> through that "bashing" stage- I'm normally pretty confident that it's
> more or less "right". I very rarely end up needing to come back to fix
> problems related to unexpected input, etc.
>
> Most of the time when I need to "fix" a function it's because I simply
> had the wrong idea about what it actually needed to do, rather than
> because it was doing it wrong. If that makes any sense.
>
>
> For a large project I think you probably need to be more disciplined
> with something like Clojure than, say, Java. But that's the whole
> "with great power" thing again: I think you get something valuable in
> return for being asked to exercise some discipline.
>
> Can't really comment on how easily Clojure works for large groups of
> developers as such. The flexibility thing might start losing it's
> charm when you have 10 different coding styles competing with one
> another under time constraints, etc. (where discipline starts to go
> out the window in favour of "getting stuff done").
>
> - Peter Taoussanis
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Clojure now officially supported on Heroku

[frou]

Great news. I was considering trying Google-App-Engine for Clojure,
but it looked somewhat messy. I've tried Heroku for Ruby in the past
and it was an unbelievably slick experience. I'll definitely go with
this.

On Jul 5, 6:54 pm, Mark McGranaghan  wrote:
> I'm very excited to say that Clojure is now an officially supported
> deployment option onHeroku:
>
>    http://blog.heroku.com/archives/2011/7/5/clojure_on_heroku/
>
> A big thanks to everyone in the Clojure community that helped us make
> this a reality - especially James Reeves, Phil Hagelberg, Chris
> Redinger, and Aaron Bedra.
>
> I hope this announcement proves exciting for the Clojure community and
> enables a new wave of Clojure application deployments!

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

Re: ANN: Hafni

[Jonathan Fischer Friberg]

Sorry to not get back at you earlier. I was on vacation.

iarr stands for internal arrow, it was created because the arr function
cannot be used inside the Arrow record. As of the rearrangement of the arrow
protocol, it is deprecated.

The ||| function is definitely the most confusing, but I added a docstring
that might help:
https://github.com/odyssomay/Hafni/blob/master/src/Hafni/arrow.clj

I also added your examples.

I should also say that the flow macro is deprecated in favor of the new >>>
function in version 1.0.6 (which I just uploaded).

Jonathan

On Thu, Jun 30, 2011 at 8:48 PM, Scott Jaderholm wrote:

> In arrow.clj:
>
> What is iarr an abbreviation for?
>
> Perhaps a docstring on ||| would help, I'm having trouble understanding it.
>
> Maybe add these examples, I found them helpful
>
> ((arr inc) 1)
> ;; 2
>
> ((>>> (arr inc) (arr dec)) 1)
> ;; 1
>
> ((flow (arr inc) >>> (arr inc) >>> (arr inc)) 1)
> ;; 4
>
> ((*** (arr inc)
>  (arr dec))
>  [1 1])
> ;; [2 0]
>
> ((&&& (arr inc)
>  (arr dec))
>  1)
> ;; [2 0]
>
> ((fst (arr inc)) [1 1])
> ;; [2 1]
>
> Scott
>
>
>
> On Mon, Jun 20, 2011 at 7:57 AM, Jonathan Fischer Friberg
>  wrote:
> > Hi,
> >
> > I figured that I would announce a library that I have been working on for
> a
> > while now.
> >
> > It's called Hafni, and it's a swing wrapper. Why another swing wrapper?
> > I wanted to solve the following problems:
> >
> > 1. There are a lot of boilerplate code needed.
> >
> > 2. Changes made to content is not very functional.
> >
> > 3. Changing content is (sometimes) annoyingly hard.
> >
> > To solve these problems, I looked into the very functional world of
> Haskell
> > and found something called Functional reactive programming (FRP)[1][2]
> which
> > has been used to solve problem 2 in gui programming for Haskell. To be
> able
> > to program FRP, the datatype "arrow" was created (or maybe the other way
> > around), and this is what Hafni uses. I wont go into detail here since it
> is
> > not very easy to explain in a short mail, and there are a lot of
> resources
> > out there on the subject (see the links).
> >
> > To be honest, when I first started programming on Hafni, I didn't know
> that
> > there existed other swing wrappers for java (I guess I also wanted to try
> > this myself, which meant that I didn't really search it out), but since
> they
> > do exist, lets compare Hafni to the two I have seen on this mailing list:
> > seesaw [3] and GUIFTW [4].
> >
> > 1. Hafni is strictly a swing wrapper and does not claim to be anything
> else.
> >Seesaw - aims to provide a ui library, "It happens to be built on
> Swing".
> >GUIFTW - "It's not tied to any GUI toolkit but instead front-ends for
> > each can be written easily."
> >
> > 2. Hafni has facilities, but is not really interested in exactly how
> > components look.
> >Seesaw - Doesn't really express an opinion about this, but seems to
> have
> > a lot of facilities for making components look a certain way.
> >GUIFTW - "Style it in a CSS fashion"
> >
> > 3. When events happen, Hafni uses the "Event" and "arrow" datatypes to
> make
> > things happen while both
> >seesaw and GUIFTW uses something that looks like
> >the standard java event function(s). It should be noted that Hafni
> > event/arrows
> >behaves exactly like corresponding for seesaw and GUIFTW if no changes
> is
> > made to content.
> >
> > The reason of 2 (which, in a way, leads to 3) is that when I wrote swing
> > code manually, the parts
> > that I were most annoyed with weren't to make things look as I wanted
> them,
> > it was changing them.
> >
> > I haven't really looked into it exactly (or tried it), but it looks like
> > seesaw and Hafni can be combined
> > since seesaw deals directly with java objects (the "config!" function is
> > especially interesting) [5].
> >
> > I would like to end this mail with an example of Hafni. This example is
> the
> > same as in the Hafni readme.
> >
> > (frame :content (comp-and-events (button :text "*")
> >   :act (flow (output-arr this :text) >>>
> >  (arr #(str % "*")) >>>
> > (input-arr this :text)))
> > :size 200 200 :dont_exit_on_close)
> >
> > As it's already explained in the readme, let's look at the most
> interesting
> > part:
> >
> > (flow (output-arr this :text) >>> (arr #(str % "*")) >>> (input-arr this
> > :text))
> >
> > This code snippet says that the current text of the button created with
> > (button :text "*") should "flow" to
> > the function #(str % "*") which adds a "*" to the text, which should flow
> to
> > the text of that same button.
> > The result of this is that when the button is pressed, the text of that
> > button is changed as follows:
> > "*"
> > "**"
> > "***"
> > ""
> > etc ...
> >
> > And finally, the link to Hafni: https://github.com/odyssomay/Hafni
> >
> > ___
> >
> > I really hope that someone finds this proje

Re: Please stand firm against Steve Yegge's "yes language" push

[James Keats]

On Jul 5, 11:07 pm, faenvie  wrote:
> note on the original posting:
>
> > First, he shouldn't be porting Java code to clojure, Second, Clojure IS
> > fundamentally different from Java, and third, such said users who
> > don't want to touch Java should not touch Clojure.
>
> to port java-code to clojure-code is certainly not the
> right thing to do in most cases ... but
>
> the fact that clojure is not determined to use the jvm as its
> hosting-language could certainly be a driver for the reimplementation
> of popular components.
>
> even memory-management (gc), io-functions and process-management
> may be candidates for a (re)implementation in clojure some day.

I recently read this and I think it's a very sensible position:


Fogus: Different target hosts would naturally support different
subsets of Clojure’s functionality. How do you plan to unify the
ports?

Hickey: I don’t. It has not been, and will not be, the objective of
Clojure to allow porting of large programs from one host to another.
That is simply a waste of time, and needed by almost no one.
Currently, you often have to change languages when you change hosts—
from Java to C# or Javascript. This is better than that, while short
of some full portability layer. The idea is to be able to take one’s
knowledge of Clojure and its core libraries, and of the host du jour,
and get something done. Certainly, non-IO libraries, like Clojure’s
core, can move between hosts. The JVM and CLR have rough capability
parity. We’ll have to see how restrictive a Javascript host might be.

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

[Konrad Hinsen]

On 5 Jul, 2011, at 20:38 , Laurent PETIT wrote:

> a) Select your project's node in the Package Explorer
> b) Trigger its contextual menu, select "Run as", select "Clojure Application"
> I *insist* (*) : you must trigger the Run from the project's node.
> Only with the project's node will the incremental compilation be
> activated for the started process' JVM.

Ah..

> Then you should see:

All I see in Eclipse is the REPL view. No Java console view, no "background" 
job, unless I don't know where to look. After a while, I also get a namespace 
browser, and shortly thereafter the classes show up in "classes". But this 
takes around five minutes, perhaps I was simply not patient enough. Or perhaps 
I started the REPL from something else than the project node.

> Currently, there's one drawback : CCW does not refrain AOT compilation
> from "compiling too much things", nor does it remove AOT compilation
> artifacts that should generally not be desired (e.g. anything in
> packages not being related to the project's own namespaces).

I simply don't put them into the fat jar. Not as convenient as it should be (in 
particular since I need to do it again every time I make a fat jar), but at 
least I get the result I want.

> (*) : In contrast, if you trigger a run of "Clojure Application" from
> the contextual menu of a specific clojure lib file, the process will
> not be started in "project mode", but in "file mode".

That difference is not easy to see from the menu text. Apparently it is 
important nevertheless.

Some quick tests work as they should, so it seems my build is correct. Thanks a 
lot for your help!

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: Please stand firm against Steve Yegge's "yes language" push

[Carlos Ungil]

On Tuesday, July 5, 2011 8:08:51 PM UTC+2, Sean Corfield wrote:
>
> It might be an interesting community exercise to examine the 23 GoF 
>
patterns and discuss whether they are applicable in an FP world and, 
>
if a pattern _is_ still applicable, what it would look like?
>

Hi Sean,

take a look at http://norvig.com/design-patterns/index.htm 

I think it corresponds to what you're suggesting.

Cheers,

Carlos

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

Leiningen 1.6.1 released

[Phil Hagelberg]

Hello folks.

I just pushed out Leiningen 1.6.1! http://bit.ly/lein-news

Highlights in this release include:

* New search task: find dependencies in all remote repositories (not
  just clojars) from the command-line.

* New retest task: re-run only the tests that failed in the last run.

* New trampoline task avoids creation of project subprocess. (Useful to
  save memory in settings like Heroku.)

* Support dependencies that contain native libraries.

* Support constructing classpath out of ~/.m2 instead of copying to
  lib/ by setting :local-repo-classpath true in project.clj.

As always, pull in the latest by running "lein upgrade". (The Windows
version will be updated soon.) Give it a try!

Last week version 1.6.0 was released, but it had a few issues, so it
wasn't widely announced. Those issues have been addressed in 1.6.1.

-Phil

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

Re: Clojure for large programs

[Raoul Duke]

On Wed, Jul 6, 2011 at 3:18 AM, Johan Gardner  wrote:
> What you say especially resonates with me regarding the 'ease of use' wrt
> hammering code in a highly iterative/productive way, and I have approached a
> number of 'enterprise' size solutions in exactly that way with extremely
> robust results (IMO of course :-)).

for those of you who
(a) find such reports tantalizing
and
(b) don't totally dislike static typing, especially when done with inference
i suggest checking into things in the ML family of languages. i found
that when i used SML it gave me the same amazing feeling only more so.

sincerely.
$0.02.

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

Re: Leiningen 1.6.1 released

[Sergey Didenko]

Hi Phil,

Is it an intention or a bug that dev-dependencies are being copied into
"lib/dev" when :local-repo-classpath is true?

Regards, Sergey.

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

Re: Leiningen 1.6.1 released

[Phil Hagelberg]

Sergey Didenko  writes:

> Is it an intention or a bug that dev-dependencies are being copied
> into "lib/dev" when :local-repo-classpath is true?

This is necessary since those dependencies need to be available to
Leiningen's own process, which has to be launched before project.clj is
parsed. Unfortunately lib/dev has to be hard-coded into the shell script.

-Phil

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

Re: Unknown constant tag 32 in class file error

[Alessio Stalla]

On 6 Lug, 09:07, Ken Wesson  wrote:
> On Tue, Jul 5, 2011 at 4:32 PM, Alessio Stalla  
> wrote:
> > On 5 Lug, 18:49, Ken Wesson  wrote:
> >> 1. A too-large string literal should have a specific error message,
> >> rather than generate a misleading one suggesting a different type of
> >> problem.
>
> > There is no such thing as a too-large string literal in a class file.
>
> That's not what Patrick just said.

Not really; he said "65535 characters [...] is the maximum length of a
String literal in Java" (actually, it is 65535 *bytes*, not
characters) and "Clojure will generate a corrupt class if that String
is too long". The class file is incorrect, but it doesn't contain any
string longer than 64KB, because it cannot, by definition. There is no
way for the JVM to detect a string which is too long. The generated
class file contains a legal string followed by garbage; it's that
garbage that makes the class file illegal. The JVM can't know that
originally the string + garbage was intended to be a longer string. In
fact, for certain longer-than-64KB strings, a syntactically valid
class file could still be generated.

> >> 2. The limit should not be different from that on String objects in
> >> general, namely 2147483647 characters which nobody is likely to hit
> >> unless they mistakenly call read-string on that 1080p Avatar blu-ray
> >> rip .mkv they aren't legally supposed to possess.
>
> > That's a limitation imposed by the Java class file format.
>
> And therefore a bug in the Java class file format, which should allow
> any size String that the runtime allows. Using 2 bytes instead of 4
> bytes for the length field, as you claim they did, seems to be the
> specific error. One would have thought that Java of all languages
> would have learned from the Y2K debacle and near-miss with
> cyber-armageddon, but limiting a field to 2 of something instead of 4
> out of a misguided perception that space was at a premium was exactly
> what caused that, too!

A bug is a discrepancy between specification and implementation. Here,
there's no discrepancy: the JVM is correctly implementing the spec.
Now, you might argue that the spec is badly designed, and I might
agree, but it's not a "bug in Oracle's Java implementation" - any
conforming Java implementation must have that (mis)feature.

> >> 3. Though both of the above bugs are in Oracle's Java implementation,
>
> > By the above, 1. is a Clojure bug and 2. is not a bug at all.
>
> Oh, 2 is a bug alright. By your definition, Y2K bugs in a piece of
> software would also not be bugs. The users of such software would beg
> to differ.

User perception and bugs are different things.

> >> it would seem to be a bug in Clojure's compiler if it is trying to
> >> make the entire source code of a namespace into a string *literal* in
> >> dynamically-generated bytecode somewhere rather than a string
> >> *object*.
>
> > Actually it seems it's the IDE, rather than Clojure, that is
> > evaluating a form containing such a big literal. Since Clojure has no
> > interpreter, it needs to compile that form.
>
> The same problem has been reported from multiple IDEs, so it seems to
> be a problem with eval and/or load-file.

Ok, sorry, didn't know that.

> The question is not why they
> might be using String *objects* that exceed 64K, since they'll need to
> use Strings as large as the file gets*. It's why they'd *generate
> bytecode* containing String *literals* that large.
>
> And it's not IDEs that generate bytecode it's
> clojure.lang.Compiler.java that generates bytecode in this scenario.

Yes, ultimately there's a bug in the compiler regardless of where
(form "with-loooooong-string") comes from.

> * There is a way to reduce the size requirements; crudely, line-seq
> could be used to implement a lazy seq of top-level forms built by
> consuming lines until delimiters are balanced and them emitting a new
> form string, then evaluating these forms one by one. This works with
> typical source files that have short individual top-level forms and
> have at least 1 line break between any two such and would allow
> consuming multi-gig source files if anyone ever had need for such a
> thing (I'd hope never to see it unless it was machine-generated for
> some purpose). Less crudely, a reader for files could be implemented
> that didn't just slurp the file and call read-string on it but instead
> read from an IO stream and emitted a seq of top-level forms converted
> already into reader-output data structures (but unevaluated). In fact,
> read-string could then be implemented in terms of this and a
> StringInputStream whose implementation is left as an exercise for the
> reader but which ought to be nearly trivial.

Yes, that's a good way of circumventing the problem when dealing with
reasonable input files. But I don't think this is the problem we're
talking about; read on.

> >> Sensible alternatives are a) get the string to whatever
> >> consumes it by some other means than embedding it a

Re: Leiningen 1.6.1 released

[Conrad Taylor]

On Jul 6, 10:42 am, Phil Hagelberg  wrote:
> Hello folks.
>
> I just pushed out Leiningen 1.6.1!http://bit.ly/lein-news
>
> Highlights in this release include:
>
> * New search task: find dependencies in all remote repositories (not
>   just clojars) from the command-line.
>
> * New retest task: re-run only the tests that failed in the last run.
>
> * New trampoline task avoids creation of project subprocess. (Useful to
>   save memory in settings like Heroku.)
>
> * Support dependencies that contain native libraries.
>
> * Support constructing classpath out of ~/.m2 instead of copying to
>   lib/ by setting :local-repo-classpath true in project.clj.
>
> As always, pull in the latest by running "lein upgrade". (The Windows
> version will be updated soon.) Give it a try!
>
> Last week version 1.6.0 was released, but it had a few issues, so it
> wasn't widely announced. Those issues have been addressed in 1.6.1.
>
> -Phil

Hi, should people new to Clojure install tool?  Is this something that
mostly used within the command line or IDE?  I noticed a MacPort for
it
at version 1.3.1 but I guess one can easily upgrade it to the latest
by
doing the following:

lein upgrade

Thanks for any additional information that you can provide.

-Conrad

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

Re: Leiningen 1.6.1 released

[Sergey Didenko]

IMHO new people only will benefit from installing lein. It's very simple in
basic usage.

It can be used both from command line and with IDE.

Though I prefer my own scripts for starting REPL with readline instead of
"lein repl".

It can be used with Enclojure by running "lein pom" every time you update
the dependencies.

Hi, should people new to Clojure install tool?  Is this something that
> mostly used within the command line or IDE?
>

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

[Ken Wesson]

On Wed, Jul 6, 2011 at 3:28 PM, Alessio Stalla  wrote:
> On 6 Lug, 09:07, Ken Wesson  wrote:
>> On Tue, Jul 5, 2011 at 4:32 PM, Alessio Stalla  
>> wrote:
>> > On 5 Lug, 18:49, Ken Wesson  wrote:
>> >> 1. A too-large string literal should have a specific error message,
>> >> rather than generate a misleading one suggesting a different type of
>> >> problem.
>>
>> > There is no such thing as a too-large string literal in a class file.
>>
>> That's not what Patrick just said.
>
> Not really;
>> > That's a limitation imposed by the Java class file format.
>>
>> And therefore a bug in the Java class file format, which should allow
>> any size String that the runtime allows. Using 2 bytes instead of 4
>> bytes for the length field, as you claim they did, seems to be the
>> specific error. One would have thought that Java of all languages
>> would have learned from the Y2K debacle and near-miss with
>> cyber-armageddon, but limiting a field to 2 of something instead of 4
>> out of a misguided perception that space was at a premium was exactly
>> what caused that, too!
>
> A bug is a discrepancy between specification and implementation.

Your extremely narrow definition precludes the notion that a
specification can itself be in error, and therefore excludes, among
others, the famous category of Y2K bugs from meeting your definition
of "bug". It also precludes *anything* being considered a bug in any
software that lacks a formal specification distinct from its
implementation (i.e., almost ALL software!), or in the reference
implementation of any software whose formal specification is a
reference implementation rather than a design document of some sort.

> Now, you might argue that the spec is badly designed, and I might
> agree, but it's not a "bug in Oracle's Java implementation" - any
> conforming Java implementation must have that (mis)feature.

Does the JLS specify this limitation, or does it just say a string
literal is a " followed by any number of non-" characters and
\-escaped "s followed by a " or words to that effect? Because if the
latter, a conforming implementation of the Java language (as in not
directly contradicting the JLS anywhere) could permit longer string
literals, even if Oracle's does not.

>> Oh, 2 is a bug alright. By your definition, Y2K bugs in a piece of
>> software would also not be bugs. The users of such software would beg
>> to differ.
>
> User perception and bugs are different things.

Not past a certain point they aren't. One user disagreeing with the
developers can be written off as wrong. A large percentage of users
(that know about an issue) disagreeing with the developers means it's
the developers that are wrong, unless you take the extreme step of
rejecting the premise that the developers' ultimate job is serving the
needs of the software's user base. And when the developers are wrong
about something and that wrongness is expressed in the code, that
constitutes a bug, though it may not be a deviation from the
"specification" (assuming in that instance there even is a formal
specification distinct from the implementation).

>> Frankly it seems like a bit of a hack to me, though since it would be
>> used to work around a Y2K-style bug in Java it might be poetic justice
>> of a sort.
>
> It is a sort of hack, yes. An alternative might be to store constants
> in a resource external to the class file, unencumbered with silly size
> limits.

Given the deployment architecture around Java, that doesn't even add
any deployment complexity and, depending on how it is implemented, may
even make i18n easier to accomplish in some cases by freeing the
developers from having to set up a bunch of ResourceBundle
infrastructure in each codebase that needs i18n. +1.

>> I don't think so. The problem isn't with normal strings but only with
>> strings that get embedded as literals in code; and moreover, the
>> problem isn't even with those strings exceeding 64k but with whole
>> .clj files exceeding 64k. The implication is that load-file generates
>> a class that contains the entire contents of the sourcefile as a
>> string constant for some reason; so:
>>
>> a) What does this class do with this string constant? What code consumes it?
>
> Hmm, I don't think it's like you say.

Patrick said:

Does the file you are evaluating have more than 65535
characters? As far as I can tell, that is the maximum
length of a String literal in Java

This clearly implies that the problem is the .clj file exceeding the
maximum length of a string literal, and thus implies more indirectly
that the entire source file is being embedded in some class file as a
string constant. Now you seem to be denying that this is occurring. If
so, your disagreement here is with Patrick, not me.

> Without knowing anything about
> Clojure's internals, it seems to me that the problem is more likely to
> be in a form like the one Patrick posted, (clojure.lang.Compiler/load
> (java.io.StringReader. "the-whole-file-as-a-string

PragPub July 2011 - A Clojure Edition

[Miki]

Greetings,

PragPub for July 2011 is a Clojure edition. You can read it at 
http://pragprog.com/magazines/2011-07/content

Enjoy,
--
Miki

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

Re: Leiningen 1.6.1 released

[Phil Hagelberg]

Conrad Taylor  writes:

> Hi, should people new to Clojure install tool?  Is this something that
> mostly used within the command line or IDE? 

Yes, I think newcomers would benefit from installing it. Clojure is not
like most languages in that it is not "batteries included"--it's just a
library that you can include in your projects that happens to include a
primitive REPL. It's not very pleasant to interact directly with on a
regular basis.

Leiningen is designed to be used from the command-line, but it is also
integrated with various editors and IDEs.

> I noticed a MacPort for it at version 1.3.1 but I guess one can easily
> upgrade it to the latest by doing the following:
>
> lein upgrade

There have been issues reported in the past with the macports version; I
suggest installing manually (it's easy) or switching to homebrew if you
are on Mac OS X.

-Phil

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

ANN: Gantry system administration and deploy tool written in clojure

[Damon Snyder]

Hello,
I wanted to let everyone know about a tool I have been working on. I'm
calling it gantry (a type of crane that I see every day on my commute
on BART to SF and inspired by crane). I started working on it after
seeing crane (https://github.com/getwoven/crane) and seeing the
possibilities while also suffering the frustration of using capistrano
for deployment of a few non-rails apps (PHP to be specific). I was
longing for something simpler and found fabric (http://fabfile.org)
but I was disappointed when I learned that all commands are executed
sequentially (this has since been fixed I believe). I also wanted to
spend more time with clojure and see how it could be used for system
administration and scripting.

Gantry comes in two parts. The first is a command line tool and task
macro. You define tasks and the commands specified in those tasks
(provided by gantry.run) are run in parallel on each host using agents/
send-off. Here is a quick start:

$ curl -L https://github.com/downloads/drsnyder/gantry/gantry >
gantry; chmod +x gantry

$ cat > gantryfile
(use 'gantry.run)
(task hello
   (run (format "echo \"hello %s at $(hostname)\"" (:name (get-args
(get-config))
^D

$ ./gantry -H one.myhost.com,two.myhost.com -t hello -s name=bob
INFO [one.myhost.com] hello bob at one.myhost.com
INFO [two.myhost.com] hello bob at two.myhost.com

The second part is a library for running commands remotely on one or
more hosts. Here are some examples:

(use 'gantry.run)

(remote "host.com" "yum install -y atop")
(remote "host.com" "yum install -y atop" {:user "deployer"})

(remote* ["host.com", "host2.com"] "yum install -y atop" {:user
"deployer"})

(upload "host.com" "filea" "/tmp")
(upload "host.com" ["filea", "fileb"] "/tmp" {:port 222})

(upload* ["host.com", "host2.com"] ["filea", "fileb"] "/tmp" {:id "/
home/deployer/my-key"})

The jar is in clojars. Use [gantry "0.0.1-SNAPSHOT"] in your
dependencies. See https://github.com/drsnyder/gantry for the
documentation and source.

Feedback welcome!

Damon

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

[nil]

I'm on a Windows machine. Does the output below indicate that I need
something like cygwin? Thanks in advance!

[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant
[default] Running provisioner: Vagrant::Provisioners::Shell...
[default] stdin: is not a tty
[default] bash: /tmp/vagrant-shell: /bin/bash^M: bad interpreter: No
such file or directory
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

chmod +x /tmp/vagrant-shell
/tmp/vagrant-shell

The output of the command prior to failing is outputted below: [no
output]

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

Re: Please stand firm against Steve Yegge's "yes language" push

[James Keats]

On Jul 5, 7:30 pm, Sean Corfield  wrote:
> On Sun, Jul 3, 2011 at 8:04 PM, Sean Corfield  wrote:
> > On Sun, Jul 3, 2011 at 3:34 PM, James Keats  wrote:
> >> For example I suggest you look at this video/transcript and pay
> >> attention in particular to the point of debate between Joe Armstrong
> >> of Erlang and Martin Odersky of 
> >> Scalahttp://www.infoq.com/interviews/functional-langs
> >> , in particular around the point where Odersky says "I’m not quite
> >> sure I buy that...". (also of additional relevance to those two points
> >> arehttp://erlang.org/pipermail/erlang-questions/2011-May/058769.html
> >> and alsohttp://www.scala-lang.org/node/1637), and if you're further
> >> interested you may wish to read Eric Meyer's essay in the book
> >> Beautiful Architecture regarding a previous Simon Peter Jones Haskell-
> >> related publication, titled "Software Architecture: Object-Oriented
> >> Versus Functional".
>
> > I've read that book (a month or two ago) but I'll go back and re-read
> > that essay in light of this thread.
>
> I think you mean Bertrand Meyer's piece, extolling the virtues of OO
> in general (and Eiffel in particular)? I thought it was a terribly
> self-serving piece. Meyer has a strong bias and quite a bit of disdain
> for anything that isn't Eiffel - which shines right thru that essay to
> the point of making it fairly worthless, IMO. It has no objectivity :)
>

It was an amusing read somewhat - at points hilarious (I'm actually a
fan of Meyer!), but it needs to be considered within a long... what to
call it... well, debate or dispute that I've long observed between the
Haskell and Eiffel communities; both are concerned with correct
software, but come at it in different ways. I believe both are
relevant, Haskell's statelessness and Meyer's design by contract.

> I read the interview transcript for Syme, Armstrong and Odersky and I
> have to be honest that I found Armstrong almost incoherent and half
> the time couldn't figure out what he was trying to argue at all - so
> I'm not sure what point you're trying to make by referring to that
> interview, sorry. Similarly Armstrong's musings on the Erlang list
> about the entire world being a single flat "namespace" full of
> functions that are globally unique seems rather incoherent too. He
> talks about the problems with using modules to organize functions
> (and, yes, modularity can be hard) but then proposes something that
> would be no different (functions made unique by either having nearly
> random names or a structured set of metadata that would really be
> indistinguishable from modules in the first place - 
> seehttp://erlang.org/pipermail/erlang-questions/2011-May/058773.html).
>

Armstrong can come across as incoherent but if you read him again and
again and again I find more and more and more in what he says. In any
case, what he's suggesting there reminds me of something I read years
ago by Dr Richard Hipp of Sqlite and Tcl core, where he suggests
instead of putting your program in files you put it in a database
http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html


> The Scala forum discussion is more useful and relevant: TL;DR -
> objects are occasionally the most natural model for solving a problem.
> And in Clojure, mutable (shared) state is "occasionally" the most
> natural model for solving a problem. That doesn't seem newsworthy to
> me, just that a pure functional approach might not always lead to the
> cleanest solution. That's kind of a "duh!" because otherwise why would
> we need STM...

I think the point he was making was not so much that, but that OOP
allows you to defer implementation and there's value in that.

>
> And then there's the Ruby rant. Yeah, I'd be pretty ticked off that I
> got shot in the foot by combining two or three libraries that
> otherwise ought to behave reasonably together. Global method injection
> is pretty nasty. When I first read about multi-methods and protocols
> in Clojure I was a bit worried that library code might cause a similar
> problem by redefining functions out from under me, by virtue of more
> specific "overloading" but it hasn't been a problem yet and when I
> look at how those features are used in various libraries, I'm no
> longer so worried.
>
> I have other reasons for not liking Ruby so it's ability to shoot you
> in the foot like that doesn't change my opinion of the language (nor
> does it change its widespread popularity for a certain class of
> programmers / companies).
>
> Overall then, modularity is hard and sometimes a shared / mutable
> state solution is cleaner... And I agree with both points. Am I
> missing something in your concerns?

No, you're spot on. I wasn't advocating anything in particular, I was
merely suggesting that some of the finest minds in the industry do
still find this a hard problem and can disagree on to how best to deal
with it. :-)

I personally don't feel that much of a schism between functional and
OO, but perhaps that

Re: Please stand firm against Steve Yegge's "yes language" push

[nchubrich]

I've been using Clojure on and off for a whilecurrently off,
though not because of the language itself.  The thread now seems to
have moved in a different direction, but I have to say (looking at the
Seajure and Y Combinator threads) that Steve Yegge has some good
points.  And ending up here with a thread titled "stand firm
against..." seems to be exactly the sort of community problem that he
is worried about.

I wish that we did not have to deal with a fundamental disagreement
about what a language is \for.  If a programming language is something
like Hermann Hesse's Glass Bead Gamean intellectual diversion for
superior intellectsthen spending time contemning "Joe Developer"
and "deploring" people who want to suggest different directions for
the language is a worthwhile activity.  But ultimately programming
languages are about getting things \done, just as cars are about
\going places.

It is still possible (though increasingly difficult) to tinker with
your own car before driving it.  In the beginning, it was obligatory.
You had to choose a third-party auto-body manufacturer.  You had to
crank the engine yourself.  You even had to manually set the ignition
timing while you were driving.  There was a lot of cruft you had to
deal with that had nothing to do with getting from point A to point
B.  The first users of cars had to be willing to work with them as a
kind of \hobbyyou had to give over a certain amount of time out of
your day just to just keeping the things running.  At some point, a
transition happened.  They became mass-market devices.  The tinkerers
never went away, but their increased numbers, and the increased
numbers of people simply \using cars, led to an increase in simplicity
and reliability.  Every time there was an issue to deal with, there
were that many more people with a stake in fixing it.  Some people may
miss the old hobbyist culture around cars, but I don't think anyone
really wants to go back to Model T days.  The remarkable thing
nowadays is that a \huge number of people become good drivers
(although admittedly there are quite a few that shouldn't be on the
roads)and driving is a fairly demanding and crucial activity.
Sadly, we cannot say the same thing for computer users.

Clojure is still in the Model T days (though it is continuously
improving).  Getting a non-broken Emacs setup is not always easy (I
attended a Clojure class a few weeks ago where we spent the first
couple of hours just trying to get Clojure and Emacs working).  There
is no built-in command-line REPL or interpreter.  Debugging is cryptic
and not particularly helpful, and occasionally outright misleading
(see what someone posted to the Seajure and Y Combinator threads on
his roundabout way of discovering that Clojure needed advance
declarations).  The documentation is not quite as consolidated and
organized as the Java or Python documentation (though it has also
gotten better), and people really wanting to get things done must deal
with two independent sets of documentation, Java and Clojure, the
latter of which is simply organized alphabetically.  Supposing that
they do get over this hump and now wish to develop a practical
project, they are immediately faced with more choices.  There is no
standard, immediate path for developing web apps, GUIs, or even shell
scriptsyou have to use your sixth sense of what libraries may or
may not actually work (which on the Internet can be quite difficult,
as something that doesn't really work rarely \tells you so itself).

You can jump into Python as a complete noob in the morning, and have a
useful program by the afternoon.  This is much less likely to happen
with Clojure.  There are plenty of smart people who lack both the time
and the system administration chops to deal with getting into
Clojure.  This is very sad, because once you get into it, Clojure is
very easy and very sensible.  There are surely many great programs
that are not being writtensome of them would be programs that help
smoothe the way for everyone else.  Many people who would help spread
the functional programming gospel are getting their brains fried in
Python and Javaand teaching them will be that much harder when
they eventually come around (as people have pointed out here).

Now all of the rough edges are perfectly understandable for a new
language, and they continue to get betterand the more you are
willing to Google around and read blogs and so forth, the more
solutions you find.  But what bothers Steve Yegge and many other
people, I suspect, is that fixing this fragmented user experience and
the gaps in the language doesn't really seem to be a prioritywhen
in fact it should be a prime mission.  People actually make the
argument that these difficulties are good "weed outs" for the "joe
developers" who would (presumably) get in here and muck everything
up.  I have actually heard people say here that people who don't have
the wherewithal to configure emacs and 

Re: Clojure for large programs

[Zach Tellman]

I agree that namespaces should be designed to be consumed, but that can be 
pretty taxing on the developer.  In my libraries, I tend to split the 
functions into whatever sub-namespaces I want to keep the organization easy 
for me, and then import all the functions I want to expose into a 
higher-level namespace.

For example, in Aleph I have HTTP functionality implemented in 
aleph.http.client, aleph.http.server, aleph.http.websocket, etc. but all the 
useful functions are gathered together into aleph.http.  This means that I 
don't have to navigate a monolithic namespace, but the users of my library 
don't have to declare a dozen namespaces to get anything done.  I find this 
approach scales for me pretty well, and I haven't heard any complaints from 
the people using my libraries about the organization.

Zach

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[Phil Hagelberg]

nchubrich  writes:

> A few people could spend a few tens of hours making things easier for
> everyone else, thereby saving thousands of man-hours (isn't this
> supposed to be what programming is about in the first place?), and yet
> it doesn't happen.

Really? It doesn't happen?

http://groups.google.com/group/clojure/browse_thread/thread/b87468adeffcd899
http://groups.google.com/group/clojure/browse_thread/thread/bdf5e874f5367b7e
http://groups.google.com/group/clojure/browse_thread/thread/b86a60e252031e74
http://groups.google.com/group/clojure/browse_thread/thread/eb259e999d381d5d
http://groups.google.com/group/clojure/browse_thread/thread/20d314bc0a23b574
http://groups.google.com/group/clojure/browse_thread/thread/48b8fcb3e9b30474

Maybe the twenty minutes spent drafting this voluminous post could have
been better spent doing something a bit more tangible to make things better.

-Phil

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

Correct way to define the else clause of a cond form?

[Conrad Taylor]

Hi, what's the correct way to define an else clause of a cond form?
For example,

a)

(cond
   (= total 20) 8.75
   (or (amount > 20) (= country "US") 9.75)
   (else 10.0))

b)

(cond
   (= total 20) 8.75
   (or (amount > 20) (= country "US") 9.75)
   :default 10.0)

c)

(cond
   (= total 20) 8.75
   (or (amount > 20) (= country "US") 9.75)
   10.0 )

d)

(cond
   (= total 20) 8.75
   (or (amount > 20) (= country "US") 9.75)
   :else 10.0 )






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

Re: emacs-clojure-vagrant: a sane development virtual environment

[Justin Lilly]

I don't have access to a windows machine to help you debug this, but
this is squarely an issue with the vagrant installation. I would
suggest reading

http://vagrantup.com/docs/getting-started/setup/windows.html

As a starting point. Vagrant related channels should be able to help
you further (but please communicate your solution back to the group!).

Thanks,
 -justin

On Wed, Jul 6, 2011 at 2:20 PM, nil  wrote:
> I'm on a Windows machine. Does the output below indicate that I need
> something like cygwin? Thanks in advance!
>
> [default] VM booted and ready for use!
> [default] Mounting shared folders...
> [default] -- v-root: /vagrant
> [default] Running provisioner: Vagrant::Provisioners::Shell...
> [default] stdin: is not a tty
> [default] bash: /tmp/vagrant-shell: /bin/bash^M: bad interpreter: No
> such file or directory
> The following SSH command responded with a non-zero exit status.
> Vagrant assumes that this means the command failed!
>
> chmod +x /tmp/vagrant-shell
> /tmp/vagrant-shell
>
> The output of the command prior to failing is outputted below: [no
> output]
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[Mark Rathwell]

> And ending up here with a thread titled "stand firm
> against..." seems to be exactly the sort of community problem that he
> is worried about.

To be fair, this post and its title were the work of an individual who has
only been in this community for about 3 weeks.  And while that individual,
and everyone else, is completely entitled to their beliefs, and those
beliefs may be justified from the perspective they were written from, it is
unfair to ascribe them to the community as a whole (which is growing large
and very diverse).  You can see in the responses, as is almost always seen
in this community, the calm, reasoned and balanced behavior of the group as
a whole.

> But what bothers Steve Yegge and many other
> people, I suspect, is that fixing this fragmented user experience and
> the gaps in the language doesn't really seem to be a prioritywhen
> in fact it should be a prime mission.

Again, to be fair, the problem is not a lack of effort on the part of the
community.  The problem is multiple fold: everyone has their own idea of
what the ideal new user experience should be, and it is an extraordinarily
massive amount of work and a lot of trial and error to go from zero to easy
for everyone.  Python has had 15+ years to get to that point, Clojure is at
3+.  Needs are seeming to be addressed at a reasonable rate, in my view.
 Not to be rude, only practical: if there are itches you are having that are
not being scratched, it would be far more productive to do something about
it than complain that others are not pulling their weight.




On Wed, Jul 6, 2011 at 7:30 PM, nchubrich  wrote:

> I've been using Clojure on and off for a whilecurrently off,
> though not because of the language itself.  The thread now seems to
> have moved in a different direction, but I have to say (looking at the
> Seajure and Y Combinator threads) that Steve Yegge has some good
> points.  And ending up here with a thread titled "stand firm
> against..." seems to be exactly the sort of community problem that he
> is worried about.
>
> I wish that we did not have to deal with a fundamental disagreement
> about what a language is \for.  If a programming language is something
> like Hermann Hesse's Glass Bead Gamean intellectual diversion for
> superior intellectsthen spending time contemning "Joe Developer"
> and "deploring" people who want to suggest different directions for
> the language is a worthwhile activity.  But ultimately programming
> languages are about getting things \done, just as cars are about
> \going places.
>
> It is still possible (though increasingly difficult) to tinker with
> your own car before driving it.  In the beginning, it was obligatory.
> You had to choose a third-party auto-body manufacturer.  You had to
> crank the engine yourself.  You even had to manually set the ignition
> timing while you were driving.  There was a lot of cruft you had to
> deal with that had nothing to do with getting from point A to point
> B.  The first users of cars had to be willing to work with them as a
> kind of \hobbyyou had to give over a certain amount of time out of
> your day just to just keeping the things running.  At some point, a
> transition happened.  They became mass-market devices.  The tinkerers
> never went away, but their increased numbers, and the increased
> numbers of people simply \using cars, led to an increase in simplicity
> and reliability.  Every time there was an issue to deal with, there
> were that many more people with a stake in fixing it.  Some people may
> miss the old hobbyist culture around cars, but I don't think anyone
> really wants to go back to Model T days.  The remarkable thing
> nowadays is that a \huge number of people become good drivers
> (although admittedly there are quite a few that shouldn't be on the
> roads)and driving is a fairly demanding and crucial activity.
> Sadly, we cannot say the same thing for computer users.
>
> Clojure is still in the Model T days (though it is continuously
> improving).  Getting a non-broken Emacs setup is not always easy (I
> attended a Clojure class a few weeks ago where we spent the first
> couple of hours just trying to get Clojure and Emacs working).  There
> is no built-in command-line REPL or interpreter.  Debugging is cryptic
> and not particularly helpful, and occasionally outright misleading
> (see what someone posted to the Seajure and Y Combinator threads on
> his roundabout way of discovering that Clojure needed advance
> declarations).  The documentation is not quite as consolidated and
> organized as the Java or Python documentation (though it has also
> gotten better), and people really wanting to get things done must deal
> with two independent sets of documentation, Java and Clojure, the
> latter of which is simply organized alphabetically.  Supposing that
> they do get over this hump and now wish to develop a practical
> project, they are immediately faced with more choices.  There is no
> stand

Re: Correct way to define the else clause of a cond form?

[Benny Tsai]

I believe (d) is considered the idiomatic way*.  Btw, I think the second 
case may not be written correctly; if the intended logic is that 9.75 should 
be returned when either amount > 20 or country = "US", the code should look 
something like this:

(cond (= total 20) 8.75
  (or (> amount 20) (= country "US")) 9.75
  :else 10.0)

*See: http://dev.clojure.org/display/design/Library+Coding+Standards

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

[Tim Robinson]

In addition to Benny's suggestion -  I will suggest, for future
reference, that the ClojureDocs website does an brilliant job in
showing some examples. It really is a valuable resource that I've come
to rely on.

http://clojuredocs.org/clojure_core/clojure.core/cond

And what's interesting to note is the comment made near the bottom:

"We should add a comment in the docstring for the final usage
of :else."

Isn't that a coincidence :)

On Jul 6, 6:34 pm, Conrad Taylor  wrote:
> Hi, what's the correct way to define an else clause of a cond form?
> For example,
>
> a)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    (else 10.0))
>
> b)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    :default 10.0)
>
> c)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    10.0 )
>
> d)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    :else 10.0 )

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

I cannot scroll up down REPL in konsole

[Antonio Recio]

In the default terminal of KDE linux, konsole, when I am using REPL I 
cannot scroll up down. When I get a long message I can only read the last 
lines. Is there any way to scroll up down the REPL in konsole (or other 
linux terminal)? (I think it is possible in emacs or vim, but I am 
interested in konsole.)

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

[Aaron Bedra]

I haven't had any issues in gnome-terminal, xterm, or iterm2.  I suggest
trying another terminal to see if it's a problem with konsole or your setup.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Wed, Jul 6, 2011 at 9:21 PM, Antonio Recio  wrote:

> In the default terminal of KDE linux, konsole, when I am using REPL I
> cannot scroll up down. When I get a long message I can only read the last
> lines. Is there any way to scroll up down the REPL in konsole (or other
> linux terminal)? (I think it is possible in emacs or vim, but I am
> interested in konsole.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Correct way to define the else clause of a cond form?

[Conrad Taylor]

On Jul 6, 6:07 pm, Benny Tsai  wrote:
> I believe (d) is considered the idiomatic way*.  Btw, I think the second
> case may not be written correctly; if the intended logic is that 9.75 should
> be returned when either amount > 20 or country = "US", the code should look
> something like this:
>
> (cond (= total 20) 8.75
>       (or (> amount 20) (= country "US")) 9.75
>       :else 10.0)
>
> *See:http://dev.clojure.org/display/design/Library+Coding+Standards

Benny, thanks for the reference.

-Conrad

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

[Antonio Recio]

With xterm works fine. 
Are other people with konsole?

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

[Antonio Recio]

I have discovered the cause of the problem, it is screen. When I am using 
repl with screen I cannot scroll up down with konsole or xterm. Without 
screen works fine in konsole or xterm. 

Is there other people with problem with screen and scroll down up repl?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[nchubrich]

To Phil: I am certainly not complaining about your efforts on
Leiningen, Swank, etc.  I appreciate them and use themthey have
already made things vastly easier for people, and the problems with
setting up Emacs, certainly, are probably more to do with Emacs
itself.  I am just pointing out that there is still a long way to go
with the overall user experience, documentation, etc.; and as long as
this remains, Steve Yegge will have a point, and it is not fair to
simply dismiss what he says.  The original poster in this thread was
arguing that Clojure has no need to grow to a larger community.  He
also was arguing essentially that barriers to new users were a \good
thing.  I just wanted to argue against this, and indeed it ended up
being at some length.  If I have offended anyone in doing so, that was
not my intent.

When the transition to a more broad-based language happens, then there
will end up being a lot more users than there are people with the
ability to make fundamental changes in the language.  They may make
small improvements that don't get much attention, or they may simply
be users with suggestions.  There is nothing wrong with either of
these things.  I don't think their experience is any less important
than people who "pull their weight".  Telling them always to "fix it
yourself" is not necessarily going to improve thingsI think we are
all well aware that we should make contributions if we are able.  What
fraction of Python users end up making any contribution at all?  Are
they a bad thing for Python?

As to making contributions, I just pointed out an example of someone
who made a contribution and was ignored.  And as to improving
documentation, how is one to go about doing it?  This would be an
excellent area to have some community effort on, especially from
relative beginners, and that is an itch I would not mind scratching.

It isn't my intention to disparage the community.  It is a very good
and active community; but this doesn't mean it isn't capable of
improving, even based on suggestions from outsiders like Steve Yegge.
Mark has a good point that the original poster is a fairly new member,
and he is also right that there have been a lot of balanced
responses.  I felt however that nobody had really spoken directly and
fully against his basic premiseif someone had, I would not have
said anything.

It is also correct to say that fixing many issues with user experience
is a lot of hard work.  I don't dispute that (and I was certainly
exagerrating to say it would only take tens of hours).  But there also
seem to be things that might make a very big difference in initial
impression, and would also not be too much trouble.  I don't really
know much about packaging, but is it really necessary (for 3+ years)
to tell users under 'getting started' to type "java -cp
jline-0_9_5.jar:clojure.jar jline.ConsoleRunner clojure.main" as their
first introduction to Clojure?  (This is what I was talking about with
respect to difficulties in shell scripting.)  The fact that it has
remained under "getting started" for all this time (in a place where
virtually every new user is going to visit within his first five
minutes)this sets the tone to a certain extent, and it makes
impressions about where the priorities of the community might be.  It
also gives a mistaken impression that the language is not ready yet
which is entirely untrue.  When Yegge talks about "marketing" a
language, this is exactly the kind of thing he is talking about.

There may be points of disagreement as to how exactly the user
experience should improve, but I hope that the goal of getting new
users up to speed and writing useful code quickly is not really a
controversial one.

Needless to say, I have gone on long enough

--Nick.


On Jul 6, 5:53 pm, Mark Rathwell  wrote:
> > And ending up here with a thread titled "stand firm
> > against..." seems to be exactly the sort of community problem that he
> > is worried about.
>
> To be fair, this post and its title were the work of an individual who has
> only been in this community for about 3 weeks.  And while that individual,
> and everyone else, is completely entitled to their beliefs, and those
> beliefs may be justified from the perspective they were written from, it is
> unfair to ascribe them to the community as a whole (which is growing large
> and very diverse).  You can see in the responses, as is almost always seen
> in this community, the calm, reasoned and balanced behavior of the group as
> a whole.
>
> > But what bothers Steve Yegge and many other
> > people, I suspect, is that fixing this fragmented user experience and
> > the gaps in the language doesn't really seem to be a prioritywhen
> > in fact it should be a prime mission.
>
> Again, to be fair, the problem is not a lack of effort on the part of the
> community.  The problem is multiple fold: everyone has their own idea of
> what the ideal new user experience should be, and it is an extraordinari

Re: Correct way to define the else clause of a cond form?

[David Sletten]

Conrad,

The syntax of 'cond' is actually pretty straightforward. Following the symbol 
'cond' you have pairs of predicate forms and consequent expressions. The 'cond' 
form evaluates each predicate in turn until one evaluates to true and then 
returns the value of the corresponding consequent form. Many 'cond' forms have 
a default value that is returned when none of the predicates succeed. Remember 
that in Clojure only the value 'false' and the value 'nil' are considered 
false. Everything else is true. By convention we use the keyword ':else' as a 
'predicate' for the default case. Since ':else' is neither 'false' nor 'nil', 
it is considered to be true, and if the 'cond' form reaches the ':else' clause, 
then the default value will be returned.

Given these restrictions, only a) and c) are syntactically correct. And even 
they don't do what you want.

> a)
> 
> (cond
>   (= total 20) 8.75
>   (or (amount > 20) (= country "US") 9.75)
>   (else 10.0))
> 

Here we have:
predicate | consequent
(= total 20) | 8.75
(or (amount > 20) (= country "US") 9.75) |  (else 10.0)

Unfortunately, (else 10.0) winds up as the consequent of the 2nd predicate. 
Furthermore, 'else' is not a Clojure operator. Unless you've defined a function 
or macro named 'else' you will get an error.

> b)
> 
> (cond
>   (= total 20) 8.75
>   (or (amount > 20) (= country "US") 9.75)
>   :default 10.0)
> 

predicate | consequent
 (= total 20) | 8.75
 (or (amount > 20) (= country "US") 9.75) | :default
 10.0 | ???

These are not paired up properly.

> c)
> 
> (cond
>   (= total 20) 8.75
>   (or (amount > 20) (= country "US") 9.75)
>   10.0 )

predicate | consequent
 (= total 20)  | 8.75
 (or (amount > 20) (= country "US") 9.75) | 10.0

Not what you expected...

> 
> d)
> 
> (cond
>   (= total 20) 8.75
>   (or (amount > 20) (= country "US") 9.75)
>   :else 10.0 )

predicate | consequent
 (= total 20)  | 8.75
 (or (amount > 20) (= country "US") 9.75) |  :else
 10.0 | ???

Not syntactically correct.

Here's what you want to use:
(cond
  (== total 20) 8.75
  (or (> amount 20) (= country "US")) 9.75
  :else 10.0)

(Note that '==' is the proper predicate for numerical equality.)

Have all good days,
David Sletten




-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[Ken Wesson]

On Wed, Jul 6, 2011 at 10:06 PM, nchubrich  wrote:
> As to making contributions, I just pointed out an example of someone
> who made a contribution and was ignored.

Does the term "tl;dr" mean anything to you? I doubt very many people
got that far in the wall of text you posted earlier, especially in
just the few hours it's been since you posted 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: I cannot scroll up down REPL in konsole

[Ken Wesson]

On Wed, Jul 6, 2011 at 9:40 PM, Antonio Recio  wrote:
> I have discovered the cause of the problem, it is screen. When I am using
> repl with screen I cannot scroll up down with konsole or xterm. Without
> screen works fine in konsole or xterm.
> Is there other people with problem with screen and scroll down up repl?

Only the ones still dialing into time-share Unix systems to hack, I
suspect. Nobody uses "screen" anymore since you can just use multiple
xterms and it works much better. As you've found, "screen" eats some
keypresses meant for the nested application, among other things.

-- 
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: Please stand firm against Steve Yegge's "yes language" push

[nchubrich]

It did go on too long.  I hope when someone \does read it, they will
see I am not being wholly unreasonable.

On Jul 6, 7:21 pm, Ken Wesson  wrote:
> On Wed, Jul 6, 2011 at 10:06 PM, nchubrich  wrote:
> > As to making contributions, I just pointed out an example of someone
> > who made a contribution and was ignored.
>
> Does the term "tl;dr" mean anything to you? I doubt very many people
> got that far in the wall of text you posted earlier, especially in
> just the few hours it's been since you posted 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: Correct way to define the else clause of a cond form?

[Conrad Taylor]

On Jul 6, 5:34 pm, Conrad Taylor  wrote:
> Hi, what's the correct way to define an else clause of a cond form?
> For example,
>
> a)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    (else 10.0))
>
> b)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    :default 10.0)
>
> c)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    10.0 )
>
> d)
>
> (cond
>    (= total 20) 8.75
>    (or (amount > 20) (= country "US") 9.75)
>    :else 10.0 )

I'm getting the error message at the line where cond is being defined:

Unable to resolve symbol: ? in this context

At line 14, I have the following:

(cond

This is kind of cryptic as it can get being that this is defined by
the core language unless I need to import a library/module/form.
>From the documentation, I have everything correct but I'm seeing
two different errors for 1.2.0 and 1.3.0.

-Conrad

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

[Benny Tsai]

Could you please post the entire form, including the code surrounding the 
cond form (since total, amount, and country need to be defined somewhere)?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[Luc Prefontaine]

And I thought my posts were long :)

Luc P.

On Wed, 6 Jul 2011 19:26:04 -0700 (PDT)
nchubrich  wrote:

> It did go on too long.  I hope when someone \does read it, they will
> see I am not being wholly unreasonable.
> 
> On Jul 6, 7:21 pm, Ken Wesson  wrote:
> > On Wed, Jul 6, 2011 at 10:06 PM, nchubrich 
> > wrote:
> > > As to making contributions, I just pointed out an example of
> > > someone who made a contribution and was ignored.
> >
> > Does the term "tl;dr" mean anything to you? I doubt very many people
> > got that far in the wall of text you posted earlier, especially in
> > just the few hours it's been since you posted 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.
> 



-- 
Luc P.


The rabid Muppet

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

[Conrad Taylor]

On Jul 6, 7:16 pm, David Sletten  wrote:
> Conrad,
>
> The syntax of 'cond' is actually pretty straightforward. Following the symbol 
> 'cond' you have pairs of predicate forms and consequent expressions. The 
> 'cond' form evaluates each predicate in turn until one evaluates to true and 
> then returns the value of the corresponding consequent form. Many 'cond' 
> forms have a default value that is returned when none of the predicates 
> succeed. Remember that in Clojure only the value 'false' and the value 'nil' 
> are considered false. Everything else is true. By convention we use the 
> keyword ':else' as a 'predicate' for the default case. Since ':else' is 
> neither 'false' nor 'nil', it is considered to be true, and if the 'cond' 
> form reaches the ':else' clause, then the default value will be returned.
>
> Given these restrictions, only a) and c) are syntactically correct. And even 
> they don't do what you want.
>
> > a)
>
> > (cond
> >   (= total 20) 8.75
> >   (or (amount > 20) (= country "US") 9.75)
> >   (else 10.0))
>
> Here we have:
> predicate | consequent
> (= total 20) | 8.75
> (or (amount > 20) (= country "US") 9.75) |  (else 10.0)
>
> Unfortunately, (else 10.0) winds up as the consequent of the 2nd predicate. 
> Furthermore, 'else' is not a Clojure operator. Unless you've defined a 
> function or macro named 'else' you will get an error.
>
> > b)
>
> > (cond
> >   (= total 20) 8.75
> >   (or (amount > 20) (= country "US") 9.75)
> >   :default 10.0)
>
> predicate | consequent
>  (= total 20) | 8.75
>  (or (amount > 20) (= country "US") 9.75) | :default
>  10.0 | ???
>
> These are not paired up properly.
>
> > c)
>
> > (cond
> >   (= total 20) 8.75
> >   (or (amount > 20) (= country "US") 9.75)
> >   10.0 )
>
> predicate | consequent
>  (= total 20)  | 8.75
>  (or (amount > 20) (= country "US") 9.75) | 10.0
>
> Not what you expected...
>
>
>
> > d)
>
> > (cond
> >   (= total 20) 8.75
> >   (or (amount > 20) (= country "US") 9.75)
> >   :else 10.0 )
>
> predicate | consequent
>  (= total 20)  | 8.75
>  (or (amount > 20) (= country "US") 9.75) |  :else
>  10.0 | ???
>
> Not syntactically correct.
>
> Here's what you want to use:
> (cond
>   (== total 20) 8.75
>   (or (> amount 20) (= country "US")) 9.75
>   :else 10.0)
>
> (Note that '==' is the proper predicate for numerical equality.)
>

Is this true for comparing integer values?  I ask this question
because
I read the following in the documentation:

http://clojuredocs.org/clojure_core/clojure.core/=

-Conrad

> Have all good days,
> David Sletten

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

Re: Clojure for large programs

[Glen Stampoultzis]

On 7 July 2011 09:39, Zach Tellman  wrote:

> I agree that namespaces should be designed to be consumed, but that can be
> pretty taxing on the developer.  In my libraries, I tend to split the
> functions into whatever sub-namespaces I want to keep the organization easy
> for me, and then import all the functions I want to expose into a
> higher-level namespace.
>
> For example, in Aleph I have HTTP functionality implemented in
> aleph.http.client, aleph.http.server, aleph.http.websocket, etc. but all the
> useful functions are gathered together into aleph.http.  This means that I
> don't have to navigate a monolithic namespace, but the users of my library
> don't have to declare a dozen namespaces to get anything done.  I find this
> approach scales for me pretty well, and I haven't heard any complaints from
> the people using my libraries about the organization.
>

I think that's a fairly sane way to organise things.  I tend to get annoyed
when a library has several use/requires to make use of 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: I cannot scroll up down REPL in konsole

[Antonio Recio]

I am using a vim script called 
Vicleto send lines to 
screen repl. This is the reason why I use screen.

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

[Conrad Taylor]

On Jul 6, 7:33 pm, Benny Tsai  wrote:
> Could you please post the entire form, including the code surrounding the
> cond form (since total, amount, and country need to be defined somewhere)?

Benny, that was just sample code to zero in on the initial issue.  I'm
working
through the SICP with a lot of pain but here's what I have so far:

(def us-coins (list 50 25 10 5 1))
(def uk-coins (list 100 50 20 10 5 2 1 0.5))

(defn first-denomination [ coin-values ] (first coin-values))

(defn except-first-denomination [ coin-values ] (rest coin-values))

(defn no-more? [coin-values] (nil? coin-values))

(defn cc [amount coin-values]
(cond
(= amount 0) 1
(or (< amount 0) (no-more? coin-values)) 0
   :else (+ (cc amount (except-first-denomination coin-values))
(cc (- amount (first-denomination coin-
values)) coin-values


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

[Tim Robinson]

You have some rogue text cluttering your cond statement.
Remove the question mark... or whatever this is...



and you'll be fine.

On Jul 6, 8:58 pm, Conrad Taylor  wrote:
> On Jul 6, 7:33 pm, Benny Tsai  wrote:
>
> > Could you please post the entire form, including the code surrounding the
> > cond form (since total, amount, and country need to be defined somewhere)?
>
> Benny, that was just sample code to zero in on the initial issue.  I'm
> working
> through the SICP with a lot of pain but here's what I have so far:
>
> (def us-coins (list 50 25 10 5 1))
> (def uk-coins (list 100 50 20 10 5 2 1 0.5))
>
> (defn first-denomination [ coin-values ] (first coin-values))
>
> (defn except-first-denomination [ coin-values ] (rest coin-values))
>
> (defn no-more? [coin-values] (nil? coin-values))
>
> (defn cc [amount coin-values]
>         (cond
>                 (= amount 0) 1
>                 (or (< amount 0) (no-more? coin-values)) 0
>              :else (+ (cc amount (except-first-denomination coin-values))
>                             (cc (- amount (first-denomination coin-
> values)) coin-values

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

[Ken Wesson]

On Wed, Jul 6, 2011 at 11:06 PM, Tim Robinson  wrote:
> You have some rogue text cluttering your cond statement.
> Remove the question mark... or whatever this is...
>
> 
>
> and you'll be fine.

Whatever WHAT is? There's nothing in your post there but three blank lines.

-- 
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: Correct way to define the else clause of a cond form?

[David Sletten]

On Jul 6, 2011, at 10:58 PM, Conrad Taylor wrote:

> On Jul 6, 7:33 pm, Benny Tsai  wrote:
>> Could you please post the entire form, including the code surrounding the
>> cond form (since total, amount, and country need to be defined somewhere)?
> 
> Benny, that was just sample code to zero in on the initial issue.  I'm
> working
> through the SICP with a lot of pain but here's what I have so far:
> 
> (def us-coins (list 50 25 10 5 1))
> (def uk-coins (list 100 50 20 10 5 2 1 0.5))
> 
> (defn first-denomination [ coin-values ] (first coin-values))
> 
> (defn except-first-denomination [ coin-values ] (rest coin-values))
> 
> (defn no-more? [coin-values] (nil? coin-values))
> 
> (defn cc [amount coin-values]
>   (cond
>   (= amount 0) 1
>(or (< amount 0) (no-more? coin-values)) 0
>  :else (+ (cc amount (except-first-denomination coin-values))
>   (cc (- amount (first-denomination coin-
> values)) coin-values
> 

Part of the problem is that Clojure uses a slightly different syntax for 'cond' 
than Scheme (and Common Lisp) do. In particular, Common Lisp more frequently 
allows for side effects, so rather than a single consequent value Common Lisp's 
COND encloses its consequent expressions in a an additional layer of 
parentheses. Clojure discourages side effects, so it's reasonable to think in 
terms of a single expression as a consequent. The need for enclosing 
parentheses disappears.

Beware that the predicate 'nil?' tests whether an object is 'nil'. You probably 
want to use the predicate 'empty?' to test whether your coin list is empty.


Have all good days,
David Sletten




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

[Tim Robinson]

Lol. not sure what to tell you... on Mac OSX Firefox I see what looks
like this

--
- OBJ -
--

in the middle line, but really really really small.

and when I copy his text and paste at the repl, I get his same error.
When I remove it its not a problem.


On Jul 6, 9:07 pm, Ken Wesson  wrote:
> On Wed, Jul 6, 2011 at 11:06 PM, Tim Robinson  wrote:
> > You have some rogue text cluttering your cond statement.
> > Remove the question mark... or whatever this is...
>
> > 
>
> > and you'll be fine.
>
> Whatever WHAT is? There's nothing in your post there but three blank lines.
>
> --
> 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: Correct way to define the else clause of a cond form?

[Benny Tsai]

On Wednesday, July 6, 2011 9:06:30 PM UTC-6, Tim Robinson wrote:
>
> You have some rogue text cluttering your cond statement. 
> Remove the question mark... or whatever this is... 
>
>  
>
> and you'll be fine. 
>
 
That's what I encountered too.

Conrad, when I pasted your code into emacs, there was a mystery character 
between the 0 at the end of the second condition and the :else at the start 
of the default condition.  Once I removed that character (and fixed a 
spurious newline in the last line), the code evaluated with no problems.

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

[Conrad Taylor]

On Jul 6, 8:08 pm, David Sletten  wrote:
> On Jul 6, 2011, at 10:58 PM, Conrad Taylor wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 6, 7:33 pm, Benny Tsai  wrote:
> >> Could you please post the entire form, including the code surrounding the
> >> cond form (since total, amount, and country need to be defined somewhere)?
>
> > Benny, that was just sample code to zero in on the initial issue.  I'm
> > working
> > through the SICP with a lot of pain but here's what I have so far:
>
> > (def us-coins (list 50 25 10 5 1))
> > (def uk-coins (list 100 50 20 10 5 2 1 0.5))
>
> > (defn first-denomination [ coin-values ] (first coin-values))
>
> > (defn except-first-denomination [ coin-values ] (rest coin-values))
>
> > (defn no-more? [coin-values] (nil? coin-values))
>
> > (defn cc [amount coin-values]
> >    (cond
> >            (= amount 0) 1
> >                (or (< amount 0) (no-more? coin-values)) 0
> >                 :else (+ (cc amount (except-first-denomination 
> > coin-values))
> >                                (cc (- amount (first-denomination coin-
> > values)) coin-values
>
> Part of the problem is that Clojure uses a slightly different syntax for 
> 'cond' than Scheme (and Common Lisp) do. In particular, Common Lisp more 
> frequently allows for side effects, so rather than a single consequent value 
> Common Lisp's COND encloses its consequent expressions in a an additional 
> layer of parentheses. Clojure discourages side effects, so it's reasonable to 
> think in terms of a single expression as a consequent. The need for enclosing 
> parentheses disappears.
>
> Beware that the predicate 'nil?' tests whether an object is 'nil'. You 
> probably want to use the predicate 'empty?' to test whether your coin list is 
> empty.
>
> Have all good days,
> David Sletten

David, thanks for the advice here and things appear to be working now.
It's not optimized but it's functional.  Anyway, I don't if the tabs
caused issues for Clojure but
I know I had issue with other languages.

Thanks all,

-Conrad

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

[Perry Trolard]

Antonio,

Apologies if this is obvious to you, but screen eats your scrollback
lines. You can't use the terminal program's scroll bars; you've got to
enter screen's copy mode to view history. It's a little jarring at
first, but with the vim-style navigation keys & the ease of copying it
allows, copy mode's actually pretty handy.

Perry

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

[Brent Millare]

How's the progress on this project going? During my spare time I've
been reading through some of the logic programming literature, trying
to learn about this, but there is still much to learn. While I could
spend hours continuing to read the literature, I feel it might be more
productive to get dirty instead and learn as I go. What area needs the
most help at the moment? And what would be the best reference for
tackling that sector?

Best,
Brent

On May 14, 5:20 am, "Heinz N. Gies"  wrote:
> On May 13, 2011, at 14:37 , David Nolen wrote:
>
> > On Fri, May 13, 2011 at 2:04 AM, Heinz N. Gies  wrote:
> > Hearing Pattern Matching,
> > do you mean Erlang like Pattern matching?
>
> > Regards,
> > Heinz
>
> > Erlang, OCaml, SML, Haskell, Scala all have the kind of pattern matching 
> > I'm talking about. One important point is that they all support guards on 
> > patterns. It's not clear to me that current implementation actually use 
> > guards to shape the tree, but that is my plan. In the system I'm proposing 
> > guards are actually logical predicates that can be reasoned about.
>
> > (match n
> >    ([x] :guard [(number? x)]
> >     ...)
> >    ([0] ...))
>
> > This is not ok in OCaml, SML, or Haskell (or Scala and Erlang as far as I 
> > know). This would be ok in the system I'm proposing since number? is a 
> > logical predicate and we can test for such cases and reorder the pattern.
>
> Erlang not only allows predicate functions, simple math is also just fine like
>
> f(x) when x < 0 ->
> ...
>
> then again erlangs reasoning for only allowing certain BIF's and simple 
> arithmetics in guards is speed, those are writtin in plain C so are blazing 
> fast compared to erlang functions ^^. That is a issue Clojure does not have 
> to face so I don't think it would make sense to limit the code you can put in 
> guard expressions.
>
> Regards,
> Heinz
>
>  smime.p7s
> 2KViewDownload

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Please stand firm against Steve Yegge's "yes language" push

[Sean Corfield]

On Wed, Jul 6, 2011 at 7:21 PM, Ken Wesson  wrote:
> Does the term "tl;dr" mean anything to you?

I'll remember this date - I find myself really liking / agreeing with
one of Ken's posts :)

Sorry nchubrich but that really was far too long - I started reading
but couldn't find any meat in the first few paragraphs and just tuned
out... I may try again later but if you can _summarize_ more ppl  will
read what you're trying to say.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: I cannot scroll up down REPL in konsole

[Antonio Recio]

@Perry: You are right, when screen is in copy mode (Ctrl + a + [) the 
scrollback works. Solved. Thanks.

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

Re: Please stand firm against Steve Yegge's "yes language" push

[nchubrich]

I'll try :)  It was really a polemical post for a polemical thread,
but my main points can be extracted here.  Feel free to read as many
or as few of them as you are inclined:

* Clojure still ends up turning off new users more than it needs to.
This may be partly an issue of priorities (see the Getting Started
section on clojure.org).  Many good efforts are going into libraries,
but this doesn't necessarily lead to a smoothe starting path.  That
would require choices from the top.

* It also can do a better job of attracting and retaining core
contributors.  I cited an example of someone who posted a patch to
make refs persistent.  She ended up being ignored, and left for
Erlang.  But Clojure needs people like her.

* Putting up barriers to entry is \not a good thing.  The benefits of
getting new users outweigh the drawbacks, because they will bring more
functionality and maturity with them.  It only takes a small effort to
filter out 'noise' in the group (even mine!).

* Since Lisp is highly extensible, in the long run being
'prescriptive' is a losing battle.  It is better to eventually add
standard 'bad' features to the language than to tempt third parties to
do it in even worse and incompatible ways.

* Clojure is already enough of a new way of thinking, and it may be
simply too much at once for many people.  If a gentle path gets more
people into the ecosystem, it's worth itonce they are in Clojure
they can be steered towards better, more functional ways of doing
things.  In any case, experienced users are always free to ignore
extra features.

* It's meant to be a pragmatic language.  This means that a prime goal
should be to get people writing useful (web, GUI, shell) code in it
right away.  Having choices is good, but being forced to make all
these choices your first day of writing Clojure, when you don't have a
"sixth sense" about the community and What Really Works, is needlessly
discouraging.

* The attitude that Smart People are precisely the ones who will want
to deal with Clojure's existing drawbacks ends up excluding many great
future Clojurians.  (A lot of smart people are busy.)  The attitude
itself is off-putting and self-defeating.  Moreover, dealing with
these issues takes \everyone's time.

* Final (added) point: while it might have made sense to be
'prescriptive' initially in order to establish the identity, core, and
soul of the language, this has been done sufficiently.  Newcomers are
not going to be confused about what the main points of Clojure are
now.  There is therefore less risk in making it broadly useful to
different paradigms.

If you want to read the arguments behind all that, you can wade into
the postor add your own.

On Jul 6, 9:37 pm, Sean Corfield  wrote:
> On Wed, Jul 6, 2011 at 7:21 PM, Ken Wesson  wrote:
> > Does the term "tl;dr" mean anything to you?
>
> I'll remember this date - I find myself really liking / agreeing with
> one of Ken's posts :)
>
> Sorry nchubrich but that really was far too long - I started reading
> but couldn't find any meat in the first few paragraphs and just tuned
> out... I may try again later but if you can _summarize_ more ppl  will
> read what you're trying to say.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
> Railo Technologies, Inc. --http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Please stand firm against Steve Yegge's "yes language" push

[Sean Corfield]

Much better. Now I can read it and see your points... and respond...

On Wed, Jul 6, 2011 at 10:42 PM, nchubrich  wrote:
> * Clojure still ends up turning off new users more than it needs to.

I think we need to nail the intro / setup experience and I'm nailing
my colors to Leiningen. I think that needs to be adopted as the
default, standard way to get up and running on Clojure and all the
official tutorials need to be updated to reflect that. It's the
biggest, single roadblock IMO and all that nonsense about downloading
ZIP files and running some specific Java command is a huge barrier to
entry. So far everyone I've introduced to Clojure has struggled with
the Java infrastructure stuff but has "got" Leiningen instantly.

> * It also can do a better job of attracting and retaining core
> contributors.  I cited an example of someone who posted a patch to
> make refs persistent.  She ended up being ignored, and left for
> Erlang.  But Clojure needs people like her.

Unfortunate but all open source projects have a bar to entry and lots
of potential contributors get left by the wayside. I think Clojure
actually has a pretty good ecosystem around contribution. Could it be
better? Maybe. Could it maintain the high level of quality and still
be more inclusive? Hard to say...

> * Putting up barriers to entry is \not a good thing.

I think most people agree with that but the disagreement is on whether
Clojure really is putting up such barriers. I think that's debatable.

> * Since Lisp is highly extensible, in the long run being
> 'prescriptive' is a losing battle.

Again, I think this is a debatable point. I don't believe there is any
direct correlation between the prescriptiveness of a language /
framework and its success.

> * Clojure is already enough of a new way of thinking, and it may be
> simply too much at once for many people.

Aye, maybe. I don't think there's a gentle path tho'. FP is something
you just have to "grok". In some ways, if you want a middle ground,
there's Scala - a hybrid OO/FP language. I have to be honest and say
that after attending Scala Days recently at Stanford, I was even more
convinced Clojure was the right choice for World Singles (we tried
Scala first). I don't think that FP being "hard" is an issue tho' - OO
was "hard" for people back in the day.

> * It's meant to be a pragmatic language.

And I think it succeeds admirably here. We have an incredible
diversity of applications. With Heroku supporting Clojure - and some
great step-by-step tutorials for web applications (with databases) - I
don't think anyone can accuse Clojure of not being pragmatic. I'm
using Clojure for DB work, text file analysis, and all sorts of very
pragmatic, real-world stuff. It's a great language for general purpose
stuff.

> * The attitude that Smart People are precisely the ones who will want
> to deal with Clojure's existing drawbacks ends up excluding many great
> future Clojurians.

I flat out don't agree with this on any level. Clojure is pragmatic
and a wide variety of developers from all sorts of backgrounds are
picking it up and building real world stuff with it. It's not just
about "Smart People" nor about any subset of "Smart People".

> * Final (added) point: while it might have made sense to be
> 'prescriptive' initially in order to establish the identity, core, and
> soul of the language, this has been done sufficiently.  Newcomers are
> not going to be confused about what the main points of Clojure are
> now.  There is therefore less risk in making it broadly useful to
> different paradigms.

And I think the new process for moving contrib libraries forward
addresses that. I'm late to the game but folks I trust tell me that
contributing to the new contrib libraries is much easier and much more
open that the process around the old contrib libraries.
clojure.core.unify and clojure.core.logic are testament to serious
innovation within the core Clojure context.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Please stand firm against Steve Yegge's "yes language" push

[faenvie]

@nchubrich

> It did go on too long.  I hope when someone \does read it, they will
> see I am not being wholly unreasonable.

i liked to read through it anyway ...

>>I was drawn to Clojure because I felt it was another
>>evolutionary step in programming.  I hope I am not wrong.

i feel and hope that too.

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

[Tassilo Horn]

Ken Wesson  writes:

Hi!

>> Remove the question mark... or whatever this is...
>>
>> 
>>
>> and you'll be fine.
>
> Whatever WHAT is? There's nothing in your post there but three blank
> lines.

Sure there is! ;-)

,
| character:  (65532, #o14, #xfffc)
| preferred charset: unicode (Unicode (ISO10646))
|code point: 0xFFFC
|syntax: w  which means: word
|  category: .:Base
|   buffer code: #xEF #xBF #xBC
| file code: #xEF #xBF #xBC (encoded by coding system utf-8-emacs)
|   display: by this font (glyph code)
| xft:-unknown-GFS Bodoni Rg-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1 
(#x226)
| 
| Character code properties: customize what to show
|   name: OBJECT REPLACEMENT CHARACTER
|   general-category: So (Symbol, Other)
`

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