Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Richard Möhn]

Am Donnerstag, 28. Mai 2015 07:57:37 UTC+9 schrieb Colin Fleming:
>
> […]
>
> Much of this is specific to editing environments, and more concretely 
> specific to Cursive. It's also mostly necessary because I'm working from 
> unexpanded source rather than introspecting a REPL.
>

I see. I think I won't have to work with unexpanded source. And I hope my 
tool won't have to do too many clever things. But thanks for your 
explanation anyway!

Following Alex's advice, I won't try to continue discussing everything 
about my project on this list. I will post updates that are interesting for 
the general public occasionally and otherwise bug the people with 
experience in this field directly.

Richard

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

[Colin Fleming]

At the moment, the extension system is very tied to Cursive and to IntelliJ
internals. Several people have asked whether I could extract the
functionality so it would be reusable, but since I haven't even had time to
get my own API public yet this is unlikely to happen - it's a very
significant piece of work.

The key idea is to have extensions for forms. These extensions are keyed
off the head symbol of lists, which is fully qualified. This means that I
can have separate extensions for clojure.core/defn and schema.macros/defn,
which is critical. However this relies on reliably being able to resolve
symbols, which is non-trivial in source. If you're willing to macroexpand
everything this may be easier. I also have a parsing framework which I use
to describe grammars for individual forms, which makes form parsing and
data extraction much much easier. See the Illuminated Macros talk for a
similar approach.

Things that extensions can currently do:

1. Describe var metadata for global symbols (vars)
2. Describe local bindings (what their scope is, what their type is, etc)
3. How to extract the arglists from a particular form
4. Whether the form is a threading form, and how to interpret it if so.
5. Various extensions for parsing namespace relationships (imports, refers,
aliases)
6. Whether the form declares a namespace.
7. Various things relating to testing - does this form describe a test, etc.

Things that they'll do soon:

1. Describe the type of the form, for Java interop type inference (almost
done)
2. Allow customisation of code completion at various points in forms.

Much of this is specific to editing environments, and more concretely
specific to Cursive. It's also mostly necessary because I'm working from
unexpanded source rather than introspecting a REPL.

Cheers,
Colin


On 25 May 2015 at 20:49, Richard Möhn  wrote:

>
>
> Am Freitag, 22. Mai 2015 11:09:40 UTC+9 schrieb Colin Fleming:
>>
>> On one of the latest Cognicasts, Colin Fleming talked about a repo where
>>> library authors can upload extensions that help the IDE understand their
>>> macros. I have to listen to it again, but it sounded a bit like what you're
>>> talking about. Right now I can't find that repo, though. Maybe he was just
>>> talking about plans.
>>>
>>
>> Right, sadly this is still at the plans stage, although Cursive already
>> uses this API internally. I'll let everyone know when this is public.
>>
>
> Hmm, do you think it would be realistic to have a common format? Maybe you
> could tell me how your extensions look like, so that I can take it into
> account when developing my model? However, I know that publishing things
> can be "dangerous", so I'd absolutely understand if you want to keep this
> to yourself for now.
>
> Richard
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>

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

[Richard Möhn]

Am Freitag, 22. Mai 2015 11:09:40 UTC+9 schrieb Colin Fleming:
>
> On one of the latest Cognicasts, Colin Fleming talked about a repo where 
>> library authors can upload extensions that help the IDE understand their 
>> macros. I have to listen to it again, but it sounded a bit like what you're 
>> talking about. Right now I can't find that repo, though. Maybe he was just 
>> talking about plans.
>>
>
> Right, sadly this is still at the plans stage, although Cursive already 
> uses this API internally. I'll let everyone know when this is public.
>

Hmm, do you think it would be realistic to have a common format? Maybe you 
could tell me how your extensions look like, so that I can take it into 
account when developing my model? However, I know that publishing things 
can be "dangerous", so I'd absolutely understand if you want to keep this 
to yourself for now.

Richard

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

[Colin Fleming]

>
> On one of the latest Cognicasts, Colin Fleming talked about a repo where
> library authors can upload extensions that help the IDE understand their
> macros. I have to listen to it again, but it sounded a bit like what you're
> talking about. Right now I can't find that repo, though. Maybe he was just
> talking about plans.
>

