| | <<<Back 1 day (to 2013/08/19) | 2013/08/20 |
| mvrhel_laptop | henrys: so I had installed the Universal print driver. was there anything else I needed to install? Like a driver for a particular printer? | 00:00.02 |
| henrys | I don't know I'm unravelling it myself now. | 00:01.02 |
| mvrhel_laptop | ok thanks | 00:01.06 |
| henrys | I think with the dynamic you need to have the printer. | 00:02.23 |
| ray_laptop | mvrhel: we may want to mention the RIP times for gs as well (to the /dev/null device) | 00:02.34 |
| henrys | static would have prompted you to say what printer you have I imagine | 00:02.45 |
| ray_laptop | mvrhel: PDF 9, 10, 11, 12: gs 29, 47, 89, 119 | 00:04.55 |
| | mvrhel: PS: gs 36, 45, 83, 102 cpsi: 30, 49, 88, 115 | 00:10.30 |
| | mvrhel: I only ran those once. There's probably a lot of variablility | 00:11.59 |
| mvrhel_laptop | right | 00:12.11 |
| | ok this is good. I agree that having the rip times for gs is good (i.e. to dev/null) | 00:12.34 |
| | was this on linux or windows? | 00:12.48 |
| | henrys: so did you have any luck installing acrobat? then you could just print to file for your 4700 right? | 00:13.34 |
| henrys | yep but now that is sees the printer the driver won't go to a file. | 00:13.52 |
| | is there someplace in the control panel windows can redirect? | 00:15.19 |
| ray_laptop | mvrhel: so it's all I/O. Which makes me suspect that CPSI isn't bothering with any bitmap compression. because even using png16m I from the PS files I get 20, 28, 47, 83 sec | 00:15.58 |
| henrys | ray_laptop, mvrhel_laptop I can of course send to the printer but can't capture. Any ideas? | 00:17.42 |
| | mvrhel_laptop:they have given you pcl times correct? | 00:18.44 |
| ray_laptop | mvrhel: and with png16m, we are CPU limited, since the user time is a significant. With 'raw' files the user time matched the -o nul: times | 00:18.55 |
| | henrys: You installed the printer with the port set to FILE: ??? | 00:19.20 |
| henrys | ray_laptop:it didn't ask me it found my printer at an ip address. | 00:19.56 |
| ray_laptop | henrys: on the printer properties, there should be a "Ports" tab. You can change it | 00:20.32 |
| | henrys: with win 7, from the "devices and printers" menu, if I double click on the printer, it shows a "Customize your printer" that's where I see the tabs: General, Sharing, Ports, ... | 00:22.27 |
| | mvrhel: so you have what you need from me ? | 00:22.50 |
| mvrhel_laptop | ray_laptop yes I believe so. adding new data to table now | 00:23.08 |
| | so what was the gs command line for the record | 00:23.17 |
| | everyone bellyached about that today | 00:23.26 |
| | and fairly so | 00:23.41 |
| | I can handle criticism | 00:23.52 |
| | just no whining | 00:24.01 |
| | i get enough of that from my family | 00:24.31 |
| ray_laptop | mvrhel: time gswin32c -q -r600 -sDEVICE=bitrgb -o x.raw -dBufferSpace=16m -dGrayValues=256 inputfile | 00:24.34 |
| mvrhel_laptop | ok great. thanks | 00:24.43 |
| ray_laptop | shame I don't have an SSD on this system. Might let us see CPSI performance better. | 00:25.56 |
| henrys | ray_laptop:it's not like that in the dynamic mode | 00:26.11 |
| ray_laptop | henrys: I see. Well unplug the printer and install one the regular way | 00:26.50 |
| henrys | mvrhel_laptop: who got the times for the pcl files? We need to request the files properly. | 00:27.08 |
| | ray_laptop:I am sure that will result in michael's adventure but I'll try it. | 00:27.43 |
| ray_laptop | henrys: are you running win 7 or 8 ? | 00:28.03 |
| mvrhel_laptop | henrys: didnt I forward the times to you? | 00:28.06 |
| | to tech? | 00:28.09 |
| | ray_laptop: so gs is just a little slower than cpsi for one file | 00:30.57 |
| henrys | you mean Timing Data? | 00:30.58 |
| mvrhel_laptop | henrys: yes | 00:31.28 |
| | that is the only information that I have | 00:31.45 |
| | I don't have any files. | 00:31.56 |
| | I will see if takane-san can request some pcl files from the customer for us to test with prior to our visit | 00:32.28 |
| henrys | mvrhel_laptop: I understand I want takane-san to request the files. | 00:32.31 |
| mvrhel_laptop | yes | 00:32.35 |
| | let me send that email now | 00:33.02 |
| henrys | In the meantime I'll fiddle with this but I'm not hopeful | 00:33.11 |
| mvrhel_laptop | ok | 00:33.36 |
| ray_laptop | mvrhel: I re-ran J9 PS a couple of times and I get the same times (within .5 sec). so I guess CPSI wins that one | 00:34.25 |
| mvrhel_laptop | ok | 00:34.32 |
| | fair enough | 00:34.35 |
| | we win the others | 00:34.38 |
| | just wanted to make sure I got the numbers all correct | 00:34.55 |
| | ray_laptop: so I will send this table out to you and tech | 00:35.16 |
| ray_laptop | it's sort of surprising since the user time from PS is shorter than from PDF | 00:35.22 |
| mvrhel_laptop | if you can double check that I have things correct that would be great | 00:35.35 |
| ray_laptop | mvrhel: OK. I have to run out for a bit, but I'll check them as soon as I get back. | 00:36.05 |
| mvrhel_laptop | ok thanks for your help ray_laptop! | 00:36.15 |
| | as you always say THANKS | 00:36.21 |
| henrys | I set it up static and it didn't even ask what kind of printer I had so it's going to be bad pcl. | 00:39.49 |
| | but I did get it to print to a file. | 00:40.00 |
| | going to eat something. | 00:40.39 |
| mvrhel_laptop | henrys: ok. sent the results out that ray made | 00:48.11 |
| henrys | that's good I had another idea I'm going to try later - a network packet sniffer should be able to grab the data. | 00:49.16 |
| mvrhel_laptop | henrys: ok fired off email to takane-san and cc'd tech | 01:03.08 |
| | running PS files on raspberry pi since we do have some number for the other company for PS on the 600Mhz dual core arm | 01:03.47 |
| | it seems to be chugging through them at an ok rate | 01:04.13 |
| | will know more soon | 01:04.16 |
| | ray_laptop: I see you are back. I sent out the file to tech with the numbers you gave me | 01:04.43 |
| ray_laptop | I wonder if one of us should get a dual core ARM such as the Wandboard Dual or the Olinuxino A20. | 01:05.22 |
| | mvrhel: Ok, I'll review that | 01:05.31 |
| mvrhel_laptop | thanks | 01:05.35 |
| ray_laptop | mvrhel: I had given you the J10 times. Why aren't they in your table ? | 01:30.13 |
| mvrhel_laptop | ray_laptop: I just wanted J9, J11 and J12 | 01:30.30 |
| | That is what they used | 01:30.44 |
| ray_laptop | mvrhel: Since we have the data, I think we should include it. At least for internal distribution. | 01:31.18 |
| mvrhel_laptop | ray_laptop: ok. I will generate another table then | 01:31.33 |
| ray_laptop | mvrhel: by "they" you mean the info from takena-san ? | 01:31.43 |
| mvrhel_laptop | let me get the PS data from the pi over | 01:31.44 |
| | yes and from miles. he sent the email to you about J9 J11 and J12 | 01:32.14 |
| | I have only been working with those 3 on the pi | 01:32.34 |
| ray_laptop | well, J10 is faster than 11 or 12, so it shouldn't be too bad to add | 01:33.21 |
| mvrhel_laptop | true. but I think miles wants data to send out tomorrow morning at the latest | 01:34.23 |
| | and I am going as fast as I can | 01:34.33 |
| | that is the speed limit here | 01:34.39 |
| ray_laptop | mvrhel: true. I thought you already had all of the Pi numbers (except J10) | 01:37.46 |
| mvrhel_laptop | just got the PS number now | 01:38.01 |
| | I am going to throw the pdf ref manual times in too though, as suggested by others | 01:38.18 |
| ray_laptop | Just for reference, PS is mostly used from printer drivers, but PDF is used with cloud printing and from USB stick / SD card printing that some printers support. The nice thing is that a vendor can always blame the cloud if that isn't as fast as a direct from system print :-) | 01:40.21 |
| mvrhel_laptop | right | 01:41.18 |
| | marcosw_ so how was the Caribbean? | 04:48.21 |
| marcosw_ | mvrhel_laptop: great, we had a wonderful time. though it was a bit pricey... | 04:49.09 |
| henrys | I am now capturing pcl data bound to the printer with tcpdump, nice tools! | 04:49.38 |
| mvrhel_laptop | I have never been there. It is hard to justify that trip when Hawaii is closer | 04:49.42 |
| | henrys: ok great | 04:49.51 |
| | I have only been to Aruba a couple times which is not really the Caribbean | 04:50.29 |
| marcosw_ | we've been to hawaii several times but wanted to try something different. Jill and i went to Montserrat and Antigua a few years after we were married. OTOH, we went to The Atlantis in the The Bahamas so it wasn't very Caribbean like. | 04:54.32 |
| henrys | mvrhel_laptop: j9.pcl is very slow on the HP printer | 04:54.36 |
| mvrhel_laptop | henrys: ok based upon what you are seeing then, I am thinking that we hold off on giving them any pcl numbers until we get some real files from them | 04:55.26 |
| | what do you think | 04:55.30 |
| henrys | mvrhel_laptop: or it might be because I'm tapping the line. | 04:55.37 |
| mvrhel_laptop | oh. your years of NSA training have not taught you the subtle ways of this | 04:56.05 |
| henrys | yeah I think we should wait for the pcl files but I found this entertaining. | 04:56.25 |
| mvrhel_laptop | ok. I am rendering the pdf manual on the pi now | 04:56.49 |
| henrys | my pcl is only 1.6M for J9 against ray 6.4 meg so it is more optimized. | 04:57.04 |
| mvrhel_laptop | once that is finished I think we share our performance with the pdf and ps files and also the comparison of us to adobe that ray did | 04:57.22 |
| henrys | mvrhel_laptop: yes sounds good to me. | 04:57.53 |
| mvrhel_laptop | the ps performance on the pi is reasonable compared to the ps numbers that takane-san gave us | 04:57.54 |
| | based upon the fact that his numbers were for a dual core device | 04:58.30 |
| | and we have s single core | 04:58.34 |
| | henrys: don't know if you have been watching any of the little league world series | 05:01.37 |
| | local kids from our town are there | 05:01.56 |
| | they are 1 to 2 years older than my son and in the same league though | 05:02.20 |
| henrys | wasn't there some giant kid there were questions about? | 05:02.31 |
| mvrhel_laptop | one of the kids on our team is bigger than me at 13 | 05:02.49 |
| | I am sure there are other similar giants on the other teams | 05:03.18 |
| henrys | mvrhel_laptop: so baseball is big there? | 05:04.57 |
| mvrhel_laptop | the northwest team is in the losers bracket now though. they have to win every game from here on out. one tomorrow and the one thursday and then the us championship saturday | 05:05.00 |
| | henrys: yes it is nutty | 05:05.06 |
| | people set up batting cages in back yards. | 05:05.20 |
| | there are training facilities for the kids | 05:05.29 |
| | pitching lessons, batting lessons, batting camps, pitching camps | 05:05.45 |
| | my son is starting fall ball in a week | 05:06.01 |
| | I ended up doing a bunch of umping this past spring which was fun | 05:06.24 |
| | and I will probably do that again in the spring. | 05:06.33 |
| henrys | I see the headline - northwest stays alive | 05:06.45 |
| mvrhel_laptop | yes | 05:06.49 |
| | they won tonight. so the are from our local little league here in sammamish | 05:07.18 |
| | s/the/they | 05:07.24 |
| | they had a tough lost on sunday. their best pitcher took a ball to the knee | 05:08.07 |
| henrys | mvrhel_laptop: do you have problems with the parents being an ump⦠the stuff I've seen at these kids games are crazy, parents are way too involved. | 05:09.25 |
| mvrhel_laptop | I have not had too much. But remind me to tell you a story about one friend who did. | 05:09.55 |
| henrys | I coached soccer and the parents just drove me nuts. | 05:10.03 |
| mvrhel_laptop | It kept him from ever umping again | 05:10.04 |
| | basically the parent ended up calling his house and stalking him later | 05:10.26 |
| | the league had to step in | 05:10.36 |
| henrys | I know some of them are just nuts | 05:10.56 |
| mvrhel_laptop | I have not gotten much done on the windows phone. | 05:10.56 |
| | maybe the flight to japan. if miles does not snore too much. he is flying up here and we are going together out of seattle | 05:11.21 |
| henrys | mvrhel_laptop: oh and scott too? | 05:12.56 |
| mvrhel_laptop | no we are meeting scott there | 05:13.03 |
| henrys | I've done japan and taiwan - long flights | 05:13.40 |
| | but interesting places to visit. | 05:14.04 |
| mvrhel_laptop | japan from here is about 8 hours I think. which is not really that bad to me. beyond 8 hours really feels long | 05:14.13 |
| henrys | http://bleacherreport.com/articles/1740390-swag-daddy-chad-lorkowski-taking-2013-little-league-world-series-by-storm | 05:17.03 |
| mvrhel_laptop | good grief | 05:17.23 |
| | that is insane | 05:17.53 |
| | they did not do so well in the series though. lost their first 2 | 05:20.04 |
| henrys | probably his parents put steroids in his lucky charms ⦠| 05:20.39 |
| | yeah it didn't seem to help much. | 05:20.59 |
| | mvrhel_laptop: nope I was wrong j9.pcl I've captured is the same as ray's, I grabbed it too early. | 05:36.07 |
| mvrhel_laptop | henrys: ok. so we will hold off then on providing any pcl data | 05:36.31 |
| | you saw my email to takane-san? | 05:36.45 |
| henrys | mvrhel_laptop: I did yes, hopefully we can get files. | 05:37.02 |
| | marcosw? | 05:37.57 |
| Sta | help | 05:41.01 |
| | exit | 05:41.08 |
| | quit | 05:41.10 |
| | q | 05:41.11 |
| | query | 05:43.23 |
| | hello | 05:43.29 |
| | ehlo | 05:43.32 |
| henrys | Sta:commands begin with '/' | 05:43.47 |
| Sta | hello | 05:45.36 |
| ghostbot | what's up, sta | 05:45.36 |
| Sta | how to get help from here | 05:46.47 |
| | hey can you pls help me how to quit from here | 05:50.50 |
| ray_laptop | Sta seemed quite clueless. Couldn't even read henry's help | 06:06.48 |
| | HURRAY! I found the issue I had with chrisl's patch to zcolor.c for the lookup string. Works now. | 06:07.48 |
| | at least the ball is now on cust 532's side :-) | 06:08.32 |
| | would have been simpler had they picked up code more recently than 2010 | 06:09.33 |
| mvrhel_laptop | henrys: sent data to miles. done for the day. thanks for helping me out today | 06:24.26 |
| | I am ready to get back to some regular work | 06:24.55 |
| | good night all | 06:25.32 |
| sebras | morning kens! finally I beat you to it. :) | 06:47.09 |
| kens | :) | 06:47.16 |
| | chrisl ping | 08:38.27 |
| chrisl | kens: pong | 08:40.12 |
| kens | I can sort out the current working directory easily, but the error return I'm more nervous about. It looks to me like the Unix veriosn behaves the same (empty string) did you check that ? | 08:40.55 |
| chrisl | kens: I did check it - it definitely returns an error | 08:41.30 |
| kens | Hmm, OK then I don't understand the code in gp_unixfs.c. OK I'll change the Windows code to match, it definitely didn't do this before. | 08:42.06 |
| chrisl | kens: or I should say, somewhere between the enumerate function and the PS interpreter, there is an error generated | 08:42.12 |
| kens | Umm..... I guess that could be it. The code in gp_unix.c doesn't seem to return an error though, just an empty string. | 08:42.44 |
| chrisl | Yeh, I'm just to have a poke and see where the error actually hails from | 08:43.12 |
| | In truth, I think the API is "wrong" - I think the return value should be an error code, and not the length, but much too late now :-( | 08:44.07 |
| kens | Ah, it looks like it returns -1 for an error | 08:44.23 |
| | ~(unit)0; | 08:44.31 |
| | Someone being clever | 08:44.41 |
| chrisl | That's a very liberal definition of "clever"..... | 08:45.01 |
| kens | It is definitely a change for WIndows, but I'm sure it won't matter. I don't suppose you figured out which CET files test this ? I can't check it on the cluster | 08:45.38 |
| | Looks like its because the function returns a uint, so it is an API problem essentially | 08:46.44 |
| chrisl | kens: 09-02.PS has a test with filenameforall in it - in fact, if you run that with the current code it will take *forever* because it traverses the entire file system | 08:47.08 |
| kens | OK I'll try that one. | 08:47.21 |
| chrisl | Same with 09-02.PS | 08:47.31 |
| kens | ? 09-02.ps is tghe same file as 09-02.ps.... | 08:47.48 |
| chrisl | Sorry, 09-01.PS | 08:48.04 |
| kens | :-) | 08:48.09 |
| chrisl | I didn't get much further than those two because I got board waiting for the entire file system to be searched! | 08:48.42 |
| | or even bored! | 08:48.50 |
| kens | I can't see how an error is generated | 08:49.13 |
| | Ah, I need code > len | 08:49.25 |
| | OK | 08:49.28 |
| | (zfile.c, line 380) | 08:49.43 |
| | Looks like gp_ntfs has never been correct (or at least conformed to the Unix code) in this repsect | 08:50.31 |
| | OK that does it, time to test | 08:51.00 |
| chrisl | No probably not, that's why I had you check what Distiller did before I committed the Unix code. | 08:51.17 |
| kens | Your 09-01.ps must differ from mine :-( | 08:53.20 |
| | Also 09-02.ps. OK I'll grep for filenameforall | 08:54.14 |
| chrisl | 09-01.PS line 3860 has the test | 08:54.47 |
| kens | Yes my grep just turned it up, so why doesn't it print that out ? | 08:54.59 |
| chrisl | Print what out? | 08:55.36 |
| kens | Actually loads of them have it | 08:55.37 |
| | something using filenamrforall on the outpuit wa what I was looking for | 08:55.53 |
| chrisl | I'm not sure it does print anything | 08:56.34 |
| kens | Oh its those crappy incomprehensible final pages | 08:56.38 |
| | Well it certainly takes next to no time to run them now so I guess that's OK | 08:57.28 |
| chrisl | Oops, just noticed a bug in the Unix version...... | 09:00.04 |
| kens | Oh, what was the test so I can try Windows ? | 09:00.18 |
| chrisl | It's just looking at the code: we copy the candidate into the string bytes even when the string length is too short for the file name | 09:01.03 |
| kens | I htink that's OK as long as you don't run off the end of the buffer. By returning the required lenght (> string length) you trigger an error and so the string is unused | 09:01.46 |
| Robin_Watts | Interesting. Rewrite one function that supposedly took 43% of the CPU time. Average page time drops from 4.2s to 1.4s. | 09:02.27 |
| kens | :-) | 09:02.40 |
| | Its a good result either way | 09:02.53 |
| chrisl | kens: it's not okay to copy more bytes into a buffer than the size of the buffer! | 09:03.04 |
| kens | chrisl that's what I meant about not running off the end :-) | 09:03.19 |
| chrisl | But we are running off the end..... | 09:03.33 |
| kens | I wasn't looking at the Unix code, just saying that copying the bytes per se wasn't a problem | 09:04.11 |
| chrisl | The problem is we use the length of the file name and ignore the maxlen variable, at that point | 09:05.24 |
| kens | right, I think the Winfows code is OK there. | 09:05.49 |
| kens | runs off to check quickly | 09:05.53 |
| chrisl | The Unix code is trivial to fix | 09:08.20 |
| kens | I'm removing some fallback code form the Windows case which used to copy the filename, if that would fit in the string, but the whole path wouldn't, so this will be different. But apart form that we're ok for buffer length on WIndows | 09:08.41 |
| | err actually let me rephrase that it copied a partial filename and full path. WHich seems totally useless | 09:09.19 |
| chrisl | That's sort of what I've got in the Unix code - it copies up to maxlen bytes into the scratch string | 09:10.24 |
| kens | Yes, I'm choosing to drop that | 09:10.39 |
| | and return an error | 09:10.45 |
| | Are you choosing to keep it ? | 09:11.18 |
| chrisl | How are you returning an error? | 09:12.12 |
| kens | return the required length, since its > maxlen the code in file_continue detects that and throws an error | 09:12.33 |
| | (icky or what ?) | 09:12.39 |
| chrisl | Well, I just thought that it was neat to do: memcpy(ptr, work, len > maxlen ? maxlen : len); | 09:13.24 |
| | It saves a "logical fork" in the code | 09:13.37 |
| kens | So the Unix code never throws an error then ? The WIndows version should have thrown an error only if the pattern was > supplied string. | 09:14.12 |
| | I'm about to try Distiller | 09:14.18 |
| chrisl | We'll still return the full file name length, so the check in zfile.c will still trigger the error | 09:15.03 |
| kens | ah OK | 09:15.13 |
| | I'll remove the code from Windows then. FWIW Distiller executes the procedure until it hits the first filename that doesn't fit and then throws an error. | 09:17.49 |
| | THe old Windows code never threw an error and would return truncated filenames | 09:18.35 |
| chrisl | kens: yes, I know, you tested it before, and that's why I left the Unix code throwing the error...... | 09:18.53 |
| kens | right, I don't remember testing it before :-( | 09:19.13 |
| | OK I'm going to commit this then | 09:20.29 |
| chrisl | It caused differences in the cluster tests of the CET files, because recursing into directories caused us to encounter longer paths than we did before, hence I wanted to know what the "right" behaviour was | 09:20.43 |
| kens | ahb, OK | 09:21.00 |
| chrisl | I'm amazed we got away with filenameforall being *so* broken for so long..... | 09:22.59 |
| kens | I have to agree..... | 09:23.12 |
| Robin_Watts | Just tell people it was for security reasons. | 09:23.46 |
| kens | :-) | 09:24.00 |
| | OK there you go commit c1544d825be1f87ed0821ef0163d08595b5fc0e6 | 09:24.30 |
| chrisl | Groovy, I'll pull all those onto the 9.09 branch - and keep my fingers crossed! | 09:25.34 |
| kens | *very* firmly crossed.... | 09:25.45 |
| chrisl | I think I won't update the changelog yet - don't want to tempt fate..... | 09:27.15 |
| kens | Ah, chrisl gets to trip the new warnigns from gcc :-( | 09:47.16 |
| chrisl | Yes, I got them from my clusterpush, too | 09:48.43 |
| tor7 | Robin_Watts: ping. | 10:13.07 |
| Robin_Watts | pong | 10:40.15 |
| tor7 | Robin_Watts: there's a couple of commits on tor/master | 11:09.10 |
| | and sebras/master has a bunch of x11/pdfapp improvements I've looked over | 11:09.14 |
| Robin_Watts | tor7: OK. Can they wait until tomorrow. | 11:19.03 |
| | ? | 11:19.05 |
| tor7 | Robin_Watts: yes, no rush. | 11:19.19 |
| Robin_Watts | mvrhel has to send timings "this morning" (US time), and I've got some stuff here that doubles our speed on some files. | 11:19.34 |
| tor7 | ah! fab! | 11:19.53 |
| | I'm curious to see what nasty bottlenecks you've found | 11:20.23 |
| Robin_Watts | fz_paint_span_with_color is all. | 11:20.32 |
| tor7 | that's an important one. all text drawing goes through that. | 11:21.56 |
| Robin_Watts | I think I'm gonna ARM code it. | 11:24.43 |
| | tor7: My optimisations so far are on robin/master | 11:26.41 |
| tor7 | Robin_Watts: I wonder if (int*)dp)[0] somehow breaks the "restrict" promise we made | 11:29.02 |
| Robin_Watts | tor7: Why? | 11:30.24 |
| | restrict says the compiler can assume that mp and dp never overlap. | 11:30.47 |
| tor7 | aliasing, casting to a different type and writing to the same array | 11:30.48 |
| | and nothing *else* overlaps mp | 11:30.58 |
| | or dp | 11:31.02 |
| | not just mp/dp | 11:31.04 |
| Robin_Watts | all I'm doing is writing 4 bytes at a time rather than 1. | 11:31.16 |
| tor7 | which is a promise more to the optimiser than anything else | 11:31.49 |
| | consider if the optimiser vectorises to write 8 bytes at a time, and that gets clobbered by you writing 4 bytes and it doesn't know | 11:32.21 |
| | I wonder, we could do the SIMD-like hacks by always writing a uint32 and doing \bit shuffling | 11:33.25 |
| Robin_Watts | SWAR. | 11:35.33 |
| | SIMD Within A Register | 11:35.43 |
| tor7 | yeah, that :) | 11:35.52 |
| Robin_Watts | We can do 2 muls rather than 4 using that, yes. | 11:36.40 |
| | I will play with that too. | 11:36.49 |
| sebras | Robin_Watts: tor7: I'll have a look at the desktop-related bugs when i get home. | 12:16.26 |
| sags | @kens: The 2 recent patches (put back the handling of template escape chars and using the current directory if none present in the template) solved a good part of the problems. Would it help if I add some remaining problems that I know of on the bug report (without reopening it, of course)? | 13:04.52 |
| | (And I appologize for yesterday. It was a really bad day for me...) | 13:05.00 |
| kens | sags If you know of more problems, then yes please | 13:05.08 |
| | It wasn't a great day for use, we're atill trying to get a stable release :-( | 13:05.59 |
| sags | @kens: Done. I only wrote what I consider to be problems in any (most?) interpretation(s) of "match the template", "all enumerable files", "recurse directories". | 13:07.50 |
| kens | Well, much of it (all of recursion) is new now, and differnt to the old Linux behaviour | 13:08.18 |
| | I'll reference back to Distiller in case of doubt | 13:08.38 |
| | OK mail arrived | 13:09.12 |
| sags | @kens: OK then. Bye. | 13:09.18 |
| kens | bye sags | 13:09.27 |
| Robin_Watts | tor7: I have the SWAR stuff working in ARM. | 13:28.42 |
| tor7 | Robin_Watts: how does the performance compare? | 13:36.22 |
| Robin_Watts | tor7: I've only done the "non-optimised" path. | 13:40.28 |
| | let me do the optimised path too. | 13:40.38 |
| | tor7: You may be right. Just spotted this warning: | 14:06.02 |
| | source/fitz/draw-paint.c: In function âfz_paint_span_with_color_4â: | 14:06.12 |
| | source/fitz/draw-paint.c:250:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] | 14:06.14 |
| henrys | weird xps bug reports | 14:08.18 |
| Robin_Watts | Well, that's just strange. How can my lovingly hand crafted ARM code be slower than the crap the C compiler produces? | 14:28.34 |
| | mvrhel: I have MUCH improved results for mupdf. | 14:32.39 |
| | Can we avoid sending the current timings for a couple of hours ? | 14:32.57 |
| henrys | time for a meeting ⦠I start vacation tomorrow and come back wednesday so let's cancel next tuesday | 15:00.08 |
| tor7 | henrys: ok. | 15:00.50 |
| henrys | you guys are all released right? | 15:01.26 |
| Robin_Watts | Yes. | 15:02.01 |
| henrys | I probably won't get to the newsletter stuff until I return. | 15:02.12 |
| Robin_Watts | We ought to do a rebuild of the android app at some point. | 15:02.18 |
| | but we're holding off on that partly cos we may have the digitial signature stuff to include soon. | 15:02.48 |
| | I have some significant speed increases here on the pi (that should also give speedups on all devices, actually) | 15:03.24 |
| henrys | that will be nice. | 15:03.33 |
| | it's arm code though right? | 15:04.32 |
| Robin_Watts | henrys: No. | 15:04.56 |
| | I have speedups in the C. | 15:05.00 |
| mvrhel_laptop | sorry I am late | 15:05.02 |
| Robin_Watts | I am trying to ARM code those speedups for extra credit, but I'm not seeing the expected increase there. | 15:05.24 |
| henrys | Robin_Watts: oh I just read your comment about handcrafted ARM ⦠and assumed. | 15:05.27 |
| Robin_Watts | mvrhel_laptop: In case you didn't see the above comment, please can we hold off on sending the mupdf timings for a few hours ? | 15:05.58 |
| mvrhel_laptop | so where are we with digital signatures? just curious since it may come up in japan | 15:06.20 |
| | Robin_Watts: yes. I can update as you improve | 15:06.33 |
| henrys | really prefer ARM code as a last resort I imagine tor7 would agree. | 15:06.43 |
| mvrhel_laptop | I think now we are going to wait and share numbers next week on monday | 15:06.50 |
| Robin_Watts | henrys: Indeed. | 15:07.02 |
| mvrhel_laptop | Robin_Watts: if you can get some speed up at 1200 dpi that would be good. I am not even going to show those otherwise | 15:07.22 |
| Robin_Watts | I try to get as much as I can from the C, and then only ARM code leaf functions if I think there is something significant to be gained over letting the compiler do it. | 15:07.54 |
| henrys | paulgardiner: so signatures still looking possible for chicago? | 15:08.13 |
| Robin_Watts | mvrhel_laptop: yeah, that's where I'm testing. | 15:08.20 |
| mvrhel_laptop | Robin_Watts: ok great | 15:08.31 |
| paulgardiner | henrys: I think so. It's very close. I have it working except for a few bugs | 15:08.52 |
| mvrhel_laptop | paulgardiner so it it possible you will have it done and available for me to grab by the end of the week? | 15:09.37 |
| | just curious | 15:09.44 |
| paulgardiner | ... e.g. crashes if I type the wrong password for the key file, and doesn't recognise yet-to-be-saved sigs as valid | 15:09.57 |
| mvrhel_laptop | oh a few hours work then :) | 15:10.16 |
| paulgardiner | mvrhel_laptop: Should do. It looks like a few hours | 15:10.42 |
| mvrhel_laptop | nice | 15:10.47 |
| paulgardiner | One pain is I can't get debug output under Android since I updated my S2 to 4.2 | 15:11.22 |
| henrys | paulgardiner: known issue? | 15:11.46 |
| paulgardiner | 4.1.2 I mean | 15:11.52 |
| Robin_Watts | paulgardiner: A couple of bugs came in over the weekend that might be worth looking at. bug 694527 and bug 694529 | 15:12.20 |
| henrys | tor7:this isn't really mupdf stuff but you can bounty xps stuff but you still have to okay it for commit - shelly has some results and there is a new bug to do with the pattern stuff I think kens did. | 15:12.46 |
| paulgardiner | henrys: I don't know. When I last googled it, nothing came up | 15:12.48 |
| tor7 | henrys: yes, I got a mail from shelly. still need to review his patches. | 15:13.27 |
| paulgardiner | Eek! 694527: certainly used to open in AR | 15:14.09 |
| henrys | anything else for the meeting I'm going through the mupdf agenda now. | 15:15.03 |
| | paulgardiner: I assume the release has that? | 15:18.02 |
| paulgardiner | henrys: bug 694529? Quite possibly. | 15:19.05 |
| | :-( | 15:19.10 |
| henrys | fixing that should be high priority and a probably a new release. | 15:19.27 |
| | paulgardiner: is there some way to test that regression test wise? | 15:21.31 |
| mvrhel_laptop | henrys: I got nothing mupdf related done this past week. hoping to get back on the phone app this week | 15:21.34 |
| paulgardiner | The version I'm working on here just created a file with highlight that can be opened in Reader | 15:21.58 |
| henrys | mvrhel_laptop: I understand you should focus on the upcoming trip. | 15:22.02 |
| paulgardiner | henrys: the file with freshly created highlight can also be opened in Foxit. | 15:23.04 |
| | I'll grab the file from the bug report and try | 15:23.30 |
| henrys | paulgardiner: well maybe the report is bogus | 15:23.31 |
| Robin_Watts | paulgardiner: He doesn't say whether it's our build off play, or his build from git, or ... | 15:23.53 |
| henrys | maybe you guys should break down mupdf into components then tor7 wouldn't get all the assignments. I think we are likely to miss stuff with this setup. | 15:24.50 |
| | bugzilla-wis | 15:25.00 |
| | e | 15:25.02 |
| | what would be really nice is to have a support person that preprocessed all bugs. | 15:26.40 |
| Robin_Watts | OR at the very least the incoming bugs should be assigned to someone-that's-not-us. | 15:27.09 |
| | And we should pick the ones out and reassign them to us as appropriate. | 15:27.21 |
| | That way you can yell at us if the bin gets too full, and no one will think that someone else is handling a bug. | 15:27.52 |
| henrys | wait till marcosw hears about our new idea ;-) | 15:28.23 |
| Robin_Watts | henrys: mupdf-group@artifex.com or something | 15:28.57 |
| henrys | I'll put it on the agenda, I do think we are missing stuff with the current setup | 15:30.05 |
| | meeting done - we are at the 1/2 | 15:30.34 |
| | Robin_Watts: but gs does work better than gs - i.e. I get pcl bugs and kens by and large get pdfwrite from the component menu, maybe something like that is simple enough. | 15:33.29 |
| | I don't know how well that transfers into the mupdf universe though | 15:34.02 |
| Robin_Watts | henrys: Yes, there are kind of 'components' to mupdf, I guess. | 15:34.14 |
| | but how visible those are to people outside the team, I don't know. | 15:34.32 |
| | "Fonts - urgh, not me" | 15:34.42 |
| henrys | tor7:can you hang the Contributor License Agreement somewhere off mupdf - I guess under Documentation. Miles frequently asks for it, and it's current location is strange - the patch thing in bugzilla | 15:40.03 |
| | ? | 15:40.15 |
| | mupdf.com that is. | 15:40.27 |
| Robin_Watts | henrys: Likewise there should be a link to it from ghostscript.com | 15:41.18 |
| henrys | you can also add the bounty policy if you think that might attract contributors, tor7. | 15:41.21 |
| | Robin_Watts: well that is for the next meeting ;-) | 15:41.36 |
| Robin_Watts | marcosw: You keep asking tor7 if you can move the mupdf webpages out of his user area. | 15:41.57 |
| marcosw | Robin_Watts: yes, I was going to ask again at the 9:00am pdt meeting | 15:42.19 |
| Robin_Watts | tor7 said that he kept missing you, and that you should just go ahead. | 15:42.39 |
| marcosw | will do, thanks for following up. | 15:42.51 |
| henrys | also, I remember chrisl wanted to change mupdf.com and was concerned about permissions. | 15:43.26 |
| Robin_Watts | If marcos moves it, I can then edit it to include the CLA link. | 15:43.50 |
| | (unless tor7 reappears and wants to do it) | 15:44.11 |
| marcosw | I believe chrisl was hesitant because it was in tor7's private directory, presumably moving it to /var/www will allow him to edit it without concern. | 15:44.22 |
| henrys | marcosw: yes | 15:44.35 |
| tor7 | I can add the CLA link. moving it to /var/www is better all around. | 15:44.41 |
| | the directory is a git repository, so anyone editing should remember to add and commit the changes as well. | 15:45.03 |
| Robin_Watts | will leave it to tor7 then. | 15:45.29 |
| henrys | mvrhel_laptop: that's not so great because we haven't had luck generating pcl output for printers we don't have. Perhaps the new drivers will be different. | 15:45.32 |
| tor7 | marcosw: ping me when the move is finished, and I'll edit in a link | 15:46.34 |
| marcosw | tor7: will do, should be within the next 30 minutes or so. | 15:46.52 |
| chrisl | kens: have you looked at sags's filenameforall bug? | 15:48.01 |
| kens | chrisl I'm looking at it now | 15:48.08 |
| | The result from Distiller is not entierly what I expected | 15:48.22 |
| | I'm working on matching it | 15:48.31 |
| Robin_Watts | mvrhel: AIUI, the issue with the J files is that they are .doc's etc, right? So when you print one, the output you get depends not only on whatever driver you are using, but also on how the app you are using drives that driver. | 15:48.36 |
| | So unless we happen to have exactly the same version of word etc as the other people have, we will still get different output files regardless of the driver used. | 15:49.11 |
| chrisl | kens: the results I get from Distiller don't match what sags described, either | 15:49.44 |
| kens | Quite :-) | 15:49.51 |
| | It only matches at teh top level, direcotries which match the pattern then return all their contents | 15:50.22 |
| chrisl | Yeh, and it's hard to get excited about random selections of forward and back slashes...... | 15:51.02 |
| kens | That one I may ignore | 15:51.10 |
| henrys | mvrhel_laptop: | 15:51.27 |
| Robin_Watts | mvrhel_laptop: New timings for 600dpi: 21.7/96.9/140.3 19.3/94.1/119.8 19.4/93.2/111.0 | 15:51.42 |
| kens | chrisl if you are thinking of holding up the release against this I would say not | 15:51.43 |
| | The details of pattern matching in the template are device dependent (says the PLRM) | 15:52.17 |
| henrys | mvrhel_laptop: do we have the files in the XLS spreadsheet? sent under the email Timing data? | 15:52.39 |
| chrisl | kens: oh, who cares, then? ;-) | 15:52.44 |
| kens | Well, sort of :-) I was thinking that the t* example is a little curious, if I can match Distiller with that then I will | 15:53.22 |
| chrisl | kens: I wasn't thinking of holding up the release - I don't believe of those "problems" are regressions, and it is *much* better than it was..... | 15:53.34 |
| kens | Nonefo them can be regressions, since it didn't do recursion at all previously :-) | 15:53.51 |
| ray_laptop | Robin_Watts: what are those 9 numbers ? | 15:54.01 |
| chrisl | kens: Exactly! | 15:54.09 |
| kens | and the non-recursion bug he list, he says isn't a regression | 15:54.09 |
| henrys | tor7:I was also thinking you could advertise the bounty program on mupdf.com, maybe that stuff should be somehow integrated with the CLA as they are frequently dependent. | 15:54.26 |
| chrisl | kens: it does probably mean I need to revisit the Unix code, too :-( | 15:55.21 |
| Robin_Watts | ray_laptop: The Time (sec) from the first column of Michaels Timing_Compare.pdf | 15:55.26 |
| kens | chrisl that's possibly true, but let me work on this for a bit first, it would be nice to be consistent | 15:55.52 |
| Robin_Watts | i.e. they were 27.9/111.62/169.1 27.03/109/149.48 27.18/108.14/141.7 | 15:56.00 |
| ray_laptop | Robin_Watts: I assume that's with your newly optimized code. Are they the 3 files 9, 11, 12 and the groups are the bandheight ? | 15:56.05 |
| Robin_Watts | ray_laptop: Yes. | 15:56.31 |
| ray_laptop | Robin_Watts: thanks just wanted to make sure | 15:56.33 |
| Robin_Watts | There is more to be had in the J files. | 15:57.10 |
| ray_laptop | Robin_Watts: is that with just the "write 32 instead of 8 bits" ? | 15:57.29 |
| Robin_Watts | The pdf_reference pages hammer fz_paint_span_with_color (the function I optimised) more than the J files do. | 15:57.47 |
| ray_laptop | Robin_Watts: because they use lots of cached text ? | 15:58.10 |
| Robin_Watts | ray_laptop: No. It's a combination of 1) write 32 bits instead of 8, 2) do multiple blends operations in a single register, 3) avoid doing blending for solid or opaque pixels, 4) use ARM code. | 15:58.40 |
| paulgardiner | Bug #694527 is looking nasty: Adobe Reader on android is happy with the file, but AR on Windows wont open it. Thankfully, the version of MuPDF on Play is okay. | 15:58.51 |
| Robin_Watts | ray_laptop: Yes. The J files hammer fz_paint_colid_color, and I can probably do similar optimisations on that. | 15:59.14 |
| | s/colid/solid/ | 15:59.23 |
| henrys | using tcpdump and wireshark I am not able to grab all manner of stuff going any network printer. Amazing how well these tools work, it reassembles the data from the packets and everything. | 15:59.32 |
| | s/not/now | 15:59.39 |
| Robin_Watts | well, I've done *some* optimisations there, but there are more to come I think. | 15:59.43 |
| ray_laptop | Robin_Watts: of those 3, only 1 page has transparency, so blending optimization won't help much I would guess | 16:00.30 |
| Robin_Watts | ray_laptop: blending is used for AA. | 16:00.34 |
| | i.e. the edges of cached chars - it's that sort of blending I'm talking about here. | 16:00.50 |
| | Now, I know we have AA disabled, but it still goes through the same loop here. | 16:01.10 |
| henrys | okay gs meeting time. | 16:01.10 |
| ray_laptop | Robin_Watts: ah, but for these benchmarks, mvrhel was using -b 0 | 16:01.17 |
| tor7 | henrys: yes, I'll look into that as soon as marcosw is finished migrating the web pages. | 16:01.25 |
| ray_laptop | Robin_Watts: OK | 16:01.33 |
| Robin_Watts | right, so this routine gets called with a bitmap full of 0's and FF's. | 16:01.36 |
| henrys | I'm going on vacation tomorrow and will return wednesday so no meeting next Tuesday unless you want to meet. | 16:02.03 |
| ray_laptop | henrys: hurray! | 16:02.15 |
| henrys | ray_laptop: no meeting or that I'm leaving. | 16:02.32 |
| | ? | 16:02.33 |
| Robin_Watts | henrys: "hurray! We get a week off!" :) | 16:02.52 |
| ray_laptop | uh, both ? Vacation is hurray for you, no meeting is hurray for us ;-) | 16:03.09 |
| henrys | we should probably wait for mvrhel_laptop since he's the center of action these days. | 16:03.16 |
| ray_laptop | any release issues need to be discussed while we wait ? | 16:03.39 |
| | like, is it imminent ? | 16:03.58 |
| henrys | chrisl? | 16:04.06 |
| ray_laptop | or are there still "issues" ? | 16:04.09 |
| chrisl | I've added the filenameforall fixes to the release branch. The only feedback I've had about the RC is from kens | 16:04.19 |
| | As far as I'm concerned, the release can go ahead tomorrow or Thursday | 16:05.07 |
| henrys | chrisl: we've all been running around with michaels stuff. | 16:05.09 |
| ray_laptop | chrisl: the filenameforall is rather a serious thing to cram in. Was it really needed for the release ? | 16:05.12 |
| Robin_Watts | Would anyone object to chrisl releasing without it going through full testing again? I think we can make strong arguments that none of the testing would be affected by the patches that have gone in. | 16:05.23 |
| henrys | Robin_Watts: that seems at odds with what ray_laptop just said. | 16:05.47 |
| mvrhel_laptop | I am back | 16:05.49 |
| kens | ray the change was done some weeks ago, and nobody noticed a problem, we either need to pull the change ort fix it. | 16:05.53 |
| ray_laptop | chrisl: what if it breaks or changes resource path searching or something ? | 16:05.54 |
| mvrhel_laptop | sorry for being late again | 16:05.56 |
| Robin_Watts | henrys: The pre-release testing failed to catch that it was hopelessly broken. | 16:06.16 |
| henrys | mvrhel_laptop: there were a few things for you to read above. | 16:06.27 |
| ray_laptop | ken: Oh, I thought you just did it today (from the logs I was reading from earlier) | 16:06.32 |
| kens | henrys, the changes are all *Windows* specific and none of our tests exercise that | 16:06.39 |
| Robin_Watts | Re running the tests with the fixed ("less hopelesly broken") code will not tell us anything useful :) | 16:06.51 |
| chrisl | ray_laptop: given that it was broken for *years*, and it is *less* broken now....... | 16:06.53 |
| kens | ray_laptop : I did some *fixes* today | 16:06.54 |
| | I will change it again very slightly to match Distiller | 16:07.41 |
| chrisl | That change won't go into this release | 16:08.05 |
| kens | SaGS may find Distiller's result surprising, but it seems reasonable to match it | 16:08.06 |
| ray_laptop | chrisl: so if we stay with the RC, when is the 9.10 release ? (it _is_ still 9.10, right?) | 16:08.12 |
| henrys | I'm fine with chrisl deciding, marcosw did you want to weigh in on retesting? | 16:08.18 |
| kens | Its 9.09 isn't it ? | 16:08.30 |
| mvrhel_laptop | ok. Robin_Watts I will update the table with your results | 16:08.48 |
| marcosw | tor7: okay, the mupdf.com site has been moved (actually copied, since I was paranoid about screwing up). You might want to put a link fromhttp://www.ghostsrcript.com/~tor7/mupdf to mupdf.com, just in case that page shows up in search results. | 16:09.00 |
| chrisl | ray_laptop: 9.09, like I said, tomorrow or Thurs - unless I'm outvoted on another weeks' testing...... | 16:09.03 |
| mvrhel_laptop | and yes, the file that we have depends upon the app AND the drive | 16:09.03 |
| ray_laptop | kens: oh, that's right. we all have 910 PRE-RELEASE | 16:09.03 |
| mvrhel_laptop | s/drive/driver | 16:09.12 |
| henrys | mvrhel_laptop: be coming up to your neck of the woods this week - penticton B.C. | 16:09.16 |
| marcosw | henrys: I don't think we need to retest. | 16:09.30 |
| mvrhel_laptop | oh right. for the Triathalon | 16:09.31 |
| | I would head up there to cheer you on if I was not heading off on Saturday | 16:10.06 |
| chrisl | marcosw: did henrys mention about documenting how the weekly tests are done? And what they test? | 16:10.06 |
| ray_laptop | chrisl: no, I'm fine as long as kens tweaks from today weren't part of it. Remember chrisl, just breathe and push when we tell you ;-) | 16:10.22 |
| henrys | mvrhel_laptop: weather looks great, cloudy | 16:10.51 |
| kens | The earlier fixes today are *required* | 16:10.51 |
| ray_laptop | chrisl: I think you are fully dilated now ;-) | 16:10.55 |
| kens | At least I think they are | 16:10.56 |
| marcosw | chrisl: I didn't see anything from henrys, the weekly/nightly testing documentation is pretty much non-existent. | 16:11.00 |
| mvrhel_laptop | I don't think you will need to worry about heat up here | 16:11.13 |
| chrisl | ray_laptop: kens' tweaks from today *are* part of it - otherwise filenameforall on Windows doesn't work "correctly" | 16:11.21 |
| tor7 | marcosw: I put a .htaccess Redirect to mupdf.com in ghostscript.com/~tor/mupdf | 16:11.52 |
| ray_laptop | chrisl: earlier you said: That change won't go into this release | 16:11.55 |
| kens | He means the one I'm curerently working on in response to SaGS | 16:12.12 |
| chrisl | ray_laptop: the changes to match Distiller won't go into the release | 16:12.16 |
| henrys | mvrhel_laptop: a no wet suit day would be very bad for me. I'm a weak swimmer relative to biking and running. | 16:12.20 |
| mvrhel_laptop | I am sure the water will be plenty cold | 16:12.35 |
| marcosw | tor7: that works. | 16:12.55 |
| chrisl | ray_laptop: we can't have "(*) {pop} 100 string filenameforall" start enumerating in the root directory of the drive! | 16:13.14 |
| ray_laptop | kens: OK, I need to pull in your change from today and I'll see if I can agree. Is the describption of what it fixes in the log message, and "why" ? | 16:13.23 |
| sebras | marcosw: do you configure the products in bugzilla? | 16:13.37 |
| kens | TWhat it fixes is in the commit message, I'm not sure about why | 16:13.44 |
| sebras | marcos: mupdf is missing a version 1.2 and 1.3 in there. | 16:13.49 |
| mvrhel_laptop | henrys: so miles is not worried about getting PCL numbers for the meeting. He feels the PDF numbers are fine. I think though we should investigate how we can get reasonable PCL files for the future though for the JEITA files | 16:14.01 |
| ray_laptop | chrisl: was that only happening on Windoze ? | 16:14.06 |
| chrisl | ray_laptop: yes | 16:14.12 |
| kens | ray_laptop : 'why' in this case is 'to match Unix' | 16:14.20 |
| henrys | marcosw: well the issue is how do we do the prerelease test and what exactly is tested. In your absence we need to know if we should do and how to do it. | 16:14.58 |
| ray_laptop | but matching unix is not required, and *is* a change from the way it has been for years. | 16:15.19 |
| kens | ray_laptop : yes, and that contravenes tghe spec | 16:15.29 |
| | and does not match Adobe implementations, or our own implementation on a different platform | 16:15.49 |
| chrisl | ray_laptop: that change happened quite a while ago - you didn't object then! | 16:15.56 |
| ray_laptop | kens: I thought the spec says that it is implementation dependent ? | 16:15.57 |
| henrys | saying the obvious August is probably the worst month we could release. Almost everyone goes on vacation. September would be much better but doesn't work well with ubuntu. | 16:16.01 |
| kens | ray opnly some parts | 16:16.05 |
| | 'template matching' is device dependent | 16:16.18 |
| | henrys, staff meeting topic there | 16:16.31 |
| | We need to talk about our release dates | 16:16.43 |
| mvrhel_laptop | Robin, so the timings that you have is with the raspberry pi set up at 700 MHz right? Just checking. One time I had mine set to 800 Mhz and forgot | 16:16.51 |
| ray_laptop | chrisl: so the change that happened "quite a while ago" I am fine with. I have been keeping my code current and I run windows. | 16:16.53 |
| Robin_Watts | mvrhel_laptop: I haven't changed my pi's speed (wouldn't know how) | 16:17.12 |
| kens | ray_laptop : those break badly if you don't have COMPILE_INITS=1 | 16:17.17 |
| ray_laptop | chrisl: I am concerned that a fix from today is going in | 16:17.25 |
| mvrhel_laptop | Robin_Watts: also, can you run the first 100 pages of the PLRM through? | 16:17.26 |
| chrisl | ray_laptop: the change that happened a while ago introduced the problem of enumerating from the root directory | 16:17.32 |
| Robin_Watts | mvrhel_laptop: Will do. | 16:17.35 |
| mvrhel_laptop | ok. and you are going to do 1200 dpi too? | 16:17.46 |
| henrys | mvrhel_laptop: well I'm looking at the takahe sans xls spreadsheet the sooner I see those files the better. I always get into this crap of optimize these by yesterday and I really like to avoid that. | 16:17.51 |
| Robin_Watts | I'm just doing the 1200dpi stuff now. but it's 4 times as slow, oddly :) | 16:18.00 |
| henrys | kens:yes I'll add it. | 16:18.13 |
| kens | henrys thanks | 16:18.21 |
| mvrhel_laptop | Robin_Watts: ok thanks | 16:18.27 |
| ray_laptop | kens: OK, so now I understand. The change from "quite a while ago" broke COMPILE_INITS=0 and you just fixed that. | 16:18.27 |
| kens | I fixed that on Friday I think Ray, that exposed some other 'quirks' which arepotentially a problem | 16:18.57 |
| ray_laptop | Robin_Watts: you are cutting the band height down to use the same (approx) memory > | 16:19.06 |
| kens | particularly always enumerating form the root | 16:19.08 |
| ray_laptop | ? | 16:19.08 |
| Robin_Watts | ray_laptop: I am. | 16:19.21 |
| tor7 | henrys: paragraph at the top of http://mupdf.com/docs/ look good to you? | 16:19.29 |
| mvrhel_laptop | henrys: so from his email, the customer had indicated that we should use their driver to generate. but then in takane-san's last email he indicated he was going to ask about my request, so I am a little confused | 16:19.56 |
| marcosw | sebras: yes, I do the bugzilla updates. | 16:20.27 |
| henrys | mvrhel_laptop: where are the original application files? | 16:20.27 |
| | those aren't the jeita files. | 16:20.29 |
| ray_laptop | kens: OK. I've been wrapped up (until last night) with cust 532's bug (and Miles' fire drill), so I didn't look at the change Friday, sorry | 16:20.48 |
| mvrhel_laptop | henrys: we need to buy the original jeita files | 16:20.50 |
| henrys | mvrhel_laptop: I'll generate them if I have the app files | 16:20.56 |
| marcosw | sebras: I'll fix the mupdf version numbers (and ghost*) | 16:20.56 |
| chrisl | ray_laptop: put it this way: without the fix from today, we basically cannot run most of the CET files on Windows - I don't think we can ship it like that | 16:21.08 |
| kens | Not a problem Ray, its been rather a cumulative nightmare caused by the fact that we don't test on WIndows and don't test wiht COMPILE_INITS=0 and don't test GS_LIB | 16:21.16 |
| sebras | marcosw: nice! hopefully some users will be bothered to used them too. :) | 16:21.20 |
| mvrhel_laptop | henrys: I will get the files ordered | 16:21.24 |
| henrys | mvrhel_laptop: oh okay or I'll do it. I didn't know they were a testing outfit. Are they like QL? | 16:21.47 |
| sebras | marcosw: I don't know if you guys have a release script or a release check-list, but I guess updating bugzilla versions should go in there too. | 16:21.55 |
| chrisl | sebras: your faith in users is admirable, but probably misplaced! | 16:22.08 |
| mvrhel_laptop | henrys: they are a standards body. like ISO or ECMA I believe | 16:22.36 |
| | so a not for profit | 16:22.41 |
| | unlike QL | 16:22.44 |
| Robin_Watts | Japan Electronics and Information Technology Industries Association | 16:22.51 |
| sebras | chrisl: no, my belief is that someone might use the newly added version numbers by accident at least. :) | 16:22.54 |
| henrys | marcosw: I have not heard booh from 801 is the ftp site you sent me the only place they would upload stuff? With our luck they will deliver day 1 of my vacation tomorrow. | 16:23.08 |
| chrisl | :-) | 16:23.08 |
| mvrhel_laptop | henrys: ok I will leave it to you to get the files | 16:24.00 |
| henrys | mvrhel_laptop: it's on my list now. thanks | 16:24.12 |
| marcosw | henrys: yes, customer 801 only uploads to the ftp site. they have emailed small files to support in the past but nothing lately (and you would see those). | 16:24.49 |
| henrys | chrisl:can you do something like what tor7 just did for the CLA on ghostscript.com? | 16:26.02 |
| | tor7:that's perfect. | 16:26.03 |
| marcosw | sebras: I usually do it when chrisl sends out the notice of the release, but I was on vacation last week. When I've forgotten in the past someone usually points it out, so we have a working system in place :-) | 16:26.06 |
| chrisl | henrys: yeh, I'll do it when I do the release | 16:26.42 |
| henrys | okay I think we squeezed in everything let's adjourn | 16:27.11 |
| marcosw | 3 minutes early. w00t! | 16:27.25 |
| chrisl | marcosw: we'd pulled the gs 9.08 release before you got back - didn't think it worth adding! | 16:27.33 |
| marcosw | it's still on the customer download page (or was the last time I checked). | 16:28.05 |
| chrisl | marcosw: but the webpage doesn't like to it | 16:28.27 |
| | s/like/link | 16:28.34 |
| | marcosw: the 9.08 files are gone from the customer downloads directory now, too | 16:30.35 |
| sebras | marcosw: ah, ok then. then I'm part of the system. ;) | 16:30.46 |
| ray_laptop | henrys: there is also a JEIDA -- That's Japan Electronics Industires Development Association. The one "original" file I have is a PPT and it says the "Author" is JEIDA | 16:35.04 |
| | henrys: so I'm not sure which J group we need for sure. Do you want me to ask cust 532 ? | 16:35.43 |
| kens | I've had enough of filenameforall for one day, I'm heading off. Goodnight all | 16:37.19 |
| sags | @kens: resourceforall uses filenameforall and is very picky on the results it gets. True, it uses a particular form, not very fancy in terms of wildcards (template = "RESOURCEDIR/Category/*"). Extra "/" inthere, or at the start of the returned (as it was before one of your latest fixes) can be fatal. | 16:38.14 |
| | For what exactly this means, and why it's like this, you can see Igor's point of view on bug #688737 "'resourceforall' truncates names of file-based resources". I had a different opinion, but Igor's expectation that there is a text-like-match between requested pattern and any result string is legitimate. Among other things that means filenamefoall won't "simplify" parts link "./" or "DIR/../", or "canonicalize" paths. | 16:38.21 |
| | The bug I mentioned yesterday connected to resources is not conditioned by COMPILE_INIT=0, that just made GS fail in an obvious and easy to reproduce way. | 16:38.52 |
| henrys | ray_laptop, mvrhel_laptop it seems prudent that takane-san should ask his contact which tests we should buy. That would should a good faith effort in advance. | 16:40.04 |
| mvrhel_laptop | yes | 16:40.32 |
| chrisl | sags: what we have now works, and works better than before, so that is most likely going to be the 9.09 release code. | 16:40.33 |
| | sags: but both kens and I found that Distiller's filenameforall doesn't match your description of Adobe's behaviour in your bug report...... | 16:41.28 |
| sags | @chrisl: I didn't describe Distiller's behaviour. | 16:41.52 |
| chrisl | sags: you're comparing our filenameforall with Adobe's, aren't you? | 16:42.18 |
| sags | No, I'm trying to compare to what PLRM says it should be. True, PLRM lets some room for implementation-specific behaviour, and I'm not sure what you think Ghostscript's filenameforall should do exctly. "Recurse into directories" is vague. | 16:44.02 |
| chrisl | Generally speaking, the arbiter when the spec isn't clear is an Adobe implementation. | 16:44.47 |
| | "Recurse into directories" may be vague. but it clearly means doing more than just enumerating files in the current directory | 16:45.37 |
| Robin_Watts | mvrhel_laptop:1200dpi timings: 77.6/384.3/665.4 66.9/358.3/502.7 61.3/344.1/424.3 | 16:46.37 |
| chrisl | sags: Like I say, what we have now is *less* broken than it was, and we'll try to get a reasonable approximation to Distiller's behaviour in time | 16:46.58 |
| mvrhel_laptop | Robin_Watts: ok thanks. | 16:48.02 |
| henrys | ray_laptop:from what I've gathered they were merged into jeita | 16:48.14 |
| mvrhel_laptop | still is a little slower than gs at 1200 dpi but faster at 600dpi . | 16:48.23 |
| sags | @chrisl: ok. | 16:48.34 |
| mvrhel_laptop | Robin_Watts: so just the first 100 pages of the PLRM.pdf file would be the last thing if you can please. | 16:48.55 |
| Robin_Watts | mvrhel_laptop: I'm doing pdf_reference timings now. | 16:48.55 |
| | oh. PLRM.pdf, crap. | 16:49.31 |
| mvrhel_laptop | ok. I had used the PLRM for mine since gs was complaining about a bad x-ref of my pdf ref | 16:49.34 |
| chrisl | I'm never sure if sags is happy with the discussion, or just p*ssed off so he leaves...... I hope it's the former | 16:49.39 |
| mvrhel_laptop | and that was hurting the timing for me | 16:49.44 |
| chrisl | mvrhel_laptop: it would be better to use a PDF of just the first 100 pages of the PLRM, since we can spend a fair amount of time juggling xrefs and stuff before we actually start rendering pages | 16:51.03 |
| mvrhel_laptop | that is what I used | 16:51.20 |
| chrisl | Ah, great! | 16:51.29 |
| Robin_Watts | mvrhel_laptop: How did you generate such a beast? | 16:51.34 |
| chrisl | pdfwrite is your friend.... :-) | 16:51.45 |
| mvrhel_laptop | Robin_Watts: I have a copy here | 16:51.50 |
| Robin_Watts | pfft. | 16:51.51 |
| mvrhel_laptop | let me put it in my public | 16:51.57 |
| | for you | 16:52.01 |
| chrisl | Or Acrobat Pro.... | 16:52.02 |
| Robin_Watts | mvrhel_laptop: Can I have a copy please? Makes sense to use the same thing. | 16:52.03 |
| | chrisl: pdfclean is much better than pdfwrite for such things, as it doesn't rewrite everything. | 16:52.30 |
| chrisl | Robin_Watts: true, yes | 16:53.28 |
| mvrhel_laptop | http://www.ghostscript.com/~mvrhel/PLRM.pdf | 16:54.00 |
| | Robin_Watts: ^^ | 16:54.21 |
| Robin_Watts | Copying it (as PLRM100.pdf to avoid confusing myself) now. | 16:54.53 |
| chrisl | That's the entire PLRM..... | 16:55.31 |
| Robin_Watts | chrisl: Indeed. | 16:56.59 |
| | mvrhel_laptop: Is that a mistake? | 16:57.05 |
| mvrhel_laptop | uh it is the whole thing | 16:57.16 |
| | I just ran the first 100 pages | 16:57.22 |
| | 1-100 for mupdf | 16:57.39 |
| Robin_Watts | Right, which is what chrisl said was a bad thing to do above :) | 16:57.42 |
| mvrhel_laptop | and -dFirstPage=1 and -dLastPage=100 | 16:57.48 |
| | for gs | 16:57.50 |
| Robin_Watts | but I'll do the same. | 16:57.52 |
| mvrhel_laptop | oh that is what he meant | 16:58.13 |
| | so no, that is not what I did chrisl | 16:58.28 |
| Robin_Watts | (It's his accent :) ) | 16:58.34 |
| mvrhel_laptop | :) | 16:58.37 |
| chrisl | :-) | 16:58.44 |
| mvrhel_laptop | the fact is, I did not see a big start up time issue at all | 16:59.02 |
| chrisl | Oh, fair enough. I did with the PDFRM, which is why I suggested it | 16:59.27 |
| mvrhel_laptop | the PDFRM has a problem when I run gs | 16:59.40 |
| | and had a huge start up time | 16:59.46 |
| | due to gs complaining about the xref | 17:00.02 |
| chrisl | I didn't get an xref warning or anything, and it still spent quite a while thinking, before it began spitting out pages | 17:00.25 |
| mvrhel_laptop | interesting | 17:00.34 |
| | anyway I did not see that with the PLRM | 17:00.45 |
| chrisl | That time would probably end up being fairly negligible when averaged for all the pages in the file, but for just the first 50 (as I was using) it was pretty significant | 17:01.26 |
| mvrhel_laptop | right | 17:02.45 |
| Robin_Watts | Timings for PLRM pages 1-100, 600dpi: 55.3/53.7/56.1 | 17:08.07 |
| | for the 3 bandheights. | 17:08.19 |
| | Doing the 1200dpi ones now | 17:08.29 |
| | mvrhel_laptop: If you're interested I can get you a copy of the profiling stuff that I'm using. | 17:15.28 |
| mvrhel_laptop | Robin_Watts: that would be good to have | 17:15.52 |
| Robin_Watts | This 1200dpi stuff is taking ages, so I'm going to mow the lawn while I wait for it to run. | 17:16.08 |
| | 507.1 is the first timing. Does that match what you had? | 17:16.26 |
| mvrhel_laptop | Robin_Watts: what do you mean 507.1 is the first timing? | 17:18.58 |
| | I did not fool with mupdf at 1200 dpi, so I did not run the PLRM | 17:19.23 |
| | at that resolution | 17:19.28 |
| | that is, with as slow as it was, I just was not going to present it. The times you have now are close to gs at 1200 dpi so that is fine | 17:20.32 |
| chrisl | marcosw: could you run the weekly regression on Windows? Using cygwin or mingw? | 17:22.52 |
| | marcosw: Or maybe better: "could someone run the weekly regression on Windows? Using cygwin or mingw?" | 17:27.05 |
| mvrhel_laptop | ray_laptop: ping | 17:28.06 |
| | that is the alarm at the fire house | 17:28.27 |
| ray_laptop | mvrhel: pong ? | 17:31.25 |
| sicos | ? | 17:31.32 |
| ray_laptop | slides down the pole ... | 17:31.39 |
| mvrhel_laptop | ray_laptop: so I did want to add in J10 timings in the comparison of CPSI and GS. In looking over the irc logs, I dont see the number for CPSI when running the J10.pdf | 17:32.09 |
| sicos | someone here that knows when ghostscript 9.08 will be re released? | 17:32.14 |
| mvrhel_laptop | did it throw an exception? | 17:32.20 |
| ray_laptop | mvrhel: right, only J9.pdf and J12.pdf ran | 17:33.13 |
| chrisl | sicos: 9.08 had a rather nasty bug, so we pulled it PDQ. 9.09 should be out in a few days | 17:33.36 |
| mvrhel_laptop | ok. Miles did not like having files that did not work so I guess I will strip it down to J9 and J12 | 17:33.53 |
| sicos | ok.. because I was really looking forward to the extra multithreading options... keep up the good work | 17:34.08 |
| ray_laptop | mvrhel: I don't think that's a good idea, but.. I just re-ran J10 throws an exception after < 1 min | 17:34.55 |
| sicos | is it ok to pull the sourcecode from git and compile the dll myself or is the bug still in there? | 17:34.59 |
| mvrhel_laptop | ray_laptop: well do you think it is not odd that we would be comparing to something that does not even work | 17:35.40 |
| chrisl | sicos: the bug is fixed. You could actually grab the release candidate and try it: http://www.ghostscript.com/~chrisl/ghostscript-9.09rc1.tar.gz | 17:35.41 |
| ray_laptop | mvrhel: in the flurry yesterday, I may not have been patient enough for J11. I'm trying it. I killed it after 8 minutes yesterday | 17:36.00 |
| sicos | ok ill try that one.. i compile it for windows | 17:36.08 |
| mvrhel_laptop | ray_laptop: ok | 17:36.14 |
| ray_laptop | mvrhel: If we want Adobe CPSI, that's all we have that we can do run side by side with GS | 17:36.49 |
| mvrhel_laptop | right I understand. | 17:37.06 |
| chrisl | sicos: that archive has all supported platforms in there - we don't do a zip any more, since reading tar.gz files is pretty universally supported now | 17:37.11 |
| sicos | I use total commander for windows.. so no problem with tar.gz files overhere | 17:37.46 |
| chrisl | Okay, I have to go - 'nite all! | 17:38.02 |
| ray_laptop | on J11, after about 3 minutes it gets to 66% on one page, then stalls with free memory going down. I'll just let it keep cranking | 17:39.04 |
| | it's probably the page with transparency. | 17:39.47 |
| mvrhel_laptop | yes | 17:39.53 |
| ray_laptop | mvrhel: I could *zap* the Pages /Kids and /Count to skip that page ;-) | 17:40.40 |
| | call it J10.99.pdf ;-) | 17:41.14 |
| mvrhel_laptop | well if the object is to compare CPSI to GS then I think that is fair | 17:41.16 |
| ray_laptop | oops. It just crashed with an "memory could not be read" error. | 17:42.03 |
| | mvrhel: OK, I'll try it taking out the page with trans | 17:42.28 |
| mvrhel_laptop | ok sounds good | 17:42.37 |
| sicos | I got a question about ghostscript speed optimalisation... the manual says the following --> In general, larger -dBufferSpace=# values provide slightly higher performance since the per-band overhead is reduced. | 17:46.53 |
| | What will be a good settings when you are on a windows 2008R2 system with 8GB of ram and a quadcore | 17:47.12 |
| | I almost only use the pdfwrite output device | 17:47.48 |
| | I've have a couple of pdfs that i put into ghostscript to make one pdf(a) from it | 17:48.09 |
| | I read the pdf's from a postscript file that I generate. I use the run command to process the pdf's | 17:49.21 |
| | THe pdf's are mostly html files that I converted to pdf with wkHtmlToPdf | 17:51.25 |
| Robin_Watts | sicos: It will make no difference for pdfwrite. | 17:55.26 |
| | mvrhel_laptop: OK. Timings at 1200dpi: 507.0/329.8/241.8 | 17:55.44 |
| ray_laptop | mvrhel: running J9_no_p9.pdf | 17:56.04 |
| mvrhel_laptop | ok thank you | 17:56.33 |
| ray_laptop | mvrhel: OK. that runs. CPSI 176 sec (11 pages), gs writing the file: 80 sec, gs -o nul: 7.6 sec | 18:06.04 |
| mvrhel_laptop | ray_laptop: ok great | 18:07.27 |
| | thank you. | 18:07.30 |
| ray_laptop | mvrhel: I have to run now. Call me if you need something. I'll be back ~noon. | 18:07.42 |
| mvrhel_laptop | hopefully we can all head back to the fire house now | 18:07.49 |
| Robin_Watts | mvrhel_laptop: I have some more optimisations that seem to help. 600dpi figures for the J files at 424: 15.3/89.1/124.0 | 18:23.44 |
| mvrhel_laptop | Robin_Watts: ok | 18:24.20 |
| Robin_Watts | but in order to really test my optimisations, I need to rebuild mupdf without the AA_BITS=0, so I'm going to do that now, and it'll take ages. | 18:24.39 |
| mvrhel_laptop | ok well, if you get any improvements you can email me them to me and then I will not lose the on IRC if that is OK | 18:25.32 |
| | s/the/them | 18:25.34 |
| Robin_Watts | mvrhel_laptop: Sure. If we've got til monday that takes the pressure off a bit :) | 18:25.39 |
| mvrhel_laptop | well until Saturday morning | 18:25.52 |
| | I don't know if I will be able to get to much email before the monday meeting next week japan time | 18:26.17 |
| | between leaving saturday and the meeting on monday that is | 18:26.49 |
| Robin_Watts | gotcha. | 18:42.27 |
| | I'll try and get everything done and dusted by friday morning your time. | 18:42.42 |
| ray_laptop | mvrhel: were you going to send out the revised, more complete timing info ? | 20:06.16 |
| | or are you still collecting info ? | 20:06.30 |
| | windows is _such_ a pain. Files get "locked" then trying to run procexp just hangs :-( reboot time | 20:11.43 |
| mvrhel_laptop | bbiaw | 20:19.32 |
| | Forward 1 day (to 2013/08/21)>>> | |
IRC Logs