| | <<<Back 1 day (to 2011/12/15) | 2011/12/16 |
| kens | chrisl can you get to ghostscript.com ? | 08:22.24 |
| chrisl | kens: yes | 08:23.47 |
| kens | Hmm, odd I can't. Must be a DNS problem, I'll keep trying. | 08:24.05 |
| | Oh, now I can.... | 08:24.20 |
| chrisl | Routing problem, then? | 08:24.41 |
| kens | I guess. | 08:24.47 |
| hje841 | Why does my Ghostscript die with signal 11? what does 11 mean? | 14:05.47 |
| kens | crash | 14:05.57 |
| hje841 | from what? | 14:06.20 |
| kens | From a bug | 14:06.24 |
| | Probably | 14:06.48 |
| | Can't say more without seeing the source feil, the command line and knowing the version of GS you are using | 14:07.10 |
| hje841 | http://pastebin.com/Qd0ZC8Rd | 14:07.56 |
| | heres my verbose output | 14:08.03 |
| kens | Doesn't help | 14:08.12 |
| | But that's an out of date versoin of GS, try using 9.04 | 14:08.29 |
| hje841 | okay, never mind then | 14:08.29 |
| | is that packed for Ubuntu? | 14:10.52 |
| kens | I have no idea. | 14:11.00 |
| | But I imagine so | 14:11.08 |
| chrisl | GS 9.04 is used in Oneiric, I don't know if it's available for earlier Ubuntu releases | 14:11.46 |
| kens | In fact thre is (or shortly should be) a patched version of 9.04 for Oneiric | 14:11.49 |
| | Morning mvrhel | 14:57.37 |
| Robin_Watts | tor8: ping | 15:27.03 |
| | In order to help track down these memsqueezing problems, I've added a new thing to memento: Memento_label(ptr, "blah"); which associates the string 'blah' with the block 'ptr'. So when we leak it's easier to see what things are. | 15:28.26 |
| | This means that I'm adding a lot of Memento_label calls to the code. | 15:28.43 |
| | but, a lot of the time I'm seeing code like: | 15:28.54 |
| | foo = fz_malloc(ctx, sizeof(fz_something)); | 15:29.22 |
| | Memento_label(foo, "fz_something"); | 15:29.24 |
| | How would you feel about an fz_malloc_struct macro? so I could do: foo = fz_malloc_struct(ctx, fz_something); | 15:30.15 |
| tor8 | Robin_Watts: something in vein with the fz_malloc_array stuff, but with an implicit sizeof instead? | 15:51.01 |
| | well, now that we've already broken "basic c compatibility" with the introduction of exceptions, why not? | 15:51.40 |
| Robin_Watts | #define fz_malloc_struct(CTX, STRUCT) Memento_label(fz_malloc(CTX, sizeof(STRUCT)), #STRUCT) | 15:51.41 |
| tor8 | i.e. go right ahead! | 15:52.00 |
| Robin_Watts | Fab, thanks. | 15:52.05 |
| tor8 | oh, and change the _array and _resize functions to be the same | 15:52.25 |
| Robin_Watts | fz_malloc_struct_array ? | 15:52.44 |
| tor8 | nah, just _array no need for the old one I think | 15:52.59 |
| | I wonder if we have any 'pure' mallocs left in the codee | 15:53.19 |
| Robin_Watts | I'm confused about what you mean, sorry. | 15:53.35 |
| tor8 | maybe we can get away with just turning fz_malloc into what you propose for malloc_struct | 15:53.37 |
| Robin_Watts | No, I think we still need real malloc for buffers etc. | 15:53.52 |
| | Not all malloc calls are a sizeof | 15:54.00 |
| tor8 | yeah, there are 73 non-sizeof mallocs in the code | 15:54.41 |
| | and 122 sizeof mallocs | 15:54.54 |
| | and 10 non-sizeof malloc_array which could be trivially rewritten to be sizeof(char) | 15:55.57 |
| | or just plain mallocs in the case of pixmaps | 15:56.12 |
| | #define fz_malloc(C,T) (T*) fz_malloc_imp(C,sizeof(T)) -- with the typecast to catch typing typos | 15:56.58 |
| | pardon the pun :) | 15:57.04 |
| | fz_malloc_struct is fine | 15:58.33 |
| Robin_Watts | (sorry, got called to help with dog) | 15:59.02 |
| chrisl | kens: I'd a bit tied up - if I get finished at reasonable time, I'll give you a call | 15:59.05 |
| Robin_Watts | OK. | 15:59.06 |
| kens | OK chrisl | 15:59.37 |
| tor8 | Robin_Watts: and I would like to see fz_malloc|resize_array to follow the same scheme with taking a type as argument. symmetry in the code and all that. | 16:00.28 |
| Robin_Watts | tor8: Now I'm confused again | 16:00.51 |
| | Currently, I'm leaving fz_malloc alone. | 16:01.05 |
| tor8 | fz_malloc_array(ctx, count, T) | 16:01.08 |
| | leave fz_malloc as is | 16:01.13 |
| Robin_Watts | and adding fz_malloc_struct() | 16:01.14 |
| | so the '_struct' suffix tells us to expect a type rather than a size. | 16:01.29 |
| | fz_malloc_struct_array (to my mind) would take types, but fz_malloc_array would take sizes | 16:02.15 |
| tor8 | okay. | 16:02.42 |
| Robin_Watts | But so far I'm not feeling the urgency to add that. | 16:02.44 |
| tor8 | agreed. | 16:02.50 |
| | no urgency there, just a thought I had. | 16:02.58 |
| henrys | kens:sorry for the confusion I thought you and Hintak had provided a mapping from URW name to original font names for all 80 PCL fonts - thus the ones other than the 14 would be handled by the platform. | 16:07.16 |
| | but now I see there is just the mapping for the 14 | 16:07.30 |
| kens | :-) | 16:07.35 |
| | We could opt not to embed substitute fonts, I looked at it briefly for the DroidSansFallback | 16:08.25 |
| henrys | I am wondering if this was done right - do we need the mapping? It looks like there is a "name" member in the font data structure. Isn't that where a correct name could be provided. | 16:11.28 |
| kens | Yes, but we would need to know that we don't want to embed the font | 16:12.12 |
| henrys | I thought the option dictated that. | 16:12.56 |
| kens | Oh yes, if you choose not toe Embed fonts. | 16:13.08 |
| | But that's not the default | 16:13.16 |
| henrys | right | 16:13.43 |
| kens | Was thining maybe we should opt not to embed substitutes | 16:13.58 |
| henrys | right that would fix it in the default build but it would create a surprise for the user. Most folks expect pdf to embed unless told otherwise right? | 16:15.54 |
| kens | Disstilere doesn't I don;t think, for substitutes | 16:16.45 |
| | Well, it doesn't have substitutes in the same way | 16:17.52 |
| henrys | I'm fine with doing that if you want. How would we tell pdfwrite the font is a substitute? | 16:20.13 |
| kens | I'm not sure :-) | 16:20.20 |
| henrys | for PCL that is. | 16:20.22 |
| kens | I only scanned the problem for the CIDFont DroidSansFallback, that was quite easy to detect. | 16:20.43 |
| henrys | let's see what the customer comes back with after marcos asks for the correct files. | 16:21.40 |
| kens | Seems reasonable | 16:21.49 |
| henrys | kens:I copied you in on a customer discussion. | 16:22.04 |
| kens | I was just reading it | 16:22.12 |
| | Loks interesting | 16:23.30 |
| | Looks | 16:23.34 |
| | I think we'll need some examples | 16:24.10 |
| Robin_Watts | tor8: patches pushed. | 16:30.34 |
| tor8 | Robin_Watts: loads of memsqueezing fixes :) | 16:50.51 |
| Robin_Watts | yeah. I'm up to 279 mallocs before it finds a problem :/ | 16:51.22 |
| kens | henrys shall we do a build for John ? | 16:52.20 |
| tor8 | fitz/base_object.c: In function âfz_new_nullâ: | 16:53.32 |
| | fitz/base_object.c:60: warning: statement with no effect | 16:53.32 |
| | Robin_Watts: ^ | 16:53.32 |
| | warnings in no-memento builds there | 16:53.39 |
| Robin_Watts | tor8: damn. will fix. | 16:53.54 |
| henrys | kens:yes I'm afraid that would be the right thing to do, sorry. | 16:54.16 |
| kens | OK, do you know if they are using Windows ? | 16:54.26 |
| tor8 | probably the blank ; left after the no-op macro | 16:54.29 |
| henrys | kens:yes he is. | 16:54.36 |
| kens | OK I'll make a build and send it. | 16:54.44 |
| henrys | It would be nice to have a sevlet on ghostscript.com with txtwrite now that I think about it. | 16:55.14 |
| | I mean servlet | 16:55.34 |
| kens | knows nothing about web programming.... | 16:55.42 |
| Robin_Watts | Memento_label(A,B) turns into just 'A' in a no-memento build. | 16:55.52 |
| | So a standalone call to that results in 'expression;' | 16:56.33 |
| | so the warning is correct. | 16:56.45 |
| henrys | ignore me just stammering aloud... | 16:56.45 |
| Robin_Watts | henrys: So you can upload a ps file and get the text out ? | 16:57.10 |
| | s/ps/ps or pdf/ | 16:57.17 |
| henrys | Robin_Watts:yes | 16:57.25 |
| | rendering would be painful slugging around hi res stuff but text would be light. | 16:57.46 |
| Robin_Watts | If we were doing that, why wouldn't we use mupdf? | 16:57.52 |
| kens | ps or PDF or PCL | 16:58.02 |
| henrys | yeah you guys need to add a postscript and pcl interpreter to that project of yours. | 16:58.30 |
| Robin_Watts | Well, it'd be easy to do a simple webpage to do that. | 17:01.47 |
| kens | Not simple for me ;-) I know nothing.... | 17:02.00 |
| Robin_Watts | It all depends how hardened you want it. | 17:02.06 |
| henrys | we'd want an input size limitation and the interpreter of course would run with the safety options | 17:04.08 |
| Robin_Watts | henrys: Give me the exact command line to use and what input size limit, and I'll see what I can do. | 17:05.00 |
| henrys | what else were you worried about - if there are buffer overflows in gs they can be exploited - I don't see what we could do about that. | 17:05.05 |
| | 10 Meg | 17:05.30 |
| Robin_Watts | henrys: flooding ghostscript.com with requests. | 17:05.36 |
| | I could craft a small postscript file that produces lots of text, then upload that lots of time - and ghostscript.com would sink under the weight. | 17:06.23 |
| | Presumably you'd want a runtime limit too. | 17:06.37 |
| | and an output size limit. | 17:06.47 |
| | And if this starts to get used a lot, you might want a queuing system... | 17:07.08 |
| | there is a world of difference between a quick demo, and something that's suitably 'enterprise'. | 17:07.27 |
| henrys | gs -sDEVICE=txtwrite -o "output?" -dSAFER input | 17:09.31 |
| Robin_Watts | OK. | 17:10.28 |
| henrys | if you only allow 1 upload at a time it is hard to imagine we'd get into trouble unless there was a coordinated attack. | 17:10.48 |
| | I guess if users could highlight a bunch of files and send that would be a problem. | 17:11.13 |
| Robin_Watts | No, the worry is that someone targets you with a botnet. | 17:11.29 |
| henrys | that's a coordinated attach I believe. | 17:12.21 |
| Robin_Watts | yes, sorry. | 17:12.32 |
| | If you only want one user at a time to be able to use the service, that's doable, probably. | 17:12.50 |
| | Getting it to instantly refuse "Sorry, someone else is using the server, please try later" should be easy. | 17:13.30 |
| kens | That sounds good to me | 17:13.47 |
| Robin_Watts | Getting it to wait in a queue is harder. | 17:13.48 |
| henrys | if it gets abused we'll pull it down quickly. It'll be interesting to see what sort of folks use it. | 17:13.56 |
| | there's the man with a lot of customers. | 17:16.39 |
| | off to the coffee shop bbiaw | 17:25.10 |
| kens | marcosw_ Shall I send you the binary to send to the customer, or send uit myself ? | 17:25.55 |
| chrisl | kens: just finished - way longer than I expected. So talk to you next week? | 17:26.23 |
| kens | Yes, no problem. | 17:26.31 |
| | I'm building a release Windows binary from current code now :-( | 17:26.43 |
| mvrhel | marcosw_ : hate to keep asking you. did you run the plank device with the planar halftoning on? | 17:29.44 |
| marcosw_ | yes, I'll send you the results. | 17:34.50 |
| | kens: could you send it directly to the customer? | 17:35.14 |
| kens | I'm doign that now :-) | 17:35.21 |
| mvrhel | ok thanks | 17:35.24 |
| Robin_Watts | tor8: warnings fixed (and more memsqueezing stuff too) | 17:37.19 |
| kens | marcosw_ henrys, mail has gont to customer, and now I'm off. Please keep an eye out for any replies. I will be back in the morning if there are any issues you need me to look at. | 17:41.56 |
| | Goodnight all | 17:42.12 |
| mvrhel | Robin_Watts: so I am puzzled by some of the numbers that marcos had on the report | 18:17.21 |
| | I don't know why some of the pdf files would be slower | 18:17.35 |
| | the fact that he is not going to /dev/null would that make us incur a larger cost on the planar results? | 18:18.09 |
| Robin_Watts | Yes. | 18:18.28 |
| mvrhel | ok. I guess then, we are interested in the case out to /dev/null | 18:18.49 |
| Robin_Watts | because we have to planar->chunky the results to write them out. | 18:18.51 |
| mvrhel | yes | 18:18.54 |
| | that was what I was thinking | 18:18.58 |
| | not very fair | 18:19.02 |
| Robin_Watts | Let me just check to see if the code is smart enough to avoid that in the /dev/null case. | 18:19.11 |
| mvrhel | ok thanks | 18:19.38 |
| Robin_Watts | yes, /dev/null or nul: are special cased. | 18:20.33 |
| mvrhel | ok. I will send an email to marcos to see if he can rerun. thanks | 18:20.54 |
| Robin_Watts | np. | 18:20.58 |
| tor8 | Robin_Watts: you missed a warning on line 392 in base_object.c | 18:40.54 |
| Robin_Watts | tor8: Thanks. MSVC is not giving me the warnings. | 19:04.37 |
| | BT got back in touch with my ISP saying "We can't find anything wrong with the line", and yet, miraculously it seems fixed. | 19:06.12 |
| | Call me a cynic, but I wonder if that's a trick to avoid paying compensation for the fact it's been broken for 3 weeks. | 19:06.39 |
| | tor8: the first sane file (2.7.1....) memtests clean. At last! | 19:55.32 |
| tor8 | Robin_Watts: congratulations! | 19:55.51 |
| Robin_Watts | Is there a reason there is no pdfinfo build for windows ? | 19:57.30 |
| tor8 | I forgot? | 20:05.44 |
| Robin_Watts | OK. My kind of reason :) | 20:08.18 |
| | tor8: How large is an fz_shade (without looking!) | 20:09.52 |
| tor8 | color lookup table + mesh size | 20:10.11 |
| Robin_Watts | I was shocked by the size of the structure. | 20:10.31 |
| | ignoring the mesh | 20:10.39 |
| tor8 | yeah, it's pretty big. the color table is inline isn't it? | 20:10.48 |
| Robin_Watts | Its 33K or so. | 20:11.00 |
| tor8 | it's the damn MAXCOLORS thing being ridiculously big :( | 20:11.16 |
| | maybe we can get away with setting it to a more reasonable 8 (or even 4... punting on funky deviceN colorspaces) | 20:12.12 |
| | 32K from the function lookup table | 20:12.50 |
| Robin_Watts | It's not an issue for me really. | 20:12.55 |
| tor8 | now that I did take a look | 20:12.59 |
| Robin_Watts | Its just that my new memento thing to calculate nestings only used to look for pointers in the first 1K of a block. | 20:13.26 |
| | I've upped that to 64K and it's all good :) | 20:13.33 |
| tor8 | well, you did spot a potential huge friggin' waste of memory :) | 20:13.48 |
| Robin_Watts | actually... those are held around in the display list? | 20:14.07 |
| tor8 | yup they are | 20:14.14 |
| Robin_Watts | crumbs, yes, that will add up. | 20:14.18 |
| tor8 | we could squeeze that by 1) reducing the number of max colors | 20:14.35 |
| Robin_Watts | tor8: Can we make that section malloced? | 20:14.46 |
| | i.e. can we malloc that once we know what the real number of colors we need is? | 20:15.01 |
| tor8 | argh! sometime I hate linux. | 20:15.40 |
| | I did an apt-get upgrade and now errno.h is broken | 20:15.49 |
| Robin_Watts | Hmm. | 20:20.22 |
| | fz_new_stream; if a call to that fails (because it can't allocate stm), I'd like to be able to destroy state automatically. | 20:20.58 |
| | otherwise I need to wrap every call to it. | 20:21.11 |
| | I could call the close function on stm, but that would have the side effect of closing the underlying stream too in some cases. | 20:21.46 |
| | I'll just wrap it :( | 20:23.39 |
| tor8 | you mean insert an exception to test for null return instead? that way lies madness. | 20:24.14 |
| | and by this case I don't mean the throwable kind of exception | 20:24.32 |
| Robin_Watts | No. | 20:24.50 |
| | Actually, I think I might be safe to let it close chain in the event of an error. | 20:25.15 |
| | I'll try it and see :) | 20:25.36 |
| | Oh, hmm. | 20:28.27 |
| | The close functions are called with stm rather than just being called with ctx and a state. | 20:28.45 |
| | I'm going to change them so they get called with a ctx and a state. They shouldn't need to know the internals of fz_stream | 20:31.26 |
| | Forward 1 day (to 2011/12/17)>>> | |
IRC Logs