| | <<<Back 1 day (to 2013/03/21) | 2013/03/22 |
| ray_laptop | marcosw: sorry. Yes, this was a bmpcmp run and subsequent localcluster runs (user runs) were fine. | 00:11.40 |
| | open house at the middle school tonight. I might be back on later... | 00:12.16 |
| marcosw | ray_laptop: that's what it looked like. a bmpcmp run didn't initialize some memory values. | 00:12.24 |
| Robin_Watts | ray_work: I strongly suspect that the bitmap only gets displayed at the end of rendering. | 00:46.11 |
| | TTOTD: When outputting debugging to file, it helps if it all goes to the same file. | 00:59.44 |
| | tor8 or paulgardiner: (For the logs) http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bf08301ded2f44e33bebf5572587a9c7102dcc98 | 01:03.03 |
| mvrhel_laptop | whew. finally getting somewhere with the async calls in the windows app and keeping all the rendering thread safe. no mutex locks etc and I wanted to be able to render the document thumbnails but not block any full res resolution renderings while that is going on and of course no blocking of the UI | 04:23.25 |
| ray_work | closed 3 bugs that I think I have fixed recently (made a lot of changes that are in similar areas) and they no longer fail. (plus the original 3 bugs and 3 I found along the way, of course) | 04:45.57 |
| | bug scrub can be rewarding sometimes, but I hate when none of the bugs I think might be fixed are not | 04:47.01 |
| | mvrhel_laptop: great! I look forward to seeing the windows viewer in all of its glory :-) | 04:48.50 |
| | enough work for today. Tomorrow going to play with digital signing for Windows drivers :-( | 04:51.01 |
| | doesn't look to hard -- just a lot of hoops to jump through. | 04:51.21 |
| | mvrhel_laptop: do you have to deal with digital signing your viewer in order to get it to install nicely on Win8 (or is only drivers that they pick on) ? | 04:52.02 |
| vtorri | ray_work, i'm writing a multi doc rendering lib, cross platform, and i plan to make it fully async too | 04:58.39 |
| ray_work | vtorri: yes, I've seen you chatting w/ Robin_Watts and sometimes tor | 05:08.56 |
| | vtorri: is your implementation on Windoze or what ? | 05:09.21 |
| vtorri | cross platform | 05:09.32 |
| | at least it will work for linux, widows and mac os x | 05:09.51 |
| ray_work | vtorri: I know you said "cross platform", but which platforms | 05:09.53 |
| | vtorri: are you using Qt or some other cross platform tools ? | 05:10.16 |
| vtorri | other one | 05:10.24 |
| | EFL | 05:10.26 |
| | you konw them ? | 05:11.03 |
| ray_work | vtorri: thanks. I'll check that out (and probably run screaming). Cross platform tools are nice, but have a large learning curve | 05:11.06 |
| vtorri | indeed | 05:11.15 |
| ray_work | at least when dealing with UI issues | 05:11.20 |
| vtorri | check what can be done with the EFL: | 05:12.33 |
| | http://www.rasterman.com/files/wp2.avi | 05:12.35 |
| | this is the wallpaper selector of E17 | 05:15.39 |
| | i plan to do the same for an 'exposé' like effect | 05:16.03 |
| | for my app | 05:16.08 |
| ray_work | vtorri: reminiscent of an XPS viewer I saw Microsoft demoing about 3 years ago (before Win 7 was released) | 05:18.26 |
| | vtorri: so the 'expose' will go from a thumbnail of pages to the page at full size ? | 05:19.20 |
| vtorri | yes | 05:19.28 |
| ray_work | cute | 05:19.36 |
| | and if I want to then only see that page, I click on it or something ? And can return to the thumbnails somehow ? | 05:20.21 |
| vtorri | yes | 05:20.32 |
| | in the expose mode, you click on a thumbnail. The page is shown. | 05:21.38 |
| ray_work | vtorri: well, good luck ! | 05:21.41 |
| | time for bed... | 05:21.54 |
| vtorri | you click elsewhere than on an icon, you return in the expose mode | 05:22.05 |
| | click on the icon, and then, the page is really selected | 05:22.19 |
| | thanks and good night | 05:22.29 |
| ray_work | vtorri: can I see the pages without the icon tiles collected around the edge ? | 05:22.43 |
| vtorri | yes | 05:23.14 |
| | it will be different from that wallpaper selector | 05:23.33 |
| | you have to read a document | 05:23.42 |
| ray_work | OK. Thanks for the info. | 05:23.43 |
| vtorri | so that doc must not have hidden parts | 05:23.55 |
| mvrhel_laptop | ray_work: so yes, it has to be submitted and approved | 05:41.19 |
| | but it windows8 does "install" it as is on my local machine. not sure about how it is shared and installed on others | 05:42.17 |
| | I will have to look at that later. the way the async stuff works is taking me a little time to get used to . i would prefer if I had more control over threads in the standard way | 05:43.14 |
| | done for the night | 06:24.48 |
| | good night all | 06:24.50 |
| chrisl | kens: do we actually care about the pdfwrite/ps2write build "bug"?? | 07:58.14 |
| kens | chrisl, imo no. I will look at it, but I suspect it is 'unfixable'. My solution is to remove one of teh '.,ak' files | 07:58.42 |
| | .mak files* | 07:58.48 |
| | I think the problem is that *noth* devices are defined in the same C source file | 07:59.05 |
| | So you can't remove one of tehm just by removing C input files from the build | 07:59.26 |
| chrisl | I think I can fix it, we're using a sort of "short cut" to handle the dependency | 07:59.35 |
| | Although, I'm not totally sure....... | 08:00.06 |
| | But the current behaviour is intentional | 08:00.27 |
| kens | Hmm, why ? | 08:00.39 |
| chrisl | From devs.mak: "Since ps2write actually is a clone of pdfwrite, we just depend on it." | 08:01.08 |
| kens | Right, which is pretty much what I sadi in the bug report, these aren't so much devices in comman as the *same* device | 08:01.35 |
| | Since the 2 devices are both defined in gdevpdf.c, I'm not at all sure how you could remove one of them. | 08:02.12 |
| chrisl | Sure, as I say, it was clearly done this way on purpose - so it's not accidental | 08:02.33 |
| kens | Yes, I see. I'm not bothereed myself, I was goinjg to propose removing one of the .mak files as a solution (having both does seem odd), but its up to you | 08:03.13 |
| | The only alternative is to move the definition of ps2write into its own file and to be honest I can'tr see any point. | 08:03.41 |
| | Its not like it would actually save anything | 08:03.54 |
| chrisl | No, exactly - I'd close it "won't fix" | 08:04.19 |
| kens | OK in that case I'll do so, just looking at the other one Macros raised, which is at least a bug :-) | 08:04.42 |
| chrisl | Yeh, I'm looking at the tiff build one. | 08:05.29 |
| kens | I passed on that one. The one to support this morning looks like a nightmare | 08:05.59 |
| chrisl | I've never seen anything like that error message | 08:06.46 |
| kens | No me neither | 08:07.13 |
| | Oh, I wonder if they are somehow spawning GS as a thread of execution, in which case it could be their app causing the problem. | 08:07.54 |
| | Or the fact that GS doesn't clean up very well | 08:08.16 |
| chrisl | I think that is what they're doing - it could be that stack problem that Ray just fixed | 08:08.25 |
| kens | Of course their test app is written in something weird and M$ ish | 08:08.42 |
| chrisl | C#? | 08:10.14 |
| kens | It calls something that looks like it ought to start a 'process' but I wonder if it really spawns a thread. Not sure what langage this is, could well be C# yes | 08:10.23 |
| chrisl | Well, based on the .cs | 08:10.47 |
| kens | I'm looking at the code, which is 'sort of' like C++ | 08:11.04 |
| | Yes its C# | 08:12.02 |
| | Bit hard for us to help with that | 08:12.45 |
| | Despite hte use of teh word 'process' I would guess its spawning a thread | 08:13.12 |
| chrisl | That could explain the weird error message - it might be from the C# runtime | 08:13.19 |
| kens | I think it is basically yes | 08:13.29 |
| | I suspect that the GS executable is spawned as a thread and is therefore using the C# app address space. | 08:13.50 |
| | Presumably our porr cleanup leaves stuff lying around and eventually it can't spawn a new process because it hasn't got enough memory. Or something like that. | 08:14.24 |
| | I suppose using process explorer woudl show whether gswin32c is a prcoess or a thread | 08:15.01 |
| chrisl | I'm struggling to find reference for this stuff to find what "new Process..." actually does | 08:16.15 |
| kens | Fundamentally this is a pretty lousy way to run Ghostscript, or any other command line process, if teh above is true. It relies on the process cleaning up perfectly. Arguably the thread handler ought to clean up the memory used by the thread when it terminates of course, but this is Microsoft we're talking about | 08:16.37 |
| | chrisl new is a C++ operator | 08:16.47 |
| chrisl | Also C# | 08:16.59 |
| kens | if you have vs installed look for System.Diagnositics.Process | 08:17.11 |
| | In the 'SeaRCH' UNDER HELP | 08:17.22 |
| chrisl | kens: no, the thread handler doesn't clean up memory - it doesn't work like a process completing | 08:17.40 |
| kens | chrisl then if it is a thread, its not going to work well | 08:17.55 |
| | THis is suspicious: | 08:18.21 |
| | "A Process component provides access to a process that is running on a computer. A process, in the simplest terms, is a running application. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the code of the process, including parts currently being executed by another thread." | 08:18.21 |
| chrisl | But then, Ghostscript shouldn't leak any resources - we certainly don't leak memory on Unix-like systems | 08:18.49 |
| kens | Looks to me like it does run the process as a thread (nicely corrupted terminology MS) | 08:18.54 |
| | chrisl GS has memory allocated when the process | 08:19.11 |
| | exits | 08:19.16 |
| | It does not clean up 100% | 08:19.32 |
| chrisl | Hmm, well, it does on Unix..... | 08:19.45 |
| kens | It certainly does not on Windows, according to Memento | 08:19.59 |
| | And when I brought it up (pdfwrite memory cleanup) I was told that this was known and nobody cared because its all one-time allocations that get freed when the process exits | 08:20.30 |
| chrisl | One of the last things the code does is shut down the memory manager(s) and that releases all the memory - valgrind reports no leaked blocks on Linux | 08:21.13 |
| kens | Well I guess maybe Memento can't catch that | 08:21.38 |
| | If someone runs their application it should be easy enough to see if the memory usage is increasing. | 08:21.56 |
| chrisl | Do you know what the leaked memory is for? IIRC, the Jaws "GUI" app left memory allocated on exit for the Windows gui crap | 08:22.32 |
| kens | Its also possible that the memory simply becomes fragmented, and not enough contiguous memory is available to lauch the large) Ghostscript executable | 08:22.37 |
| | Not GUI stuff, this was stuff reported by Memento | 08:22.59 |
| chrisl | It still could be text buffers and stuff like that | 08:23.21 |
| kens | I don't know, it wasn't what I was cahsing so I ignored it. Made my life a bit harder because I had to sift my allocations out at the end | 08:23.58 |
| chrisl | Mind you, 576 dpi - add in a bit of transparency, and that could use a *lot* of memory....... | 08:25.41 |
| kens | Yeah its fairly high resolution, but the file appears to be text only (I didn't chec all 400 pages) | 08:26.12 |
| chrisl | Oh, well it shouldn't be a problem...... | 08:26.51 |
| | Hmm, well, if my cursory reading is right, that code should be creating a process, not a thread | 08:28.48 |
| kens | chrisl it says process, but the doc (see above) says 'a thread is the basic unit to which the operating system allocates processor time' | 08:29.40 |
| | I don't trust MS to make a proper ditinction between threads and processes. | 08:29.59 |
| chrisl | Yes, but there are specific c# calls to spawn a thread | 08:30.14 |
| kens | THe only way to tel is probably going to be to run their test app :-( | 08:30.15 |
| | Well if we aren't spawning a thread (I don't think their command line does that), its hard to see how we can be responsible for a thread error. | 08:30.50 |
| chrisl | Except that all processes are threads (but not all threads are processes) | 08:31.32 |
| kens | Well I'm going to get on with real work and leave it just now | 08:31.55 |
| chrisl | I wonder if they're exhausting resources before the c# garbage collector runs - I wonder if explicitly destroying the object would help...... | 08:32.50 |
| kens | I don't know, its worth trying | 08:33.03 |
| | If you can reproduce the problem... | 08:33.12 |
| | of course if it truly does generate a random set of pages, then its definitely going to be awkward to reproduce | 08:34.05 |
| | indeterminate test harnesses don't really help | 08:34.21 |
| chrisl | No, I'm not going to volunteer for this one..... | 08:36.49 |
| chrisl | (quoting Robin_Watts) touches nose! | 08:37.10 |
| kens | has finger on nose also | 08:37.26 |
| chrisl | Okay, back to makefile fun....... | 08:38.16 |
| kens | Not done my morning Stack Overflow review yet.... | 08:38.37 |
| Robin_Watts | Morning tor8. More reviews on robin/master for you. | 10:30.41 |
| tor8 | Robin_Watts: store debugging fns LGTM | 11:04.09 |
| Robin_Watts | tor8: D'oh. 2 more there now that I'd forgotten to push. | 11:06.17 |
| | For the reflow stuff, would it be easier if I made a branch with the commits all squashed? | 11:06.47 |
| tor8 | Robin_Watts: or a few squashed by category | 11:21.29 |
| Robin_Watts | tor8, paulgardiner: I'm going to spend a couple of hours trying to reduce the noise in the reflow branch to make it easier for you guys. | 11:31.31 |
| | so, unless you've started already, don't start looking! :) | 11:31.50 |
| paulgardiner | Ok. Let us know when it's ready | 11:32.23 |
| Robin_Watts | paulgardiner: There is a pdf_device commit waiting on robin/master that you might want to look at. | 12:14.21 |
| paulgardiner | Looking... and at the fixing of warnings | 12:22.16 |
| | Robin_Watts: Unlikely to matter I guess, but should diff be set to 1 also when the colorspace changes? | 12:38.54 |
| Robin_Watts | paulgardiner: It should. Do i not do that? | 12:39.06 |
| | Isn't that what the first hunk of the diff does? | 12:39.42 |
| paulgardiner | :-) Sorry, I'm looking I was looking at my local copy for the sake of checking the warning fixes, and I carried on looking at it | 12:39.44 |
| Robin_Watts | ah! :) | 12:39.54 |
| paulgardiner | Those two commits look fine. | 12:40.15 |
| Robin_Watts | I obviously only got 1/2 way through that code :) | 12:40.25 |
| paulgardiner | Yeah. That's partly what confused me: the old copy seemed to have the intention of handling the case | 12:41.16 |
| tor8 | Robin_Watts: warnings look fine | 12:42.24 |
| Robin_Watts | tor8, paulgardiner: Thanks. | 12:42.37 |
| henrys | wow adobe is doing really well revenues wise with the $50 a month creative cloud. I'm surprised these apps with very heavy UI's don't have latency problems over the web. I can't imagine something like freehand drawing with a stylus would keep up with an artist. | 14:23.47 |
| Robin_Watts | tor8, paulgardiner: OK. Reflow branch rejigged. | 14:30.10 |
| | I think that's better. I'm going diff blind though. | 14:30.23 |
| | There are some xps files that seem to show up as changed quite a lot in mupdf regresion runs. | 14:31.45 |
| | Seem to involve xeon and macpro a lot. | 14:32.10 |
| | 1 trivial fix on robin/master | 14:38.15 |
| | tor8, paulgardiner: ^ | 14:38.24 |
| paulgardiner | trivial fix fine | 14:42.02 |
| Robin_Watts | Thanks. | 14:42.17 |
| paulgardiner | I'm doing less well at checking the reflow stuff. There is a lot of it | 14:42.37 |
| | Android changes look fine | 14:42.56 |
| Robin_Watts | paulgardiner: Yeah, there is a fair amount of reflow stuff, and I'm prepared to believe that you/tor might see bits you want changed before we take it on. | 14:44.10 |
| | (although I hope we might be able to take it on and then refine it, but...) | 14:44.33 |
| paulgardiner | Any particular parts that you thought might be objectional? | 14:45.14 |
| Robin_Watts | Not really. | 14:45.27 |
| | There is a bubblesort hidden in there somewhere. | 14:45.51 |
| henrys | chrisl:was the problem to that all generated files should go to one directory fixed? Before we were seeing tiff stuff created in the tiff tree, I meant to put that on the agenda. | 14:49.53 |
| | marcosw:since the policy is customers only at support@artifex.com I don't think bugzilla should have any default assignments going to support, are you okay with that. I can fix it or you can, wanted to run it by you first at least. | 14:51.57 |
| Robin_Watts | So I can reproduce the macpro vs other xps diffs. | 14:53.35 |
| | I wonder if this is to do with atof or sscanf being different on the macpro ? | 14:53.56 |
| paulgardiner | Robin_Watts: I'm not seeing anything I don't like | 14:54.55 |
| Robin_Watts | paulgardiner: That's good to know. I spent so long staring at that code I think I've lost all perspective on it :) | 14:56.23 |
| chrisl_r61 | Hmm, the command lines have disappeared from the cluster log files :-( | 15:08.04 |
| kens | Still int the ones I see | 15:08.46 |
| henrys | chrisl_r61 I wrote to chrisl above don't know if you saw it. | 15:09.47 |
| chrisl_r61 | henrys: sorry, I didn't - no not fixed yet, other crap keeps hitting my queue before it..... | 15:10.34 |
| henrys | chrisl_r61:I can create a bug if you want, let me know | 15:11.08 |
| chrisl_r61 | henrys: no necessary - it is written on the whiteboard in my office, so I won't forget! | 15:11.38 |
| | s/no/not | 15:11.44 |
| | kens: the local push I just did, the log files are "formatted" timing, md5 etc | 15:12.14 |
| kens | Hmm | 15:12.22 |
| chrisl_r61 | Oh, hang on a sec..... | 15:12.41 |
| kens | Not what I'm seeing for my last set | 15:12.46 |
| | AH you are looking at result email | 15:12.57 |
| | you need individual machine logs | 15:13.03 |
| chrisl_r61 | Oh, that is odd - I have two browser tabs open, both the same address, one shows the "formatted" log, and one the old style "dump" I was expecting..... | 15:13.54 |
| | Well, confusing, but I have the command line I needed. | 15:15.31 |
| kens | :) | 15:15.37 |
| Robin_Watts | tor8: To run mudraw on an exploded xps file, what bit do I point it at again? | 15:47.52 |
| tor8 | _rels/.rels | 15:48.20 |
| Robin_Watts | error: cannot find end of central directory | 15:49.05 |
| ray_work | kens: I am looking at your comment on 693722. We have many instances of modules that include MANY devices, but not all of the devices get built in. For example, pamcmyk is in gdevpbm.c but is not part of the standard Windows build | 15:50.01 |
| | kens: so why does the device list get populated with the pdfwrite device ? (I know all the files will still be linked in, but that is different) | 15:50.58 |
| tor8 | Robin_Watts: odd... | 15:51.13 |
| Robin_Watts | ./_rels/.rels works. | 15:51.25 |
| tor8 | that means it doesn't detect it being a xps-in-a-directory | 15:51.29 |
| Robin_Watts | It needs "/_rels/.rels" in the path "_rels/.rels" isn't enough | 15:51.47 |
| kens | 1ray as far as I understand it,the macros defining the devices caus ehtem to be defined. SO if you include a source file with a macro definition of a device then that device is included. Is this not correct / | 15:52.03 |
| tor8 | Robin_Watts: what you said :) I just checked too. | 15:52.32 |
| ray_work | kens: I am looking at what might be wrong in the makefiles... | 15:53.02 |
| Robin_Watts | kens: AIUI, including a source file is NOT enough to get all the devices that that source file defines included. | 15:53.15 |
| chrisl | ray_work: there is *nothing* wrong in the makefiles, it was intentionally written that way | 15:53.28 |
| ray_work | kens: OK. the problem is that the ps2write.dev does ADDMOD $(DD)ps2write -include $(DD)pdfwrite.dev | 15:54.03 |
| chrisl | ray_work: there is even a comment in the makefile making it clear it was intentional | 15:54.03 |
| kens | ray_work : see chrisl comment above and the note in the bug thread | 15:54.21 |
| chrisl | ray_work: that's not a problem!!! | 15:54.25 |
| ray_work | kens: (and chrisl): just because it was "intentional" (not sure it wasn't just for convenience) doesn | 15:56.50 |
| | doesn't mean that it is very difficult to fix. | 15:57.09 |
| kens | No, but I don't see it as a major problem eitgher | 15:57.23 |
| chrisl | Of course it was just for convenience - but what benefit do we derive from changing it? | 15:57.26 |
| ray_work | kens: I was commenting on your statements that there is no way to do this. It's actually quite simple -- the problem is the -include pdfwrite.dev invokes uses the SETDEV2 macro | 16:01.49 |
| | so it's only a couple of lines to change it | 16:02.25 |
| kens | ray_work : I detest the way we define devices, and I'm no expert on teh build. I did say if it bothred Marecos enough he could raise it as a build issue | 16:02.28 |
| ray_work | marcosw: is it worth fixing ? If so I'll develop the patch and pass it to chrisl for review | 16:03.09 |
| | kens: I assume marcosw had a reason to open the bug in the first place. | 16:03.34 |
| kens | I have no idea, apart from the fatc that it's 'differnt' to other devies | 16:03.51 |
| | Because he didn't say why this was a problem | 16:04.01 |
| ray_work | kens: just for the record, the SETMOD just defines a helper .dev module (usually a library or collection of modules). The SETDEV2 is what also puts the device into the device list | 16:04.59 |
| | kens: so if what is there now for the pdfwrite.dev : target instead were to be changed to a pdflib.dev target then this BOTH the ps2write.dev and the pdfwrite.dev just become two line definitions that -include pdflib.dev | 16:09.25 |
| | (well, maybe three line definitions) | 16:10.08 |
| chrisl | ray_work: why do you care? | 16:10.16 |
| ray_work | chrsl: why do I want to make sure kens knows why it happens, and that there is an easy way to fix it ? | 16:11.04 |
| kens | is not interested | 16:11.21 |
| ray_work | kens: perfectly fine with me. | 16:11.42 |
| | Mostly I don't like incorrect information being spread in the bug tracker, because people might get confused | 16:12.15 |
| Robin_Watts | Having one (set of) devices that works differently to others is bad. We should strive for consistency. | 16:14.26 |
| | A consistently mad build system is better than an inconsistently mad one :) | 16:14.55 |
| ray_work | Robin_Watts: so you are thinking that's why marcosw opened the bug ? | 16:14.59 |
| | I'll wait until marcosw weighs in... | 16:15.24 |
| Robin_Watts | It sounds like it confused marcosw. And if it confuses marcosw it's entirely possible it'll confuse other people. | 16:15.56 |
| | It's worth noting that I've never found anyone that was entirely happy with the build system they were used. I think it's a fact of nature that everyone will consider their build system to be suboptimal. | 16:16.51 |
| ray_work | Robin_Watts: well, ghostscript's build system is a bit more arcane than many -- what with all the 'helper' generated programs | 16:17.41 |
| Robin_Watts | ray_work: Everyones build system has quirks such as that. Everyone believes that their system is worse than everyone elses. | 16:18.31 |
| henrys | a clue that there shouldn't be build systems | 16:19.09 |
| Robin_Watts | should introduce henrys to Julian Smith one day :) | 16:19.42 |
| ray_work | henrys: right. we should go back to the good old days of just compiling each file by itself, then putting all the object files on a link command line ;-) | 16:20.18 |
| | at least we don't use Jam (anymore) | 16:20.50 |
| henrys | who is juilan smith | 16:22.37 |
| | ? | 16:22.39 |
| Robin_Watts | friend of mine. one of the guys behind undodb. | 16:23.03 |
| | Has written at least 2 build systems that I know of. | 16:23.35 |
| | Is extremely good at pointing at things in computing and saying "but we've been doing that wrong for years". | 16:24.23 |
| marcosw | Robin_Watts, kens, chrisl, and ray_work: I opened bug 693722 because I wasted a bunch of time trying to build a gs without the pdfwrite device and couldn't. I needed gs without pdfwrite for bug 693721. I also tried building with just the TIFF devices, but that didn't work either (which explains bug 693720). | 16:41.40 |
| | pdfwrite.dev and ps2write.dev being inseparable is a bug according to the documentation (see doc/Make.htm#Features_and_devices, which says you may omit devices by removing them from the DEVICE_DEVS definition in the Makefile, removing pdfwrite.dev from the Makefile does not remove it from the build). I suppose kens will argue that it's a documentation error :-) | 16:50.23 |
| kens | That or a build prcoess bug, its *NOT* mine. | 16:50.48 |
| henrys | no kens argued - assign it to chrisl as I recall. | 16:51.02 |
| | ray_work, marcosw ^^^ | 16:52.55 |
| ray_work | marcosw: I just posted a patch (tested on my Windows build) that works. see bug 693722 | 16:54.18 |
| | I don't see any harm in making the change, but I'll leave it up to the rest of you to duke out | 16:55.24 |
| henrys | ray_work:I don't like calling something a lib that isn't but I'll stay out of it too. | 16:56.23 |
| ray_work | I don't care what it's called. That is also a trivial change: pdfstuff.dev is fine with me :-) | 16:57.03 |
| Robin_Watts | pdfwritecore.dev ? | 16:58.08 |
| ray_work | pdfwrshared or pdfwrcommon also (or what Robin_Watts said). | 16:58.22 |
| henrys | Robin_Watts: any of those is fine by me. | 16:58.34 |
| ray_work | the point of posting the patch was to show _how_ to do it | 16:58.35 |
| Robin_Watts | common is nice. | 16:58.39 |
| ray_work | Robin_Watts: we used to have to keep .dev names to 8 char, but I think we abandoned that since all systems have long filenames (at least the build systems) | 16:59.42 |
| | pdfwrcore ? | 16:59.54 |
| Robin_Watts | IF we're abandoning 8 chars, then let's abandon 9 too. pdfwritecommon seems nicest to me. | 17:00.32 |
| | but I'm only involved in this cos I'm nosey, so feel free to ignore me :) | 17:00.49 |
| henrys | in the interest of ruffling feathers: code review works again ⦠;-) | 17:01.49 |
| ray_work | henrys: in this case, the feathers were ruffled by my review of the bug commentary. | 17:02.30 |
| ray_laptop | chrisl: A makefile question for you (new topic -- I'm done with the previous one). gs.mak lines 376 and 377 set FEATURE_DEVS_EXTRA= and DEVICE_DEVS_EXTRA= (no contents). With stoopid nmake, this redefines the macros, making the intended use non-functional | 17:08.23 |
| | chrisl: do we really need these? undefined macros are harmless in all makes that I know of. | 17:09.06 |
| | they just default to an empty string | 17:09.24 |
| chrisl | ray_laptop: okay, I wasn't aware of what the intended purpose was.... was can probably remove the assignments | 17:09.24 |
| | ray_laptop: We could protect them with a conditional | 17:10.18 |
| ray_laptop | chrisl: this works OK on linux make (and most other make implementations) because they don't assign something that already has a value | 17:10.26 |
| chrisl | ray_laptop: as I say, we can make them conditional on not being defined already | 17:11.04 |
| ray_laptop | chrisl: we don't allow conditional statements in the shared .mak files (like lib.mak and gs.mak) since those also are not the same on different makes | 17:11.14 |
| chrisl | ray_laptop: oh, sorry I thought you were in a windows specific file | 17:11.44 |
| ray_laptop | only the top makefiles that are specific to a particular build system can have conditionals | 17:11.54 |
| chrisl | Well, as I said, removing is probably fine | 17:12.31 |
| ray_laptop | chrisl: I found a couple of other problems with these optional macros in msvc.mak as well so if you don't object, I'll fix them in the same patch | 17:13.07 |
| chrisl | ray_laptop: sure, no problem | 17:13.26 |
| ray_laptop | the other problem is that the 'nmake' invocations for the other targets don't populate the invocation with FEATURE_DEVS_EXTRA=$(FEATURE_DEVS_EXTRA) (same for DEVICE_DEVS_EXTRA) | 17:14.21 |
| | that's the problem with nested nmake invocations :-( | 17:14.50 |
| | as the common/msvc_top.mak shows. | 17:15.47 |
| | it would be so much nicer if the macros were inherited | 17:16.16 |
| | chrisl: unix make does inherit macro values, doesn't it ? | 17:16.51 |
| chrisl | ray_laptop: I think it does, it uses environment variables - but I would prefer to fix it properly than rely on that | 17:17.45 |
| ray_laptop | chrisl: mess up the unix make to add all of the junk that msvc_top.mak has ? Noooooo... | 17:18.30 |
| chrisl | ray_laptop: okay, we'll not worry about it then | 17:19.13 |
| ray_laptop | this is already a nightmare because the pcl make has to be manually maintained every time we add a macro (and we -- the gs-centric folks -- usually forget) | 17:19.50 |
| chrisl | ray_laptop: that's why I want to have pcl/xps built "properly" by the gs build system - as discussed at the staff meeting | 17:20.32 |
| ray_laptop | chrisl: I meant that if you really want to do that to the unix makefiles, fine. As long as you keep them up to date | 17:20.43 |
| chrisl | ray_laptop: no, let's not worry about it | 17:22.51 |
| ray_laptop | chrisl: currently msvc_top.mak has 62 macros that it passes down into the nmake !!! | 17:23.46 |
| | and I have no idea if that is a complete list :-( | 17:24.20 |
| | chrisl: I hope you can get things straightened out. I don't envy you. Maybe you can put pharmaceuticals on your expense report ;-) | 17:25.30 |
| chrisl | :-) | 17:25.46 |
| ray_laptop | or at least hair replacement treatments | 17:26.05 |
| Robin_Watts | So, we're getting different FP results on macpro and on windows. | 18:36.18 |
| | a + (b-a)*d | 18:36.30 |
| | where *(int*)&a = 0x3f800000 *(int *)&b = 3e40c0c1 *(int *)&d = 0x3e40c0c0 | 18:37.42 |
| | Sorry. *(int *)&d = 0x3f800000 | 18:38.37 |
| | macpro gives result r, where *(int *)&r = 0x3e40c0c0 | 18:39.15 |
| | wheras windows gives 0x3e40c0c1 | 18:39.30 |
| | 3f800000 = 1.0, so it seems that windows is right :) | 18:41.44 |
| | If simple FP can vary between machines, how is the cluster ever working!? | 18:42.06 |
| | tor8, paulgardiner: 2 small patches on robin/master | 19:06.31 |
| paulgardiner | Robin_Watts: Look fine, although I'm astounded that those two versions could give different results. | 19:11.23 |
| Robin_Watts | paulgardiner: It's a difference in the bottom bit. | 19:11.42 |
| paulgardiner | If it had been a + b +c I'd guess it was down to non-associativity, but you'd think there was only one way to calculat a + (b - a) *x ... unless it was being really clever and making it b * x + a * (1-x) | 19:15.45 |
| Robin_Watts | why would that be clever? That's 2 muls instead of 1. | 19:16.18 |
| | 1 more patch, also tiny. | 19:20.36 |
| paulgardiner | Yeah, that makes no sense, so the only freedom it has is commutability. Surely that would count as a processor bug if plus or times didn't commute | 19:25.18 |
| Robin_Watts | paulgardiner: You would hope that a + (b-a)*1 = b | 19:25.43 |
| | but my fix makes all the machines make a+(b-a)*1 be not quite b. | 19:26.05 |
| paulgardiner | I'm less surprised at that than at there being two possibly values. | 19:27.56 |
| | Was x == 1 the only failing case? | 19:28.21 |
| Robin_Watts | x == 1 was the case I spotted. | 19:28.47 |
| | I fear this same problem may occur elsewhere in the code (like in the antialiasing code). So it may not be possible to get it consistent :( | 19:29.26 |
| | even with this fix in, I'm seeing some files giving different results. | 19:29.51 |
| paulgardiner | Optimiser might be spotting the x == 1 case, but that's a really bad thing to do with floating point. | 19:31.39 |
| Robin_Watts | paulgardiner: It's a variable. Don't see how it could. | 19:32.29 |
| paulgardiner | store-bookkeeping commit looks good | 19:33.03 |
| | yeah it can't be. The only other thing I can think of is the plus and times instructions themselves don't commute. | 19:33.57 |
| Robin_Watts | paulgardiner: If it was an ARM thing I'd look at the assembly :) | 19:36.35 |
| | Yeah, still getting funny blending on the edges of things. On both text and line art :( | 19:37.23 |
| paulgardiner | Would be insteresting to know what b -= a; x *= b; x += a; return x; does and b -= a; b *= x; a += b; return a; | 19:37.43 |
| Robin_Watts | So the cluster may have problems with FP usage. | 19:38.07 |
| | Forward 1 day (to 2013/03/23)>>> | |
IRC Logs