Right, sadly this is still at the plans stage, although Cursive already
uses this API internally. I'll let everyone know when this is public.

Cheers,
Colin

On 22 May 2015 at 12:42, Richard Möhn  wrote:

> Thanks for the great feedback!
>
> Am Freitag, 22. Mai 2015 05:48:38 UTC+9 schrieb Laurent PETIT:
>>
>> Sorry for jumping late inside the pool, but the topic has retained my
>> attention from day one.
>>
>> As a developer of an IDE plugin (CounterClockWise for Eclipse), I'm very
>> interested in this effort.
>> Here are my ideas/questions/remarks:
>>
>> - Finding a winning scenario for adoption is key. A perfect tool with no
>> users will be of no use
>> - Specifically, for broad adoption, one scenario I can see is that such
>> APIs are automatically delivered by library authors without changing any of
>> their habit. E.G. the result would be automatically downloaded to either
>> clojars or maven central as just an additional jar with a specific
>> classifier.
>> - To be even more specific, I think that this means that from start you
>> should plan to provide leiningen plugin, at the very least. And probably
>> maven (clojure-maven-plugin) and boot plugins as well. Go reach the users
>> where they are.
>>
>
> I didn't think of giving the plugins high priority, but I guess you're
> right! Thanks for pointing out their importance again.
>
>
>> - Of course, from the point of view of an IDE, which already has the
>> tooling to get jars from maven repositories, it would not be difficult then
>> to get information from libraries, that could be used to help Users anytime
>> about the libraries they've chosen. No need to get a REPL open and get all
>> the project namespaces loaded. No need to reinvent another way to
>> statically parse all the project dependencies to get static analysis (at
>> least for the project dependencies).
>> - This would also enable providers of not open-source projects to deliver
>> the API - and not the source code -, and for this kind of scenario only
>> your solution will be of help.
>>
>> If I remember well, when talking about this with Tom Faulhaber, the
>> author of Autodoc, several years ago (yeah, hammock time can sometimes be
>> very long ;-) ), he told me that everything was already there, in
>> Autodoc, after it had produced the HTML pages. But maybe not published in
>> the final "HTML" product. But definitely there, maybe even not just in
>> memory, but as an intermediary set of files to be transformed, on the
>> filesystem.
>>
>
> Do you mean the fourth item of "what Autodoc will generate" in
> https://tomfaulhaber.github.io/autodoc/? It could be a starting point,
> but I think we will have to go further.
>
> Last point for today: I don't know how easy it could be done, but if the
>> tool could give most possible accurate guidance about which arguments of a
>> macro should be considered as symbols that will name locals inside the
>> macro body, that would be very cool ! Currently Cursive probably has a list
>> of macros for clojure core, and for most used clojure projects, with a way
>> to declare which argument will be a symbol usable as a local, etc.
>> Sooner or later, I'll have to do that for CCW also.
>> Unless a standard comes out from your project first, which would be great
>> :-)
>>
>
> I'm not entirely sure how you mean this, but I'll take some more time for
> digesting your feedback anyway. On one of the latest Cognicasts, Colin
> Fleming talked about a repo where library authors can upload extensions
> that help the IDE understand their macros. I have to listen to it again,
> but it sounded a bit like what you're talking about. Right now I can't find
> that repo, though. Maybe he was just talking about plans.
>
> Richard
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>

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

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Richard Möhn]

Thanks for the great feedback!

Am Freitag, 22. Mai 2015 05:48:38 UTC+9 schrieb Laurent PETIT:
>
> Sorry for jumping late inside the pool, but the topic has retained my 
> attention from day one.
>
> As a developer of an IDE plugin (CounterClockWise for Eclipse), I'm very 
> interested in this effort.
> Here are my ideas/questions/remarks:
>
> - Finding a winning scenario for adoption is key. A perfect tool with no 
> users will be of no use
> - Specifically, for broad adoption, one scenario I can see is that such 
> APIs are automatically delivered by library authors without changing any of 
> their habit. E.G. the result would be automatically downloaded to either 
> clojars or maven central as just an additional jar with a specific 
> classifier.
> - To be even more specific, I think that this means that from start you 
> should plan to provide leiningen plugin, at the very least. And probably 
> maven (clojure-maven-plugin) and boot plugins as well. Go reach the users 
> where they are.
>

