*** saneax is now known as saneax-_-|AFK | 00:40 | |
*** jamielennox is now known as jamielennox|away | 00:41 | |
jeblair | jlk: your request for early review is entirely reasonable, and i'd like to help. but as i try, i'm honestly not sure how to proceed. i can do a half-assed review and say "yes/no good/bad general direction" and then do a real review later where we change all kinds of interfaces, etc (and i may still be wrong). or i can do a real review which involves a major context switch and time investment. | 00:42 |
---|---|---|
*** jamielennox|away is now known as jamielennox | 00:44 | |
jeblair | jlk: i don't feel like we have achieved enough forward progress on the major milestones which are ahead of the github milestone to be able to afford doing that at this point. | 00:45 |
jeblair | jlk: i can't see a cursory review being helpful. you're likely to just get upset that i'm not being consistent. :) | 00:51 |
jeblair | i've just spent 30 minutes reviewing the first one and have only gotten as far as determining i need to spend more time on it. | 00:54 |
jeblair | my hope was that you would be able to do the bulk of the porting work now, and then once we cleared out more of the work ahead of it, we'd both have time to dig into refining the series. | 00:57 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Re-enable test_tags https://review.openstack.org/439858 | 01:25 |
*** Wei_Liu has joined #zuul | 02:08 | |
SpamapS | jeblair: deerrrrppp.. I totally forgot about example.* in rfc2606 .. sorry.. it's a knee jerk to see names in urls. :-P | 02:29 |
SpamapS | jeblair: and regarding py3 stuff.. I wonder if we can get a non-intrusive way to start running a subset of the tests for py3. I have some pretty minimal patches that got a couple of the unit test suites to pass. | 02:30 |
SpamapS | just to start preventing backsliding | 02:30 |
SpamapS | because I'd definitely prefer /usr/bin/python3 as the linter in this case. :) | 02:30 |
*** Wei_Liu has quit IRC | 02:31 | |
*** abregman_ has joined #zuul | 06:33 | |
openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Change mutex to counting semaphore https://review.openstack.org/442563 | 06:43 |
*** saneax-_-|AFK is now known as saneax | 07:05 | |
*** abregman_ is now known as abregman | 08:53 | |
*** openstackgerrit has quit IRC | 09:03 | |
*** hashar has joined #zuul | 09:06 | |
*** isaacb has joined #zuul | 09:08 | |
*** bhavik1 has joined #zuul | 09:23 | |
*** bhavik1 has quit IRC | 11:07 | |
*** isaacb has quit IRC | 11:44 | |
*** abregman has quit IRC | 12:58 | |
*** abregman has joined #zuul | 12:59 | |
*** abregman has quit IRC | 13:02 | |
*** abregman has joined #zuul | 13:03 | |
*** isaacb has joined #zuul | 14:02 | |
*** openstackgerrit has joined #zuul | 14:31 | |
openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool feature/zuulv3: Add 'requestor' to NodeRequest model https://review.openstack.org/443151 | 14:31 |
pabelanger | morning | 14:37 |
pabelanger | https://etherpad.openstack.org/p/zuulv3-ansible-jobs | 14:37 |
pabelanger | jeblair: Shrews: mordred: SpamapS: ^ please review my proposed email for feedback request | 14:37 |
pabelanger | related to our tox playbook(s) | 14:38 |
Shrews | pabelanger: will look in a bit | 14:38 |
Shrews | pabelanger: looks good, definitely helped me | 14:59 |
*** saneax is now known as saneax-_-|AFK | 15:04 | |
*** abregman is now known as abregman|mtg | 15:06 | |
Shrews | pabelanger: and i think i agree with mordred that, when considering what run-tox might look like after it's no longer a passthrough, the individual playbooks seem a bit better than the single playbook. And opens it up for more easily customizing things, I think. | 15:13 |
pabelanger | Shrews: right, that is what I am thinking too. | 15:14 |
Shrews | thx for the writeup | 15:14 |
jeblair | pabelanger: email lgtm. you might want to copy/paste some of that into the respective commit msgs | 15:18 |
pabelanger | jeblair: agree | 15:19 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add generic tox job (multiple playbooks) https://review.openstack.org/438281 | 15:26 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add generic tox job (single playbook) https://review.openstack.org/442180 | 15:28 |
jeblair | pabelanger: ++ | 15:37 |
pabelanger | Wow, all sorts of badness here: http://zuulv3-dev.openstack.org/logs/62edb6f2d5b64cee9369d605e5eed65c/console.log | 15:39 |
Shrews | pabelanger: wow | 15:49 |
Shrews | something eat up all the memory? | 15:49 |
pabelanger | Shrews: looks that way | 15:49 |
pabelanger | testing locally with fresh virtualenv | 15:50 |
pabelanger | to see if I can reproduce | 15:50 |
jeblair | 2017-03-08 15:37:16.099322 | [28908.424773] Out of memory: Kill process 3758 (coverage) score 443 or sacrifice child | 15:50 |
jeblair | looks like each process was about 1G each | 15:52 |
pabelanger | Ya, something looks to have changed. A recheck also fails | 16:08 |
pabelanger | the good news, is we can reproduce the issue on zuulv2.5 | 16:09 |
jeblair | that's good news? | 16:10 |
Shrews | this isn't zuulv3 specific? uh oh | 16:10 |
pabelanger | :) | 16:10 |
pabelanger | going to compare dependencies | 16:11 |
pabelanger | http://paste.openstack.org/show/601957/ | 16:14 |
pabelanger | new GitPython today it looks like | 16:14 |
pabelanger | and appdirs yesterday | 16:15 |
jeblair | i'll use old and new venvs locally and see if i can spot a memory diff | 16:16 |
jeblair | meanwhile, it may be a good idea to push up a change that experimentally pins gitpython to the previous version and see what shakes out | 16:16 |
pabelanger | k | 16:17 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: DNM: pin GitPython https://review.openstack.org/443221 | 16:19 |
jeblair | oh yep, definite increase in memory usage with a new venv compared to old | 16:20 |
mordred | jeblair: AWESOME | 16:20 |
mordred | pabelanger: that DNM may turn in to merge please rather quickly :) | 16:20 |
pabelanger | mordred: indeed | 16:20 |
Shrews | mordred: DNM means "Desperately Needs Merged" duh | 16:20 |
mordred | the commit message on 2.1.3 is amazing: https://github.com/gitpython-developers/GitPython/commit/c23ae3a48bb37ae7ebd6aacc8539fee090ca34bd | 16:22 |
mordred | I almost want to just respond to it directly | 16:22 |
pabelanger | mordred: please do! deleting things from pypi makes me sadface | 16:22 |
jeblair | mordred: please do. i hope he will appreciate learning that he has users that depend on important information like that | 16:23 |
jeblair | also, i just had to kill my test process because my workstation was swapping. | 16:23 |
jeblair | my workstation *never* swaps. | 16:23 |
jeblair | (*one* of the coverace processes was up to 16gb) | 16:24 |
pabelanger | woah | 16:25 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Cap GitPython at 2.1.1 due to memory consumption https://review.openstack.org/443221 | 16:32 |
pabelanger | capping GitPython fixes our memory issues | 16:32 |
jeblair | i'm testing out some reverts of commits with suspicous commit msgs | 16:33 |
mordred | jeblair: I'm going to guess the code in https://github.com/gitpython-developers/GitPython/compare/c823d482d03caa8238b48714af4dec6d9e476520...master in git/repo/base.py is going to be involved | 16:33 |
mordred | since it does gc things | 16:33 |
jeblair | there seemed to be at least one particular test, or smaller set of tests, that really set it off | 16:34 |
jeblair | but i don't know how to figure out what it/they were | 16:34 |
jeblair | if we could, that would be useful in producing a test case | 16:34 |
mordred | all of the rest of the changes had something to do with docs, tests or kwarg handling | 16:34 |
mordred | jeblair: ++ | 16:34 |
mordred | jeblair: so - the gc code seems to be doing something similar to what the paramiko code was doing - trying to be more explicit about memory on close or something | 16:35 |
jeblair | i reverted both bdb4c7cb5b3dec9e4020aac864958dd16623de77 and f1a82e45fc177cec8cffcfe3ff970560d272d0bf and the problem did not present | 16:36 |
jeblair | mordred: wow, did someone write a blog post on how to (poorly) muck around with python gc internals? | 16:36 |
mordred | yah- bdb4c is the one I was suspecting | 16:36 |
jeblair | mordred: i'm re-running with only that one reverted now | 16:37 |
mordred | oh - I'm sorry - I got that backwards | 16:37 |
mordred | f1a82 is the one that does it not for the test suite | 16:38 |
jeblair | oh okay, i'll let this run then try the other | 16:38 |
mordred | https://github.com/gitpython-developers/GitPython/issues/553 is the issue the commit purports to be about | 16:39 |
jeblair | there it goes -- so with only bdb4c7cb5b3dec9e4020aac864958dd16623de77 reverted we still see the problem. i'll just run with only f1a82e45fc177cec8cffcfe3ff970560d272d0bf reverted now to confirm | 16:40 |
jeblair | pabelanger: when you said this is reproducible with zuulv2.5, did you mean zuulv2.5 running tests on zuulv3, or did you mean tests running on the code in the master branch? | 16:43 |
pabelanger | jeblair: running the py27 job on both zuul.o.o and zuulv3-dev.o.o showed the same failure for the feature/zuulv3 branch | 16:45 |
pabelanger | I haven't checked master yet | 16:45 |
jeblair | pabelanger: can you please? | 16:46 |
pabelanger | sure | 16:46 |
jeblair | i'm poking around at subunit log files, and i notice that the debugging output we added to try to catch the gitpython leak problem is outputting *a lot* of data. it's possible the oom is triggered by that debug output. | 16:46 |
pabelanger | recheck of 442533 underway | 16:47 |
jeblair | i mean, there's still a lot of unknowns there (why did we suddenly start seeing gitpython object leaks about a week ago, and why did the new release seem to make it a certainty). | 16:47 |
jeblair | mordred: confirmed that reverting f1a82e45fc177cec8cffcfe3ff970560d272d0bf only fixes the problem | 16:48 |
mordred | jeblair: cool. so, that's at least some information | 16:48 |
jeblair | i'm running with gitpython 2.1.3 now but without the insane gc logging in zuul's tests | 16:49 |
mordred | jeblair: looking further at the change, there are two changes in place there - one is adding context manager and an explicit close method so that what was the contents of __del__ will get called in context manager context but also let someone do an explicit cllose- this seems perfectly innocuous | 16:52 |
mordred | jeblair: but the other change is adding two calls to gc.collect() on either side of a call to gitdb.util.mman.collect() | 16:53 |
pabelanger | jeblair: no kernel traces on master, but jobs did fail still. Doesn't appear related to OOM | 16:54 |
pabelanger | http://logs.openstack.org/33/442533/1/check/zuul-coverage-ubuntu-xenial-nv/37bb728/console.html | 16:55 |
mordred | jeblair: I betcha that http://paste.openstack.org/show/601965/ is actually the revert that will make it go away | 16:55 |
mordred | in the mman.collect() call is this comment: | 16:58 |
mordred | .. TODO:: | 16:58 |
mordred | implement a case where all unusued regions are discarded efficiently. | 16:58 |
mordred | Currently its only brute force | 16:58 |
jeblair | we've had a problem in the past with zuul leaking gitpython git.Repo objects. so we added a check at the end of every unit test that calls gc.collect and then gc.get_objects to make sure that there are no git.Repo objects in memory. | 16:59 |
jeblair | that hadn't produced any errors in, idunno, years | 17:00 |
jeblair | last week a couple started popping up, which seemed really weird, so i added some more debugging to try to figure out what the references are. that produces a lot of output. but since merging that change, we haven't seen the errors again. | 17:01 |
jeblair | it does seem that it's the debugging output that causes the oom condition -- probably because of all the debug logging going into memory. | 17:01 |
jeblair | when i remove the extra debugging and run with gitpython 2.1.3, i don't get ooms, but i do consistently get a lot of tests failing the gc reference count check | 17:02 |
jeblair | so it seems like the change in 2.1.3 causes zuul to leak git.Repo objects reliably | 17:03 |
jeblair | (there are 225 instances of "Leaked git repo object" in the test output) | 17:04 |
mordred | jeblair: I cannot explain that from reading the code | 17:06 |
*** hashar has quit IRC | 17:06 | |
jeblair | mordred: where's mman.collect? | 17:06 |
mordred | in https://github.com/gitpython-developers/smmap | 17:06 |
mordred | jeblair: in smmap/mman.py | 17:06 |
mordred | jeblair: I have not dived too deeply into the crack that's in there - although I will say that implementing your own lru mmap in python seems like a choice _I_ wouldn't choose | 17:09 |
jeblair | mordred: hrm, i wonder if the additional gc.collect calls are pushing git.python objects into higher generations and so ours isn't actually running on them | 17:10 |
jeblair | (it's not clear to me what the behavior is for gc.collect() with no arguments) | 17:10 |
jeblair | i guess "full collection" means run on all the generations? | 17:11 |
mordred | maybe? | 17:12 |
jeblair | also, i'd really like an analysis of why they think they need to run a full gc sweep twice every time a repo object is closed | 17:12 |
jeblair | we close repo objects *all the time* | 17:12 |
mordred | yah | 17:12 |
mordred | that seems super extra expensive | 17:12 |
jeblair | like, many times in a single repo update, because gitpython is poor at dealing with files changed out from under it -- even if *it* caused those files to change. | 17:13 |
jeblair | (run git remote update; get a new repo object; run git fetch; get a new repo object... etc) | 17:13 |
mordred | yah | 17:14 |
jeblair | mordred: i'm going to poke at that 3 line patch and see what makes things change | 17:15 |
mordred | jeblair: k. | 17:17 |
mordred | jeblair: I give even odds on it being the call to the mman.collect | 17:17 |
*** bhavik1 has joined #zuul | 17:18 | |
*** abregman|mtg has quit IRC | 17:24 | |
jeblair | first i'm going to spend a few minutes trying to find a smaller test case | 17:27 |
*** bhavik1 has quit IRC | 17:35 | |
jeblair | mordred: hrm, in issue 553, he says you have to call gc.collect before calling clear_cache, but that's not what the patch does | 17:55 |
mordred | oh - interesting | 17:56 |
jeblair | (though, i mean, i still think "you have to call gc.collect before..." is probably wrong, or at least needs some real justification) | 17:56 |
mordred | yah | 17:57 |
jeblair | i can't get a smaller test case. the leaked object detection only seems to be happening when i run the full test suite in parallel | 17:59 |
mordred | jeblair: JOY | 18:01 |
jeblair | (at some point, it would probably be a good idea to remove our leak detection and then time the test run with and without the change to gitpython to see how much the extra gc calls cost) | 18:01 |
mordred | ++ | 18:03 |
jeblair | oh, i just had a thought | 18:03 |
jeblair | it's possible i'm seeing a bunch of leaked objects *because* the tests run slower and are timing out | 18:03 |
mordred | jeblair: oh! yeah | 18:04 |
jeblair | yeah, i see a lot of correlation with test timeouts. so, erm, i guess i will perform that benchmark now. :) | 18:06 |
jeblair | mordred: i ran *one* test with and without that 3 line patch. 6.7s vs 24.2s. | 18:07 |
mordred | jeblair: WOW. at the very least, it would be nice if maybe we could get a Repo constructor option that would skip the three collect calls on every close | 18:08 |
mordred | I'd love to understand more why it's needed - but if the upstream devs can't explain that, then a get-out-of-jail-free card might be nice :) | 18:08 |
jeblair | mordred: the mman.collect doesn't seem to have much of an effect. it's the gc calls. | 18:09 |
jeblair | mordred: i think maybe we have enough to file a bug now? | 18:11 |
Shrews | pabelanger: in the current nodepoold, the updateStats() call for node counts is called in several different places, some of which won't be relevent in the new system. The zuulv3 relevent ones are at node launch time and node deletion. It's called twice at node deletion for whatever reason. I'm having difficulty figuring out exactly how often updateStats() should be called in the new system. Does it necessarily | 18:14 |
Shrews | need to be immediately when nodes are created/deleted, or can it be more periodic? | 18:14 |
Shrews | I guess I'm wondering if those data points need to be recorded so closely to node changes, or can should we spread out the data points a bit. | 18:16 |
jeblair | Shrews: the intent is to be as close to real-time as possible (in openstack-infra, we have a 10s resolution) | 18:18 |
pabelanger | Ya, keeping it close to realtime would be my preference | 18:19 |
Shrews | ok. fwiw, i've written this change twice now because i haven't been happy with how it turned out. i might try one more way to see how i like it. | 18:21 |
jeblair | Shrews: if the concern is needing to query zk for the gauges (the counters should basically be free), having that be somewhat periodic is probably okay; but an interval measured in seconds would still be ideal. | 18:21 |
Shrews | jeblair: that was one concern (since each provider thread is going to be querying zk for the counts), but it may not be so bad since nodes can only be created/deleted so quickly | 18:23 |
*** isaacb has quit IRC | 18:27 | |
jeblair | mordred: https://etherpad.openstack.org/p/3BnandNi86 how's that look? | 18:30 |
jeblair | mordred: (also, do i need to do any github magic to make the commit sha link?) | 18:31 |
jlk | jeblair: that's perfect feedback, and certainly a good direction to go in. | 18:34 |
mordred | jeblair: looking | 18:43 |
mordred | jeblair: yah - I agree - I think it's a good bug | 18:44 |
mordred | jeblair: I've also got a patch that would add a get-out-of-jail constructor argument, should we decide we desire such a thing | 18:45 |
*** adam_g has quit IRC | 18:46 | |
*** adam_g has joined #zuul | 18:47 | |
jeblair | https://github.com/gitpython-developers/GitPython/issues/605 | 18:55 |
jeblair | mordred, pabelanger: i think we should pin to <2.1.2 until that's resolved | 18:55 |
jeblair | i'll update pabelanger's change to reference that in the commit msg | 18:56 |
pabelanger | wfm | 18:56 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Cap GitPython at 2.1.1 due to performance degradation https://review.openstack.org/443221 | 18:57 |
jeblair | apparently github permits me to express my reaction to that issue. i don't see an icon that looks appropriate for "shock". | 18:59 |
mordred | jeblair: oh fun - have you read the readme at https://github.com/gitpython-developers/smmap ? | 19:16 |
mordred | "System resources (file-handles) are likely to be leaked! This is due to the library authors reliance on a deterministic __del__() destructor." | 19:16 |
mordred | jeblair: also - https://github.com/gitpython-developers/smmap/pull/33 is potentially worth being on our radar | 19:18 |
jlk | speaking of radar | 19:21 |
jlk | mordred: https://github.com/ansible/ansible/pull/22281 this may be of some interest | 19:21 |
openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Remove ubuntu-precise from AFS mirror list https://review.openstack.org/443295 | 19:24 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Allow using webapp from connections https://review.openstack.org/439831 | 19:30 |
mordred | jlk: yah - I was looking at that the other day | 19:33 |
jlk | I gave it a cursory once-over, but seems vaguely similar to our problem | 19:33 |
jlk | If we get our talk accepted to AnsibleFest, it'd be worth mentioning this effort. | 19:33 |
mordred | jlk: yah - it's similar but I think possibly opposite in some ways ... that said, we should likely talk to those people and figure out where we might be able to store common ground | 19:34 |
mordred | jlk: (for them, it's easy to restrict playbook content, which is the thing we can't do) - but I think the list of restrictions and unsafe thigns you want to prevent would likely be pretty much the same | 19:34 |
jlk | yup | 19:35 |
mordred | I like bcoca's first response | 19:35 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Support GitHub PR webhooks https://review.openstack.org/439834 | 19:37 |
mordred | jlk: thanks - I responded to that pr | 19:41 |
openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Check if /etc/apt/apt.conf.d first exists https://review.openstack.org/443302 | 19:41 |
mordred | jlk: do you think that returning the package list in a fact for the bindep module is the right thing to do? or should we just return values and have people do register? | 19:50 |
mordred | jlk: (I was just doing your suggestion of making an example of feeding to package) | 19:50 |
mordred | jlk: pushed updates | 19:56 |
jlk | Register probably, as it seems like a strange thing to pollute the fact space with? dunno. | 20:11 |
mordred | yah | 20:17 |
pabelanger | left a comment, but list and register is fine with me | 20:19 |
jlk | huh, why are we getting OOM in tests? | 20:19 |
pabelanger | unless we want to get fancy and have the bindep task pip it into the package task | 20:19 |
pabelanger | jlk: ya we have a workaround | 20:20 |
pabelanger | mordred: jlk: https://review.openstack.org/#/c/443221/ | 20:20 |
pabelanger | mind a review | 20:20 |
jlk | oh taht. | 20:20 |
jlk | I already reviewed | 20:20 |
mordred | jlk: +A | 20:20 |
jlk | don't have those rights :( | 20:20 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: Cap GitPython at 2.1.1 due to performance degradation https://review.openstack.org/443306 | 20:21 |
jlk | (I don't think I should either yet) | 20:21 |
mordred | gah | 20:21 |
mordred | pabelanger: +A I mean | 20:21 |
pabelanger | master patch^ | 20:21 |
pabelanger | mordred: danke | 20:21 |
mordred | jlk, pabelanger: ok. I updated the PR to not use facts - and it now includes an appropriate example | 20:23 |
jlk | there. | 20:24 |
jlk | whoh, github now has a "changes since you last looked" button type thing | 20:24 |
jlk | and it seems to show the right stuff | 20:24 |
mordred | oh neat | 20:24 |
pabelanger | mordred: Yay, already have a role lined up to use it | 20:25 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Cap GitPython at 2.1.1 due to performance degradation https://review.openstack.org/443221 | 20:27 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Allow using webapp from connections https://review.openstack.org/439831 | 20:28 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Support GitHub PR webhooks https://review.openstack.org/439834 | 20:29 |
mordred | pabelanger: nice work on your reference to the issue in the zuul patch :) | 20:30 |
pabelanger | mordred: thanks, but that was jeblair who linked it\ | 20:31 |
mordred | oh - so it was | 20:32 |
jeblair | mordred: that was partly for our reference, and partly to ensure it ended up in the github event stream for the issue. :) | 20:48 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove extra debugging around git repo leaks https://review.openstack.org/443317 | 20:52 |
mordred | jeblair: yup. it worked | 20:52 |
*** eggshell has quit IRC | 21:05 | |
*** eventingmonkey has quit IRC | 21:05 | |
*** eggshell has joined #zuul | 21:06 | |
*** eventingmonkey has joined #zuul | 21:06 | |
*** hashar has joined #zuul | 21:08 | |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Add basic Github Zuul Reporter. https://review.openstack.org/443323 | 21:09 |
*** eggshell has quit IRC | 21:20 | |
*** eventingmonkey has quit IRC | 21:20 | |
*** eggshell has joined #zuul | 21:26 | |
*** eventingmonkey has joined #zuul | 21:27 | |
jhesketh | Morning | 21:29 |
mordred | look it's a jhesketh | 21:37 |
openstackgerrit | Merged openstack-infra/nodepool master: Remove ubuntu-precise from AFS mirror list https://review.openstack.org/443295 | 22:34 |
openstackgerrit | Merged openstack-infra/nodepool master: Check if /etc/apt/apt.conf.d first exists https://review.openstack.org/443302 | 22:36 |
jamielennox | eek, that gitpython thing is horrible, wtf is a library doing invoking python's gc? | 23:08 |
*** saneax-_-|AFK is now known as saneax | 23:21 | |
*** hashar has quit IRC | 23:34 | |
mordred | jamielennox: this is amongst today's many horrors | 23:41 |
mordred | jamielennox: if that is concerning, I recommend you definitely do not look at the library that implements an LRU mmap thing in python | 23:42 |
jamielennox | mordred: it's still morning here, don't ruin all the surprises for me | 23:42 |
jamielennox | there's a library for that? | 23:42 |
mordred | jamielennox: oh yeah | 23:42 |
mordred | jamielennox: https://github.com/gitpython-developers/smmap | 23:43 |
mordred | jamielennox: enjoy the limitations listed in the readme | 23:43 |
jamielennox | this may be obvious - but why does this exist? | 23:44 |
mordred | jamielennox: well, that's easy .... alsjdnc93w4un 0384fnoain3408nvclsairnvasr34unfvclasdna | 23:44 |
mordred | (to be fair, the gitpython library has served us well for a few years now, so it's doing an amount of tasks well - but my mind definitely boggles when I see smmap and gc.collect() in a library) | 23:45 |
jamielennox | so we're looking at the libgit2 bindings or going to limp it through a while | 23:46 |
jamielennox | ? | 23:46 |
mordred | we've submitted a bug, and the pin to the earlier version is making this go away - so I think for now just dealing with it | 23:46 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!