| | <<<Back 1 day (to 2012/05/03) | 2012/05/04 |
| ghostgum | good morning | 00:15.31 |
| henrys | Robin_Watts:yes Arnie delivered the scarf thank you very much | 06:49.34 |
| tor8 | Robin_Watts: morning. | 08:49.42 |
| Robin_Watts | tor8: Morning | 09:10.01 |
| tor8 | thinking of the jbig2dec situation, http://apenwarr.ca/log/?m=200904#30 might help | 09:10.46 |
| Robin_Watts | interesting. | 09:14.15 |
| tor8 | supposedly an easy way to pull and push bits of code from a subdirectory of a mega-repo to a smaller one | 09:14.49 |
| Robin_Watts | So we could use that on casper to generate a standalone jbug2dec from the gs master. | 09:15.21 |
| | And then disallow commits to the standalone one. | 09:15.37 |
| tor8 | that was my thinking, yeah. | 09:15.41 |
| Robin_Watts | So people would have to commit to the main gs one, and it would automatically appear in the standalone. | 09:15.56 |
| | I like that, | 09:15.58 |
| tor8 | or if it works, we could commit to both and just use the subtree command to pull/push and merge changes between the two | 09:16.15 |
| | I've been doing the same thing manually for the last couple of times, but finding a command to do it for us would help. | 09:16.43 |
| | unless we decide to discontinue the standalone git, but I think that may be bad for the jbig2dec project's credibility | 09:17.07 |
| Robin_Watts | Pulling changes automatically (untested) into gs sounds bad. | 09:17.17 |
| tor8 | yeah, automatic (that direction) would be bad | 09:17.43 |
| | a crontab job to do the automatic the other direction would be swell | 09:17.53 |
| | we'll need to fix up the the makefile and configure differences first though, something I discussed with chrisl the other day | 09:18.32 |
| | chrisl: MuPDF 1.0 is out on the app store now! | 09:18.55 |
| Robin_Watts | Would be nicer to trigger on commits to specific parts of the gs tree than just to do it "every 12 hours" or something. | 09:18.59 |
| tor8 | the apple app store, that is. | 09:19.01 |
| | we could do it as part of the same triggers that start the cluster tests | 09:19.49 |
| ghostgum | Is Artifex still using mirror.cs.wisc.edu for anything ? | 09:19.54 |
| chrisl | ghostgum: only the legacy stuff, there's nothing current of ours on there | 09:20.25 |
| | tor8: cool! (on the app store) | 09:20.54 |
| ghostgum | mirror.cs.wisc.edu has been turned off by Wisconsin. So I now need to put GSview and RedMon somewhere else, probably sourceforge. | 09:21.07 |
| chrisl | ghostgum: Hmm, did I miss notice of that? | 09:21.42 |
| ghostgum | I wasn't notified either. I just got emails from people saying they couldn't download GSview. | 09:22.02 |
| | Does Artifex want to host the downloads of GSview and RedMon? | 09:22.30 |
| Robin_Watts | ghostgum: I think that would be sensible. | 09:22.53 |
| ghostgum | If not, I'll set up a project on sourceforget.net. | 09:23.05 |
| chrisl | I saw a couple of mails, but the wisc site has been pretty unreliable for the last year or so, so I ignored them. | 09:23.20 |
| Robin_Watts | but Henry would be the guy to decide, I think. | 09:23.21 |
| | And he's away with the sheep at the moment. | 09:23.37 |
| ghostgum | Is he likely to be on IRC in 8 hours, or would email be better? | 09:24.11 |
| Robin_Watts | He's in the UK at the moment, on holiday. | 09:24.32 |
| | Email is probably better. | 09:25.08 |
| chrisl | Yeh, if Henry pops up here, we'll tell him about it | 09:25.38 |
| ghostgum | Short term I'll put GSview on my own site, then watch monthly download limits carefully. | 09:26.37 |
| chrisl | ghostgum: http://pages.cs.wisc.edu/~ghost is still working, could we just rearrange the files a bit (for now)? | 09:27.39 |
| ghostgum | I thought about putting the files on pages.cs.wisc.edu, but wasn't sure how much it would upset them. I'll try that short term for the current version only. | 09:32.08 |
| chrisl | ghostgum: hopefully, they'll cut us some slack given that they pulled the mirrors pages without notice. I don't anticipate any objection to Artifex taking over the hosting, so hopefully it won't be for long. | 09:33.31 |
| kens | Robin_Watts : or tor8 What's the git command to collapse a bunch of patches ? I don't really want to make 19 commits | 09:51.51 |
| tor8 | kens: git rebase -i and change the lines of the commits you want to collapse to 'squash' | 09:53.52 |
| Robin_Watts | git rebase -i hash | 09:54.18 |
| tor8 | so you'll have a 'pick' for the commit you want to keep, and 'squash' on the commits you want to squash into the picked commit | 09:54.32 |
| kens | Ah, a difference of opinion... | 09:54.42 |
| Robin_Watts | where hash is the one before your first one. | 09:54.46 |
| | We agree - tor8 just didn't mention the need for the hash. | 09:55.07 |
| kens | The one before my first one is the master | 09:55.11 |
| ghostgum | They didn't just turn off the server, they removed the AFS mount. | 09:55.13 |
| Robin_Watts | git rebase -i master then | 09:55.25 |
| kens | git logg still shows 20 commits, is that right ? | 09:56.34 |
| | Hmm, let me put this a different way. I have a branch with 20 commits. It is rebased onto master. I want to 'aquash' all 20 commits into one, and update master so that I can commit it. | 09:58.39 |
| Robin_Watts | OK. git rebase -i master | 10:00.00 |
| | That starts an "interactive rebase". | 10:00.11 |
| kens | Which branch needs to be checked out ? | 10:00.15 |
| Robin_Watts | Your branch with all the commits on. | 10:00.31 |
| kens | OK one second | 10:00.36 |
| Robin_Watts | That will open a window that lists all the commits between HEAD and the specified hash (i.e. master) | 10:00.58 |
| kens | Yes, got that | 10:01.17 |
| Robin_Watts | You now need to edit that file, save it back, and then the git history will be rejigged so it conforms to that list of instructions. | 10:01.30 |
| kens | of the form pick xxxxx comment | 10:01.31 |
| Robin_Watts | I typically use this to reorder lines so I can change the order of commits. | 10:01.52 |
| kens | The order is OK. | 10:02.11 |
| Robin_Watts | The last line is the most recent commit - you want to keep that, so leave it as 'pick'. | 10:02.21 |
| kens | last one ? OK | 10:02.35 |
| | Others to squash ? | 10:02.41 |
| Robin_Watts | All the others go to squash. | 10:02.47 |
| kens | OK | 10:03.08 |
| | done | 10:03.10 |
| Robin_Watts | save the file and exit. | 10:03.20 |
| kens | Won't let me | 10:03.50 |
| | path does not exist | 10:03.56 |
| Robin_Watts | eh? | 10:04.15 |
| kens | c:\ghostpdl\.git\rebase-merge\git-rebase-todo.txt is the path, WIndows says 'Path does not exist' | 10:04.32 |
| | the 'rebase-merge' directory indeed does not exist | 10:05.09 |
| Robin_Watts | What editor are you using? | 10:05.15 |
| kens | Wordpad | 10:05.23 |
| | Or write or something | 10:05.32 |
| Robin_Watts | That path must have existed when the file was launched into the editor. | 10:05.47 |
| kens | It doesn't exist now | 10:05.56 |
| Robin_Watts | I suspect that because it's a windows app, git thinks the editor has closed down, and it's tidied up. | 10:06.16 |
| | How do you usually manage to get commit messages in ? | 10:06.29 |
| kens | Seems likely, I have a command prompt in MingW | 10:06.34 |
| | I normally use git gui | 10:06.41 |
| Robin_Watts | Ah. | 10:06.46 |
| | Well, you need to configure a less broken editor then. | 10:06.56 |
| | export EDITOR=emacs | 10:07.05 |
| | (or something like that) | 10:07.08 |
| kens | Not using emacs | 10:07.10 |
| | Will do 20 commits rahter than that | 10:07.18 |
| Robin_Watts | I feel the same about vi :) | 10:07.48 |
| kens | Yes, don't wnat to use vi either | 10:08.00 |
| | MingW doesn't have emacs anyway | 10:08.19 |
| Robin_Watts | btw, marcosw sent a link in an email about a webpage for helping to choose the meeting date. We should all use it. | 10:08.41 |
| | kens: right, but I'm sure you can find an editor that works. | 10:08.52 |
| kens | Robin_Watts : the only editor appears to be vi in MingW | 10:09.10 |
| tor8 | kens, Robin_Watts: squash squashes the commit into the *previous* commit, so you want the 'pick' to be the first commit. you get a chance to edit the commit messages later. | 10:09.11 |
| | and if you goof up, git-gui with 'amend' can let you rewrite the commit messages | 10:09.24 |
| kens | All Windows editors cause MingW to go back to the command prompt | 10:09.31 |
| Robin_Watts | Well, emacs is a windows editor, and it works for me. | 10:09.53 |
| kens | I don't have emacs on Windows. | 10:10.06 |
| | Obvuiously :-) | 10:10.11 |
| Robin_Watts | Right, but you should be able to find an editor that works - my point is that it doesn't need to be a special msys one. | 10:10.39 |
| tor8 | kens: hm, msysgit on my windows box (with no special configuration) picks 'vi' as its editor | 10:10.54 |
| kens | I can't find an editor that I have installed which it will work with | 10:11.00 |
| tor8 | I think it has to be a command line editor, that keeps the console busy until it's done | 10:11.13 |
| | so the typical gui editors probably won't work because they detach from the console, leaving git to think you're done | 10:11.46 |
| kens | export EDITOR=vi doesn't work, still launches write.exe | 10:11.57 |
| Robin_Watts | msys can be kept busy by windows apps too - if you run procexp for example, that starts procexp up, and doesn't give you the command line back until you exit it. | 10:12.19 |
| | If I run emacs I need to run emacs & to get the command line back instantly. | 10:12.33 |
| kens | Thats unusual behaviour in Wndows | 10:12.47 |
| Robin_Watts | Yes. msys is different to windows. | 10:12.59 |
| kens | Still, I can't use hte MingW emacs, it doesn't launch it | 10:13.07 |
| tor8 | kens: I don't have any EDITOR setting anywhere. maybe you've set it up with 'git config'? | 10:13.08 |
| kens | tor8 yes possibly | 10:13.19 |
| | How do I tell ? | 10:13.32 |
| tor8 | kens: git config -l to list your config options | 10:13.33 |
| Robin_Watts | core.editor="D:/Program Files/emacs-21.3/bin/emacs.exe" | 10:13.53 |
| kens | Yes, core.editor is set to write.exe | 10:13.56 |
| tor8 | kens: https://github.com/github/gitpad | 10:14.58 |
| kens | SO how do I change that ? | 10:14.59 |
| tor8 | a wrapper exe to let you use notepad.exe as your editor | 10:15.13 |
| | git config core.editor "new setting" | 10:15.21 |
| kens | Well its better than using vi or emacs.... | 10:15.42 |
| tor8 | certainly, if you're not used to either :) | 10:15.54 |
| chrisl | emacs is evil, at least vi is just deranged....... | 10:16.45 |
| kens | Well gitpad has installed itself, but doesn't do anything useful | 10:19.27 |
| tor8 | kens: I think you need to set your core.editor to it as well | 10:19.45 |
| kens | Yeah, I just can't find out how | 10:20.02 |
| tor8 | git config core.editor "c:/program files/wherever/gitpad.exe" ? | 10:20.31 |
| | or am I misunderstanding your question? | 10:20.59 |
| kens | Gitpad has set itelf up in 'AppData' and added an environment variable EDITOR which begins with a ~ | 10:21.17 |
| | So its obviously not a windows command | 10:21.24 |
| | But if I do git confgi core.editor EDITOR it doesn't work either | 10:21.44 |
| tor8 | git config --unset core.editor | 10:21.57 |
| kens | Nope straight back to command prompt | 10:22.55 |
| | "sucessfully rebased..." | 10:23.03 |
| tor8 | did you start a new command prompt, so the gitpad EDITOR setting has taken effect? | 10:23.42 |
| kens | Yes | 10:23.54 |
| tor8 | grasping at straws here... | 10:23.56 |
| | and there is no more core.editor config setting? | 10:24.16 |
| kens | I just reset the core.editor to the GitPad executable. | 10:24.39 |
| chrisl | Is there a global core.editor setting? | 10:24.52 |
| kens | Now it says C;/Program: No such file or directory | 10:24.58 |
| | Sio its getting confused by spaes in filenames | 10:25.08 |
| | Which is pretty crap since its a Windows app I presume | 10:25.24 |
| | Trying to launch notepad | 10:25.31 |
| tor8 | kens: hm, I can't get gitpad.exe to work either... | 10:25.44 |
| kens | Well at least its not just me | 10:25.58 |
| | OK if I set git config to vi it works. | 10:26.27 |
| | I'll struggle with that for now. | 10:26.35 |
| | SO I leave the *initial* commit as pick and change the later ones to squash ? | 10:26.59 |
| tor8 | kens: you could probably get an msys binary for nano or pico or one of those other notepad-like editors :) | 10:27.00 |
| kens | nano would be OK if I could find it. | 10:27.14 |
| tor8 | kens: yes, the first of your commit should be pick and the following ones squash | 10:27.21 |
| kens | Slowly doing that now | 10:27.41 |
| tor8 | then it pops back into the editor to let you edit the commit message | 10:27.42 |
| kens | Seems to be a reasonably usable version of vi, though I don't think much of the syntax coloring | 10:28.42 |
| chrisl | It's probably vim | 10:29.35 |
| tor8 | kens: I think it's vim. | 10:29.43 |
| kens | It may be | 10:29.53 |
| tor8 | which thankfully allows cursor keys :) | 10:30.06 |
| kens | Having to press 'esc' puzzled me for a bit | 10:30.07 |
| | it si now doing something, I don't know what | 10:30.19 |
| | (11/20) | 10:30.23 |
| | etc | 10:30.31 |
| | OK new file to edit with all the commit messages | 10:31.08 |
| | Well, again its doign something | 10:34.53 |
| | ANd it seems to be complete | 10:34.59 |
| | Yay, only one commit now. | 10:35.10 |
| | OK so how to get that back into master nad push it ? | 10:35.19 |
| tor8 | hopefully the one you wanted :) | 10:35.19 |
| kens | tor8 I hope so, but I'm ceasing to care... | 10:35.33 |
| tor8 | kens: are you on a separate branch? | 10:35.34 |
| kens | yes | 10:35.42 |
| Robin_Watts | kens: git checkout master | 10:35.54 |
| | git rebase other_branch | 10:36.01 |
| tor8 | kens: checkout the master branch (git checkout master) then pull in the other branch (git rebase my-other-branch) | 10:36.07 |
| | echo... | 10:36.14 |
| | echo.. | 10:36.15 |
| | echo. | 10:36.16 |
| Robin_Watts | plop | 10:36.24 |
| kens | Done all that. | 10:36.25 |
| Robin_Watts | and git logg should show master and the new branch all being the same ? | 10:36.41 |
| kens | Hmm I think so | 10:36.50 |
| Robin_Watts | (HEAD, master, new_branch) | 10:36.57 |
| | THen git push. | 10:37.11 |
| kens | HEAD new branch master | 10:37.12 |
| Robin_Watts | and if you want to be neat: git branch -D new_branch | 10:37.31 |
| tor8 | kens: you can then get rid of the branch with "git branch -D old_br....what robin just said :) | 10:37.39 |
| kens | lots of echos, but I'm grateful, thnks | 10:37.55 |
| Robin_Watts | tor8: We should just nominate one of us to answer a query in future :) | 10:38.01 |
| tor8 | Robin_Watts: but we usually don't pay attention to irc at the same time! | 10:38.21 |
| kens | And the cluster is running, lets hope its all OK ! | 10:38.26 |
| | Looked at the commit and it seems to have everything in there | 10:41.15 |
| | I'm going to keep the branch until I see the cluster result | 10:41.36 |
| Robin_Watts | The 'branch' is merely a record that says "the head of this branch is hash xxxxxx" | 10:42.25 |
| | and master and HEAD are both records that point to the same hash number. | 10:43.06 |
| kens | But if I undo the commit, the branch will still point to the altered code, correct ? | 10:43.44 |
| | Seems like an easy way to keep a pointer until I'm sure its OK | 10:43.53 |
| Robin_Watts | sure. | 10:43.59 |
| ghostgum | mirror.cs.wisc.edu ghostscript files weren't completely removed. They are in ~ghost/old_mirror. These are accessible only by the ghost account. | 10:57.54 |
| Robin_Watts | Could we get shelley to look at bug 693025 as a bountiable thing ? | 11:58.20 |
| kens | which one is that ? | 11:58.36 |
| Robin_Watts | zenikos jbig2dec fixes. | 11:59.05 |
| kens | OK then that makes good sense | 11:59.16 |
| Robin_Watts | IME, many of his fixes are spot on, but many of them actually just patch around a deeper problem. | 11:59.30 |
| kens | check with henry but I would think it would be oK | 11:59.54 |
| Robin_Watts | so taking them on or not requires a certain understanding of the underlying code - and I don't have that for jbig2dec. | 12:00.03 |
| | kens: sure. | 12:00.23 |
| sebras | tor8 Robin_Watts: did you find the type3-bug eventually? | 12:07.47 |
| Robin_Watts | sebras: Nope. I didn't look. | 12:11.05 |
| | tor8: Got a couple of minutes? | 12:13.42 |
| tor8 | Robin_Watts: yes. | 12:15.05 |
| Robin_Watts | The idea about making mupdf not have to load everything in streams into memory... | 12:15.27 |
| tor8 | talking about the content streams? | 12:15.44 |
| Robin_Watts | The problem with that is that we might get competing seeks on the underlying files, right? | 12:15.52 |
| | Yes, exactly. | 12:15.54 |
| | I believe the pattern of use we might see is that we'll be part way through reading/executing a content stream, and then we'll have to zap off somewhere else to read a resource object. | 12:17.02 |
| tor8 | quite | 12:18.23 |
| Robin_Watts | What we need to be able to do is to store the stream pointer before we move off elsewhere, and to put it back when we come back (i.e. ftell, fseek). | 12:18.27 |
| | I had an idea about how to get that done automatically for us for streams, but it's just dawned on me that objects are a problem too. | 12:18.55 |
| tor8 | and not mess up the internal buffers of the chain of filters | 12:18.56 |
| | yeah, any seeking of the underlying file while there is a stack of filters reading on top is problematic | 12:19.38 |
| Robin_Watts | I had figured that we could change the fz_open_null function to read and store the original stream_pos. and then fseek back to it in close_null. | 12:19.56 |
| tor8 | one solution would be to have each filter store the 'offset' of its chain | 12:19.58 |
| Robin_Watts | Yes. | 12:20.05 |
| tor8 | so every read would start with an offset or seek | 12:20.09 |
| | that should solve it most elegantly I think | 12:20.18 |
| Robin_Watts | I'd be tempted to roll the requested offset into the read. | 12:20.32 |
| tor8 | then we can push and pop and read anywhere with nested chains etc | 12:20.40 |
| | so, pread(2) basically? | 12:20.53 |
| Robin_Watts | possibly :) | 12:21.01 |
| tor8 | as long as we don't do it from multiple threads we should be re-entrant at least | 12:21.21 |
| | or whatever the word I'm looking for is | 12:21.32 |
| Robin_Watts | If we are prepared to change the fz_stream structure, then there are other things I'd like to do to it too. | 12:21.47 |
| tor8 | one hitch though, the filters can't seek backwards | 12:21.51 |
| Robin_Watts | Filters will never need to. | 12:22.05 |
| tor8 | the encryption, null and/or copy filters might need to (but I'm not sure) | 12:22.53 |
| | what other changes do you want to do? | 12:23.00 |
| Robin_Watts | An alternative approach would be to wrap the initial stream into one that can be cloned. | 12:23.18 |
| | or wrap it in a 'cloner' stream when we make a filter out of it. | 12:24.20 |
| | The cloner would do nothing but ensure that it always seek/reads and used its local storage. | 12:24.46 |
| | That could be achieved with no changes to the stream functions/structures at all, I think. | 12:25.12 |
| | In fact, the null stream may be perfectly placed to do that already. | 12:25.46 |
| | Other changes? | 12:26.37 |
| | It offends my sensibilities that for every stream we a) have a 4K buffer, and b) have to do 2 mallocs. | 12:27.00 |
| | Rather than having a separate 'state' pointer to a second block, I'd rather switch to doing a 'derived class' thing where every fz_stream_blah starts with an fz_stream. | 12:28.24 |
| | BUT... there may be a strong argument to be made for not changing the structure if we can get away with it, and updating the null filter may offer us a cheap(free) way of getting around this problem. | 12:29.05 |
| tor8 | 2 mallocs? there's only one malloc... | 12:30.05 |
| | oh, you mean the state thing | 12:30.20 |
| Robin_Watts | Yes. | 12:30.23 |
| | I mean have the state and the stream in the same block. | 12:30.35 |
| tor8 | doesn't bother me one bit. streams are not numerous. | 12:30.38 |
| Robin_Watts | Right. It's not a showstopper by any means. | 12:31.07 |
| | but if we were changing it anyway... | 12:31.19 |
| tor8 | subclassing with embedded structs I consider an evil but sometimes worthwhile hack :) | 12:31.23 |
| Robin_Watts | but I hope that by tweaking the null device we can avoid any nasty changes. I'll give it a whirl. | 12:31.44 |
| tor8 | and the void* userdata thing makes it trivial for clients to extend | 12:31.45 |
| | and makes the binary api a bit more stable | 12:32.03 |
| | if we are to change it, I think making read() take an explicit offset would make it more robust against mistakes with the filter pushing and popping | 12:32.40 |
| | not sure how you envision the cloner / null device to work, but I look forward to see what you come up with | 12:33.21 |
| Robin_Watts | Every filter is based on the 'null' device already. | 12:33.41 |
| | Whenever the filter sucks data, the null device calls the underlying stream to suck data into the null devices 4K buffer. | 12:34.09 |
| tor8 | we start every stream with the null filter just to set the EOF to the stream length | 12:34.10 |
| | right | 12:34.15 |
| Robin_Watts | So if the null device keeps track of the desired position in the underlying file, and always 'seek/reads' rather than just reading, we'll always get the data we want. | 12:34.55 |
| tor8 | so turn the null device into said clone device that remembers the offset and allows multiple copies on top. right. I see what you're getting at. | 12:35.09 |
| | allows multiple null streams on top of a base stream, i.e. | 12:35.28 |
| Robin_Watts | "allows multiple copies on top" = something we get for free. | 12:35.42 |
| tor8 | actually, that's a pretty smart idea :) wish I'd come up with it! | 12:35.44 |
| Robin_Watts | :) | 12:36.00 |
| tor8 | that lets us seek in the underlying stream while filters are still on top | 12:36.01 |
| Robin_Watts | yes. | 12:36.13 |
| | I was worried about introducing a new stream just to do that, but there is one in exactly the right place already :) | 12:36.36 |
| tor8 | fz_open_null could be extended to take three arguments (chain, offset, length) rather than just the two if you want to make it more clear | 12:36.36 |
| Robin_Watts | tor8: Yes. | 12:36.47 |
| tor8 | it's in the internal header so no worries there | 12:37.03 |
| Robin_Watts | Either that or it needs to read chain->pos, and we need to fz_seek before making an fz_open_null. | 12:37.13 |
| | But changing the function is nicer. | 12:37.22 |
| tor8 | I think changing the function makes it clearer that it isolates the stream and seeking outside its context is 'okay' | 12:37.53 |
| Robin_Watts | Oh, wait... fz_open_null is called from pdf_open_filter | 12:37.54 |
| | Hmm. I mean it's called from other places. | 12:38.27 |
| tor8 | Robin_Watts: with icky fragile bits of code to make sure the stream is at the right offset | 12:38.29 |
| Robin_Watts | so they would need to change a bit. | 12:38.37 |
| | but that may be neater overall. | 12:38.44 |
| tor8 | Robin_Watts: that's where you want the changes isn't it? | 12:38.46 |
| Robin_Watts | Yes. I'll bash on this this afternoon and upload a patch for your comments. | 12:39.37 |
| tor8 | pdf_open_inline_stream is the only one you have to worry about | 12:39.38 |
| | since that's used for inline image data streams | 12:39.48 |
| Robin_Watts | stream->pos is the offset of the start of the buffer? or the offset of the current point? | 12:40.38 |
| | Ah, fz_tell :) | 12:41.07 |
| | Well, it builds. I'll test it after lunch, so I can have 30 minutes of happiness :) | 12:45.59 |
| tor8 | Robin_Watts: it should be the offset of the end of the buffer IIRC | 12:46.12 |
| kens | Hmm, still have to work on freeing CIDFont resources :-( | 12:51.06 |
| spencer | Hey all, I'm trying to use the @filename switch on windows, but ghostscript crashes. Can I mix it with other cmd line args, or do I have to put all args into the file? | 13:10.55 |
| kens | I believe you cna m ix and match | 13:11.39 |
| | but I've never tried | 13:11.44 |
| spencer | Hmm, then why would it be crashing? I'm using it to get around the Windows error 87 problem. | 13:12.21 |
| kens | don't know. | 13:12.36 |
| | Woudl have to debug it | 13:12.41 |
| spencer | So I bumped into an unused portion of the code base? | 13:13.22 |
| kens | Perhaps, or perhaps its 'something else' | 13:13.36 |
| | IIRC you are using Windows 7 | 13:13.42 |
| spencer | Win 7 64 bit and a Win XP 32 bit | 13:13.59 |
| kens | Both the same ? | 13:14.06 |
| spencer | Yup | 13:14.12 |
| kens | When you say 'crash' what exactly do you get ? | 13:14.23 |
| spencer | Pop up message saying that gswin32c has crashed. I can give you the dump windows attaches. | 13:15.06 |
| kens | NO, that's fine | 13:15.14 |
| | Just sometimes people describe erors messages as 'crash' | 13:15.28 |
| | I think the best thing is to open a bug report | 13:15.51 |
| spencer | Hmm, just ran a test and the option does work if I strip out practically all the cmd line args | 13:16.15 |
| kens | There you can attach your command line and a file to exhibit the problem | 13:16.21 |
| spencer | I must have something off in the cmd line | 13:16.28 |
| kens | spencer : then it sounds like you ahev come across some incompatible opption | 13:16.38 |
| | Obviously it shouldn't crash though | 13:16.49 |
| | So still worth opening a bug report | 13:17.07 |
| spencer | I'll create a bug report so it's documented then | 13:17.11 |
| | It might also be the ordering of the, I hadn't thought of that | 13:17.54 |
| kens | well it still shoudn't crash.... | 13:20.21 |
| spencer | bug report created, I need a work around for this now though, so I'm going to investigate having all of the cmd args inside the @file. | 13:35.24 |
| kens | Makes sense, thanks for the report | 13:35.35 |
| spencer | Question though, since gs is handling the contents of the @file, how does it parse cmd line args? | 13:37.17 |
| | I had been doing the parsing using a modified version of the envoy library | 13:38.00 |
| kens | @file is a command line argument | 13:40.47 |
| | So its just another argument (at least, as far as I know) | 13:41.00 |
| chrisl | spencer: can you get around the problem by putting your options in a Postcript file? | 13:41.07 |
| | The problem is (it seems) GS is trying to open the options file before IO has been initialised - no idea how we'd get around that....... | 13:41.54 |
| spencer | chrisl: I haven't tried that. I'm not sure how all of the options would translate into postscript. You can check the bug 693026 for the full set | 13:43.28 |
| chrisl | spencer: you haven't stated what's in your @tmpfile | 13:44.02 |
| spencer | A list of pdf file names | 13:44.12 |
| | It's dynamically generated, and I tried with one file name and the whole set | 13:44.38 |
| chrisl | Okay, so instead of putting that list in the @tmpfile, you could create a tmpfile.ps with contents like: http://pastebin.com/7zYiEPCb | 13:46.34 |
| spencer | That might work, I'll try it in a little bit | 13:48.41 |
| chrisl | spencer: basically, that all that GS does internally with the list of file names you give on the command line. | 13:49.25 |
| Robin_Watts | mvrhel_laptop: Morning | 13:53.11 |
| | What's the difference between tiffsep and tiffsep1? Just that tiffsep1 is 1bpp ? | 13:53.48 |
| | 1bpc, even. | 13:53.55 |
| | Would a neater solution not be to have a -dBitsPerComponent option on tiffsep ? | 13:54.30 |
| chrisl | Robin_Watts: mainly, it also doesn't produce a contone proof | 13:54.48 |
| | Robin_Watts: using a option is possibly more viable if it's a planar device? (guessing) | 13:55.41 |
| Robin_Watts | chrisl: That was my thought. | 13:55.53 |
| | artifex.dsis.co.uk looks almost unreadable on a kindle :( | 13:56.30 |
| chrisl | Because of the grays? | 13:56.45 |
| Robin_Watts | yes. It'd be fine in black. | 13:56.59 |
| mvrhel_laptop | good morning | 13:57.11 |
| mace | Robin_Watts: artifex.dsis.co.uk vs artifex2.dsis.co.uk | 13:58.06 |
| mvrhel_laptop | Robin_Watts: to tiffsep1 is just like teffsep, except the composite image is not create, and after rendering to contone it is halftoned | 13:58.14 |
| | kind of odd | 13:58.17 |
| Robin_Watts | mace: MUCH better on the kindle. | 13:59.44 |
| | and I have to say, that personally, I prefer it on chrome too. | 13:59.56 |
| | Less washed out. | 14:00.10 |
| mace | fine by me, makes for a faster download ;-) | 14:00.57 |
| Robin_Watts | Anyone else here have any opinions on artifex.dsis.co.uk vs artifex2.dsis.co.uk ? | 14:01.41 |
| mace | on the other hand the 20 bytes saved by that change are more than going to get eaten up by the change of the big buttons from jpeg to png :/ | 14:01.45 |
| mvrhel_laptop | Robin_Watts: not sure if you the whole tiffsep1 stuff is of interest to you. It would be pretty easy for me to move it over to planar since I just did the other 2 sep devices. | 14:02.29 |
| Robin_Watts | mvrhel_laptop: I have to say that I'd prefer to concentrate on mupdf and/or gs scan conversion. | 14:03.01 |
| | but if henrys wants me to look at it, then so be it. | 14:03.12 |
| mvrhel_laptop | Robin_Watts: I think that is a better use of you time | 14:03.15 |
| Robin_Watts | It did strike me that it might be easier to just add a -dBitsPerComponent option (or something similar) to tiffsep and lose tiffsep1 entirely. | 14:03.50 |
| mvrhel_laptop | dont spend any time on it until we talk to henry | 14:03.52 |
| | Robin_Watts: yes I will think about that a bit | 14:04.09 |
| Robin_Watts | Seems silly to maintain 2 separate devices that basically do the same thing to me. | 14:04.11 |
| kens | for some stuff the artifex.dsis.co.uk is OK but for most I prefer the black text | 14:04.17 |
| chrisl | Robin_Watts, mvrhel_laptop: I'm guess it was done as two devices because of the post-process halftone in tiffsep1 | 14:05.02 |
| Robin_Watts | chrisl: Yes. But now we can halftone as part of the core, that may no longer be the overriding factor. | 14:09.21 |
| chrisl | Robin_Watts: That's what I meant when I said making it planar probably removes the need | 14:10.02 |
| mvrhel_laptop | right | 14:10.41 |
| Robin_Watts | tor8: ping | 15:57.48 |
| | For type3 fonts and for patterns we load the contents into a buffer. | 15:58.18 |
| | Should we keep doing that, or should they go to read from the file too ? | 15:58.35 |
| tor8 | Robin_Watts: I'd keep them in buffer for now. | 16:20.23 |
| Robin_Watts | That may not be trivial. | 16:20.43 |
| tor8 | Oh? open_buffer works does it not? | 16:21.03 |
| Robin_Watts | Currently I'm changing them to be pdf_obj *'s rather than fz_buffer *'s, but we can revert that if required. | 16:21.41 |
| tor8 | alright | 16:24.37 |
| | I don't have a convincing argument for either case :) | 16:25.00 |
| Robin_Watts | TBH having one done one way and one done the other is probably not hard. | 16:25.20 |
| tor8 | I just figured leaving them as buffers would mean less things to change | 16:25.40 |
| Robin_Watts | but it requires me to duplicate a function and edit 2 copies. | 16:25.43 |
| tor8 | or fewer as it were | 16:25.55 |
| Robin_Watts | At the moment I'm changing pdf_run_buffer to be pdf_run_contents where it takes an fz_obj *contents rather than an fz_buffer *contents. | 16:26.20 |
| tor8 | not a fz_stream then? | 16:27.09 |
| Robin_Watts | pdf_run_contents will make a stream from the obj. | 16:27.26 |
| | (I'm changing my mind here as I go - don't expect consistency :) ) | 16:27.45 |
| tor8 | ah wait, we already have a pdf_run_stream | 16:27.52 |
| | right, so change the run_buffer to whatever fits best | 16:28.02 |
| Robin_Watts | tea | 16:30.54 |
| | tor8: Can you remember by pdf_open_image_stream is in mupdf-internal.h (rather than being static) | 16:51.50 |
| | s/by/why/ | 16:51.55 |
| | ? | 16:52.03 |
| tor8 | no... | 16:52.20 |
| Robin_Watts | ok. | 16:52.33 |
| | tor8: Cor. | 16:55.48 |
| | I get locking warnings (which are to be expected), but it works. | 16:56.00 |
| tor8 | sweet! | 16:56.07 |
| Robin_Watts | (on my exhaustive 1 file, 2 page test :) ) | 16:56.25 |
| | http://www.bbc.co.uk/news/world-us-canada-17949808 | 17:02.22 |
| | tor8: ping | 18:12.43 |
| | This change has put me into locking hell. | 18:13.03 |
| | It used to be that we'd take the file lock before we did any seeks on the main file, and release the lock afterwards. | 18:14.13 |
| | Hmm. poorly expressed. Let me try again. | 18:14.29 |
| | It used to be that we'd take the file lock before we did any seeks on the file handle, and released the lock once we'd finished all the reads based upon that seek. | 18:14.58 |
| | We are now reading from the file during interpretation, so when we try to perform actions that involve fetching resources/resolving indirections etc, those things try to access the file too, and the locking gets confused. | 18:18.09 |
| | One simple solution would be to make the FZ_FILE_LOCK recurseive. | 18:18.35 |
| | (or recursive) | 18:18.41 |
| | but I'm wondering whether we can safely just remove the FZ_FILE_LOCK entirely. | 18:19.22 |
| tor8 | Robin_Watts: silly question, but why do we even need the lock? to prevent accidents when idiot clients try to use the file from mroe than one thread? | 18:19.33 |
| sebras | Robin_Watts: why can't you just release the lock before doing the fetching of resources? | 18:19.50 |
| tor8 | cocking up threading by accessing the document from more than one thread is going to fail miserably one way or another anyway, so I don't really see the point of the file lock | 18:20.00 |
| sebras | and take it again afterwards (i.e. why keep the file locked?). | 18:20.12 |
| Robin_Watts | sebras: I could, but that would produce a plethora of lock/unlocks throughout the code. | 18:20.17 |
| | sebras: Currently that's done pretty much automatically by the stream code. | 18:20.37 |
| sebras | wouldn't the resource fetching be located in just one place..? | 18:20.56 |
| Robin_Watts | no. We can need to access the file whenever someone does a: pdf_is_int etc. | 18:21.23 |
| tor8 | all file access should still happen in only the main thread. unless you wanted the image resource decoding callbacks? | 18:21.30 |
| Robin_Watts | tor8: Originally, I think I'd hoped that the file lock would allow us to get away with doing stuff in 2 threads (albeit inefficiently). | 18:22.23 |
| | but I think that's gone by the by. | 18:22.37 |
| | Decoding images from files might be nice to aspire to one day. | 18:23.07 |
| tor8 | well, no need to complicate today's work by worrying about that, IMO. just rip out the file lock and mandate all file access must be in one thread. we can figure out how to decode images from files in a separate thread another day. you already save them compressed in the fz_image struct and I think that's good enough for quite some time now. | 18:24.26 |
| Robin_Watts | Part of the attraction of having the lock is that the debugging then checks that mandate. | 18:26.19 |
| | but you may well be right. | 18:26.29 |
| tor8 | anyone using the high level api:s won't ever see the file (hopefully) | 18:26.55 |
| Robin_Watts | tor8: Well, I think we're going to be expecting people to use fz_open_document_with_stream at some point, right? | 18:27.25 |
| tor8 | assert(get_current_thread == original_thread) would be nice to have though :) | 18:27.37 |
| | Robin_Watts: yeah, especially for the thing we discussed yesterday with appending data to it | 18:27.59 |
| Robin_Watts | tor8: That's what a recursive lock would give us nicely. | 18:28.05 |
| tor8 | but the locks should be per file then IMO and not just a global 'all files are locked now' in the context | 18:28.24 |
| | but file locks for multithreading, I dunno, it just stinks. files aren't a multithreaded resource. | 18:28.47 |
| Robin_Watts | I can use the FZ_LOCK_FILE to implement a recursive per file lock. | 18:29.20 |
| tor8 | now a threadsafe "readp" call for files, that might work better. | 18:29.29 |
| | but then you want a different api than open/read/close for data access altogether. | 18:30.02 |
| Robin_Watts | Actually, no I can't. | 18:31.25 |
| | I need a lock + a semaphore (or a mutex or something equivalent) | 18:31.50 |
| | Do we need a lock to be able to safely implement the appending stream thing ? | 18:32.17 |
| | Do you forsee us using multiple documents with a single context? | 18:33.29 |
| | (I don't, I think) | 18:33.45 |
| | If not, then we have one file lock per document. | 18:33.58 |
| | I'm going to rip out the file lock entirely (well, leave it in there, but unusued). | 18:34.57 |
| | And we can reuse it to do the appending stream thing. | 18:35.06 |
| kens | Robin_Watts : tor8 can you answer the email about 'Linear PDF' please ? As its MuPDF | 18:41.49 |
| | I'm sure the answer is 'yes' but ti might be ebst to some from one of you | 18:42.02 |
| Robin_Watts | mace: miles likes the black text too. | 18:42.55 |
| kens | God my typing is bad tonight | 18:42.58 |
| Robin_Watts | kens: I will answer. | 18:44.06 |
| kens | Thanks | 18:44.13 |
| mvrhel | Gigs: you around? | 19:03.40 |
| mace | Robin_Watts: ok i'll switch to that | 21:11.09 |
| mvrhel | hi marcosw: how has the show been?" | 21:23.52 |
| | ok so still a few DeviceN sep planar issues... | 21:30.12 |
| | we will need to get the customer an update probably early next week | 21:30.25 |
| | alexcher: are you around? | 22:29.18 |
| | alexcher: I just gave you a bug. | 22:39.24 |
| | If you could take a lok at it, I would appreciate it | 22:39.37 |
| | fairly certain it is a PDF interpreter issue | 22:39.49 |
| | Forward 1 day (to 2012/05/05)>>> | |
IRC Logs