I didn't think of giving the plugins high priority, but I guess you're 
right! Thanks for pointing out their importance again.
 

> - Of course, from the point of view of an IDE, which already has the 
> tooling to get jars from maven repositories, it would not be difficult then 
> to get information from libraries, that could be used to help Users anytime 
> about the libraries they've chosen. No need to get a REPL open and get all 
> the project namespaces loaded. No need to reinvent another way to 
> statically parse all the project dependencies to get static analysis (at 
> least for the project dependencies).
> - This would also enable providers of not open-source projects to deliver 
> the API - and not the source code -, and for this kind of scenario only 
> your solution will be of help.
>
> If I remember well, when talking about this with Tom Faulhaber, the author 
> of Autodoc, several years ago (yeah, hammock time can sometimes be very 
> long ;-) ), he told me that everything was already there, in Autodoc, after 
> it had produced the HTML pages. But maybe not published in the final "HTML" 
> product. But definitely there, maybe even not just in memory, but as an 
> intermediary set of files to be transformed, on the filesystem.
>

Do you mean the fourth item of "what Autodoc will generate" in 
https://tomfaulhaber.github.io/autodoc/? It could be a starting point, but 
I think we will have to go further.

Last point for today: I don't know how easy it could be done, but if the 
> tool could give most possible accurate guidance about which arguments of a 
> macro should be considered as symbols that will name locals inside the 
> macro body, that would be very cool ! Currently Cursive probably has a list 
> of macros for clojure core, and for most used clojure projects, with a way 
> to declare which argument will be a symbol usable as a local, etc.
> Sooner or later, I'll have to do that for CCW also.
> Unless a standard comes out from your project first, which would be great 
> :-)
>

I'm not entirely sure how you mean this, but I'll take some more time for 
digesting your feedback anyway. On one of the latest Cognicasts, Colin 
Fleming talked about a repo where library authors can upload extensions 
that help the IDE understand their macros. I have to listen to it again, 
but it sounded a bit like what you're talking about. Right now I can't find 
that repo, though. Maybe he was just talking about plans.

Richard

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

[Laurent PETIT]

Sorry for jumping late inside the pool, but the topic has retained my
attention from day one.

As a developer of an IDE plugin (CounterClockWise for Eclipse), I'm very
interested in this effort.
Here are my ideas/questions/remarks:

- Finding a winning scenario for adoption is key. A perfect tool with no
users will be of no use
- Specifically, for broad adoption, one scenario I can see is that such
APIs are automatically delivered by library authors without changing any of
their habit. E.G. the result would be automatically downloaded to either
clojars or maven central as just an additional jar with a specific
classifier.
- To be even more specific, I think that this means that from start you
should plan to provide leiningen plugin, at the very least. And probably
maven (clojure-maven-plugin) and boot plugins as well. Go reach the users
where they are.
- Of course, from the point of view of an IDE, which already has the
tooling to get jars from maven repositories, it would not be difficult then
to get information from libraries, that could be used to help Users anytime
about the libraries they've chosen. No need to get a REPL open and get all
the project namespaces loaded. No need to reinvent another way to
statically parse all the project dependencies to get static analysis (at
least for the project dependencies).
- This would also enable providers of not open-source projects to deliver
the API - and not the source code -, and for this kind of scenario only
your solution will be of help.

If I remember well, when talking about this with Tom Faulhaber, the author
of Autodoc, several years ago (yeah, hammock time can sometimes be very
long ;-) ), he told me that everything was already there, in Autodoc, after
it had produced the HTML pages. But maybe not published in the final "HTML"
product. But definitely there, maybe even not just in memory, but as an
intermediary set of files to be transformed, on the filesystem.

