Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TST: splitlines in rec2txt test #6423

Merged
merged 4 commits into from May 17, 2016

Conversation

tacaswell
Copy link
Member

On windows the output has '\r\n' instead of '\n' for new
lines.

If this passes I plan to self-merge to un-break appveyor

On windows the output has '\r\n' instead of '\n' for new
lines.
@tacaswell
Copy link
Member Author

attn @dopplershift I think this is an equivalent test .

@tacaswell
Copy link
Member Author

@JanSchulz Can you help out with the windows issue here? I do not have a system to test on and debugging via appveyor seems maddeningly painful!

@dopplershift
Copy link
Contributor

👍 from me.

@tacaswell
Copy link
Member Author

tacaswell commented May 16, 2016

In windows this seems to output one less space is some cases:

windows = ['       x   y   s    s2', '   1.000   2   foo  bing ']
truth =   ['       x   y   s   s2',  '   1.000   2   foo bing ']

@tacaswell
Copy link
Member Author

Sorry, had order flipped, windows adds an extra space.

The division was always returning 1, use length of first element
instead.
@tacaswell
Copy link
Member Author

@dopplershift I think there was a bug in computing the width of the string columns which for some reason was behaving differently on windows/linux.

@tacaswell tacaswell added this to the 2.0 (style change major release) milestone May 16, 2016
@jankatins
Copy link
Contributor

jankatins commented May 16, 2016

I have a look... Looks like there are at least two problems:

The one where the link step can't find png.lib and the one where there is a space difference.

Re the png one: it seems that conda-forge recently added a libpng (and that one is installed), could be that there is a difference to the official one? https://github.com/conda-forge/libpng-feedstock/commits/master (cc: @ocefpaf)

@tacaswell
Copy link
Member Author

I think I have the space issue fixed

# The division below handles unicode stored in array, which could
# have 4 bytes per char
length = max(len(colname), column.itemsize // column[0].itemsize)
length = max(len(colname), len(column[0]))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced len() will do what we want if the data for a column is ['foo', 'bars']. Probably should change the test to have some differing string sizes and see what happens.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that allowed in recarrays? The types look like fixed-width string, not variable width.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In [18]: a = np.array([(1, 'foo'), (2, 'bars')], dtype=np.dtype([('i', np.int32), ('s', np.str, 4)]))

In [19]: a
Out[19]:
array([(1, 'foo'), (2, 'bars')],
      dtype=[('i', '<i4'), ('s', '<U4')])

In [20]: len(a['s'][0])
Out[20]: 3

I couldn't find a numpy function to get that 4 from the <U4, which is what we really want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it turns out my original code was broken as well:

In [29]: a['s'][0].itemsize
Out[29]: 3

WTF?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you want a.dtype['s'].itemsize == 16 ( / 4 for Unicode == 4)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

len() is not the right thing. The best I can come up with is int(a.dtype['s'].str[2:])

@tacaswell
Copy link
Member Author

And tests are passing, but it is dying as while trying to build the conda package

Fixed width byte/unicode dtypes seem to have the pattern
"[|<>][US][1-9][0-9]*" thus if we drop the first two charters we will
have the fixed width.
@tacaswell
Copy link
Member Author

ok, this is now passing (except for a down-load error on one of the appveyor tests).

I had to turn off the conda package building which is less than great, but makes the test useful again for code review.

@jenshnielsen jenshnielsen merged commit 326cc05 into matplotlib:master May 17, 2016
@jenshnielsen jenshnielsen mentioned this pull request May 17, 2016
@tacaswell tacaswell deleted the tst_fix_windows_print_test branch May 22, 2016 15:49
@cgohlke
Copy link
Contributor

cgohlke commented May 23, 2016

Is this going to be backported? matplotlib 1.5.2rc1 on Windows fails one test:

======================================================================
FAIL: test_csv2txt_basic (matplotlib.tests.test_mlab.rec2txt_testcase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "X:\Python35\lib\site-packages\matplotlib\tests\test_mlab.py", line 409, in test_csv2txt_basic
    assert_equal(mlab.rec2txt(a), truth)
AssertionError: '       x   y   s    s2\r\n   1.000   2   foo  bing \r\n   2.[16 chars]lah ' != '       x   y   s   s2\n   1.000   2   foo bing \n   2.000   3   bar blah '
-        x   y   s    s2
?                 -     -
+        x   y   s   s2
-    1.000   2   foo  bing
?                   -      -
+    1.000   2   foo bing
-    2.000   3   bar  blah ?                   -
+    2.000   3   bar blah

----------------------------------------------------------------------
Ran 5209 tests in 1399.371s

@tacaswell
Copy link
Member Author

Yes, sorry this got lost in the appveyor related issues.

On Sun, May 22, 2016, 20:12 Christoph Gohlke notifications@github.com
wrote:

Is this going to be backported? matplotlib 1.5.2rc1 on Windows fails one
test:

FAIL: test_csv2txt_basic (matplotlib.tests.test_mlab.rec2txt_testcase)

Traceback (most recent call last):
File "X:\Python35\lib\site-packages\matplotlib\tests\test_mlab.py", line 409, in test_csv2txt_basic
assert_equal(mlab.rec2txt(a), truth)
AssertionError: ' x y s s2\r\n 1.000 2 foo bing \r\n 2.[16 chars]lah ' != ' x y s s2\n 1.000 2 foo bing \n 2.000 3 bar blah '

  •    x   y   s    s2
    
    ? - -
  •    x   y   s   s2
    
  • 1.000 2 foo bing
    ? - -
  • 1.000 2 foo bing
  • 2.000 3 bar blah ? -
  • 2.000 3 bar blah

Ran 5209 tests in 1399.371s


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#6423 (comment)

tacaswell pushed a commit that referenced this pull request May 23, 2016
@tacaswell
Copy link
Member Author

backported to v1.5.x as cab8cf7

@QuLogic QuLogic added this to the 1.5.2 (Critical bug fix release) milestone May 23, 2016
@QuLogic QuLogic removed this from the 2.0 (style change major release) milestone May 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants