jython-bugs — Private bug notification list. Do not post to this list.

[Jython-bugs] [issue2602] NumberFormatException in terminal on OSX 10.12.5 (ncurses related)

[Stefan R. <re...@bu...>]

New submission from Stefan Richthofer:

I was pointed to this issue in JyNI context, but it seems to be JyNI-unrelated.
On OSX macOS Sierra 10.12.5 / Oracle Java 1.8.0_131 / Jython 2.7.1 RC2/RC3/Final, using the terminal:

[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at org.python.jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at org.python.jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
at org.python.jline.UnixTerminal.<init>(UnixTerminal.java:65)
at org.python.jline.UnixTerminal.<init>(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.python.jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at org.python.jline.TerminalFactory.create(TerminalFactory.java:102)
at org.python.jline.TerminalFactory.get(TerminalFactory.java:186)
at org.python.jline.TerminalFactory.get(TerminalFactory.java:192)
at org.python.jline.console.ConsoleReader.<init>(ConsoleReader.java:243)
at org.python.util.JLineConsole.install(JLineConsole.java:107)
at org.python.core.Py.installConsole(Py.java:1745)
at org.python.core.PySystemState.initConsole(PySystemState.java:1269)
at org.python.core.PySystemState.doInitialize(PySystemState.java:1119)
at org.python.core.PySystemState.initialize(PySystemState.java:1033)
at org.python.core.PySystemState.initialize(PySystemState.java:989)
at org.python.core.PySystemState.initialize(PySystemState.java:984)
at org.python.util.jython.run(jython.java:263)
at org.python.util.jython.main(jython.java:142)

(Not showing up in xcode IDE.)


The issue is known in different context:
https://stackoverflow.com/a/44329833

A suggested workaround is to set the environment variable TERM to a dfifferent value than "xterm-256color".
(Apparrently, newer ncurses displays 256 as 0x100 for better readability.)

This is said to be fixed in recent JLine2. So maybe another update of JLine2 can solve this issue in Jython.

----------
messages: 11457
milestone: Jython 2.7.2
nosy: stefan.richthofer, zyasoft
priority: normal
severity: normal
status: open
title: NumberFormatException in terminal on OSX 10.12.5 (ncurses related)
type: behaviour

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2602>
_______________________________________

[Jython-bugs] [issue2601] increased tax on goods

[Dietrich S. <re...@bu...>]

New submission from Dietrich Schulten:

Dear, 

I've  found an article where it's written about increasing tax  on goods and services, you may find more information  here http://bit.do/dxS24

My Best, ds

Sent from Mail for Windows 10

----------
files: 2B295E6A6536D5B12E1FD387A0367A39.jpg, unnamed
messages: 11451
nosy: dschulten
severity: normal
status: open
title: increased tax on goods
Added file: http://bugs.jython.org/file1590/unnamed
Added file: http://bugs.jython.org/file1591/2B295E6A6536D5B12E1FD387A0367A39.jpg

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2601>
_______________________________________

[Jython-bugs] [issue2600] subprocess doesn't have _args_from_interpreter_flags (blocks support for multiprocessing)

[Stefan R. <re...@bu...>]

New submission from Stefan Richthofer:

I stumbled upon this blogpost (http://forum.imagej.net/t/jupyter-notebook-for-imagej/5421/16) that points out missing support for multiprocessing. After some investigation (one has to add '/usr/lib/python2.7/lib-dynload' and '/usr/lib/python2.7' to sys.path), I found that Jython+JyNI is actually capable of importing CPython's _multiprocessing.so.
However, "import multiprocessing" fails with
ImportError: cannot import name _args_from_interpreter_flags

I have not looked what it takes to implement it in Jython yet.

----------
messages: 11450
milestone: Jython 2.7.2
nosy: stefan.richthofer, zyasoft
priority: normal
severity: normal
status: open
title: subprocess doesn't have _args_from_interpreter_flags (blocks support for multiprocessing)
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2600>
_______________________________________

[Jython-bugs] [issue2599] Cannot handle network paths under Windows

[Tobias <re...@bu...>]

New submission from Tobias:

When Jython 2.7.1-rc2 is executed from a network location under Windows, it fails to access any file from within the jar itself.

Reproducing the error with "Jython-standalone-2.7.1-rc2" is a little bit tricky. If we just open a command line and execute Jython, Windows automatically assigns a drive letter to the network location and Jython works just fine. The problem occurs, however, if we use "PowerShell" and carefully avoid assigning a letter to the network path.

Using standard java to start Jython results in the following output:
#############################################################################
$> java -jar jython-standalone-2.7.1-rc2.jar
*sys-package-mgr*: can't create package cache dir, '\\MY-PC\Shared\Jython\MY-PC\Shared\Jython\cachedir\packages'
Exception in thread "main" ImportError: Cannot import site module and its dependencies: No module named site
Determine if the following attributes are correct:
  *sys.path: [\\\\MY-PC\\Shared\\Jython\\MY-PC\\Shared\\Jython\\Lib,__classpath__, __pyclasspath__/]
   This attribute might be including the wrong directories, such as from CPython
  *sys.prefix: \\\\MY-PC\\Shared\\Jython\\MY-PC\\Shared\\Jython
   This attribute is set by the system property python.home, although it can
   be often automatically determined by the location of the Jython jar file
   
You can use the -S option or python.import.site=false to not import the site module
#############################################################################

So, we try the -S option, yielding the following scenario. At first, everything seems fine, but then, the "random"-random cannot be found.
#############################################################################$> java -jar jython-standalone-2.7.1-rc2.jar -S
*sys-package-mgr*: can't create package cache dir, '\\MY-PC\Shared\Jython\MY-PC\Shared\Jython\cachedir\packages'
Jython 2.7.1rc2 (default:f66327aa5de9, May 29 2017, 17:56:49)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_131
>>> from random import randint
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named random
#############################################################################

Note how the path to jython.jar is obviously doubled:
\\\\MY-PC\\Shared\\Jython\\MY-PC\\Shared\\Jython
It seems that the path "MY-PC/Shared/Jython" lacks the proper reference to the "root", resulting in Java interpreting the path relative to the current directory instead.

The problem did not occur with Jython 2.7.0

----------
components: Core
messages: 11447
milestone: Jython 2.7.1
nosy: tkohn
severity: major
status: open
title: Cannot handle network paths under Windows
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2599>
_______________________________________

[Jython-bugs] [issue2598] Parsing of `from . import something` is incorrect

[Julien E. <re...@bu...>]

New submission from Julien Enselme:

Hi,

I am a member of the NbPython team (http://nbpython.org/). We develop the python plugin for Netbeans IDE and bundle Jython in our plugin.

We rely on jython to parse import statements. We found out that the result of org.python.ast.alias.getInternalName (https://github.com/jythontools/jython/blob/master/src/org/python/antlr/ast/alias.java#L24) is wrong in some cases. If we parse statement like `from . import toto`, the method returns an empty string instead of `.`. This causes our code formating capabilities to fail. Tested with jython 2.7.0 and 2.7.1rc2.

----------
messages: 11433
nosy: jenselme
severity: normal
status: open
title: Parsing of `from . import something` is incorrect
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2598>
_______________________________________

[Jython-bugs] [issue2597] Possible memory leak in Jython 2.7.1 RC2

[tobias <re...@bu...>]

New submission from tobias:

I rechecked the problem encountered in an earlier Jython version (2.5.2) which was a memory leak described in this bug report: http://bugs.jython.org/issue2026 . The bug is marked as fixed and I wanted to double check this. Therefore, I used the code snipped contained in the bug report to reconstruct the issue. The original issue seems to be resolved, but I encountered another problem. If I run the aforementioned code for a short period of time, the consumed heap increases quite fast: ~120MB after ~60 seconds. I inspected the heap dump and most the memory is consumed by a ConcurrentHashMap in PySystemState. I took a quick peek at the source and found this:

PySystemState has a static final ConcurrentHashMap named sysClosers [0]. If a new PySystemStateCloser is created, a Key-Value-Pair of a WeakReference to a PySystemState and a reference to the PySystemStateCloser is added to the map [1], but never removed. Even if the WeakReference is finalized, if looks like the value will still remain in the map, since there is no removal code for broken references.

----------
components: Core
messages: 11416
milestone: Jython 2.7.1
nosy: tobias
severity: normal
status: open
title: Possible memory leak in Jython 2.7.1 RC2
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2597>
_______________________________________

[Jython-bugs] [issue2596] Linebreaks in exceptions are wrong

[Tobias <re...@bu...>]

New submission from Tobias:

If an exception's message contains linebreaks, they are output as "\n" instead of true linebreaks. This differs from how Python 2.7 behaves and breaks some of our error messages (i.e. makes them much less readable).

Example:
raise Exception("Hello\nWorld")

Expected Output:
Exception: Hello
World

Actual Output:
Exception: Hello\nWorld

I found the problem in Jython 2.7.1-rc2.

As far as I can tell, the cause for this behaviour is to be found in the method "asMessageString()" inside "Py.java" (line 1509).

----------
components: Core
messages: 11413
milestone: Jython 2.7.1
nosy: tkohn
severity: normal
status: open
title: Linebreaks in exceptions are wrong
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2596>
_______________________________________

[Jython-bugs] PCB PCBA One-Stop Service Factory

[luck P. S. <ad...@pc...>]

Dear  Sir 
We're Fr4 PCB .Flexible PCB, Aluminum PCB   Supplier in china,
High Quality, Great Prices, Flexible Scheduling, 
With Outstanding Service.

We also offer PCBA work too ,No MOQ require,
1 pcs also can do only customer need it

If  you're interesting in PCB or PCBA.
Please Let us know.

Regards

----

Luck  PCB PCBA Sales

Skype:Luck PCB

[Jython-bugs] [issue2595] os.path.isdir does not recognize symlinks in zOS

[David A. <re...@bu...>]

Changes by David Alexander <dav...@ib...>:


----------
components: Library
milestone: Jython 2.7.0
nosy: trickyturtle
severity: normal
status: open
title: os.path.isdir does not recognize symlinks in zOS
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2595>
_______________________________________

[Jython-bugs] [issue2594] test_ssl failure in Jython (only) after standard installation

[Jeff A. <re...@bu...>]

New submission from Jeff Allen:

I'm see this failure in test_ssl, but only when running from an installed Jython. I do not reproduce it in the development environment.

Did we forget to pack something?


======================================================================
ERROR: test_load_cert_chain (__main__.ContextTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\test\test_ssl.py", line 820, in test_load_cert_chain
    ctx.load_cert_chain(CERTFILE_PROTECTED, password=KEY_PASSWORD)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\ssl.py", line 1128, in load_cert_chain
    self._key_managers = _get_openssl_key_manager(certfile, keyfile, password, _key_store=self._key_store)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\ssl.py", line 1128, in load_cert_chain
    self._key_managers = _get_openssl_key_manager(certfile, keyfile, password, _key_store=self._key_store)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\_sslcerts.py", line 121, in _get_openssl_key_manager
    _certs, _private_key = _extract_certs_for_paths([cert_file], password)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\_sslcerts.py", line 218, in _extract_certs_for_paths
    _certs, _private_key = _extract_cert_from_data(f, password, key_converter, cert_converter)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\_sslcerts.py", line 237, in _extract_cert_from_data
    certs, private_key = _read_pem_cert_from_data(f, password, key_converter, cert_converter)
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\_sslcerts.py", line 273, in _read_pem_cert_from_data
    key_pair = key_converter.getKeyPair(obj.decryptKeyPair(provider))
  File "C:\Users\Jeff\Documents\Jython\ldrtest\Lib\_sslcerts.py", line 273, in _read_pem_cert_from_data
    key_pair = key_converter.getKeyPair(obj.decryptKeyPair(provider))
PEMException: org.python.bouncycastle.openssl.PEMException: Unable to create OpenSSL PBDKF: PBKDF-OpenSSL SecretKeyFactory not available

----------
components: Library
keywords: test failure causes
messages: 11398
nosy: jeff.allen
severity: normal
status: open
title: test_ssl failure in Jython (only) after standard installation
type: crash
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2594>
_______________________________________

[Jython-bugs] [issue2593] writing a buffer (instead of str) fails with NullPointerException instead of TypeError

[topi k. <re...@bu...>]

Changes by topi kanerva <tka...@gm...>:


----------
components: Core
files: write_file_w_list.py
nosy: tkanerva
severity: minor
status: open
title: writing a buffer (instead of str) fails with NullPointerException instead of TypeError
type: behaviour
versions: Jython 2.7
Added file: http://bugs.jython.org/file1586/write_file_w_list.py

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2593>
_______________________________________

[Jython-bugs] [issue2592] sys.cleanup() in PythonInterpreter close() method closing thread pool _socket.NIO_GROUP in _socket.py

[Parisa <re...@bu...>]

New submission from Parisa:

sys.cleanup() in org.python.util.PythonInterpreter.close() method closing thread pool _socket.NIO_GROUP in _socket.py

Is thread pool needs to be recreated create_connection() function in _socket.py if it is shutdown?
or Can we use org.python.util.PythonInterpreter instance without closing ? repeatedly shared across multiple threads?

Please suggest...

Thank you.

----------
components: Core
messages: 11374
milestone: Jython 2.7.1
nosy: psterdale
severity: major
status: open
title: sys.cleanup() in PythonInterpreter close() method closing thread pool _socket.NIO_GROUP in _socket.py
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2592>
_______________________________________

[Jython-bugs] [issue2591] Unable to execute directory or zip file (test_cmd_line_script)

[Jeff A. <re...@bu...>]

New submission from Jeff Allen:

Parking to revisit later. Working on failures of un-skipped tests in test_cmd_line_script (when we have non-ascii paths) I noticed these skips, that with my new-found familiarity with runpy look tractable.

The logic in org.python.util.jython.runMainFromImporter() should presumably agree with runpy._run_module_as_main(). Alternatively, could we just use runpy as in jython.runModule()?


We've noted these as skips in #1861 but no other  issue I can find.

----------
components: Library
keywords: test failure causes
messages: 11366
nosy: jeff.allen
priority: normal
severity: normal
status: open
title: Unable to execute directory or zip file (test_cmd_line_script)
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2591>
_______________________________________

[Jython-bugs] [issue2590] 'org.python.core.io.StreamIO' object has no attribute '_register_selector'

[Bjarke B. B. <re...@bu...>]

Changes by Bjarke B. Blendstrup <bj...@bi...>:


----------
components: Any
files: rc.log
nosy: BjarkeBB
severity: normal
status: open
title: 'org.python.core.io.StreamIO' object has no attribute '_register_selector'
type: behaviour
versions: Jython 2.7
Added file: http://bugs.jython.org/file1582/rc.log

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2590>
_______________________________________

[Jython-bugs] [issue2589] Two copies of jansi DLL created per invocation of Jython

[Jeff A. <re...@bu...>]

New submission from Jeff Allen:

Noted in passing on Windows, the jansi DLL that is necessary to support the JLine console is extracted twice from the JLine JAR every time I run Jython. Doing it twice appears to be a bug in org.fusesource.hawtjni.runtime.Library, which cannot find the file it extracted earlier when loading a class.

Files extracted from a URL are given (by Java) a randomly-generated name component, so the DLL ends up as "jansi-64-2636578793605407255.dll", or some such, and go into the temporary directory.

However, WIBNI JLine (and jnr-posix for that matter) found the necessary dependencies, instead of regenarating them?

----------
components: Core
messages: 11358
nosy: jeff.allen
severity: minor
status: open
title: Two copies of jansi DLL created per invocation of Jython
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2589>
_______________________________________

[Jython-bugs] [issue2588] test_io failure in concurrent access to a buffered file

[Jeff A. <re...@bu...>]

New submission from Jeff Allen:

A couple of tests in test_io have started failing for me. This is the case since I localised my PC to Chinese, but encoding seems to have nothing to do with the failure.

The test opens one file and creates 20 threads that compete to write in it. There is no explicit synchronisation. The test fails if, at the end, the file does not contain exactly one message from each thread. Comments reference: http://bugs.python.org/issue6750 . Obviously, this is asking for trouble ;)

If I reduce the number of threads below about 10 it passes, so maybe it only ever passed because something was faster, slower or "stickier" than now, effectively serialising access.

The problem arises in CPython because writing releases the GIL in the middle of managing the buffered data. CPython's solution relies on dancing around the moment when the GIL is given up. In the tracker, this appears to be the triumph of pragmatism over purism. The first answer was that it was "not designed to be thread-safe at all".

Of course, we don't have a GIL in Jython, hence I'm actually wondering how this test ever passed, and whether we should expect it to. I'm going to insert a skip for now, referring to this issue.

I'm seeing this in the trunk repository (alongside the errors that *are* to do with encoding):

======================================================================
FAIL: test_threads_write (__main__.CTextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeff\Documents\Eclipse\jython-trunk\dist\Lib\test\test_io.py", line 2460, in test_threads_write
    self.assertEqual(content.count("Thread%03d\n" % n), 1)
AssertionError: 0 != 1

======================================================================
FAIL: test_threads_write (__main__.PyTextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeff\Documents\Eclipse\jython-trunk\dist\Lib\test\test_io.py", line 2460, in test_threads_write
    self.assertEqual(content.count("Thread%03d\n" % n), 1)
AssertionError: 0 != 1

----------------------------------------------------------------------

In my fork, when I've dealt with the encoding problems, I still have these threading failures.

----------
components: Library
keywords: test failure causes
messages: 11357
nosy: jeff.allen
severity: normal
status: open
title: test_io failure in concurrent access to a buffered file
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2588>
_______________________________________

[Jython-bugs] [issue2587] tests failures on Linux due to file permissions on NTFS partition

[Stefan R. <re...@bu...>]

New submission from Stefan Richthofer:

My usual development workspace on Linux (Mint 18 Cinnamon-64Bit) is hosted on an NTFS partition for better interoperability with Windows.
I observe test_dumbdbm and test_shutil to fail in this settings, while both pass if I move dist-folder to an ext4-partition. test_mailbox also suffers from this, but also fails for me on ext4 with less failures though. On Windows I don't observe any of these failures, but maybe they are just skipped (didn't yet check).

Outputs on NTFS are as follows:

test_dumbdbm:
======================================================================
FAIL: test_dumbdbm_creation_mode (__main__.DumbDBMTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_dumbdbm.py", line 67, in test_dumbdbm_creation_mode
    self.assertEqual(stat.S_IMODE(st.st_mode), expected_mode)
AssertionError: 511 != 413

----------------------------------------------------------------------
Ran 9 tests in 0.923s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_dumbdbm.py", line 190, in <module>
    test_main()
  File "Lib/test/test_dumbdbm.py", line 185, in test_main
    test_support.run_unittest(DumbDBMTestCase)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1330, in run_unittest
    _run_suite(suite)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1313, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_dumbdbm.py", line 67, in test_dumbdbm_creation_mode
    self.assertEqual(stat.S_IMODE(st.st_mode), expected_mode)
AssertionError: 511 != 413




test_shutil:
======================================================================
FAIL: test_on_error (__main__.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_shutil.py", line 101, in test_on_error
    self.assertEqual(self.errorState, 2,
AssertionError: Expected call to onerror function did not happen.

----------------------------------------------------------------------
Ran 31 tests in 0.525s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_shutil.py", line 816, in <module>
    test_main()
  File "Lib/test/test_shutil.py", line 813, in test_main
    test_support.run_unittest(TestShutil, TestMove, TestCopyFile)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1330, in run_unittest
    _run_suite(suite)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1313, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_shutil.py", line 101, in test_on_error
    self.assertEqual(self.errorState, 2,
AssertionError: Expected call to onerror function did not happen.



For test_mailbox see #2586.

----------
messages: 11354
nosy: stefan.richthofer
priority: normal
severity: normal
status: open
title: tests failures on Linux  due to file permissions on NTFS partition
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2587>
_______________________________________

[Jython-bugs] [issue2586] test_mailbox fails on Linux

[Stefan R. <re...@bu...>]

New submission from Stefan Richthofer:

On Linux Mint 64Bit, Java 8 I observe test_mailbox to fail. Note that it doesn't fail on Windows (or is skipped there, I currently cannot tell).
Also note that in discussion of #2585 I learned that this failure isn't commonly visible.

======================================================================
FAIL: test_file_permissions (__main__.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 787, in test_file_permissions
    self.assertEqual(mode & 0111, 0)
AssertionError: 73 != 0

======================================================================
FAIL: test_folder_file_perms (__main__.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 804, in test_folder_file_perms
    self.assertFalse((perms & 0111)) # Execute bits should all be off.
AssertionError: 73 is not false

======================================================================
FAIL: test_file_perms (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 1011, in test_file_perms
    self.assertFalse((perms & 0111)) # Execute bits should all be off.
AssertionError: 73 is not false

======================================================================
FAIL: test_mboxmmdf_to_maildir (__main__.TestMessageConversion)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 1580, in test_mboxmmdf_to_maildir
    self.assertEqual(msg.get_date(), 0.0)
AssertionError: 1493984035.955 != 0.0

----------------------------------------------------------------------
Ran 303 tests in 8.456s

FAILED (failures=4, skipped=2)
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 2122, in <module>
    test_main()
  File "Lib/test/test_mailbox.py", line 2117, in test_main
    test_support.run_unittest(*tests)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1330, in run_unittest
    _run_suite(suite)
  File "/data/workspace/linux/Jython/ssh/jython/dist/Lib/test/test_support.py", line 1313, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred


Seeing the file permission related failures it occurred to me that my workspace folder is on an NTFS partition so I can easily access it from Windows. NTFS has less fine grained file permission handling, so I tried the test on an ext4 partition. There it still fails, but yields fewer failures:

======================================================================
FAIL: test_mboxmmdf_to_maildir (__main__.TestMessageConversion)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 1580, in test_mboxmmdf_to_maildir
    self.assertEqual(msg.get_date(), 0.0)
AssertionError: 1493984654.341 != 0.0

----------------------------------------------------------------------
Ran 303 tests in 5.819s

FAILED (failures=1, skipped=2)
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 2122, in <module>
    test_main()
  File "Lib/test/test_mailbox.py", line 2117, in test_main
    test_support.run_unittest(*tests)
  File "/home/stefan/Jython/jython/dist/Lib/test/test_support.py", line 1330, in run_unittest
    _run_suite(suite)
  File "/home/stefan/Jython/jython/dist/Lib/test/test_support.py", line 1313, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 1580, in test_mboxmmdf_to_maildir
    self.assertEqual(msg.get_date(), 0.0)
AssertionError: 1493984654.341 != 0.0


Still - the test shouldn't fail because of running on an NTFS partition. If NTFS inherently yields insufficient permission handling for some tests, these should detect it somehow and be skipped or so.

----------
messages: 11353
nosy: stefan.richthofer
priority: normal
severity: normal
status: open
title: test_mailbox fails on Linux
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2586>
_______________________________________

[Jython-bugs] [issue2585] test_ssl failure on linux

[James M. <re...@bu...>]

New submission from James Mudd:

Running test_ssl as part of the regrtests or individually on linux I see the following failure:

FAIL: test_connect_ex_error (test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/james/git/jython/Lib/test/test_ssl.py", line 1343, in test_connect_ex_error
    self.assertIn(rc, errors)
AssertionError: -1 not found in (111, 113, 110, 11)

I believe the cause is the handling of netty exceptions

----------
messages: 11344
nosy: jamesmudd
severity: normal
status: open
title: test_ssl failure on linux

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2585>
_______________________________________

[Jython-bugs] [issue2584] netty threads not terminated during regrtest

[James M. <re...@bu...>]

New submission from James Mudd:

If you run the regression tests and watch the threads using the debugger, you can see that many tests leave netty threads running after that test should have been teared down. There seems to be lots of these >50.

These threads are named Jython-Netty-Child-XXX where I think XXX is just a counter.

To see this I am running 'java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=1045 -jar jython.jar Lib/test/regrtest.py' and then connecting using Eclipse remote debugger.

I don't think this is actually causing any issues but its not very nice that tests leave stuff behind. I wonder if this is related to the errors seen during netty finalization issue #2517

----------
components: Core
messages: 11336
nosy: jamesmudd
severity: minor
status: open
title: netty threads not terminated during regrtest
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2584>
_______________________________________

[Jython-bugs] [issue2583] ❤Re: just take a look at that

[Dietrich S. <re...@bu...>]

New submission from Dietrich Schulten:

Hey, 

I've  never seen something like that before, it's fantastic!  You should take a  look  http://www.fasterdelivery.net/case.php?9c9d

Rushing, ds

From: Jython tracker [mailto:re...@bu...]
Sent: Friday, April 28, 2017 12:48 AM
To: ds...@es...
Subject: B1G B1G B1G

Honestly  after  Negredo went out on loan after all the  stuff around the stadium  about  him, with my "unleash the  beast" shirt,  hell  he was December 2014 on my calendar... I just  ripped up  my season  ticket, burnt  my  shirts and demanded a refund...
Wait...  No I didn't  because  one  man does not a club make. I mean that's a shitty  message to send out  to the rest  of  the players. "ONE GUY'S NOT HERE SO WE WANT A REFUND!!"  Like what? Really?  Great morale boost  guys. "We didn't bring this on the team,  the management did."  No, you  did. By cancelling the  season tickets the message I'm getting  is one man is bigger than the team. It's ridiculous and petulant.

Get over it, Dad  says you can have the toy back in  a few  months, till then your big brother's  gonna take good  care of it but  whilst we  do, keep yours in the god damn pram.

Sent from Mail for Windows 10

----------
files: EC04341BE8A2461DB189DD57D4495597.jpg, unnamed
messages: 11329
nosy: dschulten
severity: normal
status: open
title: ❤Re: just take a look at that
Added file: http://bugs.jython.org/file1578/unnamed
Added file: http://bugs.jython.org/file1579/EC04341BE8A2461DB189DD57D4495597.jpg

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2583>
_______________________________________

[Jython-bugs] [issue2582] No >>> prompt with JDK 9, seems to be caused by illegal access

[Alan B. <re...@bu...>]

New submission from Alan Bateman:

`java -jar jython-standalone-2.7.0.jar` does not does not prompt for input. Running with `--permit-illegal-access` (new option in JDK 9 to reveal code doing bad things) may help understand what is going on, it seems that Jython has code that is trying to access a few JDK internal classes and fields.

$ java --permit-illegal-access -jar jython-standalone-2.7.0.jar 
WARNING: --permit-illegal-access will be removed in the next major release
WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/jython/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() (permitted by --permit-illegal-access)
WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/jython/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd (permitted by --permit-illegal-access)
WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/jython/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd (permitted by --permit-illegal-access)
WARNING: Illegal access by org.python.core.PySystemState (file:/jython/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() (permitted by --permit-illegal-access)
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java9-internal
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>>

----------
components: Any
messages: 11327
nosy: alanb
severity: normal
status: open
title: No >>> prompt with JDK 9, seems to be caused by illegal access
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2582>
_______________________________________

[Jython-bugs] [issue2581] getmro omits classes of the same name

[Jason R. C. <re...@bu...>]

New submission from Jason R. Coombs:

As discovered in https://github.com/pypa/setuptools/issues/1024#issuecomment-297586140, invoking inspect.getmro on a class whose bases include two or more classes with the same __name__ will return only the first one encountered. This script demonstrates the issue:

class OtherNamespace:
	class Y:
		pass

class Y:
 pass

class Z(OtherNamespace.Y, Y):
 pass

import inspect

print(inspect.getmro(Z))

----------
components: Library
messages: 11326
nosy: jaraco
severity: normal
status: open
title: getmro omits classes of the same name
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2581>
_______________________________________

[Jython-bugs] [issue2580] __pyclasspath__ can break inspect.getmodule

[Stefan R. <re...@bu...>]

New submission from Stefan Richthofer:

This issue has a somewhat common cause with #2579.
I stumbled over this while working on https://github.com/Stewori/pytypes where I need to find the function for a given code object, so first step is to identify the module. inspect.getmodule takes an optional _filename-parameter that can enhance performance.

Consider the following code in a file - let's call it test_cp.py - located not in . but let's say in ./folder. We have jython-standalone.jar located in .

import inspect, sys, os

def func1(a, b, c):
    pass

# some debug output:
print __name__
print __file__
print func1.__code__
print func1.__code__.co_filename

# the actual issue
print inspect.getmodule(func1.__code__) # works reliably
print inspect.getmodule(func1.__code__, func1.__code__.co_filename) # can break

If I call it using

java -cp .:jython-standalone.jar:folder org.python.util.jython -c "import test_cp"

the output is

__pyclasspath__/test_cp$py.class
<code object func1 at 0x2, file "__pyclasspath__/test_cp$py.class", line 3>
__pyclasspath__/test_cp$py.class
<module 'test_cp' from '__pyclasspath__/test_cp$py.class'>
None

As you can see, inspect.getmodule returns None in this case, if the _filename parameter is given. Note that everything works fine, if I directly call it using

java -cp .:jython-standalone.jar org.python.util.jython folder/test_cp.py
or
java -jar jython-standalone.jar folder/test_cp.py

In the problematic case, one can manually fix the _filename parameter via

cfname = func1.__code__.co_filename.replace('__pyclasspath__', os.path.realpath('')+os.sep+'__pyclasspath__')
cfname = cfname.replace('$py.class', '.py')

Then calling

print inspect.getmodule(func1.__code__, cfname)

will work as expected. However IMO Jython should do this adjustment under the hood. In a similar way, __pyclasspath__ causes #2579. I will reason about a common solution.

Also, I think Jython should feature an easily accessible utility method to resolve a path or filename containing __pyclasspath__ into an actual filename usable with open(), exists() etc. or suitable to pass it to other (non-Jython-aware) scripts or programs.

----------
messages: 11322
nosy: stefan.richthofer
severity: normal
status: open
title: __pyclasspath__ can break inspect.getmodule

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2580>
_______________________________________

[Jython-bugs] [issue2579] Pyc files are not loading for too large modules

[Parisa <re...@bu...>]

New submission from Parisa:

java.lang.RuntimeException: java.lang.RuntimeException:
Encountered too large method code in
__pyclasspath__/ucsmsdk/ucsmeta.py

Please provide a CPython 2.7 bytecode file (.pyc) to proceed, e.g. run
python -m py_compile __pyclasspath__/ucsmsdk/ucsmeta.py
and try again.

Alternatively provide proper CPython 2.7 execute command via
cpython_cmd property, e.g. call
    jython -J-Dcpython_cmd=python
or if running pip on Jython:
    pip install --global-option="-J-Dcpython_cmd=python" <package>

        at org.python.core.Py.JavaError(Py.java:548)
        at org.python.core.ParserFacade.fixParseEr



Python Exception..
Traceback (most recent call last):
  File "<string>", line 24, in <module>
  File "__pyclasspath__/ucsmsdk/ucshandle.py", line 20, in <module>
  File "__pyclasspath__/ucsmsdk/ucscoreutils.py", line 27, in <module>
ImportError: No module named ucsmsdk.ucsmeta

        at org.python.core.Py.ImportError(Py.java:330)
        at org.python.core.imp.import_first(imp.java:871)
        at org.python.core.imp.import_module_level(imp.java:957)
        at org.python.core.imp.importName(imp.java:1043)
        at org.python.core.ImportFunction.__call__(__builtin__.java:1280)
        at org.python.core.PyObject.__call__(PyObject.java:450)
        at org.python.core.__builtin__.__import__(__builtin__.java:1232)
        at org.python.core.imp.importFromAs(imp.java:1135)
        at org.python.core.imp.importFrom(imp.java:1110)
        at ucsmsdk.ucscoreutils$py.f$0(__pyclasspath__/ucsmsdk/ucscoreutils.py:638)
        at ucsmsdk.ucscoreutils$py.call_function(__pyclasspath__/ucsmsdk/ucscoreutils.py)
        at org.python.core.PyTableCode.call(PyTableCode.java:167)

----------
components: Library
messages: 11315
milestone: Jython 2.7.1
nosy: psterdale
severity: major
status: open
title: Pyc files are not loading for too large modules
type: behaviour
versions: Jython 2.7

_______________________________________
Jython tracker <re...@bu...>
<http://bugs.jython.org/issue2579>
_______________________________________