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

2011-07-05 Thread Tassilo Horn
Ken Wesson  writes:

Hi Ken,

> A related case may be when you're not making just a straight wrapper,
> but adding something -- your own pre/post checks, or argument
> transformations, or etc.
>
> As for binding to a Var, that makes sense if the result is not as
> trivial as #(.meth %) and is going to be used many times. Otherwise
> #(.meth %) is not much longer than a reasonably clear Var name for it
> and is crystal clear as to what it does, so I'd just use that.

Another consideration I take into account is if a functionality is
exposed to users.

For example, I have a clojure graph querying and transformation library
that is built upon our java graph library.  The functionality is
hopefully implemented in idiomatic clojure, like iterating nodes and
edges using lazy seqs.  However, there are two or three functions that
basically wrap only java methods.  I decided to put them in although
it's idiomatic clojure to call java, because then the user gets a
complete, consistent clojure API and doesn't have to know anything about
the java side.

For example, you can write

--8<---cut here---start->8---
(reduce + (map #(value %1 :inhabitants)
   (vseq (rg) 'localities.Locality)))
--8<---cut here---end--->8---

instead of the slightly alien

--8<---cut here---start->8---
(reduce + (map #(.getAttribute %1 "inhabitants")
   (vseq (rg) 'localities.Locality)))
--8<---cut here---end--->8---

That's a bit shorter (and allows for giving the attribute name as
keyword, symbol, or string), and most importantly it is documented.  If
that wrapper wasn't there, users that just want to use the clojure
library have to study the javadocs, too.

Bye,
Tassilo

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


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

2011-07-05 Thread Ken Wesson
So, another justification for wrapping a Java method is when it's a
layer boundary and the Java method is two (or more) layers lower than
the caller, basically.

This suggests a generalization as well: that there's a form of "Law of
Demeter" applied to layers (and libraries) where one should tend to
talk directly to the levels adjacent but not to a level two steps
down, for instance. The layer two steps down is an implementation
detail of the layer one step down and therefore shouldn't be exposed
to that layer's clients, including your current layer. This would be
more broadly applicable than just when the layer boundary is a
client/library boundary -- then again, maybe in a sense it's the
reverse, and all layer boundaries can be thought of as client/library
boundaries, i.e. every layer of an application but the top should
basically be a library (or set of libraries) that is (or are) used to
implement the next layer up.

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

2011-07-05 Thread faenvie
>>Of the people I've tried to expose to Clojure over the last six months,
>>I've definitely found that those with less OO experience tend to pick
>>it up much quicker.

that's exactly true for me: 40+ years old and OO-centric-Programmer
since 1995.
it takes me one year now to reach a highlevel quality in programming
clojure. i maybe
near but still have the feeling that i am not there ...

the IMO main-reasons for this are:

- i am so deeply entrenched in OO-thinking

- no chance to apply clojure in the job so it's kind of a hobby

- 40+ years -> brain is full of stuff -> more difficult to learn

IMO one thing that could help OO-people a lot would be  a
detailed guide for implementing classical design-patterns using
clojure (see: head first desing patterns which is a fantastic book) .
'the joy of clojure' touches this subject but not in detail.

Btw. it's not true IMO, that clojure eleminates the benefit of
thinking in design-patterns.

and finally to correct myself: clojure IS a general purpose language.
no doubt about it. -> high-level skills in clojure enable programmers
to
do both: system-programming and application-programming.

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

2011-07-05 Thread Kevin Sookocheff
You can always try http://projecteuler.net using Clojure.

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

Re: Clojure for large programs

2011-07-05 Thread Stuart Halloway
> On Jul 3, 2011, at 3:13 AM, Sean Corfield wrote:
>> Since I mostly work with 50-100kloc projects, I think 5-10kloc
>> projects are kinda small :)
> 
> 
> My point was that I'm running into interesting questions even with a small 
> program. The answers are not obvious to me. There's evidence I'm not alone, 
> so those to whom the answers *are* obvious would help the community by 
> describing them.
> 
> * An example: organizing code into namespaces (skippable)
> 
> I was uncertain that Midje's "sweet" (syntactically sugared) interface would 
> catch on, so I organized it by translation layers. I wrote the "unprocessed" 
> layer first; it had functions that worked solely on maps. The "semi-sweet" 
> layer provided macros that introduced some useful conventions but had only 
> one syntactic innovation. It was easy to translate the `expect` and `fake` 
> macros into "unprocessed" function calls on maps. Then I added the "sweet" 
> layer that has a considerably more ambitious set of macros that translate 
> `facts` into `expects` and `fakes`. 
> 
> As time went on, I pulled out utility functions into namespaces like 
> [midje.util thread-safe-var-nesting laziness file-position]. But that 
> organization failed. When I divide things up into files, I want the division 
> such that I usually find things in the first place I look. That wasn't 
> happening.
> 
> So I started migrating to an organization based on verbs (this is a 
> functional language, right?). So I have namespaces like [midje.midje-forms 
> recognizing translating building]. Two problems: 1) New features require 
> recognizing, translating, and building, so all the hopping around files was 
> annoying. 2) The functions didn't fall into such clear-cut categories that I 
> could reliably find things in the first place I look. (Unsurprising, since 
> clear-cut categories are rare in nature: 
> http://www.exampler.com/testing-com/writings/pnsqc-2005-communication.pdf)
> 
> Now I'm moving toward an organization around nouns, which feels a bit too OO 
> to me, but at least I'm far enough in the project that the key concepts/nouns 
> are likely to stay stable.
> 
> This progression feels a lot more wasteful than it would have been in Java 
> (which has IDE support) or Ruby (which lets you mention a file once and have 
> it be available throughout the program). So I'd have preferred to get it 
> (more) right in the first place.
> 
> * What would help
> 
> It'd be useful for people happy with their multi-namespace codebases to 
> volunteer them as exemplars. What's grouped together and why? What are the 
> dependencies? How'd you arrive at this structure?  A really interesting thing 
> to do would be to implement a feature and narrate how you decide where to put 
> things, where existing things must be, and so forth. [I spend a fair amount 
> of time parachuting into projects and learning the code structure by pairing. 
> Works pretty nicely.]

On large projects I do the following:

(1) Use "require :as prefix" everywhere. This felt ugly at first, but puts 
pressure on naming in way that is beneficial as the codebase grows.

(2) Think of the consumer of the lib, not the author. As a user of Midje, I 
would want all the utility fns in a single namespace (if they were separated 
from the domain API at all).

In general, I have found that namespaces should be larger than my OO intuition 
would have them be.

Stu


Stuart Halloway
Clojure/core
http://clojure.com

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

Re: Clojure for large programs

2011-07-05 Thread Laurent PETIT
2011/7/5 Stuart Halloway :
> On large projects I do the following:
> (2) Think of the consumer of the lib, not the author. As a user of Midje, I
> would want all the utility fns in a single namespace (if they were separated
> from the domain API at all).
> In general, I have found that namespaces should be larger than my OO
> intuition would have them be.
> Stu

Yes, and this is IMHO driven by the fact that there is less
dependencies between two functions in a namespace than two methods in
a class (which may share state via the instance).

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


Re: Build tool for mixed Clojure/Java projects

2011-07-05 Thread Michael Wood
On 5 July 2011 06:34, Sean Corfield  wrote:
> On Mon, Jul 4, 2011 at 7:43 PM, Ken Wesson  wrote:
>> I was using it in the sense typically meant in phrases like "source
>> code repository", as seems reasonable given the context, but oh well.
>
> If you're using git, "source code repository" could easily be local
> and not require an Internet connection... so I think it depends on
> your experience :)

The same goes for CVS or Subversion or Mercurial and probably various
other "source code repositories".  If you want to network them you
can, but you have to do something extra (e.g. run cvs-pserver or
mod_dav_svn or svnserve or hg serve etc.)

Things like Debian package archives are the same.  They have a
particular structure and set of metadata and they may or may not be
available over the network (via FTP or HTTP).  If you have one locally
(e.g. on CD) you can use it without setting up an FTP server or web
server, but of course then nobody else can use it from their machine.

> In the OP comment, I certainly took repository to just mean "somewhere
> you store stuff" and hence it could easily be local...

I take it to me "somewhere you can store stuff in a particular
structure perhaps with metadata" so that maven knows what's there and
how to set up class paths and whatever else it needs to do with it.

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

2011-07-05 Thread Stephen C. Gilardi

On Jul 4, 2011, at 7:52 AM, Michael Wood wrote:

> "Repository" need not imply anything to do with networking.  I'm sure
> someone will correct me if I'm wrong, but I am pretty sure that the
> repository Steve [Lindsay] is talking about above is just a hierarchy of files
> in your home directory.

Right, there's a per-user repository at ~/.m2/repository .

Without any change to lein, its "install" subcommand will place a jar for the 
current project within ~/.m2/repository . The jar can be used from there in 
other local projects. Here's an example:

  % cd 
  % lein install
  [...]
  [INFO] Installing ./projectA-1.0.0-SNAPSHOT.jar to 
~/.m2/repository/projectA/projectA/1.0.0-SNAPSHOT/projectA-1.0.0-SNAPSHOT.jar
  % cd 
  % lein install
  [...]
  [INFO] Installing ./projectB-1.0.0-SNAPSHOT.jar to 
~/.m2/repository/projectB/projectB/1.0.0-SNAPSHOT/projectB-1.0.0-SNAPSHOT.jar
  % cd 
  % cat project.clj
  defproject projectC "1.0.0-SNAPSHOT"
:description "FIXME: write description"
:dependencies [[org.clojure/clojure "1.2.1"]
   [projectA "1.0.0-SNAPSHOT"]
   [projectB "1.0.0-SNAPSHOT"]])
  % lein deps
  Copying 3 files to /lib
  % ls lib   
  clojure-1.2.1.jar   projectB-1.0.0-SNAPSHOT.jar
  projectA-1.0.0-SNAPSHOT.jar

This appears to meet Konrad's original specs except (depending on the intended 
meaning of "repository") for:

