Re: Questions about Clojure 1.7 Release / Process / Helping Out

[David James]

Andy and Alex: Thanks for the answers!

-- 
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: core async and transducers in Clojure 1.6.0

[Alex Miller]

inc all the other responses in this thread but will also point at this 
example in the core.async tests that defines a transducer (works in 1.6) as 
an example:

https://github.com/clojure/core.async/blob/master/src/test/clojure/clojure/core/pipeline_test.clj#L6


On Monday, December 29, 2014 10:38:05 AM UTC-6, Udayakumar Rayala wrote:
>
> Hi,
>
> We are currently using clojure 1.6.0 and using async channels version 
> "0.1.346.0-17112a-alpha". 
> I see that the (chan) function accepts a transducers but transducers are 
> not available in Clojure 1.6.0. 
>
> Is there any option other than upgrading to Clojure 1.7.0-alpha4? If not, 
> how safe it is right now to use Clojure 1.7.0-alpha4 in production? We 
> really want to use transducers as it makes our code readable.
>
> Thanks,
> Uday.
>

-- 
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: Questions about Clojure 1.7 Release / Process / Helping Out

[Alex Miller]

Hi David!

On Tuesday, December 30, 2014 4:01:27 PM UTC-6, David James wrote:
>
> My questions are: (Please let me know if I've overlooked links to read.)
>
>- Does Rich or Clojure Core have rough dates in mind for the 1.7 
>release? Any idea? (I wouldn't be surprised at all if dates were not at 
> all 
>a driving factor.) From what I can tell, bug fixes, a fixed set of new 
>features, performance, and stability are the driving factors.
>
> We don't work from fixed dates. I think we are currently on a track 
towards a 1.7 final release in Q1. Everything currently targeted towards 
1.7 can be seen in this 
report: 
http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10519
 
which is what I am currently working from on a daily basis. There are some 
tickets in that list that I have added without Rich's approval, but that I 
believe are essential to other vetted tickets or established goals. Some of 
those may be removed in the next round of review with Rich. 

At this point the major "feature" drivers are transducers and feature 
expressions. The majority of the tickets remaining revolve around shoring 
up various aspects of transducers.

>
>- Do the above links about cover it and/or are there additional 
>suggestions where community help is most needed?
>- Is there a good "I want to help, what do I do next?" page? I see 
>   that http://clojure.org/contributing has some suggestions; namely, 
>   using the mailing list. Also, the "Screening Tickets" link above is a 
> great 
>   example.
>
>
>- An idea: I suspect there may be value for a link or blurb (from the 
>   Clojure home page) that would focus attention onto one or two "hot" 
> issues 
>   each week. I say this because JIRA does not seem to be geared towards 
>   driving a critical mass to one ticket at a time -- but sometimes this 
> is a 
>   great way to get the eyes you need on an issue.
>
> Things change enough on a daily basis that it's hard for there to be a 
concrete list pointing to specific tickets. I sometimes ask for help on the 
clojure-dev mailing list when I need that kind of focus.

Some things that come to mind right now for 1.7:
- review or feedback of any patch still on the 1.7 list is useful, 
particularly ones that have not yet been screened
- CLJ-979 and CLJ-1544 are not related to any of our release goals but are 
imho important enough to consider for addition at this time. These are the 
most likely to be chopped out of this list when Rich reviews it. Having a) 
a list of places where they help and b) a list of places where they don't 
hurt is particularly important. Review or alternative approaches would also 
be useful.
- Test and use of feature expressions would be particularly helpful - 
see: https://github.com/levand/fx-hello-world for probably the best way to 
try them out

Beyond 1.7, I recently re-prioritized the Triaged 

 
list for 1.8 and anything at the higher-priority ends of Defects and 
Enhancements are good places to work on patches or give feedback for 1.8. 
Feature work for 1.8 is likely to be anything on the Releases.Next page 
that's not currently in or planned for 1.7 but it's pretty hard to suggest 
a useful way to work on most of that right now.

>
>- Clojure 1.7 is alpha now. I'm curious: how much feedback does our 
>BDFL like/need to move across the various stages (alpha, beta, release 
>candidate, release)?
>
> We work with the following meanings:
Alpha - in dev, not yet "feature complete", may make breaking changes in 
new features
Beta - "feature complete" - we think all new features are in, may still fix 
bugs found
RC - all tickets fixed, potential release pending critical bugs

At the moment, I think feature expressions is the long pole for beta, 
although I believe the patches currently cover the majority of what's 
proposed. My personal hope is that we can go beta in mid-January. I expect 
a period to contemplate the fx changes and drive enough tooling updates to 
consider it further and see what comes out.

