| *** Prince781 has joined #buildstream | 05:17 | |
| *** Prince781 has quit IRC | 05:27 | |
| *** Prince781 has joined #buildstream | 05:28 | |
| *** Prince781 has quit IRC | 06:11 | |
| *** coldtom has joined #buildstream | 07:49 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 08:22 |
|---|---|---|
| *** Phil has joined #buildstream | 08:34 | |
| *** jonathanmaw has joined #buildstream | 08:37 | |
| gitlab-br-bot | buildstream: merge request (jennis/output_useful_error_when_trying_to_load_directory->master: Output a useful error message when trying to load a directory) #522 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/522 | 08:46 |
| noisecell | tristan, ok, I will try to do what you suggest but I think we should think about the possibility to be able to configure the image as we would like after the compose happens without having to have the tools which modify your image inside of it. | 08:52 |
| *** bochecha has joined #buildstream | 08:59 | |
| *** brejoc has joined #buildstream | 09:20 | |
| *** brejoc has left #buildstream | 09:20 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 09:27 |
| *** dominic has joined #buildstream | 10:31 | |
| gitlab-br-bot | buildstream: merge request (phil/437-workspaces-tutorial->master: Phil/437 workspaces tutorial) #519 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/519 | 10:34 |
| * noisecell wonders if there is a way to set up ENV variables inside of the sandbox using script element and variables? | 10:59 | |
| jmac | Yes, you should be able to pass them into a sandbox | 11:00 |
| jmac | There's an environment: option in project.conf | 11:01 |
| jmac | Just looking for per-element | 11:01 |
| noisecell | per element | 11:01 |
| jmac | Yeah, same option in an element according to the documentation | 11:01 |
| noisecell | jmac, thanks! | 11:02 |
| jmac | There's an example using LD_LIBRARY_PATH on https://buildstream.gitlab.io/buildstream/format_declaring.html | 11:03 |
| jmac | I haven't tried using variables, but I'd assume they would work | 11:03 |
| noisecell | jmac, thank you very much | 11:14 |
| noisecell | that example is very helpful | 11:15 |
| *** bochecha has quit IRC | 12:03 | |
| gitlab-br-bot | buildstream: issue #451 ("Run CI on more distributions") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/451 | 12:24 |
| gitlab-br-bot | buildstream: merge request (phil/add-ubuntu-ci-job->master: .gitlab-ci-yml: Add ubuntu 18 test) #523 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/523 | 12:47 |
| *** solid_black has joined #buildstream | 13:01 | |
| gitlab-br-bot | buildstream: merge request (phil/437-workspaces-tutorial->master: Phil/437 workspaces tutorial) #519 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/519 | 13:45 |
| *** solid_black has quit IRC | 14:25 | |
| *** bochecha has joined #buildstream | 14:27 | |
| *** dominic has quit IRC | 14:31 | |
| *** Phil has quit IRC | 14:31 | |
| *** jmac has quit IRC | 14:31 | |
| *** benbrown has quit IRC | 14:31 | |
| *** tlater has quit IRC | 14:31 | |
| *** aiden has quit IRC | 14:31 | |
| *** mohan43u has quit IRC | 14:31 | |
| *** jennis has quit IRC | 14:31 | |
| *** skullman has quit IRC | 14:31 | |
| *** juergbi has quit IRC | 14:31 | |
| *** gitlab-br-bot has quit IRC | 14:31 | |
| *** pro[m] has quit IRC | 14:31 | |
| *** krichter[m] has quit IRC | 14:31 | |
| *** finn has quit IRC | 14:31 | |
| *** laurence has quit IRC | 14:31 | |
| *** awacheux[m] has quit IRC | 14:31 | |
| *** ernestask[m] has quit IRC | 14:31 | |
| *** inigomartinez has quit IRC | 14:31 | |
| *** m_22[m] has quit IRC | 14:31 | |
| *** paulsherwood has quit IRC | 14:31 | |
| *** valentind has quit IRC | 14:31 | |
| *** Demos[m] has quit IRC | 14:31 | |
| *** segfault3[m] has quit IRC | 14:31 | |
| *** asingh_[m] has quit IRC | 14:31 | |
| *** kailueke[m] has quit IRC | 14:31 | |
| *** ssssam[m] has quit IRC | 14:31 | |
| *** cgmcintyre[m] has quit IRC | 14:31 | |
| *** rafaelff[m] has quit IRC | 14:31 | |
| *** jjardon[m] has quit IRC | 14:31 | |
| *** mattiasb has quit IRC | 14:31 | |
| *** alatiera has quit IRC | 14:31 | |
| *** abderrahim[m] has quit IRC | 14:31 | |
| *** ptomato[m] has quit IRC | 14:31 | |
| *** oknf[m] has quit IRC | 14:31 | |
| *** theawless[m] has quit IRC | 14:31 | |
| *** connorshea[m] has quit IRC | 14:31 | |
| *** albfan[m] has quit IRC | 14:31 | |
| *** waltervargas[m] has quit IRC | 14:31 | |
| *** slaf has quit IRC | 14:31 | |
| *** cs_shadow has quit IRC | 14:31 | |
| *** jjardon has quit IRC | 14:31 | |
| *** csoriano has quit IRC | 14:31 | |
| *** persia has quit IRC | 14:31 | |
| *** persia has joined #buildstream | 14:32 | |
| *** csoriano has joined #buildstream | 14:32 | |
| *** jjardon has joined #buildstream | 14:32 | |
| *** cs_shadow has joined #buildstream | 14:32 | |
| *** slaf has joined #buildstream | 14:32 | |
| *** valentind has joined #buildstream | 14:32 | |
| *** ptomato[m] has joined #buildstream | 14:32 | |
| *** theawless[m] has joined #buildstream | 14:32 | |
| *** waltervargas[m] has joined #buildstream | 14:32 | |
| *** rafaelff[m] has joined #buildstream | 14:32 | |
| *** abderrahim[m] has joined #buildstream | 14:32 | |
| *** asingh_[m] has joined #buildstream | 14:32 | |
| *** connorshea[m] has joined #buildstream | 14:32 | |
| *** mattiasb has joined #buildstream | 14:32 | |
| *** kailueke[m] has joined #buildstream | 14:32 | |
| *** cgmcintyre[m] has joined #buildstream | 14:32 | |
| *** jjardon[m] has joined #buildstream | 14:32 | |
| *** alatiera has joined #buildstream | 14:32 | |
| *** segfault3[m] has joined #buildstream | 14:32 | |
| *** ssssam[m] has joined #buildstream | 14:32 | |
| *** albfan[m] has joined #buildstream | 14:32 | |
| *** Demos[m] has joined #buildstream | 14:32 | |
| *** oknf[m] has joined #buildstream | 14:32 | |
| *** paulsherwood has joined #buildstream | 14:32 | |
| *** phildawson has joined #buildstream | 14:32 | |
| *** jennis_ has joined #buildstream | 14:32 | |
| *** pro[m] has joined #buildstream | 14:32 | |
| *** krichter[m] has joined #buildstream | 14:32 | |
| *** finn has joined #buildstream | 14:32 | |
| *** m_22[m] has joined #buildstream | 14:32 | |
| *** ernestask[m] has joined #buildstream | 14:32 | |
| *** laurence has joined #buildstream | 14:32 | |
| *** awacheux[m] has joined #buildstream | 14:32 | |
| *** alatiera has quit IRC | 14:32 | |
| *** alatiera has joined #buildstream | 14:32 | |
| *** inigomartinez has joined #buildstream | 14:33 | |
| *** skullman has joined #buildstream | 14:33 | |
| *** mohan43u has joined #buildstream | 14:34 | |
| *** aiden has joined #buildstream | 14:37 | |
| *** tlater has joined #buildstream | 14:37 | |
| *** juergbi has joined #buildstream | 14:38 | |
| *** jmac has joined #buildstream | 14:40 | |
| *** benbrown has joined #buildstream | 14:40 | |
| *** dominic has joined #buildstream | 14:44 | |
| *** toscalix has joined #buildstream | 14:57 | |
| *** noisecell has quit IRC | 15:04 | |
| *** noisecell has joined #buildstream | 15:14 | |
| *** Prince781 has joined #buildstream | 15:20 | |
| *** toscalix has quit IRC | 15:21 | |
| *** Prince781 has quit IRC | 15:21 | |
| *** Prince781 has joined #buildstream | 15:24 | |
| *** tristan has joined #buildstream | 15:25 | |
| *** Prince781 has quit IRC | 15:32 | |
| *** Prince781 has joined #buildstream | 15:33 | |
| *** Prince781 has quit IRC | 15:36 | |
| *** Prince781 has joined #buildstream | 15:38 | |
| *** gitlab-br-bot has joined #buildstream | 15:38 | |
| *** Prince781 has quit IRC | 15:45 | |
| *** Prince781 has joined #buildstream | 15:47 | |
| *** Prince781 has quit IRC | 15:48 | |
| *** Prince781 has joined #buildstream | 15:51 | |
| jjardon | Hi, question about buildstream artifact management; if something is build, is the artifact pushed to the cache server immediately? or when the whole build of the project ends? | 15:51 |
| jmac | Each artifact is pushed when it is built | 15:55 |
| *** dominic has quit IRC | 15:58 | |
| *** Prince781 has quit IRC | 15:58 | |
| gitlab-br-bot | buildstream: merge request (jennis/output_useful_error_when_trying_to_load_directory->master: Output a useful error message when trying to load a directory) #522 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/522 | 15:58 |
| *** Prince781 has joined #buildstream | 16:01 | |
| *** phildawson has quit IRC | 16:32 | |
| gitlab-br-bot | buildstream: issue #446 ("Stack trace shown if you accidentially `bst COMMAND <directory>`") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/446 | 16:37 |
| gitlab-br-bot | buildstream: merge request (jennis/output_useful_error_when_trying_to_load_directory->master: Output a useful error message when trying to load a directory) #522 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/522 | 16:37 |
| valentind | tristan, one thing I need to do is make tracking automatic when needed on junctions. Otherwise we get stuck in case where we cannot even call "bst track" because it would fail before. | 16:39 |
| valentind | I am making an example of flaptak application using the include feature. And I found that problem. | 16:40 |
| tristan | valentind, hrrrrrmmmm | 16:41 |
| *** jcampbell has quit IRC | 16:41 | |
| valentind | tristan, I think the problem is junction being elements. They should have not been elements. | 16:42 |
| tristan | valentind, I think this is the current situation anyway | 16:42 |
| valentind | We already automatically fetch. What I do is automatically track as well. | 16:42 |
| tristan | Uhhh | 16:42 |
| *** jcampbell has joined #buildstream | 16:43 | |
| tristan | except that automatically fetching does not effect the input | 16:43 |
| gitlab-br-bot | buildstream: merge request (adamjones/systemd-cas->juerg/googlecas: Include systemd file examples for google-cas cache) #524 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/524 | 16:43 |
| tristan | valentind, really... projects should be revisioning their junction refs in junctions.refs at least | 16:43 |
| tristan | having the junctions.refs is what makes building gnome-build-meta a bit less annoying for the first time in that regard | 16:44 |
| valentind | Should I make this automatic tracking only when configure not inlined? | 16:44 |
| tristan | I dont think we really need to have automatic tracking | 16:45 |
| valentind | I mean when it is using with project.refs and junctions.ref? | 16:45 |
| valentind | How do you want to do then? Manually write the junction.refs file? | 16:45 |
| tristan | rather a good error informing the user that the junction references have not been resolved yet and need to be | 16:45 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-289->master: Tiagogomes/issue 289) #521 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/521 | 16:46 |
| tristan | The user should be able to get out of that undefined project situation by doing `bst track my-junction.bst` | 16:46 |
| valentind | tristan, this is the problem. | 16:46 |
| tristan | if the upstream maintainer of that BuildStream project failed to commit the reference | 16:46 |
| gitlab-br-bot | buildstream: merge request (adamjones/systemd-cas->juerg/googlecas: Include systemd file examples for google-cas cache) #524 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/524 | 16:47 |
| valentind | If I call "bst track junction.bst", it fails and tells me to call "bst track junction.bst". | 16:47 |
| tristan | valentind, tracking `my-junction.bst` should still work, though; it does not have any dependencies | 16:47 |
| valentind | tristan, sure, but then I need to disable full project loading. | 16:47 |
| tristan | That should be able to change, currently (without the includes branch), that works - if not it's pretty alarming and broke recently | 16:47 |
| valentind | And the problem is to know when I do not need to fully load it. | 16:48 |
| tristan | valentind, I thought that junctions are not allowed to have includes anyway ? | 16:48 |
| valentind | tristan, yes, but the project still needs to be fully loaded. | 16:48 |
| valentind | tristan, I could make the loading of the project lazy. | 16:48 |
| tristan | right, this dual pass thing annoys me a bit, it's certainly hard to reason about | 16:49 |
| valentind | tristan, let's say you call "bst track somejunction.bst someelement.bst". | 16:54 |
| *** coldtom has quit IRC | 16:55 | |
| valentind | We need to first do tracking of somejunction.bst. In one pipeline. | 16:55 |
| valentind | And then later we can do tracking on someelement.bst. | 16:55 |
| valentind | Because someelement.bst might be using somejunction.bst for including some file. | 16:56 |
| tristan | valentind, in that case; it's better to force the user to track only the junctions independently: Drill it into their skulls that these are junction elements are very special and different | 17:02 |
| tristan | than to automatically track, allowing the user to build anything that is not declared explicitly (like an arbitrary unspecified version of something) | 17:03 |
| valentind | tristan, could we make a special command for that? It would make it more obvious for the user. And for us, easier to know when to partially load the project. | 17:03 |
| valentind | bst junction-track junction.bst | 17:04 |
| valentind | or track-junction | 17:04 |
| * tristan feels he has to redigest and properly understand the justifications behind the partial load again | 17:04 | |
| valentind | tristan, I can explain it easily. | 17:04 |
| tristan | It has to do with options right ? | 17:05 |
| tristan | what was it again ? | 17:05 |
| valentind | We do not have any information on which order to load junctions. | 17:05 |
| tristan | the "order to load junctions" | 17:05 |
| *** jcampbell has quit IRC | 17:05 | |
| tristan | So what is that order exactly, and how is it significant ? | 17:05 |
| valentind | If we have several junctions, and we load some includes from one, then load the second junction. Or we do the opposite, we get a different behavior. | 17:05 |
| tristan | i.e. in normal cases, we recurse and load on demand | 17:05 |
| tristan | Hmmmmmmmm | 17:06 |
| tristan | I'm still not catching on | 17:06 |
| valentind | Let's say in project.conf, you include a.bst:a.conf and b.bst:b.conf. | 17:06 |
| tristan | Right | 17:06 |
| tristan | following | 17:07 |
| valentind | Let's say a.bst:a.conf modifies the behavior of b.bst. | 17:07 |
| tristan | hold on there | 17:07 |
| valentind | And b.bst:b.conf modifies the behavior of a.bst. | 17:07 |
| tristan | slow down | 17:07 |
| tristan | "modifies the behavior" | 17:07 |
| valentind | For example options. | 17:07 |
| tristan | What is modifies the behavior ? | 17:07 |
| valentind | Wait, I have maybe better. Let me think. | 17:07 |
| valentind | YEs. | 17:08 |
| valentind | You can override source plugin configuration. | 17:08 |
| valentind | And junctions depends on source plugins. | 17:08 |
| tristan | Aha! | 17:08 |
| valentind | source override something. | 17:08 |
| tristan | not sure that is the final Aha!,... lets see where it goes... | 17:08 |
| tristan | So a project.conf can globally modify sources or elements by their "kind", yes | 17:09 |
| tristan | Where do things go wrong, we need a scenario | 17:09 |
| *** jcampbell has joined #buildstream | 17:09 | |
| tristan | project.conf includes a.bst:a.conf... this causes a junction load of a.bst junction... a.conf from a.bst modifies source behaviors in the calling project.conf... invalidating how a.bst was originally loaded. | 17:10 |
| tristan | valentind, basically ? | 17:11 |
| valentind | Well, this would be OK to just say we keep it loaded like that. | 17:12 |
| valentind | The problem comes when you have several junctions that can influence each others. | 17:12 |
| valentind | Then you cannot really decide because you need ordering. | 17:12 |
| tristan | Not necessarily right ? I mean it's conceivable that a project.conf setting can influence the source you used to download the project overriding that setting | 17:13 |
| tristan | I dont follow now | 17:13 |
| valentind | So basically at the end you want to say all junctions behaves like nothing was included. | 17:13 |
| tristan | Not anymore | 17:13 |
| valentind | OK, so in theory, it breaks like you say. Junctions need the full configuration. Full configuration needs the junctions. | 17:15 |
| tristan | Ok so... first problem is, we cannot use project.conf overridden variables in junction declarations; which is pretty annoying because we quite recommend using variable expansion in junction declarations | 17:15 |
| valentind | tristan, for sure you cannot use it. And yes, it is annoying. | 17:16 |
| tristan | There is something at least possibly circular about this to be sure | 17:16 |
| tristan | However, I dont feel like I've explored the problem enough | 17:16 |
| tristan | Intuition says that while circular chains can obviously form; the nature of a buildstream project is top-down dependency wise | 17:17 |
| tristan | Such that, it might be that there is a way to crunch this top down one by one, so long as there isn't something circular found | 17:17 |
| tristan | but then, not sure | 17:18 |
| tristan | the loading is top down however include asks for the opposite | 17:18 |
| tristan | valentind, it would seem to me that... lets imagine first that you *know* you have all the elements of all the projects on hand | 17:19 |
| tristan | valentind, it would seem to me that we might want some kind of double phase where we first collect includes bottom up and then start processing the load top-down | 17:21 |
| tristan | of course that ignores the problem of junctions | 17:21 |
| valentind | But you go from project.conf. You can only go top-down. | 17:22 |
| *** tiago has quit IRC | 17:23 | |
| *** jcampbell has quit IRC | 17:25 | |
| *** tristan has quit IRC | 17:26 | |
| *** jcampbell has joined #buildstream | 17:26 | |
| valentind | tristan, I am not sure I understood here what you mean by collecting includes bottom up. | 17:26 |
| *** tristan has joined #buildstream | 17:35 | |
| tristan | valentind, oops... what was my last ? | 17:35 |
| tristan | ah, lost all of it according to the log... one sec... | 17:36 |
| tristan | <tristan> I'm still pretty lost I think | 17:36 |
| tristan | <tristan> valentind, "The problem comes when you have several junctions that can influence each others." | 17:36 |
| tristan | <tristan> I think I have to understand still how that is possible | 17:36 |
| tristan | <tristan> junctions which can "influence each other" | 17:36 |
| tristan | <tristan> So, lets define what causes that to arise, and inspect whether that should be an error ? | 17:36 |
| tristan | <tristan> project A depends on projects B and C.... fine... the order in which files included from C and B are applied in project A is dictated by the order of the (@) include directives | 17:36 |
| tristan | <tristan> Then, project B depends also on project C... in *any* case project A cannot apply the fragment included from project B... until that fragment from project B has completely composited *it's* include from project C | 17:36 |
| tristan | <tristan> ...Along the way... we are loading junctions... and that somehow changes something... but I'm not entirely sure how | 17:36 |
| tristan | <tristan> Concretely, the only problem I'm really seeing, is that the definition of a junction may have changed as a result of it's being loaded | 17:36 |
| tristan | <tristan> valentind, and in *that* case, it is not enough to just say "junctions cannot use (@) directives" | 17:36 |
| tristan | <tristan> because variables can be used to declare the junction, and can also be overridden in the project.conf by the include file in the loaded junction | 17:36 |
| *** jonathanmaw has quit IRC | 17:40 | |
| valentind | tristan, Yes. the main problem is that a junction can change after a file from there has been loaded in the top level project.conf. But if you try to work around that, you will find that we cannot work around the problem when there are multiple junctions. The point with the multiple junction case is that it is not easy to try to work around it. | 17:47 |
| valentind | But it is of course already a problem with the simple case. | 17:48 |
| *** bochecha has quit IRC | 17:50 | |
| *** bochecha has joined #buildstream | 17:50 | |
| *** bochecha has quit IRC | 17:51 | |
| *** bochecha has joined #buildstream | 17:51 | |
| *** bochecha has joined #buildstream | 17:51 | |
| valentind | tristan, you are correct in what you say. | 17:52 |
| *** bochecha has quit IRC | 17:52 | |
| *** bochecha has joined #buildstream | 17:52 | |
| *** bochecha has quit IRC | 17:52 | |
| *** bochecha has joined #buildstream | 17:53 | |
| valentind | tristan, so to solve the problem, I just said, let's interpret twice project.conf. Once without includes, once with includes. Then we give the one without includes to junctions. | 17:53 |
| *** bochecha has quit IRC | 17:53 | |
| valentind | And by without include, I actually fixed it now to strip all (@) directive completely for this pass. | 17:54 |
| *** bochecha has joined #buildstream | 17:54 | |
| *** bochecha has quit IRC | 17:54 | |
| *** bochecha has joined #buildstream | 17:54 | |
| *** bochecha has quit IRC | 17:55 | |
| *** bochecha has joined #buildstream | 17:55 | |
| *** bochecha has joined #buildstream | 17:55 | |
| *** bochecha has quit IRC | 17:56 | |
| *** bochecha has joined #buildstream | 17:57 | |
| *** bochecha has joined #buildstream | 17:57 | |
| *** bochecha has joined #buildstream | 17:58 | |
| *** bochecha has quit IRC | 17:58 | |
| *** bochecha has joined #buildstream | 17:59 | |
| *** bochecha has quit IRC | 18:02 | |
| tristan | valentind, got stuck in an email window :-S | 18:02 |
| tristan | valentind, not an easy problem :-S | 18:04 |
| tristan | the problem is at least much simpler to understand now | 18:05 |
| tristan | valentind, so what happens when you reload that same junction the second time ? | 18:05 |
| tristan | valentind, when you find out that it's been modified by affected variables from the post-include phase, and you discover that you must re-load that junctioned project entirely a second time from scratch ? | 18:06 |
| tristan | hehe | 18:06 |
| tristan | I guess you don't do that but... there is still no answer | 18:06 |
| valentind | No. What I have is Project has twice some of the configuration. And junctions only use configuration prior to includes. | 18:16 |
| valentind | tristan, so now on my branch, junctions will always behave the same, it will ignore includes in project.conf. | 18:16 |
| tristan | right, junctions wont take project.conf includes into account | 18:17 |
| tristan | that sounds reasonable | 18:17 |
| valentind | So it m | 18:17 |
| valentind | So it makes it possible. | 18:17 |
| valentind | But now I just have to deal with tracking junctions. | 18:17 |
| valentind | tristan, however, I could say that local includes are always included. | 18:18 |
| tristan | Ok so, "junctions influencing other projects" and "order in which junctions are loaded"... are things which I can safely forget about right ? | 18:18 |
| valentind | tristan, I have not done that, but this behavior would not be problematic. | 18:18 |
| valentind | tristan, Yes. You can forget about. It is the same problem. It just shows you cannot hack around it. | 18:18 |
| valentind | And this situation works with my solution. | 18:19 |
| tristan | So the only thing left is to raise a more decent error in the case that you are loading a project which depends on junctions but fails to specify a ref ? (the "Inconsistent junction source error" ?) | 18:20 |
| tristan | valentind, I dont want to jump too quickly into making separate API surfaces in the CLI for junctions | 18:21 |
| valentind | tristan, I removed that. | 18:21 |
| valentind | I kept the "if"s. But I just check that kind is "junction". | 18:22 |
| tristan | if we must, let's discuss it on the ML, there are reasons that junctions are very much like elements, and reasons why users have to consider junctions differently | 18:22 |
| valentind | tristan, Ah you mean in the client. Yes. OK. | 18:23 |
| valentind | I can try to make the second pass load lazy. We can because there now Project.load_elements that could potentially load the configuration if needed. | 18:25 |
| valentind | I am not completely sure though. I will see where this goes. | 18:25 |
| tristan | right, I think this all started because you wanted to autotrack junction elements, and I want that to remain explicit | 18:26 |
| tristan | but the whole walk through the park helped me understand the problem better :) | 18:27 |
| valentind | Good. I am happy that you understand what I have been struggling with. | 18:27 |
| tristan | haha | 18:27 |
| tristan | Yeah I still dont follow the junctions influence other junctions hehehe | 18:28 |
| tristan | but that only happens when you tackle things a certain way | 18:28 |
| *** Prince781 has quit IRC | 19:54 | |
| *** cs_shadow has quit IRC | 20:36 | |
| *** tristan has quit IRC | 21:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!