Re: Declarative Data Models

[David Jagoe]

Hey Stuart,

On 4 May 2011 00:19, Stuart Sierra  wrote:
> No. Clojure template (which I wrote) is a backwards way of doing macros. It
> happens to be useful in clojure.test, but nowhere else.

Thanks that's good to know. While we're on the subject, I'm curious
about cc.apply-macro. Why should it not be used? I got around a
potential use-case by rearranging my macro a bit. Can it have
unintended consequences? It seems like there may be cases where it
would make code easier to understand.


Thanks,
David

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

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

ANN: Java dependency injection in Clojure

[Luc Prefontaine]

Hi,

being tired of wandering through a few thousand lines of XML Spring bean 
definitions, I finally wrote a library
to start moving away from Spring/XML. It's definitively nicer doing dependency 
injection/auto-wiring using Clojure.

This is part of our global effort here to confine Java as much as possible to 
lower layers. 

Lacking imagination (or being lazy ?), I called it boing. The source code is 
available at https://github.com/lprefontaine/Boing
and the Wiki there describes its scope and capabilities.

It's a 1.0 version. It should make it to prod beginning of this summer.

The jar is on Clojars ([org.clojars.lprefontaine/boing "1.0"] in leiningen).

It may be of interest to people having mixed environments and potentially to 
some using external Java libraries.
It's much more dynamic than XML and significantly shorter. Look at the examples 
folder.

Comments are welcomed. The TODO list is not yet published but we see a few 
things we want to add to it especially
in the area of resource management and some optimizations.

Code wise I think it's not too horrible given that I had to squeeze this in my 
already ultra-tight schedule in
the last three weeks or so.

-- 
Luc P.


The rabid Muppet

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Sean Corfield]

On Tue, May 3, 2011 at 4:39 PM, Chas Emerick  wrote:
> That's interesting; I very intentionally built in "proper" support for 
> browser back/forward actions (as you discovered), thinking that that would be 
> a good local maxima in terms of history navigation.

I guess I could get used to splat-[ / splat-] as the hot keys for that
(RockMelt on Mac OS X).

> FWIW, click-and-hold on the back or forward buttons in your browser will give 
>you the "breadcrumbs" you're looking for.

Hmm... that means taking the mouse out of the atlas and interacting
with the chrome of its surroundings...

> I'd like to plumb at this up/down notion a bit.  Perhaps it's not clear, but 
> the ontology is not a hierarchy – there absolutely are cycles in its graph.  
> For example:
>
> http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/isa?
>
> Which way is "up" (or "down") from isa? here?

It was more relative to the browser history. I start at Clojure, I go
off exploring, I find myself on some node with no obvious direct edge
to something I was looking at before. If I could hit 'up' and go back
in the history to the last thing connected to what I'm focused on...

Maybe I just need to spend more time with it and just get used to the
way it works now...

> As you say, 1.2.0 contrib is large, but "new contrib" is likely to get much, 
> much larger (presumably larger than the standard library) since contributing 
> to it is far easier than classic contrb.

Really? I thought "new contrib" was more tightly controlled and
subject to more Clojure/core approval. Mind you, we had ~60 old
contrib libraries and we already have close to 30 new contrib
libraries so you may well be right...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

Re: Monadic implementation of the Shunting-yard algorithm

[Nicolas Buduroi]

I've refactored your code into this: https://gist.github.com/954579

On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote:
>
> I wrote a simple implementation: 
> http://gist.github.com/953966
> (only supports operators)
> It's not very elegant (I don't know how to use fnparse..), but it is 
> functional. 
> What it does is find out what the next element in the operator stack and 
> the out stack should be, and then recursively update the stacks and output 
> the finished out stack.
>
> As I said I don't know how to use fnparse and therefore I couldn't really 
> understand your code.
> Either way I hope that this code helps in some way.. ;) 
>
> Jonathan
>
> On Tue, May 3, 2011 at 2:23 AM, Nicolas Buduroi  wrote:
>
>> Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written 
>> the following implementation of the Shunting-yard algorithm:
>>
>> https://gist.github.com/952607
>>
>> I plan to make a lightning talk about monadic parser at the next Bonjure 
>> meeting and I'd like to hear what people here think about that 
>> implementation first.
>>
>> It is more imperative that I would like, but that is the nature of this 
>> algorithm I think. Would a non-monadic implementation would be better in 
>> some ways? How would you make this code more flexible, faster and/or 
>> cleaner? Is there a more functional way of writing it?
>>
>> Thanks in advance for any comments!
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>

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

Optimizing my function for performance

[Bhinderwala, Shoeb]

This is related to my multi-level bucketing problem which I am starting
new thread. 

The code is at:

   https://gist.github.com/952861

I am referring to the sum-by function which was provided by fellow
clojurer in this group. It choked when I passed in data of size one
million - meaning I didn't run out of memory but it took a very long
time. 

Quoting below are two functions from my code:

(def data (take 100 (repeatedly get-rec)))

;get aggregate values for list of attributes
(defn sum-by [data attrs]
  (let [aggregated (group-by (apply juxt attrs) data)]
(zipmap (keys aggregated) (map #(reduce + (map :mv %)) (vals
aggregated)

;invoke sum-by
(sum-by data [:attr1 :attr2])

Are there any obvious performance optimizations (e.g. transient, etc)
that can be performed so that the function can perform better and
consume less memory? In general what are the things to watch out for
when writing functions such as these so as not to get poor performance
with very large data sets.

Thanks for your help.

-- Shoeb

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[pmbauer]

ALT-<[LEFT|RIGHT] ARROW> - nav back/forward
I was very pleased to have proper browsing history support - great way
to do breadcrumbs.

P.S.
When I started learning clojure a year ago, one of the biggest pain
points was not having a resource like this.
Dynamic languages, in general, and clojure, in particular, lack the
self-documenting relational ontology that static language jocks take
for granted.
It's difficult to quickly find relationships (e.g. find all the
functions that operate on ISeq or Seqable); having half of Clojure
implemented in Clojure and the other half in Java doesn't make it easy
to automate this navigation with tools either.

Major kudos on this.

On May 3, 4:39 pm, Chas Emerick  wrote:
> On May 3, 2011, at 6:06 PM, Sean Corfield wrote:
>
> > It's a very cool way to visualize the Clojure world and to explore
> > what's available. One thing I found - which would definitely stop me
> > paying for it as-is - I get lost when I drill down: there's no way to
> > navigate 'back' to what I was looking at and no sense of history (like
> > a crumb trail). Messing around with the demo I just realized I can use
> > the browser back button / hot key but that feels clunky - being able
> > to navigate more easily with keyboard shortcuts within the atlas
> > itself would make it a lot nicer to use. Perhaps left arrow / right
> > arrow to go back / forward thru the direct history and up arrow / down
> > arrow to jump up and down the hierarchy?
>
> That's interesting; I very intentionally built in "proper" support for 
> browser back/forward actions (as you discovered), thinking that that would be 
> a good local maxima in terms of history navigation.  FWIW, click-and-hold on 
> the back or forward buttons in your browser will give you the "breadcrumbs" 
> you're looking for.
>
> I'm not entirely convinced that left/right shortcuts would make sense — that 
> would simply map to back/forward in the browser, which already have keyboard 
> shortcuts.  I'll think about it for a bit.
>
> I'd like to plumb at this up/down notion a bit.  Perhaps it's not clear, but 
> the ontology is not a hierarchy – there absolutely are cycles in its graph.  
> For example:
>
> http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure...
>
> Which way is "up" (or "down") from isa? here?
>
> > It doesn't appear to include any of the contrib libraries (I know
> > that's a mammoth task for 1.2.0). Do you plan to include the new
> > contrib libraries in 1.3.0 since they seem more "integrated" now?
>
> I hope that Clojure Atlas will include contrib libraries in the future, 
> though I can't imagine I'll be building the ontologies for them.  As you say, 
> 1.2.0 contrib is large, but "new contrib" is likely to get much, much larger 
> (presumably larger than the standard library) since contributing to it is far 
> easier than classic contrb.  I'm thinking about various ways to allow for 
> community-constructed ontologies for various libraries, including contrib of 
> all versions.
>
> - Chas

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Chas Emerick]

On May 3, 2011, at 6:29 PM, Sean Corfield wrote:

> On Tue, May 3, 2011 at 3:06 PM, Sean Corfield  wrote:
>> It doesn't appear to include any of the contrib libraries (I know
>> that's a mammoth task for 1.2.0). Do you plan to include the new
>> contrib libraries in 1.3.0 since they seem more "integrated" now?
> 
> I also could not find: try/catch/finally/throw, do, if, quote... Are
> these known "missing" special forms?

Indeed; all of the special forms in the ontology right now are linked from:

http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#concept/special-forms

As I say at http://www.clojureatlas.com/#status, I'm far from done. :-)

BTW, thanks for the earlier feedback,

- Chas

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Chas Emerick]

On May 3, 2011, at 6:06 PM, Sean Corfield wrote:

> It's a very cool way to visualize the Clojure world and to explore
> what's available. One thing I found - which would definitely stop me
> paying for it as-is - I get lost when I drill down: there's no way to
> navigate 'back' to what I was looking at and no sense of history (like
> a crumb trail). Messing around with the demo I just realized I can use
> the browser back button / hot key but that feels clunky - being able
> to navigate more easily with keyboard shortcuts within the atlas
> itself would make it a lot nicer to use. Perhaps left arrow / right
> arrow to go back / forward thru the direct history and up arrow / down
> arrow to jump up and down the hierarchy?

That's interesting; I very intentionally built in "proper" support for browser 
back/forward actions (as you discovered), thinking that that would be a good 
local maxima in terms of history navigation.  FWIW, click-and-hold on the back 
or forward buttons in your browser will give you the "breadcrumbs" you're 
looking for.

I'm not entirely convinced that left/right shortcuts would make sense — that 
would simply map to back/forward in the browser, which already have keyboard 
shortcuts.  I'll think about it for a bit.

I'd like to plumb at this up/down notion a bit.  Perhaps it's not clear, but 
the ontology is not a hierarchy – there absolutely are cycles in its graph.  
For example:

http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/isa?

Which way is "up" (or "down") from isa? here?

> It doesn't appear to include any of the contrib libraries (I know
> that's a mammoth task for 1.2.0). Do you plan to include the new
> contrib libraries in 1.3.0 since they seem more "integrated" now?

I hope that Clojure Atlas will include contrib libraries in the future, though 
I can't imagine I'll be building the ontologies for them.  As you say, 1.2.0 
contrib is large, but "new contrib" is likely to get much, much larger 
(presumably larger than the standard library) since contributing to it is far 
easier than classic contrb.  I'm thinking about various ways to allow for 
community-constructed ontologies for various libraries, including contrib of 
all versions.

- Chas

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

Re: Closures in macros

[Chris Perkins]

On May 3, 5:22 pm, André Thieme  wrote:
> Some of the limitations:
> 1. (defmacro x [] `(let [a# ~(atom 0)]))
>
> 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link
>
> 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)]))
>
> All three calls fail, (x) and (y) and (z).
> I see no plausible reason why it *should* be that way.

I do - because most of the time, embedding an object in code is
accidental, caused by messing up the quoting and unquoting. I would
prefer that evaling something that cannot be produced by the reader be
an error.

I can see that in some cases, having eval pass unexpected types
through unchanged can be useful, but I think it would be much more
common for it to result in hard-to-debug errors, especially for
beginning macro writers.

- Chris Perkins

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

[Nicolas Buduroi]

One small question, how would you modify your version to output 
s-expressions?

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

[Nicolas Buduroi]

On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote:
>
> I wrote a simple implementation: 
> http://gist.github.com/953966
> (only supports operators)
> It's not very elegant (I don't know how to use fnparse..), but it is 
> functional. 
> What it does is find out what the next element in the operator stack and 
> the out stack should be, and then recursively update the stacks and output 
> the finished out stack.
>
> As I said I don't know how to use fnparse and therefore I couldn't really 
> understand your code.
> Either way I hope that this code helps in some way.. ;)
>

This is great, hadn't thought about using a protocol for this!

I'll improve both versions to be able to compare them on equal ground and to 
see how they cope with adding more features. Although in the end, I think 
the recursive one will be faster while the monadic one will be more 
composable,

 Thanks

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Sean Corfield]

On Tue, May 3, 2011 at 3:06 PM, Sean Corfield  wrote:
> It doesn't appear to include any of the contrib libraries (I know
> that's a mammoth task for 1.2.0). Do you plan to include the new
> contrib libraries in 1.3.0 since they seem more "integrated" now?

I also could not find: try/catch/finally/throw, do, if, quote... Are
these known "missing" special forms?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

Re: Declarative Data Models

[Stuart Sierra]

No. Clojure template (which I wrote) is a backwards way of doing macros. It 
happens to be useful in clojure.test, but nowhere else.

-Stuart S
clojure.com

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

Re: Any wisdom in the math speed of different clojure libraries?

[Stuart Sierra]

Anything implemented with multimethods (contrib.generic) will be slow 
compared to primitives and Java methods invoked on primitives.  Also try out 
the better primitive math ops in the 1.3.0-alphas.

-Stuart
clojure.com

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Sean Corfield]

On Tue, May 3, 2011 at 11:34 AM, Chas Emerick  wrote:
> I've previously linked[1] to my preview of Clojure Atlas – my attempt at
> producing a more useful, more tractable medium for understanding programming
> languages and the libraries that go along with them – so I won't repeat that
> material here.  I did think I'd let the list know that Clojure Atlas is now
> available publicly however:
> http://clojureatlas.com

It's a very cool way to visualize the Clojure world and to explore
what's available. One thing I found - which would definitely stop me
paying for it as-is - I get lost when I drill down: there's no way to
navigate 'back' to what I was looking at and no sense of history (like
a crumb trail). Messing around with the demo I just realized I can use
the browser back button / hot key but that feels clunky - being able
to navigate more easily with keyboard shortcuts within the atlas
itself would make it a lot nicer to use. Perhaps left arrow / right
arrow to go back / forward thru the direct history and up arrow / down
arrow to jump up and down the hierarchy?

It doesn't appear to include any of the contrib libraries (I know
that's a mammoth task for 1.2.0). Do you plan to include the new
contrib libraries in 1.3.0 since they seem more "integrated" now?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

Re: resultset-seq

[Allen Johnson]

IMHO c.j.j/resultset-seq should perform something like the following:

;; i want my columns as strings exactly how they are in the db
(resultset-seq rs)
(resultset-seq rs identity)

;; i want my columns as lower-case keywords
(resultset-seq rs (comp keyword lower-case))

;; i want my columns as upper-case symbols
(resultset-seq rs (comp symbol upper-case))

With the existing c.c/resultset-seq, I found myself converting the
keys back to strings in order to pass those results to some existing
Java code and templates for further processing. Most of the time the
lower-cased keyword keys were just fine.

Just my $0.02
Allen

On Tue, May 3, 2011 at 4:54 PM, Sean Corfield  wrote:
> Since this thread from October focused on clojure.core/resultset-seq,
> I thought I'd bump it again in the context of the (new)
> clojure.java.jdbc library (formerly clojure.contrib.sql).
>
> In order to support naming strategies, c.j.j uses an internal,
> modified copy of resultset-seq that allows you to control the way SQL
> entity names are converted to keywords. The default is still
> clojure.string/lower-case but you can override the behavior for calls
> to c.j.j. Naming strategies also allow you to control how keywords are
> converted to SQL entity names within c.j.j.
>
> I'm undecided on whether to expose this function (it's currently
> clojure.java.jdbc.internal/resultset-seq*) as part of the public API
> for c.j.j. In favor of exposing it: it would provide a way to get the
> behavior most people in this thread seem to want. Against exposing it:
> potential confusion with the version in clojure.core?
>
> This is the only decision I want to tie up before declaring a 0.0.1
> release of c.j.j (and moving on to other requested enhancements for
> 0.0.2).
>
> If anyone has any input...?
>
> Sean
>
> On Fri, Oct 15, 2010 at 2:04 PM, Laurent PETIT  
> wrote:
>>
>>
>> 2010/10/15 Mark Engelberg 
>>>
>>> On Fri, Oct 15, 2010 at 1:49 AM, David Powell 
>>> wrote:
>>> > I'm in favour of down-casing - at least by default.  Some processing is
>>> > going to happen anyway, as column names might contain spaces, which 
>>> > wouldn't
>>> > be allowed in keywords.
>>> >
>>> > --
>>> > Dave
>>>
>>> One of the more significant nuisances in Clojure/Java interop is that
>>> if you use some sort of wrapper library which converts Clojure things
>>> to Java, and then converts from Java back to Clojure, you often end up
>>> with something different than you started.  Anywhere we can ameliorate
>>> this, we should.
>>>
>>> For example, if I create a table using clojure.contrib.sql, where the
>>> column names are things like :numberOfApples, and then I load in a
>>> bunch of maps of the form {:numberOfApples 2}, {:numberOfApples 5},
>>> and so on, then when I fetch them out of the database, I really need
>>> them to be {:numberOfApples 2}, etc. so that I can compare them with
>>> the original maps used to fill the database to begin with.
>>>
>>> Right now, I get back {:numberofapples 2}.  Yes, SQL is usually case
>>> insensitive, but Clojure is not, so everything breaks down if you
>>> don't get back the maps in the form you started with.  Since SQL
>>> typically *stores* the column names internally in mixed case (even
>>> though it ignores the case for querying purposes), you might as well
>>> retrieve them in mixed case so it matches the form you started with.
>>>
>>> Why would I write my column names using mixed case?  Because I once
>>> tried using :number-of-apples to match Clojure's conventions, but got
>>> burned by a number of third-party tools gagging on the hyphens.
>>>
>>
>> I guess most of the time column names are written with
>> names_separated_by_underscores, but anyway, it seems indeed weird that such
>> downcase is done, especially without any (or to come) good reason for that.
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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: which is the location for the latest data.finger-tree?

[Stuart Sierra]

Yes, that is the latest source.

One JAR has been released to the Maven Central Repository:
http://repo2.maven.org/maven2/org/clojure/data.finger-tree/0.0.1/

-Stuart S
clojure.com

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

which is the location for the latest data.finger-tree?

[Sunil S Nandihalli]

Hello everybody,
 Can somebody tell me as to which is the location for the current version
 of data.finger-tree .. the one I found via google was
git://github.com/clojure/data.finger-tree.git

Thanks,
Sunil..

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

[André Thieme]

Am 02.05.2011 23:14, schrieb David Nolen:


The relevant clojure-dev thread.
http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907ebca8ef6e11

It's not clear whether the core team and the various contributors are
interested in supporting the behavior you want. It's also not clear
whether the issue is matter of the difficulty of a good implementation
or simply disinterest.


Thanks for that link. I would really like to hear (read) a statement of
one member of the core team.
Some of the limitations:
1. (defmacro x [] `(let [a# ~(atom 0)]))

2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link

3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)]))

All three calls fail, (x) and (y) and (z).
I see no plausible reason why it *should* be that way.
Instead this is useful and idiomatic lisp.

Normally I wanted to write:
`(~(get @loggers level @logger)
  ~(get *level-name* level)
  ~domain ~msg ~e)

The first get will see if for the given “level” there is a level
specific log function. If not it will fall back to the default logger
“logger”. So, “loggers” is a mapping from level to closures and
“logger” is a closure. Those closures are functions that take 4 args:
the log level, a domain, a message and an exception.

Now I have to write instead
(let [l (get @loggers level @logger)
  f (gensym "logger")]
  (intern 'mylib.log f l)
  `(~f ~(get *level-name* level) ~domain ~msg ~e))

which is plain ugly. I need to artificially invent a name, pollute the
NS of my logging lib and probably create less efficient code, because
a lookup of my gensymed ~f will be required at runtime.
Would be great if this could be fixed easily enough to get included in
a (near) future version.


Regards,
André

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

[Sean Corfield]

Since this thread from October focused on clojure.core/resultset-seq,
I thought I'd bump it again in the context of the (new)
clojure.java.jdbc library (formerly clojure.contrib.sql).

In order to support naming strategies, c.j.j uses an internal,
modified copy of resultset-seq that allows you to control the way SQL
entity names are converted to keywords. The default is still
clojure.string/lower-case but you can override the behavior for calls
to c.j.j. Naming strategies also allow you to control how keywords are
converted to SQL entity names within c.j.j.

I'm undecided on whether to expose this function (it's currently
clojure.java.jdbc.internal/resultset-seq*) as part of the public API
for c.j.j. In favor of exposing it: it would provide a way to get the
behavior most people in this thread seem to want. Against exposing it:
potential confusion with the version in clojure.core?

This is the only decision I want to tie up before declaring a 0.0.1
release of c.j.j (and moving on to other requested enhancements for
0.0.2).

If anyone has any input...?

Sean

On Fri, Oct 15, 2010 at 2:04 PM, Laurent PETIT  wrote:
>
>
> 2010/10/15 Mark Engelberg 
>>
>> On Fri, Oct 15, 2010 at 1:49 AM, David Powell 
>> wrote:
>> > I'm in favour of down-casing - at least by default.  Some processing is
>> > going to happen anyway, as column names might contain spaces, which 
>> > wouldn't
>> > be allowed in keywords.
>> >
>> > --
>> > Dave
>>
>> One of the more significant nuisances in Clojure/Java interop is that
>> if you use some sort of wrapper library which converts Clojure things
>> to Java, and then converts from Java back to Clojure, you often end up
>> with something different than you started.  Anywhere we can ameliorate
>> this, we should.
>>
>> For example, if I create a table using clojure.contrib.sql, where the
>> column names are things like :numberOfApples, and then I load in a
>> bunch of maps of the form {:numberOfApples 2}, {:numberOfApples 5},
>> and so on, then when I fetch them out of the database, I really need
>> them to be {:numberOfApples 2}, etc. so that I can compare them with
>> the original maps used to fill the database to begin with.
>>
>> Right now, I get back {:numberofapples 2}.  Yes, SQL is usually case
>> insensitive, but Clojure is not, so everything breaks down if you
>> don't get back the maps in the form you started with.  Since SQL
>> typically *stores* the column names internally in mixed case (even
>> though it ignores the case for querying purposes), you might as well
>> retrieve them in mixed case so it matches the form you started with.
>>
>> Why would I write my column names using mixed case?  Because I once
>> tried using :number-of-apples to match Clojure's conventions, but got
>> burned by a number of third-party tools gagging on the hyphens.
>>
>
> I guess most of the time column names are written with
> names_separated_by_underscores, but anyway, it seems indeed weird that such
> downcase is done, especially without any (or to come) good reason for that.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Jeffrey Schwab]

On Tuesday, May 3, 2011 3:31:33 PM UTC-4, tbc++ wrote:
>
>
> On Tue, May 3, 2011 at 2:28 PM, Jeffrey Schwab wrote:
>
>> Boo.  Keep the paywall.  Don't make me look at ads.  And for the record, 
>> you're not paying for information, but rather to have the information 
>> presented in a particular way.
>>
>>
> Well I think it's more of the case that with a paywall you'll get a very 
> small number of people generating income. With ads every user could be 
> generating ads. I don't know how many programs I don't use simply because 
> it's a cool program but not $20 cool... From a business standpoint one as to 
> ask if program X that costs Y will save developers Y worth of work.
>

Maybe the best model is: Ads by default, or pay your way out of them.  /. 
has a nice implementation of this, where you can fine-tune the frequency 
with which you see ads.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Chas Emerick]

On May 3, 2011, at 3:28 PM, Jeffrey Schwab wrote:

> Boo.  Keep the paywall.  Don't make me look at ads.  And for the record, 
> you're not paying for information, but rather to have the information 
> presented in a particular way.

No worries, I've zero intention of using advertising of any sort.  Besides it 
being a pitiful source of actual revenue except in very specific circumstances, 
I'd much rather optimize to make the product more useful for its users, rather 
than compromising it in various ways in the hopes of earning 5¢ from Google.

- Chas

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Timothy Baldridge]

On Tue, May 3, 2011 at 2:28 PM, Jeffrey Schwab wrote:

> Boo.  Keep the paywall.  Don't make me look at ads.  And for the record,
> you're not paying for information, but rather to have the information
> presented in a particular way.
>
>
Well I think it's more of the case that with a paywall you'll get a very
small number of people generating income. With ads every user could be
generating ads. I don't know how many programs I don't use simply because
it's a cool program but not $20 cool... From a business standpoint one as to
ask if program X that costs Y will save developers Y worth of work.


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

Re: Any wisdom in the math speed of different clojure libraries?

[Jeffrey Schwab]

On Tuesday, May 3, 2011 3:20:25 PM UTC-4, David Nolen wrote:
>
> On Tue, May 3, 2011 at 2:51 PM, Ken Wesson  wrote:
>
>> It's optimizing your loop away, or else you're using ridiculously
>> powerful hardware.
>>
>> user=> (time (dotimes [_ 100] (Math/ceil (rand
>> "Elapsed time: 142.86748 msecs"
>> nil
>
>
> Maybe, maybe not: 
>

Either way, it's got a weird profile (increasing, but not monotonically):

user=> (doseq [n (map #(Math/pow 10 %) (range 10))] (time (dotimes [_ n] 
(Math/ceil 0.1
"Elapsed time: 0.238077 msecs"
"Elapsed time: 0.007346 msecs"
"Elapsed time: 0.030386 msecs"
"Elapsed time: 0.255107 msecs"
"Elapsed time: 10.399609 msecs"
"Elapsed time: 5.677462 msecs"
"Elapsed time: 1.423789 msecs"
"Elapsed time: 9.779539 msecs"
"Elapsed time: 65.505686 msecs"
"Elapsed time: 651.333768 msecs"
nil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Chas Emerick]

On May 3, 2011, at 3:15 PM, Timothy Baldridge wrote:

> > There is a free (nagging) demo, but I assure you kittens will purr just for
> > you if you support Clojure Atlas' future development with your purchase.
> 
> You know it's nice, the search is pretty cool. But it takes me longer to go 
> and search, or to chase little (i) symbols around than it does to actually go 
> to the repl and hit (doc assoc). Maybe it's just too much eye candy for my 
> liking. 

Check out the 'help' link in the upper-right; you can hold down Ctrl while 
scrubbing over nodes to see docs, source, etc.

Indeed, if you're just after (doc foo) for some known foo, Clojure Atlas has 
little to offer.  The hope is that this will make it easier to (a) find an 
unknown bar that is relevant to the operation/data structure/etc you're working 
with, and (b) understand the relationships between different types, data 
structures, classes of operations, etc.

And, yes, the "overanimated" quality of the visualization is the #1-reported 
problem so far.  I've prioritized it appropriately.

Thanks for the feedback,

- Chas

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Laurent PETIT]

This is awesome job, Chas, thanks for creating this!

2011/5/3 Chas Emerick 

> I've previously linked[1] to my preview of Clojure Atlas – my attempt at
> producing a more useful, more tractable medium for understanding programming
> languages and the libraries that go along with them – so I won't repeat
> that material here.  I did think I'd let the list know that Clojure Atlas is
> now available publicly however:
>
> http://clojureatlas.com
>
> And a few comments on its release are available on my blog[2].
>
> There is a free (nagging) demo, but I assure you kittens will purr just for
> you if you support Clojure Atlas' future development with your purchase.
>  FYI, you can currently get $10 off of Clojure Atlas for Clojure 1.3 when
> you preorder it now with your 1.2 purchase[3].
>
> I suspect I'll not clutter up the ML with further announcements (though
> I'll happily answer questions, if any are posed), so make sure you follow
> @ClojureAtlas[4] or subscribe to updates by email[5] if you'd like to be
> notified as Clojure Atlas is expanded and improved.
>
> Thanks,
>
> - Chas
>
> [1]
> http://groups.google.com/group/clojure/browse_thread/thread/3b8e2eaed664e3ca
> [2] http://cemerick.com/2011/05/03/clojure-atlas-now-available/
> [3] http://clojureatlas.com/buy
> [4] http://twitter.com/ClojureAtlas
> [5] http://www.clojureatlas.com/#status
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Jeffrey Schwab]

Boo.  Keep the paywall.  Don't make me look at ads.  And for the record, 
you're not paying for information, but rather to have the information 
presented in a particular way.

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

[David Nolen]

On Tue, May 3, 2011 at 2:51 PM, Ken Wesson  wrote:

> It's optimizing your loop away, or else you're using ridiculously
> powerful hardware.
>
> user=> (time (dotimes [_ 100] (Math/ceil (rand
> "Elapsed time: 142.86748 msecs"
> nil


Maybe, maybe not:

(do
  (set! *unchecked-math* true)
  (let [nums (double-array (repeatedly 1e3 rand))]
(dotimes [_ 10]
  (time
   (dotimes [i 1e8] (Math/ceil (double (aget nums (rem i 1e3)
"Elapsed time: 1405.835 msecs"

(do
  (set! *unchecked-math* true)
  (let [nums (double-array (repeatedly 1e3 rand))]
(dotimes [_ 10]
  (time
   (dotimes [i 1e8] (double (aget nums (rem i 1e3
"Elapsed time: 1409.305 msecs"

Given that the i7 is far into the gigaflops territory, I don't find this
particularly surprising. But I'm not a hardware architecture expert by any
means nor an expert of what kind of magic the JVM can do.

David

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Ken Wesson]

On Tue, May 3, 2011 at 3:15 PM, Timothy Baldridge  wrote:
>> There is a free (nagging) demo, but I assure you kittens will purr just
>> for
>> you if you support Clojure Atlas' future development with your purchase.
>
> You know it's nice, the search is pretty cool. But it takes me longer to go
> and search, or to chase little (i) symbols around than it does to actually
> go to the repl and hit (doc assoc).

Not to mention that (doc assoc) is free. :)

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

[Ken Wesson]

On Mon, May 2, 2011 at 8:23 PM, Nicolas Buduroi  wrote:
> Is there a more functional way of writing it?

If you have imperative code implementing a conceptually-pure function,
the answer to this is always "yes", in at least a trivial sense: you
can write a pure-functional interpreter for the imperative code's
language that that is something like

(defn step [world-state]
  (apply-instruction
(get-next-instruction world-state)
world-state))

(defn run [program & arg-list]
  (let [world-state (initial-state-for program arg-list)]
(extract-output-from
  (first
(drop-while
  #(not (done-state? %))
  (iterate step world-state))

Here, get-next-instruction figures out what instruction to apply next
from a world-state (e.g. it reads a program counter and then an opcode
from an address); apply-instruction applies an instruction to a
world-state to output a new world-state; initial-state-for? takes an
imperative function and an argument list and returns an initial
world-state for executing it in the virtual machine; done-state?
checks if a world-state represents an imperative function that's
finished running rather than still running; and extract-output-from
extracts the return value of that program. If all of those are pure
functions, then so is run.

But I expect most who ask "is there a more functional way of writing
it?" are hoping for something less trivial. :)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Timothy Baldridge]

> There is a free (nagging) demo, but I assure you kittens will purr just
for
> you if you support Clojure Atlas' future development with your purchase.

You know it's nice, the search is pretty cool. But it takes me longer to go
and search, or to chase little (i) symbols around than it does to actually
go to the repl and hit (doc assoc). Maybe it's just too much eye candy for
my liking.

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

Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)

[Ken Wesson]

On Tue, May 3, 2011 at 2:34 PM, Chas Emerick  wrote:
> There is a free (nagging) demo, but I assure you kittens will purr just for
> you if you support Clojure Atlas' future development with your purchase.

You've put this thing behind a *paywall*? It's *information*. If you
really want to monetize it you'll probably get far more by having it
freely and easily accessible, so lots of people will link into it, and
putting AdSense on every 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: Monadic implementation of the Shunting-yard algorithm

[Jonathan Fischer Friberg]

I wrote a simple implementation:
http://gist.github.com/953966
(only supports operators)
It's not very elegant (I don't know how to use fnparse..), but it is
functional.
What it does is find out what the next element in the operator stack and the
out stack should be, and then recursively update the stacks and output the
finished out stack.

As I said I don't know how to use fnparse and therefore I couldn't really
understand your code.
Either way I hope that this code helps in some way.. ;)

Jonathan

On Tue, May 3, 2011 at 2:23 AM, Nicolas Buduroi  wrote:

> Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written
> the following implementation of the Shunting-yard algorithm:
>
> https://gist.github.com/952607
>
> I plan to make a lightning talk about monadic parser at the next Bonjure
> meeting and I'd like to hear what people here think about that
> implementation first.
>
> It is more imperative that I would like, but that is the nature of this
> algorithm I think. Would a non-monadic implementation would be better in
> some ways? How would you make this code more flexible, faster and/or
> cleaner? Is there a more functional way of writing it?
>
> Thanks in advance for any comments!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?

[Ken Wesson]

On Tue, May 3, 2011 at 8:03 AM, David Nolen  wrote:
> Why not?
> user> (time (dotimes [_ 10] (Math/ceil 0.1)))
> "Elapsed time: 626.867 msecs"
> David

It's optimizing your loop away, or else you're using ridiculously
powerful hardware.

user=> (time (dotimes [_ 100] (Math/ceil (rand
"Elapsed time: 142.86748 msecs"
nil

Making it a local of type "double" seems slightly faster:

user=> (time (dotimes [_ 100] (let [x (double (rand))] (Math/ceil x
"Elapsed time: 136.96752 msecs"
nil

But to really time a "ceil" function we should have premade random
numbers and avoid including their generation in the time. We'll also
get rid of some boxing and function call overheads:

user=> (let [nums (double-array (repeatedly 100 rand))]
  (time
(dotimes [i 100] (Math/ceil (aget nums i)
"Elapsed time: 47.99892 msecs"
nil

Now the only things in the timing loop are: counting to 1 million,
aget from a primitive array, and Math/ceil itself. That's about as
good as it's gonna get.

Substitute calls to other ceil implementations as appropriate.

Oh, and by the way, (int x) is not quite floor either:

user=> (int -2.1)
-2

It truncates towards 0 rather than -infinity.

#(quot % 1) does the same thing (and is slower by nearly a factor of 10).

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

[Ken Wesson]

You had:

(defmacro eval-cached [obj]
  (when-not (contains? @cache obj)
(reset! cache (assoc @cache obj (eval obj
  (@cache obj))

and:

(eval-cached fbody)

This results in eval-cached being called with obj bound to the symbol
'fbody rather than to the second argument to def-cached -- probably
not what you intended. It checks the cache for containing a value at
the key 'fbody, fails, and so goes to create the entry -- and calls
(eval 'fbody), rather than (eval the-code-you-passed-to-def-cached).

You really did need a function and not a macro for eval-cached.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language & standard library)

[Chas Emerick]

I've previously linked[1] to my preview of Clojure Atlas – my attempt at 
producing a more useful, more tractable medium for understanding programming 
languages and the libraries that go along with them – so I won't repeat that 
material here.  I did think I'd let the list know that Clojure Atlas is now 
available publicly however:

http://clojureatlas.com

And a few comments on its release are available on my blog[2].

There is a free (nagging) demo, but I assure you kittens will purr just for you 
if you support Clojure Atlas' future development with your purchase.  FYI, you 
can currently get $10 off of Clojure Atlas for Clojure 1.3 when you preorder it 
now with your 1.2 purchase[3].

I suspect I'll not clutter up the ML with further announcements (though I'll 
happily answer questions, if any are posed), so make sure you follow 
@ClojureAtlas[4] or subscribe to updates by email[5] if you'd like to be 
notified as Clojure Atlas is expanded and improved.

Thanks,

- Chas

[1] http://groups.google.com/group/clojure/browse_thread/thread/3b8e2eaed664e3ca
[2] http://cemerick.com/2011/05/03/clojure-atlas-now-available/
[3] http://clojureatlas.com/buy
[4] http://twitter.com/ClojureAtlas
[5] http://www.clojureatlas.com/#status

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

Re: [ANN] Lacij v.0.1 a graph visualization library

[Ambrose Bonnaire-Sergeant]

Hi Pierre

This looks very cool, I'd love to try it.

The version on clojars is 0.1.0-SNAPSHOT, could you upload 0.1.0?

How do you build it from source? I can't locate a build script.

Thanks,
Ambrose

On Tue, May 3, 2011 at 9:26 PM, Pierre Allix <
pierre.allix.w...@googlemail.com> wrote:

> Hello,
>
> I would like to announce the version 0.1 of the Lacij library,
> a graph visualization library written in Clojure.
>
> I would be really happy with any feedbacks and comments, on the code
> or the architecture. Help is welcome to implement additional layout
> algorithms.
>
>
> From the README file:
>
> Lacij is a graph visualization library written in Clojure. It allows
> the display
> and the dynamic modification of graphs as SVG documents that can be
> viewed
> with a Web browser or with a Swing component. Undo/redo is supported
> for the
> dynamic modification. Automatic layout is provided for the
> visualization.
> The library is available on GitHub:
>
> https://github.com/pallix/lacij
>
> and on Clojars:
>
> http://clojars.org/lacij
>
> This library is being developed as part of the Carneades project:
>
> http://carneades.berlios.de/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Key order of literal maps

[David Jagoe]

Thanks for the responses.

On 3 May 2011 17:39, Steve Miner  wrote:
>
> On May 3, 2011, at 7:08 AM, David Jagoe wrote:
>
> For your specific purpose, I would be careful about using a map as an 
> "entity" specification. If the order is significant, a vector of field 
> specifiers would be better.  Instead of taking a map as the second argument 
> to defentity, you could make it variadic like (defmacro defentity [ent & 
> specs] ...).

Yes, that looks like the solution.


Thanks again.

David

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

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

RE: RE: Multi-level bucketing problem

[Bhinderwala, Shoeb]

Whoa! Thanks Juan. I will start to understand/analyze this...

 



From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On
Behalf Of JuanManuel Gimeno Illa
Sent: Tuesday, May 03, 2011 11:40 AM
To: clojure@googlegroups.com
Subject: Re: RE: Multi-level bucketing problem

 

I'm sure this can be simplyfied:

 

(defn mlg [attrs data]

(if (empty? attrs)

[ (reduce + (map :mv data)) {:children data}]

(let [parts (group-by (first attrs) data)

  subtrees (map (fn [[value data]] 

[value (mlg (rest attrs) (map #(dissoc %
(first attrs)) data))])

  parts)]

(reduce (fn [[sum tree] [value [sumsubtree subtree]]]

[(+ sum sumsubtree)

 (update-in tree [:children] conj (assoc
subtree 

:path
[(first attrs) value]

:mv
sumsubtree))]

)

[ 0.0  { :children [] }]

subtrees

 

Returns a pair with the sum for all items and a tree. 

 

Each tree is represented as a dictionary, and inner nodes of the tree
have three keys:

- :mv the sum of :mv's of its children

- :path a pair of attr-value that represents all the leaves in the
subtree

- :children the subtrees of this level

 

Leaves are represented as dictionaries with only the keys :sec_id and
:mv.

 

I've forked your gist, so you can grab the code directly from github
https://gist.github.com/952861

 

Best regards,

 

Juan Manuel

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

[JuanManuel Gimeno Illa]

I'm sure this can be simplyfied:

(defn mlg [attrs data]
(if (empty? attrs)
[ (reduce + (map :mv data)) {:children data}]
 (let [parts (group-by (first attrs) data)
   subtrees (map (fn [[value data]] 
 [value (mlg (rest attrs) (map #(dissoc % (first 
attrs)) data))])
   parts)]
 (reduce (fn [[sum tree] [value [sumsubtree subtree]]]
 [(+ sum sumsubtree)
  (update-in tree [:children] conj (assoc subtree 
 :path [(first 
attrs) value]
 :mv sumsubtree))]
 )
 [ 0.0  { :children [] }]
 subtrees

Returns a pair with the sum for all items and a tree. 

Each tree is represented as a dictionary, and inner nodes of the tree have 
three keys:
- :mv the sum of :mv's of its children
- :path a pair of attr-value that represents all the leaves in the subtree
- :children the subtrees of this level

Leaves are represented as dictionaries with only the keys :sec_id and :mv.

I've forked your gist, so you can grab the code directly from 
github https://gist.github.com/952861

Best regards,

Juan Manuel

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

[Steve Miner]

On May 3, 2011, at 7:08 AM, David Jagoe wrote:

> Can I rely on (keys some-literal-map) always returning the keys in the
> order they were defined in the literal map?

In general, the key order is not guaranteed, but an array-map will maintain the 
insertion order of the keys.  Use the array-map function to create one. There's 
a bit more info here:

http://clojuredocs.org/clojure_core/clojure.core/array-map

> An array-map maintains the insertion order of the keys. Look up is linear, 
> which is not a problem for small maps (say less than 10 keys). If your map is 
> large, you should use hash-map instead.
> 
> When you assoc onto an existing array-map, the result is a new array-map with 
> the new key as the first key. The rest of the keys are in the same order as 
> the original. Functions such as seq and keys will respect the key order.
> 
> Note that assoc will decide to return a hash-map if the result is too big to 
> be efficient.

For your specific purpose, I would be careful about using a map as an "entity" 
specification. If the order is significant, a vector of field specifiers would 
be better.  Instead of taking a map as the second argument to defentity, you 
could make it variadic like (defmacro defentity [ent & specs] ...).

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

[JuanManuel Gimeno Illa]

I'm sure this can be simplyfied:

(defn mlg [attrs data]
(if (empty? attrs)
[ (reduce + (map :mv data)) {:children data}]
(let [parts (group-by (first attrs) data)
  subtrees (map (fn [[value data]] 
[value (mlg (rest attrs) (map #(dissoc % (first 
attrs)) data))])
  parts)]
(reduce (fn [[sum tree] [value [sumsubtree subtree]]]
[(+ sum sumsubtree)
 (update-in tree [:children] conj (assoc subtree 
:path [(first attrs) 
value]
:mv sumsubtree))]
)
[ 0.0  { :children [] }]
subtrees

Returns a pair with the sum for all items and a tree. 

Each tree is represented as a dictionary, and inner nodes of the tree have 
three keys:
- :mv the sum of :mv's of its children
- :path a pair of attr-value that represents all the leaves in the subtree
- :children the subtrees of this level

Leaves are represented as dictionaries with only the keys :sec_id and :mv.

Best regards,

Juan Manuel



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

[Armando Blancas]

Keys from literal maps aren't sorted; you need a sorted map.

user=> (keys {:z 1 :f 2 :a 0})
(:z :a :f)
user=> (keys (sorted-map :z 1 :f 2 :a 0))
(:a :f :z)

On May 3, 4:08 am, David Jagoe  wrote:
> Hey everyone,
>
> I'm busy implementing a macro whose usage looks like this:
>
> (defentity Person
>   {:name      {:type String :validator name-validator}
>    :id-number {:type String :validator id-number-validator}
>    :height    {:type Float  :default 0.0}
>    :weight    {:type Float  :default 0.0}
>    :bmi       {:type Float  :internal true}})
>
> The macro generates a defrecord like so:
>
> (defrecord Person [name id-number height weight bmi])
>
> Which can later be used in the application like this:
>
> (Person. "David" "123" 1 2 3)
>
> Obviously the argument order is important. So my question is:
>
> Can I rely on (keys some-literal-map) always returning the keys in the
> order they were defined in the literal map? In my experiment, a map
> literal will create a PersistentArrayMap which I understand has sorted
> keys. Can someone confirm that this is reliable (e.g. across
> implementations?)
>
> Thanks!
> David

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

Re: Any wisdom in the math speed of different clojure libraries?

[David Nolen]

On Tue, May 3, 2011 at 9:50 AM, bOR_  wrote:

> Because I did not remember Math/ceil :-).
>
> Point is, is there any consensus on what math library to use? Is (Math/...
> in general the fastest?
>

For basic math, I'm not sure what could be faster than Java primitive
operators and methods. For more sophisticated things you'll probably have to
look at the various Java libs which I'm not all that familiar with.

David

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

Re: Any wisdom in the math speed of different clojure libraries?

[bOR_]

Because I did not remember Math/ceil :-).

Point is, is there any consensus on what math library to use? Is (Math/... 
in general the fastest?

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

[Stanislav Paskalev]

Hello again,

This has solved the issue:

(let [cache (atom {})
  cache-eval (fn [obj]
(when-not (contains? @cache obj)
  (reset! cache (assoc @cache obj (eval obj
(@cache obj))]
  (defmacro def-cached
"Just as def, however it will return an existing object if it has
already been defined with it"
[fname fbody]
(intern *ns* (symbol fname) (cache-eval fbody)))
  (defmacro eval-cached
"Just as eval, however it will return an existing object if it has
already been evaluated with it"
[obj]
(cache-eval obj)))

However it'll be good if someone could share some insight why a macro
cannot call another one and what is the general solution in such a
case

Stanislav Paskalev



On Tue, May 3, 2011 at 3:50 PM, Stanislav Paskalev  wrote:
> Hello,
> Evaluating the form
>
> (let [cache (atom {})]
>  (defmacro eval-cached
>        "Just as eval, however it will return an existing object if it has
> already been evaluated with it"
>        [obj]
>        (when-not (contains? @cache obj)
>          (reset! cache (assoc @cache obj (eval obj
>        (@cache obj))
>  (defmacro def-cached
>        "Just as def, however it will return an existing object if it has
> already been defined with it"
>        [fname fbody]
>        (intern *ns* (symbol fname) (eval-cached fbody
>
> Gives me a java.lang.UnsupportedOperationException: Can't eval locals
> - for the last line of "def-cached"
>
> However, when I use eval the first defmacro by itself as a closure -
> it works perfectly. How can I make those share the cache state without
> binding it to a public symbol ?
>
> Best regards,
> Stanislav Paskalev
>

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

[ANN] Lacij v.0.1 a graph visualization library

[Pierre Allix]

Hello,

I would like to announce the version 0.1 of the Lacij library,
a graph visualization library written in Clojure.

I would be really happy with any feedbacks and comments, on the code
or the architecture. Help is welcome to implement additional layout
algorithms.


>From the README file:

Lacij is a graph visualization library written in Clojure. It allows
the display
and the dynamic modification of graphs as SVG documents that can be
viewed
with a Web browser or with a Swing component. Undo/redo is supported
for the
dynamic modification. Automatic layout is provided for the
visualization.
The library is available on GitHub:

https://github.com/pallix/lacij

and on Clojars:

http://clojars.org/lacij

This library is being developed as part of the Carneades project:

http://carneades.berlios.de/

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

Let over defmacro

[Stanislav Paskalev]

Hello,
Evaluating the form

(let [cache (atom {})]
  (defmacro eval-cached
"Just as eval, however it will return an existing object if it has
already been evaluated with it"
[obj]
(when-not (contains? @cache obj)
  (reset! cache (assoc @cache obj (eval obj
(@cache obj))
  (defmacro def-cached
"Just as def, however it will return an existing object if it has
already been defined with it"
[fname fbody]
(intern *ns* (symbol fname) (eval-cached fbody

Gives me a java.lang.UnsupportedOperationException: Can't eval locals
- for the last line of "def-cached"

However, when I use eval the first defmacro by itself as a closure -
it works perfectly. How can I make those share the cache state without
binding it to a public symbol ?

Best regards,
Stanislav Paskalev

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

[David Nolen]

Why not?

user> (time (dotimes [_ 10] (Math/ceil 0.1)))
"Elapsed time: 626.867 msecs"

David

On Tue, May 3, 2011 at 3:38 AM, bOR_  wrote:

> user> (time (dotimes [i 10] (contribmath-ceil (rand
>
>
> "Elapsed time: 4500.530303 msecs"
>
>
> nil
>
>
> user> (time (dotimes [i 10] (contribgenericmath-ceil (rand
>
>
> "Elapsed time: 44.707193 msecs"
>
>
> nil
>
>
> user> (time (dotimes [i 10] (incanterprocessing-ceil (rand
>
>
> "Elapsed time: 38.322599 msecs"
>
>
> nil
>
>
> user> (time (dotimes [i 10] (inc (int (rand)
>
>
> "Elapsed time: 28.939557 msecs"
>
> Observing the huge differences in speed of certain math functions in
> different clojure libraries, I was wondering if anyone knows which clojure
> math library is fastest in general? Is there any wisdom in this, or is it
> just up to users to check for each function where to get an efficient
> implementation.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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

Key order of literal maps

[David Jagoe]

Hey everyone,

I'm busy implementing a macro whose usage looks like this:

(defentity Person
  {:name  {:type String :validator name-validator}
   :id-number {:type String :validator id-number-validator}
   :height{:type Float  :default 0.0}
   :weight{:type Float  :default 0.0}
   :bmi   {:type Float  :internal true}})

The macro generates a defrecord like so:

(defrecord Person [name id-number height weight bmi])

Which can later be used in the application like this:

(Person. "David" "123" 1 2 3)

Obviously the argument order is important. So my question is:

Can I rely on (keys some-literal-map) always returning the keys in the
order they were defined in the literal map? In my experiment, a map
literal will create a PersistentArrayMap which I understand has sorted
keys. Can someone confirm that this is reliable (e.g. across
implementations?)


Thanks!
David

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

Re: Serialising functions...

[Jules]

see inline

On Friday, 29 April 2011 04:25:58 UTC+1, kovasb wrote:
>
> Thats some serious hacking. Definitely agree that distributed clojure
> would be awesome.
>
> Two points/questions:
>
> 1) Is this just a bug in DynamicClassLoader? Why doesn't it call
> super.defineClass instead of falling back on the URLClassLoader?:
>
> public Class defineClass(String name, byte[] bytes){
> return defineClass(name, bytes, 0, bytes.length);
> }
>
I wondered this.

Perhaps the guy who wrote it thought it conceptually cleaner to map his 
defineClass into another method at the same inheritance-level, rather than 
super, or he intended that you be able to make use of the UCL fn-ality 
within DCL, or that it is just how the code has turned out after being 
edited several times by several people
 

> If it simply called super, then I believe I can pass in the right
> "bytecode preserving" class with the context class loader, thus
> avoiding modifications to the clojure source.
>
You could try patching it to do so, so that you could try out your approach. 
If it is successful it might provide a less intrusive way of achieving the 
same thing. I have messed wih ClassLoaders before and just took the simplest 
approach that I could see to get where I wanted to go. I did try aspecting 
the DCL to get my bytecode memo table working without code modification - no 
joy, but I can't remember if I tried slipping my own ClassLoader into the 
hierarchy...

Given that, without my patch, there are no URLs to fall back on, would the 
code not fall through and do what you want to do anyway ?

> 2) Do you know how to serialize an entire namespace? This largely
> avoids the issue of closures.
>
I haven't tried this - you are ahead of me here. 

> Right now I'm serializing the classes, and serializing all the vars in
> the NS, and then containing them in some ad-hoc format on disk.
> Obviously this somehow can be done with a single class, but how the
> compiler does it is too hairy for me to understand.
>
>
> This sounds like a bit more of a challenge.

Is the idea that you are dynamically creating a namespace and then 
dynamically creating types/functions within it and that you then want to 
persist/migrate this construct ?

I haven't investigated how ns-es are implemented, but I expect that you are 
going to have to chase down a list of nested references and ensure that you 
have marshalled up everything that you need. Along the way, you will 
probably have to filter out references to other static ns-es on which you 
depend.

This sounds like the sort of code that I would want to write in Clojure 
rather than in Java. You are likely to come across types that are not 
serialisable as well and have to write custom serialisation routines for 
them.

Sounds interesting :-) - wish I could help more - please keep the list 
posted.

Jules

On Thu, Apr 28, 2011 at 9:28 AM, Jules  wrote:
> > well spotted :-)
> >
> > I have ported it up to 1.3.0-alpha5 - alpha6 gave me some trouble that I
> > haven't had time to sort out.
> >
> > [BTW - the following is from memory]
> >
> > You set the JVM's UID via a sys property.
> >
> > If this property is set it is incorporated into the names of new classes
> > created in this JVM.
> >
> > The DynamicClassLoader maintains a map of classname : bytecode.
> >
> > I run a Jetty in this JVM which knows how to respond to URLClassLoader
> > requests for class bytecode by looking them up in this map.
> >
> > I think I hacked DynamicClassLoader (which ?inherits? from 
> URLClassLoader)
> > so that you can optionally set a system property that is a URL from which 
> it
> > can request classes that it cannot find locally. So you do this on client
> > JVMs
> >
> > Putting this all together, you can basically create types/fns on the-fly 
> in
> > a one JVM, serialise instances of these and send them to another JVM, 
> then
> > deserialise them (transparently pulling their class over from their 
> parent
> > JVM) and use them as if they had been created at compile rather than
> > runtime.
> >
> > This plugs what I have found to be a bit of a hole in Clojure, namely
> > dynamism is great, but I want to use it in a distributed app...
> >
> > The patches are not prodction ready, but I have been using them for some
> > time with no problem. I'd be very happy to find other people with similar
> > interest, improve the patches and see if we can persuade the powers that 
> be
> > to accept them or something providing similar fn-ality into e.g. 
> Clojure-1.4
> > :-)
> >
> > If you need any help getting this stuff to work, just shout.
> >
> >
> > Jules
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com
> > For more optio

Re: Any wisdom in the math speed of different clojure libraries?

[Alan]

On May 3, 12:38 am, bOR_  wrote:
> user> (time (dotimes [i 10] (contribmath-ceil (rand                
>
> "Elapsed time: 4500.530303 msecs"                                          
>
> nil                                                                        
>
> user> (time (dotimes [i 10] (contribgenericmath-ceil (rand          
>
> "Elapsed time: 44.707193 msecs"                                            
>
> nil                                                                        
>
> user> (time (dotimes [i 10] (incanterprocessing-ceil (rand          
>
> "Elapsed time: 38.322599 msecs"                                            
>
> nil                                                                        
>
> user> (time (dotimes [i 10] (inc (int (rand)                


That's a terrible ceil method: (inc (int 0)) is 1. The reason it's
fast is that (int x) is a java primitive. It acts like the *floor*
function, making it not useful to 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

Any wisdom in the math speed of different clojure libraries?

[bOR_]

user> (time (dotimes [i 10] (contribmath-ceil (rand 

   
"Elapsed time: 4500.530303 msecs"   


nil 


user> (time (dotimes [i 10] (contribgenericmath-ceil (rand   

  
"Elapsed time: 44.707193 msecs" 


nil 


user> (time (dotimes [i 10] (incanterprocessing-ceil (rand   

  
"Elapsed time: 38.322599 msecs" 


nil 


user> (time (dotimes [i 10] (inc (int (rand) 

   
"Elapsed time: 28.939557 msecs" 

Observing the huge differences in speed of certain math functions in 
different clojure libraries, I was wondering if anyone knows which clojure 
math library is fastest in general? Is there any wisdom in this, or is it 
just up to users to check for each function where to get an efficient 
implementation.

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