>
>- Just for fun, if we were to make a data-driven prediction on the 
>next release, what parts of JIRA do you think are most important to 
>consider? This is probably the best summary I've seen so far: Clojure 
>JIRA Clojure Text Board for Release 1.7 
>
> 
>.
>
> I'd refer to the 1.7 report I linked above as that's what Rich, Stu, and I 
are working from.

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

Re: Questions about Clojure 1.7 Release / Process / Helping Out

[Andy Fingerhut]

The "Clojure JIRA Workflow" page you linked to has several links on it to
'saved JIRA searches', which show only JIRA tickets matching specific
criteria.  In the "Dev patch" section there are ones for all "Needs a
patch" tickets, for example, or all "Incomplete" tickets.  For writing
patches, the "Needs a patch" list are the ones scheduled for the next
release where a patch is desired.  That list is empty right now, I believe,
because all of the ones that were in that state have had patches written
for them, and are waiting to be screened (state "Screenable") or for Rich
Hickey's approval (state "Screened").

Any tickets that are not currently marked with a "Fix version" of 1.7 are
unlikely to be part of Clojure 1.7, and that list is 19 ticket right now, I
believe (look at the links of saved JIRA searches for "Screened",
"Screenable", and "Incomplete" tickets).  You can save searches as your
favorite when you are logged into JIRA, and when you are logged in there is
an "Issues" menu near the top left that has a choice "Manage Filters" in
it, that will show you all of your favorite filters with a count of how
many tickets match them.

The last time I made a guess of "probably within 2 to 6 months" for the
release of Clojure 1.7, Alex Miller, who is much closer to these things,
said it would likely be closer to the low end of that range.  I don't think
dates are a driving factor.

The activity of JIRA tickets tends to be that Clojure contributors create
tickets or write and attach patches, add comments, etc., whenever they
wish.  Alex Miller and other screeners evaluate screenable tickets to
decide whether they should become Screened or not, on their schedule, and
Rich Hickey tends to pick a day roughly every month or two to look at a
bunch of screened tickets all at once (or earlier in a release cycle, to
look at a bunch of triaged tickets to decide whether to mark them Vetted or
not).  I'm not sure whether having a "ticket of the week" would generate
much interest, but I haven't seen it tried, either.

Probably the most useful feedback for the alpha/beta releases are "this
seems to be a bug in this release that wasn't in a previous release" and
"performance for this commonly used construct is much worse in this release
than in previous ones".  Also useful is "we tried the latest Clojure
release on Clojure code base X, and everything is working as expected."

Andy


On Tue, Dec 30, 2014 at 2:01 PM, David James  wrote:

> I'm curious about the future Clojure 1.7 release. I recently looked over
> these pages:
>
>- Clojure JIRA Workflow
>
>- Contributing to Clojure
>
>- Next Release Planning
>
>- Clojure Changelog
>
>- Screening Tickets
>
>- JIRA Road Map
>
> 
> (currently showing that 54 of 73 issues have been resolved)
>
> My questions are: (Please let me know if I've overlooked links to read.)
>
>- Does Rich or Clojure Core have rough dates in mind for the 1.7
>release? Any idea? (I wouldn't be surprised at all if dates were not at all
>a driving factor.) From what I can tell, bug fixes, a fixed set of new
>features, performance, and stability are the driving factors.
>- Do the above links about cover it and/or are there additional
>suggestions where community help is most needed?
>   - Is there a good "I want to help, what do I do next?" page? I see
>   that http://clojure.org/contributing has some suggestions; namely,
>   using the mailing list. Also, the "Screening Tickets" link above is a 
> great
>   example.
>   - An idea: I suspect there may be value for a link or blurb (from
>   the Clojure home page) that would focus attention onto one or two "hot"
>   issues each week. I say this because JIRA does not seem to be geared
>   towards driving a critical mass to one ticket at a time -- but sometimes
>   this is a great way to get the eyes you need on an issue.
>- Clojure 1.7 is alpha now. I'm curious: how much feedback does our
>BDFL like/need to move across the various stages (alpha, beta, release
>candidate, release)?
>- Just for fun, if we were to make a data-driven prediction on the
>next release, what parts of JIRA do you think are most important to
>consider? This is probably the best summary I've seen so far: Clojure
>JIRA Clojure Text Board for Release 1.7
>
> 
>.
>
> P.S. I'm building a useful list of 

Questions about Clojure 1.7 Release / Process / Helping Out

[David James]

I'm curious about the future Clojure 1.7 release. I recently looked over 
these pages:

   - Clojure JIRA Workflow 
   
   - Contributing to Clojure 
   
   - Next Release Planning 
   
   - Clojure Changelog 
   
   - Screening Tickets 
   
   - JIRA Road Map 
   

(currently showing that 54 of 73 issues have been resolved)
   
My questions are: (Please let me know if I've overlooked links to read.)

   - Does Rich or Clojure Core have rough dates in mind for the 1.7 
   release? Any idea? (I wouldn't be surprised at all if dates were not at all 
   a driving factor.) From what I can tell, bug fixes, a fixed set of new 
   features, performance, and stability are the driving factors.
   - Do the above links about cover it and/or are there additional 
   suggestions where community help is most needed?
  - Is there a good "I want to help, what do I do next?" page? I see 
  that http://clojure.org/contributing has some suggestions; namely, using 
  the mailing list. Also, the "Screening Tickets" link above is a great 
  example.
  - An idea: I suspect there may be value for a link or blurb (from the 
  Clojure home page) that would focus attention onto one or two "hot" 
issues 
  each week. I say this because JIRA does not seem to be geared towards 
  driving a critical mass to one ticket at a time -- but sometimes this is 
a 
  great way to get the eyes you need on an issue.
   - Clojure 1.7 is alpha now. I'm curious: how much feedback does our BDFL 
   like/need to move across the various stages (alpha, beta, release 
   candidate, release)?
   - Just for fun, if we were to make a data-driven prediction on the next 
   release, what parts of JIRA do you think are most important to consider? 
This 
   is probably the best summary I've seen so far: Clojure JIRA Clojure Text 
   Board for Release 1.7 
   

   .

P.S. I'm building a useful list of terms/acronyms:

   - BDFL: Benevolent Dictator For Live (a.k.a Rich)
   - JIRA: "We originally used Bugzilla for bug tracking and the developers 
   in the office started calling it by the Japanese name for Godzilla, Gojira 
   ... then it became an issue tracker, the name stuck, but the Go got dropped 
   - hence JIRA! ... Further investigation into the name has revealed that 
   Gorira is Japanese for "gorilla", whilst Kujira is Japanese for "whale". So 
   Gojira is roughly translated to mean "*gorilla the size of a whale*" 
   (from What does JIRA mean? 
   
   )

-- 
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: core async and transducers in Clojure 1.6.0

[Max Penet]

I did the same recently, you can already leverage transducer support in 
core.async while staying backward compatible with clojure 1.6. You loose 
some sugar and the transducer versions of most sequences functions but it's 
very usable still. 

you can see 2 examples here: 
https://github.com/mpenet/jet/blob/master/src/clj/qbits/jet/client/http.clj#L63-L84

one just decodes chunk from http responses as they are fed to a channel, 
the other takes every chunk from the response and reduces them into a 
single value before putting it into the channel. Not a killer use for sure, 
but it makes code a lot less convoluted.

On Monday, December 29, 2014 7:00:38 PM UTC+1, Francis Avila wrote:
>
> It will be inconvenient to use transducer functions without the transducer 
> support added in 1.7.0, but there's nothing magical about transducers that 
> requires Clojure 1.7.
>
> Core.async 0.1.346.0-17112a-alpha does not depend on clojure 1.7 (it only 
> depends on Clojure 1.6) and you don't need anything special to create a 
> transducing function. We use the transducer features of core.async with 
> Clojure 1.6 in production.
>
> All you need to do is provide the core async channel with a function that 
> has the transducer structure: a function accepting a transforming-function 
> (supplied by core.async) and returning a function with three arities for 
> initialization, finalization, and the reduction step.
>
> (fn [xf]
>   (fn
> ([] (xf))
> ([r] (xf r))
> ([r v] (xf r v)))
>
> We use an as-transducer function as a convenience to make these:
>
> https://gist.github.com/favila/ecdd031e22426b93a78f
>
> On Monday, December 29, 2014 10:38:05 AM UTC-6, Udayakumar Rayala wrote:
>>
>> Hi,
>>
>> We are currently using clojure 1.6.0 and using async channels version 
>> "0.1.346.0-17112a-alpha". 
>> I see that the (chan) function accepts a transducers but transducers are 
>> not available in Clojure 1.6.0. 
>>
>> Is there any option other than upgrading to Clojure 1.7.0-alpha4? If not, 
>> how safe it is right now to use Clojure 1.7.0-alpha4 in production? We 
>> really want to use transducers as it makes our code readable.
>>
>> Thanks,
>> Uday.
>>
>

-- 
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: Finding ClojureScript Libraries

[Francesco Bellomi]

Hi,

FWIW I just put on a Clojurescript-specific subsite of CrossClj [1], that lists 
and searches both cljs tools and projects (published on clojars/github) with at 
least a .cljs source file (that includes projects developed with cljx)

http://crossclj.info/cljs

The auto-completing search field only looks into cljs projects for vars, fns 
and namespaces.

Of course this is much less curated than the wiki, being auto-genrated, but 
it's always fresh.

I also put on a cljs-specific page for documentation search:

http://crossclj.info/docsjs

which searches on the whole corpus of auto-generated docs of ClojureScript 
related projects,

Both these features are still buggy: CrossClj still has some problems 
cross-referencing some cljs projects. Also the docs search shows some 
unnecessary redundancy. I hope to fix these issues soon.

Francesco

[1] http://crossclj,info 

-- 
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: core async and transducers in Clojure 1.6.0

[Sean Corfield]

On Dec 29, 2014, at 8:38 AM, Udayakumar Rayala  wrote:
> Is there any option other than upgrading to Clojure 1.7.0-alpha4? If not, how 
> safe it is right now to use Clojure 1.7.0-alpha4 in production? We really 
> want to use transducers as it makes our code readable.

We’ve used pre-release (alpha, beta, RC) builds in production for years with no 
trouble. We originally went live on 1.3.0-alpha7 (or alpha8, I no longer 
remember) and right now we’ve been on 1.7.0-alpha2 for almost three months with 
no issues.

We always run multi-version unit tests, against whatever "stable" version we’re 
on as well as the current master snapshot so we pick up any breaking changes 
before they hit a version we might go to production with.

Unlike some other languages, the official Clojure pre-release builds are 
impressively stable!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"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 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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Jony Hudson]

That would be great, if possible! I did try looking yesterday with visualvm 
to see what was going on, but some 50,000 findClass calls in, visualvm ran 
out of memory and crashed. And then I got distracted ...


Jony

On Tuesday, 30 December 2014 07:22:02 UTC, Mikera wrote:
>
> I'm trying to figure out how to get core.matrix to load much faster - I 
> think it's actually some kind of Clojure issue with protocols but I'm not 
> *exactly* sure what is causing
>
> On Tuesday, 30 December 2014 05:13:24 UTC+8, Jony Hudson wrote:
>>
>> @Mike Thinking out loud here ... one option would be to put the 
>> core.matrix dependent stuff in gg4clj in a separate ns, like 
>> gg4clj.datasets or similar. This would then avoid the loading time for 
>> users just wanting to use gg4clj.core. I'm not sure I think this as good a 
>> solution, ultimately, as trying to make core.matrix load in a more 
>> incremental fashion -  but I do appreciate that it's not so easy to change 
>> core.matrix, and that there are good reasons not to. What do you think - 
>> does this sound like a reasonable way forward to you? 
>>
>>
>> Jony
>>
>

-- 
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: Is there a reason ns macro is not a function?

[Angel Java Lopez]

Hi!

My first guess: a normal function evaluates all its arguments. ns uses
(:require ) (:use.. ) (:import ..) that should be not evaluated at ns
apply. The alternative is to make ns an special form, but macro should be
more flexible.

Instead, in-ns is simpler, and it can be implemented as a normal function.

Angel "Java" Lopez
@ajlopez


On Tue, Dec 30, 2014 at 5:30 AM, Petr  wrote:

> Hello.
>
> Does anyone know why clojure.core/ns macro is not implemented as function?
> It seems that it should work that way except that probably it would be
> nicer to have in-ns call at the top level.
>
> --
> 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: core async and transducers in Clojure 1.6.0

[Aleš Roubíček]

Clojure 1.7 alphas are pretty solid. I use them in production without any 
problems and with benefits of 1.7. 

On Monday, December 29, 2014 5:38:05 PM UTC+1, Udayakumar Rayala wrote:
>
> Hi,
>
> We are currently using clojure 1.6.0 and using async channels version 
> "0.1.346.0-17112a-alpha". 
> I see that the (chan) function accepts a transducers but transducers are 
> not available in Clojure 1.6.0. 
>
> Is there any option other than upgrading to Clojure 1.7.0-alpha4? If not, 
> how safe it is right now to use Clojure 1.7.0-alpha4 in production? We 
> really want to use transducers as it makes our code readable.
>
> Thanks,
> Uday.
>

-- 
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.

Is there a reason ns macro is not a function?

[Petr]

Hello.

Does anyone know why clojure.core/ns macro is not implemented as function? 
It seems that it should work that way except that probably it would be 
nicer to have in-ns call at the top level. 

-- 
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.