#jython IRC Log


IRC Log for 2015-05-28

Timestamps are in GMT/BST.

[1:36] <fwierzbicki1> ok, the basics of extended iterable unpacking are checked into the jython3 git repo.
[2:41] * eatkin (~eatkin@ has joined #jython
[3:10] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) Quit (Remote host closed the connection)
[3:34] * koo6 (~koo5@236.152.broadband3.iol.cz) Quit (Ping timeout: 264 seconds)
[4:34] <ztane> so which is the official repo now? I could see too if I can do something
[4:52] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) has joined #jython
[6:29] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) Quit (Quit: Leaving)
[7:25] <agronholm> ztane: fkr 2
[7:25] <agronholm> agh
[7:25] <agronholm> ztane: for 2.7 or 3.x?
[10:49] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Ping timeout: 248 seconds)
[10:52] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[10:54] <ztane> 3+ obviously
[10:54] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Excess Flood)
[10:54] <ztane> 3.5+ would be obvious target since it has the bytes % formatting
[10:55] <ztane> btw, python enum planet example was copied from java example :D
[10:57] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[10:57] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Excess Flood)
[11:01] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[11:02] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Excess Flood)
[11:03] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[11:17] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Ping timeout: 248 seconds)
[11:24] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[11:42] * xemdetia (xemdetia@nat/ibm/x-wltklpjokjjimgbx) has joined #jython
[11:47] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Ping timeout: 248 seconds)
[11:48] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[11:50] * dustinm (~dustinm@105.ip-167-114-152.net) Quit (Excess Flood)
[11:50] * dustinm (~dustinm@105.ip-167-114-152.net) has joined #jython
[13:06] <agronholm> ztane: https://github.com/jython/jython3 <- this is what we have as far as jython 3 code goes
[14:36] * koo6 (~koo5@236.152.broadband3.iol.cz) has joined #jython
[14:40] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[14:59] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[14:59] * ChanServ sets mode +o Arfrever
[15:39] <jimbaker> next step is to make https://github.com/jython/jython27 be authoritative for 2.7 development (probably best to keep the github.com/jythontools/jython mirror, but not certain)
[15:40] <jimbaker> i would prefer using jython27 than jython for the obvious reasons
[15:41] <jimbaker> peke, any chance we can have you take a look at the repo cleanup you suggested? that's the blocker for doing this move
[15:42] <jimbaker> also, before i got pretty sick (but apparently now recovering) i was looking at doing a filter of the cpython docs
[15:43] <jimbaker> so that will be a next step
[16:13] * DanC_ (~dconnolly@ has left #jython
[16:25] * gopar (~gopar@ has joined #jython
[17:12] * koo6 (~koo5@236.152.broadband3.iol.cz) Quit (Ping timeout: 265 seconds)
[17:42] * mbooth_ (~mbooth@redhat/mbooth) has joined #jython
[17:44] * mbooth (~mbooth@redhat/mbooth) Quit (Ping timeout: 272 seconds)
[18:02] <peke> jimbaker: unfortunately i'm _really_ busy right now and haven't actually done such cleanup myself.
[18:03] <peke> when we moved robot framework to github, i was responsible on moving issues and others moved the repository.
[18:03] <jimbaker> peke, i wonder if we should defer then. don't want some perfect preventing the good of moving over to github sooner than later
[18:04] <peke> i totally agree it's more important to move to github than cleanup the repo. cleaning up shouldn't be that big a task for someone who knows git a bit better, though.
[18:05] <peke> any git gurus here? or anyone knows one?
[18:08] <peke> if we agree that it is a good idea to move also issues to github, i can take a look at that. i doubt i have time for it until in july, but that's anyway better to do after the repo has been moved.
[18:11] <jimbaker> peke, sounds good, i wasn't aware of timing related issues. i guess the easiest thing to do is fork jythontools/jython into jython/jython27. we can just take master - i don't really care if older branches (2.2, 2.5) remain on hg.python.org/jython
[18:11] <jimbaker> at least for the time being
[18:11] <jimbaker> as authoritative - clearly 2.2 is just historical, and 2.5 needs work, but has little interest by anyone
[18:12] <peke> hmmm, wouldn't it be easier to have everything in same repo?
[18:13] <peke> i don't think it's possible to add branches there later without requiring everyone to re-clone.
[18:14] <jimbaker> peke, well i'm purposefully calling it jython/jython27 ...
[18:15] <peke> i see.
[18:15] <jimbaker> peke, if we look at https://hg.python.org/, it's done the same way
[18:15] <jimbaker> it's a bit of a mess, mind you...
[18:16] <jimbaker> lots of sandboxes, feature branches, etc
[18:18] <jimbaker> but cpython is python3; releasing/2.7.x for other releases. iirc it was svn before 2.7
[18:21] <jimbaker> not quite true; https://hg.python.org/cpython/ includes current 2.7.10 work (which was just released a few days ago btw)
[18:24] <jimbaker> brb, rebooting this box
[18:30] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Quit: Coyote finally caught me)
[18:43] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[18:43] * ChanServ sets mode +o jimbaker
[18:53] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 276 seconds)
[19:05] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[19:05] * ChanServ sets mode +o jimbaker
[19:06] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Quit: Konversation terminated!)
[19:10] <Arfrever> Which things are planned for being moved to github? Only source code repository?
[19:21] <jimbaker> also docs, as filtered from cpython
[19:24] <jimbaker> agronholm, Arfrever, any thoughts on having github.com/jython/jython27 - only move the master branch for 2.7, and we continue to have a separate github.com/jython/jython3?
[19:24] <jimbaker> this seems easiest, because github.com/jython/jython27 is effectively just a fork of github.com/jythontools/jython that we make authoritative
[19:25] <jimbaker> but i'm not git/github expert, i have just used it :)
[19:25] <agronholm> jimbaker: my idea is to put that in jython/jython and when the jython 3 repo is in workable condition, merge that remove the jython3 repository and then create a 2.7 branch
[19:25] <jimbaker> (also used it in my teaching, but those were perhaps crazy workflows)
[19:26] <jimbaker> agronholm, so more like hg.python.org/cpython then
[19:26] <agronholm> yes
[19:26] <jimbaker> i think that makes perfect sense to me
[19:26] <agronholm> we could merge the jython 3 work now of course
[19:27] <agronholm> no particular reason not to
[19:27] <agronholm> the 2.7 branch will have to be made right away in that case
[19:27] <jimbaker> i think we should do that merge of jython3 later, unless it makes jython3 dev easier
[19:28] <agronholm> doesn't really matter either way IMHO
[19:29] <jimbaker> for now, main focus of work is on 2.7.x, because we have the possibility of doing time-based releases there, and then figure out when we do the 3.5 release
[19:29] <jimbaker> good to see you've been working through async/await btw!
[19:29] <agronholm> I've been very interested in new language features in 3.5
[19:29] <agronholm> particularly PEP 484 type hinting
[19:30] <jimbaker> i think that's the best part of going for 3.5 for jython
[19:30] <jimbaker> here's some stuff that could really benefit us
[19:30] <agronholm> I was thinking the same
[19:30] <jimbaker> eg autostub every java package
[19:30] <agronholm> how would that work?
[19:30] <Arfrever> +1 for multiple branches (2.7, 3.5) in single repository.
[19:31] <agronholm> Arfrever: I was thinking 3.x work would remain in master for now, and 2.7 work would go in the 2.7 branch
[19:31] <jimbaker> autostubbing - it would just be one more part of package scanning
[19:31] <Arfrever> Would it make sense to target 3.6 instead of 3.5?
[19:31] <jimbaker> Arfrever, that's likely the real target :)
[19:31] <agronholm> I really wish I had more time
[19:31] <Arfrever> In CPython repository, there is now 3.5 branch, and default branch has CPython 3.6.
[19:32] <agronholm> also, I would be more productive if given proper tutoring on the jython internals
[19:32] <agronholm> like, how to add new language syntax
[19:32] <agronholm> and why there are many kinds of built-in modules
[19:32] <jimbaker> agronholm, ahh, we missed that at pycon
[19:33] <agronholm> there wasn't a lot of time
[19:33] <jimbaker> at least super got implemented...
[19:33] <jimbaker> ;)
[19:33] <agronholm> and I was more productive than last time (2012)
[19:33] <agronholm> I felt like I actually got stuff done :)
[19:33] <jimbaker> agronholm, one thing we can definitely do is cleanup the many kinds of built-in modules :)
[19:34] <agronholm> jimbaker: yes...and PySystemState needs to die
[19:34] <jimbaker> indeed it does
[19:34] <agronholm> the variable length integer is also a big challenge
[19:34] <agronholm> I looked at implementing that but it was beyond my knowledge
[19:35] <jimbaker> so cpython 3.6 has no current release schedule
[19:35] <agronholm> Arfrever: we'll have our hands full implementing 3.5
[19:35] <agronholm> but one crucial difference when compared to 2.7 is that we no longer have to maintain strict backwards compatibility
[19:35] <jimbaker> agronholm, what do you mean variable length integer?
[19:36] <agronholm> jimbaker: that long was removed
[19:36] <agronholm> "int" can be arbitrarily large
[19:36] <agronholm> but how to do that efficiently
[19:37] <agronholm> the idea of using BigInteger to back every python in makes me shudder
[19:37] <agronholm> *int
[19:37] <Arfrever> jimbaker: Re "so cpython 3.6 has no current release schedule": It can be estimated easily. 18 months after scheduled release of 3.5.0.
[19:37] <jimbaker> well, we already support variable length integers
[19:37] <agronholm> yes, with PyLong?
[19:37] <Arfrever> So 2017-03.
[19:38] <jimbaker> PyInteger does the abstraction
[19:38] <jimbaker> Arfrever, so there you go - 2 years from now :)
[19:38] <agronholm> so just remove PyInteger and rename PyLong to PyInteger?
[19:39] <jimbaker> agronholm, it's just a question of making it look the same to users. i don't think it's much work
[19:40] <agronholm> jimbaker: I was thinking, could we get a code signing certificate in the PSF's name, or maybe just for Jython?
[19:40] <jimbaker> no longer support constants like 47L. don't have the repr display L suffix. have type() return int. otherwise, it's pretty much abstracted away
[19:40] <jimbaker> agronholm, that sounds reasonable
[19:41] <jimbaker> i know it came up in a different context with respect to windows installs
[19:41] <agronholm> I also finally understood why jarsigner bitches about tsaurl not being specified
[19:41] <agronholm> and why jars need to be timestamped
[19:42] <agronholm> without signed timestamped, a JRE cannot know if the jar was signed with a non-expired certificate, after the certificate has expired
[19:42] <agronholm> so timestamping keeps the jars valid indefinitely
[19:43] <agronholm> otherwise they would fail to validate the moment the code signing certificate expires
[19:45] <jimbaker> agronholm, just tell me what we need from the PSF, as well as the workflow steps, and we can have this place for 2.7.1
[19:45] <jimbaker> presumably we will just have fwierzbicki1 do the signing, but some group of us should be able to do the same
[19:47] <agronholm> jimbaker: we just need a X.509 certificate authorized for code signing
[19:47] <agronholm> one granted by an authority recognized by oracle et al, so it works with java web start too
[19:49] <fwierzbicki1> agronholm: I'm pretty sure this is something the PSF will either have or will be wiling to get on our behalf. I'll just have to figure out the security needs around such a certificate. It might mean that I need to move the build for Jython distributions to some PSF based server.
[19:49] <agronholm> fwierzbicki1: well, obviously the key needs to be kept safe -- so yeah, that might be necessary
[19:50] * fwierzbicki1 is now known as fwierzbicki
[19:51] <jimbaker> yeah, that certainly would be ideal
[19:51] <jimbaker> also it would be best if jython.exe is built in this way, and signed too
[19:52] <agronholm> yup
[19:54] <jimbaker> fwierzbicki, so it looks like consensus is that we are going to move to github.com/jython/jython as the main code repo. (i believe we have quorum here - pjenvey is probably the only other person who has been actively involved in this discussion)
[19:55] <jimbaker> and i'm hoping that agronholm can do this work once again :)
[19:55] <fwierzbicki> looking here https://docs.oracle.com/javase/tutorial/deployment/jar/signing.html it looks like I would create the jars and then run them through "jarsigner -sigfile cert -tsa http://some.tsa.authority
[19:55] <jimbaker> then peke can help us do a post cleanup
[19:55] <fwierzbicki> jimbaker: sounds good to me!
[19:56] <jimbaker> github.com/jython/jython3 will still be active for at least the time being - we need to be closer to something really working before pulling in - maybe an alpha?
[19:56] <agronholm> fwierzbicki: hope this helps: https://github.com/jython/swingutils/blob/master/build.xml
[19:56] <agronholm> re: signing
[19:56] <agronholm> I found a free timestamp authority too (with a limited number of timestamps per day per ip)
[19:57] <fwierzbicki> agronholm: looks pretty straightforward once i get a cert and a tsa url
[19:57] <agronholm> fwierzbicki: there's a working TSA url in that ant file
[19:57] <fwierzbicki> oh I see it, thanks :)
[19:58] <agronholm> that one has some limitations, obviously
[19:58] <agronholm> I haven't done all that much research on alternatives, I admit
[19:58] <agronholm> jimbaker: is there anything more involved than pull/push? I believe you talked about pruning some unwanted binaries from the history...?
[19:58] <fwierzbicki> agronholm: I think there is a good chance that the PSF has a prefered tsa - though I'm not positive. I know they do some signing
[19:58] <agronholm> fwierzbicki: yup
[19:59] <jimbaker> agronholm, i don't think it is, other than we want to get all the branches if possible from hg.python.org/jython
[19:59] <agronholm> jimbaker: I can do that
[19:59] <jimbaker> agronholm, cool
[20:00] <agronholm> they just need to be bookmarked to be recognized as git branches by that tool
[20:00] <jimbaker> peke will help with pruning after you do this. but he said that can be done about month from now
[20:01] <agronholm> the pruning needs to be done now
[20:01] <jimbaker> fwierzbicki, agronholm - probably best to ask either on #python-dev, or on python-dev mailing list
[20:01] <agronholm> otherwise anyone who forks jython will be in for a nasty surprise when we do the pruning
[20:01] <fwierzbicki> jimbaker: yeah I'll take that on - though I can't today
[20:01] <agronholm> because the forks will no longer be compatible
[20:02] <jimbaker> this is the recloning problem, right?
[20:02] <agronholm> the word recloning rings no bells
[20:02] <jimbaker> then i have no idea :)
[20:02] * koo6 (~koo5@236.152.broadband3.iol.cz) has joined #jython
[20:02] <jimbaker> i'm just trying to push this process forward :)
[20:02] <agronholm> but pruning changes the version history so any forks will be unrooted
[20:02] <fwierzbicki> though won't most clones be from hg?
[20:02] <fwierzbicki> so they will have to transition to git anyway...
[20:02] <agronholm> fwierzbicki: jim suggested that the pruning be done in a month
[20:03] <fwierzbicki> oh I see
[20:03] <jimbaker> i think in a nutshell, the pruning is remove extlibs/ jars
[20:03] <agronholm> so any clones made during that time wil be incompatible
[20:03] <jimbaker> and resolve separately
[20:03] <fwierzbicki> that would suck yeah
[20:03] <agronholm> jimbaker: resolve separately? using maven, or...?
[20:03] <jimbaker> yes, maven
[20:04] <jimbaker> or a manual process
[20:04] <agronholm> I have never used maven so someone needs to figure this out
[20:04] <jimbaker> but maven seems to be the approach to resolve artifacts
[20:04] <agronholm> I can probably handle the pruning on my own
[20:04] * gopar (~gopar@ Quit (Remote host closed the connection)
[20:05] <jimbaker> maybe we just make this a manual step - copy from your hg checkout :)
[20:05] <jimbaker> until we get the pom resolution done
[20:05] <jimbaker> just a question of integrating our ant build with pom, that's all
[20:05] <agronholm> I have taken a look at maven's pom file structure
[20:05] <agronholm> it didn't look too complicated
[20:06] <jimbaker> yeah, it should be straightforward. and because it's in code, we can make it better at any time
[20:06] <jimbaker> as opposed to being in history
[20:08] <jimbaker> also, it should just be a simple step from there to remove jarjarlinks in favor of maven shading
[20:09] <jimbaker> https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
[20:09] <jimbaker> works exactly the same as jarjarlinks
[20:09] <agronholm> +1 for stronger maven integration
[20:10] <agronholm> I could use some in my own project -- I'm currently storing all the dependencies in source control :/
[20:10] <jimbaker> yeah, it made sense for a different time
[20:14] <jimbaker> agronholm, what if we used submodule to manage these dependencies temporarily?
[20:14] <agronholm> a subrepository?
[20:14] <jimbaker> yeah
[20:14] <agronholm> why?
[20:15] <jimbaker> just as a convenience. but maybe more. it could be useful for storing jython.exe and the cpython 27 dll
[20:15] <agronholm> are we in a hurry to do the migration?
[20:15] <agronholm> I would like to move directly to using maven
[20:15] <jimbaker> well, i think it's best to do concrete steps as soon as possible
[20:16] <jimbaker> so i'm completely ok with saying, you will have to cp $HGBRANCH/extlibs/*.jar extlibs/.
[20:17] <jimbaker> because we know this can be rapidly improved
[20:17] <agronholm> that wouldn't be necessary
[20:17] <jimbaker> sure, once we adopt maven
[20:17] <agronholm> assuming we actually use a subrepository at extlibs/
[20:18] <jimbaker> or sure, we can do that first as well
[20:18] <agronholm> -1 on that
[20:18] <agronholm> I expect it will get messy enough that the time would have been better spent on getting this to run on maven
[20:19] <jimbaker> agronholm, so maven first, then move to github?
[20:19] <agronholm> yup
[20:19] <jimbaker> i suppose. i guess i'm impatient because the user exp is just so bad right now. at least if one is merging PRs... otherwise, probably fine
[20:21] <jimbaker> well, i also hate that working on my own feature branches against hg.python.org/jython is just as painful
[20:22] <jimbaker> biab, i really need to get some lunch
[20:23] <agronholm> I don't quite see how that would be painful
[20:49] <peke> jimbaker: agronholm is right that possible pruning of history needs to be done before the repository goes public.
[20:50] <peke> also, i actually promised to help migrating _issues_ to github (assuming there's a consensus that's a good idea) in a month when i hopefully have more time.
[20:51] <peke> i could take a look at pruning the history too, but i don't have any first hand experience from it. anyone else with some git knowledge can do it too.
[20:51] <fwierzbicki> issues - as in roundup?
[20:51] <fwierzbicki> or something else????
[20:52] <agronholm> I wouldn't mind using github's issue tracker -- assuming they have an export function
[20:52] <peke> fwierzbicki: yes, move bugs.jython.org to github
[20:53] <agronholm> ok, apparently they do
[20:53] <fwierzbicki> peke: I'm good with that given that there is an exporter
[20:53] <fwierzbicki> Will we be able to migrate the issue history?
[20:53] <fwierzbicki> (as in closed bugs?)
[20:53] <agronholm> I would assume so
[20:53] <agronholm> given any decent exporter
[20:54] <peke> github issue tracker isn't the best one i've used but neither is roundup. in by good github tracker wins in general, and obviously the really big win is getting integration to version control.
[20:54] <fwierzbicki> if so, I'm all for it. The Jython bug tracker is behind the CPython one, and there is no maintainer (we lost ours a while back)
[20:54] <agronholm> I did raise the issue of getting us a free JIRA license at pycon
[20:54] <agronholm> JIRA is the best issue tracker I've seen so far
[20:54] <peke> i have know idea is there a ready made exporter. when we moved robot framework to from google code to github, we needed to create own own exporter script.
[20:54] <fwierzbicki> oh that would work too
[20:54] <agronholm> but I'm cool with github too
[20:56] <peke> personally i think jira is too heavy weight in general but that's definitely a personal taste.
[20:56] <agronholm> let's go with github then
[20:56] <agronholm> it's certainly workable
[20:56] <fwierzbicki> If we are hosting the code at github, it makes sense to use their tracker too
[20:56] <fwierzbicki> I'm sure there are benefits (linking to code easily etc)
[20:57] <peke> at github the automatic integration between version control and issue tracker is so good that an external tracker needed to be a lot better to be worth the trouble.
[20:57] <peke> i love it that #1234 automatically creates links both ways and that "fixes #1234" actuallu just does that.
[20:57] <fwierzbicki> that's pretty nice
[20:59] <peke> anyway, since i have experience migrating issues to github, that's definitely something where i can help with jython too.
[21:00] <peke> when we moved robot's issues from google code to github, we moved all issues and were able to preserve ids.
[21:00] <agronholm> peke: sounds good
[21:00] <fwierzbicki> peke: cool, that's great!
[21:01] <peke> with jython the latter isn't possible because there are old issues originating from sourceforge with ids like 222342342
[21:03] <peke> adding a link to migrated issues on github pointing to the old issue is easy. adding a link to old issues to github depends on is there any suitable api on roundup.
[21:04] <peke> this is anyway something that can be done after the repository itself has been moved.
[21:05] * fwierzbicki (~Adium@99-106-169-5.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Leaving.)
[21:05] <peke> here's by the way information about why pruning the repository history would probably be a good idea and also instructions how to do it:
[21:05] <peke> https://git-scm.com/book/es/v2/Git-Internals-Maintenance-and-Data-Recovery#Removing-Objects
[21:06] <peke> we did that when we moved our repository. i didn't participate in actually doing it so i don't have first hand experience.
[21:28] <ztane> so what is the way of running anythin jython3, I am getting complaints about YieldFrom...
[21:34] <agronholm> ztane: it's nowhere near a runnable state
[21:34] <agronholm> you're seriously jumping the gun here :)
[21:35] <agronholm> there's a gazillion things to be fixed
[21:39] <agronholm> we've only scratched the surface so far
[21:44] <ztane> :D
[21:45] * fwierzbicki (~Adium@194.sub-70-214-14.myvzw.com) has joined #jython
[21:45] <ztane> I thought maybe not runnable but can I do PythonInterpreter.eval or something
[22:01] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 250 seconds)
[22:16] <fwierzbicki> ztane: if you run it with -S it should start up, but not much works. YieldFrom is a big one that has support in the parser but nothing in the compiler yet.
[22:17] <fwierzbicki> and since YieldFrom is all over the place (in os.py for example) real programs will just die
[22:17] <jimbaker> any objections to using gradle? some of my colleagues at rackspace really like it, and it does seem like it will be less complexity than managing pom.xml, especially since we want to publish multiple artifacts
[22:17] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[22:18] <fwierzbicki> also nonlocal and the argumentless super are all over the place - those I'm working on now (well, day job so not *right now* )
[22:18] <jimbaker> that gradle uses groovy is absolutely fine imho
[22:18] <jimbaker> we like all of the jvm languages here in #jython
[22:18] <fwierzbicki> gradle > pom IMHO
[22:18] <fwierzbicki> I've liked it when I've encountered it
[22:18] <jimbaker> http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608 seems convincing
[22:18] <fwierzbicki> and it uses the same dependencies as maven
[22:18] <jimbaker> yeah, that seems the key point
[22:19] <jimbaker> we get a DSL, and maven integration
[22:19] <jimbaker> plus it supports existing ant tasks
[22:19] <jimbaker> if it all works, why not? ;)
[22:19] <fwierzbicki> I'm up for it - as long as somebody else does it :)
[22:19] <jimbaker> i was just comparing this against https://github.com/jruby/jruby/blob/master/pom.xml
[22:19] <fwierzbicki> oh yeah, I don't even need to look
[22:19] <fwierzbicki> coding with xml == the suck
[22:20] <fwierzbicki> that includes ant
[22:20] <jimbaker> fwierzbicki, yeah, we have had enough with ant for sure on that
[22:20] <jimbaker> also, i already have sort of a guide here: https://github.com/rackerlabs/keystone-jvm/blob/master/build.gradle
[22:20] <jimbaker> this was written by one of my rackspace colleagues. it assumes a standalone jar, then builds out an openstack keystone jar
[22:20] <fwierzbicki> I'm all for it, several projects at work use it - I like it much more than pom files (which is the majority here)
[22:21] <jimbaker> cool, i will take a look at writing up this in gradle and see where it goes
[22:21] <fwierzbicki> oh nice, that's actually for Jythob
[22:21] <fwierzbicki> *Jython
[22:21] <jimbaker> yeah, indeed it is
[22:21] <jimbaker> sort of the same functionality as clamp's singlejar
[22:21] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[22:22] <fwierzbicki> uh oh you said jruby and summoned one of them :)
[22:22] <jimbaker> enebo is of course a big fan of xml ;), he's here to defend their pom.xml i'm sure
[22:22] <fwierzbicki> ha, doubt it
[22:23] <jimbaker> enebo, since we are dragging you in the conversation, we are thinking of using gradle (and i guess a smattering of groovy) to rework our current ant-based build
[22:23] <jimbaker> still want to use our ant custom tasks
[22:24] <jimbaker> eg bytecode annotations (our expose task); and antlr generation
[22:25] <enebo> DONT CARE
[22:25] <enebo> :)
[22:25] <enebo> tbh I am not sure if I like any build tool now???I feel like typing it all in by hand now
[22:25] <jimbaker> ;)
[22:26] <enebo> I have used gradle only for a minecraft experiment and it was slow but the build stuff it was doing was also atypical
[22:26] <jimbaker> well, one alternative is to write our own python-based system that somehow integrates with maven
[22:26] <enebo> maven is slow
[22:26] <enebo> we did that with ant
[22:26] <enebo> the real issue for me is pushing artifacts
[22:27] <enebo> buildr I looked at recently
[22:27] <enebo> It just did not seem to get a lot of adoption
[22:27] <jimbaker> enebo, yeah, that's what we want to support better. not to mention better shading of dependencies
[22:28] <enebo> I remade a library to use buildr from maven and builds went from like 35s to about 18s with JRuby as the Ruby and like 11s with MRI as the ruby
[22:28] <jimbaker> but we are about to transition to github.com/jython from hg.python.org/jython, and want to nuke storing ext dependencies in source control
[22:28] <jimbaker> because that's just painful. and no longer necessary
[22:29] <enebo> yeah we made that change as well
[22:29] <enebo> but fwiw it is good for clones but bad for ci
[22:30] <enebo> anyways???gotta bolt
[22:30] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[22:30] <jimbaker> hmm, i think we should favor cloning
[22:35] <jimbaker> http://docs.travis-ci.com/user/languages/java/ describes CI with travis, and i hope they optimize by caching artifacts - an obvious thing to do after all
[22:38] * mbooth_ (~mbooth@redhat/mbooth) Quit (Ping timeout: 272 seconds)
[22:52] <jimbaker> fwierzbicki, any progress on YieldFrom? or is that an open task?
[22:52] <jimbaker> i guess i could take a look on the compiler side
[22:53] <fwierzbicki> jimbaker: I have the parser part done - but the compiler part is pending - I'll still be on nonlocal and super() for a while I think
[22:53] <fwierzbicki> so if you want to grab it feel free!
[22:53] <jimbaker> ack. i will take it then
[22:53] <agronholm> the parser part of what
[22:54] <jimbaker> agronholm, of yield from
[22:54] <agronholm> ok
[22:54] <fwierzbicki> oop gotta go for a bit, back in a while
[22:54] <jimbaker> seems straightforward enough to implement https://www.python.org/dev/peps/pep-0380/
[22:54] * fwierzbicki (~Adium@194.sub-70-214-14.myvzw.com) Quit (Quit: Leaving.)
[23:09] * mbooth (~mbooth@redhat/mbooth) has joined #jython
[23:24] * fwierzbicki (~Adium@99-106-169-5.lightspeed.sntcca.sbcglobal.net) has joined #jython
[23:27] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) has joined #jython
[23:34] * koo6 (~koo5@236.152.broadband3.iol.cz) Quit (Ping timeout: 250 seconds)
[23:36] * xemdetia (xemdetia@nat/ibm/x-wltklpjokjjimgbx) Quit (Ping timeout: 265 seconds)


These logs were automatically created by JythonLogBot on irc.freenode.net using a slightly modified version of the Java IRC LogBot.