Last point for today: I don't know how easy it could be done, but if the
tool could give most possible accurate guidance about which arguments of a
macro should be considered as symbols that will name locals inside the
macro body, that would be very cool ! Currently Cursive probably has a list
of macros for clojure core, and for most used clojure projects, with a way
to declare which argument will be a symbol usable as a local, etc.
Sooner or later, I'll have to do that for CCW also.
Unless a standard comes out from your project first, which would be great
:-)

HTH,

Laurent








2015-05-20 2:34 GMT+02:00 Richard Möhn :

> Just trying to bump this up a bit. "Coding" will start soon, so I'd be
> happy about some more input. Especially if you have further thoughts or
> wishes along the lines of
> https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>



-- 
Laurent Petit

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

[Alex Miller]

It is a non-goal to define any new "standard" metadata for vars as part of 
the project. But it does seem reasonable that retaining var metadata and 
making it available would be useful to enable tooling for examples or 
anything else.

On Thursday, May 21, 2015 at 1:15:17 PM UTC-5, Russell Mull wrote:
>
> There are some potential applications for literate programming here. For 
> example, when doing an 'untangle' from your literate program source (to 
> extract the code), the typical way to allow changes to be merged back in is 
> to add comments with line number information. A more structured place to 
> put that data would be nicer. (although it would have to be a 
> clojure-focused LP tool for this to work) I'm not really in love with this 
> idea, as it doesn't feel very lisp-y. 
>
> Reversing the relationship, it could be nice to offer some standard 
> LP-related metadata about top-level forms to indicate how they should be 
> presented. For example:
>  - should the docstring be extracted and presented as top-level text?
>  - should this form be called out as important, or perhaps hidden entirely?
>  - some example invocations and their results, in a structured way. Then 
> we could (a) present the examples and results in the appropriate place, 
> depending on the context, or (b) automatically recompute those results (or 
> test against them) with a bit of tooling. 
>
> Of these, only the example usages case feels like it would be useful 
> outside LP, and thus be a candidate for common metadata. 
>
> - Russell
>

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

[Russell Mull]

There are some potential applications for literate programming here. For 
example, when doing an 'untangle' from your literate program source (to 
extract the code), the typical way to allow changes to be merged back in is 
to add comments with line number information. A more structured place to 
put that data would be nicer. (although it would have to be a 
clojure-focused LP tool for this to work) I'm not really in love with this 
idea, as it doesn't feel very lisp-y. 

Reversing the relationship, it could be nice to offer some standard 
LP-related metadata about top-level forms to indicate how they should be 
presented. For example:
 - should the docstring be extracted and presented as top-level text?
 - should this form be called out as important, or perhaps hidden entirely?
 - some example invocations and their results, in a structured way. Then we 
could (a) present the examples and results in the appropriate place, 
depending on the context, or (b) automatically recompute those results (or 
test against them) with a bit of tooling. 

Of these, only the example usages case feels like it would be useful 
outside LP, and thus be a candidate for common metadata. 

- Russell

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

[Richard Möhn]

Just trying to bump this up a bit. "Coding" will start soon, so I'd be 
happy about some more input. Especially if you have further thoughts or 
wishes along the lines of 
https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion.

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

[Alex Miller]

On Wednesday, May 6, 2015 at 3:30:57 PM UTC-5, Fluid Dynamics wrote:
>
> On Wednesday, May 6, 2015 at 4:09:54 PM UTC-4, Alex Miller wrote:
>>
>> Yes, I think that's largely correct. The goal of Richard's project is to 
>> create an information model (data) describing a project from the 
>> perspective of use. Codeq goes much deeper by integrating code history - 
>> that allows you to ask very interesting and useful questions, however I 
>> believe they are different than questions like: what records exist in this 
>> particular version of a library I'm using? 
>>
>
> What protocols exist may be an even more interesting question. A protocol 
> exposed to consumers of a library is likely to be a particularly useful 
> (deliberately so) extension point. 
>

Yes, exactly. 

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

[Fluid Dynamics]

