| | <<<Back 1 day (to 2013/09/19) | 2013/09/20 |
| Robin_Watts | http://gawker.com/public-masturbation-declared-legal-in-sweden-after-land-1340599730 | 08:21.37 |
| kens | Well, Tor's OK then | 08:22.23 |
| paulgardiner | tor7: ping | 08:26.27 |
| tor7 | paulgardiner: pong. | 08:27.25 |
| paulgardiner | I think I mentioned before a crash from the iOS app when clicking the "Library" button (really on closing MuDocumentController). I'm seeing that again. | 08:28.49 |
| | What's happening is the doc is being freed before the pages. | 08:29.12 |
| | Presumably that was never happening with older iOS versions. | 08:29.43 |
| tor7 | paulgardiner: more fz calls running on the wrong threads? | 08:29.50 |
| paulgardiner | I don't think so | 08:30.10 |
| tor7 | it wouldn't surprise me if apple have tweaked how the thread dispatch and destructors interact with objc reference counting | 08:30.38 |
| paulgardiner | Oh! I suppose the fact that the background thread is used via a queue implies that we just need to ensure the correct order of putting the requests on the queue | 08:31.21 |
| tor7 | MuPageView could be freed later then, I suspect | 08:31.41 |
| paulgardiner | Ah yes. You are probably right | 08:31.43 |
| Robin_Watts | "just" | 08:32.01 |
| paulgardiner | One idea is to wrap fz_document and fz_page in objective-C classes and then have the page hold a ref to the doc. | 08:32.28 |
| | But I don't want to go down that route if it's overkill. | 08:32.42 |
| tor7 | or maybe we don't really need to hold on to the fz_page object in MuPageView ... I suspect we could just load the page to a display list | 08:32.49 |
| Robin_Watts | paulgardiner: I'm doing that in the java, and it's proving problematic. | 08:32.54 |
| | s/java/jni/ | 08:32.59 |
| | How do you ensure that the document isn't destroyed until after the page? | 08:33.16 |
| paulgardiner | Robin_Watts: Oh right. :-( | 08:33.23 |
| Robin_Watts | currently I have the Page holding a ref to the Document (capitals being the java object). | 08:34.03 |
| paulgardiner | Robin_Watts: in the objective C case, the pages' refs of the doc would ensure it? | 08:34.15 |
| Robin_Watts | the Page also holds an fz_page, and then Document holds an fz_document | 08:34.26 |
| tor7 | paulgardiner: there's some lazy loading of the fz_page in MuPageView. if we just load/free directly instead of holding on to it would be a quick fix. | 08:34.33 |
| Robin_Watts | When someone does a Document.close() though... what do I do? | 08:35.08 |
| | Actually, ignore me for now. I'll stick a patch up later for you guys to look at. | 08:35.26 |
| paulgardiner | Robin_Watts: Ah nasty. I don't think I have that problem in the objective C. | 08:35.39 |
| tor7 | Robin_Watts: I suspect having circular reference from the Page back to Document would prevent the document from being finalized, but ick, then you get into weak reference territory. all madness. | 08:36.08 |
| paulgardiner | Robin_Watts: I have no need to provide expicit close | 08:36.14 |
| tor7 | Robin_Watts: the Document could set all Page objects to be invalid (and then toss an exception if they're used) | 08:36.43 |
| | but that's going to be awkward doing all those checks in the language bindings | 08:37.07 |
| Robin_Watts | tor7: yes, that might be nicest. That's what I'm doing with Annotations I think. | 08:37.22 |
| | tor7: actually, that probably falls out nicely. | 08:37.36 |
| tor7 | one thought I had was to change the mupdf api to not expose the fz_page, all page accesses go through document+pagenumber | 08:37.38 |
| Robin_Watts | tor7: The alternative is to make fz_document reference counted. | 08:38.05 |
| tor7 | Robin_Watts: or we do the checks in the c level too | 08:38.13 |
| Robin_Watts | at least internally. | 08:38.20 |
| tor7 | fz_page isn't reference counted at the moment (and it would be awkward for xps and cbz to do so) | 08:39.01 |
| Robin_Watts | ok. having Document keep an array of pages is probably easy enough. | 08:39.38 |
| | I'll look at that when I get back from shooting. | 08:39.47 |
| paulgardiner | tor7: We'd need to be careful with the swap to using doc and page number. I believe you pointed out how the way of handling partial update I introduced interacted badly with that | 08:40.52 |
| | ... or maybe that was the idea of caching pages in the doc | 08:41.25 |
| tor7 | paulgardiner: I can't remember any of that... | 08:42.00 |
| | but no, I don't think we should solve it that way. rather get a proper story together for reference counting and ownership of sub-owned objects. | 08:42.24 |
| paulgardiner | tor7: Nor can I remember the detail, but I'm fairly sure it was discussed | 08:42.33 |
| tor7 | or dependent, or what it's called | 08:42.37 |
| | annot is derived from page, page is derived from document, etc | 08:43.02 |
| paulgardiner | Yeah, I imagine that would work best | 08:43.22 |
| tor7 | it's common enough that we should have a proper solution for it. it hasn't been an issue yet because in C it's pretty easy to not mess up. | 08:43.26 |
| | but with multi-threading and foreign language bindings with garbage collection, not so much | 08:43.47 |
| | Robin_Watts: so reference counted fz_document (from fz_page) and fz_page (from fz_annot) may be the way to go | 08:44.25 |
| | and fz_document would only hold weak references to the pages (or none at all) | 08:45.05 |
| paulgardiner | For the iOS app, I might introduce objective C wrappers even if it is just temporary because it seems pretty certain that it will solve it | 08:45.19 |
| | I think we render without going via display lists, so the alternative would require adding use of display lists before I could remove the holding of the page | 08:46.19 |
| tor7 | paulgardiner: I don't understand how that will solve it, you'll still have lifetime issues even with the wrappers? | 08:46.24 |
| paulgardiner | I make the page wrapper hold a objective C level ref to the doc wrapper | 08:46.52 |
| tor7 | paulgardiner: the page is reused between doing text search, showing links, and drawing the page. try it by just not holding on to the page and reloading it each time to see if that solves the crash. | 08:47.08 |
| paulgardiner | I could do, but I'm 99% certain it will solve it. | 08:47.56 |
| tor7 | paulgardiner: a reference from MuPageView to MuDocumentController? | 08:48.04 |
| paulgardiner | That's a thought | 08:48.23 |
| | I'll look into that | 08:48.30 |
| tor7 | because those are basically the current wrappers. might want to double check that you don't get into circular reference territory though. | 08:48.47 |
| | or at least have a manual teardown function to break the circular dependency when the controller is supposed to shut down | 08:49.25 |
| paulgardiner | Right. Just to make clear, the wrappers I was thinking of adding would have been trivial. I wasn't thinking of adding methods for each fz func. Just a class to keep a reference and give access directly to the raw doc and page | 08:50.34 |
| | Hang on: isn't the reference from MuPageView to MuDocumentController pretty much certain to cause a circular ref problem | 08:53.36 |
| tor7 | the documentcontroller has a UIScrollView that holds the MuPageViews | 08:56.26 |
| | you could clear out the UIScrollView on viewWillDisappear (or maybe another callback is better) | 08:57.08 |
| | actually, that's probably just going to solve your current problem with no other changes | 08:57.36 |
| | or should, unless the UI framework is holding on to them elsewhere. which is probably what's happening. | 08:58.06 |
| paulgardiner | Yeah, introducing MuPageRef and MuDocRef might be a more general solution | 08:58.12 |
| | that will work without much thinking out of exactly how it works | 08:58.43 |
| tor7 | if we do the proper solution (refcounting in the mupdf library itself) nothing would need to change here | 08:58.55 |
| paulgardiner | And I could remove the changes | 08:59.13 |
| tor7 | but that would mean an API change (fz_close_document -> fz_drop_document) | 08:59.17 |
| | actually, I could be convinced to eradicate all "close" and "free" functions and use "drop" for *all* objects, refcounted or not | 08:59.54 |
| | to make future changes less likely to break existing code | 09:00.10 |
| | paulgardiner: yeah. I suspect any solution we think of now is going to hit snags somewhere, so it may make sense to try a few different ones. | 09:00.42 |
| paulgardiner | I don't know: while we have non-ref-counted objects, I think it's good to distinguish | 09:00.54 |
| | You have to call free in a very different way to drop | 09:01.08 |
| tor7 | paulgardiner: in all cases I can think of, moving from free to drop doesn't change how things are called | 09:05.28 |
| | the other way around, certainly | 09:05.38 |
| | and knowing the distinction is why we've kept the calls separate | 09:05.57 |
| | but it does lead to a lot of churn when we add refcounting to something | 09:06.07 |
| paulgardiner | I more meant that others writing new apps might make mistakes if they assumed the word drop meant the object was ref counted... but the I guess the lack of an addref func would make it clear | 09:07.40 |
| | s/the/then | 09:07.56 |
| | s#then#then/# :-) | 09:08.17 |
| Robin_Watts | back later. | 09:10.13 |
| sebras | Robin_Watts: tor7: did you see my comments on zeniko's patch? | 11:26.27 |
| Robin_Watts | sebras: Not checking fz_read's return value happens in a lot of places I think. | 11:30.40 |
| | Personally, if we don't check it, I like the explicit cast to void to point out that we know we're not checking it, and we've thought about it. | 11:31.09 |
| sebras | sure, but I'd like it to be consistent. | 11:31.32 |
| | either way is fine with me. | 11:31.53 |
| | this patch adds both approaches. | 11:32.41 |
| Robin_Watts | Bah. java doesn't like explicit casts to voids. | 11:47.35 |
| kens | Hmm, someone here using Ghostscript and licencing their work under Mozilla Public licence, does that sound legitimate ? | 12:13.51 |
| chrisl | Depends if they are including GS? | 12:14.20 |
| | Oh, actually, it probably depends on a lot of things - if they don't include GS, and just call the exe, it may be okay | 12:15.26 |
| Robin_Watts | paulgardiner, tor7: With annotations... | 12:52.02 |
| | Is it the intention that we should be able to call fz_first_annot to get an annotation pointer P, then call fz_next_annot etc and still have P be valid? | 12:52.45 |
| | i.e. it's not just one at a time? | 12:53.04 |
| paulgardiner | I don't think we anywhere currently rely on that. | 12:53.31 |
| Robin_Watts | paulgardiner: The natural java interface is to have an array of annotations. | 12:55.39 |
| | hence I need to make an array of java Annotation objects. | 12:55.51 |
| paulgardiner | I was just thinking the same | 12:55.52 |
| Robin_Watts | It would be nice if each one could just have a pointer to the native thing internally, rather than having to 'find' itself by stepping each time. | 12:56.17 |
| tor7 | Robin_Watts: fz_annot_count, fz_annot_index(i) might be easier to map than an iterator? | 12:56.25 |
| | Robin_Watts: if thinking about keeping the wrapper layer as thin as possible, otherwise you can just load them all into an array in Page.java or something like that (and no, I wouldn't agree with that design choice) | 12:57.31 |
| Robin_Watts | tor7: Ah, currently I was proposing to just load them into an Annotation [] in the java. | 12:58.09 |
| | The 'natural' java interface is for them to be available as an array, I think. | 12:58.26 |
| tor7 | Robin_Watts: well, you should be able to do that already. the fz_first/next is just a wrapper around the linked list implementation | 12:58.43 |
| | Robin_Watts: java uses enumerators everywhere doesn't it? | 12:58.57 |
| Robin_Watts | tor7: Why do you object to the array? | 13:02.59 |
| tizio72 | Is it possible to compile MuPDF to use Multi-threading? ..If YES would you reccomend Pthread or OpenMP? | 13:03.04 |
| Robin_Watts | tizio72: Yes, it's perfectly possible. | 13:03.17 |
| tor7 | Robin_Watts: because it doesn't map naively to the underlying data structure | 13:03.34 |
| Robin_Watts | MuPDF doesn't care - it's up to the user to supply the lock/unlock functions. | 13:03.42 |
| tizio72 | I've an AMD APU based machined and would like to skip the INTEL comppiler CPUID check | 13:03.50 |
| tor7 | do you want to do a separate java array for each kind of list we have in mupdf? | 13:04.07 |
| Robin_Watts | tor7: Yes. | 13:04.16 |
| tor7 | I'd rather see an iterator (like first/next) or an array-like accessor function (count/index) | 13:04.25 |
| Robin_Watts | Fitting the interface to the implementation is bad practise right? | 13:04.34 |
| | Let's figure out the interface that we'd like to offer people, and try to fit that to the implementation. | 13:05.02 |
| tizio72 | Is there any scale-up data available for MuPDF? ..in order to see how well it does scale with 4 Cores/Threads? | 13:05.14 |
| Robin_Watts | An array is a much simpler beast than iterators. | 13:05.16 |
| tor7 | there isn't a 1-to-1 mapping between data types and functions between the C and the Java interface with your proposal | 13:05.17 |
| Robin_Watts | tor7: Indeed. The java interface is "more natural to java". | 13:05.44 |
| | for (Annotation a: annotations) { ... } etc | 13:05.58 |
| tor7 | Robin_Watts: yes, but then we have two separate interfaces to document... | 13:06.02 |
| Robin_Watts | Being called for food. back soon. | 13:06.05 |
| | sorry. | 13:06.10 |
| tor7 | I'd like it if it was possible to look at one set of data types and functions and know how to use the library from any language we support (C, Java, Lua, anything else we add later) | 13:07.43 |
| kens | chrisl I had to go give blood, I suspec they are using the Windows DLL, given the app is written in C# | 13:13.37 |
| | chrisl it uses Ghostscript.net which is another project form the same developer | 13:14.30 |
| | chrisl he's using the gsapi_* calls | 13:16.06 |
| tizio72 | Is there any scale-up data available for MuPDF? ..in order to see how well it does scale with 4 Cores/Threads? | 13:16.06 |
| chrisl | kens: I think it depends: they definitely can't ship GS as MPL, and they definitely couldn't link closed source code to the DLL. But a more permissive open source license, not sure at all. | 13:16.24 |
| kens | Well I guess if MPL is more open we probably don't mind | 13:16.50 |
| chrisl | kens: have you got a URL for it? | 13:17.13 |
| kens | sure, here's the one for Ghostscript.et: | 13:17.45 |
| | http://ghostscriptnet.codeplex.com/ | 13:17.45 |
| | And this is 'Ghostscript Studio': | 13:18.31 |
| | http://ghostscriptstudio.codeplex.com/team/view | 13:18.31 |
| | coffee brb | 13:18.37 |
| chrisl | Hmm, heavy use of the "Ghostscript" name - not sure about that...... | 13:18.48 |
| henrys | chrisl:let's have a bug report on the urw problem then I'll contact you or send you contact info whichever you prefer. | 13:45.33 |
| chrisl | henrys: okay, fine | 13:48.07 |
| Robin_Watts | tor7: back. | 13:51.34 |
| | I have been pondering this more over lunch. | 13:51.45 |
| tor7 | Robin_Watts: how much is done in C vs Java with the JNI classes? | 13:52.03 |
| Robin_Watts | In java, objects tend to persist more than in C. | 13:52.12 |
| tor7 | one thought was to make the convert-to-array as a function in java that calls the first/next to populate it | 13:52.28 |
| Robin_Watts | With C, when you fz_annot_next it's natural to assume that the old pointer is no longer valid. | 13:52.29 |
| | with java objects are kept alive by you holding onto them. | 13:52.48 |
| tor7 | Robin_Watts: yeah, the lifetimes of the fz_annot pointers are a bit vague | 13:52.56 |
| | I wouldn't mind a revamp that added refcounting and a different way to access/enumerate them | 13:53.22 |
| Robin_Watts | But I worry that with an array, someone would do: blah = Page.getAnnotations(); and then what would happen to blah as the annotations are edited ? | 13:53.28 |
| tor7 | Robin_Watts: yeah. that's what worries me most about having an automatic in-between datastruct | 13:53.58 |
| Robin_Watts | The elements of blah would remain valid as they get moved around, but if the array changes size, then blah will be an 'orphaned' copy. | 13:54.24 |
| tor7 | want to add an fz_annot_list struct to hold the annots, rather than have the enumerator/accessors live directly on the fz_page? | 13:54.45 |
| | Robin_Watts: and a naive user might think that deleting an element from blah would delete the annot from the page | 13:55.07 |
| Robin_Watts | tor7: I have no fixed plan currently. I had been working to the array, but now I'm not so sure. | 13:55.24 |
| tor7 | we could add fz_xxx_list structs to all collections that need to be enumerated, if that would make writing native-feeling bindings easier | 13:56.17 |
| Robin_Watts | I think I like your countAnnotations/getAnnotation(idx) solution. | 13:56.17 |
| tor7 | then the fz_xxx_list could just implement the Enumerator interface (or however it's done these days) | 13:56.33 |
| Robin_Watts | That would mean we can easily do 'insertAnnotation' etc, later. | 13:57.00 |
| tor7 | Robin_Watts: we do linked lists mainly because of easy of implementation | 13:57.11 |
| | doubly linked lists would make insertions and deletions easier, but then you get into non-trivial code for it and may as well just use an array | 13:57.42 |
| Robin_Watts | tor7: right, but the choice of underlying data structure should not drive the interface, necessarily. Though I take your point about being consistent. | 13:57.49 |
| | I could implement exactly the 'getFirst' 'getNext' interface that the C has now. | 13:58.25 |
| | I think I may do that for now at least. We can revisit this at the end when we come to review what I come up with. | 13:59.06 |
| tor7 | Robin_Watts: fair enough. the lifetime issues of dependent objects (annot holding a ref to pages, pages holding a ref to documents) seems more important to solve promptly. | 14:00.21 |
| Robin_Watts | tor7: I believe I have that all sorted. | 14:00.36 |
| | oh, no, I have 1 problem in that regard. | 14:01.27 |
| | Actually, no, I've fixed that. | 14:01.40 |
| | so Java "Enumeration" is deprecated, and people should use "Iterator" instead... | 14:02.39 |
| Gigs- | adventures in dealing with users: Our web site would trigger gs automatically if there were not cached raster images, they'd have to wait for gs to finish then they'd get the image. Except some of our files are unnecessarily complex or have huge page sizes. | 14:19.16 |
| | So they'd start mashing reload and the server would try to run gs over and over rendering the same files. | 14:19.39 |
| Robin_Watts | Gigs-: You should put a marker down when you start processing a file so you don't start reprocessing it. | 14:20.19 |
| Gigs- | Then since other previews started getting unresponsive, those users would start compulsively mashing reload too | 14:20.20 |
| Robin_Watts | (have a queue of jobs, and the ability to check for what jobs have been queued etc) | 14:21.02 |
| Gigs- | Yeah I fixed it by running ps from one of the scripts to detect if a build was in process for the requested one, and a wait loop | 14:21.25 |
| | created a deadlock the first whack heh | 14:21.50 |
| | because it would see all the other build scripts waiting, and assume they were building too | 14:22.13 |
| | anyway I got it all resolved now, just relating dealing with emergent user behavior and GS :) | 14:22.42 |
| | speaking of asynchronous behavior... is gs supposed to build with make -j4? | 14:24.11 |
| Robin_Watts | Gigs-: It had problems at some point in the past, but I *think* those are resolved. | 14:24.39 |
| Gigs- | because it doesn't work, something must not be defined right in terms of make pre-reqs | 14:24.42 |
| chrisl | It works for me | 14:24.59 |
| Robin_Watts | I think our test system does: make -j 8 gs && make gs just to be sure. | 14:24.59 |
| kens | I believe chris uses -j8 | 14:25.00 |
| Gigs- | weird, I wonder if he just always winds up on the right side of a race condition | 14:25.14 |
| chrisl | Unless something's broken recently | 14:25.23 |
| Gigs- | I'll have to get details and put in a report | 14:25.26 |
| chrisl | Gigs-: as Robin_Watts the cluster does parallel builds, too, so..... | 14:25.47 |
| Gigs- | 64bit/ | 14:26.02 |
| | ? | 14:26.03 |
| kens | gicen the number of times we build gs on the cluster machines, and the variety of hardware, I'd be surprised if there were truly a race conditiona dn we always missed it | 14:26.04 |
| Gigs- | let me reproduce it again, one sec | 14:26.15 |
| chrisl | The word length can't affect the build | 14:26.30 |
| Gigs- | one wouldn't think | 14:26.36 |
| chrisl | What version are you using? | 14:26.49 |
| Gigs- | well, I use make so as well | 14:26.54 |
| | I don't think you all use the SO very much | 14:27.01 |
| | it's running... watch it not do it now | 14:27.47 |
| | that's a sure way to fix bugs, start talking to the developers and then try to reproduce again | 14:28.20 |
| Robin_Watts | tor7: To answer your earlier question; the veneers are as small as possible. | 14:28.41 |
| Gigs- | well, go figure, it didn't do it now | 14:29.05 |
| chrisl | I have a script somewhere that builds repeatedly with make -j12 until the build fails | 14:29.05 |
| Robin_Watts | the C tends to be just jni calls, and the java just tiny wrappers around calls to the native functions. | 14:29.21 |
| Gigs- | let me slow down a CPU with some spinning scripts and try again | 14:29.33 |
| Robin_Watts | JNI has the advantage that it can poke/prod at private members in other classes, so I do stuff in the C to avoid having to write new 'get/set' calls in some classes that I wouldn't want users calling. | 14:30.32 |
| Gigs- | hrm, no reproduction now :( | 14:31.53 |
| | I swear it did it heh | 14:32.00 |
| | I wonder if maybe it's something like make clean misses the thing so it only builds once ever | 14:32.21 |
| chrisl | Gigs-: what version? | 14:32.32 |
| Gigs- | git from like 2 days ago | 14:32.38 |
| chrisl | Well, I just built it six times with make -j12 and it didn't fail...... | 14:33.08 |
| Gigs- | yeah we may have to call that one cosmic rays | 14:33.25 |
| chrisl | I'll repeat the test on my own machine, it has more cores | 14:33.34 |
| Gigs- | I only tried at j4 | 14:33.42 |
| | let me see if I have the scrollback somewhere | 14:33.54 |
| | nah the new make scrolled it off | 14:34.56 |
| | what is the git command to tell me all the files in my tree that aren't in git? | 14:35.44 |
| chrisl | git status I think | 14:36.23 |
| | If you want to clean out non controlled files, then (use with care!) git clean -x -f -d | 14:36.48 |
| tor7 | they both ignore files listed in .gitignore though | 14:37.27 |
| chrisl | I didn't think git clean did? | 14:38.16 |
| Gigs- | oh man I shouldn't have checked out gs in / | 14:38.25 |
| | hehe just kidding | 14:38.35 |
| chrisl | tor7: the "-x" tells clean to ignore .gitignore | 14:39.02 |
| tor7 | chrisl: ah! | 14:39.20 |
| Gigs- | the burn it all with fire option | 14:39.34 |
| | starting a clean build | 14:39.48 |
| chrisl | For status you can use --ignored - so the manpage tells me...... | 14:40.16 |
| tor7 | Gigs-: burn it all with fire is: rm -rf * && git reset --hard | 14:40.21 |
| Gigs- | oh well it built. I guess the stars had to align a certain way to make it fail | 14:40.45 |
| | don't worry about it | 14:40.49 |
| | I'm glad you all went to git though, I really do like it. It's too bad corporate here still uses CVS | 14:41.50 |
| | thankfully I don't develop on their code most of the time | 14:42.03 |
| tor7 | I used git on ghostscript long before we made the global switch, via git-svn | 14:42.41 |
| Gigs- | for a while there was that big debate over source code control and everyone had a favorite, it's good that git got where it is, because dealing with 4 different systems sucked too | 14:43.41 |
| chrisl | There's a git/cvs bridge, too, but I'd not vouch for how well (or otherwise) it works | 14:43.42 |
| Gigs- | that has to be kind of ugly chrisl | 14:44.01 |
| | since there's no concept of half the stuff git can do in cvs | 14:44.31 |
| chrisl | Well, the important thing is, you have a local git repo, so you can everything git-ish in there. Presumably, it "flattens" things down to CVS when you "push" | 14:49.51 |
| Robin_Watts | tor7: Gah. I can't see how the Iterator interface avoids these same problems. | 15:02.36 |
| | http://docs.oracle.com/javase/6/docs/api/java/util/Iterator.html | 15:02.41 |
| | You call y = x.next(); to get the next one in the sequence. This doesn't say that x is not valid any more. | 15:03.22 |
| | hence someone could pull out all the values and stick 'em in an array and we'd have to honour them. | 15:04.04 |
| | I'd hoped that it might be more like you'd call x.next() to move x onto the next one. | 15:04.35 |
| | So I guess I'm rolling my own iterator like interface then :( | 15:08.58 |
| mpictor | I'm using ghostscript 9.05. Trying to convert a ps file with ps2pdf, and I get "Error: /undefined in .". | 15:38.20 |
| kens2 | mpictor : firstly try current code, the current version is 9.10, if that continues to fail then please open a bug report at bugs.ghostscript.com where you'll be able to attach a file for us to look at | 15:39.30 |
| mpictor | hopes that 9.10 is available in gentoo :) | 15:40.06 |
| Robin_Watts | tor7, paulgardiner: Should we be looking to cope with the case where we can have multiple enumerations on the same page at the same time? | 16:00.28 |
| paulgardiner | I would hope not. | 16:01.15 |
| Robin_Watts | Imagine if you wanted to look through all the annotations on a page and compare them to one another in some way? | 16:02.01 |
| paulgardiner | I'd place a *small* bet on our never needing to do so. | 16:03.05 |
| Robin_Watts | ok, I will leave it the way I have coded here then. | 16:04.09 |
| | tor7: Any objections to us making the password passed into fz_authenticate_password a const char * ? | 16:11.11 |
| sebras | Robin_Watts: looks like the functions actuallyt using that utf8-string already take const char* | 16:13.54 |
| Robin_Watts | sebras: Indeed, I think the pdf_ versions are already const char *. | 16:14.13 |
| | The fz_ versions aren't. I suspect it's just an oversight. | 16:14.24 |
| sebras | isn't the only problematic consts returned types? | 16:14.32 |
| Robin_Watts | possibly mine :) | 16:14.35 |
| sebras | :) | 16:14.42 |
| Robin_Watts | sebras: const is only a problem when you want to pass it onwards to somewhere else that isn't marked as const. | 16:14.54 |
| sebras | exactyly. and password is converted by the utf8-parsing code which already does this. | 16:15.21 |
| | quite unusually I think const makes sense at this occasion. | 16:16.00 |
| | is the jni-stuff complainig | 16:16.10 |
| Robin_Watts | yeah. | 16:17.43 |
| | The jni stuff so far is online at robin/jni. Any comments etc appreciated. | 16:22.18 |
| | The jni stuff so far is online at robin/jni. Any comments etc appreciated. (Repeating for tor7) | 16:23.17 |
| sebras | has a look. | 16:29.19 |
| | Robin_Watts: TryLaterException is just a placeholder at the moment, right? | 16:30.27 |
| | at least I can't find it in your latest patch. | 16:30.46 |
| Robin_Watts | sebras: Urm... | 16:32.07 |
| | yes. I wonder why the java build isn't telling me that I'm missing that ? | 16:32.49 |
| | oh, because it's only in the JNI currently. | 16:51.26 |
| | sebras: Updated version there that fixes that. | 16:56.38 |
| mvrhel_laptop | bbiaw | 17:12.08 |
| mpictor | I still get "Error: /undefined in ." | 17:52.40 |
| | with gs 9.10 - should I attache the file to the bug report, or provide a link? | 17:52.59 |
| Robin_Watts | attach the file to the bug report, please. | 17:53.12 |
| mpictor | file the bug on the PS Interpreter? | 17:55.02 |
| | (I'm using ps2pdf) | 17:55.27 |
| ray_laptop | mpictor: Is this a PS file ?, then PS interpreter is fine | 17:55.45 |
| | mpictor: but it's probably a broken file. | 17:56.06 |
| mpictor | I ran "psrepair" on it, and it didn't complain. No clue how good that utility is, though. File is from '95 | 17:56.49 |
| ray_laptop | usually some embedded data (often image) is damaged so we end up trying to interpret data as PS operators | 17:57.04 |
| | mpictor: never heard of psrepair | 17:57.20 |
| | mpictor: you should probably attach the file BEFORE it went through psrepair | 17:57.54 |
| mpictor | http://www.cs.columbia.edu/irt/software/psrepair/ | 17:57.59 |
| | yes | 17:58.00 |
| | the download link is broken, append the tarball name to that url and it works | 17:58.22 |
| ray_laptop | mpictor: DON"T use this utility. Translating CR and CR-LF is REALLY risky, particularly if the file has binary data. | 18:00.12 |
| | This *might* work on Level 1 files without binary data | 18:00.38 |
| | mpictor: what bug number are you updating ? | 18:01.07 |
| mpictor | ok. I get the same result either way. | 18:02.44 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=694607 | 18:02.45 |
| | crap, I should have checked if something like that already existed. | 18:03.07 |
| ray_laptop | mpictor: if the file has been cr-lf damaged by transmission being "smart" about text files, you are probably stuck if the file has binary data | 18:03.25 |
| mpictor | downloaded from an ftp site with chrome. guess I could ftp in and try again... | 18:04.23 |
| | is it possible to programmatically detect such corruption and warn? | 18:04.56 |
| | actually, it shouldn't be corrupted. it was in a .gz | 18:05.24 |
| Robin_Watts | mpictor: We *were* reporting such corruption :) | 18:05.43 |
| mpictor | the parser stack looks more like a bug than a corruption report to me :P | 18:06.43 |
| | waitaminute... "Last OS error: No such file or directory" | 18:07.22 |
| ray_laptop | mpictor: It has a bogus last line. I just closed the bug with the analysis | 18:08.13 |
| mpictor | yea, I just refreshed and saw that. Thanks! | 18:08.33 |
| ray_laptop | mpictor: you probably forgot to force binary mode in FTP | 18:08.44 |
| mpictor | well, it was in a gzip file... seems to me that would have been corrupted | 18:09.07 |
| ray_laptop | mpictor: no, the original before gzip must have been corrupted | 18:09.29 |
| | mpictor: anyway, it's easy enough to fix with an editor | 18:09.52 |
| mpictor | been corrupted since Apr 3 1995 then :o | 18:10.12 |
| | I'll fix it. Appreciate the help! | 18:10.19 |
| ray_laptop | probably so | 18:10.23 |
| | mpictor: the file was probably corrupted before being gzipped, since it has <cr><cr><lf> line endings. At least there's no binary data in the PS, so the extra white-space doesn't hurt. | 18:12.34 |
| | Forward 1 day (to 2013/09/21)>>> | |
IRC Logs