| *** gtristan has quit IRC | 00:41 | |
| *** gtristan has joined #baserock | 01:00 | |
| *** franred has joined #baserock | 04:08 | |
| *** gtristan has quit IRC | 05:47 | |
| *** gtristan has joined #baserock | 06:19 | |
| *** CTtpollard has joined #baserock | 07:18 | |
| paulsherwood | pedroalvarez: any ideas about https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2016-June/013663.html ? | 07:28 |
|---|---|---|
| *** rdale has joined #baserock | 07:39 | |
| franred | paulsherwood, biff | 07:45 |
| paulsherwood | franred: aha! thanks! | 07:46 |
| franred | no probs :) | 07:47 |
| paulsherwood | so 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 around | 07:50 |
| jjardon | +1 | 07:52 |
| *** toscalix has joined #baserock | 07:54 | |
| franred | paulsherwood, we just have to clean dead code (or old files) - that was wrongly merged when we reviewed that code, so it has been never used | 07:55 |
| paulsherwood | franred: it's not that simple for me, i'm afraid (never is...) | 07:55 |
| paulsherwood | ybd parses all definitions, every time it runs, to allow (for example) path/to/ybd.py pies x86_64 | 07:57 |
| franred | paulsherwood, 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 system | 07:58 |
| paulsherwood | even supposing we clean up, this use-case is now valid because it's been present in definitions.git for a long time | 07:58 |
| paulsherwood | i agree ybd has a bug here (and i'm confused as to why it didn't show up ages ago) | 07:59 |
| paulsherwood | franred: my general approach with ybd is to attempt to support all historical versions of definitions as far back as possible | 08:02 |
| franred | ok, 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 |
| franred | s/was definitions/was in definitions/ | 08:05 |
| paulsherwood | ack | 08:08 |
| *** edcragg has joined #baserock | 08:11 | |
| *** CTtpollard has quit IRC | 08:26 | |
| franred | paulsherwood, 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 #baserock | 08:29 | |
| franred | so 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 chunk | 08:29 |
| franred | paulsherwood, I've got the log from https://github.com/devcurmudgeon/ybd/issues/225 | 08:30 |
| *** jonathanmaw has joined #baserock | 08:31 | |
| paulsherwood | franred: yup. thanks. i have a late night ahead of me :-) | 08:31 |
| franred | at 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.py | 08:31 |
| franred | paulsherwood, I would suggest to check what does "this" contain when "this['name']" is pie inside of get_build_commands (or something similar) | 08:33 |
| paulsherwood | ack, tvm | 08:35 |
| franred | yw | 08:37 |
| pedroalvarez | all sorted? | 08:50 |
| *** CTtpollard has quit IRC | 08:51 | |
| *** CTtpollard has joined #baserock | 08: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 laptop | 09: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/ubuntu | 09:01 |
| franred | pedroalvarez, I think so | 09:02 |
| paulsherwood | yup | 09:08 |
| paulsherwood | (except for fixing the bug in ybd of course) | 09:08 |
| *** locallycompact has joined #baserock | 09:25 | |
| *** locallycompact has quit IRC | 09:27 | |
| *** locallycompact has joined #baserock | 09:29 | |
| edcragg | fwiw, i believe 'this' to be a very confusing variable name | 09:46 |
| paulsherwood | edcragg: 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 |
| paulsherwood | i did rename many of the 'this' instances... but 'component' and 'definition' are long | 10: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 palce | 10:11 | |
| richard_maw | s/palce/place/ | 10:11 |
| *** richard_maw has left #baserock | 10:12 | |
| paulsherwood | richard_maw: you have a point. that makes it even harder to find meaningful names, though | 10:12 |
| * rjek wonders what is wrong with long, descriptive variable names | 10:19 | |
| * paulsherwood likes short code lines | 10:21 | |
| paulsherwood | but i take your point also, rjek | 10:21 |
| edcragg | it's nice when it's clear what parameters are, by way the code works, as part of an architectural/design decision | 10:22 |
| * rjek suggests assembler if you want short lines :) | 10:23 | |
| jmacs | It's annoying when PEP 8 recommends a Fortran-style line length of 72 characters, but I'd rather ignore PEP8 than write short variable names | 10:25 |
| edcragg | descriptiveness of variables is important in dynamically typed languages | 10:26 |
| pedroalvarez | hehe, I remember paulsherwood complaining because of meaningless and short variable names :) | 10:30 |
| paulsherwood | i complain about everyone else's code... just as you folks complain about mine :) | 10:31 |
| paulsherwood | given that folks seem happy that morph uses 'a' as a variable, i guess i could s/this/d/ ? | 10:33 |
| pedroalvarez | I think your review that day about meaningless variable names was good tbh | 10:34 |
| paulsherwood | thank you. this stuff is hard | 10:34 |
| pedroalvarez | it really helps newcomers to understand the code quickly | 10:35 |
| paulsherwood | my question was serious - would folks grok that d is always a definition? | 10:35 |
| perryl | paulsherwood: would def be acceptable? single character variables can be confusing | 10:36 |
| SotK | I don't think that "d" is any more understandable than "this" | 10:36 |
| paulsherwood | perryl: def is a keyword in python | 10:36 |
| perryl | so it is, darn! | 10:36 |
| paulsherwood | SotK: but you're ok with 'a'? | 10:36 |
| edcragg | 'd' it has more meaning than 'this' imo | 10:36 |
| perryl | defn? :) | 10:36 |
| franred | why not "definition" ? | 10:36 |
| rjek | "morph" | 10:37 |
| * rjek runs for the hills | 10:37 | |
| SotK | paulsherwood: No. Where is that variable in morph ooi? | 10:37 |
| paulsherwood | franred: inevitably leads to having to spread code over more lines | 10:37 |
| rjek | It'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 clarity | 10:38 | |
| locallycompact | definition 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 |
| paulsherwood | SotK: search for a. in the code - there's also 'sa' | 10:38 |
| paulsherwood | rjek: agreed, but i choose to run pep8 | 10:39 |
| paulsherwood | locallycompact: ybd has lots of functions that operate on a definition | 10:39 |
| franred | locallycompact, 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 path | 10:40 |
| jmacs | paulsherwood: "d" does sound better than "this" for that code. "this" is a specific term meaning the current instance of a class; 'd' is abstract | 10:40 |
| paulsherwood | ack | 10:40 |
| jmacs | Since it's used over a maximum of about 20 lines using a single character variable name seems OK to me | 10:40 |
| locallycompact | paulsherwood, I'd start by throwing them out, not changing the name | 10:41 |
| locallycompact | There is no common interface for a "definition". | 10:41 |
| paulsherwood | locallycompact: and replacing with what? | 10:43 |
| locallycompact | what's an example of this happening atm | 10:44 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/cache.py#L34 | 10:45 |
| paulsherwood | from a set of defintions (defs) calculate the cache key of a definition (this) | 10:45 |
| * locallycompact is processing | 10:49 | |
| locallycompact | Ok 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 |
| locallycompact | there's three reasons this function is confused for me: | 10:55 |
| locallycompact | 1) it returns string or False | 10:55 |
| locallycompact | 2) it side effects as well as returns | 10:55 |
| locallycompact | 3) it's hidden information in the parameter "definition", in order to reextract it inside the implementation "if definition.get('repo')" | 10:56 |
| locallycompact | this is a sort of boolean blindness | 10:56 |
| locallycompact | the fix for 1) is to return string or None, | 10:57 |
| locallycompact | which is the closest thing python has to Maybe String | 10:57 |
| *** pedroalvarez has left #baserock | 10:58 | |
| locallycompact | the 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 dictionary | 10:59 |
| paulsherwood | while 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 |
| locallycompact | So, firstly yes, but not surely. | 11:05 |
| locallycompact | In 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 |
| locallycompact | What 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 |
| locallycompact | I'm not able to point to "how to calculate this for a chunk/stratum/system", here | 11:09 |
| *** paulwaters_ has joined #baserock | 11:44 | |
| *** franred has quit IRC | 11:56 | |
| *** gtristan has quit IRC | 12:00 | |
| *** gtristan has joined #baserock | 12:46 | |
| *** CTtpollard has quit IRC | 12:59 | |
| *** CTtpollard has joined #baserock | 13:41 | |
| *** franred has joined #baserock | 14:37 | |
| *** rjek_ has joined #baserock | 15:36 | |
| *** rjek has quit IRC | 15:40 | |
| *** rjek_ is now known as rjek | 15:41 | |
| *** jonathanmaw has quit IRC | 17:02 | |
| jmacs | rjek: 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 |
| rjek | I meant to communicate that it does support them and that is good, and that GitLab does not support them which is bad. | 17:25 |
| jmacs | Right. | 17:25 |
| rjek | But it's been a long hot day and my brain may be turning to goo | 17:25 |
| *** toscalix has quit IRC | 17:37 | |
| *** locallycompact has quit IRC | 17:43 | |
| *** tiagogomes has quit IRC | 18:16 | |
| *** rdale has quit IRC | 18:28 | |
| robtaylor | perryl: loving the bomb-drop ;) | 21:02 |
| * robtaylor gets the popcorn | 21:02 | |
| rjek | Haha | 21:05 |
| * rjek replies suggesting gogs and Launchpad | 21:05 | |
| SotK | launchpad++ :D | 21:05 |
| *** edcragg has quit IRC | 21:08 | |
| rjek | Obviously Baserock did be reworked to use bzr, as unlike git it has a user interface. | 21:25 |
| *** franred has quit IRC | 22:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!