| | <<<Back 1 day (to 2013/02/27) | 2013/02/28 |
| Robin_Watts | tor8: 3 reviews for you on robin/master | 00:31.06 |
| sebras | Robin_Watts: time to sleep! | 00:49.52 |
| | good night no one. | 00:50.04 |
| Robin_Watts | night | 00:50.12 |
| | tor8: 3 reviews for you, when you get a mo. | 10:36.48 |
| | tor8: We don't have .desktop files, right? So what's with bug 693467 ? | 11:05.57 |
| | Morning paulgardiner | 11:06.02 |
| | Just doing a quick trawl through the bugs... bug 693481 has an android zooming 'fix'. | 11:06.30 |
| | any opinion on it ? | 11:06.35 |
| tor8 | Robin_Watts: 3 commits look good. | 11:07.17 |
| | and thanks for jumping on the WinMain crap :) | 11:07.24 |
| | though I think we already have a function to convert ucs2 to utf8 | 11:08.04 |
| | ah, no we don't. only the other direction... | 11:08.33 |
| Robin_Watts | tor8: yeah, I hunted for it :) | 11:09.08 |
| tor8 | there is a pdf_to_ucs2_buf but that messes with pdf doc encoding too | 11:09.31 |
| | and goes the wrong way | 11:09.36 |
| paulgardiner | Robin_Watts: was that the right bug? I see no zoom fix | 11:09.42 |
| Robin_Watts | 2 more commits then, both makefile tweaks. | 11:09.47 |
| tor8 | the .desktop stuff is probably the 'debian/mupdf.desktop' stuff we have | 11:10.00 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=693481&list_id=2842 | 11:10.03 |
| | paulgardiner: Also... http://bugs.ghostscript.com/show_bug.cgi?id=693671 <- in case you have anything to add. | 11:13.53 |
| paulgardiner | Not sure about 693481. Pity it isn't a patch rather than a file. It seems to be based on a version before smart scroll and reflow. | 11:16.17 |
| Robin_Watts | I think we can turn it into a diff. Let me try that now. | 11:17.41 |
| paulgardiner | Oh. I guess I can see the changes he's made. We'll need to try it out and see if we like the effect. The description sounds like something worth having. | 11:17.42 |
| | I'm viewing it as a diff agains the current version | 11:17.59 |
| Robin_Watts | sebras, paulgardiner: bug 693230 should be solved now, right? | 11:18.01 |
| paulgardiner | It removes smarscroll and some stuff to do with reflow | 11:18.26 |
| | 693671: could be something we'd support for a customer. | 11:20.06 |
| Robin_Watts | http://ghostscript.com/~robin/diff.txt | 11:20.53 |
| paulgardiner | Robin_Watts: you picked out the bits that seemed pertinant, or you diffed against a version based on date? | 11:22.11 |
| Robin_Watts | I diffed on a version based on date. | 11:22.22 |
| paulgardiner | Ah good | 11:22.30 |
| | It looks sort of sensible, but would need to try it out | 11:23.58 |
| | For some reason I'm having trouble finding the right item of 693230 | 11:24.27 |
| Robin_Watts | paulgardiner: Are you just clicking in chatzilla where it says "bug 693230" or something ? | 11:25.51 |
| paulgardiner | Well yes :-) Is that taking me to ghostscript rather than mupdf? | 11:26.40 |
| Robin_Watts | cos unless you've configured it, that'll take you to mozillas bug tracker, not ours. | 11:26.44 |
| paulgardiner | oh right | 11:26.52 |
| | That would explain it | 11:26.59 |
| Robin_Watts | In chatzilla: File -> Preferences... | 11:27.21 |
| | Global Settings => Appearance => Bugzilla URL | 11:27.36 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=%s | 11:27.49 |
| | Then it works as you'd hope. | 11:28.08 |
| paulgardiner | Doesn't seem to, but maybe when I next shutdown and restart | 11:30.16 |
| Robin_Watts | It probably only affects new ones. Try this: bug 693230 | 11:30.47 |
| paulgardiner | We think we've fixed 693230, provided it wasn't really about large images in the pdf | 11:31.09 |
| Robin_Watts | right, so if sebras is happy, I'll close that one then. Or you can. | 11:31.36 |
| sebras | Robin_Watts: yo! | 12:09.55 |
| | paulgardiner: no, the images were just required in order to make mupdf render pages slowly I think... | 12:11.17 |
| | are you guys tidying bugzilla today? | 12:11.43 |
| paulgardiner | bug 693230 | 12:43.15 |
| | Robin_Watts: that chatzilla config worked thanks. | 12:43.37 |
| | Robin_Watts, tor8: a few little commits on paulg/master when you get a moment | 13:29.35 |
| | tor8, Robin_Watts: I'm looking at the API change we discussed: if I remove the type fz_annot then we cannot draw the page without making use of the pdf_ API because we separated drawing the page into drawing the main part and iterating through drawing the annotations. Is that okay? | 13:52.40 |
| tor8 | paulgardiner: the "heuristics" in the bbox device for stroked corners should be based on accurate math or there's a bug/misunderstanding of the mitering math on my par | 13:56.32 |
| | t | 13:56.33 |
| | Robin_Watts: makefile fixes look good | 13:56.47 |
| paulgardiner | tor8: I needed to base the bbox on the selected text to match Adobe Reader in any case. The heuristics I was refering to was a factor of 10 mulitplication that I think is something to do with mitres | 14:01.51 |
| | A factor of 10 mult that I now can't find. :-S I saw it while tracing in the debugger | 14:04.29 |
| | Ah no. It was a multiplication by mitrelimit which happened to be 10 | 14:07.14 |
| | It's in fz_adjust_rect_for_stroke. I imagine it's as good as can be achieved without some more intensive calculation... although I'm not sure why expand is initially set to linewidth and not linewidth/2 | 14:09.55 |
| Robin_Watts | because linewidth is half the linewidth. | 14:11.45 |
| | obviously :) | 14:12.04 |
| paulgardiner | Doh!! :-) | 14:12.54 |
| | I guess I could have set the mitre limit to 1.0, but still Adobe Reader sets the bounding box for text markup annotations based on the selected text rathert than the annotation itself, so we now do the same. | 14:14.18 |
| | Hmmm. Maybe that should be expand *= fz_max(mitrelimit, 1.0); unless mitrelimit is guaranteed >= 1.0 | 14:20.48 |
| | Ah it's in the test Doh2!! | 14:21.18 |
| Robin_Watts | I've got Radu talking to me on skype. apparently the multicore stuff is lumpier than it used to be. | 14:37.15 |
| | so I'm going to try to add some debugging to track how long locks are held etc. | 14:37.37 |
| paulgardiner | Any thoughts on the fz_annot removal's effect on page drawing? | 14:41.36 |
| Robin_Watts | paulgardiner: Sorry, I got sidetracked. | 14:42.40 |
| | sebras: Yes, I was vaguely tidying bugzilla. | 14:42.54 |
| paulgardiner | np | 14:43.21 |
| Robin_Watts | We have had fz_annot for as long as I've been involved in mupdf. | 14:54.58 |
| | and that's not pulled the interpreter in. | 14:55.41 |
| | the change that's caused the interpreter to be pulled in is that fz_annot now knows how to synthesise annotation streams, right? | 14:56.07 |
| | but for the cases where we don't want the interpreter pulled in, we don't care about the synthesis of annotation streams. | 14:57.12 |
| | So... if I've got this right, can't we have the synthesis of annotation streams be done by a call via a function pointer in the fz_document structure? | 14:58.17 |
| | Then fz_document_open_no_run can leave that NULL, and we won't pull in the interpreter, and we won't have annotation synthesis, etc. | 14:58.55 |
| | and fz_load_annot can stay where it is. | 14:59.02 |
| tor8 | I think robin's suggestion is worth thinking about | 15:37.15 |
| Robin_Watts | tor8: I just chatted to paulgardiner on the phone. | 15:37.34 |
| | He reckons the issues of avoiding bloat and of splitting fz_annot out of fitz.h are separable ones. | 15:38.16 |
| | So he's going to try the function pointer to avoid bloat first, and then we can talk about whether to split fz_annot out or not after that. | 15:38.40 |
| tor8 | alright | 15:39.16 |
| paulgardiner | Yeah, I looked yesterday at avoiding pulling in the interpeter and concluded that Robin's suggestion was the best way. That wasn't really what I was asking about. It was the other part of your suggestion to do with getting some of the interactive stuff out of the fz api | 15:39.24 |
| tor8 | more specifically rendering the page and annotation layers separately | 15:40.11 |
| Robin_Watts | As a dumb user, I'd just want to be able to say "render this document" and get the whole lot. | 15:41.03 |
| paulgardiner | We were doing that. I'm not sure why we changed. | 15:41.43 |
| Robin_Watts | For finer control (i.e. for doing smart things with hiding/showing annotations etc), then I'd be prepared to do more fiddling, but really, for simple rendering, we want it to be as simple as we can be. | 15:41.52 |
| tor8 | I don't recall why we changed it... for partial updates? | 15:42.36 |
| paulgardiner | That was why we provided the separate methods, but I'm less sure why we got rid of the method that drew all | 15:43.36 |
| Robin_Watts | possibly a desire to keep the API small. | 15:44.00 |
| paulgardiner | Yeah. I think it was | 15:44.11 |
| Robin_Watts | paulgardiner made the suggestion on the phone that we could have the "whole" api as an fz one, and then the separate parts as pdf_ ones (but that assumes we split the fz_annot stuff out) | 15:45.00 |
| tor8 | Robin_Watts: that sounds reasonable, and it means we can drop the fz_annot stuff into pdf_ | 15:46.24 |
| Robin_Watts | but... do we really want that? | 15:46.42 |
| paulgardiner | Yesterday we discussed have a cast-to-pdf function in place of fz_interactive, but if we go that way we need to decide which of the fz types that are just wrappers over pdf_ types to remove | 15:46.49 |
| Robin_Watts | Are we sure that we'll never have another file format we want to support that has annotations ? | 15:47.11 |
| tor8 | though having the split makes me wonder how much extra trouble users of the library will have to do to support pdf features as well as the high level document wrappers | 15:47.19 |
| paulgardiner | exactly | 15:47.37 |
| henrys | the latest firefox release has the PDF.js builtin, It seems to to work pretty well, who'da thought would be performant? | 15:47.53 |
| tor8 | I mean, if any "complete" viewer will downcast to pdf_document just to expose some of the more advanced features, the high level api has failed in a way | 15:48.11 |
| paulgardiner | Yes quite | 15:48.29 |
| tor8 | henrys: for plain text, I'm not surprised. computers are fast and parsing was never the big bottle neck. | 15:48.38 |
| Robin_Watts | henrys: I think they extended canvas to do the heavy lifting. | 15:48.39 |
| tor8 | the question is how well do they cope with type 3 fonts and fax and jbig2 images | 15:49.25 |
| chrisl | And transparency..... | 15:50.02 |
| henrys | I don't think transparency works - I opened a few test files and they displayed incorrectly and I got the error "this file may not display correctly" ⦠and it prompts you to open with another viewer. I do think it is well suited for surfing. | 15:51.28 |
| kens2 | Until you hit the first Cairo PDF | 15:51.54 |
| henrys | it is doesn't support transparency cairo is easy | 15:52.17 |
| Robin_Watts | tor8: I'm sure that fax and jbig2 images will just be implemented as new image types in the browser. | 15:52.46 |
| kens2 | Cairto uses *lots* of transparency | 15:53.06 |
| chrisl | Especially (it seems) when it shouldn't! | 15:53.25 |
| henrys | tkamppeter:ping | 15:53.31 |
| | I'm impressed with firefox I dropped it for the bloat but now I find it a bit faster and responsive than chrome on mac os x | 15:55.31 |
| tor8 | henrys: chrome's gone the same way as firefox... down to bloat town. | 15:57.00 |
| chrisl | I've always found chromium a bit resource heavy - plus I've had it crash a few times (taking down all the tabs/windows, despite all the claims"), so I usually stick to firefox | 15:57.22 |
| tor8 | guess we'll see a new browser pop up in a few years that's back to basics again and everyone will oooh and aaah and use that until it gets bloated, etc, etc | 15:57.39 |
| tkamppeter | henrys, hi | 15:57.48 |
| Robin_Watts | chrisl: Serves you right for relying on flaky open source software. (That's what FOSS stands for, right?) | 15:58.02 |
| chrisl | Robin_Watts: Yeh, I should go back to using Micro$haft Winblows....... | 15:58.42 |
| henrys | tkamppeter:I was wondering if there are open source initiatives to support internet printing that you guys are looking into, seems like everyone is getting on this boat, google cloud printing, HP sprint etc. | 15:59.20 |
| tkamppeter | henrys, I do not know about any free software cloud printing server project. Should one perhaps initiate efforts in that direction, perhaps discuss it on the OpenPrinting Summit? | 16:02.00 |
| henrys | It seems like it could be very disruptive, internet printing seems to be here in a big way, driverless printing could really take Ubuntu (any distribution) out of the printing pipeline. I guess the larger distributions red hat, ubuntu, and suse could participate with cloud based services. | 16:07.54 |
| | tkamppeter:curious to see if this swings the pendulum back to rasterizing on the printer. We'll see. | 16:15.08 |
| paulgardiner | tor8, Robin_Watts: were my commits okay? | 16:18.37 |
| henrys | anyway (Artificers) I was going to suggest at the meeting we do a distiller like demo that uses xmpp (https://developers.google.com/cloud-print/docs/rawxmpp) just to show we some competency with this. | 16:20.58 |
| | s/we/we have/ | 16:21.17 |
| Robin_Watts | paulgardiner: Looking now. | 16:24.02 |
| paulgardiner | ta | 16:24.07 |
| Robin_Watts | oops. | 16:25.58 |
| henrys | sorry I'm doing parts of the agenda out loud: chrisl:you brought up doing svg - IMO svg should be part of mupdf. | 16:26.01 |
| chrisl | henrys: I just thought it would be good if we had a clear direction for the project - at the moment it seems stagnant and lost.... | 16:26.56 |
| Robin_Watts | paulgardiner: fz_include_point_in_rect won't work as is. | 16:27.54 |
| paulgardiner | Do you mean you need to special case the first point? | 16:28.18 |
| Robin_Watts | Yes. | 16:28.24 |
| | And you do. | 16:28.30 |
| paulgardiner | I explain that in the h file preamble | 16:28.39 |
| Robin_Watts | ok. | 16:28.48 |
| | I should read the whole diff before commenting. But then I'd forget stuff :/ | 16:29.11 |
| | All look good to me then. | 16:29.37 |
| paulgardiner | Great stuff | 16:30.09 |
| Robin_Watts | I'll push them in a mo, when I get my branch back to building again. | 16:30.25 |
| henrys | chrisl: yeah my vote is it goes into mupdf or we ditch it. Doesn't seem to fit into the ghostscript architecture being more viewer than printer oriented | 16:30.36 |
| paulgardiner | ta | 16:31.01 |
| chrisl | henrys: so far, none of the (10) PDFs with JBIG2 images in them that I've tried work in PDF.js - no warnings, just a blank page | 16:31.19 |
| paulgardiner | Robin_Watts: the need to special case the first point is a pain. Makes it easy to use wrongly. Couldn't think of another way around it, unless we used INT_MAX, INT_MAX, INT_MIN, INTMIN for empty rect rather than 0,0,0,0 | 16:32.42 |
| | I seem to remember that MAX,MAX,MIN,MIN has its problems too. | 16:33.08 |
| Robin_Watts | I keep pondering on different formulations of rectangles, but haven't thought of anything that solves all the issues. | 16:33.25 |
| henrys | chrisl:I only looked at obvious things on the web. I'm sure if you went through say bugzilla files PDF.js would suck. | 16:34.28 |
| kens2 | JBIG2 not that uncommon | 16:35.11 |
| chrisl | True, but a conforming PDF interpreter needs it, so...... | 16:35.45 |
| | kens2: I've been working through that crashing/freezing Konica-Minolta printer with the reporter | 16:39.52 |
| kens2 | cool chrisl, any results ? | 16:40.27 |
| henrys | chrisl:the tree reorg looks like a good step to me. | 16:40.49 |
| chrisl | It *seems* to be crashing with the Truetype font embedded | 16:40.50 |
| | henrys: thanks | 16:41.00 |
| kens2 | chrisl that could be awkward | 16:41.30 |
| | Fixing it might need that TT rewrite I keep promising to do | 16:41.46 |
| chrisl | kens2: but he says that the 9.05 output works and 9.06 fails, and the *only* differences I can see around the TTF related stuff is that you fixed the missing DSC Begin/EndResource comments | 16:42.21 |
| kens2 | Thats.... odd...... | 16:42.40 |
| | Could try remogin them :-) | 16:42.49 |
| chrisl | I have, I just put the file up, and mailed him a few minutes ago, so we'll see | 16:43.14 |
| kens2 | will be interesting to hear | 16:43.22 |
| chrisl | It would certainly be a first - a printer crashing due to comments! | 16:44.16 |
| kens2 | Nothing would surprise me now..... | 16:44.51 |
| chrisl | I guess if the printer has built-in reverse page ordering or other such stuff, it's within the bounds of reason it could be parsing the comments | 16:45.55 |
| kens2 | comment parsing isn't unknown, but as far as I can see those comments are correct... | 16:46.40 |
| chrisl | Odd that it would be *only* the font related ones that have the problem | 16:47.54 |
| Robin_Watts | mvrhel_laptop: Tea? | 16:49.01 |
| | chrisl: separation seems reasonable to me. | 17:01.15 |
| chrisl | Ta | 17:01.53 |
| Robin_Watts | paulgardiner: Commits pushed. | 17:08.59 |
| | tor8: ping | 17:11.10 |
| | Are we assuming that fz_authenticate_password takes a password in utf8 form? | 17:11.30 |
| kens2 | TIme to go, night all | 17:11.51 |
| Robin_Watts | Night kens2 | 17:12.04 |
| henrys | bye kens2 | 17:12.09 |
| Robin_Watts | tor8: The current implementation doesn't seem to expect utf8 (and that's good, IMHO), but the mudraw use of it passes utf8 in. | 17:12.58 |
| | so, the obvious idea would seem to be to convert from utf8 before calling it. | 17:13.58 |
| | but converting from utf8 will give us 16bit values to feed in when the password code expects 8 bits. | 17:14.21 |
| | So I'm guessing we should convert from utf8 to chars, and throw an error on out of range values? | 17:15.07 |
| ray_laptop | chrisl_away: I was looking at last staff meeting's notes. Re: item 10, did you find out anything about working with file handles on Windows so we can automatically get rid of temp files ? | 17:29.27 |
| Robin_Watts | alecher: Looks like bug 693653 has mutated from a "shadings are slow" to a "wierd uninstallpagedevice error". | 17:29.28 |
| | alexcher: Accordingly, I'm running away from it. | 17:29.48 |
| chrisl_away | ray_laptop: we discussed that after meeting - we concluded cloning the fd wouldn't work as it still affects the underlying file position. | 17:31.20 |
| ray_laptop | chrisl_away: OK. I had forgotten that. I notice that some apps make a folder in $TEMP and put their files there. What do you think about making a 'gstemp' folder and then every time we start gs, we can clean out any left over tempfiles that match the template | 17:34.19 |
| Robin_Watts | ray_laptop: Nope. Suppose I am running several gs exes at once ? | 17:34.42 |
| ray_laptop | chrisl_away: if there are multiple gs's running, the OS won't allow deletion | 17:35.00 |
| | if the file is still in use | 17:35.15 |
| Robin_Watts | only if the file is still open. Might there not be a moment between writing and reading when it's closed? (I can't remember the details, so maybe I should shut up) | 17:35.42 |
| ray_laptop | Robin_Watts: we _do_ close the clist file when setting up for MT rendering, so maybe that is a 'gotcha' | 17:37.11 |
| chrisl_away | ray_laptop: the thing I was thinking about was DuplicateHandle() on Windows, but it still has the problem that operations on each instance affect the underlying object, not just its own state | 17:39.46 |
| ray_laptop | Robin_Watts: we could play other games to prevent other gs instances from deleting files we still are using -- just during the close..reopen window | 17:39.48 |
| Robin_Watts | ray_laptop: Such as? | 17:40.09 |
| chrisl_away | Sorry, I have to go.... | 17:40.16 |
| ray_laptop | chrisl_away: np. Thanks. | 17:40.24 |
| | Robin_Watts: such as creating a marker tempfile that has 'delete on close', then close the clist files and reopen them for read, then close the marker file. | 17:41.44 |
| | Robin_Watts: the startup code would look at the marker file and not do cleanup if it is there | 17:42.23 |
| Robin_Watts | ray_laptop: So on a restart you'd only delete a file in gstemp if they weren't open and there wasn't a marker file for that file. | 17:42.43 |
| | s/they/it/ | 17:42.52 |
| | tor8: New patch for review in robin/master | 17:43.31 |
| | (the utf8/password one) | 17:43.41 |
| ray_laptop | Robin_Watts: yes. But the marker file could just cause us to skip the cleanup altogether, not just for a specific file | 17:43.44 |
| | if that makes it simpler or more efficient. | 17:44.31 |
| Robin_Watts | seems a bit horrid, just to allow us to atomically close/reopen a file. | 17:46.07 |
| ray_laptop | just thinking out loud -- there may be another way to 'hide' a file before closing it | 17:46.16 |
| Robin_Watts | ray_laptop: Why can't we just freopen ? | 17:48.53 |
| | In the clist code, we fopen a file, and write to it. When we're finished, we freopen it to make it a read stream. | 17:50.02 |
| | We store the FILE * somewhere, but never use it, until we close it just before we delete the clist file at the end. | 17:50.26 |
| | In the meantime other threads can fopen to get their own FILE * on the file, right? | 17:50.45 |
| | That way, at no point does the FILE * get dropped. | 17:51.26 |
| | Always assuming that freopen is atomic of course. | 17:53.53 |
| ray_laptop | Robin_Watts: It may just be a Windows problem. I'll play with linux to see if there is a way to use the unlink there. | 17:56.42 |
| Robin_Watts | ray_laptop: Right. but (if freopen is truly atomic) it would be a portable solution. | 17:57.34 |
| ray_laptop | Robin_Watts: freopen doesn't appear atomic from my reading "The original stream is closed, regardless of whether the open ultimately succeeds." to me implies separate steps | 17:57.57 |
| | and it since it closes the file, how does that interact with the "delete on close" | 17:59.00 |
| | Robin_Watts: but I can try that on windoze and linux | 17:59.31 |
| Robin_Watts | ray_laptop: I suspect you're right :( | 17:59.57 |
| | mvrhel_laptop: ping | 18:25.25 |
| ray_laptop | Robin_Watts: I saw your response to moving contrib into the new devices. Since contrib is all devices, that's why I think it _should_ be moved there. I sometimes use grep to find things in device modules, and this means I have to grep -r in two directories -- just a minor inconvenience, but contrib under devices seems more logical to me | 18:57.13 |
| Robin_Watts | I guess. | 18:58.22 |
| | I'm in too minds here. On one hand I'm thinking "ooh, no, too many nested dirs", and on the other hand, I like the idea of separating the modules of gs out into more clear divisions (and dirs are the obvious way to do that). | 18:59.50 |
| ray_laptop | Robin_Watts: it's not a big deal, and I consider the new structure an improvment | 19:00.02 |
| Robin_Watts | so I guess I withdraw any objections. | 19:00.05 |
| | There would be something to be said for having contrib as a top level dir, but then we've already lost that by having it as gs/contrib, so... | 19:00.47 |
| ray_laptop | Robin_Watts: as long as ctags -R still works, I'm OK with more directories | 19:00.50 |
| | oh, my. chrisl is going to hate this one. 18 levels deep in UFST (but 693674) | 19:11.40 |
| | bug 693674, that is | 19:12.43 |
| marcosw | ray_laptop: I'll be sure to tell chrisl_away that you reminded me to open that bug. | 19:18.40 |
| ray_laptop | marcosw: I knew I shouldn't have cc'ed tech in the email to you ;-) | 19:19.50 |
| | bbiaw... | 19:20.22 |
| mvrhel_laptop | Robin_Watts: I am here now | 19:25.38 |
| Robin_Watts | mvrhel_laptop: 2 questions... | 19:25.46 |
| | 1) Do you need tea? | 19:25.49 |
| mvrhel_laptop | oh Robin_Watts she said she was good until the June meeting thanks | 19:26.07 |
| Robin_Watts | 2) Have you seen the emails about a customer wanting a Windows RT MuPDF viewer ? | 19:26.31 |
| mvrhel_laptop | Robin_Watts: no I did not see that | 19:26.41 |
| Robin_Watts | very recent. | 19:26.49 |
| mvrhel_laptop | sounds like I better get busy | 19:26.49 |
| | I am hoping to get search working shortly | 19:27.14 |
| Robin_Watts | mvrhel_laptop: It might be worth you introducing yourself to him. | 19:27.49 |
| mvrhel_laptop | oh Robin_Watts I wanted to ask you about what I need to do to get a repository set up for mupdf on casper like you tor and paul have | 19:27.52 |
| Robin_Watts | Have you set up a git repo.... | 19:27.56 |
| | OK :) | 19:28.00 |
| | Do you have your stuff committed locally into a git repo? | 19:28.21 |
| mvrhel_laptop | I have not even done a local commit here yet | 19:28.44 |
| | living on the edge | 19:28.48 |
| Robin_Watts | eek. | 19:28.54 |
| | So, ssh to casper. | 19:29.04 |
| mvrhel_laptop | ok hold on | 19:29.08 |
| | ok I am there | 19:29.32 |
| Robin_Watts | mkdir repos | 19:29.38 |
| | cd repos | 19:29.40 |
| mvrhel_laptop | ok I do have a repos directory already | 19:29.50 |
| | I may have done this for ghostscript long ago | 19:29.59 |
| | yes, there is a ghostpdl.git in there | 19:30.12 |
| Robin_Watts | git clone /home/git/mupdf.git mupdf.git | 19:30.14 |
| mvrhel_laptop | ok hold on | 19:30.30 |
| | cloning.... | 19:30.49 |
| | done | 19:30.51 |
| Robin_Watts | Damn. | 19:31.27 |
| | Let's try that again.... rm -rf mupdf.git | 19:31.41 |
| mvrhel_laptop | ok | 19:31.45 |
| | done | 19:31.56 |
| Robin_Watts | git clone --bare /home/git/mupdf.git mupdf.git | 19:32.00 |
| mvrhel_laptop | done | 19:32.23 |
| Robin_Watts | And your repo is showing up on http://git.ghostscript.com/ | 19:32.39 |
| mvrhel_laptop | ok the nunamed one | 19:33.05 |
| | unnamed | 19:33.21 |
| Robin_Watts | You can edit mupdf.git/description to be "MuPDF / mvrhel" if you want. | 19:34.38 |
| mvrhel_laptop | doing that now | 19:34.45 |
| Robin_Watts | Now, how we set the next bit up is down to your personal taste. | 19:35.08 |
| | At the moment, your local mupdf repo (the one on your PC) has been cloned from the main one. | 19:35.43 |
| | As such 'origin' points to the main one. | 19:35.56 |
| mvrhel_laptop | right | 19:35.59 |
| | I want to be able to pull in stuff from the main into my local one | 19:36.18 |
| Robin_Watts | We need to add a new pointer to this repo. | 19:36.29 |
| | Personally, I have "golden" set to point to the main one, and "origin" set to my personal one on casper. | 19:36.52 |
| | That's so I have to make a special effort to push to 'golden'. | 19:37.10 |
| | but we can set this up however you'd like. | 19:37.17 |
| | I also have 'tor' and 'paul' and 'sebras' set up as remotes, so I can pull in changes from their repos. | 19:37.47 |
| mvrhel_laptop | Robin_Watts: I think I like that terminology. And then do you fetch from golden? | 19:38.21 |
| Robin_Watts | I do. | 19:38.50 |
| | I do "pull --rebase golden master" | 19:39.02 |
| mvrhel_laptop | and then do you push those up to your local repo on casper? | 19:39.02 |
| Robin_Watts | Indeed. | 19:39.07 |
| mvrhel_laptop | ok. I can handle that I believe | 19:39.17 |
| | lets set mine up like yours | 19:39.25 |
| Robin_Watts | I commit (often) to my own repo. As soon as I have something that's not too embarassing (or that I wouldn't like to lose), I then push to origin. | 19:39.37 |
| | Then people can review my work, and when we're all happy, we push to golden. | 19:39.53 |
| mvrhel_laptop | origin being your repo on caspar | 19:40.10 |
| Robin_Watts | yes. | 19:40.13 |
| mvrhel_laptop | ok. got it | 19:40.16 |
| Robin_Watts | Now, you don't use command line git, do you? | 19:40.43 |
| mvrhel_laptop | I can I have git bash open ow | 19:41.08 |
| | now | 19:41.10 |
| Robin_Watts | ok, let's do some simple ones first. | 19:41.22 |
| mvrhel_laptop | I can do either | 19:41.23 |
| | ok. let me save what I have. we are not in danger of losing my work right? | 19:41.54 |
| Robin_Watts | We should not be, no. | 19:42.13 |
| | But if you wanted to quickly copy the directory, I wouldn't blame you :) | 19:42.34 |
| mvrhel_laptop | let me do that | 19:42.40 |
| | ok. done | 19:43.12 |
| Robin_Watts | git remote add robin mvrhel@ghostscript.com:/home/robin/repos/mupdf.git | 19:43.18 |
| | Actually before you do that... | 19:43.39 |
| | do git remote -v and paste it here. | 19:43.48 |
| mvrhel_laptop | ok hold on | 19:43.52 |
| | origin ghostscript.com:/home/git/mupdf.git (fetch)origin ghostscript.com:/home/git/mupdf.git (push) | 19:44.37 |
| Robin_Watts | git remote add robin ghostscript.com:/home/robin/repos/mupdf.git | 19:44.57 |
| | git remote add paul ghostscript.com:/home/paulg/repos/mupdf.git | 19:45.14 |
| | git remote add sebras ghostscript.com:/home/sebras/repos/mupdf.git | 19:45.25 |
| | git remote add tor ghostscript.com:/home/tor/repos/mupdf.git | 19:45.37 |
| | git remote add golden ghostscript.com:/home/git/mupdf.git | 19:45.54 |
| mvrhel_laptop | ok done | 19:46.36 |
| Robin_Watts | Now all that remains is to make origin point to your repo rather than the main one. | 19:46.38 |
| | git remote rm origin | 19:46.45 |
| mvrhel_laptop | hmm got an error with that one | 19:47.07 |
| Robin_Watts | ah. OK. | 19:47.22 |
| mvrhel_laptop | error: Could not remove config section 'remote.orgin; | 19:47.25 |
| | error: Could not remove config section 'remote.orgin' | 19:47.30 |
| Robin_Watts | OK. In that case, let's edit the .git/config file in your favourite editor. | 19:48.00 |
| | origin, not orgin. | 19:48.14 |
| mvrhel_laptop | ok hold on let me open it | 19:48.19 |
| | ok I am there | 19:49.16 |
| Robin_Watts | ok, look for the line that says [remote "origin"] | 19:49.38 |
| mvrhel_laptop | yes I see it | 19:49.45 |
| Robin_Watts | the next line should be url = .... | 19:49.51 |
| mvrhel_laptop | ghostscript.com:/home/git/mupdf.git | 19:49.53 |
| | url = ghostscript.com:/home/git/mupdf.git | 19:49.57 |
| | [remote "origin"] | 19:50.09 |
| | fetch = +refs/heads/*:refs/remotes/origin/* | 19:50.10 |
| | url = ghostscript.com:/home/git/mupdf.git | 19:50.12 |
| Robin_Watts | We need to make that url = ghostscript.com:/home/mvrhel/repos/mupdf.git | 19:50.25 |
| mvrhel_laptop | right | 19:50.34 |
| Robin_Watts | i.e. we're just changing the path. | 19:50.39 |
| mvrhel_laptop | ok done | 19:50.55 |
| Robin_Watts | ok, I think you should be sorted then. | 19:51.09 |
| mvrhel_laptop | ok. so, I have not fetched in a while, perhaps I should do a local commit here, fetch from golden and then after I fix a couple things push up to my repo | 19:51.48 |
| Robin_Watts | That sounds smart. | 19:52.04 |
| mvrhel_laptop | I will reply to the email about WinRT and introduce myself tell them where I am in the project | 19:52.30 |
| Robin_Watts | If I was you, I'd make a new branch, commit everything on that. | 19:52.31 |
| mvrhel_laptop | Robin_Watts: oh that might be a good idea | 19:52.45 |
| Robin_Watts | Then pull in the latest changes onto master, then rebase the branch. | 19:52.51 |
| | That way, if anything goes wrong, it's easy to back out of the rebase :) | 19:53.05 |
| mvrhel_laptop | ok | 19:53.34 |
| | Robin_Watts: so I have a ARM windows surface here that I am able to run my code on | 19:55.26 |
| | I can build for the ARM with VS and actually debug on the surface on my local network here | 19:55.57 |
| Robin_Watts | mvrhel_laptop: Oh, cool. | 19:56.13 |
| mvrhel_laptop | So are they writing there own version too? I am a bit confused by the email | 19:56.35 |
| | Robin_Watts: ^^ | 19:56.40 |
| Robin_Watts | no. | 19:56.44 |
| mvrhel_laptop | ok | 19:56.51 |
| | they said something about being 70% done | 19:57.04 |
| malc_ | Robin_Watts: boblycat.org/~malc/ttest.c | 19:57.04 |
| Robin_Watts | They are existing customers. They have an Android app, that is basically our app for displaying PDF + a load of their code for getting magazines as PDF etc. | 19:57.24 |
| | I think they want to do the same on Windows 8 - hence their side of the code is the purchasing of magazines, downloading it, showing a shelf full of magazines to pick from etc. | 19:58.21 |
| | and then they'll kick it into our code to actually show it. | 19:58.35 |
| | See the private message... | 19:58.48 |
| mvrhel_laptop | ok. I can probably have something reasonable working in the next month. I have to fix a few crash issues and fix issues with device rotation add xps and finishe search | 19:58.53 |
| | Robin_Watts: thanks for the help with git! | 20:00.30 |
| Robin_Watts | mvrhel_laptop: No worries. | 20:01.02 |
| mvrhel_laptop | ok. lunch time then back to the salt mine | 20:02.27 |
| | ok so now back to git. Robin_Watts so I have not been fooling with branches at all with git, but I am willing to try with this project. So, should I first create the branch and then commit my existing changes to the branch | 21:14.20 |
| | first I need to clean up a few things | 21:16.22 |
| | so, I have my changes committed locally to my branch | 21:35.27 |
| | now to push the branch up to my repos on casper | 21:35.38 |
| | first I better do a fetch and rebase | 21:36.02 |
| | ok. so I do a fetch from golden | 21:37.17 |
| | now to my branch | 21:37.54 |
| | I am a little confused. so was the last commit to golden really on Dec 19th? | 21:40.37 |
| pancho_jay | hi | 21:41.15 |
| ghostbot | hi, pancho_jay | 21:41.15 |
| pancho_jay | someone speaks spanish? | 21:41.24 |
| mvrhel_laptop | pancho_jay: hola. not that I am aware of | 21:42.08 |
| pancho_jay | mvrhel_laptop, uppsss | 21:42.26 |
| | I need some help | 21:42.32 |
| | I will try to write in english | 21:42.53 |
| mvrhel_laptop | ok | 21:42.59 |
| pancho_jay | I am having problems with changed characters | 21:43.04 |
| | when trying to concatenate two or more pdfs | 21:43.18 |
| mvrhel_laptop | pancho_jay: is this for gs or mupdf? | 21:43.36 |
| pancho_jay | mvrhel_laptop, I using gs from commandline to concatenate pdf files | 21:45.24 |
| | btw, I dont know what is mupdf | 21:45.47 |
| mvrhel_laptop | pancho_jay: ok. I would suggest that you try to catch kens when he is on here in about 12 hours | 21:46.06 |
| | oh wait he is on vacation | 21:46.13 |
| pancho_jay | bad luck :( | 21:46.20 |
| mvrhel_laptop | maybe chrisl will be able to help you with character issues in about 12 hours | 21:46.34 |
| | or alexcher if he is around may be able to help | 21:47.02 |
| pancho_jay | alexcher, ping! | 21:47.14 |
| mvrhel_laptop | anything involving characters is not my strong suite | 21:47.21 |
| pancho_jay | I've seen this issue http://bugs.ghostscript.com/show_bug.cgi?id=693324 | 21:47.47 |
| | and we are using an old version of GS (8.71) in production server | 21:48.43 |
| | everything always went fine, but last weeks we tried to concatenate various pdfs and error apears | 21:49.24 |
| mvrhel_laptop | looks like you should update as this was fixed | 21:50.01 |
| | ok. now I have the local mupdf updated | 21:52.18 |
| | now to get those onto my branch... | 21:52.29 |
| pancho_jay | mvrhel_laptop, ok, i will try updating and get some conflicting pdfs to tests! | 21:56.00 |
| | thanks you! | 21:56.05 |
| mvrhel_laptop | panch_jay sounds like a good first step | 21:56.23 |
| | Robin_Watts: I know it is late. If you happen to wander back to your machine and have a few seconds I could use a little git help | 21:57.18 |
| pancho_jay | see you! | 22:21.49 |
| | Forward 1 day (to 2013/03/01)>>> | |
IRC Logs