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

Using timezone: Eastern Standard Time
* jcoyne joins08:41
* jcoyne leaves08:59
* acoburn joins09:11
* dwilcox joins09:33
* dwilcox_ joins09:39
* dwilcox leaves09:42
* dwilcox_ leaves10:14
* github-ff joins10:21
[fcrepo-module-auth-webac] ajs6f pushed 2 new commits to master: https://git.io/vaRda
fcrepo-module-auth-webac/master 56eb1d7 Aaron Coburn: Tighten webac module code...
fcrepo-module-auth-webac/master 2f6ca56 A. Soroka: Merge pull request #59 from acoburn/fcrepo-1946...
* github-ff leaves
* jcoyne joins10:23
* travis-ci joins10:30
fcrepo4/fcrepo-module-auth-webac#117 (master - 2f6ca56 : A. Soroka): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/32015b3f504c...2f6ca56de4cd
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/116132520
* travis-ci leaves
* EdF joins10:35
* whikloj joins10:43
* github-ff joins11:00
[fcrepo-module-auth-rbacl] acoburn opened pull request #28: change AccessRolesProvider::getRoles to return a Collection instead of a List (master...fcrepo-1955) https://git.io/va0Uz
* github-ff leaves
* tjohnson joins11:12
* github-ff joins11:19
[fcrepo-module-auth-webac] acoburn opened pull request #60: change WebACRolesProvider::getRoles to return a Collection (master...fcrepo-1955) https://git.io/va0qR
* github-ff leaves
* ajs6f leaves11:39
<whikloj>ajs6f: I think the webac PR failed because the RbAcl one is not merged. You mind if I merge it?
<acoburn>whikloj: ajs6f is out, but feel free to merge11:40
* github-ff joins11:41
[fcrepo-module-auth-rbacl] whikloj pushed 2 new commits to master: https://git.io/va0Gk
fcrepo-module-auth-rbacl/master e4bdcb2 Aaron Coburn: change AccessRolesProvider::getRoles to return a Collection instead of a List...
fcrepo-module-auth-rbacl/master eeb03ee Jared Whiklo: Merge pull request #28 from acoburn/fcrepo-1955...
* github-ff leaves
<whikloj>acoburn: I restarted the Travis run, if ajs6f isn't back when it completes I can merge the WebAC one as well11:42
<acoburn>whikloj: travis wail fail until the new rbacl artifacts are published11:43
whikloj: once jenkins finishes, that will happen: http://jenkins.fcrepo.org/view/FF/
<whikloj>acoburn: ohhhhh right, sorry I stupidly thought it built it all.11:44
* rbenji joins11:49
<whikloj>acoburn: can I add multiple "peeks" in a stream chain to see what has changed at each "step"?11:50
<acoburn>whikloj: yes, it's good for logging (and debugging)11:51
* travis-ci joins
fcrepo4/fcrepo-module-auth-rbacl#48 (master - eeb03ee : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/d328d0fc1240...eeb03ee06739
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/116152330
* travis-ci leaves
<acoburn>whikloj: but you have to be a little careful with your expectations
<whikloj>acoburn: I just want to learn how some of these things you do (map -> filter) look inside, I have no context for what is happening
<acoburn>whikloj: myBigList.stream().peek(…).findFirst().get()11:52
whikloj: there, you'll only see the first element logged
<whikloj>acoburn: because it only operates on that one?11:53
<acoburn>whikloj: yes, the data is _streamed_ and you only use as much as you ask for
<acoburn>whikloj: there is a lot of "lazy evaluation" happening
whikloj: fyi the travis build finished: https://github.com/fcrepo4/fcrepo-module-auth-webac/pull/6011:55
<whikloj>acoburn++ # oops11:56
* github-ff joins
[fcrepo-module-auth-webac] whikloj pushed 2 new commits to master: https://git.io/va0CI
fcrepo-module-auth-webac/master f6b8dc7 Aaron Coburn: change WebACRolesProvider::getRoles to return a Collection...
fcrepo-module-auth-webac/master 7b44189 Jared Whiklo: Merge pull request #60 from acoburn/fcrepo-1955...
* github-ff leaves
<acoburn>whikloj++ #thanks
* dwilcox joins13:07
* dwilcox leaves13:22
* dwilcox joins13:27
* dwilcox leaves13:38
* ajs6f joins14:25
<whikloj>acoburn/ajs6f: Thought you might be interested, I was doing some learning on streams and found this Javascript implementation of them. https://github.com/winterbe/streamjs14:46
<ajs6f>whikloj: Cute. Yeah, they are a heck of a useful tool.14:47
<acoburn>whikloj: JS arrays have native prototypes for .map and .filter, which are really nice14:49
<ajs6f>Jav arrays are really efficient, but that's all they are.14:50
<whikloj>this guys tutorial is (IMHO) very clear. http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/14:55
Really helps with why you guys do certain things with streams
<ajs6f>whikloj: That guy says something very useful at the beginning: streams are monads. They're not iterators. The fact that Java connects the source of elements to the series of operations you perform in the stream is kind of off-point. It's just how Java does things. The real action is in the series of calculations, and if you look at the impl classes that actually do work in the Streams API, you will see that they don't care at all about where 14:58
whikloj: he doesn't point out that Optional is also a monad, but that's why it also features flatMap (and why flatMap is useful with Optional).15:00
whikloj: Actually, pretty much any collection is also a monad, but Java's impl doesn't make that clear or let you use that fact, which is kind of crappy.
<acoburn>whikloj: to that ^^^ I would add that what this manner of programming gives you is a much more declarative style, which make the "independent transformation of data" more important that the "state of a particular object".15:02
whikloj: IMO it's much more readable than the Iterator-based code you may have seen elsewhere15:03
<whikloj>acoburn: once you understand it, I would agree. But sometimes those long chains lose me15:04
<ajs6f>whikloj: Most, although not all, of those long chains can be broken up for readability, and there's nothing wrong with that.
Stream<Thing> things = collection.stream().map().filter();
<acoburn>whikloj: it's just a style. It's sort of like reading Joyce: it takes a little while to get used to it, but then it all starts making sense (or, in the case of Joyce, it doesn't)
<ajs6f>Stream<Other> others = things.filter().map();15:05
<whikloj>ajs6f: true, but the reason I don't understand it is more to do with my lack of comfort than the actual chain
* peichman joins
<ajs6f>acoburn: Come to Dublin. Find out if Joyce makes any more sense in context.
<acoburn>whikloj: if you'd like to try your hat at Streams, the rbacl code could be significantly refactored to use Streams15:06
whikloj: the code is pretty bite-sized, and ajs6f and I will guide you through the style considerations
<ajs6f>I would like to try my hat at all kinds of things.
<whikloj>acoburn: I'll put it on the list, I'm supposed to be converting fcr:transform to use Fedora resources instead of direct JCR15:07
<acoburn>ajs6f: I doubt Finnegan's Wake will make any more sense if I am in Dublin15:08
<ajs6f>acoburn: It's not the location, it's the drinking you will do. Given a good evening, you will be able to _write_ Finnegans Wake.15:09
<ajs6f>FW may actually just be an early draft of an APL language standard using only ASCII characters.15:10
<acoburn>ajs6f: the only part I really understood was "the fall": bababadalgharaghtakamminarronnkonnbronntonnerronntuonnthunntrovarrhounawnskawntoohoohoordenenthurnuk!15:12
<ajs6f>acoburn: My 2-year-old son says things like that every day, but no one is writing them down. What a pity...15:14
acoburn: I've honestly not got a lot of patience for that sort of book. I'm more inclined to Brian O'Nolan
's view of Joyce.
acoburn: Am I supposed to merge those two PRs at the same time?15:25
<acoburn>ajs6f: whikloj already took care of that
* ajs6f leaves
* github-ff joins15:30
[fcrepo4] acoburn opened pull request #1007: Allow references to the Root resource to omit a trailing slash (master...fcrepo-1884) https://git.io/vaEmI
* github-ff leaves
* ajs6f joins
* github-ff joins15:31
[fcrepo-module-auth-webac] acoburn opened pull request #61: Integration tests to confirm that FCREPO-1884 has been fixed (master...fcrepo-1884) https://git.io/vaEmg
* github-ff leaves
* peichman leaves15:41
<jcoyne>Has anyone seen a FileNotFoundException for transaction.log ?15:50
Nm, somone deployed an old version.15:53
<acoburn>ajs6f: do you have an opinion about using Akka?15:54
<ajs6f>acoburn: In fcrepo4?!?!
<acoburn>ajs6f: yes
<ajs6f>acoburn: I have never even considered it. You are talking about a pretty substantial rearchitecture, no?15:55
acoburn: not against it, not for it— it never occured to me.
acoburn: going to Play, too?
<acoburn>ajs6f: no, not that far15:56
ajs6f: I was thinking about this: https://jira.duraspace.org/browse/FCREPO-1498
<ajs6f>acoburn: Oh, like we talked about the other day? How do you percolate the change out through the repo?15:57
<acoburn>ajs6f: I thought the actor model would be nicer to work with than a thread pool15:58
<ajs6f>acoburn: It _could_ be. But the investment… are you thinking about just introducing it for this one thing as a sort of test drive?
<acoburn>ajs6f: I'm on the fence about this. It seems like it could be a good sort of "test drive", but it's also a pretty big step15:59
<ajs6f>acoburn:whikloj: Yes. And using Futures from a thread pool isn't that hard and is pretty cheap. whikloj: Futures (Promises)? They're monads too. THEY'RE EVERYWHERE.16:00
<ajs6f>acoburn: Maybe we can think of some other uses for actors? Other places they would either simplify something we are already doing or make it cheap enough to do something new that we might do it.
<acoburn>ajs6f: once we start talking about a distributed F4 system, actors make a ton of sense. In the modeshape impl, I admit that it's a little forced16:02
<ajs6f>acoburn: Yeah, that was my reaction above. Of course, we are working hard to stop talking about MODE and start talking about that distributed impl.16:03
<acoburn>ajs6f: and Akka works so very nicely with Scala…16:04
<ajs6f>acoburn: Oh, I see how it is. "Try this stuff, man. Oh, you like it? You want the harder stuff now?" Shocking, acoburn.
<acoburn>ajs6f: Akka: the gateway drug16:05
<ajs6f>acoburn: I like to imagine Odersky intoning that in his affectless deadpan.16:06
<ajs6f>acoburn: If there is anything to which Odersky is addicted, it's long strings of punctuation marks.16:07
acoburn: I would not be against using Akka for this purpose, but I really would want to see another use case, and if you find it anywhere, I think it will be in fixity.16:08
<acoburn>ajs6f: that's a good point16:09
<ajs6f>acoburn: In some ways, I'm less worried about how we enact async behavior than how we expose it. Async in a REST architecture is… weird. It's like reaching down into the water in your bath and feeling something scaly.16:10
<acoburn>ajs6f: next thing you know, we'll need a zookeeper ensemble just to run F4, and I'm not sure that will go over well16:13
<ajs6f>acoburn: No, this is where we started to back off several years ago looking at Project Lily and other Hadoop assemblages.16:14
acoburn: On the other hand, maybe these are just hard problems. And as long as a solid single-node impl is easily available… maybe it's okay to say, "If you want to go on this ride, you have to be taller than this cartoon sign."16:15
<acoburn>ajs6f: well, they certainly are hard problems. You don't need a zk ensemble to find consensus on that16:16
acoburn: Got to run, but if you want to put this on a call, I will happily talk about it.16:17
<acoburn>ajs6f: ok, I'll start looking at Akka. It may be a few weeks (months?) before I have anything
<ajs6f>acoburn: np. It's good to be looking ahead down the road. We may still go over the cliff, but at least we will have our act together enough to do the wave as we do.16:18
* ajs6f leaves16:19
* tjohnson leaves16:34
* dwilcox joins16:35
* dwilcox leaves16:48
* rbenji leaves16:49
* whikloj leaves17:00
* acoburn leaves17:07
* ksclarke joins17:17
* jcoyne leaves17:25
* peichman joins17:29
* peichman leaves18:15
* jcoyne joins20:12
* jcoyne leaves20:14
* ksclarke leaves20:28
* jcoyne joins20:52
* peichman joins21:00
* peichman leaves21:04

Generated by Sualtam