| *** tristan has quit IRC | 07:13 | |
| *** tristan has joined #buildstream | 07:18 | |
| *** ChanServ sets mode: +o tristan | 07:18 | |
| *** benschubert has joined #buildstream | 07:34 | |
| benschubert | Ok, for a threaded scheduler model, I am at 8 failures and 11 errors on the whole test suite. It's getting there :D | 08:02 |
|---|---|---|
| tristan | benschubert, Sounds good ! | 08:05 |
| tristan | I guess we can just go ahead with this then, but then there will be some benchmarking we should do... | 08:06 |
| benschubert | tristan: what I am not sure about is whether we want a "clean" MR, that cleans up some things more or if we want the bare minimum in and then improve? | 08:06 |
| benschubert | I'll benchmark before merging anyways :) | 08:06 |
| tristan | I have to admit that a nasty thought crossed my mind the other day | 08:06 |
| benschubert | ? | 08:06 |
| tristan | I was thinking that... this thread-scheduling looks like a lot of work, which is a blocker for native windows support, but not *really* a blocker for 2.0 | 08:07 |
| tristan | I know, pesky brain | 08:07 |
| tristan | It looks like it will be a great improvement anyway, I'll tell my brain to shut up :) | 08:08 |
| benschubert | tristan: that's true, and I know the aim is bst 2.0, but I also would really like a solid, well tested release, and these QOL improvements will probably help with that :D | 08:09 |
| tristan | Yes, you don't have to tell me, believe me my heart is with you on that :) | 08:10 |
| tristan | I just got a call from the dark side of the force that's all :) | 08:10 |
| * tristan wants to start really getting closer to 2.0, see it materialize on the horizon | 08:11 | |
| benschubert | it happens :) | 08:11 |
| benschubert | I still don't have a solution for the plugins where I'm 99% satisfied BTW, I keep moving things around | 08:11 |
| * benschubert really should site for a week and get that done | 08:11 | |
| tristan | I am thinking a september release is now completely out of the question, but if we can get feature/major change completeness by some time in september... then a 2.0 in 2020 could be a reality | 08:12 |
| tristan | Yeah the plugins is a big step | 08:13 |
| benschubert | I am doubtful around september, though that would indeed be good | 08:13 |
| tristan | I mean, december is usually mostly a bust, if you don't get your stable release out by the first days of december, it's next year | 08:14 |
| benschubert | but if we miss the september/october milestone (Fedora 33/Ubuntu 20.10) I believe the next "important" milestone would be April/May on the opensource schedule right? | 08:14 |
| benschubert | (and I don't think september/october is feasible if we want a stable release) | 08:14 |
| tristan | I'm talking about feature / "major change" completeness for around september, hopefully by the end of september | 08:15 |
| tristan | If that happens, I could see us having IRC team meetings again, and doing roll call on blockers | 08:15 |
| tristan | There are a couple of months of ironing out kinks and being truly ready, after feature completeness and before release | 08:16 |
| benschubert | ah yeah, ok seems good | 08:16 |
| tristan | Of course, this is mostly a wish statement at this point... | 08:17 |
| tristan | if we focus I think we can make it happen | 08:17 |
| benschubert | juergbi: Where you involved in the vstorage_dir tests ? https://gitlab.com/BuildStream/buildstream/-/jobs/610202063 When run in randomized order there are a few failures and I am not sure what's the real cause. Would you have an idea? | 08:17 |
| benschubert | tristan: true | 08:18 |
| juergbi | I wasn't involved in writing the original test, although I think I have tweaked or extended it since then | 08:18 |
| juergbi | don't know otoh, can maybe take a look later | 08:19 |
| benschubert | sure, thanks | 08:19 |
| tristan | FWIW, the way I would see this fitting into the upstream world schedules is that, after stable is released (near close of 2020), this lets upstream projects start moving their master branches to use BuildStream 2, which would mean stable apps, runtimes, demo bootable images etc, around next summer, all using bst 2 | 08:19 |
| juergbi | a propos bst 2.0 blockers, I'm making progress on the Remote Asset API front. initial push and pull of artifacts seems to work | 08:20 |
| juergbi | (but still a lot to do) | 08:20 |
| benschubert | juergbi: that's awesome, I'm looking forward to my first build without any git checkout :D | 08:20 |
| tristan | Awesome | 08:20 |
| benschubert | tristan: true, there is more than "just" having bst2 in distributions | 08:20 |
| juergbi | benschubert: well, full integration into the sources with the corresponding plugin API extensions/changes is a whole other step | 08:21 |
| tristan | heh | 08:21 |
| juergbi | first priority is moving from buildstream-specific protocol to remote asset API without changing the architecture | 08:21 |
| juergbi | (much) | 08:21 |
| benschubert | ah gotcha | 08:22 |
| tristan | So... the controversial topic, what about pulling the trigger on nuking the ability of plugins to write directly into the sandbox ? | 08:22 |
| benschubert | tristan: I still need to write an answer to the ML thread, but still need to finish reading it and look at all the plugins | 08:22 |
| juergbi | I have to read some more on that thread | 08:22 |
| benschubert | I should have an answer today/tomorrow | 08:23 |
| tristan | And, should we also remove a couple of APIs like... Element.set_public_data() and Element.get_variable() ? | 08:23 |
| tristan | benschubert, I recommend this specific post: https://lists.apache.org/thread.html/r5af5f67b392ca5036f16f7ee2f33018f032d2615a8d5f814357d62df%40%3Cdev.buildstream.apache.org%3E | 08:23 |
| tristan | benschubert, I took a long time yesterday trying to compose that, I think it's got a clear compelling argument | 08:24 |
| tristan | The rest of the thread, read it but, it may be confusing to follow | 08:24 |
| benschubert | tristan: I'll read everything through | 08:24 |
| benschubert | one question that I haven't seen answer while skimming through though: How would you see the 'tar' element implemented with the change? | 08:24 |
| tristan | I don't believe there is any such thing as a 'tar' element | 08:25 |
| tristan | It could be there is one, but then it should just be a script element really, which stages a build of `tar` | 08:25 |
| benschubert | which means now you need to have 'tar' available in your sandbox? What about docker, now you need buildah/tar again? (Just trying to get your whole view there :) ) | 08:26 |
| tristan | Yes - there should absolutely never be any data manipulation outside of the sandbox | 08:27 |
| tristan | Docker (or the 'oci' element), is one of the biggest offenders of this rule | 08:27 |
| tristan | It's build is entirely non-deterministic, and as a result, it's output is hopelessly non-reproducible | 08:28 |
| benschubert | the docker element is deterministic, if you run it twice your tar will even have the exact same sha | 08:28 |
| benschubert | *image not tar | 08:28 |
| tristan | Is that different from the oci element ? | 08:29 |
| benschubert | I have not look at the code of the oci element | 08:29 |
| tristan | And what about if you run it multiple times, each time with different hosts and different versions of python ? | 08:29 |
| tristan | Where is docker | 08:29 |
| tristan | Does it at least stage docker in a sandbox ? | 08:29 |
| tristan | I believe it should | 08:29 |
| benschubert | https://gitlab.com/BuildStream/bst-plugins-container/-/blob/master/src/bst_plugins_container/elements/docker_image.py | 08:29 |
| benschubert | this is what it does | 08:29 |
| benschubert | which would not be possible under the new changes :) | 08:30 |
| tristan | benschubert, definitely, that needs a rewrite | 08:30 |
| tristan | That has to happen all inside the sandbox | 08:31 |
| tristan | It is a terrible mistake that that was allowed to happen in the first place | 08:31 |
| tristan | Host python tarfile.open( ... ) manual python host manipulation, putting files in the sandbox | 08:31 |
| tristan | Defeats the purpose of using BuildStream in the first place | 08:32 |
| tristan | If you wanted that, you could use `bst artifact checkout --tar > file.tar` in a script with host docker or such | 08:32 |
| tristan | the oci plugin does similar | 08:33 |
| benschubert | I would agree if it was running arbitrary code, but given what is doing it's very similar to a "source" plugin in what it bring? (anywyas I'll answer on the ML once I'm all caught up) | 08:33 |
| tristan | It is running arbitrary code, it's running tarfile.open() on host python | 08:33 |
| tristan | Also, even if it happened to run code which was guaranteed by all upstreams involved to produce deterministic results, regardless of host of version of python/tool etc... the base principle of BuildStream is to assume that such guarantees cannot be made | 08:35 |
| tristan | The tooling used to produce output is considered a part of the input | 08:35 |
| tristan | s/of host of version of python/of host or version of python/ | 08:36 |
| *** santi has joined #buildstream | 08:46 | |
| tristan | valentind, the node passed to Variables() is never composited after being given to the Variables() constructor right ? | 09:43 |
| tristan | Or is it mutable ? | 09:43 |
| tristan | If we were to change the constructor to copy the passed node, everything would still work ? | 09:43 |
| valentind | Yes it would still work. | 09:44 |
| tristan | Ok, yeah some grepping shows we only ever use it once in Element | 09:45 |
| tristan | So it's just that in the case of junctions, things do not *have* to be fully resolved, only the things which the junction asks for has to be resolved | 09:46 |
| * tristan is not sure why Variables implements __getitem__ | 09:48 | |
| tristan | maybe it's a part of the current recursion | 09:49 |
| tristan | I think there are some wrong comments in this variables code :-S | 09:55 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_variables.pyx#L243 | 09:56 |
| tristan | Why on earth would it be useful to preserve "foo" and "baz" from that example string ?? | 09:57 |
| tristan | whoa, this appears terribly broken :-S | 10:02 |
| tristan | benschubert, can you tell me what the API documenting comment should be for _expand_expstr(): https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_variables.pyx#L300 ? | 10:03 |
| tristan | it seems to have a copy/pasted doc comment from _expand_var() | 10:04 |
| tristan | and it's unclear what it's purpose is | 10:04 |
| tristan | I think I get it, but... it's quite wrong | 10:05 |
| tristan | Ok... so basically, this takes the full list of values with any %{...} delimiters stripped, and treats each item as if it were a variable name, attempting to do an unconditional substitution on all text, and then joins them together | 10:06 |
| tristan | Gotcha | 10:06 |
| tristan | benschubert, The current code will expand "prefix%{prefix}" as "/usr/usr" instead of correctly expanding it as "prefix/usr" | 10:07 |
| tristan | At least, that's my prediction from a reading of it | 10:07 |
| benschubert | tristan: let me have a look | 10:12 |
| benschubert | No | 10:12 |
| benschubert | The way it works here, is the list value ["x", "y", "z"] has this formt https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_variables.pyx#L243, which means that every even (0, 2, ...) indices are normal values, that should be taken directly, and every odd indices get expanded | 10:14 |
| benschubert | You can see line 310 the handling for even indices and line 314 the handling for odd ones | 10:14 |
| benschubert | that probably needs better documenting | 10:15 |
| benschubert | https://gitlab.com/BuildStream/buildstream/-/commit/8ae5e115a4693ff33248278f5702614ff6f3abee#135c57f9ad9406691ef175d76fc8ddcb09c4238d_289_319 was the previous comment which was more correct but not better | 10:17 |
| benschubert | I actually missed that comment misplace during the CR | 10:17 |
| benschubert | Does that make sense? | 10:18 |
| abderrahim[m] | benschubert: since you're working on the scheduler, it would be nice if you could take a look at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1970 (especially to avoid conflicts) | 10:18 |
| abderrahim[m] | juergbi: what are you using as a server for remote-asset? I didn't manage to find a server implementation | 10:19 |
| * abderrahim[m] also wants to weigh in on the virtual directory thread but didn't get around to reading it | 10:20 | |
| juergbi | abderrahim[m]: I added prototype code to buildbox-casd for remote asset support and then added a proxy for that part to bst-artifact-server as well | 10:20 |
| benschubert | abderrahim[m]: oh nice! I'll add this and review today thanks! | 10:21 |
| abderrahim[m] | juergbi: ah, please ping me when you have a public branch | 10:21 |
| juergbi | will do | 10:22 |
| coldtom | i believe https://github.com/buchgr/bazel-remote has an experimental server implementation of the remote asset api too fwiw | 10:22 |
| abderrahim[m] | coldtom: it only implements Fetch and only fetches single files AFAICT | 10:23 |
| juergbi | yes, we also need push | 10:23 |
| tristan | Hmmm, even and odd indices ?? | 10:23 |
| tristan | Lemme take a look at this closer | 10:24 |
| benschubert | tristan: in the 'value' list | 10:24 |
| benschubert | if you look at the while loop, we iterate through elements 2 by two | 10:24 |
| benschubert | because we handle each one differently | 10:24 |
| tristan | whoa | 10:24 |
| benschubert | probably needs better comments | 10:25 |
| tristan | SPLITTER.split("%{foo}%{bar}baz") -> ['', 'foo', '', 'bar', 'baz'] | 10:25 |
| tristan | Indeed, talk about some black magic voodoo hiding out in there | 10:25 |
| benschubert | yep... | 10:25 |
| tristan | So only even indices represent matches, is that it ?? | 10:25 |
| benschubert | I'm not the one who came up with that, but it actually is around the fastest we can go | 10:25 |
| benschubert | even are exact values that we take, odd are variables we need to expand | 10:26 |
| tristan | crazy | 10:26 |
| benschubert | and efficient :/ | 10:26 |
| benschubert | If you have an idea for a more maintainable and as fast approach I'm all for it though :) | 10:27 |
| tristan | I was thinking of a datatype to store the results instead of a list, but that only adds overhead | 10:27 |
| tristan | e.g. a list of strings with a list of indices which are variables | 10:28 |
| benschubert | tristan: we're in full cython, we could do a struct or something, or special "classes" for variables and have a __str__ defined on them | 10:28 |
| benschubert | might not be as fast, but could be pretty close | 10:28 |
| tristan | I don't think we need __str__ (that might just make things look more "magic" rather than explicit like plain C code), but having a type to represent this list could help | 10:29 |
| benschubert | yep | 10:30 |
| tristan | cdef class ExpandedString(): ... cdef list words; cdef list variable_indices; | 10:31 |
| tristan | I wonder if that would add much overhead | 10:31 |
| benschubert | tristan: the best way to know is to experiment :D | 10:32 |
| benschubert | thanks to valentind we have a good project for testing variables now | 10:32 |
| benschubert | should we actually have it somewhere as a test in BST? to ensure that some of it is correct and htus be able to also use it for performance | 10:32 |
| tristan | We could keep the knowledge of this even/odd nonsense in the same function that does the re.split() | 10:32 |
| benschubert | and remove the 'empty' entries | 10:33 |
| tristan | We should have it in the benchmarks repo, and finally finish the work in the benchmarks repo | 10:33 |
| benschubert | yeah | 10:33 |
| tristan | We still havent integrated any CI of it | 10:34 |
| benschubert | there is a lot of different benchmarking efforts that went and did things without pyshing towards a common thing | 10:34 |
| tristan | But I don't want to have performance measurements in the test suite | 10:34 |
| benschubert | ah I did not mean that :) | 10:34 |
| tristan | Yeah anything that tests correctness belongs in the test suite | 10:34 |
| benschubert | I wonder if we should reset and start the benchmarking from scratch or something | 10:34 |
| tristan | But I don't know what is missing in that regard | 10:34 |
| tristan | I've considered that for a time | 10:35 |
| benschubert | and then we do: words.copy(); for index in variable_indices: replace(workds[index]), return "".join(words) | 10:35 |
| tristan | But I've been doing other work | 10:35 |
| tristan | I really want to use the logger, nanosecdond precision and log parsing for benchmarks | 10:35 |
| benschubert | I'd say let's postpone the benchmarking until we get the scheduler right, the plugins test sorted and the few other "big" chunks of work and come back to it later? | 10:35 |
| tristan | do discrete measurements of targetted operations | 10:36 |
| benschubert | Is that really what we want? I'm more interested in E2e timings | 10:36 |
| tristan | I want to know about how much it costs to do a given routine by data set | 10:36 |
| tristan | Like if we have many elements, is our performance linear ? | 10:37 |
| benschubert | true | 10:37 |
| benschubert | we'd need to decide on some datasets too | 10:37 |
| tristan | To do that, I want to chop off irrelevant timings from the calculation | 10:37 |
| tristan | So I would not count the time it takes to say, import pkg_resources | 10:37 |
| tristan | I want to know specifically how much time it takes to check for circular references in the load cycle, not counting the load cycle | 10:37 |
| tristan | For large and small datasets, and compare | 10:38 |
| tristan | This is dead easy to do | 10:38 |
| benschubert | this doesn't need to use the `bst` command line though | 10:38 |
| benschubert | we can actually do it inside | 10:38 |
| tristan | I've been given like 3 different resources over the years, had sessions in which I explained what needed to be done to achieve this, and every time, the whole thing just falls flat on it's face and said resource ends up working on something else | 10:38 |
| tristan | benschubert, I think it would be easier (and more correct) to use `bst` though | 10:39 |
| tristan | Also I think that leveraging the logger (with specially configured log output, as our userconfig allows), would yield true results | 10:39 |
| tristan | i.e. we reduce the observer effect as much as possible | 10:40 |
| tristan | by not adding additional instrumentation codepaths | 10:40 |
| tristan | or reducing them | 10:40 |
| tristan | Since we already have the logger in play unconditionally, we should use that | 10:40 |
| benschubert | tristan: there are multiple things at stake here: | 10:40 |
| benschubert | - Timings of specific operations, that is for micro benchmarking, you'll likely want to repeat the operation many times and such. This is usually better done inside the code directly and not the cmdline | 10:40 |
| benschubert | - Timings of e2e, this is macro benchmarking and you get different information from each | 10:40 |
| benschubert | Nah, using the logger is the worse thing possible for benchmarks | 10:40 |
| benschubert | I have timing more than 5 times longer using the logger vs dumping everything to /dev/null for macro benchmarking of buildstream | 10:41 |
| tristan | We should be able to work with that | 10:41 |
| tristan | benschubert, We could keep the log in RAM, we could allow configuration of the logger to avoid logging anything we don't care about for the purpose of the benchmark, etc | 10:42 |
| benschubert | which is easier done when importing the code directly, so you don't have to change too much of BuildStream user code for this | 10:42 |
| tristan | If we had stable API for this, we could observe differences over the years | 10:43 |
| tristan | Always show the load time/cyclic dependency check time, etc... for small/medium/large datasets, for 2.0, 2.2, 2.4, 2.6 | 10:43 |
| benschubert | That's much trickier | 10:44 |
| tristan | And render pretty graphs | 10:44 |
| benschubert | that's irrelevant | 10:44 |
| benschubert | you don't want to keep the same kernel version, hardware, python version for the benchmarking over time | 10:44 |
| tristan | Well, I want to always see a graph of the last stable 2 releases + master | 10:44 |
| tristan | At all times, without having to run the benchmarks myself | 10:44 |
| tristan | The "current report" | 10:44 |
| benschubert | why would I be interested in python 3.6 timings when I'm using python3.9? | 10:44 |
| tristan | Crap, python | 10:44 |
| benschubert | python3.8 is >20% faster than python3.6 on my benchmarks | 10:45 |
| tristan | for the latest 2 stable versions, we could use the same version of python at least ? | 10:45 |
| benschubert | ubuntu 20.04 with python3.8 is >10% faster than ubuntu 19.10 with python3.8 for my benchmarks | 10:45 |
| tristan | Of course you'd want dedicated hardware for the runner which does the benchmarking | 10:45 |
| benschubert | Yeah | 10:45 |
| tristan | But yeah, you definitely want to compare versions, unfortunately fast moving python makes this window small | 10:46 |
| benschubert | what I'm saying is, there are different levels of benchmarks that are interesting. for 'trends' over time, macro benchmarks through `bst` are easier and better and more stable, for debugging and trying to optimize, micro benchmarks are better | 10:46 |
| tristan | I would say that debugging is profiling | 10:47 |
| benschubert | but what do you profile? :) | 10:47 |
| tristan | benchmarking is categorizing operations and observing trends | 10:47 |
| benschubert | I can tell you that if you profile the variable expansion, it will seem a big part of the work, whereas in reality, it's not | 10:47 |
| tristan | When I see that for instance, resolving cyclic references is becomming exponential rather than linear, then I'll do profiling | 10:47 |
| tristan | in order to fix it and address the benchmarks | 10:48 |
| tristan | I definitely want the benchmarks to tell me *which part* of BuildStream is slow | 10:48 |
| tristan | Not just "Oh damn, this `bst build` command got slower" | 10:48 |
| benschubert | > I definitely want the benchmarks to tell me *which part* of BuildStream is slow | 10:49 |
| benschubert | Yes, but you probably don't want that for the last 4 years. If you want to optimize, you want the current version and maybe 1-2 other points in the recent past | 10:49 |
| tristan | If I see that a certain part of BuildStream is becoming slow, I can then see that it's a problem and I can profile that part | 10:49 |
| tristan | benschubert, Right, that's what I mean latest 2 stable releases | 10:49 |
| tristan | On say, a 6 month schedule | 10:49 |
| tristan | But I don't want just "bst build" | 10:49 |
| tristan | I want a good handful of measurements in addition to "bst build" | 10:49 |
| benschubert | again I don't disagree with that | 10:50 |
| tristan | Anyway, nobody did it, and I don't think we have time :( | 10:50 |
| benschubert | what I'm saying is that if you wnat ot benchmark the whole loading pre-scheduler, you'll be much better off having targeted benchmarks than things through `bst build` | 10:50 |
| tristan | Hammering it in so that it sticks is probably a month of work for a single developer | 10:51 |
| benschubert | and then affects each run | 10:51 |
| tristan | Maybe less for a very simple implementation which has about 10% of the information I want to see | 10:51 |
| benschubert | tristan: my worry is that if we have this benchmarking information + profiling information already in place, things will get slower for _no gain to the user_ | 10:52 |
| benschubert | and thus we should keep this separate | 10:52 |
| tristan | benschubert, That's why I think we should have conditional logging statements and make that first class | 10:52 |
| benschubert | well, that's again a runtime cost | 10:52 |
| tristan | We should be able to tell the logger to not print anything except for "these specific start/stop messages" | 10:52 |
| benschubert | the profiling check we have in place do have a measurable (though small) impact on the speed of buildstream | 10:53 |
| tristan | A single branch statement for a few hot codepaths should not be that expensive | 10:53 |
| benschubert | do we _really_ want to add more of those? | 10:53 |
| benschubert | tristan: let's park this for now? In the end if we _do_ get an efficient, easy to maintain benchmarking setup in that I'd be fine. I will be picky on not affecting users though :) | 10:55 |
| tristan | benschubert, Honestly, I've been wanting a more fancy `--debug` option too for a very long time and never got around to it, it would probably be similarly expensive | 10:56 |
| tristan | e.g. it would be nice to say `--debug "core-topic1:core-topic2:element(compose):source(git)"` | 10:57 |
| benschubert | tristan: I like this idea and think it is worth it, as it's also good for users :) | 10:57 |
| benschubert | might need to cythonize part of that if we want | 10:57 |
| tristan | And only have Plugin.debug() messages from the compose element, git plugin, and core debugging statements issued when debug("core-topic1", message...) was called | 10:57 |
| tristan | You would have a one time parse at the beginning, reducing it to bits or booleans | 10:58 |
| tristan | with a mapping, of course you would not use string compares at runtime | 10:58 |
| tristan | But anyway, this would be as costly as adding a few conditionals for benchmarking (and could even be implemented with the same framework) | 10:59 |
| benschubert | tristan: that could be also easily cythonized to have it _real fast_ if we have performance problem afterwards | 10:59 |
| tristan | But yes, agree about parking it - because nobody is going to do the work :'( | 10:59 |
| benschubert | and again: In the end if we _do_ get an efficient, easy to maintain benchmarking setup in that I'd be fine. I will be picky on not affecting users though :D | 10:59 |
| tristan | Weird, so cython is not very strict, you can define the types of variables you intend to use in a scope, but... you don't have to ? | 11:11 |
| benschubert | tristan: correct. Defining them means they'll be C variables when possible (strings, int, etc), otherwise it will default to PyObject, which is the least efficient | 11:15 |
| benschubert | So for str, int, float, bool, list, dict, set, please always define | 11:16 |
| tristan | ok | 11:21 |
| tristan | benschubert, I was curious about https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_variables.pyx#L245 | 11:21 |
| tristan | Why 'splits' is not cdef list | 11:21 |
| tristan | But I guess it's just an oversight | 11:21 |
| benschubert | correct, and we can therefore remove the <list> 5 lines later | 11:28 |
| benschubert | if we type it | 11:29 |
| tristan | Gotcha | 11:42 |
| tristan | I think I'm getting somewhere, but I'll be interrupted by dinner | 11:42 |
| tristan | I think I can buy some performance also by using interns properly | 11:42 |
| tristan | This code appears to try to use interns to save memory, but they should be used to speed up the dictionary lookups | 11:42 |
| tristan | Hmmm, actually fairly good around that area, but I can see some gaps | 11:49 |
| tristan | anyway, on a roll with variables finally... should have a good patch tomorrow | 11:50 |
| *** tristan has quit IRC | 11:53 | |
| *** tristan has joined #buildstream | 12:06 | |
| *** ChanServ sets mode: +o tristan | 12:06 | |
| adds68 | hi, what is the default path used by te bst-artifact server? | 14:43 |
| coldtom | adds68: i think there's no default, it's just a cli arg https://docs.buildstream.build/master/using_configuring_cache_server.html#command-reference | 14:47 |
| adds68 | oh thanks coldtom :) | 14:51 |
| *** toscalix has joined #buildstream | 15:33 | |
| *** toscalix has quit IRC | 16:52 | |
| *** santi has quit IRC | 17:28 | |
| *** benschubert has quit IRC | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!