> 4) Must handle dependencies in the form of on-disk jar files (not in any 
> repository)

I would argue that the ~/.m2 repository is nearly as easy to work with as any 
other local, on-disk scheme one might envision and has the benefit of working 
with any maven-compatible tool.

It also works for arbitrary jars one may have on disk (acquired from any 
source) via:

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

--Steve

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


Re: Build tool for mixed Clojure/Java projects

2011-07-05 Thread faenvie
hi meikel,

you plugin really rocks.

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 ?

maybe after gradle has released it's 1.0 version ?

best regards ..

> I'm open for any support request to get you going with clojuresque.
> Mail me or put the discussions on the newly created google
> group:http://groups.google.com/group/clojuresque.

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

2011-07-05 Thread Patrick Houk
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 (see the CONSTANT_Utf8_info struct in
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html).
I've encountered that limit when using Eclipse/CounterClockwise.  The
problem occurs when evaluating a file by doing something like:

(clojure.lang.Compiler/load (java.io.StringReader. "the-whole-file-as-
a-string"))

So the contents of the file ends up as a String literal, and Clojure
will generate a corrupt class if that String is too long.
CounterClockwise calls a function in nREPL (helpers/load-file-command)
that does this.  Perhaps Emacs/Slime is doing something similar.

I hope that helps.
- Pat

On Jul 4, 3:11 am, Peter T  wrote:
> Hi all,
>
> Since I started using Clojure (I think from just before 1.0) I have,
> on the odd occasion, received an error message of this form (Unknown
> constant tag X in class file error) while trying to evaluate a
> namespace in Slime/Emacs.
>
> Whenever it cropped up, it was completely random: it never seemed to
> have any specific relation to something I'd done in the code.
> Sometimes it'd get triggered by an arbitrary change like renaming a
> variable or deleting a comment or unused function.
>
> In all cases, recompiling the project from scratch would get past the
> issue.
>
> I'd always figured it was some random quirk of the compiler. Since it
> didn't happen often and could be fixed by a recompile, I just let it
> be.
>
> Today though, I've started running into this error more persistently.
> It'll start appearing consistently -right- after a recompile.
>
> I.e.: I'll compile the project, then try re-evaluate a namespace that
> was just compiled (no changes to the code) and it'll throw the error.
>
> There hasn't been any change to the code in this file and the other
> recent changes are all superficial and syntactically correct (proved
> also by the fact that the source is compiling successfully).
>
> I'm using Clojure 1.2.0.
>
> The best info I could find on this error is here, from 
> 2009:http://www.mail-archive.com/clojure@googlegroups.com/msg19130.html.
>
> I don't have any familiarity with Clojure's compiler (or Java or the
> JVM) so am a little clueless as to where I'd begin trying to get past
> the problem. Any rough idea what might be going on? Am I possibly
> bumping into a Clojure/Java/JVM limitation somewhere? Could this be a
> Slime/Swank issue? The project's about 21,000 LOC right now, including
> lots of comments. This is split into about 40 namespaces/files.
>
> Kind of in the middle of a product launch right now, so the timing's a
> little bit unfortunate: would really appreciate any advice! Thank you!
>
> The full stack trace is below:
>
> Unknown constant tag 32 in class file wusoup/web/responses/profiles
> $eval7347
>   [Thrown class java.lang.ClassFormatError]
>
> Restarts:
>  0: [QUIT] Quit to the SLIME top level
>
> Backtrace:
>   0: java.lang.ClassLoader.defineClass1(Native Method)
>   1: java.lang.ClassLoader.defineClass(ClassLoader.java:634)
>   2: java.lang.ClassLoader.defineClass(ClassLoader.java:480)
>   3:
> clojure.lang.DynamicClassLoader.defineClass(DynamicClassLoader.java:
> 45)
>   4: clojure.lang.Compiler$ObjExpr.getCompiledClass(Compiler.java:
> 3964)
>   5: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3219)
>   6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>   7: clojure.lang.Compiler.analyze(Compiler.java:5190)
>   8: clojure.lang.Compiler.eval(Compiler.java:5421)
>   9: clojure.lang.Compiler.eval(Compiler.java:5391)
>  10: clojure.core$eval.invoke(core.clj:2382)
>  11: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>  12: swank.core$eval_for_emacs.invoke(core.clj:241)
>  13: clojure.lang.Var.invoke(Var.java:373)
>  14: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  15: clojure.lang.Var.applyTo(Var.java:482)
>  16: clojure.core$apply.invoke(core.clj:540)
>  17: swank.core$eval_from_control.invoke(core.clj:101)
>  18: swank.core$spawn_worker_thread$fn__465$fn__466.invoke(core.clj:
> 300)
>  19: clojure.lang.AFn.applyToHelper(AFn.java:159)
>  20: clojure.lang.AFn.applyTo(AFn.java:151)
>  21: clojure.core$apply.invoke(core.clj:540)
>  22: swank.core$spawn_worker_thread$fn__465.doInvoke(core.clj:296)
>  23: clojure.lang.RestFn.invoke(RestFn.java:398)
>  24: clojure.lang.AFn.run(AFn.java:24)
>  25: java.lang.Thread.run(Thread.java:636)

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

2011-07-05 Thread Ken Wesson
On Tue, Jul 5, 2011 at 11:22 AM, Patrick Houk  wrote:
> 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 (see the CONSTANT_Utf8_info struct in
> http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html).
> I've encountered that limit when using Eclipse/CounterClockwise.  The
> problem occurs when evaluating a file by doing something like:
>
> (clojure.lang.Compiler/load (java.io.StringReader. "the-whole-file-as-
> a-string"))
>
> So the contents of the file ends up as a String literal, and Clojure
> will generate a corrupt class if that String is too long.
> CounterClockwise calls a function in nREPL (helpers/load-file-command)
> that does this.  Perhaps Emacs/Slime is doing something similar.

Smells like multiple bugs to me.

1. A too-large string literal should have a specific error message,
rather than generate a misleading one suggesting a different type of
problem.

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.

3. Though both of the above bugs are in Oracle's Java implementation,
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*. 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, 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, 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).

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

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


Re: Build tool for mixed Clojure/Java projects

2011-07-05 Thread Ken Wesson
On Tue, Jul 5, 2011 at 9:21 AM, Michael Wood  wrote:
> On 5 July 2011 06:34, Sean Corfield  wrote:
>> On Mon, Jul 4, 2011 at 7:43 PM, Ken Wesson  wrote:
>>> I was using it in the sense typically meant in phrases like "source
>>> code repository", as seems reasonable given the context, but oh well.
>>
>> If you're using git, "source code repository" could easily be local
>> and not require an Internet connection... so I think it depends on
>> your experience :)
>
> The same goes for CVS or Subversion or Mercurial and probably various
> other "source code repositories".  If you want to network them you
> can, but you have to do something extra (e.g. run cvs-pserver or
> mod_dav_svn or svnserve or hg serve etc.)

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

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

2011-07-05 Thread Ken Wesson
On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
 wrote:
> In general, I have found that namespaces should be larger than my OO
> intuition would have them be.

One problem with scaling up namespaces, though, is that ongoing
"invalid constant tag 32" issue with big enough input files (see other
thread). For now, until it's fixed, there's an effective size cap on
namespaces that is hit at around 1kloc (typically no more than a few
hundred functions).

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

2011-07-05 Thread Sean Corfield
On Tue, Jul 5, 2011 at 6:01 AM, Stuart Halloway
 wrote:
> (1) Use "require :as prefix" everywhere. This felt ugly at first, but puts
> pressure on naming in way that is beneficial as the codebase grows.

I've also started leaning toward that approach. At first I tended to
:use clojure.* namespaces and :require our own code with aliases but
now I'm moving more to :require on all namespaces, often without an
alias (on short ns names) and then using the long form in calls. In
other words, only using an alias if it really cleans up the code (one
tooling deficiency I noticed is that CCW won't recognize clojure.*
namespace functions if you use an alias and I find the color-coding is
worth more than the conciseness of the code).

> In general, I have found that namespaces should be larger than my OO
> intuition would have them be.

I'm beginning to find that. At first I was creating namespaces much as
I would have for classes but that soon produced long (ns) forms
requiring all the small namespaces so I backed off to less granular
namespaces and I'm finding that easier to manage.

I just saw Ken's note come in about "invalid contant tag 32" and
looking at the threads behind that, it looks like folks hit it when
they have "large" files but I'd be concerned about any single
namespace-based-API that grew that large - I would have expected to
break it down into a "public" API and a "private" implementation
namespace before files got that large. I guess it will be interesting
to see how this pans out as Clojure adoption continues to grow...
maybe that limitation should be endorsed and the compiler could issue
an "Error: your namespace is too big - please modularize your code!"
message as a way to keep namespaces to a maintainable length... :)
-- 
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


