Camelia, the Perl 6 bug

IRC log for #darcs, 2013-08-22

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

All times shown according to UTC.

Time Nick Message
00:59 gbeshers joined #darcs
01:13 kofno joined #darcs
01:44 mizu_no_oto joined #darcs
01:53 intripoon_ joined #darcs
03:09 srinup joined #darcs
03:24 preflex joined #darcs
03:33 mtp_ joined #darcs
03:34 mtp joined #darcs
03:56 arpunk joined #darcs
04:42 kofno joined #darcs
04:54 Heffalump sm: hi!
04:54 jlneder hi!
05:47 kofno joined #darcs
06:47 kofno joined #darcs
06:55 raichoo joined #darcs
07:06 lelit joined #darcs
07:34 endou joined #darcs
07:48 kofno joined #darcs
08:06 amgarchIn9 joined #darcs
08:10 endou joined #darcs
08:48 kofno joined #darcs
08:52 endou joined #darcs
08:56 arpunk joined #darcs
09:23 donri joined #darcs
09:35 raichoo1 joined #darcs
09:49 kofno joined #darcs
09:56 whaletechno joined #darcs
10:18 donri joined #darcs
10:39 owst joined #darcs
10:50 kofno joined #darcs
10:50 dcoutts joined #darcs
11:21 mizu_no_oto joined #darcs
11:41 endou joined #darcs
11:42 mizu_no_oto joined #darcs
11:50 kofno joined #darcs
11:59 mizu_no_oto joined #darcs
12:08 mizu_no_oto joined #darcs
12:38 iago joined #darcs
12:39 kofno joined #darcs
13:06 mizu_no_oto joined #darcs
13:54 bfrank joined #darcs
13:56 arpunk joined #darcs
14:11 mizu_no_oto joined #darcs
14:35 jlneder joined #darcs
14:36 jlneder joined #darcs
14:37 jlneder joined #darcs
14:38 jlneder joined #darcs
14:39 jlneder joined #darcs
14:40 jlneder joined #darcs
14:40 jlneder joined #darcs
14:42 jlneder joined #darcs
14:42 jlneder joined #darcs
14:43 jlneder joined #darcs
14:44 jlneder joined #darcs
14:45 jlneder joined #darcs
14:46 jlneder joined #darcs
14:46 jlneder joined #darcs
14:47 jlneder joined #darcs
14:48 jlneder joined #darcs
14:48 jlneder joined #darcs
14:49 jlneder joined #darcs
14:50 jlneder joined #darcs
14:51 jlneder joined #darcs
15:13 raichoo joined #darcs
15:32 sm g'day g'day
15:50 endou joined #darcs
16:03 sm @tell bsrk the mime patch doesn't build here (M.union undefined)
16:03 lambdabot Consider it noted.
16:03 sm @tell bsrk the next patch (add compare feature) has a lot of conflicts with darcsden head, can you rebase ?
16:03 lambdabot Consider it noted.
16:29 bfrank___ joined #darcs
16:38 mizu_no_oto joined #darcs
16:57 * Heffalump appears
16:58 Heffalump sm: I think I'm meeting bsrk nowish, though I might have misremembered
17:04 Heffalump ah, he cancelled
18:12 Heffalump sm: has darcsden gone through any schema upgrades yet
18:12 Heffalump ?
18:23 amgarchIn9 joined #darcs
18:53 mizu_no_oto joined #darcs
18:56 arpunk joined #darcs
19:04 sm hi Heffalump.. yes, there were some a month or two back
19:19 Heffalump how did it happen? Did you just manually upgrade the db?
19:21 Heffalump (sorry, I think we've had this conversation before, I've just forgotten..)
19:55 bfrank_ joined #darcs
19:57 amgarchIn9 joined #darcs
20:29 lelit joined #darcs
20:32 sm Heffalump: bsrk added special code to handle both old and new schemas, and to auto-upgrade to the new one
20:32 sm I don'
20:33 sm this has advantages but I don't think it scales well, I think I'd prefer to have compile-time schema guarantees like eg persistent, and explicit migrations
20:41 Heffalump oh. I wonder why his bundle stuff doesn't work on my db then.
20:47 sm he might not have done the same thing successfully with the latest
20:47 sm I don't think I've run the latest bundle code here
20:49 sm I think the run-time schema adapting approach breeds bugs
20:49 sm well, at least if you're flipping around between versions the way we are
20:52 Heffalump yeah
20:53 Heffalump FYI I put up a draft version of my changes to abstract over Couch at http://hub.darcs.net/ganesh/darcsden-abstractcouch
20:54 Heffalump not sure if it helps with the upgrade problem
20:54 mizu_no_oto joined #darcs
20:56 sm excellent, I'll check it out soon. I assume an abstraction layer loses some benefits compared to picking say persistent and using all its features ?
20:57 sm nice monster patch :) http://hub.darcs.net/ganesh/darcsden-ab​stractcouch/patch/20130806192128-81bb2
20:57 Heffalump it's just a draft, for one thing it would need merging/rebasing to latest
20:58 Heffalump also, the most disruptive ting is that it introduces a type parameter to Doc and Rev, and I think there must be a better way
20:59 Heffalump I need to get a clearer understanding of how persistent works.
21:01 sm persistent has some very appealing (to me) features - compile-time schema checking, mostly-automatic migration, familiar sql databases, and still some db independence
21:02 sm and battle-tested
21:02 sm but, I haven't actually used it much
21:03 sm just curious: what effect does a type sig like frontpage :: BPRun bp => Page have ? Looks odd since bp isn't used
21:03 Heffalump yeah, it is kind of strange, that's the other dubious aspect of my patch
21:04 Heffalump it's hiding an implicit parameter that gets passed through to callees
21:05 sm this looks like an excellent start, I'm just slightly concerned that abstracting away from sql is a bad move
21:05 Heffalump I'm definitely not wedded to the approach of my patch.
21:05 Heffalump as you know I'm keen on having a "minimal dependencies" way of running darcsden
21:06 * Heffalump reads about Persistent again in the hope it will stick
21:07 sm for a default light dependency setup, I'm assuming persistent plus sqlite will work well
21:15 Heffalump it has the same problems with migrations in terms of general fragility, I think
21:15 sm it detects the problems at compile time
21:15 sm and helps you migrate
21:15 Heffalump it does?
21:16 sm yup
21:16 Heffalump >> I’m sorry to tell you, but so far I have lied to you a bit: the example from the previous section
21:16 Heffalump >> does not actually work. If you try to run it, you will get an error message about a missing table.
21:16 Heffalump that's the first para of the section about migrations
21:16 sm well sure, probably not all possible problems
21:16 sm but some compile-time help is better than none at all
21:16 Heffalump I agree it helps you migrate, i.e. it does a lot of the work for us that we would otherwise do by hand, so it'll be less error-prone
21:16 iago joined #darcs
21:16 Heffalump I don't see any compile-time help with migrations.
21:17 sm I mean, it provides compile-time help with having your code and schema in sync
21:17 sm right now, we don't have that at all
21:18 Heffalump right, ok
21:18 Heffalump but it still has the potential fragility of migrations, and the flipping backwards and forwards problem
21:19 Heffalump so I think it's definitely better than what we're doing now because it does the same general thing but better
21:19 sm yes you're right. It probably doesn't do backward migrations eg
21:19 Heffalump I think the "unsafe" bit would do backwards migrations if that just involves deleting stuff.
21:20 sm but I'd rather have some dev time hassle than unknowingly break the production app by running the dev instance, as I did
21:20 Heffalump dod prod break because dev did a forward migration? If so wouldn't the same problem apply?
21:20 Heffalump s/dod/did/
21:21 sm yes it did.. I think we'd disable the auto-migration-on-startup that most persistent examples do
21:22 sm so dev would fail, and you'd know you have to do something different (use a separate db, or deploy the same schema change to prod)
21:23 Heffalump right
21:24 sm if you feel a total abstraction layer is worthwhile, and it works, I'll totally give it a try
21:24 sm but here's why I'm pushing sql a bit: as a darcsden admin, I crave easy adhoc sql queries and the mature sql toolset, and feel no need for anything more exotic than sqlite or postgres. And as a maintainer, I crave mature libs and to keep our own codebase as small and standard as possible, so we can focus on our user-facing features
21:24 Heffalump I guess my biggest concern is that sticking with a database-ish representation will make distributed bug tracking harder. But that doesn't exist right now.
21:24 Heffalump what wuold you do with adhoc sql queries?
21:25 Heffalump I guess you have a userbase you need to understand
21:25 sm yes, I've had any number of needs for this and it has been a pain
21:25 Heffalump I think I'm sold on persistent, at least for the medium term.
21:26 sm understanding what's going on in prod.. repairing bugs.. managing users in ways the ui doesn't allow yet
21:26 Heffalump arguably a VCS backend could also be written for persistent
21:26 sm indeed.. or an acid-state one ?
21:27 sm oh VCS backend, I see what you're thinking
21:27 sm everything stored in darcs
21:27 sm there's also the lib gitit uses, filestore
21:28 Heffalump yeah, though I think it's for filesystem-structured things, not db-structured things
21:29 sm arguably it would be great to have everything on the filesystem
21:29 sm I guess that'd be an alternative to sql/db-ish storage
21:29 Heffalump oh yes, that's the other argument I had I'd forgotten about :-)
21:30 Heffalump I want more stuff to come from the presence of repos in a directory and from things in _darcs
21:30 Heffalump so that things are more mobile and more manipulable directly
21:30 sm right. Since repos are always filesystem-based, if we could avoid having a db at all it removes another source of bugs, db and fs being out of sync
21:30 Heffalump but your point about SQL is significant when you're looking at a large userbase
21:31 sm I think manipulating things on the fs is also fine for admin tasks.. makes some things easier, some things harder
21:31 sm it sounds a bit harder to make it perform well
21:31 Heffalump yeah, will definitely be bad for scaling
21:32 sm I think last time we discussed this, there was the idea that everything is stored on fs primarily, but you can add an optional db to accelerate it
21:32 Heffalump oh yes, now I remember where I was going with the abstraction layer :-)
21:32 sm \o/ :)
21:33 Heffalump but as it stands it doesn't help restructure the data, that would have been the next step
21:34 sm it's also possible an all fs-based system even with no db accelerator might perform just fine for current darcs hub
21:34 Heffalump I suspect that's likely for current usage
21:34 sm simplifying dependencies, architecture, and enhancement is probably higher priority than scaling
21:35 Heffalump that would point in favour of dropping databases altogether
21:35 Heffalump i.e. not just optionally
21:35 sm yes, at least for now
21:35 sm I would see the db coming back later as an option when needed
21:38 * sm might be overthinking. What are our goals, current pain point, best uses of limited time ?
21:38 Heffalump mine: make darcsden more useful locally, migrate the darcs issue tracker to use it
21:40 sm mine: make darcs hub easier to enhance, easier to maintain, sustainable, and more useful
21:41 sm and indirectly, have the same effect on darcs itself
21:48 sm my pain points: adhoc queries and some management tasks are a hassle; darcs hub activity is opaque and hosting risks are on the rise; not much checking of schema correctness; contributing requires setting up two uncommon dbs; schema changes are error-prone
21:50 Heffalump ok, so SQL or the filesystem would improve the adhoc queries thing, but in different directions
21:52 Heffalump I think the main benefit of the filesystem over SQL is that it would encourage design of the schema as something associated with "real" things like repos rather than an isolated thing
21:54 Heffalump bed calls
21:54 sm ok.. night Heffalump
21:58 * sm thinks making single-user-single-repo mode work without a db will be a good step
21:59 sm later
22:42 codolio joined #darcs
23:08 mizu_no_oto joined #darcs
23:56 arpunk joined #darcs

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