| | <<<Back 1 day (to 2014/12/17) | 20141218 |
| kens | Hmm, well Gunther is definitely correct, not only that, but 9.15 is a *lot* slower processing the PDF file than the current master. | 08:49.37 |
| chrisl | Well, that's good.... sort of | 08:50.42 |
| kens | chrisl I can't see any problems with the patch for 695745, do you want to go ahead and commit it and close the bug please ? | 08:51.06 |
| kens | assumes chris has cluster tested it :-) | 08:51.17 |
| chrisl | Sure, will do so in a bit - yes, it is cluster tested...... | 08:51.32 |
| kens | OK thanks. I guess I'll have to go bisect the (300+) page job. This might take some time, I htink I'll work on the PCL text bug first. | 08:52.10 |
| chrisl | kens: do you want me to do the bisect? It might be quicker | 08:56.34 |
| kens | If you don';t mind. I suspect it may be the change to planar images, or something like that, the details escape me but someone else has complained about a similar problem I think. | 08:57.05 |
| | I may be some time with this stupid text render mode thing :-( | 08:57.18 |
| chrisl | Can you stick the test file on casper? | 08:57.29 |
| kens | Sure, one second. | 08:57.34 |
| | You might be quicker getting the original | 08:58.59 |
| | Its going to be 10 minutes uploading from here, seems to be unreasonably slow uploading | 08:59.24 |
| chrisl | Okay, I'll try the details in the e-mail | 08:59.40 |
| kens | THat's what I used and it was quick. | 08:59.49 |
| | You want the one and only file in the 'files' sub directory | 09:00.01 |
| chrisl | Got it | 09:00.57 |
| | Or, getting it.... | 09:01.04 |
| kens | THen I'll cancel the upload :-) | 09:01.05 |
| chrisl | Oh, I bet there's all kinds of horrid transparency in there :-( | 09:01.49 |
| kens | Its completely possible, certainly, but the 9.10 binary sits at ~30MB while the 9.15 was up to 500MB at page 170 and still rising. | 09:04.04 |
| | So something is eating memory. | 09:04.25 |
| | And of course when I ask for a command line they say 'you don't need anything special'. THat's helpful | 09:04.58 |
| chrisl | Hah, 500Mb isn't so bad nowadays ;-) | 09:05.07 |
| kens | Well true, but at that rate it was going to hit 1GB by the end. Also its slow. | 09:05.33 |
| chrisl | kens: so, what command line did you use? | 09:07.10 |
| kens | gs <input file> | 09:07.21 |
| | So straight to the display device at 96 dpi | 09:07.32 |
| chrisl | Hmm, I wonder if the 9.15 binary I'm trying is already patched for something - I'm not seeing anything like that amount of memory use..... | 09:09.02 |
| kens | Well I have to confess I was using my current code which *defintiely* has patches in it. | 09:09.29 |
| chrisl | But you saw the problem with 9.15? | 09:09.55 |
| kens | I never tested the stock 9.15 | 09:10.03 |
| | Give me a minute and I'll try it. I was using a 33-bit build of master with some random pdfwrite changes | 09:10.22 |
| chrisl | Ah, one of those custom 33 bit builds - well, they can be awkward..... | 09:11.00 |
| kens | using the 32-bit 9.15 windows build, fomr the installer, at page 27 I'malready at 100MB and riusing, and the rendering is slow | 09:11.44 |
| | page 39, now at 137MB | 09:12.22 |
| | Page 59, 208MB | 09:12.50 |
| | and so on, I won't run the whoel 330+, it takes a long time | 09:13.10 |
| chrisl | Can you try it with ppmraw please? | 09:13.38 |
| kens | Looks like I don't currently have a 64-bit installed | 09:13.45 |
| | just a moment | 09:13.49 |
| | THat seems a lot better. | 09:14.47 |
| | Memory is up and down, bt sticking around 30 MB and much faster | 09:15.10 |
| chrisl | So, clearly, configuration *is* important..... | 09:15.29 |
| kens | Looks like it yes | 09:15.37 |
| | ppmraw looked good to me. | 09:15.58 |
| | But the display device definitely is not. | 09:16.17 |
| chrisl | I wonder what is special about the display device..... | 09:16.25 |
| kens | I wonder what the difference is..... | 09:16.26 |
| | The display debice *is* unusual in many ways, which one is important.... | 09:16.44 |
| Nygashi | Goodmorning :) | 09:18.09 |
| chrisl | psdcmyk does not show a problem either..... | 09:18.16 |
| kens | nor pkmraw | 09:18.22 |
| | Surely they aren't really using the display device ? O.O | 09:18.38 |
| | I'll mail them. | 09:18.43 |
| chrisl | If it's just the display device, it'll be harder for me to bisect | 09:19.04 |
| Nygashi | Could anyone help me with hopefully a quick question about MuPDF? :) | 09:19.53 |
| chrisl | Nygashi: probably not at the moment - the mupdf devs probably won't be around for another hour or two | 09:20.44 |
| Nygashi | Ok, thank you very much! | 09:21.03 |
| kens | And I see the Lilypond guy is back, gluing PDF files together and wondering why his annotations don't work..... | 09:21.09 |
| chrisl | Nygashi: if you want to ask a question, the channel is logged, and we can make sure they see it | 09:21.13 |
| kens | He can wait anyway | 09:21.19 |
| Nygashi | Haha, i will be around the whole day :) | 09:21.30 |
| | i' ll just wait if that's ok with you guys | 09:21.38 |
| chrisl | Nygashi: feel free | 09:21.54 |
| Nygashi | This might be a very stupid question, but what is this channel used for in general? | 09:22.11 |
| chrisl | Nygashi: ghostscript and mupdf development discussion | 09:25.12 |
| kens | THe Message of the day says that I think :-) | 09:25.47 |
| chrisl | It just mentions Ghostscript, which is a little remiss these days | 09:26.09 |
| kens | We shoudl change it in that case | 09:26.21 |
| | Probably should also mention MuJS too | 09:26.39 |
| Nygashi | I'm not very familiar with the term or name Ghostscript :> | 09:26.52 |
| chrisl | http://en.wikipedia.org/wiki/Ghostscript | 09:27.19 |
| kens | A quick google will tell you more than you could possibly want to know..... | 09:27.21 |
| Nygashi | Ye i did that, thanks :D | 09:27.31 |
| kens | Hmm, I see whoever wrtes teh wiki page also doesn't like AGPL 3 | 09:29.31 |
| chrisl | Okay, let's see it that worked - back in a mo | 09:31.25 |
| | Hmm, nope | 09:32.09 |
| | Maybe you need to be a channel owner to change it, rather than just an op | 09:33.34 |
| kens | Possibly, best to ask Ray to do it I guess | 09:33.46 |
| chrisl | Yeh | 09:34.43 |
| kens | hrisl no reply form the customer, so maybe best you leave the bisect to me, and I'll get to it after I finish up the PCL Tr mode change | 09:59.11 |
| chrisl | kens: okay, if they come back, we can talk again | 10:00.09 |
| Nygashi | Hi there :) | 11:24.46 |
| | Trying again, could anyone help me with hopefully a quick question about MuPDF? :) | 11:25.00 |
| tor8 | Nygashi: possibly | 11:25.28 |
| Nygashi | Nice | 11:25.53 |
| | I'm working on a double page view (two pages in landscape mode). | 11:26.32 |
| | I've managed to get it working, almost | 11:26.42 |
| tor8 | android? | 11:26.44 |
| Nygashi | The only thing that is left is increasing the width of the view the pages are drawn on, i think | 11:27.00 |
| | Would you maybe know how i can achieve that? :) | 11:27.19 |
| | As the two pages are now drawn inside the width of just 1 page, if you can follow me so far | 11:27.43 |
| | Yes on android | 11:27.54 |
| | I have the latest version aswell | 11:28.05 |
| tor8 | I'm not that familiar with the android app details, paulgardiner or Robin_Watts are better placed to answer your question | 11:28.25 |
| Robin_Watts | paulgardiner: is the expert on how the android app works. | 11:28.35 |
| | AIUI, each page is held in a view. | 11:28.42 |
| | The views are managed by an adapter. | 11:28.48 |
| Nygashi | Yes indeed | 11:28.57 |
| Robin_Watts | so it sounds to me like you need to change the calculations within the adapter that resize the views. | 11:29.07 |
| Nygashi | The weird thing is, the adapter specifies a bitmap that is equal to the width of the screen in landscape mode | 11:29.21 |
| | Though, they are still drawn as if it's just the width of 1 pdf page | 11:29.43 |
| Robin_Watts | There is a boolean you can change that changes the adapter between laying pages out horizontally and laying them out vertically. | 11:29.52 |
| Nygashi | So my two cents is that something happens in the MuPDFCore, in which i'm adjusting things now | 11:30.05 |
| Robin_Watts | Nygashi: Current MuPDF Android makes some assumptions, like that it only needs to keep 3 cached pages around. | 11:31.01 |
| paulgardiner | Hang on, isn't it ReaderView that does all this calculation? | 11:31.06 |
| Robin_Watts | The current one, plus one either side. | 11:31.08 |
| Nygashi | Ok thanks, i will look for the boolean :) | 11:31.10 |
| tor8 | Robin_Watts: how is that JNI project coming along? ;) | 11:31.42 |
| Robin_Watts | If you are doing a 2 page up view, then you probably need to expand that to be 6 pages (the 2 current ones, plus 2 either side) | 11:31.45 |
| Nygashi | Ok :) | 11:31.57 |
| Robin_Watts | tor8: I can safely say that I have not touched it in 3 months :) | 11:32.00 |
| Robin_Watts | reboots PC. | 11:32.15 |
| Nygashi | Thanks btw guys, i will look into it again with the information supplied :P | 11:35.56 |
| zeniko | tor8: in case you missed it last week, there are some small patches on zeniko/mupdf for a crash fix, some memory leaks and an MSVC warning | 11:36.14 |
| tor8 | zeniko: okay. will take a look. | 11:36.33 |
| Nygashi | Awesome btw that you guys have a channel and are prepared to answer questions :) | 11:36.39 |
| tor8 | zeniko: did robin look at the ensure_solid_xref change? (I've not paid attention to the xref changes lately) | 11:37.11 |
| zeniko | Robin_Watts: ^ ? | 11:37.38 |
| tor8 | zeniko: now I wonder if the const char ** in cbz_document.page shouldn't be char * const * instead... | 11:40.20 |
| | zeniko: but no, that's even more wrong | 11:41.43 |
| zeniko | tor8: I don't quite see the reason for the MSVC warning, as the pointer to use/free is pointing to a non-const value (which happens to be a pointer to a const one) | 11:42.45 |
| tor8 | zeniko: exactly, I'd report that as a bug to microsoft... | 11:43.06 |
| zeniko | tor8: The warning seems to be present in both VS2008 and VS2013, so I'd assume it's already been reported dozen of times and WontFixed for some reason. | 11:45.33 |
| | Robin_Watts: Could you please check whether the crash fix related to ensure_solid_xref on zeniko/mupdf is (sufficiently) correct? | 11:47.09 |
| Robin_Watts | zeniko: I'm buried in SOT stuff at the moment. Will try to look at some point. Sorry. | 11:47.54 |
| zeniko | tor8: http://c-faq.com/ansi/constmismatch.html | 11:48.21 |
| Robin_Watts | actually, that's a simple fix, and it looks good. | 11:48.45 |
| zeniko | Robin_Watts: thanks | 11:49.03 |
| Robin_Watts | And I think you're right, it should be doc->num_xref_sections-1, not 0. | 11:49.38 |
| | so if you want to do a fix for that too, we can test it and get it committed. Nice spot. | 11:50.01 |
| tor8 | zeniko: urgh... sometimes I regret adding const everywhere, but it's such a useful documentation tool | 11:51.41 |
| | fixes look good, but I'd possibly reword the LZW warning message to mention LZW | 11:52.27 |
| zeniko | tor8: done (our MuPDF includes file names and line numbers for all warnings and errors) | 11:56.24 |
| tor8 | zeniko: right, our warnings don't include the file and line number | 11:57.09 |
| zeniko | pushed, so bug 695746 can be closed as fixed (I don't seem to have the rights to do this myself) | 12:01.46 |
| kens | Robin, in case you missed it, commit d7c0c0856b31be17823ae4745b2c542a9c71765f seems to have introduced a load of seg faults | 12:06.53 |
| tor8 | zeniko: done. | 12:17.42 |
| zeniko | tor8: thanks | 12:20.12 |
| kens | chrisl that seems to finish up the PCL text rendering mode stuff, so I'll get to the memory/slowdown problem bisect after lunch | 12:21.10 |
| chrisl | kens: I may have some news on that in a moment or three..... | 12:21.29 |
| kens | tor8 mujstest still throwing lots of seg faults out | 12:21.35 |
| | chrisl, oh, OK then I'll catch that after lunch :-) | 12:21.54 |
| tor8 | kens: oh... how long has it been doing that? | 12:22.26 |
| kens | tor8 I mentioned it in the logs a minut ago | 12:22.39 |
| | But I puut robin's anem :- | 12:22.50 |
| | commit d7c0c0856b31be17823ae4745b2c542a9c71765f seems to have introduced a load of seg faults | 12:22.58 |
| tor8 | kens: right. well, it's in robin's bit of code so I thought you mentioned the right name :) | 12:23.21 |
| kens | :-) | 12:23.28 |
| tor8 | kens: I finished blindsight, started on the sequel. definitely worth reading! | 12:56.35 |
| | kens: http://www.amazon.co.uk/Firefall-Peter-Watts/dp/1784080462/ there's the omnibus volume | 12:56.53 |
| kens | tor8 thanks for the URL, one for the next staff meeting :-) | 12:58.13 |
| tor8 | kens: very brainy stuff, not light reading. but highly recommended. | 12:59.01 |
| kens | That's OK, I'm fine with reading real science :-) | 12:59.23 |
| tor8 | (pardon the pun...which you'll get once you read it) | 12:59.25 |
| kens | chrisl the cusotmer says they *are* using the display device <boggles> | 13:18.03 |
| | chrisl any lucj with the display device problem ? | 13:42.04 |
| Robin_Watts | oh, that's zenikos patch from this morning? odd. | 13:49.52 |
| kens | has to go for a checkup at the dentist, back later. Chrisl if you find anything with the display device please say here, otherwise I'll start on a bisect when I get back. | 13:58.26 |
| chrisl | kens: sorry, parents were here. | 14:04.18 |
| | kens: display device problem is caused by: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4e44c995 | 14:04.47 |
| rayjj | morning, kens, chrisl (et al.) | 14:29.59 |
| chrisl | Hi rayjj | 14:30.09 |
| rayjj | the display device writing clist _could_ slow things down. Shouldn't (but could) result in higher RAM use | 14:30.33 |
| | -dMaxBitmap=1g should revert to the old, non-clist mode | 14:30.55 |
| chrisl | I was about to try that when my parents arrived..... | 14:31.18 |
| tor8 | rayjj: that embedded javascript thing you found at the meeting, it's using mozilla's javascript engine | 14:31.28 |
| rayjj | a debug build with -Z: should show if clist mode is used | 14:31.29 |
| | tor8: I see. So presumably it isn't all that small ? | 14:32.00 |
| | duktape seems to be small, however | 14:32.15 |
| tor8 | rayjj: duktape seems like our biggest competition. but it's 3x worse than mujs on all accounts. | 14:32.45 |
| | 3x as much source code, 3x slower, uses 3x as much ram | 14:32.55 |
| rayjj | I have to take my kids to school in just a few minutes. back in ~30x | 14:33.08 |
| | tor8: 3x slower ??? | 14:33.14 |
| | WOW!!! | 14:33.18 |
| chrisl | rayjj: -dMaxBitmap=1g causes memory use to be stable, rather than growing. Without it, -Z: shows a clist in use. So it does seem to be something clist related not being freed | 14:33.45 |
| tor8 | mujs is faster than spidermonkey without the jit on some benchmarks! | 14:33.47 |
| rayjj | 3x source code is a don't care, 3x RAM use might be | 14:33.57 |
| tor8 | espruino, which is our second biggest competition, which seems to be a rewrite of tinyjs to be in C and actually complete | 14:34.28 |
| rayjj | chrisl: I'll have a look when I get back unless you've kept looking at it | 14:34.31 |
| | I'll check the logs | 14:34.40 |
| tor8 | it runs in a fraction of the memory, but it's got severe limits on recursion depth | 14:34.41 |
| chrisl | rayjj: okay | 14:34.43 |
| tor8 | but it's orders of magnitude slower than anything else | 14:34.54 |
| | what mujs does in 3s it takes nearly 3 minutes to do | 14:35.23 |
| henrys | trying to add some clipping to xpswrite - I swear the vector superclass is like a chinese finger puzzle. good god. | 14:45.43 |
| tor8 | bah. trying to build javascriptcore on linux is a nightmare! | 14:53.31 |
| henrys | tor8: so are you finding mujs faster than you thought? | 15:50.09 |
| | relatively | 15:50.15 |
| rayjj | tor8: please collect the relative benchmark data as you go through this. It'll be handy for Scott (and us if we actually get a customer interested). BTW, what are you using for benchmarking RAM + performance ? | 15:53.04 |
| | (so we won't have to do it again later) | 15:53.52 |
| Robin_Watts | rayjj: The entire point of this is to capture that data :) | 15:54.26 |
| henrys | rayjj: tor is doing a report for miles and scott ... | 15:54.35 |
| kens | henrys, did you see I chucked the PCL 'transparent' text bug over to you ? | 15:55.20 |
| henrys | yes I did sorry I've been embroiled in the latest sot saga | 15:55.49 |
| kens | Not a problem, just wanted to make sure you realised | 15:56.00 |
| | I'm going to tackle the Lilypond user's bug then get bck to devices, if I can remember where I was...... | 15:56.35 |
| henrys | okay I guess I should deal with transparent first since the customer is waiting | 15:57.14 |
| kens | It shoudl be easy,just pull the stuff for the params out of the pctext file and make a 'global' in the PCL state instead. | 15:57.55 |
| | I commented teh include files I added, and why | 15:58.23 |
| henrys | yup | 15:58.30 |
| kens | You'll want to pull those out too | 15:58.41 |
| henrys | kens: so I'll rework your patch and put it back on the bug or should I commit? | 16:01.50 |
| kens | Whenyou're happy I;d just commit it. THe pdfwrite commit is in place already | 16:02.09 |
| | You could check the customer's file, or I cando that after you commit it if you like. | 16:02.29 |
| henrys | I'll just commit it and cite you. | 16:02.49 |
| | in case it breaks ;-) | 16:03.03 |
| kens | Yeah I figured that was why :-) | 16:03.14 |
| henrys | actually I didn't want to steal the glory | 16:04.53 |
| kens | Glory ? ROFL.... | 16:05.03 |
| | The hard bit was all in pdfwrite anyway :-) And if that ever breaks I'll have no idea how it works anyway | 16:05.38 |
| chrisl | rayjj: so, the memory being leaked *seems* to be ICC related - ICC stuff allocated when we push the final image to the target device. But I'm struggling beyond that right now | 16:11.46 |
| rayjj | gah. want to avoid loading (large) patterns when playing back the clist, but the patterns are written to the clist *before* the fill processing (up in do_fill) so I have to re-factor code to get the bounds for the bands | 16:15.03 |
| henrys | do we have some law against strdup in ghostscript? | 16:23.23 |
| Robin_Watts | strdup is not a C89 function. | 16:24.17 |
| henrys | ah that's it. | 16:24.27 |
| | I don't know if marcos or I have a role in support all the emails are sent to Ken specifically. | 16:31.06 |
| kens | THey are cc'ed to support though I hope ? | 16:31.37 |
| | Because I'm planning to take a good break over Xmas, then ski-ing early January | 16:31.53 |
| henrys | kens: yes just that they start Hi Kens ... is what I meant | 16:32.04 |
| kens | Ah, probably because I responded first to the customer. Often they start 'Hi Marcos' :-) | 16:32.27 |
| | Or at least they do when Marcos is on duty | 16:32.50 |
| | Speaking of which, do we know when Marcos is back ? | 16:34.50 |
| | I cna't remember what he said at the staff meeting | 16:35.05 |
| henrys | kens: I didn't get it either ... | 16:35.41 |
| kens | Ah well, presumably he'll tell us when he's bacl :-) | 16:36.00 |
| Robin_Watts | Dec 16th was the hard deadline for his thesis. | 16:36.26 |
| | I suspect he's still asleep :) | 16:36.41 |
| | chrisl: I see you're off from friday - are you doing anything exciting over the new year? | 16:37.31 |
| | s/new year/xmas and the new year/ | 16:37.46 |
| chrisl | Robin_Watts: not working ;-) | 16:38.20 |
| | TBH, it depends a lot on the weather | 16:38.40 |
| Robin_Watts | ah, come on, we all know you really want the excuse to ignore all of us while you finish the gs directory restructuring in peace :) | 16:38.54 |
| chrisl | As the next item on that list is the Windows stuff, I doubt I'll be tempted to look at it outside work time! | 16:39.59 |
| | Robin_Watts: actually, I'm probably going to devote some time to nosing around used car lots..... I'm not convinced the 924 will make it to next August..... | 16:44.25 |
| rayjj | chrisl: are you using memento to find the leaks? | 16:55.35 |
| chrisl | rayjj: that was where I got the hint that they were ICC related, yes | 16:56.03 |
| rayjj | chrisl: just let me know when you want to stop working on it and I'll pick it up | 16:56.06 |
| | chrisl: it'll make a nice break from trying to find the elusive performance hit between 8.71 and 9.06 for cust 532. Every time I ask for timing info, the problem points move :-( | 16:58.34 |
| chrisl | rayjj: That always seems to happen with their "profiling tools". Despite the time it wastes, once again, they don't seem willing to implement a "proper" solution | 16:59.47 |
| | rayjj: I think I have something for the memory leak problem. It makes a big difference to the memory use, but I want to double check with memento | 17:05.57 |
| henrys | kens: in apple preview your new code is display the social security number. | 17:18.13 |
| kens | henrys that's because apple preview ignores the Tr 3 for bitmap fonts. Acrobat doesn't, so I class that as an Apple preview bug. There's nothing more we can do about it, if the customer is not happy with that. | 17:19.35 |
| | From a technical perspective, I agree with the Apple preview, but its not what Acrobat does, so.... Also, if they are relying on the PDF not displaying the number, that's a piss poor security measure, because they also want Acrobat to be able to search for it, and if it cna do that, then cut and paste will work on it. | 17:20.59 |
| henrys | kens: remind me not to give my social security number to ibm. | 17:21.07 |
| kens | About as good as 'redacting' CIA PDF files by drawing over them with a black rectangle.... | 17:21.31 |
| | Yay marcos is back | 17:22.03 |
| henrys | dr marcos | 17:23.03 |
| kens | Well, not quite yet I htink | 17:23.15 |
| | But soon we cna hope | 17:23.25 |
| Robin_Watts | Marcos has his viva on Jan 16th. | 17:25.41 |
| kens | TIme for me to be off, goodnight folks | 17:26.46 |
| chrisl | rayjj: This solves the memory leak problem: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=53dc47fff | 17:30.08 |
| rayjj | chrisl: thanks. Seems safe enough. I guess when the gx_device_printer is not the "rendering" one I create for non-printer devices, the icc_cache must be freed someplace else | 17:38.41 |
| | (other than "tear_down") | 17:38.51 |
| chrisl | Yeh, I guess so - I'm contemplating whether to track it down...... | 17:40.31 |
| rayjj | chrisl: I think it is usually done in clist_finish_page (when the clist is in "reader/render" mode) | 17:41.23 |
| chrisl | Ah, so I don't need to check for null before the rc_decrement, cool, I'll remove that | 17:46.13 |
| rayjj | chrisl: yep, in pdf14_clist_create_compositor toward the end, it calls get_bits on the "fake" device, but never calls clist_finish_page | 17:46.38 |
| chrisl | rayjj: I assume because you don't want it to reinitialise the clist at that point | 17:47.11 |
| rayjj | chrisl: I guess I assume that closing the printer device would clean up everything (after rendering the image, it falls through to put_accum_error: where it closes the prn_device and unhooks | 17:48.37 |
| chrisl | rayjj: tbh, it's not an unreasonable assumption! | 17:49.10 |
| rayjj | chrisl: you may want to check the color_usage_array (that is also freed in clist_finish_page) | 17:50.33 |
| | chrisl: the other bgprint stuff in clist_finish_page is not relevant | 17:50.57 |
| McErroneous | Hi, does anybody know how to access a usb-printer using the "cp-command" ? | 17:51.07 |
| chrisl | rayjj: I'm fairly sure I saw that being freed, but I'll double check | 17:51.22 |
| rayjj | chrisl: but if you want to leave that for me, that's fine, too | 17:51.23 |
| | McErroneous: what OS | 17:51.43 |
| chrisl | rayjj: it's fine, although I may have to finish up tomorrow.... | 17:51.54 |
| McErroneous | crunchbang 10 | 17:51.55 |
| rayjj | McErroneous: is that a linux variant ? | 17:52.07 |
| McErroneous | rayjj: yes | 17:52.14 |
| rayjj | McErroneous: I think, since a printer doesn't have a file system, you 'cat' to it, *not* cp | 17:52.34 |
| | as in: cat file > /dev/usb0 | 17:52.47 |
| | or something like that | 17:52.53 |
| chrisl | McErroneous: do you have cups running? | 17:53.05 |
| McErroneous | rayjj: hmm... i am going to try that now.... | 17:54.23 |
| | the printer is supposed to be a file ? as everything in linux is a file ? | 17:55.25 |
| | i think so.. | 17:55.44 |
| chrisl | Almost everything in Unix/Linux is a file - devices are "special" files | 17:55.58 |
| McErroneous | damn , i am not able to test cat, because my keyboard does not offer rectangular brackets at this point in time... | 17:58.23 |
| chrisl | Copy'n'paste from above..... | 17:58.50 |
| mvrhel_laptop | ok all the bit depths as well as planar or chunky images are now working for the xpswrite device. just have one funny decode issuing going on with one of the ps cet files to fix | 17:59.10 |
| McErroneous | :-) | 17:59.10 |
| mvrhel_laptop | rayjj: I may not have a patch for you to review until tomorrow | 17:59.56 |
| chrisl | McErroneous: if you have cups running, you might be better considering the lpr command | 18:00.41 |
| rayjj | mvrhel_laptop: no rush | 18:02.26 |
| McErroneous | chrisl: that is what i want to avoid..., i want to be a terminal-shell junkie | 18:02.34 |
| chrisl | lpr is a command line utility | 18:02.57 |
| McErroneous | chrisl: i want to be in power... | 18:03.11 |
| rayjj | McErroneous: having a good k/b is pretty much a requirement to be a shell junkie ;-) | 18:03.44 |
| chrisl | McErroneous: very laudable, but, no offence, you might be trying to run before you can walk..... | 18:03.54 |
| rayjj | McErroneous: a little power can be dangerous. Have you heard of "Sorceror's Apprentice"? ;-) | 18:04.56 |
| chrisl | McErroneous: the point is, you can use the "-o raw" option to lpr which will bypass *all* the cups filtering, and make life a little easier getting things going | 18:06.23 |
| rayjj | chrisl: with the leak fixed, I assume that the clist mode to the display device is still slow. I hope that you posted the -dMaxBitmap=1g param setting to revert to old behaviour | 18:06.37 |
| chrisl | rayjj: kens sent the MaxBitmap option to the customer | 18:07.20 |
| rayjj | McErroneous: what chrisl says is true. Sometimes there are privelege issues with going to the /dev/___ devices directly | 18:07.25 |
| | chrisl: OK. Thanks | 18:07.34 |
| | McErroneous: but 'lpr' runs with adequate priveleges | 18:08.16 |
| chrisl | rayjj: with the leak fixed the speed is still slower than using the large bitmap, but not badly so. The display still zips past faster than I could proof the contents, so...... | 18:08.28 |
| rayjj | chrisl: Can you see if -dBufferSpace=32m speeds it up further ? | 18:08.57 |
| | (that'll increase the band size a bit, iirc) | 18:09.28 |
| chrisl | rayjj: will try in a second | 18:10.05 |
| McErroneous | chrisl: as soon as i get to know how to use the "lpr -o"-option i am going to forget what i have been looking for.... | 18:10.37 |
| | namely to do a "cp-command" to my usb-printer... | 18:11.26 |
| chrisl | You cannot do a "cp-command" to your usb-printer..... | 18:11.57 |
| McErroneous | usb-device.. | 18:12.06 |
| chrisl | You need to mount the device as a file system, then you can cp to it - printers generally are not accessible as file systems | 18:12.42 |
| McErroneous | sorry, chrisl i done the cp-command to my lpt1-printer..., so i should well be possible to do the same thing on my usb-printer... | 18:13.49 |
| chrisl | Really? cp? Not cpio? | 18:14.24 |
| McErroneous | chrisl: yes..., as i mentioned | 18:15.05 |
| chrisl | McErroneous: well, it's certainly not the normal way of doing it | 18:15.43 |
| McErroneous | i am late to do oldschool stuff...., but i want it... | 18:16.08 |
| chrisl | rayjj: (for the logs) -dBufferSpace=32m is about four times faster than using the default - we should possibly review the default.... | 18:32.57 |
| | I'm stopping now - I'll recheck and push the fix in the morning. | 18:33.15 |
| mvrhel_laptop | aha. looks like the color monitoring had a bug in it for when we had funky decode settings | 21:59.47 |
| | which is causing me issues in the xpswrite output | 22:00.00 |
| | have to head out for a bit now | 22:00.12 |
| | back shortly to fix this | 22:00.16 |
| | Forward 1 day (to 2014/12/19)>>> | |
IRC Logs