Data filtering function

2011-07-05 Thread Bhinderwala, Shoeb
I need help to write a small filtering function. Given the following
definitions:

(def m1 
   {["45"] {:a 45 :b "day1"}
["55"] {:a 55 :b "day1"}
["25"] {:a 25 :b "day1"}
["15"] {:a 15 :b "day1"}
["10"] {:a 10 :b "day1"}})

(def m2 
   {["45"] {:a 45 :b "day2"}
["55"] {:a 55 :b "day2"}
["25"] {:a 25 :b "day2"}
["15"] {:a 15 :b "day2"}
["10"] {:a 10 :b "day2"}})

(def m3 
   {["45"] {:a 45 :b "day3"}
["55"] {:a 55 :b "day3"}
["25"] {:a 25 :b "day3"}
["15"] {:a 15 :b "day3"}
["10"] {:a 10 :b "day3"}})

(def d (list m1 m2 m3))

I need to write a function that returns the filtered results as follows:

(my-filter d ["45"])
=> ({:a 45 :b "day1"} {:a 45 :b "day2"} {:a 45 :b "day3"})

Thanks for your help.

-- Shoeb

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

Clojure now officially supported on Heroku

2011-07-05 Thread Mark McGranaghan
I'm very excited to say that Clojure is now an officially supported
deployment option on Heroku:

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: Clojure Koans and others interactive exercises to learn clojure?

