| | <<<Back 1 day (to 2012/04/22) | 2012/04/23 |
| mvrhel | marccosw: could you go ahead and grab the two files tests/ps/gray-to-cmyk-with-transfer.ps.psdcmyk.72.0 | 03:37.45 |
| | from my last bmpcmp | 03:37.51 |
| | apparently, the other files that I mentioned for you to grab were ok and my browser was not refreshed | 03:38.19 |
| | thank you | 03:38.33 |
| | Robin_Watts: no there is still something wrong. look at 152 for example. | 03:43.53 |
| | in compare 2 | 03:44.00 |
| | basically all the ps files are like this | 03:44.07 |
| | oh weird | 03:44.32 |
| | there is some issue | 03:44.35 |
| | I will have to take a closer look at this tonight | 03:44.54 |
| kens | Hmmm, I wonder if I need to rewrite pdfwrite so that it uses FreeType. At the moment it seems that it uses the Artifex code for TrueType fonts. | 06:58.10 |
| chrisl | For doing what with Truetype fonts? | 07:03.35 |
| kens | Its building information for pdfwrite, its calling teh flyph_info proc of the font for a given glyph | 07:04.02 |
| | Which seems to load nad use the Artifex TT font code, including (in this case) a 'spot analyser' for TrueType grid fitting.... | 07:04.39 |
| chrisl | Hmm, it may be problematic getting the glyph data you need out of freetype..... | 07:05.28 |
| kens | Ah, well in that case we can't deprecate the old Artifex code :-( | 07:05.47 |
| ray_laptop | kens: why do we care (that much) which font rendering is used for pdfwrite | 07:05.48 |
| kens | ray_laptop : its not rendering | 07:06.03 |
| | And I care because it means we will have to keep the Artifex TrueType code supported | 07:06.21 |
| ray_laptop | kens: if we are just using it to get outlines, then they should both get the same info | 07:06.23 |
| kens | ray_laptop : (why are you still awake ?) if as chrisl says I c an't get the info from FreeType, then I need us to keep the Artifex code. | 07:07.00 |
| | chrisl I am calling the font->procs.glyph_info method | 07:07.33 |
| ray_laptop | kens: I thought we need to keep the AFS code anyway for when we have the UFST | 07:07.36 |
| chrisl | ray_laptop: that's not true, either, since freetype implements all the bytecode ops, whilst the AFS code doesn't - the outlines *may* differ | 07:07.46 |
| kens | ray_laptop : Really ? I thought UFST handled TrueType. | 07:07.55 |
| chrisl | kens: I'll have a proper look later on, see if we might be able to extend FAPI in some way to retrieve what's required. | 07:08.45 |
| kens | chrisl seems I'm after the glyph width, bbox and 'num pieces' | 07:08.56 |
| | chrisl don't spend any time on it at present | 07:09.35 |
| ray_laptop | chrisl: true, but the artifex code only subsets the bytecode ops because we wanted to jump the gun on the patents -- now the AFS bytecode interpreter can be brought up to the "full" implementation -- equivalent to (or same as) freetype | 07:09.42 |
| chrisl | ray_laptop: then what was the point of integrating freetype? | 07:10.05 |
| kens | So we cna ship two interpreters instead of 1 :-) | 07:10.33 |
| ray_laptop | we licensed the FT bytecode interpreter BEFORE the patent expired to support the Dynalab fonts | 07:10.36 |
| chrisl | kens: we can definitely get the first two of those (we need them for rendering), but what is "num pieces"? | 07:11.00 |
| kens | chrisl I have no idea :-( | 07:11.16 |
| ray_laptop | chrisl: we wanted the FT font rendering engine because it is faster than the AFS implementation | 07:11.19 |
| kens | But I assume it relates to composite glyphs | 07:11.28 |
| | chrisl give me a second to run a grep | 07:12.16 |
| ray_laptop | chrisl: kens: but if the FT library can give us everything we need, I have NO objection to deprecating the AFS font scaler | 07:12.33 |
| kens | ray_laptop : we certainly can't do so until we have FT for the other languages anyway | 07:12.58 |
| ray_laptop | in particular the 'no dropout' fixed_adjust = -1 HACK is really a performance hit | 07:13.06 |
| kens | I simply hadn't realised it was being used still by pdfwrite | 07:13.14 |
| chrisl | I'm pretty sure Freetype can give us what kens needs - I suspect that UFST can't - but UFST+pdfwrite is of very limited use anyway | 07:13.59 |
| kens | chrisl from gxfont.h: | 07:14.36 |
| | #define GLYPH_INFO_NUM_PIECES 8 | 07:14.37 |
| | int num_pieces; /* # of pieces if composite, 0 if not */ | 07:14.37 |
| | We use it for type 1 fonts too | 07:15.12 |
| | Presumably for SEAC | 07:15.21 |
| chrisl | very obvious name! I would be surprised if we can't retrieve that from Freetype - as I say, I'll take a look later today. | 07:15.55 |
| kens | NP chrisl | 07:16.05 |
| | I wouldn't worry too much right now as we can't ditch the Artifex code right now anyway. | 07:16.27 |
| | But its somethign to bear in mind for the future. | 07:16.35 |
| chrisl | Yeh, I'd like know *whether* we can do it, even if we're not right now | 07:17.00 |
| kens | :-) | 07:17.06 |
| | chrisl found another good one over the weekend. | 07:17.48 |
| | CMaps; there is code to allocate them (and ToUnicode CMaps which are more complex) but ther eis no code to free them. | 07:18.10 |
| | Since these are compound structures containing other allocations, and they are not garbage collected, they leak totally. | 07:18.31 |
| | And in the case of a ToUnicode CMap, that cna be a lot. | 07:18.42 |
| ray_laptop | Robin_Watts: (for the logs). No rush on the ARM performance benchmarking -- until we get their test files, it might be a futile exercise | 07:26.45 |
| | my daughter was out 3 days last week and just finished up her missed homework, so I'm heading to slumber land.. | 07:27.59 |
| | g'nite, all | 07:28.07 |
| norbertj | kens: On UFST handling TT. As far as I know the ufst build in ghostpdl does not use the tt. Henrys is still to implement this. The tt-fonts were passed to afs not ufst. | 07:40.48 |
| | A couple of years ago I ask henrys to add tt support also to the ufst (mod in pl-fontapi?) | 07:43.08 |
| | But I think he did not yet implement this. | 07:43.21 |
| kens | norbertj Currently only the PS/PDF interpreter uses either FreeType, so we wouldn't be changing until that is extended to the other languages anyway | 07:43.46 |
| chrisl | norbertj: we're going a slightly different route with that, now: we current the Font API (FAPI) which is Postscript/PDF only, and provides an abstraction layer between GS and any font rendering library. I'm (gradually) working to make that interpreter independent, so it can be used for all the languages. | 07:44.09 |
| kens | At the same time UFST would work as well, since they use the same font API | 07:44.11 |
| chrisl | wot kens said.... | 07:44.23 |
| kens | Only chrisl said a better explanation | 07:44.36 |
| Robin_Watts | Morning all. | 09:14.52 |
| | tor8: So, I'm hoping you've not done any tagging/building of exes over the weekend? | 09:15.23 |
| tor8 | Robin_Watts: I haven't. | 09:15.35 |
| Robin_Watts | cool. We should look into the new freetype/zlib before we do. | 09:15.51 |
| kens | Hi Robin_Watts | 09:16.00 |
| | Robin_Watts : did you notice that your fix to avoid leaking the stack in page loading seemed to introduce a seg fault ? (or assertion) | 09:16.49 |
| Robin_Watts | I noticed at 1:30am last night. | 09:17.10 |
| kens | Ah, OK | 09:17.14 |
| | As long as you know about it I can safely forget it :-) | 09:17.33 |
| Robin_Watts | When I looked at deltas before, 99% of the indeterminisms were on macpro. | 09:19.02 |
| | The other 1% were on feet. | 09:19.11 |
| | And this one was on feet too, I think. | 09:19.18 |
| kens | Umm, could be. | 09:20.22 |
| | Well it was either feet or henrysx6 | 09:20.43 |
| | tests_private/comparefiles/Bug692174.pdf.ppmraw.200.0 mupdf henrysx6 feet Seg_Fault | 09:20.55 |
| tor8 | I see you already tackled the compiler bug issue thing that popped in over the weekend as well | 09:21.05 |
| Robin_Watts | tor8: In so far as "It's a compiler bug, and nothing we can do about it". | 09:21.35 |
| tor8 | yeah. enough to know we don't have to worry about it for 1.0. | 09:21.55 |
| Robin_Watts | kens: No seg fault seen on peeves. | 09:24.45 |
| kens | Well, I only wanted to make sure you'd seen it.... | 09:25.03 |
| Robin_Watts | yeah. it would be nice to fix though... | 09:25.28 |
| | Having no indetermisms is a very nice position to be in. | 09:25.44 |
| | or would be... | 09:25.48 |
| kens | true | 09:25.53 |
| Robin_Watts | Ah, deltas show it was miles that had problems, not feet. | 09:26.54 |
| Bo98 | In MuPDF for Android, I've noticed that if the document fails to open, the application will crash. If you look at 'public void onCreate(Bundle savedInstanceState)' in MuPDFActivity.java then 'core' will stay as 'null' if the file fails to open. Look at the third 'if (core == null)'. As you can see 'core' stays as 'null' which will cause in multiple NullPointerExceptions. | 09:27.42 |
| Robin_Watts | Urm... it's supposed to leave core = null, because it didn't load anything, right? | 09:30.15 |
| | Where do the exceptions occur ? | 09:30.31 |
| Bo98 | Everywhere where it uses core | 09:33.05 |
| | *or at least most places | 09:33.26 |
| | For example: if (core.hasOutline()) { in createUI | 09:33.53 |
| | because core == null, NullPointerException | 09:34.17 |
| Robin_Watts | So... there is no way in onCreate to signal that the creation failed ? | 09:34.39 |
| Bo98 | Well I did sort of fix it with try & catches in the places where it crashes. | 09:35.54 |
| Robin_Watts | (Sorry, it's been AGES since I looked at this) | 09:36.03 |
| Bo98 | eg. mPageNumberView.setText(String.format("%d/%d", index+1, core.countPages())); Crashes because core == null, | 09:36.33 |
| | but if you catch the NullPointerException you can set it like mPageNumberView.setText("0/0"); or something | 09:36.53 |
| Robin_Watts | Right, but ideally we should NEVER call onMoveToChild in the core == null case. | 09:37.14 |
| sebras_ | Robin_Watts: androidsdk: You can call finish() from within this function, in which case onDestroy() will be immediately called without any of the rest of the activity lifecycle (onStart(), onResume(), onPause(), etc) executing. | 09:37.28 |
| Robin_Watts | sebras_: Perfect. | 09:37.45 |
| Bo98 | I was meaning the line in updatePageNumView | 09:37.50 |
| Robin_Watts | Bo98, so if we add a finish() after the alert.show() in onCreate, does that solve it ? | 09:38.42 |
| Bo98 | Hmm, well we need to warn the user that the app will close. | 09:39.02 |
| Robin_Watts | Is that not what the alert does? | 09:39.29 |
| | Or does the finish mean the alert doesn't get displayed? | 09:39.41 |
| Bo98 | We already have it called finish() when the user dismisses the alert but the rest of the application is running in the background | 09:39.50 |
| | if you look at alert.setButton | 09:40.08 |
| | in onCreate | 09:40.58 |
| Robin_Watts | Maybe we should call destroy ? | 09:41.00 |
| Bo98 | It will still only run if you click the button unless you put it after alert.show() but the app will close without warning, | 09:42.07 |
| | unless there is someway to 'pause' the app until the user presses the button? | 09:42.54 |
| Robin_Watts | Ok, so I have a possible fix. | 09:44.48 |
| | B98: http://ghostscript.com/~robin/MuPDFActivity.java | 09:45.28 |
| | Bo98: Does that solve it ? | 09:45.37 |
| Bo98 | I'll have a look | 09:45.58 |
| | What bit did you change? | 09:46.55 |
| Robin_Watts | I added various if (core == null) return; things to back out of functions before they use core. | 09:47.15 |
| Bo98 | Should do I'll test it. | 09:47.58 |
| naveen_ | Hi Robin, Morning.. | 09:48.49 |
| Robin_Watts | naveen_: Morning. | 09:48.58 |
| | Did you have any luck with your code ? | 09:49.07 |
| naveen_ | read_encrypt_file is rendering only table layouts(in the pages that have tables) with out any text...remaining pages are blank..You can have alook at the function here http://pastebin.com/BTVx5nMC | 09:49.11 |
| | I know this code is not efficient but I want to make it work first..then improve the efficiency... | 09:49.48 |
| Robin_Watts | naveen_: I'd add some debug to your code. Print out the locations it seeks to, and the data it reads each time. | 09:50.32 |
| | It should then be easy to step through the real file, and spot where it's failing. | 09:50.52 |
| | i.e. at some point it must be seeking somewhere and then reading, and be getting the wrong results. | 09:51.21 |
| naveen_ | while debugging, stm->pos is actually showing be a pos greater than file size... | 09:51.26 |
| Bo98 | Robin_Watts, sorry I have to go out now but I'll test the code as soon as I come back. It looks ok at a glance though. | 09:51.28 |
| Robin_Watts | Bo98 - OK, would be good to know so I can get the fix into 1.0 before we release later today. | 09:51.53 |
| | naveen_: Well, that doesn't sound right... | 09:52.26 |
| Bo98 | Robin_Watts I'll report back. | 09:52.30 |
| Robin_Watts | Bo98: Many thanks! | 09:52.42 |
| | I'm off for a run. back in an hour or so. | 09:53.37 |
| naveen_ | where does the muPDF get the file length from? | 09:54.26 |
| | is it from header or the actual file size? | 09:54.41 |
| Robin_Watts | naveen_: it does a seek(stm, 0, SEEK_END); | 09:59.14 |
| naveen_ | can I modify it to take the value I want to set | 09:59.50 |
| | because my file size is not the actual pdf size | 10:00.26 |
| Robin_Watts | naveen_: Then you should modify the value you return from seek_encrypted_file | 10:00.50 |
| | mupdf calls fz_seek(xref->file, 0, 2); which comes to you as: seek_encrypted_file(stm, 0, 2); | 10:01.41 |
| | You should ensure that you return the length of the requested file there, not the length of the real file. | 10:02.06 |
| naveen_ | ok got that..will try that.. | 10:02.22 |
| Robin_Watts | (In general, you should subtract the length of any header you have from the value given by lseek) | 10:02.25 |
| naveen_ | ok.. | 10:02.52 |
| Robin_Watts | kens, tor8: I think the delta display is wrong. | 10:06.05 |
| | It *was* running on feet. | 10:06.23 |
| kens | The seg fault ? Yes I posted the regression line | 10:06.54 |
| Robin_Watts | I reran the cluster test and got: | 10:07.12 |
| | The following 1 regression file(s) have stopped producing errors: | 10:07.20 |
| | tests_private/comparefiles/Bug692174.pdf.ppmraw.200.0 mupdf feet inches Seg_Fault | 10:07.23 |
| kens | So last run was feet (which also failed) this run is inches, and it failed too | 10:07.52 |
| Robin_Watts | no. | 10:08.09 |
| | As I read it, the last run was inches, and that STOPPED failing (i.e. didn't crash) | 10:08.25 |
| kens | Oh yes, misread it | 10:08.35 |
| Robin_Watts | So the delta display is wrong, it seems. | 10:08.47 |
| kens | But yes, I knew the last failed run was on feet | 10:08.49 |
| Robin_Watts | damn. ipod flat. need to charge it before I run. | 10:14.01 |
| | Let's fix the deltas. | 10:14.12 |
| | Oh, stupid me. THe deltas display was right - I'm just incapable of resizing a browser window. | 10:37.12 |
| | back. | 11:55.15 |
| | tor8: Want I should make a new thirdparty.zip ? | 12:14.00 |
| | or are you doing that? | 12:14.14 |
| kens | Hmm 4 cluster machiens are down.... | 12:14.48 |
| | I think 2 of them are at the office, not sure about the other 2, Marcos's home maybe ? | 12:15.17 |
| Robin_Watts | miles/kilometers are at miles'. | 12:15.36 |
| kens | Yes, but feet & meters are at Marocs's ? | 12:15.53 |
| Robin_Watts | Yes. | 12:16.03 |
| | So maybe nocal has dropped off the map ? | 12:16.09 |
| kens | Wasa bout to suggest that : -) or San Francisco anyway | 12:16.29 |
| tor8 | Robin_Watts: I just started doing it. | 12:17.13 |
| Robin_Watts | hmm. At least 5 of the nodes run the exact same gcc as feet. | 12:17.33 |
| tor8 | Robin_Watts: are there any changes in jbig2dec that I should port over as well? | 12:17.46 |
| Robin_Watts | gcc (4.4.3-4ubuntu5.1) 4.4.3 | 12:18.06 |
| | tor8: Not that I'm aware of. Let's look. | 12:18.14 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=history;f=gs/jbig2dec;h=cca4b9ea124fb8abd72984a35aeae0c8c62a5a08;hb=b40ce1e58c211008831971f3866cb49e912a1e4f | 12:19.17 |
| | So Shailesh made changes in feb.. | 12:19.25 |
| tor8 | zlib is still at 1.2.6, I recall you had some problems with that version? | 12:19.52 |
| kens | Ah, the cluster machiens seem to be back online | 12:20.14 |
| Robin_Watts | tor8: ooh, your memory is better than mine. That does ring a bell. | 12:20.32 |
| tor8 | Robin_Watts: right. I should port those over to the maste jbig2dec.git | 12:20.36 |
| Robin_Watts | tor8: OK. I shall leave this to you then. Yell if there is anything you'd like me to look at. | 12:21.05 |
| vtorri | Robin_Watts: which problems with 1.2.6 ? | 12:24.49 |
| tor8 | bah. now I forgot the invocations to git format-patch and git am to do the patch with different directory structures | 12:25.36 |
| Robin_Watts | vtorri: I don't remember offhand. | 12:30.56 |
| | Let me try it again. | 12:31.04 |
| chrisl | Robin_Watts: http://ghostscript.com/irclogs/2012/01/30.html look at ~15:49hrs | 12:35.50 |
| Robin_Watts | You need to pull in gzwrite.c and gzlib.c too, because it insists on linking with a gzflags function. | 12:38.28 |
| | Yes. I think we should skip 1.2.6 | 12:38.58 |
| | I'll send the maintainers an email so they can offer us a config flag in later versions. | 12:39.20 |
| | lunch. | 12:40.19 |
| | re Bo98 | 13:09.38 |
| vtorri | Robin_Watts: there API changes in zlib 1.2.6 ?? | 13:10.34 |
| Robin_Watts | They have introduced a new dependency. | 13:10.54 |
| | previously the gz functions of zlib were independent of the rest and didn't get built in unless you needed them. | 13:11.15 |
| | Now they get pulled in too. | 13:11.22 |
| vtorri | ha | 13:12.00 |
| | because of your static linking of the deps | 13:12.10 |
| Robin_Watts | However we do it, the dependency is the same. | 13:12.34 |
| sebras_ | vtorri: I belive those functions would be compiled and linked into the library anyway. | 13:12.37 |
| Robin_Watts | It's just obvious because we use our own makefile. | 13:12.49 |
| | Bo98: Did those changes solve the android crashes ? | 13:26.53 |
| vtorri | Robin_Watts, sebras_ : then, you will never upgrade zlib ? because i don't think that the next versions will change that design | 13:28.43 |
| Robin_Watts | vtorri: I've just sent an email to the maintainers. We'll see what they say. | 13:29.05 |
| | There are a couple of very simple things they can do to solve it. | 13:29.16 |
| | 1) They could put the gzflags function in it's own file. | 13:29.28 |
| | 2) The could offer a ZLIB_NO_GZ flag to avoid it at build time. | 13:29.43 |
| | 3) They could roll gzflags into zflags. | 13:29.57 |
| | 4) they could move the gzflags into the same file as zflags. | 13:30.09 |
| | all of those would make no odds to them, but would solve the additional bloat caused by that dependency. | 13:30.33 |
| Bo98 | Robin_Watts: Sorry I was having lunch, just give me 2 minutes. | 13:33.05 |
| Robin_Watts | np. | 13:33.11 |
| | Hey scott-san | 13:34.49 |
| scott-san | Good morning | 13:35.02 |
| | I've got nothing, just checking in to see what's up?? | 13:35.20 |
| | Alas, good evening Robin. | 13:35.46 |
| Robin_Watts | scott-san: Nothing huge. We're hoping to release MuPDF today (or tomorrow if we run out of time) | 13:35.58 |
| | MuPDF 1.0 that is. | 13:36.06 |
| scott-san | OK, Well then, good luck and see you next Sunday at Hook Norton. | 13:36.49 |
| sebras_ | Robin_Watts: did you upgrade freetype? or there were no benefits in doing so? | 13:38.04 |
| | to make sure it's not forgotten. | 13:38.16 |
| Robin_Watts | scott-san: My postcode is OX15 5LY, and we're 22 Hollybush Road. | 13:38.18 |
| | You'll need that for a sat nav or google maps or whatever. | 13:38.31 |
| | sebras_: tor8 is taking care of that, I believe. | 13:40.02 |
| sebras_ | Robin_Watts: oh. | 13:40.13 |
| scott-san | Got it Robin. Adios. | 13:40.40 |
| Bo98 | Robin_Watts: Okay I think I know why the crashes happened in the first place. I was using it in a Fragment Application (Fragments basically are to support more dynamic and flexible UI designs on large screens). The way UI is created in Fragment is a little different. Instead of setting it through onCreate (createUI is called from onCreate) you set it though the method onCreateView, which meant that the return at the end of 'if (core | 13:41.22 |
| | did nothing since onCreateView would still get called after onCreate. However adding 'if (core == null) return;' at the beginning of createUI would fix the problem as it then does not matter whether createUI is called in onCreate or anywhere else. I don't think you need to add it anywhere else apart from createUI. | 13:41.25 |
| | So the android application works as it is atm unless you convert it to fragment. | 13:42.13 |
| Robin_Watts | Bo98: Well, belt and braces - my existing fixes won't hurt. | 13:42.36 |
| | I'll commit that, thanks. | 13:42.40 |
| Bo98 | np | 13:42.48 |
| Robin_Watts | pushed. | 13:45.02 |
| Bo98 | Good :) | 13:45.12 |
| kens | chrisl your latest change seems to cause an awful lot of seg faults. | 13:55.01 |
| chrisl | kens: looking at it now | 13:55.13 |
| kens | All on henrysx6 interestingly | 13:55.22 |
| vtorri | Robin_Watts: i don't see your mail in the zlib ML. Or you send it directly to Mark ? | 14:00.11 |
| Robin_Watts | zlib@gzip.net | 14:00.42 |
| | zlib@gzip.org sorry. | 14:01.06 |
| vtorri | you should use zlib-devel@zlib.net | 14:01.25 |
| | but you must subscribe first | 14:01.34 |
| Robin_Watts | I followed the instructions on the webpage. | 14:01.41 |
| vtorri | strange | 14:03.21 |
| | ha | 14:04.42 |
| | questions about using zlib : zlib@gzip.org | 14:05.00 |
| | questions about the dev of zlib : zlib-devel@zlib.net | 14:05.15 |
| Robin_Watts | "Mark and Jean-loup can be reached by e-mail at zlib@gzip.org." | 14:06.20 |
| vtorri | yes | 14:06.32 |
| | http://zlib.net/mailman/listinfo/zlib-devel_madler.net : | 14:06.59 |
| | Please do not subscribe to this list in order to get answers to questions about zlib or to provide comments about zlib. Send those directly to the authors at zlib@gzip.org | 14:07.52 |
| | it means what i said above | 14:08.01 |
| | you're asking a question about the dev of zlib | 14:08.29 |
| | the development of zlib* | 14:08.42 |
| | i said that because using zlib-devel@zlib.net, you're sure that you'll reach the devs and testers | 14:11.49 |
| Robin_Watts | Well, I'll wait to see if I get a response from Mark/Jean-loup before spamming them again. | 14:13.19 |
| vtorri | Jean-Loup is not working on zlib anymore | 14:15.52 |
| | Mark is the only maintainer | 14:16.00 |
| chrisl | kens: I *think* I've fixed it, based on valgrind output - but it's not code I had changed....... | 14:55.42 |
| Robin_Watts | vtorri: Just heard back. Apparently it's fixed in the latest beta. | 15:05.54 |
| | yeah, they've rolled gzflags into zflags. | 15:07.13 |
| | So we'll just wait for 1.2.7 | 15:07.22 |
| | Hey marcosw. | 15:12.16 |
| marcosw | morning Robin_Watts | 15:12.25 |
| Robin_Watts | Could you rescue me a couple of bmpcmp files from mvrhel's last run please? | 15:12.35 |
| marcosw | sure, what file? | 15:12.45 |
| henrys | for the logs: I did have one thing for the meeting tomorrow - have a look at the last tech agenda and see if a little progress can be made on the projects before the meeting or at least be prepared ot talk about the highest priority project listed at the end of the followup. | 15:12.45 |
| vtorri | Robin_Watts: ok | 15:13.06 |
| Robin_Watts | marcosw: tests/ps/imagemask-with-pattern.ps.psdcmyk.72.0 | 15:14.06 |
| | henrys: So... you're travelling tomorrow, but not arriving until friday ? | 15:14.36 |
| kens | chrisl maybe your change just exposed it | 15:14.42 |
| henrys | Robin_Watts:no I'm traveling thursday, I'm taking off a couple days before the trip. | 15:15.45 |
| marcosw | Robin_Watts: I'll have to re-run mvrehl's last bmpcmp, the cluster has started a new job and the previous output files have been removed. | 15:16.10 |
| chrisl | kens: yeh, I think that's likely - I'm surprised it didn't come up in the clusterpush | 15:16.22 |
| Robin_Watts | marcosw: Ah, ok. | 15:16.23 |
| | henrys: I thought you were connecting via Tokyo or something :) | 15:16.41 |
| henrys | I could do a couple laps around with that amount of time. | 15:17.16 |
| mvrhel | good morning | 15:32.53 |
| kens | Morning Michael | 15:33.00 |
| henrys | hi mvrhel | 15:33.21 |
| Robin_Watts | morning mvrhel. Marcos is retrieving the images for tests/ps/imagemask-with-pattern.ps.psdcmyk.72.0 for me. | 15:34.19 |
| mvrhel | ok great. | 15:34.36 |
| | I would like to have a look at them too | 15:34.47 |
| | Robin_Watts: the bmp compare is different | 15:40.45 |
| | this time | 15:40.47 |
| | was it correctly run? | 15:40.55 |
| | or should I do another kick off | 15:41.16 |
| Robin_Watts | marcosw ran it. | 15:41.18 |
| mvrhel | ok. but the compare.html shows no diffs | 15:41.34 |
| marcosw | mvrhel: the tests__ps__imagemask-with-pattern.ps.psdcmyk.72.0 files are the same, is there an indetermism? | 15:41.48 |
| mvrhel | hehe | 15:41.54 |
| | no I think something else must be a miss | 15:42.00 |
| marcosw | mvrhel: never mind, my fault | 15:42.07 |
| Robin_Watts | marcosw: Shall we let mvrhel rerun, and then nominate a file ? | 15:42.27 |
| mvrhel | I will just do it | 15:42.33 |
| marcosw | sounds good. | 15:42.35 |
| ray_laptop | morning, all | 15:44.12 |
| mvrhel | good morning ray_laptop | 15:44.25 |
| henrys | ray_laptop:feeling better? | 15:44.39 |
| ray_laptop | henrys: yes. Feeling great today | 15:45.03 |
| | henrys: do you want me to look at norbert's PCL file ? | 15:45.20 |
| henrys | well I asked marcosw to bisect it, because I'm working on the agenda today. I think that will tell all we need. | 15:46.03 |
| ray_laptop | henrys: I'm familiar enough with tracking memory leaks | 15:46.09 |
| henrys | have at it if you want - tell marcosw you are working on it. | 15:46.47 |
| marcosw | henrys: I'm here (and sort of paying attention). | 15:47.03 |
| ray_laptop | marcosw: BTW, I don't have the mysql password, unless that is the bugzilla password | 15:47.49 |
| henrys | they don't say anything for months and they report a bug just before my vacation. | 15:48.21 |
| marcosw | ray_laptop: no, it's different (at least it should be). I kind of thought that it might be lost, which is why I mentioned resetting it. | 15:48.30 |
| ray_laptop | marcosw: but I have no problem with you setting a new password | 15:48.36 |
| | marcosw: I assume you will cc a few of us on what the new password is | 15:49.06 |
| marcosw | when did we hire those guys to do the bugzilla migration? They should have needed it to set up the new mysql bugzilla database. | 15:49.31 |
| ray_laptop | marcosw: I don't recall, but I think it was 3 yrs ago or more | 15:52.03 |
| marcosw | that's sounds right, so presumably Ralph gave it to them. I have to leave Peet's and drive the last 10 miles to campus, will be back online in 15 minutes. | 15:53.10 |
| ray_laptop | mvrhel: looks like you are getting pretty close to wrapping up the planar spot color stuff | 15:54.54 |
| | Robin_Watts: I assume you saw the email from Tsutomo-san that mentions that they are using PS, not PDF. At least that tells me it isn't the 'easy' problem of eliminating the 'copy to tempfile'. | 15:57.17 |
| Robin_Watts | ray_laptop: I did. I haven't done anything on the timings yet. Was waiting (as instructed) until they have a test file. | 16:01.29 |
| ray_laptop | Robin_Watts: I checked the info from cust 532. On their 750MHz PPC the gs init time + first text page parse to clist time is only 1.2 seconds, so I can't imagine why a 1.2GHz ARM would take so long for initialization | 16:02.17 |
| | Robin_Watts: if they don't come through with their test files (because they are confidential or something) with their next email, I'll make a multi-page PS file that we can benchmark and send to them. Maybe one of the sicence fair reports from my kids or something. | 16:04.52 |
| Robin_Watts | I use pdf_reference17.pdf :) | 16:05.09 |
| | Oh, but a ps file, right. | 16:05.20 |
| ray_laptop | Robin_Watts: we can always 'print' a PDF file to a PS printer and save to a file | 16:06.05 |
| chrisl | If only we had a way to convert PDF to PS.... hmmmmm...... | 16:06.24 |
| ray_laptop | chrisl: I was thinking of going through a Windows print driver in order to more closely match what people get from the 'real world' (at least Windows) | 16:07.19 |
| | chrisl: when we do PDF to ps2write it doesn't look at all like what comes from Windows | 16:07.55 |
| | (since it is mostly a PDF file with a PS procset to interpret it) | 16:08.15 |
| chrisl | ray_laptop: But the PS from the Adobe driver can produce *very* different output depending on the printing application - unless we get one of the tests the customer is talking about, we're pretty much in the dark - other than the init time, which is the same for any file. | 16:09.09 |
| kens | Huh, the airport shuttle for teh Heathrow hotel costs £4. :-( | 16:09.24 |
| chrisl | kens: if we get the timing right, I could pick you up at Heathrow. | 16:10.19 |
| kens | chrisl thanks, what time are you planning to get there ? | 16:10.36 |
| | I've yet to check buses... | 16:10.44 |
| ray_laptop | chrisl: I agree that the output from Windows can be very different depending on the application. The init time can vary too depending on how many procsets are loaded, and one thing that can slow down the first page more than subsequent pages is loading several fonts that then hang around for later pages | 16:11.10 |
| chrisl | kens: In "good time" for the meeting start | 16:11.19 |
| kens | :-) | 16:11.23 |
| | I was planning to ge to the airport by 9am | 16:11.32 |
| | leaving 30 minutes to get to the hotel. | 16:11.42 |
| chrisl | Where does the coach drop off? | 16:12.00 |
| kens | Heathrow bus station | 16:12.13 |
| | Central Bus Station | 16:12.21 |
| chrisl | I assume it's well signposted? | 16:12.29 |
| ray_laptop | kens: thanks for the warning about the shuttle cost. I'll make sure and have some £'s when I go to the shuttle | 16:12.32 |
| kens | ray_laptop : Was a surprise to me... | 16:12.45 |
| | chrisl I certainly hope so :-) | 16:12.53 |
| ray_laptop | kens: yes, but presumably you don't go there without any £'s (just US $) | 16:13.23 |
| kens | ray_laptop : I could easily not have any £ coins. | 16:13.43 |
| chrisl | ray_laptop: I just think that the PS has *so* much variability, we're kind of hobbled without an illustrative example from the customer. | 16:13.44 |
| kens | Anyway, time to go, night all | 16:14.02 |
| ray_laptop | chrisl: which is why the first thing I asked Tsutomo-san for was his files | 16:14.18 |
| chrisl | kens: I'll aim to be nearby at ~9 you can call/txt when you arrive, of if any problems arrise. | 16:14.21 |
| ray_laptop | bye, kens | 16:14.24 |
| kens | chrisl I'll get you a better time shortly. | 16:14.38 |
| | Need to book my coach trip, I'll let you know then | 16:14.51 |
| chrisl | Okay | 16:14.59 |
| | ray_laptop: sure, it's just, I'd not waste any time on it until the test job comes through. | 16:15.14 |
| Robin_Watts | Hmm. There are two Holiday Inns at Heathrow :( | 16:17.04 |
| chrisl | Miles did give us an address | 16:18.02 |
| henrys | Robin_Watts:Miles sent out mail identifying which one. | 16:18.04 |
| Robin_Watts | yeah. we're at the smaller, more southerly one. | 16:18.23 |
| marcosw | Robin_Watts: I see mvrhel's bmpcmp is done. Do you have a test file you'd like to look at? | 16:23.09 |
| Robin_Watts | tests/eps/big-multi-source.eps.psdcmyk.300.1 ? | 16:23.41 |
| | mvrhel may have a better idea, but that one looks typical to me. | 16:24.15 |
| mvrhel | that one is fine | 16:25.22 |
| Robin_Watts | Actually... tests/eps/big-multi-source.eps.psdcmyk.72.0 might be better | 16:25.24 |
| | (Same problem, just smaller files) | 16:25.33 |
| mvrhel | ok sounds good | 16:25.38 |
| marcosw | I just put the big-multi-source.eps.psdcmyk.300.1 files onto casper in ~marcos, I'll do the 72 dpi one as well | 16:26.46 |
| | okay, the tests__eps__big-multi-source.eps.psdcmyk.72.0.gz files are on casper as well. | 16:29.08 |
| Robin_Watts | I can't see them... | 16:30.30 |
| mvrhel | hmm. I saw them a sec ago | 16:31.18 |
| | and now they are gone | 16:31.21 |
| | marcosw... | 16:32.14 |
| marcosw | huh? | 16:32.19 |
| Robin_Watts | Where are the files again? | 16:32.34 |
| marcosw | oops, I'm an idiot. give me a sec :-) | 16:32.50 |
| | okay they are back | 16:33.24 |
| | to transfer them to casper I had to first move them to my home machine then when they were on casper I rm'd from what I thought was my home machine but was in fact casper. Luckily there were still on my home machine. | 16:34.39 |
| ray_laptop | mvrhel: are you here aorund ? | 16:35.26 |
| mvrhel | yes. ray_laptop | 16:35.49 |
| Robin_Watts | At first glance, those files look very different. | 16:37.26 |
| | The header is the same, then the C plane is solid ffff in the baseline one, many different values in the new one. | 16:37.54 |
| ray_laptop | mvrhel: now that I'm feeling better, I'm back to the 'part 2' of avoiding pdf14 transparency for part of the page in clist mode. I'd like your opinion: is a bbox for where transparency is actually needed enough, or should it be band byt band | 16:37.56 |
| Robin_Watts | a bbox per band? | 16:39.15 |
| ray_laptop | mvrhel: When the painting is to the page level (outside any transparency group) I want to avoid pushing the pdf14 device at all | 16:39.19 |
| Robin_Watts | And if it's a null bbox then don't push the device ? | 16:39.52 |
| mvrhel | ray_laptop: that is fine. the only issue is for softmasks. the bbox of the parent transparency group may define the region depending upon the background content | 16:40.53 |
| ray_laptop | Robin_Watts: getting the rendering inside a box that has some transparency to EXACTLY match with rendering done without the pdf14 compositor is a bigger task | 16:40.57 |
| Robin_Watts | mvrhel: And it looks (with a VERY rough test) that the scanline values repeat in the new__ files, which explains the stripey thing. | 16:41.09 |
| mvrhel | Robin_Watts: hold on I am trying to get a look at the files | 16:41.32 |
| | ok file is screwed up | 16:43.07 |
| ray_laptop | mvrhel: right. That was what we discussed (was it last week or the week before). I already put in the patch to only do that for SMasks that were NOT from an image since those don't really do ANY painting outside the image | 16:43.13 |
| mvrhel | so, I need to figure out why it runs fine on my build and not there | 16:43.23 |
| marcosw | Robin_Watts and mvrhel: I've modified the cluster code so that for 72 and 75 dpi tests the bitmaps for the new and the baseline code are both rsync'd to the cluster (in the ~regression/cluster/bmpcmp directory). These files tend to be small but if it's a performance issue I'll remove this feature. | 16:43.41 |
| mvrhel | it also seemed to be ok on my linux release build but I need to double check that Robin_Watts | 16:43.46 |
| Robin_Watts | mvrhel: OK. Let me know if I can help out. | 16:44.03 |
| mvrhel | Robin_Watts: thanks. it is clearly my issue. | 16:44.17 |
| | I need to work on my talk for Wednesday.... | 16:44.24 |
| | ray_laptop: I think you are going to have to worry about patterns with transparency drawn in paths too | 16:45.14 |
| | you are going to need to create a bbox with that includes all paths drawn with transparency | 16:45.48 |
| marcosw | I'm running another mvrhel bmpcmp job, to test the copying of the bitmaps. | 16:46.20 |
| Robin_Watts | mvrhel: If you want to work on your talk, I could try to reproduce the issue. | 16:47.31 |
| ray_laptop | mvrhel: paths painted to the page level that happen to have been created using transparency features just 'paint' to the page level don't they (assuming alpha == 1.0). | 16:47.45 |
| Robin_Watts | It could be just an uninitialised variable or something. | 16:47.48 |
| mvrhel | right | 16:48.04 |
| | Robin_Watts: let me take a quick look with valgrind | 16:48.29 |
| | ray_laptop: no, not patterns with transparency | 16:49.16 |
| ray_laptop | mvrhel: doesn't the alpha of the pattern get flattened before filling a path ? or is it retained and applied when painting to the page level ? | 16:49.25 |
| mvrhel | they are painted into another group | 16:49.28 |
| | there has to have been a "master" pdf14 device pushed | 16:49.53 |
| | or drawn in their own group | 16:50.22 |
| ray_laptop | mvrhel: by master, you mean the same as I call 'page level', right | 16:50.31 |
| | ? | 16:50.33 |
| mvrhel | yes | 16:50.35 |
| | the alpha is not flattened | 16:50.52 |
| | it is merged in | 16:51.04 |
| | and a new alpha value is retained | 16:51.19 |
| ray_laptop | mvrhel: OK, but there will have been a transparency group to tell us what BM to use, right ? | 16:51.28 |
| mvrhel | yes. | 16:51.53 |
| ray_laptop | mvrhel: I plan on updating the bbox(es) when we push transparency group (or mask) | 16:52.30 |
| mvrhel | that should work. | 16:53.00 |
| | ray_laptop: but how do you "rewind" to make sure the device is pushed first? | 16:53.38 |
| | that is during clist writing | 16:53.44 |
| | you are adding group pushes | 16:53.51 |
| ray_laptop | of course that doesn't address the issue where the group bbox is bogus (full page). For that I'd have to ignore the transparency group bbox and just collect the bbox when things are painted | 16:53.52 |
| mvrhel | and other stuff and now you want to go back and make sure to push the pdf14 device only in those bands | 16:54.24 |
| | but that has to precede the other compositor actions | 16:54.43 |
| ray_laptop | mvrhel: I'm thinking that we the clist writer will write all the compositor actions AND collect the bbox(es). Then during the playback, if the current band is unaffected, SKIP ALL pdf14 compositor actions | 16:55.13 |
| mvrhel | oh | 16:55.30 |
| | gotcha | 16:55.33 |
| | that should work | 16:55.36 |
| ray_laptop | whew! | 16:55.42 |
| mvrhel | just make sure you let the overprint get through | 16:56.19 |
| ray_laptop | mvrhel: right -- it would only be fore pdf14 compositor actions | 16:56.56 |
| marcosw | Robin_Watts: okay, bmpcmp jobs now transfer the raw 72 and 75 dpi bitmaps back to casper. They are stored in the ~regression/cluster/bmpcmp directory and have names such as tests__ps__uncolored_pattern.ps.psdcmyk.72.0.baseline.gz and tests__ps__uncolored_pattern.ps.psdcmyk.72.0.new.gz. I don't know if you want to do to the trouble of modifying pngs2html to copy these to the bmpcmp web site, but in any case, they are easier for everyone to get | 17:00.41 |
| | Note that the files are volatile, the next cluster job will remove them. | 17:00.41 |
| Robin_Watts | I could copy them, and then make the bmpcmp images point to the originals. | 17:01.50 |
| | does casper have the (virtual) disc space for that though? | 17:02.03 |
| marcosw | Robin_Watts: disk space isn't a problem at the moment. If this ends up being an issue we can use the ephemeral storage that comes with the instance (currently we don't use it at all since it's wiped during a reboot, but that wouldn't be a big issue for bmpcmp output). | 17:05.12 |
| | All: I'm going to reset the mysql password on casper. This will mean that bugzila will be down for a few minutes. | 17:06.19 |
| mvrhel | valgrind did not help. comparing what my linux build creates vs. the cluster it is weird. the image data from the cluster is garbags | 17:06.22 |
| | the header is ok | 17:06.31 |
| marcosw | All: change of plans. My 10:00 meeting just showed up, so I won't get to this until later. | 17:07.36 |
| mvrhel | Robin_Watts: If you want to take a look I can email you the massive patch | 17:08.55 |
| Robin_Watts | Sure. | 17:09.05 |
| mvrhel | Robin_Watts: ok. thanks. I sent you the patch | 17:13.29 |
| | now I will work on this talk | 17:13.40 |
| ray_laptop | hmm... I need to fix the bogus band_complexity passing BEFORE I can pass the per-band transparency bbox info correctly. Oh, well ... it's overdue. | 17:25.13 |
| mvrhel | maybe you can add some enums objects in place of the magic numbers | 17:26.14 |
| ray_laptop | bbiaw... | 17:26.18 |
| mvrhel | ray__laptop.. | 17:26.23 |
| marcosw | All: mysql root password update and sent out in email to tech@. | 18:00.18 |
| Robin_Watts | mvrhel: I've got it being reproduced. | 18:08.40 |
| mvrhel | Robin_Watts: oh great! | 18:08.58 |
| Robin_Watts | mvrhel: OK... got a mo? | 18:47.02 |
| mvrhel | Robin_Watts: yes about 5 minutes. | 18:48.22 |
| Robin_Watts | I've found the problem. | 18:48.32 |
| mvrhel | wife is waiting for me to eat | 18:48.34 |
| | oh good | 18:48.36 |
| Robin_Watts | gdev_mem_set_planar | 18:48.48 |
| | in gdevmpla.c | 18:48.53 |
| | it gets called with the number of planes, and the plane depth details. | 18:49.07 |
| mvrhel | ok | 18:49.12 |
| Robin_Watts | It then runs through and sets up the planes, and as part of that, checks that none of them overlap. | 18:49.21 |
| mvrhel | overlap where ? | 18:49.37 |
| Robin_Watts | The plane data says how to pack them into a gz_color_index. | 18:50.02 |
| | each plane has a number of bits, and a shift to apply. | 18:50.15 |
| mvrhel | right | 18:50.21 |
| Robin_Watts | The problem is we have 14 components in this file, each with 8 bits. | 18:50.43 |
| | Doesn't fit in a 64bit int. | 18:50.51 |
| | and with C's funky shifting behaviour, we detect an overflow. | 18:51.17 |
| | sorry, we detect an overlap when there isn't one. | 18:51.27 |
| mvrhel | I wonder why I dont see the issue | 18:51.39 |
| Robin_Watts | What I'm going to do is to disable the checking if the stuff would shift out of range. | 18:51.48 |
| | because shifting by more than the size of the thing you are shifting is undefined in C, | 18:52.03 |
| mvrhel | I see | 18:52.23 |
| Robin_Watts | so windows may not give the same as linux. | 18:52.28 |
| mvrhel | well, I get the same ok result in my linux and windows run | 18:52.43 |
| Robin_Watts | We don't need to pack down into a gx_color_index any more. | 18:52.51 |
| mvrhel | just the cluster output was funky | 18:52.54 |
| | Robin_Watts: right | 18:53.01 |
| Robin_Watts | 64bit linux? | 18:53.05 |
| mvrhel | yes 64 bit | 18:53.10 |
| Robin_Watts | so the packing shouldn't matter. | 18:53.17 |
| | may be a different compiler version or something then. | 18:53.24 |
| mvrhel | right | 18:53.27 |
| | ok so thank you for finding this | 18:53.35 |
| Robin_Watts | so I'll just disable the checking and hope we get the right results. | 18:53.44 |
| | no worries. | 18:53.46 |
| mvrhel | I don't know if I could have found it since I cant replicate it | 18:53.47 |
| Robin_Watts | I'm ssh'd onto macpro :) | 18:53.58 |
| mvrhel | made it about 1/2 way through my slides too | 18:54.01 |
| Robin_Watts | cool. Enjoy your lunch. | 18:54.12 |
| mvrhel | Robin_Watts: so is this something you are going to commit to the trunk? | 18:54.34 |
| Robin_Watts | Yeah, why not. | 18:54.46 |
| mvrhel | ok cool | 18:54.49 |
| | just wanted to understand what I needed to do | 18:55.01 |
| | ok I will be back in a bit | 18:55.22 |
| Robin_Watts | mvrhel: pushed. | 19:09.28 |
| | I'll start a cluster test and a bmpcmp to see if it made a difference. | 19:09.37 |
| | tor8: ping ? | 19:21.46 |
| tor8 | Robin_Watts: sebras here... tor3 will be here shortly. | 19:22.11 |
| Robin_Watts | Hi sebras/tor. | 19:22.27 |
| tor3 | Robin_Watts: pong | 19:22.28 |
| tor8 | Robin_Watts: hi. | 19:22.35 |
| Robin_Watts | Was just wondering what the state of play was ? | 19:22.37 |
| tor3 | belly full, ready to build 1.0 | 19:22.49 |
| tor8 | I think all of us are eager to get 1.0 out the door. | 19:22.52 |
| tor3 | I am tor. | 19:23.17 |
| tor8 | I am not tor. | 19:23.17 |
| Robin_Watts | Makethird doesn't mention ftcache.c | 19:24.53 |
| | but android/jni/ThirdParty.mk does. | 19:25.08 |
| tor3 | we don't use the ftcache | 19:25.18 |
| Robin_Watts | I'm sure that will be fixed by you moving to freetype2.49, right? | 19:25.24 |
| | being called by helen. bbs. | 19:25.50 |
| tor3 | I guess I can remove that line before tagging 1.0[ | 19:26.04 |
| Robin_Watts | hmm.I think there are lots of lines to remove | 19:29.56 |
| | Interestingly, we don't link type1cid.c in the android case. | 19:31.47 |
| | and yet it links OK. | 19:31.51 |
| | and there is too much in the jpeglib too. | 19:33.08 |
| | and zlib. | 19:35.06 |
| | I clearly just added all the files :( | 19:35.12 |
| mvrhel | Robin_Watts: is the push and bmpcmp that you are doing with my patch? | 19:48.52 |
| Robin_Watts | yes. | 19:49.02 |
| mvrhel | oh ok | 19:49.04 |
| | I will abort my run then | 19:49.12 |
| | thanks | 19:49.30 |
| Robin_Watts | mvrhel: Something has killed my test. | 19:57.01 |
| mvrhel | uh oh | 19:57.18 |
| Robin_Watts | I'll abort mine, and you start one. | 19:57.59 |
| mvrhel | ok | 19:58.05 |
| tor8 | Robin_Watts: we'll remove local.properties from the android build files. | 20:24.31 |
| | Robin_Watts: since it contains installation specific paths, we ought to make sure not to add it again. | 20:25.02 |
| | and I'm still sebras... | 20:25.13 |
| mvrhel | Robin_Watts: you still there? | 20:35.40 |
| | bbiaw | 20:40.18 |
| Robin_Watts | mvrhel: back. | 20:50.54 |
| | tor8: Its been added and removed several times. | 20:51.04 |
| | I reckon we should leave it in as local.properties.sample so people can edit it ? | 20:51.39 |
| tor3 | that would be acceptable | 20:52.37 |
| | Robin_Watts: http://mupdf.com/download/mupdf-1.0-windows.zip | 20:57.21 |
| Robin_Watts | mvrhel: bmpcmp looks to be better. 146 looks like a progression? | 20:57.23 |
| | works for me. | 20:58.13 |
| | Are you interested in trying upx ? | 20:58.35 |
| | upx -9 --ultra-brute worked well for me. | 20:59.18 |
| | I'm being called by Helen, so I'd better go. | 21:00.05 |
| | mvrhel: I'll check back in in a bit. I'll be here in around 2 hours or so for a while. | 21:00.25 |
| tor3 | paulgardiner (for the logs): the android app has stopped searching when you hit "enter" in the search field | 21:18.51 |
| | paulgardiner: also, rotating the device drops the highlights. | 21:21.21 |
| | we ought to fix at least the first problem before tagging and building 1.0 | 21:21.42 |
| mvrhel | thanks Robin_Watts: it does look much better. I need to look at number 646 | 22:53.37 |
| | and 884 | 22:55.33 |
| | and 979 | 22:57.50 |
| Robin_Watts | hi | 22:58.22 |
| mvrhel | I do see a few progressions too | 22:58.25 |
| | I am very close now I think | 22:58.29 |
| | need to run kids to piano, then I will work on the above files tonight after I finish up my talk slides | 22:58.51 |
| | Robin_Watts: | 22:58.57 |
| | question for you | 22:59.01 |
| marcosw | mvrhel: should I go email the customer and say a new version will be ready tonight :-) | 22:59.12 |
| mvrhel | marcosw: no | 22:59.23 |
| marcosw | :-( | 22:59.30 |
| mvrhel | Robin_Watts: and idea why I get this new warning gdevmx.$(OBJ): extra dependency on $(MAKEDIRS) | 22:59.54 |
| | i copied what was done for the other mem devices | 23:00.11 |
| | but if you look in the list of new warning you will see this as a New makefile issue | 23:00.24 |
| | need to bo | 23:00.30 |
| | go | 23:00.32 |
| | bb later | 23:00.36 |
| Robin_Watts | mvrhel: We have a script that checks that all dependencies listed are justified. | 23:04.41 |
| | and presumably your patch has an unwarranted one. | 23:04.56 |
| | Ah, right. Possibly you can ignore that. | 23:10.45 |
| | I suspect that the Makefile checker gives those warnings, and you've just added another new one. | 23:11.09 |
| | mvrhel: I'm off to bed. Let me know if you'd like me to look for some of the SEGVs or something. | 23:45.22 |
| | Forward 1 day (to 2012/04/24)>>> | |
IRC Logs