| | <<<Back 1 day (to 2012/10/28) | 2012/10/29 |
| mvrhel | henrys: are you there? | 03:46.52 |
| | the microsoft build 2012 conference that I was wait listed has opened up | 03:56.36 |
| | http://www.buildwindows.com/ | 03:57.00 |
| | that is, they have a spot for me now. the cost is a bit high though. ($2000). I left a message with miles to double check if he was fine with this but have not heard back from him. I need to go ahead and do it if I am going to get the slot | 03:58.20 |
| | henrys: let me know what you think | 03:58.35 |
| henrys | mvrhel:that's fine. | 04:07.41 |
| mvrhel | ah thanks for getting on henrys. After I missed the first sign up I didnt want to miss this one | 04:08.18 |
| | as it starts Tuesday | 04:08.22 |
| | ok. so I am in. hopefully it will be an informative meeting | 04:11.03 |
| | I guess they waited until the last possible day to add in local people. making travel plans would be hard with this short of notice | 04:12.23 |
| | hmm. maybe I should register for the Hackathon. You get to build a windows phone 8 app. | 04:13.11 |
| henrys | do you have a windows-like phone? | 04:24.25 |
| | I got the nexus 7 pretty impressive tablet. | 04:25.03 |
| | bbm (be back monday) | 04:31.15 |
| kens | tor8 I've just chucked an XPS problem your way | 08:38.11 |
| | Just realised I made a mistake testing it, I'm going to test again | 08:39.55 |
| tor8 | kens: okay, I'll make the necessary changes to gxps once you give the ok | 08:42.25 |
| kens | OK well it turns out I was correct, hold off for an hour and I'll just run a cluster test to be sure I haven't broken something else stupidly | 08:49.41 |
| kens | needs coffee to bootstrap brain | 08:55.00 |
| | tor8 I wonder if we do any XPS tests with ps2write on the cluster.... My test came back with no differences. | 09:18.29 |
| | Well, my change fixes the test file for the bug report, though as it leaks memory its no use as a fix. So if you have a good solution, please go ahead and implement it | 09:19.07 |
| sebras | marcosw: there is no robots.txt on git.ghostscript.com which I think might be related to the dos of that domain a few days ago. | 09:49.23 |
| | marcosw: at least there is nothing preventing a webcrawler from exercising gitweb.cgi a lot. | 09:49.44 |
| paulgardiner | tor8: ping | 09:51.21 |
| tor8 | paulgardiner: pong. | 09:51.26 |
| paulgardiner | Hi. Were you happy with those three commits on paulg/master? | 09:52.00 |
| tor8 | paulgardiner: did you change the pdf_run_page thing we discussed? | 09:52.58 |
| paulgardiner | yep | 09:53.04 |
| tor8 | then I'm happy :) | 09:53.30 |
| Robin_Watts | tor8: are you going to push them for paul, or should I? | 09:54.34 |
| paulgardiner | sebras also has on on his master branch which I've reviewed. | 09:55.57 |
| tor8 | Robin_Watts: paulgardiner: I'll push paul's and sebras' patches | 09:56.43 |
| paulgardiner | sebras: come to think of it, what was the behaviour before your patch: crash or missing content? | 09:56.54 |
| | tor8: ta | 09:57.16 |
| sebras | paulgardiner: ehm... what was my patch now again..? | 09:57.18 |
| tor8 | sebras: inheritance | 09:57.34 |
| sebras | paulgardiner: well, not a crash, but we errored out on a document | 09:58.03 |
| | it relied on the font being inherited from the Catalog' AcroFrom dictionary. | 09:58.29 |
| paulgardiner | sebras: I'm just thinking we might want to also protect against da actually being missing. | 09:58.36 |
| sebras | paulgardiner: right, but we did that. | 09:58.54 |
| | if the font could not be found fz_throw() was called and handled appropriately. | 09:59.10 |
| paulgardiner | ok. That's good. | 09:59.11 |
| | Possibly we'd miss displaying later content that would be possible to display, but that's not so bad for a faulty doc | 09:59.54 |
| sebras | I guess we could choose to ignore the annotation completely if it fails to draw, instead of erroring out. | 10:00.11 |
| | paulgardiner: ok, I mean that mupdf exited. but not due to a segfault, due to a fz_throw(). | 10:00.57 |
| paulgardiner | sebras: yeah, it was segfault that I was worrying about. | 10:01.23 |
| sebras | paulgardiner: why did you choose to not catch rendering errors in annotations and ignore them as we do for e.g. images? | 10:02.34 |
| | would that create issues for the js bindings later? (still haven't read up on how that works.) | 10:03.07 |
| paulgardiner | I wasn't aware that I'd changed the erroring behaviour of annotation rendering, but I can quite believe I have. I'll take a look when I get a chance. | 10:04.18 |
| | On the js binding stuff, those are all protected against throws in the wrappers. | 10:04.45 |
| sebras | paulgardiner: I'm not sure you have changed it. I'm just advocating that maybe we should handle rendering errors for annotations the same way as other rendering errors. | 10:07.27 |
| paulgardiner | sebras: yes. Makes sense. | 10:07.57 |
| Robin_Watts | gets 10 spam messages ostensibly from alex. | 11:32.26 |
| | Maybe hurricane sandy is infested with malware too :( | 11:32.43 |
| | Gah. I can't get to artifex.com | 11:42.18 |
| kens | Its OK for me | 11:42.45 |
| Robin_Watts | kens, chrisl, paulgardiner, tor8, anyone else: Can you reach it? | 11:42.46 |
| kens | Did you need something from it ? | 11:43.10 |
| Robin_Watts | I've got to print and read Raphs paper on Even Toned Screening, which, if memory serves, is on artifex.com | 11:43.11 |
| kens | 1 second | 11:43.21 |
| paulgardiner | seems ok here too | 11:43.24 |
| Robin_Watts | Thanks. | 11:43.25 |
| kens | DSon't see the paper there | 11:43.54 |
| chrisl | I'll put it up on casper | 11:44.04 |
| Robin_Watts | chrisl: Thanks. | 11:44.43 |
| chrisl | http://www.ghostscript.com/~chrisl/ei03.pdf | 11:44.55 |
| Robin_Watts | It used to be athttp://www.artofcode.com, but it's gone from there too. | 11:45.08 |
| chrisl | Do you need the source, too? | 11:45.32 |
| Robin_Watts | To the paper? No, thanks. | 11:45.44 |
| chrisl | No, for ets | 11:45.51 |
| Robin_Watts | oh, yes please. | 11:46.23 |
| chrisl | http://www.ghostscript.com/~chrisl/ets_138.zip - has the paper in it, too | 11:47.44 |
| Robin_Watts | Got it, thanks. | 11:48.26 |
| chrisl | NP, I'll be intested to know what you think - I've been meaning to read it for a while | 11:48.59 |
| Robin_Watts | The paper says the source is GNU GPL'd. | 11:55.14 |
| | So why isn't it in git somewhere? | 11:55.25 |
| | (hmm, sounded like a criticism, wasn't meant to) | 11:55.34 |
| chrisl | Erm, ask Raph? | 11:55.58 |
| tor8 | Robin_Watts: it might be stowed away in an old svn repo somewhere | 11:56.10 |
| Robin_Watts | tor8: If it is, could you work your magic on it to make a git version? | 11:56.30 |
| | Aha. | 11:57.14 |
| | http://www.levien.com/artofcode/eventone/ | 11:57.16 |
| tor8 | Robin_Watts: did that solve your problems, or do you want me to start digging through svn repos? | 12:07.32 |
| Robin_Watts | tor8: That was the original website, but it only has a .tgz | 12:08.00 |
| | If there was an SVN repo of it, that would be nicer. | 12:08.12 |
| | but don't feel obliged to waste time on it! | 12:08.22 |
| kens | lunches | 12:08.30 |
| paulgardiner | Robin_Watts, tor8: two more commits on paulg/master when you have a moment. | 12:12.06 |
| Robin_Watts | has never met Raph, but puts a big black mark next to his imagined profile, for using gnu indentation style. | 14:12.41 |
| kens | Raph is an 'interesting' character. | 14:13.38 |
| Robin_Watts | plus a complete absence of error checking (mallocs can never fail!) | 14:13.53 |
| | plus no particular naming style. | 14:14.08 |
| | plus an absence of comments. | 14:14.17 |
| kens | I haven't read his code | 14:14.52 |
| Robin_Watts | maybe the latter is unfair, given the presence of the paper. | 14:15.14 |
| henrys | and we're back for another week of this stuff. | 14:30.52 |
| | Miles is probably still celebrating the Giants swept the Series. | 14:37.39 |
| Robin_Watts | hopes alexcher is busily protecting his house with sandbags. | 14:48.23 |
| | What proportion of our cluster is in his basement (and hence going to be under water in 24 hours time) ? | 14:49.00 |
| henrys | oh geez I didn't even think of that. | 14:50.06 |
| Robin_Watts | The reports I read this morning seemed to indicate that Philly was pretty much going to be ground zero :( | 14:55.59 |
| henrys | wow and I see 90 mph winds - that's a nasty storm. | 14:56.59 |
| | alexcher have you received emergency instructions? I have friends in New York evacuated. | 14:57.42 |
| Robin_Watts | And the storm itself is only moving at 10mph, so it won't 'blow over' quickly. | 14:57.42 |
| henrys | googling I see man in philadelphia house boat to ride out the storm, darwin is always around. | 14:58.47 |
| | this looks really bad - a disaster like Katrina. | 15:08.59 |
| Robin_Watts | OH MY GOD. Starbucks has closed all it's NYC outlets! | 15:09.48 |
| marcosw | sebras: the logs say that we had 18700 access to git .ghostscript.com from a single ip address, 38.97.113.129, at a rate of 5 accesses per second. They don't identify themselves other than "Mozilla/5.0" so I don't think they are a spider. | 15:27.18 |
| Robin_Watts | Were they downloading a .tgz for every revision or something? | 15:32.16 |
| marcosw | Robin_Watts: no, they would download the same file multiple items: | 15:34.21 |
| | HEAD /?p=mupdf.git;a=blobdiff;f=Makefile;h=558489754ab055bca6e4f900b2605883b0adcb5c;hp=28157a0266f3595ea6bd8cbc4b7312d7b344f6e4;hb=ca9f39b1ea1a274fe1d9c86439daba4a2464490d;hpb=cf5f789556391ddeab32e8de6df62b3ef166f401 HTTP | 15:34.50 |
| | and after some number would change to a different revision. | 15:35.19 |
| | always with "f=Makefile" | 15:35.48 |
| | sebras and Robin_Watts: We do have a lot of access from a spider that identifies itself as 360spider, which some suggest should be banned. Over it apparently doesn't respect robots.txt. | 15:36.54 |
| kens | marcosw that IP address resolves to bit9.com who 'provide advanced threat protection' | 15:45.04 |
| | Possibly like the nice people from Sicily. | 15:45.24 |
| Robin_Watts | so if we get someone offering to sell us protection against DOS attacks in the next few weeks, we should be suspicious. | 15:45.40 |
| | http://google.org/crisismap/2012-sandy | 15:49.08 |
| ray_laptop | Robin_Watts: I saw that you were looking into the ETS stuff. BTW, last Tue I posted the 'official' distro site: http://www.artifex.com/ets_138 | 15:54.46 |
| | I assume that chrisl just grabbed that | 15:54.56 |
| Robin_Watts | ray_laptop: Right. I can't reachhttp://www.artifex.com though. | 15:55.11 |
| chrisl | Yeo, that's what I zipped up for Robin_Watts | 15:55.56 |
| ray_laptop | if there was ever any use of a SCCS, I don't know where it would be. In fact, it probably would have been CVS -- maybe svn, but definitely pre-git | 15:56.46 |
| | at the time Raph left, gs was still on CVS | 15:57.15 |
| Robin_Watts | ray_laptop: If we have an archive of the released .zip files we could regenerate a change log of sorts... | 15:57.18 |
| henrys | be prepared for losing the cluster, bugzilla etc. - an amazon data center could easily be downed over the next few days effecting services. I wish bugzilla was distributed like our code. | 15:57.43 |
| Robin_Watts | henrys: we could ask marcosw to move casper to a west coast data centre ? | 15:58.13 |
| | It might mean we didn't have access for a few hours now, but it's better than not having access for a few days later. | 15:58.57 |
| ray_laptop | Robin_Watts: I have previous / other releases, but the 'evenbetter' code in rinkj is older than 138 (133) | 15:59.31 |
| | oops I _don't_ have previous releases | 15:59.46 |
| mvrhel | henrys: so do you want me to look over the ETS stuff too or just Robin_Watts? | 15:59.49 |
| ray_laptop | other than whats in rinkj | 15:59.56 |
| henrys | wonders if everyone is doing that creating problems at westernd data centers. | 16:00.00 |
| ray_laptop | BTW, is there a way to get a log of only the changes that affected rinkj ? | 16:00.18 |
| Robin_Watts | mvrhel: Reading the paper only takes 30-60 mins - it's not that hard an idea. | 16:00.39 |
| mvrhel | Oh I read the paper | 16:00.51 |
| henrys | mvrhel: I think you should both look at it, but you (mvrhel) should own it. But if you guys feel differently let's come up with something else. | 16:00.57 |
| mvrhel | ok I am fine with that | 16:01.24 |
| ray_laptop | Robin_Watts: I agree -- the devil is in the details -- like WHY the values that are baked in work "better", etc. | 16:01.28 |
| Robin_Watts | ray_laptop: I fear a lot of the figures are "I tried it, and I liked this value best". | 16:01.56 |
| | Personally, I can't help feeling that if we're going to sell this, we should strip it back a bit and produce something tidier/better documented. | 16:02.49 |
| ray_laptop | Robin_Watts: right. But we don't even know if that was based on printing on a real (ink jet) printer, or looking at the dithering on a display | 16:02.49 |
| mvrhel | well that is the way a lot of specialized ED methods are developed. Sometimes the methods are also sensitive to dot shape, location, how the weaving is done etc. | 16:03.00 |
| Robin_Watts | ray_laptop: indeed. | 16:03.03 |
| mvrhel | ray_laptop: yes exactly | 16:03.19 |
| Robin_Watts | mvrhel: Right, and I'm not saying that's a bad approach. | 16:03.27 |
| ray_laptop | Robin_Watts: well, Artifex has been selling it (collecting royalties) for > 8 years, and Raph licensed it to people before that. | 16:04.27 |
| Robin_Watts | But we can't expect mathematical reasons behind each value. The best we could hope for was "I selected this value as it looked best when using an epson color stylus on plain paper with a following wind..." etc | 16:04.29 |
| | ray_laptop: Right, but it's not exactly bullet proof code is it. | 16:05.00 |
| | Lack of any malloc failure checking etc. | 16:05.14 |
| ray_laptop | Robin_Watts: I suspect that most of it was tuning done for the Stylus 2200 -- I know that's what Raph had and used to produce 'samples' for Scott to take around and sell. | 16:05.38 |
| henrys | raph was a pretty picky coder, I'm surprised to hear no malloc checing. strange. | 16:07.50 |
| Robin_Watts | and the aligned malloc code will fail on 64bit platforms with 32bit ints. | 16:08.36 |
| | (None of this stuff is showstoppingly bad, just mentioning what I've noticed). | 16:08.52 |
| | IME refactoring code like this is one way to try and ensure you understand exactly what it does. | 16:09.18 |
| mvrhel | I have not looked at the code in detail or built and looked at the output. I will do that today, need to run one errand now. bbiab | 16:14.37 |
| ray_laptop | what the heck is it with people using '-dWRITESYSTEMDICT' ??? | 16:18.33 |
| kens | Monkey see, monkey do.... | 16:18.50 |
| chrisl | used it just the other day..... | 16:20.52 |
| ray_laptop | my respect for chrisl just went down a notch ;-) | 16:21.48 |
| chrisl | :-) It makes it easier to grab stuff from inside fonts...... | 16:22.19 |
| ray_laptop | chrisl: do you really want to emulate customers like Avadhut and Thomas ? | 16:22.27 |
| | ;-) | 16:22.30 |
| kens | Its fine for people who klnow whta they are doing, otherwise we should remove it :-) | 16:22.52 |
| chrisl | ray_laptop: no, definitely not! But I also didn't want to work out a bunch font information "by hand" - much easier to let Ghostscript do it for me..... | 16:23.23 |
| ray_laptop | chrisl: I was just kidding -- real debug work is not what those yahoos were doing (or capable of) | 16:26.19 |
| chrisl | ray_laptop: I'm not very insulted, really! It's the kind of thing that if the command line option weren't there, I'd temporarily hack the source to do what I need. As the option's there, I used it. | 16:29.40 |
| | uh oh, late for squash.... bye! | 16:33.11 |
| Robin_Watts | So, I'm going to stop looking at ETS now and leave it to mvrhel. | 17:01.35 |
| | Unless I get told different. | 17:01.58 |
| henrys | nice job Robin_Watts thank you for having a look. | 17:02.11 |
| Robin_Watts | no worries, was interesting. | 17:02.21 |
| | I wonder if I should push some of it into the tiffscaled devices. | 17:02.37 |
| | OK, so mvrhel and ray_laptop, I spotted something while doing the landscape interpolation work. | 17:03.17 |
| | There is a bit of special case code at the top of the interpolation code that says: | 17:03.39 |
| | if (we are a mono device with < 15 shades, OR we are a color device with < 15 colors) { if (downsampling) use special code else if (upsampling by less than 4) don't interpolate. } | 17:05.48 |
| | BUT in the presence of a pdf14 device, that outside test fails. | 17:06.16 |
| | (because it looks at num_components and max_greys etc) | 17:06.37 |
| | so the presence of transparency within a file can make a difference to the time/quality we get. | 17:08.31 |
| | I plan to fix that by using a devspecop to do the test - please speak up if there is a reason I shouldn't. | 17:09.04 |
| | (i.e. if that test *should* behave differently) | 17:09.27 |
| mvrhel_laptop | Robin_Watts: sounds reasonable to me | 17:10.49 |
| | Robin_Watts: I may drag you back into the ETS stuff after I look this over.... | 17:11.49 |
| Robin_Watts | mvrhel_laptop: Sure. | 17:12.01 |
| ray_laptop | Robin_Watts: mvrhel: I don't know -- it _does_ make sense to not interpolate to less than 4x upscale even if transparency, but I'm not sure we ever want to do anything special to the pdf14 device if downsampling | 17:13.32 |
| | the point of that is to prevent dropout of data when downsampling, but transparency (probably) defeats that by altering the gray shade to where stuff would disappear anyway (due to halftoning) | 17:15.03 |
| Robin_Watts | ray_laptop: Well, you can't say that pdf14 => paler colors. | 17:16.37 |
| | cos we have all sorts of blend modes (like Darken etc). | 17:16.56 |
| | We can generate exactly the same range of colors regardless of whether transparency is enabled or not. | 17:18.57 |
| | Therefore, if we choose to behave differently in the case where the target of the rendering is a device with only a few colors, we should do the same regardless of transparency, IMAO. | 17:19.38 |
| henrys | chrisl_away do you know the status of the AIX problem I can't find marcos and have a meeting with the customer. | 17:20.56 |
| | 693387 | 17:22.02 |
| kens | AFAIK marcosw duplicated the problem | 17:24.15 |
| | But that was the last I heard | 17:24.28 |
| ray_laptop | I think the use of Interpolate true to invoke the special downsampling should be replaced with a specop return so that a device can say it wants it (and that can be set by a device parameter if a device wants it to be run-time controlled) | 17:24.30 |
| kens | let me check email | 17:24.37 |
| Robin_Watts | I thought ray_laptop had taken a look at 693387 ? | 17:25.48 |
| kens | marcosw fond the regression commit | 17:26.36 |
| | ray suggested some potential improvements | 17:26.47 |
| | For some reason 8.64 is especially sensitive to this, | 17:27.12 |
| ray_laptop | Robin_Watts: we threw that in for cust 531 (and 700) before we had a specop method, but we can change it and they'll just change from -dDOINTERPOLATE to -dSpecialDownSample=true (or whatever) | 17:27.12 |
| Robin_Watts | ray_laptop: Ugh. | 17:27.34 |
| kens | 9.06 is slower than 8.54, but 8.64 is *much* slower | 17:27.36 |
| Robin_Watts | Do they have their own devices? | 17:27.39 |
| | (531 and 700, I mean, do they have their own devices where they can implement stuff in the dso call?) | 17:28.28 |
| kens | I see fomr Ray's comment that he thinks possibly the 9.06 time is slower than 8.54 possibly because of colour management changes, he could becorrect. | 17:28.29 |
| henrys | we really do owe her an email 5 days ago she asked a question by my read. | 17:29.16 |
| kens | I don't know what to suggest for the bug, Alex had a good reaosn for his commit which introduced the problem. Possibly marcosw needs to do another bisect to fiond out what caused the slowdown to revert. | 17:29.21 |
| ray_laptop | Robin_Watts: they use the tiff device, iirc. But it would be more flexible (and less surprising) to not have files that happen to have Interpolate true when downsampling turn on the special filter | 17:29.35 |
| kens | Its by no means as bad with the current code as with the 8,64 code, so *something* got better | 17:29.48 |
| ray_laptop | kens: we know that ICC color is slower than the older (simple) color management (when not using -dUseCIEColor) | 17:30.33 |
| kens | bbiaw | 17:30.33 |
| | Ray, yes, that was what I was trying to say, marcosw's test was not comparable in that regard | 17:30.56 |
| | But the 9.06 code, even with colour management' was much faster than the 8,64 code without | 17:31.11 |
| | So in some way, the problem they are seeing 'got better' | 17:31.25 |
| ray_laptop | darn. I have to reboot. Something has eaten up my RAM (but it doesn't show on the task manager in the Processes tab). :-( | 17:33.06 |
| mvrhel | Robin_Watts: are you there? | 18:21.21 |
| chrisl_away | henrys: I don't know the status of the AIX problem (the performance issue, I assume), other than there's a bug open (693387). I did ask Marcos if he wanted me to take it over, but I got no reply..... | 19:16.42 |
| Robin_Watts | mvrhel: back, sorry | 19:30.08 |
| henrys | chrisl_away:thanks chrisl_away no problem he's on it and i'm through the meeting | 19:31.18 |
| mvrhel | Robin_Watts: hold on on phone | 19:34.07 |
| Robin_Watts | ok. | 19:34.13 |
| mvrhel | Robin_Watts: so I was curious if you understood how (according to the ETS paper) the term in equation (5) is used with the forward and backward distance calculation. It is not clear to me | 19:41.40 |
| | also, I am running the test_evenbetter code and it takes as input a pgm file and outputs a pgm file. I guess I need to do a bit of work to get it to do some color... | 19:42.19 |
| Robin_Watts | yes, indeed, it looks like it only reads/writes pgms, which is a bit poor. | 19:45.05 |
| | Possibly Raph was really testing this using the rinkj device. | 19:45.29 |
| | If this code just drops in there, that may be the best way to test it. | 19:45.52 |
| mvrhel | ok. I ran a simple pgm in and the pgm out is very strange looking. I need to dig a bit more to see what is going on | 19:47.29 |
| Robin_Watts | Right, that distance term is part of the whole eb_compute_rbscale thing. | 19:47.41 |
| mvrhel | I am not familiar with the rinkj device | 19:47.43 |
| Robin_Watts | me either. | 19:47.51 |
| mvrhel | equation 5? | 19:47.54 |
| Robin_Watts | yeah, sorry, equation 5. | 19:48.11 |
| | He builds this rs_lut table. | 19:49.01 |
| mvrhel | in the paper, i understand that he wants to compute a distance to a placed dot and has an efficient way to do it. it is not clear in the paper how it modifies the threshold nor how equation 5 is used as it is simply 0.95/(gray level squared) | 19:49.26 |
| Robin_Watts | mvrhel: indeed. | 19:49.44 |
| | I follow the requirement for the distance thing, and how the distance thing is efficiently calculated. | 19:50.03 |
| mvrhel | and of course then there is the effect of the error from all the planes, weighted in equation (6). Is this term used to modify all the plane thresholds? | 19:53.33 |
| Robin_Watts | Yeah. The paper is unclear on this. | 19:54.36 |
| mvrhel | ok. so it is not just me then | 19:55.03 |
| Robin_Watts | In order to make progress, I felt I would have needed to start going through his code line by line, adding comments as to exactly what was being held in what table, when. | 19:55.08 |
| mvrhel | I am thinking the same | 19:55.22 |
| Robin_Watts | The problem is, it's hard to tell the optimisations he's made in implementing it from the actual algorithm. | 19:55.41 |
| mvrhel | My worry is that this is going to take some time | 19:55.41 |
| | yes. for that reason I am going to avoid the SSE2 stuff for sure | 19:55.56 |
| Robin_Watts | (and I have some sympathy for him, cos it's the kind of stupid thing I do too :) ) | 19:56.03 |
| mvrhel | sure. but, having a golden slow implementation is nice | 19:56.23 |
| Robin_Watts | mvrhel: Well, how much do you have on your plate at the moment? | 19:56.35 |
| mvrhel | well, I am out all this week because of this microsoft thing | 19:56.51 |
| | starting tomorrow | 19:56.54 |
| | it is all day every day | 19:56.58 |
| Robin_Watts | I think I'm relatively free at the moment, so I could take a first run at it. | 19:56.59 |
| mvrhel | Robin_Watts: if you have the time, that would be great | 19:57.10 |
| | It would be nice if we could get this code checked in someplace | 19:57.20 |
| Robin_Watts | And then you could double check my working/fill in the blanks when you get back from MS. | 19:57.31 |
| | I'll make a git repo with it and put it on casper where we can get to it (privately) | 19:57.52 |
| mvrhel | that sounds good | 19:57.56 |
| Robin_Watts | First version will be this unchanged, and then I might split some stuff out a bit for clarity. | 19:58.12 |
| mvrhel | ok. I may add in my minor changes that have a visual studio solution and a cleaner interface for input and output if you are fine with that | 19:58.49 |
| Robin_Watts | great. | 19:59.01 |
| mvrhel | that is not using stdin and stdout | 19:59.03 |
| | I will wait until you do the check in | 19:59.25 |
| Robin_Watts | That won't be until tomorrow. | 19:59.36 |
| | Will that be a problem ? | 19:59.47 |
| mvrhel | ok. no worries. I am going to grab some lunch | 19:59.50 |
| | and then head down to MS and get my badge and goodies | 19:59.58 |
| | so I avoid the rush tomorrow | 20:00.05 |
| Robin_Watts | ok. have fun. | 20:00.07 |
| mvrhel | Robin_Watts: thanks for helping out with this stuff | 20:00.39 |
| Robin_Watts | no worries, it's interesting. | 20:01.02 |
| | mvrhel: If you get something worthwhile working, feel free to send it to me, and I'll check that in after the vanilla code, and then continue work from that. | 20:10.10 |
| sebras | marcosw: that's really strange. but given that bit9.com is a web-hosting company I guess one of their customers have a hacked server. | 22:40.00 |
| Robin_Watts | http://google.org/crisismap/2012-sandy <- looks like alex might be spared the worst of it. | 22:54.20 |
| malc_ | Robin_Watts, tor8: when doing something like "dlist = fz_new_dlist; dev = fz_new_device (dlist); for (;;) { pdf = pdf_open_doc; page = pdf_load_page; pdf_run_page(pdf, page, dev, identity, NULL); pdf_free_page(page); pdf_close_doc(pdf); }" the memory should not grow indefintely, right? | 23:07.19 |
| Robin_Watts | eh? | 23:07.53 |
| | So you make a display list, then repeatedly open a document and run it to that display list. | 23:08.17 |
| | So the displaylist will get the page contents appended to it, again and again and again. | 23:08.42 |
| | So yes, it should grow. | 23:08.46 |
| malc_ | Robin_Watts: fine, if i free/allocate dlist,dev on every iteration it shouldn't gro indefintely, right? | 23:12.49 |
| Robin_Watts | right. | 23:14.40 |
| | Forward 1 day (to 2012/10/30)>>> | |
IRC Logs