IRC logs for #baserock for Tuesday, 2016-06-07

*** gtristan has quit IRC00:41
*** gtristan has joined #baserock01:00
*** franred has joined #baserock04:08
*** gtristan has quit IRC05:47
*** gtristan has joined #baserock06:19
*** CTtpollard has joined #baserock07:18
paulsherwoodpedroalvarez: any ideas about https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2016-June/013663.html ?07:28
*** rdale has joined #baserock07:39
franredpaulsherwood, biff07:45
paulsherwoodfranred: aha! thanks!07:46
franredno probs :)07:47
paulsherwoodso basically morph ignores that morph file, and so should ybd. but this is another example where i think we'd be better off constraining, so users can't leave dud definitions lying around07:50
jjardon+107:52
*** toscalix has joined #baserock07:54
franredpaulsherwood, we just have to clean dead code (or old files) - that was wrongly merged when we reviewed that code, so it has been never used07:55
paulsherwoodfranred: it's not that simple for me, i'm afraid (never is...)07:55
paulsherwoodybd parses all definitions, every time it runs, to allow (for example) path/to/ybd.py pies x86_6407:57
franredpaulsherwood, morph ignores that file because it is not listed in the stratum, so ybd should do something similar, IMHO. If we want to have same definition with different versions at some point this is something that should be able to do the build system07:58
paulsherwoodeven supposing we clean up, this use-case is now valid because it's been present in definitions.git for a long time07:58
paulsherwoodi agree ybd has a bug here (and i'm confused as to why it didn't show up ages ago)07:59
paulsherwoodfranred: my general approach with ybd is to attempt to support all historical versions of definitions as far back as possible08:02
franredok, although this bug is just a very old use-case. morph field (path to morph file) was definitions long time ago. I'm also confused why ybd didn't catch it before either.08:05
franreds/was definitions/was in definitions/08:05
paulsherwoodack08:08
*** edcragg has joined #baserock08:11
*** CTtpollard has quit IRC08:26
franredpaulsherwood, ybd is detecting that has to build manually the chunk "16-06-07 00:00:03 [0/1/1] [pies] Defined build system is manual" when in the definition is defined as "build-system: python-distutils" -- maybe you have default ybd to build manual and use any file which matches with the name of the chunk?08:28
*** CTtpollard has joined #baserock08:29
franredso I can see there are 2 bugs: 1) Bad detection/parsing of the build-system field 2) Default to manual build using any random file which is in the system with same name as the chunk08:29
franredpaulsherwood, I've got the log from https://github.com/devcurmudgeon/ybd/issues/22508:30
*** jonathanmaw has joined #baserock08:31
paulsherwoodfranred: yup. thanks. i have a late night ahead of me :-)08:31
franredat the moment I don't have more time to spend on this - if I have some spare time I may check what ybd does in "def get_build_commands(defs, this)" https://github.com/devcurmudgeon/ybd/blob/master/ybd/assembly.py08:31
franredpaulsherwood, I would suggest to check what does "this" contain when "this['name']" is pie inside of get_build_commands (or something similar)08:33
paulsherwoodack, tvm08:35
franredyw08:37
pedroalvarezall sorted?08:50
*** CTtpollard has quit IRC08:51
*** CTtpollard has joined #baserock08:53
benbrown_paulsherwood: re my lorry-controller patches and how well they've been tested, I've been using it with a trove + gitlab deployed to my laptop09:00
benbrown_paulsherwood: I also sent an email to the list with a link to a repo with ansible scripts to deploy lorry-controller + gitlab to debian/ubuntu09:01
franredpedroalvarez, I think so09:02
paulsherwoodyup09:08
paulsherwood(except for fixing the bug in ybd of course)09:08
*** locallycompact has joined #baserock09:25
*** locallycompact has quit IRC09:27
*** locallycompact has joined #baserock09:29
edcraggfwiw, i believe 'this' to be a very confusing variable name09:46
paulsherwoodedcragg: you're not the first to remark on that. can you suggest something else, that's short and could sensibly represent 'the definition we currently care about' ?10:11
paulsherwoodi did rename many of the 'this' instances... but 'component' and 'definition' are long10:11
* richard_maw thinks that's exactly the wrong idea, and that the name *has* to be different all over the place, because the contexts of its uses are different all over the palce10:11
richard_maws/palce/place/10:11
*** richard_maw has left #baserock10:12
paulsherwoodrichard_maw: you have a point. that makes it even harder to find meaningful names, though10:12
* rjek wonders what is wrong with long, descriptive variable names10:19
* paulsherwood likes short code lines10:21
paulsherwoodbut i take your point also, rjek10:21
edcraggit's nice when it's clear what parameters are, by way the code works, as part of an architectural/design decision10:22
* rjek suggests assembler if you want short lines :)10:23
jmacsIt's annoying when PEP 8 recommends a Fortran-style line length of 72 characters, but I'd rather ignore PEP8 than write short variable names10:25
edcraggdescriptiveness of variables is important in dynamically typed languages10:26
pedroalvarezhehe, I remember paulsherwood complaining because of meaningless and short variable names :)10:30
paulsherwoodi complain about everyone else's code... just as you folks complain about mine :)10:31
paulsherwoodgiven that folks seem happy that morph uses 'a' as a variable, i guess i could s/this/d/ ?10:33
pedroalvarezI think your review that day about meaningless variable names was good tbh10:34
paulsherwoodthank you. this stuff is hard10:34
pedroalvarezit really helps newcomers to understand the code quickly10:35
paulsherwoodmy question was serious - would folks grok that d is always a definition?10:35
perrylpaulsherwood: would def be acceptable? single character variables can be confusing10:36
SotKI don't think that "d" is any more understandable than "this"10:36
paulsherwoodperryl: def is a keyword in python10:36
perrylso it is, darn!10:36
paulsherwoodSotK: but you're ok with 'a'?10:36
edcragg'd' it has more meaning than 'this' imo10:36
perryldefn? :)10:36
franredwhy not "definition" ?10:36
rjek"morph"10:37
* rjek runs for the hills10:37
SotKpaulsherwood: No. Where is that variable in morph ooi?10:37
paulsherwoodfranred: inevitably leads to having to spread code over more lines10:37
rjekIt's 2016.  We have monitors with more than 80 columns now!10:38
* rjek tries to keep to 80, but doesn't mind overflowing if it means more clarity10:38
locallycompactdefinition has no information associated with it, how is it useful for a function to take a "definition" as a parameter? What is this function doing?10:38
paulsherwoodSotK: search for a. in the code - there's also 'sa'10:38
paulsherwoodrjek: agreed, but i choose to run pep810:39
paulsherwoodlocallycompact: ybd has lots of functions that operate on a definition10:39
franredlocallycompact, I was showing an example for not use def, defn .... On the other hand, if a function take a definition and evaluate it should be perfectly fine as math terminology, if you are going in that path10:40
jmacspaulsherwood: "d" does sound better than "this" for that code. "this" is a specific term meaning the current instance of a class; 'd' is abstract10:40
paulsherwoodack10:40
jmacsSince it's used over a maximum of about 20 lines using a single character variable name seems OK to me10:40
locallycompactpaulsherwood, I'd start by throwing them out, not changing the name10:41
locallycompactThere is no common interface for a "definition".10:41
paulsherwoodlocallycompact: and replacing with what?10:43
locallycompactwhat's an example of this happening atm10:44
paulsherwoodhttps://github.com/devcurmudgeon/ybd/blob/master/ybd/cache.py#L3410:45
paulsherwoodfrom a set of defintions (defs) calculate the cache key of a definition (this)10:45
* locallycompact is processing10:49
locallycompactOk so you're using the dictionary to side effect the status of the cache key calculation into something that could be basically any valid json type.10:52
locallycompactthere's three reasons this function is confused for me:10:55
locallycompact1) it returns string or False10:55
locallycompact2) it side effects as well as returns10:55
locallycompact3) it's hidden information in the parameter "definition", in order to reextract it inside the implementation "if definition.get('repo')"10:56
locallycompactthis is a sort of boolean blindness10:56
locallycompactthe fix for 1) is to return string or None,10:57
locallycompactwhich is the closest thing python has to Maybe String10:57
*** pedroalvarez has left #baserock10:58
locallycompactthe simplest fix for 2 is to add more types, a cache key calculator can take a dictionary and calculate a cache key from first principles, just don't mutate the dictionary10:59
paulsherwoodwhile all of the above is valid criticism, you'd still need to pass definition (or whatever we call it) to the cache_key function, surely?11:04
locallycompactSo, firstly yes, but not surely.11:05
locallycompactIn this case what you've meant by definition is "a dictionary that might have an arch, and might have a repo and therefore a tree", but this isn't well typed.11:07
locallycompactWhat I would think of as the right way to do this is to pattern match on things that can validly have cache keys, a chunk cache key is provided in such and such a way, a stratum cache key is provided in another such and such a way, the type guides the calculation.11:08
locallycompactI'm not able to point to "how to calculate this for a chunk/stratum/system", here11:09
*** paulwaters_ has joined #baserock11:44
*** franred has quit IRC11:56
*** gtristan has quit IRC12:00
*** gtristan has joined #baserock12:46
*** CTtpollard has quit IRC12:59
*** CTtpollard has joined #baserock13:41
*** franred has joined #baserock14:37
*** rjek_ has joined #baserock15:36
*** rjek has quit IRC15:40
*** rjek_ is now known as rjek15:41
*** jonathanmaw has quit IRC17:02
jmacsrjek: I don't understand your post to the mailing list; are you saying Gitano supports multiple levels of heirarchy and that's bad?17:24
rjekI meant to communicate that it does support them and that is good, and that GitLab does not support them which is bad.17:25
jmacsRight.17:25
rjekBut it's been a long hot day and my brain may be turning to goo17:25
*** toscalix has quit IRC17:37
*** locallycompact has quit IRC17:43
*** tiagogomes has quit IRC18:16
*** rdale has quit IRC18:28
robtaylorperryl: loving the bomb-drop ;)21:02
* robtaylor gets the popcorn21:02
rjekHaha21:05
* rjek replies suggesting gogs and Launchpad21:05
SotKlaunchpad++ :D21:05
*** edcragg has quit IRC21:08
rjekObviously Baserock did be reworked to use bzr, as unlike git it has a user interface.21:25
*** franred has quit IRC22:55

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!