2011-07-05 Thread Jonathan Cardoso
Thanks for sharing this!! I didn't know that there was a Koans version
for Clojure =D

On 4 jul, 00:52, Antonio Recio  wrote:
> Clojure koans  is awesome
> to learn clojure. Do you know other projects with exercises to learn
> clojure?

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


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

2011-07-05 Thread Sean Corfield
On Tue, Jul 5, 2011 at 4:54 AM, faenvie  wrote:
> that's exactly true for me: 40+ years old and OO-centric-Programmer
> since 1995.
> it takes me one year now to reach a highlevel quality in programming
> clojure.

I sympathize! I turn 49 this week (Thursday) and have been doing OO
since '92. Fortunately I did quite a bit of FP before that so I think
I can still be "saved" :)

> IMO one thing that could help OO-people a lot would be  a
> detailed guide for implementing classical design-patterns using
> clojure (see: head first desing patterns which is a fantastic book) .

That's an interesting point. Since the Gang of Four book is subtitled
"Elements of Reusabled _Object-Oriented_ Software", I wonder whether
it's really the right starting point tho'? Several of those patterns
exist to address problems people run into with OO, much like the Core
J2EE Patterns book contains patterns that exist solely to workaround
problems / deficiencies with J2EE constructs (such as EJBs).

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?

For example, Command would probably just be a function or closure, as
would Strategy I suspect? Template Method might be a multi-method or
protocol / extend-type combo, as might Decorator? Facade would be a
new API implemented in a namespace that uses / requires the various
namespaces to which it is a facade? Proxy is relatively
straightforward in the absence of a static type system. Flyweight is
probably not applicable. Singleton could be delay / deref? Iterator is
not needed in Clojure due to the seq abstraction. Just throwing some
ideas out there - I haven't given any of that much thought...
-- 
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: Data filtering function

2011-07-05 Thread Sean Devlin
Try merge-with to create a single map.

On Jul 5, 1:49 pm, "Bhinderwala, Shoeb" 
wrote:
> I need help to write a small filtering function. Given the following
> definitions:
>
> (def m1
>        {["45"] {:a 45 :b "day1"}
>         ["55"] {:a 55 :b "day1"}
>         ["25"] {:a 25 :b "day1"}
>         ["15"] {:a 15 :b "day1"}
>         ["10"] {:a 10 :b "day1"}})
>
> (def m2
>        {["45"] {:a 45 :b "day2"}
>         ["55"] {:a 55 :b "day2"}
>         ["25"] {:a 25 :b "day2"}
>         ["15"] {:a 15 :b "day2"}
>         ["10"] {:a 10 :b "day2"}})
>
> (def m3
>        {["45"] {:a 45 :b "day3"}
>         ["55"] {:a 55 :b "day3"}
>         ["25"] {:a 25 :b "day3"}
>         ["15"] {:a 15 :b "day3"}
>         ["10"] {:a 10 :b "day3"}})
>
> (def d (list m1 m2 m3))
>
> I need to write a function that returns the filtered results as follows:
>
> (my-filter d ["45"])
> => ({:a 45 :b "day1"} {:a 45 :b "day2"} {:a 45 :b "day3"})
>
> Thanks for your help.
>
> -- Shoeb

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


Re: Build tool for mixed Clojure/Java projects

