Re: [ANN] excel-templates 0.3.2 release available

[Tom Faulhaber]

I'm glad the library is helping you, Ralf. Thanks for the feedback!

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

[ANN] excel-templates 0.3.2 release available

[Tom Faulhaber]

*Our Story*

In this episode, our hero discovers the betrayal of his former ally, the 
Apache POI library, and goes to great lengths to patch things up between 
them, while beginning to dream of the day when they can part ways 
.

And thus, excel-templates 0.3.2 
 was created.

*The #1 feature of this release: cloning charts.*

Worksheets with charts on them can now be cloned and the charts are copied 
and updated correctly. As an example, consider that you want a separate 
sheet for each stock in your portfolio and each sheet should have a chart 
showing the year-to-date performance of the stock. This will do it! (In 
fact, this precise example is in the latest excel-templates-example 
.)

Otherwise, this release fixed most of the known bugs, especially some 
problems that Windows users were having. (People want to use Excel on 
Windows? Who knew?). A full list of the bugs fixed in this release are on 
the GitHub issues page for the 0.3.2 milestone 

.

I want to thank the users who submitted bug reports. The pull requests and 
nice, clear bug reports made most of the problems easy to fix.

*What is Excel Templates anyway?*

Excel Templates is a library that lets you build beautiful spreadsheets 
from pure Clojure data. I gave a talk on it at Clojure/West last year where 
you can see it in action: https://www.youtube.com/watch?v=qnJs79W0BDo

I'm always interested in feedback or new ideas for this library.

Enjoy,

Tom

P.S. If there's anyone who's interested in what an Excel file looks like on 
the inside (hint: it's a zip file full of XML files), I've made a little 
script that expands it into a directory of files and nicely formats the 
XML: https://gist.github.com/tomfaulhaber/4f1db38af6e57ac648e9.

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

Re: Does Pedestal have a future in the long run

[Tom Faulhaber]

On Monday, November 11, 2013 6:38:23 AM UTC-8, Brenton wrote:

> If you are looking for something that is finished and stable then do not 
> look at Pedestal. We will indicate stability with version numbers. When you 
> see a release of version 1.0 then you may want to have another look. A 1.0 
> release will not happen until we have thorough reference documentation.
>
>
If I waited for Clojure libraries to go to 1.0, I still be in Python or 
Java! (Not quite true, but within epsilon.)

Just scroll through the topics of this list for confirmation. Even within 
the Clojure organization, the only project that's made it to 1.0 is Clojure 
core on the JVM.
 

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

Re: Incanter 1.5.2 has been released

[Tom Faulhaber]

The documentation is, in general, updated automatically when there is a 
github checkin that causes a change to the docs.

However, github doesn't seem to trigger a webhook call when a tag is added, 
so autodoc didn't get called.

I just ran it manually and we're now happily in 1.5.2-land.

Tom

On Monday, August 5, 2013 7:46:24 AM UTC-7, Alex Ott wrote:
>
> I don't know, how often the documentation is regenerated - I think, that 
> Tom can clarify this...
>
>
> On Mon, Aug 5, 2013 at 3:19 PM, Jakub Holy 
> > wrote:
>
>> I can see that http://liebke.github.io/incanter/core-api.html still 
>> reads "Incanter 1.5.1" so either it hasn't been long enough since you 
>> tagged it or something else must be done to update the docs.
>>
>> Thank you!
>>
>>
>> On Monday, August 5, 2013 8:10:38 AM UTC+2, Alex Ott wrote:
>>
>>> Ooops, completely forgot to do this - it's done now
>>>
>>> thank you
>>>
>>>
>>> On Mon, Aug 5, 2013 at 3:55 AM, Tom Faulhaber wrote:
>>>
>>>> Thanks for keeping the ball rolling, Alex. We appreciate it very much!
>>>>
>>>> Could you tag the release on github so that autodoc will build for it 
>>>> correctly? 
>>>>
>>>> Thanks,
>>>>
>>>> Tom
>>>>
>>>>
>>>> On Sunday, August 4, 2013 11:20:07 AM UTC-7, Alex Ott wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>> I've just pushed new release of Incanter to Clojars. This is mostly 
>>>>> bugfix release. More information is at http://data-sorcery.org/2013/**
>>>>> 0**8/04/incanter-1-5-2-bugfix-**rel**ease/<http://data-sorcery.org/2013/08/04/incanter-1-5-2-bugfix-release/>
>>>>>
>>>>> -- 
>>>>> With best wishes,Alex Ott
>>>>> http://alexott.net/
>>>>> Twitter: alexott_en (English), alexott (Russian)
>>>>> Skype: alex.ott 
>>>>>
>>>>  -- 
>>>> -- 
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>>
>>>> Note that posts from new members are moderated - please be patient with 
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@**googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en>
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to clojure+u...@**googlegroups.com.
>>>>
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>  
>>>>  
>>>>
>>>
>>>
>>>
>>> -- 
>>> With best wishes,Alex Ott
>>> http://alexott.net/
>>> Twitter: alexott_en (English), alexott (Russian)
>>> Skype: alex.ott 
>>>
>>  -- 
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Incanter" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to incanter+u...@googlegroups.com .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
> Skype: alex.ott 
>

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

Re: Incanter 1.5.2 has been released

[Tom Faulhaber]

Thanks for keeping the ball rolling, Alex. We appreciate it very much!

Could you tag the release on github so that autodoc will build for it 
correctly? 

Thanks,

Tom

On Sunday, August 4, 2013 11:20:07 AM UTC-7, Alex Ott wrote:
>
> Hi all
>
> I've just pushed new release of Incanter to Clojars. This is mostly bugfix 
> release. More information is at 
> http://data-sorcery.org/2013/08/04/incanter-1-5-2-bugfix-release/
>
> -- 
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
> Skype: alex.ott 
>

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

Re: Offline Clojure docs

[Tom Faulhaber]

Sorry, my second method should have been:

$ curl  -L https://github.com/clojure/clojure/archive/gh-pages.tar.gz | tar 
xvzf -

Enjoy!

Tom

On Sunday, June 30, 2013 7:44:17 PM UTC-4, David Pollak wrote:
>
> Folks,
>
> Is there an offline package of Clojure docs (the full core.* api docs, 
> cheat sheets, etc.)?
>
> I'm traveling with intermittent Internet connectivity (I'm in China now 
> and it's marginal but I'm going to the UP in Michigan where there's no 
> Internet within 15 miles of where I'm staying).
>
> With all the travel and flying and such, it'd be great to have all the 
> docs without having to clone all the various source repositories.
>
> Thanks for your help.
>
> David
>

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

Re: Offline Clojure docs

[Tom Faulhaber]

It's easy to pull the autodoc documentation for offline use. You can either 
do this:

$ git clone https://github.com/clojure/clojure.git clojure-api
$ cd clojure-api
$ git checkout gh-pages

or you can just open 
"https://github.com/clojure/clojure/archive/gh-pages.zip"; or pull the 
directory with 

$ curl  -L https://github.com/clojure/clojure/archive/gh-pages.tar.gz | tar 
tvzf -

The same method works for all the contrib docs (though there isn't a 
command that gets all the docs) and incanter as well.

HTH,

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

Re: ANN: lambic v. 0.1.0

[Tom Faulhaber]

+1

I've always thought that this sort of thing should be more decorative and 
transparent with the tools we have in Clojure, core.match, and core.logic. 
This is a neat way to proceed.

I'll be keeping my eyes on your progress!

Tom

On Thursday, June 14, 2012 4:44:10 PM UTC-7, rob wrote:
>
> This announcement is more of a call for suggestions (even pull requests if 
> you are moved to do so) as there's not much to it yet, just enough to to 
> demonstrate the concept for simpler transformations.  I'm thinking of how 
> best to go about supporting a wider range of sequence transformations.
>
> https://github.com/rplevy/lambic
> https://clojars.org/lambic
>
> The basic idea is that languages like Prolog are very good at manipulating 
> sequences "by example" based on pattern matching, and that using core.match 
> this can become the norm for Clojure too (either using this library or some 
> other I don't yet know about.)
>
> In Clojure, when you encounter data that matches pattern X and you want to 
> systematically turn into data of the form Y, depending on how complex the 
> structures are, you tend to start with some solution, change it around, and 
> ultimately end up with a very elegant solution that is clearly the "best 
> way".
>
> My present take on how to implement lambic is essentially to catalog these 
> "best ways" for a number of different classes of sequence transformations, 
> so that lambic knows what to do with them.  What do you think of this idea? 
>  Is there a way to use logical magic (magical logic?) to do something 
> better? ;)
>

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

Re: Pretty-print with metadata

[Tom Faulhaber]

Chris, nice use of custom dispatch! I can't claim all the credit for
this mechanism. I based my work on the old XP system that has been
used in Lisp since the eighties. Standing on the shoulders of giants,
as it were. :)

