pmxbot IRC Log Viewer

[03:17:45] <wiredfool_> aclark: ping

[11:15:21] <aclark> wiredfool: hey, yeah i'm trying to figure that out myself

[11:16:05] <aclark> wiredfool: i have to fix the py3 tests first i think there is some pull request waiting… then back to the few tests that fail on travis but not local

[16:12:57] <wiredfool> I'm going to dial the logging up to 11, and add a few more asserts in my save test.

[16:13:34] <wiredfool> They say that they're running a 32bit ubuntu 12.04 instance, but it looks like we're actually getting a 64bit instance.

[16:14:12] <wiredfool> I'll spin up one of those to see if I can replicate their issues here

[17:17:56] <aclark> wiredfool: cool thanks

[17:47:56] <wiredfool> I've got a pair of vms, one is 12.04/x86, one is 12.04/x64. The write errors only show up in the 64 bit version. Also, there's some jpeg errors that only show up in the 64 bit version.

[17:48:05] <wiredfool> So, yay, I can replicate

[18:02:41] <aclark> wiredfool: did you see the issue i had when i tested your pull request?

[18:02:48] <wiredfool> nope

[18:03:27] <wiredfool> was that on compile, or test run?

[18:03:49] <aclark> wiredfool: https://github.com/python-imaging/Pillow/pull/98#issuecomment-14836420, on test run

[18:04:02] <aclark> all my tests blew up… so i didn't merge :-)

[18:04:05] <aclark> not sure what's going on yet

[18:04:10] <wiredfool> sorry, I saw it, but I didn't see it here

[18:04:16] <aclark> np

[18:05:22] <wiredfool> the write error is definately a 64 bit problem

[18:06:41] <wiredfool> thre read error on lena_g4, the 128px version, is not a 64bit issue

