| | <<<Back 1 day (to 2017/07/09) | 20170710 |
| sebras-mobile | I just verified malc_'s issues reported during the weekend: https://pastebin.com/raw/8x2kwcmJ | 07:56.59 |
| | I'm not sure if this is due to my internet connection or if it is due to something on the server. | 07:57.32 |
| | though the error message is not the same, it should be noted that it is only lcms2 that creates a problem for me, the other thirdparty repos clone fine! | 07:58.55 |
| prashant_123456 | hello to all | 08:57.51 |
| | i am in love with mupdf previously i was using qpdfview but mupdf won my heart but one thing i want to know how can i use mupdf using continious page mode rather than one by one view ? | 08:59.01 |
| Robin_Watts | For the logs: malc_: sebras: Try now. | 09:31.26 |
| tor8 | sebras: not too thrilled about the idea of building with pthreads for *all* tools | 10:12.51 |
| sebras | tor8: sure that's reasonable, but as it is now, I believe that nothing except the threadhandling code itself is built using pthreads..? | 10:16.25 |
| tor8 | sebras: muraster and mudraw uses threads | 10:17.04 |
| | use* | 10:17.08 |
| | which I guess does make 'mutool' need pthreads | 10:17.30 |
| sebras | tor8: true, and that's because of mudraw. | 10:18.10 |
| | tor8: I guess separating mudraw out into a separate tool might avoid that situation. | 10:18.40 |
| tor8 | I'd rather not do that... | 10:21.31 |
| | so well, I guess I don't *actually* mind building on pthreads | 10:21.44 |
| sebras | tor8: so... a compiletime setting akin to verbose or build to control whether pthreads are used? | 10:21.52 |
| tor8 | which then makes our stance of not depending on a threading library a bit weak | 10:22.09 |
| sebras | tor8: the _library_ doesn't depend on threads. | 10:22.26 |
| | tor8: isn't that what we claim? and mudraw is a tool that happens to use threads, which is fine. | 10:22.53 |
| tor8 | uh... look in Makefile line 339 | 10:23.17 |
| | THREAD_OBJ := $(THREAD_OBJ) | 10:23.23 |
| | yeah, we build a separate 'muthread' library for the tools | 10:24.08 |
| sebras | right, so this is a problem of building MUTOOL_SRC while having HAVE_PTHREAD defined in that case. | 10:24.55 |
| tor8 | your "Enable pthreads in all tools" commit moves the -DHAVE_PTHREAD from building the threading helper library to the all the source | 10:25.05 |
| | I don't think that should be necessary | 10:25.10 |
| sebras | no, but for building mudraw.o and muraster.o it is necessary. | 10:25.47 |
| | the -DHAVE_PTHREAD | 10:25.54 |
| tor8 | sebras: mudraw and muraster don't reference HAVE_PTHREAD, they just use the thread helper API | 10:26.33 |
| sebras | ./build/debug/mutool draw -T 2 -s t ./pdfref17.pdf 1 | 10:27.47 |
| | Threads not enabled in this build | 10:27.48 |
| | this is without my patch. | 10:27.54 |
| tor8 | oh. now I see, the mu-threads.h has a compile time check for HAVE_PTHREAD which sets DISABLE_MUTHREADS which is *then* used by the tools | 10:28.09 |
| sebras | I think the threading header file requires HAVE_PTHREAD. | 10:28.11 |
| | tor8: so everything that includes that header must define HAVE_PTHREAD. | 10:28.42 |
| tor8 | that seems ... bad. should be a run-time check IMO. | 10:28.44 |
| | sebras: yes, and that's not good. | 10:28.56 |
| sebras | tor8: how would you know what library to dlopen()? or rather in what locations? | 10:29.14 |
| tor8 | the muthread helper library should know; exposing HAVE_PTHREAD to the client is bad design. | 10:29.55 |
| sebras | tor8: it would be nice to be able to in run-time check if we were linked to pthreads and if so use the threading. | 10:30.02 |
| tor8 | I'm thinking a run-time check to see whether the muthread library supports threads | 10:30.25 |
| | and if built with pthreads (or win32) it would report yes, otherwise no | 10:30.40 |
| | an if (mu_threads_enabled()) or something like that in mudraw and muraster | 10:31.23 |
| sebras | tor8: right, and if there is no threading library just have the threading implementations fail hard? | 10:31.48 |
| tor8 | then it would always return false, and use the 'null' threading implementation we have | 10:32.09 |
| | too bad the mu-threads.h exposes the internals to the client, the structs are not opaque | 10:32.50 |
| | I think we ought to involve Robin_Watts in this | 10:32.57 |
| | ah, he ran away :) | 10:33.07 |
| sebras | tor8: smart! :) | 10:33.16 |
| | tor8: I'll whip up a patch doing what you propose and see if I can make it sane. | 10:33.28 |
| | tor8: ok, besides this one, how about the rest of sebras/master? | 10:33.42 |
| tor8 | I'd suggest waiting for Robin's response | 10:33.43 |
| | the other two on sebras/master LGTM | 10:33.56 |
| sebras | tor8: in that case I'll push them. | 10:34.05 |
| | Robin_Watts: RobinWattsLenovo: malc_: I just cloned recursively using git://, https:// and http:// and all worked fine. | 10:52.37 |
| Robin_Watts | sorry, chatzilla got itself into a state where I wasn't seeing any incoming messages. Reading logs now. | 11:39.56 |
| | What tor8 says sounds sane. | 11:40.34 |
| | Let me look at sebras patch. | 11:40.38 |
| | oh, there is no patch yet. | 11:41.40 |
| | having mu_threads offer a runtime "are threads enabled" question seems sensible. | 11:42.33 |
| | That would require some changes in the tools where they refer to "threaded build" or not (in the usage messages, IIRC). | 11:43.20 |
| tor8 | making the mu_thread, mu_mutex and mu_semaphore structs opaque means we have to deal with dynamic allocation though | 11:43.30 |
| Robin_Watts | Hiding the implementations would indeed be nicer, but that would mean dynamic allocation, yes. | 11:43.42 |
| tor8 | the main concern here is whether to hide the implementation or not. if we do we can avoid passing HAVE_PTHREAD when compiling the tools. | 11:44.39 |
| Robin_Watts | Personally, I don't feel offended by having to pass HAVE_PTHREAD to the tools. | 11:45.14 |
| | I would feel offended by having to pass it to the lib. | 11:45.22 |
| tor8 | in that case we only need to modify the Makefile to pass -DHAVE_PTHREAD to mudraw.c and muraster.c | 11:46.10 |
| | well, source/tools/%.c would probably be safer | 11:46.21 |
| sebras | tor8: right. | 11:47.37 |
| | Robin_Watts: is there a readon the usage() in mudraw.c uses ifdef MUDRAW_THREADS? | 11:50.19 |
| | Robin_Watts: I believe it is a typo. | 11:50.24 |
| Robin_Watts | sounds like a typo to me. | 11:53.06 |
| sebras | sebras/master has a patch that seems to work now. | 11:53.08 |
| Robin_Watts | probably something I missed while I refactored MUDRAW_THREADS to MUTHREADS | 11:53.23 |
| sebras | I verified in gdb that there are actually multiple threads. | 11:56.07 |
| Robin_Watts | sebras: sebras/master looks reasonable to me, but I wonder if we can't do a bit better... | 12:15.46 |
| | can we have a 'THREADING_FLAGS' setting in the Makefile ? | 12:15.58 |
| | then pass $(THREADING_FLAGS) to tools and helpers? | 12:16.10 |
| | That makes it easier to ensure that people editing the makefile to tweak the threading don't change it in just one place. | 12:16.42 |
| Robin_Watts | foods. | 12:17.00 |
| sebras | Robin_Watts: ok, so more akin to what is on sebras/master now? | 12:52.10 |
| Robin_Watts | Yes. | 13:03.19 |
| | My make-fu is not strong enough to be 100% sure that it's OK to define THREADING_FLAGS after they are used though. | 13:03.39 |
| | makes me wonder if that section should be moved to Makerules ? | 13:04.30 |
| tor8 | the ifneq "$(threading)" "no" section ought to live in Makerules | 13:13.36 |
| | Robin_Watts: variables are evaluated when the rule is invoked, so assigning after use in dependency rules is okay | 13:14.45 |
| | but it is a bit confusing, and I prefer having this sort of variables set in Makerules | 13:15.16 |
| Robin_Watts | I figured it was probably OK. I know there are 2 types of assignment in makefiles, = and := and i can never immediately remember which is which ;) | 13:28.55 |
| tor8 | := evaluates at the point of assignment, = re-evaluates every time it is used | 13:29.38 |
| | you spend too much time with visual studio ;0 | 13:30.09 |
| malc_ | tor8: are you sure? i was under impression that on is eager and the other lazy (i.e. not re-evaluated always) | 13:32.02 |
| tor8 | malc_: with := the right hand side is evaluated immediately, with '=' the right hand side is re-evaluated every time the variable is used | 13:33.57 |
| | example: FOO = hello; A := $(FOO); B = $(FOO); FOO = goodbye; echo $(A); echo $(B) | 13:34.06 |
| | will print "hello goodbye" | 13:34.15 |
| | this has a larger impact in the right hand side includes things like $(shell run-expensive-command) | 13:35.32 |
| sebras | tor8: if not directed otherwise I'll just tack the threading configuration at the end of Makerules.w | 13:40.04 |
| tor8 | sebras: after the ifeq "$(largefile)" section would be good | 13:40.34 |
| | or, hm, maybe after the ifeq $(OS) sections but before the cross- | 13:41.21 |
| | compilation sections would be even better | 13:41.27 |
| | because then we have the HAVE_PTHREAD stuff detected | 13:41.50 |
| sebras | undefined reference to `pthread_create' | 13:43.01 |
| | hm... | 13:43.05 |
| | yeah, but HAVE_PTHREAD is done in Makethird. | 13:44.34 |
| | eh.. PTHREAD_CFLAGS. | 13:44.41 |
| | I'll just use SYS_PTHREAD_* directly, that would work, and remove PTHREAD_* altogether. | 13:45.15 |
| tor8 | why do we need a separate THREADING_CFLAGS in the Makefile? | 13:47.20 |
| sebras | I _can_ rename it variable to PTHREAD_CFLAGS if you wish, but I guess Robin's idea was that someone might replace this with some other threading library..? | 13:48.29 |
| tor8 | I'd worry about that when we need it. I dislike adding generic layers of cruft to enable switching implementations before having multiple implementations. | 13:49.23 |
| sebras | renames. | 13:49.53 |
| Robin_Watts | tor8: I'm happy to have it called PTHREAD_CFLAGS. | 13:50.05 |
| tor8 | sebras-pthread: rename what? | 13:50.08 |
| | we already have a PTHREAD_CFLAGS | 13:50.20 |
| Robin_Watts | I just want the actual definition of what flags we use to be in just one place. | 13:50.26 |
| | rather than duplicated in 2 separate lines. | 13:51.08 |
| tor8 | Robin_Watts: you mean in the $(CC_CMD) lines for helpers/%.o and tools/%.o? | 13:51.38 |
| Robin_Watts | yes. | 13:51.46 |
| tor8 | then adding -DHAVE_PTHREAD to the bottom section of Makethird where we set the PTHREAD_CFLAGS to SYS_PTHREAD_CFLAGS would be the place | 13:52.15 |
| Robin_Watts | tor8: Sounds OK to me. | 13:52.33 |
| tor8 | and we could rename PTHREAD_CFLAGS and PTHREAD_LIBS to THREADING_CFLAGS and THREADING_LIBS if you prefer that | 13:52.44 |
| | (but keep SYS_PTHREAD_CFLAGS as it is currently named) | 13:52.56 |
| | then if you want to change threading lib, editing Makethird would be all you need | 13:53.10 |
| sebras-pthread | alright, I' | 14:00.48 |
| | m hitting enter when I don't intent to! also, I have updated sebras/master. | 14:01.19 |
| tor8 | sebras-pthread: LGTM! | 14:02.07 |
| Robin_Watts | and me. | 14:02.38 |
| sebras-pthread | tor8: also the pattern is apparently try {} try {} try {} try {} try {} finally {} ;) | 14:02.41 |
| | Robin_Watts: thanks! | 14:02.50 |
| tor8 | Robin_Watts: could we do something about the (to my understanding completely pointless) ContextID = ContextID; statements in lcms2? | 14:03.12 |
| Robin_Watts | tor8: In lcms2 itself? No. | 14:03.23 |
| | For the same reason I haven't gone through and reindented it all. | 14:03.40 |
| tor8 | they're lines added by mvrhel. | 14:04.10 |
| Robin_Watts | Oh, then we could probably make them (void)ContextID; | 14:04.25 |
| tor8 | I don't see what purpose they serve though. | 14:04.34 |
| Robin_Watts | To stop compilers whinging about used arguments | 14:04.48 |
| | s/used/unused/ | 14:04.56 |
| tor8 | but ContextID is used elsewhere in cmsOpenIOhandlerFromMem | 14:05.28 |
| | likewise it's also used elsewhere in cmsMLUalloc | 14:06.06 |
| | and also in AllocElem | 14:06.25 |
| Robin_Watts | tor8: Then yes, we can drop them :) | 14:06.37 |
| | I suspect they were added when they weren't used :) | 14:06.47 |
| tor8 | yes, that's a plausible explanation | 14:07.13 |
| | which of the branches are we actually using? there are mupdf_changes, mupdf_changes1, and mupdf_changes2 | 14:09.33 |
| Robin_Watts | We are currently on mupdf_changes2. | 14:10.57 |
| | I rebase it on top of martis changes each time we pull in fixes. | 14:11.15 |
| | I may at some point start doing merges instead. | 14:11.30 |
| | Those could be tags instead of branches, but meh, it's git. | 14:11.48 |
| tor8 | merges might be better if we point the submodule to it | 14:11.50 |
| | otherwise we have to be extra careful to keep all the old rebases around | 14:12.01 |
| Robin_Watts | submodules always point to SHAs. | 14:12.07 |
| | That's why they are there are branches :) | 14:12.14 |
| | s/there are/there as/ | 14:12.24 |
| tor8 | yeah, but we need to take lots of care not to lose those branches so I think merging might be better | 14:12.42 |
| Robin_Watts | tor8: probably, yes. | 14:13.23 |
| tor8 | there's a commit on my thirdparty-lcms2.git tor/master | 14:14.01 |
| Robin_Watts | tor8: Seems OK to me. | 14:16.28 |
| mvrhel_laptop | tor8: yes lcms2 probably needs some cleaning up. The ContextID = ContextID likely came about during a pile of auto replacements. | 15:40.23 |
| | There were so many places that changes needed to be done and I wanted to see if these would even work so I was working quickly | 15:40.55 |
| Robin_Watts | mvrhel_laptop: We want to avoid doing any cleanups that take us further away from Marti though :) | 15:41.58 |
| | tor8 has done a commit for those, and it pulls us back towards baseline. | 15:42.31 |
| | mvrhel_laptop: Have you ever successfully written a .psd from mupdf including an icc profile ? | 15:44.32 |
| mvrhel_laptop | Robin_Watts: yes. But changes that I did that need cleaning up certainly should be fixed :) | 15:45.03 |
| | Robin_Watts: no I have not even tried psd yet | 15:45.16 |
| Robin_Watts | mvrhel_laptop: Ah, cool. | 15:45.22 |
| | Cos I just spotted a "how can that work?" in there :) | 15:45.37 |
| | (in my code) | 15:47.02 |
| mvrhel_laptop | Robin_Watts: ah ok. I am hoping to have a commit or two for you to look at tomorrow. It will use the group color spaces and also fix several blending issues | 15:47.56 |
| | that I stumbled upon | 15:48.08 |
| Robin_Watts | cool. I'm hoping to be able to try some rendering with spot colors by then too. | 15:48.25 |
| mvrhel_laptop | Robin_Watts: oh | 15:48.35 |
| | I had a thought also that you might want to think about | 15:48.50 |
| Robin_Watts | uh oh. | 15:48.57 |
| mvrhel_laptop | no this is for overprint | 15:49.04 |
| | which would be next | 15:49.11 |
| Robin_Watts | yeah, I have a vague plan for overprint. | 15:49.22 |
| mvrhel_laptop | oh I would like to hear it. Or I can write you an email with a couple of my thoughts on it | 15:50.06 |
| | that should be an And not an Or | 15:50.27 |
| Robin_Watts | OK. There are probably questions about overprint that I haven't thought of yet. | 15:50.51 |
| mvrhel_laptop | Robin_Watts: how about if I send you an email | 15:51.12 |
| | that may spark a couple thoughts on how best to do it | 15:51.24 |
| Robin_Watts | cool. | 15:51.24 |
| | My vague plan... | 15:52.10 |
| | in the draw device, I get called with a colorspace and a color array. | 15:52.25 |
| | I spot that colorspace being a separation/devn one, and transmute the colors array from being in the supplied colorspace, to being in the target colorspace/separations. | 15:53.10 |
| | (That's just how I deal with separations/devicen in general, no special overprintness yet). | 15:53.31 |
| | Then I call the scan converter (or whatever) to actually apply those colors. | 15:53.53 |
| | The scan converter (or the image/glyph drawing code etc), call down to get 'painter' routines for that pixmap. | 15:54.49 |
| | The painter routines know how to plot solid runs of a color etc. | 15:55.26 |
| | So whether we are overprinting or not "just" needs to be passed down to the selection for those painter routines. | 15:55.48 |
| mvrhel_laptop | Robin_Watts: ok. So the overprint information that you would want to pass at that level would be essentially a mask that would indicate the colorants that you are overprinting and which you are not clearing | 15:57.30 |
| Robin_Watts | mvrhel_laptop: Can we not say "if color != 0, don't touch it?" | 15:58.06 |
| mvrhel_laptop | That mask is set of course, by the color space, the overprint setting and the overprint mode | 15:58.09 |
| Robin_Watts | Do we actually need a mask? | 15:58.19 |
| mvrhel_laptop | Robin_Watts: I think we do. Let me check one thing | 15:58.51 |
| Robin_Watts | If we have spots A,B,C,D,E and I have a DevN colorspace with A and B in it, and A = 1 and B = 0, and the current screen values are all A,B,C,D,E=0.5.... what do we end up with? | 15:59.42 |
| | A=1, B,C,D,E = 0.5 ? or A=1, B=0, C,D,E=0.5 ? | 16:00.28 |
| mvrhel_laptop | 1 0 0.5 0.5 0.5 | 16:00.30 |
| Robin_Watts | Bollocks, said Pooh. | 16:00.44 |
| | That would seem to suggest that I do need a mask, yes. | 16:01.09 |
| mvrhel_laptop | That is if overprint mode is 0 though | 16:01.12 |
| | if overprint mode is 1 it is different | 16:01.27 |
| | then you have | 16:01.34 |
| | 1 0.5 0.5 0.5 0.5 | 16:01.46 |
| Robin_Watts | AIUI, "overprint mode" or not only determines whether CMYK is treated like spots. | 16:02.22 |
| mvrhel_laptop | no | 16:02.28 |
| | With overprint mode of 1 a tint value of 0.0 for a source color component leavs the corresponding component when drawing unchanged | 16:03.15 |
| | there is nothing about CMYK in that | 16:03.25 |
| | so the fact that you had 0 for spot B | 16:03.51 |
| Robin_Watts | OK, so let's run through this in really small words... | 16:04.02 |
| | sorry, go on. | 16:04.07 |
| mvrhel_laptop | means that you could get the same effect as if you had used a DevN color space with ACDE | 16:04.18 |
| | Done | 16:04.31 |
| Robin_Watts | Right, so: For OP=0, we end up with A=1, B,C,D,E=0 | 16:04.57 |
| | For OP=1, OPM=0, we get A=1,B=0, C,D,E=0.5 | 16:05.28 |
| mvrhel_laptop | uh no wait | 16:05.47 |
| Robin_Watts | For OP=1, OPM=1, we get A=1, B,C,D,E=0.5 | 16:05.52 |
| | waiting. | 16:05.59 |
| mvrhel_laptop | Lets go back to your first comment | 16:06.26 |
| | oh sorry | 16:06.38 |
| | your are correct | 16:06.42 |
| | I did not see the OP=0 :) | 16:06.58 |
| Robin_Watts | :) | 16:07.07 |
| | Ok, I understand. | 16:07.13 |
| mvrhel_laptop | Yes those all look correct to me | 16:07.17 |
| Robin_Watts | So in order to do the OP=OPM=1 case, we need an extra bitmap. | 16:07.28 |
| mvrhel_laptop | yes. gs uses an effective overprint setting for this | 16:07.56 |
| | iirc | 16:08.16 |
| Robin_Watts | No, wait... it's the OP=1, OPM=0 case that needs the bitmap. Cos we need to know that the 0 isn't really a 0. | 16:08.30 |
| | It's all doable, it's just 1 more param to pass around. | 16:08.51 |
| mvrhel_laptop | ok. It sounds like you have a handle on it | 16:09.06 |
| Robin_Watts | mvrhel_laptop: Thanks for this discussion. It has saved me going down the wrong path. | 16:09.26 |
| mvrhel_laptop | good deal | 16:09.34 |
| Robin_Watts | I'll hopefully have something for you to look at tomorrow. | 16:09.48 |
| mvrhel_laptop | with overprint? | 16:09.57 |
| Robin_Watts | mvrhel_laptop: No :) | 16:10.49 |
| mvrhel_laptop | ha ok | 16:10.54 |
| Robin_Watts | but possibly with some of the overprint skeleton in there. | 16:11.01 |
| mvrhel_laptop | ok cool | 16:11.14 |
| sebras | Robin_Watts: there's a threading leak patch on sebras/master | 19:16.03 |
| | Robin_Watts: but my gut tells me that the better solution is the second patch on sebras/master which disables parallel interpretation/rendering altogether if threads are disabled. | 19:16.27 |
| | because no threads are actually started and so we shouldn't even get into that situation because it just seems wrong. | 19:16.52 |
| | need to sleep, will read logs. | 19:16.58 |
| libplayz | hi everyone, i'm trying to use mupdf but i'm having issues compiling it, can you help? | 21:21.51 |
| | if its the right channel | 21:22.10 |
| Robin_Watts | libplayz: This is the right channel, just the wrong timezone. | 22:36.20 |
| libplayz | lol, it's midnight in paris (so its late even in local time for me), I found a solution for my problem, I was having compilation issues, redefinition of strlen in output.c | 22:49.06 |
| | the project structure was (ð¤ and still is) a little confusing for me | 22:50.04 |
| | thank for your reply Robin_Watts | 22:50.23 |
| Robin_Watts | libplayz: No worries. You're in the same timezone as (most of) the MuPDF developers. | 22:52.45 |
| | Currently UK and Sweden. Oh, but Sebras is in Taiwan at the moment, and mvrhel is in Seattle, so we do spread around a bit. | 22:53.32 |
| libplayz | salutation from paris guys. nice work, good night. | 23:01.19 |
| | Forward 1 day (to 2017/07/11)>>> | |
Log of #mupdf at irc.freenode.net.