| | <<<Back 1 day (to 2014/07/07) | 2014/07/08 |
| tkamppeter | Is there already some decision whether someone from Artifex will come to the OpenPrinting Summit? | 09:04.54 |
| chrisl | tkamppeter: I don't know - I suspect there are very few people available..... given holidays and the current workload | 09:16.56 |
| mattchz | morning | 09:31.02 |
| Robin_Watts | morning. | 09:31.20 |
| jogux | hello! | 09:53.57 |
| Robin_Watts | tkamppeter: I *think* mvrhel may have said he might be available to do a phone in. | 10:04.19 |
| mattchz | anybody have any thoughts about whether I should upload the 1.5 build to apple? | 10:11.02 |
| jogux | mattchz: I'd say do it :-) | 10:11.38 |
| mattchz | 'k | 10:11.43 |
| jogux | not sure if there's anyone else that could be persuaded to try the testflight build | 10:12.04 |
| | worth asking tor8 when he appears I guess | 10:12.17 |
| mattchz | and as if by magic... | 10:18.07 |
| | hi tor8 | 10:18.17 |
| tor8 | hi matt. | 10:18.40 |
| mattchz | tor8: we were wondering if we should go ahead and upload the 1.5 build to apple. | 10:18.47 |
| | unless you can think of anyone who would be interested in doing more testing. | 10:18.58 |
| | ? | 10:19.04 |
| tor8 | this is the #4 build on testflight? | 10:19.12 |
| mattchz | #5, I think | 10:19.22 |
| tor8 | does it include my CBZ patch from yesterday? | 10:19.37 |
| mattchz | no, #4 | 10:19.39 |
| | nope, doesnât. | 10:19.45 |
| | I can do another with that in if you like. | 10:19.50 |
| jogux | is just installing ios8b3, so I'll have a go with it on there | 10:20.01 |
| mattchz | jogux> cool ta | 10:20.27 |
| tor8 | mattchz: if it's not too much of a bother, I'd like it included. now that we actually can open CBZ files it'd be a shame if the page order ends up being wrong... :) | 10:21.00 |
| mattchz | np | 10:21.07 |
| | make sense. | 10:21.15 |
| tor8 | and given that we don't generally do releases that often... | 10:21.28 |
| mattchz | sure, sounds good. | 10:21.54 |
| | please would someone mind reviewing http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commit;h=bd61a5f21b390631ee68a8bd3d3a674e37910093 | 10:22.15 |
| | I canât remember if we decided if this was ok from an IPR point of view (contributor agreement etc) | 10:22.36 |
| | anyhow, the code works well. | 10:23.00 |
| Robin_Watts | mattchz: Can we hold off until this afternoon? | 10:24.17 |
| | We can check with henrys/miles as to whether we have a CLA from Michael. | 10:24.32 |
| mattchz | sure, np. itâs a trivial patch if that makes any difference. | 10:24.59 |
| Robin_Watts | mattchz: Yeah, it's pretty trivial. | 10:25.10 |
| | curses. PDF images aren't created as reopenable Images :( | 10:35.59 |
| | mattchz: Is it fair to assume that all estreams passed to image as image sources must be seekable ? | 10:38.06 |
| mattchz | not sure. | 10:39.39 |
| | http images arenât, but itâs possible we wrap them in a seekable wrapper (cachefss?) | 10:39.57 |
| jogux | if they weren't, image would have to permanently keep around either the source or decoded form itself? | 10:40.04 |
| mattchz | I think they must be; I assume we seek to 0 when we redecode. | 10:40.23 |
| | so, I think the answer is yes | 10:40.38 |
| | possibly if it supports reopening, it doesnât need to be seekable, but otherwise it does? | 10:42.08 |
| Robin_Watts | jogux: That was exactly what I was afraid of. | 10:42.15 |
| | mattchz: I wondered if there was a mode whereby when the Image component finished decoding an image, it could say "and pin this in memory cos I can't decode it again". | 10:42.54 |
| mattchz | very possibly. I canât remember exactly tbh. Just looking at the code. | 10:43.26 |
| | * dimensions check) to allow the CacheFss entry to become evictable. | 10:44.24 |
| | * | 10:44.26 |
| | * We are only allowed to close the estream if the source is | 10:44.27 |
| | * re-openable. Also, while not *mandatory*, if the decoder has requested a | 10:44.29 |
| | * persistent stream, we'll be nice and not close it. | 10:44.30 |
| | * | 10:44.32 |
| | * We also do not close the estream if we've got RetainSource enabled, | 10:44.33 |
| | * because it adds extra complication because of the duplicated (tee) estream | 10:44.34 |
| | */ | 10:44.35 |
| | bah, I missed the top line: /* Close the estream if possible. This is called after each decode (or | 10:44.36 |
| | afaics, seeking is mandatory. | 10:45.58 |
| Robin_Watts | So, if someone does Image_getSource and the stream is not reopenable, I can: | 10:46.10 |
| | 1) lock the imdec, 2) store the position of the estream, 3) seek to 0, 4) pull the data out into a buffer, 5) seek back to the old pos, 6) unlock, 7) make an estream from that data, 8) return that. | 10:47.06 |
| | Possibly I can skip 2/3/5 as the estream should always be at 0 if it's not mid decode. | 10:47.44 |
| mattchz | sounds likely. | 10:47.52 |
| Robin_Watts | and middecode implies locked, I think. | 10:47.55 |
| mattchz | in convertFile(), we seek to 0 anyway. | 10:48.51 |
| | hmm, not sure about getDimensions(), but I think that only happens once on the first decode | 10:49.36 |
| Robin_Watts | mattchz: I'm assuming that some lock or other must be held during the getDimensions/decode process. | 10:50.22 |
| mattchz | yeah. claim lock, iirc | 10:50.30 |
| Robin_Watts | so if I take the same lock, I'll know I'm not interrupting. | 10:50.37 |
| | Pal_Thread_mutexHeldAssert(&(imdec->claimlock), | 10:50.48 |
| | ISSYNC(imdec) && !ISASYNCREQUEST(imdec)); | 10:50.50 |
| mattchz | one oddity: âbool persistent; true if the decoder requies a persistent estream" | 10:50.59 |
| | let me see what that means. | 10:51.04 |
| Robin_Watts | So the claim lock is not held for async requests ? | 10:51.20 |
| mattchz | robin_watts: I wonder if we can bin all the asynchronous stuff now. It was only really used for the browser. | 10:51.32 |
| | robin_watts: I donât think so, although it may be held very briefly while changing critical info. | 10:51.45 |
| | e.g. dimensions. | 10:51.49 |
| | it wonât be held while decoding pixel data though. | 10:51.57 |
| Robin_Watts | right, so probably I should fail getSource if it's an async imdec. | 10:52.18 |
| mattchz | however, the code is structured such that an sync decode cannot happen while an async one is in progress. | 10:52.32 |
| | robin_watts: is this to determine the colorspace? | 10:53.09 |
| | oh, to actually get the source? | 10:53.24 |
| Robin_Watts | mattchz: No, this is to get the original data so I can write it out. | 10:53.27 |
| | yeah | 10:53.29 |
| mattchz | hmm, Iâm not sure. Itâll possibly work if itâs been teed. | 10:53.42 |
| | I canât remember. | 10:53.48 |
| | but sounds safe to do so if you want to be safe. | 10:53.54 |
| Robin_Watts | It only gets teed if "RETAIN_SOURCE" is set. | 10:54.01 |
| mattchz | ah. | 10:54.06 |
| Robin_Watts | and I don't want to set that as it increases memory use. | 10:54.16 |
| mattchz | I thought Image_getSource() didnât work at all without RETAIN_SOURCE set? | 10:54.32 |
| Robin_Watts | The point of this is to make it work :) | 10:55.21 |
| mattchz | ah, okay. | 10:55.35 |
| | tbh, Iâd really be tempted (long term), to ditch all the asynchronous stuff. | 10:55.46 |
| Robin_Watts | Yesterdays fix made it work without RETAIN_SOURCE, but with supportsReOpening. | 10:55.47 |
| mattchz | it would simplify the code an awful lot. | 10:55.56 |
| Robin_Watts | I see the attraction of that, but I worry that we'd discover that it was used in other places. | 10:56.27 |
| mattchz | so now youâre making it work with !RETAIN_SOURCE and !supportsReOpening. | 10:56.34 |
| | ? | 10:56.35 |
| Robin_Watts | like didn't Gavin use it in Disptree? | 10:56.38 |
| | that's the plan, yes. | 10:56.44 |
| mattchz | not sure I can even remember what DispTree is these days | 10:56.55 |
| Robin_Watts | !RETAIN_SOURCE && !supportsReOpening && !isAsync | 10:57.10 |
| mattchz | nod | 10:57.16 |
| | is DispTree Lomond? | 10:57.19 |
| Robin_Watts | Disptree is used in Lomond, I think. | 10:57.28 |
| mattchz | ah, fair enough. you might be right actually. | 10:57.41 |
| Robin_Watts | I remember there being lots of AsyncImage stuff in various reviews. | 10:57.45 |
| mattchz | yeah, sounds right now you mention it. | 10:57.51 |
| | bin Lomond :) | 10:57.55 |
| Robin_Watts | ha! | 10:57.59 |
| | Osama bin Lomond. Responsible for atrocities and acts of terror in the early noughties. | 10:58.44 |
| mattchz | haha | 10:58.56 |
| | and clearly the reverberations are still being felt | 10:59.05 |
| | oh. | 10:59.32 |
| | you may want to look at Image_Decoder_requestPersistentStream(), and see if that causes any problems. | 10:59.42 |
| | I think itâs used in JPEG. | 10:59.49 |
| jogux | mattchz : latest build seems okay on ios8b3. still crashes trying to delete a file :( | 11:00.27 |
| mattchz | aww | 11:00.37 |
| | thanks for testing. | 11:00.39 |
| | same error? | 11:00.54 |
| | in fact, that looks like it could screw things up. | 11:01.22 |
| paulgardiner | Oh yeah the delete file crash. I meant to look at that. From tests I did, it looked like it was an out by one error | 11:01.39 |
| mattchz | oh I fixed that | 11:01.47 |
| paulgardiner | Ah right. | 11:01.52 |
| mattchz | it also would delete the wrong file :) | 11:01.55 |
| | this is an ios 8 specific bug I think | 11:02.17 |
| paulgardiner | Yeah exactly | 11:02.21 |
| Robin_Watts | mattchz: Ah, so that's for partial decode. | 11:02.29 |
| jogux | mattchz : not sure, don't seem to be getting console output :( | 11:02.34 |
| mattchz | nom | 11:02.40 |
| Robin_Watts | goes to eye appt. back later. thanks! | 11:02.51 |
| mattchz | robin_watts: so I *think* if the estream is persistent, youâll need to do the âremember positionâ, seek to start thing, then seek back. | 11:07.59 |
| | then again, that in itself may not be safe. I canât remember if the jpeg code stashes pointers to within the estream data which would change if you were to do a seek. | 11:08.28 |
| jogux | is it possible to duplicate the estream instead? | 11:09.00 |
| mattchz | jogux: Iâm not sure if thatâs only possible if youâve got a tee. | 11:09.23 |
| | I think that was the point of the tee iirc | 11:09.30 |
| | Robin_Watts: actually, what you should probably do is tell the decoder that the estream has been closed, so that it can get a new one next time. | 11:11.46 |
| | Image_Internal_closeFile looks like it does that. | 11:11.57 |
| | Image_decoder_closeStream() seems to be an example of where this happens, although I canât find any code that actually calls it in practice;. | 11:17.11 |
| | It states: | 11:17.40 |
| | * Close the Image's EStream. Used by image codecs that decode the image | 11:17.41 |
| | * data outwith the Image library and need to re-open the source image. | 11:17.41 |
| | w | 11:17.48 |
| | whatever that means ;) | 11:17.52 |
| | ah, that function was used in PAV | 11:19.33 |
| | which was long deleted, I guess. | 11:19.55 |
| tor8 | mattchz: mupdf 1.5#5 works fine on my iPad 2 with iOS 7.1.1, no problems navigating links in XPS files or annotating PDF files and opening all the file types we support from safari and/or google drive | 11:20.13 |
| mattchz | excellent | 11:20.27 |
| jogux | mattchz: tor8 : I guess we're good to submit to Apple then ? | 11:20.56 |
| tor8 | jogux: I think so. I don't think we're going to get much more testing done without letting users have a go at it :) | 11:21.52 |
| jogux | did we want to try and throw crashlytics in somehow? | 11:22.16 |
| | we're getting a lot of good data out of SO with crashlytics :-S | 11:22.25 |
| | possibly just take a release branch, add crashlytics in and upload from there? that avoids robin's (I think) concerns about forcing it onto other people | 11:23.21 |
| mattchz | I wonder if we can distribute the Crashlytics stuff in public git though. | 11:24.22 |
| | I guess we could just not push that branch. | 11:24.27 |
| tor8 | jogux: I believe the open source incompatibility makes it difficult. | 11:24.50 |
| jogux | :-( that's a pain. | 11:25.33 |
| tor8 | but it's certainly possible to make the iOS build from an unpublished (or only accessible via ssh on casper) git | 11:25.33 |
| | depends on how the source integration works. | 11:25.58 |
| mattchz | is the open source thing an actual problem? | 11:26.00 |
| | I was just concerned it might be. | 11:26.05 |
| tor8 | if it's not a secret API, then we can #ifdef the stuff and publish it in our git | 11:26.28 |
| mattchz | I was just wondering about redistributing the closed library. | 11:27.03 |
| tor8 | but if there's any EULA bullshit that you can't publish source that uses crashlytics, then we're in a tougher spot | 11:27.06 |
| mattchz | and also our API key. | 11:27.07 |
| tor8 | the API key should probably be kept secret | 11:27.21 |
| jogux | the code change is pretty much a single line to initialise their sdk. | 11:27.22 |
| mattchz | with the API key. | 11:27.35 |
| jogux | which has the API key in it... yeah. | 11:27.39 |
| tor8 | and the code could be #ifdef'd and set with makefile flags for the Xcode build | 11:27.46 |
| jogux | so, yeah, probably shouldn't publish that. | 11:27.46 |
| | private git seems the only way really. shame. | 11:28.47 |
| tor8 | set the API key from a makefile environment variable -DSECRET=$(SECRET_KEY) and set the variable in your .bashrc? | 11:28.47 |
| mattchz | as robin said though, we can #include a file with the secret in it, and have that not in the main git. | 11:29.04 |
| tor8 | might be more hassle than just having a private git for the crashlytics release | 11:29.06 |
| | mattchz: that'd work too, as long as it doesn't try to build that by default | 11:29.40 |
| mattchz | weâd check an empty file into git, I think. | 11:29.50 |
| | or something. | 11:29.55 |
| tor8 | mattchz: #ifdef HAVE_CRASHLYTICS #include "secret.h" was what I had in mind :) | 11:30.15 |
| | and then in the makefile just make -DHAVE_CRASHLYTICS depend on the presence of secret.h (or the thirdparty/crashlytics/ binaries) | 11:30.43 |
| | or however it's done | 11:30.54 |
| | anyway, I think it'd be good to have. iOS users are not very good at reporting bugs themselves. | 11:31.13 |
| mattchz | yeah. | 11:31.18 |
| | Iâll email crashlytics and ask them about the licensing issue. | 11:31.25 |
| jogux | maybe that should just go into the enhancement list rather than holding up this release. dunno. :) | 11:39.04 |
| mattchz | http://pastebin.com/bZWcTMsm | 11:41.23 |
| | does that describe the situation correctly? | 11:41.28 |
| jogux | pretty much. I think Artifex could add a GPL exception for crashlytics to solve the AGPL3 problem, but not sure what craslytics license is | 11:42.34 |
| | I think there's at least one copy of the crashlytics sdk in a github project already :) | 11:42.44 |
| mattchz | :) | 11:42.50 |
| | ok, sent. | 11:43.09 |
| | letâs see what they say. | 11:43.11 |
| | ok, Crashlytics has passed on my query to their legal guy at twitter | 12:43.35 |
| | Iâm tempted to close this as weâve made a change, canât reproduce the original issue anyway. | 13:13.34 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=693607 | 13:13.35 |
| | Unless we want to try and get hold of one of those devices specifically? | 13:13.46 |
| | also, tempted to kill this: | 13:14.10 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=694523 | 13:14.11 |
| jogux | would close with a comment saying 'please reopen if you can reproduce in the 1.5 release' or something :) | 13:14.50 |
| mattchz | the random fix I tried for the first bug didnât make it into 1.5 | 13:15.29 |
| | (android) | 13:15.38 |
| | second one, I agree we can close. | 13:15.50 |
| | if Crashlytics is possible btw, we should do Android too maybe. | 13:17.55 |
| | rebooty... | 13:24.27 |
| jogux | btw, forums, Ron needed to setup a entry in artifex dns - anyone know who has access to edit that? | 13:42.05 |
| chrisl | Ray usually does the DNS stuff | 13:42.51 |
| jogux | thanks Chris, I'll drop him an email | 13:49.10 |
| jogux | tries to remember / find the hostname we decided on for forum | 13:51.19 |
| | ahha, smartoffice-forum.artifex.com | 13:52.20 |
| | only had to search through 10 days logs ;) | 13:52.26 |
| henrys | it will be nice to refer these folks to a forum instead of the black hole | 13:54.21 |
| jogux | I guess we could actually reply to the emails :-) | 13:55.10 |
| henrys | Robin_Watts: which bug is Michael on? | 13:55.19 |
| jogux | he's still doing chart stuff I presume | 13:55.31 |
| | Robin's out at the opticians | 13:55.37 |
| henrys | jogux: I saw the note about Michael and a CLA - is he a contributor to MuPDF? | 13:56.41 |
| mattchz | henrys: yes | 13:56.57 |
| jogux | henrys : yep, he put a patch on an android bug which mattchz wants to use if possible | 13:57.20 |
| mattchz | henrys: http://bugs.ghostscript.com/show_bug.cgi?id=693228 | 13:57.21 |
| mvrhel_laptop | henrys: I am still making my way through the chart stuff | 13:57.40 |
| | I am working today on getting the extra color info into the edr | 13:57.50 |
| | my goal is to have something that works and can be reviewed by the end of this week or early next week | 13:58.36 |
| henrys | mvrhel_laptop: sorry confusion - this person Michael Cadihac needs a CLA I was asking what bug he was working on to get this email address | 13:59.35 |
| jogux | henrys : ah. right. sorry :-) | 13:59.49 |
| mvrhel_laptop | oh. wrong Michael | 13:59.53 |
| mattchz | henrys: please see the link above | 14:01.47 |
| henrys | mattchz: yes I used it thanks, sorry I should have said something | 14:02.12 |
| mattchz | ah, np | 14:02.18 |
| | :) | 14:02.19 |
| | ls -l | 14:02.21 |
| | oops, sorry :) | 14:02.26 |
| henrys | mattchz: wrong window | 14:02.36 |
| mattchz | heh | 14:02.56 |
| Robin_Watts | is back. | 14:06.40 |
| | Many many interesting technological scans of the eye later, and... can't see anything significant wrong. | 14:07.10 |
| mattchz | weird | 14:07.23 |
| paulgardiner | That has to be good news. | 14:07.30 |
| Robin_Watts | I have an appt with a Vitreo-Retinal specialist next monday. | 14:07.33 |
| | yeah, at least I know I haven't had another bleed like the last one. | 14:07.53 |
| mattchz | phew | 14:08.17 |
| paulgardiner | Robin_Watts: you sure you don't have smear on your glasses? :-) | 14:08.18 |
| mattchz | thatâs a relief. | 14:08.19 |
| Robin_Watts | paulgardiner: I have checked. Many times :) | 14:08.40 |
| henrys | Robin_Watts: good news but it would be best to know the root of it. | 14:10.03 |
| Robin_Watts | henrys: Indeed. It looks like there might be some "bleaching" evident in one of the photos that might explain stuff. Might be caused by the previous bleed. | 14:12.07 |
| henrys | next meeting is at the O.K. Corral: http://chicago.cbslocal.com/2014/07/07/11-killed-at-least-60-wounded-in-citywide-shootings-this-weekend/ - wow | 14:13.47 |
| Robin_Watts | henrys: "So, you want me to work on smart office?" bang bang! | 14:15.18 |
| henrys | Robin_Watts: hopefully youâre eye problem wonât effect ducking quickness | 14:16.23 |
| mattchz | jaman codepage | 14:17.37 |
| | bah..not doing well today. | 14:17.47 |
| henrys | s/youâre/your even | 14:18.11 |
| jogux | robin_watts : I now know the cause of the editting issue with ppt's after the NPH/PH changes. essentially PH TxLevel-1 now seems to be missing Display: block, and that causes the editting code to get confused and screw up the edr. | 14:18.50 |
| | I don't know where to give it Display: block though. | 14:19.04 |
| mattchz | henrys: so that happened where you guys are meeting? | 14:19.08 |
| Robin_Watts | mattchz: Next meeting is in "Chicago". | 14:19.20 |
| mattchz | ah. big place. | 14:19.24 |
| | no wonder robin_watts has been practising with clays then | 14:19.45 |
| jogux | pops to get some chocolate/cakes. | 14:19.52 |
| henrys | mattchz: yeah big city but even so those are big crime numbers for a weekend | 14:20.14 |
| Robin_Watts | mattchz: Random thought on the image_getSource thing. | 14:21.05 |
| | could I maybe just tee the estream in image_getSource? | 14:21.36 |
| mattchz | I think probably not. | 14:21.57 |
| | but Iâm not sure. | 14:22.10 |
| | Maybe you can if itâs not in use? | 14:22.49 |
| | possibly | 14:22.55 |
| Robin_Watts | yeah, I was thinking take the imdec lock so we know it's not middecode, then tee it. | 14:23.26 |
| mattchz | might work if itâs not async. | 14:23.49 |
| Robin_Watts | yeah. | 14:23.55 |
| mattchz | and itâs not persistent. | 14:23.55 |
| Robin_Watts | will ponder on that. | 14:23.59 |
| mattchz | (the JPEG thing for partial decode) | 14:24.07 |
| | Hold on, whatâs the problem with always teeing those non-reopeneable estreams? | 14:24.54 |
| | either way, we have to keep the source data around surely? | 14:25.18 |
| Robin_Watts | We can only tee while the estream is seeked to 0. | 14:25.20 |
| henrys | marcosw: I have a duplexing printer now and wonât have to bug you. The color laserjet pro is a nice replacement for the 4700 - about 1/2 the size | 14:25.30 |
| mattchz | I mean, we want to avoid RETAIN_SOURCE | 14:25.36 |
| Robin_Watts | and tee isn't terribly efficient. It copies the data, I think. | 14:25.43 |
| henrys | marcosw: pro 400 that is | 14:25.57 |
| mattchz | robin: as i remember it (cbw), it locks the underlying estream and multiplexes | 14:26.07 |
| marcosw | henrys: unless the customer's expected behaviour doesn't match your printer, then you'll want me to see if the duplexing is consistent across different models :-) | 14:26.26 |
| Robin_Watts | You are right. | 14:26.40 |
| mattchz | it might copy 256 bytes worth, possibly. | 14:26.56 |
| Robin_Watts | mattchz: Can't see that it does. | 14:27.29 |
| henrys | marcosw: actually to do duplexing completely right weâd have to get into custom behavior for different printers. Iâd like to stay away from that and be satisfied with a 95% solution | 14:27.38 |
| mattchz | I guess my point is âwhy is retain source bad?â | 14:27.40 |
| Robin_Watts | mattchz: That's a very good question. | 14:27.52 |
| mattchz | if presumably, weâll need to keep an estream around. | 14:28.02 |
| Robin_Watts | Let me run a fortify build of the test shell, with and without that flag set. | 14:28.22 |
| | and see how peak memory use changes. | 14:28.32 |
| mattchz | oh, is this in the case where the source is larger than the decoded version? | 14:28.36 |
| Robin_Watts | I don't care about that case, cos I think it's rare. | 14:29.08 |
| henrys | meeting in a few minute but I donât have much for gs or mupdf - a couple things | 14:29.21 |
| mattchz | retain source may have pre-dated the use of estreams throughout image. | 14:29.56 |
| Robin_Watts | retain source works by teeing I believe. | 14:30.36 |
| mattchz | Iâm really glad I wrote lots of comments/long commit messages | 14:32.03 |
| henrys | Miles was late to tell me and I think a few others know but Takane-san is no longer with Artifex. His arrangement was temporary but Iâll certainly miss him. If anyone knows of an account open that we should close let me know. I donât think he has anything on casper | 14:32.36 |
| mattchz | robin: originally RetainSource used by duplicating a file handle, apparently. | 14:33.30 |
| Robin_Watts | mattchz: Fair enough. | 14:33.48 |
| henrys | marcosw: will the review field in bugzilla only come on with new bugs I donât see it in existing bugs | 14:33.54 |
| | ? | 14:34.03 |
| mattchz | and if the source FSS doesnât support duplicate(), we run it via cachefss apparently, so that we can duplicate. | 14:34.13 |
| Robin_Watts | mattchz: I think you're right that it's the best way forward. | 14:34.15 |
| mattchz | Iâm trying to understand why RetainSource is bad. | 14:34.42 |
| henrys | chrisl: anything on the outline stuff - that is really the only path Iâve consider for fixing xps print performance if it isnât going to work good to know soon. | 14:34.55 |
| mattchz | is it only the case where the decoded version is smaller? | 14:35.03 |
| | cos, preumably we have to keep the estream around for all other images anyway? | 14:35.16 |
| Robin_Watts | mattchz: It may not be. It may just have been me fearing that it would have copied stuff. | 14:35.19 |
| | yes, that seems true. | 14:35.23 |
| mattchz | in which case, thereâs no harm. | 14:35.43 |
| chrisl | henrys: it isn't going to work - for the PLRM first 50 pages, the XPS file ended up bigger | 14:35.46 |
| marcosw | henrys: I hadn't added the field to the bugzilla "workflow", so there were no bug states that you could go from to the AWAITING_REVIEW state. I've fixed that and now it should show up for all bugs. I'm adding it to the reports today. | 14:36.07 |
| henrys | chrisl: ugh | 14:36.29 |
| chrisl | henrys: but I think there is a bigger issue with xpswrite, which is performance - for the tests I tried it was worse than ten times slower than pdfwrite | 14:36.54 |
| mattchz | robin_watts: ISTR some issue with some MS documents with huge source images (e.g. BMPs) | 14:37.46 |
| henrys | chrisl: depends on the input - tiger should be about the same. | 14:37.47 |
| mattchz | robin_watts: those were signfiicantly larger than subsampled 565 images. | 14:38.15 |
| chrisl | henrys: that's not really a representative job - I was looking at text heavy jobs | 14:38.20 |
| mattchz | I think thatâs probably why. | 14:38.24 |
| Robin_Watts | Ah, right. | 14:38.38 |
| mattchz | so, we may end up screwing up such documents. | 14:38.38 |
| henrys | chrisl: we know using an outline instead of a font is going to be bad no doubt | 14:38.57 |
| Robin_Watts | So... how about a new bit of logic in Image_getSource, where we effectively do 'retainSource' lazily? | 14:39.45 |
| henrys | Iâll send out the urw font order right after the meeting. I didnât get to it yesterday | 14:39.48 |
| Robin_Watts | If it's not an async image, and it's not persistent, do the same thing that retain source would have done. | 14:40.18 |
| mattchz | robin_watts: which is what you were originally suggesting, right? | 14:40.20 |
| chrisl | henrys: for the glyph outlines, I'm not sure, but the problem might be related to xpswrite not being able to handle clipping paths - that *might* force us to degenerate to rectangles even when we pass the outline through from the "front end" | 14:40.24 |
| Robin_Watts | effectively, yes. | 14:40.27 |
| mattchz | seems sane. | 14:40.41 |
| | What if itâs a persistent image? I donât know when that happens exactly, but JPEG uses it for partial decode. | 14:41.03 |
| henrys | chrisl: do you have the outline stuff working now for pdfwrite as kens was requesting | 14:41.22 |
| | ? | 14:41.25 |
| mattchz | i.e. Iâm not sure if persistent is used for all JPEGs. | 14:41.32 |
| chrisl | henrys: no, we're looking at a different approach for that entirely | 14:41.51 |
| Robin_Watts | mattchz: Dunno yet :) | 14:42.00 |
| rayjj | sorry I'm late. | 14:42.13 |
| chrisl | henrys: what we want for pdfwrite wouldn't help with xpswrite | 14:42.17 |
| henrys | chrisl: what fell apart there? I just want to understand so I donât investigate stuff youâve already looked at | 14:43.01 |
| | rayjj: np ron needs some keys from you change dns stuff. | 14:43.23 |
| chrisl | henrys: you mean with the clipping? | 14:43.44 |
| henrys | rayjj: jogux send him email to contact you. | 14:43.47 |
| jogux | henrys : rayjj: I hopefully sent Ray an email with the details :) | 14:44.03 |
| rayjj | jogux: I'll check. Just a sec | 14:44.44 |
| henrys | chrisl: no why does it not work in pdfwrite to use outlines for some type 3 fonts. Isnât that the path you were going to pursue? | 14:44.49 |
| rayjj | jogux: got it. I'll get to it shortly. | 14:45.25 |
| jogux | rayjj : excellent, thanks | 14:45.37 |
| | as soon as that's done I think the SO forums should be ready to point users at | 14:45.45 |
| henrys | rayjj: you should have administrative email from miles as well. | 14:45.54 |
| chrisl | henrys: it's paths for type 1 fonts used inside a type 3, those currently go missing. What pdfwrite needs is a way to get to the type 1 outline before it's rendered | 14:46.02 |
| rayjj | all I have to do is remember where to do this. :-/ | 14:46.19 |
| chrisl | sorry, not "go missing" but end up as rasterised | 14:46.25 |
| henrys | chrisl: to test xpswrite did you just set the cache size to 0 or something like that? | 14:47.20 |
| chrisl | henrys: yes, exactly that | 14:47.49 |
| | I can't remember if I tested the speed without the cache disabled...... | 14:48.22 |
| rayjj | henrys: I got an email from Miles last night and took care of takena-san's email message | 14:48.24 |
| henrys | Iâll look at it sometime this week and see if the clipping matters | 14:49.07 |
| chrisl | henrys: I did want to debug the clipping stuff a bit before passing it back to you, but various bits of customer sh*t hit the fan, and I didn't get back to it | 14:49.49 |
| henrys | chrisl: no problem and the directory reorg is more important | 14:50.12 |
| chrisl | I haven't got much done on that, either :-( | 14:50.29 |
| henrys | anything else for gs and mupdf? | 14:50.35 |
| mattchz | oh, weâre intending to upload 1.5 to Apple today. | 14:50.49 |
| | well, we might delay it until Crashlytics get back to us. | 14:51.03 |
| henrys | mattchz: oh cool | 14:51.30 |
| Robin_Watts | Do crashlytics work on android too, or just ios? | 14:51.42 |
| mattchz | I presume you didnât hear back from Miles yet about the contributor agreement? | 14:51.45 |
| | robin_watts: I believe thereâs an android version. | 14:51.56 |
| | I think it would be good to use it. | 14:52.01 |
| henrys | mattchz: no I talk to him today and Iâll ask | 14:52.06 |
| mattchz | (or an alternative like ACRA, although that canât easily do native backtraces, so probably not that useful) | 14:52.20 |
| | henrys: cool - thanks! | 14:52.25 |
| rayjj | I have to get some lab work done and they open in about 5 min (I'm in the parking llot). I'll check back later if there is anything else. | 14:52.25 |
| henrys | mattchz: he usually tells me when he gets one but heâs been busy | 14:52.31 |
| | should we have an SOT meeting on the hour? | 14:53.07 |
| Robin_Watts | henrys: I believe michael cadilhac has given us patches before, so I was thinking that we might have had one on file. | 14:53.23 |
| rayjj | (the lab I first went to that opened an hour ago doesn't take my insurance -- they used to, but changed) | 14:53.24 |
| | bbiab | 14:53.31 |
| henrys | Robin_Watts: ah Iâll ask miles wonât be in for another hour. I donât remember michael | 14:54.02 |
| Robin_Watts | I remember the name. | 14:54.22 |
| henrys | be back in a few minutes | 14:57.34 |
| paulgardiner | mattchz, jogux: any idea how to set android.library.reference to an absolute path? (on Windows) | 15:02.19 |
| jogux | has no idea, sorry | 15:02.40 |
| mattchz | sorry, I donât even know what it is. | 15:02.56 |
| paulgardiner | Within the project.properties of one of Good Dynamics sample apps, there is a reference to v7/appcompat. Not surprisingly, it's in a different place on my machine. | 15:04.42 |
| henrys | paulgardiner: nothing from matt I assume? | 15:05.48 |
| paulgardiner | henrys: your assumption is correct. :-) | 15:06.07 |
| | I mean :-( | 15:06.11 |
| henrys | Iâll reping | 15:06.16 |
| | looking at the SOT bug list | 15:07.54 |
| jogux | henrys : SO2 2.3 is live on the iOS store now if you didn't see. | 15:08.42 |
| henrys | jogux: yes itâs on my list to get it installed and look at it. I now have a modern wireless HP printer that I wanted to try out. | 15:09.51 |
| jogux | cool :-) | 15:10.03 |
| | we have a large number of crashes captured by crashlytics (which we added in this release). No particular reason at this stage to believe any of them are new in this version (apart from possibly 1). Definitely a few we should fix. (I plan to have a look but have my head down in the ppt styling thing just now.) | 15:10.58 |
| paulgardiner | jogux: I thought we had reason to believe that the most common one was new. | 15:11.36 |
| henrys | a bit concerned because miles is very hopeful about this release. Yet my eyeballing of the bugs doesnât show a big change. Is it time for me to have a âreality discussionâ with Miles, better to ease him into it then tell him in September. | 15:11.37 |
| jogux | paulgardiner: yeah, that's the 1 :-( | 15:11.49 |
| mattchz | TTOD: donât insert a uSD card into a SIM slot. | 15:12.18 |
| paulgardiner | May not be hard to fix, probably being in the same area as the one already fixed | 15:12.39 |
| Robin_Watts | henrys: expectation management would be good. | 15:12.41 |
| henrys | Robin_Watts: no problem | 15:13.41 |
| | anything else for SOT? mvrhel_laptop? | 15:16.23 |
| Robin_Watts | henrys: might be worth a quick word in the skype group. | 15:16.53 |
| henrys | okay give me a minute to fetch my laptop | 15:17.18 |
| mvrhel_laptop | henrys: nothing in particular from me. | 15:20.14 |
| | I will join in on skype too | 15:20.21 |
| paulgardiner | henrys: I've been back to spending most of my time on SOG, looking to help with the nasty crashing problems with the Android app. I suspect it may be possible to work around the problems without GD's help. This of course means I haven't been looking at the layout bug list. I'm happy battling this thing a little more, but please say if you'd like me to shelve SOG altogether so that I can put... | 15:22.50 |
| | ...my time into the layout bugs. | 15:22.52 |
| mattchz | Iâve been trying, unsuccessfully, to reproduce http://bugs.ghostscript.com/show_bug.cgi?id=694409 | 15:47.53 |
| | after a bit of googling, I found this: | 15:48.21 |
| | https://groups.google.com/forum/#!topic/android-developers/KYpLey2vnO0 | 15:48.29 |
| | so, I think itâs a google bug, and one we canât work around. | 15:48.35 |
| | ultimately, it links back to this: https://code.google.com/p/android/issues/detail?id=%2025386 | 15:50.47 |
| | which was opened in 2012. | 15:51.01 |
| | the only way we could probably work around this, is to do our own native code to enumerate the directory. | 15:51.24 |
| | I think we decided this was not really something we should attempt, so should we just close this bug? | 15:51.40 |
| Robin_Watts | mattchz: I think so. | 15:52.08 |
| jogux | I assume most other apps crash | 15:52.21 |
| | except SO :-) | 15:52.31 |
| mattchz | Iâd assume so. | 15:52.35 |
| | I canât actually reproduce it. | 15:52.47 |
| | especially now that Iâve jammed the SD card in the SIM slot. | 15:53.06 |
| | I guess we could implement our own native code to check the filename, and avoid calling File.list() if we find any bad strings. | 15:55.18 |
| Robin_Watts | I think we should be able to trust the underlying system. | 15:55.48 |
| mattchz | We should, but we canât, and Google arenât great at fixing android bugs :( | 15:56.07 |
| | I suspect it would kill any file manager though too. | 15:56.28 |
| | so, close it then? | 15:56.59 |
| Robin_Watts | close it as WONTFIX ? And if someone wants to give us a patch, we'll consider it. | 15:57.47 |
| mattchz | ok | 15:59.35 |
| jogux | or when a paying customer reports it ;) | 15:59.42 |
| mattchz | is it a paying customer?:) | 15:59.49 |
| jogux | I presume not | 15:59.58 |
| mattchz | Iâm tempted to close this one too, as weâve not had any feedback for a few weeks (with please reopen if it still occurs) | 16:06.27 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=693607 | 16:06.28 |
| jogux | seems reasonable. was that one of the fixes that made it into the android 1.5? | 16:10.11 |
| mattchz | no. | 16:10.23 |
| | oh, that was the one I posted earlier. | 16:10.43 |
| | We *could* try and get hold of sony xperia x10 | 16:10.52 |
| Robin_Watts | yes, feel free to close bugs like that with "closing due to lack of response from original poster. Please reopen if bug still occurs." | 16:11.17 |
| mattchz | we did actually get some response from the poster, just not for a while. | 16:11.48 |
| | well, from a different user, actually, who reported a duplciate I think. | 16:12.10 |
| jogux | I presume it might be worth pushing out a 1.5.1 for android if there were a few fixes since? | 16:12.24 |
| mattchz | could do, yeah. At least we could then close this one, and say âtry 1.5.1' | 16:12.47 |
| | I had an idea about http://bugs.ghostscript.com/show_bug.cgi?id=693224, although I think we decided to just close it as it only affected 2.3 | 16:13.43 |
| | this is the bug list as it stands: | 16:14.18 |
| | http://bugs.ghostscript.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cpriority&list_id=15805&op_sys=iOS%204&op_sys=iOS%205&op_sys=iOS%206&op_sys=iOS%207&op_sys=Android&product=MuPDF&query_format=advanced | 16:14.19 |
| jogux | I guess record your idea, but close it as a wontfix due to it being fine on newer versions | 16:14.52 |
| mattchz | fair enough. | 16:15.14 |
| jogux | looks like you're basically done with the bugs then? | 16:16.24 |
| mattchz | yeah | 16:16.35 |
| Robin_Watts | how do we feel about: http://bugs.ghostscript.com/show_bug.cgi?id=693464 | 16:18.10 |
| | I hate the patch... | 16:19.56 |
| mattchz | ok, Iâve closed #693224 | 16:20.57 |
| | Robin_Watts: we have code to read from a stream anyway, which I think you wrote? | 16:21.18 |
| | so itâs perhaps no longer needed? | 16:21.37 |
| Robin_Watts | possibly. I'd be tempted to close that too I think. | 16:22.01 |
| jogux | it would certainly be nice for library users to be able to display documents without them needing to be saved to disk | 16:22.37 |
| Robin_Watts | jogux: I believe they can, using the Intent stuff, right? | 16:22.56 |
| | email attachments get opened like that. | 16:23.06 |
| jogux | would that end up broadcasting it to other apps on the device? | 16:23.30 |
| | I got the feeling this was someone embedding the library into their app | 16:24.01 |
| mattchz | We use âopenBufferâ in MuPDFActivity.java which I think Robin wrote to do exactly what they are asking. | 16:24.12 |
| Robin_Watts | Then, no, they can call openBuffer, as Matt says. | 16:24.25 |
| mattchz | We use it when receiving Intents with content:// URLs, exactly as you describe. | 16:24.38 |
| jogux | right. so close the bug with "thanks, we've implemented functionality to do this now, see <x> and <y>" :-) | 16:24.48 |
| mattchz | the data is passed by IPC by Android | 16:24.51 |
| | cool | 16:24.54 |
| jogux | and the usual if this doesn't work for you let us know blahblah :) | 16:25.35 |
| mattchz | yeah thatâs what Iâm doing :) | 16:25.41 |
| | that patch was from 2012 :) | 16:26.53 |
| | is this something we want to do: http://bugs.ghostscript.com/show_bug.cgi?id=695326 | 16:27.13 |
| | or should I just close it as WONTFIX? | 16:27.19 |
| Robin_Watts | Possibly we should, yes. | 16:27.50 |
| | It's just a question of me/whoever uploading them to our own site as well as google play. | 16:28.13 |
| mattchz | `tnod. | 16:28.21 |
| | gah. nod. | 16:28.24 |
| jogux | may be worth dropping them on amazon store if that's trivial too. dunno. | 16:28.33 |
| mvrhel_laptop | bbiab | 16:28.35 |
| mattchz | I think Iâll look at the crashlytics integration on a private branch for now, then we can decide what to do when we hear back from them. | 16:30.54 |
| Robin_Watts | what are we hoping to hear from them about ? | 16:31.57 |
| mattchz | whether we can distribute their SDK via our git repository. | 16:32.21 |
| | which potentially might mean it might get linked with AGPL code ... | 16:32.42 |
| Robin_Watts | mattchz: Can we not use a git submodule ? | 16:32.52 |
| mattchz | possibly. I donât know how they work. | 16:33.07 |
| Robin_Watts | We have a thirdparty dir. | 16:33.16 |
| mattchz | Iâm not sure if their terms allow us to even redistribute the lib at all. | 16:33.40 |
| jogux | mattchz : I think if we were to put crashlytics in we'd want to add a AGPL exception - ie. your app must be open source, apart from you're allowed to use crashlytics. | 16:33.42 |
| Robin_Watts | In there there are various git submodules - essentially these are just other .git repos. | 16:33.52 |
| mattchz | crashlytics SDK used to be private/confidential. Iâm not sure it is any more though. | 16:34.15 |
| jogux | robin_watts : would git submodules barf in odd ways at a non-public sub module? | 16:34.39 |
| mattchz | btw, please could someone add me to the Artifex account? | 16:34.39 |
| Robin_Watts | jogux: No, we'd just say "use of crashlytics is incompatible with the AGPL". It is there for commercial customers (or free users that don't distribute) only. | 16:34.40 |
| | jogux: It means updates of that submodule would fail. | 16:35.02 |
| jogux | in a way that doesn't result in users asking us questions? :-) | 16:35.17 |
| Robin_Watts | Clearly, it would be nicer if they say yes :) | 16:35.33 |
| mattchz | yeah; thatâs what I thought. Would save a lot of hassle if there was no private repo to have to use. | 16:35.59 |
| Robin_Watts | Can we make the code use thirdparty/crashlytics if it's there, but otherwise not? | 16:36.10 |
| jogux | it's a bit of an arse to do that in xcode unfortunately | 16:36.25 |
| mattchz | not sure. I was going to look into that. | 16:36.27 |
| | we might be able to add it as a dependency of only a specific target | 16:36.39 |
| jogux | mattchz : you should have an email | 16:36.46 |
| mattchz | but it might still barf | 16:36.47 |
| | jogux: got it, ta. | 16:37.54 |
| rayjj | jogux: I've added the CNAME record and it seems to work | 17:50.29 |
| | jogux: email sent to staff and to you and Ron | 17:50.45 |
| Robin_Watts | rayjj: Got it, thanks. | 17:52.53 |
| rayjj | Robin_Watts: great. I assume it works for you now as well ? | 17:54.21 |
| Robin_Watts | http://smartoffice-forum.artifex.com/ ? | 17:55.04 |
| | I get "pageok" | 17:55.09 |
| rayjj | Robin_Watts: for me it re-directs to http://smartoffice.discoursehosting.net | 17:56.11 |
| henrys | a little creepy gmail reads the word âattachmentâ in your message and tells you forgotten it upon hitting send. | 17:56.29 |
| Robin_Watts | henrys: so does thunderbird. | 17:56.43 |
| rayjj | but it may not have propagated yet. It warned that it would take up to 24 hrs | 17:56.55 |
| Robin_Watts | If you think that's all google is reading of your mail... | 17:57.00 |
| henrys | Robin_Watts: but thatâs on your machine. | 17:57.10 |
| rayjj | henrys: tbird also triggers on zip and pdf | 17:57.15 |
| | henrys: was the administrative issue Miles had for me the one I took care of last night? I haven't seen anything from him today | 18:01.18 |
| henrys | rayjj: yes | 18:01.40 |
| rayjj | henrys: thanks | 18:01.45 |
| henrys | he doesnât have a casper account does he? | 18:01.53 |
| rayjj | I'll hcekc... | 18:02.03 |
| | henrys: nope | 18:02.30 |
| henrys | yup I donât see one | 18:02.42 |
| Robin_Watts | rayjj: ugh. A redirect is nasty. | 18:23.44 |
| rayjj | Robin_Watts: let just try using an A record to see if that will work. | 18:25.53 |
| | hmm... smartoffice.discoursehosting.net dig comes back with: | 18:28.29 |
| | ;; ANSWER SECTION: | 18:28.31 |
| | smartoffice.discoursehosting.net. 300 IN A 192.241.177.167 | 18:28.32 |
| | but 192.*.*.* are unrouteable addresses, iirc | 18:28.50 |
| | we may need a smartoffice-forums.artifex.com host to use HTML to the "this page should automatically redirect... if it doesn't, click the link below" | 18:33.12 |
| | maybe the discoursehosting folks don't want people accessing via a different name, and have funky subdomain IP addresses intentionally ? | 18:35.06 |
| | have to run an errand. bbiab | 18:37.04 |
| Robin_Watts | rayjj: For the logs... 192.168.x.x are private. | 19:00.19 |
| | 192.Y.x.x for Y != 168 are fine, I think. | 19:00.34 |
| | 10.x.x.x offers 24bits of private space. | 19:01.15 |
| | 172.16.0.0 offers 20 bits of private space | 19:01.28 |
| | 192.168.0.0 offers 16 bits of private space. | 19:01.36 |
| | everything else is OK. | 19:01.52 |
| marcosw_ | Anyone else watching the world cup? | 20:27.23 |
| mvrhel_laptop | Robin_Watts: ping | 21:00.46 |
| jogux | our foster kitten finally gave birth! you should, just, be able to spot 4 kittens in here: https://scontent-a-lhr.xx.fbcdn.net/hphotos-xfp1/t1.0-9/10550922_4361955623371_3703433060356711520_n.jpg :) | 21:39.38 |
| henrys | jogux: :-) | 21:45.40 |
| | brazil is not having a good day | 21:46.30 |
| jogux | thatâs putting it mildly :-) | 21:51.32 |
| mvrhel_laptop | I can only make out two kittens | 22:00.25 |
| jogux | mvrhel: yes, itâs tricky. thereâs two in the blob just under her chin and even I canât work out where the 4th is. Itâs nigh on impossible to get all 5 cats visible in a single photo :-) | 22:18.42 |
| | the dns for http://smartoffice-forum.artifex.com/ doesnât seem to have propogated for me yet (itâs still resolving using what I presume is a wildcard). will check again in the morning | 22:29.54 |
| | rayjj: thanks for sorting that out! | 22:30.00 |
| rayjj | jogux: I'm not sure that it's sorted out yet. I'll wait until tomorrow and then see if it works any better, and if not, I'll dig into it | 22:41.48 |
| jogux | ah, okay. :) | 22:42.20 |
| rayjj | jogux: the email from Ron doesn't make sense to me -- setting an A record to point to a non-routeable IP (192.241.177.167) doesn't seem like it will help. | 22:43.45 |
| jogux | I think Robin mentioned itâs only 192.168.x.x thatâs not routable. certainly there is a http://192.241.177.167/ gets me to a http server. | 22:44.57 |
| rayjj | jogux: I guess Robin_Watts is right 192.168 is a non-routable class C range | 22:46.10 |
| | jogux: If that is the case, I'll go ahead and add the A record | 22:47.17 |
| jogux | ok, thanks | 22:49.14 |
| rayjj | jogux: I've added the A record so if you want to try it (after clearing your browser cache) and let me know, I'd appreciate it, but for me it still just gives me "pageok" | 22:53.13 |
| jogux | rayjj: directly querying the dns server, Iâm getting the old result still | 22:54.04 |
| | itâs smartoffice-forum.artifex.com, right? | 22:54.25 |
| rayjj | jogux: the networksolutions server ? | 22:54.37 |
| jogux | ns43.worldnic.com | 22:54.50 |
| | it just changed! | 22:54.54 |
| rayjj | jogux: is it correct now ? 192.241.177.167 ? | 22:55.09 |
| jogux | ah. I get different answers, I guess that ip is actually multiple servers. | 22:55.32 |
| | thatâs correct, yeah | 22:55.37 |
| | just needs time to propogate across all their servers, then out into the world :) | 22:55.47 |
| rayjj | jogux: I wonder about the A record -- whether that will make it not work. Sometimes the host servicing multiple virtual hosts/domains needs the access via CNAME (not A) | 22:57.19 |
| jogux | their docs said both would work, but they recommended the cname (iirc) | 22:57.42 |
| rayjj | jogux: but it's been a long time since I delved into this junk | 22:57.45 |
| | jogux: now we have both CNAME and A (and I have no idea which has priority) | 22:58.10 |
| jogux | errr. okay. I did not know that was possible. | 22:58.26 |
| | I only see the A record so far querying their server :-) | 22:58.45 |
| rayjj | the CNAME goes to smartoffice.discoursehosting.net and the A goes to the IP address | 22:58.49 |
| | jogux: 'dig' from casper gives me: | 23:00.54 |
| | ;; ANSWER SECTION: | 23:00.56 |
| | smartoffice-forum.artifex.com. 7200 IN A 188.121.46.128 | 23:00.57 |
| jogux | I can never remember how to use dig. but âhost smartoffice-forum.artifex.com ns43.worldnic.comâ gives me the new/correct answer about 50% of the time :) | 23:01.43 |
| rayjj | which is NOT right. From casper, "host smartoffice-forum.artifex.com" gives me: smartoffice-forum.artifex.com has address 188.121.46.128 | 23:03.21 |
| | jogux: new/correct == 197.241.177.167 ??? | 23:04.01 |
| jogux | $ host smartoffice-forum.artifex.com ns43.worldnic.com | 23:04.21 |
| | Using domain server: | 23:04.21 |
| | Name: ns43.worldnic.com | 23:04.23 |
| | Address: 207.204.40.122#53 | 23:04.24 |
| | Aliases: | 23:04.25 |
| | smartoffice-forum.artifex.com has address 192.241.177.167 | 23:04.26 |
| rayjj | jogux: I guess we just have to be patient (not one of my virtues, yet) and see how it sorts out tomorrow | 23:07.48 |
| jogux | sounds right to me | 23:08.04 |
| | Forward 1 day (to 2014/07/09)>>> | |
IRC Logs