2011-07-05 Thread Laurent PETIT
Yes, I've found Eclipse's maven support rather stable for the last 6
months, so I consider it stable and use it for my projects.
The plugin is called m2eclipse.


2011/7/5 Steve :
> On Jul 5, 7:13 am, Ken Wesson  wrote:
>>
>> > No, there's no server, no port, nothing to firewall. It's just a
>> > directory (~/.m2/repository).
>>
>> So, not actually a repository, then. :)
>>
>
> Well not as you're defining it :) But yes it is a repository if
> repository means "place to store stuff". In particular, "place to
> store jars for one project that can be effortlessly depended upon by
> another project".
>
>>
>> One problem with that is that you generally can't *not* use your IDE's
>> built in project management unless you don't use an IDE at all (vi,
>> emacs, Notepad, whatever rather than Eclipse, IDEA, Netbeans,
>> whatever).
>>
>
> No that's not right, Netbeans (and I'm sure Eclipse, no idea about
> IDEA) happily creates and works with Maven projects. We have guys
> working here using a range of different tools (mostly Java projects
> using Netbeans and Eclipse, running on Linux and Windows) and because
> we've standardised on Maven we have very few issues sharing projects.
>
> - Steve
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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


Re: Clojure now officially supported on Heroku

2011-07-05 Thread Jonathan Cardoso
Amazing news!!
Heroku is great and simple!

On 5 jul, 14:54, Mark McGranaghan  wrote:
> I'm very excited to say that Clojure is now an officially supported
> deployment option on Heroku:
>
>    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: Data filtering function

2011-07-05 Thread Benny Tsai
This should work:

(defn my-filter [coll k]
  (for [m coll]
(get m k)))

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

2011-07-05 Thread Sean Corfield
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 Scala 
>> http://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
>> are http://erlang.org/pipermail/erlang-questions/2011-May/058769.html
>> and also http://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 :)

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 - see
http://erlang.org/pipermail/erlang-questions/2011-May/058773.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...

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

2011-07-05 Thread Laurent PETIT
Ken, I'm sorry I didn't answer quickly to you on the CCW mailing list.

Unless there's a bug involved (and I suspect there's a rampant one
somewhere :) ), CCW handles AOT compilation.

Would it not handle it, I would not be able to release CCW itself !

Indeed, currently there are cyclic dependencies between java and
clojure code in CCW, and this is handled by Eclipse's Compiler only :
Eclipse compiles java files to (incompletely working) class files.
The CCW builder builds the missing AOT class files (thanks to
Eclipse's compiler having put the necessary signatures in place in the
java class files, even if the implementations are not complete yet).
After the CCW build, Eclipse refreshes the project and does a second
compile pass on its java files, ending the roundtrip with everything
being OK.

Sooo... how does CCW handle AOT compilation ?
Here's the current state of the art. It's subject to laarge
improvements, but I haven't opened this can of worms yet, I'm working
on other more urgent CCW topics.

So there it is :
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.
Then you should see:
1) A java console view for the underlying process' JVM inputs/outputs
2) A (n)REPL client view speaking with the underlying process' JVM via
either the nrepl dependency already present in your project's
classpath, either added "on the fly" to the classpath by the "Clojure
Application" launch configuration machinery (a clever ccw trick)
3) a "background" user job running (generally on the bottom right)
reporting some kind of progress related to the AOT compilation of the
project.
4) when the background user job has finished, you should see that your
project's "classes/" directory is full of AOT compiled class files.

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

So now that you have the explanations, if this works for you as it
does for me, Eclipse+CCW will handle for you, out of the box:

1) Must handle Clojure namespaces that are AOT-compiled.
3) Must handle Java source code files.
4) Must handle dependencies in the form of on-disk jar files (not in
any repository)
5) No XML configuration files.


(*) : 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". Which implies
that CCW will just pre-load the selected file on the clojure process,
but do none of what it does when run in "project mode" : neither
attempt to AOT compile the whole project when the process starts,
neither attempt to (again) re-AOT compile the whole project everytime
you save a file in the editor.

HTH,

Cheers,

-- 
Laurent

