<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 18 Jul 2022 at 17:12, Joey Hess <<a href="mailto:id@joeyh.name">id@joeyh.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Karel Gardas wrote:<br>
> Thanks for the talk and for the arduino and zephyr support. However seen<br>
> this I can't resist to think that you basically turn copilot upside down and<br>
> make that a real "pilot". E.g. you turn all the sampling of system variables<br>
> and comparing with the spec idea to let's make it a real C code and run that<br>
> instead. Am I right or still not getting whole idea behind the Copilot?<br>
<br>
Yes, the Arduino is being piloted without anyone in the other seat, as it<br>
were.</blockquote><div><br></div><div>I've seen other people do this too (that is, using Copilot as a stream processing or dataflow language to control systems, not monitor them).</div><div><br> </div><div>It's something that likely has not been explored enough in the context of Copilot. In the domain where Copilot is applied, there are other languages that I expect might be more expressive (Scade comes to mind).<br></div><div><br></div><div>I'd be interested in seeing more examples, and the plumbing necessary in each case. If "piloting", as you call it, is a use case we ever decide to support, that'll help us design the language right.</div><div><br></div><div>Ivan</div></div></div>