Re: Enlive questions

[Christophe Grand]

David Nolen a écrit :
> One early thought, would you like me to extend the number of examples? 
> I'm really getting into the nitty gritty of what's possible with 
> Enlive and it would be nice to have a relatively informative list of 
> possibilities distributed with the library vs. the single example 
> that's in there right now ;)

With pleasure!

-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[Christophe Grand]

David Nolen a écrit :
> Sorry to bombard but I couldn't get attr? or attr= to work inside the 
> selector:
>
> (deftemplate my-app4 "app.html"
>   [widgets]
>   [:div '(attr? :tiptree:replace)] (content "bar"))
> (apply str (my-app4 {}))
>
> (deftemplate my-app4 "app.html"
>   [widgets]
>   [[:div '(attr? :tiptree:replace)]] (content "bar"))
> (apply str (my-app4 {}))
>
> Neither forms worked for me. I messed around with the enlive code 
> itself for quite a bit trying to understand what was going on under 
> the hood but to no avail.

I'll lift the need to quote predicates. I'm worried about 
:tiptree:replace, are you using namespaces?
[:div '(attr? :foo :bar)] is equivalent to div *[foo][bar]
[[:div '(attr? :foo :bar)]] is equivalent to div[foo][bar]


-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[David Nolen]

Sorry to bombard but I couldn't get attr? or attr= to work inside the
selector:
(deftemplate my-app4 "app.html"
  [widgets]
  [:div '(attr? :tiptree:replace)] (content "bar"))
(apply str (my-app4 {}))

(deftemplate my-app4 "app.html"
  [widgets]
  [[:div '(attr? :tiptree:replace)]] (content "bar"))
(apply str (my-app4 {}))

Neither forms worked for me. I messed around with the enlive code itself for
quite a bit trying to understand what was going on under the hood but to no
avail.

On Tue, Apr 14, 2009 at 1:31 PM, Christophe Grand wrote:

>
> I pushed do->, attr=, attr? and snippets values as source to github
> http://github.com/cgrand/enlive/commits/right
>
> Christophe Grand a écrit :
> > Hello David,
> >
> > David Nolen a écrit :
> >
> >> Considering the above, I'm left wondering if it's possible to further
> >> eliminate these redundancies and make templates more reusable. I'm not
> >> sure if this is what you had in mind for Enlive, but allowing
> >> templates to be created without references to files would make it
> >> possible to build very, very composable interfaces.
> >> Of course it's quite possible that you can already do this with Enlive
> >> and I'm just unclear about how to accomplish it.
> >>
> >
> > I'm sorry for the lack of documentation.
> >
> > The "source" of a template/snippet can either be:
> > - a string (a resource path resolved by the classloader)
> > - a File, URI or URL,
> > - a map (a "literal" xml/html tree).
> >
> > A template is a function that returns a seq of strings. (It's the end of
> > the "pipeline".)
> >
> > A snippet is a function that now (in the "new" enlive) returns a seq of
> > nodes. (I suppose I should add "seq of nodes" as a valid source type.)
> > Snippets are valid values on the right-hand side of rules. The only
> > difference between templates and snippets is that templates serialize
> > their return value.
> >
> >
> >> This is great.  I had thought that supporting some kind of partial
> >> template thing would be interesting, but that's actually just my poor
> >> logic at work ;)
> >>
> >> It seems like with the new version of Enlive I could do something like
> >> this:
> >>
> >> (deftemplate pageA-template path
> >>   []
> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >>
> >> (deftemplate pageB-template path
> >>   []
> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >>
> >> (def pageAPartial (pageA-template))
> >> (def pageBPartial (pageB-template))
> >>
> >> ;; the following would work only if templates allowed passing html as
> >> strings and not just as files
> >>
> >> (deftemplate widgetsPageA pageAPartial
> >>   [map]
> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >>
> >> (deftemplate widgetsPageB pageBPartial
> >>   [map]
> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >>
> >> (def pageA (widgetsPageA someMap))
> >> (def pageB (widgetsPageA someMap))
> >>
> >>
> >
> > I suppose you really want to break the computation in two and not write:
> > (deftemplate pageA-template path
> >   [map]
> >   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
> >   [[:div (attr? :tiptree:widget)]] (fn [xml]
> > (use-xml-attr-and-map-to-apply-and-return-a-snippet)))
> >
> > or:
> > (deftemplate pageA-template path
> >   [map]
> >   [[:div (attr? :tiptree:replace)]]
> > (do->
> >   (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
> >   (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet
> >
> > (well, it would work if do-> has been ported to the new enlive)
> >
> > Keeping in mind the difference between a snippet and a template, you
> > will be able to do what you describe with the new enlive once I
> > implement 'attr? and add support for seq of nodes as a valid source type.
> >
> >
> > hth,
> >
> > Christophe
> >
> > >
> >
> >
>
>
> --
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[Adrian Cuthbertson]

I'm just starting out on Enlive - any examples added would be welcome.
I'll also accumulate some documentation as I go through the learning
curve.

Thanks, Adrian.

On Wed, Apr 15, 2009 at 5:05 AM, David Nolen  wrote:
> One early thought, would you like me to extend the number of examples? I'm
> really getting into the nitty gritty of what's possible with Enlive and it
> would be nice to have a relatively informative list of possibilities
> distributed with the library vs. the single example that's in there right
> now ;)
> On Tue, Apr 14, 2009 at 1:31 PM, Christophe Grand 
> wrote:
>>
>> I pushed do->, attr=, attr? and snippets values as source to github
>> http://github.com/cgrand/enlive/commits/right
>>
>> Christophe Grand a écrit :
>> > Hello David,
>> >
>> > David Nolen a écrit :
>> >
>> >> Considering the above, I'm left wondering if it's possible to further
>> >> eliminate these redundancies and make templates more reusable. I'm not
>> >> sure if this is what you had in mind for Enlive, but allowing
>> >> templates to be created without references to files would make it
>> >> possible to build very, very composable interfaces.
>> >> Of course it's quite possible that you can already do this with Enlive
>> >> and I'm just unclear about how to accomplish it.
>> >>
>> >
>> > I'm sorry for the lack of documentation.
>> >
>> > The "source" of a template/snippet can either be:
>> > - a string (a resource path resolved by the classloader)
>> > - a File, URI or URL,
>> > - a map (a "literal" xml/html tree).
>> >
>> > A template is a function that returns a seq of strings. (It's the end of
>> > the "pipeline".)
>> >
>> > A snippet is a function that now (in the "new" enlive) returns a seq of
>> > nodes. (I suppose I should add "seq of nodes" as a valid source type.)
>> > Snippets are valid values on the right-hand side of rules. The only
>> > difference between templates and snippets is that templates serialize
>> > their return value.
>> >
>> >
>> >> This is great.  I had thought that supporting some kind of partial
>> >> template thing would be interesting, but that's actually just my poor
>> >> logic at work ;)
>> >>
>> >> It seems like with the new version of Enlive I could do something like
>> >> this:
>> >>
>> >> (deftemplate pageA-template path
>> >>   []
>> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
>> >>
>> >> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>> >>
>> >> (deftemplate pageB-template path
>> >>   []
>> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
>> >>
>> >> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>> >>
>> >> (def pageAPartial (pageA-template))
>> >> (def pageBPartial (pageB-template))
>> >>
>> >> ;; the following would work only if templates allowed passing html as
>> >> strings and not just as files
>> >>
>> >> (deftemplate widgetsPageA pageAPartial
>> >>   [map]
>> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
>> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>> >>
>> >> (deftemplate widgetsPageB pageBPartial
>> >>   [map]
>> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
>> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>> >>
>> >> (def pageA (widgetsPageA someMap))
>> >> (def pageB (widgetsPageA someMap))
>> >>
>> >>
>> >
>> > I suppose you really want to break the computation in two and not write:
>> > (deftemplate pageA-template path
>> >   [map]
>> >   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
>> >
>> > (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>> >   [[:div (attr? :tiptree:widget)]] (fn [xml]
>> > (use-xml-attr-and-map-to-apply-and-return-a-snippet)))
>> >
>> > or:
>> > (deftemplate pageA-template path
>> >   [map]
>> >   [[:div (attr? :tiptree:replace)]]
>> >     (do->
>> >       (fn [xml-node]
>> >
>> > (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>> >       (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet
>> >
>> > (well, it would work if do-> has been ported to the new enlive)
>> >
>> > Keeping in mind the difference between a snippet and a template, you
>> > will be able to do what you describe with the new enlive once I
>> > implement 'attr? and add support for seq of nodes as a valid source
>> > type.
>> >
>> >
>> > hth,
>> >
>> > Christophe
>> >
>> > >
>> >
>> >
>>
>>
>> --
>> Professional: http://cgrand.net/ (fr)
>> On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[David Nolen]

One early thought, would you like me to extend the number of examples? I'm
really getting into the nitty gritty of what's possible with Enlive and it
would be nice to have a relatively informative list of possibilities
distributed with the library vs. the single example that's in there right
now ;)
On Tue, Apr 14, 2009 at 1:31 PM, Christophe Grand wrote:

>
> I pushed do->, attr=, attr? and snippets values as source to github
> http://github.com/cgrand/enlive/commits/right
>
> Christophe Grand a écrit :
> > Hello David,
> >
> > David Nolen a écrit :
> >
> >> Considering the above, I'm left wondering if it's possible to further
> >> eliminate these redundancies and make templates more reusable. I'm not
> >> sure if this is what you had in mind for Enlive, but allowing
> >> templates to be created without references to files would make it
> >> possible to build very, very composable interfaces.
> >> Of course it's quite possible that you can already do this with Enlive
> >> and I'm just unclear about how to accomplish it.
> >>
> >
> > I'm sorry for the lack of documentation.
> >
> > The "source" of a template/snippet can either be:
> > - a string (a resource path resolved by the classloader)
> > - a File, URI or URL,
> > - a map (a "literal" xml/html tree).
> >
> > A template is a function that returns a seq of strings. (It's the end of
> > the "pipeline".)
> >
> > A snippet is a function that now (in the "new" enlive) returns a seq of
> > nodes. (I suppose I should add "seq of nodes" as a valid source type.)
> > Snippets are valid values on the right-hand side of rules. The only
> > difference between templates and snippets is that templates serialize
> > their return value.
> >
> >
> >> This is great.  I had thought that supporting some kind of partial
> >> template thing would be interesting, but that's actually just my poor
> >> logic at work ;)
> >>
> >> It seems like with the new version of Enlive I could do something like
> >> this:
> >>
> >> (deftemplate pageA-template path
> >>   []
> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >>
> >> (deftemplate pageB-template path
> >>   []
> >>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >>
> >> (def pageAPartial (pageA-template))
> >> (def pageBPartial (pageB-template))
> >>
> >> ;; the following would work only if templates allowed passing html as
> >> strings and not just as files
> >>
> >> (deftemplate widgetsPageA pageAPartial
> >>   [map]
> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >>
> >> (deftemplate widgetsPageB pageBPartial
> >>   [map]
> >>   [[:div (attr? :tiptree:widget)]] (fn [xml]
> >> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >>
> >> (def pageA (widgetsPageA someMap))
> >> (def pageB (widgetsPageA someMap))
> >>
> >>
> >
> > I suppose you really want to break the computation in two and not write:
> > (deftemplate pageA-template path
> >   [map]
> >   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
> >   [[:div (attr? :tiptree:widget)]] (fn [xml]
> > (use-xml-attr-and-map-to-apply-and-return-a-snippet)))
> >
> > or:
> > (deftemplate pageA-template path
> >   [map]
> >   [[:div (attr? :tiptree:replace)]]
> > (do->
> >   (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
> >   (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet
> >
> > (well, it would work if do-> has been ported to the new enlive)
> >
> > Keeping in mind the difference between a snippet and a template, you
> > will be able to do what you describe with the new enlive once I
> > implement 'attr? and add support for seq of nodes as a valid source type.
> >
> >
> > hth,
> >
> > Christophe
> >
> > >
> >
> >
>
>
> --
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Krešimir Šojat]

On 14 tra, 23:48, Meikel Brandmeyer  wrote:

> I already use MacroDef. As far as I see, none of those allows me to  
> define
> new targets, right? Only tasks?
>

Yes, they can only define new tasks, you can call targets from them
(using antcall) and of course call them from your tasks. If you use
antcall you can pass parameters to targets, so in a way they can act
as tasks as they can be reconfigured on runtime.

Script task can be used inside your target, so you can define targets
that have JavaScript code in them, only problem with this is that you
can't share code from one task/target script with others.

If you can't solve this with normal Ant construct you can drop down to
Java and create new Task, or even in Clojure (you will need to
initialize your antlib with classpath set to point to clojure.jar).

--
Krešimir Šojat
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Tom Faulhaber]

Jason,

Thanks for the offer. I may take you up on it as I get this into
"production" such as it is.

Sean,

Nothing that I found in contrib (but who knows, there's no
documentation :-)). Rich posted some code (which I'm using in a
modified version in the center of things) for doing the API paage for
clojure.org here: http://paste.lisp.org/display/77339

When I get my code looking anything other than nasty (and anyone who's
looked at pprint knows that's a low bar!), I'll at least put it up on
github. Eventually I may add it to contrib, too, if the community
feels it should go (but let's solve the problem ahead of us).

Laurent,

You seem to be going in the opposite direction from Konrad and I would
worry about the duplication. I would be more inclined to think about a
single markup format for :doc strings that could be converted for the
various uses. But that's really a language change at some level, so
I'd rather defer that until we see how this stuff is used.

But to be honest, I haven't read your comments that closely because
today has been a long day. Maybe later tonight...

Thanks for all the feedback, guys!

Tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Meikel Brandmeyer]

Hi,

Am 14.04.2009 um 23:24 schrieb Krešimir Šojat:


I'd really love to see defmacro in ant...


There is macrodef http://ant.apache.org/manual/CoreTasks/macrodef.html
in Ant, also, there is a Script task you can use to include JavaScript
(and many other) in your Ant builds. You may also check out scriptdef
and presetdef tasks.


I already use MacroDef. As far as I see, none of those allows me to  
define

new targets, right? Only tasks?

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Building modularised contrib with ant+ivy

[Meikel Brandmeyer]

Dear Clojurians,

here an update of my Ivy experiments.
For publishing in a shared repository
it uses svnant[1] to automatically extract
the current revision as new version
number.

Sincerely
Meikel

[1]: http://subclipse.tigris.org/svnant.html

 

contrib-ivy2.diff
Description: Binary data


clojure-ivy2.diff
Description: Binary data




smime.p7s
Description: S/MIME cryptographic signature

Re: Contribs with dependencies

[Mark Reid]

Hi,

I'm not sure if this is relevant to this discussion but, as a
newcomer, I was puzzled by the organisation of the clojure-contrib
source.

Why, for example, are ClojureCLR and clojurescript at the top of the
trunk? Shouldn't these be in separate projects?

Regards,

Mark.
--
http://mark.reid.name/

On Apr 14, 10:19 pm, Rich Hickey  wrote:
> I've been thinking recently about contribs with dependencies.
>
> I think it's very important to have layers - e.g. core depends only on
> JDK 1.5, contrib only on core. Lately there have been some ideas
> centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
> etc.
>
> I'd like to start a discussion about how best to support the
> contributions of libraries that depend on things not in the JDK.
>
> Obviously, without care and rules it could get crazy quickly, and I
> want to avoid the kitchen-sink effect. It is very important that
> things remain [truly, not just apparently] simple.
>
> Looking for suggestions,
>
> Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Krešimir Šojat]

Hi,

On 14 tra, 23:15, Meikel Brandmeyer  wrote:

> I'd
> really love to see defmacro in ant...

There is macrodef http://ant.apache.org/manual/CoreTasks/macrodef.html
in Ant, also, there is a Script task you can use to include JavaScript
(and many other) in your Ant builds. You may also check out scriptdef
and presetdef tasks.

--
Krešimir Šojat

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[Meikel Brandmeyer]

Hi,

Am 14.04.2009 um 23:02 schrieb Howard Lewis Ship:


I'd say to refactor clojure-contrib into a number of seperate modules;
individual modules (each with its own pom) could have their own
dependencies. Thus if you choose clojure-contrib-freechart, you get
that JAR (or compiled Clojure sources) plus the jfreechart dependency.

In this way you are using the good part of Maven: transitive
dependency management.


I solved this in my Ivy approach by using different configurations.
Although everything is configured in a single ivy.xml (no need
for different poms), there is still a lot of moisture to DRY out. I'd
really love to see defmacro in ant... Maybe I will look deeper into
lancet. Since it uses the ant machinery underneath, it might be
a good solution for this problem...

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Enlive questions

[David Nolen]

Great! I will play around with the new features and returns with some more
informed feedback ;)
On Tue, Apr 14, 2009 at 9:58 AM, Christophe Grand wrote:

>
> Hello David,
>
> David Nolen a écrit :
> > Considering the above, I'm left wondering if it's possible to further
> > eliminate these redundancies and make templates more reusable. I'm not
> > sure if this is what you had in mind for Enlive, but allowing
> > templates to be created without references to files would make it
> > possible to build very, very composable interfaces.
> > Of course it's quite possible that you can already do this with Enlive
> > and I'm just unclear about how to accomplish it.
>
> I'm sorry for the lack of documentation.
>
> The "source" of a template/snippet can either be:
> - a string (a resource path resolved by the classloader)
> - a File, URI or URL,
> - a map (a "literal" xml/html tree).
>
> A template is a function that returns a seq of strings. (It's the end of
> the "pipeline".)
>
> A snippet is a function that now (in the "new" enlive) returns a seq of
> nodes. (I suppose I should add "seq of nodes" as a valid source type.)
> Snippets are valid values on the right-hand side of rules. The only
> difference between templates and snippets is that templates serialize
> their return value.
>
> > This is great.  I had thought that supporting some kind of partial
> > template thing would be interesting, but that's actually just my poor
> > logic at work ;)
> >
> > It seems like with the new version of Enlive I could do something like
> > this:
> >
> > (deftemplate pageA-template path
> >   []
> >   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >
> > (deftemplate pageB-template path
> >   []
> >   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
> >
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
> >
> > (def pageAPartial (pageA-template))
> > (def pageBPartial (pageB-template))
> >
> > ;; the following would work only if templates allowed passing html as
> > strings and not just as files
> >
> > (deftemplate widgetsPageA pageAPartial
> >   [map]
> >   [[:div (attr? :tiptree:widget)]] (fn [xml]
> > (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >
> > (deftemplate widgetsPageB pageBPartial
> >   [map]
> >   [[:div (attr? :tiptree:widget)]] (fn [xml]
> > (use-xml-attr-and-map-to-apply-and-return-a-snippet))
> >
> > (def pageA (widgetsPageA someMap))
> > (def pageB (widgetsPageA someMap))
> >
>
> I suppose you really want to break the computation in two and not write:
> (deftemplate pageA-template path
>  [map]
>   [[:div (attr? :tiptree:replace)]] (fn [xml-node]
>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>   [[:div (attr? :tiptree:widget)]] (fn [xml]
> (use-xml-attr-and-map-to-apply-and-return-a-snippet)))
>
> or:
> (deftemplate pageA-template path
>  [map]
>  [[:div (attr? :tiptree:replace)]]
>(do->
>   (fn [xml-node]
>
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>   (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet
>
> (well, it would work if do-> has been ported to the new enlive)
>
> Keeping in mind the difference between a snippet and a template, you
> will be able to do what you describe with the new enlive once I
> implement 'attr? and add support for seq of nodes as a valid source type.
>
>
> hth,
>
> Christophe
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[Howard Lewis Ship]

I'd say to refactor clojure-contrib into a number of seperate modules;
individual modules (each with its own pom) could have their own
dependencies. Thus if you choose clojure-contrib-freechart, you get
that JAR (or compiled Clojure sources) plus the jfreechart dependency.

In this way you are using the good part of Maven: transitive
dependency management.

On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey  wrote:
>
> I've been thinking recently about contribs with dependencies.
>
> I think it's very important to have layers - e.g. core depends only on
> JDK 1.5, contrib only on core. Lately there have been some ideas
> centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
> etc.
>
> I'd like to start a discussion about how best to support the
> contributions of libraries that depend on things not in the JDK.
>
> Obviously, without care and rules it could get crazy quickly, and I
> want to avoid the kitchen-sink effect. It is very important that
> things remain [truly, not just apparently] simple.
>
> Looking for suggestions,
>
> Rich
>
> >
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Javascript generator

[David Nolen]

Cool! Thanks.
Also sorry for the accidental double post and I had a typo, I meant the
weird result was:

(println
 (javascript (new ClassGenerator {prop1 "a" prop2 "b"})))
> var MyClass = new(ClassGenerator, {prop1:"a",prop2:"b"});

Instead of-

var MyClass = new ClassGenerator({prop1:"a", prop2:"b"});

On Tue, Apr 14, 2009 at 4:01 PM, jim  wrote:

>
> I got my static IP today.  I'm setting up the web server now.  I'll
> setup the Git server ASAP.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Tom Faulhaber]

Konrad,

I too would rather have everything in a single :doc tag and it most
cases it will be (just as it is with the clojure.org API page). But I
wanted to leave open the option for people to create custom marked-up
version for the wiki if they wanted something fancier. Any solution
that involves including the markup in the :doc string seemed to me to
be not immediately practical either cause it mucks up the output of
(doc ...) or requires changes to core to do something with markup. I
didn't want to break what was there or have to wait for a new feature.
But we can change pretty easily later, I think, once it seems like we
know the right answer.

Tom

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Meikel Brandmeyer]

Hi,

Am 14.04.2009 um 17:17 schrieb Laurent PETIT:

It will be very difficult to speak about it without the discussion  
switching to a dependency management tool war  OR to keep things  
simple, add the dependencies (if their license allow it *OUCH*) in  
some libs/ directory in clojure-contrib itself.


I guess Meikel Brandmeyer somewhat started  to show the path by  
already offering a split of clojure-contrib in several more modular  
units.


AGAIN, I would be very unhappy to have to download even one or two  
jars from the web in order to be able to compile clojure-contrib if  
I just want to use a namespace of it that has nothing to do with the  
downloaded jar, either directly or indirectly ...


I think splitting into modules is the key here. While experimenting
with Ivy I got a setup where really only what is needed is downloaded.
I can specify dependencies like eg. a test library or a source jar,  
which

are only used while I develop the library. The user of the library only
really gets the runtime dependencies.

I also don't understand the distaste which is exhibited for such build
systems. Eg. with Ivy I can specify a hierarchy of repositories. If I  
don't

want to download stuff, I simply remove the public repository. And
only the local repositories are searched for dependencies. I have the
flexibility to decide. Nothing is forced.

However this is at the moment based on pre-compiled jars. On the
build machine all dependencies (eg. miglayout) must be available.
This might not be viable when compiling itself must be done, eg.
for a different host VM. So a more modularised build should be also
possible.

I'm a bit amazed, that the build systems today go away from really
building what's necessary to go to some targets which are purely
PHONY (in make terms). Make is not perfect, but it does have a point!

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Javascript generator

[jim]

I got my static IP today.  I'm setting up the web server now.  I'll
setup the Git server ASAP.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Greg Harman]

Are there strong feelings against moving away from a centralized
contrib repository in favor of a directory (probably on clojure.org)
of independent projects? Seems to me that this simplifies the matter
of getting just the libraries you need without having to worry about
unrelated dependencies, and without imposing those dependencies on
other unrelated libraries. Even without dependencies, I now have to
include (without dicing up the jar & repackaging) all the libraries in
clojure contrib just to use one of them...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

new contrib: per-thread-singleton

[Stuart Sierra]

A better version of clojure.contrib.singleton:

clojure.contrib.singleton/per-thread-singleton
([f])
  Returns a per-thread singleton function.  The singleton
  function will call f only once for each thread, and cache its value
  for subsequent calls from the same thread.  This allows you to
  safely and lazily initialize shared objects on a per-thread basis.

clojure.contrib.singleton/global-singleton
([f])
  Returns a global singleton function.


per-thread-singleton is implemented using java.lang.ThreadLocal, which
has an edge-case bug up to JDK 5:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025230

-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[Christophe Grand]

I pushed do->, attr=, attr? and snippets values as source to github 
http://github.com/cgrand/enlive/commits/right

Christophe Grand a écrit :
> Hello David,
>
> David Nolen a écrit :
>   
>> Considering the above, I'm left wondering if it's possible to further 
>> eliminate these redundancies and make templates more reusable. I'm not 
>> sure if this is what you had in mind for Enlive, but allowing 
>> templates to be created without references to files would make it 
>> possible to build very, very composable interfaces.
>> Of course it's quite possible that you can already do this with Enlive 
>> and I'm just unclear about how to accomplish it.
>> 
>
> I'm sorry for the lack of documentation.
>
> The "source" of a template/snippet can either be:
> - a string (a resource path resolved by the classloader)
> - a File, URI or URL,
> - a map (a "literal" xml/html tree).
>
> A template is a function that returns a seq of strings. (It's the end of 
> the "pipeline".)
>
> A snippet is a function that now (in the "new" enlive) returns a seq of 
> nodes. (I suppose I should add "seq of nodes" as a valid source type.)
> Snippets are valid values on the right-hand side of rules. The only 
> difference between templates and snippets is that templates serialize 
> their return value.
>
>   
>> This is great.  I had thought that supporting some kind of partial 
>> template thing would be interesting, but that's actually just my poor 
>> logic at work ;)
>>
>> It seems like with the new version of Enlive I could do something like 
>> this:
>>
>> (deftemplate pageA-template path
>>   []
>>   [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
>> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>>
>> (deftemplate pageB-template path
>>   []
>>   [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
>> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>>
>> (def pageAPartial (pageA-template))
>> (def pageBPartial (pageB-template))
>>
>> ;; the following would work only if templates allowed passing html as 
>> strings and not just as files
>>
>> (deftemplate widgetsPageA pageAPartial
>>   [map]
>>   [[:div (attr? :tiptree:widget)]] (fn [xml] 
>> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>>
>> (deftemplate widgetsPageB pageBPartial
>>   [map]
>>   [[:div (attr? :tiptree:widget)]] (fn [xml] 
>> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>>
>> (def pageA (widgetsPageA someMap))
>> (def pageB (widgetsPageA someMap))
>>
>> 
>
> I suppose you really want to break the computation in two and not write:
> (deftemplate pageA-template path
>   [map]
>   [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>   [[:div (attr? :tiptree:widget)]] (fn [xml] 
> (use-xml-attr-and-map-to-apply-and-return-a-snippet)))
>
> or:
> (deftemplate pageA-template path
>   [map]
>   [[:div (attr? :tiptree:replace)]]
> (do->
>   (fn [xml-node] 
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
>   (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet
>
> (well, it would work if do-> has been ported to the new enlive)
>
> Keeping in mind the difference between a snippet and a template, you 
> will be able to do what you describe with the new enlive once I 
> implement 'attr? and add support for seq of nodes as a valid source type.
>
>
> hth,
>
> Christophe
>
> >
>
>   


-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Got a Clojure library?

[mikel]

On Apr 14, 6:43 am, Rich Hickey  wrote:
> On Apr 13, 1:31 pm, mikel  wrote:


> Thanks! It looks like that first link is broken?

Sorry about that; it was an svn link. I;ve added a Wiki page to the
project that explains what Model and GF are, and how to get and use
them. So how about this description instead:

Name: xg-model, xg-gf
URL:  http://code.google.com/p/explorersguild/wiki/XGModelAndGF
Files: util.clj, gf.clj, model.clj, model_gf.clj
Author: mikel evins
Tags: generic functions, models, dispatch
License: EPL
Dependencies: none
Description: Provides:
  model: an implementation of extensible record types with optional
value constraints on fields
  gf:an implementation of CLOS_style generic functions. gf domains
provide a means of defining dispatch algorithms. Example domains are
provided that implement CLOS-style dispatch over Java classes, and
simple predicate-dispatch. Included is a dispatch domain that
implements multimethod dispatch on XG models.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Laurent PETIT]

2009/4/14 Konrad Hinsen 

>
> On Apr 14, 2009, at 17:17, Laurent PETIT wrote:
>
> > The problem will then be that the next time I checkout clojure-
> > contrib, BLAM I can't compile it because I need to download a jar
> > from somewhere on the web ...
>
> That could be avoided by including the Clojure source in clojure-
> contrib,


I don't mind having to externally download the clojure source. It seems a
reasonable explicit required dependency to compile anything in
clojure-contrib ;-)


> but not add it to the libraries to be precompiled in
> build.xml. I suspect that it would even be possible to add specific
> compilation targets for libraries that have external dependencies,
> but I don't know ant well enough to be certain.
>
> Note that I am not proposing any dependency management, just separate
> compilation targets for "clojure-only" libraries and "depends-on-XYZ"
> libraries. For a precompiled jar distribution, that would probably
> imply separate jar files.



Yes, certainly having different build targets, probably different jars, (and
maybe on big jar if one wants everything ?), and also maybe reorganising the
top level directory to reflect this ...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Matt Clark]

I like Stuart's idea, but I can see those dependency declarations
becoming repetitive in any significantly large project.  I think there
would need to be someway to declare dependencies on a larger scope,
perhaps application wide, or some mechanism to describe dependencies
for sets of namespaces.

I also think it's worth supporting artifact, group and version
information for a given dependency so users, or even an automated tool
can easily go out to maven repositories and download them as needed.
I think there is a case here for a simple automated tool to use maven
repositories to satisfy dependencies, but I am far from an expert in
this realm.  I think buildr does something similar, but someone can
correct me if I'm wrong.

-Matt

On Apr 14, 12:38 pm, Konrad Hinsen  wrote:
> On Apr 14, 2009, at 17:17, Laurent PETIT wrote:
>
> > The problem will then be that the next time I checkout clojure-
> > contrib, BLAM I can't compile it because I need to download a jar  
> > from somewhere on the web ...
>
> That could be avoided by including the Clojure source in clojure-
> contrib, but not add it to the libraries to be precompiled in  
> build.xml. I suspect that it would even be possible to add specific  
> compilation targets for libraries that have external dependencies,  
> but I don't know ant well enough to be certain.
>
> Note that I am not proposing any dependency management, just separate  
> compilation targets for "clojure-only" libraries and "depends-on-XYZ"  
> libraries. For a precompiled jar distribution, that would probably  
> imply separate jar files.
>
> Konrad.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Konrad Hinsen]

On Apr 14, 2009, at 17:17, Laurent PETIT wrote:

> The problem will then be that the next time I checkout clojure- 
> contrib, BLAM I can't compile it because I need to download a jar  
> from somewhere on the web ...

That could be avoided by including the Clojure source in clojure- 
contrib, but not add it to the libraries to be precompiled in  
build.xml. I suspect that it would even be possible to add specific  
compilation targets for libraries that have external dependencies,  
but I don't know ant well enough to be certain.

Note that I am not proposing any dependency management, just separate  
compilation targets for "clojure-only" libraries and "depends-on-XYZ"  
libraries. For a precompiled jar distribution, that would probably  
imply separate jar files.

Konrad.




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Laurent PETIT]

The problem will then be that the next time I checkout clojure-contrib, BLAM
I can't compile it because I need to download a jar from somewhere on the
web ...

But in the other end, this seems inevitable for the parts that will really
*need* those libs.

Maybe it's time to make clojure-contrib more modular.

It will be very difficult to speak about it without the discussion switching
to a dependency management tool war  OR to keep things simple, add the
dependencies (if their license allow it *OUCH*) in some libs/ directory in
clojure-contrib itself.

I guess Meikel Brandmeyer somewhat started  to show the path by already
offering a split of clojure-contrib in several more modular units.

AGAIN, I would be very unhappy to have to download even one or two jars from
the web in order to be able to compile clojure-contrib if I just want to use
a namespace of it that has nothing to do with the downloaded jar, either
directly or indirectly ...

2009/4/14 Stuart Sierra 

>
> On Apr 14, 8:19 am, Rich Hickey  wrote:
> > I've been thinking recently about contribs with dependencies.
> ...
> > I'd like to start a discussion about how best to support the
> > contributions of libraries that depend on things not in the JDK.
>
> I'm ok with contribs depending on non-JDK libs, as long as they're
> clearly labeled.
>
> How about a flag on the ns declaration?  If the ns can't find a Java
> class that it needs to import, it displays an error with the name of
> the library and where to download it.  Something vaguely like:
>
> (ns clojure.contrib.foo
>  (:import (org.foo.lib FooFactory)
>  (:needs (org.foo.lib :name "FooLib", :url "http://foo.com/
> lib", :version "1.2")))
>
> I'm NOT proposing a dependency management system to download and
> install the JAR files.  That way lies madness.
>
> -Stuart Sierra
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Google includes Clojure in App Engine demo

[Stuart Sierra]

On Apr 13, 9:44 pm, levand  wrote:
> As a demo of JVM languages running on the Google App Engine, they
> included a Clojure REPL.

Nifty. Printing doesn't seem to work.
-S

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[David Nolen]

Ooops didn't finish that thought. But my point was that I think some of the
libraries in consideration stand apart in terms of convenience vs. actual
utility.
Not so sure about how to deploy this stuff ;) Stuart's ideas seems
reasonable, though again, Clojure already includes some external source
(compiler stuff), perhaps some of these things should be included in core if
possible?

Some of the libraries really save development resources by not reinventing
the wheel, and having them delivered in some way with Clojure means that
newcomers don't have to make the same mistakes over and over again (writing
matrix math Clojure apps on top of Clojure vectors...)

On Tue, Apr 14, 2009 at 11:01 AM, David Nolen wrote:

> Joda Time, Colt, Fork/Join seem like projects that truly add something to
> Clojure. These are projects which solve problems that developers have come
> to expect from their respective language.
> Joda Time - sane date/time (really useful when building web services).
> Colt - enough people want to do graphics related projects (and have done)
> that built in support for matrix math would be really great.
> fork/join - not my expertise, but again a lot of posts about parallel
> computation.
>
>
> On Tue, Apr 14, 2009 at 8:19 AM, Rich Hickey  wrote:
>
>>
>> I've been thinking recently about contribs with dependencies.
>>
>> I think it's very important to have layers - e.g. core depends only on
>> JDK 1.5, contrib only on core. Lately there have been some ideas
>> centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
>> etc.
>>
>> I'd like to start a discussion about how best to support the
>> contributions of libraries that depend on things not in the JDK.
>>
>> Obviously, without care and rules it could get crazy quickly, and I
>> want to avoid the kitchen-sink effect. It is very important that
>> things remain [truly, not just apparently] simple.
>>
>> Looking for suggestions,
>>
>> Rich
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Maven access to nightly builds

[Brian Sletten]

Cool, thanks Howard. That is helpful and I know how much you love  
Maven, so it is appreciated. :)

On Apr 14, 2009, at 10:52 AM, Howard Lewis Ship wrote:

>
> Both Clojure and Clojure-Contrib are now available as nightly builds
> from the Tapestry360 Maven snapshot repository.
>
> To access the nightly snapshots in Maven, you must update your
> pom.xml's  element (creating it as necessary):
>
> 
>  
>  tapestry-snapshots
>  http://tapestry.formos.com/maven-snapshot-repository/ url>
>  
> 
>
> You can then add a  for Clojure:
>
> 
>   org.clojure
>   clojure-lang
>   1.0-SNAPSHOT
> 
>
>
> You can then add a  for Clojure-Contrib:
>
> 
>   org.clojure
>   clojure-contrib
>   1.0-SNAPSHOT
> 
>
> Clojure-Contrib has a transitive dependency to the clojure-lang
> artifact: you only need include one of these,
> not both.
>
>
> Note that the repository includes a sources JAR (most IDEs will
> download it automatically, which may help with debugging).  In
> addition, there's a "slim" variant, where the clojure
> sources are NOT pre-compiled:
>
> 
>   org.clojure
>   clojure-lang
>   1.0-SNAPSHOT
>   slim
> 
>
> clojure-contrib also has a "slim" jar.
>
> Hope this makes it easier to track with nightly builds.
>
> -- 
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What is the difference between :type and :tag metadata?

[Stuart Sierra]

On Apr 13, 9:12 pm, Rich Hickey  wrote:
> :tag is applied to source forms to communicate type hints to the
> compiler. :type can be used, by convention, to add 'type names' to
> runtime data structures that support metadata. The type function will
> return the :type metadata if present, else the class, making it a
> handy dispatch function. Neither :tag nor :type are used directly by
> isa?

What about using maps as structured records, with a special key for
the "class".  Some people use :tag as the "class" key, some
use :type.  Should this be stored in metadata, rather than in the map
itself?

-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Stuart Sierra]

On Apr 14, 8:19 am, Rich Hickey  wrote:
> I've been thinking recently about contribs with dependencies.
...
> I'd like to start a discussion about how best to support the
> contributions of libraries that depend on things not in the JDK.

I'm ok with contribs depending on non-JDK libs, as long as they're
clearly labeled.

How about a flag on the ns declaration?  If the ns can't find a Java
class that it needs to import, it displays an error with the name of
the library and where to download it.  Something vaguely like:

(ns clojure.contrib.foo
  (:import (org.foo.lib FooFactory)
  (:needs (org.foo.lib :name "FooLib", :url "http://foo.com/
lib", :version "1.2")))

I'm NOT proposing a dependency management system to download and
install the JAR files.  That way lies madness.

-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[David Nolen]

Joda Time, Colt, Fork/Join seem like projects that truly add something to
Clojure. These are projects which solve problems that developers have come
to expect from their respective language.
Joda Time - sane date/time (really useful when building web services).
Colt - enough people want to do graphics related projects (and have done)
that built in support for matrix math would be really great.
fork/join - not my expertise, but again a lot of posts about parallel
computation.

On Tue, Apr 14, 2009 at 8:19 AM, Rich Hickey  wrote:

>
> I've been thinking recently about contribs with dependencies.
>
> I think it's very important to have layers - e.g. core depends only on
> JDK 1.5, contrib only on core. Lately there have been some ideas
> centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
> etc.
>
> I'd like to start a discussion about how best to support the
> contributions of libraries that depend on things not in the JDK.
>
> Obviously, without care and rules it could get crazy quickly, and I
> want to avoid the kitchen-sink effect. It is very important that
> things remain [truly, not just apparently] simple.
>
> Looking for suggestions,
>
> Rich
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Laurent PETIT]

2009/4/14 Laurent PETIT 

> Great initiative !
>
> Some thoughts I had when reading your proposal:
>
> 2009/4/14 Tom Faulhaber 
>
>
>> [This is specifically for contrib authors, but also for anyone whose
>> interested.]
>>
>> There was some discussion (or maybe the wailing and gnashing of teeth)
>> about the fact that there's lots of cool functionally coming into
>> clojure.contrib but no easily accessible documentation. I had been
>> thinking about this already and figured maybe I'd set up the framework
>> for fixing it.
>>
>> My idea is to use the namespace and var metadata to auto-generate a
>> set of documentation that has:
>> - an overview page that lists the namespaces in contrib and presents a
>> summary of each derived from the namespace metadata.
>> - each entry on the namespace overview page will have a link to an API
>> page for that namespace. That page will be basically like the API page
>> on clojure.org.
>> - probably should have an index page as well, but I haven't thought
>> about it much.
>> - an ability to link from a namespace to a custom created piece of
>> documentation (like the nice DatalogOverview that Jeffery wrote).
>>
>> I've written the code that builds (a first cut of) this stuff from the
>> namespaces. It uses the following metadata:
>>
>> On the namespace:
>> - :author to supply a string with the author(s) name(s)
>> - :wiki-doc to supply a wiki specific doc string (that can include
>> wiki markup) or, if that doesn't exist, we fall back to
>> - :doc the default doc string
>
>
> Could this be made a little bit more generic ? (If you find it useful) :
>
> Have a global var *rich-doc-renderers* which holds a map of
> type-of-rich-documentation to a map of renderer functions indexed by type of
> output (mime/type such as plain/html , plain/text for the :doc ...). This
> var could be enriched by libraries willing to contribute new standards :
> they would provide in the same time a new type of doc, and also ways to
> transform these docs into output formats:
>
> Example of *rich-doc-renderers* "out-of-the-box" could be :
>
> *rich-doc-renderers* { :default { :plain/html some.namespace/some-fn
> :plain/text some.namespace/some-other-fn ... } } ; default is what would be
> used for clojure / clojure-contrib ;
>
> And we could have a :rich-doc instead of :wiki-doc , with a simple version
> (if the default type of rich doc is to be used) and an extended version:
>
> simple version :rich-doc "my rich doc" => the type of formatting content to
> be used is :default , one can use the provided renderers for :default
>
> extended version :rich-doc { :type :default :content "my rich doc" } =>
> this version explicits the type of doc in :content. Of course for the
> general case it's not needed, but if a lib implementor wants to enrich
> *rich-doc-renderers* with  a new set of renderers, it could be interesting ?
>

Of course, some rules could be used to smoothly downgrade the documentation
if the renderers throw exceptions, or are impossible to load ... :

the doc function could use this simple algorithm :
find the :doc tag.
   If found, use it
   If not found, try to use :rich-doc with a :plain/text renderer

the function for getting :rich-doc in a particular format could use this
simple algorithm :
find the :rich-doc tag
  if not found: find the :doc tag. if found, use it. if not found, return
nil or "".
  if found :
if it's a string, find and load the renderer for the :default type and
the expected output format (if exception in the chain, try to return the
:doc tag content)
if it's a map, get the value for :type, try to resolve it in
*rich-doc-renderers*, and then search and load the renderer function for the
expected output format (again, if exception in the chain, try to return the
:doc tag content)
if neither a string or map, ? (throw an exception, or defaults to the
doc with a warning message on *err* ?)


Well,

something like that ...



>
>
> One problem I can see with my proposal is that it forces the rendering part
> to be an explicit dependency (*rich-doc-renderers* references functions).
> Maybe this could be loosened by requiring symbols and not fns in the map ?
>
>
> Do you thing it's interesting, or overkill ?
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Maven access to nightly builds

[Howard Lewis Ship]

Both Clojure and Clojure-Contrib are now available as nightly builds
from the Tapestry360 Maven snapshot repository.

To access the nightly snapshots in Maven, you must update your
pom.xml's  element (creating it as necessary):

 
  
  tapestry-snapshots
  http://tapestry.formos.com/maven-snapshot-repository/
  
 

You can then add a  for Clojure:

 
   org.clojure
   clojure-lang
   1.0-SNAPSHOT
 


You can then add a  for Clojure-Contrib:

 
   org.clojure
   clojure-contrib
   1.0-SNAPSHOT
 

Clojure-Contrib has a transitive dependency to the clojure-lang
artifact: you only need include one of these,
not both.


Note that the repository includes a sources JAR (most IDEs will
download it automatically, which may help with debugging).  In
addition, there's a "slim" variant, where the clojure
sources are NOT pre-compiled:

 
   org.clojure
   clojure-lang
   1.0-SNAPSHOT
   slim
 

clojure-contrib also has a "slim" jar.

Hope this makes it easier to track with nightly builds.

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Javascript generator

[David Nolen]

Cool! Rather then waiting, you could host it in the interim on GitHub or
Google Code so people like myself can submit patches (which I'm more than
willing to do) ;) Just a thought...
A couple of things:

(println
 (javascript (var x)))

I would expect this to convert to:

var x;

It does not.

(println
 (javascript (new Object {prop1 "a" prop2 "b"})))
> var MyClass = new(ClassGenerator, {prop1:"a",prop2:"b"});

Instead of ,

var MyClass = new ClassGenerator({prop1:"a", prop2:"b"});

This idiom is essential to MooTools, a JS library I use quite a bit.

The other thought that I had was how to use macros with js-gen? The
javascript macro pretty much captures everything and doesn't allow macros to
be embedded. Seems like this would be quite handy.

I've been contemplating writing a system which generates tagged javascript
so that it can be sanely debugged if generated server side via Clojure.

On Tue, Apr 14, 2009 at 9:07 AM, jim  wrote:

>
> I'll be glad to support it if people choose to use it and report
> issues. My plans to use are still on my todo list, things just keep
> getting put on top of them. One of which is to get my own server set
> up to host this and some other projects.
>
> I'll check out those asserts and make them so they're not dependent on
> order.  Have you seen anything else that needs to be fixed?
>
> Thanks
> Jim
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Javascript generator

[David Nolen]

Cool! Rather then waiting, you could host it in the interim on GitHub or
Google Code so people like myself can submit patches (which I'm more than
willing to do) ;) Just a thought...
A couple of things:

(println
 (javascript (var x)))

I would expect this to convert to:

var x;

It does not.

(println
 (javascript (new Object {prop1 "a" prop2 "b"})))
> var MyClass = new(ClassGenerator, {prop1:"a",prop2:"b"});

Instead of ,

var MyClass = new ClassGenerator({prop1:"a", prop2:"b"});

This idiom is essential to MooTools, a JS library I use quite a bit.

The other thought that I had was how to use macros with js-gen? The
javascript macro pretty much captures everything and doesn't allow macros to
be embedded. Seems like this would be quite handy.

I've been contemplating writing a system which generates tagged javascript
so that it can be sanely debugged if generated server side via Clojure.

On Tue, Apr 14, 2009 at 9:07 AM, jim  wrote:

>
> I'll be glad to support it if people choose to use it and report
> issues. My plans to use are still on my todo list, things just keep
> getting put on top of them. One of which is to get my own server set
> up to host this and some other projects.
>
> I'll check out those asserts and make them so they're not dependent on
> order.  Have you seen anything else that needs to be fixed?
>
> Thanks
> Jim
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Laurent PETIT]

Great initiative !

Some thoughts I had when reading your proposal:

2009/4/14 Tom Faulhaber 

>
> [This is specifically for contrib authors, but also for anyone whose
> interested.]
>
> There was some discussion (or maybe the wailing and gnashing of teeth)
> about the fact that there's lots of cool functionally coming into
> clojure.contrib but no easily accessible documentation. I had been
> thinking about this already and figured maybe I'd set up the framework
> for fixing it.
>
> My idea is to use the namespace and var metadata to auto-generate a
> set of documentation that has:
> - an overview page that lists the namespaces in contrib and presents a
> summary of each derived from the namespace metadata.
> - each entry on the namespace overview page will have a link to an API
> page for that namespace. That page will be basically like the API page
> on clojure.org.
> - probably should have an index page as well, but I haven't thought
> about it much.
> - an ability to link from a namespace to a custom created piece of
> documentation (like the nice DatalogOverview that Jeffery wrote).
>
> I've written the code that builds (a first cut of) this stuff from the
> namespaces. It uses the following metadata:
>
> On the namespace:
> - :author to supply a string with the author(s) name(s)
> - :wiki-doc to supply a wiki specific doc string (that can include
> wiki markup) or, if that doesn't exist, we fall back to
> - :doc the default doc string


Could this be made a little bit more generic ? (If you find it useful) :

Have a global var *rich-doc-renderers* which holds a map of
type-of-rich-documentation to a map of renderer functions indexed by type of
output (mime/type such as plain/html , plain/text for the :doc ...). This
var could be enriched by libraries willing to contribute new standards :
they would provide in the same time a new type of doc, and also ways to
transform these docs into output formats:

Example of *rich-doc-renderers* "out-of-the-box" could be :

*rich-doc-renderers* { :default { :plain/html some.namespace/some-fn
:plain/text some.namespace/some-other-fn ... } } ; default is what would be
used for clojure / clojure-contrib ;

And we could have a :rich-doc instead of :wiki-doc , with a simple version
(if the default type of rich doc is to be used) and an extended version:

simple version :rich-doc "my rich doc" => the type of formatting content to
be used is :default , one can use the provided renderers for :default

extended version :rich-doc { :type :default :content "my rich doc" } => this
version explicits the type of doc in :content. Of course for the general
case it's not needed, but if a lib implementor wants to enrich
*rich-doc-renderers* with  a new set of renderers, it could be interesting ?

One problem I can see with my proposal is that it forces the rendering part
to be an explicit dependency (*rich-doc-renderers* references functions).
Maybe this could be loosened by requiring symbols and not fns in the map ?


Do you thing it's interesting, or overkill ?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enlive questions

[Christophe Grand]

Hello David,

David Nolen a écrit :
> Considering the above, I'm left wondering if it's possible to further 
> eliminate these redundancies and make templates more reusable. I'm not 
> sure if this is what you had in mind for Enlive, but allowing 
> templates to be created without references to files would make it 
> possible to build very, very composable interfaces.
> Of course it's quite possible that you can already do this with Enlive 
> and I'm just unclear about how to accomplish it.

I'm sorry for the lack of documentation.

The "source" of a template/snippet can either be:
- a string (a resource path resolved by the classloader)
- a File, URI or URL,
- a map (a "literal" xml/html tree).

A template is a function that returns a seq of strings. (It's the end of 
the "pipeline".)

A snippet is a function that now (in the "new" enlive) returns a seq of 
nodes. (I suppose I should add "seq of nodes" as a valid source type.)
Snippets are valid values on the right-hand side of rules. The only 
difference between templates and snippets is that templates serialize 
their return value.

> This is great.  I had thought that supporting some kind of partial 
> template thing would be interesting, but that's actually just my poor 
> logic at work ;)
>
> It seems like with the new version of Enlive I could do something like 
> this:
>
> (deftemplate pageA-template path
>   []
>   [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>
> (deftemplate pageB-template path
>   []
>   [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
> (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result)))
>
> (def pageAPartial (pageA-template))
> (def pageBPartial (pageB-template))
>
> ;; the following would work only if templates allowed passing html as 
> strings and not just as files
>
> (deftemplate widgetsPageA pageAPartial
>   [map]
>   [[:div (attr? :tiptree:widget)]] (fn [xml] 
> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>
> (deftemplate widgetsPageB pageBPartial
>   [map]
>   [[:div (attr? :tiptree:widget)]] (fn [xml] 
> (use-xml-attr-and-map-to-apply-and-return-a-snippet))
>
> (def pageA (widgetsPageA someMap))
> (def pageB (widgetsPageA someMap))
>

I suppose you really want to break the computation in two and not write:
(deftemplate pageA-template path
  [map]
  [[:div (attr? :tiptree:replace)]] (fn [xml-node] 
(find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
  [[:div (attr? :tiptree:widget)]] (fn [xml] 
(use-xml-attr-and-map-to-apply-and-return-a-snippet)))

or:
(deftemplate pageA-template path
  [map]
  [[:div (attr? :tiptree:replace)]]
(do->
  (fn [xml-node] 
(find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))
  (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet

(well, it would work if do-> has been ported to the new enlive)

Keeping in mind the difference between a snippet and a template, you 
will be able to do what you describe with the new enlive once I 
implement 'attr? and add support for seq of nodes as a valid source type.


hth,

Christophe

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Sean]

This feature would be very useful, as I know I spend too much time in
re-implementing stuff that exists in contrib. However, contrib isn't
the only library that needs to be documented.  Besides the doc-string
metadata, is there any type of Clojure-doc, similar to Java-doc?

Is there utility to generate HTML docs that is part of Clojure contrib/
core?

On Apr 14, 7:37 am, Rich Hickey  wrote:
> On Apr 13, 11:14 pm, Tom Faulhaber  wrote:
>
>
>
> > [This is specifically for contrib authors, but also for anyone whose
> > interested.]
>
> > There was some discussion (or maybe the wailing and gnashing of teeth)
> > about the fact that there's lots of cool functionally coming into
> > clojure.contrib but no easily accessible documentation. I had been
> > thinking about this already and figured maybe I'd set up the framework
> > for fixing it.
>
> > My idea is to use the namespace and var metadata to auto-generate a
> > set of documentation that has:
> > - an overview page that lists the namespaces in contrib and presents a
> > summary of each derived from the namespace metadata.
> > - each entry on the namespace overview page will have a link to an API
> > page for that namespace. That page will be basically like the API page
> > on clojure.org.
> > - probably should have an index page as well, but I haven't thought
> > about it much.
> > - an ability to link from a namespace to a custom created piece of
> > documentation (like the nice DatalogOverview that Jeffery wrote).
>
> > I've written the code that builds (a first cut of) this stuff from the
> > namespaces. It uses the following metadata:
>
> > On the namespace:
> > - :author to supply a string with the author(s) name(s)
> > - :wiki-doc to supply a wiki specific doc string (that can include
> > wiki markup) or, if that doesn't exist, we fall back to
> > - :doc the default doc string
>
> > On the vars, I use:
> > :wiki-doc and :doc, as above
> > :macro - to indicate if it's a macro
> > :arglists to grab the arglist
>
> > The last two are set automatically by defn and defmacro.
>
> > AUTHORS PLEASE NOTE: In order for this to be useful these fields need
> > to be filled in for your contributions. The system will work without
> > it, just not as nicely.
>
> > The next stage of my plan is to build a robot that watches the
> > subversion repository and updates the doc on every checkin. Therefore
> > the doc will typically correspond to the tip of the tree.
>
> > To avoid thinking too hard, I'm planning to use the wiki on
> > clojure.contrib's googlecode page because (a) there's almost nothing
> > on it now and (b) it's easy to use subversion to update stuff there.
> > Whether this is the right place long-term is another question that we
> > can worry about once it's running.
>
> > Does all of this seem like the right direction? Comments? Suggestions?
>
> The wiki on clojure.contrib's googlecode page is definitely the right
> place for the contrib docs, contrib members should please feel free to
> use it. That's one of the reasons I moved to googlecode.
>
> Thanks,
>
> Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Javascript generator

[jim]

I'll be glad to support it if people choose to use it and report
issues. My plans to use are still on my todo list, things just keep
getting put on top of them. One of which is to get my own server set
up to host this and some other projects.

I'll check out those asserts and make them so they're not dependent on
order.  Have you seen anything else that needs to be fixed?

Thanks
Jim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this 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: clj-android

[Remco van 't Veer]

On Tue, Apr 14, 2009 at 2:40 PM, Rich Hickey  wrote:
> On Apr 9, 10:28 am, "Remco van 't Veer"  wrote:
>> On Thu, Apr 9, 2009 at 3:17 PM, Rich Hickey  wrote:
>> A blocker for dalvik is issue 77;
>>
>>  http://github.com/remvee/clojure/commit/7c110dc00895dea8e583e122acc64...
>
> Did this fix your problem?
>
> http://code.google.com/p/clojure/source/detail?r=1344

Yes it does.  Thanks!

Remco

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this 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: clj-android

[Rich Hickey]

On Apr 9, 10:28 am, "Remco van 't Veer"  wrote:
> On Thu, Apr 9, 2009 at 3:17 PM, Rich Hickey  wrote:
> > On Apr 9, 8:03 am, "Remco van 't Veer"  wrote:
> >> On Thu, Apr 9, 2009 at 1:23 PM, Onorio Catenacci  
> >> wrote:
> >> > [..]
>
> >> > I know you were mentioning some real performance issues when starting
> >> > a Clojure app fromAndroid(I see them too).  I wonder if using
> >> > TraceView to profile the Dalvik code generated by the conversion from
> >> > the Clojure bytecode might point us to something to fix the startup
> >> > time?  I'll try this myself--I just thought I might ask you if you'd
> >> > already done this and if it were a waste of time or not. :-)
>
> >> I've used the mentioned profiler and I did some performance tweaks
> >> already, thus the clojure fork on github.
>
> > Is that still needed after:
>
> >http://code.google.com/p/clojure/issues/detail?id=78
>
> Yes, the fork has two extra tweaks in place and a workaround for dalvik.
>
> A blocker for dalvik is issue 77;
>
>  http://github.com/remvee/clojure/commit/7c110dc00895dea8e583e122acc64...
>

Did this fix your problem?

http://code.google.com/p/clojure/source/detail?r=1344

Rich


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Jason Sankey]

Hi Tom,

Tom Faulhaber wrote:

> The next stage of my plan is to build a robot that watches the
> subversion repository and updates the doc on every checkin. Therefore
> the doc will typically correspond to the tip of the tree.


I'd be happy to add generation/upload of documentation as a build step 
or even separate project on the server at http://pulse.zutubi.com/.  It 
already has the ability to trigger on every change, so there would be no 
need to create a separate robot to check for changes.  Just let me know 
if you think this would be helpful.

Cheers,
Jason


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: The :file metadata key value

[Chouser]

On Tue, Apr 14, 2009 at 3:12 AM, Kei Suzuki  wrote:
>
> In the recent releases it looks the value of the :file metadata key
> for the core functions changed from "core.clj" to "clojure/core.clj".
> Because of the change the get-source function of the
> clojure.contrib.repl-utils library, for example, now fails to get the
> source code of the core functions (I remember the function was working
> before).

I've fixed repl-utils/source in contrib 667.  Thanks for the report.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Konrad Hinsen]

On Apr 14, 2009, at 5:14, Tom Faulhaber wrote:

> My idea is to use the namespace and var metadata to auto-generate a
> set of documentation that has:
> - an overview page that lists the namespaces in contrib and presents a
> summary of each derived from the namespace metadata.
> - each entry on the namespace overview page will have a link to an API
> page for that namespace. That page will be basically like the API page
> on clojure.org.
> - probably should have an index page as well, but I haven't thought
> about it much.
> - an ability to link from a namespace to a custom created piece of
> documentation (like the nice DatalogOverview that Jeffery wrote).

That sounds like an excellent idea! I'd be happy to add metadata to  
my code to support such a system.

The only aspect of your proposal that I am not happy about is this:

> On the namespace:
> - :author to supply a string with the author(s) name(s)
> - :wiki-doc to supply a wiki specific doc string (that can include
> wiki markup) or, if that doesn't exist, we fall back to
> - :doc the default doc string

Since the standard docstring in :doc is required for Clojure's built- 
in doc and find-doc, your proposal amounts to having a copy of the  
docstring with wiki formatting added in :wiki-doc. I don't like the  
idea of duplicating the docstring for several reasons:

- sooner or later :doc and :wiki-doc will differ because an update is  
applied to only one of them
- it implies extra work for every single documented function
- it makes the code harder to read, all the more because there is no  
syntax support for :wiki-doc.

I would prefer to have a single docstring containing optional markup.  
There are (at least) two possibilities:

1) Use a very lightweight markup that preserves readability even  
without any processing.
2) Add a markup stripper/transformer to Clojure's doc and find-doc  
functions.

> The next stage of my plan is to build a robot that watches the
> subversion repository and updates the doc on every checkin. Therefore
> the doc will typically correspond to the tip of the tree.

That's a nice feature.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

[Discuss] Contribs with dependencies

[Rich Hickey]

I've been thinking recently about contribs with dependencies.

I think it's very important to have layers - e.g. core depends only on
JDK 1.5, contrib only on core. Lately there have been some ideas
centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
etc.

I'd like to start a discussion about how best to support the
contributions of libraries that depend on things not in the JDK.

Obviously, without care and rules it could get crazy quickly, and I
want to avoid the kitchen-sink effect. It is very important that
things remain [truly, not just apparently] simple.

Looking for suggestions,

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Got a Clojure library?

[Rich Hickey]

On Apr 13, 1:31 pm, mikel  wrote:
> Name: xg-model, xg-gf
> URL:  http://code.google.com/p/explorersguild/source/clj/com/explorersguild
>Instructions for checking out code are at:
>http://code.google.com/p/explorersguild/source/checkout
> Files: util.clj, gf.clj, model.clj, model_gf.clj
> Author: mikel evins
> Tags: generic functions, models, dispatch
> License: EPL
> Dependencies: none
> Description: Provides:
>
>   model: an implementation of extensible record types with optional
> value constraints on fields
>
>   gf:an implementation of CLOS_style generic functions. gf domains
> provide a means of defining dispatch algorithms. Example domains are
> provided that implement CLOS-style dispatch over Java classes, and
> simple predicate-dispatch. Included is a dispatch domain that
> implements multimethod dispatch on XG models.

Thanks! It looks like that first link is broken?

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Rich Hickey]

On Apr 13, 11:14 pm, Tom Faulhaber  wrote:
> [This is specifically for contrib authors, but also for anyone whose
> interested.]
>
> There was some discussion (or maybe the wailing and gnashing of teeth)
> about the fact that there's lots of cool functionally coming into
> clojure.contrib but no easily accessible documentation. I had been
> thinking about this already and figured maybe I'd set up the framework
> for fixing it.
>
> My idea is to use the namespace and var metadata to auto-generate a
> set of documentation that has:
> - an overview page that lists the namespaces in contrib and presents a
> summary of each derived from the namespace metadata.
> - each entry on the namespace overview page will have a link to an API
> page for that namespace. That page will be basically like the API page
> on clojure.org.
> - probably should have an index page as well, but I haven't thought
> about it much.
> - an ability to link from a namespace to a custom created piece of
> documentation (like the nice DatalogOverview that Jeffery wrote).
>
> I've written the code that builds (a first cut of) this stuff from the
> namespaces. It uses the following metadata:
>
> On the namespace:
> - :author to supply a string with the author(s) name(s)
> - :wiki-doc to supply a wiki specific doc string (that can include
> wiki markup) or, if that doesn't exist, we fall back to
> - :doc the default doc string
>
> On the vars, I use:
> :wiki-doc and :doc, as above
> :macro - to indicate if it's a macro
> :arglists to grab the arglist
>
> The last two are set automatically by defn and defmacro.
>
> AUTHORS PLEASE NOTE: In order for this to be useful these fields need
> to be filled in for your contributions. The system will work without
> it, just not as nicely.
>
> The next stage of my plan is to build a robot that watches the
> subversion repository and updates the doc on every checkin. Therefore
> the doc will typically correspond to the tip of the tree.
>
> To avoid thinking too hard, I'm planning to use the wiki on
> clojure.contrib's googlecode page because (a) there's almost nothing
> on it now and (b) it's easy to use subversion to update stuff there.
> Whether this is the right place long-term is another question that we
> can worry about once it's running.
>
> Does all of this seem like the right direction? Comments? Suggestions?
>

The wiki on clojure.contrib's googlecode page is definitely the right
place for the contrib docs, contrib members should please feel free to
use it. That's one of the reasons I moved to googlecode.

Thanks,

Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: The :file metadata key value

[Meikel Brandmeyer]

Hi,

Am 14.04.2009 um 09:12 schrieb Kei Suzuki:


Isn't the value supposed to be a simple file name? Is the format of
the value up to the one who sets it?


The value is a simple file name. However up to now it
was only the basename of the file. Now suppose that
(:file ^some-var) says "foo.clj" and you have bar/foo.clj
and frob/foo.clj. Which to choose? Also a multifile
namespace might load files from a subdirectory. So
constructing the filename from the namespace and the
:file key does not work correctly.

To remove this ambiguity the change was to provide
the file name fully qualified. Depending on how the
file was loaded this means:
- relative to the Classpath when loaded from there
- or an absolute filename when loaded via load-file.

This allows to find the correct source position in 100%
of the cases. In the first case, we can simply go on as
before and read from the Classpath. In the second case
we can access the file directly.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

The :file metadata key value

[Kei Suzuki]

In the recent releases it looks the value of the :file metadata key
for the core functions changed from "core.clj" to "clojure/core.clj".
Because of the change the get-source function of the
clojure.contrib.repl-utils library, for example, now fails to get the
source code of the core functions (I remember the function was working
before).

Isn't the value supposed to be a simple file name? Is the format of
the value up to the one who sets it?

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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: A clojure server

[Konrad Hinsen]

On 05.04.2009, at 17:35, Christian von Essen wrote:

> Yeah, I'll try providing some documentation for that. As for MacOS X,
> I don't have any, so we have to figure it out together, or hope that
> anyone else knows how to do it :)

I looked at this yesterday. Apparently all those headers and  
libraries are for JNI, which works quite differently under MacOS,  
where all that is part of the JavaVM framework. Under MacOSX, there  
is thus no JAVATOP at all.

I got the library to compile with:

CXXFLAGS = -I/System/Library/Frameworks/JavaVM.framework/Headers - 
DPOSIX_STRERROR_R -DSIGDANGER -DSIGMAX -DHAS_SEM_POST - 
Dsigthreadmask=pthread_sigmask -fPIC

libposix.jnilib: $(POSIX_OBJS)
g++ -bundle -o libposix.dnilib $(POSIX_OBJS) -lpthread

I didn't find the time to test it yet though. Is there a simpler test  
than installing and testing clj-server?

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---