| | <<<Back 1 day (to 2013/12/30) | 2013/12/31 |
| Robin_Watts | tor8: (For the logs) Checking the repair logic again... | 10:22.29 |
| | The only place I refuse to skip strings is when looking for "xx xx obj" | 10:22.46 |
| | when we actually try to repair an object, we accept strings normally there. | 10:23.02 |
| | so we'd be fine with 10 0 obj\n(Hello)\nendobj | 10:23.19 |
| linukso | hey, good job with mupdf | 11:03.04 |
| | I've seen it on the xfce's recommendations | 11:03.24 |
| Robin_Watts | linukso: really? | 11:13.25 |
| linukso | Robin_Watts, really | 11:14.15 |
| Robin_Watts | hmm, so I see. Didn't know about that. | 11:14.25 |
| linukso | although we have this memory issue, mupdf uses heap for storing the pages ? | 11:16.12 |
| Robin_Watts | Where else would it store the pages? | 11:16.31 |
| linukso | Robin_Watts, where else it would be possible | 11:16.50 |
| | it seems that you forget to free() it | 11:16.59 |
| Robin_Watts | No, we don't forget to free it. | 11:17.07 |
| | Stuff stays in a store for reuse. | 11:17.17 |
| linukso | could be a memory leak so | 11:17.21 |
| | http://wiki.xfce.org/pt-br/recommendedapps | 11:17.30 |
| Robin_Watts | So the problem is probably just that the store is larger than you'd like. | 11:17.43 |
| | Whenever people complain about this, we go and check for leaks and it always turns out that people aren't understanding the store. | 11:18.13 |
| linukso | Robin_Watts, man, mupdf almost used 3 GB here | 11:18.27 |
| Robin_Watts | So, do a memento build, run it, and then on exit, it will list the leaked blocks. | 11:18.52 |
| linukso | Robin_Watts, so you're aware of this problem? | 11:19.16 |
| | I think it happens just with me | 11:19.24 |
| | don't know | 11:19.26 |
| Robin_Watts | no, as far as we are aware there are no leaks. | 11:19.44 |
| | If there were, a memento build would show them. | 11:19.51 |
| linukso | I'm not sure if it is a leak, but it is using much memory | 11:20.06 |
| | I'll debug | 11:20.16 |
| Robin_Watts | linukso: Sure. Look for the call to fz_new_context in x11_main.c | 11:20.30 |
| | That passes in the store size to use. | 11:20.44 |
| | Try setting that to 1 (for 1 byte). | 11:20.52 |
| | Then see if the memory usage drops. | 11:20.59 |
| linukso | Robin_Watts, ok | 11:21.04 |
| | I build it with all the security options on gcc, could be that too | 11:22.22 |
| | It isn't, and it isn't -O3 too | 11:36.02 |
| Robin_Watts | I wouldn't expect the optimisation level (or security settings) to make a fundamental change to the memory things require. | 11:37.42 |
| | I can see we're in for a wacky 48 hours of [Global Notice] fun here. | 11:40.03 |
| linukso | Robin_Watts, I've just received one | 11:43.11 |
| | xI | 11:43.16 |
| | xDÇ | 11:43.19 |
| | man... | 11:43.22 |
| | Yeah, it seems It'll really have to debug, later I came with results, it'll be long | 11:44.01 |
| Robin_Watts | yes, we all did. We're doomed to a day of messages from wacky funster admins who think they are Gods gift to comedy. | 11:44.17 |
| | linukso: The first thing to do is to try knocking the store size down to 1 byte. | 11:44.36 |
| | Then try a memento build and see if it reports leaked blocks. | 11:44.50 |
| linukso | I'll follow your advice | 11:45.02 |
| Robin_Watts | ok. if you do find that it's leaking, do let us know. | 11:45.17 |
| | Morning tor8 | 12:17.54 |
| tor8 | Robin_Watts: morning. how's your git-cvs job coming along? | 12:18.34 |
| | I started one just for epage yesterday and it's still running :( | 12:18.44 |
| Robin_Watts | Did the first pass... then died because nec-lookclub-branch is defined twice. | 12:19.01 |
| | so I've tried to delete that branch and am retrying. | 12:19.11 |
| tor8 | it's probably spending 99% of cpu time printing warning messages though :( | 12:19.20 |
| | in retrospect, shouldn't have run with -v... | 12:19.35 |
| | invalid patchset, tag dcs-2-0-beta-8-release, etc | 12:20.17 |
| Robin_Watts | If this fails, then I will have to try with some judicious --excludes | 12:22.15 |
| tor8 | oh... might be because my /home is filled up to the brim :( | 12:22.21 |
| Robin_Watts | Did you see my burbling earlier? | 12:23.58 |
| | My revised repair logic is OK. | 12:24.08 |
| | The only place I refuse to parse strings is when hunting for the next 10 0 obj | 12:24.24 |
| | When we've found a valid 'obj' and we then repair it, we still accept strings. | 12:24.43 |
| | So 10 0 obj\n(Hello)\nendobj will still be fine. | 12:24.59 |
| | but 10 0 obj\n((((\nendobj will still cause us to skip bits of the file. | 12:25.25 |
| | So my code is an improvement, but it's not perfect. | 12:25.33 |
| | but I still think we should commit it, because it gets us closer to being right, and who knows when/if we'll ever come up with a perfect one. | 12:26.28 |
| tor8 | my .xsession-errors is 13G of "xterm: This should not happen. Why is it so?" | 12:27.51 |
| | re the string parsing in repair, yes | 12:27.51 |
| | why not an even simpler lexer that only finds numbers and "obj", less chance of other errors then? | 12:27.54 |
| | I guess I don't like the amount of copy&paste between the lexer functions | 12:28.20 |
| Robin_Watts | tor8: Well, it's numbers, obj, xref, and <<, I think. | 12:29.28 |
| | tor8: I did ponder about a param for 'repair mode' or something, but cutting/pasting was nicer, I thought. | 12:30.30 |
| | but I'm prepared to be convinced. | 12:30.42 |
| tor8 | I don't really have a strong opinion, that code is pretty stable so the risk of duplicate bugs is fairly low | 12:31.23 |
| Robin_Watts | tor8: Did you have an opinion on 694863 ? | 13:29.36 |
| | sebras_: ping ? | 13:59.17 |
| tor8 | Robin_Watts: wouldn't it be easier to just keep the existing already loaded objects in the xref when doing a repair? | 14:10.45 |
| Robin_Watts | tor8: Only if we can safely assume that we'll never replace one with better guess. | 14:11.19 |
| | but that's worth considering. | 14:11.47 |
| | I will try that after lunch. | 14:24.10 |
| henrys | tor8, Robin_Watts anything happening with cvs 2 git? | 14:58.17 |
| Robin_Watts | henrys: First attempt was killed by marcos. | 15:10.21 |
| | second attempt died with an error after a long time. | 15:10.30 |
| | so I've had a go at correcting that and am retrying. | 15:10.43 |
| | I'm working on peeved now, so it's faster. | 15:11.55 |
| henrys | Robin_Watts: what was the error? | 15:12.10 |
| Robin_Watts | The nec-lookclub-branch supposedly had several versions of the same file tagged. | 15:12.48 |
| | so I deleted the branch :) | 15:13.04 |
| | lcms is dying with clist stuff :( | 15:13.45 |
| henrys | so that could happen 50 more times⦠| 15:13.49 |
| Robin_Watts | henrys: It could. but if it turns into a repeating problem, I'll try converting just the trunk. | 15:14.12 |
| henrys | Robin_Watts: you mean new lcms marti is working? | 15:14.53 |
| Robin_Watts | Not with the clist it seems. | 15:15.06 |
| | but that's probably a problem on my end, not his. | 15:15.20 |
| henrys | Robin_Watts: oh I though peeves was upgraded to xeon but /proc/cpuinfo says i7's | 15:16.30 |
| Robin_Watts | peeved, not peeves. | 15:16.44 |
| henrys | Robin_Watts: oh so peeved is in ray's office? | 15:17.38 |
| Robin_Watts | henrys: I believe so. | 15:17.47 |
| | I thought peeved was ray's uber server thing, like the ones that marcosw bought. | 15:18.04 |
| | but then I guess they'd have to be 4 machines, not just 1. | 15:18.32 |
| henrys | I meant to ask him about noise. I read some articles about replacing fans with some effect. | 15:18.38 |
| Robin_Watts | They are only 2U servers. | 15:19.02 |
| | Most fan replacement things involve putting large slow fans in in place of small fast moving ones. | 15:19.29 |
| | but with a 2U server you are limited in scope. | 15:19.41 |
| | I guess you could machine the top plate of the server and put large slow fans on there sucking the air out. | 15:20.17 |
| | If you weren't going to rack mount it, I mean. | 15:20.39 |
| | henrys: So, from the net it seems that the C6100's have 4 fans in the middle of the unit. | 15:46.00 |
| | This sucks air in from the front, over the hard drives, then forces it out the back over the CPU heatsinks etc. | 15:46.47 |
| | It tops out at 77db. | 15:47.05 |
| | Supposedly a simple fan replacement will get you down to ~50db | 15:52.36 |
| linukso | Robin_Watts, well, I checked somethings and, the problem just happens at gentoo | 16:36.02 |
| | Robin_Watts, thanks man for the help | 16:36.18 |
| Robin_Watts | faster than a speeding ken. | 16:36.48 |
| | tor8: ping | 16:40.17 |
| tor8 | Robin_Watts: pong. | 16:51.05 |
| Robin_Watts | I'm confused by the repair code. | 16:51.16 |
| | I can't see where we ever rewrite existing objects. | 16:51.41 |
| tor8 | Robin_Watts: yeah, neither am I... | 16:54.48 |
| Robin_Watts | OK, so I'm going to go back to zeniko and see if he can give me an example where the repair damages something. | 16:55.16 |
| tor8 | I would have expected the for loop that initialises the entries to zero them out | 16:55.23 |
| | but now I see that it only touches 'f' type entries | 16:55.35 |
| Robin_Watts | The file he gave in the bug doesn't seem to use-after-free. | 16:55.54 |
| | So maybe this is all just a misunderstanding ? | 16:56.02 |
| tor8 | I think we probably should ask paul, everything has changed from how I remember it working since the incremental update rework he did | 16:56.34 |
| | but from what I read, I don't see how we could ever free an old obj like zeniko says | 16:58.19 |
| | so yeah, let's get a file from him (and ask paul what he thinks) | 16:58.33 |
| Robin_Watts | tor8: So I ran through the mupdf bugs. | 17:03.58 |
| | Or all the recent ones at least. | 17:04.04 |
| | I've dealt with the ones I felt able to. | 17:04.16 |
| | There are some fonty/character encodey/x buildy ones that I felt I should leave to you, and some androidy/formy ones I've left to Paul. | 17:04.45 |
| | lcms2 stuff seems to all be working now. | 17:08.44 |
| | I've reported a couple of small things back to Marti, mostly simple, but one potential nasty. | 17:09.05 |
| | tor8: So, my current works in progress are: | 17:10.39 |
| | 1) The JNI stuff; this is blocked on the rebind stuff which we need to talk to sebras_ about. | 17:10.59 |
| | 2) The mesh speedups. The first part of that requires you to make a change to the opengl version, the second part we need to sort out an API we are happy with for the cached color converter. | 17:11.43 |
| | 3) The improved repair logic (no strings) | 17:11.56 |
| | Can 3 go in as is for now? | 17:14.52 |
| | and for 2) if I make fz_get_cached_color_converter and fz_free_cached_color_converter be init and fin, are you happy with that? | 17:15.28 |
| | Did you want us to make the ctx available to the convert functions too? | 17:15.42 |
| | tor8: ping? | 17:37.34 |
| tor8 | Robin_Watts: 3 can go in as is for now. with init/fin naming I think I'm happy with that. | 18:42.08 |
| | and it looks like we already make the ctx available to the conversion functions... | 18:43.34 |
| | but I'm not sure I understand why we have two separate sets of colorspace conversion functions | 18:45.08 |
| | gray_to_rgb antd g2rgb are the same but take different arguments... | 18:45.22 |
| | oh wait, nvm | 18:49.25 |
| henrys | Robin_Watts: is your friend interested in working for artifex if we became the app vendor? | 19:05.56 |
| | Robin_Watts: we can go private if you want | 19:06.14 |
| | Robin_Watts: just mulling over things it makes sense for us to hire and be the app vendor. You get something that cheaply it's foolish not to give it a go. Doesn't work we pull the plug. | 19:26.01 |
| Robin_Watts | henrys: Which friend? | 20:35.53 |
| | Rory works for JP Morgan - their interest is primarily in getting the rights to be able to use the code as part of the apps they develop in house that are used by their traders, and customers of the bank. | 20:36.58 |
| henrys | the immediate idea was rory but I think we just need 1 full time person capable with the code - presumably you and Paul would wok on it a bit and we're in the apps business. | 20:37.12 |
| Robin_Watts | Being able to keep selling the app, and to be able to sublicense is just a sideline for them I think. | 20:37.44 |
| | I don't think Rory would be interested in working for Artifex. He's managing twenty programmers for JP Morgan, and that number is set to rise threefold or so over the next couple of years, AIUI. | 20:38.40 |
| | Now, Alex might be capable of getting us into the app business. | 20:39.09 |
| henrys | Robin_Watts: yes I'm confusing rory with someone else was it Alex? | 20:39.14 |
| Robin_Watts | As people left Picsel over the years Alex stayed on. He therefore has experience of a wider range of the code than anyone else. | 20:39.42 |
| | Certainly he'll know more of the hoops to jump through towards getting us a build than anyone else I know. | 20:40.23 |
| | Certainly Picsel were making reasonable money from the sale of the app (supposedly enough to support a few engineers full time). Miles mentioned a figure this morning that sounds plausible. | 20:42.16 |
| | But the question comes as to whether that will continue. With various people having perpetual licenses, you have to figure on their being fragmentation of that market. | 20:42.59 |
| | Alex is working for Bipartate Ltd now, a company set up specifically to support people that have perpetual licenses. | 20:43.57 |
| | They don't have rights to the code themselves currently, but they can work for people that do have rights. | 20:44.18 |
| henrys | Robin_Watts: sure that's a risk. It still seems like a no brainer given what we paid for the technology. We can pull the plug anytime... | 20:44.27 |
| Robin_Watts | They are interested in obtaining rights to the code, so I've suggested that they consider licensing from us. | 20:45.11 |
| | What we've paid so far gets us the code. It doesn't get us the website and the rights to the SmartOffice name etc. | 20:46.03 |
| | We'd have to pay more for that - and how much more determines whether it's still a no brainer or not. | 20:46.19 |
| | If we did want to get into the app selling business, then I'd be tempted to get bipartate ltd to do us the build and the support. | 20:46.49 |
| henrys | Robin_Watts: I was thinking of rebranding it. | 20:47.12 |
| Robin_Watts | That way we get the benefit of their experience. If it works out, we can maybe fold them in. If not, we part ways amicably and they remain in a position to support other customers. | 20:47.41 |
| | We could launch a rebranded build, sure. | 20:47.59 |
| henrys | I am also assuming the open source threat will make licenses unattractive but that remains to be seen | 20:48.17 |
| Robin_Watts | but again, I'd be tempted to get bipartate ltd to do that build for us. Time to market etc. | 20:48.20 |
| | Indeed. | 20:48.30 |
| henrys | Robin_Watts: how many at bipartite now? | 20:48.47 |
| Robin_Watts | Certainly I'd not be prepared to spend big bucks on a license when someone else has the rights to release open source. | 20:48.58 |
| | 2. Alex and Andrew, AIUI. | 20:49.04 |
| | Andrew was also ex-picsel. I don't know him really, but paulgardiner does. Paul speaks well of him. | 20:49.46 |
| | I would imagine bipartate ltd are going to be doing a lot of "can you build us an app with the branding changed?" in the coming months. | 20:50.39 |
| | Everyone that's bought a perpetual license is going to want their app to lose the SmartOffice branding and come 'in house', I guess. | 20:51.15 |
| | I believe it's bipartate, not bipartite (I think the spelling mistake is deliberate) | 20:52.26 |
| | I'm being called to help with dinner. I will keep popping up to check back in. | 20:53.57 |
| henrys | Robin_Watts: sure just thinking out loud | 20:54.13 |
| Robin_Watts | Bear in mind that the Picsel {f,b}ounders have started a new company and are continuing to exploit the source. | 20:58.37 |
| | so there will be a clone app on the store pretty soon (I'd bet). | 20:59.03 |
| | so we'll have competition. | 20:59.19 |
| | You don't need to slice the current income from the app many times before it becomes negligible compared to the support cost. | 20:59.44 |
| henrys | Robin_Watts: I'm proposing just hiring one more person, if you and paul dip into it with time that would have spent working on mupdf so I'm not seeing a lot of cost. | 21:12.31 |
| Robin_Watts | but then who'd do the mupdf work? | 22:08.18 |
| mvrhel_laptop | happy new year Robin_Watts | 23:43.05 |
| Robin_Watts | mvrhel_laptop: Thanks. And you. | 23:46.38 |
| | Forward 1 day (to 2014/01/01)>>> | |
IRC Logs