#jython IRC Log

Index

IRC Log for 2015-01-14

Timestamps are in GMT/BST.

[13:01] -asimov.freenode.net- *** Looking up your hostname...
[13:01] -asimov.freenode.net- *** Checking Ident
[13:01] -asimov.freenode.net- *** No Ident response
[13:01] -asimov.freenode.net- *** Couldn't look up your hostname
[13:01] * JythonLogBot (~PircBot@74.50.59.201) has joined #jython
[13:01] * Topic is 'Try Jython 2.7b3 at http://tinyurl.com/p2kmxod | This channel is logged: http://jython.extreme.st/irclogs/ | Please update the wiki: http://wiki.python.org/jython | Jython Book: http://jythonbook.com | Podcast: http://jython.org/jythonpodcast/'
[13:01] * Set by agronholm!~agronholm@2001:1bc8:102:6f29:ed9d:3487:3941:d41a on Fri Aug 22 22:40:30 UTC 2014
[13:02] * xemdetia (xemdetia@nat/ibm/x-oztgupeurtiikpzd) has joined #jython
[13:17] * xemdetia (xemdetia@nat/ibm/x-oztgupeurtiikpzd) Quit (Remote host closed the connection)
[13:23] * xemdetia (xemdetia@nat/ibm/x-ktaoinmjjknpyfyf) has joined #jython
[13:27] * wovenhead (~wovenhead@pool-108-44-90-115.ronkva.east.verizon.net) has joined #jython
[13:48] * wovenhead (~wovenhead@pool-108-44-90-115.ronkva.east.verizon.net) Quit (Remote host closed the connection)
[14:21] * dimm (504f468b@gateway/web/freenode/ip.80.79.70.139) has joined #jython
[14:24] * Paladiamors (~justin@pa9b391.tokynt01.ap.so-net.ne.jp) has joined #jython
[14:25] <dimm> hello, All
[14:25] <dimm> what it meant?
[14:25] <dimm> issueObject.setOriginalEstimate(customLaborCosts.getValue(issue)); TypeError: setOriginalEstimate(): 1st arg can't be coerced to java.lang.Long
[14:25] <dimm> is it meant that setOriginalEstimate must be filled with value with long data type?
[14:26] <agronholm> what type are you trying to pass to it?
[14:33] * wovenhead (~wovenhead@pool-108-44-90-115.ronkva.east.verizon.net) has joined #jython
[14:42] <dimm> agronholm: i try to copy value from customfield which called as Number in web interface
[14:43] <dimm> not called... one minute please
[14:43] <agronholm> just check the exact type of the argument
[14:44] <dimm> called "Number Field" - stores and validates floating point input
[14:44] <dimm> agronholm: how i can check it?
[14:44] <agronholm> either use the debugger, or if you don't know how, just print type(customLaborCosts.getValue(issue))
[14:45] * dimm choose second variant
[15:00] <dimm> agronholm: got it
[15:00] <dimm> agronholm: class org.python.core.PyFloat
[15:01] <dimm> agronholm: i just use log.info instead print
[15:01] <agronholm> ok, what if you do long(customLaborCosts.getValue(issue)) and pass that as argument to setOriginalEstimate?
[15:04] <dimm> was trying something like this before New Year... now will try once again your example
[15:06] <dimm> agronholm: something working =)
[15:06] <dimm> agronholm: but...
[15:07] <dimm> one minute please it seems like my mistake
[15:09] <dimm> agronholm: working like sharm, thank you very much
[15:09] <agronholm> *charm
[15:09] <agronholm> yw!
[15:09] <dimm> i was trying to_long (or something like it) before New Year
[15:09] <dimm> charm... ok thx for right
[15:44] <jimbaker> peke, agronholm, i now have ownership of github.com/jython
[15:45] <jimbaker> i will add both of you to the owners list
[15:50] <agronholm> what should with do with it?
[15:51] <agronholm> will this be the official repository then?
[15:52] <jimbaker> agronholm, we are going to try it out, based on the migration idea that peke discussed here earlier
[15:52] <jimbaker> but yes, if possible
[15:53] <jimbaker> hg.python.org/jython then becomes a mirror
[15:54] * Paladiamors (~justin@pa9b391.tokynt01.ap.so-net.ne.jp) Quit (Ping timeout: 252 seconds)
[16:04] <agronholm> "This organization has no repositories. Create one now."
[16:04] <jimbaker> agronholm, yeah, whenever we care to do so
[16:05] <jimbaker> peke plans to take the history and clean it up a bit, by stripping out jars
[16:05] <agronholm> sounds good
[16:06] <jimbaker> basically this will support 2.7.1 development and beyond
[16:06] <jimbaker> so our timeline should be, definitely complete by pycon
[16:36] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[17:34] * BillSussman (~botwin@179.178.100.53) has joined #jython
[17:44] <jimbaker> if anyone has ideas on making windows 8.1
[17:44] <jimbaker> on vmware easier to test against, i would appreciate it
[17:46] <jimbaker> it really does want to make sure i'm paying attention (return of clippy!). but i have simple needs. give me a terminal :)
[18:24] * BillSussman (~botwin@179.178.100.53) Quit (Quit: Leaving)
[18:38] <peke> jimbaker: I was actually thinking it would be better for someone who knows the code base better to take a look at cleaning up history.
[18:39] <peke> I could then investigate what it would require to merge issues from Roundup to GitHub.
[18:40] <peke> But I can look at history too after we've investigated mavenization.
[18:53] <jimbaker> peke, sounds cool. so 1) mavenization, including shadowing with it instead of jarjarlinks 2) issue migration to github 3) source migration
[18:54] <jimbaker> another thing to look at would be jar size reduction, although the main culprit, icu4j, will be difficult - most of it is data files, so that's harder to do i would think
[18:54] <jimbaker> (without really looking into icu4j, vs automated analysis)
[18:56] <jimbaker> peke, also please accept the invitation i sent you re github.com/jython
[19:01] <jimbaker> lastly, can i get anyone here interested in debugging this issue for the j9 variant of the jvm? http://bugs.jython.org/issue2084
[19:01] <jimbaker> in general, we need to try out j9
[19:06] <peke> jimbaker: accepted, thanks!
[19:07] <peke> I run Robot Framework's acceptance test on Jython 2.7b4. 3855 total, 3826 passed, 29 failed.
[19:10] <jimbaker> peke, i hope we are making good progress
[19:10] <jimbaker> process termination is probably one reason
[19:12] <peke> Just started analyzing failures. There are no failures with Jython 2.5, but there's a change that some tests are disabled with 2.5 and not anymore with 2.7.
[19:12] <jimbaker> got it. i expect a good bug report from you :)
[19:13] <peke> First failure was actually due to an enhancement to Jython. java.util.Map apparently nowadays implements Mapping.
[19:14] <jimbaker> yes, that's a potential breaking change
[19:14] <peke> Second one looks _really_ weird. I can reproduce it like this:
[19:14] <peke> jython -c "import sys; print sys.argv[1]" ???
[19:14] <peke> Exception in thread "main" java.lang.IllegalArgumentException: Cannot create PyString with non-byte value at org.python.core.PyString.<init>(PyString.java:62) at org.python.core.PyString.<init>(PyString.java:68) at org.python.core.PySystemState.initArgv(PySystemState.java:1133) at org.python.core.PySystemState.doInitialize(PySystemState.java:1052)
[19:15] <peke> at org.pythoncore.PySystemState.initialize(PySystemSttate.java:973) at org.python.core.PySystemState.initialize(PySystemState.java:929) at org.python.core.PySystemState.initialize(PySystemState.java:924) at org.python.util.jython.run(jython.java:235) at org.python.util.jython.main(jython.java:145)
[19:15] <peke> actually, just using "jython -c 'pass' ???" is enough.
[19:15] <peke> No exception w/ b3.
[19:16] <jimbaker> peke, but b3 was not stringent with str getting chars > 255
[19:16] <jimbaker> so likely the root cause here
[19:16] <peke> Sounds like that. Using e.g. ?? instead of ?????works fine.
[19:17] <peke> And ?? < 255 but ??? > 255
[19:17] <jimbaker> exactly
[19:17] <jimbaker> peke, from java.util import HashMap; HashMap()[42] now raises KeyError
[19:18] <jimbaker> so that might impact you with respect to java.util.Map being a Mapping
[19:18] <jimbaker> otherwise, we would be lying. this was a breaking change, so i made sure it was in the beta
[19:18] <jimbaker> on the other hand, it's a good breaking change
[19:19] <jimbaker> (in the past, it was treated the same as HashMap().get(42), which has the default of None
[19:19] <peke> jimbaker: I agree it's a good change and doubt it causes issues for us. The Mapping related failure was in unit test for a utility to verify is an object got from a user dict-like.
[19:20] <jimbaker> peke, i do know we are currently missing dictviews support
[19:20] <peke> Can you reproduce the problem with ?????on the cli? So far tested it only on Linux but can install b4 also on Windows.
[19:21] <jimbaker> that was overlooked, because it's a separate test in python, test_dictviews
[19:22] <jimbaker> peke, for jython27 -c 'pass' ???, I get Exception in thread "main" java.lang.IllegalArgumentException: Cannot create PyString with non-byte value
[19:22] <jimbaker> which is exactly what i would expect. we can readily fix
[19:22] <jimbaker> it's one more place where i expect java is providing us unicode, and we have to pass through accordingly
[19:23] <peke> Cool, I'll submit an issue about it then. Will it mean that sys.argv will be Unicode?
[19:25] <jimbaker> peke, i think so
[19:25] <jimbaker> i haven't looked at what python 3 does here
[19:25] <peke> That would be quite a big difference compared to CPython but ought to be acceptable.
[19:25] <jimbaker> so far, python 3 doing something the right way has been an acceptable excuse ;)
[19:25] <peke> Also consistent with os.environ changes.
[19:25] <jimbaker> exactly
[19:26] <jimbaker> our hand is rather forced
[19:26] <jimbaker> we might provide an option just in case
[19:26] <jimbaker> plus environment variable
[19:29] <jimbaker> in python 3, argv is unicode
[19:29] <jimbaker> peke, ^^^
[19:31] <jimbaker> fwierzbicki, looks like a good reason to redo beta 4, would prefer if this breaking change is in it
[19:31] <peke> jimbaker: I'm ok with sys.argv being Unicode.
[19:32] <jimbaker> peke, so what it will be if we follow the other changes: it will be bytes/str if char < 128, otherwise unicode
[19:32] <jimbaker> so that minimizes the appearance of the change
[19:33] <peke> If I remember correctly, sys.argv isn't exactly correct bytes in 2.5 either. I think we have some workaround code to handle sys.argv.
[19:33] <jimbaker> in general, the fact that str/unicode distinction is sloppy in 2.x means that it's not the big problem it would be in python3
[19:33] <jimbaker> peke, yeah, that would not surprise me one bit
[19:34] <jimbaker> although it does beg the question, what happens with something like six
[19:39] <fwierzbicki> jimbaker: ok - let me know when you are sure, I'll hold off on finalizing b4 until I hear otherwise.
[19:39] <jimbaker> fwierzbicki, should be done today. i guess i can try to fix ensurepip as well
[19:39] <jimbaker> so it works on windows as well
[19:43] <fwierzbicki> sounds good to me
[19:43] <jimbaker> hopefully just a one line fix
[19:44] <peke> Perhaps six can be enhaced to take it into account that sys.argv, os.environ, etc. is Unicode with Jython? Handling differences between different Python versions its main purpose anyway.
[19:45] <jimbaker> peke, ack, that sounds like a reasonable way to think about it
[19:46] <peke> Need to put kids to bed. Will be back analyzing results with test run on b4 a bit later. I try to go through all of them still tonight in order to see is there anything else that ought to be fixed in final b4.
[19:47] <jimbaker> peke, that would be great
[20:18] <peke> jimbaker: here's an issue about ???: http://bugs.jython.org/issue2252
[20:25] * zesus_ (zesus@peruna.fi) has joined #jython
[20:31] * rgb_byte (~3dprint@209.77.221.1) has joined #jython
[20:32] <rgb_byte> does jython work with haiku-vm?
[20:33] <jimbaker> rgb_byte, i would think jython 2.7 would be too large
[20:33] <jimbaker> could look at 2.1 which is much smaller
[20:33] <jimbaker> and is also "pure java"
[20:34] <jimbaker> 2.2 might also work
[20:34] <rgb_byte> that is what I was thinking... as I understand it jython "compiles" to java byte code right?
[20:34] <jimbaker> rgb_byte, i got to run, but please write here, i will respond here when i get back
[20:35] <rgb_byte> any idea when that is (time and timezone)?
[20:56] <rgb_byte> so I don't want to run the full jython implementation on the vm, I just want to be able to compile to java bytecode and run it on the vm. I would be able to do that right?
[20:56] * rgb_byte (~3dprint@209.77.221.1) has left #jython
[21:05] <peke> jimbaker: one more bug analyzed. this occurs also with b3: http://bugs.jython.org/issue2253
[21:05] <peke> Not major but definitely annoying to have such noise on console.
[21:22] <peke> jimbaker: Apparently java.util.Map string representation has changed too. It used to be like {foo=bar} and is {foo: bar} nowadays. Should it also have quotes like dict str has?
[21:38] * mbooth (~mbooth@redhat/mbooth) Quit (Ping timeout: 244 seconds)
[21:45] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 255 seconds)
[21:49] * Paladiamors (~justin@pa9b391.tokynt01.ap.so-net.ne.jp) has joined #jython
[21:53] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[21:53] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[21:53] * mbooth (~mbooth@redhat/mbooth) has joined #jython
[21:59] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[21:59] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[21:59] * mbooth_ (~mbooth@redhat/mbooth) has joined #jython
[22:01] * mbooth (~mbooth@redhat/mbooth) Quit (Disconnected by services)
[22:01] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[22:01] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[22:01] * mbooth (~mbooth@redhat/mbooth) has joined #jython
[22:02] * mbooth_ (~mbooth@redhat/mbooth) Quit (Client Quit)
[22:02] * mbooth (~mbooth@redhat/mbooth) Quit (Read error: Connection reset by peer)
[22:03] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[22:03] * mbooth (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[22:03] * mbooth (~mbooth@redhat/mbooth) has joined #jython
[22:05] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[22:05] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[22:05] * mbooth_ (~mbooth@redhat/mbooth) has joined #jython
[22:05] * mbooth (~mbooth@redhat/mbooth) Quit (Client Quit)
[22:05] * mbooth_ (~mbooth@redhat/mbooth) Quit (Read error: Connection reset by peer)
[22:10] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[22:10] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[22:10] * mbooth_ (~mbooth@redhat/mbooth) has joined #jython
[22:27] * mbooth_ (~mbooth@redhat/mbooth) Quit (Ping timeout: 244 seconds)
[22:35] * Paladiamors (~justin@pa9b391.tokynt01.ap.so-net.ne.jp) Quit (Ping timeout: 240 seconds)
[22:40] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) has joined #jython
[22:40] * mbooth_ (~mbooth@cpc11-shef10-2-0-cust659.barn.cable.virginm.net) Quit (Changing host)
[22:40] * mbooth_ (~mbooth@redhat/mbooth) has joined #jython
[22:58] <jimbaker> peke, i thought about changing the repr of Map so that it would use python instead of toString()
[22:59] <jimbaker> for a later release, i suppose it would be backwards breaking but that seems pushing things a bit
[22:59] <jimbaker> peke, re socket logging, i can take a look at that. it used to be worse
[23:01] <jimbaker> rgb_byte, in case you look at the log - that's not really going to work with jython. the elephant so to speak is the jython runtime
[23:22] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[23:28] <peke> jimbaker: does os.kill work reliably nowadays?
[23:29] <peke> If yes, shouldn't that and Popen.pid mean that fixing Popen.send_signal ought to be easy?
[23:30] <jimbaker> peke, it should work just fine, since it uses signals
[23:30] <jimbaker> (unless one is apparently using the J9 jvm)
[23:31] <peke> Ok. I assume these could be considered for rc1 then? http://bugs.jython.org/issue2219 http://bugs.jython.org/issue2220
[23:32] <jimbaker> re Popen.send_signal, i would have to look more closely - there's too much conditional function definition in subprocess
[23:33] <jimbaker> peke, yes, that was my assumption re those bugs
[23:33] <jimbaker> don't forget to keep asking however
[23:33] <jimbaker> :)
[23:33] <jimbaker> i'm currently juggling a bit too much...
[23:34] * rgb_byte (~Ethan_Smi@76.126.150.235) has joined #jython
[23:35] <jimbaker> i now have no memory of commenting on some bugs, but that's what happen after massive triages
[23:35] <jimbaker> rgb_byte, responded, check the log
[23:37] <peke> jimbaker: re send_signal, I would assume that the standard POSIX implementation `os.kill(self.pid, sig)` ought to work outside Windows with Jython too nowadays.
[23:38] <jimbaker> peke, as usual - if you have a patch, with a test (test_subprocess_jy.py), that can get in much faster
[23:38] <jimbaker> peke, it assumes sun.misc.unsafe
[23:38] <jimbaker> the right way to support is to use support in Process, then try signal if it cannot use the pid
[23:40] <peke> jimbaker: Sure. I'll take a look at implementing this but not today. Shouldn't be too complicated, although I'm not sure can we actually support signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT on Windows.
[23:40] <jimbaker> so we should check for java 8 support, eg hasattr(process, "destroyForcibly")
[23:41] <jimbaker> yeah, that seems very nonportable without going into C
[23:41] * rgb_byte (~Ethan_Smi@76.126.150.235) has left #jython
[23:41] <peke> Yeah, I just reread your commment about destroyForcibly in #2220. Definitely should use it with Popen.kill when available.
[23:42] <jimbaker> peke, cool - i think it sketches out what needs to need be done here, it would be great if you can take it on. then guaranteed to get in! :)
[23:44] * rgb_byte (~Ethan_Smi@76.126.150.235) has joined #jython
[23:44] <peke> It might actually be possible to send CTRL_C/BREAK_EVENT using ctypes. I'm not going to worry too much if that doesn't work out, though.
[23:44] * rgb_byte (~Ethan_Smi@76.126.150.235) has left #jython
[23:50] * xemdetia (xemdetia@nat/ibm/x-ktaoinmjjknpyfyf) Quit (Ping timeout: 244 seconds)

Index

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