Re: Sorting of function definitions in namespaces

[Laurent PETIT]

Hi,

Create & use dotopdown (or doreverse, name it as you like):

user=> (defmacro dotopdown [& body] `(do ~@(reverse body)))
#'user/dotopdown
user=> (dotopdown (defn abstract [a] (helper a)) (defn helper [a] (str a)))
#'user/abstract
user=> (abstract 30)
"30"

;)


2011/2/9 jkrueger 

> When writing a Clojure namespace very often I would like to sort my
> functions according to level of abstraction, starting with the most
> abstract functions, followed by helper functions to the more abstract
> functions, and so on. This way of organizing code is promoted as good
> style by the Clean Code guys. However, to do this in Clojure one would
> have to declare almost every function in the namespace before actually
> defining it, since namespaces are interpreted top-down. This strikes
> me as very ugly. Since other functional languages like Haskell manage
> to avoid this problem, I would like to suggest that Clojure should
> provide a way to support this organizational scheme in the future.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: (finally) got all class signature changes w/gen-class reloading at runtime

[Robert Campbell]

Hi George,

That's correct. I briefly mention the JVM's standard "hot swapping"
capabilities when running in debug mode. Unfortunately this hot
swapping is mostly limited to changing method bodies and not class
signatures (add/remove method, etc).

Normally this is not even a problem because - as you mentioned -
Clojure compiles _new_ classes on the fly, and these can be loaded
fine. The problem is limited to gen-class development when stub
classes are generated. During interactive development you'll probably
be adding/removing methods or otherwise changing the class signature.
This is a problem because the stub was already generated the first
time you called (compile) and loaded. Subsequent compiles - which
include the class sig changes - don't get reloaded due to JVM
limitations. This specific issue is solved via JRebel.

Rob



On Thu, Feb 10, 2011 at 12:21 AM, George Jahad
 wrote:
> I studied it a bit more and noticed that the jdi redefineClasses
> method can't add new methods, (as you imply in your blog.)  That's
> what's special about what JRebel offers.
>
> The redefineClasses method is described here:
> http://download.oracle.com/javase/6/docs/jdk/api/jpda/jdi/com/sun/jdi/VirtualMachine.html#redefineClasses(java.util.Map)
>
>
> On Feb 9, 12:38 pm, George Jahad  wrote:
>> so i think most java debuggers, even jdb, are capable of reloading
>> classes aren't they?
>>
>> i haven't tried your example, but in the cdt, you use
>> the .redefineClasses method to reload a java class
>>
>> For example, I can hack on one of the classes in  clojure compiler and
>> reload it, without restarting, like so:
>>
>> (.redefineClasses
>>  (vm)
>>  {(first (find-classes #"clojure.lang.Compiler\$DefExpr\$Parser"))
>>   (to-byte-array
>>    (java.io.File.
>>     "/Users/georgejahad/incoming/clojure/classes/clojure/lang/Compiler
>> $DefExpr$Parser.class"))})
>>
>> is that what you are talking about, or am i missing something?
>>
>> On Feb 9, 12:49 am, Robert Campbell  wrote:
>>
>> > Back in January I found myself writing some gen-class to connect my
>> > Clojure library to my Java project. Until now I'd been spoiled by
>> > Clojure's dynamic, interactive nature, so running up against the whole
>> > "stub class signature can't change w/out jvm reboot" thing hurt a bit.
>>
>> > I found a partial solution via JRebel, but it only worked with
>> > invocations lacking type information and compiled to use reflection.
>> > It failed on any invocation with enough type information present in
>> > the sexpr to use invokevirtual. I actually met Jevgeni (CTO of ZT)
>> > last week and he mentioned he might have some of their guys take a
>> > look at the problem. Lo and behold, their latest nightly build fixes
>> > the issue and it now seems that everything is working.
>>
>> > Here's how to set it up:http://blog.robert-campbell.com/post/2760935713
>>
>> > The company behind JRebel, ZeroTurnaround, gives out free licenses to
>> > OSS and Scala developers. When I spoke with Jevgeni he seemed open to
>> > the idea of adding Clojure development to that list provided there was
>> > enough demand. While gen-class is a relatively rare/minor part of most
>> > Clojure development, I think this tool allows us to smooth out one
>> > rough patch in the dev experience.
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: Anyone want to take a crack at making the fasta shootout program faster?

[Bill James]

http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta&lang=all

The fastest program shown here is in Java and runs in 1.72 seconds.
However, at the bottom of the page (under "interesting alternative"
programs) there is a C++ program that runs in 0.25 seconds; it seems
to work basically the same way that my program does.

So this Clojure program will probably be relegated to the bottom of
the page.

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

[Andreas Kostler]

Hi All,
Is there a list of languages that had a big influence on the development of 
clojure and how this influence manifests itself?
E.g. What language or design decisions were derived from from Haskell or 
Prolog, etc.?
Kind Regards
Andreas

--
 “There is a strong correlation between being smart and being a nerd, and an 
even stronger inverse correlation between being a nerd and being popular”
(Paul Graham)
-- 
**
Andreas Koestler, Software Engineer
Leica Geosystems Pty Ltd
270 Gladstone Road, Dutton Park QLD 4102
Main: +61 7 3891 9772 Direct: +61 7 3117 8808
Fax: +61 7 3891 9336
Email: andreas.koest...@leica-geosystems.com

www.leica-geosystems.com*

when it has to be right, Leica Geosystems

Please  consider the environment before printing this email.





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

[Laurent PETIT]

This :
http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH/ref=cm_lm_byauthor_title_full

HTH,

-- 
Laurent

2011/2/10 Andreas Kostler 

> Hi All,
> Is there a list of languages that had a big influence on the development of
> clojure and how this influence manifests itself?
> E.g. What language or design decisions were derived from from Haskell or
> Prolog, etc.?
> Kind Regards
> Andreas
>
> --
>  “There is a strong correlation between being smart and being a nerd, and
> an even stronger inverse correlation between being a nerd and being popular”
> (Paul Graham)
> --
> **
> Andreas Koestler, Software Engineer
> Leica Geosystems Pty Ltd
> 270 Gladstone Road, Dutton Park QLD 4102
> Main: +61 7 3891 9772 Direct: +61 7 3117 8808
> Fax: +61 7 3891 9336
> Email: andreas.koest...@leica-geosystems.com
>
> www.leica-geosystems.com*
>
> when it has to be right, Leica Geosystems
>
> Please  consider the environment before printing this email.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 language influences

[Andreas Kostler]

I am aware of that list. I would be interested in what influence those 
languages had on clojure. E.g. what language features Rich borrowed from which 
language when he designed Clojure.
Cheers
Andreas

On 10/02/2011, at 9:18 PM, Laurent PETIT wrote:

> http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH/ref=cm_lm_byauthor_title_full

--
 “There is a strong correlation between being smart and being a nerd, and an 
even stronger inverse correlation between being a nerd and being popular”
(Paul Graham)
-- 
**
Andreas Koestler, Software Engineer
Leica Geosystems Pty Ltd
270 Gladstone Road, Dutton Park QLD 4102
Main: +61 7 3891 9772 Direct: +61 7 3117 8808
Fax: +61 7 3891 9336
Email: andreas.koest...@leica-geosystems.com

www.leica-geosystems.com*

when it has to be right, Leica Geosystems

Please  consider the environment before printing this email.





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

[Wolodja Wentland]

On Wed, Feb 09, 2011 at 04:33 -0800, Meikel Brandmeyer wrote:
> Hi,
> 
> omni completion is aware of the namespace of the file you are
> currently editing. It only provides completions which make sense for
> this namespace. Example:

Great, this makes sense and works as expected.

> Feel free to ask such questions on the vimclojure google group.

Thank you for bringing the vimclojure group to my attention. I will ask
subsequent vimclojure related questions there.

On Wed, Feb 09, 2011 at 04:38 -0800, Meikel Brandmeyer wrote:

> >         [vimclojure/server "2.3.0-SNAPSHOT"]

> As a sidenote: you probably want 2.2.0 here instead of the SNAPSHOT.

Ok, that works. The reason for my "decision" to use 2.3.0-SNAPSHOT are
manifold, among them:

* It not clear how to setup vimclojure and hard to find relevant and
  complete information on how to do this. It took me some time to
  come up with the installation procedure I posted above.

  I know that I had to spend some effort to learn aspects of the
  Clojure ecosystem (leinigen? cake? cljr?).

* Clojars search is only showing the "2.3.0-SNAPSHOT" version and
  it is not clear that one can indeed install an earlier one.

Be that as it may, thank a lot for the prompt and very helpful reply and
may you all have a nice day.
-- 
  .''`. Wolodja Wentland 
 : :'  :
 `. `'` 4096R/CAF14EFC 
   `-   081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: clj-ldap - Clojure LDAP client

[Saul Hazledine]

On Feb 10, 8:36 am, Jozef Wagner  wrote:
> One question, If I search for some entries, you return results as a sequence
> of maps. How do I get dn of some result? It seems that your entry-as-map
> converts attributes but strips away entry dn.
>
> I've solved this by adding :dn key in each entry map, 
> seehttps://github.com/wagjo/dredd/blob/master/src/dredd/ldap.clj#L19
>

Many thanks for spotting this important missing attribute. Thanks also
for the link to your code. After reading your version I realised that
clj-ldap should also allow attributes to be selected for an ldap/get.

I've fixed the problem with dn, added attribute selection to ldap/get,
improved the README slightly and released this as version 0.0.2 which
is now on clojars.org.

Saul

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

[Meikel Brandmeyer]

Hi,

On 10 Feb., 13:22, Wolodja Wentland  wrote:

> Ok, that works. The reason for my "decision" to use 2.3.0-SNAPSHOT are
> manifold, among them:
>
>     * It not clear how to setup vimclojure and hard to find relevant and
>       complete information on how to do this. It took me some time to
>       come up with the installation procedure I posted above.

In which way did you find the README in the plugin distribution
lacking or unclear?

>       I know that I had to spend some effort to learn aspects of the
>       Clojure ecosystem (leinigen? cake? cljr?).

Yes. Putting together several pieces plus language at once can be
quite difficult. But be steadfast in your endeavour! It is worth the
trouble! :)


>     * Clojars search is only showing the "2.3.0-SNAPSHOT" version and
>       it is not clear that one can indeed install an earlier one.

There will be always a version for the corresponding vim plugin.
SNAPSHOTs are intended for in development, eh, snapshots. Versions
without SNAPSHOT are (hopefully) stable releases. I'm sorry for the
bad clojars search, but there is nothing I can do about it. My hope
was that the README instructions would also be clear with respect to
the version number.

> Be that as it may

Hopefully not. If there is something to be improved, please speak up!

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: Tricky Macro to write.

[CuppoJava]

That's an awesome solution Meikel!

I forgot to specify that I want the bindings to have lexical scope
only. But I think I can get that to work easily by modifying your
solution.

Thanks!
  -Patrick

On Feb 10, 2:09 am, Meikel Brandmeyer  wrote:
> Whoops. Misclick. Sorry
>
> Here again:
>
> (def *deferred-bindings* {})
>
> (defmacro do-binding
>   [& body]
>   `(with-bindings *deferred-bindings*
>      ~@body))
>
> (defmacro bind-later
>   [bindings & body]
>   (let [vars   (map (fn [v] `(var ~v)) (take-nth 2 bindings))
>         values (take-nth 2 (next bindings))]
>     `(binding [*deferred-bindings* (merge *deferred-bindings*
>                                           ~(zipmap vars values))]
>        ~@body)))
>
> user=> (def a "outer a")
> #'user/a
> user=> (bind-later [a "inner a"] (println a) (do-binding (println a)))
> outer a
> inner a
> nil
> user=> (def b "outer b")
> #'user/b
> user=> (bind-later [a "inner a"] (println a) (bind-later [b "inner b"]
> (println b) (do-binding (println a) (println b)))
> )
> outer a
> outer b
> inner a
> inner b
> nil
>
> Nested invocations merge together. However I haven't checked all the
> edge cases.
>
> And always with binding: beware thread boundaries. But I think you
> know the drill. ;)
>
> 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: Tricky Macro to write.

[Meikel Brandmeyer]

Hi,

On 10 Feb., 14:58, CuppoJava  wrote:
> That's an awesome solution Meikel!

You are welcome. :)

> I forgot to specify that I want the bindings to have lexical scope
> only. But I think I can get that to work easily by modifying your
> solution.

Haha. In fact that was my first impulse. But then I saw the (def a)
and read "bind" and changed my interpretation to dynamic scope.

Lexical scope is much harder. The only "simple" solution, I see at the
moment, is walking the body of bind-later and do substitution. This is
in general ugly, but the only thing I can think of at the moment. This
is a (very) rough sketch, but you should get the key idea.

(declare do-bind)

(defn magic-walk-fn
  [form locals db env]
  (if (seq? form)
(let [[f & args] form
  args   (map magic-walk-fn args)]
  (if (when-not (contains? env f)
(= #'do-bind (resolve f)))
`((fn [~locals] ~@args) ~db)
`(~f ~@args)))
(else-do-other-walking-magic form)))

(defmacro bind-later
  [bindings & body]
  (let [db (gensym "deferred-bindings")
locals (vec (take-nth 2 bindings))
values (vec (take-nth 2 (next bindings)))]
`(let [~db ~values]
   ~@(map #(magic-walk-fn % locals db &env) body

Note that do-bind is just a dummy to identify the correct forms to
transform.

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: Tricky Macro to write.

[CuppoJava]

Hi Meikel,

That's what I original thought I might have to do. But it seemed
overly complicated. Perhaps there's no way around it.

I have a small question about the "with-bindings" function that you
used.

That one establishes dynamically scoped variables. Can't there be
another Clojure function that provides lexically scoped variables?

I actually don't know of any lisp/scheme system that provides a way to
introduce lexically scoped variables at runtime. Do you know if
there's a fundamental reason against doing so?

  -Patrick

On Feb 10, 9:27 am, Meikel Brandmeyer  wrote:
> Hi,
>
> On 10 Feb., 14:58, CuppoJava  wrote:
>
> > That's an awesome solution Meikel!
>
> You are welcome. :)
>
> > I forgot to specify that I want the bindings to have lexical scope
> > only. But I think I can get that to work easily by modifying your
> > solution.
>
> Haha. In fact that was my first impulse. But then I saw the (def a)
> and read "bind" and changed my interpretation to dynamic scope.
>
> Lexical scope is much harder. The only "simple" solution, I see at the
> moment, is walking the body of bind-later and do substitution. This is
> in general ugly, but the only thing I can think of at the moment. This
> is a (very) rough sketch, but you should get the key idea.
>
> (declare do-bind)
>
> (defn magic-walk-fn
>   [form locals db env]
>   (if (seq? form)
>     (let [[f & args] form
>           args       (map magic-walk-fn args)]
>       (if (when-not (contains? env f)
>             (= #'do-bind (resolve f)))
>         `((fn [~locals] ~@args) ~db)
>         `(~f ~@args)))
>     (else-do-other-walking-magic form)))
>
> (defmacro bind-later
>   [bindings & body]
>   (let [db     (gensym "deferred-bindings")
>         locals (vec (take-nth 2 bindings))
>         values (vec (take-nth 2 (next bindings)))]
>     `(let [~db ~values]
>        ~@(map #(magic-walk-fn % locals db &env) body
>
> Note that do-bind is just a dummy to identify the correct forms to
> transform.
>
> 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 language influences

[Fogus]

While the speaker at the video linked below is no absolute authority
in the matter, he does talk (well, mostly gibber) about some of
Clojure's influences.

http://clojure.blip.tv/file/4501296/

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

[Meikel Brandmeyer]

Hi,

On 10 Feb., 15:54, CuppoJava  wrote:

> That one establishes dynamically scoped variables. Can't there be
> another Clojure function that provides lexically scoped variables?
>
> I actually don't know of any lisp/scheme system that provides a way to
> introduce lexically scoped variables at runtime. Do you know if
> there's a fundamental reason against doing so?

Something which modifies &env so to speak? Dunno. I would expect the
lexically scoped variables to be hard-wired by the compiler. Similar
to what happens now with Vars w/o ^:dynamic. That means you'd have to
transform the byte code at runtime based on what the runtime
function's input is. I remember some OCaml docs back in ye olden days,
which stressed that "let x = 5 in ..." does create a variable, which
has the value 5, but is really just a name for the value 5. So it is
substituted by the compiler directly, where its name is used.

But I'm not a language (let alone compiler) guy. So ignoring my
explanations probably doesn't do any harm. :)

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

clojure xmpp

[Bruce Durling]

Hi,

We're going to be doing a dojo in the future that will create an XMPP bot.

I've found a couple of clojure xmpp projects out there, but I was
wondering if anyone on the list could recommend a particular project
in clojure or failing that a good Java library to base our work on.

I've seen xmpp-clj https://github.com/zkim/xmpp-clj and it appears to
be the furthest along so far.

cheers,
Bruce

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

[hdenk]

hi meikel,

thank you for this ...

i have published a gist that showcases a clojure-based webapp
and uses gradle/clojuresque for the build.

http://gist.github.com/815806

gruesse

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

[Bojan Jovicic]

Dear all,
what are in your opinion 3 biggest advantages that Clojure and
functional languages have over .NET, with focus on LINQ?

E.g. I thought of set functions, but this is supported in LINQ.

Any help is more than welcome for this student research.

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

[Mike Meyer]

On Wed, 9 Feb 2011 20:34:56 -0800 (PST)
CuppoJava  wrote:

> Description: (bind-later bindings & body)  and (do-binding & body)
> (bind-later) is used like a let-form, except that it doesn't
> *immediately* make the bindings available.
> The bindings become available only within (do-binding).
> (do-binding) is always used within a (bind-later).
> 
> Here's some sample code showing how it works.
> 
> (def a "outer a")
> (bind-later (a "inner a")
>   (println a)<-- this prints out "outer a" still.
>   (do-binding
> (println a)))  <-- this will print out "inner a"
> 
> Is such a macro possible?

Yes. It's just - as you say - tricky. You need to create a
"do-binding" macro for each bind-later macro, meaning it should be
part of the macros lexical space. First trick - use
clojure.contrib.macro-utils/macrolet to do that sanely. Then comes the
really tricky part - figuring out the correct unquoting for everything.
But this does it:

(defmacro bind-later [bindings & body]
  `(macrolet [(~'do-binding [& body#]
`(let ~'~bindings
  ~@body#))]
 ~@body))

Oh, one thing - since let requires a vector for binding, your example
has to be written as (bind-later [a "inner a"]  But that's the
standard clojure idiom for bindings, so you should do it that way
anyway ;-).

  http://www.mired.org/consulting.html
Independent Network/Unix/SCM consultant, email for more information.

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

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

Re: better error messages > smaller stack traces

[Jeff Rose]

Here's an error I just got that could be improved upon.  It shows an
error in a file core.clj, but my current project uses many libraries
and there are multiple files named core.clj.  How about putting the
full path to the file somewhere so we can jump straight to it?

Thanks,
Jeff

---

user=> (use 'clojure.stacktrace)
nil
user=> (require 'session.inst)
#
user=> (e)
java.lang.Exception: EOF while reading
 at clojure.lang.LispReader.readDelimitedList (LispReader.java:1043)
clojure.lang.LispReader$ListReader.invoke (LispReader.java:900)
clojure.lang.LispReader.readDelimitedList (LispReader.java:1051)
clojure.lang.LispReader$ListReader.invoke (LispReader.java:900)
clojure.lang.LispReader.readDelimitedList (LispReader.java:1051)
clojure.lang.LispReader$ListReader.invoke (LispReader.java:900)
clojure.lang.LispReader.read (LispReader.java:145)
clojure.lang.Compiler.load (Compiler.java:5854)
nil
user=>

On Feb 8, 3:01 pm, Stuart Halloway  wrote:
> This conversation began on Twitter [1] but I want to continue it on the 
> mailing list as it may be of broader interest.
>
> The core team is very interested in improving error messages, and relatively 
> less interested in more code to manipulate stack traces, for the following 
> reasons:
>
> (1) The language sits at the bottom, and must solve the problems nobody 
> higher up can solve. Error messages are created at the point of an error, and 
> if the language gets it wrong you may not have the information to fix it 
> later. OTOH, any old library code can reduce a stacktrace.
>
> (2) Better error messages are easy to implement [2]. Most oddball errors are 
> in macroexpansion, so there is no runtime cost to doing extra work to improve 
> error messages. These can be implemented as pure functions, so even a 
> relative beginner could contribute a patch.
>
> (3) The clojure.repl/pst macro in 1.3 already provides better control of 
> stack trace spewage at the REPL.
>
> Please let us know when you get a misleading error message from a 
> macroexpansion, so we can make it better. Or contribute a patch along the 
> lines of [2].
>
> Thanks,
> Stu
>
> Stuart Halloway
> Clojure/corehttp://clojure.com
>
> [1]http://twitter.com/marick/statuses/33760838540070912
> [2]https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9...

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

[Mark Rathwell]

I just created my own clojure wrappers around the jive (igniterealtime) java
libraries.  Created an xmpp client library with their Smack library, and a
server component library with Tinder (you will need to build from source
with this one).  They are fairly solid java xmpp libraries.

igniterealtime site:  http://www.igniterealtime.org/

I don't have them in any public
repositories, but if you have any interest in using them as a starting point
for your own work, let me know, I can post them somewhere or email them to
you.

 - Mark

On Thu, Feb 10, 2011 at 7:06 AM, Bruce Durling  wrote:

> Hi,
>
> We're going to be doing a dojo in the future that will create an XMPP bot.
>
> I've found a couple of clojure xmpp projects out there, but I was
> wondering if anyone on the list could recommend a particular project
> in clojure or failing that a good Java library to base our work on.
>
> I've seen xmpp-clj https://github.com/zkim/xmpp-clj and it appears to
> be the furthest along so far.
>
> cheers,
> Bruce
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Tricky Macro to write.

[CuppoJava]

Thanks for all your help everyone!

So I came up with an elegant solution. It was a combination of
Meikel's codwalker solution gave me the idea to bootstrap off of
Clojure's macroexpand system to get it to work.

;;This is a convenience method for expanding macros. It recursively
;;macroexpands every subform within a form.
(defn macroexpand-full [expression]
  (let [expanded (macroexpand expression)]
(cond
  ;;Normal Form
  (or (seq? expanded) (list? expanded))
  (doall (map macroexpand-full expanded))

  ;;Vector Form
  (vector? expanded)
  (vec (map macroexpand-full expanded))

  ;;Map Form
  (map? expanded)
  (into {} (map macroexpand-full expanded))

  ;;Set Form
  (set? expanded)
  (into #{} (map macroexpand-full expanded))

  ;;Atom
  :else
  expanded)))

;;After that convenience function, the macro that I actually wanted to
write is trivial!
(def *bindings*)
(defmacro do-binding [& body]
  `(let ~*bindings* ~@body))
(defmacro bind-later [bindings & body]
  (binding [*bindings* bindings]
(macroexpand-full `(do ~@body

Thanks for all your ideas!
  -Patrick

On Feb 10, 2:19 am, Mike Meyer  wrote:
> On Wed, 9 Feb 2011 20:34:56 -0800 (PST)
>
>
>
>
>
> CuppoJava  wrote:
> > Description: (bind-later bindings & body)  and (do-binding & body)
> > (bind-later) is used like a let-form, except that it doesn't
> > *immediately* make the bindings available.
> > The bindings become available only within (do-binding).
> > (do-binding) is always used within a (bind-later).
>
> > Here's some sample code showing how it works.
>
> > (def a "outer a")
> > (bind-later (a "inner a")
> >   (println a)    <-- this prints out "outer a" still.
> >   (do-binding
> >     (println a)))  <-- this will print out "inner a"
>
> > Is such a macro possible?
>
> Yes. It's just - as you say - tricky. You need to create a
> "do-binding" macro for each bind-later macro, meaning it should be
> part of the macros lexical space. First trick - use
> clojure.contrib.macro-utils/macrolet to do that sanely. Then comes the
> really tricky part - figuring out the correct unquoting for everything.
> But this does it:
>
> (defmacro bind-later [bindings & body]
>   `(macrolet [(~'do-binding [& body#]
>                             `(let ~'~bindings
>                                   ~@body#))]
>              ~@body))
>
> Oh, one thing - since let requires a vector for binding, your example
> has to be written as (bind-later [a "inner a"]  But that's the
> standard clojure idiom for bindings, so you should do it that way
> anyway ;-).
>
>       --
> Mike Meyer           http://www.mired.org/consulting.html
> Independent Network/Unix/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org

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

Re: better error messages > smaller stack traces

[Jeff Rose]

Sorry for the reply spam, but I've just remembered another error
reporting issue: pre and post conditions.  They are a great feature
and I'd like to use them more often, but the error messages they
produce are virtually useless in comparison to just writing your own
check with a custom exception.  How about having optional error
messages for the conditions?

Thanks again,
Jeff

On Feb 8, 3:01 pm, Stuart Halloway  wrote:
> This conversation began on Twitter [1] but I want to continue it on the 
> mailing list as it may be of broader interest.
>
> The core team is very interested in improving error messages, and relatively 
> less interested in more code to manipulate stack traces, for the following 
> reasons:
>
> (1) The language sits at the bottom, and must solve the problems nobody 
> higher up can solve. Error messages are created at the point of an error, and 
> if the language gets it wrong you may not have the information to fix it 
> later. OTOH, any old library code can reduce a stacktrace.
>
> (2) Better error messages are easy to implement [2]. Most oddball errors are 
> in macroexpansion, so there is no runtime cost to doing extra work to improve 
> error messages. These can be implemented as pure functions, so even a 
> relative beginner could contribute a patch.
>
> (3) The clojure.repl/pst macro in 1.3 already provides better control of 
> stack trace spewage at the REPL.
>
> Please let us know when you get a misleading error message from a 
> macroexpansion, so we can make it better. Or contribute a patch along the 
> lines of [2].
>
> Thanks,
> Stu
>
> Stuart Halloway
> Clojure/corehttp://clojure.com
>
> [1]http://twitter.com/marick/statuses/33760838540070912
> [2]https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9...

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

[Bruce Durling]

Mark,

Smack looks delightfully straightforward. I think I'll give it a shot thanks!

cheers,
Bruce

On Thu, Feb 10, 2011 at 15:58, Mark Rathwell  wrote:
>
> I just created my own clojure wrappers around the jive (igniterealtime) java
> libraries.  Created an xmpp client library with their Smack library, and a
> server component library with Tinder (you will need to build from source
> with this one).  They are fairly solid java xmpp libraries.
> igniterealtime site:  http://www.igniterealtime.org/
> I don't have them in any public repositories, but if you have any interest
> in using them as a starting point for your own work, let me know, I can post
> them somewhere or email them to you.
>  - Mark
>
> On Thu, Feb 10, 2011 at 7:06 AM, Bruce Durling  wrote:
>>
>> Hi,
>>
>> We're going to be doing a dojo in the future that will create an XMPP bot.
>>
>> I've found a couple of clojure xmpp projects out there, but I was
>> wondering if anyone on the list could recommend a particular project
>> in clojure or failing that a good Java library to base our work on.
>>
>> I've seen xmpp-clj https://github.com/zkim/xmpp-clj and it appears to
>> be the furthest along so far.
>>
>> cheers,
>> Bruce
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: better error messages > smaller stack traces

[Fogus]

> reporting issue: pre and post conditions.  They are a great feature
> and I'd like to use them more often, but the error messages they
> produce are virtually useless in comparison to just writing your own
> check with a custom exception.  How about having optional error
> messages for the conditions?

I'm not sure that I follow your meaning.  Do you mind giving an
example?

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

[Alan]

See the clojure.walk namespace. It has macroexpand-all and walk/
prewalk functions which would make this much simpler.

That said: yes, of course there is a form that introduces lexical
bindings; it's called let (as shown in Mike Meyers's solution).

On Feb 10, 8:01 am, CuppoJava  wrote:
> Thanks for all your help everyone!
>
> So I came up with an elegant solution. It was a combination of
> Meikel's codwalker solution gave me the idea to bootstrap off of
> Clojure's macroexpand system to get it to work.
>
> ;;This is a convenience method for expanding macros. It recursively
> ;;macroexpands every subform within a form.
> (defn macroexpand-full [expression]
>   (let [expanded (macroexpand expression)]
>     (cond
>       ;;Normal Form
>       (or (seq? expanded) (list? expanded))
>       (doall (map macroexpand-full expanded))
>
>       ;;Vector Form
>       (vector? expanded)
>       (vec (map macroexpand-full expanded))
>
>       ;;Map Form
>       (map? expanded)
>       (into {} (map macroexpand-full expanded))
>
>       ;;Set Form
>       (set? expanded)
>       (into #{} (map macroexpand-full expanded))
>
>       ;;Atom
>       :else
>       expanded)))
>
> ;;After that convenience function, the macro that I actually wanted to
> write is trivial!
> (def *bindings*)
> (defmacro do-binding [& body]
>   `(let ~*bindings* ~@body))
> (defmacro bind-later [bindings & body]
>   (binding [*bindings* bindings]
>     (macroexpand-full `(do ~@body
>
> Thanks for all your ideas!
>   -Patrick
>
> On Feb 10, 2:19 am, Mike Meyer  wrote:
>
> > On Wed, 9 Feb 2011 20:34:56 -0800 (PST)
>
> > CuppoJava  wrote:
> > > Description: (bind-later bindings & body)  and (do-binding & body)
> > > (bind-later) is used like a let-form, except that it doesn't
> > > *immediately* make the bindings available.
> > > The bindings become available only within (do-binding).
> > > (do-binding) is always used within a (bind-later).
>
> > > Here's some sample code showing how it works.
>
> > > (def a "outer a")
> > > (bind-later (a "inner a")
> > >   (println a)    <-- this prints out "outer a" still.
> > >   (do-binding
> > >     (println a)))  <-- this will print out "inner a"
>
> > > Is such a macro possible?
>
> > Yes. It's just - as you say - tricky. You need to create a
> > "do-binding" macro for each bind-later macro, meaning it should be
> > part of the macros lexical space. First trick - use
> > clojure.contrib.macro-utils/macrolet to do that sanely. Then comes the
> > really tricky part - figuring out the correct unquoting for everything.
> > But this does it:
>
> > (defmacro bind-later [bindings & body]
> >   `(macrolet [(~'do-binding [& body#]
> >                             `(let ~'~bindings
> >                                   ~@body#))]
> >              ~@body))
>
> > Oh, one thing - since let requires a vector for binding, your example
> > has to be written as (bind-later [a "inner a"]  But that's the
> > standard clojure idiom for bindings, so you should do it that way
> > anyway ;-).
>
> >       > --
> > Mike Meyer           http://www.mired.org/consulting.html
> > Independent Network/Unix/SCM consultant, email for more information.
>
> > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
>
>

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

Re: Clojure and functional languages advantages over .NET

[James Reeves]

> what are in your opinion 3 biggest advantages that Clojure and
> functional languages have over .NET, with focus on LINQ?

Do you mean .NET or C#? There are several functional languages that
run on .NET, such as F#.

- James

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

[Joost]

On Feb 9, 6:48 pm, Bojan Jovicic  wrote:
> Dear all,
> what are in your opinion 3 biggest advantages that Clojure and
> functional languages have over .NET, with focus on LINQ?

.NET is not a language, it's a runtime with explicit multi-language
support. There's even a clojure implementation that runs on .NET.
There's also F#, which is Microsoft's functional language for .NET.
The JVM and .NET runtimes both support loads of languages. There are
several other multi-language runtimes in the works at the moment.
AFAICS "serious" hosted languages are all moving towards a split
between langugage and runtime. Comparing languages to runtimes is not
very useful at this point in time and the question will probably
become even more pointless in the future.

Never heard of LINQ until you mentioned it, but it appears to be a
general data querying library. That sort of thing is generally
implemented as on top of a language/runtime. Clojure/Java doesn't
currently have something like that as far as I know,  (unless you
count JDBC and the Clojure-specific layers on top of it like the
interesting ClojureQL), though I may be wrong - there is a stupendous
amount of Java libraries and frameworks out there and most work with
Clojure if need be.

> E.g. I thought of set functions, but this is supported in LINQ.

Clojure has sets and related functions in the core language, ClojureQL
implements sets in a way that might be closer to what you're thinking
about.

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

[Jason Wolfe]

> Alternatively, records could have an enforced mapping {:type
> TheRecordsClass} that does not actually take up storage space, but
> appears when records are queried and automatically imposes the desired
> equality semantics if records were simply treated as maps -- other
> than that a plain map with the same type key-value pair could now
> compare equal to the record. (Would that be a bad thing though?)

That might be the clearest way to allow records to behave as Java
Maps, while preserving type-based equality.  It's how I did things
manually to keep struct-maps straight, before there were records.

The more I think about the current behavior, the less I think I like
it.  If P and Q have different implementations of the same protocol,
you can have (.equals (P.) (Q.)) but completely different semantics
for (foo (P.)) and (foo (Q.)).

In any case, I've posted a ticket for the docstring fix:
http://dev.clojure.org/jira/browse/CLJ-736

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

Re: better error messages > smaller stack traces

[Daniel Werner]

On 10 February 2011 17:05, Jeff Rose  wrote:
> Sorry for the reply spam, but I've just remembered another error
> reporting issue: pre and post conditions.  They are a great feature
> and I'd like to use them more often, but the error messages they
> produce are virtually useless in comparison to just writing your own
> check with a custom exception.  How about having optional error
> messages for the conditions?

You can make your pre/post condition AssertionErrors more
human-readable by factoring out their logic into helper functions:

(defn valid-article-id? [art-id]
  (or (and (> (mod x 42) 3) (frobz x)) (qux x)))

(defn buy-article [art-id]
  {:pre [(valid-article-id? art-id)]}
  ...)

Thus, the AssertionError message will complain about
"valid-article-id?" failing instead of the rather cryptic "or and
mod". If you need even more flexibility, it is also possible to throw
an exception from the helper function. Not pretty, though.

That said, I'd really wish for the private clojure.core/assert-args
macro to be made public. It's very comfortable to work with and
provides for semi-standardized error messages (offending argument name
always in front).

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

[Michael Ossareh]

On Thu, Feb 10, 2011 at 08:21, Bruce Durling  wrote:

> Mark,
>
> Smack looks delightfully straightforward. I think I'll give it a shot
> thanks!
>
>
Smack has a bunch of oddities once you start wanting to do anything past
simple message processing. The predominate issue (this as of smack 3.0 I
believe) was that each XMPP connection fires up 4 threads, since we (heysan)
were using this in a service setting (consider something similar to meebo)
this really impacted our scalability.

If you're not creating a chat site for teens - you're good to go!

XMPP itself is a relatively simple protocol (primarily since it is so well
documented). If someone were game to build a pure clj implementation on top
of something like aleph I'd definitely donate 15hours a week to help. The
world needs a better JVM XMPP stack, imho.





> cheers,
> Bruce
>
> On Thu, Feb 10, 2011 at 15:58, Mark Rathwell 
> wrote:
> >
> > I just created my own clojure wrappers around the jive (igniterealtime)
> java
> > libraries.  Created an xmpp client library with their Smack library, and
> a
> > server component library with Tinder (you will need to build from source
> > with this one).  They are fairly solid java xmpp libraries.
> > igniterealtime site:  http://www.igniterealtime.org/
> > I don't have them in any public repositories, but if you have any
> interest
> > in using them as a starting point for your own work, let me know, I can
> post
> > them somewhere or email them to you.
> >  - Mark
> >
> > On Thu, Feb 10, 2011 at 7:06 AM, Bruce Durling  wrote:
> >>
> >> Hi,
> >>
> >> We're going to be doing a dojo in the future that will create an XMPP
> bot.
> >>
> >> I've found a couple of clojure xmpp projects out there, but I was
> >> wondering if anyone on the list could recommend a particular project
> >> in clojure or failing that a good Java library to base our work on.
> >>
> >> I've seen xmpp-clj https://github.com/zkim/xmpp-clj and it appears to
> >> be the furthest along so far.
> >>
> >> cheers,
> >> Bruce
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Clojure and functional languages advantages over .NET

[Timothy Baldridge]

I know talked a bit about this when you e-mailed me personally on the
subject, but perhaps I'll take another stab at it.

But back to the subject at hand of C# vs Clojure. For me the biggest
thing comes down to immutability and functions with zero side effects.
I tend to code very functionally when I write code in C#. Infact,
since learing F#, my code C# looks more and more like F# code.

In OOP and C# you'll see something like this allot (sadly):

public void WriteData()
{
 _fileWriter.Write("foo");
}

Now, just looking at this function, what is _fileWriter? Where is it
assigned? If it's null in this function where the heck do I go to
figure out what's gone wrong? We haven't a clue. So now we have to
either put a null check in this routine, or specify somewhere in the
documentation "Call open file before you call WriteData() or this
program will bomb".

Instead, let's write this like a functional program should be written:

public static void WriteData(StreamWriter fileWriter)
{
 fileWriter.Write("foo");
}

Ah! Now we know exactly what _fileWriter is, and if it's null, well
then we know exactly where to go. And it's very clear that we don't
need a null check, since why on earth would you pass a null in to
WriteData(StreamWriter) and expect it to do something?

Now let's throw multicore into the mix. On the second example we can
do whatever we want to fileWatcher (such as seeking) and not be
worried about messing up the data for other threads using this same
class.

All this to say. Functional languages such as F# and Clojure make this
sort of programming easier. And as time goes on C# is slowly shifting
more and more to functional programming Eric Lippert (one of the main
devs working on C#) has said that immutability is future of C#.

I hope this helps some.

Timothy

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

Problems with lazy-xml

[Marko Topolnik]

I am required to process a huge XML file with 300,000 records. The
structure is like this:


  

  
  
...
...
... 299,998 more
  


Obviously, it is of key importance not to allocate memory for all the
records at once. If I do this:

(use ['clojure.contrib.lazy-xml :only ['parse-trim]])
(use ['clojure.java.io :only ['reader]])

(-> (parse-trim (reader "huge.xml"))
 :content
 second
 :tag)

This should only parse the start-tag , but it parses all the way
down to  -- at least it tries to, failing with
OutOfMemoryError.

Am I wrong in expecting the entire contents of body not to be
parsed? :content is supposed to be a lazy seq, so even if I access its
head, it should still not parse more than just the first 
element, right?

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

[jkrueger]

Sure. I'm not saying that you can't write it yourself. My point was,
that

a) This is essential to writing understandable code, so it would be
nice if the language supported it out of the box
b) A namespace feels to me like a set of functions (ns-publics
actually returns a map). That Clojure enforces a particular ordering
(if we forget about the "declare" kludge) while writing a namespace
seems arbitrary from a programmers point of view.

Jan

On Feb 10, 9:43 am, Laurent PETIT  wrote:
> Hi,
>
> Create & use dotopdown (or doreverse, name it as you like):
>
> user=> (defmacro dotopdown [& body] `(do ~@(reverse body)))
> #'user/dotopdown
> user=> (dotopdown (defn abstract [a] (helper a)) (defn helper [a] (str a)))
> #'user/abstract
> user=> (abstract 30)
> "30"
>
> ;)
>
> 2011/2/9 jkrueger 
>
> > When writing a Clojure namespace very often I would like to sort my
> > functions according to level of abstraction, starting with the most
> > abstract functions, followed by helper functions to the more abstract
> > functions, and so on. This way of organizing code is promoted as good
> > style by the Clean Code guys. However, to do this in Clojure one would
> > have to declare almost every function in the namespace before actually
> > defining it, since namespaces are interpreted top-down. This strikes
> > me as very ugly. Since other functional languages like Haskell manage
> > to avoid this problem, I would like to suggest that Clojure should
> > provide a way to support this organizational scheme in the future.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from 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 and functional languages advantages over .NET

[Paulo Pinto]

Hi,

I got the impression that you don't know .Net.

.Net is a VM similar to what the JVM offers, there are many functional
languages that
target .Net as well.

Microsoft's own functional language F#
Currently VB.Net and C# provide functional programming constructs
LINQ is actually an implementation of Monads
There is OCaml for .Net
There are efforts in place to target Scala to .Net
And many other functional languages, that I have omitted.

Oh lets not forget that there is Clojure being developed for .Net as
well.

So I suggest that you rethink the scope of your question.

--
Paulo

On Feb 9, 6:48 pm, Bojan Jovicic  wrote:
> Dear all,
> what are in your opinion 3 biggest advantages that Clojure and
> functional languages have over .NET, with focus on LINQ?
>
> E.g. I thought of set functions, but this is supported in LINQ.
>
> Any help is more than welcome for this student research.

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

Re: better error messages > smaller stack traces

[Hubert Iwaniuk]

Hi,

Jeff correct me if I'm wrong but I think you are after something along the 
following lines.
Instead:
(defn f [x] {:pre [(some-fancy-validation x)]} ..)

To have something like this:
(defn f [x] {:pre [^{:msg "here goes description of what has not been valid"} 
(some-fancy-validation x)]} ..)

It could turn precondition to a bit more user-friendly construct.

I would also like to have assert-args public.

Cheers,
Hubert.
On Feb 10, 2011, at 8:10 PM, Daniel Werner wrote:

> On 10 February 2011 17:05, Jeff Rose  wrote:
>> Sorry for the reply spam, but I've just remembered another error
>> reporting issue: pre and post conditions.  They are a great feature
>> and I'd like to use them more often, but the error messages they
>> produce are virtually useless in comparison to just writing your own
>> check with a custom exception.  How about having optional error
>> messages for the conditions?
> 
> You can make your pre/post condition AssertionErrors more
> human-readable by factoring out their logic into helper functions:
> 
> (defn valid-article-id? [art-id]
>  (or (and (> (mod x 42) 3) (frobz x)) (qux x)))
> 
> (defn buy-article [art-id]
>  {:pre [(valid-article-id? art-id)]}
>  ...)
> 
> Thus, the AssertionError message will complain about
> "valid-article-id?" failing instead of the rather cryptic "or and
> mod". If you need even more flexibility, it is also possible to throw
> an exception from the helper function. Not pretty, though.
> 
> That said, I'd really wish for the private clojure.core/assert-args
> macro to be made public. It's very comfortable to work with and
> provides for semi-standardized error messages (offending argument name
> always in front).
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: better error messages > smaller stack traces

[Fogus]

> (defn f [x] {:pre [^{:msg "..."} (some-fancy-validation x)]} ..)

That idea (or some variation) is actually kinda nice.

Additionally, I've always hoped for separate
PreConditionAssertionError and PostConditionAssertionError types, but
keep forgetting to discuss 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: Sorting of function definitions in namespaces

[Meikel Brandmeyer]

Hi,

Am 10.02.2011 um 16:27 schrieb jkrueger:

> a) This is essential to writing understandable code, so it would be
> nice if the language supported it out of the box

Is that so? I'd rather say that this a personal opinion of yours. There are 
different ways to organise code and neither is superior to the other. Just 
different.

> b) A namespace feels to me like a set of functions (ns-publics
> actually returns a map). That Clojure enforces a particular ordering
> (if we forget about the "declare" kludge) while writing a namespace
> seems arbitrary from a programmers point of view.

But Clojure's model of evaluation of a namespace also has a simple elegance. 
Defining a function is treated equally to adding two numbers. Everything is 
consistent. It is easy to determine what happens when. There are no special 
cases. This should seem quite logic from a programmers point of view.

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: Anyone want to take a crack at making the fasta shootout program faster?

[Isaac Gouy]

On Feb 10, 1:17 am, Bill James  wrote:
> http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta〈=all
>
> The fastest program shown here is in Java and runs in 1.72 seconds.
> However, at the bottom of the page (under "interesting alternative"
> programs) there is a C++ program that runs in 0.25 seconds; it seems
> to work basically the same way that my program does.
>
> So this Clojure program will probably be relegated to the bottom of
> the page.


Should it be relegated to the bottom of the page?

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

[Andy Fingerhut]

It would be easier for submitters to answer that question if it was  
more obvious *why* a program is in the "interesting alternative"  
program section.  Even a brief note in comments at the top of such  
programs explaining the reason for their alternative status would be  
enlightening.


Thanks,
Andy

On Feb 10, 2011, at 12:47 PM, Isaac Gouy wrote:


On Feb 10, 1:17 am, Bill James  wrote:

http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta〈=all

The fastest program shown here is in Java and runs in 1.72 seconds.
However, at the bottom of the page (under "interesting alternative"
programs) there is a C++ program that runs in 0.25 seconds; it seems
to work basically the same way that my program does.

So this Clojure program will probably be relegated to the bottom of
the page.



Should it be relegated to the bottom of the page?

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

To unsubscribe from 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 language influences

[Andreas Kostler]

I like it when people talk about themselves in third person ;)
Thanks Michael

On 11 February 2011 01:00, Fogus  wrote:

> While the speaker at the video linked below is no absolute authority
> in the matter, he does talk (well, mostly gibber) about some of
> Clojure's influences.
>
> http://clojure.blip.tv/file/4501296/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>



-- 
**
Andreas Koestler, Software Engineer
Leica Geosystems Pty Ltd
270 Gladstone Road, Dutton Park QLD 4102
Main: +61 7 3891 9772 Direct: +61 7 3117 8808
Fax: +61 7 3891 9336
Email: andreas.koest...@leica-geosystems.com

www.leica-geosystems.com*

when it has to be right, Leica Geosystems

Please  consider the environment before printing this email.

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

[Bill James]

On Feb 10, 2:47 pm, Isaac Gouy  wrote:
> On Feb 10, 1:17 am, Bill James  wrote:
>
> >http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta〈=all
>
> > The fastest program shown here is in Java and runs in 1.72 seconds.
> > However, at the bottom of the page (under "interesting alternative"
> > programs) there is a C++ program that runs in 0.25 seconds; it seems
> > to work basically the same way that my program does.
>
> > So this Clojure program will probably be relegated to the bottom of
> > the page.
>
> Should it be relegated to the bottom of the page?

The C++ program was evidently deprecated because it did not go through
the process of generating a random character for each character that
it output. The author realized that the pseudo-random-number-generator
had a cycle-length less than 200_000.

Both the C++ program and the Clojure program use a much more efficient
algorithm than the other programs.  That may violate the rules.

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

[Bojan Jovicic]

Dear all,
I wish to thank you for your answers.

I am sorry for confusion because of my generic questions. We are
learning Clojure at University, and are looking for some nice example
of integrating it with one ERP system that has .NET integration
capability, so my question was directed at getting more insight about
following:

1) What would be the potential reason to use functional languages
(Clojure, F#, ...) vs .NET (because this is the context of this ERP
integration mechanism) non-functional languages (C#) with LINQ (a
Monads implementation as Paulo pointed)?
2) Are there potential advantages of Clojure over F#?

Thank you all, once again :)

On Feb 10, 5:32 pm, Paulo Pinto  wrote:
> Hi,
>
> I got the impression that you don't know .Net.
>
> .Net is a VM similar to what the JVM offers, there are many functional
> languages that
> target .Net as well.
>
> Microsoft's own functional language F#
> Currently VB.Net and C# provide functional programming constructs
> LINQ is actually an implementation of Monads
> There is OCaml for .Net
> There are efforts in place to target Scala to .Net
> And many other functional languages, that I have omitted.
>
> Oh lets not forget that there is Clojure being developed for .Net as
> well.
>
> So I suggest that you rethink the scope of your question.
>
> --
> Paulo
>
> On Feb 9, 6:48 pm, Bojan Jovicic  wrote:
>
>
>
>
>
>
>
> > Dear all,
> > what are in your opinion 3 biggest advantages that Clojure and
> > functional languages have over .NET, with focus on LINQ?
>
> > E.g. I thought of set functions, but this is supported in LINQ.
>
> > Any help is more than welcome for this student research.

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

[Mike Meyer]

On Thu, 10 Feb 2011 07:22:55 -0800 (PST)
Marko Topolnik  wrote:

> I am required to process a huge XML file with 300,000 records. The
> structure is like this:
> 
> 
>   
> 
>   
>   
> ...
> ...
> ... 299,998 more
>   
> 
> 
> Obviously, it is of key importance not to allocate memory for all the
> records at once.

I don't think it's obvious. Maybe I'm missing something? Like - how
big are the records? If they're less than 1K, that's at most 300 meg
in core - which is large, but not impossible on modern hardware. I've
been handling .5G data structures in core for the last few years (in
Python, anyway). I've run into at least one stupid garbage collector
that insisted on scanning such structures even though they weren't
changing, which pretty much killed performance. Maybe you have a "fast
startup" requirement, which building the initial data structure would
kill. Maybe something else?

  Thanks,
   http://www.mired.org/consulting.html
Independent Network/Unix/SCM consultant, email for more information.

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

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

Re: Clojure and functional languages advantages over .NET

[Timothy Baldridge]

I think it comes down to the following:

1) STM, for many applications, STM is a major plus (F# doesn't have
STM currently)
2) The LISP syntax can be quite freeing once you learn it
3) Clojure is a dynamic language, unlike F# and C#

Now here's the kicker. Depending who you talk to, all of these can be
"cons" as well as "pros". Dr. Cliff Click and Rich Hickey have had
some rather friendly arguments over STM and its usefulness in large
applications.

The LISP syntax can be viewed as a bad thing. I for one struggle with
it from time to time. I personally haven't decided if I think the LISP
syntax is a pro or a con.

And the dynamicness of Clojure can be considered a bad thing
performance-wise. Many benchmarks will show Clojure trailing a bit
behind C# in pure number crunching performance.

So it goes down to using the tool that fits.

My parents built a house years ago that uses steel for all the
internal structure. The thing is rock solid, and if it got hit with a
tornado it would probably still be there. But you know what? Hanging a
mirror on the wall ends up being an hour long process because you have
to drill into a metal beam before hanging the picture. Is steel better
than wood? Ask 10 people and you'll get 12 answers. It's all in the
style of the project, and your goals.

Timothy

On Thu, Feb 10, 2011 at 3:48 PM, Bojan Jovicic  wrote:
> Dear all,
> I wish to thank you for your answers.
>
> I am sorry for confusion because of my generic questions. We are
> learning Clojure at University, and are looking for some nice example
> of integrating it with one ERP system that has .NET integration
> capability, so my question was directed at getting more insight about
> following:
>
> 1) What would be the potential reason to use functional languages
> (Clojure, F#, ...) vs .NET (because this is the context of this ERP
> integration mechanism) non-functional languages (C#) with LINQ (a
> Monads implementation as Paulo pointed)?
> 2) Are there potential advantages of Clojure over F#?
>
> Thank you all, once again :)
>
> On Feb 10, 5:32 pm, Paulo Pinto  wrote:
>> Hi,
>>
>> I got the impression that you don't know .Net.
>>
>> .Net is a VM similar to what the JVM offers, there are many functional
>> languages that
>> target .Net as well.
>>
>> Microsoft's own functional language F#
>> Currently VB.Net and C# provide functional programming constructs
>> LINQ is actually an implementation of Monads
>> There is OCaml for .Net
>> There are efforts in place to target Scala to .Net
>> And many other functional languages, that I have omitted.
>>
>> Oh lets not forget that there is Clojure being developed for .Net as
>> well.
>>
>> So I suggest that you rethink the scope of your question.
>>
>> --
>> Paulo
>>
>> On Feb 9, 6:48 pm, Bojan Jovicic  wrote:
>>
>>
>>
>>
>>
>>
>>
>> > Dear all,
>> > what are in your opinion 3 biggest advantages that Clojure and
>> > functional languages have over .NET, with focus on LINQ?
>>
>> > E.g. I thought of set functions, but this is supported in LINQ.
>>
>> > Any help is more than welcome for this student research.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)

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

[jkrueger]

On Feb 10, 9:33 pm, Meikel Brandmeyer  wrote:
> Hi,
>
> Am 10.02.2011 um 16:27 schrieb jkrueger:
>
> > a) This is essential to writing understandable code, so it would be
> > nice if the language supported it out of the box
>
> Is that so? I'd rather say that this a personal opinion of yours. There are 
> different ways to organise code and neither is superior to the other. Just 
> different.
>

Well... It is Robert C. Martin's opinion. I just happen to agree with
him. I don't mean to call on a higher authority as an argument
stopper. But people who have put a lot of thought into organizing
code, seem to have arrived at this opinion. I definitely phrased the
original sentence too strongly. I should have said that I _think_ that
it is essential to writing readable code.

> > b) A namespace feels to me like a set of functions (ns-publics
> > actually returns a map). That Clojure enforces a particular ordering
> > (if we forget about the "declare" kludge) while writing a namespace
> > seems arbitrary from a programmers point of view.
>
> But Clojure's model of evaluation of a namespace also has a simple elegance. 
> Defining a function is treated equally to adding two numbers. Everything is 
> consistent. It is easy to determine what happens when. There are no special 
> cases. This should seem quite logic from a programmers point of view.
>

I'm perfectly willing to be convinced that I'm wrong if there are good
reasons not do this in Clojure. That's why i brought it up as a
discussion. Additional complexity in the core language is obviously a
concern. Still, I feel that the fixed ordering is a restriction that
is very bothersome when trying to clean up my code. I think I will
spent some more time thinking about how this would actually affect the
language.

> 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 and functional languages advantages over .NET

[Joost]

Please note that I don't want to start a big argument either.

On Feb 10, 11:01 pm, Timothy Baldridge  wrote:
> The LISP syntax can be viewed as a bad thing. I for one struggle with
> it from time to time. I personally haven't decided if I think the LISP
> syntax is a pro or a con.

I think this is fair. Lisp languages work for me, mostly because they
make stuff that seems "special" in other languages much more explicit
and hackable. YMMV.

> And the dynamicness of Clojure can be considered a bad thing
> performance-wise. Many benchmarks will show Clojure trailing a bit
> behind C# in pure number crunching performance.

Dynamic languages make *development* fast. At least compared to Java/C
style "static" languages. Even if you're working on a program where
performance really matters, the big gains are very probably only to be
found in about 20% of the code base (and I think I'm being very
generous here). For the other 80% dynamic vs static  typing is a non-
issue. But in a static language, you're still paying the extra
development time for that 80% of code where it doesn't matter.

Again, YMMV, IMHO, bla bla bla
Joost.

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

[Joost]

On Feb 10, 4:27 pm, jkrueger  wrote:
> Sure. I'm not saying that you can't write it yourself. My point was,
> that
>
> a) This is essential to writing understandable code, so it would be
> nice if the language supported it out of the box

I don't agree it's essential. I think if you use namespaces, you can
easily structure code in a way that's "top down":

(ns high-level
  (:use lower-level))

(defn high [a b]
  (low1 a (low2 b)))

The order within a file is not that important, because a single file
shouldn't contain enough code to be confusing.

> b) A namespace feels to me like a set of functions (ns-publics
> actually returns a map). That Clojure enforces a particular ordering
> (if we forget about the "declare" kludge) while writing a namespace
> seems arbitrary from a programmers point of view.

Yes it's arbitrary, but the other way around would be arbitrary too,
and IME

1) it's fairly rare that you actually *need* a declare "kludge".
2) full free ordering generally makes stuff harder to find than
"enforced order".

In conclusion, I see the current behavior as slightly more a feature
than an issue.

Joost.

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

[Joost]

On Feb 11, 12:02 am, Joost  wrote:
> Yes it's arbitrary, but the other way around would be arbitrary too,
> and IME
>
> 1) it's fairly rare that you actually *need* a declare "kludge".
> 2) full free ordering generally makes stuff harder to find than
> "enforced order".

I forgot to add that I've used Perl a lot, which does *try* to do free-
style ordering, and it ended up with a system that works most of the
time, but is really not easy to figure out when it doesn't work, and
even adding "declare" style statements don't always work like you want
to. I really prefer an enforced order with *reliable* declarations.

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

[Ken Wesson]

On Thu, Feb 10, 2011 at 11:01 AM, CuppoJava  wrote:
> Thanks for all your help everyone!
>
> So I came up with an elegant solution. It was a combination of
> Meikel's codwalker solution gave me the idea to bootstrap off of
> Clojure's macroexpand system to get it to work.
>
> ;;This is a convenience method for expanding macros. It recursively
> ;;macroexpands every subform within a form.
> (defn macroexpand-full [expression]
>  (let [expanded (macroexpand expression)]
>    (cond
>      ;;Normal Form
>      (or (seq? expanded) (list? expanded))
>      (doall (map macroexpand-full expanded))
>
>      ;;Vector Form
>      (vector? expanded)
>      (vec (map macroexpand-full expanded))
>
>      ;;Map Form
>      (map? expanded)
>      (into {} (map macroexpand-full expanded))
>
>      ;;Set Form
>      (set? expanded)
>      (into #{} (map macroexpand-full expanded))
>
>      ;;Atom
>      :else
>      expanded)))

What a coincidence. I just had reason to write my own version of this.
 I came up with a somewhat different approach though:

(defn map-ps [f coll]
  (if (map? coll)
(into (empty coll)
  (map (fn [[k v]] [(f k) (f v)]) coll))
(if (or (vector? coll) (set? coll))
  (into (empty coll) (map f coll))
  (map f coll

(defn macroexpand-all [form]
  (if (coll? form)
(let [f (macroexpand form)]
  (if (coll? f)
(map-ps macroexpand-all f)
f))
form))

The helper function map-ps maps a function over any set, map, vector,
or seq/list, preserving the type and applying to both keys and values
of maps. (It should even turn a sorted-set, say, into a sorted-set
with the same comparator. That may actually work poorly in certain
cases where the types of the elements are changed. But that's not
relevant for macroexpand-all. Meanwhile all lists/seqs become
LazySeq.)

The actual macroexpand-all function exploits macroexpand, as does your
implementation, but uses map-ps to recursively apply itself to
subforms.

I didn't bother with doall because typical Clojure code does not nest
thousands of parentheses deep. :)

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

[Eugen Dück]

Thanks guys for all the input.

I finally read the CA, and I guess the principal difference between
clojure contributions and wikipedia (which you wouldn't even know what
the heck it was if they had asked everyone to sign a CA first)
contributions - is not the type of content - code vs. prose (and the
division is not that sharp either, as both contain both things, and
more) - but the various transfers of rights of whom some are on the
brink of granting exclusivity. And of course IANAL.

That said, I've contributed to a number of open source projects, none
of which required anything physical from me, and which wouldn't have
gotten anything from me had they asked, just because I wouldn't have
wanted to spend the time on red tape for every single one small patch
(although important to me) for every one of those projects. Actually
in the past I did also contribute to a bunch of different parts of the
iirc biggest open source project - KDE - without ever signing
anything, in fact mostly using some alias (so now you where all those
pesky bugs originate ;).

But I guess it all comes down to what Rich wants to be able to do with
the code base and not get locked in by some guys he has to chase for
permission later on if he wants to rearrange things, which I can
understand.

And for those posters telling us not to "waste your time, stop asking
questions and just trust Rich": Why don't you stop wasting your time
telling us what to do with ours? As this thread shows, it's still an
open question, with some people curious for the answer. And even
though I'll send the CA out this weekend, I am curious as to why
signing is necessary for this project, when it isn't for others. And
at least I have some ideas now.

In terms of git pull requests by CA signers, I'm still hopeful though,
as I don't see the legal issue there, and there's a hint in "please
don't send pull requests via GitHub AT THIS TIME".

Cheers
Eugen

On Feb 5, 11:45 am, Mike Meyer  wrote:
> On Fri, 4 Feb 2011 18:36:34 -0800
>
>
>
> Sean Corfield  wrote:
> > On Fri, Feb 4, 2011 at 6:16 PM, Eugen Dück  wrote:
> > > Is it really necessary, though? We all agree to EULAs and make other
> > > more significant legal commitments online all the time, and in some
> > > cases without having proven who and where we are.
>
> > There are certainly some legal transactions that do not accept
> > electronic "agreements" and require a physical signature.
>
> > IANAL so I looked up US copyright law and found this paragraph about
> > transfers in Circular 1 (from here
> >http://www.copyright.gov/help/faq/faq-assignment.html):
>
> > "Any or all of the copyright owner’s exclusive rights or any
> > subdivision of those rights may be transferred, but the trans­fer of
> > exclusive rights is not valid unless that transfer is in writing and
> > signed by the owner of the rights conveyed or such owner’s duly
> > authorized agent. Transfer of a right on a nonexclusive basis does not
> > require a written agreement."
>
> > So that's why a written signature is required for the Clojure CA.
>
> Um, read the last line in the quote, about "nonexclusive basis".
>
> The first bullet of clause two in the CA (downloaded just now) grants
> Rich Hickey a "... perpetual, irrevocable, non-exclusive, worldwide
> ... license"
>
> Given that the license is nonexclusive transfer (and I have to wonder
> if you'd get any contributors otherwise, or if any other OSS project
> has an exclusive transfer), then according to that last line, it "does
> not require a written agreement."
>
> IANAL either, but it sure seems like the current requirements exceeds
> what the law requires.
>
>        --
> Mike Meyer           http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org

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

Re: Anyone want to take a crack at making the fasta shootout program faster?

[Andy Fingerhut]

On Feb 10, 2011, at 1:41 PM, Bill James wrote:


On Feb 10, 2:47 pm, Isaac Gouy  wrote:

On Feb 10, 1:17 am, Bill James  wrote:

http://shootout.alioth.debian.org/u32/benchmark.php? 
test=fasta〈=all



The fastest program shown here is in Java and runs in 1.72 seconds.
However, at the bottom of the page (under "interesting alternative"
programs) there is a C++ program that runs in 0.25 seconds; it seems
to work basically the same way that my program does.



So this Clojure program will probably be relegated to the bottom of
the page.


Should it be relegated to the bottom of the page?


The C++ program was evidently deprecated because it did not go through
the process of generating a random character for each character that
it output. The author realized that the pseudo-random-number-generator
had a cycle-length less than 200_000.

Both the C++ program and the Clojure program use a much more efficient
algorithm than the other programs.  That may violate the rules.


If that was the reason it was deprecated, then it makes sense.  It  
would be nice if the rules for that problem made it more explicit that  
this was not allowed.


I made a modified version of the program that calls the random number  
generator for every separate character output (for the two sequences  
that should be randomly generated), and unfortunately the run time is  
back up to about the same as the current fastest program on the web  
site, which unfortunately is 6x to 8x slower than the best Java program.


I've published that program at the link below.  It contains comments  
marking two lines in the function gen-random-fast where the Hotspot  
JVM profiler tells me that the CPU is spending lots of time in  
java.lang.Integer.valueOf (Clojure 1.2.0).  I can't seem to get rid of  
these calls to Integer.valueOf even after trying about half a dozen  
different variations of type-hinting.  Can anyone else see a way to  
change the program to avoid those calls?


http://github.com/jafingerhut/clojure-benchmarks/blob/master/fasta/fasta.clj-10.clj

Thanks,
Andy

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

Macrolet

[Ken Wesson]

(defn quo [expr] `(quote ~expr))

(defn union [s1 s2]
  (if (empty? s2)
s1
(apply conj s1 s2)))

(def sfrms '#{def if do quote var recur throw monitor-enter monitor-exit . new
  set!})

(defn map-ps [f coll]
  (if (map? coll)
(into (empty coll)
  (map (fn [[k v]] [(f k) (f v)]) coll))
(if (or (vector? coll) (set? coll))
  (into (empty coll) (map f coll))
  (map f coll

(declare macrolet-v)

(defmacro macrolet* [shadowlist fnspecs & body]
  (let [locals (keys &env)
gensyms (for [_ locals] (gensym))
qlocals (map quo (for [_ locals] (gensym)))
lqmap (zipmap locals qlocals)
qgensyms (map quo gensyms)
fnmap (reduce
(fn [fnm [name argl & body]]
  (assoc fnm name
(eval
  `(fn ~name ~argl
 (let ~(vec
 (mapcat identity
   (apply dissoc lqmap (flatten argl
   `(let ~~(vec (interleave qlocals qgensyms))
  ~~@body))
  {}
  fnspecs)
fnames (set (keys fnmap))
proc (fn proc [form fnames locals]
   (if (or (not (coll? form)) (empty? form))
 form
 (if-not (seq? form)
   (map-ps #(proc % fnames locals) form)
   (let [op (first form)]
 (cond
   (= op 'fn*) (let [nls (mapcat
   (fn [f]
 (if (symbol? f)
   f
   (first f)))
   (rest form))]
 (map
   #(proc %
  (apply disj fnames nls)
  (union locals nls))
   form))
   (or
 (= op 'let*)
 (= op 'loop*)) (let [nls (take-nth 2 (second form))]
  (map
#(proc %
   (apply disj fnames nls)
   (union locals nls))
form))
   (= op 'try) (map-ps
 (fn [subf]
   (if (or
 (not (seq? subf))
 (empty? subf))
 (proc subf fnames locals)
 (condp = (first subf)
   'finally
   (cons 'finally
 (map #(proc % fnames locals)
   (rest subf)))
   'catch
   (if (>= (count subf) 3)
 (conj
   (map
 #(proc %
(disj fnames
  (nth subf 2))
(conj locals
  (nth subf 2)))
 (drop 3 subf))
   (nth subf 2)
   (second subf)
   (first subf))
 (proc subf fnames locals))
   (proc subf fnames locals
 form)
   (contains? fnames op) (proc
   (apply (fnmap op)
 (rest form))
   fnames locals)
   (contains? locals op) (map-ps
   #(proc % fnames locals)
   form)
   :else (let [nested (if (symbol? op)
(if-let [v (ns-resolve *ns* op)]
  (if (.isBound v)
(= @v macrolet-v]
   (if nested
 (proc
   (macroexpand-1
   

Re: Anyone want to take a crack at making the fasta shootout program faster?

[Ken Wesson]

On Thu, Feb 10, 2011 at 7:49 PM, Andy Fingerhut
 wrote:
> I've published that program at the link below.  It contains comments marking
> two lines in the function gen-random-fast where the Hotspot JVM profiler
> tells me that the CPU is spending lots of time in java.lang.Integer.valueOf
> (Clojure 1.2.0).  I can't seem to get rid of these calls to Integer.valueOf
> even after trying about half a dozen different variations of type-hinting.
>  Can anyone else see a way to change the program to avoid those calls?
>
> http://github.com/jafingerhut/clojure-benchmarks/blob/master/fasta/fasta.clj-10.clj

I don't get any reflection warnings with (gen-random-fast) on 1.2. Do you?

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

[Andy Fingerhut]

On Feb 10, 2011, at 6:37 PM, Ken Wesson wrote:


On Thu, Feb 10, 2011 at 7:49 PM, Andy Fingerhut
 wrote:
I've published that program at the link below.  It contains  
comments marking
two lines in the function gen-random-fast where the Hotspot JVM  
profiler
tells me that the CPU is spending lots of time in  
java.lang.Integer.valueOf
(Clojure 1.2.0).  I can't seem to get rid of these calls to  
Integer.valueOf
even after trying about half a dozen different variations of type- 
hinting.
 Can anyone else see a way to change the program to avoid those  
calls?


http://github.com/jafingerhut/clojure-benchmarks/blob/master/fasta/fasta.clj-10.clj


I don't get any reflection warnings with (gen-random-fast) on 1.2.  
Do you?


Nope.  No reflection warnings.  But the profiler does show significant  
amounts of CPU time spent in java.lang.Integer.valueOf.  Maybe it is  
mistaken or misleading output from the profiler, but I'm inclined to  
believe it so far.


Andy


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

Help - .class files and GAE's "too many files" problem

[Edgar Gonçalves]

Hi!

I just realized there's this 3000 files limit we can upload on a WebApp to 
Google's Application Engine (GAE). I also realized more than 2700 of mine 
were .class files generated by clojure. (Which is obvious, once you think of 
how it works). 

Question: how can I delete those classes and make GAE happy with my 
servlet? 
- I tried simply placing a standalone jar with everything, but it complains 
the servlet can't be found. I've yet to find a valid documentation to 
explain this, but I'm exploring the next idea.
- I tried erasing all .classes except the .class generated by the 
(:gen-class...) clause in the servlet file. No use, I'm guessing clojure 
code can only be used from .classes, too? Or am I missing something?

Thanks in advance, all pointers are welcome!

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

[Ken Wesson]

On Thu, Feb 10, 2011 at 9:49 PM, Andy Fingerhut
 wrote:
>
> On Feb 10, 2011, at 6:37 PM, Ken Wesson wrote:
>
>> On Thu, Feb 10, 2011 at 7:49 PM, Andy Fingerhut
>>  wrote:
>>>
>>> I've published that program at the link below.  It contains comments
>>> marking
>>> two lines in the function gen-random-fast where the Hotspot JVM profiler
>>> tells me that the CPU is spending lots of time in
>>> java.lang.Integer.valueOf
>>> (Clojure 1.2.0).  I can't seem to get rid of these calls to
>>> Integer.valueOf
>>> even after trying about half a dozen different variations of
>>> type-hinting.
>>>  Can anyone else see a way to change the program to avoid those calls?
>>>
>>>
>>> http://github.com/jafingerhut/clojure-benchmarks/blob/master/fasta/fasta.clj-10.clj
>>
>> I don't get any reflection warnings with (gen-random-fast) on 1.2. Do you?
>
> Nope.  No reflection warnings.  But the profiler does show significant
> amounts of CPU time spent in java.lang.Integer.valueOf.  Maybe it is
> mistaken or misleading output from the profiler, but I'm inclined to believe
> it so far.

Then you've got boxed primitives, but the Clojure compiler knows what
types they all are...

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

[James Reeves]

On 11 February 2011 02:15, Ken Wesson  wrote:
> (defmacro macrolet* [shadowlist fnspecs & body]
>  (let [locals (keys &env)
>        gensyms (for [_ locals] (gensym))
>        qlocals (map quo (for [_ locals] (gensym)))
>        ...

This macro is huge!!!

You might want something more like:

  (require '[clojure.walk :as walk])

  (defn fnmap [fnspecs]
(zipmap
 (map first fnspecs)
 (for [f fnspecs]
   (cons 'fn (rest f)

  (defn expand-macrolet [macro-fns form]
(if (seq? form)
  (let [[name & args] form]
(if-let [m (macro-fns name)]
  `(eval (~m ~@args))
  form))
  form))

  (defmacro macrolet [fnspecs & body]
`(do ~@(walk/postwalk
(partial expand-macrolet (fnmap fnspecs))
body)))

I'm not sure that does everything you want, but it's probably not far off.

- James

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

Re: Help - .class files and GAE's "too many files" problem

[Edgar Gonçalves]

Just a quick adenda: 
Yes, I can run this on the local machine with all classes in place, and with 
just the .servlet, so the problem should lie within the GAE side, right?

The specific error I get from GAE's logs, if I try to upload only the 
servlet.class and everything else on a jar (along with clojure and 3rd party 
jars), is this:

java.lang.NoClassDefFoundError: Could not initialize class myapp.servlet

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

[SOLVED] Re: Help - .class files and GAE's "too many files" problem

[Edgar Gonçalves]

Ok, there was a hastiness problem from my side, caching or other issue, but 
It's working now...

So for future reference, if you come up with the same issue, the solution is 
to compile your gen'ed-classes and delete all the others from the 
war/WEB-INF directory, making sure you have a standalone jar along the 
remaining used jars (a uberjar may also work, can't see why not). If you 
happen to have a file-size problem on your jars, you can use a flag on the 
upload script. Google for "--enable_jar_splitting" for more details.

Thanks, and sorry for the noise!

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

[CuppoJava]

Your solution with map-ps is quite elegant. I was actually a little
annoyed that I had to deal with different data structures when walking
through Clojure code, as opposed to Lisp/Scheme code.

The doall was necessary for my use-case actually. Some of the macros I
write interact with the environment (ie. they're not side-effect
free). So I had to ensure that macroexpand-all actually *does* run all
the macros appropriately.

  -Patrick

On Feb 10, 6:29 pm, Ken Wesson  wrote:
> On Thu, Feb 10, 2011 at 11:01 AM, CuppoJava  
> wrote:
> > Thanks for all your help everyone!
>
> > So I came up with an elegant solution. It was a combination of
> > Meikel's codwalker solution gave me the idea to bootstrap off of
> > Clojure's macroexpand system to get it to work.
>
> > ;;This is a convenience method for expanding macros. It recursively
> > ;;macroexpands every subform within a form.
> > (defn macroexpand-full [expression]
> >  (let [expanded (macroexpand expression)]
> >    (cond
> >      ;;Normal Form
> >      (or (seq? expanded) (list? expanded))
> >      (doall (map macroexpand-full expanded))
>
> >      ;;Vector Form
> >      (vector? expanded)
> >      (vec (map macroexpand-full expanded))
>
> >      ;;Map Form
> >      (map? expanded)
> >      (into {} (map macroexpand-full expanded))
>
> >      ;;Set Form
> >      (set? expanded)
> >      (into #{} (map macroexpand-full expanded))
>
> >      ;;Atom
> >      :else
> >      expanded)))
>
> What a coincidence. I just had reason to write my own version of this.
>  I came up with a somewhat different approach though:
>
> (defn map-ps [f coll]
>   (if (map? coll)
>     (into (empty coll)
>       (map (fn [[k v]] [(f k) (f v)]) coll))
>     (if (or (vector? coll) (set? coll))
>       (into (empty coll) (map f coll))
>       (map f coll
>
> (defn macroexpand-all [form]
>   (if (coll? form)
>     (let [f (macroexpand form)]
>       (if (coll? f)
>         (map-ps macroexpand-all f)
>         f))
>     form))
>
> The helper function map-ps maps a function over any set, map, vector,
> or seq/list, preserving the type and applying to both keys and values
> of maps. (It should even turn a sorted-set, say, into a sorted-set
> with the same comparator. That may actually work poorly in certain
> cases where the types of the elements are changed. But that's not
> relevant for macroexpand-all. Meanwhile all lists/seqs become
> LazySeq.)
>
> The actual macroexpand-all function exploits macroexpand, as does your
> implementation, but uses map-ps to recursively apply itself to
> subforms.
>
> I didn't bother with doall because typical Clojure code does not nest
> thousands of parentheses deep. :)

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

[Ken Wesson]

On Thu, Feb 10, 2011 at 11:10 PM, CuppoJava  wrote:
> Your solution with map-ps is quite elegant.

Thanks. My implementation of macrolet also uses it. In fact, I wrote
my macroexpand-all as a tool to aid in developing that. It was useful
both for debugging macrolet itself and for testing which "special
forms" are really macros, and what the true special forms are, so I
could identify all of the possible local-name-binding forms post
macroexpansion. (This turns out, apparently, to be:

(let* [name x name x name x] b)

(loop* [name x name x name x] b)

(fn * ([name name name] b) ([name name] b) ...)

(fn * name ([name] b) ...)

(try
  b
  (catch Exception name b)
  (finally b))

where "name" appears in the positions where local names may be bound.
I needed to know all of this because macrolet had to actually
implement its own macro-expansion engine, which in turn needs to
detect when the names of local macros, and macrolet itself, have been
shadowed.)

> I was actually a little annoyed that I had to deal with different data
> structures when walking through Clojure code, as opposed to
> Lisp/Scheme code.

Fortunately that's something you can abstract over.

> The doall was necessary for my use-case actually. Some of the macros I
> write interact with the environment (ie. they're not side-effect
> free).

Ah. Usually it's best for macros to *expand* sometimes into code with
side-effects but avoid *having* side effects directly. I find the
latter an unusual case in my own experience.

> So I had to ensure that macroexpand-all actually *does* run all
> the macros appropriately.

I see.

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

[Andy Fingerhut]

On Feb 10, 2011, at 4:49 PM, Andy Fingerhut wrote:


I've published that program at the link below.  It contains comments  
marking two lines in the function gen-random-fast where the Hotspot  
JVM profiler tells me that the CPU is spending lots of time in  
java.lang.Integer.valueOf (Clojure 1.2.0).  I can't seem to get rid  
of these calls to Integer.valueOf even after trying about half a  
dozen different variations of type-hinting.  Can anyone else see a  
way to change the program to avoid those calls?


http://github.com/jafingerhut/clojure-benchmarks/blob/master/fasta/fasta.clj-10.clj


Here is something a little odd.  I've looked at the disassembly of the  
Java bytecode produced for this Clojure function:


(def random-seed (int-array [42]))
(let [scale (double (/ *lookup-size* 139968))]
  (defn gen-random-fast []
(let [^ints random-seed random-seed
  IM (int 139968)
  IA (int 3877)
  IC (int 29573)
  zero (int 0)
  new-seed (int (unchecked-remainder
 (unchecked-add
  (unchecked-multiply
   (aget random-seed zero) IA) IC) IM))]
  (aset random-seed zero new-seed);; <--- this line produces  
odd Java bytecode

  (int (* new-seed scale)

The marked line produces bytecodes for pushing the args on the stack,  
then calling aset, and then it calls Integer.valueOf to take the int  
returned by aset (which is just the value of new-seed assigned to the  
array element) and convert it to an Integer, then it pops it off the  
stack, discarding that Integer value.  Strange.  Apparently java - 
server was not able to optimize away that wasted work, but I don't yet  
know why the Clojure compiler generated the call in the first place.


The second call to Integer.valueOf() from the last line of the  
function makes sense to me now: the int return value must be boxed  
into an Integer before being returned as the value of function gen- 
random-fast, since all Clojure 1.2 function arguments and returns  
values must be Objects.


Given the wasted bytecode instructions mentioned above, on a hunch I  
decided to assign the return value of aset to a symbol via let -- one  
that is never used again.  This actually produces faster code:



(def random-seed (int-array [42]))
(let [scale (double (/ *lookup-size* 139968))]
  (defn gen-random-fast []
(let [^ints random-seed random-seed
  IM (int 139968)
  IA (int 3877)
  IC (int 29573)
  zero (int 0)
  new-seed (int (unchecked-remainder
 (unchecked-add
  (unchecked-multiply
   (aget random-seed zero) IA) IC) IM))
  throwaway-val (int (aset random-seed zero new-seed))] 
<-- this is the only changed line

  (int (* new-seed scale)


H.  I hope such wasted instructions are rare.

Andy

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

[Sean Corfield]

On Thu, Feb 10, 2011 at 4:27 PM, Eugen Dück  wrote:
> That said, I've contributed to a number of open source projects, none
> of which required anything physical from me, and which wouldn't have
> gotten anything from me had they asked, just because I wouldn't have
> wanted to spend the time on red tape for every single one small patch

FWIW, another open source project I work with a lot (a JBoss community
project based out of Switzerland) just conducted a review of copyright
and license issues and has decided to implement a Contributor's
Agreement pretty much identical to the Clojure / Oracle CA (with the
only exception to the process being that they will allow scanned,
signed CAs to be emailed to the project team).

As noted elsewhere in this thread, written CAs are actually pretty
common in large, successful open source projects...
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

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

[Mike Meyer]

On Thu, 10 Feb 2011 21:57:01 -0800
Sean Corfield  wrote:

> Agreement pretty much identical to the Clojure / Oracle CA (with the
> only exception to the process being that they will allow scanned,
> signed CAs to be emailed to the project team).

That exception is the major issue, assuming you don't have issues with
the terms of the CA.

> As noted elsewhere in this thread, written CAs are actually pretty
> common in large, successful open source projects...

A far more interesting statistic would be how many of those large,
successful open source projects had CAs *before* they were large and
successful.

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

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

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

Re: Any news on pull requests?

[Eugen Dück]

Not that size should matter when it comes to legalistics, but it
appears the already mentioned KDE project, claiming that "the KDE
community is the second largest Free Software community" by most
measures, after the linux kernel, does not seem to have introduced a
CA requirement by now. (From quickly glancing over a bunch of links on
http://techbase.kde.org/Contribute and google, but maybe an active KDE
contributor could verify this)

Apart from them using different licenses than Clojure, which might
have different requirements, if my last post's (completely unfounded)
assumption is right, they would be more constrained in the future when
it comes to changing things related to their licenses.

On Feb 11, 3:00 pm, Mike Meyer  wrote:
> On Thu, 10 Feb 2011 21:57:01 -0800
>
> Sean Corfield  wrote:
> > Agreement pretty much identical to the Clojure / Oracle CA (with the
> > only exception to the process being that they will allow scanned,
> > signed CAs to be emailed to the project team).
>
> That exception is the major issue, assuming you don't have issues with
> the terms of the CA.
>
> > As noted elsewhere in this thread, written CAs are actually pretty
> > common in large, successful open source projects...
>
> A far more interesting statistic would be how many of those large,
> successful open source projects had CAs *before* they were large and
> successful.
>
>          --
> Mike Meyer           http://www.mired.org/consulting.html
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org

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