Date: Thu, 15 Jun 2023 14:23:30 -0500
On Thu, Jun 15, 2023 at 2:06 PM Olga Arkhipova <olgaark_at_[hidden]> wrote:
>
> >> Can someone point out some concrete examples of that situation that I can investigate?
>
> One of the examples I had in mind is cross platform development like developing for Linux on Windows in VS, where build (and all build tools) are running on Linux side, and VS IDE on Windows side.
> Sure, there is a communication channel between the machines, but reading a json file on a different machine is much simpler/robust/faster than launching a process and then transferring its output.
>
> And even when developing on the same OS as build tools are running on - the build environment where tool exe can actually be launched (as it, say, depends on some other binaries to be found there) can be quite different from the IDE environment - i.e. you might not be able to launch a build tool directly from the IDE.
>
> My main point is that many more things can go wrong when you are launching a process than when you read an existing json (text) file. The process might require a special (and different from the caller) environment. Reading a json file (even if you transfer it between the machines) is much simpler.
I can see how it would be easier in those remote execution situations
to have the introspection information as a file. I also talked with
some friends that do super-computing development. And there are cases
where not only is it not easy to remote execute but it may not be
possible at all. Hence I'm thinking we definitely need to account for
having the information as a related file. I have an idea for how to
approach this that can hopefully cover all the use cases in the most
convenient form for almost everyone. I'm going to write that part up
in the paper before tomorrow's discussion. But it will likely be rough
and full of errors :-)
> Thanks,
Thank you for the examples. Very useful.
>
> >> Can someone point out some concrete examples of that situation that I can investigate?
>
> One of the examples I had in mind is cross platform development like developing for Linux on Windows in VS, where build (and all build tools) are running on Linux side, and VS IDE on Windows side.
> Sure, there is a communication channel between the machines, but reading a json file on a different machine is much simpler/robust/faster than launching a process and then transferring its output.
>
> And even when developing on the same OS as build tools are running on - the build environment where tool exe can actually be launched (as it, say, depends on some other binaries to be found there) can be quite different from the IDE environment - i.e. you might not be able to launch a build tool directly from the IDE.
>
> My main point is that many more things can go wrong when you are launching a process than when you read an existing json (text) file. The process might require a special (and different from the caller) environment. Reading a json file (even if you transfer it between the machines) is much simpler.
I can see how it would be easier in those remote execution situations
to have the introspection information as a file. I also talked with
some friends that do super-computing development. And there are cases
where not only is it not easy to remote execute but it may not be
possible at all. Hence I'm thinking we definitely need to account for
having the information as a related file. I have an idea for how to
approach this that can hopefully cover all the use cases in the most
convenient form for almost everyone. I'm going to write that part up
in the paper before tomorrow's discussion. But it will likely be rough
and full of errors :-)
> Thanks,
Thank you for the examples. Very useful.
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
Received on 2023-06-15 19:23:45