| *** brlogger has joined #automotive | 08:59 | |
| *** pedroalvarez has left #automotive | 09:08 | |
| paulsherwood | ah, i notice that someone from #baserock already acted on my request, so logging has started. if ulf` or others would prefer an alternative approach we can kill brlogger | 09:10 |
|---|---|---|
| persia | To comply with freenode policy, we ought get that in the /topic | 09:13 |
| *** persia changes topic to "Automotive Linux Discussion | Channel logs at https://irclogs.baserock.org/automotive/" | 09:14 | |
| *** dabukalam has joined #automotive | 09:14 | |
| paulsherwood | could you make that 'currently at' for now? :) | 09:15 |
| *** persia changes topic to "Automotive Linux Discussion | Channel logs currently at https://irclogs.baserock.org/automotive/" | 09:16 | |
| persia | There's no ACL, so if you want to change again, please use /topic :) | 09:16 |
| paulsherwood | :) | 09:17 |
| *** Luming has joined #automotive | 09:36 | |
| fredericocadete | that was fast | 09:57 |
| olivier | thanks ! | 09:57 |
| paulsherwood | :) | 09:59 |
| paulsherwood | i just asked on the lists where the AGL repos are... does anyone here know the answer? | 09:59 |
| * paulsherwood imagines that some engineers would prefer to talk on irc rather than the ml | 10:00 | |
| *** tcouniha has joined #automotive | 10:02 | |
| fredericocadete | I do not know of any repositories | 10:02 |
| fredericocadete | the wiki mentions a git server but says it's a placeholder (see https://wiki.automotivelinux.org/agl-distro) | 10:04 |
| paulsherwood | yup, i saw that. but then also i'm *sure* that this needs to be based heavily on openembedded layers, and then probably some yocto layers including meta-ivi... | 10:05 |
| paulsherwood | i'm not an oe/yocto expert, so i don't even know yet how this process of mixing layers is done to keep things tidy over the long term without forking | 10:05 |
| *** olivier has quit IRC | 10:22 | |
| boucman_work | paulsherwood, basically any layer can override anything on any layer it depends on, so it's pretty easy to not fork, just do an overlay | 10:29 |
| boucman_work | but IIUC the AGL repos/layer are being heavily reworked right now, so i'd wait for it to settle down | 10:29 |
| paulsherwood | boucman_work: i think you're right. i'd just like to know who is doing that heavy rework, and where the work-in-progress is. would be a shame if it was just dumped over the wall, so to speak :) | 10:31 |
| paulsherwood | particularly as some of the folks here are eager to help | 10:31 |
| paulsherwood | boucman_work: also, i may be wrong, but if folks override everything, doesn't that pretty much create the same issues as forking? | 10:33 |
| boucman_work | yes and no... afaik from the yocto world, there is very few hidden forks, it's more tweaks for the particular needs of a particular overlay | 10:35 |
| paulsherwood | ok cool! :) | 10:41 |
| *** Armin_ has joined #automotive | 12:35 | |
| Armin_ | hey guys | 12:36 |
| Armin_ | Would anyone know how to draw a torque curve of my car | 12:36 |
| paulsherwood | Armin_: that's a very interesting question... most of the folks on this channel are interested in software for vehicles. i expect there must be some way to use rpm and speed, vs known weight of the car, for each gear? but i'm totally guessing | 12:44 |
| paulsherwood | what level of accuracy are you aiming for? | 12:44 |
| * paulsherwood googles a bit more... there may be other variables required | 12:45 | |
| Armin_ | well | 12:46 |
| Armin_ | I'm aiming at | 12:46 |
| Armin_ | ~ 50 RPm up or down | 12:46 |
| Armin_ | I know max rpm | 12:46 |
| Armin_ | 112Nm @ 3000 RPM | 12:46 |
| *** sebh has joined #automotive | 12:48 | |
| paulsherwood | how do you know/deduce the 112Nm? | 12:49 |
| Armin_ | I dont I read it on the engine chart | 12:50 |
| Armin_ | it says max torque | 12:51 |
| paulsherwood | heh. | 12:51 |
| * paulsherwood doesn't trust specsheets, normally | 12:51 | |
| Armin_ | dont know how to calc it but nevermind | 12:52 |
| Armin_ | it doesnt really have any practical use | 12:52 |
| *** emaj has joined #automotive | 12:56 | |
| fredericocadete | you could probably set up your car on a dyno | 12:57 |
| fredericocadete | they could have one at a big car repair shop | 12:58 |
| *** Armin_ has left #automotive | 13:00 | |
| *** jonathanmaw has quit IRC | 13:02 | |
| *** jonathanmaw has joined #automotive | 13:47 | |
| fredericocadete | question: does anyone know if GENIVI/AGL has a preference for configuration file format? as in xml / json / yaml, or some obviously-much-better domain-specific format? | 13:56 |
| * rjek would disrecommend XML and JSON to anyone who would listen | 13:56 | |
| fredericocadete | (assuming .ini is not enough, need at least array support | 13:57 |
| fredericocadete | thank you rjek | 13:57 |
| fredericocadete | any altermatives? | 13:57 |
| rjek | I don't hate yaml or ini | 13:57 |
| rjek | yaml's much more expressive | 13:57 |
| fredericocadete | I thought of yaml but the whitespace sensitivity could get me hanged; I am not sure how my downstream developers will handle space vs tabs | 13:58 |
| mdunford | rjek: "don't hate" is fairly positive in this context? :) | 13:58 |
| rjek | Correct. | 13:58 |
| * rjek uses none of the formats mentioned so far in his own, personal, software. | 13:59 | |
| rjek | But I think INI or yaml would be fine | 13:59 |
| rjek | If your configuration structure is not complex, INI is file, but if it is INI is pain that is worth swapping for whitespace sensitivity | 13:59 |
| fredericocadete | I was on the fence between yaml or json; no standard comment support in json is a real shortcoming | 14:00 |
| rjek | Yes | 14:01 |
| rjek | And it wears out your { } keys | 14:01 |
| rjek | JSON exists because it's quick to parse client-side in web-apps. That's basically the only reason to consider it | 14:01 |
| fredericocadete | then again JSon is supported by more toolkits and comments are not so important if you have Json schema documentation | 14:02 |
| fredericocadete | so I hesitate until death, or unless GENIVI/AGL mandate something on me :) | 14:03 |
| boucman_work | I don't know what it means to have a configuration format defined for a distro... | 14:04 |
| boucman_work | there are so many config files... unless you mean the config of the layers in which case it's more or less fixed to what the bitbake infrastructure forces on us | 14:05 |
| fredericocadete | good question. it's more in terms of convention, what developers that are used to GENIVI will find more common | 14:06 |
| fredericocadete | but I am bikeshedding with myself, it doesn't matter that much in the end | 14:06 |
| persia | fredericocadete: I think that's an optimisation that cannot be done. | 14:06 |
| persia | There's too many layers of too much upstream software from too many sources. | 14:06 |
| boucman_work | I really think saying that genivi/agl has a standard config format is counterproductive. it just... doesn't make sense. there is no such thing as "the config file of a distro" only apps have config files | 14:07 |
| persia | We could say "We like YAML" all day, but there's going to be lots of non-YAML around, so developers are going to have to understand the other formats. | 14:07 |
| boucman_work | and most apps are third parties as far as genivi/agl is concerned so we can't force a format on them | 14:07 |
| boucman_work | a dev that develops the OS layers of genivi will need to know the config format of whatever software he is configuring | 14:08 |
| paulsherwood | fredericocadete: spaces vs taps? simple... outlaw tabs! :-) | 14:08 |
| paulsherwood | fredericocadete: json is a subset of yaml. so specify yaml and let them deliver as json if they insist? :-) | 14:09 |
| * rjek frowns at paulsherwood | 14:09 | |
| paulsherwood | why, rjek ? | 14:09 |
| rjek | No reason, just practising for later | 14:09 |
| paulsherwood | boucman_work: for some solutions, 'the config file of a distro' does kind of have a meaning | 14:10 |
| boucman_work | ok, could you give an example ? I might be too focused on my own use-case | 14:11 |
| paulsherwood | eg yocto/oe recipes, baserock definitions. cloudfoundry manifests. there are lots of cloud technologies handling 'configuration' ... chef, puppet, ansible etc | 14:12 |
| paulsherwood | they're really all integrations that depend on the lower level config of the apps, though | 14:13 |
| boucman_work | yes, seeding a distro... ok. In that case, the recommanded format for AGL is the OE .cfg format, as parsed by bitbake :P | 14:13 |
| paulsherwood | s/apps/system software and apps/ | 14:13 |
| paulsherwood | boucman_work: i'm not qualified to comment on that yet... i know a lot about baserock, not much about bitbake | 14:14 |
| * boucman_work was in the yocto world recently | 14:14 | |
| paulsherwood | but if it works, then you may be right - i think agl is standardising on yocto/oe anyway, so bitbake has to be part of the solution | 14:14 |
| paulsherwood | boucman_work: i've been asking some questions there today. rburton was helpful, but there are still some things not clear to me | 14:15 |
| paulsherwood | s/there/in #yocto/ | 14:15 |
| fredericocadete | the original question was definitely for runtime configuration, as in a config file that can be read from the rootfs to be more flexible at least during the development phase | 14:18 |
| fredericocadete | for built time configuration I am already too into yocto to even pose myself the question ... | 14:19 |
| paulsherwood | :) | 14:19 |
| paulsherwood | fredericocadete: will the things reading the config be written in any particular languages/technologies? or to put it another way, would the consumers of the config be able to parse yaml easily? | 14:21 |
| paulsherwood | boucman_work: it the third parties are interacting with genivi/agl it may not be so hard to get them to adopt a common format? | 14:22 |
| paulsherwood | prticularly if the format choice is sensible, open etc | 14:23 |
| fredericocadete | paulsherwood: qt is a possible candidate for consumer, and it does have Json, XML and Ini support, but no yaml | 14:23 |
| paulsherwood | aha. | 14:24 |
| boucman_work | paulsherwood, I really have trouble making sense of your remarks, it seems you are mixing application developement (where config format is in the sole hand of whoever develops the apps) and Distro developement (where there are various formats, and the "main" format is the yocto config format. AGL doesn't have anything to decide here) | 14:24 |
| * persia concurs with boucman_work | 14:25 | |
| paulsherwood | boucman_work: you may be right, i'm sorry. new to this :) | 14:25 |
| fredericocadete | paulsherwood: my fear was mostly that genivi had defined a preferred format I was not aware of, as seems to be the case for the FIDL interface description language and common-api IPC system. Of course interoperability is much more important for IPC than for configuration | 14:26 |
| persia | In the event that someone decides to create a *new* component, it may be possible to have guidelines, but in general, it's probably best to let the developers working on that component decide amoungst themselves, so as to be something they are most comfortable using, so they can be most productive. | 14:26 |
| boucman_work | paulsherwood, are you comming from a "deep embedded"/firmware world ? in that sort of dev (which is common in automotive) the BSP provider tends to impose a format that works the way you think, but when moving to linux, you need to drop the firmware frame of thought | 14:26 |
| paulsherwood | boucman_work: maybe i've been in management too long, and think engineeriing is easier than it actually is. certainly my colleagues accuse me of that sometimes | 14:27 |
| *** waltminer has joined #automotive | 14:27 | |
| paulsherwood | on a powerpoint, it's always trivial :-) | 14:28 |
| boucman_work | paulsherwood, no worries... yocto is an extremely powerfull environement which provides huge benefits for it's learning cost, but the learning cost is not low. It takes some time to master... | 14:28 |
| paulsherwood | right. i'm staring at that mountain, wondering how/when and how far to climb :) | 14:29 |
| *** amcgee7 has joined #automotive | 14:29 | |
| paulsherwood | in the meantime, all i hope to do is help the discussion - if i'm saying dumb things, i'm happy for others to correct me | 14:29 |
| *** olivierdelbeke_ has joined #automotive | 14:50 | |
| *** e8johan has quit IRC | 14:50 | |
| *** bbranch has joined #automotive | 14:56 | |
| *** gvancuts has joined #automotive | 14:58 | |
| *** waltminer has quit IRC | 15:00 | |
| *** jonathanmaw has quit IRC | 15:03 | |
| *** amcgee7 has quit IRC | 15:13 | |
| *** lemagoup has joined #automotive | 15:43 | |
| *** jonathanmaw has joined #automotive | 15:45 | |
| *** rstreif_ has joined #automotive | 15:52 | |
| *** olivierdelbeke_ has quit IRC | 15:58 | |
| *** boucman_work has quit IRC | 16:07 | |
| *** bbranch1 has joined #automotive | 16:14 | |
| *** bbranch has quit IRC | 16:15 | |
| *** jlrmagnus has joined #automotive | 16:18 | |
| *** bbranch1 has quit IRC | 17:00 | |
| *** jonathanmaw has quit IRC | 17:05 | |
| *** mdunford has quit IRC | 17:12 | |
| *** e8johan has joined #automotive | 17:50 | |
| *** e8johan has quit IRC | 18:24 | |
| *** bbranch has joined #automotive | 18:52 | |
| *** bbranch has left #automotive | 18:52 | |
| *** juergbi` is now known as juergbi | 19:13 | |
| *** bjones has joined #automotive | 19:55 | |
| *** bjones has quit IRC | 22:04 | |
| *** emaj has quit IRC | 22:20 | |
| *** lemagoup has quit IRC | 22:42 | |
| *** lemagoup has joined #automotive | 22:43 | |
| *** dabukalam has quit IRC | 23:24 | |
| *** dabukalam has joined #automotive | 23:25 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!