| | <<<Back 1 day (to 2014/06/22) | 2014/06/23 |
| mvrhel_laptop | hmm I wonder if I have the right repository to SOT. I updated and the last commit in my log shows 4/17... | 05:12.14 |
| | likely things have moved.. | 05:12.41 |
| | Robin_Watts: heading to bed. if you could leave me a email about the repository that would be great. | 05:14.04 |
| Robin_Watts | mvrhel_laptop: (For the logs) the repo has not moved | 07:29.00 |
| pedro_mac | morning folks | 08:15.13 |
| kens | Morning Pete | 08:24.39 |
| Robin_Watts | morning. | 08:30.24 |
| paulgardiner | Hi | 08:39.15 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 08:39.15 |
| pedro_mac | morning Paul | 08:39.46 |
| mattchz | mornin' | 08:48.45 |
| kens | Hi Matt | 08:48.53 |
| jogux | hello | 08:48.59 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 08:48.59 |
| mattchz | paulgardiner/robin_watts you were fine with my patches, right? | 08:56.38 |
| paulgardiner | Four patches, one being the AsynTask thing? | 08:58.45 |
| mattchz | Yeap, from the annotation fix in eclipse up to the .gitignore change | 08:59.16 |
| paulgardiner | Yeah. Look good to me | 09:03.11 |
| mattchz | thanks. | 09:04.36 |
| | I'll get the original bug tester to try and re-test with the patch. | 09:04.44 |
| kens | suspects Robin_Watts | 09:10.39 |
| chrisl | Ugh, this could get noisy :-( | 09:13.14 |
| mattchz | :) | 09:13.43 |
| kens | Its probably OK for GS, but for MuPDF where commits get queued as a group it probably not a good plan | 09:13.47 |
| mattchz | I can try and push one commit at a time, if it helps | 09:14.11 |
| kens | I wonder if there's a mute list in miranda | 09:14.17 |
| | mattchz : not your fault | 09:14.22 |
| chrisl | It also depends if it reports on clusterpushes as well as commit runs..... | 09:14.36 |
| kens | If ti get really annoying we can kick the bot | 09:14.40 |
| mattchz | Do we have access to the play store crash console btw? | 09:14.42 |
| kens | doesn't even know what that means :-) | 09:14.56 |
| jogux | mattchz: I presume so | 09:15.06 |
| jogux | examines my list of passwords | 09:15.11 |
| mattchz | This bug mentions that the crash reports have been submitted to Google, and I suspect the backtraces will appear in the Google Play developer console | 09:15.33 |
| | jogux> ta | 09:16.00 |
| kens | chrisl I get the email and I watch the dashboard, I don't need the bot, personally | 09:16.54 |
| jogux | hm, odd, the artifex login I have has no apps at all in it. confusing. PaulGardiner will now. | 09:17.24 |
| | know | 09:17.26 |
| mattchz | it's possible to delegate stuff to other gmail accounts btw, with limited permissions if that helps. | 09:17.57 |
| paulgardiner | Robin_Watts had so far done the releases of MuPDF on Play. | 09:21.19 |
| mattchz | nice. This bug talks about mupdf crashing with a huge pdf file. | 09:22.20 |
| | turns out the pdf file is 730Mb | 09:22.24 |
| kens | That's a reasonable definition of huge | 09:22.37 |
| mattchz | Guys, what would you like to me do with bugs that are platform android, but appear to be core related? | 09:29.47 |
| kens | change the platform to 'all' ? | 09:30.09 |
| jogux | mattchz: so long as they're reproducible on other platforms, just update the OS field | 09:30.13 |
| mattchz | ok | 09:30.22 |
| paulgardiner | jogux: your iOS changes: looks like I need to do something for SOG too as the build now fails - "Undefined symbols for architecture armv7" _showReplacePaperDlg ... | 09:39.04 |
| Robin_Watts | kens: Not me. | 09:41.58 |
| kens | Hmm, OK then who ? marcosw seems unlikely... | 09:42.14 |
| | someone was messing with bots at the weekend I noticed | 09:42.29 |
| Robin_Watts | marcosw I reckon. | 09:43.02 |
| kens | Is he home now ? | 09:43.11 |
| Robin_Watts | Dunno. | 09:43.21 |
| kens | Oh well | 09:43.30 |
| Robin_Watts | mattchz: See AndroidKeyDetails.txt in my home dir. | 09:43.53 |
| jogux | paulgardiner: hm. darn. | 09:44.39 |
| mattchz | robin> ta | 09:44.52 |
| jogux | paulgardiner: apparently I broke simulator builds too, in a different way. | 09:45.42 |
| paulgardiner | I don't see anything suspicious in the commits | 09:46.34 |
| jogux | paulgardiner: it must be 90b05a33d that broke good I guess. | 09:47.06 |
| | paulgardiner: if reverting that fixes it I'm happy for you to push that and I'll try and figure out what I did wrong later. albeit showMainViewToast is just a function in print-interface-ticprint.m in the alien so the possibilties must be limited. | 09:51.31 |
| | this is what I get for trying to tidy up code :-S | 09:55.17 |
| paulgardiner | I know. Long term there'll be benefits from doing so even if it causes little hiccups on the way | 09:56.25 |
| jogux | I'm just doing a build here to check it. It must be something obvious... | 09:56.58 |
| paulgardiner | What supplies PrtDocInterface? | 09:59.28 |
| jogux | that's in the ticprint library thing | 10:01.06 |
| paulgardiner | Could it be a C/C++ thing? | 10:04.40 |
| | ... hmmm unlikely | 10:05.15 |
| jogux | paul: I was just wondering that actually | 10:05.29 |
| | but I couldn't see how. | 10:05.34 |
| mattchz | robin/paul> another small review for you: http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commitdiff;h=5eccc07eb3c9bc65e3234fc99e936fa7d76f2586 | 10:07.09 |
| jogux | paul: it is that. but I don't understand why it works in the non-good build. or why __cpluscplus would be defined. | 10:08.01 |
| | wtf. printwrapper.m is build with -x objective-c++. | 10:10.48 |
| | but, presumably, only in the good build. | 10:12.17 |
| mattchz | robin/paul> can I close bugs like this? http://bugs.ghostscript.com/show_bug.cgi?id=694529 | 10:13.02 |
| | (waiting for feedback for months) | 10:13.11 |
| Robin_Watts | mattchz: Yes. Just put "Closed due to lack of feedback from OP." or something. | 10:13.45 |
| | mattchz: For commit messages, as a rule, we try to have a short self contained first line :) | 10:14.41 |
| mattchz | oh, right. | 10:14.47 |
| | I'll change that :) | 10:14.56 |
| Robin_Watts | otherwise various git outputs get bent. | 10:15.04 |
| | but otherwise looks good to me. | 10:15.32 |
| mattchz | Fixed (and pushed) | 10:16.59 |
| jogux | paulgardiner: I've emailed you a patch that fixes it. I don't understand it's been build as objective-c++ though, I can't see a relevant setting. | 10:19.47 |
| paulgardiner | mattchz: actually I don't yet understand 5eccc07eb3c9bc65e3234fc99e936fa7d76f2586. I suspect it's fine but I'm not yet understanding it | 10:20.29 |
| mattchz | ah, sorry. I should have waited. | 10:20.56 |
| | basically, in the case the doc failed to load, core was null, and if you dismiss the 'Cannot open document' dialog using the back button, rather than the 'OK' button, you'd end up on a blank screen. | 10:21.30 |
| | Pressing back again would cause the app to crash, because the onBackButtonPressed handler used core (which was Null) | 10:21.46 |
| jogux | paulgardiner: ahha! someone has set GCC_INPUT_FILETYPE = sourcecode.cpp.objcpp; | 10:22.12 |
| paulgardiner | Right. I get it now | 10:22.15 |
| mattchz | so I fixed the null pointer issue, but also made cancelling the dialog behave the same as oking it | 10:22.17 |
| jogux | hm. maybe. | 10:22.18 |
| | paulgardiner: yes. that's it. xcode has been set to try objective C files as objective C++ files, but only in the good alien. If I undo that setting, I get a ton of linker errors involving good. | 10:24.18 |
| | paulgardiner: I emailed you a patch btw. | 10:26.10 |
| paulgardiner | Okay. So your patch sounds like the best solution | 10:26.22 |
| | Was what I had in mind too. | 10:26.57 |
| jogux | hm. actually, no, linker errors were from another change I had | 10:27.32 |
| | if I peel back to what's in git, then just undo that setting to treat objc files as objc++, then it builds fine. | 10:27.52 |
| | whether it runs okay is a different matter of course :-) | 10:28.05 |
| paulgardiner | You'd imagine that would have been set for a reason... not necessarily a good one but some sort of reason at least | 10:29.37 |
| jogux | paulgardiner: tracing it back just gets me to a review that says 'added the good project file' with no further explanation :-S | 10:33.12 |
| pedro_mac | paulgardiner: when you get a chance could you try goodshare/gfe and see if you can connect please? Iâm getting errors from their lib trying to connect to trygoodnow.com | 10:35.55 |
| paulgardiner | pedro_mac: both have just started up and authorized for me, although Good Share looked to delegate to GFE | 10:38.20 |
| | Not sure what you mean by connect to trygoodnow.com. | 10:39.01 |
| pedro_mac | paulgardiner: but with goodshare can you access any datasources? | 10:39.05 |
| paulgardiner | Ah no I can't. I have one offline file that is okay, but I cannot access anything else. Could this be to do with the time limit on the keys? (if so strange that it still authorises) | 10:40.24 |
| pedro_mac | Iâm getting log traces from the GD library with a socket transfer failing during policy negotiation (TGN-GD02.trygoodnow.com) | 10:40.35 |
| | Iâm using keys which Brad just sent - they expire if they havenât been activated yet, but I dont think they were time-limited trials | 10:41.34 |
| paulgardiner | I guess part of their network must be down | 10:41.58 |
| pedro_mac | could be wrong - Iâd have thought in that case weâd be prevented from starting the apps | 10:42.07 |
| paulgardiner | Isn't it different servers that hold the data and do the authorization? | 10:45.58 |
| pedro_mac | most likely, but all on the trygoodnow domain | 10:47.59 |
| | the NOC is outside that and handles the policy exchange, but this is all black-box for me - all I can see are the comms error logs | 10:49.57 |
| mattchz | Someone here's asking about mupdf for ios (and the fact that only 1.4 is available on the app store). | 11:23.27 |
| | is there a plan for 1.5 release? | 11:23.31 |
| Robin_Watts | mattchz: That's one for paulgardiner or tor. | 11:26.11 |
| jogux | Paul put a beta of 1.5 on testflight, and iirc my testing of it showed it was okay. | 11:32.36 |
| jogux | wonders if there's a way to stop cmd-w leaving the channel in colloquy | 11:34.15 |
| mattchz | Should I just close this one then: http://bugs.ghostscript.com/show_bug.cgi?id=695313 | 11:34.33 |
| | with "It's coming" | 11:34.37 |
| jogux | mattchz : lt's worth checking with Paul I guess | 11:35.39 |
| Robin_Watts | mattchz: Could do. Or leave it open as a reminder. | 11:35.54 |
| mattchz | 'k | 11:36.58 |
| paulgardiner | mattchz: yeah probably best leave it open as a reminder. | 11:38.38 |
| mattchz | ok | 11:43.47 |
| jogux | paulgardiner: is there anything else we need to do before submitting it to Apple? | 11:50.12 |
| paulgardiner | Not at far as I know. It was only a little while ago that I submitted 1.4 | 11:51.01 |
| jogux | was it 1.5 I was testing? | 11:51.19 |
| | oh, no, 1.4 apparently | 11:51.59 |
| paulgardiner | No 1.4 | 11:52.00 |
| mattchz | Paul : regarding: http://git.ghostscript.com/?p=mupdf.git;a=blobdiff;f=android/src/com/artifex/mupdf/MuPDFActivity.java;h=7b100050ad7657a0147cfd23944253dd958852a1;hp=051c2740fbe4a13fde6bbb738598c341c2618e96;hb=150e7f9781cd67c9bf00dd24188cd8052fe5c0c3;hpb=f6ec243a4a629913419a739a25199ec8a28bab65 | 11:52.05 |
| jogux | should matt stick 1.5 up onto testflight then? | 11:52.15 |
| mattchz | can you remember how you caused the file manager to generate such a file (rather than just a file url) | 11:52.28 |
| Robin_Watts | mattchz: I thought that was just what the transformer primes inbuilt file manager did. | 11:53.20 |
| paulgardiner | mattchz: yes. Specific to the transformer prime, and contrary to the hope I don't think it works in many other cases (email attachments from K9 on my S2) | 11:54.34 |
| mattchz | Ours seems to pass a file URL. | 11:54.36 |
| | (the File MNager on our TF201) | 11:54.50 |
| paulgardiner | Perhaps we should store a copy of the file locally and open that | 11:54.59 |
| Robin_Watts | mattchz: Which is the 201? | 11:55.22 |
| | right, mine is the 201, and that is what Paul was using when he coded that. | 11:57.30 |
| | so presumably he was using an older version of android at the time. | 11:57.41 |
| paulgardiner | It was a trick found on stackoverflow that we probably shouldn't be using | 11:58.11 |
| mattchz | Fair enough. I was just trying to test the patchon http://bugs.ghostscript.com/show_bug.cgi?id=695229, but I can probably do that another way. | 12:01.00 |
| mvrhel_laptop | Robin_Watts: I see what was confusing me | 13:43.44 |
| | do you have a sec | 13:43.48 |
| paulgardiner | jogux: I've not before uploaded a patch to the new ATS. What's the procedure? | 13:44.24 |
| | Oh it's probably doc'd on the twiki | 13:44.46 |
| jogux | gen-patch -g, then the usual (schedule grouptask with the patch) | 13:44.58 |
| | not sure it is :) | 13:45.07 |
| | you've got access to the web front end already right? | 13:45.24 |
| mvrhel_laptop | brb | 13:45.42 |
| paulgardiner | jogux: yep. | 13:46.11 |
| | jogux: ta | 13:46.17 |
| jogux | it should be easy and obvious hopefully :) | 13:46.26 |
| | we've got 3 predefined group tasks, tgvath, runtests and precommit - the latter between the combination of the first two. | 13:46.50 |
| paulgardiner | gen-patch is complaining about stuff (on MacOS) cvs does not exist | 13:48.10 |
| Robin_Watts | paulgardiner: You are using gen-patch.pl -g right ? :) | 13:50.04 |
| paulgardiner | I seem to be | 13:50.56 |
| | I have some recollection of still needing cvs when running in git mode from back when I first added it, but presumably whatever that was needed for wont work anymore now the main repo isn't cvs | 13:52.54 |
| | I'll try just installing cvs to shut it up | 13:53.14 |
| | Is macports my friend for this? | 13:53.34 |
| jogux | are you on master? | 13:53.54 |
| Robin_Watts | personally, I'd create a cvs.sh file | 13:53.56 |
| paulgardiner | jogux: yes master | 13:54.02 |
| Robin_Watts | and have that print the args its called with. | 13:54.08 |
| paulgardiner | Robin_Watts: that's a nice idea | 13:54.21 |
| Robin_Watts | just to see how it's been used. | 13:54.23 |
| jogux | I certainly meant to remove the cvs requirement. maybe I never got around to it. | 13:54.26 |
| | doesn't look like I did | 13:55.19 |
| | paulgardiner: try altering line 816, change both cvs's to git | 13:55.35 |
| | oh, no, that won't work | 13:55.52 |
| | just deleting cvs bit should work. | 13:56.02 |
| Robin_Watts | jogux: That works for me. | 13:56.17 |
| Robin_Watts | lunches. | 13:57.49 |
| | Smart Art is officially mad. | 13:57.54 |
| paulgardiner | Yep. Sorted | 13:58.30 |
| mvrhel_laptop | hi Robin_Watts | 14:00.37 |
| jogux | paulgardiner: cool, feel free to commit | 14:00.45 |
| mvrhel_laptop | so I did an update from golden so that I would be all caught up and for some reason there are like 75 commits sitting in my local repos here that it wanted to rebase on | 14:01.18 |
| | I had expected it just to fast forward | 14:01.34 |
| henrys | mvrhel_laptop: are you interested in the OpenPrinting summit in toronto? | 14:01.36 |
| mvrhel_laptop | henrys: that is a time of year that I really dislike to travel. | 14:02.06 |
| | I could do a remote call in | 14:02.20 |
| jogux | mvrhel_laptop: I have vague memories of us needing to do a force push - just do a hard reset to golden master | 14:02.36 |
| paulgardiner | jogux: Now it's claiming to create a patch in /tmp/paul-gen-patch-24198/gen-patch-git-24198, but there is no such subdir of /tmp | 14:03.16 |
| henrys | mvrhel_laptop: yea me too I always have family stuff going on that time of year. | 14:03.29 |
| mvrhel_laptop | jogux: ok thanks! | 14:03.44 |
| jogux | paul: that's just a tmp location | 14:03.46 |
| | mvhel_laptop: I'm presuming you've not committed anything locally :-) | 14:03.57 |
| mvrhel_laptop | henrys: quite a few people have done presentations with a call in in the past there | 14:04.05 |
| jogux | paul: you should have a patch-something.zip in cwd? | 14:04.06 |
| mvrhel_laptop | and it has gone pretty smooth | 14:04.12 |
| | jogux: good guess! | 14:04.19 |
| paulgardiner | jogux: Silly me. Yes I do | 14:04.51 |
| mvrhel_laptop | and my repos is all good. | 14:07.45 |
| | I wonder if Robin_Watts committed that funny issue I was having with his romfs python script | 14:08.06 |
| jogux | I have vague memories of reviewing it. | 14:08.42 |
| mvrhel_laptop | yes. your memory is good | 14:14.33 |
| paulgardiner | jogux: 3 commits on my master branch, two actually being your patches and the other being something we discussed. | 14:15.02 |
| | jogux: ... suggesting you might be a good reviewer. :-) | 14:15.21 |
| jogux | :-) | 14:15.52 |
| jogux | looks | 14:15.52 |
| henrys | tkamppeter: your tutorial link on http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/cupsprintingtutorial#CUPS_Printing_Setup_Mini-HOWTO points to the linux standard base documentation | 14:19.01 |
| jogux | paulgardiner: I wonder if setVisible ever changes not as a result of DocumentInfoView_setVisible? and/or, I'd add assert(docInfoView->visible == UE2Panel_getVisible) before the assignment in | 14:20.46 |
| tkamppeter | henrys, seems that they have taken down dev.linuxfoundation.org and default every access to the LSB doc. | 14:24.08 |
| | henrys, so these resources are probably permanently gone. | 14:24.42 |
| paulgardiner | jogux: I checked and couldn't see other cases of the panel having it's visibility changed. | 14:24.45 |
| jogux | paulgardiner: possibly it could be changed when it's a cast to a uicontrol though :-( | 14:25.17 |
| | paulgardiner: tbh I'm not even convinced the check is correct in the first place, I have a suspicion they wanted isDisplayed (but maybe they turn out to be the same thing in ue2fileviewer) | 14:25.54 |
| paulgardiner | jogux: would you rather I remove the call? I was just nervous of changing the way it operates | 14:27.38 |
| jogux | I think it's all making me nervous. I think at least the assert to verify it's still behaving as it was would be good. | 14:28.14 |
| paulgardiner | jogux: what were you thinking might act on the underlying UIControl? | 14:28.21 |
| mvrhel_laptop | henrys: I will be working tomorrow. just at my inlaws. I think wed. and thurs I will be out though | 14:28.34 |
| | I will know better what the schedule is once I get there | 14:28.48 |
| jogux | paulgardiner: I was from a 'it is possible' point of view rather than with any knowledge of something that actually does that. | 14:28.50 |
| mvrhel_laptop | I just do what I am told... | 14:28.54 |
| | when I get there... | 14:29.02 |
| jogux | paulgardiner: but possibly I think setting visible flag may cascade down the uicontrol hierachy? | 14:29.04 |
| mvrhel_laptop | I am hoping to work some on this SOT bug with the charts on my flight and then I will hopefully have a pile of questions tomorrow for the meeting.. | 14:29.53 |
| pedro_mac | mvrhel_laptop: sounds like a plan | 14:30.16 |
| | the charts should hopefully be nice and self contained | 14:30.39 |
| mvrhel_laptop | henrys: I wonder if I can pass 695118 off to ken since my part of this is done | 14:30.39 |
| paulgardiner | jogux: I see how the assert works only if placed in DocumentInfoView_isVisible, in which case I'll still see the locking problem I'm trying to cure when running in debug, wont I? | 14:30.46 |
| mvrhel_laptop | need to run cat to boarder (other wise house would be destroyed when we returned). bbiab | 14:31.21 |
| paulgardiner | jogux: I'm happy to try removing the problematic call to DocumentInfoView_isVisible. I suspect it's just an optimisation, but just can't be sure. | 14:32.10 |
| jogux | paulgardiner: ah. hrm. I was thinking in setVisible. but I'm not convinced. | 14:32.12 |
| henrys | mvrhel_laptop: seems like kens should get the bug now. | 14:32.42 |
| kens | What ? | 14:32.49 |
| | Oh yeah, you can pass that to me | 14:33.02 |
| | I'll get to it one day | 14:33.10 |
| paulgardiner | jogux: it's a case of choosing the least evil | 14:33.13 |
| jogux | yeah :-S | 14:33.32 |
| | on balance, of the options we have, I think I feel slightly happier remover the call. AFAICT the worse effect would be take slightly longer to shutdown when the document info view is on screen. | 14:34.13 |
| | where as there is a possibility the current patch could fail to save when we needed to | 14:34.41 |
| | paulgardiner: typo in the most recent commit message, yen-patch -> gen-patch | 14:35.11 |
| paulgardiner | okay ta. I'll give that a try | 14:35.29 |
| jogux | paulgardiner: and in the good fix I'd mention in the commit message about the GCC_INPUT_FILETYPE oddness being the root cause. | 14:35.47 |
| | I'm tempted to try removing that tbh, it seems weird. the references I found for it online seemed to be working around an xcode 4 bug. | 14:36.29 |
| | paulgardiner: could you login to ats as paul rather than atsadmin please? :-) | 14:37.14 |
| paulgardiner | jogux: I asked about credentials on Skype but got no reply | 14:37.46 |
| jogux | odd, I didn't see anything | 14:37.58 |
| jogux | replies there | 14:38.23 |
| | well, starts talking, as I don't see the original message. | 14:38.32 |
| paulgardiner | ta | 14:38.50 |
| Robin_Watts | mvrhel_laptop: Sorry, was at lunch. | 14:39.28 |
| pedro_mac | paulgardiner: youâre using the com.picsel.smartoffice2gd bundle ID for the iOS Good build arenât you? Iâm just rationalising the app list we have so that thereâs just one entry for the marketplace app (managed on the Partner portal) and one for dev (with a com.artifex.dev.sog id, managed by our GC server) | 14:57.57 |
| kens | chrisl do we still support -dUseFAPI=false ? | 14:58.03 |
| | (or whatever the switch is called) | 14:58.16 |
| | -dDisableFAPI apparently | 14:59.00 |
| chrisl | kens: Yes, although I'm thinking it will go soon | 15:00.01 |
| paulgardiner | My most recent tests have been with com.picsel.smartoffice2gd, although before I was using com.picsel.smartofficegd | 15:00.09 |
| kens | THat's what I thought, its just that I can test this customer file with it and see what that does | 15:00.19 |
| chrisl | Does it have the fonts embedded? | 15:00.51 |
| kens | Noppe | 15:00.56 |
| chrisl | So we're using substitutes? Or only base14? | 15:01.14 |
| kens | Frankly I think the customer is being an ass, comparing against a 4 year old version ofthe code, but..... | 15:01.24 |
| | only base14 | 15:01.29 |
| | times only I htink | 15:01.36 |
| | Times family that is | 15:01.48 |
| chrisl | It might be worth checking if we end up going through the width matching code | 15:02.00 |
| kens | Is that the code that checks the UID and widths to determine if its the same font ? | 15:02.30 |
| chrisl | No, it's where we compare the average width from the Widths array with the average width of the actual glyphs, and scale if they differ | 15:03.20 |
| kens | Hmm,I don't know.... | 15:03.35 |
| chrisl | It's around line 780 in pdf_font.ps | 15:04.05 |
| kens | Well,if I set -dDisableFAPI=true I get about twice the performance out | 15:04.20 |
| | 1.9954 seconds as opposed to 3.54 with FT | 15:04.40 |
| chrisl | That seems.... odd | 15:04.56 |
| kens | For comparison 8.71 was 1.526 seconds | 15:05.05 |
| chrisl | I guess we could shift to lazy "FAPI-ization" of the fonts, but I'd really prefer not to | 15:05.53 |
| kens | WIth FAPI the code spends a *lot* of time in names_ref, called form the FAPI code for some reason | 15:06.14 |
| | Let me fire up Very Sleepy | 15:06.30 |
| chrisl | From the FAPI C code, or in gs_fapi.ps? | 15:06.48 |
| kens | Well its only the C code that I can profile.... | 15:07.01 |
| chrisl | I suppose it could be during serialising of the font dicts | 15:07.38 |
| kens | The code spends 6.92% of tis time in names_ref | 15:08.10 |
| | Looking at the call stack I see it called from FAPI_FF_get_subr (more to follow) | 15:08.32 |
| mattchz | paul> I'm looking at a crash in the code to load from a buffer. | 15:09.15 |
| kens | gs_font_find_similar calls font_with_same_UID_and_metrics which calls dict_find_striong which calles names_ref | 15:09.20 |
| mattchz | (MuPDFCore_openBuffer etc) | 15:09.31 |
| kens | FAPI_char calls dict_find_string which calls names_ref | 15:09.44 |
| mattchz | the crash is actually in bufferStreamSeek() will trying to get the array object. | 15:09.46 |
| | sorry, the array field from the MuPDFCore object. | 15:09.57 |
| | I notice we're stashing the env pointer in the globals | 15:10.13 |
| kens | gs_fapi_serialize_type1_font deos call FAPI_FF_get_subr | 15:10.19 |
| mattchz | I've just been reading the JNI docs, and it claims these pointers differ from thread to thread. i.e. you shouldn't pass an env pointer between threads. | 15:10.41 |
| kens | FAPI_FF_get_glyph calls names_ref too | 15:10.45 |
| | (from FAPI_char) | 15:10.59 |
| mattchz | So I'm wondering if that's likely to be the problem here, as the crash seems to occur in an AsyncTask. | 15:10.59 |
| paulgardiner | mattchz: I think Robin_Watts knows that area better than I do. | 15:11.29 |
| kens | FAPI_char calls zchar_get_CDevProc and that calls names_ref | 15:11.32 |
| mattchz | ah, right, thanks paulgardiner | 15:11.50 |
| kens | There's a bunch of calls to names_ref from the pdfwrite stuff wanting metrics | 15:12.02 |
| Robin_Watts | mattchz: Hold on. Let me look. | 15:12.34 |
| kens | The FAPI code calls zchar_get_metrics2 which calls dict_find_string as well | 15:12.40 |
| mattchz | robin_watts> specifically glo->env and (possibly) glo->thiz | 15:13.42 |
| kens | chrisl the biggest culprit of the call stacks, at 3.93% seems to be the serailising code | 15:13.52 |
| chrisl | kens: seems a long way short of the 50% deficit..... | 15:14.28 |
| kens | FAPIrebuildfpont -> FAPI_refine_font......names_ref | 15:14.29 |
| Robin_Watts | mattchz: We don't do anything on timers in the C. | 15:14.48 |
| kens | chrisl there are 146 call stacks, this is the one that took most time | 15:14.49 |
| Robin_Watts | which means that somewhere in the callstack of any crash there should be the point at which the JNI was originally entered. | 15:15.06 |
| kens | The next worst one is 0.73% and is from buildfont1 | 15:15.18 |
| Robin_Watts | And the env should be being stored in the globals at that point. | 15:15.19 |
| kens | Then the next 3 worst ones are FAPI again | 15:15.34 |
| | Then we get to gs_scan_token | 15:15.53 |
| | SO FAPI and buildfotn are calling names_ref much more than hte interpreter | 15:16.07 |
| Robin_Watts | mattchz: whenever we call get_globals, we store the env pointer. | 15:16.12 |
| mattchz | ah, ok. | 15:16.26 |
| paulgardiner | mattchz: are we not passing in the global pointer on every call and using them only for callback (in the same thread)? | 15:16.36 |
| mattchz | if two threads are running at the same time, they could clobber each other values ? | 15:16.39 |
| Robin_Watts | mattchz: Do you have a callstack with a crash to hand ? | 15:16.41 |
| mattchz | erm. | 15:16.58 |
| | yeah. pastebin best? | 15:17.03 |
| Robin_Watts | mattchz: probably, yes. | 15:17.11 |
| mattchz | in fact, there's awarning about using the wrong env pointer... | 15:17.38 |
| Robin_Watts | mattchz: We only have 1 globals object, so yes, multiple threads could be a problem. | 15:17.42 |
| mattchz | http://pastebin.com/TWMJtdnb | 15:17.50 |
| | so looks like the asynctask is using the env pointer from the main thread | 15:18.07 |
| Robin_Watts | balls. | 15:18.26 |
| | That does indeed make it sound like we have 2 threads working at once :( | 15:18.47 |
| mattchz | should all the native methods be running on the AsyncTasks? | 15:19.15 |
| Robin_Watts | A quick and nasty way to test this would be to make drawPage a synchronized method maybe ? | 15:19.18 |
| mattchz | that might 'fix it', I guess. | 15:20.09 |
| Robin_Watts | It would be a bad long term fix. | 15:20.20 |
| chrisl | kens: well, we can't safely eliminate many of the dictionary lookups, I guess we could cache things like the Private dict, CharStrings dict.... another option is to create an array of refs with all the names we use in FAPI, and save repeatedly doing the C string->string ref->name ref conversions | 15:20.30 |
| Robin_Watts | but it might serve as confirmation that the problem is threading driven (though that seems fairly clear I think) | 15:20.47 |
| mattchz | presumably there's plenty of code where we call into the JNI from the main thread? | 15:20.57 |
| | just not page drawing? | 15:21.05 |
| Robin_Watts | Dunno. | 15:21.16 |
| paulgardiner | mattchz: we do almost everything on the background thread | 15:21.27 |
| | so as not to stall the UI | 15:21.37 |
| kens | chrisl I'm inclined to tell the customer to live with it. Its a dumb file which exhibits maximum penalty (and it snot even the original source file, its a 'modified' version of it). If he only updates every 4 yearts he can't be surprised if things have changed. | 15:21.43 |
| mattchz | i'm just trying it in gdb, to see if I can get a list of threads. | 15:21.54 |
| paulgardiner | mattchz: I think opening the document is the only thing done on the UI thread | 15:21.55 |
| mattchz | unfortunately, the backtraces seem corrupt in gdb | 15:22.12 |
| kens | chrisl I don't see his performance penalty of x30 (for me its x16) with 9.14, and the master code is 'only' x2.5 | 15:22.15 |
| mattchz | paul> ah. I wonder if this happens when I'm opening a new document. I have seen it in that case, I think. | 15:22.28 |
| kens | chrisl I just wondered if you wanted to look at it before I punt it back to them. | 15:22.33 |
| paulgardiner | And I think the AsyncTask version we are using guarantees to use the same thread for each task | 15:22.35 |
| Robin_Watts | kens: Regardless of the dumbness of the file/customer, getting a 30fold slowdown between versions is something that it's not unreasonable to complain about. | 15:22.39 |
| kens | Robin_Watts : Its not x30 | 15:22.48 |
| chrisl | kens: I guess is depends if we think there performance to be gained in more sane files | 15:22.58 |
| kens | Its x16 and with the current code its x2.5 | 15:23.03 |
| | chrisl I don't know, it looks to me like the major part of it is in the font code now | 15:23.19 |
| paulgardiner | mattchz: the whole getGlobals thing was done so that two MuPDF tasks could be running symultaneously and it seemed to work. | 15:23.25 |
| | IIRC | 15:23.33 |
| Robin_Watts | paulgardiner: Eh? | 15:23.36 |
| paulgardiner | Maybe I don't then :-) | 15:23.46 |
| kens | I'm doubtful there is a whole lot to be gaind here, and I certainly don't want to penalise sensible files in order to make stupid files go faster | 15:23.48 |
| Robin_Watts | paulgardiner, mattchz: For every MuPDFCore we have exactly one globals object. | 15:24.26 |
| mattchz | is it just me, or is ndk-gdb pretty much useless (I've found it mostly useless in other projects too) | 15:24.28 |
| kens | Robin_Watts : I sentthe custoimer the timings, and I don;t think they looked at them, they just complained that 9.14 was 30 times slower. | 15:24.30 |
| paulgardiner | I thought we used to have actual globals but then things went bang if two android MuPDF tasks were open | 15:24.38 |
| jogux | mattchz> ssssh, you're start Robin off about visualgdb :) | 15:24.48 |
| | s/re/ll/ | 15:24.52 |
| mattchz | if it works, I'm all ears ;) | 15:25.02 |
| Robin_Watts | mattchz: VisualGDB rocks. I recommend it. It has a 30 day free trial. | 15:25.23 |
| mattchz | although I can't see how it can, when gdb itself can't even get a stacktrace. | 15:25.26 |
| jogux | I think at least one of Robin or Pete got it working for debugging both java & native? | 15:25.28 |
| Robin_Watts | but you need to use Visual C. | 15:25.34 |
| | That was pete. | 15:25.36 |
| mattchz | and windows | 15:25.39 |
| | :( | 15:25.40 |
| paulgardiner | Robin_Watts: what was the "eh?" concerning? I'd like to remind myself what this stuff does. | 15:25.51 |
| Robin_Watts | Or VisualC under parallels. | 15:25.53 |
| mattchz | yeah, could do | 15:26.00 |
| jogux | mattchz: though I'd tend to agree with you it seeming unlikely it could work if gdb isn't, unless it's just a config issue. | 15:26.16 |
| mattchz | nod | 15:26.23 |
| chrisl | kens: well, I'll look at possibly streamlining some of the FAPI code - it does do a *lot* of dict_find_string() so if I could avoid the string/name conversion for *every* call, there may well be benefits | 15:26.30 |
| mattchz | I could have corrupted the stacks, of course. | 15:26.37 |
| kens | chrisl OK I'll mention that to them in the email. | 15:26.45 |
| Robin_Watts | paulgardiner, mattchz: As I say, We have exactly one globals object for every MuPDFCore object. | 15:26.45 |
| chrisl | kens: couch it as "as and when we have time......." | 15:27.02 |
| kens | OK | 15:27.12 |
| Robin_Watts | If we run 2 copies of MuPDF at the same time, then we get 2 MuPDFCores, and hence we are fine. | 15:27.18 |
| chrisl | kens: I don't want to held to ransom for it! | 15:27.28 |
| kens | Yeah, I think he hsould try the commit I already pointed him at | 15:27.45 |
| mattchz | presumably when we open a new doc, we have 2 MuPDFCores? | 15:27.45 |
| Robin_Watts | so the globals stuff *is* responsible for making sure that we can have multiple mupdf instances running. | 15:27.56 |
| | mattchz: Yes. | 15:27.58 |
| chrisl | kens: sure, that might well give them acceptable performance | 15:28.07 |
| Robin_Watts | But it does *not* allow 2 calls to be made from the app into the core for the same MuPDFCore object at the same time. | 15:28.19 |
| paulgardiner | Robin_Watts: yeah, so two tasks used to be two MuPDFCores and only one set of globals. Your getGlobals thing makes sure there are a set of globals each for the two cores. | 15:28.20 |
| kens | chrisl I believe it will, though they will likely disagree and insist on getting the 8.71 performance back, which almost certainly isn't going to happen. | 15:28.41 |
| Robin_Watts | i.e. it does not protect us from a background thread and a foreground thread calling at once. | 15:28.49 |
| mattchz | hmm. | 15:29.01 |
| | I wonder if i broke this, with my cleanup stuff. | 15:29.07 |
| mvrhel_laptop | Robin_Watts: so for some reason the windows visual studio solution for SOT no longer works for me. I may see if you can help me when I get to the airport if you are around | 15:29.18 |
| chrisl | kens: well, they can keep using 8.71, then - unsupported | 15:29.19 |
| mattchz | because when we shutdown a thread, we make a native call to set the cookie | 15:29.29 |
| kens | chrisl suits me :-) | 15:29.34 |
| Robin_Watts | so, my "eh?" was targetted at my misreading paulgardiners comment about 'tasks' to mean 'threads', sorry. | 15:29.36 |
| | mvrhel_laptop: What error are you seeing? | 15:29.51 |
| paulgardiner | Ah okay I understand now. | 15:29.53 |
| mvrhel_laptop | 1> RuntimeError: Unknown defines found | 15:30.16 |
| | 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "cd ..\epage && python scripts\solution_build.py scripts\winbuild.py -vs2010 da\test-shell -nonet -define=ALL_DAS -define=PDF_EXPORT -define=DEBUG_PUTS_ENABLE -define=EXCEL_EDITOR -define=PDF_ENCRYPT -define=PDF_ENCRYPT_AES -debug -romfss2 -browse-tags && bscmake /v /o ..\solution\sot.b | 15:30.18 |
| | sc ..\genroot\windows\x86\vs2010\debug\nonet\romfss2\heap\all_das\debug_puts_enable\excel_editor\pdf_encrypt\pdf_encrypt_aes\pdf_export\search_enable\en-gb\obj\*.sbr" exited with code 1. | 15:30.19 |
| Robin_Watts | mvrhel_laptop: Oh, right, that's my bad. | 15:30.28 |
| | Damn. Let me get a fix for that committed. | 15:30.38 |
| mvrhel_laptop | oh great! thanks Robin_Watts | 15:30.46 |
| paulgardiner | The intent was that we never call from more than one thread at a time and infact we call almost entirely from the background thread used by AsyncTask | 15:30.49 |
| mvrhel_laptop | I was worried I messed something up | 15:30.50 |
| Robin_Watts | In the meadntime, remove the -define=PDF_ENCYRPT_AES | 15:30.52 |
| paulgardiner | but possibly opening the doc is done from the foreground | 15:31.09 |
| mattchz | yes. | 15:31.23 |
| Robin_Watts | mattchz: I suspect it's matts cancel thing. | 15:31.24 |
| | There is probably a simple fix... | 15:31.35 |
| | the cancel thing doesn't need the 'env' pointer. | 15:31.44 |
| paulgardiner | jogux: I've pushed new versions of those commits to my repo and started a new ATS precommit. | 15:31.58 |
| mattchz | yeah; I'm not using it for cancel. | 15:31.58 |
| | Let me check where I'm calling create/destroy | 15:32.02 |
| Robin_Watts | oh. | 15:32.11 |
| | OK, so the key thing is to identify which method is being called from the foreground while the drawPage is underway. | 15:32.38 |
| | I'd do that with calls to LOG cos I am a luddite. | 15:33.04 |
| mattchz | ok, we are calling create from the main thread. | 15:33.23 |
| | so that's certainly wrong. | 15:33.26 |
| jogux | paul> ah. hm. gen-patch.py -> gen-patch.pl :-) | 15:33.30 |
| Robin_Watts | Calling create from the main thread should be fine, shouldn't it ? | 15:33.48 |
| jogux | paul: with that fixed, LGTM. | 15:33.50 |
| mattchz | and quite likely to clash if we start renders in sequence (e.g. page 1, page 2) | 15:33.57 |
| paulgardiner | bah! | 15:34.08 |
| Robin_Watts | unless I'm misunderstanding what create you are talking about ? | 15:34.19 |
| paulgardiner | yes, that's what I thought, assuming create is what I think it is | 15:34.48 |
| mattchz | no, cos I do: | 15:34.57 |
| | JNIEXPORT jlong JNICALL | 15:35.11 |
| | JNI_FN(MuPDFCore_createCookie)(JNIEnv * env, jobject thiz) | 15:35.12 |
| | { | 15:35.13 |
| | globals *glo = get_globals(env, thiz); | 15:35.15 |
| | if (glo == NULL) | 15:35.16 |
| | return 0; | 15:35.18 |
| | fz_context *ctx = glo->ctx; | 15:35.19 |
| | return (jlong) (unsigned int) fz_calloc_no_throw(ctx,1, sizeof(fz_cookie)); | 15:35.20 |
| | } | 15:35.21 |
| Robin_Watts | Ah, right, so create cookie. | 15:35.32 |
| | Right, so you're not actually using Env in there at all. | 15:35.42 |
| mattchz | no, just get_globals() | 15:35.52 |
| Robin_Watts | So I would do a new version of get_globals | 15:35.55 |
| | get_globals_fg or something. | 15:36.03 |
| | That does get_globals, but doesn't clobber env. | 15:36.11 |
| mattchz | ok, that sounds sane. | 15:36.11 |
| Robin_Watts | That way it's clear which ones are called on the foreground thread etc. | 15:36.32 |
| mattchz | there possibly should be an assert in the other one which checks we're not running on the main thread. | 15:37.03 |
| Robin_Watts | if such a thing is possible in a way that doesn't hurt runtime speeds, yes. | 15:37.55 |
| mattchz | oh, the new thing will need to use env, just not stash it | 15:38.52 |
| Robin_Watts | mattchz: Where will it use it? | 15:44.42 |
| | just in get_globals_fg, right? | 15:45.06 |
| mattchz | yeah | 15:45.14 |
| kens | added it to my mute list | 15:48.10 |
| jogux | arse. runtests in ATS locked up in netman_finalise again, in xml-walk-test. That may need to be investigated, that's the third time at least (not sure if they were all netman_finalise) :-S | 15:48.22 |
| kens | marcosw are you back from vacation now ? I could do with a decrease back to normal proportions in thd customer bug reports.... | 15:48.53 |
| jogux | marcosw: not sure what it was intended for, but possibly notifying failures might be useful? | 15:49.11 |
| Robin_Watts | marcosw: It doesn't offend me. | 15:50.53 |
| marcosw | kens: yes, I'm back from holiday and will resume support duties, anything you need to pass off to me or will you followup with customers you are talking to | 15:52.14 |
| kens | marcosw its not so much handling support duties as the fact that as soon as you go on vacation customers start sending in tiwce hte usual volume of email :-) | 15:53.01 |
| mattchz | I kinda like at least the notification that indicates something has been committed. | 15:53.38 |
| paulgardiner | pedro_mac: I was just about to have another go at getting Good Share to send to SOG, this time uninstalling everything and reinstalling, but I'll need 3 keys for that, unless any of the apps are delegated to others. How many of those keys do we have left? | 15:53.47 |
| mattchz | but fair enough if people find it too noisy | 15:53.49 |
| jogux | hehe | 15:54.05 |
| kens | I dislike the raspberry farting noise from Miranda when 5 commits go off at once | 15:54.05 |
| marcosw | kens: that's because I tell them to keep their questions in reserve until you take over ;-) | 15:54.24 |
| pedro_mac | paulgardiner: Iâve taken the first one from Bradâs most recent list, but the rest should be good | 15:54.42 |
| | if youâll pardon the pun | 15:54.48 |
| kens | marcosw I suspected you gave your vacationdates to a secret customer mailing list :-) | 15:55.00 |
| paulgardiner | :-) thanks pete | 15:55.01 |
| marcosw | yeah, the bulk commits that occur occasionally with mupdf will be annoying, I suppose I should only report ghostscript commits and cluster results. Also I'm thinking I don't need to report cluster jobs starting... | 15:56.20 |
| Robin_Watts | jogux, pedro_mac, paulgardiner: Can one of you nod at the VS change commit on robin/master please? | 15:57.01 |
| | 3rd from the top. | 15:57.13 |
| mattchz | robin/paul> that fixed it, ta! | 15:57.15 |
| Robin_Watts | mattchz: Fab. | 15:57.23 |
| mattchz | mind reviewing the top two commits please? | 15:57.59 |
| | http://git.ghostscript.com/?p=user/matt/mupdf.git;a=summary | 15:58.00 |
| jogux | looks at Robin's commit. | 15:58.02 |
| | robin_watts: assuming it works, LGTM :) | 15:58.57 |
| Robin_Watts | jogux: Ta. | 15:59.11 |
| kens | chrisl It looks sort of like hte performance penalty 'might' be assocaited with pdfwrite requesting glyph widths, though I'mjust guessing. I checked ppmraw @300dpi and while there is a slowdown with 9.14 its not that bad., its a little over 25% (Still bad, but not hundreds of %) | 16:00.39 |
| chrisl | kens: hmmm, we might be able to do the same kind of optimisation that PCL has, so we skip rendering if you're only getting the metrics | 16:01.47 |
| kens | chrisl that might well help some. DOn't go anywhere with it yet though I will need to look further, this is just an idea based on some very lilmited testing and a quick inspection of hte profile. | 16:02.29 |
| | Its clear that pdfwrite is suffering much more than the rendering devices | 16:02.41 |
| | I'm just doign a 72dpi test to see how big the diffs are that way, its possible that the rendering time exceeds the interpretation at 300 dpi by enough to make the performance look OK | 16:03.16 |
| chrisl | kens: there is a problem where we originally skipped rendering glyphs for operations like stringwidth, but that caused problems as the cache code can still expect to get a bitmap to cache, so we ended up with blank entries in the glyph cache | 16:04.33 |
| kens | chrisl yeah that sounds familiar | 16:04.46 |
| chrisl | kens: I'd need to look at the code, but it may simply be a case of pdfwrite setting a flag to disable the rendering - I can't remember right now | 16:05.47 |
| kens | I probably can't tell if its a stringwidth which later gets turned into a real usage. Might need to think about that and look again at the original problem | 16:05.50 |
| mattchz | hmm | 16:06.17 |
| chrisl | kens: It really depends if it is pdfwrite asking for the width, or stringwidth | 16:06.32 |
| kens | chrisl I cancertainly tell if its pdfwrite asking ofr the wiodth, and I can tell if pdfwrite is doing it in the context of a stringwidth | 16:07.03 |
| paulgardiner | pedro_mac: now I can't even provision Good Share. I get "Set-up Failed. Failed to Negotiate Secure Communication" | 16:07.22 |
| | pedro_mac: Ah! I haven't taken on the lastest SDK update yet. That's probably why | 16:07.46 |
| pedro_mac | do you get anything from their diagnostic trace ? | 16:08.00 |
| | not sure the SDK change would affect it tbh | 16:08.15 |
| | they have to support legacy apps too | 16:08.27 |
| paulgardiner | pedro_mac: I've gone mad: that was Good Share I was trying to provision. Can hardly be to do with the SDK I use in SOG | 16:08.55 |
| pedro_mac | paulgardiner: you are using com.picsel.smartoffice2gd for the appid/bundle ID arenât you? | 16:08.57 |
| | thatâs the only setup we can use with trygoodnow.com - they donât have the development IDs permitted in their GC | 16:09.47 |
| paulgardiner | pedro_mac: I think their network is flakey today | 16:09.55 |
| pedro_mac | concurs | 16:10.02 |
| | I have reverted to doing some test using our own setup and AppKinetics for now | 16:11.01 |
| kens | chrisl at 72dpi I see the same sort of performance shape for ppmraw as for pdfwrite. 9.14 is 22 times slower than 8.71, master is 2.5 times slower. So it looks like its more an interpretation problem than pdfwrite as such, the higher resolution just masks the problem somewhat (I can't understand why this didn't show up before, it must be something file-specific). Its still worth thinking about the rendering/width thing, but I'm | 16:11.24 |
| | going to go ahead and send this email to the customer. Then Marcos can have them back :-) | 16:11.24 |
| | OK mail sent, now I need to dash. 25th anniversary today, off out to dinner, goodnight all. | 16:12.30 |
| pedro_mac | is having a minor nightmare with the switching between SOG and <other good apps> just now due to this issue with the singleTop/singleTask change :( | 16:12.37 |
| jogux | kens: enjoy! | 16:12.42 |
| | (and congrats :) ) | 16:12.48 |
| kens | Thanks :-) | 16:12.52 |
| pedro_mac | kens: cool - have a good one :) | 16:12.54 |
| mattchz | have a good one kens :) | 16:12.54 |
| henrys | marcosw: are you back? if so you should tell sriram rayâs on vacation. | 16:14.38 |
| Robin_Watts | jogux, pedro_mac, paulgardiner: So I've spent the day looking at SmartArt, and what would be involved. | 16:22.57 |
| | It looks like it's a huge amount of work. | 16:23.14 |
| pedro_mac | yup | 16:23.19 |
| Robin_Watts | There are multiple layout algorithms. | 16:23.22 |
| | All of which seem to require layout to happen based on rules defined in the XML. | 16:23.50 |
| | For instance, a simple one would be 'set the width of the child element to be a 5th of the width of the parent element' etc. | 16:24.17 |
| | I was hoping that we could do deal with the smartart stuff before the edr level, so we'd produce a single set of Edr from the data, and that would be it. | 16:26.54 |
| | but I fear that's not general enough. We probably need to extend Edr so that it's capable of redoing the layout when margins etc change. | 16:27.23 |
| jogux | yeah, sounds likely. people will want to at least be able to edit the text I'd guess too :-S | 16:27.53 |
| Robin_Watts | which means adding a whole new set of brains to the Edr/Layout stuff. | 16:28.02 |
| jogux | do they have styling rules type stuff? | 16:28.25 |
| Robin_Watts | Oh yes. | 16:28.47 |
| jogux | joy :-S | 16:28.55 |
| Robin_Watts | Every diagram has at least 4 parts. | 16:28.59 |
| | data1.xml that contains the actual data for the given slide. | 16:29.14 |
| | (brb) | 16:29.21 |
| pedro_mac | there are also fun parts like text rendered along paths (doable), extrusions and other fun bits | 16:29.42 |
| Robin_Watts | layout1.xml that contains information of how to lay things out (here are some constraints, lay out this property of this object based on this property of other objects etc, complete with if/then/else logic) | 16:32.04 |
| | quickstyle1.xml styles to use | 16:33.05 |
| | colors1.xml different color sets to apply. | 16:33.14 |
| | pedro_mac: text rendered along paths is something I'd be up for having a go at. That's more my area :) | 16:33.37 |
| | Plus there are 3d lighting effects etc. | 16:33.54 |
| jogux | I'm vaguely surprised if we don't already have text along paths somewhere. | 16:34.01 |
| pedro_mac | yeah, think its quite a feasible feature with wasp/layout - used for watermarks too, which we dont support yet | 16:34.17 |
| jogux | robin_watts: 3d light effects falls into the "would be nice but you can see the content without them" area hopefully? | 16:34.25 |
| Robin_Watts | jogux: Yeah. | 16:34.31 |
| jogux | I bet/hope they're only quick fake lighting anyway :-) | 16:35.10 |
| Robin_Watts | I'm going to have a quick look at the chart stuff to see if there is any crossover here. | 16:35.23 |
| | if so, mvrhel_laptop may want to bear that in mind... | 16:35.38 |
| | jogux: Have you had any luck with the powerpoint style stuff? | 16:36.09 |
| jogux | robin_watts: after staring at edr for a bit I'd found a bug. | 16:36.21 |
| | I've | 16:36.23 |
| | [style selector is in the wrong order in one case, which breaks a whole bunch of docs] | 16:36.54 |
| Robin_Watts | Ah. | 16:37.01 |
| jogux | which I *hope* breaks a whole bunch of docs. | 16:37.07 |
| | because there's a whole bunch broken :) | 16:37.14 |
| | robin_watts: at some point I suspect I need to ask you what + bool isPlaceholder = 1; /* FIXME: RJW */ means :-) | 16:38.26 |
| Robin_Watts | jogux: Oh, right. | 16:38.39 |
| jogux | I'm assuming something like "I need to do the same here as I did in other places", but not sure if there's more to it | 16:38.50 |
| Robin_Watts | Well, my plan was to explicitly add 'PH' and 'NPH' selectors to the Edr. | 16:39.08 |
| | where PH would be put on Placeholder content, and NPH on non-placeholder content. | 16:39.22 |
| | So that we'd never inadvertently get placeholder stuff inheriting from non-placeholder stuff, as I believe was the problem in that file. | 16:40.24 |
| | (and vice versa) | 16:40.33 |
| jogux | yep | 16:40.49 |
| Robin_Watts | In order to do that, we need to know whether groups are placeholder content or not. | 16:40.53 |
| | So in various places I have isPlaceholder. | 16:41.13 |
| | In a lot of places I actually had the data as to whether they were/weren't to hand, but in one or two, I didn't. | 16:41.48 |
| | so I hardwired them for now. | 16:41.54 |
| | I got it to the stage where the Edr looked correct, and it still wasn't doing the right thing, so I never pushed the rest of the changes through. | 16:42.22 |
| | If you think that's blocking anything I'll happily revisit it. | 16:42.39 |
| jogux | ok, fair enough. so to sum up: if everything seems to be working just delete the FIXME? :-) | 16:44.52 |
| Robin_Watts | No. :) | 16:45.14 |
| jogux | damn | 16:45.16 |
| Robin_Watts | If everything seems to be working, pass it back to me and tell me to fix the fixme :) | 16:45.31 |
| jogux | okay, great, ta :-) | 16:45.39 |
| Robin_Watts | So I think I've convinced myself that, SmartArt is *not* what we should be looking at next. Just because it's a massive amount of work, and I'm sure there must be *something* better to do (something that might actually reasonably be expected to work by september for example) | 16:46.06 |
| | If mvrhel is going to look at charts, I might look at the crash you pointed out. | 16:46.53 |
| jogux | mvrhel could have that as stage 2 induction :-) | 16:47.18 |
| Robin_Watts | that would be cruel... | 16:47.33 |
| jogux | how about http://bugs.ghostscript.com/show_bug.cgi?id=695011 for you? | 16:47.43 |
| | albeit that may be cruel too :-) | 16:47.56 |
| Robin_Watts | Yeah, cos my previous interactions with edr/style have worked so well :/ | 16:48.44 |
| | but sure. | 16:48.51 |
| | but first I'm going to read about charts... | 16:49.11 |
| jogux | robin_watts: it's okay, that one is not edr/style, just layout ;-) | 16:49.45 |
| Robin_Watts | Does python have an atexit ? | 16:52.37 |
| | If you break out of a build, it leaves the status files set in the genroot. | 16:53.01 |
| jogux | it doesn't for me. | 16:53.13 |
| Robin_Watts | On windows ? | 16:53.41 |
| pedro_mac | it does (most of the time) for me too on âdoze | 16:54.05 |
| jogux | robin_watts: mac / linux | 16:54.33 |
| | https://docs.python.org/2/library/atexit.html#module-atexit | 16:54.36 |
| Robin_Watts | pedro_mac: Start a build from the solution, cancel it, then build again... | 16:54.38 |
| pedro_mac | Robin_Watts: yeah, it fails for me too | 16:55.11 |
| jogux | I think I more meant: I wonder why it works on unix. | 16:55.56 |
| | ah, I guess it falls down the finally: | 16:56.16 |
| | try: | 16:56.19 |
| | targetCfg = buildoptions.BuildOptions(targetbldflg, tgtProps, fetcher, False) | 16:56.19 |
| | toolCfg = buildoptions.BuildOptions(toolbldflg, hostProps, fetcher, True) | 16:56.21 |
| | results = build.run(targetBld, targetCfg, toolCfg, time.time()) | 16:56.22 |
| | finally: | 16:56.23 |
| | status_decr(target_status, "Can't find the status file for the target.") | 16:56.24 |
| | I guess ctrl-c goes down to the compiler and causes it to fail perhaps, rather than the python process getting it. | 16:56.49 |
| | I guess setting a building flag before / clear after build.run (and in the finally), and calling status_decr from atexit if building is true? | 16:59.22 |
| | oh, scratch the 'clear after build.run' bit of course. | 16:59.42 |
| Robin_Watts | It's not clear that the atexit will actually be called. | 17:00.28 |
| jogux | I was wondering how VS is killing the process, if it even knows | 17:01.12 |
| | oh, apparently ctrl-c would be translated into a KeyboardInterrupt exception. | 17:02.54 |
| Robin_Watts | warning MSB5021: "cmd" and its child processes are being terminated in order to cancel the build. | 17:03.49 |
| jogux | well, fairly easy to test and see if atexit is running anyway | 17:06.23 |
| | I'm not sure what else you can do if it's not | 17:06.30 |
| marcosw | henrys: yes, I'm back. | 17:11.07 |
| Robin_Watts | it's not called. So I think I'm out of luck. | 17:12.21 |
| mattchz | robin/wurz> did you get a chance to look at my commits? | 17:14.18 |
| Robin_Watts | mattchz: Sorry, will look now. | 17:14.29 |
| mattchz | np | 17:14.35 |
| | last two commits (one is just a patch submitted by someone) | 17:14.44 |
| Robin_Watts | Are you putting the ...'s into the git commit message? Or is that something git is doing ? | 17:16.08 |
| mattchz | in the titles? | 17:16.37 |
| Robin_Watts | look good to me. | 17:16.38 |
| | yeah. | 17:16.40 |
| mattchz | I think it's just truncating my messages? | 17:16.51 |
| jogux | robin_watts: maybe just add a -ignorestatusfile option that's used only in your solution? | 17:16.59 |
| mattchz | is the first line too long? | 17:17.14 |
| Robin_Watts | jogux: Ah, could do, yes. | 17:17.17 |
| marcosw | henrys: it looks like Sriram is asking for a gswin32c.exe build that includes some changes to base/gsdparam.c that Ray sent. What's our current policy for building custom executables for customers? | 17:17.29 |
| jogux | or just remove the status file and make the same assumption as 'make' etc do that no one would be stupid enough to try and build the same source tree twice at the same time | 17:17.38 |
| Robin_Watts | mattchz: Figure on 60 chars as being good, because you want the output of git logg to fit on single lines. | 17:17.43 |
| mattchz | Ok. Want me to change those? | 17:17.58 |
| Robin_Watts | alias.logg=log --graph --oneline --decorate --all | 17:18.07 |
| | Nah, we'll live. | 17:18.12 |
| mattchz | ok, ta. | 17:18.16 |
| jogux | mattchz: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html is a small rant that's probably applicable :) | 17:19.52 |
| Robin_Watts | good link. | 17:21.21 |
| mattchz | slightly scared to click that domain ... | 17:22.27 |
| pedro_mac | heads off now | 17:23.47 |
| marcosw | Robin_Watts: did you see the email to you with the subject "image quality issue on ppt file"? | 17:25.22 |
| | clusterqueue | 17:25.37 |
| mattchz | Yeah; that article's good. | 17:25.48 |
| | I mostly do try and put a subject on the first line, but sometimes it runs over 50 chars. | 17:26.01 |
| Robin_Watts | marcosw: I did not. | 17:26.18 |
| marcosw | it's from the customer who originally emailed using the subject: "I8101(2.1.8) can not load whole word file" | 17:27.02 |
| Robin_Watts | marcosw: I've found it, thanks for that. | 17:27.58 |
| jogux | that latest support email is I think a request that we update http://apps.samsung.com/venus/topApps/topAppsDetail.as?productId=000000397746&srchClickURL=|@sn=SAPS|@qh=-1769983360|@qid=SAPS.SRCH.PRX|@q=smart+office|@tot=719|@idx=9|@doc=G00006046398|@title=nil - no idea what's involved in that, if we even have the login id for that, etc :-S | 17:30.01 |
| | sigh. this style rule still isn't matching now I've fixed it. so I'll be back into debugging the same problem Robin thought he had :-S | 17:32.52 |
| | time to cycle home. night all. | 17:35.21 |
| mvrhel_laptop | Hi Robin_Watts: Grabbed the latest and building now. | 17:45.07 |
| | it builds now. Thanks Robin_Watts | 17:52.32 |
| mattchz | hometime, night all | 18:00.42 |
| Robin_Watts | getLastSelectableObj seems to be a poorly named (or implemented) function. | 19:30.07 |
| pedro_pc | is that a layout/displaylist function? | 19:33.36 |
| Robin_Watts | it's an edr-selection-text one. | 19:37.15 |
| | maybe I'm wrong. | 19:37.25 |
| | Maybe "last selectable objects" should never be groups? | 19:39.56 |
| | will play more later. | 19:40.02 |
| pedro_pc | it looks a bit odd on first inspection | 19:40.24 |
| | Forward 1 day (to 2014/06/24)>>> | |
IRC Logs