Timestamps are in GMT/BST.
[1:45] * lheuer1 (~Adium@blfd-4db0fd40.pool.mediaWays.net) has joined #jython
[1:45] * lheuer (~Adium@blfd-4d083682.pool.mediaWays.net) Quit (Ping timeout: 244 seconds)
[1:52] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[1:52] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Client Quit)
[2:01] * juneau001 (~juneau@50-103-3-12.dklb.il.frontiernet.net) has joined #jython
[2:41] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) has joined #jython
[3:46] <sabi> fwierzbicki: you might consider the first line of your commit messages slightly more :)
[3:46] <sabi> http://hg.python.org/jython/graph/
[4:29] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[4:46] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Quit: fwierzbicki)
[4:55] * juneau001 (~juneau@50-103-3-12.dklb.il.frontiernet.net) Quit (Read error: Connection reset by peer)
[5:24] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) Quit (Ping timeout: 244 seconds)
[5:48] * lheuer1 is now known as lheuer
[6:50] * Oti (~ohumbel@adsl-84-227-92-215.adslplus.ch) Quit (Quit: Oti)
[8:01] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[9:34] * wmeissner (~wmeissner@ppp59-167-223-31.static.internode.on.net) has joined #jython
[9:37] <wmeissner> pjenvey: ping
[11:12] * juneau001 (~juneau@131.225.24.88) has joined #jython
[11:17] * seletz (~seletz@business-178-015-118-087.static.arcor-ip.net) has joined #jython
[12:49] * wainersm (~wainersm@189.61.204.85) has joined #jython
[13:25] * enebo (~enebo@75-168-81-196.mpls.qwest.net) has joined #jython
[14:13] * wmeissner (~wmeissner@ppp59-167-223-31.static.internode.on.net) Quit (Quit: wmeissner)
[14:15] * seletz (~seletz@business-178-015-118-087.static.arcor-ip.net) Quit (Quit: seletz)
[14:26] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) has joined #jython
[15:35] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[15:59] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) Quit (Ping timeout: 246 seconds)
[16:27] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) has joined #jython
[16:31] * shashank1 (~shashank@71-218-17-191.hlrn.qwest.net) Quit (Ping timeout: 240 seconds)
[16:37] * lheuer1 (~Adium@blfd-4db0fd40.pool.mediaWays.net) has joined #jython
[16:41] * lheuer (~Adium@blfd-4db0fd40.pool.mediaWays.net) Quit (Ping timeout: 246 seconds)
[17:11] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Max SendQ exceeded)
[17:12] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[18:37] <shashank> enebo, hi
[18:37] <enebo> shashank: hello
[18:38] <shashank> enebo, I saw your name on the jnr-all project
[18:38] <shashank> I recently encountered a bug in Chmod in jnr-posix
[18:38] <shashank> (I think it's a bug atleast)
[18:39] <shashank> chmod doesn't seem to return 0 when it's successful
[18:39] <enebo> shashank: ah that's strange
[18:39] <shashank> see: https://github.com/jnr/jnr-posix/blob/master/src/main/java/jnr/posix/util/Chmod.java#L53
[18:39] <shashank> enebo, so I thought it's a pretty easy fix and have a pull request here: https://github.com/jnr/jnr-posix/pull/8
[18:41] <enebo> shashank: yeah this looks like a but to me too and your fix looks correct
[18:41] <enebo> I will merge this. Weird though that it is not hitting all sorts of warning bells in our tests
[18:42] <enebo> This jnr-posix on master is still only in our current master dev tree in JRuby though
[18:42] <enebo> Perhaps we have some poor coverage
[18:42] <shashank> enebo, yeah it was quite freaky, I suspect there was an issue with the error propagating back up the layers
[18:43] <shashank> I only saw this quite recently in Jython
[18:43] <enebo> shashank: we do actually have quite a bit of red on our CI system which we are working through???this may be a regression we just have not gotten to
[18:43] <enebo> This a fairly new jnr-posix
[18:43] <enebo> err well new for us to be consuming on master
[18:43] <shashank> ah I see, ok I understand
[18:43] <shashank> anyway, thanks for merging it back up
[18:44] <enebo> It is over a year old without anyone using it because of our release schedule of JRuby itself
[18:44] <enebo> shashank: thanks for the fix
[18:44] <shashank> do you know if the jnr will see a release?
[18:44] <shashank> enebo, no problem
[18:44] <enebo> I think wmeissner did put one out but clearly we will need another
[18:44] <enebo> Plus I want to get better native exec support into it before mid may
[18:45] <enebo> So I would expect another release <1month
[18:45] <shashank> enebo, oh I see. sounds good. I'll probably start using the master for now
[18:45] <shashank> enebo, will report any issues if I come across them
[18:45] <enebo> shashank: yeah for sure???you already solved a bug by trying it :)
[19:07] * juneau001 (~juneau@131.225.24.88) Quit (Quit: Take care...)
[19:39] <pjenvey> shashank - ah, so it was jnr-posix. cool
[19:39] <shashank> pjenvey, yeah
[19:40] <shashank> maybe we should migrate our whole jruby.ext* to the jnr project so that we get those changes?
[19:42] <shashank> pjenvey, because I know fwierzbicki was saying that there was an issue with the jffi and asm4 as well
[19:46] <fwierzbicki> ah that's good to get a confirmation that we'll see new releases of jnr-posix - since we switched to ASM 4 we've become incompatible with the older jnr-posix - if you see goofy errors of the form "OSError: [Errno 20000] Unknown error: 20000:" it is likely because of this
[19:47] <fwierzbicki> basically a class changed to an interface and so we don't get any native posix at all on the default branch right now
[19:47] <fwierzbicki> A little poking turned this up:
[19:47] <fwierzbicki> java.lang.IncompatibleClassChangeError: Found class org.objectweb.asm.ClassVisitor, but interface was expected
[19:48] <fwierzbicki> which ultimately causes:
[19:48] <fwierzbicki> Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows.
[19:48] <pjenvey> shashank - sure. I didn't even realize the namespace changed
[19:49] <fwierzbicki> A silver lining: it's nice to see that so many tests pass on the Java impl
[19:50] <agronholm> fwierzbicki: is it okay if I give functools.partial and zipimport.zipimporter dicts? that is, want_dict: true, in the 2.5 branch
[19:50] <agronholm> they have dicts in cpython but not in jython
[19:50] <agronholm> partial(lambda: None).a = 1 fails on jython, works on cpython
[19:50] <fwierzbicki> agronholm: sounds right to me, better to match cpython
[19:50] <agronholm> k
[19:51] <shashank> fwierzbicki, also, is it ok if I change the jnr-* and jffi-* libs to the ones from the jnr project
[19:51] <shashank> fwierzbicki, this will first fix some of the Errno test cases you were talking about
[19:51] <shashank> and it'll be less pain to switch over to the jnr project after they release it
[19:52] <fwierzbicki> shashank, that would be great, we definitely need to do that
[19:52] <shashank> fwierzbicki, ok I'll take care of it
[19:52] <fwierzbicki> I chatted with wmeissner a couple of weeks ago - he suggested pulling right from jruby as there are platform builds that are otherwise hard to get
[19:53] <fwierzbicki> shashank: ^^^
[19:53] <fwierzbicki> I'm not sure if that's been corrected. enebo ^^^?
[19:53] <shashank> fwierzbicki, oh really, by platform builds you mean the jffi-XXX.jars right?
[19:54] <fwierzbicki> shashank: yeah I think so
[19:54] <shashank> mm, I see such jars in the jnr-jffi project too, but I guess they might be older builds
[19:55] <enebo> I am trying to build x86_64 right now with little luck :(
[19:55] <enebo> fwierzbicki, shashank: also look in lib/native of jruby repo
[19:55] <shashank> enebo, I see that there's a list of jars maintained at: https://github.com/jnr/jffi/tree/master/archive
[19:55] <enebo> you will see some generated lib for libjffi for each platform
[19:56] <shashank> ok I'll just pull from there then
[19:56] <fwierzbicki> enebo: is lib/native of jruby the best place?
[19:57] <enebo> fwierzbicki: That is something I don't know???but we do have them
[19:57] <enebo> fwierzbicki: wayne maybe has them somewhere else as well?
[19:57] <fwierzbicki> enebo: ok - I think wayne thought jruby was the best place to pull from - that was his suggestion when I asked a few weeks ago.
[19:58] <enebo> oh I see
[19:58] <enebo> sorry???the .jars do contain the files I am talking about
[19:58] <enebo> but it looks like 1.2 is only generated for some of those
[19:58] <enebo> which I think is indicated by the different update times
[19:59] <enebo> I was trying to debug something in our CI builds and JRuby won't load because our jffi for x86_64 has no 1.2 build
[19:59] <enebo> so I was trying to generate one
[19:59] <enebo> grrr :)
[19:59] <shashank> ah good then
[19:59] <fwierzbicki> good times :)
[20:00] <enebo> So we need to figure out some process for updating these things on big changes like 1.0 -> 1.2
[20:01] <agronholm> I guess simply turning want:_dict to True won't give the builtin classes dicts?
[20:01] <enebo> I am guessing this may be one of the last big API breaking releases personally since you can only do this stuff so many ways and it is painful to update 20 platforms
[20:03] <shashank> enebo, yeah I'd imagine the effort involved in maintaining with big changes to become very cumbersome!
[20:03] <enebo> shashank: yeah???mostly it is not a huge problem getting people to generate new binaries, but some platforms seem to be difficult like 64 bit windows
[20:03] <enebo> but getting 20 platforms built sucks
[20:04] <shashank> ah ok
[20:05] <agronholm> what does want_dict do in *.derived? I turned it on for partial.derived, yet it still does not have a __dict__
[20:15] <pjenvey> you have to rerun gderived.py partial.derived
[20:15] <pjenvey> it'll change the Derived file slightly to create a dict when its instantiated (iirc)
[20:16] <agronholm> oh right
[20:16] <agronholm> heck if I remember this stuff anymore :)
[20:18] <pjenvey> it looks like partial/zipimporter already have that turned on on default
[20:18] <pjenvey> maybe not 2.5
[20:18] <agronholm> not in 2.5
[20:23] <agronholm> well, partial subclasses have dicts now
[20:23] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Ping timeout: 246 seconds)
[20:23] <agronholm> but partial should not be slotted in the first place
[20:25] <agronholm> now I'm confused...
[20:25] <agronholm> partial instances have a __dict__ attribute, but it's still acting like a slotted type
[20:29] <pjenvey> oh
[20:29] <pjenvey> the derived change would only affect subclasses of partial
[20:29] <agronholm> I know
[20:29] <agronholm> and that works
[20:29] <agronholm> I'm now investigating why direct partial instances can't be assigned extra variables
[20:30] <pjenvey> it looks like the machinery is all there for it
[20:30] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[20:30] <agronholm> I'm looking at PyRandom.java, it has none of the getDict(), setDict() etc, yet it has a __dict__ and setting attributes works
[20:31] <pjenvey> i think partial has all of it because it's trying to initialize the dict lazily
[20:32] <agronholm> well PyRandom does not even have a __dict__ variable in the java class
[20:32] <agronholm> or the setters/getters for it
[20:32] <pjenvey> since most partial objects aren't assigned arbitrary attributes
[20:33] <pjenvey> oh
[20:34] <pjenvey> no
[20:34] <agronholm> I removed all of the __dict__ machinery from PyPartial.java, no effect
[20:34] <pjenvey> i can't remember the rules as to why random would auto get a dict
[20:34] <pjenvey> maybe it's because it has an __init__ method as opposed to a __new__? or something obscure
[20:34] <pjenvey> anyway the setDict stuff should actually be working w/ PyPartial
[20:34] <agronholm> ahm
[20:35] <agronholm> actually PyRandom was the implementation of _random.Random
[20:35] <agronholm> which does NOT take extra attributes
[20:36] <pjenvey> aaaah. yea, I was going to suggest that
[20:36] <pjenvey> but it's named 'random'
[20:37] <pjenvey> that's confusing, we map it to _random in Setup.java
[20:37] <pjenvey> o_O
[20:37] <agronholm> I'm having trouble finding a builtin class that actually takes extra variables
[20:37] <pjenvey> (that was my 'oh', 'no' earlier =] )
[20:39] <agronholm> can you think of any builtin class in jython that can be assigned attributes to?
[20:42] <pjenvey> yea i suspect it has to do with implementing __new__
[20:42] <pjenvey> PyModule has the exact same lazy dict scheme
[20:42] <pjenvey> but it has __init__
[20:43] <pjenvey> no the problem is PyPartial lacks fastGetDict
[20:46] <agronholm> do I need to do more than just compile to make a difference?
[20:46] <agronholm> I added fastGetDict() but the behavior didn't change
[20:47] <pjenvey> yea you need that and you nee dto overwrite setattr
[20:47] <pjenvey> look at PyBaseException, it's doing the right thing
[20:47] <pjenvey> this is all kind of goofy, in cpython, I think basically every object lazily creates its own dict
[20:48] <agronholm> ah, finally it works
[20:51] <pjenvey> i wonder if you even need want_dict for the deriveds now?
[20:51] <agronholm> let me see
[20:52] <pjenvey> looks like you wouldn't, according to BaseException.derived
[20:56] <agronholm> pjenvey: http://pastebin.com/i1ieNdyY
[20:56] <agronholm> this is with wants_dict: false
[21:01] <pjenvey> did you expose the setattr
[21:01] <agronholm> I copied it from PyBaseException verbatim
[21:01] <pjenvey> ok, weird. a BaseException subclass seems to let you do it, w/ want_dict = false
[21:02] <agronholm> well I have no clue why things work or don't...it's all magic to me :/
[21:03] <agronholm> but when I turn on wants_dict, it works
[21:03] <agronholm> ahhhh
[21:05] <agronholm> copied it verbatim...yes...shouldn't have done that
[21:12] <agronholm> pjenvey: ok now it works fine
[21:12] <pjenvey> agronholm - sweet
[21:13] <agronholm> why is it necessary to have both __setattr__() and partial__setattr__() there?
[21:17] <pjenvey> partial__setattr is the actual exposed method to python (which is why it's final, you would only override it by overwriting a type dict) whereas __setattr__ is the method accessible to Java code
[21:17] <pjenvey> which you could override in Java, for example
[21:18] <agronholm> should I write tests for these, and if so, where should I put them?
[21:19] <agronholm> this and zipimport that is
[21:19] <pjenvey> there's a test_zipimport_jy, maybe make a test_functools_jy
[21:44] <agronholm> I wonder if am also supposed to copy __findattr_ex__() from PyBaseException
[21:44] <agronholm> I don't know what that even does
[21:54] <fwierzbicki> agronholm: the doc strings in PyObject are pretty good on __findattr__ vs __findattr_ex__
[21:55] <fwierzbicki> agronholm: basically the ex one returns null and the normal one throws NoAttributeError
[21:55] <fwierzbicki> so you can avoid the exception cost if you want
[21:55] <agronholm> so should I copy the overridden ones from PyBaseException to PyPartial/zipimporter?
[21:56] <fwierzbicki> Let me look at PyBaseException...
[21:57] <fwierzbicki> pjenvey: do you remember why you overrode __findattr_ex__ the way you did in PyBaseException?
[21:58] <fwierzbicki> agronholm: just poking around it looks like some there might or might not be a __dict__ around for exceptions
[21:58] <fwierzbicki> s/some//
[21:59] <agronholm> not sure what you mean
[21:59] <fwierzbicki> oh oops I'm looking in the wrong place
[22:00] <fwierzbicki> oh no I'm not - there's a check in BaseException___findattr__ that checks for a dict and uses it, but then defers to super.__findattr_ex__ if not
[22:01] <fwierzbicki> I'd probably need to spend some time looking at BaseException to untangle this
[22:01] <pjenvey> I do not remember
[22:02] <agronholm> well, attribute assignment is working as expected (the two new tests pass) so I'm going to commit it w/o the __findattr_ex__
[22:02] <pjenvey> i dont think partial would need it..
[22:02] <pjenvey> agronholm - does the subclass work w/ want_dict = false or is that still broken?
[22:02] <agronholm> it works with want_dict=false
[22:02] <fwierzbicki> yeah it looks like BaseException is optimized in the case of having no attributes set if I'm reading right
[22:02] <pjenvey> oh ok
[22:02] <agronholm> I even found a bug that depends on this fix: http://bugs.jython.org/issue1730
[22:02] <pjenvey> I guess the answer is, don't copy findattr
[22:03] <agronholm> I'm just trying to get the zipimporter test working
[22:03] <agronholm> zipimporter wants a path to a real file
[22:04] <pjenvey> test_zipimporter is very much tailored to cpython
[22:05] <pjenvey> i never ported it to jython, unfortunately, it would take some effort
[22:06] <fwierzbicki> agronholm: does your fix kill the need for the patch on #1730?
[22:06] <agronholm> yes
[22:07] <agronholm> what the patch does is just add some slots to the class
[22:07] <agronholm> allowing __dict__ eliminates the need to add slots
[22:07] <fwierzbicki> agronholm: ah of course
[22:10] <agronholm> well, I have no clue how to safely test instantiation of zipimporter
[22:10] * wainersm (~wainersm@189.61.204.85) Quit (Quit: Ex-Chat)
[22:11] <agronholm> TemporaryFile won't do since zipimporter needs a path and TemporaryFile does not reveal its path
[22:11] <agronholm> mkstemp() won't do either because I need to write the header to it and I don't know how to make a real file of the descriptor it returns
[22:11] <pjenvey> theres NamedTempfile
[22:12] <agronholm> ah.
[22:12] <pjenvey> there might be an existing .zip bundle in test dir somewhere too?
[22:12] <pjenvey> just need a .zip, really
[22:12] <agronholm> there is but figuring out the correct path to it is kinda hard
[22:13] <pjenvey> try test_support.find_file
[22:24] * enebo (~enebo@75-168-81-196.mpls.qwest.net) Quit (Quit: enebo)
[22:28] <agronholm> doesn't look like it can actually find anything
[22:28] <agronholm> and if I'm in the dist directory it won't matter anyway
[22:43] <agronholm> ok, the fix is pushed now
[22:43] <agronholm> fwierzbicki: however, I cannot mark the relevant tracker issue as fixed
[22:55] <fwierzbicki> agronholm: let me give you permissions there
[22:55] <fwierzbicki> if I remember how :)
[23:00] * juneau001 (~juneau@50-103-3-12.dklb.il.frontiernet.net) has joined #jython
[23:00] <fwierzbicki> agronholm: ok you should be able to mark that bug as fixed now (I think)
[23:02] <agronholm> done
[23:04] <agronholm> fwierzbicki: do you use the transplant extension of mercurial?
[23:04] <fwierzbicki> agronholm: I haven't tried that yet no
[23:05] <agronholm> do you know what it does?
[23:05] <fwierzbicki> agronholm: I am not what you would call an advanced mercurial user
[23:05] <fwierzbicki> so short answer is no :)
[23:05] <agronholm> the transplant extension lets you cherry pick changesets from one branch to another
[23:05] <agronholm> w/o having to merge
[23:06] <fwierzbicki> ah cool - sorry about the annoying merges - I do now user "hg rebase" pretty well
[23:06] <fwierzbicki> I mean I now use rebase regularly
[23:06] <agronholm> yeah but I saw you doing a lot of merges due to fixing something in both 2.5 and 2.7
[23:06] <agronholm> that's why I wanted to mention this
[23:07] <fwierzbicki> agronholm: yeah - really it was more of a workflow mistake - what would have been better is if I would have put the fix in 2.5 and merged forward in default
[23:08] <fwierzbicki> instead of fixing in default and merging back to 2.5 which is akward - but I guess transplant cleans up some of that awkwardness
[23:08] <agronholm> yeah no merges necessary to either direction
[23:09] <fwierzbicki> oh huh - so you would do one check in to both branches?
[23:10] <agronholm> first commit to either branch
[23:10] <agronholm> switch to the other
[23:10] <agronholm> then transplant the changeset from the first branch
[23:10] <agronholm> it creates a new commit to the current branch with the appropriate message
[23:16] * sabi (~nriley@osric.zoiks.net) Quit (*.net *.split)
[23:17] * sabi (~nriley@osric.zoiks.net) has joined #jython
[23:23] <fwierzbicki> ah ok, cool, I'll definitely have a look at that
[23:49] <fwierzbicki> agronholm: so I have a mercurial patch from a contributor that applies nicely except for NEWS - once I fix "hg blame" puts my name next to all of the changes instead of his. Do you know a way around that so his name is attached to the blame lines?
[23:51] <fwierzbicki> ah I could just use "-u" to import -- so RTFM should work on this one :)
[23:52] <agronholm> are you talking about a patch or a changeset from another branch?
[23:52] <fwierzbicki> it is an "HG changeset patch"
[23:53] <agronholm> so how did you solve it?
[23:53] <fwierzbicki> I haven't yet - but I noticed that the hg import command has a "-u" switch so that I can give credit
[23:54] <fwierzbicki> I'm reading through the import command now to make sure I have it right - then I'll try to transplant this patch as it is a fix for both 2.5 and default
[23:54] <agronholm> you know, you can commit using another name too
[23:54] <agronholm> or does it commit automatically after you fix the NEWS?
[23:55] <fwierzbicki> oh right - that's actually what I'll really need to do
[23:55] <agronholm> hg commit -u <username>
[23:55] <fwierzbicki> no - there is no automatic commit
[23:55] <fwierzbicki> at least not that I have seen - so yeah the commit flag is what I need
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).