| | <<<Back 1 day (to 2015/10/21) | 20151022 |
| kens | Huh looks like hte problem with ghostpdf.inf and the .cat file is a Git'ism and our policies. The file has been Unix'ised when sent back to the repository, but not Windows'ised when pulled back. | 08:34.26 |
| | Which means hte CR/LF have turned into L:F which means the SHA is different | 08:34.46 |
| chrisl | Hmm, not, that's probably because I do the release from a LInux system..... | 08:35.07 |
| kens | I guessed it might be something like that | 08:35.20 |
| | It didn't occur to me at the time, I assumed the .inf file would be the same as the one I had in my checkout | 08:35.41 |
| Robin_Watts | chrisl: Can you unix2dos in the release script? :) | 08:35.42 |
| kens | Well I can build a .cat file from the Unix version | 08:36.05 |
| chrisl | Robin_Watts: there isn't a release script (except for the commercial release....) | 08:36.07 |
| kens | Its just that it didn't occur to me before. Of course when I *tested* it, I used the .inf and .cat I had here, which of course worked fine | 08:36.40 |
| chrisl | Is there a way we can force git to treat a file as binary? | 08:36.53 |
| kens | has no idea | 08:37.22 |
| | TO be fair, Git does always tell me its doing tghe translation, I just assumed it would be undone again. | 08:37.59 |
| chrisl | Ah, we can do it using gitattributes | 08:38.05 |
| | kens: I think it is undone, isn't it? | 08:38.28 |
| Robin_Watts | echo "*.inf binary" > .gitattributes | 08:38.46 |
| kens | chrisl it is when it comes back to me yes | 08:38.54 |
| | I meant that I assumed that the translationwould be done when doing the release, of course if you use a Linux machine, that doesn't happen | 08:39.15 |
| chrisl | Aha, so we do have a .gitattributes file, we that's good | 08:40.03 |
| kens | We do ? O.O | 08:40.12 |
| Robin_Watts | actually... *.inf eof=crlf is probably better. | 08:40.15 |
| kens | Oh yeah I see it | 08:40.29 |
| | OK so if I add /lib/ghostpdl.inf eol=crlf that should be enough I think ? | 08:41.25 |
| chrisl | Although, I think echo "*.inf eof=crlf" >> .gitattributes would work better...... | 08:42.07 |
| kens | But as Robin says *.inf woudl work as well and we only have one | 08:42.09 |
| | Dumb question, if I change *my* .gitattributes, does that affect everyone else too ? | 08:42.48 |
| chrisl | If you commit the change | 08:42.58 |
| kens | Let me play for a second or tow :-) | 08:43.09 |
| chrisl | Which you should..... | 08:43.10 |
| kens | I want to look over what happens first, just to be sure I understand and am haoppy with it | 08:43.29 |
| | Oh and I'll need to go back to master too, oh well | 08:43.46 |
| chrisl | I shall take a deep breath, count to ten, and try to get cust 532's simulator working..... maybe it will just work this time | 08:44.33 |
| kens | Yeah and right after that your roof will be hit by a jet propelled boar | 08:44.59 |
| | Well, ths looks OK, I'll commit the change and see what happens :-) | 08:45.23 |
| | OK commit done, chrisl when you have a minute could you update your checkout and just check that the ghostpdl.inf file now has CR/LF line endings please ? | 08:49.06 |
| chrisl | kens: no, it doesn't seem to have changed at all. Possibly you need to force a commit of ghostpdl.inf to make the change take effect? | 09:00.06 |
| kens | Yeah I wondered about that | 09:00.33 |
| | I'll do that too, give me a second | 09:00.41 |
| | chrisl I touch'ed the file and then did a commit, can you try again please ? | 09:03.24 |
| Robin_Watts | kens: That won't have changed the SHA, so it's possible it won't have an effect. | 09:05.16 |
| kens | Robin_Watts : don't know | 09:06.36 |
| | But git gui knew it had changed, that's why I'#m asking Chris to check it | 09:06.52 |
| | Short of adding in blank lines, its not a file I want to alter | 09:07.09 |
| chrisl | Well, *something* changed.... | 09:09.49 |
| kens | WHen I try to check out my branch its telling me it can't delete teh directory 'lib' | 09:10.14 |
| | Which sounds kind of bad | 09:10.19 |
| | The commit report is bonkers | 09:10.56 |
| | Its copied a file from lcms2 (._.DS_Store) to lib/ghostpdl.inf | 09:11.25 |
| | I have a nasty feeling my repository has been screwed up | 09:11.42 |
| chrisl | But the contents of ghostpdf.inf have not changed :-( | 09:12.08 |
| kens | Bum | 09:12.16 |
| | I'll have to add whte space then | 09:12.32 |
| chrisl | If you do that, you'll need to recreate the .cat file | 09:15.11 |
| kens | Its OK, I can do another commit afterwards with it removed again | 09:15.26 |
| chrisl | I have to head out for a couple of hours...... | 09:17.35 |
| kens | OK I'll fire up a VM and keep plodding | 09:17.51 |
| chrisl | Possibly wait until Tor appears, he'll probably have some insight | 09:18.13 |
| kens | I might do that. I also thnk I've damaged my checkout and I may need some help fixiing it | 09:18.45 |
| | Hmm ghostpdl.inf seems to be radically broken, it now checks out at 0 bytes :-( | 09:27.34 |
| tor8 | kens: ghostpdl.inf is indeed empty; but to be fair it didn't exist before your last commit which confusingly mentions ghostpdf.inf in the comment, but only creates a new blank ghostpdl.inf file | 09:32.06 |
| kens | tor8 yes I just realised htat | 09:32.17 |
| | I must have essed up the filename somewhere | 09:32.26 |
| | I'm sorting it now (I hope!) | 09:32.37 |
| tor8 | coaxing the .gitattributes to take effect after the fact is not always trivial | 09:33.05 |
| | I think the easiest way is to remove the file locally and then 'git checkout ghostpdf.inf' (or git reset --hard) | 09:33.41 |
| kens | Or copy from another place ? | 09:33.57 |
| tor8 | but I'm not sure that will actually work as well | 09:33.59 |
| kens | I have multiple copies of the file | 09:34.04 |
| tor8 | delete it, commit that, copy from another place with the right endings, and add it back in | 09:34.12 |
| kens | Right, I'll do that. | 09:34.19 |
| tor8 | then you can try rebasing to squish the two commits and hopefully that should do it | 09:35.27 |
| kens | Hmm well we'll see :-) | 09:35.52 |
| tor8 | https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings | 09:36.30 |
| kens | Well I still got a warnign about LF being replaced by CR/LF, not sure if that's relevant | 09:37.33 |
| tor8 | kens: typo in .gitattributes, should be 'eol' not 'eof' | 09:38.04 |
| kens | sigh....... | 09:38.18 |
| tor8 | I can pretend it's monday for you :) | 09:38.26 |
| kens | Its been a trying week. Not as bad as Roin's of course | 09:39.03 |
| | OK done the commits and squashed them up, lets see what happens | 09:47.39 |
| | anyone know a good way to tell line endings on a Unix system ? | 09:49.26 |
| Robin_Watts | Washing Machine engineer coming tomorrow, apparently. | 09:50.36 |
| | I will be unhappy if they offer me a repair. | 09:50.45 |
| kens | LOL he's going to rebuild it ? | 09:50.49 |
| Robin_Watts | If the machine has managed to wrong enough that it's smashed a concrete block to bits, I don't hold out much hope for the long term health of the bearings etc. | 09:51.21 |
| | Dunno. But they insisted on an engineer, not a straight swap at least initially. | 09:51.41 |
| kens | I'd be unhappy in your position, smashed concrete sounds like there's going to be damage all over the isnides | 09:52.08 |
| | OK I believe grep is finding CR characters in the .inf file now, so I *thnk* all is good. | 09:53.15 |
| | It is also the same size in bytes on Linux and WIndows | 09:53.45 |
| | Finally...... | 09:53.58 |
| tor8 | kens: open it with vim, type ":set ff" | 10:07.09 |
| | it'll say unix or dos | 10:07.13 |
| kens | Hmm don't know if I have vim, but the WIndows file is CR/LF and the Unix file is the exact same size in bytes, so I thnk its fine. | 10:15.20 |
| | I'df have to restart the VM to check | 10:15.31 |
| tor8 | Robin_Watts: could you take a look at the commits on tor/master? if all looks good there I think it's time to compile release candidates. | 12:05.53 |
| Robin_Watts | tor8: sure. | 12:06.28 |
| | tor8: For stroke and fill paths, we first fill then stroke | 12:14.25 |
| | I reckon the comment /* No need for group, as stroke won't show up */ is wrong. | 12:14.41 |
| | It should be /* No need for group, as fill won't show through stroke */ | 12:15.02 |
| | but that's very minor. | 12:15.05 |
| | tor8: Other than that, look good to me. | 12:16.48 |
| | Simon put up a 4 line patch to fix something yesterday. Have we taken that on? | 12:17.04 |
| | That might be the one in your repo actually. | 12:17.22 |
| tor8 | that's the one in my repo | 12:17.38 |
| | the comment is an old one of yours I believe :) | 12:17.45 |
| Robin_Watts | hehe. ahem. | 12:18.12 |
| tor8 | copied from how fill+stroke is handled for paths | 12:18.33 |
| Robin_Watts | simon91: So, no more fixes coming imminently ? | 12:20.51 |
| simon91 | Robin_Watts: not for the moment ;-) | 12:22.40 |
| Robin_Watts | tor8: rc seems reasonable then. | 12:24.21 |
| simon91 | Robin_Watts: there is a big performance problem with formatting of floating point objects. working on it, but it can surely wait | 12:24.28 |
| tor8 | simon91: the fix to take FILE* will have to wait, I want to redo it properly with fz_output | 12:24.34 |
| | simon91: it's slow, but it's the only way we've found to do it reliably and portably | 12:24.52 |
| simon91 | tor8: can understand that | 12:25.03 |
| tor8 | converting floats to a string, and be able to keep full precision when reading it back is easy enough | 12:26.06 |
| simon91 | tor8: it must be locale independent, use the minimum amount of bytes and must not loose precision | 12:26.18 |
| tor8 | doing it while keeping the string only as short as absolutely required, less so | 12:26.21 |
| | it's a limitation of libc :( | 12:26.39 |
| simon91 | tor8: hmm. my idea would be to use "e" modifier with printf to bring it into [0-9] decimal-point-char [0-9]{6} e [+-] [0-9]{2}. | 12:28.53 |
| | and then strip the trailing zeros and handle the exponent | 12:28.53 |
| | tor8: Am I missing something with this? | 12:29.19 |
| tor8 | yeah, that can very well give you 1.0000000000000001e0 where 1e0 would give the same bit pattern. obviously not with those numbers, but you get the idea. | 12:30.09 |
| | also 0.999999999999e0 | 12:30.18 |
| | which is why we do the for loop trying different precision widths until we get one that round trips perfectly | 12:31.04 |
| simon91 | tor8: thought that with IEEE arithmetic you only have FLT_DIG (float.h) maximum digits of precision, so its save to use the "e" like above without loosing precision. | 12:33.06 |
| tor8 | "%.9g" is enough to get perfect precision with exponent syntax, but (a) you can get shorter strings than that in many cases, and (b) pdf can't do exponent syntax | 12:34.18 |
| | are you looking in source/fitz/printf.c at fmtfloat()? | 12:34.40 |
| | the 'slow' part of that is in source/fitz/ftoa.c | 12:35.32 |
| simon91 | tor8: I will try out my idea and check it on some random floats. | 12:37.45 |
| | tor8: hmm so 6 digits of precision woult not be enough for the rendering? | 12:39.23 |
| tor8 | everything depends on the transforms in use; the current code keeps numbers lossless. | 12:40.17 |
| | lossy floats in rendering is not going to make for any visible changes, but even if you limit it to 6 digits you're going to make bigger files | 12:41.07 |
| simon91 | tor8: if you have e.g. 0.99999999999999 and print it with "%e", I thought the C Spec mandates that it be correcty rounded to produce "1.000000" so all is left to do is stripping the trailing zeros. | 12:44.24 |
| | to reach at "1" | 12:45.04 |
| simon91 | hopes he is not talking complete non-sense | 12:47.04 |
| | Harbison-Steele says "some C implementations do not perform correct rounding in all cases" but that would hardly be our problem? | 12:51.10 |
| kens | Depends on the implemnetation, if its MS Visudal Studio that would be a problem | 12:51.42 |
| simon91 | kens: we would have to try it out | 12:52.24 |
| kens | Cross platform portability is a big issue. Failing with Android or iOS would also be a problem, and potentially with old versions of gcc which might be required for some embedded platforms | 12:53.25 |
| | We do, sadly, face these sorts of problems on Ghostscript :-( | 12:53.52 |
| simon91 | kens: Hmm. think we still should provide the users of the not-completely-broken platforms to do it in a way that performance is bound by disk-IO. So switch it on atleast on linux and bsd derived stuff like osx, cywin. | 12:59.57 |
| chrisl | kens: I'm still seeing ghostpdf.inf being in Unix format :-( | 13:00.36 |
| kens | A compile tmie preprocessor definition is a possibility, my comments were intended to be general, not specific to ths particular problem | 13:00.38 |
| | chrisl really ? :-( | 13:00.47 |
| | I'll get my VM out again | 13:00.56 |
| kens | thnks, time for a branch possibly | 13:01.47 |
| | THen I can hammer it until its fixed and pull it back from there | 13:02.05 |
| | chrisl I did a git up, and it said my checkout was up to date, vim ghostpdl.inf and then :set ff returns fileformat=dos | 13:03.34 |
| | I could try a new clone I suppose | 13:04.37 |
| | That shoudl read ghostpdf.inf of course..... | 13:05.06 |
| chrisl | For me, it says fileformat=unix | 13:06.37 |
| kens | c46f8651e6bea69b76f84dd58568c18fc73ade7dWeird | 13:06.43 |
| | Ahem | 13:06.49 |
| | weird | 13:06.52 |
| | I wonder if its because I did the .gitattributtes and all in one commit | 13:07.19 |
| chrisl | I'm not sure about Windows, since I use Cygwin, that might well get in the way | 13:07.22 |
| kens | Windows is OK for me, but then so is Linux | 13:07.33 |
| | I'll try a fresh clone | 13:09.14 |
| | chrisl a fresh clone says fileformat=dos | 13:14.54 |
| | (In fact vim says its a dos file on opening it) | 13:15.12 |
| | "ghostpdf.in" [dos] 52L, 1396C | 13:15.47 |
| | Could you try a fresh clone as well ? | 13:16.13 |
| chrisl | Just doing so | 13:16.23 |
| kens | OK | 13:16.27 |
| | If its still different I thnk I'll be stumped | 13:16.38 |
| chrisl | Ah, yes, I understand now...... | 13:17.29 |
| kens | I can make a white space change to see if that 'fixes' it, but I'll have to take it back out again, or as you rightly point out, the SHA will be incorrect, whch would mean I'd have to remake the .cat | 13:17.31 |
| | ?? | 13:17.50 |
| chrisl | To get git to update it, you have to remove the file, and checkout a fresh copy. | 13:18.02 |
| kens | Oh, I guess that makes some sense | 13:18.33 |
| | I had assumed it meant Git would store it with CR/LF, it sounds like it strips it back to lf but when pulling a copy makes it a CR/LF on all systems | 13:19.09 |
| chrisl | I dunno, if people expect to be able to rerun configure without doing a make clean, I think git should handle this ;-) | 13:19.27 |
| kens | :-) | 13:19.33 |
| | I guess as long as you're good now it doesn't matter, this only gets used when people try to install, so as long as the copy you use to build the installer is correct we should be fine. | 13:20.14 |
| | The only other problem would be someone who had an existing (Unix) checkout, and tried to use ghostpdl.inf from there. That seems too extreme to worry about | 13:21.05 |
| | Once I have access to an unsullied Windows 8+ system again I'll try and see if the .inf matches the .cat now. | 13:22.18 |
| chrisl | The only problem will be if I've been jumping around commits, since ghostpdf.inf doesn't update on it's own..... | 13:22.39 |
| kens | Hmm once you've got it correct I thnk you shold be OK | 13:23.15 |
| | It won't overwrite it when you go back a commit unless its changed (I think you;d have to go back a long way for that) | 13:23.40 |
| chrisl | Hopefully, yes.... | 13:23.51 |
| kens | I suppose I should note it down somewhere as something to check on a RC | 13:24.23 |
| chrisl | Actually, not that long ago, as I added the explanation about working around the lack of a signature | 13:24.25 |
| kens | Ah buit in that case the file will actually change won't it ? So a differetn SHA means Git will have to pull a new copy | 13:24.57 |
| | And presumably will use .gitattributes, so you should still be OK | 13:25.17 |
| kens | says hopefully | 13:25.30 |
| chrisl | gitattributes is part of the commit, so..... | 13:25.42 |
| kens | Yeah I know but it works OK on a clone | 13:25.57 |
| chrisl | particularaly with a bisect, there are still pitfalls | 13:25.58 |
| kens | I guess its possible, but as long as you end up with the file being correct (when doing a release) it doesn't matter if intermediate ones are not OK | 13:26.29 |
| tor8 | kens: it works fine, since the file was touched in the same commit it will pull out a new copy and the .gitattributes will change the line endings of it | 13:27.11 |
| kens | tor8 I was hopeful of that, because the clone worked :-) | 13:27.32 |
| chrisl | If I go from a commit from last week, to the current HEAD, it does not automatically update ghostpdf.inf | 13:28.05 |
| kens | scratches head, admits defeat | 13:28.56 |
| tor8 | chrisl: does ghostpdf.inf show as dirty when you do that? | 13:29.16 |
| chrisl | No | 13:29.32 |
| kens | A nice incoherent bug report :-( | 13:30.12 |
| chrisl | Anyway, I've made an additional note in my notes for doing a release to double check it, so it should be fine | 13:31.03 |
| kens | I'm right that Michael tried GSView on WIndows 10 aren't I ? | 13:31.03 |
| | Ah and the incoherent report is from someone using a Chines/Japanese ISP this is going to be fun :-( | 13:32.13 |
| mvrhel_laptop | kens: actually I have not tried it on windows 10. I will do that today. I actually need to go ahead and need a release | 14:23.18 |
| | s/need/do/ | 14:23.26 |
| | another beta | 14:23.32 |
| kens | mvrhel_laptop : I'm assuming GS works on Widows 10, I can't see any reason why it wouldn't and I htink I did try it, some time ago | 14:30.20 |
| | Confirmation would be good though | 14:30.27 |
| | I'm referencing bug #696299 by the way | 14:31.07 |
| henrys | certainly API.htm gsapi_run_string_continue() should be checking it's return value. | 15:24.07 |
| rayjj | this must be the day for muppets to open bug reports. Ken is more attentive to (and more patient with) these folks than I would be. | 16:38.03 |
| | just got a strange email from bugzilla saying "marcos has used the sudo feature to change your email preferences". He isn't here to ask, but I hope that what he does works :-/ | 17:01.41 |
| | right in the middle of debugging "Visual Studio has encountered an internal error" | 17:09.09 |
| | and it won't go away. | 17:09.25 |
| | oh, that's not good. After a reboot, I fired up VS 2008 again, and as soon as I hit F5, it got the error again :-( | 17:17.25 |
| yitzchok | kens: Thanks for your reply. I wasn't intending to rely on the logs but I had to reboot shortly after I sent my message and forgot to come back. | 18:30.15 |
| | I'm a long-time Linux user but I do tend to stay with my distro's packages. I'll have a go at installing 9.18 from ghostscript.com after uninstalling what I currently have installed. | 18:40.31 |
| rayjj | I /think/ I've found the issue with bug 696254. I was able to run 100 times with NumRenderingThreads=16 with no problems, where before i would be lucky to get 3. | 19:36.21 |
| | I'll build and test a release build next, while the cluster runs... | 19:37.07 |
| | so far, so good. It compiles on linux :-) | 19:37.48 |
| yitzchok | I see that the GS 9.18 download is a standalone executable. Nice and easy. I put it where my distro's gs was and printing still behaves the same way (some files print, others - PDFs it seems - don't) so 9.18 isn't worse. | 19:44.18 |
| | I will work again through the CUPS filter script to get the files which are sent to GS and the command lines which are used - both for successful and failed printing - and will update here. | 19:45.09 |
| | That will probably be tomorrow | 19:45.24 |
| rayjj | paulgardiner: Robin_Watts: chrisl: kens: Any or all of you, please review my change on my repo to fix bug 696254. | 23:15.56 |
| Robin_Watts | So, basically the code to check the filesize of a clist file wasn't protected by the mutex? | 23:19.10 |
| | oh, there is no mutex. ReadFile is an atomic "read from position x" call? | 23:19.46 |
| | gp_fwrite doesn't return the number of bytes written? | 23:20.40 |
| | In clist_fwrite_chars we don't account for res >=0 && res == len | 23:28.01 |
| | I am a bit confused by that commit. | 23:30.05 |
| | I can't see anything bad, but if the only thing reading from the file is ReadFile, then the filepos doesn't matter. | 23:30.43 |
| | If the only thing that ever seeks is the 'seek to the end then ftell', then how can 2 things ever conflict? | 23:31.13 |
| | I guess there must be something else going on that uses the filepos and is hence confused by the seek to the end? | 23:31.48 |
| | Forward 1 day (to 2015/10/23)>>> | |
IRC Logs