Log file Viewer

[16:17:11] <w0rp> I'm having trouble installing PIL through pip. I'm running a site where I have PIL==1.1.7 in my requirements file, but there are no verifiable sources for it.

[16:19:24] <wiredfool> is the effbot site down?

[16:19:54] <wiredfool> http://effbot.org/downloads/Imaging-1.1.7.tar.gz

[16:23:27] <w0rp> I added the relveant 'unverified' options for it.

[17:53:50] <aclark> w0rp: this is essentially why Pillow was created, use Pillow instead.

[17:57:11] <wiredfool> ls

[18:03:39] <wiredfool> heh. window fail

[18:06:03] <terseus> hello

[18:07:07] <terseus> any Pillow developer here? I'm trying to fix issue 367 ( https://github.com/python-imaging/Pillow/issues/367 ) but I'm quite lost

[18:08:07] <wiredfool> hey terseus

[18:08:14] <terseus> hey ^_^

[18:08:15] <wiredfool> I was looking at that this am

[18:09:06] <terseus> ok, I'll be here

[18:09:38] <wiredfool> I seem to recall something about that actual coordinate system being shifted .5 off, but I can't find the docs now.

[18:09:59] <wiredfool> I do agree that defining the correct behavior is an open problem

[18:11:58] <terseus> I'm pretty sure that there should be some mmm mathematically defined way to draw a polygon to be considered "consistent"

[18:12:37] <terseus> but I don't know where to look at

[18:13:12] <w0rp> aclark: I will switch to Pillow, but not right away.

[18:13:18] <wiredfool> I'd say that consistent, non-suprising behavior is important

[18:13:28] <w0rp> I need to upgrade first on a staging machine, and then test everything. Then I can upgrade.

[18:13:31] <terseus> considering the square example of the comment, what do you think is the correct? 6 or 7 pixels?

[18:13:43] <wiredfool> w0rp: early versions of pillow were only packaging fixes for PIL

[18:13:51] <wiredfool> (pillow < 2.0.0)

[18:14:12] <w0rp> Well, if I'm going to upgrade, I'll just go all the way and get on some recent version.

[18:14:59] <w0rp> Each site uses virtualenv, so I can upgrade one at a time.

[18:15:10] <wiredfool> w0rp: that's helpful.

[18:15:49] <wiredfool> terseus: ...

[18:16:23] <wiredfool> The lower coordinate should clearly be inclusive.

[18:16:45] <wiredfool> e.g. rect from (0,0) -> (x,y) should clearly include 0,0

[18:16:49] <terseus> yes, I think the same

[18:16:55] <terseus> the problem are the higher coordinates

[18:17:09] <wiredfool> though, the more I think about the language, anytime I say clearly, I should ahve to justify it other than with hadnwivnig

[18:17:24] <wiredfool> M-x spell

[18:18:03] <wiredfool> The coordinate system goes from (0,0) -> (size)-(1,1)

[18:18:33] <wiredfool> so, if one were to draw a rectangle of (0,0), (size), then you'd fill the entire image

[18:19:21] <wiredfool> this feels somewhat inconsistent to me. Useful, and probably easier, but inconsistent with the rest of the package

[18:20:12] <terseus> but, if one were drawing a rectangle from (0,0) to (size)-(1,1), should it fill the entire image, too?

[18:21:59] <wiredfool> It's ... not if the end of the range is inclusive

[18:23:04] <terseus> as a side note, the hline functions do include the maximum coords

[18:23:29] <wiredfool> Inclusive would be predictable based on the rest of the api. Noninclusive would be convenient

[18:23:34] <terseus> so a hline from x=2 to x=4 ends up in a line of length 3

[18:24:02] <wiredfool> I think inclusive is probably the right call

[18:24:30] <terseus> well, it's the easiest call ;)

[18:25:58] <terseus> ok, I'll consider inclusive the defined behavior for now

[18:27:03] <terseus> and begin to do extensive test with lines and polygons, to be sure that my changes don't break other functionalities

[18:27:44] <terseus> btw, it will NOT be ready for 2.4.0 :(

[18:29:24] <terseus> well, thank a lot wiredfool, I was very very lost on this

[18:30:34] <terseus> I'll go back to work, I hope to send a pull request in a few days so all of you can review the changes

[18:31:14] <terseus> see you!

[18:36:21] <wiredfool> glad to help, and thanks for working on this.