| | <<<Back 1 day (to 2012/09/12) | 2012/09/13 |
| kens | Robin_Watts (for the logs) I've fixed those 2 warnngs, but they are only in debug prints, so I'm not much worried by them. | 07:14.40 |
| | chrisl ping | 09:34.40 |
| Robin_Watts | gp_unix_cache is using malloc/free etc rather than gs equivalents. | 09:44.51 |
| chrisl | kens: pong | 09:48.03 |
| kens | chrisl: Having trouble building gs on Linux. I used Git to rebase to master, then from ghostpdl ran ./configure (it was a very old checkout). Now from ghostpdl/gs, when I try to run 'make clean' I get errors. 'Makefile:599 base/jasper.mak: No such file or directory' and 'Makefile:603: base/icclib.mak: No such file or directory'. Which step did I forget ? | 09:48.15 |
| Robin_Watts | kens: ./autogen.sh not ./configure | 09:48.42 |
| kens | Robin_Watts : tried that too, same result | 09:48.53 |
| chrisl | Also, for gs you need to run everything in the gs directory, | 09:49.04 |
| kens | OK that's the bit I missed. | 09:49.14 |
| | Is there a reason why we don't do this from the tope level as well ? | 09:49.48 |
| chrisl | The toplevel configures the PCL/PXL and XPS builds | 09:50.43 |
| kens | Yes, I know, bu twhy not gs as well ? | 09:50.57 |
| chrisl | Because you don't build gs from the toplevel, you build it from the gs directory | 09:52.13 |
| kens | OK I can see we need to be ablle to do GS separately, but given the top level already builds PCL and XPS why not do GS too while we are tehre ? | 09:52.50 |
| chrisl | I don't know, I didn't write this stuff...... | 09:53.36 |
| kens | Oh, OK I thought maybe there was a reason. It just seemed to me to make sense to build all of tehm. | 09:54.01 |
| chrisl | Possibly because most people building in the toplevel directory are only interested in the PCL executable so configuring and building gs would just take extra time | 09:54.56 |
| kens | Seems like the obvious answer would be individual make/configure for each product, and the top level makes them all. | 09:55.34 |
| chrisl | If you want to stick something in bugzilla, I can look at it at some point | 09:56.46 |
| kens | Its not desperate, it just keeps tripping me up. | 09:56.59 |
| chrisl | Well, the only way I'll remember to look into it is if someone opens a bug about it....... | 09:57.44 |
| kens | Well, my code which seg faults on the cluster doesn't go wrong on my Linux debug build :-( | 09:57.53 |
| chrisl | Using the entire cluster command line? | 09:58.11 |
| kens | No, that's my next trial | 09:58.24 |
| | After that it would be debug/release or 64-bit related | 09:58.40 |
| | Oh, actually its a differetn file :-( | 09:59.41 |
| | I see Raed's bug reports have reached a new high in cryptic | 10:39.32 |
| tor8 | kens: chrisl: probably because originally you checked out 'gs' as a separate svn checkout | 10:39.53 |
| | so the people who worked on gs never bothered with compiling pcl/xps/etc | 10:40.13 |
| | it has bothered me that I have to go into 'gs' and do autogen and make there separately from the other languages | 10:40.47 |
| kens | tor8 yes that was what I was implying above. I can see that its useful to have a separate build for each product, to avoid building all of them when you only want one, but it would be nice if the top level one did them all. | 10:41.59 |
| | I may even get round to an enhancement request for it if I get this stupid bug resolved. | 10:42.16 |
| chrisl | tor8: there are problems with the jbig2dec git rejig, I'm afraid..... | 10:43.13 |
| | For example, take a look at: http://git.ghostscript.com/?p=ghostpdl.git;a=tree;h=e37802e4 | 10:44.01 |
| tor8 | chrisl; that's expected | 10:49.42 |
| | the git-subtree "merge" puts that in the right directory | 10:50.00 |
| | but that's the original jbig2dec commit, with the same sha1 | 10:50.13 |
| chrisl | Oh, so we just bisect skip those commits? | 10:50.26 |
| tor8 | shouldn't bisect down that side of the merge | 10:50.45 |
| chrisl | It does, that commit is on master | 10:50.57 |
| tor8 | odd, it's a commit that comes into master from the side | 10:51.32 |
| chrisl | Yeh, that's how I thought it should work..... | 10:51.50 |
| tor8 | so if your bisect range is on the other 'thread' I don't understand how it goes down to that commit | 10:52.16 |
| chrisl | I did a bisect between 23d410c021a2b038ac5535e9eb028d6a808801ea and 523697346bbc88bf309cb44b47f53516c33917f7 | 10:53.56 |
| tor8 | chrisl: what are the good and bad commits for the bisect command that ended... ah you beat me to it | 10:54.03 |
| chrisl | so 23d410c0 is the "bad" commit | 10:54.33 |
| tor8 | that is odd indeed | 10:57.04 |
| | git bisect calls git rev-list to get the list of commits to test, but I guess it's non-trivial to add --first-parent to that subcommand :/ | 10:58.50 |
| chrisl | Well, skipping should work okay | 11:00.05 |
| tor8 | chrisl: yeah, annoying though. but we could create a tag for making it easier. | 11:06.31 |
| | or bisect twice, once from good .. merge-point and once from merge-point~1 .. bad | 11:07.30 |
| chrisl | I'm not sure that's easier/nicer that bisect skip! | 11:08.26 |
| tor8 | probably worse! | 11:08.35 |
| | oh well, tags for quickly skipping it sound okay to you? | 11:08.57 |
| chrisl | Sure - I wonder if there's a way to permanently mark commits to exclude from bisects | 11:09.39 |
| tor8 | chrisl: git bisect start -- gs | 11:28.42 |
| chrisl | tor8: okay, what does that get me? | 11:29.45 |
| tor8 | chrisl: it'll only look at commits that change 'gs' path | 11:29.59 |
| chrisl | OKay, what about ghostpdl changes? | 11:30.54 |
| tor8 | you can give multiple paths | 11:32.07 |
| | just a thought, but it did skip the jbig2dec commits | 11:32.34 |
| chrisl | Okay, that'll work. Maybe you could send a mail to tech about it? | 11:32.50 |
| tor8 | chrisl: will do | 11:39.05 |
| chrisl | thanks | 11:39.31 |
| tor8 | chrisl: the other option is to rewrite history and have the jbig2dec branch as a 'squashed' commit. fewer commits to skip then. | 11:49.46 |
| | but I doubt we can automatically split out the jbig2dec history to jbig2dec.git anymore if we do that | 11:50.38 |
| chrisl | tor8: it's up to you, I'm not that bothered about skipping the affected commits - it shouldn't generally affect the affectiveness of bisect | 11:51.21 |
| tor8 | it'll only be a problem if you bisect across that particular merge, and it's easy enough to recover from, I'd hope | 11:53.39 |
| | took my computer a good 10-15 seconds to build the full skip list though | 11:53.59 |
| Bleu|taF | hi all | 11:58.57 |
| sebras | Bleu|taF: hi, feel free to ask questions. :) | 12:01.12 |
| Robin_Watts | VS2012 for the desktop express is out. | 12:07.28 |
| kens | I know | 12:07.49 |
| | May have to go download it | 12:07.57 |
| Robin_Watts | I've just grabbed the ISO. | 12:11.05 |
| chrisl | Robin_Watts: does it actually let you build desktop apps, now? | 12:21.34 |
| Robin_Watts | "for desktop" does, yes. | 12:21.46 |
| | for desktop express has all the languages (VB, C#, and C++ etc) in it, rather than just 1. | 12:22.30 |
| chrisl | It being Microsoft, I thought it worth asking ;-) | 12:22.31 |
| Robin_Watts | xiki.org looks like a whole bag full of awesomeness that I'd never use. | 12:23.19 |
| Bleu|taF | Anyone knows what printer i must define with openoffice xps writer ? | 12:50.47 |
| Robin_Watts | chrisl: ping. | 13:27.02 |
| | Am I right in thinking that the fapi code that talks to UFST doesn't cope with reentrance? | 13:27.37 |
| | Looks like it uses a static for gs_mem_ctx to me. | 13:27.52 |
| chrisl_ | Robin_Watts: yes, the UFST code isn't reentrant - I'm not convinced the reentrant option in the UFST actually works..... | 13:40.54 |
| | Robin_Watts: if it ever becomes a problem I can revisit it and/or put locks around the UFST calls | 13:41.52 |
| Robin_Watts | chrisl: Well, I'm seeking to make gsapi usable with multiple instances. | 13:45.00 |
| | and currently it won't be if ufst is in play. | 13:45.20 |
| chrisl | Robin_Watts: yep, that's the way it is | 13:45.35 |
| Robin_Watts | ok. | 13:45.43 |
| kens | documentation :-) | 13:46.22 |
| Robin_Watts | documentation? | 13:47.24 |
| chrisl | It will have to be documented as a restriction, at least until I can sped some time on it | 13:51.50 |
| Robin_Watts | chrisl: My cunning plan is to have a new build symbol: GS_THREADSAFE (unless anyone can give me a better name). | 13:54.11 |
| chrisl | And what will that change? | 13:54.41 |
| Robin_Watts | If that is enabled, then all the print functions/macros that use a static memory pointer will not be defined. | 13:54.57 |
| chrisl | Can't we just remove the static memory pointer altogether? | 13:55.36 |
| Robin_Watts | I'm hoping that I can get the core of gs building with that defined. | 13:55.42 |
| | chrisl: How? | 13:55.49 |
| | If I remove the static memory pointer, then it's impossible to implement lots of the print functions. | 13:56.23 |
| | and lots of devices (and the fapi ufst code) won't build. | 13:56.40 |
| chrisl | How often do we actually call print functions where no memory pointer is available? | 13:57.03 |
| Robin_Watts | More often than we'd like. | 13:58.08 |
| | Most of the time I can work around it. | 13:58.25 |
| | but if I just remove the functions, loads of devices won't build (all the contrib ones for a start). | 13:58.47 |
| | Hence having a switch you can enable. | 13:59.21 |
| chrisl | The problem I see is that we'll get people trying to use the Windows DLL or the Unix so in a multithreaded app, and b*tching when it doesn't work | 13:59.26 |
| | Why can't we fix the devices? | 13:59.45 |
| Robin_Watts | Given time, we can. | 13:59.55 |
| | but it's a lot of time, and I can't easily test 'em all. | 14:00.04 |
| | For now, we tell people to rebuild with GS_THREADSAFE, and if it builds then they have a good chance that it'll work. | 14:00.27 |
| | If it fails, then they can at least see why. | 14:00.37 |
| chrisl | Well, we're either thread safe or we're not, IMHO..... | 14:02.59 |
| Robin_Watts | The core can be made thread safe. But if I remove the non thread safe printing functions, suddenly everyones device stops working. | 14:03.39 |
| | hence we have a flag to say "build thread safely". And if people enable that flag and try to build a non thread safe device, it falls over at compile time. | 14:04.26 |
| | That seems like a pretty good solution to me. | 14:04.37 |
| chrisl | Robin_Watts: could we throw a bounty Shelly's way to revise the devices with appropriate print calls? | 14:18.22 |
| Robin_Watts | chrisl: Probably. | 14:18.38 |
| | But I've got a long way to get to the stage of it just being the devices that are problems. | 14:18.56 |
| | Not only do I have all the dprintf, eprintf, lprintf, dlprintf things to fix... | 14:19.19 |
| | I have the if_debug stuff too. | 14:19.28 |
| | And the reference counting stuff. | 14:19.38 |
| chrisl | Do they use globals? | 14:20.05 |
| Robin_Watts | They all boil down to using a global gs_memory_t, yes. | 14:20.30 |
| | Essentially I am going to be changing every bloody file in gs :( | 14:20.50 |
| aq | Hi, I have a query related to Mupdf's android app. In com.artifex.mupdf.PageView there is a class called PatchInfo and its values are passed to the drawPage function. I want to know what patchInfo is | 14:28.31 |
| Robin_Watts | Sounds like it's the details of the patch of screen that needs redrawing. | 14:28.59 |
| | PatchInfo is defined at the top of PageView | 14:30.43 |
| aq | Yes, so patchViewSize refers to Screen size ? as in height and width? | 14:31.35 |
| Robin_Watts | Quite possibly. | 14:31.46 |
| | The guy who most recently touched this is paulgardiner, and he's on holiday this week. | 14:31.59 |
| | I think PatchInfo was introduced when he bundled some stuff up so it could happen asyncronously in the background. | 14:32.20 |
| aq | Ok. Can you tell me if the bitmap that we receive from the mupdf library to display in android, is the whole page or just the patch I want to display on screen ? | 14:34.39 |
| Robin_Watts | aq: offhand no. | 14:35.19 |
| | And that decision is made in the java anyway. | 14:35.31 |
| | The mupdf library will render a bitmap any size you like. | 14:35.46 |
| | It won't be the whole page (as if you're zoomed in the whole page can be HUGE). It may be the whole page intersected with the screen. | 14:36.41 |
| aq | Robin_Watts: Ok, Thanks | 14:38.07 |
| Robin_Watts | aq: Can I ask what you're doing with mupdf? (Idle curiosity, you don't have to answer) | 14:38.38 |
| aq | I am trying to add some custom annotations on it. | 14:39.13 |
| | Like highlight, underline. For this I need to track where user's touch on screen. | 14:40.24 |
| | So, my first task is mapping screen co-ordinates to pdf page co-ordinates. | 14:40.47 |
| Robin_Watts | So you're building it into your own android app? | 14:41.38 |
| aq | Yes. | 14:42.12 |
| | Can you tell me if patchArea in PatchInfo refers to an area in Pdf Page or the Screen ? | 14:42.34 |
| Robin_Watts | Not offhand. | 14:42.51 |
| aq | Ok thanks | 14:43.01 |
| Robin_Watts | Damn. Was typing a message about licensing. | 14:44.06 |
| henrys` | chrisl:there is a UFST_REENTRANT definition but not simply a matter of just turning it on, there are other changes we'd have to make but I think they're code would be alright. We'll wait for a customer request | 14:58.10 |
| chrisl | henrys: I went to try it a while back, and the UFST didn't actually build | 14:59.15 |
| henrys | well that would be a reportable bug, the docs say it works right? | 15:01.10 |
| | not worth fooling with now. | 15:01.39 |
| chrisl | Yeh, I need to look into it properly - it's possible I had incompatible options selected, but I had other things to worry about at the time | 15:02.03 |
| sebras | Robin_Watts: maybe we should start our with that question nowadays... | 15:03.41 |
| | at least if people are asking about android-stuff... | 15:04.16 |
| Robin_Watts | sebras: Well, I'm trying to avoid scaring people off. | 15:04.30 |
| chrisl | henrys: actually, there is an (relatively) insurmountable problem making the UFST code reentrant: we "hook" UFST's calls to fopen/fread etc, to go through the GS stream code. fopen and co don't have any scope for a "context" to be passed around. | 15:09.41 |
| Robin_Watts | So you change ufst internally to call fopen_with_context and pass a context, and have UFST default to casting that down to a normal fopen call. That way everyones existing code works, but you can undo the cast and just implement fopen_with_context. | 15:16.04 |
| | How amenable are they to taking patches? | 15:16.10 |
| kens | ROFL | 15:16.35 |
| chrisl | So far, I haven't had much luck - I'd have to check, it might mean a *lot* of changes | 15:16.47 |
| Robin_Watts | pulled a muscle behind my shoulder blade this morning whilst running. | 15:16.48 |
| | Either it's playing up again, or chrisl is stabbing his voodoo doll of me. | 15:17.07 |
| chrisl | Not me, no, I've lost the pin ;-) | 15:17.34 |
| henrys | it's really not worth fooling with the intersection of UFST and MT users is 0 | 15:17.35 |
| kens | henrys, regarding the 4Gb limit with pdfwrite. | 15:19.46 |
| | Got something of a problem. | 15:19.53 |
| | Ultimately the problem is the lack of a 64-bit data type | 15:20.18 |
| | Fundamentlly the problem boils down to the fact that the stream code (stell) returns a long, and in 32-bit systems a long is 32-bits. | 15:20.49 |
| chrisl | Most 64 bit systems have long as 32 bit, too | 15:21.32 |
| kens | Alex tells me this works on at least one Linux system where long is 64 bits | 15:21.57 |
| henrys | chrisl:not mac or linux, does windows? | 15:22.02 |
| Robin_Watts | windows has long == 32bits. *nix derived things tend to have long = 64bits. | 15:22.30 |
| kens | see comment #4 in bug 692290 | 15:22.34 |
| Robin_Watts | Windows has an __int64 type (or something like that). | 15:22.52 |
| henrys | I wonder if it is reasonably to make 64 bits prerequisite | 15:22.55 |
| Robin_Watts | and gs uses that for something already. | 15:23.02 |
| | gs already relies on a 64bit data type as a prerequesite for building, I believe. | 15:23.33 |
| chrisl | We use int64_t IIRC | 15:23.34 |
| henrys | but I'm sure the banding code works, I remember ray fixing it. | 15:23.34 |
| | and it uses the usual file operations | 15:23.54 |
| kens | Pass. | 15:24.07 |
| henrys | maybe it bypasses the stream stuff. | 15:24.08 |
| Robin_Watts | chrisl: We use __int64 too, I think. Possibly the genarch generated stuff. | 15:24.09 |
| kens | I do know that stell returns a long and on my 32-bit Windows build a long is 32-bits | 15:24.21 |
| Robin_Watts | kens: So either we need to change stell to return an int64 (of some description)... | 15:24.44 |
| | or we need to add an stell64 entry point that does. | 15:24.52 |
| chrisl | Robin_Watts: typedef __int64 int64_t; in stdint_.h | 15:25.03 |
| kens | Robin_Watts : yes, but the stream code is not my area.... | 15:25.06 |
| Robin_Watts | chrisl: right. | 15:25.12 |
| henrys | kens:let ray and alex weigh in on it are they cc'd on the bug? I know both of them have worked on similar stuff in the code. | 15:26.11 |
| kens | As far as I can tell, the only thing wrong here is that the xref code maintains a list of offsets, which are longs. I can easily change that to an in64_t, but that won;t help if stell is returning a long. | 15:26.26 |
| Robin_Watts | kens: or we need to have some cunning way of getting a 64bit number through a 32bit hole... | 15:26.26 |
| kens | henrys alex has commented on the bug. | 15:26.43 |
| | Neither is CC'ed though | 15:26.55 |
| | I wanted to run it past Ray but he's not here yet | 15:27.16 |
| henrys | the stream code does need to be fixed in some way, ray or alex are likely victims. | 15:30.52 |
| chrisl | kens: do the other stream functions handle 64 bit values? | 15:31.21 |
| kens | chrisl don't know | 15:31.58 |
| | THe underlyign file code does. | 15:32.05 |
| henrys | although it could be considered a system oriented thing for chrisl ;-) | 15:32.06 |
| chrisl | I'm just wondering if the stell() thing is an oversight..... | 15:32.28 |
| kens | chrisl I have no idea | 15:32.40 |
| | Like I said, the stream code is a bit of a black box for me | 15:32.52 |
| | For the linearisation code I'm using the file calls and an int64_t dtaa type for the offsets | 15:33.13 |
| | I *could* rewrite all the pdfwrite code to do the same instead of using the stream code, but I hitnk that would probably have a big bug tail | 15:33.51 |
| chrisl | If you were going to that effort, I'd rather pdfwrite use the stream code everywhere, and we fix that | 15:34.36 |
| henrys | kens:but what a step forward for humanity | 15:34.47 |
| kens | chrisl it does mostly use the stream code throughout. The linearisation code is quite self-contained. | 15:35.09 |
| | And has no use for the sophistication of the stream interface | 15:35.28 |
| Robin_Watts | sophistication. Yes. That's the word I'd have picked. honest. | 15:36.19 |
| kens | was being polite | 15:36.29 |
| chrisl | It doesn't look like the stream code is 64 bit capable at all | 15:36.29 |
| kens | Moving away from teh stream interface worries me, we use it a lot for applying filters to the data. | 15:37.10 |
| | But if the stream code is not 64-bit capable, that may be something I just have to do | 15:37.59 |
| henrys | yes I do think the direction should be to fix the stream code, kidding aside. | 15:38.14 |
| Robin_Watts | kens: I'm sure that making streams 64bit capable isn't that big a deal. | 15:38.20 |
| kens | is less sanguine ;-) | 15:38.28 |
| Robin_Watts | If I didn't have gs in bits on the floor already, I'd volunteer. | 15:38.36 |
| kens | OTOH it probably isn't my problem :-) | 15:38.41 |
| Robin_Watts | (and if people are prepared to wait, I'll still volunteer) | 15:38.50 |
| kens | I'm in no hurry | 15:38.58 |
| henrys | we don't have a waiting customer? | 15:39.09 |
| kens | I know what I meed to do to add this to pdfwrite. henrys, there is no customer demand as far as I know, its a free user, I could be wrong | 15:39.33 |
| | Hmm, acyually one of the reports has #661 on it. | 15:39.53 |
| | I guess that's an important customer, I didn't know they were using pdfwrite | 15:40.46 |
| henrys | kens:well I don't know that division of the company is particular active. | 15:41.57 |
| | so we put it off, seems like chrisl or robin_watts (as he volunteered) are reasonable to work on the stream stuff when one of them has a chance ... | 15:42.35 |
| kens | Fine, I can wait no problem | 15:42.52 |
| | Since I have been deluged with reports today | 15:43.01 |
| chrisl | henrys: I can look at it next week | 15:43.09 |
| henrys | chrisl:okay | 15:43.22 |
| chrisl | I haven't broken Ghostscript for a while - seems like my turn ;-) | 15:45.22 |
| henrys | kens:let me know if you need another test file for the new font type, it occurred to me there are 2 font types in that tests | 15:47.39 |
| kens | henrys I haven't got anywhere with that yet, been chasing font prefixes all day | 15:48.00 |
| | and other customer bugs | 15:48.05 |
| nortti | /g 38 | 15:48.19 |
| kens | The file works OK now that I fixed my linearisation problem, but the text is not in a font, its just linework | 15:48.26 |
| henrys | kens:right certainly not high priority | 15:50.12 |
| kens | Since it basically works, that's what I figured | 15:50.34 |
| henrys | marcosw:ping | 15:51.32 |
| marcosw | henrys: morning | 15:51.41 |
| henrys | marcosw:what do you think about making a gs_bisect script that incorporates tor8's skipping jbig2 and takes a parameter like "fix" to indicate the keywords good and bad should be reversed. | 15:53.04 |
| | we need some sort of sane bisect | 15:54.28 |
| marcosw | I don't know what the skipping jbig2 reference means. Is this something discussed at the meeting or did I miss an email thread? | 15:57.09 |
| Robin_Watts | http://git.661346.n2.nabble.com/RFC-reverse-bisect-td6844052.html | 15:58.05 |
| | marcosw: tor8 sent a mail yesterday. | 15:58.16 |
| | (or this morning) | 15:58.21 |
| henrys | marcosw:tor8 -> tech mail git bisecting with jbig2dec | 15:58.29 |
| marcosw | Robin_Watts: found it, hadn't gotten around to reading the non-customer emails. | 15:59.40 |
| | Robin_Watts: couldn't we just have you or tor8 do some git black magic and fix the issue in the repository, seems silly to have to manually skip commits when running bisect. | 16:00.42 |
| chrisl | marcosw: the problem is, if we do that we'll lose the ability to keep the jbig2dec history | 16:01.32 |
| marcosw | have to run to uni will be back in an hour | 16:03.40 |
| kens | OK I'm off, night all | 16:07.46 |
| Gigs- | does anyone have an ascii list of all pantone colors? | 18:54.34 |
| | I don't need values or anything just the names | 18:54.54 |
| Robin_Watts | Gigs: You can do lookups on the pantone.com website. | 19:01.27 |
| | Maybe you can screenscrape what you need from that. | 19:01.38 |
| Gigs- | Robin_Watts: there's a color selector popup window I think I can scrape | 19:04.59 |
| | thanks | 19:05.01 |
| Robin_Watts | cool. | 19:09.12 |
| Gigs- | Robin_Watts: it's kind of funny, the color selector html scrape has rgb values too | 21:11.09 |
| | pantone is basically publishing their RGB book online with just a little javascript obfuscation | 21:11.25 |
| | well all their books, with rgb | 21:11.44 |
| | chrome is great for scraping dynamic html btw :P | 21:12.15 |
| | in the developer pane it shows you the html that is generating the current dom, not what was downloaded | 21:12.46 |
| henrys | alexcher:don't fix this problem - we are waiting to see if there is a support contract in the works but why is 692757 failing are we aware of an input size limitation other than the 10 digits for offsets? | 21:18.00 |
| | note it is a mupdf bug but the customer says the same thing happens in gs. | 21:18.23 |
| | maybe 32 bit machine is the problem. | 21:21.54 |
| | well anyway the claim in comment #5 is it should work. | 21:23.38 |
| Gigs- | ray's comment seems to be only in regard to file I/O functions | 21:25.44 |
| | you may still be internally using a 32 bit value somewhere that is getting you | 21:25.59 |
| | post_eof_count seems to be overflowing for example | 21:26.33 |
| henrys | right, I did think we could support "large" pdf's though and I think ray was implying that as well although he didn't specifically address how gs would handle the data once read. | 21:39.07 |
| | unless he wanted to say gs will run longer than mupdf before it fails ;-) | 21:40.15 |
| Gigs- | does the PS engine implement > 32 bit ints? | 21:41.43 |
| | PLRM doesn't say how big an integer should be in PS, only that it's "typically" 32 bits | 21:42.01 |
| chrisl_away | GS Postscript integer objects are only ints, so only 32 bit - PDF file i/o is done via Postscript, so....... | 21:50.13 |
| henrys | well there's another project | 21:52.39 |
| | presumably this can be fixed like we allow for large references. | 21:53.23 |
| chrisl_away | Yes, the "object" is already 64 bit, so we can change it to a int64_t - it *might* cause problems with some QL tests, but then those tests are invalid | 21:54.20 |
| | henrys: the point is, I was aware of the PS related problem - I assumed it was included in the 64 bit capable stream code work. I was going to raise the question of how we handle the possible QL test problem in the Tuesday IRC meeting. | 21:59.56 |
| henrys | well at least the stream code would work on a 64 bit machine... it looks to me like this won't even do that, I am betting that overflow would still happen on 64 bit, the ps type is overflowing when we are doing something in the pdf interpreter infamously scribed in PostScript | 22:08.29 |
| chrisl_away | henrys: as I say, I was aware of the PS integer situation, and the PS filter objects will need attention - I'll have a better picture after I spend some time on it. | 22:13.29 |
| henrys | I'm sorry I misunderstood you I thought you were saying by fixing ftell and friends to use 64 bits it would fix the bug. | 22:14.28 |
| chrisl_away | No, 'fraid there's going to be more to it than that :-( | 22:15.23 |
| henrys | I was talking to someone and told him I worked for a company that did PDL's and he said well all that code was written years ago right? What do you do now? Hardware guys don't understand how to stay employed. | 22:19.59 |
| | chrisl_away:workin' late? | 22:24.17 |
| | bbiaw | 22:29.11 |
| Robin_Watts | Hi mvrhel | 23:30.30 |
| | Was the tea right? | 23:30.34 |
| mvrhel | Hi Robin_Watts . The tea is great. She is drinking the Twinings | 23:34.08 |
| Robin_Watts | So it's different to the stuff you get in the US? | 23:34.25 |
| mvrhel | yes it is | 23:34.57 |
| Robin_Watts | Cool. Remind me nearer the time and I'll bring some at each meeting. | 23:35.15 |
| mvrhel | awesome. thank you | 23:35.24 |
| Robin_Watts | no worries. | 23:35.29 |
| mvrhel_laptop | ray_work : you there? | 23:55.29 |
| | found my issue | 23:55.35 |
| | there was one magic offset floating around for the number of pointers in the graphic state that I had to decrement. | 23:56.09 |
| | the magic number occurs in multiple spots. Maybe I should fix that while I am poking around in here | 23:56.38 |
| | off to kids curriculum night now. bbiaw | 23:57.00 |
| | Forward 1 day (to 2012/09/14)>>> | |
IRC Logs