| <<<Back 1 day (to 2013/09/12) | 2013/09/13 |
kens | chrisl ping | 08:09.26 |
chrisl | kens: pong | 08:09.32 |
kens | having build troubles o Linux. | 08:09.42 |
chrisl | Have you done the autogen.sh? | 08:10.00 |
kens | Ah, no I only did ./configure | 08:10.12 |
| One moment | 08:10.15 |
| in ghostpdl and ds ? | 08:10.48 |
| err gs... | 08:10.57 |
chrisl | What are you building? | 08:10.57 |
kens | Just gs | 08:11.00 |
chrisl | Then just in gs | 08:11.06 |
kens | ah OK | 08:11.09 |
| It was giving an unsupported platform error in openjepg | 08:12.54 |
| Looks like its OK now, thanks | 08:12.54 |
chrisl | That's probably because it's now OpenJPEG 2 in there | 08:13.24 |
kens | Yeah its been a while since I last updated this VM | 08:13.50 |
| OK it built fine this time, thanks | 08:14.00 |
chrisl | NP | 08:14.06 |
sebras | see you guys soon! | 08:49.59 |
Robin_Watts | gawd. It looks like it takes and hour and 40 minutes to generate the warnings stuff that Marcos does on each commit. | 11:46.02 |
| And it's just caught up to when chris bumped the version number to 9.10 | 11:46.38 |
| This could take a while. | 11:46.42 |
| And protecting the dashboard has not protected the reports :( | 11:49.45 |
deleet | Robin_Watts: hey, I am planning on implementing an interface to mupdf on android with fragments sometime next month, do you guys have anything planned yet? | 11:53.08 |
Robin_Watts | deleet: Fragments? Not at all. | 11:53.25 |
deleet | alright, cool. also, does mupdf have any standard format for saving annotations outside of the file itself? (haven't looked) | 11:54.09 |
kens | For now and the logs, does anyone have a copy of Windows server 2003 I could borrow ? | 11:58.48 |
Robin_Watts | deleet: No. | 12:29.18 |
| ok, I've updated the dashboard so that mupdf warnings have links too. | 12:33.26 |
| and I've updated it so that the ghostpdl ones offer a full set of links, but we'll need to wait for the warnings to catch up to try them, | 12:33.56 |
kens | Sounds good to me | 12:35.35 |
Robin_Watts | I've just moved all the cgi-bins called by the dashboard so that they should now be protected by passwords. | 12:51.17 |
| You'll all need to reload the dashboard. | 12:51.25 |
| If any of the links are broken, please let me know. | 12:51.35 |
| Flooding in Denver looks biblical. | 13:34.18 |
kens | :-( | 13:41.09 |
Robin_Watts | Bah. Why is it that when I find some really dodgy code, and git blame it, it's always mine ? | 13:43.33 |
| oh, it's OK. I was clearly smarter then than I am now. | 13:44.09 |
kens | diminishing brain cells with age | 13:44.36 |
Robin_Watts | http://marcosw.no-ip.com:8080/artifex/mupdf/455fecd8213201417a75f887349a5c3b75d5f46d/mupdf-scan-build.txt | 13:45.33 |
| ok, I see what it's whining about. | 13:45.57 |
russcriptor_ | is there a way to have mudraw autocrop? | 15:00.13 |
Robin_Watts | autocrop ? | 15:04.29 |
| unhappy cluster :( | 15:08.46 |
kens | cannot connect to the dashboard | 15:10.02 |
| ah finally got in, | 15:10.15 |
Robin_Watts | kens: really? | 15:10.16 |
kens | took a *long* time | 15:10.22 |
Robin_Watts | ah, well that may be an indication that the network issues are real :) | 15:10.35 |
kens | Indeed, that's why I mentioned it | 15:10.47 |
Robin_Watts | thanks | 15:11.08 |
| paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=aefe6a511b3cb901034e5995fd882e334e40f2bb | 15:12.19 |
| paulgardiner: Looking at yours now, | 15:12.23 |
marcosw | Robin_Watts: I'm going to reboot casper (you are the only one logged on, other then me). | 15:13.41 |
Robin_Watts | marcosw: I think I'm disconnected now. | 15:14.11 |
| marcosw: Thanks for the warning. | 15:14.15 |
| marcosw: How do you do your non-web cluster dashboard thing please? | 15:14.39 |
marcosw | ~regression/c | 15:15.01 |
| casper is coming back up :-) | 16:11.49 |
| casper is back up and everything is working but slowly. I presume this because everyone abandoned the aws zone with connectivity problems and the other zones are now swamped with new instances being launched. I'm in the process of copying our instance to a different region (from N. Virginia to Oregon), that will take a while and until it's finished there isn't much else I can do (right now the aws console page is overloaded as well, so I can't even se | 16:27.43 |
chrisl | Robin_Watts: any chance of getting one of the "Handel & Companye" CDs tomorrow? | 16:51.46 |
mvrhel_laptop | this cie to icc stuff is taking too long. it is starting to feel like a wack the gopher game | 16:56.13 |
ray_laptop | henrys: You are back from Chi-town, right ? | 17:00.10 |
| henrys: I hope you aren't in the area affected by all that rain. How is it there? | 17:00.46 |
henrys | ray_laptop: I'm on high ground and unaffected but this is really awful... | 17:01.41 |
vtorri | hey | 17:02.14 |
| is there someone here who can help me with the libs API ? | 17:02.28 |
| arg | 17:06.18 |
| libgs API | 17:06.22 |
mvrhel_laptop | henrys: I just heard about it all on the radio. Sounds really bad | 17:09.33 |
henrys | the "creek" that runs through my town Longmont looks like the mississippi⦠Sabrina put a ton of pics on Facebook, mvrhel_laptop | 17:13.49 |
mvrhel_laptop | I will have a look | 17:14.01 |
Robin_Watts | chrisl: Will have a look in my loft :) | 17:25.32 |
ray_laptop | vtorri: What do you need to know about the libgs API. I assume you've read the doc/API.htm | 17:29.39 |
vtorri | ray_laptop: i have a segfault when i call gsapi_run_string_with_length() | 17:36.44 |
| i have created the instance | 17:36.55 |
| i have set the callbacks | 17:37.10 |
| i have called gsapi_init_with_args with the args | 17:37.56 |
ray_laptop | vtorri: a debugger should tell you where you are segfaulting from. Are you on linux or windows ? | 17:38.18 |
vtorri | i have set a string buffer to "<< /Orientation %d >> setpagedevice .locksafe" with %d replaced by 0 | 17:38.25 |
| currently on linux | 17:38.35 |
| but i use a pre-compiled libgs (mageia distro) | 17:38.51 |
| so i'm not sure that gdb or valgrind will help me here | 17:39.10 |
Robin_Watts | vtorri: You can try with gdb, and see what you get. | 17:39.34 |
| if you at least build your app with debugging, you should be able to see that the args you pass in are reasonable | 17:40.01 |
vtorri | http://codepad.org/O2rL9dIx | 17:41.21 |
| does it help ? | 17:41.26 |
| i can provide the code if needed | 17:42.00 |
| note that i call all the gs API in a thread, and only in that one | 17:43.06 |
ray_laptop | vtorri: so the function: etui_ps_display_cb_update is your display handler ? It looks like the segfault in in the 'display' device you've set. | 17:43.20 |
vtorri | it's the ast function in the display_callback structure so i think that it is indeed the display handler | 17:44.37 |
| last* | 17:44.39 |
| so maybe the loop which calls memcpy is wrong | 17:45.42 |
| at least i have a starting point where to look at the bug | 17:46.12 |
| thank you | 17:46.13 |
ray_laptop | vtorri: display_fill_rectangle fills the memory buffer then calls out to whatever display callback->display_update function you'veset | 17:46.25 |
| vtorri: OK. Good luck | 17:46.42 |
vtorri | thanks | 17:46.50 |
ray_laptop | vtorri: note that gs_fillpage is the very first thing that is done, to fill the page area (in this case 414 by 711 pixels) with white. Then the "update" is called in case your display device wants to paint the screen with the updated page | 17:48.41 |
vtorri | ray_laptop: what is display_fill_rectangle ? | 17:48.49 |
ray_laptop | vtorri: that is one of the gs 'device API' procs that paints a rectangle with a color. It is FREQUENTLY used. It paints into it's page buffer which can be read out by the 'get_bits_rectangle' device procedure. | 17:51.18 |
vtorri | ok | 17:51.53 |
| in my case i want to fill a piece of memory (the data of my graphic object) with : http://codepad.org/V5mqTU0C | 17:52.27 |
| does the loop seem good ? | 17:52.36 |
| pd->gs.**** is what is returned by libgs | 17:53.07 |
| my data has BGRA as colorspace | 17:54.06 |
ray_laptop | vtorri: what's in the 'pd' struct, and how is it set up (things like gs.image and gs.stride) ? | 17:55.47 |
vtorri | pd is my big structure | 17:56.27 |
| pd->gs is filled with the display_callback callbacks | 17:56.49 |
| in _cb_presize(), should I malloc the image ? | 17:57.30 |
ray_laptop | vtorri: OK. So what is the gs struct ? | 17:57.40 |
vtorri | ray_laptop: http://codepad.org/46MAfTBe | 17:58.13 |
| and my callbacks : http://codepad.org/Sdln1o32 | 17:59.27 |
| ok, first problem : the stride is not width*4, which i have assumed | 18:03.23 |
| hmmm, i think i begin to understand | 18:04.40 |
| _etui_ps_display_cb_update() displays all the "elements" of the page, right ? | 18:05.05 |
| and not the whole page ? | 18:05.21 |
ray_laptop | vtorri: when display_fill_rectangle paints, it does so into its memory device's buffer | 18:05.28 |
| vtorri: the update callback can do whatever you want. See psi/dwmain.c which only actually updates the screen periodically. | 18:06.35 |
vtorri | ray_laptop: and the page_callback ? | 18:07.13 |
ray_laptop | you probably don't want to update on every fill_rectangle call. | 18:07.14 |
vtorri | indeed | 18:07.27 |
| i just want the whole page | 18:07.36 |
| i want a void * image and i want to memcpy(pd->efl.m, image, size); | 18:08.31 |
ray_laptop | vtorri: the display_page only gets called when the page is complete (from the display device's output_page proc) | 18:08.36 |
vtorri | ok | 18:09.03 |
ray_laptop | vtorri: so you need to know where the display device has it's buffer that it paints into, and it's "raster" (the stride) | 18:09.36 |
Robin_Watts | vtorri: I suspect that gs won't give you the image in one continuous block as you want. You will need to cope with stride != w*4. | 18:09.52 |
vtorri | ok | 18:10.22 |
ray_laptop | Robin_Watts: that's what 'bitmap_raster()' is for | 18:10.34 |
Robin_Watts | ray_laptop: Indeed. | 18:10.41 |
ray_laptop | that defines a memory device's "stride" | 18:10.48 |
vtorri | time to go | 18:11.05 |
| thank you very much ! | 18:11.20 |
ray_laptop | vtorri: the device's get_bits proc will return a line of data from the buffer | 18:12.40 |
| vtorri: dev->proc.get_bits (see base/gxdevcli.h for the info on this proc). You specify the line (y) and it returns a pointer. That way you don't need to know how the data is set up in the memory device's buffer | 18:14.47 |
vtorri | ok, i did a final test | 18:15.33 |
| the update callback does nothing | 18:16.02 |
| the page callback fills my piece of data with a loop | 18:16.23 |
| and it seems to work | 18:16.28 |
ray_laptop | I have to run an errand now ... | 18:16.32 |
| vtorri: OK, good. Sorry I have to run, but I'll check back later | 18:16.50 |
vtorri | so i'm happy | 18:16.56 |
| np | 18:16.59 |
| thank you again | 18:17.03 |
ray_laptop | vtorri: great! | 18:17.04 |
| vtorri: you are welcome | 18:17.12 |
mvrhel_laptop | and one more cluster push to test cie to icc fun | 18:18.03 |
| henrys: I am surprised you have power. I would have thought they would shut parts of it off | 18:22.10 |
Robin_Watts | mvrhel_laptop tempts fate on henrys behalf. | 18:53.36 |
henrys | really is amazing what's going on: http://www.denverpost.com/portlet/article/html/imageDisplay.jsp?contentItemRelationshipId=5404887 | 19:16.22 |
mvrhel_laptop | ok. cie stuff done for a while, until I tackle V2 profiles for kens | 19:16.25 |
| now onto 694551 which is PCL, FAPI, Overprint | 19:16.40 |
| very curious about this one | 19:16.51 |
Robin_Watts | henrys: It's Gods judgement on the liberals. | 19:17.15 |
mvrhel_laptop | henrys: it sounded like there are quite a few people that are cut oof | 19:17.19 |
| yes, the red parts of CO are saying "I told you so" | 19:17.36 |
| marcosw: so I need to put together a desktop machine for my son. what is the best deal to be found without getting something that sounds like a vacuum cleaner | 19:21.28 |
| ok fair enough. profile_struct is null... | 19:27.45 |
| sounds like my issue | 19:27.45 |
| this is weird though | 19:28.47 |
| lunch break for a bit | 19:28.53 |
| hmm a few warnings in my last commit. will try to get those taken care of | 20:16.18 |
| ok have a fix for 694551 . henrys: can you look athttp://www.ghostscript.com/~mvrhel/ICC_character.patch and let me know if you are fine with this? | 20:30.26 |
| running cluster test on it now | 20:36.33 |
| bbiaw | 20:38.33 |
marcosw | amazon claims they've resolved the problem with the connectivity to the us-east-1a zone, so I'm going to put casper back. It will be down ~30 minutes. | 21:08.14 |
| okay, casper is back up. please let me know via sms or email if something is amiss. | 21:56.25 |
mvrhel_laptop | henrys: so cluster issues with the above patch. are you fine if I commit? | 22:18.04 |
| s/so/no/ | 22:18.11 |
henrys | mvrhel_laptop: I tried to look but casper seas down. Is it up now? | 22:18.33 |
mvrhel_laptop | yes | 22:18.44 |
henrys | okay so why isn't the change in make_mem_mono_device? It is needed anytime you use it right? | 22:21.22 |
mvrhel_laptop | well this is the only call to make_mem_mono_device in the whole code base but yes, I could move it in there in case someone uses it in the future | 22:22.48 |
| should I go ahead and add a return also then on gs_make_mem_mono_device_with_copydevice | 22:23.17 |
| in case the init fails for some reason | 22:23.31 |
| which could happen if there is a path issue if we built without the romfs | 22:24.10 |
| henrys: I am fine making that change | 22:27.43 |
henrys | mvrhel_laptop: I'm not feeling on firm ground with this one. Why wouldn't the same problem occur with gs_make_mem_mono_device? | 22:28.03 |
mvrhel_laptop | let me look. depends upon how it is used | 22:29.28 |
| it is always possible to make a random device and try to use it without having things properly intialized | 22:29.46 |
| in most cases, the device is set up to have the target device profile be the profile | 22:30.57 |
henrys | and why the default profile? Suppose somebody is using a custom gray profile? | 22:31.18 |
mvrhel_laptop | set_dev_proc(dev, get_profile, gx_forward_get_profile); | 22:31.53 |
| and a comment before that saying /* Should this be forwarding or monochrome profile? */ | 22:32.09 |
| with gs_make_mem_mono_device | 22:32.32 |
| which was my concern with the other case | 22:32.40 |
| If someone is using a custom gray profile, it is the default profile | 22:32.56 |
| henrys: so with that aspect we are correct | 22:33.03 |
| I would argue that gs_make_mem_mono_device is actually wrong in forwarding | 22:33.13 |
| if I am going out to a rgb device there would be some issues | 22:33.34 |
| I wonder who made that comment. let me do blame | 22:33.52 |
| and yes indeed. I made that comment | 22:35.07 |
| henrys: so let me go ahead and set both gs_make_mem_mono_device and the other one to get set up with the gray profile | 22:35.49 |
| question though | 22:36.00 |
| is gs_make_mem_mono_device ever called during clist playback? | 22:36.18 |
henrys | yikes performance | 22:36.20 |
| every character cached needs a mono men device and we're going to swap out profiles? | 22:36.59 |
mvrhel_laptop | right now we would be simply assigning a pointer | 22:37.25 |
henrys | oh okay. | 22:37.41 |
mvrhel_laptop | no different than assigning the proc | 22:37.42 |
| the profile is already set in the manager. | 22:37.58 |
| however, that brings me to my clist question | 22:38.08 |
henrys | you don't dump say a cache of colors when switching? | 22:38.22 |
| mvrhel_laptop: I think clist must use it. | 22:39.12 |
mvrhel_laptop | ok. that presents a problem | 22:39.22 |
| the other function was only called during clist writing | 22:39.43 |
henrys | and why do we only see a problem in this very isolated situation? | 22:39.54 |
mvrhel_laptop | this call is only used with non-FAPI case. Don't know why with this file | 22:40.17 |
henrys | mono memory device are created all the time. | 22:40.26 |
| it just seems something else should break. | 22:40.40 |
mvrhel_laptop | and bold_fraction != 0 | 22:41.30 |
| for what ever that is worth | 22:41.34 |
| I am not a font person as you know | 22:41.41 |
| do you run into alot of bold tt in PCL | 22:42.26 |
henrys | I'm sorry I'm just puzzled by this one. It really isn't about fonts - if I create a DeviceGray pattern I make a mono memory device and everything works fine. | 22:43.18 |
| maybe you added the icc init to the pattern code. | 22:44.55 |
mvrhel_laptop | ok. but I do think that there is a bug in gs_make_mem_mono_device | 22:45.00 |
| as it is forwarding to the target device. | 22:45.21 |
henrys | yes I agree. | 22:45.23 |
mvrhel_laptop | let me make that fix, and see what explodes | 22:45.29 |
| as that will def. occur in lots of places | 22:45.42 |
henrys | stand back! | 22:46.05 |
mvrhel_laptop | one question though | 22:46.09 |
henrys | go ahead | 22:48.36 |
| very few bold tt tests | 22:49.05 |
mvrhel_laptop | sorry. I am back | 22:49.35 |
henrys | I am only concerned that this pattern of making a mono memory device is very common in the code - I don't care about PCL bold. | 22:49.53 |
mvrhel_laptop | I am worried that if gs_make_mem_mono_device is called during clist playback, there is no default gray profile to grab | 22:50.19 |
henrys | well it shouldn't failâ¦. but you know what I mean. | 22:50.26 |
mvrhel_laptop | as any profiles that are needed must be packed in the clist | 22:50.43 |
| I don't understand how it can work right now the way that it is | 22:51.02 |
| I am going to go ahead and make the change and see what happens | 22:51.15 |
henrys | I don't know if clist would use it if the profile were never set before clist. | 22:51.53 |
mvrhel_laptop | what I mean by "I don't understand how it can work right now the way that it is" is that the color mappings should be wrong when going to the mono device with an RGB target device | 22:51.56 |
henrys | yes that is what is completely nutty how is this working now? | 22:52.21 |
mvrhel_laptop | if I were doing a RGB fill in the mono mem device | 22:52.23 |
| then the color would be mapped to the device RGB profile | 22:52.34 |
| and filled in the mono mem device | 22:52.41 |
| which would seem like an issue | 22:52.47 |
| ok. let me fool with it and set it the way I think it should be | 22:53.20 |
| and see where that takes me | 22:53.24 |
| oh | 22:53.47 |
| gs_make_mem_mono_device has no access to pgs | 22:53.59 |
| you know though | 22:55.44 |
henrys | let me step through in the debugger a more common use of the mono device so I can understand this better. | 22:56.17 |
mvrhel_laptop | that is what I was just thinking I need to do | 22:56.38 |
| what is a good file to use? | 22:56.46 |
henrys | any character will create a mono device to make the cache bitmap. | 22:57.43 |
mvrhel_laptop | ok actually, I am going to go ahead and change gs_make_mem_mono_device_with_copydevice to set it to forwarding and then see what is going on | 22:58.38 |
henrys | the default gray profile is subtractive right? It can't be just using the first component of the rob profile. | 22:58.42 |
| can it? | 22:58.45 |
| s/rob/rgb | 22:58.53 |
mvrhel_laptop | it is additive | 22:58.54 |
| ok here is a call into gs_make_mem_mono_device | 22:59.18 |
| hmm. other than gs_setoverprint we never seem to call to get the profile | 23:00.39 |
| oh I see | 23:01.39 |
| we always do a call to gx_set_device_color_1 | 23:01.59 |
| I suspect we are not doing any color management here | 23:03.07 |
| as we are sticking in a Gray color space with no profile | 23:03.23 |
| and likely using the DeviceGray mapping proces | 23:03.36 |
| that makes sense now | 23:03.39 |
| and is probably what we want anyway | 23:04.12 |
| for text | 23:04.32 |
| bitmaps | 23:04.32 |
| hmm henrys: I need to look at this a bit more later. I have to take care of some home issues here now. | 23:09.21 |
| sorry to drag you into the quagmire | 23:09.36 |
henrys | oh no problem. | 23:09.45 |
| Forward 1 day (to 2013/09/14)>>> | |