2011/7/3 Konrad Hinsen :
> I am looking for a build tool that fulfills the following requirements:
>
> 1) Must handle Clojure namespaces that are AOT-compiled.
> 2) Must handle Clojure namespaces that are not AOT-compiled.
> 3) Must handle Java source code files.
> 4) Must handle dependencies in the form of on-disk jar files (not in any
> repository)
> 5) No XML configuration files.
>
> Candidates that I have tried and found insufficient include
> - Leiningen (no dependencies without repositories)
> - Cake (doesn't handle Java source files)
> - Eclipse/Counterclockwise (doesn't handle AOT compilation)
> - ant, maven: XML configuration files
> - scons: incomplete Java support, no Clojure support
>
> Is there anything else worth trying?
>
> Thanks in advance,
>  Konrad.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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


Re: Integrating Clojure-CLR w/ VS

2011-07-05 Thread Sean Devlin
That + a reboot was exactly what I needed.  Oh, the joys of windows
system administration!

On Jul 2, 11:03 pm, Jeff Sigmon  wrote:
> Sean,
>
> It looks like your not alone, see 
> thishttps://github.com/jmis/vsClojure/issues/33
>
> I was able to launch an exe outside of VS by adding the following
> environment variable ->
>
> name: clojure.load.path
> value: 
> %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\jmis\vsClojure\1.1.0\Runtimes\1.2.0
>
> Jeff

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

2011-07-05 Thread Kevin Sookocheff
Terrific!  Congratulations to everyone involved.

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

2011-07-05 Thread David Nolen
On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson  wrote:

> On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
>  wrote:
> > In general, I have found that namespaces should be larger than my OO
> > intuition would have them be.
>
> One problem with scaling up namespaces, though, is that ongoing
> "invalid constant tag 32" issue with big enough input files (see other
> thread). For now, until it's fixed, there's an effective size cap on
> namespaces that is hit at around 1kloc (typically no more than a few
> hundred functions).
>

Why doesn't this limitation affect clojure.core, which is 6k+ loc?

David

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

Re: Data filtering function

2011-07-05 Thread Base
(map #(get % ["45"]) d)

On Jul 5, 12:49 pm, "Bhinderwala, Shoeb"
 wrote:
> I need help to write a small filtering function. Given the following
> definitions:
>
> (def m1
>        {["45"] {:a 45 :b "day1"}
>         ["55"] {:a 55 :b "day1"}
>         ["25"] {:a 25 :b "day1"}
>         ["15"] {:a 15 :b "day1"}
>         ["10"] {:a 10 :b "day1"}})
>
> (def m2
>        {["45"] {:a 45 :b "day2"}
>         ["55"] {:a 55 :b "day2"}
>         ["25"] {:a 25 :b "day2"}
>         ["15"] {:a 15 :b "day2"}
>         ["10"] {:a 10 :b "day2"}})
>
> (def m3
>        {["45"] {:a 45 :b "day3"}
>         ["55"] {:a 55 :b "day3"}
>         ["25"] {:a 25 :b "day3"}
>         ["15"] {:a 15 :b "day3"}
>         ["10"] {:a 10 :b "day3"}})
>
> (def d (list m1 m2 m3))
>
> I need to write a function that returns the filtered results as follows:
>
> (my-filter d ["45"])
> => ({:a 45 :b "day1"} {:a 45 :b "day2"} {:a 45 :b "day3"})
>
> Thanks for your help.
>
> -- Shoeb

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

2011-07-05 Thread Bhinderwala, Shoeb
Thanks. That was simple. I got hung up on trying to use the filter function and 
didn't realize it could be done in simpler ways without it.

-Original Message-
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of 
Base
Sent: Tuesday, July 05, 2011 3:37 PM
To: Clojure
Subject: Re: Data filtering function

(map #(get % ["45"]) d)

On Jul 5, 12:49 pm, "Bhinderwala, Shoeb"
 wrote:
> I need help to write a small filtering function. Given the following
> definitions:
>
> (def m1
>        {["45"] {:a 45 :b "day1"}
>         ["55"] {:a 55 :b "day1"}
>         ["25"] {:a 25 :b "day1"}
>         ["15"] {:a 15 :b "day1"}
>         ["10"] {:a 10 :b "day1"}})
>
> (def m2
>        {["45"] {:a 45 :b "day2"}
>         ["55"] {:a 55 :b "day2"}
>         ["25"] {:a 25 :b "day2"}
>         ["15"] {:a 15 :b "day2"}
>         ["10"] {:a 10 :b "day2"}})
>
> (def m3
>        {["45"] {:a 45 :b "day3"}
>         ["55"] {:a 55 :b "day3"}
>         ["25"] {:a 25 :b "day3"}
>         ["15"] {:a 15 :b "day3"}
>         ["10"] {:a 10 :b "day3"}})
>
> (def d (list m1 m2 m3))
>
> I need to write a function that returns the filtered results as follows:
>
> (my-filter d ["45"])
> => ({:a 45 :b "day1"} {:a 45 :b "day2"} {:a 45 :b "day3"})
>
> Thanks for your help.
>
> -- Shoeb

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

2011-07-05 Thread Alessio Stalla
On 5 Lug, 18:49, Ken Wesson  wrote:
> On Tue, Jul 5, 2011 at 11:22 AM, Patrick Houk  wrote:
> > 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 (see the CONSTANT_Utf8_info struct in
> >http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc...).
> > I've encountered that limit when using Eclipse/CounterClockwise.  The
> > problem occurs when evaluating a file by doing something like:
>
> > (clojure.lang.Compiler/load (java.io.StringReader. "the-whole-file-as-
> > a-string"))
>
> > So the contents of the file ends up as a String literal, and Clojure
> > will generate a corrupt class if that String is too long.
> > CounterClockwise calls a function in nREPL (helpers/load-file-command)
> > that does this.  Perhaps Emacs/Slime is doing something similar.
>
> Smells like multiple bugs to me.
>
> 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.
See: . String literals are made of 1-byte tag, 2-
bytes length, and (length * 1-byte) contents. I suppose Clojure's
compiler is generating an incorrect class file because the length is
either overflowing or growing past two bytes.

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

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

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

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

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

> 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 little impractical.

Regarding the size of individual defns, that's an orthogonal problem;
anyway, the size of the _bytecode_ for methods is limited to 64KB (see
) and, while pretty big, it's not impossible
to reach it, especially when using complex macros to produce a lot of
generated code. We used to generate such big methods in ABCL because
at one point we tried to spell out in the bytecode all the class names
corresponding to functions in a compiled file, in order to avoid
reflection when loading the compiled functions. For files with many
functions (> 1000 iirc) the generated code became too big. It turned
out that this optimization had a negligible impact on performance, so
we reverted it.

Cheers,
Alessio

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

2011-07-05 Thread faenvie
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.

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


Thread Macro For Inserting In Arbitrary Positions

2011-07-05 Thread Asim Jalis
Frequently I want to use the thread macros (-> or ->>) except I need
to thread the arguments into positions other than the first and the
last. Or sometimes I have to go back and forth between first and last
positions. Instead of alternating between -> and ->> and creating
nesting, I've been using this thread macro which replaces underscore
with the value of the previous expression.

(defmacro -->
  "Threads the expr through the forms. Replaces all underscores (_)
  with x in the form, making a list of it if it is not a list already.
  If there are more forms, inserts the first form as the last item in
  second form, etc."
  ([x form] (if (seq? form)
  (with-meta `(~(first form) ~@(replace {'_ x} (next
form))) (meta form))
  (list form x)))
  ([x form & more] `(--> (--> ~x ~form) ~@more)))

Is there a reason something like this does not exist in clojure.core?
Is this an oversight or is there a reason this is not there?

Asim

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


Re: Thread Macro For Inserting In Arbitrary Positions

2011-07-05 Thread Asim Jalis
Here is an example of using this:

(--> "hello world" (.toUpperCase _) (.toLowerCase _) (.indexOf _ "w"))

On Tue, Jul 5, 2011 at 3:50 PM, Asim Jalis  wrote:
> Frequently I want to use the thread macros (-> or ->>) except I need
> to thread the arguments into positions other than the first and the
> last. Or sometimes I have to go back and forth between first and last
> positions. Instead of alternating between -> and ->> and creating
> nesting, I've been using this thread macro which replaces underscore
> with the value of the previous expression.
>
> (defmacro -->
>  "Threads the expr through the forms. Replaces all underscores (_)
>  with x in the form, making a list of it if it is not a list already.
>  If there are more forms, inserts the first form as the last item in
>  second form, etc."
>  ([x form] (if (seq? form)
>              (with-meta `(~(first form) ~@(replace {'_ x} (next
> form))) (meta form))
>              (list form x)))
>  ([x form & more] `(--> (--> ~x ~form) ~@more)))
>
> Is there a reason something like this does not exist in clojure.core?
> Is this an oversight or is there a reason this is not there?
>
> Asim
>

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


Re: Thread Macro For Inserting In Arbitrary Positions

2011-07-05 Thread Mark Rathwell
> Is there a reason something like this does not exist in clojure.core?
> Is this an oversight or is there a reason this is not there?

Previous discussions on this subject:

1.
http://groups.google.com/group/clojure/browse_thread/thread/e826fc303e440b7c/0e7bdba707b7982d

  (in particular Rich's response on the second page:
http://groups.google.com/group/clojure/msg/1eb5cf8fa3248049 )


2.
http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852



On Tue, Jul 5, 2011 at 7:14 PM, Asim Jalis  wrote:

> Here is an example of using this:
>
> (--> "hello world" (.toUpperCase _) (.toLowerCase _) (.indexOf _ "w"))
>
> On Tue, Jul 5, 2011 at 3:50 PM, Asim Jalis  wrote:
> > Frequently I want to use the thread macros (-> or ->>) except I need
> > to thread the arguments into positions other than the first and the
> > last. Or sometimes I have to go back and forth between first and last
> > positions. Instead of alternating between -> and ->> and creating
> > nesting, I've been using this thread macro which replaces underscore
> > with the value of the previous expression.
> >
> > (defmacro -->
> >  "Threads the expr through the forms. Replaces all underscores (_)
> >  with x in the form, making a list of it if it is not a list already.
> >  If there are more forms, inserts the first form as the last item in
> >  second form, etc."
> >  ([x form] (if (seq? form)
> >  (with-meta `(~(first form) ~@(replace {'_ x} (next
> > form))) (meta form))
> >  (list form x)))
> >  ([x form & more] `(--> (--> ~x ~form) ~@more)))
> >
> > Is there a reason something like this does not exist in clojure.core?
> > Is this an oversight or is there a reason this is not there?
> >
> > Asim
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Thread Macro For Inserting In Arbitrary Positions

2011-07-05 Thread Sean Corfield
On Tue, Jul 5, 2011 at 4:14 PM, Asim Jalis  wrote:
> Here is an example of using this:
>
> (--> "hello world" (.toUpperCase _) (.toLowerCase _) (.indexOf _ "w"))

BTW, that's not a very compelling example since you can already do:

(-> "hello world!" .toUpperCase .toLowerCase (.indexOf "w"))
-- 
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

2011-07-05 Thread B Smith-Mannschott
On Sat, Jul 2, 2011 at 21:33, David Nolen  wrote:
> On Sat, Jul 2, 2011 at 3:21 PM, James Keats  wrote:
>>
>> And once you encounter the
>> reality and frustration infamously characterized by likening the
>> managing of lispers to the herding of cats then you begin to admire
>> languages like python and java and see what they got right in imposing
>> restrictions.
>
> I've yet to see any evidence anecdotal or otherwise that managing a team of
> good Lisp programmers is any more difficult than managing good programmers
> in any other language. Links?
>
>>
>> A very recent quote by Abelson is relevant:
>> "One of the things I’m learning here (Google) is the experience of
>> working on these enormous programs. I just never experienced that
>> before. Previously a large program to me was a hundred pages or
>> something. Now that’s a tiny, little thing."
>
> One of the most popular text editors to this day is Emacs. It's near 3
> million lines of Lisp.
> David

It is?

Looks like about 1.4M lines of Lisp and less than 0.4 M lines of C.

[bsmith@pepper:~/w/emacs]
$ for x in h c el ; do printf ".%-2s: %7d lines in %5d files\n" $x
$(find * -name "*.$x" | xargs cat | wc -l) $(find * -name "*.$x" | wc
-l) ; done
.h :   37093 lines in   165 files
.c :  337489 lines in   199 files
.el: 1412477 lines in  1551 files

Not that 1.4M isn't large, but it's not 3M.

// Ben

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


clojure and maths

2011-07-05 Thread jlk
Hello

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?



Say I have a fairly complete matrix/vector library, such as
FieldVector or FieldMatrix, that already implement a whole heap of
useful things like cross products and that can be decomposed and find
the determinant, also has a heap of solvers, root finders and other
useful things. etc. etc.  Looks like a good starting point.

Now rather than using BigReal, which implements a FieldElement, I want
to use BigDecimal.  (big real seems to not honour precision settings
very well? a side issue...)


My first thoughts were to try wrap BigDecimal in a (proxy [BigDecimal
FieldElement] [x] ...) and this works to a point, but all the
functions such as .add still return BigDecimals rather than the new
proxy type.

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.

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.


A similar but different problem comes up when trying to use the apache
Complex type, which only works based on double precision - I need to
reimplement the entire class using BigDecimal (or something else) as
the storage mechanism, even though the majority of the logic is
already there, and even the method names are practically the same?
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.


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).  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?  What about something like 3.0b to return
BigDecimals?  or even (set-maths-type BigDecimals) then 3.0?

similarly with matrix access (get m ri ci) is long in an equation
compared with m[ri,ci], (map to-big-decimal (range 0 0.1 1)) is long
compared to something like (set-vector type BigDecimal) ...  [0:0.1:1]


Another issue comes up with performing operations on items.  Rather
than being able to call (+ (apache vector) 3) i need to call
(.mapAddToSelf (apache vector) (to-type (determine-vector-type v))
3)).  Now I can use (:refer-clojure :exclude [+]) and then define a
multimethod such as
(defmulti + #(vec (map class %)))
(defmethod + [Number] [x] x)
(defmethod + [Number Number] [x y] (clojure.core/+ x y))
(defmethod + :default [& args] (reduce + args))
(defmethod + [FieldVector FieldVector] [x y] (.add x y))
(defmethod + [FieldVector Number] [x y] (.mapAddToSelf x (to-type
(determine-vector-type v)) y)
(defmethod + [Number FieldVector] [x y] (.mapAddToSelf y (to-type
(determine-vector-type v)) x))

this gets tiresome pretty quick (try adding a few more types), seems
fairly error prone and is slow.


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

- Lachlan

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

2011-07-05 Thread Peter T
Appreciate the input guys!

Can't comment on the technical side or on where the problem might
stem, but I'll tell you what I can:

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

FWIW the file now consistently throwing the problem -seems- to have
started throwing the problem after a change in some -other- namespace
so perhaps there's a bad interaction happening somewhere?

As per the suggestion in the "Clojure for large programs" thread, I
pulled some stuff out of the ns and it appears to be evaluating fine
again.

So, some conclusions/observations:

1. I'm more or less satisfied: if I know I can always work around the
problem by using shorter namespaces, I'm happy.
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.
3. The problem doesn't [only?] seem to be related to the project size
as a whole (since I was occasionally receiving this error even when
the project was still < 10,000 LOC).
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.
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).


That's about all I can contribute :)

Again, thank you all so much for your time!

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

2011-07-05 Thread Lachlan
Just FYI I ended up using joda time in a project and it seemed to be a
good immutable match for clojure

http://joda-time.sourceforge.net/

- Lachlan



On 30 June 2011 06:42, Islon Scherer  wrote:
> Thanks for the critic Laurent.
> set-date is not destructive, it creates a new date and returns it, the
> original is unaltered,
> but I agree that the documentation and the function name may be
> deceiving, I'll think about a better name and change the docs.
>
> Islon
>
> On Jun 29, 5:29 pm, Laurent PETIT  wrote:
>> Or to be more constructive:
>>
>> maybe set-date &al should be renamed set-date! ...
>>
>> ... the more "clojurish" a library will look like, the more
>> expectations people will have on it (principle of least surprise) even
>> before verifying their assumptions are true (e.g. a "pure clojure"
>> library => works with immutable -if not persistent- datastructures)
>>
>> My 0.02€,
>>
>> --
>> Laurent
>>
>> 2011/6/29 Islon Scherer :
>>
>>
>>
>>
>>
>>
>>
>> > Hello people.
>> > I've created date-clj, a date/time library for clojure.
>> > I know there's clj-time already but I was thinking about something
>> > less javaish and more like date.js.
>>
>> > Some examples:
>>
>> > (date :day 25 :month :november :year 2000)
>> > -> #
>>
>> > (-> (today) (set-date :month :december :year 1900))
>> > -> #
>>
>> > (from-now 1 :year 5 :days)
>> > -> #
>>
>> > (back 1 :month 200 :minutes)
>> > -> #
>>
>> > (following :friday)
>> > -> #
>>
>> > (-> (today) (is? :friday 13))
>> > -> false
>>
>> > (-> (back 3 :days) (was? :sunday))
>> > -> true
>>
>> > (-> (april) sundays first)
>> > -> #
>>
>> > (-> (following :month) fridays last)
>> > -> #
>>
>> > (monday)
>> > -> #
>>
>> > (binding [*locale* (Locale/GERMAN)] (names :week-days))
>> > -> ("Sontag" "Montag" "Dienstag" "Mittwoch" "Donnerstag" "Freitag"
>> > "Samstag")
>>
>> > The project page is:http://github.com/stackoverflow/date-clj
>>
>> > Critics and ideas are welcome =)
>> > Regards,
>> > Islon
>>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with 
>> > your first post.
>> > To unsubscribe from 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



-- 
J Lachlan Kanaley

M 0413 191 194
E lachlan.kana...@gmail.com

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


Re: Build tool for mixed Clojure/Java projects

2011-07-05 Thread Meikel Brandmeyer
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...)

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

2011-07-05 Thread Ken Wesson
On Tue, Jul 5, 2011 at 2:58 PM, David Nolen  wrote:
> On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson  wrote:
>>
>> On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
>>  wrote:
>> > In general, I have found that namespaces should be larger than my OO
>> > intuition would have them be.
>>
>> One problem with scaling up namespaces, though, is that ongoing
>> "invalid constant tag 32" issue with big enough input files (see other
>> thread). For now, until it's fixed, there's an effective size cap on
>> namespaces that is hit at around 1kloc (typically no more than a few
>> hundred functions).
>
> Why doesn't this limitation affect clojure.core, which is 6k+ loc?

I have no idea. But clojure.core is hardly typical; for one thing, it
loads during rather than after bootstrap. Possibly AOT-compiled
namespaces don't have the problem, or have it at larger sizes, than if
JIT-compiled with load-file. It *is* interesting that core.clj is over
200k and doesn't fail whereas others have reported the error happening
consistently for any .clj file exceeding exactly 64k. Perhaps there is
some way to make larger .clj files palatable that could be used by us
normal folk, though if so it isn't obvious what.

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