Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-03-14

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:17 amgarching joined #darcs
00:27 mizu_no_oto joined #darcs
00:28 byorgey joined #darcs
00:55 favonia joined #darcs
00:58 byorgey joined #darcs
01:04 byorgey_ joined #darcs
01:08 edwardk joined #darcs
01:08 favonia joined #darcs
01:31 whaletechno joined #darcs
01:55 mizu_no_oto joined #darcs
02:08 mizu_no_oto joined #darcs
02:14 haasn joined #darcs
02:46 ilbot3 joined #darcs
02:46 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.8.4 is out http://darcs.net/Releases/2.8
04:12 mizu_no_oto joined #darcs
06:04 Heffalump sm: yeah, cabal-dev and now cabal sandbox really help with managing that
06:05 Heffalump just in terms of making sure the install doesn't conflit
06:34 lelit joined #darcs
08:22 raichoo joined #darcs
09:22 raichoo1 joined #darcs
09:24 bishboria joined #darcs
11:12 lelit joined #darcs
12:02 nomeata joined #darcs
12:38 mizu_no_oto joined #darcs
12:41 edwardk joined #darcs
13:44 amgarching joined #darcs
14:01 edwardk joined #darcs
14:19 gh_ joined #darcs
14:52 mizu_no_oto joined #darcs
14:58 edwardk joined #darcs
15:21 edwardk joined #darcs
15:30 mizu_no_oto joined #darcs
15:58 stepkut joined #darcs
16:36 whaletechno joined #darcs
17:18 raichoo joined #darcs
17:25 gh_ hi
17:45 dino- gh_, Heffalump: I wanted to mention, I did get darcs 2.9.8+35 built yesterday. So I do have access to the --import and --export
17:49 gh_ dino-, nice :-) there are already a couple of bugs in the bug tracker about that, please report if you find more
17:49 dino- It ended up involving a convoluted chain of tasks for me. My distro had darcs 2.8.0 but I was having problems getting the darcs source with that. I ended up taking over maintainership of darcs built from source for my distro in order to get 2.8.4 packaged right.
17:49 dino- And that allowed me to get 2.9.8
17:50 dino- gh_: Will do, haven't tried the imp/exp yet
17:51 dino- But it's good stuff, I now have two much fresher darcses and get how to use cabal sandbox now.
17:55 mizu_no_oto joined #darcs
18:01 sm dino-: +1!
18:01 dino- sandbox is very cool
18:03 sm which distro ?
18:04 dino- sm: arch https://aur.archlinux.org/packages/darcs/
18:06 dino- I need to change that Description string next time I update. It seems super old-sounding "Decentralized replacement for CVS with roots in quantum mechanics"
18:07 dino- CVS!
18:08 sm heh
18:09 sm Heffalump: darcsden-abstract-backend is an epic load of patches :)
18:09 favonia joined #darcs
18:11 sm got it all building here, except for the third branch - darcsden-abstractcouch - which darcs had failed to pull after 10m of cpu time
18:11 sm too conflictful ? maybe that one could be rebased on top of the others ?
18:12 sm which cli options have changed - just --port ? I think the command-line help needs updating
18:17 colDrMcBeardman joined #darcs
18:26 Heffalump sm: I don't think darcsden-abstractcouch was supposed to be used
18:26 Heffalump yeah, "Preview - not for merging" - it was my original half-baked work on doing this abstraction
18:27 Heffalump good point re the command-line help, I'll fix that. I think it's just --port
18:27 Heffalump I don't want to delete darcsden-abstractcouch, but it looks to be orphaned in the UI (no "forked from")
18:27 dino- This export from git to darcs just worked. I don't have anything fancy like the bugs are speaking of. Executable perms and unicode yada yada.
18:28 sm Heffalump: oh, great
18:28 sm I increased hub request timeout from 30 to 60s to make your branch viewable
18:30 Heffalump heh
19:21 Heffalump sm: pushed a patch to the abstract-backend branch to update README.md and Makefile
19:22 mizu_no_oto joined #darcs
19:29 Heffalump sm: as I've discovered, the compile-time -fhub thing is an obstacle to refactoring. Mind if I (try to) make it a command-line option or similar so that its code at least gets compiled by default?
19:41 stepcut joined #darcs
19:48 raichoo joined #darcs
19:52 favonia joined #darcs
20:31 mizu_no_oto joined #darcs
20:33 amgarching joined #darcs
20:57 bishboria joined #darcs
21:21 amgarching joined #darcs
21:48 IbnFirnas_ joined #darcs
22:03 sm Heffalump: sure, that sounds interesting
22:12 Heffalump I've taken a simpler approach in the end - just making sure all the code gets compiled each time: patch in my darcsden repo
22:15 sm Heffalump: which branch is that ?
22:16 sm oh darcsden, right. 'use test-framework rather than the built-in HUnit test runner' looked like one I already pulled, but no
22:17 sm I like test-framework, though tasty seems to be the new hotness
22:19 bishboria_ joined #darcs
22:21 Heffalump yeah, just thought being consistent with darcs was better than latest-and-greatest
22:21 Heffalump not using it in great anger though, easy enough to switch
22:21 sm sounds reasonable
22:21 sm great to have more tests
22:22 Heffalump it's not any more tests, just makes the existing ones more usable
22:22 sm right. Let's see if this'll deploy now..
22:25 * Heffalump crosses fingers
22:26 sm I need to do something better for local settings than keeping them as a dirty working copy, like a config file
22:29 sm finally.. now running your latest on hub
22:29 Heffalump yay
22:29 Heffalump for settings, we're not far off just reading a file
22:30 sm AWESOME
22:31 sm fewer rebuilds will be good for my carbon footprint
22:31 Heffalump http://hub.darcs.net/simon/darcsden/patches times out, though I guess that would always be a risk with lots of forks and patches in them
22:31 sm yes I noticed.. I've just restored the 60s timeout
22:32 Heffalump also if you push the new patches it'll cut down the work it has to do :-)
22:32 amgarching joined #darcs
22:32 sm true true, just trying to actually look at them before I take that final step
22:33 Heffalump fair nough
22:33 sm pushing blindly would be wrong wouldn't it
22:33 Heffalump yes, I thought deploying to hub implied you'd reviewed them
22:33 Heffalump but I guess testing then reading makes sense too
22:35 sm you'd think that wouldn't you.. *usually* I would read before deploying :)
22:35 sm this time reading was too hard, and I trusted you and GHC :)
22:36 sm I did try it on the dev port first, and I keep the old binaries for a quick rollback
22:37 Heffalump I can talk you through them if that would help
22:37 sm that would be great, for me and #darcs
22:38 sm I'm at http://hub.darcs.net/ganesh/darcsden-abstract-backend/compare/simon/darcsden
22:39 sm I was supposed to pull from both darcs-abstract-settings and darcs-abstract-backend, right ?
22:39 Heffalump ok, so the first 4 are in darcsden-abstract-settings too, and are about adding an implicit parameter for the settings all over the place
22:39 Heffalump yes, though the latter includes the former because of depenencies
22:39 sm ok, great
22:39 Heffalump but the former was supposed to be easier to review on its own if you wanted to stop there
22:39 sm it was, I started there
22:40 Heffalump with the settings patch, I did some restructuring inside the DarcsDen.Settings namespace, with the goal of having the same set of exports, but with an implicit parameter context ?settings :: Settings on them
22:41 Heffalump so for most of the code, it was just type changes, no code changes
22:42 sm I haven't totally grokked it, but seems to work great
22:42 Heffalump the code that was previously in DarcsDen.Settings got duplicated into DarcsDen.Settings.Production and DarcsDen.Settings.Test, and changed for the latter in some casaes
22:42 Heffalump and now when invoking darcsden code in the executables we need to use withSettings to initialise the implicit parameter, to fgo with the withBT/withBP for the backends
22:43 sm ah
22:43 sm withSettings, I see
22:44 Heffalump oh, also I introduced a Settings record type that could be passed around, and use RecordWildCards to initialise it without needing to reorganise all the code directly within record syntax
22:44 Heffalump that's the settings = Types.Settings {..} at the bottom of Settings.{Production,Test}
22:45 Heffalump it's shorthand for initialising the record with homeDir = homeDir, accessLog = accessLog etc
22:46 Heffalump in the next patch, the HTTP port was being passed around as a string for URL construction, and specified as a Int separately for starting the daemon
22:46 Heffalump so I made that a single mechanism and removed the --port option as discussed as it didn't work anyway
22:47 Heffalump the next patch ("abstract startHTTP into a library") moves code from the darcsden exe to the library, so I can call it from the tests in future (i.e. the next patch)
22:48 Heffalump in "start a private instance of the webserver for the tests", I run darcsden in a Test configuration in a separate thread as the actual test running, to move them towards being more self-contained
22:48 Heffalump that also makes them sensible to run because now everything they do is driven entirely by the Test settings not the Production ones
22:48 stepkut joined #darcs
22:49 sm that settings stuff is pretty clever
22:49 sm it's like having a bunch of global variables, but parameterised
22:49 Heffalump I think some simplification is likely to be possible now the main refactoring is done, but I like to keep my patches doing one thing at a time so it's easier to check them
22:50 Heffalump yeah, I think it's the natural way to get away from global variables
22:51 Heffalump ok, so that covers the abstract-settings branch - any questions? Need some time to digest it before the main event? :-)
22:52 sm all good, what next
22:52 sm the lensquake!
22:52 Heffalump :-)
22:52 Heffalump so much of this is quite repetitive, so it's not as scary as the number of patches would suggest
22:53 Heffalump make DarcsDen.State.User exports explicit and delete unused code is self-explanatory, I hope; just trying to make refactoring easier by knowing what was needed in the module
22:53 sm yup
22:53 Heffalump the next patch, switch User type to use lenses was motivated by the following one, split User type into UserKey and UserData
22:54 Heffalump because when I tried to do the latter by hand I had to change a lot of code carefully, including ones where records were being updated that would then turn into a nested record update
22:55 Heffalump so the idea of using lenses is to replace record field names with first class Haskell values that can get and set pieces of a structure
22:55 sm right
22:55 Heffalump in particular you see the User type acquire _ in front of its field names, and the exported symbols become the lens accessors of type Simple Lens (record type) (field type)
22:56 Heffalump and then lookups in the record become calls to 'view', updates of the record become calls to 'set', and read-modify-write of a field becomes calls to 'over'. It was the latter that really benefit from lenses in the case of a refactoring.
22:56 Heffalump view :: Simple Lens record field -> record -> field
22:56 Heffalump set :: Simple Lens record field -> field -> record -> record
22:57 Heffalump over :: Simple Lens record field -> (field -> field) -> record -> record
22:57 sm is there some TH to create the lenses somewhere ?
22:58 mizu_no_oto joined #darcs
22:58 Heffalump I use the "ViewPatterns" extension - it's a semi-coincidence that the "View" in the extension name is the same as in the lens function - to replace pattern-matching on records.
22:58 Heffalump I couldn't use TH so I had to write the lens definitions out by hand
22:58 sm oh I see.. why couldn't you ?
22:58 Heffalump there's a comment about GHC bug 7056 - on Windows Template Haskell doesn't work with some library darcsden imports on GHC 7.6 and below
22:58 sm oh you said. nice
22:59 sm and bad luck
22:59 Heffalump replacing "Just (User { uName = un })" in a pattern with "Just (view uName -> un)" is an example of a view pattern
23:00 sm interesting
23:00 Heffalump line 353 of UserHandlers.hs is an example of using 'over'
23:00 Heffalump it's generally a pretty mechanical translation
23:00 Heffalump the other downside of the lenses is that you can't use record syntax to construct the record values from scratch any more if you want to maintain the abstraction
23:01 Heffalump so we end up with a call to freshUser instead, which I think is definitely less clear. I felt that overall it was worth that cost, but it's not a slam dunk.
23:02 sm it'll take some getting used to for anyone hacking on darcsden
23:02 sm but it might become the norm in time
23:02 Heffalump yeah. I think there are plenty of fairly clear patterns to copy, which helps.
23:03 sm s/anyone/anyone not already lens-experienced/
23:03 Heffalump it would also be possible to take them out again, e.g. post-refactoring
23:03 sm yeah
23:04 Heffalump so if you felt strongly enough that it was worth it, I would be willing to do that
23:04 sm I don't mind not being able to construct records using the type constructor, in fact I prefer it that way, easier to refactor
23:04 Heffalump FWIW I wasn't lens-experienced before I started.
23:04 Heffalump started this refactoring that is
23:04 sm I think it's a great idea
23:04 Heffalump interesting - I felt that the loss of the field names loses us some self-documentation benefits
23:05 Heffalump and the type errors at use sites when a new field is added will become more opaque
23:05 sm (giving lens a try)
23:05 Heffalump ok - well feel free to ask me to take them out again if you change your mind
23:06 Heffalump moving onto splitting up User into UserKey and UserData - you see the payoff in that the changes are entirely inside User.hs
23:06 sm well, I think I usually do it a little differently from this.. I define a default value for the type, or use Data.Default, and whenever I need to construct one I modify that using record syntax
23:06 Heffalump the point of this patch is to abstract out the bits that are really CouchDb specific, even if theoretically abstracted into the BackendPermanent typeclass. The UserKey has the Doc and the Rev types.
23:07 Heffalump hmm, I see. I guess the danger I see with that is inappropriate defaulting
23:07 sm so I don't have to touch as much code when fields change
23:07 Heffalump freshUser is only actually called from one or two places at most
23:08 Heffalump back in a few mins
23:11 sm I see.. reminiscent of persistent, which separates key and data also
23:12 Heffalump "decompose JSON instance for User" is just about building up the JSON code from the code for UserKey and UserData - keeping things modular (and helps later on as you'll see)
23:13 sm backends have different needs for keys, so I guess separating it makes sense
23:13 Heffalump right - a non CouchDB backend will almost certainly have quite a different structure
23:14 Heffalump tell me if I'm going too fast or too slow
23:15 sm just right.. at http://hub.darcs.net/ganesh/darcsden-abstract-backend/patch/20140227073520-81bb2#src/DarcsDen/State/User.hs line 295, newDoc (db Users) ud is looking up data using a UserData ? how does that work
23:15 sm oh, creating one, never mind
23:15 Heffalump yeah - that used to pass the User, and now it passes the UserData
23:15 Heffalump in that case the behaviour is completely unchanged, because the incoming User would always have had the doc and rev set to Nothing, leading to no JSON field
23:16 Heffalump in the case of the update call a bit lower down, only the doc was being set to Nothing, so in theory the missing rev is a behaviour change, but I was pretty sure it wouldn't matter. Actually I should check the Couch docs to make certain.
23:18 Heffalump oh. blast. I'm wrong..
23:18 Heffalump which means I htink you should roll back these changes until I fix it, because it's going to reject any updates to databases
23:19 Heffalump (why I'm wrong is explained at http://docs.couchdb.org/en/latest/intro/api.html#documents )
23:19 sm I can change my user settings ok
23:20 Heffalump ok, one sec then
23:20 Heffalump let me read what the Haskell bindings do
23:20 Heffalump I assumed it was benign because the _rev is being passed to the function anyway
23:21 Heffalump ok. The Haskell binding does put it back in.
23:21 Heffalump phew :-)
23:21 Heffalump http://hackage.haskell.org/package/CouchDB-0.10.1/docs/src/Database-CouchDB-Unsafe.html#updateDoc
23:22 Heffalump (that also explains why the tests weren't affected by my changes - I did run them :-) )
23:22 sm \o/
23:24 Heffalump ok, so given that we now pass in UserData when we don't have a Key, it turns out that we don't need to make the id and rev fields in the UserKey be Maybes any more, which is always nice.
23:25 sm how's your time there.. I can go a little longer, or we could continue tomorrow ?
23:25 Heffalump I'm fine with a little longer
23:25 sm ok
23:25 sm go ahead, brb
23:26 Heffalump next is a bit of cleanup - uID and uRev don't need to be exported, the refactoring I did on the JSON instance turns out to look nicer with a type class, and I need to break up StateUtils a bit to avoid future dependency problems so I move things into a new module DarcsDen.State.JSON
23:27 Heffalump (that brings us to "move pure JSON utils into DarcsDen.State.JSON")
23:28 sm json always seems a bit more work than I naively expect
23:29 Heffalump next is a bit more cleanup of the way we handle databases and designs. The code that adds the designs can be parameterised over the database they belong to, and the designs are really Couch-specific so they can be moved into that backend if we also move the responsibility for adding them to that backend.
23:29 sm great
23:29 edwardk joined #darcs
23:29 Heffalump I think it's simple enough (JSON) - just name value pairs all over the place. The JSONFields class just covers for the fact that we're putting UserKey and UserData into a single JSON document, really.
23:29 sm do you think "schemas" makes more sense than "designs" ?
23:30 Heffalump not sure really :-)
23:30 Heffalump and with them nicely hidden inside the Couch backend, I think it's less important anyway
23:30 sm hmm are we inside Couch here ?
23:31 Heffalump we are after my changes
23:31 sm ok press on
23:31 Heffalump one of the changes in the batch I just mentioned was to explicitly move those things to the Couch backend
23:31 Heffalump that's the "Move schema into the CouchDB backend" patch
23:31 sm I see, nice
23:32 Heffalump "move iteration over databases to class" is a simple refactoring to make the backend responsible for knowing what it has to initialise
23:32 Heffalump (later on in the patch set the concept of globally known database names is removed completely anyway)
23:33 Heffalump "improve name of freshUser" is a simple renaming of freshUser -> freshUserData which is what it does.
23:33 sm proxy and tagged, what's that for
23:33 Heffalump "use Proxy from tagged package" was using something external to replace something internal - really just to help with untangling some dependencies. You can pretty much ignore Proxy anyway because I introduced it previously and this patch set actually gets rid of it completely by the end.
23:33 sm ok
23:34 Heffalump but it's just about passing around a type without passing around a value of that type
23:34 sm interesting
23:34 Heffalump important for inferring the type of the backend in some cases where we don't have an actual instance to hand
23:35 Heffalump ok, so "Move filesystem-related stuff into a separate class" is really the start of breaking up the monolithic BackendPermanent class into smaller pieces. BackendPermanentFileSystem is intended to express the logic for finding repositories on disk.
23:36 Heffalump And all this is really about enabling the "abstract User-related backend code" patch.
23:36 sm great
23:36 Heffalump in that patch, we get a sane API for the User database, in the new BackendPermanentUser class
23:36 Heffalump well, at least non-Couch specific
23:37 Heffalump so that class is the Key - in darcsDen.State.User line 38. The UserKey type becomes abstract.
23:38 Heffalump and the code that is still rather Couch-specific in practice moves to the CouchDB backend
23:38 sm great
23:39 Heffalump ok, then I decided to merge the schema module with the main CouchDB backend module, to keep it all in one place and make other refactorings easier as they wouldn't cross module boundaries so much
23:40 Heffalump and then with the new BackendPermanentUser class, nothing outside the CouchDB backend needs to care that there's a Users database, so I moved that value into the CouchDB backend.
23:40 Heffalump that takes us up to "The 'Users' database name doesn't need to be global now".
23:40 sm yup
23:41 Heffalump ok, so there are 5 databases and I've refactored 1 one of them.
23:41 Heffalump So most of the rest of the patches for a while are just exactly the same pattern on Repo, Issue, Bundle and Comment
23:42 sm ok
23:42 Heffalump Repository has the largest API and the class we end up with is still a bit ugly, I think it probably needs further refactoring
23:42 Heffalump the other thing that comes up with some of the other types that didn't come up with User is that they refer to each other
23:42 Heffalump by Doc
23:42 Heffalump so a Issue refers to a Repository
23:42 Heffalump for example
23:43 Heffalump so I introduced another type function when defining BackendPermanentRepository, called "RepositoryRefKey". That's just Doc (as opposed to Doc+Rev) for the CouchDB backend, but abstractly it's about a unique key for a Repository that will remain invariant over time.
23:44 Heffalump there's also a small compile fix because I was compiling the User changes with -f-closing on Windows and so neglected to update that module and only noticed in the middle of the Repository refactoring
23:45 Heffalump but basically that repetitive pattern gets us to just before "inline code from StateUtils into CouchDB backend"
23:45 Heffalump oh, with a few exceptions which I'll do now

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary