Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dchandekstark joins04:48
* dchandekstark leaves04:52
* jrgriffiniii leaves06:25
* jrgriffiniii joins06:47
* dchandekstark joins06:49
* dchandekstark leaves06:54
* github-ff joins07:45
[fcrepo-java-client] acoburn tagged fcrepo-java-client-0.2.0 at b03b328: https://git.io/vKKho
fcrepo-java-client/fcrepo-java-client-0.2.0 2b68da9 Aaron Coburn: [maven-release-plugin] prepare release fcrepo-java-client-0.2.0
* github-ff leaves
* travis-ci joins07:48
fcrepo4-exts/fcrepo-java-client#43 (fcrepo-java-client-0.2.0 - 2b68da9 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-java-client/commit/2b68da917e3c
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-java-client/builds/146082768
* travis-ci leaves
* github-ff joins07:58
[fcrepo-java-client] acoburn pushed 1 new commit to gh-pages: https://git.io/vKKj9
fcrepo-java-client/gh-pages e88b2af Aaron Coburn: Creating site for fcrepo-java-client, 0.2.0
* github-ff leaves
* dwilcox joins08:01
* github-ff joins08:09
[fcrepo4] acoburn opened pull request #1069: update docs with new version of fcrepo-java-client (gh-pages...update_docs) https://git.io/vK6vt
* github-ff leaves
* github-ff joins08:16
[fcrepo-java-client] acoburn pushed 2 new commits to master: https://git.io/vK6vd
fcrepo-java-client/master 2b68da9 Aaron Coburn: [maven-release-plugin] prepare release fcrepo-java-client-0.2.0
fcrepo-java-client/master 03c561e Aaron Coburn: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
* travis-ci joins08:19
fcrepo4-exts/fcrepo-java-client#44 (master - 03c561e : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-java-client/compare/093653a30679...03c561e29605
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-java-client/builds/146088993
* travis-ci leaves
* dwilcox leaves08:31
* dwilcox joins08:33
* acoburn joins08:50
* dchandekstark joins08:51
* dchandekstark leaves08:55
* whikloj joins09:11
* acoburn leaves
* dchandekstark joins09:21
* awoods joins
* ajs6f joins09:22
* mikeAtUVa joins09:27
* acoburn joins09:28
awoods: question about https://jira.duraspace.org/browse/FCREPO-208109:29
awoods: I have refactored the javascript to use only native methods (no jQuery) with the exception of some Bootstrap-based animations09:30
awoods: i.e. the modal and the animated open/close of certain panes
awoods: I don't think I can extract all of that before the code freeze, so....09:31
awoods: would you like a PR now that does 95% of that ticket or should I wait until later?
<awoods>acoburn: Waiting for completion makes sense.09:32
acoburn: the next release cycle will also give us more time to work out the potential kinks.
<acoburn>awoods: makes sense to me
awoods: how important are those animations to you?09:33
awoods: I'd be happy to remove them
<awoods>acoburn: I think the animations present a clean view.09:34
<acoburn>awoods: also, did you know that the /fcr:assets endpoint doesn't respect browser caches (ETags)?
awoods: they are loaded with _every_ request
<awoods>acoburn: I did not know that... I did however know that /fcr:assets has been "problematic"09:35
<acoburn>awoods: nor are the assets compressed
<awoods>acoburn: sounds like some tickets
<acoburn>awoods: it seems to me like a part of the REST API that doesn't exactly fit into the spec
awoods: ajs6f: certainly, the spec is silent about /fcr:assets09:36
<awoods>acoburn: not at all. /fcr:assets is designed for self-consumption. There are probably better ways.
<acoburn>awoods: i.e. as a static resource in fcrepo-webapp?09:37
<ajs6f>acoburn:awoods: Can we not just mount something parallel to /rest?
acoburn:awoods: /assets and /rest?
<acoburn>awoods: moving them into fcrepo-webapp would be the simplest
<awoods>acoburn: we have tried a number of solutions...
<ajs6f>awoods:acoburn: Do ITs in fcrepo-http-api depend on them?09:38
<acoburn>ajs6f: I don't know about that — I don't think we do much in the way of JS testing
awoods: one problem with putting them in fcrepo-webapp is that they need to be loaded by the template in fcrepo-http-api09:39
awoods: which argues for keeping them where they are
<ajs6f>acoburn:awoods: It is long past time for us to swap out that homegrown template thing for something off-the-shelf.
<acoburn>awoods: however, that's exactly what we're doing with jQuery and bootstrap
i.e. serving them from fcrepo-webapp but referencing them in fcrepo-http-api09:40
ajs6f: IMO the _entire_ HTML rendering would be pulled out into a separate module09:41
ajs6f: at least, removed from fcrepo-http-api
<awoods>acoburn: that makes sense
<ajs6f>acoburna:awoods: There's also this: https://jira.duraspace.org/browse/FCREPO-1594
<awoods>ajs6f: agreed, I would like to see HTML remain in the core, but an isolated module makes sense.09:42
<acoburn>ajs6f: honestly, the HTML templates could _really_ be cleaned up, and it would be a good opportunity to switch to LDPath-based templates
awoods: core, yes, but not fcrepo-http-api
<acoburn>awoods: something that fcrepo-webapp loads is what I'm thinking
<awoods>ajs6f: I am not opposed to LDPath... but also do not quite understand the argument that Velocity templating is homegrown.09:44
<acoburn>awoods: we manage a lot of code that maps the RDF to the Velocity templates — that's what I think ajs6f is referring to09:46
awoods: with LDPath, all of that code goes away
<ajs6f>awoods: what acoburn says ^^^09:47
awoods:acoburn: Not just the mapping from resources to templates, but the complicated and unique-to-Fedora macinery that operates inside a template to provide access to properties of the resource (triples in the resource graph).09:48
<acoburn>awoods: for example: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/resources/views/common.vsl09:49
awoods: and all of this: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/responses/ViewHelpers.java09:50
* peichman joins
* jrgriffiniii leaves09:54
<ajs6f>awoods: Code freeze tomorrow, so can you get this all done by COB today? Replacing the template machinery and factoring it out into a new module?09:57
* thomz leaves
<awoods>ajs6f: no
<ajs6f>awoods: :(
<awoods>ajs6f: but maybe you can
<ajs6f>awoods: I'm release manager. I have far more important things to do.09:58
<awoods>ajs6f: I completely understand
* tolloid joins10:03
<ajs6f>awoods: Paging, far from being trivial, is actually really hard. Or we would have done it already.10:30
<awoods>ajs6f: the order certainly adds complexity10:31
on a call
<ajs6f>awoods: The _lack_ of order.
<dchandekstark>ajs6f acoburn - Is the streaming of GET on RDF sources new post-4.5.1?10:36
<ajs6f>dchandekstark: No, it's almost as old as the codebase itself.
<acoburn>dchandekstark: it's always been there
<dchandekstark>curl -u $FCREPO_USER:$FCREPO_PASSWORD -H "Range: bytes=0-99" $FCREPO_URL10:37
like that?
<acoburn>no, sans Range header
<ajs6f>dchandekstark: No, that's the use of the Range header, which is not the same thing as streaming.
<dchandekstark>ok, well the problem is i have to wait 20 minutes for a response10:38
<ajs6f>dchandekstark: streaming means that the bits that make up the response are not held in some structure in memory before transmission, but calculated as they are needed and transmitted.
dchandekstark: Are you using a released version?10:39
<dchandekstark>ajs6f: 4.5.1
<ajs6f>dchandekstark: Then wait for 4.6.0, which will include https://github.com/fcrepo4/fcrepo4/commit/bf8860d9038f7d6a1500b163f0e78a5333aa1bdc aka FCREPO-1880. That should solve most of your problem.10:40
dchandekstark: The delay is because Fedora is calculating the number of children, so as to be able to give you that fact as part of the response. 1880 changed that behavior to obviate that very delay.
<dchandekstark>ajs6f: ok, that makes sense10:41
<acoburn>ajs6f: I know that I'm looking forward to that change :-)
<ajs6f>dchandekstark: The cost, of course, is that the number of children, if you want to know it, is now something you will have to keep track of client side. But that's a fairly easy thing to do, we hope.10:42
<dchandekstark>acoburn ajs6f - fwiw i'm not arguing that you shouldn't have to use a triple store and camel, etc. but that folks should be well advised to do so10:44
<ajs6f>dchandekstark: and I think you are dead right.
<dchandekstark>my impression had been that these components were more or less optional
it seems like in practice they're not
<ajs6f>dchandekstark: Part of the long saga of Fedora 4 has been the commmunity having a difficult discussion with itself about what the repository does and doesn't do.
dchandekstark: And what kind of integrations are possible, likely, and effectively necessary.10:45
<dchandekstark>ajs6f: or to put it in practical terms, what does it mean to "run a fedora repository"
or fedora-based10:46
<ajs6f>dchandekstark: One of the principles to which the tech team has been working for several years now is that we want a small, tight, fast, efficient synchronous core, with a field of functionality around it in an asynchronous fabric.
<dchandekstark>since in the end i depend on a set of services, whether provided by the fedora software itself or an auxiliary system10:47
<ajs6f>dchandekstark: Yes, that's a very good way to put it. "Fedora" vs. "Fedora-based". We are moving a good deal of functionality from the former to the latter. The benefits: the repository core itself can scale and perform much better, unweighted by those additional functions.
dchandekstark: You depend on those things, but 1) Not everyone depends on the same set of "outside-the-core" functions, and 2) the core tech team is tasked with making the core a priority. This is how we've found it useful to organize, not your repository, but our work.10:48
<dchandekstark>ajs6f: which is fine, but i think we dove into FCR4 a bit naively, assuming we could add on other components later as the need became clear10:49
<ajs6f>dchandekstark: Your point about making clear what you can and cannot do with just a naked repository tells me that we haven't done a good job of making that distinction visible.
dchandekstark: Is that exactly what you are doing?
<dchandekstark>it seems that "later" is now
<dchandekstark>ajs6f: yeah, i guess it is
<ajs6f>dchandekstark: If it's any consolation, you are pioneers. You guys went very far very quickly.10:50
<dchandekstark>ajs6f: it goes back to the spec question i suppose - what fedora does and does not promise
<ajs6f>dchandekstark: Much of what you are doing will ensure that other folks won't have the same difficulties.
<dchandekstark>ajs6f: i hope so :)
don't use MariaDB 5.5 :)
<ajs6f>dchandekstark: Not quite. The spec is about promises between machines. The kinds of promises you are talking about are made between the community and users.10:51
<dchandekstark>ajs6f: i get what you're saying but the distinction has blurry edges
<ajs6f>dchandekstark: What can you do with Fedora? That depends on what 'Fedora" is and who "you" are (and I'm not playing with words here). If Fedora is the core repository services in abstract, that's one thing. If it's a given integration, in situ, with accompanying service, at a real site, that's something else. If you is a machine in the network, that's one thing. If you is Jim Tuttle of David Chandek-Stark, that's something else.10:52
dchandekstark: Yes, it is blurry, and we clearly haven't done a good job with communicating it.10:53
dchandekstark: Thank goodness for early adopters who help us discover these things and fix them!
<dchandekstark>ajs6f: what i'm saying is that i expect in most people's minds, fedora is not an abstraction, it's a system
<ajs6f>dchandekstark: Yes, I get that. What I'm saying is that a lot of the problems with scaling and integration people have had over the years is precisely because we haven't made that distinctin.10:54
<dchandekstark>ajs6f: fair enough
ajs6f: fwiw, i think Hydra has a similar problem10:55
is it an application? a framework? an idea?
<ajs6f>dchandekstark: I'm not saying we should never treat Fedora as a system. I'm saying we should understand when we are doing that and when we are treating it as an abstraction (and when we are treating it as a praxis or a set of ideas about how to model netwokred information so that it becomes durable, which it also is).
dchandekstark: Yes, I don't really understand what Hydra is, either. I think it has something to do with Rails, tho.10:56
<dchandekstark>and it's also a floor wax!
ajs6f: a concern - which very well could be ill-informed - is that fedora defines itself so narrowly that it becomes less clear why one would need or want it10:58
<ajs6f>dchandekstark: I think that's a reasonable concern, but I think it comes again from conflation. If all one hears abot is Fedora-the-abstraction, it could appear as you say. It's when Fedora-the-system becomes visible that you can say, "Ah, yes, I see how I can use that on behalf of the people I serve."11:00
dchandekstark: It's on the folks creating and advancing Fedora then (like you and I) to make sure people hear about both. Both the carefully-thought-through abstraction that supports performance and longevity, and the rich ecosystem that provides powerful services to use for your end-users.11:01
<dchandekstark>ajs6f: well, we've certainly learned a lot in the last few weeks :)11:02
ajs6f: i'm ok with taking a few lumps for the team11:03
<ajs6f>dchandekstark: Almost every time I present on Fedora I make (as strongly as I can) the point that Fedora started out with ideas, and it has always been about ideas, and we will know when it is over because we will have run out of ideas. But we haven't yet. For example, there are quite a few ideas about Linked Data and how you use it in institutions of memory that we have yet to work out.
dchandekstark: The practical consequence is that you know when you are making progress because your brain feels full-to-sloshing.11:04
dchandekstark: Lumps entitle you to beer from Fedora committers if you can find one at a conference.
<dchandekstark>ajs6f: yeah, although from our perspective, the linked data stuff - in something more than internal impl detail - is an indefinite number of cycles out11:05
<ajs6f>dchandekstark: See— so much to look forward to!
<dchandekstark>mainly we just thought it was time to move off the legacy system (FCR3) and get on the new train with the cool kids11:06
<ajs6f>dchandekstark: I rely on barmintor to be the cool kid.
<dchandekstark>he's pretty cool
<ajs6f>He wears hats I could never get away with.11:07
Sometimes, arguing for Fedora, I feel like this: http://www.nbc.com/saturday-night-live/video/irwin-mainway/n864111:08
<dchandekstark>"Barbie takes a knife once in a while" ?11:11
<ajs6f>I really want to do a conference presentation under the name "Johnny Switchblade Adventure Punk".11:12
ruebot: Will Danny "Woolly" Lamb be on the CLAW call today? Or will that only start after he officially starts?11:43
* tolloid leaves
<ruebot>ajs6f: he'll be back on august 1. he's been on pat-leave since march or so.
* tolloid joins11:44
<ajs6f>ruebot: Oh, right, I forgot about that aspect of it. Okay, cool.
ruebot: Lucky Canucks, with your actual paternity leave.11:45
<ruebot>ajs6f: https://pbs.twimg.com/profile_images/745312868325793792/8nV43NPH.jpg11:52
<ajs6f>ruebot: That bird has the intense stare of a very drunken man trying to figure out how to use keys.11:54
<ruebot>ajs6f: it's from one of my bots :-)11:55
ajs6f: https://twitter.com/dpl_eh or https://twitter.com/dplafy11:56
ajs6f: ...or if you like dogs; https://twitter.com/yudldog11:57
<ajs6f>ruebot: Is Twitter basically robots sending pictures of animals to each other? Isn't that kind of cruel to the robots? Like we're taunting them with what they can never know?11:59
all: Random reminder— code freeze for 4.6.0 tomorrow close of business. If you have any dead to bring out, bring 'em out today.12:01
<ajs6f>awoods: I want to start tinkering with the 4.6.0 release notes, but I don't want them visible (to avoid confusion). Do you know how to make a page do that? Some kind of permissions that mean "visible only to me"?12:14
ruebot:escowles: are either of you guys interested in reporting out a paragraph of what the performance/scaling group has been up to since the release of 4.5.1 for the release notes for 4.6.0?12:18
<ruebot>ajs6f: yeah, i think escowles and i can do that.12:20
* dchandekstark leaves12:34
<acoburn>awoods: I finished fcrepo-2081. I'll leave it up to you and ajs6f as to whether it goes in this release or not.12:36
awoods: there was some pretty awful javascript in there
* dchandekstark joins
* dchandekstark leaves12:38
<ajs6f>acoburn: I am not clueful enough about JS to do a good job reviewing this. Do you know someone who is?
<acoburn>ruebot: how are your javascript skills?
whikloj: ^^^
<whikloj>acoburn: like everything, not great but not horrible.12:39
<ajs6f>Fedora 4: Not great, but not horrible.
<whikloj>acoburn: what do you need?
<acoburn>whikloj: there is a PR on its way that completely rewrites all of the javascript for the HTML UI12:40
<whikloj>acoburn++ # nice
<acoburn>whikoj: it replaces all the jQuery stuff with native methods and ES6 constructs that are widely supported12:41
<whikloj>acoburn: did you perhaps also resolve https://jira.duraspace.org/browse/FCREPO-198212:42
* github-ff joins
[fcrepo4] acoburn opened pull request #1070: Remove jQuery dependencies on the javascript code in fcrepo-http-api (master...fcrepo-2081) https://git.io/vK6yx
* github-ff leaves
<ruebot>acoburn: they were probably sub-par in 2001/2 when i dropped out of compsci :-)
<acoburn>whikloj: ahh, yes, it does resolve that
<acoburn>whikloj: I see your name was assigned to that12:43
<whikloj>acoburn: yeah, I created that while fixing https://jira.duraspace.org/browse/FCREPO-1981
acoburn: but I never got back to it, so I'm glad you did12:44
<ajs6f>whikloj:ruebot: The question is, can one of you review acoburn's PR before COB tomorrow, so we can get it in?
<acoburn>whikloj: I put your name down as the reviewer12:45
<ruebot>ajs6f, acoburn, whikloj: i'm happy to pull it down and test.
<whikloj>ajs6f/acoburn: I can do it this afternoon
<ajs6f>whikloj++ ruebot++
<ruebot>ajs6f, acoburn, whikloj: i could do that tomorrow afternoon, or super early in the morning. i'm in meetings the rest of the afternoon in 15 minutes :-(
<whikloj>we'll get it done, knowing acoburn I imagine there won't be any issues12:46
<ajs6f>ruebot:whikloj: I leave it to Canada.12:47
<ruebot>ajs6f: we stand on guard for thee.12:48
<ruebot>whikloj: I LOVE THAT EPISODE.12:50
<awoods>acoburn/ajs6f: sorry, I have a string of calls today... two more hours worth.12:51
* dchandekstark joins12:58
* dwilcox leaves13:14
<acoburn>whikloj: jQuery is supposed to make javascript code shorter: it's the "write less, do more" library13:17
whikloj: by _removing_ it, I made the javascript code 25% shorter
<whikloj>acoburn: it was, now it is falling into the realm of code religions13:18
<acoburn>whikloj: my big issue with jQuery is that it wasn't doing anything for us that we couldn't do with native functions13:19
<whikloj>acoburn: yes, exactly13:20
* dwilcox joins13:21
<acoburn>whikloj: plus, in order for the JS code in fcrepo-http-api to _run_ it needed jquery, which is available in fcrepo-webapp, which is not the way dependencies are supposed to work
* mikeAtUVa tends to find safety in using javascript libraries because he doesn't want to test against Internet Explorer and assumes those libraries are more cross-browser compatible...
<acoburn>mikeAtUVA: well, if you want to support IE8, yes…13:22
<whikloj>mikeAtUVa++ # I just assume IE always works
<ajs6f>Does anyone who has a copy of IE available want to test acoburn's PR?13:28
* martin__ joins13:29
<ajs6f>I feel like this: if we are confident that no-library JS is clearer and easier to maintain, we should go there and just react to any browser-specific problems that arise. Those are generally not urgent problems.13:39
* osmandin joins13:40
<acoburn>ajs6f: I have to spend some quality time with Windows this afternoon. I can test IE while I'm at it13:41
<ajs6f>acoburn++ # taking a bullet for the team13:42
* dchandekstark leaves13:47
* dchandekstark joins13:50
* dwilcox leaves14:00
* dwilcox joins14:22
* dchandekstark leaves14:38
* dchandekstark joins14:42
* dchandekstark leaves
<whikloj>acoburn: did you get to test with IE?14:48
<acoburn>whikloj: no, but I can do that in just a few minutes14:49
<whikloj>acoburn: I have found one issue, but I'm not sure if it wasn't there before14:50
<acoburn>whikloj: do tell
whikloj: I also pushed a whole bunch of subsequent commits, so be sure you have the latest version14:51
<whikloj>acoburn: when I create a child container or binary with a pairtree name. Then version the parent, then view that version. The ldp:contains and children show just the first pairtree node
acoburn: yes I seem to be up-to-date
acoburn: so for example14:52
http://localhost:8080/rest/3b/fb/e8/2f/3bfbe82f-77c1-410f-9a45-038531902adb has child
but in the version
<acoburn>whikloj: I'm not sure how changing the JS would affect that
whikloj: seems that is an issue with the representation of the resource
<whikloj>acoburn: yeah, I may have to try this on master and see if it isn't a different bug
acoburn: building master now14:53
acoburn: the only other thing is there are some place where it appears that "let" might be more correct than "var", but I've seen mention that IE doesn't handle let in for loops correctly.14:55
So if you say IE works for you, I'll merge this
once I've confirmed this versioning thing is some other bug14:56
<acoburn>whikloj: I'll look into the use of `let` — I was mostly concerned with using `const` wherever possible
<whikloj>acoburn: yeah, I was looking specifically at your last commit. The `for (var i =....`14:57
<acoburn>whikloj: that was because the integration tests think the first construction was a syntax error — even though it is correct and works correctly14:58
<whikloj>acoburn: so that is purely for the ITs, okay. nevermind14:59
<acoburn>whikloj: yeah, it's just for that
<whikloj>acoburn: you have me rethinking all my uses of jQuery now15:00
<ajs6f>So we have ITs that are checking JS syntax?
<acoburn>whikloj: wait until you start using the fat arrow operators…15:01
ajs6f: yes in fcrepo-webapp (that was news to me)
<whikloj>acoburn: I was looking at that, that is amazing
<ajs6f>acoburn: Yeah, that seems a bit questionable. I mean, I get wanting checks on that sort of thing, but ITs? That's not the right tool. We should be using a tool like Checkstyles.15:02
Is there a Checkstyles for JS?
<whikloj>no idea15:03
<acoburn>ajs6f: I have no idea, I just tried to be consistent in my style
<whikloj>acoburn: yeah the version child pairtree is appearing in master. Not your work at all
<acoburn>whikloj: thanks for checking15:04
<ajs6f>acoburn:whikloj: Okay, I'll open a ticket for the future, but I can't see why this should stop us from getting this in for
<whikloj>ajs6f/acoburn: yeah, this is fine the way it is. I've run around with it using Chrome and Firefox and it seems to function the same as before.15:08
<ajs6f>whikloj++ # want to merge?
<acoburn>ajs6f: I need to test with IE first15:09
give me ~10 minutes
<whikloj>ajs6f: I was going to let acoburn do a run through on IE first, then I'll press the button
acoburn: I can merge it tomorrow too, if you need more time.
<acoburn>whikloj: no, I've got the windows VM in front of me now, I'd much rather do this right now15:10
<ajs6f>acoburn:whikloj: Sorry— I thought the IE thing was done. Don't mind me.
<acoburn>whikloj: so IE 11 doesn't work with this…15:22
whikloj: but it also doesn't work with the existing code
<whikloj>acoburn: hahaha
acoburn: so IE users are not losing anything with this change15:23
<acoburn>whikloj: so it seems
<whikloj>acoburn: then I think we can merge it and worry about IE, when someone actually uses it.15:24
ajs6f/awoods/mikeAtUVa: ^^ thoughts?
<acoburn>whikloj: it's just the part about uploading files that doesn't work
whikloj: everything else seems to check out
<whikloj>acoburn: the FileReader stuff?15:25
<ajs6f>Is IE11 something that people use, or is it really old?
<whikloj>ajs6f: its new
ajs6f: question is how many repository admins use it15:26
ajs6f: based on the fact that no one has mentioned the problems of the existing HTML UI, I'm guessing not many
<acoburn>whikloj: Object doesn't support property or method 'readAsBinaryString'
<whikloj>acoburn: weird, https://msdn.microsoft.com/en-us/library/hh772310(v=vs.85).aspx15:27
<ajs6f>I'm fine with moving ahead and simultaneously filing a ticket to say "Make the thing that didn't work before and doesn't work now work sometime in the future."
Actually, that's pretty much every ticket we have in Jira.
<acoburn>whikloj: I should verify that I have the latest version of IE 11, too15:28
whikloj: it's been a long time since I last booted up this VM
whikloj: I think it's an older version of IE 11 that I've got — and I need to reboot the machine to run the update, so I can report back in about an hour….15:30
<whikloj>acoburn: readAsBinaryString seems to be broken in IE 11
acoburn: http://stackoverflow.com/questions/31391207/javascript-readasbinarystring-function-on-e11
acoburn: possible workaround : http://salesforce.stackexchange.com/questions/33567/cant-upload-files-with-ie11-does-not-support-binary-blobs/3356815:31
<acoburn>whikloj: I'd be a little concerned about the suggestion to read the file as Text — but possibly the ArrayBuffer would work15:32
<whikloj>acoburn: yeah, seems using readAsArrayBuffer is the common workaround15:33
<acoburn>whikloj: cool, I'll make that change
<acoburn>whikloj: "Installing update 1 of 4" (and why do I never use Windows?)15:34
<acoburn>whikloj: "Installing update 2 of 4"15:50
<whikloj>acoburn: OMG
<acoburn>whikloj: I wasn't kidding when I said an hour…15:51
<whikloj>acoburn: no you were not
This is why _I_ use AmigaOS only.15:52
* dchandekstark joins
<whikloj>ahhh Amiga, I remember when my buddies father got his first HDD for their Amiga
* dchandekstark leaves15:58
* tolloid leaves15:59
* tolloid joins16:02
<whikloj>acoburn: that change from readAsBinary to readAsArrayBuffer seems to have reduced the onload function size too16:19
<acoburn>whikloj: yes, because this way we can pass the ArrayBuffer directly into the Uint8Array16:20
whikloj: I'm wondering, though, if we could just dispense with that, too
whikloj: I'm testing that now16:21
* tolloid leaves16:23
<acoburn>whikloj: yes, that works without the extra Uint8Array16:27
whikloj: since we really just want an ArrayBuffer in the first place, and that's what readAsArrayBuffer does16:28
<whikloj>acoburn: cool
<acoburn>whikloj: which also means that I can turn off this Windows VM :-)
<acoburn>whikloj: OH NO! It's going to install more software
<whikloj>acoburn: haha yes the dreaded shutdown update
* tolloid joins16:32
* tolloid leaves
<ajs6f>acoburn: Enjoy downloading THE INTERNET.16:45
afk see y'all tomorrow
* ajs6f leaves
* dwilcox leaves16:50
* acoburn leaves16:54
* mikeAtUVa leaves16:55
* martinjd leaves16:56
* whikloj leaves16:59
* peichman leaves17:39
* dchandekstark joins17:55
* dchandekstark leaves18:00
* dchandekstark joins19:57
* dchandekstark leaves20:02
* dchandekstark joins21:58
* dchandekstark leaves22:03
* github-ff joins23:10
[fcrepo4] acoburn opened pull request #1071: Add a servlet filter for handling ETags for static resources (master...fcrepo-2083) https://git.io/vKPkU
* github-ff leaves
* github-ff joins23:19
[fcrepo-webapp-plus] acoburn opened pull request #40: Add servlet filter for handling ETags for static resources (master...fcrepo-2083) https://git.io/vKPkB
* github-ff leaves
* dchandekstark joins00:00
* dchandekstark leaves00:05

Generated by Sualtam