| | <<<Back 1 day (to 2012/08/19) | 2012/08/20 |
| mfwitten | Anybody here a maintainer of MuPDF? | 01:35.04 |
| | When you release new packages for `http://mupdf.com/download | 01:37.26 |
| | When you release new packages in `http://mupdf.com/download/', please include those new packages in the `archive' subdirectory (`http://mupdf.com/download/archive/') as well. | 01:38.07 |
| | The reason is that there needs to be a `permalink' so that certain software packages can be guaranteed a URI that is useable in the long-term. | 01:38.51 |
| | If you only move a package into `archive' when it gets replaced by a newer version, then the URI disappears, and software that depends on it breaks | 01:40.48 |
| | So, please, from the very beginning, put a link in `archive' as well. | 01:41.05 |
| ray_laptop | back from Yosemite :-( | 06:48.52 |
| | It was a really great visit. First time for the kids. Temp was great, very light rain as we drove in, then the afternoon before we left, but it was so light and warm we didn't even need raincoats | 06:50.10 |
| | The rain helped stoke up the falls a bit (Yosemite falls and Bridal Veil). Vernal Falls was really full even though it's a dry year. | 06:51.14 |
| | and swimming in the Merced river was fun, and the water wasn't so cold -- we stayed in it for a couple of hours each day. | 06:52.09 |
| | morning, kens | 06:52.15 |
| kens | mornign ray_laptop | 06:52.27 |
| ray_laptop | was there anything interesting in the IRC logs last week that I should go read ? | 06:53.02 |
| kens | I don't remember tehre being anything important, IIRC we cancelled teh Tuesday meeting | 06:53.38 |
| ray_laptop | kens: yes, I saw that. | 06:57.31 |
| kens | ray_laptop : then I htink you are as up to date as you need to be :-) | 06:57.50 |
| | There were som e discussions about specific bugs, but nothing important really | 06:58.16 |
| ray_laptop | kens: thanks. I noticed that henrysx6 is still throwing sporadic problems (8/17 logs) | 07:02.26 |
| kens | ray_laptop : I think that one is reminiscent of reports from other sources. the gsromfs1.c file being corrupted | 07:02.53 |
| | So there may be a genuine problem of some kind, but its obscure and intermittent | 07:03.12 |
| ray_laptop | kens: right -- that's what hit me once and robin once. marcosw ran stress testing but didn't see anything | 07:03.46 |
| kens | ray_laptop : I think we've also had a couple of reports from the field too. | 07:04.07 |
| ray_laptop | I guess until it gets more prevalent, we can just tolerate it | 07:04.11 |
| kens | FOr now I think we have to.... | 07:04.26 |
| ray_laptop | kens: I've reviewed all the email. The main thing I have to jump on is the report from cust 532 | 07:04.50 |
| | but it's files they can't send me, so I have to go there. :-( | 07:05.10 |
| kens | Yes, I'm afraid nobody else can really contribute there | 07:05.18 |
| ray_laptop | well, any one of us that has a Windows laptop _could_ visit them and do the on site analysis, but for anyone else it involves MUCH more travel. Marcos is the next closest person | 07:06.25 |
| kens | That was kind of what I meant ;-) | 07:06.44 |
| ray_laptop | and marcosw HATES windows (not that I blame him) | 07:06.47 |
| kens | I can't see Marcos willingly using a Windows laptop | 07:06.56 |
| ray_laptop | kens: the good thing is that I've made minor tweaks to their source and makefiles so that I can build a "standalone" (gswin32c.exe) and skip the simulator | 07:07.48 |
| kens | Well, that must help a lot! | 07:08.03 |
| ray_laptop | kens: it helps a lot IF I can duplicate the failure with standalone gswin32c, and if I can't duplicate it, it helps me be able to focus on the areas that are specific to the simulator mode | 07:09.11 |
| kens | Well, finished reading, back to Linearisation :-( | 07:10.26 |
| ray_laptop | and off to sleep for me ... | 07:10.46 |
| kens | I would think so :-) Goodnight ray_laptop | 07:10.56 |
| Robin_Watts | Morning paulgardiner | 08:55.02 |
| kens | Ah, a Robin_Watts | 08:55.13 |
| paulgardiner | hi Robin. Where are you now? | 08:55.18 |
| Robin_Watts | Home. | 08:55.24 |
| paulgardiner | Oh right. I'd lost track of time. | 08:55.44 |
| Robin_Watts | Just trying to track down adeo.pdf for bug 693272 | 08:57.14 |
| kens | Robin_Watts : would you mind looking at a PDF file, and telling me what's wrong with it ? | 08:57.59 |
| Robin_Watts | I'll have a look, sure. | 08:58.10 |
| kens | I'll mail it to you, just a moment | 08:58.21 |
| | File sent. | 08:59.37 |
| Robin_Watts | ok. I'm downloading mail to my main machine at the moment. This may take a while :) | 08:59.59 |
| kens | When I poen it in Acrobat X, it insists on repairing it, but I can't figure out why.... | 09:00.00 |
| Robin_Watts | Got it. | 09:07.42 |
| kens | tor8 (logs) Robin_Watts paulgardiner would someone like to take a very quick look at this one on Stack Overflow please ? | 09:08.13 |
| | http://stackoverflow.com/questions/12034701/android-mupdf-pdf-viewer-silenty-crashed-due-to-low-memory-after-13-pages | 09:08.13 |
| | May be necessary to ask the user for the PDF file of course. | 09:08.50 |
| Robin_Watts | The '0' figure for the /H entry looks wrong to me. | 09:08.52 |
| kens | Robin_Watts : its a dummy | 09:09.03 |
| | I don't write a proper hint stream yet | 09:09.10 |
| | Its just a 0 length stream | 09:09.20 |
| Robin_Watts | endobxref ? | 09:09.47 |
| kens | It is possible that is what its complaining about though | 09:09.51 |
| | Oooh, I missed that, wehere is it ? | 09:09.58 |
| Robin_Watts | Line 11 | 09:10.04 |
| kens | I see it, that must be caused b y rewriting the xref, thanks | 09:10.17 |
| Robin_Watts | I'd guess that that was the one. | 09:10.31 |
| kens | I'll find out in a minute :-) | 09:10.39 |
| | OK Acrobat 7 is happy with it now, but 9 and X still complain. | 09:13.58 |
| | I'm going to assume that they are whining about the Hint stream for now. | 09:14.11 |
| | Which means I have to tackle that next :-( | 09:14.48 |
| sebras | morning tor88! | 10:37.35 |
| Robin_Watts | sebras has either had too much coffee, or is under the impression that tor8 is hung over. | 10:39.24 |
| tor8 | morning all | 10:39.44 |
| | ugh, I think I overslept... | 10:39.51 |
| Robin_Watts | tor8: I got the tiger.pdf the right way up with my latest patch. | 10:40.37 |
| | The device is still monstrously over simple, but it does at least represent a start. | 10:41.02 |
| sebras | Robin_Watts: 88 means double joy in chinese. 88 is also the name of an ice cream in .se. and judging by what tor writes I think he might need both. | 10:41.57 |
| tor8 | mmmm. ice cream. but no thanks to the heils. | 10:42.46 |
| sebras | tor8: hm... 88 apparently has more connotations than I can find over at wikipedia... | 10:43.51 |
| tor8 | sebras: http://en.wikipedia.org/wiki/88_(number)#As_a_Neo-Nazi_symbol | 10:44.33 |
| sebras | realizes that he was reading about 88 (the year). :) | 10:45.18 |
| | tor8: btw, according to the corollaries of godwin's law you lost the debate. | 10:47.38 |
| tor8 | right. back to work then. | 10:47.50 |
| kens | Hmm, I see a restriction in the hint table which is not obvious from teh rest of teh specification. After linearisation the 'second' page is supposed to have an object number of 1. My code doesn't follow that :-( | 10:50.23 |
| sebras | tor8: there is a patch for you over at sebras/master | 10:51.02 |
| Robin_Watts | kens: Urgh. | 10:51.22 |
| | I wonder if my code gets that wrong too. | 10:51.33 |
| kens | Robin_Watts : its not entirely obvious but it is *implied* in the earlier documentation. I chose to ignore it because it wasn't stated specifically | 10:51.57 |
| | FWIW I'm looking at table F.4 on page 1042 | 10:53.30 |
| | of the PDF reference manual | 10:53.38 |
| | Item 1 | 10:53.45 |
| | "The first object of the first page has an object number that is the value of the O entry in the linearization parameter dictionary at the beginning of the file. The first object of the second page has an object number of 1" | 10:53.57 |
| Robin_Watts | Ah, right. I do follow that. | 10:54.35 |
| kens | Presumably this explains the earlier statement (which I thought was bogus) about the pages tree being at the end 'because it isn't consolted' | 10:54.55 |
| Robin_Watts | I was generating the pages tree with my new mupdfwrite stuff without /Parent pointers, and Apple Preview refused to accept the file. | 10:56.14 |
| | I can't for the life of me see how it could be needing the parents pointers, but... | 10:56.27 |
| kens | Interesting | 10:56.33 |
| | Well the parent is really only supposed to allow you to navigate the tree without holding the entire tree in memory | 10:57.05 |
| | But I don't think anything uses it | 10:57.13 |
| Robin_Watts | Indeed. And this was a 1 page file. | 10:57.18 |
| kens | I think it is a required key though :-) | 10:57.34 |
| | So... technically invalid :-) | 10:57.44 |
| | I guess Acrobat was happy.... | 10:57.55 |
| tor8 | Robin_Watts: good work on the mupdf pdf write device! I have two stylistic gripes though (I can't be all positive you know): | 10:58.34 |
| kens | Oh great, the hint tables require me to keep track of which pages share the shared objects.... | 10:58.45 |
| Robin_Watts | kens: Yes. It's a git. | 10:58.55 |
| kens | Its crackers.... | 10:59.02 |
| Robin_Watts | tor8: go on :) | 10:59.08 |
| tor8 | 1) you've forgot your whitespace settings in your editor again ;) | 10:59.12 |
| | 2) memcpy(&ctm, &otherctm, sizeof(fz_matrix)) could be written as ctm = otherctm; | 10:59.12 |
| Robin_Watts | tor8: 1) Yeah, I've never got the whitespace settings for emacs working right. | 10:59.38 |
| | 2) I thought some compilers had problems with structure assignments? | 10:59.57 |
| tor8 | Robin_Watts: we use them all over the place already | 11:00.13 |
| Robin_Watts | Fair enough then. | 11:00.18 |
| tor8 | I used to be afraid of the same thing a few years back, then I did some actual tests and I've never run into any compiler that has problems with struct assignments | 11:01.17 |
| | the only thing to watch out for is garbage in any padding if doing memcmp | 11:01.39 |
| Robin_Watts | Something I hadn't forseen was that because the device interface takes composed matrices, we have to keep inverting them in order to get the matrices to write into the pdf stream. | 11:03.27 |
| | Not sure there is any alternative though. | 11:03.51 |
| tor8 | Robin_Watts: q/Q wrapping | 11:08.58 |
| Robin_Watts | The device really needs to keep a graphics stack. | 11:09.16 |
| tor8 | every time you need a new matrix, check if it is different and if so then Q q ... cm | 11:09.23 |
| Robin_Watts | Right. I fear that will create larger files than we need. | 11:10.04 |
| tor8 | or at least keep the current state so we only write diffs | 11:10.14 |
| | it'll compress well ;) | 11:10.56 |
| Robin_Watts | Yeah, I invert the current matrix, then multiply that inverse with the supplies one. That gives me the 'change' matrix that needs to be written into the stream itself. | 11:11.28 |
| tor8 | Robin_Watts: yeah. matrix inversion scares me though, but that may just be due to my history in 3d graphics... | 11:12.23 |
| | Robin_Watts: I've been trying out git submodules for the thirdparty libraries | 11:32.18 |
| Robin_Watts | ah. any conclusions? | 11:34.15 |
| tor8 | we'll need more employee training :) | 11:35.07 |
| | I set up thirdparty gits on http://git.ghostscript.com/ | 11:35.43 |
| | freetype is a mirror of upstream | 11:35.49 |
| | the others are tarball snapshot archives | 11:35.55 |
| | figured we'd want the submodules to point to repositories we host ourselves, in case upstream goes down or moves | 11:36.22 |
| Robin_Watts | makes sense. | 11:37.23 |
| sebras | tor8: what about jbig2dec? did you git submodule that too? | 11:38.08 |
| tor8 | I have a script to make tarball snapshots with the date stamp and author set to upstream (so we don't "steal" credit) | 11:38.17 |
| | jbig2dec is also submoduled to our main jbig2dec repo | 11:38.31 |
| sebras | tor8: sweet. let me know when the patches go in. | 11:38.51 |
| tor8 | Robin_Watts: I wanted to ask about the openjpeg stuff. the latest thirdparty.zip uses 1.5.0 + patches from svn | 11:39.09 |
| Robin_Watts | yes. | 11:39.18 |
| tor8 | I was thinking to put those patches on a branch on our thirdparty mirror and reference that branch from the submodule | 11:39.31 |
| Robin_Watts | specifically, it uses the SVN versions of the patches that we have passed them. | 11:39.44 |
| | OK | 11:39.58 |
| tor8 | until such a time as we upgrade to their next release | 11:40.00 |
| Robin_Watts | That sounds reasonable. | 11:40.21 |
| tor8 | Robin_Watts: right. so it's "diff && patch" from their svn not taking a specific svn release from them? | 11:40.25 |
| Robin_Watts | It's "take the snapshot", "unpack it", apply 2 specific SVN patches. | 11:41.07 |
| | so it's not a given SVN revision, no. | 11:41.26 |
| | it's snapshot + r1730 + r1728 (or something like that - it's in the readme) | 11:41.54 |
| tor8 | Robin_Watts: right. I'll do the equivalent for the thirdparty git then. | 11:42.08 |
| | and stick the patches on an 'artifex' branch | 11:42.20 |
| Robin_Watts | That's equivalent to what I've done for the v8 repo. | 11:42.57 |
| paulgardiner | Robin_Watts, tor8: a few commits on paulg/forms if you have a moment. | 12:53.16 |
| tor8 | Robin_Watts: sebras: tor/master for thirdparty submodules | 12:54.07 |
| | Robin_Watts: I guess linux distro people's need to compile with system libraries outweighs my desire to simplify the makefile to only allow building with the submodule checkouts | 12:55.11 |
| Robin_Watts | mmm | 12:55.45 |
| paulgardiner | "submodule" as in git submodule? | 13:04.51 |
| tor8 | paulgardiner: yup | 13:05.19 |
| paulgardiner | So did we decide to go with submodule rather than subtree... or have we been using submodules for a while now and I just hadn't realised? | 13:06.24 |
| tor8 | paulgardiner: we're going with submodules for the mupdf thirdparty libraries | 13:06.42 |
| | paulgardiner: the subtree stuff was in how we maintain the jbig2dec.git separately from ghostpdl.git where we do the jbig2dec development | 13:07.03 |
| paulgardiner | I guess we don't tend to often make our own changes to thirdparty stuff and wish to push it back. | 13:08.32 |
| tor8 | paulgardiner: quite. we prefer to use stable releases whenever possible. | 13:09.24 |
| paulgardiner | And subtree would make the mupdf repo huge. Does using submodules allow for things like git-bisect across thirdparty changes? | 13:10.55 |
| tor8 | paulgardiner: yes, that's the hope at least. git submodule isn't super well integrated with the other git commands, but with a bit of care it's possible | 13:12.46 |
| | you just have to remember to do 'git submodule update' | 13:12.56 |
| Robin_Watts | Whenever you change the SHA? | 13:13.34 |
| tor8 | Robin_Watts: whenever the SHA changes, yes | 13:13.58 |
| Robin_Watts | Right. | 13:14.05 |
| tor8 | the submodule is 'just' a directory with an associated commit sha in the git directory tree snapshot | 13:14.36 |
| | and the .gitmodules file has the association between directory and upstream git repository | 13:14.58 |
| paulgardiner | Do submodules have any advantages over use of subtree, other than not making the repo huge? | 13:15.16 |
| tor8 | paulgardiner: you keep the submodule's history out of the main repo's history (for git log etc) | 13:16.26 |
| paulgardiner | Is that an issue when we take on new versions at most monthly? (Not sure I completely understand subtree yet, but I'd have thought the thirdparty libraries own commits would be only on their branches). | 13:18.35 |
| | ... and our own branches woukl have infrequest thirdparty commits when we merge in a new version. | 13:19.24 |
| Robin_Watts | Are submodules/subtrees both parts of standard git builds ? | 13:20.13 |
| paulgardiner | I think they are now. | 13:21.44 |
| Robin_Watts | http://zanematthew.com/blog/2012/01/git-subtree-git-submodules-with-wordpress/ | 13:26.29 |
| | submodules give problems when cloning? | 13:26.43 |
| | The consensus from my brief google is that git submodule is a mess. | 13:28.52 |
| | Would it be worth trying to make a git subtree based version and then comparing them ? | 13:29.21 |
| paulgardiner | He seems to like the approach for which subtree was thought up: i.e., to develop a library as part of the projects that use it. | 13:29.24 |
| | aaah . dislike I mean | 13:29.51 |
| Robin_Watts | I'm not sure I see how a git subtree based repo will be any bigger than a git submodule based one. | 13:31.31 |
| paulgardiner | AFAIK it means making it all one repo, but with special branches that represent the different thirdparty libraries. | 13:32.20 |
| Robin_Watts | paulgardiner: Having it all as 1 repo seems like a big win to me. | 13:32.47 |
| paulgardiner | Yes, me too, if size isn't an issue. | 13:33.05 |
| Robin_Watts | I suspect with subtree, the SHA's are different. | 13:33.07 |
| sebras | Robin_Watts: how is submodules a pain when cloning? | 13:33.52 |
| Robin_Watts | (i.e. if I have libA which has release 1.0 which has SHA 0123456, and I have that as a subtree in my project, thirdparty/libA, then even on that branch the SHA for 1.0 won't be 0123456 | 13:34.01 |
| | sebras: I'm parroting what I've read and not-really understood in the hopes that people that know more can tell me I'm wrong | 13:34.38 |
| sebras | Robin_Watts: GStreamer uses submodules for some scripts common to each of its plugin gits | 13:35.08 |
| paulgardiner | Robin_Watts: a single thirdparty commit can appear on different branches in different ways, on some branches as though the library is root, and on other as though in a subdirectory. I Ssume too that that would make the shas different. | 13:35.33 |
| Robin_Watts | paulgardiner: Oh, if it can appear in different ways, then I'd have hoped that the SHA might be the same... | 13:36.11 |
| sebras | cloning there is not difficult by any means, its basically a git clone and a git submodule update. | 13:36.30 |
| Robin_Watts | Given we seem to have problems persuading some of the engineers in the company to read the basic git docs, I am slightly wary of introducing anything that is going to require them to do more steps. | 13:36.33 |
| paulgardiner | Robin_Watts: I don't think so, but merge --subtree and split move between the two. | 13:36.43 |
| sebras | Robin_Watts: as far as I know upating amounts to a git pull in the normal case and a git pull && git submodule update whenever GStreamer's thirdparty has updated. | 13:37.19 |
| Robin_Watts | http://debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb | 13:38.50 |
| paulgardiner | Robin_Watts: it's just like a commit can appear on two different branches with different shas, and the sha changes when you rebase. The only extra thing is that the files positions can be in the root on some branches and in a subdirectory on others. | 13:39.49 |
| sebras | Robin_Watts: right but then there is nothing connecting your project to a particular commit for each fake submodule... | 13:40.14 |
| Robin_Watts | But the SHA with the code in the root will be the same | 13:40.17 |
| | sebras: I'm still trying to parse it. | 13:40.38 |
| | (I mean the separate libA.git and the branch of the subtree with the stuff in the root will have the same SHAs?) | 13:41.12 |
| paulgardiner | Robin_Watts: It might be. I'd assumed not because it is a commit with a different effect: it makes the same changes but to effectively different files | 13:41.27 |
| | Robin_Watts: ah yes sorry | 13:41.39 |
| Robin_Watts | Why are they not the same files? | 13:41.45 |
| | Ah, right. | 13:41.55 |
| paulgardiner | No you are right | 13:41.57 |
| Robin_Watts | I could believe that there is some invisible 'git submodule' glue in that that screws it up. | 13:42.14 |
| | But if not, git subtree sounds pretty ideal to me. | 13:42.25 |
| mfwitten | When you release new packages in `http://mupdf.com/download/', please include those new packages in the `archive' subdirectory (`http://mupdf.com/download/archive/') as well. The reason is that there needs to be a `permalink' so that certain software packages can be guaranteed a URI that is useable in the long-term. If you only move a package into `archive' when it gets replaced by a newer version, then the URI disappears, and ... | 13:42.37 |
| | ... software that depends on it breaks. So, please, from the very beginning, put a link in `archive' as well. | 13:42.45 |
| Robin_Watts | mfwitten: That seems like a reasonable request. | 13:43.01 |
| | (Possibly we should always just put stuff into archive, and have softlinks down to it) | 13:43.20 |
| mfwitten | Sure | 13:43.30 |
| paulgardiner | Robin_Watts: that was my feeling too, other than the possibility of making the repo many time bigger (e.g., if you are developing a small app that uses huge libraries) | 13:43.34 |
| tor8 | mfwitten: right, will do. | 13:43.40 |
| mfwitten | Great! | 13:43.46 |
| | Thanks! | 13:43.49 |
| tor8 | mfwitten: done. | 13:44.08 |
| Robin_Watts | paulgardiner: Yeah. So with git subtree, people don't have an option of getting a git version WITHOUT the thirdparty sources in. | 13:44.16 |
| | So everyone gets v8. | 13:44.45 |
| paulgardiner | Robin_Watts: Yes. | 13:44.54 |
| tor8 | the way submodules work internally in git is something I find very elegant and straight forward. the plumbing to the various other git commands is a bit lacking though. | 13:46.24 |
| | I'll update my git and play with a git subtree variant as well, and see how that pans out | 13:47.30 |
| sebras | tor8: http://www.betaful.com/2011/01/i-love-git-subtree/ the command at the end of the blog post seems useful. | 13:48.21 |
| tor8 | apart from the size issue (which I find a bit disconcerting, just v8 is probably ten times the size of mupdf) another problem with subtree is that it's a new addition to git, and as such a lot of our engineers won't have it | 13:48.26 |
| sebras | tor8: though I would expect the SHAs to differ from upstreams. | 13:48.33 |
| tor8 | sebras: depends, you can have a multi-rooted git repository no problem | 13:49.35 |
| | but the subtree 'merge' would have to mess with the file paths, and if it does that on import then you'll have different sha sums | 13:50.19 |
| sebras | tor8: oh, ok. something tells me that git log/logg will not be as easy to parse any more... | 13:50.20 |
| paulgardiner | Actually the thirdparty branches wouldn't really be part of our repo. They are fetched branches of the thirdparty repos. In our repo, we'd have thirdparty commits only for version updates... I think. | 13:50.36 |
| tor8 | sebras: I'll have to play with it to see exactly what it does though | 13:50.37 |
| sebras | tor8: sure. keep us posted. :) | 13:50.49 |
| tor8 | paulgardiner: yeah, but those commits where we 'merge' the thirdparty branches they'll have pointers (I'd think) back to the branches | 13:51.15 |
| | and as such, they'd be included in our repo whenever you clone | 13:51.34 |
| paulgardiner | Ah yes. | 13:51.46 |
| tor8 | if they're just branches that files are copied from, without any commit linkage, then that's a different issue | 13:52.05 |
| Robin_Watts | v8 is 121 Meg. | 13:52.26 |
| paulgardiner | There may be an option I'ver read about that leaves them disconnected, but maybe I'm making that up. | 13:52.26 |
| tor8 | then you won't have the size, but neither will you have the history | 13:52.29 |
| paulgardiner | tor8: yes | 13:52.43 |
| Robin_Watts | no, that's the built version, sorry. | 13:52.50 |
| paulgardiner | I see what you are saying | 13:52.53 |
| | You'd have trouble when you next merge | 13:53.05 |
| Robin_Watts | My v8 source repo including windows binaries etc is 1Gig. | 13:55.44 |
| tor8 | quite a bit bigger than the 22M mupdf's .git takes | 13:56.21 |
| Robin_Watts | Yes. | 13:56.26 |
| paulgardiner | There are ways we could squash the commits between major versions so we wouldn't include all the history, but we could still repeat merges. | 14:02.59 |
| tor8 | paulgardiner: from a first naive attempt at using subtree, here is what I see: | 14:03.25 |
| | it pulls in the remote repository as a separate 'line' of history with the same sha1's as upstream | 14:04.21 |
| | then you get a 'merge' commit that renames all the files to the 'prefix' where you want them | 14:04.39 |
| | and the merge commit has a parent link back to the upstream imported branch | 14:05.00 |
| | so you get the size from the imported repo as well | 14:05.44 |
| paulgardiner | Yes, as you predicted above | 14:05.49 |
| Robin_Watts | If you have the same SHAs then you must have the same history. | 14:06.11 |
| | hence the same size. | 14:06.16 |
| paulgardiner | You could make an intermediate branch where you squash the commits. | 14:06.18 |
| Robin_Watts | I am grudgingly thinking that submodules may be the only way to go because of the size issue. | 14:06.36 |
| paulgardiner | Robin_Watts: yep, it's looking that way. | 14:06.50 |
| tor8 | Robin_Watts: quite. | 14:07.02 |
| paulgardiner | In any case, can we sensibly include the v8 build in our build. | 14:07.12 |
| tor8 | there is a --squash option to toss the history | 14:07.15 |
| Robin_Watts | But the point of this exercise is to keep the history, right? | 14:07.42 |
| tor8 | Robin_Watts: yeah, or we could just pull in tarball archives in our own git | 14:07.56 |
| paulgardiner | Will either submodule or subtree gain us much for libraries where we don't include their build in ours? | 14:08.11 |
| Robin_Watts | The attraction of submodules/subtrees is that: 1) we can commit changes back to the origin easily (e.g. jbig2dec fixes) | 14:09.00 |
| | 2) we can bisect properly. | 14:09.07 |
| | With v8 we'll never want to have it building with ours. | 14:09.45 |
| | but we will want to have the different versions in there so we can bisect them I guess. | 14:10.00 |
| | actually, that's gonna be really ugly :( | 14:10.18 |
| tor8 | Robin_Watts: due to the size of v8, may I suggest we make a v8-binary-build only git that we can reference? | 14:10.44 |
| paulgardiner | might be best to commit built libs for some third party stuff... and then subtree might become feasible again | 14:10.54 |
| Robin_Watts | tor8: Sure. But even that is 60Meg per configuration | 14:11.12 |
| tor8 | yeah, so not something we want to include in mupdf.git but could well work as an external submodule | 14:11.34 |
| Robin_Watts | (so {release,debug} * {x86,amd64,macos} | 14:11.40 |
| tor8 | ugh. why so huge? how big is spidermonkey? | 14:11.46 |
| Robin_Watts | binaries. debugging info etc? | 14:13.13 |
| tor8 | Robin_Watts: source was my main concern | 14:13.32 |
| Robin_Watts | A checkout is much smaller. | 14:14.03 |
| paulgardiner | I v8 going to be a pain either as a submodule or a subtree - I mean a pain to have to check it out at all. | 14:23.13 |
| | s/I/Is/ s/$/?/ | 14:23.34 |
| Robin_Watts | Well, at the moment, I have archives for the build versions of v8 on different platforms. | 14:24.33 |
| | and the cluster just grabs the relevant one on each machine. | 14:24.48 |
| | This works fine as long as we NEVER UPDATE THE VERSION OF V8 WE ARE USING. :) | 14:25.09 |
| paulgardiner | But if the binaries were in our repo. | 14:25.25 |
| Robin_Watts | If we had a new repo with the binaries in, we'd be fine. | 14:25.44 |
| | except that repo would be large. | 14:25.52 |
| | 250Meg of tgz's for all the current platforms, for a single version. | 14:26.57 |
| paulgardiner | Make the build fetch the appropriate version from our servers? Yucky I know. | 14:28.22 |
| Robin_Watts | I might be tempted to leave v8 as a special case for now. | 14:28.54 |
| tor8 | git subtree --squash has a couple of practical benefits -- it's essentially just including snapshots of the third party sources in our tree, but with easier merging of changes later. it bloats our repo (but not as much as without --squash) and it makes it more difficult to work with different upstream versions than git submodule lets you | 14:29.40 |
| paulgardiner | sounds sensible. So with v8 out of the picture, does subtree still make the repo huge? | 14:29.48 |
| tor8 | with git submodules you can bisect the upstream without touching our main repo while looking for bugs, etc | 14:30.05 |
| | paulgardiner: it'll probably double the size or more, just due to the size of the source of freetype and openjpeg | 14:30.32 |
| | zlib, libjpeg, and jbig2dec are tiny enough that I don't care | 14:30.58 |
| paulgardiner | tor8: Yeah, I think size kills it. I don't understand the thing about git-bisect. I'd have thought that would just work and iwthout any special hooks. | 14:31.34 |
| tor8 | openjpeg is annoying in that they *also* include their third party dependencies in their source archives | 14:31.39 |
| Robin_Watts | Damn them doing the same thing we want to do! | 14:32.07 |
| paulgardiner | Robin_Watts: :-) | 14:32.16 |
| tor8 | and doubly annoying, because they only do it because their command line tools (which we don't even build) need them | 14:32.39 |
| paulgardiner | tor8: ah you mean bisecting to find the library change that caused the problem? | 14:33.07 |
| tor8 | I guess that's also one reason I'd prefer submodules, it keeps other people using our source from having that same problem | 14:33.12 |
| | paulgardiner: yeah. when the submodule is its own repo you can do a lot of stuff | 14:33.26 |
| | just gotta be careful to keep the repos in sync with "git submodule update" or "git add ...path-to-submodule" | 14:33.54 |
| | when you want them in sync, that is :) | 14:34.16 |
| paulgardiner | tor8: but then isn't it difficult to use bisect to find one of the main project commits that caused a problem, if the branch spans library versions? Or does submodule handle that? | 14:35.00 |
| tor8 | paulgardiner: when bisecting the main repo, you have to call 'git submodule update' at each revision | 14:35.31 |
| | which should (IMO) be done automatically but isn't | 14:35.39 |
| | so after switching branches or pulling, you also have to call "git submodule update" | 14:36.04 |
| paulgardiner | tor8: Oh right of course. | 14:36.14 |
| tor8 | still, our current situation with mupdf-thirdparty.zip is way worse | 14:36.20 |
| | for size, repository hygienic, and playing nice with distro reasons, I prefer submodules. | 14:37.36 |
| Robin_Watts | So... if we make the mupdf repo use submodules... | 14:38.31 |
| | then I clone the mupdf repo, does that automatically clone the submodules too ? | 14:38.46 |
| tor8 | for ease of use, subtrees have a lot of benefits, but won't let git power users do everything they might want | 14:38.53 |
| | Robin_Watts: no. that too requires a second step. (which allows you to build with system libraries if you omit it) | 14:39.13 |
| | git clone .../mupdf.git && cd mupdf && git submodule init && git submodule update | 14:39.30 |
| Robin_Watts | Right. | 14:39.54 |
| tor8 | git pull && git submodule update | 14:39.58 |
| | git checkout && git submodule update | 14:40.02 |
| | etc... | 14:40.06 |
| | cd thirdparty/jpeg && git checkout new-release | 14:40.42 |
| | git add thirdparty/jpeg && git commit | 14:40.47 |
| henrys | kens:can you ask 693287 what imaging server he is using. | 14:41.52 |
| kens | OK henrys | 14:42.03 |
| tor8 | hm, git subtree --squash loses the ability to easily (read: automatically) push changes upstream with a simple command | 15:02.42 |
| paulgardiner | tor8: but would you in any case often need to rebase your changes anyway? | 15:04.23 |
| tor8 | paulgardiner: yeah, but git can do that for you if you have the right history linkage | 15:05.11 |
| | I worry that squashed subtree's lose that capability | 15:05.20 |
| | s/'// | 15:05.24 |
| paulgardiner | Presumably the squashed commit links back to the same point in the branch from which the commits that were squashed eminate, which is the main thing I'd have thought you need for subsequent merges. | 15:08.17 |
| tor8 | paulgardiner: the commit has a special line in it for 'git-subtree' use | 15:08.47 |
| | I doubt 'git-rebase' is smart enough to look at that | 15:08.59 |
| paulgardiner | Might have to use the horrid --onto | 15:10.31 |
| tor8 | anyway, gotta go. ttyl. | 15:11.57 |
| saper | is it possible to convert Adobe Type 1 font definition to pure PostScript (Type 3)? I just need one character that uses few subroutines (in /Subr) | 15:23.22 |
| kens | saper, yes it is possible | 15:42.06 |
| sebras | tor8: you need to adjust ThirdParty.mk for android as well. | 16:01.30 |
| henrys | saper:have you tried http://onlinefontconverter.com/? curious how good the quality is. I'm sure fontforge does it also and many commercial will export as type 3 | 16:03.08 |
| saper | henrys: right now I have reverse engineered my character using the (c) false charpath { exch == == ( moveto ) print } { exch == == ( lineto ) print } { exch == == exch == == exch == == ( curveto ) print } { ( closepath ) print } pathforall | 16:10.03 |
| | crude but it seems to work :) | 16:10.26 |
| kens | Yes, that should work fine. Of course you lose all the hinting information, but you cna't use that in a type 3 anyway | 16:12.34 |
| saper | it's for one character only | 16:13.10 |
| | lowercase c | 16:13.18 |
| | I have its Type 1 definition (/c { 0 550 hsbw -14 76 hstem 484 76 hstem 55 95 vstem 488 526 rmoveto 170 4 callsubr -50 23 -53 11 -55 0 rrcurveto -170 -105 -109 -178 hvcurveto -176 105 -111 164 vhcurveto 171 4 callsubr 61 0 53 12 50 23 rrcurveto 83 vlineto 170 4 callsubr -51 -28 -51 -14 -52 0 rrcurveto -117 -67 77 134 hvcurveto 133 67 78 117 vhc | 16:14.08 |
| | urveto 169 4 callsubr 52 0 51 -14 51 -28 rrcurveto 84 vlineto closepath endchar } | 16:14.13 |
| | but that's kind of hard to use - or is there an operator I just can give it to? | 16:14.32 |
| henrys | if it is for a specific resolution device you could render it as a bitmap and preserve hints | 16:14.41 |
| | well the hints would be reflected in the output | 16:14.58 |
| kens | You cannot pass the type 1 decoded instructions to anything in PostScript. | 16:15.21 |
| saper | it's for a logo so hints are not important - it will stay vectored | 16:15.23 |
| kens | saper, hints are to do with vector data. | 16:15.57 |
| | When using fonts | 16:16.01 |
| | All the hstem etc in the character description there. | 16:16.20 |
| saper | isn't that "hstem/vstem" operators? | 16:16.24 |
| kens | Yes, they supply the hints | 16:16.31 |
| | Note that *none* of what you have there is PostScript. | 16:16.57 |
| saper | but I can't use them in the normal drawing | 16:16.59 |
| kens | Its human-readable equivalents to the type 1 encoded charstring operations | 16:17.14 |
| | Normally they are eexec encrypted | 16:17.50 |
| | The operators can only be used in the context of a type 1 font description by the type 1 font interpreter (NOT the PostScript itnerpreter) | 16:18.30 |
| saper | so the sentence "Type 1 fonts use a subset of PostScript operators" are false | 16:19.29 |
| | s,are,is, | 16:19.32 |
| kens | Not exactly. | 16:19.38 |
| | But in a certain sense, yes | 16:19.57 |
| saper | things like hstem vstem are normally not expressible in PostScript (unless one writes a Type 1 engine in PS) | 16:20.06 |
| kens | Correct. | 16:20.12 |
| | BTW where is that sentence to be found ? | 16:20.20 |
| saper | oh there is markhint.ps | 16:24.54 |
| kens | saper where did you find the sentence "Type 1 font use a subset of..." ? | 16:25.39 |
| saper | let me check | 16:26.06 |
| | "Type 3 font (also known as PostScript Type 3 or PS3, T3 or Adobe Type 3) consists of glyphs defined using the full PostScript language, rather than just a subset. " is not the same | 16:28.04 |
| kens | Not really, no | 16:28.14 |
| henrys | hmm another compile fail on henrysx6 have to talk to marcosw about it. | 16:28.34 |
| kens | The marking operations in a type 1 font are a subset of the marking operations in PostScript, buyt they aren't the same operators | 16:28.48 |
| saper | so ghostscript uses freetype to render type 1? | 16:28.53 |
| kens | Since version 9.0 yes | 16:29.00 |
| | Also TrueType | 16:29.07 |
| | (rather more importantly) | 16:29.14 |
| saper | and before 9.0? We've had our own interpreter? | 16:29.37 |
| kens | The Artifex interpreter/renedering engine is still there | 16:29.53 |
| | if you set -dDisableFAPI it gets used instead | 16:30.04 |
| | However, it is *stringly* deprecated and *will* be removed at some point | 16:30.23 |
| saper | base/gxhintn.c and so on? | 16:30.39 |
| kens | strongly* :-) | 16:30.41 |
| | saper I don't remember which source files. | 16:30.53 |
| | Seems that is the hinting algorithm for the type 1 hinter, yes | 16:31.34 |
| saper | yep, and the base/gstype1.c is the entry point | 16:31.51 |
| | thank you, this is fascinating | 16:32.02 |
| kens | gstype1 is the old type 1 interpreter | 16:32.05 |
| | OK time for me to be off. Goodnight everyone | 16:35.37 |
| henrys | Robin_Watts:welcome back | 17:39.06 |
| Robin_Watts | thanks. | 17:39.26 |
| henrys | did you see the thing about memento and jbig2dec from zeniko? | 17:39.43 |
| Robin_Watts | Vaguely. | 17:39.55 |
| | 2 regressions came in, so I've been looking at those. | 17:40.22 |
| henrys | yes much more important to look at that. | 17:42.47 |
| Robin_Watts | I think I disagree with him. | 17:46.37 |
| | It's important that memento should be included in the public header if at all, if we return pointers to malloced blocks. | 17:47.07 |
| | Memento already is at pains to make sure that the header only does anything on the first include. | 17:48.01 |
| | and the idea is that Memento_label etc should be defined even in non memento builds. | 17:48.44 |
| | Let me comment on the bug. | 17:48.49 |
| henrys | paulgardiner:you should be able to access everything with bugzilla now. | 17:48.54 |
| | paulgardiner:let me know if you have problems. | 17:49.12 |
| Robin_Watts | I think the change to the size of ref's caused gs to tickle valgrind :( | 18:16.06 |
| | alexcher ^ | 18:16.09 |
| | Various places make ref's on the stack, causing bits of them to be uninitialised. | 18:16.44 |
| | and valgrind then whinges that we look at those bits during gc. | 18:17.01 |
| alexcher | z`Robin_Watts: The change of thge ref size has been reverted. | 18:24.14 |
| Robin_Watts | ok. I was running slightly "back in time", so may have missed that. | 18:24.40 |
| alexcher | Robin_Watts: original refeence also has unused parts for sone of the ref types. | 18:25.35 |
| | Robin_Watts: for instance, mark or null | 18:26.08 |
| Robin_Watts | right, but valgrind shouldn't trip over it. | 18:26.25 |
| alexcher | Robin_Watts: when the reference is written to a file, it's checked. | 18:27.40 |
| Robin_Watts | alexcher: I've patched around the problems for now, so valgrind is silent. | 18:30.43 |
| | but alas the valgrind run doesn't SEGV. | 18:30.54 |
| | I'll look again at the ref stuff after I find the SEGV. | 18:31.44 |
| mvrhel_laptop_ | hi Robin_Watts | 20:14.53 |
| | hmm I wonder why mvrhel_laptop is already in use everytime I come on now | 20:23.35 |
| mvrhel_laptop | aha. The other IRC client is using it | 20:24.06 |
| henrys | Robin_Watts:does zeniko ever come around IRC with a different name? | 22:17.27 |
| | that you know about | 22:17.35 |
| | or maybe tor8 knows | 22:22.17 |
| Robin_Watts | henrys: not as far as I am aware. | 22:22.29 |
| henrys | how much has this person contributed to mupdf - getting to the point he doesn't want to surrender copyright - we shouldn't have accepted anything from him without that | 22:24.13 |
| | I guess I should be more diligent looking at mupdf changes also I mainly focus on legal issues on the gs side. | 22:26.42 |
| Robin_Watts | henrys: Really? he's being awkward? | 22:31.03 |
| | We spotted that we didn't have anything in place a while ago, and made a point of trying to get it sorted. | 22:31.36 |
| | Last I heard he was talking to miles about some official wording. | 22:31.55 |
| henrys | everything that goes to miles ends up with me and then it comes back to you and tor8 I love this place | 22:33.30 |
| Robin_Watts | He's done small packages of work here and there. He's very good at finding problems. | 22:34.17 |
| henrys | anyway I certainly don't want to compensate or give copyright to zeniko. If he wants to work on bountiable bugs great. | 22:34.18 |
| Robin_Watts | His fixes are often not quite right, but often have some underlying truth. | 22:34.51 |
| | Like the memento thing; I think he may be right, and I should remove it from the public header. | 22:35.07 |
| | but his fix was wrong. | 22:35.13 |
| henrys | what is involved with pulling out any of his work and redoing if he won't surrender copyright. | 22:35.45 |
| | ? | 22:35.49 |
| Robin_Watts | pass. | 22:35.54 |
| henrys | something for tor8 I guess. | 22:36.34 |
| tor8 | oh boy. we discussed this last time didn't we? | 22:37.02 |
| | he's got a few isolated spots of his patches, but most of the stuff we've taken on had to be reworked in one way or another | 22:38.10 |
| | and we've deliberately avoided taking on some of the bigger features he's done, like the gdi+ device | 22:38.42 |
| henrys | phone for a minute | 22:41.13 |
| tor8 | henrys: Robin_Watts: the latest email about the assignment form was from march 19 this year (subject: Copyright assignment form for SumatraPDF) | 22:41.19 |
| | I haven't heard anything since then | 22:41.38 |
| Robin_Watts | Yeah, 19th March. | 22:43.40 |
| | In fact on 19th March, he sent us a document of a copyright assignment letter from another (google) project that he said he was prepared to sign. | 22:46.33 |
| henrys | the retroactive bounties seem reasonable to me, but there is a chance he'll say no in which case we'll have to undo his work, is that an option? | 22:50.19 |
| Robin_Watts | I guess it's a question of how much you think we have to excise. | 22:51.15 |
| | If it's "every line that's ever been touched as a result of something he's said" then it's a lot. | 22:51.52 |
| | If it's "noticable chunks of work" then it's less. I can't remember exactly without checking. | 22:52.40 |
| | BUT... we had an informal agreement with him about everything up to 1.0, I thought. | 22:52.58 |
| | and we haven't taken much since. | 22:53.08 |
| henrys | I am rather concerned about having a relationship with this character. The few exchanges I've had have been unpleasant I guess I'll start to talk with him about retroactive bounties. | 22:58.34 |
| Robin_Watts | henrys: Could tor8 and I see the latest emails from him please, so we know what the state of play is? | 22:58.44 |
| | I've tried to tread carefully with him, and I think my relationship with him is OK if you'd like me to have a try? | 22:59.34 |
| henrys | sure I have only seen a clipped up response from Miles, I'll get the complete email and send it to you guys. | 23:02.09 |
| | though I don't know if I want to tread lightly, let's just tell him he can have retroactive bounties that we discuss and agree on and we'd like him to participate in the bounty program if he chooses. I know it seems like he's doing good but that's not my experience with characters like this when you look at results long term. | 23:07.39 |
| | I forwarded the email | 23:10.16 |
| | we can pay someone like paulgardiner to redo any work if your worried about tor and Robin man-hours | 23:12.43 |
| Robin_Watts | henrys: OK, I've read the mail. It would indeed to be nice to read the email train leading up to this point to see at what point it started to go off the rails. | 23:15.00 |
| | I'm off to bed in a mo, but I'll check email etc in the morning. | 23:16.04 |
| henrys | yes I've asked miles to send it to me and I'll send it as soon as I have something. | 23:16.10 |
| tor8 | given his rather angry attitude in general I'd be perfectly happy to just ignore anything from him that isn't explicitly handed to us on a silver platter in our bugzilla. | 23:17.43 |
| | I find it rather bad manners to offer open source contributions under an informal agreement and then start asking for money after the fact... | 23:18.21 |
| | sebras: stop looking at SumatraPDF.patch until this is settled. | 23:19.06 |
| | henrys: we can pull out and rewrite mupdf git history to erase his main contributions (most of which are in the encryption code) and open new bugs for paul or someone else. it's the small stuff and minor bug fixes that will be a pain to rip out, but I don't think that'll be necessary. | 23:20.24 |
| henrys | oh so sumatrapdf.patch isn't integrated yet. | 23:23.33 |
| Robin_Watts | tor8: I suspect that actually we could get by by just completely ignoring him given the informal agreement we have,but if we can solve it 'nicely' (by using retroactive bug bounties) it's nicer. | 23:23.53 |
| tor8 | henrys: sumatrapdf.patch is a diff between our and sumatra's "fork" of mupdf | 23:24.08 |
| Robin_Watts | sumatrapdf.patch is a constantly updated set of diffs. | 23:24.13 |
| tor8 | sebras likes to look through it and pull bug fixes over | 23:24.24 |
| Robin_Watts | we've taken bits and pieces from it in the past. | 23:24.26 |
| | ok. bed time. night all. | 23:25.01 |
| tor8 | good night robin | 23:25.16 |
| henrys | was it clear in this informal agreement that artifex would apply its license as well? | 23:31.59 |
| | Forward 1 day (to 2012/08/21)>>> | |
IRC Logs