On Wednesday, May 6, 2015 at 4:09:54 PM UTC-4, Alex Miller wrote:
>
> Yes, I think that's largely correct. The goal of Richard's project is to 
> create an information model (data) describing a project from the 
> perspective of use. Codeq goes much deeper by integrating code history - 
> that allows you to ask very interesting and useful questions, however I 
> believe they are different than questions like: what records exist in this 
> particular version of a library I'm using? 
>

What protocols exist may be an even more interesting question. A protocol 
exposed to consumers of a library is likely to be a particularly useful 
(deliberately so) extension point. 

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

[Alex Miller]

On Wednesday, May 6, 2015 at 6:17:37 AM UTC-5, Phillip Lord wrote:
>
> > writes: 
> > The goal of this project is to develop a comprehensive and extensible 
> > model for describing Clojure sources from an API perspective. I will 
> > also write a program that analyses Clojure sources according to this 
> > model and outputs data documenting their usage. This could be compared 
> > to Javadoc, but emitting data to be consumed by other tools instead of 
> > HTML. In order to foster adoption, I will provide extensive 
> > documentation, including examples of such consumer tools, and 
> > emphasize active communication with the community. ☙ 
>
> I would like to see a mechanism for structure in the clojure doc 
> strings. So, consider the second definition in core.clj. 
>

Defining any structure inside the docstring is out of scope for this 
project. That information will be put into the model by producers and can 
be used by any consumer (who might understand some such format), but I 
think defining that specific structure is not what we're talking about. 

However, arbitrary metadata (expressed as data) attached to vars etc is 
likely to be of interest, both known metadata tags and understanding how to 
be open to extensions.

Alex

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

[Alex Miller]

On Tuesday, May 5, 2015 at 7:37:47 PM UTC-5, richar...@posteo.de wrote:
>
>
>
> Am Mittwoch, 6. Mai 2015 07:17:54 UTC+9 schrieb kovasb:
>>
>> I'm mostly interested in something like 
>> http://docs.racket-lang.org/scribble/ 
>>
>
> Thanks for the idea! There is http://clojure-scribble.publicfields.net/, 
> which you might know already. Maybe something like that could also be 
> integrated with the output of my project.
>
> But let me clarify again, because maybe this hasn't come across clearly 
> enough: my project is not about creating another tool for generating 
> documentation pages. Rather, I want to think about what aspects of Clojure 
> code describe how to use a namespace. That's vars, records etc. along with 
> their doc strings, argument lists etc. and positional information. I have 
> to think how these can be captured and then output as data in various ways. 
> That could be storing in Datomic, deploying to Clojars and so on. Other 
> tools can then use these data for their purposes like building 
> documentation pages or recording the evolution of the API like Codeq.
>
> @Alex Miller: If I'm mangling your ideas, please correct me!
>
> Richard
>

Nope, exactly so. I think something Scribble-like could sit on top of this 
and benefit from the data, but that's separate.

Alex

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

[Alex Miller]

On Monday, May 4, 2015 at 6:27:47 PM UTC-5, richar...@posteo.de wrote:
>
>
>
> Am Dienstag, 5. Mai 2015 01:56:13 UTC+9 schrieb Sean Grove:
>>
>> I've been hoping someone would rebuild Codeq 
>> , now that tools.analyzer (and 
>> friends) is out and ClojureScript has made so much progress. Not only would 
>> it be useful for diving into a new codebase (I've needed it several times 
>> when working with a large, unfamiliar codebase), but generating both useful 
>> and interesting docs from the structured data should be far easier than 
>> ad-hoc analysis.
>>
>> Just a thought, not sure that's the angle you want to take, but didn't 
>> see it on your list and each of the items on the list would probably have 
>> benefited from a revamped, well-documented, well-marketed Codeq.
>>
>
> Oh, Codeq! I heard about it a long time ago on the Cognicast and it has 
> been hopping across my mind now and then. I would also like it to come to 
> life again. While it's not quite in the scope of my project, I think it 
> could be one of the tools that can be (re)built on top of the metadata from 
> my project. Maybe I'm remembering Codeq wrong, but I think it could "just" 
> be recording the changes/snapshots of metadata according to my model over 
> time by feeding them into Datomic.
>

