| | <<<Back 1 day (to 2015/01/19) | 20150120 |
| kens | Anyone know some parameters that will make the plib class of devices work on Ghostscript ? | 10:43.56 |
| Robin_Watts | planar interlaced buffer? | 10:44.32 |
| kens | No idea, all I know is the name of the devices | 10:44.43 |
| Robin_Watts | they might be mine. in what way don't they work? | 10:45.06 |
| kens | Whenever I try to use it I get a warning "Must have a BandHeight of at least 200" even if I set BandHeight | 10:45.11 |
| | I'm guessing I'm not doing some config right, but I have no idea what I need | 10:45.57 |
| | Seem ot be decalred in gdevplib.c | 10:46.08 |
| Robin_Watts | kens: Possibly it's not using clist? | 10:46.20 |
| kens | Beats me | 10:46.28 |
| Robin_Watts | Try -dMaxBitmap=1000 ? | 10:46.29 |
| kens | OK one moment | 10:46.33 |
| | No, same error | 10:47.00 |
| Robin_Watts | kens: just rebuilding now. | 10:47.19 |
| kens | Thanks | 10:47.26 |
| Robin_Watts | What command are you using? (so I can start with the same) | 10:47.34 |
| kens | gswin32c -dBandHeight=300 -dMaxBitmap=1000 -sDEVICE=plib -sOutputFile=\temp\out.plb test.ps | 10:48.11 |
| | Right now I'm just trying to get it to do something | 10:48.36 |
| | Seems to be an error from put_params | 10:50.18 |
| | And of course that is a routine (the default one) which I have modified, maybe I should try a stock GS | 10:50.38 |
| | BandHeight is coming back as 0 :-( | 10:51.40 |
| Robin_Watts | yeah, for me too. | 10:52.36 |
| kens | Oh well that's encouraging from my POV at least. I probably haven't broken something | 10:52.55 |
| | gdevprn doesnt' handl;e BandHeight, must be in the default | 10:53.21 |
| | Well, it never seems to read BandHeight from teh param list. Have I mentioned today how much I hate param lists ? | 10:54.43 |
| Robin_Watts | No, but it's kind of assumed as a pov of all sane people. | 10:55.08 |
| kens | I suppose I'd better check what's being passed to putparams | 10:57.19 |
| | Well, the first one is because we change the page size, which means we need to reset the device, and the initial values for the 'space' params are all 0. Looks to me like this device always threw at least one error | 11:08.38 |
| Robin_Watts | kens: I'm just skipping back through versions to see if I can find a version that worked. | 11:09.17 |
| kens | Robin_Watts : that wold be good, I guess I could bisect but if you've already stsrted there's no point | 11:09.37 |
| | I'm going to quickly experiment with rtemoving the error, since it goes back to some default | 11:10.06 |
| | Oh, also 0 :-D | 11:10.27 |
| | ah, and that causes a zeg fault, possibly not the best idea | 11:10.53 |
| Robin_Watts | Looks like I introduced the device in 9.02 | 11:11.12 |
| kens | Hmm, that was a while back | 11:11.27 |
| Robin_Watts | 9.07 appears broken. | 11:11.54 |
| | Trying 9.02 now. | 11:11.57 |
| kens | ah, we do (eventually) read the BandHeight | 11:12.00 |
| | OK so if we return a rangecheck error (because the BandHeight is 0), then that causes a foul up in gs_init.ps and we never read the real BandHeight | 11:15.09 |
| Robin_Watts | kens: Ah. | 11:18.13 |
| kens | ah ? | 11:18.25 |
| Robin_Watts | This appears broken in 9.02 :( | 11:18.26 |
| kens | Oh :-( | 11:18.31 |
| Robin_Watts | No... wait... | 11:18.49 |
| | I'm running the wrong thing. | 11:18.54 |
| kens | Ooops :-) | 11:18.59 |
| Robin_Watts | I moved to an SSD, and I'm building the version on the SSD and running it off the HD. Fool | 11:19.22 |
| kens | I've done similar stuff on Linux frequently enough | 11:19.44 |
| | "Why am I running 8.71?....." | 11:20.04 |
| Robin_Watts | Rebuilding now. | 11:20.40 |
| | I wonder if maybe that catching of rangecheck is new? | 11:20.59 |
| kens | I don't think so | 11:21.06 |
| | But it is possible | 11:21.17 |
| | gs_init.ps line 1860 we look to see if any pf the changes require us to reset the device (widht/heigth/resolution) | 11:21.56 |
| | If so we call defaultdevice and then putdevieprops | 11:22.11 |
| | putdeviceprops* | 11:22.18 |
| | And that's what throws the error, because we have not yet processed the command line | 11:22.39 |
| chrisl | It sounds like the device needs a non-zero default bandheight or some other setting | 11:23.22 |
| kens | That would be the simplest solution, but if I remove the error we do (eventually) read the BandHeight. However the device then seg faults :-( | 11:23.50 |
| | For me this crashes (if I remove the error return) in gdevmpla.c line 289 "MEM_SET_PARAMS(mdev, plane_depth);" plane_depth is 8 and mdev is "image8" | 11:27.07 |
| | OK mdev->line_ptrs is 0, so the macro attempts to access mdev->line_ptrs[0] and crashes. Looks like it hasn't allocated any memory for the device to render to | 11:28.08 |
| chrisl | line_ptrs is allocated separately from the raster memory | 11:28.44 |
| kens | gdevplib has a set_line_ptrs function | 11:29.11 |
| | well the plib device has line_ptrs, but the mdev doesn't | 11:30.41 |
| kens | is confused now | 11:30.53 |
| | It 'looks like' the set_line_ptrs routine should set mdev->line_ptrs, but it doesn't | 11:31.19 |
| chrisl | I'd have thought the memory buffer device would allocate it's own page buffer and setup its own line_ptrs | 11:32.51 |
| Robin_Watts | chrisl: No. | 11:33.00 |
| kens | Seems to inherit them from the clist | 11:33.10 |
| Robin_Watts | The whole point of the plib devices, (IIRC), is that they operate in a planar interlaced buffer provided by a caller. | 11:33.22 |
| kens | So if we get called with line_ptrs of NULL we throw away any existing mdev->line_ptrs, allocate a new line_ptrs and stick it into mdev. But if (as in this case) we get given line_ptrs, we don't put it into mdev->line_ptrs, that somehow doesn't look right. | 11:36.35 |
| Robin_Watts | ok, it works in 9.02 (once I add the device in) | 11:37.41 |
| kens | Well that's something | 11:37.48 |
| | Though I'm at a loss to explain how | 11:38.01 |
| Robin_Watts | Tryung 9.07 now. | 11:38.56 |
| chrisl | Robin_Watts: did you actually test 9.07, or did you try the wrong exe then, too? | 11:38.56 |
| Robin_Watts | chrisl: wrong exe too. | 11:39.06 |
| kens | Hmm, well in that case it might be some of the setpagedevice work which broke it | 11:39.23 |
| | That was relatively recent | 11:39.33 |
| chrisl | It's just this feels quite like the x11 problems I looked at which started after Ray's changes so the clist gets used for transparency group flattening | 11:40.26 |
| kens | THat may be true for the lines_ptr stuff, but not for gs_init failing | 11:40.53 |
| chrisl | Well, except that that commit changes how some of the banding parameters are handled | 11:41.24 |
| kens | I could believe that previously we got a 'NULL' for Lines_ptr and that would definitely alter the device code | 11:41.37 |
| | Oh.... | 11:41.52 |
| | Which commit ? | 11:42.06 |
| chrisl | So possibly try this commit and the one preceding it: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=4e44c99 | 11:42.21 |
| kens | crikey, tha's a big commit | 11:42.53 |
| Robin_Watts | 9.07 seems to still work (at least, no crash) | 11:47.17 |
| | 9.07 seems to still work (at least, no crash) | 11:49.25 |
| | (or error) | 11:49.36 |
| kens | I'm just trying the commit before Ray's change in January | 11:49.42 |
| | rebuilding..... | 11:49.50 |
| | Robin_Watts : what command line works ? | 11:50.26 |
| | Well commit ea83541 filas with a rangecheck | 11:51.53 |
| | Guess I'd better bisect | 11:51.59 |
| chrisl | D'you me to do it? It'll be quicker on Linux | 11:52.25 |
| kens | GOod point, if you wouldn't mind ? | 11:52.39 |
| chrisl | Sure, the command line you posted sufficient? | 11:53.08 |
| kens | I have no idea, I don't have a working one, which is why I asked RObin | 11:53.29 |
| | Drat I seem to have broken my Git with that checkout, how do I resert it back ? | 11:58.44 |
| chrisl | You in a detached HEAD state? | 11:59.13 |
| kens | SHould be yes | 11:59.22 |
| | Yes, it said so earlier | 11:59.36 |
| chrisl | git reset --hard <branch name> | 11:59.43 |
| kens | Yeah. doesn't work if I use master | 11:59.57 |
| Robin_Watts | gs/debugbin/gswin32c.exe -dBandHeight=300 -sDEVICE=plib -dMaxBitmap=1000 -o out.plib gs/examples/tiger.eps | 12:00.11 |
| chrisl | Doesn't work how? | 12:00.11 |
| kens | Just leaves me at the commit I checked out | 12:00.18 |
| Robin_Watts | chrisl: Ey? | 12:00.26 |
| | git checkout master | 12:00.32 |
| | Then git reset --hard | 12:00.37 |
| | 9.10 works. | 12:01.09 |
| kens | If I do git checkout master then it gives me a shopping list of files which would be overwritten | 12:01.16 |
| Robin_Watts | git reset --hard will throw away all the changes in your tree. | 12:01.32 |
| | You can then git checkout master to get where you want. | 12:01.47 |
| kens | Well, I have a stash on my device branch, nothing on master | 12:01.52 |
| | git reset --hard followed by git checkout master gives me that long list of files again | 12:02.20 |
| | git reset --hard says HEAD is now at ea83541 "pdfwrtite...." | 12:02.49 |
| Robin_Watts | kens: Ah, those are probably newly introduced files. | 12:03.05 |
| kens | Probably lots of 'cannot stat'on lcms | 12:03.25 |
| | and oipenjpeg | 12:03.36 |
| Robin_Watts | delete everything (except the .git directory) | 12:03.39 |
| | then git checkout master | 12:03.45 |
| kens | Umm, OK, this won't lose my branch ? | 12:04.12 |
| Robin_Watts | kens: Nothing that is checked into your git repo will be lost, as long as you don't delete the .git directory. | 12:04.39 |
| | git keeps all it's records in the .git dir. Everything outside that is just the current working set. | 12:05.04 |
| kens | Well, most ly its checked in I have some minor stuff in a stash | 12:05.08 |
| Robin_Watts | Again the stash is in the .git dir. | 12:05.20 |
| | Whenever you use reset --hard you're risking throwing away anything that's not checked in/in a stash. | 12:05.37 |
| kens | Won't let me delete the xps directory | 12:05.39 |
| Robin_Watts | try a checkout now. | 12:05.55 |
| kens | Need to skip past xps and gs and language_switch | 12:06.10 |
| | and main | 12:06.18 |
| Robin_Watts | sounds like you've got files open there. | 12:06.27 |
| kens | Hmm, possible. | 12:06.36 |
| | Let me close VS | 12:06.40 |
| Robin_Watts | presumably you're pushing your branch to your repo on casper periodically for safekeeping? | 12:07.10 |
| kens | Yes, but I would lose a few days because I haven't pushed the last 3 or 4 commits | 12:07.28 |
| | OK so I can't delete those directories, and I can't checkout | 12:07.59 |
| Robin_Watts | reboot. | 12:08.08 |
| kens | Yeah that was my next choice | 12:08.15 |
| Robin_Watts | 9.12 is broken. So it broke somewhere between 9.10 and 9.12 | 12:08.30 |
| | I'm going for a run. I'll let kens bisect. | 12:10.01 |
| kens | OK, well that seems better | 12:11.04 |
| | was able to delete the directories, and git checkout master worked | 12:11.20 |
| Robin_Watts | kens: just to recap what you may have missed... | 12:11.36 |
| | 9.10 works, 9.12 doesn't. | 12:11.41 |
| kens | Yeah I saw that | 12:11.45 |
| Robin_Watts | I'm going to let you bisect while I go for a run :) | 12:11.56 |
| kens | hopefully that'll make it wuick for Chris to bisect it | 12:11.56 |
| | OK thanks for that | 12:12.04 |
| Robin_Watts | np. | 12:12.09 |
| kens | Bugger, looks like I lost some of my changes at least | 12:14.39 |
| chrisl | If they were stashed, they should still be there | 12:15.00 |
| kens | nope, seem to be gone from the stash | 12:15.22 |
| | Its not desperate | 12:15.29 |
| | I know what I did | 12:15.37 |
| chrisl | Try looking at what reflog tells you | 12:15.43 |
| kens | last thing is a checkout of my branch, nothing suspicious | 12:16.08 |
| chrisl | The stash commits should be listed there, too | 12:16.26 |
| kens | Not going to worry about it. I think I'll push what I have to my repo though | 12:16.28 |
| | No no stash stuff | 12:16.36 |
| chrisl | Oh, maybe it doesn't list stashes, then :-( | 12:17.40 |
| kens | Like I said, not a big deal, I just moved some param processing form devices into the default param processing so that all devices get it without specific code. | 12:18.12 |
| | Because I was getting fed up of addin ghte same code over and over.... | 12:18.32 |
| chrisl | I'm not sure this bisect is going to yield useful results - I'm hitting a lot of commits that segfault | 12:20.32 |
| kens | Less than ideal | 12:20.59 |
| chrisl | It really depends if the segfault and the error are related | 12:21.20 |
| kens | I htink my repo is definitely borked. git says I need to stash or commit changes, but the changes aren't present in the source files..... | 12:22.22 |
| chrisl | You can try deleting the files is thinks have changed, and checking those files out again | 12:23.27 |
| kens | Those are (some of) the file that should have been in the stash | 12:23.52 |
| | And git gui says I have a pile of files (pretty much all of the repo) which have been deleted, and won't let me pull or anything until I correct the provblem. | 12:24.36 |
| | OK Well telling it to 'revert' seems to have got rid of the 'deleted files' | 12:27.21 |
| | SO I'm going to get some lunch, bbiab | 12:27.36 |
| tor8 | Robin_Watts: got a minute to talk about fz_page? | 13:28.52 |
| Robin_Watts | tor8: sure. | 13:40.47 |
| | kens: git revert is almost certainly not what you want. | 13:41.13 |
| | git revert prepares a commit that backs out another commit. | 13:41.23 |
| kens | I did it from git gui, so I don;'t know what command it ran, but it seems happy in my branch now | 13:41.47 |
| | Whgich it definitely wan't before | 13:42.02 |
| | Oh oh | 13:46.20 |
| | I accidentally added my branch to master | 13:46.27 |
| | Robin_Watts : can you see if I did add a branch called 'device_subclassing' to origin/master ? | 13:48.47 |
| Robin_Watts | You mean you accidently pushed it to golden ? | 13:48.48 |
| kens | Yeah that's what I mean | 13:48.55 |
| | At least, I htink I have, because I got an email | 13:49.03 |
| Robin_Watts | kens: I just got an email about it :) | 13:49.06 |
| | I can remove it. | 13:49.09 |
| kens | Please do | 13:49.12 |
| Robin_Watts | done. | 13:49.30 |
| kens | It was supposed to got to my remote 'kens', I'll do it form the command line | 13:49.38 |
| | Thanks. Says its up to date, so I hope it really is. Guess I shodl fix soemthing else and try again to be sure. | 13:50.17 |
| Robin_Watts | kens: what sha are you on? | 13:50.52 |
| kens | moment | 13:51.06 |
| Robin_Watts | http://git.ghostscript.com/?p=user/ken/ghostpdl.git;a=shortlog;h=refs/heads/device_subclassing | 13:51.15 |
| kens | f4e3dc88 | 13:51.20 |
| Robin_Watts | That shows what's on your remote repo. | 13:51.23 |
| | same as there then. | 13:51.32 |
| kens | Yep, that's the oe | 13:51.36 |
| | one* | 13:51.40 |
| tor8 | Robin_Watts: it's making headaches for FFI bindings, I'm experimenting with adding a JNI-style interface using mujs | 13:52.09 |
| | two ideas, (1) bind the fz_page to its fz_document at creation, (2) remove fz_page from the API (just use page numbers instead and skip load/free_page) | 13:52.40 |
| Robin_Watts | tor8: ok, how would you like to change it? | 13:52.41 |
| tor8 | (2) fits better how all non-pdf document types work | 13:52.59 |
| Robin_Watts | We have the concept of binding already, right? | 13:53.39 |
| tor8 | the main gotcha is fz_bound_page, which is going to be potentially slow for xps (since it needs to load the xml to get the page bounds) | 13:53.40 |
| | Robin_Watts: only with the context | 13:53.48 |
| Robin_Watts | various things get their ctx bound/ | 13:53.52 |
| | yeah, i was going to say, just with the ctx. | 13:54.01 |
| | Let me look how i handle this in the JNI branch. | 13:54.38 |
| tor8 | but for most clients, having to do loadpage/freepage with try/catch around error cleanups | 13:54.41 |
| | is a bit of an unneccessary hassle | 13:54.50 |
| | we could get away with the slowdown in paired bound/run-page calls by keeping a one-slot page cache in the document types that need it | 13:55.20 |
| | or bind the fz_page so all further uses of fz_page will not need a fz_document (nor a fz_context) | 13:55.43 |
| | although, remembering which functions take a fz_context and which don't is getting to be a hassle :/ | 13:56.06 |
| | I *alway* have to look at the headers when writing new code to remember :( | 13:56.19 |
| Robin_Watts | yeah, in the java code the Page object gets a Document object in it. | 13:56.45 |
| | So I'm binding effectively. | 13:56.51 |
| tor8 | Robin_Watts: yeah, so my thinking is to do the binding at the C level | 13:57.01 |
| | or do away with Page objects altogether | 13:57.07 |
| Robin_Watts | The problem with doing a 1 place cache is that the moment we have 2 threads doing stuff, the thread busts. | 13:57.34 |
| | cache busts. | 13:57.41 |
| tor8 | if creating a display list, we have the begin_page function call to set the page bounds | 13:57.44 |
| Robin_Watts | (I need to talk to you about display lists :) ) | 13:58.00 |
| tor8 | so from the display list, getting the page dimensions for creating a pixmap is fast | 13:58.12 |
| | okay. talk on. | 13:58.18 |
| Robin_Watts | after the page stuff. | 13:58.27 |
| tor8 | I think it's soon time to do some major rehauls of the API, getting close to 2.0 :) | 13:58.33 |
| Robin_Watts | I think I like the idea of binding pages to their document. | 13:58.50 |
| | I mean, it makes no sense to use a page with another document, right? | 13:59.08 |
| tor8 | so, add reference counting to fz_document, and make the fz_page struct reference counted and owning a reference to its parent | 13:59.28 |
| | Robin_Watts: yes. | 13:59.33 |
| Robin_Watts | sounds good to me. | 13:59.43 |
| tor8 | okay. will do the binding version then. | 13:59.56 |
| Robin_Watts | I got bored on saturday, and I started to rewrite the mupdf display list to be more space efficient. | 14:00.10 |
| | I've done the writing side. Got to do the reading side next. | 14:00.24 |
| | The actual device interface is unchanged. | 14:00.32 |
| tor8 | also, I want to (eventually) do something to make the context and free/close/drop naming more consistent | 14:00.33 |
| | okay. | 14:00.39 |
| | array instead of linked list? | 14:00.45 |
| | or linked list of arrays? | 14:00.52 |
| Robin_Watts | an array, but the nodes don't look like they did :) | 14:01.11 |
| tor8 | oh, and I am thinking about makin fz_path and fz_text reference counted | 14:01.19 |
| Robin_Watts | THere is a work in progress commit on a branch somewhere. | 14:01.26 |
| | fz_path being reference counted makes sense. | 14:01.32 |
| tor8 | so we don't need to copy the structs when creating the display list | 14:01.34 |
| Robin_Watts | fz_text less obviously, but OK. | 14:01.49 |
| tor8 | it's a remnant of an earlier design when we didn't use display lists as much, and reused the fz_path object in the interpreter by resetting it between each object | 14:01.57 |
| | which is no longer the case | 14:02.01 |
| Robin_Watts | yeah, ok, that makes sense. | 14:02.11 |
| tor8 | so creating it, then handing it off with reference counting, makes a lot more sense | 14:02.22 |
| Robin_Watts | It does. | 14:02.29 |
| | And we can use the current trick of having -2 mean "on the stack", -1 mean "static". | 14:02.49 |
| tor8 | yeah. I don't think we use any of those variants here though | 14:03.18 |
| Robin_Watts | aha: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=014dea59bbb0863e1e09e314550b460e3865c48d | 14:03.41 |
| | We use -2 and -1 for something. | 14:03.57 |
| | but they may not apply to paths. | 14:04.14 |
| | cos we are unlikely to make paths on the stack. | 14:04.27 |
| Robin_Watts | must dive into shower. | 14:04.39 |
| tor8 | Robin_Watts: looks reasonable, as long as the unpacking can be done somewhat less verbosely than the append_display_list dozens-of-arguments-function :) | 14:07.25 |
| | it might be easier to take the old fz_display_item struct on the stack and pack that into the fields for the array, and then unpack into the same struct on the reader side? | 14:10.06 |
| | but given that this is all private functions anyway, I'm not sure there's a lot to be gained | 14:10.45 |
| kens | Hmm setting -sDEVICE=psdcmykog gives me an error "*** C stack overflow. Quitting...." :-D | 14:11.48 |
| | Same for 9.15, 9.14, 9.12. 9.10 gives an error | 14:13.54 |
| Robin_Watts | tor8: unpacking should be much simpler. | 14:21.18 |
| | I suspect I want to add code to cope with "new matrix, same as the old matrix, but with new x and y" | 14:22.04 |
| tor8 | yeah, have matrix2x2 and translate parts separate | 14:23.06 |
| | not sure how much is gained by that though | 14:23.15 |
| Robin_Watts | I suspect in text rich documents, quite a lot. | 14:23.34 |
| tor8 | that state is already optimized in the fz_text struct | 14:23.35 |
| Robin_Watts | yeah, need to run some tests. | 14:23.55 |
| tor8 | but only the text matrix part, if it's done using the ctm then you'll likely benefit from optimizing that at the display list level as well | 14:24.24 |
| kens | I have no idea what's up wiht my Git today, its broken again :-( | 14:29.59 |
| | reboot, file system knackered again | 14:31.42 |
| tor8 | Robin_Watts: oh. do I need to add magic locking cruft to text/path reference counting? | 14:33.12 |
| Robin_Watts | tor8: Yes, I would think so. | 15:10.47 |
| | but making them fz_storable takes care of all that. | 15:11.12 |
| tor8 | fz_storable would be overkill | 15:22.38 |
| Robin_Watts | fz_storable is exactly what's needed I think. | 15:24.21 |
| | oh, no, maybe not. | 15:24.38 |
| | can't evict them etc. | 15:24.47 |
| tor8 | no, we don't want to cache the paths and texts | 15:24.47 |
| Robin_Watts | yeah. | 15:24.54 |
| tor8 | they'd be cached and evicted as part of the display list, if at all | 15:25.05 |
| Robin_Watts | yeah, fz_storable is bad. I was wrong. | 15:25.21 |
| chrisl | kens: it seems that the error from plib was introduced during the period it was segfaulting. I can pursue it further, but it will take a while | 15:26.10 |
| tor8 | Robin_Watts: unrelated griping, mixing fz_throw with other exception style code ... eek! | 15:27.03 |
| chrisl | kens: the problem is that the commit that resolves the segfault would appear to be the clist for transparency commit, which can't really be applied randomly to other vintages | 15:27.16 |
| Robin_Watts | where have I done that? | 15:27.18 |
| kens | chrisl can you point me to an approximate position ? I could scan the commits | 15:27.26 |
| tor8 | Robin_Watts: not you, but I've run into it when doing mutool js | 15:27.35 |
| Robin_Watts | tor8: Ah. | 15:27.43 |
| tor8 | have to be extra careful to not mix mujs's error handling (which uses longjmp) with fitz's | 15:27.55 |
| kens | Its annoying that we have commits which seg fault | 15:28.06 |
| tor8 | separate blocks of code that shall never mix | 15:28.08 |
| Robin_Watts | tor8: Was there a reason why mujs doesn't use fz_try/fz_catch too? | 15:28.23 |
| chrisl | kens: erm, I'd have to redo the bisect | 15:28.28 |
| Robin_Watts | No fz_context I guess. | 15:28.29 |
| tor8 | do-mujs-stuff, fz_try/fz_catch/rethrow-as-js, do-mujs-stuff | 15:28.30 |
| kens | chrisl not to worry just now. I will carry on fixing the ones I can | 15:28.43 |
| | the psdcmykog device seems also to have been broken for ages | 15:28.57 |
| tor8 | I use a simpler mechanism, and it has to do more voodoo in try/catch to save/restore the JS stack | 15:29.06 |
| kens | And when I try to bisect it screws up my Git | 15:29.06 |
| Robin_Watts | tor8: right. | 15:29.15 |
| tor8 | and it can be simpler since I have garbage collection in MuJS | 15:29.35 |
| chrisl | kens: it's *possible* that the clist/transparency commit both fixed the segfault *and* introduced the error..... | 15:29.41 |
| henrys | ugh I have the flu I'm going to do the 2 meetings and go back to bed! | 15:29.46 |
| tor8 | so most places in mujs simply don't care about potential exceptions, since everything will get cleaned up at garbage collection time | 15:30.00 |
| chrisl | henrys: do the meetings from bed! | 15:30.04 |
| Robin_Watts | henrys: ouch. | 15:30.06 |
| kens | chrisl, I'm surprised, because that doesn't change gs_init.ps | 15:30.09 |
| chrisl | kens: no, if it's causing an error to come from the device API where it previously didn't, or causes a different error from previously..... | 15:30.49 |
| henrys | so what's up with ghostscript.com? marcosw was going to take care of that? | 15:30.51 |
| kens | chrisl I guess its possible, but it seems 'odd'.... | 15:31.05 |
| henrys | and does that stop hintak from using @ghostscript.com anyway. It's just a username right? | 15:31.19 |
| marcosw | henrys: I was but haven't yet. | 15:31.35 |
| kens | henrys he should be told to stop using the mail address, because its no longer valid | 15:31.39 |
| henrys | kens: okay I'll put that on my list as soon as marcosw disables it. | 15:32.00 |
| kens | The consensus seems to be that he can change it. Or maybe a Bugzilla admin can change it for him | 15:32.09 |
| Robin_Watts | The issue is that by hintak posting to bugzilla as "hintak@ghostscript.com" it sounds like he's speaking in an official capacity. | 15:32.28 |
| henrys | fredross-perry: anything for the meeting? how are things going? | 15:32.29 |
| kens | Robin_Watts : its worse than that, to a naive user a ghostscript.com email address looks *more* authoritative than a artifex.com mail address | 15:32.59 |
| rayjj | morning, all | 15:33.08 |
| kens | morning rayjj | 15:33.14 |
| rayjj | I've read (most of) the foo about the planar device issue | 15:33.29 |
| kens | Its not just plib | 15:33.38 |
| fredross-perry | hi. I set aside the iOS/Android thing for a bit and have been working on replicating Michaelâs print dialog in gsview. Thatâs been going fine. | 15:33.42 |
| marcosw | I think we are using gs-bugs@ghostscript.com for the bug traffic mailing list, so I can't disable all email. | 15:33.44 |
| kens | Several devices do not/have not been working | 15:33.52 |
| | marcosw : that's a good point | 15:34.07 |
| rayjj | so, I've got Len sorted out and am going to dive into pending issues. If you want to throw it my way, fine | 15:34.08 |
| fredross-perry | henrys: stop typing and go to bed | 15:34.17 |
| rayjj | particularly if it looks clist related | 15:34.21 |
| kens | rayjj : we are having trouble bisecting it because the bisect hits an area where commits caused seg faults | 15:34.40 |
| chrisl | kens: can you give me a psdcmyk command line to try out? | 15:34.47 |
| kens | Just -sdevice=psdcmyk -o out.psd works for me | 15:35.09 |
| rayjj | kens: as long as we have a command line that fails now, I'm fine with just tracking it down | 15:35.12 |
| henrys | tor8: nothing back from urw I'm going to ping them again today. | 15:35.23 |
| | strange. | 15:35.25 |
| kens | THere's a command line in the logs that works with 9.10 and not 9.12 rayjj | 15:35.34 |
| rayjj | I do recall one psdcmykog issue that I had trouble reproducing | 15:35.38 |
| | kens: I'll try it now | 15:35.53 |
| kens | HOWEVER< currently the deskjet, psdcmykog and plib* devices are all broken | 15:35.55 |
| | I've 'fixed' thje deskjet device on my branch | 15:36.12 |
| marcosw | I've changed hin-tak's bugzilla login and emailed him to let him know (I had told him in October that we were going to disable @ghostscript.com email addresses). | 15:36.17 |
| chrisl | henrys: it is a bit worrying that URW have been dark for so long on this..... | 15:36.24 |
| henrys | fredross-perry: it's the downside of working at home.... | 15:36.31 |
| kens | I can't figure out what's wrong with the psdcmykog device at the moment, and the plib devices seem to be in the midst of a storm of duff commits | 15:36.45 |
| | marcosw that's ideal | 15:36.58 |
| henrys | marcosw: perfect | 15:37.09 |
| chrisl | marcosw: perfect! Thank you | 15:37.12 |
| rayjj | kens: I don't see a (complete) command line above | 15:37.34 |
| kens | There's one from robin | 15:37.41 |
| Robin_Watts | marcosw: Congratulations, btw :) | 15:37.44 |
| | gs/debugbin/gswin32c.exe -dBandHeight=300 -sDEVICE=plib -dMaxBitmap=1000 -o out.plib gs/examples/tiger.eps | 15:37.59 |
| | rayjj: ^ | 15:38.05 |
| kens | Yeah that one (me stops looking) | 15:38.13 |
| marcosw | Robin_Watts: thanks. I also fixed our dishwasher on Friday, so it was a doubly good day :-) | 15:38.24 |
| chrisl | marcosw: but was it also you that *broke* the dishwasher? | 15:39.08 |
| kens | thinks marcos is going for a MechEng PhD now | 15:39.31 |
| rayjj | kens: Robin_Watts: thanks. just found it. That one gets the Must have a BandHeight of at least 200 error | 15:39.33 |
| Robin_Watts | rayjj: Yup. | 15:39.44 |
| kens | rayjj that's one part of the problem | 15:39.49 |
| marcosw | chrisl: not really, a rubber hose developed a leak. | 15:40.09 |
| kens | gs_init.ps calls the device before reading the BandHeight from teh command line | 15:40.10 |
| | If you remove the error, then it passes along and reads the BandHeight, but seg faults when rendering | 15:40.30 |
| chrisl | marcosw: well, in that case, you really did have a good day! | 15:40.43 |
| rayjj | kens: I also see the *** C stack overflow. Quiting... with that command line changed to use psdcmykog | 15:40.44 |
| kens | rayjj yes, that's what's broken about psdcmykog, but its been broken for a while | 15:41.01 |
| rayjj | "calls the device" ? | 15:41.08 |
| | gs_init.ps always does a 'get_params' and then a put_params | 15:41.32 |
| kens | OK it calls putdeviceprops or whatever, it ends up in _put_params (or get_params) | 15:41.40 |
| mvrhel_laptop | sorry I am a bit late | 15:41.46 |
| rayjj | morning, mvrhel_laptop | 15:41.57 |
| mvrhel_laptop | good morning | 15:42.03 |
| kens | rayjj its where it resets the device after a change to media or resolution | 15:42.04 |
| rayjj | kens: OK. If you are busy elsewhere, I'll take a quick look | 15:42.34 |
| kens | I have to fix a number of tiff devices for my new code, and the mswinpr2 device which is 'weird' | 15:43.09 |
| henrys | the only other item I had was miles and scott are waiting for your comparison tor8, let me know when you have it. | 15:43.13 |
| tor8 | henrys: okay. | 15:43.40 |
| rayjj | kens: sounds like you have enough. I'll have a look at it, and ping you if I find anything | 15:44.19 |
| kens | OK thanks | 15:44.24 |
| | I have no idea what broke it, and chrisl ended up in grief trying to bisect it | 15:44.40 |
| chrisl | marcosw: oh, and a quick reminder, I don't think the customer has been notified about: http://bugs.ghostscript.com/show_bug.cgi?id=695774 | 15:44.49 |
| kens | We probably ought to exercise all the devices every once in a while | 15:44.57 |
| marcosw | kens: I was just checking my email and the one from Abin confuses me. have you read it and understand what's he's going on about? I'm not even sure what to ask for in terms of clarification (other than what version of Ghostscript he's using). | 15:45.04 |
| kens | marcos I have no clue what he's talking about no | 15:45.16 |
| chrisl | kens: we do, but we're only looking for segfaults, IIRC | 15:45.19 |
| kens | marcosw ask him to give you a simple GS command line and a single file | 15:45.33 |
| marcosw | chrisl: was just looking the recent commits and saw that you fixed it (yesterday was a holiday in the US (at least for some people, me included).. | 15:45.52 |
| kens | chrisl, I htink we need to do better than that. | 15:46.07 |
| | empty files or no files is also bad | 15:46.27 |
| chrisl | marcosw: no problem, it's just it took a little longer than normal..... | 15:46.29 |
| kens | I admit we cannot test some devices | 15:46.34 |
| chrisl | kens: I think the problem is some devices require weird options set | 15:46.52 |
| kens | chrisl well a one-off script that just gets *something* out would be enough | 15:47.10 |
| Robin_Watts | kens, marcosw: We should probably have a 'smoke test' for the devices where we run tiger.eps through every device. | 15:47.12 |
| marcosw | kens: I thought there may have been a command line in the zip file; but just checked and there doesn't seem to be. | 15:47.34 |
| kens | And the deskjet device *did* seg fault for me | 15:47.37 |
| | marcos he sent one in the email, but I cannot figure it out | 15:47.50 |
| marcosw | Robin_Watts: we do. Every commit is run with every device and checked for seg faults. | 15:47.58 |
| kens | Fundamentally, if they are modifying the outptu from ps2write, they are on a fast route to pain | 15:48.07 |
| | marcosw the desakjet device seg faults for me | 15:48.22 |
| Robin_Watts | marcosw: But not errors? How come the plib device being broken was missed? | 15:48.38 |
| kens | Because it tries to create a bitmap with 3 BPP | 15:48.39 |
| | The plib device doesn't seg fault, it throws an error | 15:48.52 |
| | as does psdcmykog | 15:48.58 |
| henrys | marcosw: right I thought we ran all the "example" files through every device don't we? | 15:49.10 |
| chrisl | Robin_Watts: maybe because it's not in the build? | 15:49.15 |
| marcosw | kens: you mean the cdeskjet device? that's been whitelisted as being known broken. | 15:49.21 |
| kens | I think I mean the deskjet device | 15:49.32 |
| Robin_Watts | chrisl: plib is in the build I beleive. | 15:49.34 |
| chrisl | Robin_Watts: I've had to add it to every test build I did - might be in more recent ones | 15:50.01 |
| kens | OK it was the cdeskjet device | 15:50.02 |
| marcosw | and the psdcmykog device doesn't produce an error: | 15:50.06 |
| | marcos@i7:[43]% ~/artifex/gshead -sDEVICE=psdcmykog -o test.psd ~/artifex/head/examples/tiger.eps | 15:50.11 |
| | GPL Ghostscript GIT PRERELEASE 9.16 (2014-09-22) | 15:50.12 |
| | Copyright (C) 2014 Artifex Software, Inc. All rights reserved. | 15:50.12 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 15:50.12 |
| | marcos@i7:[44]% | 15:50.12 |
| kens | What's the point of putting a known broken device in the build ? | 15:50.12 |
| | marcosw for me the psdcmykog device produces a 'C stack overflow' error | 15:50.36 |
| marcosw | kens: command line? | 15:50.49 |
| kens | Same as yours# | 15:50.59 |
| chrisl | Robin_Watts: plib is not in the default configuration on Unix builds | 15:51.01 |
| kens | let me recheck | 15:51.03 |
| Robin_Watts | chrisl: Fair enough. | 15:51.12 |
| chrisl | Robin_Watts: It *is* on Windows though, so I should probably add the family to the Unix builds | 15:51.46 |
| kens | Testing with "c:\program files (x86)\gs\gs9.14\bin\gswin32c" -sDEVICE=psdcmykog -sOutputFile=out.psd test.ps causes a seg fault | 15:53.45 |
| marcosw | kens: no idea. there are several devices which seg fault and have for years. As I recall we discussed removing them and decided not to but I can't remember why not. | 15:54.00 |
| chrisl | Robin_Watts: what type of output file do the plib devices create? PBM? | 15:54.16 |
| kens | Oddly, it doesn't wioth my debug build, which I w*know* produced a C stack overflow before | 15:54.25 |
| | marcosw : the only one which seg faults for me so far is cdeskjt | 15:54.43 |
| Robin_Watts | chrisl: Depends. | 15:54.48 |
| kens | cdeskjet | 15:54.49 |
| marcosw | === ghostpdl/gs/examples/tiger.eps === cdeskjet === | 15:54.54 |
| | === ghostpdl/gs/examples/tiger.eps === ijs === | 15:54.54 |
| | === ghostpdl/gs/examples/tiger.eps === oprp === | 15:54.54 |
| | === ghostpdl/gs/examples/tiger.eps === opvp === | 15:54.54 |
| | === ghostpdl/gs/examples/tiger.eps === rinkj === | 15:54.54 |
| | === ghostpdl/gs/examples/tiger.eps === uniprint === | 15:54.55 |
| Robin_Watts | They are either raw devices, or (if you define something like DEBUG_DUMP) they store pams. | 15:55.15 |
| kens | Well we can't test ijs and uniprint, don't know about the others | 15:55.16 |
| Robin_Watts | They are essentially example debug devices. They aren't for general peoples production use | 15:55.33 |
| kens | But it seems to me we should either fix the cdeskjet device or drop it | 15:55.49 |
| Robin_Watts | so not having them in the default build is not unreasonable. | 15:55.50 |
| chrisl | Robin_Watts: So they would be in the same class as the "bit" devices? | 15:56.00 |
| kens | If I change the '3' to '24' then it doesn't seg fault | 15:56.06 |
| Robin_Watts | chrisl: could be. | 15:56.10 |
| kens | If we take them out of the default build I won't care if they don;t work :-) | 15:56.25 |
| marcosw | actually cdeskjet doesn't seg fault, it produces an error: | 15:56.43 |
| | **** Unable to open the initial device, quitting. | 15:56.44 |
| kens | It seg faults for me on WIndows | 15:56.59 |
| | But either way is bad | 15:57.04 |
| chrisl | marcosw: how about we remove these broken devices from the default builds, and note in the release notes they are broken, if nobody steps forward to fix them, they will be fully removed? | 15:57.32 |
| kens | Of course, I could simply ignore all devices which didn't work *before* my current code changes, but it seemed reasonable to try and fix them. | 15:57.38 |
| | chrisl I'm not certain (apart from cdeskjet) that htey are broken, more 'untestable' | 15:58.04 |
| rayjj | the psdcmykog is getting a call to cmykog_print_page with prn_stream == NULL | 15:58.26 |
| | then I immediately get a stack exception | 15:58.45 |
| marcosw | kens: is anyone using the untestable devices? if not I like chrisl's suggestion of removing them from the default build. | 15:59.14 |
| kens | I can't nonw reproduce the C stack overflow, maybe that's only on a debug bui;d | 15:59.14 |
| | marcos I'd be happy to remove them | 15:59.25 |
| | But not the mswinpr2 device, which is also untestable, but not built on Linux (of course) | 15:59.43 |
| marcosw | rayjj: seems like that should be an issue on linux as well. | 15:59.45 |
| kens | Could be a bigger C stack | 16:00.05 |
| chrisl | marcosw: some of the devices we don't test fully are apparently still in use (I asked Till about it a while back) | 16:00.20 |
| rayjj | oops. No, it's not NULL, sorry | 16:00.29 |
| kens | will be quite happy to wash my hands of devices which were 'broken' before my changes :-) | 16:01.30 |
| rayjj | the stack overflow (on Windows) is when it tries to add 0x41360 to the stack. | 16:02.35 |
| fredross-perry | stepping out. cheers. | 16:02.45 |
| kens | bb fredross-perry | 16:02.51 |
| rayjj | the psd_write_ctx struct is the culprit I suspect | 16:03.07 |
| kens | rayjj on a different note, do we have accomodation booked for ski-ing yet ? | 16:03.14 |
| mvrhel_laptop | oh we also need to make reservations for monday evening | 16:03.36 |
| | someplace | 16:03.39 |
| rayjj | kens: yes, I'll forward that. It's right at the slopes at Copper | 16:03.44 |
| kens | mvrhel_laptop : tor and I already have a hotel booked Monday | 16:03.50 |
| marcosw | checked email and the irclogs and I can't see any discussion about removing or not removing the devices which generate an error or are untestable, but, based on our current discussion, it looks like we would have decided not to remove them because they "are apparently still in use" | 16:03.56 |
| mvrhel_laptop | oh where abouts? | 16:03.56 |
| kens | rayjj great! Thanks for that | 16:03.57 |
| | mvrhel_laptop : one moment | 16:04.03 |
| rayjj | mvrhel_laptop: I think kens and tor8 did at a microtel | 16:04.11 |
| kens | Yeah that's the one | 16:04.20 |
| mvrhel_laptop | ok | 16:04.27 |
| kens | Microtel Inns DIA | 16:04.29 |
| | Came out at £36 I think about $55 | 16:04.45 |
| rayjj | mvrhel_laptop: If you don't like that one, you can book wherever | 16:04.49 |
| kens | Including a breakfast | 16:04.50 |
| rayjj | kens: that sounds fine to me | 16:05.01 |
| kens | It had a 7.2 rating | 16:05.14 |
| rayjj | I have to get my flights in, and book the hotel | 16:05.19 |
| mvrhel_laptop | yes. I will take a quick look today. rayjj what time do you get in? | 16:05.24 |
| rayjj | kens: probably a lot of international travelers that compare it to youth hostels ;-) | 16:05.42 |
| chrisl | marcosw: I know a couple of the contrib devices are untestable, but are supposed to be still in use | 16:05.55 |
| kens | At that price, its a fair compariosn :-) | 16:05.56 |
| rayjj | mvrhel_laptop: don't have flights yet | 16:05.56 |
| | mvrhel_laptop: you got my voicemail about the sax, right. I'll send the tracking info shortly as well | 16:06.25 |
| mvrhel_laptop | rayjj: yes. thanks! | 16:06.35 |
| rayjj | I have to run my son to school. | 16:06.36 |
| mvrhel_laptop | ttyl | 16:06.39 |
| rayjj | mvrhel_laptop: shipping was only $32 (plus the $5 for the cardboard boxes I wrapped it in) | 16:07.12 |
| mvrhel_laptop | awesome. | 16:07.22 |
| rayjj | mvrhel_laptop: I just emailed the tracking # | 16:16.12 |
| mvrhel_laptop | rayjj: great. | 16:16.20 |
| rayjj | bbiaw... | 16:16.21 |
| mvrhel_laptop | kens: no rooms available at Microtel Inns DIA on that date | 16:24.10 |
| | you guys must have gotten the last room | 16:24.19 |
| kens | mvrhel_laptop : sorry about that :-( | 16:29.44 |
| | I went through booking.com, they didn't have any directly | 16:30.01 |
| rayjj | mvrhel_laptop: It looks like its estimated delivery is Thursday. FedEx ground was $10 cheaper than UPS. And the thing I had a hard time understanding is that UPS still had a $2.50 "Fuel Surcharge" | 16:49.42 |
| mvrhel_laptop | rayjj: yeah. I am sure they are a little slow at getting rid of that | 16:51.46 |
| rayjj | mvrhel_laptop: just like airlines -- fast to add it, slow to remove it | 16:53.22 |
| mvrhel_laptop | kens: ok I did get a room at microtel DIA | 16:53.36 |
| | through the same place as you | 16:53.41 |
| rayjj | the problem with psdcmykog is *not* psd_write_ctx, but is the cmykog_process_arg_s that has: char spot_name[GX_DEVICE_COLOR_MAX_COMPONENTS][gp_file_name_sizeof]; | 16:54.57 |
| mvrhel_laptop | rayjj: so your address is the P.O box 3114? | 16:56.11 |
| chrisl | rayjj: ah, and we upped the gp_file_name_sizeof significantly :-( | 16:56.37 |
| rayjj | the gp_file_name_sizeof] was increased to 4096 by chrisl in commit fe0b8fcf | 16:57.08 |
| | I can fix that by allocating that struct | 16:57.39 |
| mvrhel_laptop | bbiab | 16:57.53 |
| chrisl | rayjj: Strange. I did go through the code looking for places that did stuff like that, with a view to making them heap allocated rather than stack.... I guess I missed that one | 16:58.35 |
| rayjj | chrisl: I guess so. It's easy enough to fix and shouldn't cause any performance problems since it's once per "print page" cycle | 16:59.42 |
| kens | mvrhel_laptop : good news on the room, we'll see you there :-) | 17:00.20 |
| | Well that's all the tff devices excetp tiffsep1 sorted. | 17:06.11 |
| | Leaves me a couple of awkward devices to look at. ENough for one day, goodnight everyone | 17:07.00 |
| rayjj | *** The following 16073 regression file(s) had differences but matched at least once in the previous 25 runs *** :-0 | 17:31.09 |
| | should I worry about that ? | 17:31.31 |
| | mvrhel_laptop: tor8: kens (for the logs): I sent the email with the condo info. | 17:31.58 |
| mvrhel_laptop | rayjj: thanks! | 17:32.19 |
| rayjj | note the "ski right to the back door" -- that's good because you're tired and don't want to walk afterwards :-) | 17:35.15 |
| tor8 | doubts he'll fit in the bunk bed. | 17:40.01 |
| | rayjj: fab. | 17:40.10 |
| rayjj | chrisl: if you are still around, can you check my commit for the psdcmykog stack overflow? | 17:44.56 |
| | chrisl: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=95dad9a567fec70a1fb8cee89664bd6088367dc8 | 17:45.33 |
| | I'd like to commit that so I stop seeing the XX,XXX Differences that matched once in the last 25 | 17:46.33 |
| chrisl | rayjj: give me a minute..... | 17:47.27 |
| rayjj | chrisl: It does run, BTW | 17:47.50 |
| chrisl | rayjj: Looks fine to me | 17:48.25 |
| rayjj | is customer #1 licensed for mupdf ? | 17:52.19 |
| | They (Jung) sent a "newbie" question that to support | 17:53.10 |
| mvrhel_laptop | argh. i just screwed myself with git trying to fix this commit that was 3 down in my list | 18:18.53 |
| Robin_Watts | rayjj: "the sample .net project provided" | 18:19.09 |
| | That sounds like they are trying Mvrhel's stuff. | 18:19.29 |
| | mvrhel_laptop: Don't panic. | 18:19.39 |
| mvrhel_laptop | well yes. I think I do need to panic | 18:19.47 |
| Robin_Watts | We can get it back. | 18:19.50 |
| mvrhel_laptop | In this case I dont think so | 18:19.56 |
| Robin_Watts | Trust me. | 18:20.00 |
| mvrhel_laptop | ok | 18:20.04 |
| | let me tell you what I did though | 18:20.11 |
| rayjj | although you may be hunting around in your "refs" a bit :-) | 18:20.30 |
| Robin_Watts | so, do you have any changes in your tree at the moment that haven't been committed at some point or another ? | 18:20.35 |
| mvrhel_laptop | I was wanting to fix the commit that was 3 down in the mupdf list that I had you review | 18:20.40 |
| | one issue is that I needed to add the gsprint files and project | 18:20.51 |
| | at one point I added them | 18:21.05 |
| Robin_Watts | added and committed them ? | 18:21.22 |
| mvrhel_laptop | but then I realized I had done this incorrectly (I was not doing the it as a rebase with edit) | 18:21.24 |
| | so I did a hard reset to start all over | 18:21.37 |
| | and it removed those files | 18:21.45 |
| | :( | 18:21.48 |
| | yes, added and commited | 18:22.05 |
| Robin_Watts | mvrhel_laptop: hard resets are a bad thing. You should always feel a little bit of panic when you hard reset. | 18:22.10 |
| mvrhel_laptop | yes | 18:22.17 |
| Robin_Watts | those are one of the few times that you can lose data. | 18:22.25 |
| | BUT... as long as you've actually committed at one point or another, the information is there to be saved. | 18:22.41 |
| mvrhel_laptop | yes I did | 18:22.55 |
| Robin_Watts | So, you're going to have to leave the comfort of tortoise though. | 18:23.06 |
| mvrhel_laptop | I have git bash open | 18:23.15 |
| Robin_Watts | In your git bash window, do: git reflog | 18:23.28 |
| | This will give you a big list of hashes and the first line of various commits. | 18:24.03 |
| | Effectively this is a log of all the hashes that you've been using recently. | 18:24.22 |
| mvrhel_laptop | oh cool | 18:24.32 |
| Robin_Watts | The odds are that one or more of them will have what you want in it. | 18:24.52 |
| mvrhel_laptop | so how do I reset to one of them? | 18:25.09 |
| Robin_Watts | So, the trick is to find out what commit is which. | 18:25.16 |
| | Your best bet is to leave the git reflog open in one window, and to bring up another window. | 18:25.34 |
| mvrhel_laptop | ok | 18:26.11 |
| Robin_Watts | Then in that second window, you can use gitk to check out the hashes from the first window to find the one you want. | 18:26.12 |
| mvrhel_laptop | ok | 18:26.21 |
| Robin_Watts | gitk <hash> | 18:26.23 |
| | I'll let you do that then we'll carry on when you've found the one you want. | 18:26.49 |
| mvrhel_laptop | thanks Robin_Watts ! | 18:26.55 |
| Robin_Watts | (You may want more than one, of course. One might be what you want master to be reset too, then you might want to cherry pick another one in to get your missing files) | 18:27.18 |
| marcosw | mvrhel_laptop: there are still xpswrite regressions with images. I've opened a new bug: http://bugs.ghostscript.com/show_bug.cgi?id=695790 | 18:27.33 |
| mvrhel_laptop | marcosw: ok thanks | 18:28.24 |
| | Robin_Watts: yes. If I can get the files back then I will be all set | 18:28.35 |
| | marcosw: that is interesting. I will have a look at that today | 18:29.13 |
| Robin_Watts | mvrhel_laptop: A trick to remember in future. If you ever find yourself wanting to do: git reset --hard, don't. | 18:29.51 |
| | Do: git stash && git stash drop | 18:30.01 |
| mvrhel_laptop | ok | 18:30.26 |
| marcosw | mvrhel_laptop: thanks. it will be nice to have this fixed, makes looking at the nightly regression differences easier if those are gone. | 18:30.32 |
| Robin_Watts | It does the same (in most of the cases you'll ever care about), but it has the nice side effect of leaving a ref in the reflog that you can use to save the day if it goes wrong. | 18:30.44 |
| marcosw | chrisl: speaking of regressions: your fix for 695774 has caused a few (57,000+) regressions :-) Unfortunately 20,000 of them are not considered minor by the nightly regression system so I'll either have to redefine what minor means or look at a lot of bitmaps. | 18:31.07 |
| chrisl | marcosw: I checked a *large* number of the changes, and all the ones I looked at were progressions. | 18:32.01 |
| marcosw | chrisl: i agree, none of the ones I've looked at were regressions. | 18:33.40 |
| chrisl | marcosw: there'll be lots of diffs when we update Freetype when the next release comes out, too | 18:34.55 |
| Robin_Watts | marcosw: Can you run a regression thing before chrisl's commit? and then from after chrisl's commit to current? | 18:35.06 |
| | That way you eliminate the possibility of missing changes caused by other commits in the chrisl-flood. | 18:35.48 |
| marcosw | Robin_Watts: yes, but then I will miss any regressions caused by chrisl's changes :-) | 18:38.28 |
| Robin_Watts | marcosw: It means you can then use statistical sampling on chrisl's changes and feel better about it :) | 18:38.56 |
| | (or a higher level of fuzz) | 18:39.11 |
| marcosw | mvrhel_laptop: there are also color issues with some images with the current xpswrite when read by the GhostXPS but Windows 7 opens the files correctly, so I'll open a bug in GhostXPS. | 18:39.19 |
| mvrhel_laptop | marcosw: ok thanks | 18:39.42 |
| marcosw | Robin_Watts: I'll probably change the definition of minor, which means I don't look at the images, at least for this commit. All of the changes are very small, there are just a lot of them on each page. Currently for a change to be minor the changes have to be small and there can't be too many of them. | 18:41.04 |
| mvrhel_laptop | Robin_Watts: found it | 18:48.55 |
| | whew | 18:48.57 |
| Robin_Watts | mvrhel_laptop: Git keeps sha's around for about a month before discarding them. | 18:49.28 |
| | so, you want to do: git checkout master (to change back onto master) | 18:49.59 |
| | then: git reset --hard SHA (to make master point at the SHA you just found from the reflog) | 18:50.19 |
| | (this is one case where you really do have to use git reset --hard) | 18:51.02 |
| mvrhel_laptop | ok and the files are now back | 18:52.33 |
| Robin_Watts | and all your other commits ? | 18:53.05 |
| mvrhel_laptop | thanks Robin. this particular part was a pain to get working so rewriting would have really sucked | 18:53.06 |
| Robin_Watts | np. | 18:53.14 |
| mvrhel_laptop | well the other commits I have on my repos | 18:53.16 |
| | and I have them as patches here | 18:53.26 |
| | I can reconstruct this whole thing now | 18:53.34 |
| Robin_Watts | ok. | 18:53.39 |
| mvrhel_laptop | I now understand that I should have done the rebase marking the one commit to be edited | 18:54.11 |
| | and then during the rebase made the fixes | 18:54.31 |
| | is that correct? | 18:54.34 |
| Robin_Watts | yes. | 18:55.12 |
| | Or if it was just adding some files to a commit, I'd have done it differently. | 18:55.47 |
| | I'd have committed the files as a new commit. | 18:56.04 |
| | Then I'd have rebased and reordered that commit to just after where they should have gone, and squashed the two together. | 18:56.28 |
| | That would minimise the amount of work I was doing manually within the rebase. | 18:56.53 |
| | but whatever works :) | 18:57.00 |
| mvrhel_laptop | well it was adding files and editing a file | 18:57.05 |
| Robin_Watts | That would have worked too, potentially, as the new commit could have had the edit in too. | 18:57.29 |
| | (but it increases the chance of a merge conflict as you reorder the commits of course) | 18:57.50 |
| mvrhel_laptop | right | 18:57.57 |
| | Robin_Watts: so right now I have 4 commits. The top one I would like to squash with the bottom one. Any thoughts? | 19:02.50 |
| Robin_Watts | git rebase -i HEAD~10 | 19:03.11 |
| | Cut the last line, and move it up 2 lines. | 19:03.30 |
| mvrhel_laptop | dumb network... | 19:04.00 |
| Robin_Watts | Then change it from 'pick' to 's' | 19:04.19 |
| | Save and exit the editor. | 19:04.27 |
| mvrhel_laptop | waiting for logs to catch up.... | 19:04.39 |
| Robin_Watts | You didn't miss anything. I was uncharacteristically quiet :) | 19:05.02 |
| | git rebase -i HEAD~10 | 19:05.05 |
| | Cut the last line, and move it up 2 lines. | 19:05.07 |
| | Then change it from 'pick' to 's' | 19:05.11 |
| | Save and exit the editor. | 19:05.14 |
| mvrhel_laptop | ok hold on | 19:05.18 |
| | ok that worked I was able to move the one and squash them | 19:11.56 |
| mvrhel_laptop_ | let me check that everything builds and is here. I will then have you take a quick look if you will | 19:12.42 |
| mvrhel_laptop | ok this network def is having problems. need to move to a new spot | 19:13.02 |
| | I will from now on stay away from hard resets. I think I now have a good understanding of the history reworking | 19:15.21 |
| | ok everything builds | 19:15.34 |
| | Robin_Watts: ok so now the 3 commits you reviewed before are on my repos. The HEAD~3 commit is the one that has the fixes you wanted (and were needed). I fixed the commented stuff and also added the missing project and files | 19:17.37 |
| Robin_Watts | This is... mupdf? | 19:17.56 |
| mvrhel_laptop | Robin_Watts: yes sorry | 19:18.01 |
| Robin_Watts | np. Just got to context switch :) | 19:18.10 |
| | Urm... | 19:18.46 |
| | gsprint.cpp: #define FAIL -1; | 19:18.57 |
| | The semicolon there seems... odd. | 19:19.07 |
| mvrhel_laptop | yes | 19:19.20 |
| | let me fix that | 19:19.24 |
| Robin_Watts | other than that, all looks good. | 19:22.40 |
| mvrhel_laptop | Robin_Watts: ok thanks. I will fix that commit to golden then take a quick look at the regressions from marcosw, then I have a commit for you to review for SOT | 19:23.12 |
| Robin_Watts | ok. | 19:23.25 |
| mvrhel_laptop | Robin_Watts: oh I had dinner last night with Jeong Kim. He is our Korean contact and drives us around when we are there | 19:24.30 |
| Robin_Watts | ah. | 19:24.41 |
| mvrhel_laptop | he was asking me if SOT had capability to html5 output. he has a product that does pdf to html5 output | 19:25.50 |
| Robin_Watts | mvrhel_laptop: Currently, no, it doesn't. | 19:26.09 |
| | We could do a 'dumb' output thing by running through the display list and outputting as html. | 19:26.39 |
| | but as ever the trick would be to find a way to preserve document structure. | 19:27.03 |
| mvrhel_laptop | right. | 19:28.59 |
| | can't find the english site https://www.epapyrus.com/product-2-1/ | 19:30.00 |
| | I think he might want to use the conversion to pdf in SOT and then through his stuff to get html5 | 19:32.16 |
| Robin_Watts | mvrhel_laptop: Ah. | 19:32.27 |
| | His site says "Ms-Office" | 19:32.45 |
| mvrhel_laptop | hmm not that I can read... | 19:33.36 |
| | I think he is meeting with miles tomorrow | 19:33.54 |
| Robin_Watts | See the "Active-X Plug in image" ? | 19:34.04 |
| | Move one down, and one right from there. | 19:34.09 |
| | According to google chromes "Translate to English" feature.... | 19:34.57 |
| | "A variety of document formats" | 19:35.04 |
| | "Ms-Office, Hancomm Office and various image formats" | 19:35.12 |
| mvrhel_laptop | well that might be vapor ware | 19:35.34 |
| Robin_Watts | Whenever I see stuff like that I do wonder if they are running a picsel derived lib :) | 19:35.45 |
| | it might. | 19:35.55 |
| mvrhel_laptop | Robin_Watts: it could be | 19:36.04 |
| | ok. fixed the semicolon without any git hitches. I think I am a pro at this now | 19:38.36 |
| Robin_Watts | In medicine they call that "See one, Do one, Teach one" :) | 19:40.50 |
| mvrhel_laptop | yes. I guess I need to do the teach one. Problem is I think I was the slowest one in the class on this topic | 19:41.20 |
| | special ed | 19:41.33 |
| | marcosw: you there? | 19:48.43 |
| | interesting that it looks like mupdf also has an issue with CATX0988.pdf | 19:49.38 |
| | with the same image | 19:49.43 |
| | it is smeared in the same manner too. | 19:54.09 |
| zeniko | Robin_Watts: have you had a chance to look at the few patches on zeniko/mupdf WRT xref issues? | 19:57.17 |
| | tor8: Robin_Watts: (or FTL) there's two further small bug fixes on zeniko/mupdf for unbreaking some edge case documents we've recently encountered in the wild | 19:58.12 |
| mvrhel_laptop | interesting. the image in the file is OK. it must be a geometry issue in the xps content | 19:58.25 |
| Robin_Watts | zeniko: I am afraid I have not. | 19:58.42 |
| | I'm swamped in other stuff at the moment. | 19:59.00 |
| mvrhel_laptop | path data is wacky | 19:59.51 |
| zeniko | Robin_Watts: given how small the patches are, they shouldn't bitrot too much (unless tor8 goes even more crazy than as with his tor/drop branch) | 19:59.56 |
| | just don't forget to include them before the next release | 20:00.21 |
| mvrhel_laptop | lunch time. bbiab | 20:01.35 |
| | Forward 1 day (to 2015/01/21)>>> | |
IRC Logs