| | <<<Back 1 day (to 2011/09/04) | 2011/09/05 |
| Robin_Watts | bedtime. Night. | 00:00.36 |
| sebras | should I create a bug requesting a bottomless pit of time too? ;) | 00:00.46 |
| | thanks, goodnight! | 00:00.54 |
| cryptopsy | henrys: do you own the photo store by the same name? | 03:10.48 |
| henrys | cryptopsy:no my name is henry, the 's' is for Stiles my last name - its a common username convention, first name and first letter of last name. | 04:09.39 |
| cryptopsy | oh | 04:36.42 |
| Robin_Watts | excellent google doodle today. | 09:39.20 |
| kens | Bit more than a doodle :-) | 09:40.11 |
| tor8 | kens, Robin_Watts: could you sanity check windows build of mupdf 0.9 for me? http://ghostscript.com/~tor/stuff/mupdf-0.9-windows.zip | 11:20.37 |
| kens | getting it now | 11:21.06 |
| Robin_Watts | in a mo, sure. | 11:23.20 |
| kens | brb | 11:23.26 |
| | seems to be OK | 11:23.57 |
| | tor8 mupdf.exe and pdfclean.exe work OK. Not sure how to test the others. | 11:32.21 |
| | Note that mupdf.exe spawns a UAC dialog thart the 'publisher could not be veridfied'. | 11:32.55 |
| tor8 | hmm, never seen that UAC thing | 11:34.23 |
| kens | I can turn it off by telling it not t ask again for that executable. | 11:34.44 |
| Robin_Watts | mupdf.exe works for me. | 11:43.21 |
| kens | No UAC warning ? | 11:43.32 |
| Robin_Watts | (but I'm not on V*i%t@) | 11:43.34 |
| kens | Well that would explain it | 11:43.45 |
| Robin_Watts | so do pdfdraw and pdfclean | 11:45.29 |
| | And pdfshow and extract give the expected help messages. | 11:45.51 |
| tor8 | kens: it may be the tainting it does for downloaded files | 11:48.58 |
| | kens, robin_Watts: thanks. now I can tag and release. | 11:52.38 |
| kens | tor8 Maybe, but I copied ti to a clean location before running. I think its just because tis not digitally signed. | 12:10.03 |
| | In any event, its not a problem I think. | 12:10.18 |
| tor8 | kens: already 2 downloads in the five minutes it's been up on code.google.com! | 12:16.48 |
| kens | Remarkable! | 12:16.58 |
| tor8 | I haven't even written the release notes on mupdf.com yet :) | 12:17.10 |
| kens | You'd best hurry then :-) | 12:17.19 |
| tor8 | yeah, the hardest part is remembering everything I did since april | 12:17.42 |
| kens | Off to get a haircut, back shortly. | 12:18.33 |
| Robin_Watts | Can't see any recent plank vs pamcmyk4 difference emails. Did Marcos not send the last one out? | 12:51.59 |
| kens | tor8 does MupDF report on the resolution of images in PDF files ? | 14:13.32 |
| | Or any of the tools | 14:13.44 |
| tor8 | kens: not resolution, but pdfinfo shows the width/height | 14:20.40 |
| kens | OK thanks tor8 | 14:21.04 |
| henrys | Labor Day in the US I'll be in and out today. | 14:49.17 |
| | resolved but not closed should keep marcos busy. | 14:56.51 |
| kens | have a good break henrys | 15:05.23 |
| | Logging off in good time tonight, pizza :-) | 15:42.01 |
| Robin_Watts | gawd, is it that time already? | 15:42.20 |
| kens | Afraid so | 15:43.39 |
| Robin_Watts | Time flies when you're fighting makefiles. | 15:43.52 |
| henrys | Robin_Watts:xcode build is broken seems to be related to the aux directory but I didn't look carefully | 15:50.25 |
| Robin_Watts | xcode is just broken, for me. | 15:50.47 |
| | It hasn't worked right since I updated after lion. | 15:50.58 |
| henrys | oh I upgraded too ... I have a machine with snow leopard also I'll check that. | 15:52.17 |
| Robin_Watts | ISTR I tried and failed to get it working after upgrading to lion and lost patience and went back to the command line and gdb. | 16:02.17 |
| | I wish I hadn't bothered upgrading. The compilers are now shafted, and they've removed the gesture that I used the most. | 16:03.04 |
| henrys | me too, kind of annoyed - I liked shark from the command line - now the profiler is wrapped up in instruments. Valgrind no longer works etc. | 16:05.44 |
| Robin_Watts | Yes, the lack of valgrind is VERY annoying, as that was what I used the mac for. | 16:06.33 |
| | I've got a debian virtual machine on VMware fusion on there - might have to resort to that. | 16:07.12 |
| | I now find it easiest to run windows XP on VMware and develop on that. | 16:07.30 |
| | chrisl: Did you/ray do 64bit windows ghostpdl binaries last time around ? | 16:08.42 |
| chrisl | Robin_Watts: No, the makefiles aren't there for it yet - on my to-do list for 9.05...... | 16:12.23 |
| Robin_Watts | I'm in the makefiles at the moment adding support for a memento build. | 16:12.47 |
| | and fixing some problems in the solution. | 16:12.59 |
| | so I might add that now, while I'm at it, if that's OK. | 16:13.12 |
| chrisl | Sure, go ahead. Can you test it? | 16:13.28 |
| Robin_Watts | No :( | 16:13.33 |
| | but it's not like I can make it any worse :) | 16:13.43 |
| chrisl | True, ping me when you've committed your changes, and I'll try it. | 16:14.07 |
| | if you decide to go ahead, of course | 16:14.26 |
| kens | heading off now, night all. | 16:31.10 |
| ray_laptop | chrisl: last week on IRC, I did confirm that if we were interacting with a customer on a specific issue (such as we have both done with cust 532, or ken and I were with Craig) that it is OK to continue. | 16:38.37 |
| | chrisl: I did mention last week as well that maybe a discussion at the staff meeting to clarify this would be good. We don't want to make sure that we don't make Marcos' job more difficult, but want to make sure that we don't miss a response to customers | 16:40.29 |
| Robin_Watts | ray_laptop: Did you sort it so that you could do 64 bit builds on 32 bit windows ? | 16:41.30 |
| | ISTR there was one case missing. | 16:41.48 |
| | (probably 32bit builds on 64 bit windows are OK, but 64bit on 32 is not) | 16:42.07 |
| ray_laptop | Robin_Watts: I have 64-bit Windows, so I can't easily test, but I think others have done it. | 16:42.11 |
| chrisl | ray_laptop: not a problem - as I said, I probably missed the tail end of the discussion. | 16:42.11 |
| | Robin_Watts, ray_laptop: as things stand, I don't think genconf and genarch will work cross compiling 64 bit on 32 bit Windows | 16:43.15 |
| Robin_Watts | chrisl: Indeed, that's the problem I hit. | 16:43.36 |
| | But I wondered if ray had worked some magic intending to fix that. | 16:43.50 |
| ray_laptop | The BUILD_SYSTEM macro _should_ allow for it | 16:43.58 |
| chrisl | As I have 64 bit Windows, I decided not to care. I don't see the point in building an executable you can't test | 16:44.18 |
| Robin_Watts | I'll do some tests in a mo then. | 16:44.23 |
| ray_laptop | oh, that's right -- genarch was the issue. | 16:44.27 |
| Robin_Watts | chrisl: Except that it would be nice to be able to 'Build All' to test :) | 16:44.38 |
| ray_laptop | genconf should be OK (as mkromfs) since they can be compliled and run as 32-bit apps | 16:44.57 |
| chrisl | ray_laptop: they can be, but I'm not sure that works right now - as I said, I didn't consider it important | 16:45.34 |
| ray_laptop | we'd have to make sure that genarch gets told that it was building a 64-bit app (to force 64-bit pointers), or have the Windows makefile use a 'canned' 64-bit arch.h if building on a 32-bit system. | 16:46.44 |
| chrisl | ray_laptop, henrys: Maybe when we make a policy decision like the customer contact thing, it could be communicated via e-mail? If you're not directly involved in the IRC (or sometimes if you are!), it can be difficult to know what the *final* conclusion of the discussion was. | 16:47.14 |
| ray_laptop | chrisl: I agree. It may have been discussed last staff meeting, but I didn't remember it either. | 16:48.03 |
| | chrisl: and I'd like to revisit the policy (briefly) since Ken often will see support queries, test them quickly, and then will respond to customers all before Marcos wakes up. I'm sure our customers on that side of the pond appreciate the quick response. | 16:49.59 |
| henrys | I thought it was pretty clear last meeting but no big deal, I'll add it to agenda and we'll discuss it again at the meeting. | 16:50.31 |
| ray_laptop | but maybe the issue is that once customers see a response from Ken, they respond directly to Ken and don't cc support, so it makes it hard to Marcos to track. | 16:50.53 |
| henrys | policy is probably best dealt with at the in-person meetings. | 16:51.02 |
| ray_laptop | henrys: thanks. It isn't that big a deal, but since we keep tripping over it (various of us emailing customers directly because it seems more 'natural') we need a bit more discussion. | 16:52.13 |
| chrisl | henrys: it's a shame bugzilla doesn't give us the features we need to let customer fill out their own bugs online - then everything would get tracked through that. | 16:53.27 |
| Robin_Watts | Using a system like osticket would help a lot. | 16:55.06 |
| henrys | we should be able to track what we have now. Marcos was going to look into something more structured and automated. | 16:55.10 |
| | I don't like the idea of customers filling out forms. It annoys many people. | 16:55.32 |
| Robin_Watts | It would ensure that every single email 'thread' is tracked, and it's easy to see who's been replied to/resolved and who hasn't. | 16:55.54 |
| | osticket doesn't involve forms. | 16:56.07 |
| chrisl | On the other hand, filling in a form can save a lot of to/fro e-mails getting basic information just to reproduce a bug - that annoys people, too. | 16:56.47 |
| henrys | the fixed not closed list will help also, fixes get lost. | 16:56.57 |
| Robin_Watts | AIUI, when a customer mails in, they get an automated reply saying "thanks for the email, it's been logged as ticket number X. If you have any more information, comments etc, please reply to this email, keeping the subject line the same'. | 16:57.15 |
| ray_laptop | on the 64-bit build, arch.h is the primary issue (as it is with ANY cross compilation) | 16:57.16 |
| | Robin_Watts: I don't think we've ever implemented an automated response. | 16:57.44 |
| | and we didn't have a ticket number system (yet) it was discussed last week | 16:58.04 |
| Robin_Watts | ray_laptop: I'm describing how (I believe) osticket (and similar ticketing solutions) work. | 16:58.39 |
| chrisl | Robin_Watts: sure, that kind of ticketing system is fine, but it means we have two sets of tracking numbers (bug ticket and bugzilla), one of each for customer bugs, which could prove a PITA! | 16:58.49 |
| ray_laptop | most of the 'ticket' support systems I've used are annoying in that you have to use a web site and not just email. | 16:59.17 |
| Robin_Watts | ray_laptop: The ones I've used before (think I've used 2) have all been email based. | 16:59.43 |
| | at least on the customer end. | 16:59.47 |
| ray_laptop | I agree with chrisl that having two different numbers would be a pain. | 17:00.18 |
| Robin_Watts | One of them worked by generating email addresses on the fly (support-ticketXXXX@ghostscript.com). | 17:00.37 |
| henrys | I'm sure marcos will want to weigh in but I just wanted a means to remind us when we are not responding, nothing from the customer POV should change. | 17:00.41 |
| | well accept that we are responding. | 17:01.06 |
| | s/accept/except | 17:01.14 |
| ray_laptop | right now customers can also open bugs directly (some do) and can track the issues on bugs (many more do) | 17:01.20 |
| Robin_Watts | ray_laptop: Well, when the ticket is 'promoted' to be a bug, we could close the ticket as 'reported as bug' - so only one number at a time. | 17:01.26 |
| | Or (if you have the on the fly email thing), you copy the ticket on the bug. | 17:01.58 |
| chrisl | Robin_Watts: closing the ticket when it logged in bugzilla wouldn't work because most customers rely on being e-mailed when we've fixed it | 17:02.33 |
| Robin_Watts | OK, so we use the latter scheme, and copy the ticket on the bug. | 17:02.54 |
| | Then when the bug gets closed marcos can follow up with the customer. | 17:03.12 |
| henrys | well it's now on the agenda. | 17:03.30 |
| chrisl | ANYWAY..... I didn't mean to spark this off - I just missed some of the IRC discussion about it last week, mea culpa | 17:04.34 |
| ray_laptop | I didn't mean to raise a major issue either, but we did talk about the 'ticket' idea last week on IRC (and it never got resolved) | 17:05.21 |
| henrys | it wasn't supposed to be resolved marcos was to research it. | 17:05.43 |
| | I'm happy to see the fixed not closed list and the end of monday's report. I think that will help responsiveness too. | 17:06.37 |
| chrisl | henrys: should we have the bug scrub on the agenda, too? | 17:06.57 |
| Robin_Watts | chrisl: Hmm. My makefile fiddlings so far have lead to something that seems quite natural to me, but is a change in behaviour. | 17:07.06 |
| henrys | yeah already have that. | 17:07.09 |
| chrisl | oh, great | 17:07.18 |
| Robin_Watts | At the moment, if you build DEBUG=1, the makefiles change the default output to be 'debugobj'. | 17:07.36 |
| | My change has it that if you build with DEBUGSYM=1 (and not DEBUG=1) then the makefiles change the default output to be 'profobj'. | 17:08.07 |
| ray_laptop | so far so good | 17:08.12 |
| Robin_Watts | And if you build with MEMENTO=1, the makefiles change the default output to be 'memobj'. | 17:08.33 |
| ray_laptop | Robin_Watts: so that means we also have profobj64 and memobj64 ? | 17:09.13 |
| Robin_Watts | ray_laptop: Yes. | 17:09.24 |
| ray_laptop | (corresponding to obj64 and debugobj64) | 17:09.28 |
| chrisl | Why does DEBUGSYM=1 end up with profobj? | 17:09.42 |
| Robin_Watts | Because 'Profile' builds in the windows solutions build DEBUG=0 and DEBUGSYM=1 | 17:10.07 |
| | To get a build suitable for profiling, you want debugging disabled, but symbols kept in. | 17:10.27 |
| | (These are only windows changes, and they aren't visible changes to people using the solutions) | 17:10.45 |
| chrisl | Oh, don't like that too well - I'd prefer PROFILE=1 or something. Other than that, it all sounds fine and sensible to me | 17:11.05 |
| Robin_Watts | That would mean adding a new flag. | 17:11.20 |
| | DEBUG and DEBUGSYM already have meanings. | 17:11.27 |
| ray_laptop | on linux builds, profile build go into profobj don't they ? | 17:11.28 |
| Robin_Watts | Maybe. Let me check. IF so, I'll change to use the same flag that unix builds do. | 17:11.56 |
| ray_laptop | on unix we have 'pg' target | 17:13.05 |
| | and it defines -DPROFILE | 17:13.31 |
| chrisl | And the files end up in pgobj and pgbin for GS - dunno about GhostPDL | 17:13.45 |
| ray_laptop | the unix prefix seems to be 'pg' not 'prof' | 17:14.18 |
| Robin_Watts | ray_laptop: Yeah, that's because it uses the -pg option to gcc, I think. | 17:14.54 |
| | The directory has been profobj for a while. | 17:15.04 |
| ray_laptop | Robin_Watts: you mean on Windows ? | 17:15.23 |
| Robin_Watts | ray_laptop: Yes. | 17:15.30 |
| ray_laptop | has no problems having the Windows and unix directories be different, but it's a little non-obvious to a newbie | 17:16.00 |
| chrisl | Robin_Watts: if the DEBUGSYM=1 is how it has previously worked on Windows, it might be best to leave it that way. Whether you want to add a new flag/target to be more consistent with Unix is up to you | 17:16.13 |
| Robin_Watts | I'm certainly happy to add a PROFILE flag and use that to cause the directory change. | 17:16.47 |
| | But I'm unhappy about changing from profobj to pgobj. | 17:17.00 |
| ray_laptop | profiling is mostly us, so 'fixing' it isn't needed. | 17:17.06 |
| chrisl | To be honest, I'm thinking we should change the Unix builds to also use a profobj directory | 17:17.29 |
| Robin_Watts | chrisl: Well, pgobj means "Built with -pg". | 17:17.58 |
| henrys | gprof is a dinosaur get rid of it entirely everyone uses oprofile or commercially zoom. | 17:18.03 |
| Robin_Watts | profobj means "built suitable for profiling". | 17:18.07 |
| chrisl | Robin_Watts: yeh, it's just rather gcc-centric - but I agree with ray_laptop: it's really only us that use it, so it's not really important. | 17:19.04 |
| henrys | mac uses instruments or shark | 17:19.07 |
| | bbiaw | 17:19.46 |
| chrisl | Robin_Watts: anyway, I don't have a problem with the change in behaviour you originally mentioned. | 17:21.10 |
| Robin_Watts | I think I prefer PROFILE=1 triggering the name change. | 17:21.26 |
| | that way it's not a change in behaviour. | 17:21.45 |
| chrisl | As do I, but I would be slightly wary about changing an existing flag | 17:22.22 |
| Robin_Watts | It's not an existing flag on windows :) | 17:22.36 |
| chrisl | Oh, in that case, PROFILE=1 makes more sense to me, too :-) | 17:22.57 |
| | I'm going to finish now - see if I can shake this headache. G'nite folks. | 17:28.02 |
| Robin_Watts | OOh. How's about this for a random idea. | 17:29.09 |
| | We could support a CONFIG define to the build, which gets passed to genarch. | 17:29.40 |
| | genarch would be changed so that if CONFIG is defined, then it would copy the file from that location rather than attempting to generate it itself. | 17:30.24 |
| | That would allow cross-compilation to work much more easily, right? | 17:30.51 |
| chrisl_away | Robin_Watts: we are planning to deprecate genarch, so not really worth expending effort, I don't think | 17:32.41 |
| Robin_Watts | except no one knows *how* we're planning to deprecate it. | 17:33.01 |
| | This would give us a mechanism to deprecate it. | 17:33.14 |
| chrisl_away | Yes, we discussed it last meeting: Windows will have a couple of predefined arch.h files, and Unix systems will generate arch.h through configure | 17:33.42 |
| Robin_Watts | So, there will be a part of the build that 'copies' the supplied configure file as arch.h ? | 17:34.47 |
| chrisl_away | Yes, exactly. | 17:35.00 |
| Robin_Watts | What I am suggesting is that we make genarch that bit of the build. | 17:35.14 |
| | but it keeps the facility to generate it's own when cross compiling on non-standard platforms. | 17:35.37 |
| | s/cross compiling/not cross compiling/ | 17:35.56 |
| | anyway, as I say, random idea was all. | 17:36.08 |
| chrisl_away | We want to get rid of genarch, though - at least, I do, I thought others did as well | 17:36.30 |
| Robin_Watts | IF we could get rid of *all* the exes we run during building, I'd agree with you. | 17:37.12 |
| | But given that we're always going to need the ability to run host based exes (like mkromfs), that seems far fetched. | 17:37.40 |
| chrisl_away | Well, can't get rid of mkromfs, but the others seem possible | 17:38.03 |
| Robin_Watts | as such the only reason that I see genarch as being 'worse' than the others is that it has to run on the host, but 'look like' the target. | 17:38.04 |
| | and suddenly, with my change, we change that from being a flaw to being a benefit. | 17:38.28 |
| | but thinking about this will not solve your headache :) | 17:39.06 |
| chrisl_away | Well, if you want to discuss it again at the staff meeting, add it to the agenda - yet again, I thought we'd settled all this previously. | 17:39.47 |
| ray_laptop | If we straightened out the dependencies, just having an 'arch.h' could resolve the cross compile issue (genarch would only run to make arch.h) but arc.h seems to be rebuilt to often. | 17:41.33 |
| | on msvc64.mak it can use another method to create arch.h (such a copying a predefined one) | 17:42.24 |
| chrisl_away | Robin_Watts: if we want to keep genarch for any purpose, then your proposal seems sensible - an option which says "don't generate arch.h, use this one". | 17:47.42 |
| Robin_Watts | chrisl_away: Yes. I personally think that existing users of 'odd' systems would consider it a retrograde step for us to take away the autogenerating option. | 17:48.24 |
| | If there are obscure systems that can't run configure, for example... | 17:49.27 |
| | but I'd be happy with any change that made cross-compilation simple. | 17:49.41 |
| chrisl_away | As I say, there's no point is using predefined arch.h files for Windows, configure for Unix and *still* having genarch in there. If genarch remains, we might as well use it for everything. In which case, making it flexible enough to deal with a predefined arch.h seems sensible. | 17:51.18 |
| | s/is/in | 17:51.25 |
| | Robin_Watts: I really am finishing now - if you want to make that change to genarch, go ahead, or make a bug, and I'll do it. | 17:53.54 |
| Robin_Watts | chrisl_away: No hurry at all. That was just something random that struck me. | 17:54.14 |
| chrisl_away | Robin_Watts: yeh, it's just if it's not done right away, or a bug not raised about it, we'll forget..... | 17:54.50 |
| Robin_Watts | I've done it locally. I'll test it before commit. | 18:34.21 |
| | ray_laptop: Could you mail me the arch.h from a 64bit windows box please? | 19:13.22 |
| ray_laptop | Robin_Watts: sorry, was away (holiday here) | 21:25.31 |
| | I'll email the arch.h now from 64-bit Windows (you can get the linux one from peeves or any other system) | 21:25.57 |
| tor8 | barfs on cairo's pdf output | 22:31.05 |
| | 7 wrapped xobjects, of which 2 are tiling patterns, to draw an image | 22:31.41 |
| Robin_Watts | no sign of mail from ray. | 23:11.30 |
| | tor8: Do you have a 64bit windows box ? | 23:11.38 |
| tor8 | Robin_Watts: affirmative. | 23:11.54 |
| Robin_Watts | Do you have a built version of ghostscript on it? | 23:12.07 |
| | Could you mail me the arch.h file from the obj dir please? | 23:12.20 |
| tor8 | nope. never built gs on the windows partition. | 23:12.22 |
| Robin_Watts | Oh well, never mind. | 23:12.35 |
| tor8 | I do my gs dev on linux mostly. | 23:12.43 |
| henrys | Robin_Watts:can you post your large jpeg on casper so I can convert it to pcl xl and test it. Thanks. | 23:33.02 |
| Robin_Watts | http://ghostscript.com/~robin/Beach1.jpg uploading now | 23:35.45 |
| henrys | and the snow leopard xcode failed also I'll look at it later. | 23:37.16 |
| Robin_Watts | xcode seems to be very poor when it comes to driving makefiles. | 23:38.17 |
| | uploaded | 23:40.00 |
| henrys | thanks and agreed respectively ... | 23:40.17 |
| Robin_Watts | I wonder... I might change genarch so that it generates into a memory buffer before it writes out. | 23:44.16 |
| | And if the file it would write to already exists, and is identical to that memory buffer, I won't write it. | 23:44.41 |
| | That might help with dependencies. | 23:45.02 |
| henrys | I can't think about genarch on a holiday ;-) | 23:45.13 |
| Robin_Watts | :) | 23:45.21 |
| | I mention that as much for the logs as anything else. | 23:45.34 |
| | Night. | 23:47.14 |
| henrys | see ya tomorrow | 23:47.26 |
| | Forward 1 day (to 2011/09/06)>>> | |
IRC Logs