Yes, I think that's largely correct. The goal of Richard's project is to 
create an information model (data) describing a project from the 
perspective of use. Codeq goes much deeper by integrating code history - 
that allows you to ask very interesting and useful questions, however I 
believe they are different than questions like: what records exist in this 
particular version of a library I'm using? 

That said, I think a subset of the Codeq data model is in the ballpark of 
the model we want to capture. The degree of overlap remains to be seen.

Alex

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

[Phillip Lord]

Indeed. I think Emacs docstrings are a bottom line -- Clojure should be
able to make these distinctions at least. And this would in turn allow
tools to use them. Why can I not click on function names in a docstring
and go to the function definition?

Phil

Bozhidar Batsov  writes:

> I think the real problem is the lack of conventions for adding metadata to
> docstrings. I sorely miss `some-func/var' and SOME-PARAM from Emacs Lisp.
> It's always
> clear where you refer to other functions/variables and to parameters. This
> makes it way easier to read (and parse) a docstring.
>
> On 6 May 2015 at 14:17, Phillip Lord  wrote:
>
>>  writes:
>> > The goal of this project is to develop a comprehensive and extensible
>> > model for describing Clojure sources from an API perspective. I will
>> > also write a program that analyses Clojure sources according to this
>> > model and outputs data documenting their usage. This could be compared
>> > to Javadoc, but emitting data to be consumed by other tools instead of
>> > HTML. In order to foster adoption, I will provide extensive
>> > documentation, including examples of such consumer tools, and
>> > emphasize active communication with the community. 
>>
>> I would like to see a mechanism for structure in the clojure doc
>> strings. So, consider the second definition in core.clj.
>>
>>
>> (def
>>  ^{:arglists '([x seq])
>> :doc "Returns a new seq where x is the first element and seq is
>> the rest."
>>:added "1.0"
>>:static true}
>>
>>  cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq
>>
>> Analysing this further:
>>
>> Returns a new seq where x is the first element and seq is the rest.
>>
>> We have two uses of 'seq', where one refers to the general concept (or
>> to the interface ISeq), and the other refers to the parameter defined in
>> :arglists. We have 'x' which refers to an :arglists parameter also. And
>> we have 'first', 'rest' and 'seq' none of which refer to the function
>> names in the same namespace as cons. Although they might do if the doc
>> string were reworded:
>>
>> Returns a new ISeq, s, where (first s) returns x and (rest s)
>> returns seq.
>>
>>
>> Not sure whether this is in scope or not, but it is about usage of
>> metadata.
>>
>> 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
>> ---
>> 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.
>>

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

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

[Bozhidar Batsov]

I think the real problem is the lack of conventions for adding metadata to
docstrings. I sorely miss `some-func/var' and SOME-PARAM from Emacs Lisp.
It's always
clear where you refer to other functions/variables and to parameters. This
makes it way easier to read (and parse) a docstring.

On 6 May 2015 at 14:17, Phillip Lord  wrote:

