Future of clojure.contrib.core/-?> macro
Laurent PETIT
The -?> and -?>> macros are currently inside "old", "soon to be
deprecated" clojure contrib.
They have proven useful to me a number of times, and I personnally
wouldn't see them stay in the soon "deprecated" , "not maintained
anymore" old clojure contrib repo/jar. (Not to say that I would not
want to have to add the whole old clojure contrib jar to my project
just for these macros).
So the question is: do a sufficiently important number of other people
use and want them as well ? If so, I may ask to the clojure-dev ml if
and how and/or where we could move this macro so that it is still
visible and `usable`.
But if nobody uses it (or few people), then I could understand, and
then I'd revert to use my own copy of this macro in my projects (ick).
"Users of the Null Safe Threading Operators, speak today, or suffer
tomorrow !" ;-)
Cheers,
--
Laurent Petit
James Reeves
> So the question is: do a sufficiently important number of other people
> use and want them as well ? If so, I may ask to the clojure-dev ml if
> and how and/or where we could move this macro so that it is still
> visible and `usable`.
I use it, and I think more people would use it if this were in core.
- James
Zach Tellman
Wilson MacGyver
> --
> 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
--
Omnem crede diem tibi diluxisse supremum.
Sean Corfield
> I use it, and I think more people would use it if this were in core.
I only discovered them recently - they would certainly be more
discoverable in core and that would lead to greater use (so the
question then will be whether Clojure/core consider them idiomatic or
whether they think handling nil should be done a different way).
--
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)
Konrad Hinsen
> The -?> and -?>> macros are currently inside "old", "soon to be
> deprecated" clojure contrib.
I must confess that I don't even know what those macros do, so I have
no opinion.
However, I think the question of "what will happen to module
clojure.contrib.XXX" is of wider interest. Only very few modules/
sublibraries have made it into the "new contrib". OK, many of the old
ones (including some of mine) are experiments and probably not used by
anyone any more. But there's a lot in between: useful and used code
that for whatever reason does not satisfy the stricter criteria
(whatever they are) of "new contrib".
Concerning my own modules in old contrib, there are three that I use
myself and that I am planning to maintain, independently of where they
will end up:
- clojure.contrib.monads
- clojure.contrib.macro-utils
- clojure.contrib.generic
If nothing else is decided collectively, I'll maintain them as private
projects on Google Codes or Bitbucket.
Konrad.
Paul deGrandis
I'd support their addition into core.
Also, regarding Konrad's comment:
I also find a lot of random one-off things in old contrib that I think
are useful to use as well as to read through some of the source. I
think something like a solid Monad library deserves a place in
contrib, and other smaller packages should be combed for useful
nuggets and rolled into comprehensive, cohesive libraries.
Paul
László Török
+1 for Konrad's Monad library
sent from my mobile device
Rich Hickey
The only criterion for migrating into new contrib is someone willing
to do the work of moving, and, subsequently, maintaining.
This processes is emphatically not about deprecating the contrib libs,
nor pushing anything out. We had to work out the kinks in the new
build/deploy method, and that was done first for:
Some brand new libs (e.g. unify, nrepl and finger trees)
Some of the most common others, as need arose and time permitted for
the core team.
We *are* deprecating the old build process and packaging, but I would
hope anyone with any interest in any of the other contrib libs would
please step up and move them over. The only ones that will be left
behind will be those that die of neglect or disinterest.
Stuart Sierra has documented the process here:
http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects
and I'm sure will be willing to help out anyone with the desire to
move a lib.
What you should not do is wait for someone else to move your favorite
lib. We've moved the ones we have time to do, and expect the community
to do the rest, with our help.
Special thanks to Stuart Sierra and Chas Emerick, who did a ton of
work to set this up.
I hope that clarifies things,
Rich
Sean Corfield
>> If nothing else is decided collectively, I'll maintain them as private
>> projects on Google Codes or Bitbucket.
If they don't end up as part of the new lineup of contrib libraries,
would you at least keep them on github.com?
On Mon, Apr 18, 2011 at 5:15 PM, Rich Hickey <richh...@gmail.com> wrote:
> The only criterion for migrating into new contrib is someone willing to do
> the work of moving, and, subsequently, maintaining.
Rich, could you comment on the process for picking new names for the
libraries? I got the impression that Clojure/core were trying to do a
bit of cleanup there by introducing a better namespace structure for
the libraries that survive 1.3.0? (which is definitely a good step
forward)
> Some of the most common others, as need arose and time permitted for the
> core team.
For example, clojure.contrib.sql will survive as clojure.java.jdbc.
> http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects
That process requires actions by members of the Clojure organization -
https://github.com/clojure - and the folks who manage the Hudson build
server - http://build.clojure.org/people/ - so you do need to get
those people engaged in helping you move your contrib libraries into
the new world.
I forked clojure.java.jdbc to get a first cut build in place once that
new contrib library was approved. Part of the work is setting up the
maven stuff correctly and then cleaning up any dependencies on old
contrib libraries. I'm already using clojure.java.jdbc 0.0.1-SNAPSHOT
in my own code while I am waiting to engage with Stephen Gilardi and
the other folks to get the code back into the Clojure repo and onto
Hudson.
I'd definitely like to see the monads library move forward (and I
think -?> and -?>> should be considered for core, alongside -> and
->>). I'm not (yet) familiar enough with a lot of the other contrib
libraries to have an opinion (c.c.sql was the only one I was relying
on - but since we just started integrating Clojure into our production
code base, I may well start to depend on others :)
Paul deGrandis
Thanks for the feedback and righting some things for me. Can you
speak to the -?> and -?>> macros, specifically if you think nil should
be handled differently, or if these macros code find a new home in
core?
That said, I'd happily pitch in and help maintain a handful of the
contrib libs for the community.
I'll take it upon myself to get my CA in, acquire any accounts I need,
and work with Stuart Sierra to get all the support and setup I need.
So community, aside from monads, what contrib libs are top picks?
Paul
On Apr 18, 6:02 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> > On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
> >> If nothing else is decided collectively, I'll maintain them as private
> >> projects on Google Codes or Bitbucket.
>
> If they don't end up as part of the new lineup of contrib libraries,
> would you at least keep them on github.com?
>
> > The only criterion for migrating into new contrib is someone willing to do
> > the work of moving, and, subsequently, maintaining.
>
> Rich, could you comment on the process for picking new names for the
> libraries? I got the impression that Clojure/core were trying to do a
> bit of cleanup there by introducing a better namespace structure for
> the libraries that survive 1.3.0? (which is definitely a good step
> forward)
>
> > Some of the most common others, as need arose and time permitted for the
> > core team.
>
> For example, clojure.contrib.sql will survive as clojure.java.jdbc.
>
> >http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects
>
> server -http://build.clojure.org/people/- so you do need to get
> the new world.
>
> I forked clojure.java.jdbc to get a first cut build in place once that
> new contrib library was approved. Part of the work is setting up the
> maven stuff correctly and then cleaning up any dependencies on old
> contrib libraries. I'm already using clojure.java.jdbc 0.0.1-SNAPSHOT
> in my own code while I am waiting to engage with Stephen Gilardi and
> the other folks to get the code back into the Clojure repo and onto
> Hudson.
>
> I'd definitely like to see the monads library move forward (and I
> think -?> and -?>> should be considered for core, alongside -> and
> ->>). I'm not (yet) familiar enough with a lot of the other contrib
> libraries to have an opinion (c.c.sql was the only one I was relying
> on - but since we just started integrating Clojure into our production
> code base, I may well start to depend on others :)
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
Laurent PETIT
>
> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
>
>> On 18 Apr 2011, at 17:47, Laurent PETIT wrote:
>>
>>> The -?> and -?>> macros are currently inside "old", "soon to be
>>> deprecated" clojure contrib.
>>
>> I must confess that I don't even know what those macros do, so I have no
>> opinion.
>>
>> However, I think the question of "what will happen to module
>> clojure.contrib.XXX" is of wider interest. Only very few
Hello Rich, thanks for the clarification.
For sure, my email was a first step towards this direction : find in
the general ml whether there is enough interest in he -?> and -?>>
macros, before suggesting their migration either to clojure itself, or
to a new clojure contrib.
It seems to me that they've gotten the minimal community support, so
now I'm officially volunteer to help get them out of
clojure.contrib.core and into .... ?
>
> Special thanks to Stuart Sierra and Chas Emerick, who did a ton of work to
> set this up.
>
> I hope that clarifies things,
>
> Rich
>
Konrad Hinsen
>> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote:
>>> If nothing else is decided collectively, I'll maintain them as
>>> private
>>> projects on Google Codes or Bitbucket.
>
> If they don't end up as part of the new lineup of contrib libraries,
> would you at least keep them on github.com?
I'll try to see if I can manage to migrate to new contrib (I am not
exactly looking forward to all those new tools to learn), but
otherwise, I use Mercurial rather than git all day, so github is never
my first choice.
Konrad.
Konrad Hinsen
> The only criterion for migrating into new contrib is someone willing
> to do the work of moving, and, subsequently, maintaining.
OK, thanks for the clarification!
> Stuart Sierra has documented the process here:
>
> http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects
That looks like a good start, but I suspect that this requires
accounts with suitable access rights on both github and Hudson.
> What you should not do is wait for someone else to move your
> favorite lib. We've moved the ones we have time to do, and expect
> the community to do the rest, with our help.
That's of course very reasonable.
Konrad.
Sean Corfield
<konrad...@fastmail.net> wrote:
> I'll try to see if I can manage to migrate to new contrib (I am not exactly
> looking forward to all those new tools to learn)
I hadn't needed to deal with maven until I tried to set up
clojure.java.jdbc - but that was the only piece I was new to. I'd be
happy to help you with the monads library if it moves forward.
Michael Wood
There is a git plugin for Mercurial (that I've only used to migrate an
old Mercurial repository to git). It is supposed to allow hg to talk
to a remote git repository as if it were Mercurial and it seems to
work well.
The only possible issue is that it puts a bit of metadata in some of
the log messages, but maybe that's not an issue and maybe it's
possible to turn it off if it is an issue.
--
Michael Wood <esio...@gmail.com>
Stuart Halloway
> - clojure.contrib.monads
> - clojure.contrib.macro-utils
> - clojure.contrib.generic
There is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro
I have put some suggested names for the other new projects at http://dev.clojure.org/display/design/Contrib+Library+Names. Please review and comment, either there or here on the list.
Stu
Clojure/core
http://clojure.com
Laurent PETIT
>> Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up:
>> - clojure.contrib.monads
>> - clojure.contrib.macro-utils
>> - clojure.contrib.generic
>
> There is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro
OK. Note that I don't like very much this name, tools.macro. Too
generic. tools.core could be better : would reflect functions that may
go into clojure.core, or that are to be considered at the same level
for contrib project as is clojure.core for clojure project.
Or something even more "specialized" in the name, if this makes sense,
like tools.composition, or tools.nilsafe for all nilsafe variants of
operators, etc.
>
> I have put some suggested names for the other new projects at http://dev.clojure.org/display/design/Contrib+Library+Names. Please review and comment, either there or here on the list.
>
> Stu
> Clojure/core
> http://clojure.com
>
>
>
Stuart Halloway
2011/4/19 Stuart Halloway <stuart....@gmail.com>:Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up:- clojure.contrib.monads- clojure.contrib.macro-utils- clojure.contrib.genericThere is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro
OK. Note that I don't like very much this name, tools.macro. Too
generic. tools.core could be better : would reflect functions that may
go into clojure.core, or that are to be considered at the same level
for contrib project as is clojure.core for clojure project.
Or something even more "specialized" in the name, if this makes sense,
like tools.composition, or tools.nilsafe for all nilsafe variants of
operators, etc.
Laurent PETIT
> 2011/4/19 Stuart Halloway <stuart....@gmail.com>:
>
> Concerning my own modules in old contrib, there are three that I use myself
> and that I am planning to maintain, independently of where they will end up:
>
> - clojure.contrib.monads
>
> - clojure.contrib.macro-utils
>
> - clojure.contrib.generic
>
> There is an empty repos already waiting for your macro utils:
> https://github.com/clojure/tools.macro
>
> OK. Note that I don't like very much this name, tools.macro. Too
> generic. tools.core could be better : would reflect functions that may
> go into clojure.core, or that are to be considered at the same level
> for contrib project as is clojure.core for clojure project.
> Or something even more "specialized" in the name, if this makes sense,
> like tools.composition, or tools.nilsafe for all nilsafe variants of
> operators, etc.
>
> tools.macro is a namespace for tools for macro writers.
Ah ok, so -?> and -?>> indeed really do not belong to tools.macro
> For things like -?> I proposed clojure.core.composition, which seems
> consistent with what you are saying
> (see http://dev.clojure.org/display/design/Contrib+Library+Names).
Why not clojure.core.composition ?
But to be honest, deep inside, I have the secret hope that -?> and
-?>> could be located near their -> and ->> cousins, e.g. in
clojure.core <3
> Stu
Konrad Hinsen
>> Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up:
>> - clojure.contrib.monads
>> - clojure.contrib.macro-utils
>> - clojure.contrib.generic
>
> There is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro
Great, thanks, I'll start with that one. Monads depend on it anyway. But I need commit permissions, which I probably don't have, but I don't even know how to find out without trying to do a commit. Can you please add me in the right place? My github account is khinsen.
> I have put some suggested names for the other new projects at http://dev.clojure.org/display/design/Contrib+Library+Names. Please review and comment, either there or here on the list.
It seems that for now the top-level namespaces (well, next-to-top) are
- clojure.core
- clojure.data
- clojure.java
- clojure.tools
I would like to suggest a new one, clojure.control, for control structures. This would be the natural home for monads, but also for parallelization frameworks and even for threading macros. None of this really fits into "data" or "tools".
If the goal is to keep the number of top-level namespaces as small as possible, I'd even propose to put clojure.contrib.generic under that label. Otherwise, I'd propose yet another namespace, clojure.interfaces, where the various submodules of generic would find their home next to other protocols and interfaces of general interest.
Konrad.
Ivan Koblik
Git workflow is a little bit different. You don't really need commit rights to contribute. I found a rather nice explanation of Git workflow here:
http://www.eqqon.com/index.php/Collaborative_Github_Workflow
Hope it helps.
Cheers,
Ivan.
Stuart Halloway
Mapping to old contrib names is shown at http://dev.clojure.org/display/design/Contrib+Library+Names.
Stu
Chas Emerick
- Chas
Konrad Hinsen
> There are several new top-level projects at https://github.com/
> clojure to cover the various contrib libraries people have asked for.
Thanks!
I just pushed tools.macro to github. I'll wait a while to see if this
causes any catastrophes. If not I'll go on with algo.monads and
algo.generic.
Konrad.
pmbauer
the eqqon link is not apropos.
The clojure github readme doesn't advertise the workflow, but you can
find it here:
http://clojure.org/contributing
http://clojure.org/patches
On Apr 20, 1:44 am, Ivan Koblik <ivankob...@gmail.com> wrote:
> Hello Konrad,
>
> Git workflow is a little bit different. You don't really need commit rights
> to contribute. I found a rather nice explanation of Git workflow here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow
>
> Hope it helps.
>
> Cheers,
> Ivan.
>
pmbauer
clojure/core use a different workflow than is typical for github
projects.
The github readme doesn't indicate, but you may find the process here:
http://clojure.org/contributing
http://clojure.org/patches
Cheers,
pm
>
> Git workflow is a little bit different. You don't really need commit rights
> to contribute. I found a rather nice explanation of Git workflow here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow
>
> Hope it helps.
>
> Cheers,
> Ivan.
>
Ivan Koblik
Thanks, good to know. Sorry for the misleading email.
Cheers,
Ivan.
shlomi...@gmail.com
Nicola Mometto
They're in the core.incubator contrib repository
https://github.com/clojure/core.incubator
>>> with
>>> > > your first post.
>>> > > To unsubscribe from this group, send email to
>>> > >http://groups.google.com/group/clojure?hl=en
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> your first post.
>>> To unsubscribe from this group, send email to
Shlomi Vaknin
--
--
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
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/FKvIiQeD5sY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
James Reeves
They're in the core.incubator contrib repository
https://github.com/clojure/core.incubator
Shlomi Vaknin
--
--
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
---
