| | <<<Back 1 day (to 2015/03/19) | 20150320 |
| kens | Morning chrisl, when do you plan to move the build system to MSBuild ? : | 07:49.58 |
| | http://www.theregister.co.uk/2015/03/19/microsoft_open_sources_msbuild_aims_for_crossplatform_dev_tools/ | 07:49.58 |
| | :-D | 07:49.58 |
| chrisl | kens: I'm not entirely convinced by M$ build tools on Windows, never mind Linux and Mac!! | 08:19.20 |
| kens | :-) | 08:19.37 |
| | I xsee you had a busy day yesterday | 08:19.47 |
| chrisl | Yeh, Nelson Beebe found a problem on SPARC, so I was up late dealing with the that | 08:21.27 |
| kens | I was just reading the emails (catching up, I didn't expect so many in one afternoon....) | 08:21.54 |
| chrisl | Well, some of it was tidying up my bugs, but plenty of other stuff going on | 08:22.45 |
| kens | Including the loon wibbling about fonts converted to paths. | 08:23.06 |
| | Not doing anything about that. | 08:23.11 |
| chrisl | No, I thought I'd leave that for you to reply to | 08:23.46 |
| kens | Not planning to reply, the bug is resolved invalid, I'm leaving it like that | 08:23.59 |
| | I've already replied, I'm not going to give him a repeat of the explanation | 08:24.15 |
| chrisl | How the hell do all these people come to report all this crap *during* the release process?? | 09:27.58 |
| kens | I guess maybe they start testing when they get the email ? | 09:28.12 |
| | Those 2 are from Tim Waugh, of course neither is new | 09:28.36 |
| chrisl | Both Tim's ones originate as end user reports, I think, so I doubt they are testing an rc | 09:29.16 |
| kens | Oh..... | 09:29.23 |
| | Just bad timing then I guess | 09:29.28 |
| | The gdevdsp.c code makes no sense | 09:29.35 |
| chrisl | Since when is that new?? | 09:29.47 |
| kens | Sure, just saying.... | 09:29.56 |
| | Returning an error seems reasonable, unless Ray knows a good reason why its a bad idea. | 09:30.20 |
| chrisl | Most bug investigations seem to start with the phrase "that code makes no sense...." ;-) | 09:30.27 |
| kens | It only returns 0 if there's no callback | 09:30.33 |
| chrisl | Yeh, that seems bad | 09:30.49 |
| kens | Well, we could have it ignore that fact, and just render anyway, presumably it would then discard the data | 09:31.09 |
| chrisl | I guess that may have been the original intent, but..... I think using the display device without callbacks should be an error | 09:32.22 |
| kens | Looks like its to prevent trying to use a non-existent device to return the memory pointer. Seems to me it should definitely be an error to reach that point with no device capable of returning bits to render into | 09:34.35 |
| chrisl | I'll leave it to Ray. If he's happy with it returning an error, it's quick enough to do, and if he knows or thinks there's a good reason not to return an error, he can decide if he's too busy to look at it, and pass it one of the rest of us. | 09:36.52 |
| kens | OK as far as I'm concerned it looks like it definitely shoudl be an error. It appears to be a test to ensure we don't try and use the callback to return memory, if no callback has been set. So if we reach the point where we need a render buffer, and the device isn't capable (yet) of giving us a buffer, then that's an error condition and we should halt. The intent of the code seems reasonable, but the execution is poor. | 09:38.24 |
| | Maybe an earlier incarnation of the code tested against a NULL pointer return. | 09:39.04 |
| chrisl | Is the same device method called from anywhere else? That might give a clue as to the intent | 09:40.18 |
| kens | Not sure, give me a minute | 09:40.35 |
| | well get_bits is called from all over the place | 09:41.33 |
| | Too many places to be certain, but I don;t see any evidence that it ever checked the returned memory pointer, and indeed teh display device doesn't even NULL the pointer, it just returns 0 as an exit code. All teh code seems to be the normal case where 0 = success, <0 is an error and > 0 is 'something else' | 09:46.46 |
| | So the display device just looks wrong. | 09:46.53 |
| | Oh and another 'I can't send you the PDF file' bug report from Tim Waugh. Reported Feb 22nd so I htink he's started going through his backlog when you sent out the new release notification | 11:25.59 |
| chrisl | Well, tough, I'm not rushing through stuff just because people can't be bothered to report stuff in a timely fashion. And no file, no fix..... | 11:28.32 |
| kens | Yes, that's what I'm going to tell him when he responds | 11:28.47 |
| | The variable should absolutely not be uninitialised at that point, and the fact that it is indicates a problem in a completely different piece of code, which I clearly can't trace without the file. | 11:29.26 |
| chrisl | It also may be unrelated - I don't trust valgrind alone for that kind of thing now | 11:30.04 |
| kens | No, I don't either, nor do I trust the version of Ghostscript they are using, since its undoubtedly their own packaging | 11:30.27 |
| chrisl | I'm off to squash - back in a couple of hours..... | 11:30.52 |
| kens | FWIW the 3 bugs he's reported only one is new, but it relates to a different bug from december last year. | 11:30.57 |
| | Have fun | 11:30.59 |
| Robin_Watts | Aha, a tor8. | 13:00.27 |
| | What's the state of play with getting your csi commits in? | 13:01.27 |
| tor8 | need to find and fix the segfaults | 13:01.40 |
| | was busy looking at the eclipse this morning | 13:01.49 |
| Robin_Watts | tor8: ah. was a bit cloudy here for it. | 13:02.09 |
| tor8 | just perfectly overcast to see it without needing goggles | 13:02.23 |
| kens | COuldn't see it at all here | 13:07.22 |
| Robin_Watts | tor8: Ok, I'm clear of SOT for a bit. | 13:52.18 |
| | I'm going to squish some of my patches together, and then rebase them on top of your changes. | 13:52.52 |
| | (on the grounds that the fixed version of your commits won't be hugely different to what you have now). | 13:53.22 |
| | after lunch. | 13:54.05 |
| tor8 | Robin_Watts: okay. | 14:06.34 |
| | Robin_Watts: fill.gstate_num is a struct field whose use I don't remember... | 14:43.08 |
| | or when I/you added it | 14:43.13 |
| Robin_Watts | let me look. | 14:43.19 |
| tor8 | it ends up being -1 and causing memory errors in CATX3044.pdf | 14:43.53 |
| | I've probably slipped up and forgot to update it somewhere :/ | 14:44.09 |
| | there's a segfault fix on tor/csi-squish | 14:44.33 |
| Robin_Watts | So... when running the pdf_run_processor has an array of gstates, and gstate_num is which one is in progress. | 14:45.35 |
| | It's initialised to -1 for both strokes and fills. | 14:45.46 |
| | and in pdf_set_pattern mat->gstate_num = pr->gparent. | 14:46.07 |
| tor8 | I think it might be the gstate that's at the top of the 'page' context when drawing patterns for the ctm | 14:46.11 |
| Robin_Watts | I'm sure it's going to be something like that. | 14:46.42 |
| | D'Oh. | 14:47.12 |
| | I'm looking at your branch. | 14:47.16 |
| | Just a mo. | 14:47.18 |
| tor8 | yeah, I've missed setting it at the end of the code that has replaced pdf_run_SC_imp | 14:47.25 |
| Robin_Watts | yeah. | 14:47.46 |
| | So, if you fix that and push it, I'll work from that. | 14:48.23 |
| | (push it to your personal repo I mean) | 14:48.41 |
| tor8 | yeah, just valgrind checking my fix | 14:49.12 |
| | and it came through clean :) | 14:49.27 |
| | pushed to csi-squish | 14:50.05 |
| Robin_Watts | cool. | 14:50.13 |
| | begin_softmask still has some XXX in it. | 14:56.39 |
| tor8 | ah, yes. the cookie. | 14:57.43 |
| | I thought about putting the cookie in the pdf_processor superclass struct (like I did with the OCG hidden state tracker) | 14:58.04 |
| | it's probably the right spot to put it | 14:58.15 |
| chrisl | kens: thanks for trying the rc1 installer. I'm about to put up an rc2 with a workaround for the SPARC problem. It's a small change to the configure script, so you don't need to devote to trying it on Windows unless you're feeling unfeasibly enthusiastic.... | 15:40.43 |
| kens | :-) | 15:40.53 |
| Robin_Watts | tor8: windows builds of mupdf are broken at the moment. | 15:51.11 |
| | freds freetype change has resulted in config/ftoptions.h going missing. | 15:51.31 |
| tor8 | yeah, freetype has moved their header files | 15:53.58 |
| | Robin_Watts: I'm seeing some odd bmpcmp diffs with the csi branch | 15:54.19 |
| Robin_Watts | 18 is genuine | 15:56.46 |
| | They look like stroking stuff to me. | 15:57.58 |
| | Last (or maybe first?) segments of paths being missed. | 15:58.22 |
| | A flushing problem maybe? | 15:58.45 |
| | ooh, they get wackier deeper in... | 15:59.46 |
| tor8 | yeah. real strange ones with the patterned star. | 15:59.58 |
| Robin_Watts | My copy of mupdf is still in pieces. | 16:11.49 |
| | as soon as I get it together, I can try to have a look if you want. | 16:12.00 |
| tor8 | Robin_Watts: if you want. my brain is fried. | 16:24.23 |
| Robin_Watts | speaking of which, did you see Jurgens email? | 16:24.36 |
| tor8 | it's probably just a silly typo somewhere :/ | 16:24.43 |
| | Junghen you mean? | 16:25.02 |
| Robin_Watts | D'Oh. | 16:25.30 |
| | yes. | 16:25.32 |
| tor8 | odd stuff he's trying to do with that function | 16:26.47 |
| | though it does look like our font bbox stuff is strange | 16:31.12 |
| Robin_Watts | Ok, tor8: I've pushed my work so far to robin/merge_csi | 17:24.28 |
| | I want to push the commits up to and including "Automatically update /Length..." to golden. | 17:24.53 |
| | All the ones up to "Add fz_fprintf" in fact. | 17:26.59 |
| | tor8: OK, everything up to and including "Fix Memtrace for 64bit operation" is good to go, and passes the cluster test. | 17:48.48 |
| | (I think they are all your commits that I've reviewed, or my commits that you've previously reviewed to that point) | 17:49.16 |
| tor8 | Robin_Watts: go for it | 18:20.07 |
| Robin_Watts | pushed | 18:20.32 |
| | tor8: So the PDF spec says it uses 32bit ints, and anything larger than that gets stored as single precision floats, right? | 18:22.50 |
| | So... for PDF files of larger than 2 Gig, how does it handle the /Prev entries that point to the previous xrefs ? | 18:23.37 |
| | Where has Marcosw's garage gone? | 19:13.30 |
| | tor8: I've got an updated printf commit on robin/merge_csi that I'd like to get in. | 19:14.00 |
| | actually... just let me tweak a comment. | 19:14.29 |
| | Ok. It's there. | 19:17.16 |
| | It adds %u, and fixes the leading 0 stuff so that we can do %010d. | 19:17.53 |
| | Also adds %D, , %X for 64 things. | 19:18.08 |
| | and adds %z for size_t and %Z for fz_off_t | 19:18.20 |
| | tests pass on that too. | 19:28.22 |
| | marcosw: What happened to your garage? | 19:39.47 |
| henrys | Robin_Watts: I know he bring them down in the afternoon here, but not this early | 19:43.44 |
| Robin_Watts | henrys: I suspect his internet or power have failed. | 19:44.01 |
| marcosw | Robin_Watts: we are having solar panels installed and they had to cut the power. everything should be back up. | 19:51.07 |
| Robin_Watts | marcosw: Ah, cool. | 19:51.15 |
| | What sort? What total capacity? | 19:51.26 |
| marcosw | it was very quiet in my house and garage for about 15 minutes⦠| 19:51.40 |
| tor8 | Robin_Watts: no idea... | 19:53.25 |
| Robin_Watts | tor8: ? | 19:53.44 |
| tor8 | re numbers in /Prev | 19:54.06 |
| | Robin_Watts: question, why not just use int64_t everywhere we use fz_off_t? | 19:55.02 |
| Robin_Watts | because on 32bit builds without MUPDF_LARGE_FILE_SUPPORT defined, fz_off_t will be an int. | 19:55.36 |
| tor8 | would it harm us to use int64_t there? | 19:55.53 |
| marcosw | Robin_Watts: either 8.5 or 9.4 kilowatts, depending on which rating you want to believe. | 19:55.59 |
| Robin_Watts | we don't want to take the memory hit of storing int64_t's in all the xref tables etc. | 19:56.01 |
| tor8 | also, why not reuse off_t? | 19:56.08 |
| Robin_Watts | marcosw: So 10 panels or so? | 19:56.18 |
| marcosw | 28 panels | 19:56.22 |
| tor8 | or is it because off_t depends on the automagic _LARGE_FILE_OFFSET thing changing symbols etc | 19:56.26 |
| marcosw | http://us.sunpower.com/home-solar/solar-cell-technology-solutions/ | 19:56.41 |
| tor8 | Robin_Watts: case 'X' calls fmtint instead of fmtint64 | 19:57.27 |
| Robin_Watts | _LARGE_FILE_OFFSET doesn't work on windows. | 19:57.28 |
| | tor8: oops. will fix, ta. | 19:57.39 |
| | Better to have our own type that we control, I feel. | 19:57.54 |
| tor8 | Robin_Watts: okay. let's keep it this way for now then. | 19:58.21 |
| Robin_Watts | marcosw: I got the mental arithmetic wrong. | 19:58.24 |
| marcosw | each panel puts out 335 robins | 19:58.25 |
| tor8 | %X should be unsigned ints only though? | 19:58.30 |
| Robin_Watts | marcosw: I get 190 marcosw's for each panel. | 19:58.37 |
| tor8 | no signed %x's | 19:58.39 |
| Robin_Watts | and I have 21. | 19:58.40 |
| | tor8: It should. | 19:58.52 |
| | tor8: so I should call fmtuint64 for X and fmtuint for x | 19:59.26 |
| marcosw | the panels are 21.3% efficient, which sounds like not much but is apparently good (the inverters are 97% efficient, which iâm really surprised by, particularly considering how big the heat sinks on the back of them are). | 20:01.31 |
| Robin_Watts | marcosw: 21.3 sounds good. | 20:01.47 |
| marcosw | whatâs the payback time on a solar system in the UK? I would think being so far north it would be a while (itâs 9 years in my area). | 20:02.15 |
| | otoh, you probably pay more for mains power than we do. | 20:02.30 |
| Robin_Watts | marcosw: 15p a unit or something for power. | 20:03.06 |
| | but there is a government boondoggle here that means they pay me to generate power. | 20:03.22 |
| | I make 50p for every unit I generate, whether I use it or not. | 20:03.35 |
| | and that goes up by inflation every year. | 20:03.54 |
| | so I should get a 10 year payback easily. | 20:04.10 |
| marcosw | sorry, whatâs a âunitâ is standard units. | 20:04.12 |
| Robin_Watts | and the payments are guaranteed for 25 years. | 20:04.21 |
| | kilowatt hour. | 20:04.29 |
| | I'm being called for food. | 20:06.26 |
| | have a good weekend all. | 20:06.32 |
| marcosw | Robin_Watts: you too. | 20:06.45 |
| henrys | Robin_Watts: thanks Robin_Watts have a good one | 20:07.13 |
| jazzcripter | About MuJS, I would like to know if there is any limitation to use "make release" in Android (4.4 NON ROOTED) using TERMINAL IDE EMULATOR, because when I try I'm getting this:"execvp: cc: Permission denied" | 23:05.16 |
| | is there any way to do this in a NON ROOTED device? | 23:06.14 |
| pedrocr | the Samsung 1865W seems to be a PCL printer with similar setup as the 2152W | 23:06.31 |
| | at least the 2152W gutenprint PCL driver works fine with it | 23:06.40 |
| | the 2152W pxlmono driver doesn't seem to however | 23:07.00 |
| | would you be interested in a bug report somewhere? | 23:07.13 |
| henrys | jazzcripter: you probably want to talk to Tor who has left for the day and possibly the weekend. Check in European business hours. | 23:07.36 |
| jazzcripter | Thank you Sir henrys, I will come back in another day, because MuJS looks very promising | 23:09.42 |
| henrys | pedrocr: googling it doesn't support XL so I wouldn't expect the driver to work, ljet4 or another pcl5e driver should work. | 23:11.21 |
| pedrocr | henrys: gutenprint seems to work fine but maybe that's an older PCL? | 23:12.44 |
| henrys | pedrocr: I'm sure it is pcl5e | 23:13.10 |
| pedrocr | henrys: ah, ljet4 does indeed work well | 23:16.07 |
| | what's the difference between ljet4/ljet4d/lj4dith? | 23:17.14 |
| | seems there's also hpijs-pcl5e | 23:17.33 |
| | how would I go about submitting the printer to foomatic? | 23:20.21 |
| henrys | a quick google: http://www.openprinting.org/driver/ljet4/ | 23:21.07 |
| pedrocr | that's the driver page but I don't see any info on how to submit new printers | 23:24.07 |
| henrys | pedrocr: you asked the difference between ljet4/ljet4d ... I don't know anything about foomatic but I think you can look up your question quickly | 23:25.15 |
| pedrocr | henrys: I've tried but haven't been able to find straightforward instructions | 23:29.27 |
| | lj4dith seems to work fine and the margins are decent | 23:29.39 |
| | I'll just leave it at that | 23:29.56 |
| | henrys: thanks for the help | 23:34.04 |
| henrys | pedrocr: sure good luck. | 23:34.17 |
| Robin_Watts | jazzcripter: (For the logs) That sounds like you're trying to run the c compiler, and failing due to a permissions problems. | 23:59.57 |
| | Forward 1 day (to 2015/03/21)>>> | |
IRC Logs