>  writes:
> > The goal of this project is to develop a comprehensive and extensible
> > model for describing Clojure sources from an API perspective. I will
> > also write a program that analyses Clojure sources according to this
> > model and outputs data documenting their usage. This could be compared
> > to Javadoc, but emitting data to be consumed by other tools instead of
> > HTML. In order to foster adoption, I will provide extensive
> > documentation, including examples of such consumer tools, and
> > emphasize active communication with the community. ☙
>
> I would like to see a mechanism for structure in the clojure doc
> strings. So, consider the second definition in core.clj.
>
>
> (def
>  ^{:arglists '([x seq])
> :doc "Returns a new seq where x is the first element and seq is
> the rest."
>:added "1.0"
>:static true}
>
>  cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq
>
> Analysing this further:
>
> Returns a new seq where x is the first element and seq is the rest.
>
> We have two uses of 'seq', where one refers to the general concept (or
> to the interface ISeq), and the other refers to the parameter defined in
> :arglists. We have 'x' which refers to an :arglists parameter also. And
> we have 'first', 'rest' and 'seq' none of which refer to the function
> names in the same namespace as cons. Although they might do if the doc
> string were reworded:
>
> Returns a new ISeq, s, where (first s) returns x and (rest s)
> returns seq.
>
>
> Not sure whether this is in scope or not, but it is about usage of
> metadata.
>
> 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
> ---
> 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.
>

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

[Phillip Lord]

 writes:
> The goal of this project is to develop a comprehensive and extensible
> model for describing Clojure sources from an API perspective. I will
> also write a program that analyses Clojure sources according to this
> model and outputs data documenting their usage. This could be compared
> to Javadoc, but emitting data to be consumed by other tools instead of
> HTML. In order to foster adoption, I will provide extensive
> documentation, including examples of such consumer tools, and
> emphasize active communication with the community. ☙

I would like to see a mechanism for structure in the clojure doc
strings. So, consider the second definition in core.clj.


(def
 ^{:arglists '([x seq])
:doc "Returns a new seq where x is the first element and seq is
the rest."
   :added "1.0"
   :static true}

 cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq

Analysing this further:

Returns a new seq where x is the first element and seq is the rest.

We have two uses of 'seq', where one refers to the general concept (or
to the interface ISeq), and the other refers to the parameter defined in
:arglists. We have 'x' which refers to an :arglists parameter also. And
we have 'first', 'rest' and 'seq' none of which refer to the function
names in the same namespace as cons. Although they might do if the doc
string were reworded:

Returns a new ISeq, s, where (first s) returns x and (rest s)
returns seq.


Not sure whether this is in scope or not, but it is about usage of
metadata.

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
--- 
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: [ANN, GSoC] A Common Clojure Source Metadata Model

[richard . moehn]

Am Mittwoch, 6. Mai 2015 07:17:54 UTC+9 schrieb kovasb:
>
> I'm mostly interested in something like 
> http://docs.racket-lang.org/scribble/ 
>

Thanks for the idea! There is http://clojure-scribble.publicfields.net/, 
which you might know already. Maybe something like that could also be 
integrated with the output of my project.

But let me clarify again, because maybe this hasn't come across clearly 
enough: my project is not about creating another tool for generating 
documentation pages. Rather, I want to think about what aspects of Clojure 
code describe how to use a namespace. That's vars, records etc. along with 
their doc strings, argument lists etc. and positional information. I have 
to think how these can be captured and then output as data in various ways. 
That could be storing in Datomic, deploying to Clojars and so on. Other 
tools can then use these data for their purposes like building 
documentation pages or recording the evolution of the API like Codeq.

@Alex Miller: If I'm mangling your ideas, please correct me!

Richard

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

[kovas boguta]

I'm mostly interested in something like
http://docs.racket-lang.org/scribble/



On Mon, May 4, 2015 at 7:27 PM,  wrote:

>
>
> Am Dienstag, 5. Mai 2015 01:56:13 UTC+9 schrieb Sean Grove:
>>
>> I've been hoping someone would rebuild Codeq
>> , now that tools.analyzer (and
>> friends) is out and ClojureScript has made so much progress. Not only would
>> it be useful for diving into a new codebase (I've needed it several times
>> when working with a large, unfamiliar codebase), but generating both useful
>> and interesting docs from the structured data should be far easier than
>> ad-hoc analysis.
>>
>> Just a thought, not sure that's the angle you want to take, but didn't
>> see it on your list and each of the items on the list would probably have
>> benefited from a revamped, well-documented, well-marketed Codeq.
>>
>
> Oh, Codeq! I heard about it a long time ago on the Cognicast and it has
> been hopping across my mind now and then. I would also like it to come to
> life again. While it's not quite in the scope of my project, I think it
> could be one of the tools that can be (re)built on top of the metadata from
> my project. Maybe I'm remembering Codeq wrong, but I think it could "just"
> be recording the changes/snapshots of metadata according to my model over
> time by feeding them into Datomic.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>

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

[richard . moehn]

Am Dienstag, 5. Mai 2015 01:56:13 UTC+9 schrieb Sean Grove:
>
> I've been hoping someone would rebuild Codeq 
> , now that tools.analyzer (and friends) 
> is out and ClojureScript has made so much progress. Not only would it be 
> useful for diving into a new codebase (I've needed it several times when 
> working with a large, unfamiliar codebase), but generating both useful and 
> interesting docs from the structured data should be far easier than ad-hoc 
> analysis.
>
> Just a thought, not sure that's the angle you want to take, but didn't see 
> it on your list and each of the items on the list would probably have 
> benefited from a revamped, well-documented, well-marketed Codeq.
>

Oh, Codeq! I heard about it a long time ago on the Cognicast and it has 
been hopping across my mind now and then. I would also like it to come to 
life again. While it's not quite in the scope of my project, I think it 
could be one of the tools that can be (re)built on top of the metadata from 
my project. Maybe I'm remembering Codeq wrong, but I think it could "just" 
be recording the changes/snapshots of metadata according to my model over 
time by feeding them into Datomic.

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

[Sean Grove]

I've been hoping someone would rebuild Codeq
, now that tools.analyzer (and friends)
is out and ClojureScript has made so much progress. Not only would it be
useful for diving into a new codebase (I've needed it several times when
working with a large, unfamiliar codebase), but generating both useful and
interesting docs from the structured data should be far easier than ad-hoc
analysis.

Just a thought, not sure that's the angle you want to take, but didn't see
it on your list and each of the items on the list would probably have
benefited from a revamped, well-documented, well-marketed Codeq.

On Mon, May 4, 2015 at 12:30 AM,  wrote:

> Hi all!
>
> I'm one of this year's students accepted to the Google Summer of Code for
> doing
> a Clojure project. (Thanks to Alex Miller for supporting my application!)
> For
> those who like to decide from the first paragraph whether they will read
> on or
> not: the goal of my project is to develop a model for Clojure source
> metadata
> (most of them are documentation) and ways to capture and publish them. The
> following two paragraphs are taken from my project proposal:
>
>  ❧ To the joy of the community, the number of Clojure-based libraries is
> steadily growing. To the dismay of the community, there is no agreed-upon
> way of
> getting information about those libraries' APIs. We have API documentation
> generators for individual libraries, like Autodoc or Codox. And we have big
> overview sites like Grimoire and CrossClj. None of them are comprehensive.
> All
> provide their information in a human-friendly way. Only some cater for the
> computer.
>
> The goal of this project is to develop a comprehensive and extensible
> model for
> describing Clojure sources from an API perspective. I will also write a
> program
> that analyses Clojure sources according to this model and outputs data
> documenting their usage. This could be compared to Javadoc, but emitting
> data to
> be consumed by other tools instead of HTML. In order to foster adoption, I
> will
> provide extensive  documentation, including examples of such consumer
> tools, and
> emphasize active communication with the community. ☙
>
> The project idea comes from Alex Miller, who also is my mentor, together
> with
> Reid McKenzie. Coding for the GSoC hasn't started yet. – Until 24 April
> we're in
> the warmup phase called community bonding. I wanted to use this time for
> getting
> ideas and feedback from you, so I've prepared some questions as a starting
> point:
>
>  - Who is interested in the project?
> - What would you like to see?
>  - Who has done/thought about similar things?
> - What have you done?
> - How have you done it?
> - What have you found? – Difficulties, annoyances, surprises.
> - What would you like to see?
> - What is important to you?
> - Have you built something that I might reuse?
>  - What else comes to your mind?
>
> There are many things out there which are more or less closely related to
> my
> project:
>
>  - cljs.info: https://github.com/cljsinfo
>  - Autodoc: https://github.com/tomfaulhaber/autodoc
>  - Codox: https://github.com/weavejester/codox
>  - Grimoire: http://conj.io/
>  - CrossClj: https://crossclj.info/
>  - ClojureDocs: https://clojuredocs.org/
>  - Clojure Atlas: http://www.clojureatlas.com/
>
> I would be especially happy to receive input from the people involved in
> those
> efforts.
>
> Reading this might help not having to say things again that have been said
> before: https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion
>
> I wish everyone a good summer!
>
> Richard
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
>

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

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[richard . moehn]

I just saw that the plain text formatting is horrible. Sorry for that.

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