| | <<<Back 1 day (to 2014/09/22) | 2014/09/23 |
| sadasd | hello | 00:22.47 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 00:22.47 |
| kens | Oh joy, tons of new spam from Picsel mail addresses :-( | 07:26.54 |
| chrisl | Yeh, I think I might put a filter in for those.... | 07:30.40 |
| kens | Oh ooops, a compiler warning is pointing out an assignment that's *supposed* to be a test (single == not double) :-( | 07:31.47 |
| | I'm kind of surprised that didn't cause regressions | 07:32.08 |
| | And more spam, a filter has to be in order.... | 07:34.41 |
| | ROFL I still have a filter to send any email from eugene liamkin straight to 'ignored' | 07:35.21 |
| chrisl | I think it should remain - just in case! | 07:35.55 |
| kens | :-) | 07:36.00 |
| pedro_mac | kens: yeah, looks like someone picsel-y has lost their contacts list⦠| 07:51.10 |
| | although Iâm surprised anyone still has an addressbook with all those picsel contacts in it | 07:51.48 |
| | unless of course someone has deliberately done it to give us a nice bunch of spam to deal with... | 07:52.42 |
| kens | I assume that they've been acquired over the years and sold to spammers | 07:52.49 |
| pedro_mac | strange that weâve had nothing before now though - theyâre usually pretty quick at using email lists in case they go stale | 07:54.02 |
| kens | I sort of assumed this was something Ron had changed last night | 07:54.24 |
| | Wasn't there a request to change an email address for support or something ? | 07:54.42 |
| pedro_mac | there was, but most of those messages were to random individuals @picsel | 07:55.05 |
| | mostly operations/admin | 07:55.18 |
| kens | Sure, I thought that maybe Ron had changed the picsel.copm domain to forward to smart office support | 07:55.31 |
| pedro_mac | ah, thatâs going to be painful then | 07:55.53 |
| kens | THat's what I was thinking yes, hence the filter | 07:56.08 |
| pedro_mac | with over 500 people over the years weâll probably be deluged with old crap | 07:56.17 |
| kens | Indeed, though as you say they do tend to age the lists fairly quickly | 07:56.34 |
| t4nk869 | Hello, I wanted to ask if there is a free library to convert a raster image to a binabrio to send it directly to a head epson | 08:13.25 |
| kens | No idea, I doubt anyone here owuld know, if Google doesn't turn something up. IN fact I have no idea what a 'binabrio' is | 08:14.01 |
| t4nk869 | binary | 08:14.19 |
| kens | So you want to convert it to ESC/P ? | 08:14.40 |
| | Use Ghostscript to load the image (or make a PostScript file from it using an image application) then use an epson driver in GS | 08:15.10 |
| chrisl | Depending on the format of the raster image, you might be able to use one of the view*.ps utilities to convert more directly | 08:18.06 |
| kens | Yes, that's what I meant by 'use Ghostscript to load the image' | 08:18.24 |
| t4nk869 | no, I have a tab control head epson dx5 and I need to send a buffer of 180byte equivalent to 180 lines of the head | 08:18.56 |
| kens | If it doesn't accept Epson ESC/P then you can write a Ghostscript device (if you know enough about the format). Otherwise, as I said, if Google doesn't turn something up, you;re out of luck | 08:19.57 |
| chrisl | t4nk869: do you know if cups supports your printer? | 08:21.04 |
| kens | chrisl are you going to look at #695508 ? I'm pretty sure the reference to #694573, comment 2, is bogus | 08:21.09 |
| chrisl | kens: I hadn't seen it - and certainly not in any hurry about it | 08:23.12 |
| kens | Yeah, it sounds ridiculous, and certainly doesn't look like a bug in GS to me | 08:23.36 |
| t4nk869 | no, I have no printer, I'm creating, I have a head dx5 and a control board. I need to convert an image into bits for each channel. (CMYK). | 08:26.11 |
| kens | t4nk869 : its not at all clear what you actually want. Ghostscritp canproduce output in all kinds of format, if none of those are suitable for your needs (which are entirely unclear) then you either need to write a Ghostscript device yourself, or wrie something to convert the image data you do have into whatever it is you need. | 08:27.47 |
| t4nk869 | Anyone is capable of doing this? even paying! | 08:29.43 |
| kens | Its not obvious what you need. | 08:30.05 |
| t4nk869 | Create a driver for my card which has an input image and output a binary file to be sent to my card. | 08:33.42 |
| mlen | Hi everyone! I'm looking into http://bugs.ghostscript.com/show_bug.cgi?id=695459 Where can I find documentation on how clists work? | 08:34.26 |
| | Especially on clist_playback_band function :) | 08:34.37 |
| kens | You haven't told us what format the 'binary file' needs to be in. In any event, we aren't likely to do it (though you can ask sales@artifex.com for a quote) | 08:34.45 |
| | mlen, its internal, not documented, you aren't supposed to play with it | 08:34.55 |
| | chrisl there is something odd happening in 695508, Distiller and Jaws both render the delta symbol in doc.ps, no idea why GS doesn't atm | 08:38.41 |
| t4nk869 | ok thanks | 08:39.51 |
| chrisl | kens: okay, I'll take a look at it.... | 08:41.29 |
| kens | Ah, it looks like the problem is font naming. THe EPS file asks for a font called Symbol, but does not include it. If we run that file alone, then we load our replacement font standardSymL. | 08:41.37 |
| chrisl | It says that in the bug report, doesn't it? | 08:42.10 |
| kens | In doc.ps however, the same font (Symbol) is requested, but in this case we have *alread* loaded a font called standardSymL, and *this* version of standardSymL doesn't have a delta symbol | 08:42.15 |
| | the bug report tdoesn't mention Symbol | 08:42.26 |
| chrisl | Ah, so it's the way our substitution works? | 08:42.55 |
| kens | In essence, yes | 08:43.03 |
| | Because we already have an ninsgtance of the named substitute font loaded, we don't load a new one (well, we can't!) so we ujse the existing one, with the missing glyph. | 08:43.37 |
| | I strongly suspect that if I change the name of standardSymL in the doc.ps file to Symbol, then the same result will happen on all rips. | 08:44.05 |
| chrisl | I'll need to tweak it so it undefines the original substitute font | 08:44.11 |
| kens | I'm not inclined to accept this as a bug personally | 08:44.17 |
| | chrisl, that would be bad if we then use the embedded font afterwards | 08:44.39 |
| chrisl | Huh? | 08:45.09 |
| kens | SOrry, I thought you meant undefine the exsiting standardSymL when doing a substitution for Sumbol | 08:45.29 |
| mlen | kens: I see. The thing is that it is a source of rangecheck error I'm trying to debug and it's kind of hard to do that without understanding what happens there. I figured out that's an interpreter, however I'm not sure where it reads the data from | 08:45.44 |
| kens | mlen, it reads the data from the clist, which is usually a file | 08:46.07 |
| chrisl | kens: Oh, right, well I think there's nothing we can do then | 08:46.24 |
| kens | chrisl, that's my opinion, yes. | 08:46.34 |
| | The fault is the missing font | 08:46.41 |
| chrisl | God, how the hell are we going to explain that...... | 08:47.33 |
| kens | I was sitting here stariung at the bug report trying to come up with an explanation | 08:47.56 |
| chrisl | I think possibly just a "time line" of what happens in the file | 08:48.38 |
| kens | I'll let you tackle it, I have to go back up a computer. I'll be back shortly | 08:49.02 |
| chrisl | OKay | 08:49.10 |
| mlen | kens: do you know where that file gets written? | 08:49.52 |
| chrisl | mlen: look in the base/gxcl*.c files | 08:50.24 |
| mlen | I will, thanks | 08:51.40 |
| chrisl | mlen: tbh, the clist is essentially voodoo, and not many people understand how (or even why!) it works..... | 08:52.36 |
| kens | Still, someone else who understands it would be nice :-) | 08:55.57 |
| kens | is trying to stay away from it | 08:56.06 |
| chrisl | kens: can you remember the document that outlines the font subset name prefix "requirement"? | 09:07.33 |
| kens | Not offhand, isn't it in the PDF reference ? | 09:07.47 |
| | I'll see if I cna find it | 09:07.52 |
| | Hmm, the PDF Reference isn't very helpful | 09:09.21 |
| chrisl | Hmm, I thought it was a separate doc specifically about font embedding, as I thought it applied to PS as well | 09:09.43 |
| kens | COUld be, I'm still looking (I have a lot of files to look through) | 09:10.07 |
| chrisl | It is mentioned on page 419 of the 1.7 spec | 09:10.52 |
| | Section 5.5.3 Font Subsets | 09:11.08 |
| kens | yeah but not in much detail (I had already found that bit) | 09:11.31 |
| | the implementation note is useless | 09:11.48 |
| | Doesn't seem to be in any of the tech notes I have here, not even the one with the guidelines on font embedding :-( | 09:13.11 |
| chrisl | No, which is the doc I *thought* it was in | 09:13.47 |
| kens | Well, I can't find anything useful in any of the specs. | 09:16.13 |
| chrisl | No, ah well :-( | 09:16.27 |
| | kens: I do have an idea how we might "fix" this....... | 09:19.08 |
| kens | Hmm, OK how ? | 09:19.19 |
| chrisl | If we're in the process of substituting for a font, we should only (re-)use a font loaded from "disk" | 09:19.58 |
| kens | OK well that makes sense. There's no possibility we end up with 2 fonts with the same name ? | 09:20.37 |
| chrisl | Well, yes, there is still a possible clash, but I think there always will be | 09:21.22 |
| kens | Well as long as its no worse than now it can't be a problem. | 09:21.55 |
| chrisl | If the file in this bug then carried on to use StandardSymL *after* the eps, we could end up using the disk based font, rather than the embedded one. It will depend on the sequence of save/restores that occur | 09:23.10 |
| kens | Well that was my worry, I can't see a way to have two dfifferent standardSymL fonts loaded, one which is a substitute for Symbol, and one which isn't | 09:23.45 |
| chrisl | It can't be done safely - tbh, I'm not inclined to try to address it. I don't think this is a bug | 09:25.38 |
| kens | THat's pretty much what I said earlier :-) | 09:25.52 |
| | The bug is the failure to embed a font really. | 09:26.17 |
| | I know technically you don;t have to include the base 14, and indeed if they didn't then include the URW font it wouldn't be a problem | 09:26.44 |
| chrisl | Well, I'm not impressed with embedding a subset without a name prefix.... even in a PS file | 09:27.09 |
| kens | Yep, its guaranteed to cause problems. | 09:27.24 |
| | IMO just write up the explanation in case nayhone comes looking another day, and close it as invalid or wontfix | 09:27.47 |
| | Oh great, the cat's just brought a mouse in, and now its vanished somewhere in the kitchen..... | 09:38.57 |
| chrisl | And now the cat's lost interest? | 09:40.17 |
| kens | Oh no, the cat's still interested OK | 09:40.27 |
| | After all, its still moving (or at least, it was) | 09:40.50 |
| | I may have to let him back into the kitchen to locate the stupid rodent | 09:41.26 |
| chrisl | Well, I've done my best with 695508...... | 09:44.09 |
| kens | Sorry, was off looking ofr mice | 09:50.06 |
| | Seems reasonable to me. | 09:51.46 |
| chrisl | The problem is, I don't want to give a lengthy master class on Postscript, VM, fonts and font management.... | 10:02.47 |
| kens | No, I agree, I think its a reasonable reply | 10:03.48 |
| henrys | thinks he filtered out all the real mail this morning... | 13:58.26 |
| kens | THere was a load of spam :( | 13:59.07 |
| jogux | Iâm hoping Ron wakes up soon and fixes it (or tells us how to) | 13:59.47 |
| | we wanted the picsel support emails forwarding to sos, but he seems to have forwarded /all/ picsel.com email. | 14:00.31 |
| henrys | jogux: it looks like there was one real user problem in the mix. | 14:00.33 |
| kens | I'm seeing about 40 spam emails so far | 14:00.39 |
| jogux | henrys: thereâs 4 | 14:00.40 |
| | (that Iâve found so far) | 14:00.48 |
| kens | Indeed, I extracted the real ones | 14:00.50 |
| jogux | henrys: quick back of envelope calc says weâve ignored about 1,000 support emails. | 14:01.20 |
| | plus 4 ;-) [assuming theyâre arrived at about the same rate for the last 9 months] | 14:02.06 |
| henrys | jogux: well a little googling about and they should find the support forum, but I guess that's too much for some users | 14:09.37 |
| jogux | henrys: yeah. obviously the âemail usâ form is much easier to find :-S | 14:10.11 |
| henrys | jogux: but after no response I would expect them to find the forum. It isn't at all unusual for a software company, not to say it's good and we can do better, but it's curious they aren't finding the forum. | 14:13.09 |
| jogux | henrys: yeah. with that number of emails, youâd think slightly more would find the forum than have. | 14:13.56 |
| | I suspect many just go to âjust leave a bad review on app storeâ and move on. | 14:14.08 |
| tor8 | jogux: "forum"? is that, like, um, some, like facebook app? | 14:14.23 |
| jogux | :) | 14:14.30 |
| henrys | how are your teeth tor8 you may need them for this meeting. | 14:16.00 |
| | ? | 14:16.03 |
| tor8 | henrys: uh oh, that sounds ominous | 14:16.14 |
| henrys | tor8: just kidding ... | 14:16.36 |
| tor8 | henrys: you never know, what with the SOT gorilla in the room next door... | 14:16.57 |
| Robin_Watts | henrys: Is this the meeting in 14 mins, or a different meeting? | 14:18.25 |
| henrys | Robin_Watts: I was joking with tor8 I know how he always likes his teeth in good shape for the meetings and he did says he went to the dentist.... There is a tuesday technical meeting in 10 minutes - item 1 was emailed and the next meeting will be chicago | 14:19.52 |
| | all ^^^ | 14:20.17 |
| Robin_Watts | henrys: D'Oh. Of course. | 14:20.21 |
| henrys | and a skype meeting in 40 minutes | 14:20.39 |
| tor8 | henrys: re, the email. I did take a (very) brief look at that code when it was first released. | 14:20.46 |
| | unfortunately, I can't remember what my conclusion was... | 14:22.00 |
| jogux | henrys: I did notice that item 1 doesnât seem to be available for iOS/Android. | 14:22.29 |
| henrys | tor8: okay it looks a little active not on fire ... but it may just be right ;-( | 14:22.30 |
| | jogux: oh I didn't even know you were on tech ... | 14:23.44 |
| | tor8: do you still use the chromebook? | 14:24.29 |
| jogux | henrys: yeah. I forget why :) It doesnât get much traffic. | 14:25.02 |
| tor8 | henrys: yes. | 14:26.04 |
| henrys | tor8: I was reading you can now run android apps, was curious what that was like without a touch screen | 14:27.12 |
| tor8 | henrys: I haven't tried that yet. Some of the chromebooks have touch screens though... | 14:27.44 |
| rayjj | some of the laptops and chromebooks that don't have touch screens now have multi-touch touchpads | 14:28.45 |
| chrisl | henrys: the article I read said it was flaky for a lot of apps because of all the regular Android "services" not being available | 14:28.49 |
| rayjj | (even my 2 yr old laptop does) | 14:29.19 |
| Robin_Watts | tor8 doesn't use chromeos on his chromebook, right? | 14:30.04 |
| marcosw1 | morning | 14:30.12 |
| rayjj | maybe tor recalls what Raph went through with his teeth coming back from Japan | 14:30.20 |
| tor8 | Robin_Watts: I do. I use 'crouton' to get a debian environment inside chromeos | 14:30.33 |
| henrys | in keeping with custom we'll cancel next Tuesday's meetings, I'll be in chicago. Heading out Saturday. | 14:31.20 |
| | tor8: if you don't have a mupdf can you send me release notes? Miles wants the newsletter writeup before Chicago. | 14:32.10 |
| tor8 | Robin_Watts: I've got a handful of commits on tor/master needing review, including release notes for the upcoming 1.6 | 14:33.00 |
| Robin_Watts | looking now. | 14:33.14 |
| henrys | also a great time to review the agenda for addtions, corrections etc.,. | 14:33.41 |
| henrys | thinks workflowy is severely deficient in this regard. Seeing changes would be really nice - insteap of plowing through the whole mess every time. | 14:34.35 |
| Robin_Watts | henrys: Twiki? | 14:35.02 |
| | tor8: find_max_cpt ? | 14:35.32 |
| henrys | Robin_Watts: somethng ... | 14:35.47 |
| Robin_Watts | looks like an empty static function is left in the cmap commit. | 14:35.53 |
| tor8 | Robin_Watts: eh, oops! | 14:36.20 |
| Robin_Watts | henrys: Sorry, I'll expand... Now we have a twiki, we could perhaps do the workflowy thing in that. | 14:36.28 |
| | That does versioning etc, would allow us to fork etc. | 14:36.39 |
| | fork is wrong. Subdivide down to separate project pages etc. | 14:36.56 |
| henrys | Robin_Watts: yea, I do like the intelligent outline editiing - users don't see that but it is nice. | 14:38.05 |
| | but twiki would probably be better for all. | 14:38.35 |
| tor8 | Robin_Watts: re-fetch | 14:38.53 |
| mvrhel_laptop | sorry I am late | 14:39.00 |
| henrys | mvrhel_laptop: how's xps miles wants you to stop that craziness and get back to the real action ;-) | 14:39.46 |
| Robin_Watts | tor8: All look good. The change log looks lighter than usual, but I guess we're down to a 1/3 of the manpower this time. | 14:39.48 |
| henrys | mvrhel_laptop: the fork in the eye action that is. | 14:40.02 |
| tor8 | Robin_Watts: yeah. the 1.5 changelog was the lightest ever though! | 14:40.05 |
| mvrhel_laptop | henrys: yes I will wrap this up in two days. I have what I want | 14:40.19 |
| tor8 | and we've still been in mostly bug-fixing mode, and I've been working on branches that haven't been merged for the new viewer | 14:40.35 |
| Robin_Watts | gsview? | 14:40.54 |
| tor8 | Robin_Watts: no, a refresh of the bare bones desktop viewer | 14:41.08 |
| Robin_Watts | oh, right. are we still doing that? | 14:41.18 |
| tor8 | to eventually get it to do forms and interactivity properly | 14:41.22 |
| henrys | mvrhel_laptop: interestingly the xpdf folks recommend a product for printing on windows - it might be a lot better than we can do. It will just print a pdf file. | 14:41.24 |
| tor8 | yeah, in the background when I'm not fixing bugs or working on epub | 14:41.32 |
| Robin_Watts | I thought with gsview and fredross-perry's stuff that was going to be on hold. | 14:41.37 |
| | but OK. | 14:41.42 |
| henrys | mvrhel_laptop: if it handles fonts, it will be better than we can do ;-) | 14:41.46 |
| tor8 | Robin_Watts: I still want it to be out there; if nothing else for my own use :) | 14:41.56 |
| | the gsview and qt-based viewers are c++, and you know my feelings about that | 14:42.25 |
| Robin_Watts | Should gsview be mentioned in the changelog? | 14:42.40 |
| | It is, ignore me. | 14:42.48 |
| tor8 | Robin_Watts: I'm not sure, as it isn't built by default. but I figured we could mention it. | 14:43.03 |
| mvrhel_laptop | henrys: I am curious how the proint pdf flow works with the xpdf code | 14:43.52 |
| | s/proint/print | 14:44.02 |
| rayjj | tor8: robin_watts: should we change the default build on mupdf to be the release rather than the debug build ? | 14:44.06 |
| | people downloading the sources and building now get the default as 'debug', so it will be slower than desired | 14:44.46 |
| tor8 | rayjj: good point. | 14:45.07 |
| Robin_Watts | tor8: cbz ordering fix. zip64 fixes. ios and android bugfixes. | 14:45.23 |
| henrys | that was it for today except to review your items on the agenda. If you have an item that is captured in the bug review let's get it off the agenda as a dup. I might give it a once over also for that duplication if I have time before the meeting. | 14:45.42 |
| Robin_Watts | One thing before we go... | 14:46.02 |
| henrys | well that's it for me. anybody else? | 14:46.05 |
| mvrhel_laptop | nothing form me. I will have some code for you to review maybe later today henrys | 14:46.22 |
| Robin_Watts | I'll mail round a location to get the latest smart office build for android. | 14:46.25 |
| | If people could give it a quick whirl, we'd be grateful. Looking for bugs before we release. | 14:46.44 |
| | Testing on as many android devices as possible would be appreciated. | 14:47.03 |
| mvrhel_laptop | Robin_Watts: do you know if we ever figured out that weird ui delay issue I was having on the nexus 10. recall we looked at it at the staff meeting | 14:47.19 |
| tor8 | it does give us more pain, but it's easy enough to work around locally | 14:47.24 |
| henrys | I'll start charging mine, Robin_Watts | 14:47.30 |
| tor8 | henrys: epub on the agenda? | 14:47.37 |
| Robin_Watts | mvrhel_laptop: SOT or MuPDF ? | 14:47.39 |
| mvrhel_laptop | sot | 14:47.43 |
| Robin_Watts | I have to say, I have no memory of that. | 14:47.57 |
| tor8 | Robin_Watts: updated CHANGES on tor/master now | 14:48.07 |
| mvrhel_laptop | ok. well we can look at it again at the staff meeting | 14:48.13 |
| Robin_Watts | but that's probably just me being crap. | 14:48.18 |
| | mvrhel_laptop: It *might* be related to soft threading. | 14:48.28 |
| jogux | robin: *cough* skype *cough* | 14:49.23 |
| | donât want to give our competitors hints how to fix things :-) | 14:50.22 |
| Robin_Watts | logs edited :) | 14:50.46 |
| jogux | ta :) | 14:50.52 |
| Robin_Watts | mvrhel_laptop: In code then, to avoid giving anything away... | 14:51.06 |
| | "Should I bring Tea to the staff meeting?" | 14:51.14 |
| jogux | tea easy to get hold of. itâs proper milk Americanâs seem to skip on. (I may not have cracked your code.) | 14:51.45 |
| mvrhel_laptop | robin_watts one box would be great | 14:52.22 |
| Robin_Watts | no, even the same brand of tea in the US is inferior. I do an international drug run for michaels wife :) | 14:52.36 |
| | mvrhel_laptop: Sure. | 14:52.42 |
| marcosw1 | was someone having a package sent to my house that I was supposed to bring to the meeting? I don't recall having anything arrive... | 14:52.43 |
| Robin_Watts | marcosw1: In theory, I was, but the kickstarter seems to have slipped. | 14:53.05 |
| | Actually, you might get a box of quickeys. | 14:53.26 |
| marcosw1 | np, just wanted to make sure nothing had arrived that had been misplaced. | 14:54.05 |
| jogux | robin_watts: ahhh :-) | 14:54.20 |
| | oh. hmm. I was still thinking about trying to get the thermal camera thatâs only available in the USA | 14:54.49 |
| Robin_Watts | marcosw1: Supposedly the quickeys should have shipped 11 days ago. | 14:55.19 |
| marcosw1 | robin_watts: that's ominous. Do you have any tracking information (i.e. does the shipping agent think they've been delivered)? | 14:57.24 |
| chrisl | Blimey, marcosw1, Bug 695502 may be more easily reproducible, but stone me, what a horrid bug to track down!! | 14:58.47 |
| marcosw1 | chrisl: I was expecting someone to tell me that BGPrint isn't supported for GhostPCL :-) | 15:00.25 |
| chrisl | marcosw1: even if that were true, the same problem could/should arise with Ghostscript and clist memfiles | 15:01.22 |
| kens | I wonder why I haven't seen email for that commit yet..... | 15:01.53 |
| chrisl | Which commit? | 15:02.05 |
| kens | THe one in bug695502 | 15:02.16 |
| | Oh its on your repo | 15:02.31 |
| chrisl | yes, just typing that..... | 15:02.39 |
| kens | I didn't read the URL carefully enough :-) | 15:02.52 |
| | I assume you want Ray to check it over ? | 15:03.30 |
| chrisl | Well, the bug is assigned to him | 15:03.40 |
| kens | Fair comment | 15:03.49 |
| chrisl | I just figured as I'd been messing in that area this week, it made sense to plough on | 15:04.22 |
| Robin_Watts | marcosw1: Have mailed the campaign to ask. | 15:04.28 |
| kens | Well threading problems are often a nightmare to debug :-( | 15:04.41 |
| chrisl | This wasn't really a threading problem...... | 15:05.09 |
| kens | I guess not, I'm surprised it didn't show up more. | 15:05.32 |
| | Or was it masked previously ? | 15:05.44 |
| chrisl | I suspect that the chunk allocator doesn't do much checking for this kind of error | 15:06.33 |
| kens | Ah.... | 15:06.39 |
| chrisl | In case, it needed the chunk allocator instance to still be active, but not be managing any memory - then you try to give it some back, and it crashed | 15:08.46 |
| | I need to run to the post office - back in 20 mins..... | 15:10.12 |
| rayjj | chrisl: sorry -- I was closing a bug. | 15:11.00 |
| rayjj | reviews the logs and the bug... | 15:11.15 |
| | chrisl: Thanks for tracking that down. I do see a minor typo in a comment: | 15:20.23 |
| | /* Note that in the case of back ground printing, we only was to close the instance */ should be: | 15:20.24 |
| | /* Note that in the case of back ground printing, we only want to close the instance */ | 15:20.26 |
| rayjj | hopes that /* isn't a IRC command of some sort :-) | 15:20.56 |
| pedro_mac | rayjj: looks like youâre safe ;) | 15:21.21 |
| rayjj | pedro_mac: thanks (I wasn't sure my comments made it through) | 15:21.42 |
| | chrisl: the commit LGTM. Thanks again. | 15:22.20 |
| | chrisl: actually, I do have a suggestion: when you fclose the ocfile, you potentially wipe out the bg_print->return_code set earlier, and the same when you fclose the obfile. I suggest logic to preserve any return_code < 0 (i.e. only replace it if bg_print.return_code == 0) | 15:37.51 |
| | chrisl: of course, setting it to 0 again won't hurt if the fclose returned 0. | 15:38.15 |
| chrisl | rayjj: oh, good point, I'll change that..... | 15:38.50 |
| rayjj | chrisl: and there seems to be a plethora of blank lines (just a style issue, no biggee) | 15:38.51 |
| | chrisl: I've pulled in the patches and am going to try it with the performance file I have from bug 695374 (it was crashing before with -dBGPrint=true) | 15:40.41 |
| mvrhel_laptop | ugh. I hate health insurance companies. trying to straighten out a charge and it is taking 10 minutes for them just to "pull" up my information | 15:42.15 |
| Robin_Watts | Training, day 1: The hold button is your friend. Put them on hold straight away, as it takes some of the fight out of them. | 15:42.59 |
| mvrhel_laptop | now it turns out this guy was not "trained" for I needed | 15:44.02 |
| | now back on hold.... | 15:44.06 |
| rayjj | robin_watts: actually, it make me more eager to fight | 15:44.21 |
| Robin_Watts | rayjj: I understand. please hold. | 15:44.36 |
| rayjj | hehe | 15:44.47 |
| | robin_watts: I'll talk to me supervisor and see what I can do for you. I'll be right back... | 15:45.26 |
| chrisl | rayjj: Revised commit: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=6d44e2f0 | 15:50.35 |
| rayjj | chrisl: there's still an extra blank line at the end of the bg_print_s struct that I don't see the value of, but the 'closecode' logic you added LGTM. go ahead (with or without the blank line), its fine with me. | 15:53.03 |
| | chrisl: and I confirm that it no longer crashes the way it did with my test | 15:53.37 |
| chrisl | rayjj: ah, I just missed that blank line 'cause it was off the bottom of the editor window! | 15:54.22 |
| | rayjj: and there was also this one for the last of the Ghostscript seg faults: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=2507c951 | 15:55.26 |
| rayjj | chrisl: strange, but since I was running performance for my previous test, even without -dBGPrint=true, the performance dropped from 13.2 sec to 17.0 seconds. I went back and forth twice, rebuilding each time. It's the parse time that is getting worse !!! | 16:01.07 |
| | I ran each 3 times, and took the best time. Also, the modified version is more variable | 16:01.51 |
| | the args I used were: -dNumRenderingThreads=2 -Z: -sDEVICE=bit -r600 -dMaxBitmap=0 -dBandBufferSpace=8m -dBandHeight=1500 -sOutputFile=nul: -dNOPAUSE c:/temp/25pages.pcl | 16:02.21 |
| chrisl | That seems very odd..... | 16:02.39 |
| rayjj | chrisl: where the 25pages.pcl is the test file from bug 695374 | 16:02.40 |
| | chrisl: I agree -- I can't see why it would make a difference (and such a large difference) | 16:03.13 |
| | chrisl: did you verify that the clist memfiles get freed in all cases ? Even when BGPrint is not used ? | 16:04.13 |
| chrisl | rayjj: as far as I know, the non-BGPrint behaviour should be the same | 16:04.49 |
| | Without BGPrint we should reuse the clist memfiles, shouldn't we? | 16:05.13 |
| rayjj | I haven't tried on linux | 16:05.32 |
| | chrisl: can you try those args on your machine (before and after your patch) ? | 16:06.47 |
| chrisl | I'm just searching for that file now.... | 16:07.09 |
| rayjj | in case I didn't pull in your patch correctly | 16:08.35 |
| | chrisl: If you want I can send you the file, but it is on peeves.ghostscript.com:~norbert/20140721_profiledata/25pages.pcl | 16:09.50 |
| chrisl | I've got the file - I did some of the initial investigations on that bug | 16:10.11 |
| henrys | marcosw1: did you only set up dns on macpro or do you have a login for henrysx6 also? | 16:12.36 |
| rayjj | wishes (again) for a decent profile tool for Windows. | 16:12.49 |
| henrys | marcosw1: not dns exactly but you know what I mean | 16:12.57 |
| rayjj | chrisl: I've gotten as low as 16.3 seconds for the run with the patch (tried 10 times), but I've gotten a pretty consistent 13 seconds without it) | 16:15.43 |
| chrisl | rayjj: I get near enough the same time using my branch and master - if anything, my branch may be a tiny bit quicker. Master is coming in at 23.8, and my branch 23 seconds | 16:17.00 |
| rayjj | chrisl: OK. I must have messed up the cut and paste of the patch. | 16:17.28 |
| | can you send me a format-patch (or pastebin it) ? | 16:17.46 |
| chrisl | rayjj: couldn't you just pull if from my repo? | 16:17.52 |
| | rayjj: actually let me just re-run - I just noticed you're using "nul:" rather than "/dev/null" | 16:19.23 |
| rayjj | chrisl: right. I'm a windoze-weenie most of the time :-) | 16:20.12 |
| chrisl | rayjj: maybe should have the gp_unifs.c special case "nul:"..... | 16:22.19 |
| pedro_mac | sends rayjj 400,000 USD for a Rational Quantify licence ;) | 16:23.09 |
| rayjj | chrisl: actually, I think the 'bit' device does the special case | 16:23.12 |
| | chrisl: int nul = !strcmp(pdev->fname, "nul") || !strcmp(pdev->fname, "/dev/null"); | 16:24.10 |
| chrisl | rayjj: okay, this time using "/dev/null", master gives me 21.6 seconds, and my branch gives 21.8 both averaged over four runs. | 16:25.20 |
| zeniko | tor8: (for the logs) your fix for bug 695501 doesn't seem to fix the case of malicious documents | 16:26.53 |
| | if both low and high are within the used ranges but low > high, you'll still wrap around all the way | 16:27.34 |
| | and if the required ranges contain huge holes, there won't be much to cap | 16:28.17 |
| | (also, you don't seem to take usecmap into account) | 16:29.34 |
| rayjj | chrisl: How do I pull the patch from your repos (without messing mine up) ? | 16:30.08 |
| chrisl | rayjj: I've mailed the two commits I'm testing - let me know if gmail strips the zip off | 16:30.27 |
| rayjj | on my linux vm (before your patch) I've gotten 12 seconds. | 16:30.56 |
| | chrisl: I've applied the patches to my linux vm, and get very close to the same times. Trying windoze now... | 16:38.55 |
| | chrisl: windows is _still_ slow!! The best I've gotten is 15.3 sec (vs. 13.1) | 16:43.24 |
| chrisl | Erm...... | 16:45.02 |
| | rayjj: is memory use any higher? | 16:46.19 |
| rayjj | chrisl: not noticeably. With the task manager, they both hover around 20M | 16:48.23 |
| | chrisl: I'm going to see if I can get this to profile. It's quite disturbing, particularly since norbert runs windows | 16:50.01 |
| chrisl | rayjj: I'm bemused..... | 16:50.55 |
| rayjj | chrisl: me, too | 16:52.55 |
| chrisl | rayjj: when you did your "before" test, was it with up to date master code? | 16:54.43 |
| rayjj | chrisl: yes, but both with a trivial patch of mine to allow me to see parse vs. render time. See: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=75a183ff51daebf8c3835f3d6e5107d70061a8ce;hp=98b066aad13281ce75471163959db727a5a9da58 | 16:57.40 |
| | chrisl: but _both_ versions have that. | 16:58.43 |
| | chrisl: and I just added that to my linux version and it didn't change the timing | 17:02.32 |
| chrisl | rayjj: no, I really wouldn't expect so..... | 17:03.10 |
| rayjj | henrys: do you have any objections to the change a couple of lines above ? It adds 'parse done: ...' time and changes 'done: ...' to 'render done: ...' | 17:07.11 |
| henrys | rayjj: fine for me | 17:07.51 |
| rayjj | it showed me why NumRenderingThreads=4 doesn't really help norbert's file | 17:07.54 |
| | henrys: thanks | 17:07.57 |
| henrys | rayjj: oh #ifdef DEBUG if it's per page | 17:08.31 |
| chrisl | rayjj: the only thing I can see that might have an influence is the change to use the thread_mem for the gs_getdeviceparams() in setup_device_and_mem_for_thread() - that should cause us to lock/unlock a mutex a few more times per page, but I wouldn't have thought it would make that much difference | 17:10.31 |
| rayjj | henrys: ??? what do you mean? I didn't change that. It did each page previously | 17:10.33 |
| chrisl | henrys: Ray's change is in the -Z: output | 17:11.08 |
| rayjj | chrisl: if it's only a few times, fine. But mutexes on windoze are S...L...O...W... | 17:11.22 |
| henrys | oh right sorry | 17:11.45 |
| | you want that in production code | 17:11.57 |
| | d'uh | 17:12.06 |
| rayjj | henrys: right -- performance of release code is often of more interest | 17:12.42 |
| | henrys: and the 'done:...' output with -Z: was there previously for release code | 17:13.19 |
| | per page | 17:13.29 |
| chrisl | rayjj: I can look at this more tomorrow, I need to head out soon...... but if you want to try a quick test, line 104 in gxclthrd.c, and change "thread_mem" to "dev->memory" | 17:13.50 |
| rayjj | I use a little awk script to give me the total parse and render times :-) | 17:13.55 |
| | chrisl: OK. I'll try that | 17:14.14 |
| henrys | bbiaw | 17:17.00 |
| rayjj | chrisl: sorry, doesn't make any difference. I didn't think it would because it wasn't part of the patch that I had | 17:17.54 |
| chrisl | rayjj: I would have been surprised if it did make a measurable difference even on Windows, but it was all I could think of | 17:18.40 |
| rayjj | chrisl: I'll see if I can get a profile build and get it working for very sleepy | 17:18.46 |
| chrisl | rayjj: no, let me have another look tomorrow - I kept looking at this as I figured you had enough else going on | 17:19.32 |
| fredross-perry | HI all. Iâm ready to look into converting PS/EPS and XPS to PDF. I got and built ghostpdl (should I?) and found gxps, with which I can create PDF from XPS. Where do I get gs? thanks | 17:20.04 |
| chrisl | fredross-perry: in the ghostpdl repo, there is a "gs" directory, ghostscript is in there | 17:20.40 |
| | fredross-perry: the ghostpdl (pxl/pcl and xps) are separate from the gs one (for now, anyway) | 17:21.46 |
| fredross-perry | oh i see. not built. sigh. | 17:23.29 |
| chrisl | fredross-perry: bringing the builds together is my current project..... when I get a chance to look at it...... | 17:24.20 |
| | rayjj: Right, unless I hear different, I'll brave the world of Windows tomorrow, and see if I can see any likely candidates for the performance difference | 17:30.01 |
| | Hmm, I wonder if building for Cygwin would yeild the same | 17:31.11 |
| | yield the same disparity | 17:31.19 |
| | Argh, have to go.... | 17:31.32 |
| fredross-perry | gs build error. missing symbols _iconv, _iconv_close, _iconv_open. I got the same yesterday with downloaded 9.15. Thoughts? OS X with XCode command line tools. | 17:36.23 |
| rayjj | fredross-perry: did you do ./autogen.sh in the gs directory ? | 17:36.49 |
| fredross-perry | yes, and subsequent ./configure | 17:37.07 |
| rayjj | fredross-perry: if you do ./autogen.sh it does the configure | 17:37.36 |
| fredross-perry | ok. and yet... | 17:38.07 |
| rayjj | fredross-perry: but the one in the ghostpdl directory doesn't do the one in the gs directory | 17:38.24 |
| fredross-perry | got that. I did autogen, then configure, then make, all in the gs directory. | 17:38.51 |
| rayjj | fredross-perry: henrys has macOSX | 17:38.55 |
| | and since I mentioned him, his highlight should wake him up :-) | 17:39.46 |
| | errand ... | 17:45.55 |
| jogux | fredross-perry: does this help âNOTE: If you have MacPorts (http://www.macports.org/) installed, it can "confuse" the configure script because it includes some librares which duplicate the "system" ones. This can cause missing symbol link errors. In order to resolve this, you can do: LDFLAGS="-L/usr/lib" ./configure. That will force the linker to search the default directory first, and thus pick up the system libraries first.â ? | 17:59.40 |
| fredross-perry | I probably do have macports installed. Iâll remoe it and see whatgives. | 18:00.24 |
| jogux | you could try that LDFLAGS working, thatâs quicker :-) | 18:00.40 |
| | s/working/workaround/ | 18:00.49 |
| fredross-perry | well, removes macports and now I am missing autoconf. Sigh | 18:13.39 |
| | OK, âLDFLAGS="-L/usr/lib" ./configureâ allows me to build gs. But when I launch it Iget âdyld: Library not loaded: /opt/local/lib/libcairo.2.dylibâ | 18:34.31 |
| | what I want to accomplish is building a standalone gs that gsview can carry, and launch to do conversions. Iâd rather it not rely on dynamic libs. | 18:35.39 |
| mvrhel_laptop | fredross-perry: so right now gxps does not have an API like gs has | 18:53.05 |
| fredross-perry | i hacked the gs makefile to build out Cairo, so at least I have something that launches. | 18:53.49 |
| mvrhel_laptop | henrys: what was the reason for gxps and ghostpcl not having an API like gs? | 18:54.16 |
| | I recall chis saying something about them not being thread safe i think | 18:55.14 |
| | anyway grabbing some lunch.. bbiab | 18:56.27 |
| fredross-perry | ok iâve got basic convert-then-open working for PS and EPS using my built version of gs. It looks like the config.mak sstem allows for building in/out devices and features. Can I use that to make something more minimal that only handles PS/EPS in and PDF out? | 19:10.41 |
| Robin_Watts | yes. | 19:11.28 |
| | being called away now, though, sorry. | 19:12.46 |
| | essentially you'll find a load of DEVICES_DEV1 kinda things with lists of devices. | 19:13.02 |
| | You can cut those down to just have pdfwrite, pretty much. | 19:13.17 |
| fredross-perry | not urgent, thanks. | 19:17.59 |
| | going out now too for a while. | 19:18.06 |
| mvrhel_laptop | I think for gsview, we want to have a lot of the devices though. People actually use gsview for conversions. The windoze version has the capability to select a device from the list of the devices available | 19:32.58 |
| fredross-perry | mvrhel_laptop - itâs all good. We can use gs as is and get all the devices. My primary concern is that I can make a gs that does not rely on dynamic libs that might not be there. | 20:18.02 |
| | Forward 1 day (to 2014/09/24)>>> | |
IRC Logs