It's been on my list to respect *print-meta* in the regular pprint
dispatch, but I'd like to improve the overall performance of pprint
(which is still slower than I'd like for large data structures) first.

In the meantime, this is a good solution.

Tom

On Jan 20, 2:51 pm, Chris Perkins  wrote:
> Good catch!  I was about to add this to my personal toolkit of "generally
> useful random crap" (every programmer has one of those, right?).  I'll make
> sure to cover that edge-case.  Thanks.
>
> - Chris

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

Re: marking deprecated functions, namespaces or other?

[Tom Faulhaber]

FWIW, autodoc looks for something like {:deprecated "1.3"}. See
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L201
which results in 
http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/agent-errors.

On Jan 6, 8:19 pm, Phil Hagelberg  wrote:
> Dave Sann  writes:
> > I sometimes have need to change the names of fns in some of my libs.
>
> > As I was doing this, I wondered - is there a way to mark a function or
> > namespace or other as deprecated?
>
> > I have not seen anything to this effect.
>
> Here's what I use in Leiningen:
>
> https://github.com/technomancy/leiningen/blob/1.x/src/leiningen/core
>
> For things that are just deprecated but not moved, probably just
> ^:deprecated or ^{:deprecated "1.3.1"} is probably best.
>
> -Phil

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

Re: ANN: Autodoc 0.9.0 (Finally!)

[Tom Faulhaber]

Daniel,

Glad, it's working for you!

Protocols and stuff are almost done, so I think I'm good there. I just
took a swerve off that path for a couple weeks to get things into
releasable form since so many were clearly feeling pain over it.

Expect more news on that front in the next few weeks.

Tom

On Jan 5, 8:59 am, semperos  wrote:
> Thanks Tom, works like a charm.
>
> Looking forward to support for protocols and the like. Where's a good place
> to start helping on that front?
>
> -Daniel

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

ANN: Autodoc 0.9.0 (Finally!)

[Tom Faulhaber]

A new version of Autodoc (0.9.0) is now available from clojars. This
version should work with all versions of Clojure that exist in the
wild and is generally more robust to weird dependency relationships
than previous versions.

For those who aren't familiar, Autodoc is the tool that is used to
generate the API documentation for Clojure (http://clojure.github.com/
clojure) and the various contrib libraries (see index under
construction at http://clojure.github.com).

Leiningen integration has been broken out into a separate project,
lein-autodoc (also 0.9.0), to provide better insulation between the
two.

Full documentation can be found at http://tomfaulhaber.github.com/autodoc.

New features in this version:
- Support for Clojure 1.3
- Single namespace projects will now longer have an extraneous
overview page
- An index.clj file is generated that contains all the documentation
info for the project in Clojure readable form.
- A bunch of little things I can't even remember

Coming soon: full documentation for protocols, types and records.

This version has not been tested on an extensive set of projects, so
please do let me know if you see any problems. You can file issues at
https://github.com/tomfaulhaber/autodoc or just email.

I do sincerely apologize to everyone who has been inconvenienced by my
long delay in getting this out. All the usual excuses apply.

I hope this helps with all your Clojure work,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Codox: an API doc generator for Clojure

[Tom Faulhaber]

Hi All,

This makes me feel quite embarrassed that autodoc hasn't seen a
release for non-core/contrib projects in so long. I apologize for
that. (Insert all the usual "life has been crazy... " caveats here.) I
hate seeing smart people having to recreate stuff just cause it's
taking me a long time to get around to it.

I had already put Autodoc on my "Christmas lull to-do list" and am
closing in on a new release. Depending how things go on disentagling
the recursive loop I've set up with Leiningen, I should have a 0.9.0
out this week.

Nicely, I think that Codox and Autodoc should coexist pretty happily
and Codox's life is somewhat simplified by not having to deal with the
core/contrib craziness (and not, I think, having to deal with
documenting multiple versions in the same package).

Tom

On Dec 26, 9:29 am, James Reeves  wrote:
> Hi folks,
>
> In order to generate the documentation for Ring and Compojure, I
> created Codox after being unable to get Autodoc working.
>
> Codox is pretty simple, but should work out of the box, and hopefully
> looks quite nice. Here are a couple of examples:
>
> http://mmcgrana.github.com/ring/http://weavejester.github.com/compojure/
>
> Options are limited so far, but patches to add options or improve the
> formatting are welcome.
>
> The project page is here:
>
> https://github.com/weavejester/codox
>
> - James

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

Re: multiple return values

[Tom Faulhaber]

Razvan,

I believe that proxy actually only creates a new class per call site,
not per instance. However, I can't completely swear to this.

Anyone with more detailed knowledge than I have want to comment?

Assuming I'm right,, you should be fine to have lots of instances.

HTH,

Tom

On Dec 13, 10:47 am, Razvan Rotaru  wrote:
> Thanks Tom. Using proxy like this could work. But i'm worried about
> one thing.What happens if I have many instances? With proxy there's a
> new class with each instance. Could I run out of permgen space?
>
> On Dec 13, 9:38 am, Tom Faulhaber  wrote:
>
>
>
>
>
>
>
> > Razvan,
>
> > I think that you can implement your idea of "extending the class with
> > proxy" in the following way (originally suggested to me by Rich Hickey
> > & Chris Houser for use with the pretty printer):
>
> > (let [extra-fields (ref {:field1 extra-value1, :field2 extra-value2}]
> >   (proxy [Writer IDeref]
> >     (deref [] extra-fields)
> >     (write [x] ...)
> >     other funcs))
>
> > You don't need to make the extra-values item a ref if you will set the
> > values immutably at create time.
>
> > You can see the full example of this 
> > athttps://github.com/clojure/clojure/blob/1f11ca3ef9cd0585abfbe4a9e7609...
>
> > The rest of that module is an abomination that was written when I was
> > still under the influence of CLOS & O-O.
>
> > Hope that helps,
>
> > Tom
>
> > On Dec 12, 5:10 pm, Stephen Compall  wrote:
>
> > > On Mon, 2011-12-12 at 10:54 -0800, Razvan Rotaru wrote:
> > > > - function returns a value which is a java instance (not possible to
> > > > change here, or at least not from what I see - it needs to be a java
> > > > instance)
> > > > - i need to be able to call some function which gets some values that
> > > > are not part of the java class
>
> > > You should approach such a need with great trepidation:
>
> > > [org.jboss.netty/netty "3.2.7.Final"]
>
> > > (import 'org.jboss.netty.util.internal.ConcurrentIdentityWeakKeyHashMap)
>
> > > (def ^:private asides (ConcurrentIdentityWeakKeyHashMap.))
>
> > > (defn function-with-two-return-values [...]
> > >   (let [retval ...]
> > >     (.put asides retval extra-data)
> > >     retval))
>
> > > (let [x (function-with-two-return-values ...)]
> > >   (prn x)
> > >   (prn (.get asides x)))
>
> > > --
> > > Stephen Compall
> > > ^aCollection allSatisfy: [:each|aCondition]: less is better

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

Re: xml-zip

[Tom Faulhaber]

Great. Happy to help!

On Dec 13, 7:39 am, Linus Ericsson 
wrote:
> Thank you Tom!
>
> Exactly was I was looking for!
>
> I will TRY to add some documentation to clojuredocs.org just so people
> won't be that afraid, this xml-functionality is a very sane way of doing
> it, it's just takes a while to get used to it (I'll check that it's refered
> to the correct namespace as well).
>
> I guess next step would be making a clojar avaliable, but I have no clue on
> how to do that yet.
>
> /Linus
>
> 2011/12/13 Tom Faulhaber 
>
>
>
>
>
>
>
> > Hi Linus,
>
> > Zippers and their associated helpers are woefully undocumented, so I'm
> > not surprised you fell into the swamp.
>
> > I think that the help you're looking for can be found in the
> > clojure.data contrib project (seehttps://github.com/clojure/data.zip
> > for the source andhttp://clojure.github.com/data.zipfor the
> > autodoc).
>
> > Using that, the xpathy thing you're looking for is something like
> > this:
>
> > (ns play.xml-example
> >  (:require [clojure.zip :as zip]
> >            [clojure.data.zip :as zf]
> >            [clojure.xml :as xml])
> >  (:use clojure.data.zip.xml))
>
> > (def mz (zip/xml-zip (xml/parse "dataabove.xml")))
>
> > (defn get-all-dimensions []
> >   (doseq [id (xml-> mz zf/descendants (attr= :id "2") zf/children :e
> > (attr :id))]
> >    (println (apply str id
>
> > Note that I had to make a couple of fixes to the above XML to make it
> > right.
>
> > I hope that's useful!
>
> > Tom
>
> > On Dec 12, 7:06 am, Linus Ericsson 
> > wrote:
> > > Hello!
>
> > > What's the clever way to read the E-tags "thisone" and "andthis" in the
> > > XML-file below given I don't know their id on beforehand?
>
> > > 
> > >   bla bla
> > >   bla bla
> > >   
> > >     
> > >       
> > >     
> > >       
> > >       
> > >    
> > >       
> > > 
>
> > > My solution so far would be something like
>
> > > (def mz (zip/xml-zip (xml/parse "dataabove.xml")))
>
> > > (defn get-all-dimensions []
> > >   (filter #(and (= "2" (:id %)) (= :e (:tag %))) (zip/children mz
>
> > > but I'm looking for some descending solution
>
> > > (-> mz
> > >       (zip/down a)
> > >       (zip/down c :where (= :id "wanted"))
> > >       (zip/down d :where (= :id 2))
> > >       zip/children)
>
> > > (an xpath-like solution would most awesome)
>
> > > According to it's own page Enlive is not very good for xml and I cannot
> > > figure out the way to dynamically walk with zippers (like "go into the
> > tag
> > > :d with id=..."). Would Enlive work for my needs here?
>
> > > When I got this sorted out I will try my best to add some examples on
> > > clojuredocs.org, zippers is good but I don't know if it's for
> > everything.
>
> > > /Linus
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: multiple return values

[Tom Faulhaber]

Razvan,

I think that you can implement your idea of "extending the class with
proxy" in the following way (originally suggested to me by Rich Hickey
& Chris Houser for use with the pretty printer):

(let [extra-fields (ref {:field1 extra-value1, :field2 extra-value2}]
  (proxy [Writer IDeref]
(deref [] extra-fields)
(write [x] ...)
other funcs))

You don't need to make the extra-values item a ref if you will set the
values immutably at create time.

You can see the full example of this at
https://github.com/clojure/clojure/blob/1f11ca3ef9cd0585abfbe4a9e7609be8b255123f/src/clj/clojure/pprint/pretty_writer.clj#L371

The rest of that module is an abomination that was written when I was
still under the influence of CLOS & O-O.

Hope that helps,

Tom






On Dec 12, 5:10 pm, Stephen Compall  wrote:
> On Mon, 2011-12-12 at 10:54 -0800, Razvan Rotaru wrote:
> > - function returns a value which is a java instance (not possible to
> > change here, or at least not from what I see - it needs to be a java
> > instance)
> > - i need to be able to call some function which gets some values that
> > are not part of the java class
>
> You should approach such a need with great trepidation:
>
> [org.jboss.netty/netty "3.2.7.Final"]
>
> (import 'org.jboss.netty.util.internal.ConcurrentIdentityWeakKeyHashMap)
>
> (def ^:private asides (ConcurrentIdentityWeakKeyHashMap.))
>
> (defn function-with-two-return-values [...]
>   (let [retval ...]
>     (.put asides retval extra-data)
>     retval))
>
> (let [x (function-with-two-return-values ...)]
>   (prn x)
>   (prn (.get asides x)))
>
> --
> Stephen Compall
> ^aCollection allSatisfy: [:each|aCondition]: less is better

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

Re: xml-zip

[Tom Faulhaber]

Hi Linus,

Zippers and their associated helpers are woefully undocumented, so I'm
not surprised you fell into the swamp.

I think that the help you're looking for can be found in the
clojure.data contrib project (see https://github.com/clojure/data.zip
for the source and http://clojure.github.com/data.zip for the
autodoc).

Using that, the xpathy thing you're looking for is something like
this:

(ns play.xml-example
  (:require [clojure.zip :as zip]
[clojure.data.zip :as zf]
[clojure.xml :as xml])
  (:use clojure.data.zip.xml))

(def mz (zip/xml-zip (xml/parse "dataabove.xml")))

(defn get-all-dimensions []
  (doseq [id (xml-> mz zf/descendants (attr= :id "2") zf/children :e
(attr :id))]
(println (apply str id


Note that I had to make a couple of fixes to the above XML to make it
right.

I hope that's useful!

Tom

On Dec 12, 7:06 am, Linus Ericsson 
wrote:
> Hello!
>
> What's the clever way to read the E-tags "thisone" and "andthis" in the
> XML-file below given I don't know their id on beforehand?
>
> 
>   bla bla
>   bla bla
>   
>     
>       
>     
>       
>       
>    
>       
> 
>
> My solution so far would be something like
>
> (def mz (zip/xml-zip (xml/parse "dataabove.xml")))
>
> (defn get-all-dimensions []
>   (filter #(and (= "2" (:id %)) (= :e (:tag %))) (zip/children mz
>
> but I'm looking for some descending solution
>
> (-> mz
>       (zip/down a)
>       (zip/down c :where (= :id "wanted"))
>       (zip/down d :where (= :id 2))
>       zip/children)
>
> (an xpath-like solution would most awesome)
>
> According to it's own page Enlive is not very good for xml and I cannot
> figure out the way to dynamically walk with zippers (like "go into the tag
> :d with id=..."). Would Enlive work for my needs here?
>
> When I got this sorted out I will try my best to add some examples on
> clojuredocs.org, zippers is good but I don't know if it's for everything.
>
> /Linus

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

Re: Is it possible to make a mirror of clojure.org?

[Tom Faulhaber]

It's also possible to pull a zip file of the API docs just by
following this link: https://github.com/clojure/clojure/zipball/gh-pages.

Another approach, if you're a git-head, is just to clone the clojure
repo:

$ git clone git://github.com/clojure/clojure.git api-docs
$ cd api-docs
$ git checkout -t origin/gh-pages

Now you have the API docs linked back to their sources. If you want to
update them, just go to that directory and do a "git pull"

Tom

On Oct 12, 11:10 am, Tassilo Horn  wrote:
> jingguo  writes:
>
> Hi!
>
> > When programming in Clojure, I use the Reference documentation on
> > clojure.org a lot. But my network condition is horrible. So I want to
> > make a off-line copy. I have tried "wget -x -m -khttp://clojure.org";
> > to make a mirror of clojure.org. But it does not work.
>
> First, I've thought it was due to a restrictive robots.txt on the clojure
> server, so I tried
>
>   wget -e robots=off -x -m -k --wait 1http://clojure.org/
>
> but that also downloads just the index page...
>
> But I guess for programming clojure, you mostly want only the API docs,
> and that can be mirrored perfectly fine with
>
>   wget -xmkhttp://clojure.github.com/clojure/
>
> HTH,
> Tassilo

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

Re: standalone indentation tool

[Tom Faulhaber]

> I've tried pprint and found it lacking as it inserts newlines in
> awkward places apart from the medatada/comments issue mentioned.

Are you using pprint with code-dispatch? That tends to work a lot
better, though it will put newlines where it deems fit. This is either
a good thing or a bad thing depending your context.

It also handles all the read macros that it can:

(with-pprint-dispatch code-dispatch (pprint '#(+ % 1) ))
=> #(+ % 1)

But some get eaten by the reader and are therefore impossible for
pprint to deal with (since it's working on clojure data structures and
not the raw text). These are: `, ~@, ;, ^, and the comma character.

> I think your best bet is to use Emacs from the command-line. Even if

I agree that when you're just trying to reindent human written source
code, emacs is going to produce the best results. pprint is probably
better for machine generated code, as long as you're not depending on
the macros above. (It would also be possible to annotate your code in
clojure with that and have some custom dispatch that generated those
characters as appropriate.)

HTH,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: format and printf can't be used with BigInt

[Tom Faulhaber]

FWIW, clojure.pprint.cl-format handles this fine in 1.3:

(cl-format nil "~d" 2N)
=> "2"

On Jul 27, 11:45 am, Andrea Tortorella  wrote:
> Hi everyone,
> I don't know where to post about bugs (if this is a bug).
> Anyway in clojure 1.3 with the new numerics:
>
> (format "%d" 2N)
>
> throws IllegalFormatConversionException, is it a bug? are there any
> workarounds?

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

Re: Increasing indent level in pprint

[Tom Faulhaber]

Hmmm, looking back at the code, I see that I mis-remembered the fact
that lists and vectors were different. They both (along with maps)
will break rather than fill. Arrays and sets both fill rather than
break.

I'm not sure how much logic there is around this. It just fit my
intuition about how the different structures would be most likely used
when I wrote it. It still seems about right. But if folks think it
should be different, it's easy to change.

On Jul 19, 1:19 pm, Sean Corfield  wrote:
> On Tue, Jul 19, 2011 at 12:03 AM, Tom Faulhaber  
> wrote:
> > Sean's remark is right for writing code, but not really relevant for
> > pretty printed data structures. The pretty printer will either avoid
> > "(foo a" followed by a line break or fill that line full. (By default,
> > for lists it breaks the lines and for vectors it fills them.)
>
> Interesting. I didn't realize it took a different approach.
>
> Out of curiosity, what is the thinking behind the difference between
> lists and vectors?
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
> Railo Technologies, Inc. --http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Increasing indent level in pprint

[Tom Faulhaber]

Sean's remark is right for writing code, but not really relevant for
pretty printed data structures. The pretty printer will either avoid
"(foo a" followed by a line break or fill that line full. (By default,
for lists it breaks the lines and for vectors it fills them.)

While there's no way to just set the indent, you can get this effect
with a little work.

The pretty printer allows customization of the output format using
dispatch functions.

By default it uses simple-dispatch, defined here:
https://github.com/clojure/clojure/blob/d1e39b1ec7fc65907b13458d7ec70b0839f3f85e/src/clj/clojure/pprint/dispatch.clj#L65

I have created a variant of simple dispatch that does the two
character indent (as per your example above). I through a little
project on github: https://github.com/tomfaulhaber/pprint-indent. The
README is basically a copy of your second example run in my repl. The
source is in 
https://github.com/tomfaulhaber/pprint-indent/blob/master/src/indent/indent.clj
for the curious.

Feel free to modify to taste. :)





On Jul 16, 10:52 pm, Asim Jalis  wrote:
> Okay. I see what you mean.
>
> On Jul 16, 2011, at 8:39 PM, Sean Corfield  wrote:
>
>
>
>
>
>
>
> > On Sat, Jul 16, 2011 at 7:05 PM, Asim Jalis  wrote:
> >> The position of the braces might be a red herring here. I was mostly
> >> interested in figuring out how to increase the indentation level from
> >> 1 to something larger. Even an indentation step of 2 for each level
> >> would be easier on the eye than 1.
>
> > My point was that the "natural" Lisp/Clojure indentation is to match
> > the items above so for:
>
> > {:something
>
> > the natural indentation is 1 and for:
>
> > (foo a
>
> > the natural indentation is 5: '(', 'f', 'o', 'o', ' '.
>
> > Indentation is not some fixed quantity you can change - it's dependent
> > on the structure of the data/code and the length of the symbols.
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View --http://corfield.org/
> > World Singles, LLC. --http://worldsingles.com/
> > Railo Technologies, Inc. --http://www.getrailo.com/
>
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: pretty-print by default?

[Tom Faulhaber]

To do this from a simple command line, just do:

java -cp  clojure.main -e "(require
'clojure.pprint) (clojure.main/repl :print clojure.pprint/pprint)"

modify to taste.

I once figured how to do this in Slime, too, but when I look at my
(quite dated) copy, it looks like pr-str is hard-coded.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Generating API docs for clojure 1.3 projects

[Tom Faulhaber]

Hi Tassilo,

Autodoc is usually the tool you want, I think. I'm the author of that
tool and I've been very busy on other stuff lately, so I haven't but
together a 1.3 release.

I'll try to get to that pretty soon so that you'll have something to
use. I don't know why one you built should fail, but I haven't tried
it myself. At first look, maybe it's the new numeric stuff or maybe it
still has a bad dependency chain in it's project.clj.

Tom

On Jun 20, 11:22 pm, Tassilo Horn  wrote:
> Hi all,
>
> I'd like to generate some API docs for my clojure 1.3 lib.  The way to
> go seems to be autodoc.  However, with version 0.7.1 (the stable
> release), my leiningen fails to fetch the required dependencies.
>
> On clojars, there are several other forks/versions, but for all of them
> including a self-built autodoc git checkout, "lein autodoc" fails with
>
>   java.lang.NoSuchMethodError: clojure.lang.Numbers.lt(II)Z
>
> I also had a look at the contrib libs, which also has some gen-html-docs
> library.  But for clojure 1.3, one should use the new modular contrib
> library, which doesn't contain that anymore...
>
> So my question: does anyone have a working setup for generating HTML API
> docs for a project using clojure 1.3 that he wants to share with me?  I
> really don't need anything fancy, just some browsable, linked HTML
> pages.
>
> Bye,
> Tassilo

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

Re: bug report : cl-format

[Tom Faulhaber]

Hi Carlos,

This certainly looks like a bug. I've filed issue 768 on myself
(http://dev.clojure.org/jira/browse/CLJ-768) and I'll take a look as
soon as I get a chance.

Thanks for bringing this up,

Tom

On Apr 3, 1:49 pm, Carlos Ungil  wrote:
> Hello,
>
> I don't know if there is a better way to file bug reports (if there is one,
> it's not easy to find).
>
> (use 'clojure.pprint)
>
> (let [x 111.1]
>   (doseq [fmt ["~3f~%" "~4f~%" "~5f~%" "~6f~%"]]
>     (cl-format true fmt x)))
>
> ;; 111.1
> ;; 111.1
> ;; 111.1
> ;; 111.11
>
> There is clearly a problem in the first two cases, too many digits are being
> printed.
>
> For reference, this is what common lisp does:
>
> (let ((x 111.1))
>   (loop for fmt  in '("~3f~%" "~4f~%" "~5f~%" "~6f~%")
> do (format t fmt x)))
>
> ;; 111.
> ;; 111.
> ;; 111.1
> ;; 111.11
>
> Cheers,
>
> Carlos

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

Re: about the repl

[Tom Faulhaber]

I have submitted a patch for pprint's tendency to mess up when
exceeding *print-length*. I assume that Stuart will apply it to the
1.3 (master) branch RSN, unless he sees a problem with it.

Sorry for the inconvenience.

Tom

On Dec 21, 12:30 am, Tom Faulhaber  wrote:
> Hmm, looks like I broke some logic when I hand unrolled the original
> cl-format based dispatch to get better performance for lists, vectors, and
> maps. (Really I shouldn't have to do this, but I need to make cl-format
> itself generate code rather than threaded functions which are slow and tend
> to blow your stack. Haven't gotten around to that yet, though so the
> hand-coded versions are stop-gaps.)
>
> I'm not digging the patch too much, though, for 3 reasons:
>
> 1) It breaks sets and arrays, which work in master.
> 2) It pushes the logic for *print-length* printing into the dispatch
> functions (redundantly since there's still logic in write-out). Since these
> are customizable, it places that load on whoever customizes it.
> 3) It adds redundant logic in write-out which is the called for every object
> that the pretty printer deals with.
>
> I'll try to take a stab at a patch that fits a little better with what I'm
> trying to do in the next couple of days.
>
> Tom
>
> On Sat, Dec 18, 2010 at 1:18 PM, Stuart Halloway
> wrote:
>
> > > The latter is easy to fix: provide a version of println that wraps an
> > > implicit (take n ...) around seq arguments (including when it calls
> > > itself on seqs nested within other structures). (*print-length*
> > > doesn't seem to work, just causes an infinite seq to print the first n
> > > items and then a never-ending string of "..."s.)
>
> > Hi Ken,
>
> > In my tests *print-length* works fine with the regular REPL printer, but
> > has the defect you describe when using pprint. Can you confirm that you are
> > also seeing the problem with pprint, not print?
>
> > Do some REPLs automatically replace print with pprint?
>
> > Tom:  I have created a ticket with a partial fix and would appreciate your
> > input:http://dev.clojure.org/jira/browse/CLJ-695.
>
> > Thanks,
> > Stu

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

Re: about the repl

[Tom Faulhaber]

Hmm, looks like I broke some logic when I hand unrolled the original
cl-format based dispatch to get better performance for lists, vectors, and
maps. (Really I shouldn't have to do this, but I need to make cl-format
itself generate code rather than threaded functions which are slow and tend
to blow your stack. Haven't gotten around to that yet, though so the
hand-coded versions are stop-gaps.)

I'm not digging the patch too much, though, for 3 reasons:

1) It breaks sets and arrays, which work in master.
2) It pushes the logic for *print-length* printing into the dispatch
functions (redundantly since there's still logic in write-out). Since these
are customizable, it places that load on whoever customizes it.
3) It adds redundant logic in write-out which is the called for every object
that the pretty printer deals with.

I'll try to take a stab at a patch that fits a little better with what I'm
trying to do in the next couple of days.

Tom


On Sat, Dec 18, 2010 at 1:18 PM, Stuart Halloway
wrote:

> > The latter is easy to fix: provide a version of println that wraps an
> > implicit (take n ...) around seq arguments (including when it calls
> > itself on seqs nested within other structures). (*print-length*
> > doesn't seem to work, just causes an infinite seq to print the first n
> > items and then a never-ending string of "..."s.)
>
> Hi Ken,
>
> In my tests *print-length* works fine with the regular REPL printer, but
> has the defect you describe when using pprint. Can you confirm that you are
> also seeing the problem with pprint, not print?
>
> Do some REPLs automatically replace print with pprint?
>
> Tom:  I have created a ticket with a partial fix and would appreciate your
> input: http://dev.clojure.org/jira/browse/CLJ-695.
>
> Thanks,
> Stu
>
>

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

Re: REQUEST for feedback on http://clojure.org

[Tom Faulhaber]

Jason,

Actually Alex was a little off the mark here. The problem was in the
templates that generate the autodoc so they were pretty easy to fix
for all versions.

The github links are now fixed and I expect to modify the assembla
pointers to the new confluence/jira stuff tonight or tomorrow.

Please *do* continue to point out errors in the autodoc (formatting,
content, things missing, etc.) and I will fix them (though sometimes
it might take just a little bit).

Thanks,

Tom

On Nov 2, 1:58 pm, Alex Miller  wrote:
> Jason - that's a good catch but out of my purview.  Also, those are
> autodocs generated from the (released and thus immutable :) 1.2
> afaik.
>
> On Nov 2, 4:12 pm, Jason Wolfe  wrote:
>
> > Not sure if you count this as off limits as part of the API page, but
> > its first line points to a stale "official source code for clojure"
> > -- should be updated to the new github repo.
>
> > -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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Autodoc dependencies broken?

[Tom Faulhaber]

James,

I don't know why this would be true, but something may have broken in
the underlying dependency chains. Autodoc hasn't been updated in
clojars for a very long time and does not directly depend on super-
pom.jar.

Are you using autodoc standalone or as a lein plugin?

Tom

On Nov 26, 1:09 pm, James Reeves  wrote:
> I've just tried installing autodoc 1.7.1 and 0.8.0-SNAPSHOT via
> Leiningen and Clojars, and it seems to be missing some dependencies
> (specifically org.apache.maven:super-pom:jar:2.0).
>
> Has anyone else had this problem recently?
>
> - James

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

Re: priority queue for scheduling events in the future

[Tom Faulhaber]

OK, I'm doing stuff there now.

I'll move the comment to the ns doc string, then.

There are still issues with autodoc and protocols/types, but priority
queues look like they'll be a good sandbox for resolving them.

Tom

On Nov 24, 2:51 am, Mark Engelberg  wrote:
> No reason other than my lack of knowledge that ns doc strings are picked up
> by autodoc and comments are not. :)
>
> On Wed, Nov 24, 2010 at 12:36 AM, Tom Faulhaber wrote:
>
> > Mark,
>
> > Is there a reason that you put the documentation in a comment rather
> > than as the ns doc string so that autodoc would pick it up? Currently,
> > priority queues are undiscoverable by autodoc users.
>
> > 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: priority queue for scheduling events in the future

[Tom Faulhaber]

Mark,

Is there a reason that you put the documentation in a comment rather
than as the ns doc string so that autodoc would pick it up? Currently,
priority queues are undiscoverable by autodoc users.

Tom

On Nov 23, 9:41 pm, Mark Engelberg  wrote:
> In 1.3, you can use clojure.contrib.priority-map.
> Documentation found in comment at top of 
> source:https://github.com/clojure/clojure-contrib/blob/master/modules/priori...

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

Re: string interpolation

[Tom Faulhaber]

Wow, David, that's a nice little demonstration of cl-format. I hadn't
seen that before.

But as Mike points out, clojure.contrib.strint/<< is more precisely
what the poster is asking for: true ruby-style string interpolation.

It has occurred to me to extend cl-format to do real string
interpolation (it would be nice to have both in-line arguments and
format control), but it has never gotten to the top of my list.

Tom

On Nov 20, 3:22 pm, David Sletten  wrote:
> The cool way is to use Tom Faulhaber's cl-format in 
> clojure.pprint:http://clojure.github.com/clojure/#clojure.pprint
>
> (use '[clojure.contrib.pprint :only (cl-format)])
> (cl-format true "This is a ~A string.~%" 'funky)
> This is a funky string.
>
> I have a mini-tutorial plus links 
> here:http://www.gettingclojure.com/cookbook:sequences#commas
>
> Have all good days,
> David Sletten
>
> On Nov 20, 2010, at 6:00 PM, HiHeelHottie wrote:
>
>
>
> > I think ruby has nice string interpolation.  You can put the following
> > in a textfield that a user can modify
>
> > This is a #{adjective} string.
>
> > Then, you can take that string, put it in quotes and have ruby
> > evaluate it as a string.  What is the clojure way of doing something
> > similar.  Presenting something like
>
> > "This is a " adjective " string"
>
> > and then wrapping that in (str ) before evaluating it in clojure seems
> > less attractive.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: Images in autodoc?

[Tom Faulhaber]

In order to better inform my thinking here, I want to ask: "So what's
the target here?"

Are we looking to enhance Clojure's core documentation or do you have
specific projects of your own for which you'd like these features?

For example, my rationale for images is that I want to be able to
include representative output graphs in the Incanter documentation.

The reason I ask this is that I'm trying to distinguish between things
we're proposing because we'd like to use them ourselves in areas we
control and things we're proposing because we'd like to change the
overall way documentation is done (both reasonable discussions, but
different).

One of the things I'm working on is making available a full dataset
with all the Var doc in clojure format so you can pull sample doc
strings (and other info if you want). This is important for testing
autodoc extensions against the existing population of strings.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Getting this error regarding duck-streams/spit ...

[Tom Faulhaber]

You remind me that I need to mark http://richhickey.github.com/clojure...
as obsolete and redirect users to the new place.

Zack Kim and I are working to have clojuredocs pull data from the
autodoc system and, at that point, I assume that he'll add deprecation
info over there as well.

Sorry for any confusion! Clojure's still a fast moving target.

Tom

On Oct 26, 12:48 pm, Btsai  wrote:
> I'm fairly positive duck-streams is deprecated, as it is no longer
> present in the clojure-contrib git repository:
>
> http://github.com/clojure/clojure-contrib/tree/master/modules/
>
> http://richhickey.github.com/clojure-contrib/doesn't have the
> deprecation info most likely because it is the documentation for the
> original (now outdated) clojure-contrib repository, and doesn't have
> 1.2 info.
>
> http://clojure.github.com/clojure-contrib/is the documentation for
> the current repository.
>
> clojuredocs should probably be updated to include the deprecation
> info, and also have its link to clojure-contrib point to the current
> repository.
>
> On Oct 26, 12:44 pm, Victor Olteanu  wrote:
>
> > Thank you Btsai. I checked 
> > bothhttp://richhickey.github.com/clojure-contrib/io-api.html#clojure.cont...
> > andhttp://clojuredocs.org/clojure_contrib/clojure.contrib.duck-streams/s...
> > and couldn't find any reference to deprecation.
> > If you can confirm that this deprecation was made "official" then we could
> > update those docs so other people won't run into these same issues.
>
> > Victor
>
> > On Tue, Oct 26, 2010 at 12:46 AM, Btsai  wrote:
> > > I don't think it's a mistake or accident that spit exists in
> > > clojure.core.  In 1.2, duck-streams became deprecated and functions
> > > such as spit were incorporated into clojure.core:
>
> > >http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/...
> > >http://clojure.github.com/clojure-contrib/duck-streams-api.html
>
> > > Are you using anything beyond spit and slurp*?  If not, I think you
> > > can switch to clojure.core's slurp and spit and drop duck-streams
> > > altogether.
>
> > > On Oct 25, 8:59 pm, Victor Olteanu  wrote:
> > > > Thank you.
>
> > > > The following statement worked for me:
> > > > (:require [clojure.contrib.duck-streams :as d])
>
> > > > As I was using slurp and slurp*, I then had to do the following:
>
> > > > use the form "d/slurp*" instead (prefixed with d/)
> > > > use "slurp" without a change
>
> > > > This brings up a related point - I can see that there are functions with
> > > the
> > > > same name in different packages, which I believe it's quite unfortunate.
> > > > There is slurp in clojure.core and there is duck-streams/slurp* , along
> > > with
> > > > other functions such as spit...
>
> > > > I hope this kind of things might be addressed in future versions of
> > > > Clojure...
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com > >  >
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en

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

Re: Images in autodoc?

[Tom Faulhaber]

Nah, changing the autodoc generation is easy (though we need to figure
out where images go on the input and output sides and move them
around, but that shouldn't be too much of a problem).

The bigger problem is figuring out what to tell folks who type (doc
foo) at the REPL and get a bunch of gobbledegook back. That's the
thing that's been making me look for a better format than markdown.
(Autodoc already does markdown translation for supporting
documentation).

Tom

On Oct 26, 9:25 am, Andrew Gwozdziewycz  wrote:
> On Tue, Oct 26, 2010 at 12:21 PM, Eric Schulte  wrote:
> > Chris  writes:
>
> >> On Oct 26, 9:54 am, Andrew Gwozdziewycz  wrote:
> >>> I like that idea, especially if it could be extended to reference other 
> >>> code:
>
> >> Agreed.  So now that's links to images, web pages, Clojure vars...
> >> anything else?
>
> > LaTeX equations.  Which are increasingly easy to render in HTML
> > (e.g.http://www.mathjax.org/).
>
> I guess the problem is actually making a patch to autodoc to do this all :)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
>
> --http://www.apgwoz.com

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

Re: Images in autodoc?

[Tom Faulhaber]

It's on the roadmap.

I haven't really figured out a way to do it that fits in with other
uses of doc strings.

I do know that I want the images to be able to be embedded in the doc
string so that programs like incanter can use the image as part of the
narrative, but I want the "markup" that does it to feel natural to
readers who aren't seeing the image.

Tom

On Oct 25, 7:05 pm, Chris  wrote:
> Is it possible to add images to autodoc-generated pages like javadoc
> can?  I'm interested in adding explanatory diagrams to function
> documentation as opposed to adding things like logos to the HTML
> pages.
>
> Thanks,
> Chris

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

Re: clojure.java.*

[Tom Faulhaber]

Yup, it's an autodoc bug. I had fixed the bug, but forgot to pull the
new version into the area where the autodoc robot runs. So the next
time the robot ran, it undid the fixes. :(

All fixed up now.

Tom

On Oct 19, 7:42 pm, Sean Corfield  wrote:
> On Tue, Oct 19, 2010 at 6:37 PM, Brent Millare  
> wrote:
> > Just wondering what are the plans for clojure.java.*
>
> > It used to be inhttp://richhickey.github.com/clojure/
>
> > but now that we are usinghttp://clojure.github.com/clojure
> > clojure.java.* is no longer listed.
>
> Looks like a bunch of namespaces have disappeared from that page
> (again? didn't someone else comment on a similar issue recently - and
> it got fixed?).
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

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

Re: Let usage question

[Tom Faulhaber]

Dave,

Yes, this is perfectly idiomatic and many people in Clojure (and also
Haskell, for example) use let to help document how they're building up
their computation.

Stuart's suggestion is also good and it's largely a matter of personal
preference which to use when.

Of course, as you use clojure more, you'll probably become more
comfortable with more complex statements and not use the let style
quite so much.

Tom

On Oct 19, 8:19 pm, Dave Ray  wrote:
> Hey,
>
> I'm parsing a file with a chain of filter and map operations. To make
> it a little more readable (to me), I put the steps in a let like this:
>
> (defn parse-dictionary
>   [reader]
>   (let [lines    (read-lines reader)
>         trimmed  (map #(.trim %1) lines)
>         filtered (filter is-dictionary-entry? trimmed)]
>      (map parse-entry filtered)))
>
> Is this style of let considered good/bad stylistically? Are there
> technical tradeoffs between this and a bunch of nested forms?
>
> Thanks!
>
> Dave

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

Re: Documentation tools

[Tom Faulhaber]

Hey Mark,

I don't know of any publicly available tools besides autodoc. My
understanding is that Zack was keeping the source to clojuredocs
closed, at least for now. While I assume his extraction code is in
Clojure, the actual clojuredocs presentation code is a Ruby on Rails
app [1]

Whether autodoc is the right basis for what you would like depends on
exactly what you would like.

The issue of running on Windows is a red herring. While it does have
bugs on Windows, I don't think they'd be difficult to fix. They seem
to mostly be of the form of not using path separators correctly and
being disciplined enough about using java.io.File instead of just
hacking up file name strings.  A motivated user should be able to get
it all working pretty quickly, I would think (patches very welcome!).
It's on my list to do, but I haven't gotten to it yet.

The real issue is whether you want information in comments, in
"formatted docstrings" or in non-docstring metadata. Since docstrings
are already metadata and I didn't want to mess with their usability in
other contexts, I took the last approach. I don't think putting the
info in comments (as naturaldocs does) would really be in the Clojure
style. Having a tool that detected standard formatting in doc strings
seems like the right way to go to me. The trick would be finding a
format that wasn't ugly or confusing to people accessing docstrings
another way (like from Slime or the REPL). Examples, on the other
hand, might go better in a separate metadata field. Hmmm...

All of this should be possible to build on top of autodoc fairly
easily. Autodoc basically has four parts:

- collect-info walks the source tree (by loading each file in turn)
and returns a structure describing the public variable it found there,
organized by namespace.

- build-html generates a directory of html (and optionally a JSON
index) based on this data.

- The HTML templates, CSS files and images used to create the default
format used on clojure.github.com/clojure. These are all replaceable
as long as you keep the tags that the build-html code uses (assuming
you want that information).

- the rest of the goop deals with the nastiness of automating git
interactions, creating doc trees that span branches, handling the fact
that the program is written in Clojure and also used to document
multiple, incompatible versions of Clojure, generate supporting docs
written using markdown, etc.

Two easy things to do would be:

- Recognize additional metadata fields in collect info and use them in
build-html (category markers, for instance), or

- After collect-info, parse the docstrings themselves and add elements
to the generated structures to represent docstring-embedded data. Then
use that in build-html.

Note that if you want to pull info from comments, autodoc probably
isn't the right tool since it's driven completely from the compiled
namespaces and metadata.

I am happy to see people fork autodoc[2] and twist it to their own
vision of what makes great documentation. This is a nice area in which
to improve stuff. I'll happily integrate changes that fit the main
mission of autodoc.

Enjoy,

Tom

[1]
http://groups.google.com/group/clojure/browse_thread/thread/a97d472679f2cade/53eec6db0ca0c82f?lnk=gst&q=clojuredocs+ruby#53eec6db0ca0c82f

[2] Here it is: http://github.com/tomfaulhaber/autodoc

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

Re: Does Clojure has a compiler

[Tom Faulhaber]

As the other posters mention, Clojure does have a compiler. However,
you don't always need to use it explicitly.

Clojure will compile all input before executing it and once it's
compiled it runs with the exact performance it would if it had been
compiled ahead of time.

There's no interpreted layer in Clojure as there is in some other
languages.

Some users like to pre-compile files (to obfuscate code, to speed
startup time) and others prefer pure source distribution (smaller,
more compatibility between versions). I would recommend not worrying
about it unless you have a specific reason to do it, but neither
direction would be "wrong" or "non-mainstream." Sometimes the
toolchain you're using makes one way easier or harder (slightly). For
example, I've noticed folks using maven tend to pre-compile whereas
folks using leiningen tend not to, but either way is possible with
both tools.

In the end, it's mostly just a matter of taste.

Tom

On Aug 25, 7:17 pm, HB  wrote:
> Hey,
> Both Groovy and Scala have a compiler to produce class files.
> Does Clojure has a compiler?
> Do Clojure files are compiled usually?
> Thanks.

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

Re: clojure-contrib master now in submodules

[Tom Faulhaber]

A couple of questions:

1) Does use of clojure-contrib now require maven or leinigen as a
prerequisite or is there a place to go grab the jar files?
2) From my read of this, there is no longer a clojure-contrib.jar,
just a meta dependency that causes maven to grab all the modules. Is
that correct?

Tom

On Aug 20, 7:22 am, Stuart Sierra  wrote:
> Hello, all,
>
> As planned for some time, clojure-contrib has now been split into many
> submodules on the "master" branch.
>
> *** For users of clojure-contrib 1.2.0: nothing changes.
>
> *** For users of clojure-contrib snapshots:
>
> New builds of the master branch on github will be available as 1.3.0-
> SNAPSHOT versions.  Each major contrib library has its own module with
> the groupId "org.clojure.contrib" and an artifactId which is the name
> of the library.
>
> For example, to use the clojure.contrib.macro-utils namespace in your
> projects, add a dependency on group "org.clojure.contrib", artifact
> "macro-utils", version "1.3.0-SNAPSHOT".
>
> In Leiningen syntax, this looks like:
>
>     :dependencies [ ... [org.clojure.contrib/macro-utils "1.3.0-
> SNAPSHOT"] ...]
>
> In Maven syntax, this looks like:
>
>     
>     ...
>        
>          org.clojure.contrib
>          macro-utils
>          1.3.0-SNAPSHOT
>        
>     ...
>     
>
> If you want to use ALL contrib libraries, add a dependency on group
> "org.clojure.contrib", artifact "complete", version "1.3.0-SNAPSHOT".
> This meta-library depends on all other contrib libraries.
>
> *** For clojure-contrib developers:
>
> Each library has its own directory under the "modules" directory at
> the top level of clojure-contrib.  Each module directory contains a
> pom.xml file specifying the name, version number, and dependencies of
> that library.
>
> Every module pom.xml declares a "parent" located in the modules/parent
> directory.  The parent pom.xml file defines configuration settings
> common to all clojure-contrib libraries.  Currently the parent pom.xml
> declares a dependency on Clojure 1.2.0 and sets up clojure-maven-
> plugin to compile and test Clojure sources.
>
> Individual libraries may override the parent configuration in their
> own pom.xml files.
>
> Building all of clojure-contrib (by running "mvn install" at the top
> level) can take over 10 minutes.  Fortunately, you do not need to
> build all the modules most of the time.  To build just one library, cd
> to its directory under "modules" and run "mvn install" (or "mvn test"
> to test).  You will need to have already installed, at a minimum, the
> parent module and any modules your library depends on.
>
> *** For everyone:
>
> There will doubtless be some breakage and difficulties during this
> transition period.  Please bear with us.  Post your questions to the
> list, and we will try to answer them as soon as possible.
>
> Thanks,
> 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojure.string namespace missing from API page?

[Tom Faulhaber]

clojure.string is now in for the master branch doc at 
http://clojure.github.com/clojure/

Separate 1.2 doc coming RSN.

Tom

On Jul 18, 11:10 am, Tom Faulhaber  wrote:
> The official doc for clojure and clojure-contrib have moved as well.
> They are now at:
>
> http://clojure.github.com/clojure/
>
> and
>
> http://clojure.github.com/clojure-contrib/
>
> I have not got them completely up-to-date with the 1.2 beta split, so
> for the moment just look at the master branch. I expect to have that
> fixed in the next few days.
>
> You are correct, clojure.string is not there. I'll get that added
> today. Thanks for catching it!
>
> Tom
>
> On Jul 17, 10:13 pm, Adrian Cuthbertson 
> wrote:
>
> > Yes, sorry, my post referred to the source, not the online doc API.
> > Perhaps someone else can answer regarding that?
>
> > On Sat, Jul 17, 2010 at 5:58 PM, Btsai  wrote:
> > > Thank you Adrian.  I did see in the release announcement thread that
> > > that is the new source site for 1.2.  However, I was unable to find an
> > > online API there.  http://richhickey.github.com/clojure/isthe only
> > > online API I have seen.  And again, the other new 1.2 namespaces like
> > > clojure.java.io show up just fine there, which is why I'm confounded
> > > why clojure.string is not there.
>
> > > On Jul 17, 8:57 am, Adrian Cuthbertson 
> > > wrote:
> > >> Hi Benny,
>
> > >> The 1.2 release source site has moved tohttp://github.com/clojure/
>
> > >> -Regards, Adrian
>
> > >> On Sat, Jul 17, 2010 at 8:00 AM, Btsai  wrote:
> > >> > Hi Clojurians,
>
> > >> > The recent 1.2 beta release is the first time I played with 1.2.  When
> > >> > reading the release notes, I saw a number of new namespaces.  I was
> > >> > able to find most of them (clojure.java.io, etc.) on the API site
> > >> > (http://richhickey.github.com/clojure/).  However, I could not find
> > >> > the clojure.string namespace.  Did I miss something?  Any help would
> > >> > be greatly appreciated.
>
> > >> > -Benny
>
> > >> > P.S.  My apologies for the repeat question (I asked this question in
> > >> > the 1.2 beta release announcement thread as well), but I am leaning
> > >> > quite a bit on the API site as I continue to learn the functions built
> > >> > into Clojure, and could really use some help figuring this out.

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

Re: ClojureDocs.org week 1

[Tom Faulhaber]

What I've noticed is that conventions on doc string indentation is all
over the place. Combine that with the fact that folks build tables and
columns by hand, and a really simplistic rule doesn't work so much.

I recommend you just grab the remove-leading-whitespace function from
the autodoc program and use it. It's here:

http://github.com/tomfaulhaber/autodoc/blob/master/src/autodoc/collect_info.clj#L13

That seems to make all the doc strings I've encountered in the wild
format up pretty well.

HTH,

Tom

On Jul 17, 2:52 am, Tassilo Horn  wrote:
> Hi Zack,
>
> I just had a look at ClojureDocs.org and it's really neat!
>
> Some observations I made:
>
> - When I view the docs of let's say clojure.set/rename, the clojure.set
>   part is a link.  But instead of pointing to to clojure.set summary
>   page, it is only http:.
>
> - In the source section, not all referenced vars (called functions) are
>   linked.
>
> - All lines of multi-line docstrings are except the first are indented
>   which looks quite ugly.  Well, that's not ClojureDoc.org's fault.  It
>   seems that it's a clojure convention to write docstrings like:
>
> --8<---cut here---start->8---
> (defn my-function
>   "Do magic and return a spell.
>   More detailed docs... bla bla bla bla bla bla bla bla bla bla bla bla bla 
> bla
>   bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla "
>   []
>   (let [spell (do-magic)]
>     (if (castable? spell)
>       spell
>       (alternative-spell sepll
> --8<---cut here---end--->8---
>
>   instead of like
>
> --8<---cut here---start->8---
> (defn my-function
>   "Do magic and return a spell.
> More detailed docs... bla bla bla bla bla bla bla bla bla bla bla bla bla bla
> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla "
>   []
>   (let [spell (do-magic)]
>     (if (castable? spell)
>       spell
>       (alternative-spell sepll
> --8<---cut here---end--->8---
>
>   which is the convention in any other lisp I know.  Has this convention
>   a reason, or is this only Rich's personal preference others simply
>   adapted?
>
> Anyway, really neat! :-)
>
> Bye,
> Tassilo

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

Re: clojure.string namespace missing from API page?

[Tom Faulhaber]

The official doc for clojure and clojure-contrib have moved as well.
They are now at:

http://clojure.github.com/clojure/

and

http://clojure.github.com/clojure-contrib/

I have not got them completely up-to-date with the 1.2 beta split, so
for the moment just look at the master branch. I expect to have that
fixed in the next few days.

You are correct, clojure.string is not there. I'll get that added
today. Thanks for catching it!

Tom

On Jul 17, 10:13 pm, Adrian Cuthbertson 
wrote:
> Yes, sorry, my post referred to the source, not the online doc API.
> Perhaps someone else can answer regarding that?
>
> On Sat, Jul 17, 2010 at 5:58 PM, Btsai  wrote:
> > Thank you Adrian.  I did see in the release announcement thread that
> > that is the new source site for 1.2.  However, I was unable to find an
> > online API there.  http://richhickey.github.com/clojure/is the only
> > online API I have seen.  And again, the other new 1.2 namespaces like
> > clojure.java.io show up just fine there, which is why I'm confounded
> > why clojure.string is not there.
>
> > On Jul 17, 8:57 am, Adrian Cuthbertson 
> > wrote:
> >> Hi Benny,
>
> >> The 1.2 release source site has moved tohttp://github.com/clojure/
>
> >> -Regards, Adrian
>
> >> On Sat, Jul 17, 2010 at 8:00 AM, Btsai  wrote:
> >> > Hi Clojurians,
>
> >> > The recent 1.2 beta release is the first time I played with 1.2.  When
> >> > reading the release notes, I saw a number of new namespaces.  I was
> >> > able to find most of them (clojure.java.io, etc.) on the API site
> >> > (http://richhickey.github.com/clojure/).  However, I could not find
> >> > the clojure.string namespace.  Did I miss something?  Any help would
> >> > be greatly appreciated.
>
> >> > -Benny
>
> >> > P.S.  My apologies for the repeat question (I asked this question in
> >> > the 1.2 beta release announcement thread as well), but I am leaning
> >> > quite a bit on the API site as I continue to learn the functions built
> >> > into Clojure, and could really use some help figuring this out.

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

Re: ClojureDocs.org

[Tom Faulhaber]

Quick thought: You probably don't want to include private vars.

On Jul 9, 1:32 am, zkim  wrote:
> Hi All,
>
> I'll try to keep this short.
>
> I've gotten a lot out of Clojure: I can honestly say that learning
> this language, and being part of this community has made me a better,
> happier developer, and I wanted to give something back.
>
> One of the pain points that I encountered when learning the language
> was a lack of examples specific to the individual functions I was
> trying to wrap my head around at any given time. So I took a whack at
> the problem, and came up withhttp://clojuredocs.org.  It's a site
> that (I'm hoping) will fill this need by providing a centralized
> examples database, along with solid search capabilities across both
> core and third party libraries (core being the focus).
>
> Implementation:
> ClojureDocs.org is a rails site backed by MySQL, along with some
> clojure code to pull the namespaces / metadata / source and dump them
> into the database.
>
> Highlights:
> 1. Documentation and source for Clojure core, contrib, and a few third
> party libraries (random selection out of what I'm personally familiar
> with, and whatever was on the github trends page that day).
>
> 2. Search for a var across the whole ecosystem or in a specific
> library.
>
> 3. Per var wiki-style examples section.
>
> 4. Per var comments section.
>
> 5. Per var vars-in-this-var and this-var-used-in section (my personal
> favorite).  Looking for a real-world example of a specific function?
> This is for you. For example,http://clojuredocs.org/v/1978, just
> below the source section.
>
> Lowlights:
> 1. Ugly URLs!  There's a problem in the way that URLs with encoded
> question marks are being handled, so I had to move 
> fromhttp://clojuredocs.org/clj-ssh/clj-ssh.core/file-pathtohttp://clojuredocs.org/v/1484.
>   I've got an email out to the Phusion
> Passenger mailing list (http://groups.google.com/group/phusion-
> passenger/browse_thread/thread/ed2eadfdac5c166f) but if you've got any
> experience in this area drop me a line.
>
> 2. Strange var names (http://clojuredocs.org/v/781).  Probably a bug
> in the import process.
>
> 3. General rough-around-the-edges-ness.
>
> I'm treating this as an alpha, and I'd really like feedback as to:
> a. How useful this would be to the community.
> b. Specific likes / dislikes about this alpha release.
> c. Feature requests.
>
> I've set up a feedback mechanism directly through the site (User
> Voice), which allows voting on specific posts.  I'm also considering
> setting up a google group for general discussion.  Feel free to
> contact me directly through email.
>
> Questions / thoughts?
>
> -Zack

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

Re: Link to API document in the cheat sheet

[Tom Faulhaber]

Will Langstroth had suggested this to me in private correspondence and
has built a version for his own use. I haven't (yet) had the bandwidth
to investigate adding this to the autodoc cycle, but I think it's a
great idea.

I've also been realizing lately that the autodoc should include two
other categorization features:

1) Break down the functions in clojure.core by category, since there
are so many of them.
2) Have back link from various functions to the place on clojure.org
where the concepts around them are discussed.

I'm working on those two now (as part of a larger improvement effort
around the autodoc system in response to many good suggestions).

Tom

On Jul 2, 2:11 pm, ngocdaothanh  wrote:
> Hi,
>
> This is my nth attempt to learn Clojure.
>
> I think it will be an improvement if there are links to API document
> for functions in the cheat sheet (http://clojure.org/cheatsheet).
> Clicking a function name will jump right to the description for the
> function is very convenient for newbies.

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

Re: usage examples in clojure api docs

[Tom Faulhaber]

I like the idea of having example code for all the functions.

However, speaking for myself only, I don't think that the doc strings
are the place for a comprehensive set of examples.

How about building them in some external place? (Maybe as a separate
github project to begin with.) In particular, it would be nice if the
examples used some literate programming technique that let users open
the examples and play with them. That way, they could be linked to
from the documentation (I could roll it into autodoc, for instance,
subject to Rich and Stuart's constraints) but also directly opened,
tried, copied, etc. from your editor and repl.

It's easy for me to imagine that, in the not too distant future, we
could roll that into Clojure core in a way similar to the tests.

Tom

On Jun 28, 9:06 pm, cageface  wrote:
> Several people have suggested that usage examples in the docs would be
> helpful and this is something I often find myself wishing for. Are
> patches introducing examples welcomed by the core team?

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

Re: parallel vs serial iteration in a "for" loop

[Tom Faulhaber]

Hi Viksit,

I would suggest that the CL loop construct and the Clojure construct
of the same name are, in fact, fairly different beasts, both
structurally and in terms of their goals. I don't believe that Rich
has any intent to extend loop towards the CL flavored loop. The for
construct is more Clojure's answer in that direction, though it is not
nearly so flexible.

No reason you couldn't build something similar to CL's loop construct
in Clojure, but Clojurians in general seem to have an aversion to its
"boil the ocean" nature.

I do think, however, that it would be nice to have some syntactic
sugar for consuming sequences in parallel in the for construct. I
can't think of a nice way to do it right now, though.

Tom

On Jun 18, 10:45 am, viksit  wrote:
> Hey Meikel,
>
> On Jun 17, 10:48 pm, Meikel Brandmeyer  wrote:
>
> > Hi,
>
> > On Jun 18, 1:35 am, viksit  wrote:
>
> > > (loop for x in '(a b c d e)
> > >       for y in '(1 2 3 4 5)
> > >       collect (list x y) )
>
> > > ((A 1) (B 2) (C 3) (D 4) (E 5))
>
> > > Are there any good (and idiomatic) methods to achieve this using a
> > > Clojure loop construct?
>
> > user=> (map vector [:a :b :c :d :e] [1 2 3 4 5])
> > ([:a 1] [:b 2] [:c 3] [:d 4] [:e 5])
>
> Oh yes, thanks. I know about using the map method - I was just
> wondering if Clojure's loop supports (or has any plans to support) the
> loop construct as in CL (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/
> node235.html). And if not, then are there any ways to "loop" through 2
> lists in parallel.
>
> Cheers
> Viksit
>
>
>
>
>
> > Sincerely
> > Meikel

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

Re: ANN: Robert Hooke

[Tom Faulhaber]

Nice! I think this kind of functionality should end up getting
promoted. I have also written this a couple of times and thought about
generalizing it. I'm glad you did.

This could also serve as the basis for some nice tracing functionality
(esp. combined the clojure.contrib.logging). You'd want to wrap the
hook function with a macro that also captured the function name and
maybe arglist metadata.

Tom

P.S. But shouldn't it be called Robert Hookjure?

On Jun 10, 10:56 pm, Phil Hagelberg  wrote:
> I just released this library for allowing functionality to be extended
> via plugins:
>
>     (use 'robert.hooke)
>
>     (defn examine [x]
>       (println x))
>
>     (defn microscope
>       "The keen powers of observation enabled by Robert Hooke allow
>       for a closer look at any object!"
>       [f x]
>       (f (.toUpperCase x)))
>
>     (defn doubler [f & args]
>       (apply f args)
>       (apply f args))
>
>     (defn telescope [f x]
>       (f (apply str (interpose " " x
>
>     (add-hook #'examine microscope)
>     (add-hook #'examine doubler)
>     (add-hook #'examine telescope)
>
>     (examine "something")
>     > S O M E T H I N G
>     > S O M E T H I N G
>
> Hooks are functions that wrap other functions. They receive the
> original function and its arguments as their arguments. Hook
> functions can wrap the target functions in binding, change the
> argument list, only run the target functions conditionally, or all
> sorts of other stuff.
>
> It was originally designed to be used for Leiningen plugins, but I
> realized the functionality was quite general, so I spun it off into
> its own library.
>
> Feedback welcome.
>
> -Phil

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

Re: Broken Link in Clojure Contrib Docs

[Tom Faulhaber]

Stu,

I don't see a commit from you on this.

Tom

On Jun 8, 6:16 am, Stuart Halloway  wrote:
> Fixed in the repos, thanks. Will show up in docs shortly.
>
> Stu
>
> > Hello all,
>
> > Not sure where to report this but I noticed a broken link when taking
> > a look at the docs for sql in Clojure Contrib.
>
> >http://richhickey.github.com/clojure-contrib/sql-api.html
>
> > The link for "Example code" points here:
>
> >http://code.google.com/p/clojure-contrib/source/browse/trunk/src/cloj...
>
> > Which is no longer around.  If I'm reporting this in the wrong place
> > then please let me know and I'll move the post.
>
> > Cheers,
> > Daniel
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: new Clojure Compiler...

[Tom Faulhaber]

Fabio,

Yes, there is a plan to implement Clojure in Clojure and protocols, et
al., are part of this.

This biggest part from a performance point of view is not the compiler
itself, but rather Clojure's persistent data structures (maps,
vectors, etc.).

You can find more of the discussion around this by searching the group
for "Clojure in Clojure" of "CinC"

HTH,

Tom

On May 13, 12:46 pm, Fabio Kaminski  wrote:
> Hi all,
>
> since clojure-dev its a managed list.. the question goes here..
>
> i read somewhere that protocols was implemented thinking (inclusive) for
> natively clojure the compiler, at this moment implemented in java.
>
> so, my question is, is this gonna happen?
> and if so, in what version of clojure we will see a native compiler...
>
> can some api clojure sources implemented in java turns native, and maintain
> a reasonable performance?
>
> Thanks,
>
> Fabio Kaminski
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: Trouble with Leiningen and Autodoc

[Tom Faulhaber]

Hi Joshua,

Autodoc depends on clojure 1.1, which Phil has suggested might be a
problem (he told me not to depend on a clojure version at all).

Let me pull that dependency and see if that fixes the problem.

Is this in your repo on github?

Tom

On May 1, 7:17 pm, joshua-choi  wrote:
> This is my project.clj:
>
> (defproject fnparse "3.á.3"
>   :description "A library for creating functional parsers in Clojure."
>   :dependencies [[org.clojure/clojure "1.2.0-master-SNAPSHOT"]
>                  [org.clojure/clojure-contrib "1.2.0-master-
> SNAPSHOT"]]
>   :dev-dependencies [[autodoc "0.7.0"]])
>
> I run "lein deps", and it works. But then I run "lein autodoc", and I
> get the following:
>      [null] # (autodoc.clj:1)>
>      [null] Make sure autodoc is added as a dev-dependency in your
> project.clj.
>
> Do I need to do something else?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: Documentation (was: Re: duck-streams missing from clojure-contrib.jar file)

[Tom Faulhaber]

Hi all,

(For those who don't know, I'm the one who maintains the autodoc API
documentation.)

There are some great suggestions here and I'll try to pick up as many
as I can. More useful branch names and having the branch in the title
are no brainers and I'll try to get them in soon.

One resource to use is the index included with each API. (See the
index link in the left sidebar.) This has every function, macro and
var in the whole library with a snippet of their doc. I find this to
be pretty useful sometimes, especially when I don't remember which
namespace something's in. I've always wished the Python doc had this
feature!

A couple things I've also been thinking about are building in a search
capability and building a "super-index" of not only core and contrib
but various other external libraries that would link back to their
doc.

Please also understand that Clojure is a young language and things are
still very much under development. We're still understanding what our
"best practice" is and how to approach it. As you point out,
clojure.contrib.io is an example where we're not there yet, but it is
happening. clojure.contrib.io is a precursor for a clojure.io
namespace that will unify these things.

Thanks for the ideas! Keep 'em coming.

Tom

On Apr 21, 8:39 am, Douglas Philips  wrote:
> On 2010 Apr 21, at 9:31 AM, Stuart Halloway wrote:
>
> > The second level header tells you the branch (e.g. master). On the  
> > left hand side is a list of branches (so you can click on e.g. 1.1.x).
>
> Wow, that is quite subtle. As you click into contrib from clojure.org  
> it isn't very noticeable.
> It also isn't something you notice if you are, for example, clicking  
> through from the unversioned clojure.org pages.
> An example at random:
>      Start at:http://clojure.org/macros
>      then click on the lazy-cat link, which takes you 
> to:http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/
> lazy-cat
>      and start browsing.
>
> With your focus down 'into' that page you have no idea that you've  
> jumped into versioned information.
>
> If you start as a beginner, as I did, the stuff on clojure.org is not  
> versioned (there is no master/1.1.x link in the side bar) and so  
> having version info appear only in contrib pages is not easy to  
> notice, particularly if you get there via links from the main page.
>
> > Some ways I see this might be better:
>
> > (1) make clear what master currently equals (right now it is 1.2  
> > alpha)
>
> That would help. Master is pretty generic.
>
> > (2) highlight the branch info more with css
>
> Couldn't hurt, but it it'd be nice if showed in the page title too,  
> the sidebars are lost when scrolling down into the various pages.
>
> > (3) push the branch info into the top-level header (and page title)
>
> Yup.
>
> > (4) The overview section for c.c.io could tell about the lineage  
> > back to 1.1.
>
> Not having been along for the ride since (nearly) the beginning,  
> having those breadcrumbs would be helpful to me.
>
> > Which of these (or what else?) would have helped you the most?
>
> I think having the default, as Alex Osburne suggested, be the stable  
> release would have made my exploration of 1.1 a lot less painful.
>
> And along those lines, distinguishing between core and contrib is  
> something that might be important to the maintainers, but not so much  
> to the users. And, very less useful to newbies trying to get something  
> useful done.
>
> Trying to figure out that spit is in a contrib library and slurp  
> isn't? C'mon. I finally broke down and used google, and then when I  
> saw a thread back in '08 about that, and it still isn't addressed?  
> Really, easy file I/O is that unimportant to most clojure users?
>
> Having a unified and comprehensive index of functions/macros  
> (annotated with core/contrib) would also go a long way to making the  
> clojure documentation environment a lot more useful. Oh, and then  
> there is the distinction betweenhttp://clojure.org/librariesand the  
> contrib libraries. Yet another place to look? Great, I really don't  
> have anything better to do than internalize these distinctions? (In  
> case you can't tell, having burned -hours- of spare time trying to  
> find my way around docs has been exceptionally frustrating.)
>
> At least for someone like me who is exploring on their own and isn't  
> getting paid to make this work, having to lose my train of thought for  
> 5-10 minutes while trying to figure out if something is core or  
> contrib is hugely frustrating and demotivating. Then throw in a "wtf?  
> why isn't this working in the stable release" only makes it more so  
> when I'm looking at the wrong docs and didn't even know that there  
> were versioned docs.
>
> If you want an example of the kind of structure that I do find  
> helpful, look at docs.python.org. How many times on that page do you  
> see that you're lookin at the 2.6 docs and that there are links to  
> o

Re: newbie question: Please help me stop creating constructors

[Tom Faulhaber]

You can combine let and binding like this to make this slightly more
elegant:

(let [a# 'expr involving *A* *B* and *C*''
  b# 'expr involving *A* *B* and *C*''
  c# 'expr involving *A* *B* and *C*'']
  (binding [*A* a#
   *B* b#
   *C* c#]
 ...))

Note the x# form which does an implicit gensym for you so you get
unique names.

This at least reduces it from n levels to two levels. It would be
pretty easy to build a parallel-binding macro that did this for you.

hth,

Tom


On Feb 17, 10:09 am, Yaron  wrote:
> I did but it requires two levels of macro and that made me nervous.
> The problem is derived values. When defining a binding, near as I can
> tell, the values in the binding cannot see other values in the
> binding. In other words:
>
> (def *A* 10)
> (binding [*A* 3 B (+ foo 1)] B)
>
> Returns 11, not 4.
>
> So to use the macro I have to:
>
> (def *A* bogus_value)
> (def B bogus_value)
>
> (defmacro in-environment [env & body]
>   `(binding [*A* :A ..]
>     (binding [B (+ *A* 1)...]
>     �...@body))
>
> I think this would actually work. But it requires a bunch of
> accounting (all the bogus global defs) and introduces some worrisome
> ordering issues. For example, let's say I have a value C whose
> definition is (def C (+ B 1)). I can't define it using the previous
> macro. Because, again, bindings can't see each other. So now I'd have
> to write a macro that dynamically created a whole set of nested
> bindings. Which seems like a lot of work.
>
> In other words:
>
> (binding [*A* :A...]
>   (binding [B (+ *A* 1)...]
>    (binding [C (+ *B* 1)...]
>      etc.
>
> And I can't use let (which does allow for internal visibility) because
> then other functions I call will bind to the global value not the let
> value.
>
>    Yaron

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

Re: Clojure API doc updated with both master and 1.1 (finally)

[Tom Faulhaber]

Sean,

Maybe, but it's not very high on my current priority list. Things like
automated github pages and better searching and formatting are higher
on the list (as well as a bunch of work on pretty print).

Do you know of a project that is using autodoc that needs this? That
would be a powerful impetus (as well as a good test case).

Tom

On Feb 17, 5:12 am, Sean Devlin  wrote:
> Is the long term plan to include this multi-branch behavior in the
> lein pluggin too?
>
> Sean
>
> On Feb 17, 3:27 am, Tom Faulhaber  wrote:
>
> > The autodoc robot that builds the API docs choked sometime after the
> > merge of the new branch into master and the clojure and  clojure-
> > contrib API documents haven't been updating for the past 6 weeks or
> > so. This has been unfortunate because it's been a time of momentous
> > change (deftype and defprotocol, in particular).
>
> > As it turns out, it was a busy period in my life as well, so I didn't
> > get on top of it as quickly as I would have liked.
>
> > However, I have good news: the autodoc robot now supports
> > documentation in multiple branches. I have run this and installed it
> > for the clojure API docs themselves so you can see both the master
> > branch (with all the cool new stuff) and the 1.1.x branch (with all
> > the stable stuff) athttp://richhickey.github.com/clojure/index.html.
>
> > Multi-branch versions of clojure-contrib and incanter coming up RSN.
>
> > Let me know if you see any probs in the docs.
>
> > Thanks & Enjoy,
>
> > 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Clojure API doc updated with both master and 1.1 (finally)

[Tom Faulhaber]

The autodoc robot that builds the API docs choked sometime after the
merge of the new branch into master and the clojure and  clojure-
contrib API documents haven't been updating for the past 6 weeks or
so. This has been unfortunate because it's been a time of momentous
change (deftype and defprotocol, in particular).

As it turns out, it was a busy period in my life as well, so I didn't
get on top of it as quickly as I would have liked.

However, I have good news: the autodoc robot now supports
documentation in multiple branches. I have run this and installed it
for the clojure API docs themselves so you can see both the master
branch (with all the cool new stuff) and the 1.1.x branch (with all
the stable stuff) at http://richhickey.github.com/clojure/index.html.

Multi-branch versions of clojure-contrib and incanter coming up RSN.

Let me know if you see any probs in the docs.

Thanks & Enjoy,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Pattern Matching

[Tom Faulhaber]

Also, check out Tim Lopez's work here: 
http://www.brool.com/index.php/pattern-matching-in-clojure

He has a nice version that can be used for both Lisp-y and Haskell-y
stuff, though it's not quite as full featured as what you'd see in
traditional AI systems.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Autodoc for the masses

[Tom Faulhaber]

> Looks great! A couple comments.

Thanks!

> * Adding "by unknown author" to namespaces that have no author metadata
>   seems a bit superfluous.

Yeah, that's on my list to clean up. I did that in the old days to
shame the contrib authors into adding the metadata (and remind me to
bug them), but clearly for lots of projects it makes no sense.

In the meantime, it's not too hard to do by hand. Once you've got it
set up, all you have to do is do a "git commit" in the autodoc
directory after running autodoc. See the documentation for full info
on getting it set up.

> * Have you thought about a task to automatically upload the HTML files
>   to github? I haven't used Github Pages; is this something that could
>   be done using jcsh, or would it require shelling out to scp?

Yup, and it's on its way. I was thinking I'd use ant. It's just
executing some git stuff and I already have the ant code for it. I was
thinking I'd lancet-ify it and enable a call out. The service version
of autodoc is a mix of ant calling autodoc calling ant - real set your
hair on fire kind of stuff. I'm slowly trying to rationalize it down
to "pure" clojure.

> * It would be great to be able to provide a logo image that would be
>   included as in Incanter's docs.

It's possible. I need to add doc for how to do it.

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

Autodoc for the masses

[Tom Faulhaber]

Now your project can have the same documentation as Clojure, clojure-
contrib, and Incanter!

The standalone autodoc tool is now available. It can be run from the
command line and it integrates with Leiningen and ant. (Maven still to
come - let me know if you want to help.)

Autodoc builds full, styled HTML documentation from your doc-strings
and other metadata you supply. It includes a project overview page,
separate pages for each namespace, and an overall index page.

It builds pages suitable for use with github pages so you can easily
publish documentation and can include links to source code if you
publish source.

Documentation on how to get and use Autodoc is here:
http://tomfaulhaber.github.com/autodoc/ (apologies for the fact that
the doc is not yet pretty!).

I hope that Autodoc helps you increase the quality of documentation
for your projects.

Enjoy,

Tom Faulhaber

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

Re: How do I extend an existing function to take different number of params?

[Tom Faulhaber]

Yup, this version would cover most cases in a simpler way. My goal
(for no particular reason except it entertained me) was to make
something that worked as much like defn as possible. Most of the
complexity is because of handling the possible combinations of arities
that we might see as a result: I need to "fill in the holes" with
proxies (though I could have wrapped with an if as well).

extend-fn is also a much better name.

I'm amused that you did the same thing I did before I realized it was
silly: "old-fn# (var-get (var ~name))" can just be "old-fn# ~name".
(It's like "use" and "utilize" one of my pet peeves in English.)

Tom



On Jan 10, 1:03 am, Amit Rathore  wrote:
> Here's some (simpler?) code that will work for adding arity to
> existing functions -http://gist.github.com/273401
>
> It doesn't handle adding variable-arity (ie multiple arity using &) to
> existing functions, but can add specific arity to existing varibale-
> arity functions
> It also doesn't handle adding more than one arity at a time, but you
> can call it multiple times with different arity to get the same
> effect. See example below -
>
> An example to add arity -
>
> user> (extend-fn keyword [ns name suffix]
>         (keyword ns (str name "-" suffix)))
>
> user> (extend-fn keyword [ns prefix name suffix]
>         (keyword ns (str prefix "-" name "-" suffix)))
>
> Here's the example usage -
>
> user> (keyword nil "hello")
> :hello
>
> user> (keyword nil "hello" "more")
> :hello-more
>
> user> (keyword nil "oh" "hello" "more")
> :oh-hello-more
>
> Again, like Tom said, dunno why you'd need to do this...
>
> On Jan 9, 10:45 pm, Tom Faulhaber  wrote:
>
> > Actually this is possible. (seehttp://xkcd.com/386/)
>
> > See the macro add-arity which I've put up here:http://gist.github.com/273349
>
> > This allows you to do things like:
>
> > user> (add-arity keyword [ns name suffix] (keyword ns (str name "-"
> > suffix)))
> > #
>
> > user> (keyword nil "hello" "more")
> > :hello-more
>
> > The code I put up will handle (I think) all sorts of variations of arg
> > counts: you can use add-arity just like defn and it will grab any
> > specified arglists (including arglists with &) and proxy the others
> > back to the original function. It doesn't do anything with metadata,
> > though. Also, you can override a given arity on the original function,
> > but you can't then call the original version at that arity.
>
> > Whether this is a good idea or not is a completely different
> > question :-)
>
> > 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How do I extend an existing function to take different number of params?

[Tom Faulhaber]

Actually this is possible. (see http://xkcd.com/386/)

See the macro add-arity which I've put up here: http://gist.github.com/273349

This allows you to do things like:

user> (add-arity keyword [ns name suffix] (keyword ns (str name "-"
suffix)))
#

user> (keyword nil "hello" "more")
:hello-more

The code I put up will handle (I think) all sorts of variations of arg
counts: you can use add-arity just like defn and it will grab any
specified arglists (including arglists with &) and proxy the others
back to the original function. It doesn't do anything with metadata,
though. Also, you can override a given arity on the original function,
but you can't then call the original version at that arity.

Whether this is a good idea or not is a completely different
question :-)


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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Language similarities

[Tom Faulhaber]

I can attest from personal experience that many of the folks who were
working on Ada were quite familiar with everything going on with Lisp
as well as Smalltalk and other language trends of the day (this was
around 1980).

While many of the ideas in Ada aren't so popular now (and weren't even
while the language was being developed), it certainly wasn't due to
ignorance of what was happening around them.

Tom

On Jan 1, 10:45 am, David Brown  wrote:
> On Fri, Jan 01, 2010 at 12:31:16PM -0500, Mike Meyer wrote:
> >On Fri, 1 Jan 2010 13:45:43 -0300
> >Angel Java Lopez  wrote:
>
> >> I would like to add Ada exception management. I don't know if there were
> >> previous work on the field. Any info? I worked with Algol, but I don't
> >> remember if something like exceptions was present those days. Any early 
> >> Lisp
> >> exception management?
>
> >Try/Catch were add to MacLisp in 1972, because the previous error
> >handling facilities (ERR/ERRSET) were being abused to get that
> >behavior. This predates the formation of the Ada working group by a
> >couple of years.
>
> I don't think I've ever seen any cross references between any of the
> Lisp documentation and any of the Ada documentation.  The Ada
> rationale only references a couple of obscure papers about exceptions.
> Perhaps they didn't want to scare people by mentioning where they got
> the idea.
>
> I guess another concept that wasn't really accepted until a
> "mainstream" language started using it.
>
> David

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

Re: Where is the Clojure 1.0 API documentation?

[Tom Faulhaber]

Enhancing the doc tool so that we have versions for the multiple
branches (1.0, 1.1, master, new) is on my agenda.

Maybe there's a way that Rich could add a link to the old 1.0 doc in
the meantime.

I think that the "added in version" metadata tag is a good idea, at
least for clojure itself. Python does this and I've always liked it.

Tom

On Dec 9, 5:43 am, Mark Tomko  wrote:
> I second this - since many of the IDE plugins bundle the clojure-1.0
> jar, new users trying out Clojure (and IDEs) can't use all the
> features listed in the docs, and it's hard to tell which is which.
> Maybe we could at least add a 'added in version' to the new method
> metadata?
>
> On Dec 9, 4:48 am, Jarkko Oranen  wrote:
>
> > I just noticed that the API link on the clojure web site brings up
> > documentation for the master branch of Clojure instead of 1.0.0. I
> > can't find the 1.0.0 docs anywhere either.
>
> > This is obviously a problem for 1.0.0 users, since the docs refer to
> > features that don't exist.
>
> > I think it would be good to have the API page contain links to 1.0.0
> > docs as well as master and perhaps other branches as well. Also, a
> > clear indication (preferably in a bold font or something) of which
> > revision the doc was generated for would be useful.
>
> > --
> > Jarkko

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

Re: new API webpage format

[Tom Faulhaber]

Rich applied the patch this morning.

Let me know if there are any other problems.

On Dec 8, 6:13 am, Sean Devlin  wrote:
> (inc apply-219-to-1_1)
>
> On Dec 8, 1:57 am, Tom Faulhaber  wrote:
>
> > It turns out the doc string for filter was dropped during a checkin
> > earlier this year. I surprised no one noticed sooner (I guess everyone
> > just knows how filter works).
>
> > I have filed ticket 219 with a patch and hopefully we'll get it into
> > 1.1.
>
> > I didn't see any others missing, have you seen others?
>
> > Thanks for catching that,
>
> > Tom
>
> > On Dec 7, 4:00 pm, Tom Faulhaber  wrote:
>
> > > By golly, you're right. I'll take a look at why.
>
> > > On Dec 7, 2:14 pm, cej38  wrote:
>
> > > > Hi,
> > > >   I am writing because there seem to be missing functions in the API
> > > > webpage.  The only one that I know for sure at the moment is the
> > > > filter function.

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

Re: "master" Clojure API doc now live

[Tom Faulhaber]

github.com/tomfaulhaber/contrib-autodoc

Have fun with it!

On Dec 8, 6:38 am, Tom Hickey  wrote:
> Hi Tom
>
> I was looking for this code as well.
>
> Thanks,
> Tom
>
> On Dec 8, 7:38 am, Timothy Pratley  wrote:
>
> > On Dec 4, 6:31 am, Tom Faulhaber  wrote:
>
> > > We now have an official site forAPIdocumentation on the latest
> > > master branch of Clojure, for those who aren't content to stay with
> > > the release version.
>
> > Hi Tom,
>
> > May I ask where the code that generates the docs lives? (I'm sure it
> > has been posted before but can't seem to dig it up)
>
> > Regards,
> > Tim.

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

Re: new API webpage format

[Tom Faulhaber]

I like that too. I'll have to think about how we'd do that.

On Dec 7, 8:11 pm, ataggart  wrote:
> While we're throwing requests at Tom, it'd be nice if the special
> forms were included in the api.
>
> On Dec 7, 5:21 pm, Tom Faulhaber  wrote:
>
> > Yup, I heard that the first time :-)
>
> > It's coming, but not right this sec.
>
> > Tom
>
> > On Dec 7, 4:57 pm, Howard Lewis Ship  wrote:
>
> > > I still think it would be neat if there was some DHTML coolness to
> > > help narrow down the symbol names that come down the right side of the
> > > page.
>
> > > On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber  
> > > wrote:
> > > > By golly, you're right. I'll take a look at why.
>
> > > > On Dec 7, 2:14 pm, cej38  wrote:
> > > >> Hi,
> > > >>   I am writing because there seem to be missing functions in the API
> > > >> webpage.  The only one that I know for sure at the moment is the
> > > >> filter function.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Clojure" group.
> > > > To post to this group, send email to clojure@googlegroups.com
> > > > Note that posts from new members are moderated - please be patient with 
> > > > your first post.
> > > > To unsubscribe from this group, send email to
> > > > clojure+unsubscr...@googlegroups.com
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/clojure?hl=en
>
> > > --
> > > Howard M. Lewis Ship
>
> > > Creator of Apache Tapestry
>
> > > The source for Tapestry training, mentoring and support. Contact me to
> > > learn how I can get you up and productive in Tapestry fast!
>
> > > (971) 678-5210http://howardlewisship.com

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

Re: new API webpage format

[Tom Faulhaber]

It turns out the doc string for filter was dropped during a checkin
earlier this year. I surprised no one noticed sooner (I guess everyone
just knows how filter works).

I have filed ticket 219 with a patch and hopefully we'll get it into
1.1.

I didn't see any others missing, have you seen others?

Thanks for catching that,

Tom

On Dec 7, 4:00 pm, Tom Faulhaber  wrote:
> By golly, you're right. I'll take a look at why.
>
> On Dec 7, 2:14 pm, cej38  wrote:
>
> > Hi,
> >   I am writing because there seem to be missing functions in the API
> > webpage.  The only one that I know for sure at the moment is the
> > filter function.

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

Re: new API webpage format

[Tom Faulhaber]

Yup, I heard that the first time :-)

It's coming, but not right this sec.

Tom

On Dec 7, 4:57 pm, Howard Lewis Ship  wrote:
> I still think it would be neat if there was some DHTML coolness to
> help narrow down the symbol names that come down the right side of the
> page.
>
>
>
> On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber  wrote:
> > By golly, you're right. I'll take a look at why.
>
> > On Dec 7, 2:14 pm, cej38  wrote:
> >> Hi,
> >>   I am writing because there seem to be missing functions in the API
> >> webpage.  The only one that I know for sure at the moment is the
> >> filter function.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210http://howardlewisship.com

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

Re: new API webpage format

[Tom Faulhaber]

By golly, you're right. I'll take a look at why.

On Dec 7, 2:14 pm, cej38  wrote:
> Hi,
>   I am writing because there seem to be missing functions in the API
> webpage.  The only one that I know for sure at the moment is the
> filter function.

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

Re: API pages

[Tom Faulhaber]

Yeah, I remember seeing that on IRC, but never knew what to do about
it.

It's hard for me to diagnose since I'm not seeing it in Firefox 3.5.4
on my systems (1 Ubuntu, 2 Windows). If anyone who's seeing it can
give me more info, I'd fix it up.

More generally, if there's someone in the community with more HTML/CSS
mojo than I have, I'd love to have you join the project to help out
with this kind of problem. The CSS is derived from the wiki CSS for
clojure.org and it's ugly and gross. It definitely needs to be cleaned
up.

Overall the cross-browser look and feel could be cleaned up
substantially.

You can download the source for the built documentation from the gh-
pages branch of Clojure itself and just muck around with the
formatting. All the css is in the static/ directory. Grab the tree
from http://github.com/richhickey/clojure/tree/gh-pages.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

"master" Clojure API doc now live

[Tom Faulhaber]

Folks,

We now have an official site for API documentation on the latest
master branch of Clojure, for those who aren't content to stay with
the release version. It is on GitHub here: http://richhickey.github.com/clojure/

This will be kept up-to-date with the GitHub checkins to master within
a couple of minutes.

While the formatting is not yet perfect, I have fixed all known
operational bugs (links, etc.). If you see something that looks bad in
some browser, a link that's messed up or some other problem, let me
know and I'll get it fixed up.

A couple of you suggested some nice enhancements when I posted the
test version of the page. I haven't gotten to them yet, but I haven't
forgotten them either. They are on the list.

Also on my list is support for doc for each active branch (the
released branches plus new, etc.). Stay tuned...

Enjoy,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: AOT'd namespaces lose their metadata

[Tom Faulhaber]

Yup, that's right - I filed ticket 130 to reflect this. If I get there
first, I'll mark the ticket as well and we can compare notes.

I'm super-excited about Leiningen, btw. I've been thinking about how
to turn my autodoc stuff into a Leiningen plugin so that we can get
easy doc for any project.

On Nov 24, 8:48 pm, Phil Hagelberg  wrote:
> Tom Faulhaber  writes:
> > So, Phil, if you want to take it from there, it would be great. If you
> > don't, I'll keep it on my list.
>
> Thanks for the notes; nice to see someone has done some detective work
> already. I'll probably try to take a look at this once I get Leiningen
> 1.0 out. It looks like ticket #130 in Assembla is about this problem, so
> I'll be sure to add a note to there once I start working on it.
>
> -Phil

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

Re: AOT'd namespaces lose their metadata

[Tom Faulhaber]

I did take a little bit of a look at it and it is both simple and
complex.

When you're not AOT compiling code, the symbol that's creating the
namespace gets wrapped with metadata when the ns macro is evaluated.
This metadata is then explicitly moved on to the namespace.

When the compiler runs, it doesn't seem that it is so explicit about
namespace creation. It essentially does (in-ns 'foo) which will create
the ns foo on the fly if appropriate. There is currently no code
generated to do anything *explicit* with the namespace and, therefore,
no place to decide that the namespace has metadata and tack it on.

I got about as far as I could eyeballing the code and wanted to get it
up in the debugger, but I don't have a Java debug environment set up
and my Clojure time has been super limited lately owing to all sorts
of other things happening in my life (I am *so* jealous of you guys
who are doing makor Clojure projects). If I get some time, I'll dig in
enough to make a patch, but it might be a few more months. I feel like
the fix will be pretty easy, once the real flow is well-understood.
This is my first foray into the compiler, so there's a lot to
understand (though it's all pretty straightforward).

So, Phil, if you want to take it from there, it would be great. If you
don't, I'll keep it on my list.

Tom


On Nov 23, 2:38 am, Lauri Pesonen  wrote:
> 2009/11/23 Phil Hagelberg :
>
>
>
> > I noticed an odd bug when working on the help command for leiningen. It
> > uses docstrings on metadata for help output, but when AOTing the
> > project, the docstrings (as well as all other metadata) would be
> > lost. Note that this doesn't happen when metadata is added to the
> > namespace after the fact as is the case with clojure.core and
> > alter-meta!.
>
> > Any idea what might be causing this? I'd like to dig deeper but am
> > unsure where to look.
>
> There's a ticket for it
>
> https://www.assembla.com/spaces/clojure/tickets/130-Namespace-metadat...
>
> but I don't think anyone's spent any time in trying to fix it.
>
> > thanks,
> > Phil
>
> --
>   ! Lauri

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

Re: ANN: Autodoc for clojure core, first rev

[Tom Faulhaber]

On Nov 9, 1:28 pm, Howard Lewis Ship  wrote:
> It looks very nice ... still I'd love to see something like what
> clj-doc does (http://github.com/mmcgrana/clj-doc) ... it adds a text
> field that you can type into and it matches the available names
> against what you type, hiding the rest.

Great idea. As I said in another message, I've been resisting having
any JS driven stuff while I get the HTML/CSS ironed out, but that's a
natural thing to add.

> I'll see if I can find some time to help ... where's the code? (i.e.,
> what git repo do I clone?)

The code is at http://github.com/tomfaulhaber/contrib-autodoc. The
clojure core documentation is built by the code on the "general"
branch. (The master branch is still clojure-contrib specific. Once I
get "general" so that it can build both clojure and clojure-contrib, I
will merge them back together.

I will warn you, however, that there is a crazy amount of mechanism
here (mostly undocumented) that I'm still working out. So I don't
consider this to be supported code yet.

On Nov 9, 1:42 pm, Konrad Hinsen  wrote:
> But please add clojure.test and clojure.parallel as well!

Oops, missed those. Thanks for spotting them.

On Nov 9, 2:21 pm, Michael Jaaka  wrote:
> Why when I click on left in the index menu, the description of a  
> function shows on top?
> It should be right next to clicked position, so I won't scroll whole  
> page on top in order to read doc.

I'm not sure I understand this. Do you mean, why doesn't the link on
the API index page go straight to the function? That's a bug. Fixed
soon.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: Autodoc for clojure core, first rev

[Tom Faulhaber]

>    Great work getting this to work for core.  This will really,
> really, really help those of us running edge Clojure.

Thanks. Glad to help.

>    BUGS:

Yup, know about all these. The right margin thing can be fixed by
making your window wider :-).


>    ENHANCEMENTS:
>    * Each namespace has a list of public variables/fns. It feels a bit
> long for some of the larger namespaces.  Maybe a combination of ul
> elements and a jquery/script.acul.us expander div could go a long way?

Yeah, clojure.core in particular has a lot of stuff in it relative to
any of the namespaces in contrib. I'll think about the right approach.
I've generally been avoiding scripting to make the whole doc package
easier to deal with in a variety of scenarios (not just web hosted,
but downloadable, etc.).

>    * In the HTML you use the same value in the id attribute of many
> tags. (e.g. id="var-tag", id="var-link").  Should you be setting the
> class attribute instead?

These ids aren't for styling but rather are used by the enlive
templating that builds the pages from fragments. So it doesn't matter
that they are duplicated.

But they probably should be classes anyway to be a little cleaner.

>
>    Despite these minor concerns, I am very excited about this.  Thank
> you for doing this for us.

No problem.

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

ANN: Autodoc for clojure core, first rev

[Tom Faulhaber]

Hi all,

I've been adapting my documentation robot to work for things other
than contrib and the first result is now available: documentation for
HEAD in clojure core.

You can find it here: http://tomfaulhaber.github.com/clojure/

There are still a few bugs in the links and some of the clojure core
classes could use improved documentation, but the info should all be
there. It's definitely a nice thing for those of us who have been
keeping up with core since 1.0. (See, for instance
http://tomfaulhaber.github.com/clojure/clojure.core-api.html#clojure.core/juxt)

Enjoy! And let me know your thoughts and suggestions.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: bugs in cl-format.clj

[Tom Faulhaber]

OK, fixed. Grab the latest contrib from github and you should be all
set.

Feel free to let me know directly if you see any other issues. I'm
sure they're there! :-)

Tom

On Oct 30, 11:20 pm, Tom Faulhaber  wrote:
> I've added assembla ticket #40 for these 
> issues:https://www.assembla.com/spaces/clojure-contrib/tickets/40-bugs-in-cl...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: bugs in cl-format.clj

[Tom Faulhaber]

I've added assembla ticket #40 for these issues:
https://www.assembla.com/spaces/clojure-contrib/tickets/40-bugs-in-cl-format
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: bugs in cl-format.clj

[Tom Faulhaber]

Hey Carlos,

Thanks for noticing these. I'll take a look.

I think cl-format has the most tests of anything in Clojure and it
still has lousy test coverage of all the cases it's supposed to cover.

Tom

On Oct 28, 4:53 pm, carlitos  wrote:
> Hello,
>
> I've encountered a couple of issues with the cl-format function
> included in contrib.pprint
>
> (cl-format nil "~1,1$" -12.0) ;; => "12.0"  the sign is lost
>
> I think the problem is the following assignment in the dollar-float
> function
>         add-sign (and (:at params) (not (neg? arg)))     ;; wrong
> (the sign is only printed when the colon modifier is present and only
> for positive numbers)
> that should read, if I understand correctly the logic,
>         add-sign (or (:at params) (neg? arg))
>
> The second issue is not so straightforward to solve:
>
> (cl-format true "~1,1$~%" 0.001) ;; => String index out of range: -1
>
> I've tracked down the bug into the function round-str (the variable
> round-pos will be negative and this case is not handled properly), but
> I don't understand the code well enough to propose a fix.
>
> Cheers,
>
> Carlos
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: How to make lazy seq from socket input?

[Tom Faulhaber]

One thing to keep in mind, when using sockets, is that TCP does not
guarantee to keep packetization across the network. That is, just
because you're writing lines, doesn't mean that read will return
lines. TCP can put writes together or break them into parts or some
combination of both.

So if you need a seq of lines, you need to look at the individual
bytes and find the line breaks. But you probably won't want to read
each byte separately, use a BufferedReader or some such.

HTH,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Observations from a real-world Clojure project

[Tom Faulhaber]

>
> 5. The functionality of the docs hasn't kept up with Clojure.  We
> often resorted to text searches of the various sources.  Need links
> and see-also's.  Clojure has grown/matured so much that it needs a doc
> system of some sort.
>


This has been recognized for awhile now. I have promised to extend the
documentation system we use for clojure.contrib (see
http://richhickey.github.com/clojure-contrib/) to clojure itself. This
will mean that we have up-to-the-minute doc on the latest Clojure (as
well as info for historical versions and, eventually, all the
branches) with links to the source code, the ability to attach more
detailed docs, link to URLs, full index, etc.

This has been taking awhile because my real life (both work and
personal) has been ridiculously crazy the last few months. But I have
begun to lean in on it and think I should have a preliminary version
running with the next couple of weeks.

The goal is that this system will be generalizable for all projects
and can be used as a sort of "javadoc" for Clojure libraries (with
extra bonuses like direct github support).

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: function rebinding and logging

[Tom Faulhaber]

Hey Jeff,

Craig McDaniels wrote a little trace library that does on-demand
function wrapping that does pretty much what you're looking for.

Look here:
http://groups.google.com/group/clojure/browse_thread/thread/3ea8777880231e18/6fd1b352ac1a6744?lnk=gst&q=trace#6fd1b352ac1a6744

I implemented a more general version of this in the wrapping-fn macro
in my (still-incomplete) object explorer here:

http://github.com/tomfaulhaber/clj-explorer/blob/master/com/infolace/explorer.clj#L29

The main difference between these approaches is that my version wraps
the function within a particular scope while Craig's modifies the root
binding. Which is right for you depends on your use case.

HTH,

Tom

On Oct 21, 6:41 am, Jeff Sapp  wrote:
> That's a good point. I hadn't thought about how wrapping all functions
> might be detrimental because of side-effect issue you mentioned.
>
> I guess I was thinking of something I could turn on and off easily.
> But even then, like you mentioned, just wrapping all the functions
> probably wouldn't be very helpful. I think I was just looking for an
> easy solution. I'll have to put more thought into my problem. Thanks
> for setting me straight!
>
> ~jeff
>
> On Wed, Oct 21, 2009 at 7:05 AM, Robert Lally  wrote:
> > I'd be a little concerned about wholesale wrapping of functions, purely from
> > the perspective that you'll be wrapping mostly side-effect free functions
> > with functions that do have side-effects. That sounds like something you'd
> > want to do consciously, where you know it will be safe, and where the
> > results will be meaningful ( I imagine that logging inside retry blocks
> > could reduce your logs to meaningless pudding pretty quickly ).
> > On the other hand, I could just be being paranoid.
>
> > R.
>
> > 2009/10/20 Jeff Sapp 
>
> >> Hey, I'm working on a small to medium sized, hopefully commercial
> >> product in clojure. I'll be providing an API to clients, and I'm also
> >> going to have to make some performance guarantees about a few of my
> >> functions. Because of that (as well as a few other reasons), I'm very
> >> interested interested in being able to log every little detail related
> >> to client interaction including call times for some critical
> >> functions.
>
> >> In the past I would have defined a macro similar to
> >> clojure.contrib.trace/deftrace, let's say named defn-logging, that
> >> wrapped it's definition in the appropriate logging functions. Then I
> >> would have defined all my functions with defn-logging instead of defn.
> >> This is completely unfounded, but that doesn't strike me as being very
> >> clean. Am I justified in thinking this?
>
> >> I had one, probably very bad, idea of creating a separate namespace
> >> for the logging functions that simply pointed to their non-logging
> >> counterparts in the original namespace. I'm not sure if that's even
> >> possible without wrapping defn in a macro. Certainly, I think it'd be
> >> difficult to do cleanly.
>
> >> During Rich's "Clojure for Lispers" talks, he mentioned rebinding
> >> functions, and being able to use it for the purpose of logging. I
> >> think in my case, I'd need to do this globally some how to avoid using
> >> a macro like defn-logging. It's escaped me, how would I go about doing
> >> this? Is redefining global values like this a good idea?
>
> >> Any suggestions?
>
> >> Thanks,
> >> ~jeff
>
> > --
> > Blog :http://robertlally.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Another defmult VS defn query

[Tom Faulhaber]

Check out clojure.contrib.duck-streams/reader and clojure.contrib.duck-
streams/writer (http://richhickey.github.com/clojure-contrib/duck-
streams-api.html).

They'll give you a java.io.BufferedReader or a java.io.PrintWriter
which is usually what you want with a file. If you have some other
use, you can look at the source (linked from the above doc) and see
how Stuart did the multimethods.

hth,

Tom

On Oct 8, 7:48 am, lpetit  wrote:
> Oh, maybe this as-file method already exists in clojure.contrib,
> honestly I don't know and don't have the time to search right now,
>
> regards,
>
> --
> laurent
>
> On 8 oct, 16:41, Laurent PETIT  wrote:
>
> > Suggestion :
>
> > move and generalize the problem by creating an as-file multifn that may take
> > String, File , and maybe other things later ...
>
> > (defmulti as-file type)
> > (defmethod as-file String [from] (File. from))
> > (defmethod as-file File [from] from)
>
> > (defn mv [from to]
> >   (let [ [from to] (map as-file [from to]) ]
> >     (println "transformed to file"))
>
> > cheers,
>
> > --
> > laurent
>
> > 2009/10/8 Robert Stehwien 
>
> > > Here is another question on when you would use a multi-method.  I want the
> > > mv function to accept a java.io.File or a String for either of the two
> > > parameters and here are the options I came up with:
>
> > > -(defmulti mv (fn [from to] [(class from) (class to)]))
> > > (defmethod mv [String String] [from to] (println "Both strings"))
> > > (defmethod mv [File File] [from to] (println "Both files"))
> > > (defmethod mv [File String] [from to] (println "File String"))
> > > (defmethod mv [String File] [from to] (println "String File"))
>
> > > (defn mv2 [from to]
> > >   (let [f (if (= (class from) File) from (File. from))
> > >         t (if (= (class to) File) from (File. to))]
> > >     (println "transformed to File")))
> > > -
>
> > > While I find that multi-methods allowing me to do the above exceedingly
> > > cool, would it be more idomatic to just use the let and create a File if
> > > passed a String.  Am I doing "too much work" for something relatively
> > > simple.
>
> > > The multi-method does have better (IMHO) errors when passed (mv ["foo"]
> > > "bar"):
> > > -
> > > No method in multimethod 'mv' for dispatch value:
> > > [clojure.lang.LazilyPersistentVector java.lang.String]
> > >   [Thrown class java.lang.IllegalArgumentException]
> > > -
>
> > > This would tell me that I could write another multi-method that could move
> > > multiple files from different locations passed in as a sequence to one
> > > destination... which I didn't think I needed but could be pretty handy now
> > > that I think on it.
>
> > > --Robert
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: (+ clojure cascading)

[Tom Faulhaber]

We've moved the Bay Area Clojure Meetup so that we can all come crash
your party instead.

It sounds super-interesting, but I'm not sure my friends will be
impressed :-).

Tom

On Sep 17, 8:50 pm, bradford cross  wrote:
> We're going to have a meetup on clojure and cascading and Rapleaf Sept
> 24th:  http://blog.rapleaf.com/dev/?p=196
>
> Come on by.
>
> Debate about function composition as a programming model for distributed
> computation.
>
> Impress your friends.
>
> -b
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: I just posted a discussion of building webhooks in Clojure with Ring

[Tom Faulhaber]

Thanks! Corrected.

On Sep 18, 1:32 am, James Reeves  wrote:
> On Sep 17, 11:35 pm, Tom Faulhaber  wrote:
>
> > You can find it 
> > here:http://infolace.blogspot.com/2009/08/simple-webhooks-with-clojure-and...
>
> A small correction: Ring is inspired by Rack, not Sinatra.
>
> - James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

I just posted a discussion of building webhooks in Clojure with Ring

[Tom Faulhaber]

In case this is interesting to anyone:

I just posted a description of how I created the webhook system for
the contrib autodoc robot using Ring. Nothing too profound, but
probably useful to others.

You can find it here: 
http://infolace.blogspot.com/2009/08/simple-webhooks-with-clojure-and-ring.html

Much thanks to Chouser and RHickey for fill-queue which makes this (oh
so) elegant.

Enjoy!

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: questions about datalog

[Tom Faulhaber]

Did you also read the overview that's part of contrib at
http://richhickey.github.com/clojure-contrib/doc/datalog.html.

I don't know if you already saw that, but since you didn't mention it,
I thought I'd be sure.

Tom

On Sep 12, 6:53 pm, Robert Luo  wrote:
> Thank you Josh for your answer.
>
> I have read the sources of datalog, however, literal.clj and the ideas
> of the query language behind it is unknown for me, thus I can not
> understand it quite well. The same thing happens when I saw magic.clj,
> in which file I saw "magic transformation".
>
> I ran the example you posted on github, which seems return 2 records
> because same room-id merged. However, if I want the result set look
> like this: {room-id: 1 :seat-number [1 2], :players ["joe" "smith"]},
> is it possible? Another question, there are many aggregate function in
> SQL, can it be used in the conjunctive query?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure-mode survey

[Tom Faulhaber]

Phil,

I didn't realize that had been implemented either, that's cool.

I'm not so excited about deriving authorship data from git, though. It
seems like there are a lot of reasons that could be "wrong" from the
point of view of what we want for the documentation (how do you decide
when a checkin represents a true "co--author?",  etc.). Having the
string there allows folks to use it with a little more nuance ("By
Stuart Sierra with some critical bug  fixes by Phil Hagelberg").

We also use that metadata field to add :see-also cross references,
though we don't use that as much as we did on google code.

I don't like the syntax so much either. It would be nice if (ns ...)
just took a map of metadata in addition to the docstring. There's an
opportunity of an issue/patch there and maybe I'll even make one
(though I haven't even had time to breathe lately).

But even if it did #^{} is legitimate syntax and emacs probably
shouldn't barf on it.

Tom

On Sep 10, 2:24 pm, Phil Hagelberg  wrote:
> Tom Faulhaber  writes:
> > Also, one thing that I (and others) have noticed is that clojure mode
> > chokes on the #^{} form metadata on namespaces. (See any of the files
> > in clojure-contrib for an example.) I'm not able to reproduce the
> > problem now, so if you don't already know what it is, I'll keep my eye
> > out for it and send you a proper report when I have it happening.
>
> So I just found out that you can add regular docstrings to namespaces as
> perhttp://code.google.com/p/clojure/issues/detail?id=30, which was
> actually news to me (I thought it was targeted for 1.1). Anyway, given
> that you can do docstrings with nicer syntax now and git supports far
> more detailed authorship data, is there any reason to still use the #^{}
> syntax for namespaces? I must confess I've never liked the way it looks.
>
> -Phil
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure-mode survey

[Tom Faulhaber]

Hi Phil,

Speaking for myself, I only use SLIME & emacs 23, though I certainly
wouldn't want to force anyone to do those things.

Also, one thing that I (and others) have noticed is that clojure mode
chokes on the #^{} form metadata on namespaces. (See any of the files
in clojure-contrib for an example.) I'm not able to reproduce the
problem now, so if you don't already know what it is, I'll keep my eye
out for it and send you a proper report when I have it happening.

Thanks for all your work on clojure-emacs integration. It makes all
the difference to us emacs heads!

Tom

On Sep 7, 5:36 pm, Phil Hagelberg  wrote:
> I'm working on cleaning up the code for clojure-mode.el, which provides
> Clojure support for Emacs.
>
> It includes some functionality for interacting with subprocesses. This
> is a small subset of the functionality of the functionality included in
> SLIME, but it's simpler and easier to configure.
>
> However, now that clojure-mode has the M-x clojure-install command that
> sets up SLIME etc, I don't know if the built-in subprocess features are
> worth keeping around any more. Personally I have never used them or
> heard of anyone using them; I wonder if they are just legacy baggage.
>
> Would anyone be opposed to their removal?
>
> thanks,
> Phil
>
> http://technomancy.us
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure vs scala

[Tom Faulhaber]

Plus, his spelling and grammar is atrocious. If you're going to write
a blog, proofread what you're writing!

(I know this is harder for non-English speakers, but it does make a
huge difference to the perceived quality of what you're saying.)

On Aug 25, 1:36 pm, Christian Vest Hansen 
wrote:
> I think he misrepresents both Scala and Clojure.
>
> On Tue, Aug 25, 2009 at 7:11 PM, Emeka wrote:
> > Hello All,
>
> > This sounds great!
>
> >http://codemonkeyism.com/clojure-scala-part-2/
>
> > Regards,
> > Emeka
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: ANN: clojure-contrib automatic documentation system "complete"

[Tom Faulhaber]

Rich:

Glad to help, thanks for the kind words.

For Clojure core, mostly what I need to do is refactor and
parameterize a bunch of stuff. I'll just make a fork and start
playing. When I have something, we can discuss and fine tune.

Should it be similar to what we have now with all the namespaces on a
single API page? Or would you like to go to something more like what I
have for contrib where each namespace has it's own page?


Aaron:

Agreed. That had been kind of bugging me for a while. I changed it now
to have the whole thing be the link - I might change it to have the
namespace name be the link too, but that feels a little less clear.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

ANN: clojure-contrib automatic documentation system "complete"

[Tom Faulhaber]

(I know this has been mentioned and referenced a number of times
already in this forum, but I have crossed some imaginary line to
"officially done" so I thought I'd put up an official announcement.)

The automatic documentation for the clojure-contrib library is now up
at http://richhickey.github.com/clojure-contrib.

This documentation has 3 parts:

1) The main page has an overview of each of the contributed namespaces
(each one represents a single capability that someone has contributed
to the library) along with a list of the public variables and
functions in that namespace.

2) A page for each namespace with an overview, links to supporting
documents, and documentation for each public variable with links to
the source code.

3) An API index that lists all the public variables in clojure-contrib
with links to complete documentation.

The documentation site is kept up-to-date with the latest commits of
clojure-contrib. (The site updates within about 5 minutes of a push to
clojure-contrib.)

If you'd like an offline copy of the documentation, go here
http://github.com/richhickey/clojure-contrib/tree/gh-pages and press
the "download" button.

I'm still polishing and tuning, so expect changes and improvements
going forward.

I'm also planning to generalize this capability to other projects.
Please let me know if you have a project for which you'd like to use
this.

Enjoy and let me know if you have any requests or suggestions,

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Promote clojure.contrib.def to a "core" lib

[Tom Faulhaber]

Docs for cutting edge Clojure are on the way. Rich said he was going
to think about the approach he wanted to take and we'll get it up and
running when he gets back from vacation.

Hang tight,

Tom

On Aug 14, 10:21 am, Sean Devlin  wrote:
> As long as the documentation doesn't disappear between the time the
> library is removed from contrib and the appropriate version (1.1, 1.2)
> of Clojure is released.
>
> Not-so-subtle 
> hint:http://groups.google.com/group/clojure/browse_thread/thread/8f191d3a9...
>
> Sean
>
> On Aug 14, 12:52 pm, Daniel Lyons  wrote:
>
> > On Aug 14, 2009, at 10:10 AM, Chas Emerick wrote:
>
> > > Seeing that some contrib libs have been promoted into the main clojure
> > > project, I'd like to suggest that the same be done for
> > > clojure.contrib.def (or, the majority of it).  We use it nearly
> > > everywhere, and I suspect many others do as well.
>
> > > As a slight caveat, I'm not sure that the defalias, defhinted, or  
> > > name-
> > > with-attributes members in def are central enough and/or used enough
> > > to warrant promotion.  It seems reasonable that they'd be "left
> > > behind" in c.c.def, with the other forms promoted -- either into
> > > core.clj or into a clojure.def namespace.
>
> > > Thoughts?
>
> > I myself am rather fond of defvar. I'm for it.
>
> > —
> > Daniel Lyons
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Current API doc (for HEAD)

[Tom Faulhaber]

On Aug 7, 1:43 am, Daniel  wrote:
> IIRC you can use plain HTML on the github pages. They are only
> processed by Jekyll, if you have the YAML front-matter in the file
> (http://wiki.github.com/mojombo/jekyll/usagesee index.html section).

Yup, I'm skipping the Jekyll and doing vanilla HTML + CSS so that you
can pull them for offline use. I agree completely that there is value
in offline copies.

Another benefit of that system is that you can have historical
versions available by git and it will be easy to have a doc version
that matches your contrib version even if your not at HEAD all the
time. (This will also work for other packages for which we use
autodoc.)

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Current API doc (for HEAD)

[Tom Faulhaber]

> Great! - I need to think about this, and will follow up after I get
> back from vacation.
>

Cool. No hurry, I have plenty of other stuff to clean up in autodoc
and work to do to make it non-contrib specific.

Have a great vacation!

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Current API doc (for HEAD)

[Tom Faulhaber]

> Tom, are you amenable?

Yup, happy to. Where should it go?

I'm generating real html now, not wiki-text (for a bunch of reasons,
among them the ability to download a tree and use your browser
offline, old version support, etc.), so the current system wouldn't
post back to clojure.org very efficiently. But I could throw something
onto the github pages for clojure, for instance.

Let me know how you want to proceed, or we can chat in #clojure.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: c.c Assembla wiki

[Tom Faulhaber]

Sorry, I've been meaning to post info about the "new" autodoc area on
github, but it's not totally complete yet (and summer has been keeping
my busy in other ways).

All of the API documentation is on github at 
http://richhickey.github.com/clojure-contrib/
and is generally pretty much up to the minute. However, I haven't yet
brought over the user-created wiki pages from google code (there are
three: Datalog, Common Lisp Format, and Pretty Printing). Also, some
of the links in the current wiki are broken and the formatting needs a
bunch of work.

But feel free to use it; what's there should all be right.

Tom

On Jul 31, 9:25 am, Sean Devlin  wrote:
> Okay, good to know.  I think that a link in the assembla wiki homepage
> would help future users a lot.
>
> Should I submit a ticket?  How should this be handled?
>
> Sean
>
> On Jul 31, 11:57 am, Christophe Grand  wrote:
>
> > Hi,
>
> > it's not on assembla but on 
> > github:http://richhickey.github.com/clojure-contrib/
>
> > Christophe
>
> > On Fri, Jul 31, 2009 at 5:09 PM, Sean Devlin 
> > wrote:
>
> > > The move from Google code to github has been awesome.  Rich, you & the
> > > main contributors have done a kick ass job of getting everything in
> > > order.  Thank you listening to the community, it has been a big help.
>
> > > I'd like to ask one small thing.  The Clojure Contrib wiki doesn't
> > > exist on Assembla, and the documentation on Google code is six weeks
> > > old with no sign of updating (and that's okay).  Could it be possible
> > > to start re-running the wiki script, and posting the output to
> > > Assembla?
>
> > > I know this is going to take some time, because there are changes that
> > > have to be made to the scripts in order for them to work for
> > > Assembla.  I'll look into this myself if no one has time.
>
> > > Thoughts?
>
> > --
> > 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Logging functions delegated to java logging systems

[Tom Faulhaber]

Yeah, I'd like to see something like this in clojure-contrib. One of
the problems that java systems routinely have is mismatches between
the assumed logging system. This is a real pain when it comes up and
it would be nice to have that taken care of by an abstraction layer.

Tom

On Jul 21, 10:13 pm, ataggart  wrote:
> I've written up a small set of logging functions to output from
> clojure what I'm already doing from my production java code.
>
> Currently it checks for the presence of commons-logging, log4j, and
> finally java.util.logging.  The clojure code doesn't actually do any
> logging itself; instead everything is delegated to whatever you've
> been using all along.
>
> I've stuck the code athttp://paste.lisp.org/display/83982
>
> I'd welcome any thoughts, particularly if this merits going into
> clojure-contrib.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: binding issue

[Tom Faulhaber]

Looking at the clojure docs, it doesn't appear to be defined whether
binding is a parallel (all vars are computed based on the initial
state) or sequential (vars are computed using the new values for vars
used in the same binding vector). A quick test shows that it appears
to be parallel:

(binding [a 1 b a] [a b]) => [1 nil]

Reviewing the implementation in clojure.contrib makes it seem that is
indeed true. It looks like all of the new values for the binding forms
are computed before the pairs are added to a hash that is sent to
pushThreadBindings.

Whether this is the desired behavior is another question entirely.

In any case, the fact that it is not documented seems like a bug,
especially since this behavior is different from let (as you point
out).

Tom

On Jul 11, 9:01 pm, bgray  wrote:
> Is this behavior expected from binding?
>
> user=> (def a nil)
> #'user/a
> user=> (def b nil)
> #'user/b
> user=> (binding [a 1 b (+ a 1)] a)
> java.lang.NullPointerException (NO_SOURCE_FILE:0)
> user=> (binding [a 1 b (+ a 1)] b)
> java.lang.NullPointerException (NO_SOURCE_FILE:0)
> user=> (let [a 1 b (+ a 1)] a)
> 1
> user=> (let [a 1 b (+ a 1)] b)
> 2
>
> Thanks,
> Brandon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure in Clojure?

[Tom Faulhaber]

> As awesome as this sounds, wouldn't it first require a
> native implementation to be created for each language prior to Clojure
> in Clojure running on the platform?

No, you don't need to write a native port for each platform.

Typically, you break the compiler into two broad parts: the platform
independent compiler and the code generator for each platform. (Each
of these has several parts internally.)

The idea is that most of the compiler is in the platform independent
part. This creates some sort of intermediate (but fairly low-level)
representation of your program. Then you have a smaller part for each
system that generates the exact instruction set for that system. So
you have one big compiler/library bundle and n code generators, one
for each platform. All of this is written in the source language (in
this case Clojure).

Now, the important thing is that the code generator for a target
machine X doesn't have to run *on* machine X. It can run on any
machine that supports the source language.

So say we have Clojure-in-Clojure on the JVM and we decide that we
want to run Clojure in Flash by compiling to ActionScript. What we
need to do is create an ActionScript code generator for the Clojure
compiler. Then, on the JVM, we compile all of Clojure using the
ActionScript code generator instead of the JVM code generator. The
resulting output *is* native Clojure for Flash. Typically (though not
always), you'll go ahead and recompile your compiler from Flash
generating a "pure" Flash compiler.

Thus, we never go through a "bootstrap" process on each new target
platform, we start by building a cross-compiler (which is identical to
the native compiler, but running on a platform other than the target)
and use that to get our bootstrap.

In reality, porting Clojure-in-Clojure will be more difficult than
this because of things like differences in GC between platforms. Also,
I suspect the first versions of Clojure-in-Clojure won't be quite so
nicely divided as that. But this is the basic theory.

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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---