On Tue, Oct 18, 2016 at 11:35 AM, Vladimir Prus <vladimir.prus@gmail.com> wrote:

Rene,

thanks for the write up. I have two brief points to make, might have more later.

On 18-Oct-16 4:59 PM, Rene Rivera wrote:

of logic at the project declaration layer; Too big to embed (needs
external install and linking); Heavyweight run-time, and hence slower
startups.

I am not sure I agree. Python is not tiny, but you can link with the
interpreter and provide a useful subset of the standard library as
a zip file, it worked quite satisfactory when we needed to bundle GDB
with Python support.

Sure.. I've done such embedding. But I don't know if doing that removes the benefits of not embedding it. For Lua there isn't much of a choice, you need to embed it for it to be of much use. But for Python not embedding it seems to provide more benefits. For example, being able to install packages. Does installing packages work when you are embedding it?

Also, startup time for Python itself has been
negligible for me for years.

Perhaps things have improved since the last time I needed to embed it. But perhaps it's also that I was embedding it into the rather limited Xbox360 and PS3 systems. Having said that.. I do have a lofty goal of what the b3 startup build times could be. So that may be affecting my choices. For example.. I think it's possible to design things such that we can start building a first target in under 2 seconds from launch.

Relatedly, I think what we have now is an important factor. It is not
like we have dozens of people willing to contribute. Python port was
initially contributed out of the blue by Pedro Ferreira in 2005. Later,
I had a one-month sabbatical to push it further, which was enough to
known down many test failures, but not much more. Now, Aaron has been
working on it. That's not many of people :-)

Sure.. But I would expect a bit more people contributing to this new effort.

So it would seem to me that it's most reasonable to work on what we have, and it seems like Python port does not have any fundamental
limitations, rather than consider completely different alternative.

It does seem reasonable, to an extent. When we start thinking of interfacing with IDEs that are written in other languages it starts getting messy (assuming we want direct code level integration). For example, VS would require a C# extension; CLion and Eclipse would be Java. Now it's possible we can do the integration with a client-server setup, but that will likely make things slower (obviously depending on the design). So having a fully functional core as a shared library seems like a good idea to me.

It might be great to improve the build engine too, and doing so in C++
will be better than in C, but it seems to me that core build logic better be in Python.

Perhaps :-) Don't fully know at the moment. And I'm willing to go down that route. Since it's easy enough to move things down from Python to C++ as they match up well as far as functional design.

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail