| | <<<Back 1 day (to 2018/03/29) | 20180330 |
| paulgardiner | Robin_Watts: I checked Makethird and jmemnobs.c isn't listed, so I tried dropping it from the VS project and the conflicts go away. Still doesn't explain why the muso project and mupdf project differ in behaviour of course. | 09:00.20 |
| Robin_Watts | paulgardiner: how odd. | 09:02.49 |
| paulgardiner | Quite | 09:02.57 |
| | Another strangeness is that libresources has only a Release configuration, no Debug. Perhaps it's all data no functions so it makes no odds | 09:04.06 |
| Robin_Watts | paulgardiner: Indeed, that's the key. | 09:04.40 |
| paulgardiner | I still have the mystery as to why I need to specify libraries explicitly, but it seems to work. | 09:05.55 |
| Robin_Watts | paulgardiner: See answer #1 ? | 09:25.31 |
| | https://stackoverflow.com/questions/3795567/visual-studio-2010-not-autolinking-static-libraries-from-projects-that-are-depen | 09:25.34 |
| | paulgardiner: So "Add New Reference" looks to be the way to go now. | 09:27.07 |
| | The old "project dependencies" mechanism used to mean "If A depends on B, then both 1) build B before A, and 2) link B when linking A." | 09:28.24 |
| | It now just means 1. | 09:28.29 |
| | And the "Add New Reference" thing is used to do 2. | 09:28.38 |
| | Who knew? | 09:28.40 |
| paulgardiner | Oh great. That seems to explain it. | 09:32.30 |
| | It's still a mystery to me why the inclusion of jmemnobs.c causes no problems in the mupdf project | 09:37.08 |
| Robin_Watts | indeed. | 09:44.22 |
| sebras | Robin_Watts: may I ask why the windows olution needs to include jmemcust.c and jmemnobs.c at all? since Makethird doesn't appear to include either..? | 10:55.40 |
| Robin_Watts | sebras: nafc. | 10:58.41 |
| | Oh, wait... | 10:58.48 |
| | jmemcust.c is included by libmupdf, not libthirdparty. | 10:59.03 |
| | so I bet the Makefile does include it. | 10:59.09 |
| | but while I believe jmemnobs is probably not needed, the question is not "why does the solution need to include it", but rather "why does the solution get away with including in VS2005, but not in VS2015?" | 11:00.36 |
| jogux | could it be as simple as VS2005 not checking for duplicated symbols? | 11:08.49 |
| paulgardiner | jogux: the automatic upgrade of mupdf's project to VS2015 builds okay too. | 11:11.39 |
| | Gah, that hasn't worked! I now have a reference to libmupdf from SOControl, but still have unresolved symbols | 11:13.32 |
| sebras | Robin_Watts: ok, that makes sense to me. | 11:15.51 |
| | Robin_Watts: I tried to add jmemnobs to Makethird on linux using both gcc and clang, and neither complains while linking. | 11:16.16 |
| | Robin_Watts: but I can see e.g. jpeg_free_large being listed as T in both libmupdf.a and libmupdfthird.a | 11:17.13 |
| | Robin_Watts: but because link order matters I would naïvely assume that the first object/library that can satisfy a symbol is the one to be used, and then the search process does not contiune after that (like jogux said). | 11:19.29 |
| Robin_Watts | paulgardiner: So do you still have a problem, and if so, what exactly? | 11:20.27 |
| paulgardiner | Even with a reference added, libmupdf.lib isn't included in the link unless specified explicitly | 11:21.49 |
| | I can add the lib explicitly and remove jmemnobs.c which gives me a way forward at least | 11:24.24 |
| Robin_Watts | and that solves your problem? | 11:27.47 |
| | We should remove jmemnobs.c from the VS2005 version too. | 11:28.01 |
| cmc | Hi! I did a little hack on mupdf-x11 to save page numbers https://capocasa.net/hacking-mupdf-to-save-the-page-number | 11:31.31 |
| paulgardiner | Ah, I may have found it | 11:37.34 |
| | Yep. In addition to creating the reference, I needed to set the reference's "Link Library Depends" property to true. Was confused because the properties don't show during creation. You have to select the freshly created reference and open it's property dialog | 11:44.50 |
| Robin_Watts | gah. how dumb. | 11:50.04 |
| paulgardiner | Still, I think that's sorted the problem. Thanks for all the help. | 11:52.00 |
| Robin_Watts | mvrhel_laptop: Was there another version of the paper to read? | 13:44.41 |
| mvrhel_laptop | Robin_Watts: not yet. The last data run finished after I went to bed :) | 13:45.04 |
| | give me a couple hours here | 13:45.12 |
| Robin_Watts | mvrhel_laptop: Ah. No worries. | 13:45.18 |
| mvrhel_laptop | to get the data extracted and plotted | 13:45.22 |
| | and get everyone out the door.... | 13:45.33 |
| Robin_Watts | Will be interesting to see if the CPU frequency changes make any difference. | 13:45.48 |
| mvrhel_laptop | yes | 13:48.17 |
| Robin_Watts | urgh. the threshold integration with gs appears to work in page mode, but not banded mode. I bet there is some screwy verical offset I need to fudge in somehow. | 13:49.49 |
| | The ty for the matrix in the first band is 0. | 13:53.15 |
| | In the second band it's -3539. I would have expected a +ve number. | 13:53.44 |
| mvrhel_laptop | yes there is an offset for that | 13:54.58 |
| | I remember that problem | 13:55.10 |
| Robin_Watts | yeah, I'm damned if I can see it though :( | 13:57.21 |
| | mvrhel_laptop: Oh, and when you get a free moment (after dealing with family, breakfast etc), can I talk to you about screens please? | 14:00.29 |
| mvrhel_laptop | aha! | 21:42.23 |
| | I had used the wrong Altona file in one of my tests | 21:42.33 |
| | that explains the issues... | 21:42.40 |
| Robin_Watts | mvrhel_laptop: If one of the Altona tests is giving an 80% increase rather than a 40% one, can we use that instead? :) | 22:30.05 |
| | Ok, I've fixed the halftonining integration, but it's just dawned on me that I didn't write the color cache code :) | 22:59.26 |
| | And the phases over bands are broken. | 23:00.06 |
| | Forward 1 day (to 2018/03/31)>>> | |
Log of #mupdf at irc.freenode.net.