[18:07:06] <wiredfool> (also, wtf, debian is using tifflib 3.9.5, and it's reporting as 4.3.4)

[20:25:14] <wiredfool> I've narrowed it to this warning: encode.c:731:2: warning: passing argument 2 of ‘PyDict_Next’ from incompatible pointer type [enabled by default]

[20:25:55] <wiredfool> (which, appears to be incorrect, as it's getting a Py_ssize_t, it's just not realizing it. )

[20:26:21] <wiredfool> That's listed as a change in the docs, and that it could cause problems on 64 bit systems

[20:26:53] <wiredfool> And the code there doesn't properly step through the dict, where it does on 32bit

[20:27:09] <wiredfool> and I've confirmed that there are the correct items in the dict

[20:31:04] <wiredfool> using a for loop over the key list and the value list works correctly though.

[20:43:14] <wiredfool> ok, fix is in for the find_library_file issue

[21:48:09] <aclark> wiredfool: ok this is "normal" right: IOError: decoder group4 not available

[21:48:19] <aclark> i.e. my jpeglib is too old, or something?

[21:48:27] <wiredfool> no

[21:48:34] <aclark> ah, damn

[21:48:38] <wiredfool> do you have libtiff + libtidd-dev installed?

[21:48:47] <wiredfool> mimight be libtiff4

[21:48:58] <aclark> let me check

[21:49:10] <wiredfool> what platform are you on?

[21:49:29] <aclark> OS X, and here's a Py 3 compat issue, but I can fix that: File "Tests/test_file_tiff.py", line 74

[21:49:33] <aclark> print "No _compression"

[21:49:35] <aclark> ^

[21:49:40] <aclark> I'm installing tiff now

[21:50:34] <wiredfool> right. habits

[21:51:11] <aclark> crap now i get the 64 bit errors…

[21:52:08] <wiredfool> damn

[21:52:19] <wiredfool> my mac is still on py 2.5.2

[21:52:31] <wiredfool> I'm going to have to get a virtualenv going on it

[21:54:31] <aclark> wiredfool: https://gist.github.com/aclark4life/5156695

[21:54:42] <aclark> heh

[21:54:56] <aclark> 2.5 is old… but not as old as 2.4 which I still use from time to time

[21:55:24] <wiredfool> Its a stock install of lion

[21:55:37] <wiredfool> but I've got a stock install of SL on my old laptop

[21:55:38] <aclark> right

[21:55:42] <aclark> Really just: In file included from /usr/local/include/tiffio.h:33:

[21:55:42] <aclark> /usr/local/include/tiff.h:78:23: error: typedef redefinition with different types ('unsigned long' vs 'unsigned long long')

[21:55:46] <aclark> typedef TIFF_UINT64_T uint64;

[21:55:48] <aclark> ^

[21:55:51] <aclark> libImaging/TiffDecode.c:21:16: note: expanded from macro 'uint64'

[21:55:53] <aclark> #define uint64 uint64_t

[21:55:56] <aclark> ^

[21:55:58] <aclark> /usr/include/stdint.h:55:30: note: previous definition is here

[21:56:01] <aclark> typedef unsigned long long uint64_t;

[21:56:03] <aclark> ^

[21:56:05] <aclark> 1 error generated.

[21:56:08] <aclark> error: command '/usr/bin/clang' failed with exit status 1

[21:56:08] <wiredfool> yeah.

[21:56:11] <aclark> which looks fixable-ish…

[21:56:33] <wiredfool> I think that's boilerplate from the truly horrific patch that I started with

[21:56:41] <aclark> heh

[21:59:03] <wiredfool> it was using a bunch of private interfaces and doing row level twiddling

[22:01:32] <aclark> ugh

[22:01:59] <wiredfool> ok, now I get the pyssizet issue too.

[22:02:07] <wiredfool> We're not targeting 2.4

[22:03:23] <aclark> right

[22:16:50] <wiredfool> ok, give it a shot, I've taken out what look like redundant redefines

[22:26:24] <aclark> wiredfool: much better! down to one test failure: https://gist.github.com/aclark4life/5156958

[22:26:35] <aclark> (thanks for working on all this btw)

[22:31:24] <wiredfool> did you have to compile your pythons to have them link against the right sdk?

[22:31:54] <wiredfool> that one test failure is 'expected' in that it's happening here and I need to dig farther on it

[22:32:55] <aclark> wiredfool: ok cool, so ok to merge then? I'll probably turn that test off until it's fixed

[22:34:02] <aclark> wiredfool: re: compile, sort of. On OS X I install XCode which has a compiler which I then use to compile all my Pythons (with this: https://github.com/collective/buildout.python)

[22:34:53] <wiredfool> I'm asking because I don't have the 10.6 sdk here, and that's what the distributed pythons need to compile stuff

[22:35:13] <wiredfool> actually, it's probably on the snow leopard laptop...

[22:37:25] <wiredfool> Merging is ok now, with that disabled test. The other thing you might want to disable is the tracing on the tiff c-level stuff.

[22:37:38] <wiredfool> It's this commit: https://github.com/wiredfool/Pillow/commit/35ce34a5faeca68f4253938d5f96039679179a92

[22:39:08] <wiredfool> I've been maintaining some form of this patch for 5 years or more. It'll be good to get it into the base library

[22:39:36] <wiredfool> I should probably build pillow on windows for a smoke test

[22:42:28] <aclark> Yeah I'm testing windows too

[22:42:50] <aclark> ok i'll turn off the debug

[22:42:56] <wiredfool> I hate building stuff on windows

[22:43:38] <aclark> Yep, very annoying

[22:59:51] <aclark> wiredfool: oops, 2.7 has an issue: decode.c:417:5: warning: implicit declaration of function 'TRACE' is invalid in C99 [-Wimplicit-function-declaration]

[22:59:53] <aclark> TRACE(("new tiff decoder %s\n", compname));

[22:59:56] <aclark> ^

[22:59:59] <aclark> decode.c:417:12: warning: expression result unused [-Wunused-value]

[23:00:01] <aclark> TRACE(("new tiff decoder %s\n", compname));

[23:00:03] <aclark> ^~~~~~~~~~~~~~~~~~~~~~~

[23:00:06] <aclark> decode.c:441:43: error: use of undeclared identifier 'TIFFSTATE'

[23:00:08] <aclark> decoder = PyImaging_DecoderNew(sizeof(TIFFSTATE));

[23:00:11] <aclark> ^

[23:00:13] <aclark> decode.c:448:11: warning: implicit declaration of function 'ImagingLibTiffInit' is invalid in C99 [-Wimplicit-function-declaration]

[23:00:14] <wiredfool> did you uncomment the blank trace #define

[23:00:17] <aclark> if (! ImagingLibTiffInit(&decoder->state, compression, fp)) {

[23:00:19] <aclark> ^

[23:00:22] <aclark> 3 warnings and 1 error generated.

[23:00:24] <aclark> error: command 'xcrun' failed with exit status 1

[23:01:50] <aclark> not that i know of

[23:01:59] <aclark> haven't touched anything like that yet

[23:02:00] <wiredfool> that almost sounds like Tiff.h wasn't included

[23:06:52] <wiredfool> I'm not seeing it on 2.7 here

[23:07:07] <aclark> strange

[23:07:13] <wiredfool> It looks like there might be an extra #endif at the bottom of Tiff.h

[23:07:45] <wiredfool> TIFFSTATE is defined in Tiff.h. as is TRACE

[23:08:51] <aclark> wiredfool: here's my tiff.h: https://gist.github.com/aclark4life/5157301

[23:09:22] <wiredfool> that's the system one. Tiff.h is in libImaging

[23:09:34] <aclark> oh, right

[23:10:06] <wiredfool> are you on the pillow master?

[23:11:11] <aclark> wiredfool: yes

[23:11:56] <wiredfool> It's working on linux

[23:12:07] <wiredfool> I'm getting a couple of warnings in JpegEncode.c

[23:13:55] <wiredfool> https://gist.github.com/wiredfool/23af9a51bd07d9b06b6f

[23:15:33] <aclark> wiredfool: hmmm, i fiddled with Tiff.h with not much success

[23:20:43] <wiredfool> That's really strange.

[23:28:24] <aclark> wiredfool: Anything I can do to avoid (vs understanding why) ?

[23:28:43] <wiredfool> dunno, I'm trying to get a working build on osx now

[23:28:44] <aclark> I guess it's on OS X issue… decode.c:417:5: warning: implicit declaration of function 'TRACE' is invalid in C99 [-Wimplicit-function-declaration]

[23:28:48] <aclark> k

[23:29:01] <aclark> what's C99?

[23:29:18] <wiredfool> the 1999 spec for C language

[23:29:42] <wiredfool> basically, implicit definition means that this thing you're calling hasn't been defined

[23:30:14] <aclark> k

[23:30:19] <wiredfool> and that means that for some reason, there's a disconnect between the header and the file that's being compiled, since it's defined in that header

[23:31:12] <aclark> wiredfool: oh, decode.c doesn't include Tiff.h? :-)

[23:31:14] <aclark> maybe

[23:31:21] <wiredfool> ah, but it does

[23:31:27] <aclark> it optionally does #ifdef HAVE_LIBTIFF

[23:31:37] <aclark> so maybe that check is flawed

[23:31:42] <aclark> somehow

[23:31:45] <wiredfool> yeah, and if it doesn't have libtiff, then nothing in that secton compiles

[23:31:59] <wiredfool> since the ifdef covers the whole function that's having compile errors

[23:32:26] <aclark> yep

[23:32:27] <wiredfool> I've got a sneaky suspiciou

[23:33:12] <wiredfool> try renaming Tiff.h to PILTiff.h, and change Tiff.h to PILTiff.h in all the places where it shows up in .c code

[23:33:31] <wiredfool> since osx isn't case sensitive, I'm wondering if something is getting cross wired there

[23:34:06] <wiredfool> it should be included in encode.c, decode.c, and TiffDecode.c

[23:34:21] <aclark> k

[23:34:43] <aclark> well, that wouldn't explain 2.7 only would it?

[23:34:56] <wiredfool> no

[23:35:46] <wiredfool> ok, my imac will soon start sounding like it's going to take off. It's compiling 4 different pythons

[23:36:50] <aclark> cool

[23:40:14] <wiredfool> so, if this is build for distribution, presumably it needs to be built with the same toolchain as the distributed pythons

[23:40:29] <wiredfool> which means xcode 4.3, and that means SL

[23:41:30] <aclark> I'm on Mountain Lion FWIW

[23:42:10] <wiredfool> I've been meaning to upgrade, but I'm worried that it's going to kill off my lightroom

[23:42:19] <wiredfool> since Lion wasn't kind to it.

[23:46:05] <wiredfool> and, this is going to sound strange, but I prefer ubuntu 10.04 for getting stuff done

[23:48:50] <aclark> heh

[23:49:05] <aclark> wiredfool: where did Tiff.h come from? I don't see it here: https://bitbucket.org/effbot/pil-2009-raclette/src/cd403356263f039a4a48a1111c7f5cc38686e481/libImaging?at=default

[23:50:03] <wiredfool> It's a new file from the g4 patch. Previously all the tiff stuff (such as it was) was done in python

[23:50:12] <aclark> ah ok

[23:50:24] <wiredfool> It's history is the old private function patch from way back in 05 or so

[23:52:32] <aclark> heh

[23:52:33] <aclark> http://www.wiredfool.com/2005/10/29/how-to-build-the-python-imaging-library-for-windows/

[23:52:36] <aclark> man

[23:52:44] <wiredfool> yep

[23:52:46] <aclark> it's nice to be able to finally ship all of this crap ;-)

[23:52:53] <wiredfool> yeah

[23:53:03] <wiredfool> where are you getting libjpeg and lib tiff for the mac

[23:54:35] <aclark> maybe this helps: http://stackoverflow.com/questions/6704335/implicit-declaration-of-function-c99

[23:54:38] <aclark> Homebrew

Log file Viewer

Help | Karma | Search:

#pil logs for Wednesday the 13th of March, 2013